commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thomas Neidhart <thomas.neidh...@gmail.com>
Subject Re: [CANCEL][VOTE] Release of Commons Collections 4.0-alpha1 based on RC1
Date Fri, 28 Jun 2013 06:15:46 GMT
On 06/28/2013 01:40 AM, sebb wrote:
> On 27 June 2013 22:23, Thomas Neidhart <thomas.neidhart@gmail.com> wrote:
>> On 06/27/2013 10:41 PM, sebb wrote:
>>> On 27 June 2013 21:12, sebb <sebbaz@gmail.com> wrote:
>>>> On 27 June 2013 20:44, Thomas Neidhart <thomas.neidhart@gmail.com>
wrote:
>>>>> On 06/27/2013 11:44 AM, sebb wrote:
>>>>>> On 27 June 2013 10:20, Thomas Neidhart <thomas.neidhart@gmail.com>
wrote:
>>>>>>> On Sun, Jun 23, 2013 at 10:04 PM, Thomas Neidhart <thomas.neidhart@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-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message