jetty-maven-plugin depends on jetty-runner which causes problems with IBM JDK

Seems impossible to download the IBM JVM for standard x86 systems.
Using this as starting point - http://www.ibm.com/developerworks/java/jdk/linux/download.html
Then when I try to access the JVM's it requires an IBM ID Login, which itself is seemingly impossible to register/create/signup for online.

Is there another way to obtain the IBM JVM's?

I'm afraid not - you have to get your IBM ID. That's IBM
There are two (at least) registration options. The other is "partner ID", which will allow you to download all IBM Software - e.g. "IBM WebSphere Application Server 7 Network Deployment Supplements CD 1 of 2" which contains what my problem was - "WebSphere Application Client".

Because there is more politics than technology in the process of getting your own copy of "WebSphere Application Client" (hereinafter referred to as WAC ), here's my deep technological analysis:

• my POM contains jetty-maven-plugin:run-war execution during pre-integration-test phase
• Maven is being run with JAVA_HOME set to WAC's JDK (almost standard JDK)
• MAVEN_OPTS configure java.ext.dirs which extend system class loader with about 400 MB of JARs from WAC - e.g. prehistoric AspectJ, Axis2 in SNAPSHOT version, servlet-api 2.5 and WebSphere specific classes.
• among these classes are all JavaEE APIs (I had to replace servlet-api and jsp-api with the ones provided by Jetty). The critical are javax.transaction.*
• WAR is standard WAR which starts Spring Context
• The critical point during Spring Context's refresh is obtaining "jta/usertransaction" from JNDI using InitialContext configured with WAC specific properties (imagine that - it's not that easy, because WAR's being started in Jetty with "plus" config, which contains it's own JNDI)
• the object obtained from remote JNDI is WAC's implementation of javax.transation.UserTransaction.
• Here the problems begin:
  • object acquired from JNDI's implements javax.transation.UserTransaction loaded by system (java.ext.dirs) class loader
  • Spring has detected org.springframework.transaction.jta.JtaTransactionManager's constructor which takes javax.transation.UserTransaction but loaded by Jetty's classloader from ... jetty-runner jar
  • type mismatch occurs
  • WAR fails to start

(to make things more complicated, please note, that my WAR not only needs WebSphere's transaction manager from remote JNDI, it also needs Jetty's global datasource using differently parameterized InitialContext).

So - I've traced down the problem - http://search.maven.org/remotecontent?filepath=org/mortbay/jetty/jetty-runner/8.0.0.v20110901/jetty-runner-8.0.0.v20110901.pom uses maven-dependency-plugin:unpack-dependencies to pack all dependencies into the JAR.

If only the dependencies were not contained in the JAR and the runner relied on the dependent JAR being present on classpath by means of standard Maven dependency resolution, everything would work - I could just include dependency to jetty-runner in my jetty-maven-plugin with the exclusion of javax.transaction:jta. Now I had to manually remove these classes from jetty-runner JAR in my local Maven repository.

I hope I've explained my problem quite well

So - using IBM's JDK is a tiny part of the problem - you would also need: remote WAS, local WAC, remote usertransaction and remote EJBs

regards
Grzegorz Grzybek

There are a couple things we need to fix here:

1. the jetty maven plugin should not depend on jetty-runner jar AND other jars directly as the classes are all duplicated
2. to fix 1., we should not depend on only the jetty-runner jar because it includes all the classes directly inside it, so people cannot then use the plugin <dependency> mechanism to affect the plugin's classpath

We should be able to write a simple new main class for the forked plugin to use that starts jetty up instead.

A new implementation of the JettyRunForkedMojo has been checked in to jetty @ codehaus head.

Please see the comments on issue JETTY-991 for feedback that we would like to obtain on running jetty in a forked manner.

thanks
Jan

Thanks for quick response!
Commit 364fd9b229f24b47167776def4e3727175b21ff8 is all I needed
I'll look at JETTY-991 now.
regards
Grzegorz Grzybek