JDK 1.4 Compatibility for Microcontainer and other Projects

[pgier]

I'm working on setting up jdk1.4 unit tests for microcontainer, and I've run into some issues that would be good to discuss. The first idea that I had was to use a classifier to generate jdk1.4 compatible artifacts and store them in the repository. So the jboss test project (a dependency of microcontainer tests) would generate an artifact with a -jdk14 classifier and look something like jboss-test-jdk14.jar and live next to the jdk5 artifact in the repository. Then projects that want to use the jdk14 version of jboss-test would specify the dependency with the "jdk14" classifier.

There are a couple of problems with this model:
One is that artifacts with classifiers do not get the same dependency management as the main project artifact. So there is no concept of transitive dependencies for these artifacts.
Another issue is that there are a lot of released artifacts that do not currently have jdk14 compatible versions. So there is no compatible artifact that can be used by the jdk14 microcontainer tests.

So what I'm thinking about now is having a separate repository for jdk14 compatible jars. Basically it would sit next to the maven2 repository on repository.jboss.org and snapshots.jboss.org. So we'd have something like http://snapshots.jboss.org/maven2-jdk14.
Projects could be built and deployed to this repository using a jdk14 profile that will retro-translate the classes, jar them up, and deploy to the jdk14 repository. Then when we want to run the microcontainer jdk14 tests, we just depend on this repository instead of the default one.

One issue with this is the problem of where do we get jdk14 versions of our existing jar dependencies if the project has already been released without those jars? For this, I'm working on a feature of the maven-jboss-retro-plugin that will pull a specified project version from the repo, retro translate it, and deploy it to the jdk14 repo.

Anyway, I'm looking for any feedback about whether this plan sounds reasonable, or is there a better/easier way to do all this?

[ryan.campbell]

Not sure I completely understand the maven issues, but we have handled this in the past with just using the "classifier" at the module level instead of the artifact level.

So we had jbossws and jbossws14. Perhaps it would have been better to call it -jdk14.

So my question is, is it possible to solve this some place *between* the repository and artifact levels, like in the group name? Or is my maven ignorance starting to show?

[pgier]

In maven terms the equivalent to doing this at the module level, I think would be having different artifactIds. So you could have jbossws and jbossws-jdk14 as separate artifactIds. Or at the groupId level, you would have something like org.jboss.jboss-test and org.jboss-jdk14.jboss-test.

A couple of issues I see with this in terms of how maven does things:

You would have two separate sets of dependencies because maven would treat these as completely separate projects. But it probably wouldn't be that difficult to do.

Another problem would be deploying the separate artifacts. Maven profiles do not allow you to change the groupId or artifactId. So I think you would need to have a separate pom.xml, so you would have some duplication of work there.

Having a separate pom.xml could be used in addition to having a separate repository. It basically would replace the use of a profile to determine deployment location and whether to run the retro-translation.

[pgier]

After messing with this stuff for a while. I decided to use a single repository and just have different artifactIds for jdk14 artifacts (similar to what Ryan suggested). I was hoping that having two separate repositories would make things simpler because I would be able to translate dependency jars from a jdk15 repository and put them into the jdk14 repository. And that way a project could be easily built.

But I ran into problems trying to keep the jdk5 and jdk14 artifacts sorted out, especially in the local repository. Because if the jdk14 artifacts have the same name, they overwrite the jdk5 artifacts, and the local repo gets messed up. Also the maven ant tasks used to run the retro tests were having problems using the jdk14 repository.

So the current plan is to use profiles to have two different artifactIds. A maven profile doesn't allow me to modify the artifactId directly, but I can use a property in the profile to change the artifactId. The good thing is that this will allow projects to use transitive dependencies, but still be in a single repository. The bad part is that I will have to go back to some of the released versions of dependency projects and create retro versions of these projects, so that part will take some effort.

[pgier]

I ran into some problems when trying to do this using profiles. Using a property value in the artifact Id can cause problems when resolving transitive dependencies. So I am using separate poms for the jdk14 builds. I didn't do this earlier because maven doesn't support using alternate poms in modules. This means that multi-module builds will have to be done one module at a time for the time being. I opened a maven issue http://jira.codehaus.org/browse/MNG-3150 to resolve this and will work on it when I have time.

I have created working retro builds with retro tests for the common projects and jboss-test since they are dependencies of microcontainer. So now I'm gradually working my way through the microcontainer modules and their dependencies to get retro builds with working tests.