On 27 June 2013 22:23, Thomas Neidhart <thomas.neidh...@gmail.com> wrote: > On 06/27/2013 10:41 PM, sebb wrote: >> On 27 June 2013 21:12, sebb <seb...@gmail.com> wrote: >>> On 27 June 2013 20:44, Thomas Neidhart <thomas.neidh...@gmail.com> wrote: >>>> On 06/27/2013 11:44 AM, sebb wrote: >>>>> On 27 June 2013 10:20, Thomas Neidhart <thomas.neidh...@gmail.com> wrote: >>>>>> On Sun, Jun 23, 2013 at 10:04 PM, Thomas Neidhart >>>>>> <thomas.neidh...@gmail.com >>>>>>> wrote: >>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> I'd like to call a vote for releasing Commons Collections 4.0-alpha1 >>>>>>> based on RC1. >>>>>>> >>>>>>> The files: >>>>>>> >>>>>>> The artifacts are deployed to Nexus: >>>>>>> >>>>>>> https://repository.apache.org/content/repositories/orgapachecommons-060/org/apache/commons/commons-collections4/4.0-alpha1/ >>>>>>> >>>>>>> Distribution files: >>>>>>> https://dist.apache.org/repos/dist/dev/commons/collections/ >>>>>>> >>>>>>> The tag: >>>>>>> >>>>>>> https://svn.apache.org/repos/asf/commons/proper/collections/tags/COLLECTIONS_4_0_ALPHA1_RC1/ >>>>>>> >>>>>>> The site: >>>>>>> http://people.apache.org/builds/commons/collections/4.0-alpha1/RC1/ >>>>>>> >>>>>>> Additional Notes: >>>>>>> >>>>>>> o the download page and api links to older releases only work on >>>>>>> the published site and will be corrected after release. >>>>>>> >>>>>>> Please take a look at the commons-collections-4.0-alpha1 artifacts and >>>>>>> vote! >>>>>>> >>>>>>> ------------------------------------------------ >>>>>>> [ ] +1 release it. >>>>>>> [ ] +0 go ahead; I don't care. >>>>>>> [ ] -0 there are a few minor glitches: ... >>>>>>> [ ] -1 no, do not release it because ... >>>>>>> ------------------------------------------------ >>>>>>> >>>>>>> Vote will remain open for at least 72 hours. >>>>>>> >>>>>> >>>>>> The vote is cancelled due to the problems found regarding the generated >>>>>> javadoc. >>>>>> I will cut another RC using the latest Oracle JDK. >>>>> >>>>> Please use the appropriate -Pjava-1.x profile to ensure the >>>>> compilation and tests use the relevant Java version. >>>>> >>>>> Run Maven with Java 7, but compile/test with the correct version. >>>> >>>> I did run it like that: >>>> >>>> mvn clean deploy -Prelease -Ptest-deploy -Pjava-1.5 >>> >>> OK thanks. >>> >>>> after setting the JAVA_1_5_HOME environment variable correctly. The >>>> right javac / java executable is used, but the felix-bundle plugin will >>>> set the jvm that was used to start maven in the generated manifest: >>>> >>>> Build-Jdk: 1.7.0_25 >>> >>> Ah - maybe we need to look at how to override that. >> >> Cannot see any obvious way to do this. >> It's trivial to add a new entry, but redefining Build-Jdk does not seem to >> work. >> More investigation needed. >> >> If you don't mind waiting a few days, the updated Javadoc plugin >> (2.9.1) should hopefully be available, at which point you can just use >> Java 1.6 for everything. >> >> But it would be good to solve the Felix issue. > > 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. 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. Ideally the manifest(s) should show the actual compiler version used as well as the source/target settings. > Thomas > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
