Monday August 29, 2005 Building Shale with Maven
So I decided to build Shale with Maven....
The good new is that there is a manual for building Shale from scratch. Let's start using that manual.
It starts with pulling the sources from Subversion. Wait I can do that - even if I'm behind a firewall and corporate proxy. If you've never done that, just make sure that you have the http-proxy-port and http-proxy-port set. Normally, this should work like a breeze, unless your company is using a proxy that rejects unknown headers. In that case, there might be a simple workaround: use https instead of plain old http in your URL.
Now that went pretty easy. I simply did svn co http://svn.apache.org/repos/asf/struts/shale/trunk/ shale. The second argument ('shale') simply makes sure that the trunk is extracted into a 'shale' directory, instead of a 'trunk' directory. (If you're using subversion for a while, then you'll come to notice that all projects try to extract their sources to the same 'trunk' directory. So you make sure you adopt the habbit of extracting it into a project specific directory right away.)
The manual continues by stating that you should now copy build.properties files and modify it by hand, suggesting that Ant is the only way to build it. However.... it appears that all directories contain project.xml files, which happen to be Maven (1) project files. Great. Let's give it a try:
> maven multiproject:goal -Dgoal=jar:install ... +---------------------------------------- | Executing clean Shale Core Library | Memory: 4M/4M +---------------------------------------- Attempting to download tiles-core-0.2-dev.jar. WARNING: Failed to download tiles-core-0.2-dev.jar. Attempting to download spring-webflow-PR4.jar. WARNING: Failed to download spring-webflow-PR4.jar. ...
Whoops. That didn't work out very well. Although it started to run just like that, it will eventually fail due to some missing jars that it can't download. Normally, Maven would download these files from the repository at http://www.ibiblio.org/, but it appears to be unable to download these files. Bugger.
I'm leaving the manual now for what it is. It doesn't tell you how to fix this, so let's see if we can fix it ourselves. First I'm gonna see if I can resolve the Tiles dependency. I heard some rumours about Tiles being factored out from the Struts project, in order be usable as a separate entity. Let's see.....
David Geary's blog says that he turned it into a separate sandbox project. Again, I will need to check it out from Subversion. Too bad I can't download just the Tiles project. Instead I need to download the entire Struts trunk:
svn co https://svn.apache.org/repos/asf/struts/current/ tiles
Note that - again - I needed to use the HTTPS protocol in order to prevent the proxy server from blocking my request because of unknown headers. Let's move into the struts/sandbox/tiles directory and proceed:
maven jar:install
....
[junit] Tests run: 5, Failures: 0, Errors: 0, Time elapsed: 0.586 sec
[junit] Running org.apache.tiles.TestComponentDefinitions
[junit] Tests run: 3, Failures: 0, Errors: 0, Time elapsed: 0.149 sec
jar:jar:
[jar] Building jar: /workspace/struts/sandbox/tiles/target/tiles-core-0.2-dev.jar
Copying: from '/workspace/struts/sandbox/tiles/target/tiles-core-0.2-dev.jar' to: '/home/wilfred/.maven/repository/tiles/jars/tiles-core-0.2-dev.jar'
Copying: from '/workspace/struts/sandbox/tiles/project.xml' to: '/home/wilfred/.maven/repository/tiles/poms/tiles-core-0.2-dev.pom'
BUILD SUCCESSFUL
Total time: 45 seconds
Finished at: Mon Aug 29 13:37:08 CEST 2005
Now the 'jar:install' target made sure that the tiles-dev-0.2-dev.jar file is now installed in my local Maven cache of jar files. This means that the only unresolved dependency is spring-webflow-PR4.jar. Hmmmmm.
It appears that the required sources can be found at sourceforge. Problem is that this time the sources are stored in CVS, and my proxy won't tunnel CVS requests. So time to retrieve the old SOCKS server and figure a way out to force CVS in using the SOCKS server.....
I eventually end up using proxychains, which happens to be hosted at sourceforge.net as well. This tool allows you to invoke any command. If it notices that the command being invoked is trying to access the TCP/IP layer, it will intercept it and decide if it should proxy the request. SOCKS5 is just one of the options, but in my case it worked fine. After I configured proxychains, I simply invoked:
proxychains cvs -d ':pserver:anonymous@cvs.sourceforge.net:/cvsroot/springframework' co spring-projects
Since I'm only interested in the spring-webflow-PR4.jar code, I'm cd-ing to the spring-webflow directory.
Building this thing appears to be base on Ivy. *sigh* (I wish everybody would turn to Maven.) The cool thing is that it is simply Ant with extensions, but then again, I now need to make sure that Ant knows how to use my proxy. This does not work:
ANT_OPTS="-Djava.http.proxySet=true -Djava.http.proxyPort=... -Djava.http.proxyHost=...."
Funny, I always thought that this worked... Maybe this works:
ANT_OPTS="-Dhttp.proxySet=true -Dhttp.proxyPort=... -Dhttp.proxyHost=...."
Yep. It worked. If I now simply type 'ant', than it will download all of the required dependencies, and build the library.
Now I run into a problem. According the Shale project model, it depends on version PR4 of this file. But the build file just created a ./target/dist/jars/spring-webflow-rc1-dev-20050829115656.jar file. I can't really tell if this would be compatible, and I'm just too darn lazy to go and figure it out. Let's simply copy this file into my local Maven cache. (Since I'm working with Maven 1, I can ommit all of the other metadata that would probably be reuqired in Maven 2.)
cp ./target/dist/jars/spring-webflow-rc1-dev-20050829115656.jar ~/.maven/repository/springframework/jars/spring-webflow-PR4.jar
Let's try if we can now build Shale entirely:
[javac] Compiling 66 source files to /workspace/shale/core-library/target/classes
/workspace/shale/core-library/src/java/org/apache/shale/tiles/TilesViewHandler.java:29: package javax.faces.application does not exist
import javax.faces.application.ViewHandler;
^
/workspace/shale/core-library/src/java/org/apache/shale/tiles/TilesViewHandler.java:31: package javax.faces does not exist
import javax.faces.FacesException;
^
/workspace/shale/core-library/src/java/org/apache/shale/tiles/TilesViewHandler.java:32: package javax.faces.application does not exist
import javax.faces.application.ViewHandler;
...
What the...?! Ok, apparently I'm missing the JSF jar. As you may have learned, the reference implementation of JSF has just been made available under the CDDL license, so a jsf-api.jar and jsf-impl.jar might end up in the Maven repository in the future. At this stage, I'll need to figure out something else though.
... After looking around in the sources for a while, it appears that there are mechanisms to work around this problem: the project root contains a maven.xml file. This file contains a snippet of Jelly code overriding the location of the JSF jars at build time. Simply setting the maven.shale.jsf.api.jar and maven.shale.jsf.impl.jar properties should work.
maven \ -Dmaven.shale.jsf.api.jar=/home/wilfred/local/jsf-1_1/lib/jsf-api.jar \ -Dmaven.shale.jsf.impl.jar=/home/wilfred/local/jsf-1_1/lib/jsf-impl.jar \ multiproject:goal \ -Dgoal=jar:install
.... and it worked! The compilation phase completed, but one of the tests failed....
( Aug 29 2005, 02:47:15 PM CEST ) Permalink Comments [3]