Compiling for API compliance

[Martin von Gagern <Ma...@gmx.net>]

Hi!


I would like to compile code not only for a given class file format 
version, but also to the corresponding Java API specification. So I 
guess I'd need to set the bootclasspath of the compiler, which requires 
me to have a forking compiler.

I would like each project to specify its version requirements in a 
simple way, preferrably in a pair of properties, e.g. main.java.version 
and test.java.version. There should be a separate version
for the test code, as it can be useful to have a library conform to some 
early version, in order to increase its reusability, while on the other 
hand making use of recent additions, like varargs (source version), 
annotations for junit (source and target version) or printf (api 
version) in the test code. The test version should default to the main 
version, but this is a minor requirement.

The bootclasspath of different java versions is installed in a system 
dependent path, so it should probably be specified in the user settings. 
If no bootclasspath is specified for the version requested, a warning 
would be nice, as the desired API compatibility cannot be guaranteed.


I tried to achive these goals with current maven tools, but failed 
miserably.

I tried to specify a property called bootclasspath.1.4 in my settings, 
and have a profile in the pom configure the compiler plugin accordingly 
if this property is set. No luck there, I guess the profiles in settings 
are only evaluated after the ones in the pom.

I tried to create different configurations for different executions, but 
  it seems impossible to modify an execution that is configured for the 
given packaging method by default.

I tried to move my test code to an independent model, and tried to clear 
the compiler arguments there, but that seems impossible as well.


Now I tend to write my own compiler plugin, derived from 
maven-compiler-plugin, but allowing for configuration using 
${main.java.version} and ${test.java.version}, and some intelligent 
configuration element for giving the bootclasspaths for different API 
versions, which can be specified in settings.

I guess I'd also need to provide my own packaging type, to bind my own 
compiler instead of maven-compiler-plugin to the appropriate lifecycle 
phases. I might even combine this with an extended lifecycle, as the 
packaging phase feels rather crowded for me, with jar packaging, 
signing, assembly, etc.


Before I embark on this venture, I'd like to hear your opinions. Maybe 
there is a tricky way to do this with what maven has. Maybe someone 
already wrote a plugin to do pretty much what I suggest here. Or maybe 
you like the idea, and have additional suggestions, or even want to help 
code. Would you want this to be hosted in some sandbox?


Greetings,
  Martin von Gagern

RE: Compiling for API compliance

["Brian E. Fox" <br...@reply.infinity.nu>]

Because of the way maven uses an unnamed execution for command line and
lifecycle bound plugins, you can't specify multiple fields for compile
to use during the different executions.

You'll want to watch MNG-3203 and MCOMPILER-15

-----Original Message-----
From: Martin von Gagern [mailto:Martin.vGagern@gmx.net] 
Sent: Monday, April 07, 2008 6:31 AM
To: Maven Users
Subject: Compiling for API compliance

Hi!


I would like to compile code not only for a given class file format
version, but also to the corresponding Java API specification. So I
guess I'd need to set the bootclasspath of the compiler, which requires
me to have a forking compiler.

I would like each project to specify its version requirements in a
simple way, preferrably in a pair of properties, e.g. main.java.version
and test.java.version. There should be a separate version for the test
code, as it can be useful to have a library conform to some early
version, in order to increase its reusability, while on the other hand
making use of recent additions, like varargs (source version),
annotations for junit (source and target version) or printf (api
version) in the test code. The test version should default to the main
version, but this is a minor requirement.

The bootclasspath of different java versions is installed in a system
dependent path, so it should probably be specified in the user settings.

If no bootclasspath is specified for the version requested, a warning
would be nice, as the desired API compatibility cannot be guaranteed.


I tried to achive these goals with current maven tools, but failed
miserably.

I tried to specify a property called bootclasspath.1.4 in my settings,
and have a profile in the pom configure the compiler plugin accordingly
if this property is set. No luck there, I guess the profiles in settings
are only evaluated after the ones in the pom.

I tried to create different configurations for different executions, but
  it seems impossible to modify an execution that is configured for the
given packaging method by default.

I tried to move my test code to an independent model, and tried to clear
the compiler arguments there, but that seems impossible as well.


Now I tend to write my own compiler plugin, derived from 
maven-compiler-plugin, but allowing for configuration using 
${main.java.version} and ${test.java.version}, and some intelligent 
configuration element for giving the bootclasspaths for different API 
versions, which can be specified in settings.

I guess I'd also need to provide my own packaging type, to bind my own 
compiler instead of maven-compiler-plugin to the appropriate lifecycle 
phases. I might even combine this with an extended lifecycle, as the 
packaging phase feels rather crowded for me, with jar packaging, 
signing, assembly, etc.


Before I embark on this venture, I'd like to hear your opinions. Maybe 
there is a tricky way to do this with what maven has. Maybe someone 
already wrote a plugin to do pretty much what I suggest here. Or maybe 
you like the idea, and have additional suggestions, or even want to help

code. Would you want this to be hosted in some sandbox?


Greetings,
  Martin von Gagern


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org