sebb wrote:
> On 27 June 2013 22:23, Thomas Neidhart <thomas.neidh...@gmail.com> wrote:
>> On 06/27/2013 10:41 PM, sebb wrote:
[snip]
>> I could suppress the generation of the Build-Jdk from the bundle-plugin
>> with this override:
>>
>> <plugin>
>> <groupId>org.apache.felix</groupId>
>> <artifactId>maven-bundle-plugin</artifactId>
>> <configuration>
>> <instructions>
>> <_removeheaders>Build-Jdk</_removeheaders>
>> </instructions>
>> </configuration>
>> </plugin>
>>
>> Just to realize afterwards that the maven-jar-plugin also creates it and
>> it is of course also executed with in the same jvm as maven.
>>
>> Well, two solutions that come to my mind:
>>
>> * use a hard-coded entry -> ugly
>> * retrieve the version of the used compiler ${commons.compiler.javac}
>> by exeuting it with the -version argument, and override with this
>> variable the Build-Jdk
>>
>> Otoh, why do we have to use Java 1.5 for compilation / tests anyway? The
>> source / target are set to 1.5 and the generated byte-code should be
>> compatible or am I missing something?
>
> The source/target options don't affect the libraries on the classpath.
> So the code would compile wih Java 1.7 but fail to run on Java 1.6 if
> the source accidentally uses a method only available in 1.7.
The animal-sniffer plugin can ensure, that this did not happen.
http://mojo.codehaus.org/animal-sniffer-maven-plugin/
> And if the code uses JDBC, it will probably only compile and test
> using the correct version of Java, as JDBC is not upwards compatible
> between versions.
Since the animal sniffer can only verify the result, JDBC stays a problem.
> Ideally the manifest(s) should show the actual compiler version used
> as well as the source/target settings.
Definitely. Did you ever looked at the toolchain stuff? That was always
proposed as solution for such kind of problems. Unfortunately I fear that it
is not supported by the bundle plugin either.
- Jörg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
