Compiling for API compliance

[Martin von Gagern]

Hi!

I would like to compile code not only for a given class file format




http://www.nabble.com/Compiling-for-API-compliance-td16538018s177.html







There are also some open questions, which I will list below.

== 1. POM Configuration ==



<source>
  expression="${maven.compiler.source}"
  default="${main.java.version}"
<target>
  expression="${maven.compiler.target}"
  default="${main.java.version}"
<api>
  expression="${main.java.version}"
<testSource>
  expression="${maven.compiler.source}"
  default="${test.java.version}"
<testTarget>
  expression="${maven.compiler.target}"
  default="${test.java.version}"
<testApi>
  expression="${test.java.version}"





http://jira.codehaus.org/browse/MCOMPILER-15

== 2. Toolchain ==





http://jira.codehaus.org/browse/MNG-468
http://docs.codehaus.org/display/MAVEN/Toolchains
http://docs.codehaus.org/display/MAVEN/Toolchains?showComments=true&focusedCommentId=77693099#comment-77693099

== 3. Compiler arguments ==


Does someone know about corresponding settings for other compilers?

== 4. Default behaviour ==






Greetings,
 Martin von Gagern

version, but also to the corresponding Java API specification. There should be different settings for main and test code, as the main code should be highly portable, while test code might make use of quick and dirty features that only became available more recently. I had already started a mail with this subject in users@, heard that what I want to do isn't possible so far, and now I want to change things so it becomes possible. I'd like for my projects to simply set two variables, like main.java.version and test.java.version, which should affect the source and target version of the compiler, as well as either the jdk version selected, or the bootclasspath for the compiler be set accordingly. The latter would have the benefit that it would still use the newer compiler, thus allowing access to newer compiler flags, e.g. for lint, while still ensuring API compatibility to an older version. Originally I intended to write my own plugin, derived from maven-compiler-plugin, to implement this. However, I found out that the compiler plugin provides no access to its private fields, and hacking at them with reflection feels very nasty, so I'll not do that. Instead of maintaining my private branch of the java compiler, maybe this thing is interesting enough for people out there to warrant implementation in the main compiler plugin. Would you agree? My first primary concern is how to proceed with this. I could write a feature request for the compiler plugin in JIRA, start a wiki page on docs.codehaus, or continue discussion here. Or I could do several of these things at the same time. How to configure this in the POM? I guess backwards compatibility should be preserved. The current compiler allows for <source> and <target>. I could think of these settings: This way, all current settings should continue to work, unless someone used one of the newly introduced properties for some different purpose. More complex mixing of property variables could be done in a parent plugin configuration, with the corresponding properties set in submodules as required. Do you agree that this set of configuration parameters would indeed make sense? The modified plugin would need information about what compilers are available, and where the corresponding executables can be located. This information is system-specific, not project-specific, so it should reside in a maven config file. This sounds a lot like the toolchains proposal, so maybe there is some way to leverage that. I only know about javac, so I'm not sure whether this way to set the bootclasspath would work for other compilers as well. It would be nice to have this handled in a consistent way in the plexus compiler manager component, but I guess that would mean changing quite a lot of code. Should this be targeted to javac only for the time being? What should be done when the requirements cannot be met? I guess a warning would be a good solution. YOu might even want to get a hard error for release builds. Should there be a parameter to modify this behaviour? Let me know what you think of all this, how you would suggest I proceed, and what other resources might be useful. I don't have too much time to spare for this issue, but I believe it important enough to do some work for it from time to time, and when I do so, I might as well do so in a way that others can profit from it as well.

signature.asc
Description: OpenPGP digital signature