On 06/28/2013 01:40 AM, sebb wrote: > 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.
Ok, but we know that it does compile with Java 1.5. It is also part of the release process that people test it with other JDKs, and I had to cut another release several times as it was failing on others. Since then I do test with at least the following JDKs prior to a release: * Oracle 1.5 * Oracle 1.6 * Oracle 1.7 * IBM 6 Thomas --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
