commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ralph Goers <ralph.go...@dslextreme.com>
Subject Re: [BCEL] 5.3 is going to be messy
Date Tue, 07 Jun 2016 15:32:33 GMT
I suspect Gary wants a 5.3 release because the CLIRR Maven plugin fails in Java 8 which has
resulted in https://github.com/mojohaus/clirr-maven-plugin/issues/3 <https://github.com/mojohaus/clirr-maven-plugin/issues/3>,
LANG-1025, and WICKET-5836 among others. We ran into this in Log4j, which I am pretty sure
what got Gary motivated.

Ralph 

> On Jun 7, 2016, at 8:24 AM, Benedikt Ritter <britter@apache.org> wrote:
> 
> Hi,
> 
> sebb <sebbaz@gmail.com> schrieb am Di., 7. Juni 2016 um 11:49 Uhr:
> 
>> On 6 June 2016 at 21:02, Gary Gregory <garydgregory@gmail.com> wrote:
>>> On Mon, Jun 6, 2016 at 12:44 PM, Benedikt Ritter <britter@apache.org>
>> wrote:
>>> 
>>>> Hi all,
>>>> 
>>>> I had a brief look at the state of BCEL wrt doing a last 5.x release.
>> Well,
>>>> it feels like that is going to be a mess:
>>>> 
>>>> - We have @since 6.0 annotations all over the code.
>>>> - We have same deprecated classes - why if the code is currently in the
>>>> shape for the 6.0 release, there should be no deprecated stuff
>>>> - We have chances.xml which are talking about the next big 6.0 release.
>>>> - We have renamed package coordinates which make it hard to generate a
>>>> Clirr report.
>>>> 
>>>> This will all have to be resolved before we can do the 5.3 release. I'm
>>>> currently wondering what might be the best way to push out the 5.x
>> release.
>>>> I think we should create the 5.x branch ASAP, so that the way is free
>> for
>>>> work on the important stuff in trunk. Hopefully this will enable us to
>>>> implement the missing bits for Java 8 support and get the 6.0 release
>> out
>>>> of the door soon.
>>>> 
>>>> Thoughts?
>>>> 
>>> 
>>> It seems like we are stuck in the middle b/w 6.0 and 5.3.
>>> 
>>> How about letting bcel6 stand and finish 6.0? This makes Sebb's recent
>> work
>>> a bit of a waste but might make migrating from 5.2 easier anyway.
>> 
>>> We can do the best we can for bcel6. We can do more clean ups and so on.
>>> 
>>> Some users will migrate, others can be asked to provide patches to 5.2
>> for
>>> a 5.3.
>> 
>> -1 for several reasons.
>> 
>> 0) I think we are fairly close to being able to release compatible
>> code with all the necessary fixes
>> 
>> 1) I don't believe we should force users to migrate their code in
>> order to support java 7/8.
>> In the case of Findbugs, this would also require all detector plugins to
>> change.
>> 
>> 2) the BCEL6 redesign has barely started. yes, some minor changes have
>> been done to tidy the code, but nothing has been done to the original
>> design, which is full of mutable classes and non-private mutable data.
>> I think a lot more needs to be done to produce an API which will be
>> sufficiently stable.
>> Otherwise there will soon be another API break.
>> 
> 
> I'm okay with the 5.3 release. But right know it feels like you're the only
> one wants to go through the trouble.
> 
> I propose we create the 5.x branch now. Those who want/need a compatible
> release can work that out in that branch. All others can work on trunk to
> get BCEL 6 out of the door with Java 7 and Java 8 compatibility.
> 
> Benedikt
> 
> 
>> 
>>> Then we can gather patches for a 100% BC 5.3. If 5.2 users care that much
>>> for 5.2 instead of migrating, I would help that they would be ready to
>> step
>>> in with patches.
>> 
>>> Gary
>>> 
>>> 
>>>> Benedikt
>>>> 
>>> 
>>> 
>>> 
>>> --
>>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>>> Java Persistence with Hibernate, Second Edition
>>> <http://www.manning.com/bauer3/>
>>> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
>>> Spring Batch in Action <http://www.manning.com/templier/>
>>> Blog: http://garygregory.wordpress.com
>>> Home: http://garygregory.com/
>>> Tweet! http://twitter.com/GaryGregory
>> 
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>> 
>> 


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message