Thursday, October 22, 2009

Looking at JBI and Camel

I've been distracted by doing a couple of webinars on Camel so I haven't had a lot of time to spend on digging into my original blog post on Camel, CXF, and ServiceMix / JBI working well together. From looking at the JBI spec it seems that for WSDL 1.x, JBI does 'mandate' using the JBI XML wrapper. My sense is that since I'm having the CXF components work with / generate from a WSDL 1.1, it seems reasonable that would wrap the XML message. The other ServiceMix components are magically generating the NMR / WSDL binding for me so apparently its up for debate if the must use the JBI wrapper element - if they generate WSDL 2.0, the wrapper element is optional.

From looking at the JMS and HTTP components, its clear that there is a framework in place using Camel interceptors to add the JBI or SOAP envelopes when needed.

At this point, I'm going to let the dust settle with Camel 2.0, ServiceMix 4.x, etc. before I dig in more on how to get Camel's jbi endpoint to do the right thing with that jbi message wrapper….

Thursday, October 1, 2009

Setting up Nexus as a local Maven Repository Manager

I do a lot with Apache Maven, and I kept hearing about how Nexus helps with better managing your local Maven repository, especially if you go offline a lot, which I do. I was pleasantly surprised as how easy it was to setup and that it did actually seems to speed up my Maven project builds. Sad to get excited about a product that actually does what it claims...

My needs are pretty modest in regards to Maven, and most of the Maven projects I deal with are small, so normally dealing with annoyances of offline and/or configuring m2eclipse to know about the 2 other Maven repos I use isn't that bad. However, when I started trying to build all of ServiceMix (24+ Maven projects) and started to see lots and lots of waiting on downloading various dependencies, I decided maybe I'd see if Nexus could help.

The install of the Nexus Open Source is very straightforward - untaring a tar ball - and starting the Nexus server was as easy as bin/nexus start. Sonatype provides a great (free) on-line book on Nexus - Repository Management with Nexus - that provides good instructions on installation and initial configuration. There isn't much configuration by default except for modifying your Apache Maven ~/.m2/settings.xml file to use the Nexus server versus looking on the Internet for dependencies.

The biggest challenge I had was since I was dealing with a large project which references ~12 other Maven Repositories (Nexus ships with Maven Central and Apache Repos configured) I had to add in those other repositories into Nexus so it could proxy them. Again the Nexus book provides a great section on how to know your missing a repo entry and how to add custom repos into Nexus. After I did a couple, it was very straightforward to figure out the other 10 or so custom repos that ServiceMix requires.

What I saw was that now with Nexus it felt that the ServiceMix built went much faster - maybe 10-20 % - I guessing mostly from just quick all local machine lookups on dependencies. It also felt that Nexus was a little smarter about how it downloaded dependencies from the Internet, not positive on that. Regardless, I noticed a build speed up and a dramatic reduction in network traffic during the build.

I also saw that using m2eclipse was much easier, which makes sense since both Nexus and m2eclipse are developed by the folks at Sonatype. m2eclipse will use you personal Maven ~/.m2/settings.xml file, which in my case is now configured to use Nexus, so I automagically get access to all those custom repositories I already configured in Nexus without having to painfully add into Eclipse. This is nice as I can now lookup archetypes in non-Central based repos, and do the "so what dependency do I need to add for this Class" search as well on non Maven Central hosted dependencies.

Overall a positive experience. Nice work Sonatype!

Eclipse Galileo, 64-bit Java, Java 5, and Snow Leopard...

I thought I'd provide some details on the adventures I had in getting Eclipse Galileo (3.5) working on my Mac running Snow Leopard.

As detailed in this great DZone article by Zviki Cohen, Snow Leopard only ships with a 64-bit version of Java 6. In fact, if you upgrade from Leopard to Snow Leopard, the installer will actually uninstall Java 5 and replace it with symbolic links to Java 6.

This proved to by a challenge for my Eclipse needs as 1) you need to make a decision about which flavor (32 bit or 64 bit; Carbon or Cocoa) of Eclipse to install on the Mac, and 2) Eclipse gets confused by the symbolic link to Java 5 and thinks you really do have a real Java 5 JDK installed.

After reading the Dzone article, I decided to go with the 64-bit Cocoa version as that seems in line with where Java and Mac OS are going. Also, as I was going through my installation Eclipse Galileo SR 1 (3.5 SR 1) shipped which provided 64-bit Cocoa versions for all Eclipse profiles (JEE, Java, etc.). The SR 1 release eliminated many of the hoops Zviki talks about in this article, making it a much easier path to choose. After using this version of Eclipse for about a week, I'd say I don't notice a big difference from the 32-bit version, but it certainly seems stable and having it do builds with really big projects (ServiceMix) it seems relatively fast. I do notice my Laptop fan turning on and both cores maxed out, which overall I assume is a good thing as that means that its taking full advantage of my computer during a large complex build...

The next big task was fixing the Java 5 issue. This was an especial challenge / need for me since 1) most FUSE projects still support Java 5 and 2) m2eclipse (Apache Maven support in Eclipse) gets confused importing Maven projects that use Java 5 with Eclipse thinking its got a JDK 5 installed but really its Java 6 (see above note about Snow Leopard linking JDK 5 dir to JDK 6). This post at OneSwarm details how to hack a real JDK 5 onto your Snow Leopard OS. The highlight being

In the terminal:
Get the java 5 that was included in 10.5 "leopard" and unpack
cd /tmp/
tar -xvzf java.1.5.0-leopard.tar.gz
Move it to your System java folder (password needed)
sudo mv 1.5.0 /System/Library/Frameworks/JavaVM.framework/Versions/1.5.0-leopard

Tell OS X that java 5 actually is java 5
cd /System/Library/Frameworks/JavaVM.framework/Versions/
sudo rm 1.5.0
sudo ln -s 1.5.0-leopard 1.5.0

I also updated the /System/Library/Frameworks/JavaVM.framework/Versions/1.5 link to point to the 1.5.0 link for completeness.

After doing this I updated Eclipse to use the real JDK 5, and m2eclipse with my ServiceMix project built much better. Now I can do both Java 5 and 6 development on 64-bit Cocoa version of Eclipse - all nice and shiny new :-)

Now onto some real coding... :-)