Thanks Nathan. This is exactly what I was getting at (and the reasons
for it), but this is a lot more detail than what I wrote down.
So, just to make sure I understand, it would work something like this:
- JDK definitions are built in, and specify the location of executables,
a particular type of bootclasspath, and anything else that might need to
be referenced.
- a number of JDKs are preconfigured to "implement" those definitions
- the mechanism is extensible so that new JDKs with different layouts
can be added (we can do this in the same way new wagons are added using
Plexus)
- the user would only have to do minimal configuration (a list of
available JDK paths is probably enough, and we can autodiscover these if
not setup, either using JAVA_HOME, PATH or a full path search if we
really wanted to)
This sounds great. We should probably look into reusing/aligning to what
Eclipse does here if we can, too.
The only thing to keep in mind is that while I think this is primarily
for Java target environments now, I think the same technique can be used
for other target environments (.NET/Mono, native stuff, etc).
Cheers,
Brett
On 17/07/2006 4:18 AM, Nathan Beyer wrote:
-----Original Message-----
From: Brett Porter [mailto:[EMAIL PROTECTED]
<snip/>
Some things to note about targeting a different JDK:
* rt.jar is not enough - JDKs provide a number of other classes in extra
libraries, and it isn't called rt.jar on some platforms.
In fact, this actually varies from vendor to vendor on the same platform.
For example, the Harmony ClassLibrary is separated into about a dozen
"module" JARs for both Windows an Linux. [1] None of which is named
"rt.jar".
[1] http://people.apache.org/dist/incubator/harmony/snapshots/
* -source and -target are not enough (but still useful to target
something not installed)
I think the problem that you're trying to point out with these two points is
that the compiler settings alone are not enough to appropriately target a
platform. You can setup your compiler settings for Java 1.4 compliant class
files, but if the JDK you're using is a Java 5, then your code may
inadvertently link to Java 5-specific APIs because that's what's in
bootclasspath. A great example that always happens is when Java 1.3 code
that's using StringBuffer.append() with a StringBuffer passed to append. If
you're compiling against Java 1.3 libraries, this resolves to
StringBuffer.append(Object) [2], but if you're compiling against Java
1.4/5/6, this resolves to StringBuffer.append(StringBuffer) [3]. Then when
you run on a Java 1.3 JVM it blows up with a no method error.
Eclipse 3.2's JDT takes an interesting approach to this by using the OSGi
Execution Environment concept. There are a defined set of Execution
Environments, such as J2SE-1.4, J2SE-1.5, CDC-1.0/Foundation-1.0, etc. Then,
each configured JRE is associated with an Execution Environment that is can
support and those that are "perfect matches".
A similar concept could be used within Maven and setup in the user's
settings to point to the various JDKs on the system. A project could then
declare a target environment and Maven could use the best match and warn
users of any inexact matches. The other piece that can be borrowed from
Eclipse is the concept of plugging in JRE (JDK in Maven's case)
configurations, so you can have a plugin for Sun JDKs, IBM JDKs, BEA JDKs,
Harmony JDKs, etc. Sun, IBM and BEA currently follow the same "defacto"
layout, but Harmony doesn't, so there's a Eclipse Plug-in for enable Harmony
VMs as a JRE.
An interesting side effect of taking an approach like this is that Maven 2.1
could require a Java 5 JRE to run, but could support any execution
environment, as long as a JDK and the applicable plugins were available.
-Nathan
[2]
http://java.sun.com/j2se/1.3/docs/api/java/lang/StringBuffer.html#append(jav
a.lang.String)
[3]
http://java.sun.com/j2se/1.5.0/docs/api/java/lang/StringBuffer.html#append(j
ava.lang.StringBuffer)
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Apache Maven - http://maven.apache.org/
Better Builds with Maven - http://library.mergere.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
