Building modules based on JDK version

[anil.saldhana]

As it stands out today, the HEAD build has the following projects(ejb3, ejb3x, webservice) that depend on JDK 5.

The way the projects ejb3 and ejb3x bypass when compiled with JDK 4 is

<condition property="buildejb3" value="ejb3x,ejb3,">
 <isset property="HAVE_JDK_1.5"/>
 </condition>

 <condition property="buildejb3" value=" ">
 <not>
 <isset property="HAVE_JDK_1.5"/>
 </not>
 </condition>

 <echo message="build ejb3: ${buildejb3}"/>

 <condition property="buildws" value="true">
 <isset property="HAVE_JDK_1.5"/>
 </condition>

<group name="standard">
 <include modules="security,
 jbossas/remoting,
 jmx-remoting,
 jbossas/jmx-remoting,
 ...
 hibernate-int,
 jms,
 ${buildejb3}
 webservice
 "/>
 </group>

The webservices bypasses building the module on JDK4 by:

<condition property="buildws" value="true">
 <isset property="HAVE_JDK_1.5"/>
 </condition>
.....
<target name="_module-webservice-most" if="buildws">
 <ant antfile="build-distr.xml" target="_module-webservice-most"/>
 </target>

Can we just have one property setting based on availability of JDK5 and the modules that need to bypass building on JDK4, can use the "if" attribute on the target?

[ruel.loehr]

Currently webservice is still being compiled even if 1.4 jdk is used. I'm assuming you wish to change that so that it will only be compiled with a 1.5 compiler. Is that correct?

Setting the properties up in that fashion should be doable.

I've opened a jira issue:

http://jira.jboss.com/jira/browse/JBBUILD-240

[anil.saldhana]

I doubt the webservices module is being compiled with jdk4.

My objective behind this thread is that there should be a standardized mechanism in the build script for modules to take advantage of jdk version based build.

Today, when jboss is built with jdk4, there should be no jbossws.sar deployed into the deploy directory.

[jason.greene]

The old axis based stack is being compiled in head for 1.4 compatibility. Whenever we require 1.5 in head we will drop the old stack.

-Jason

[starksm64]

What Anil is looking for is just a more consistent way to setup a module such that jdk5 source and artifacts are not produced when compiled with non-jdk5.

This most likely further complicates the maven2 experiment, and also brings up the outstanding retroweave like functionality:

http://jira.jboss.com/jira/browse/JBBUILD-188
http://jira.jboss.com/jira/browse/JBWS-511

Even if we get to a retroweave type of capability, there still may be jdk5+ features that are used that cannot be retroweaved. Since retroweaving is really an artifact post processing step, this also brings up this "Jar canonicalization and dependency isolation" issue:

http://jira.jboss.com/jira/browse/JBBUILD-158

I have not caught up with the current maven2 investigation, but how does this post processing of artifacts fit?

[ruel.loehr]

The JDK 1.4 vs JDK 1.5 compilation/deployment is one which we have been on a lookout for during the evaluations. The next iteration of the Maven evaluation already has this defined as a task. Maven has the notion of activities based off of jdk version already built in, so I am not anticipating any severe issues here.

As it stands now, the current use case needs to be as follows.

1) ability to compile modules only if jdk 1.5 is used (ejb3, ejb3x, webservice?)
2) ability to compile a default source set in addition to a source set to be compiled if 1.5 jdk is used (aop)
3) ability to create and deploy artifacts based upon jdk version (aop, aspects, webservice)

Regarding post-processing of classes, one the nice features Maven has is a knowledge of the build life-cycle. A phase is built into the lifecycle for post processing:

process-classes - post-process the generated files from compilation, for example to do bytecode enhancement on Java classes.

It would just be a matter of wrapping a plugin around the retroweaver, or a plugin around the jarjar util and defining when you wish for them to be executed.