Maven 2’s EAR plugin gives me a headache

While maven 2 is all cool and such. It can indead use some more documentation.

Try building this with Maven 2:

  • EJB’s should be passed through IBM WebSphere’s 5.1 EJB Deploy.
  • Most application dependencies should be packaged into the resulting EAR file, and NOT into the war file.
  • Jar files packaged at the EAR level should be mentioned in the relevant manifest class-path entries of several WAR files.
  • There is a preference to give a packaged EJB jar in the EAR a specific name.
  • It should all be done in one single build. Execute one pom to the requested build phase and it should be done.

Well let’s get started… I won’t be pasting entire POMs, but do expect some links and snippets.

EJB’s should be passed through IBM WebSphere’s 5.1 EJB Deploy.

I can’t find any Maven 2 plugin capable of running EJB Deploy on EJB’s. Oh well, I’ll just role my own and use a MOJO to execute through the System class of Java. No problem with that. Next I should make sure that the specific file is published to the repsoitory. No problem with that, just enter this line at the end of your MOJO’s execute method:
projectHelper.attachArtifact( project, "ejb-ibm", "ibm", ibmJarFile );
(Note that the ibmJarFile is a Java File initialized with the IBM EJBDeploy output jar placed in the target directory of the ejb project. So EJBDeploy gets executed and outputs the Jar with IBM stub code in the target directory of the EJB project. The name of the Jar file isn’t really important, but you should follow Maven’s file naming conventions and use something like MyEjb-ibm.jar.)

Ok, so now EJB Deploy creates a nice EJB Jar file with all kinds of IBM stub code in it. Sweet! And that little line I showed, have a peak at the Maven EJB Mojo for inspiration, it also shows how you can get a projectHelper. Cool, lets execute this.

Building seems to be ok, but when I want other files to depend on my IBM version of the EJB something is wrong. It can not be found. I did specify a type in my dependency declarion in the depending POM.


See, how I declared ejb-ibm? Sort of the same way you can depend on a ejb-client jar. The error I get from Maven is rather misleading, something about not being able to find the artifact in the remote repository. Let’s open up the local repository after running an install on the EJB project. Strangely there is a file there named: MyEjb-0.0.1.ejb-ibm So Maven is rather creative with the naming. Must be some default behaviour. Well to cut this short I needed to define a custom Artifact type within my plugin. I found this little gem at only one single bit of documentation: Introduction to the Build Lifecycle Look for a paragrapg titled: Creating a Custom Artifact Handler

It involves defining a plexus addition with some kind of components.xml file. See the linked doc for more info. I put this custom artifact declaration into my EJB Deploy MOJO. Don’t forget to declare extensions: true when binding the your plugin to the life cycle.

Let’s try again. Everything works now, EXCEPT the maven-ear-plugin. Atleast, ehm the dependences get resolved and they are included with the ibm classifier in the manifest’s class-paths and EAR/WARs. (file names looking like MyEjb-0.0.1-ibm.jar) Close, but not good enough, I want control over my EJB jar file naming. AND I have to get the maven-ear-plugin to eat my configuration. Because right now it’s just crashing with a nasty error declaring that the ejb-ibm type is not a recognized type.

So I’m still not there yet. Now I only need to convince the EAR plugin, since to my knowledge it is the last problem I need to tackle. So let’s look up the maven-ear-plugin documentation, which states something about customizing modules. The good news, there is some statement about a classifier which I can configure. So I hope that this will allow me to select my ejb-ibm artifact type, since all the other documentation states that the ibm part of my custom artifact is called a classifier (MyEjb-0.0.1-ibm.jar). I do know module configurations give me exact control over the resulting ejb jar file names. More on this on monday. Tried it and it works.

Most application dependencies should be packaged into the resulting EAR file, and NOT into the war file.
You should declare the relevant dependencies as dependencies of your relevant EAR projects. Then all you need to do is make sure the jar file is mentioned in the WAR using the JAR and make sure the JAR isn’t packaged in the WAR file.

Jar files packaged at the EAR level should be mentioned in the relevant manifest class-path entries of several WAR files.
This combines with the above explanation. You let the EAR project depend on the artifact. Next you let the WAR file depend on the same artifact. And you declare that the maven-war-plugin should addClasspath as described here.
First guess would be to give the dependency a provided scope right? WRONG! Provided should be used for platform dependencies like J2EE jar. This one is a stupid trick. Instead of using a provided scope, drop the scope declaration and declare the dependency as optional. Now in my book an optional dependency is kind of misleading, but hey it works. I get my manifest class-path declaration and it’s not included in the war itself.

There is a preference to give a packaged EJB jar in the EAR a specific name.
See my longer explanation above. Something with using Module configurations within the maven-ear-plugin.

As you can tell, this post is sort of a brain dump to get this info out there. I am not aware of any proper documentation on the problems I encountered. So it might be a bit terse to read. If you have any questions or would like to know some more details. Post a comment, I’ll do my best to elaborate.

Going to EclipseCon 2007

I am very happy to anounce that I will be attending EclipseCon 2007. It will be my first overseas conference ever. And the first intercontinental flight I will make. So major noob factor there. But all in all “Wow!”.

Within my employer I have been active for a thing called the “Rich Client Niche”. It is sort of an extra hours activity where we try to set company wide guidelines/standards and help RCP newbies on their way. And I am getting the feeling that it is starting to work, colleagues are aware of the niche and are actively requesting assistence and knowledge. In the past year we as the Rich Clien team have been able to get more attention to rich client Java development within our company. Especially at managerial level interest is growing into the potential opertunities in this area.

Going to EclipseCon 2007 To support our activities into this year the decision was made to send me and perhaps another colleague to the EclipseCon 2007. I am very much excited about this, I am hoping that because of this we are able to get out competence level to the next level. Also I am very curious to talk to people about potential business opertunities focussed around Eclipse RCP. Drop a line if you will be there as well. I’m especially interested to learn if any other dutch colleagues at other companies will attend.

Hereby I declare, TextMate owns any previous editors I’ve used

TextMate Icon At my current project I started using TextMate for real. Because I’m editing file all over the place now instead of just java code. Anyway I could say I really love feature x or y. But no, I’m actually complaining a bit. What I would like to have is a Maven 2 Bundle for TextMate. Validated editing of pom.xml files would be great and running Maven 2 projects from textmate would really improve my workflow. I guess I’ll have to look into rolling my own Maven 2 bundle. A task which still seems a bit daunting. Because of all the XML validating and all. But then again, how hard can it be? Lots of Bundles to look into for examples anyway.

For all you potential Vista users, TextMate is Mac only. So forget Vista and get a Mac. 😉

Why I want maven 2? I’m doing a lot of Maven 2 edting for my curren t client right now. We are running a pilot on a project right now and when that succeeds and the business side of the equasion agrees: Loads of Maven 2 configurations to write. Not a few, not a dozen. But all together nearly one hundred poms to write. So editor support is actually almost a must.