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:[EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
