While the Geronimo update is a mixed bag, I’m pleased to say that updating to Google Web Toolkit (GWT) version 2.0 went a lot better.
In particular, the gwt-maven-plugin is a lot better than the last time I looked. Previously, I was unable to get it to work with my builds as its interface was completely different and it just plain didn’t work. They’ve since reconciled the interface and it works well with GWT 2.0.
I love it when a plan comes together!
So, I tried building on 2 different machines using Geronimo V2.2.
The 32 bit machine built fine after I corrected some minor permission problems. The 64 bit machine tells a different story.
I’m having issues finding the EJB using JNDI. Basically, it’s unable to connect. The only references I can find to the error refer to Geronimo V1.0 and are 5 years old. I find it hard to believe that the product could have regressed that much, so it’s probably something in my configuration, but why would it build on one machine and not another?
Stay tuned!
I’ve been awfully boring lately from a blogging point of view. With Christmas and a whole bunch of other things on the go, I haven’t been putting as much time into development as I would have liked. Well, I’m now back at it.
First step is to install and test Geronimo V2.2 released in December. This is in progress and I should have more to say about it over the next couple of days. It will have to be installed on my local machine first, then on the continuum and test servers before deploying. Lets see what surprises it has in store!
Just got this email from the MyARM folks who developed the SDK in conjunction with HP:
“Just to inform anyone who is interested ARM that HP and tang-IT changed
the license agreement of the ARM4SDK to a MIT open source license. It is
now published on the open group site at:
http://www.opengroup.org/management/arm/page.tpl?ggid=704
MyARM has setup a subversion repository and Trac frontend for
further development on the open source ARM4SDK. Anyone is welcome to
join the project. Just drop me a note.
http://www.arm4sdk.org/”
This is important since the previous license prevented redistribution of the SDK with Fedora and other Linux distributions. I guess now I have no excuse not to create another package…
Wow. What a lot of wasted time.
These are known bugs as you’ll see if you search it, but finding proper workarounds has cost a lot of time.
The first issue I got was in using replaceregexp in an ant script called from maven. I’d added all the proper jars to the dependency lists, and specified the ant.regexp.regexpimpl property to use the org.apache.tools.ant.util.regexp.JakartaOroRegexp implementation, but ant was unable to find it. If I defined a new task for replaceregexp with the proper classpath, then the definition would work fine, but it was unable to find the JakartaOroRegexp class when it executed.
To solve this, I used the Java task to call ant instead of the ant task.
<tasks>
<property name=”compile_classpath” refid=”maven.compile.classpath”/><!– This doesn’t set the paths correctly, so we need to use java to call ant –>
<!– ant antfile=”build_translation.xml” inheritAll=”true” inheritRefs=”true” / –><java
classname=”org.apache.tools.ant.launch.Launcher”
fork=”true”
failonerror=”true”
>
<classpath path=”${compile_classpath}”/><!– arg value=”-debug”/ –>
<arg value=”-buildfile”/>
<arg file=”build.xml”/>
<arg value=”-Dcompile_classpath=${compile_classpath}” />
<arg value=”-Djdk.set=true”/>
</java>
</tasks>
This worked well, but my ant script used native2ascii and I kept getting the message Error starting Sun's native2ascii. No matter how hard I tried to fix this in the script by modifying class paths, JAVA_HOME definitions and otherwise, the only way I could fix this was by creating a symbolic link from JRE_HOME/lib/ext to JDK_HOME/lib/tools.jar. This means I have to do this on every build machine, and I really shouldn’t have to. Of course, the bug shouldn’t exist in the first place, so I guess that’s life.
At least now I can move on to solving the problem I was originally trying to solve instead of wasting time getting the builds to work.
Well, it wasn’t all that clear to me after several reads of the documentation, but I worked around my Maven build issues using a fourth option. I have a pre-configured Geronimo server with all the pools created sitting idle and load it in using the tag instead of an assemblies tag. This means I have to pre-configure all my build servers and test machines, but at least it works.
I hope the Geronimo folks address this in an upcoming release. Of course, I would also hope that I could build pre-configured custom assemblies.
I’ve been working on this problem for some time with varying degrees of success. My goal is to have continuous integration working for all the modules of the system, and Maven is well suited to this. For some of my modules, things work well. For example, for independent modules not using a database or other system facility. I’ve even got web services that use JNI building with success.
The problem child is the EJB module that uses the database. It depends on a database configuration that’s very easy to create using the console. This doesn’t work well for continuous integration, especially as modules are loaded and unloaded for testing. The standard Maven approach is to install an assembly, load the pieces you need to test, and unload when done. The standard assembly doesn’t include the database pool so that has to be set up separately. Maven doesn’t support this.
Option 1: Create a custom assembly.
For Geronimo 2.1.3, which I’ve been using, this fails. Period. It can’t be done. In order to include the modules I need, I consistently get in “IOException: HEAD full” error. 2.1.4 doesn’t give this error and builds an assembly, but it fails to start with a ClassNotFound error.
Option 2: Create and install plugins
This can be done, but Maven refuses to load them because the manifest is incomplete. I haven’t investigated this option fully, primarily because it annoys me that a plugin creator would create an unusable plugin.
Option 3: Create the pool in the deployment plan
When loading from Maven, it just says “Sorry, try again.” with no indication as to what the error is. I’m paraphrasing, but if you’ve done much work with maven you know what I’m talking about. Loading it using the deployer.jar fails because the MySQL .jar is missing. And there’s no way to load it. Well, I could load it into a custom assembly, but we’ve already covered that.
Summary:
I’m stumped. I’ve tried the recommended approaches and all the work arounds I can think of. Time for a nap.
Well, it’s been a busy couple of weeks. I’m now in a new office and getting serious about getting our site in the hands of beta testers.
One aside I had to deal with was a bug in my Fedora package for ARM caused by a code reorganization in system libraries, but that was a simple fix and is now done.
The biggest accomplishment was moving my MySQL service to a clustered back end. This should give me significant scalability and reliability in the future. Since they’re all running on the same system in virtual machines means I get no such benefit now, but as machines are added this will improve. At this point it’s overkill, but I still want this configuration tested.
I’ve also set up a number of specialized servers, also in virtual machines. These host our subversion code management service, the maven artifact service, continuum build server, bugzilla, wiki, and others. How did people work before virtual machines? While these are overkill in terms of our performance needs, at least at this point, it sure makes the systems management simpler.
Of course, the downside is that a power bump is far more serious. Time to buy a UPS.
Ah the joys of being a Fedora contributor!
The first hint of trouble are the failed to build from source error messages. Apparently, the development versions just stopped building. Upon investigation, it appeared I had an incorrect dependency. Since I was using uuid libraries, I had a dependency on uuid-devel. Well, it turns out that that was for a different set of uuid functions. The ones I wanted were in e2fsprogs-devel… the package for file system maintenance ?!? Well, apparently I’m not the only one who found that odd, and they split that package into ones that made more sense. Hence the breakage.
Net result: Existing packages work, although I’ll update their dependencies to the correct ones. New packages (For Fedora 12, so you don’t have to worry about it yet) will be updated.
This is the online publication of the Computer Measurement Group. Well worth the read.
