[BCEL] 5.3 is going to be messy

classic Classic list List threaded Threaded
27 messages Options
12
Reply | Threaded
Open this post in threaded view
|

[BCEL] 5.3 is going to be messy

Benedikt Ritter-4
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?
Benedikt
Reply | Threaded
Open this post in threaded view
|

Re: [BCEL] 5.3 is going to be messy

garydgregory
On Mon, Jun 6, 2016 at 12:44 PM, Benedikt Ritter <[hidden email]> 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.

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: [hidden email] | [hidden email]
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
Reply | Threaded
Open this post in threaded view
|

Re: [BCEL] 5.3 is going to be messy

Jörg Schaible
Gary Gregory wrote:

> On Mon, Jun 6, 2016 at 12:44 PM, Benedikt Ritter <[hidden email]>
> 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.
>
> 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.

+1

Cheers,
Jörg


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [BCEL] 5.3 is going to be messy

garydgregory
In reply to this post by garydgregory
On Mon, Jun 6, 2016 at 1:02 PM, Gary Gregory <[hidden email]> wrote:

> On Mon, Jun 6, 2016 at 12:44 PM, Benedikt Ritter <[hidden email]>
> 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.
>
> 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.
>

Fat fingers! "I would help that they would be ready to step in with
patches." ->  "I would _hope_ that they would be ready to step in with
patches."

G

>
> Gary
>
>
>> Benedikt
>>
>
>
>
> --
> E-Mail: [hidden email] | [hidden email]
> 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
>



--
E-Mail: [hidden email] | [hidden email]
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
Reply | Threaded
Open this post in threaded view
|

Re: [BCEL] 5.3 is going to be messy

sebb-2-2
In reply to this post by garydgregory
On 6 June 2016 at 21:02, Gary Gregory <[hidden email]> wrote:

> On Mon, Jun 6, 2016 at 12:44 PM, Benedikt Ritter <[hidden email]> 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.

> 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: [hidden email] | [hidden email]
> 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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [BCEL] 5.3 is going to be messy

Torsten Curdt-3
>
> 1) I don't believe we should force users to migrate their code in
> order to support java 7/8.
>

...and that line of thinking is why it feels like commons projects are
effectively stuck in the past.

No one needs to upgrade. If your projects live in the past - there are bug
fix releases.
But if you want the new shiny then you as well should be OK to put in some
effort to do so.
Change should be easy - not just for our user but also for us.

My 2 cents
Reply | Threaded
Open this post in threaded view
|

Re: [BCEL] 5.3 is going to be messy

sebb-2-2
On 7 June 2016 at 11:15, Torsten Curdt <[hidden email]> wrote:
>>
>> 1) I don't believe we should force users to migrate their code in
>> order to support java 7/8.
>>
>
> ...and that line of thinking is why it feels like commons projects are
> effectively stuck in the past.

And maybe the ease of upgrade is why they are popular with users.

> No one needs to upgrade. If your projects live in the past - there are bug
> fix releases.

That's not the case in general. Very few commons projects maintain
parallel releases.

> But if you want the new shiny then you as well should be OK to put in some
> effort to do so.

Why should the user have to do so?

> Change should be easy - not just for our user but also for us.

There are many more users than there are developers.

> My 2 cents

Suppose there are 10 developers on BCEL; that's 20 cents.

There may be 1000 or more users.

That's 20 dollars.

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [BCEL] 5.3 is going to be messy

James Carman
In reply to this post by Torsten Curdt-3
+1 Torsten

On Tue, Jun 7, 2016 at 6:17 AM Torsten Curdt <[hidden email]> wrote:

> >
> > 1) I don't believe we should force users to migrate their code in
> > order to support java 7/8.
> >
>
> ...and that line of thinking is why it feels like commons projects are
> effectively stuck in the past.
>
> No one needs to upgrade. If your projects live in the past - there are bug
> fix releases.
> But if you want the new shiny then you as well should be OK to put in some
> effort to do so.
> Change should be easy - not just for our user but also for us.
>
> My 2 cents
>
Reply | Threaded
Open this post in threaded view
|

Re: [BCEL] 5.3 is going to be messy

Gilles Sadowski
In reply to this post by sebb-2-2
On Tue, 7 Jun 2016 11:39:09 +0100, sebb wrote:

> On 7 June 2016 at 11:15, Torsten Curdt <[hidden email]> wrote:
>>>
>>> 1) I don't believe we should force users to migrate their code in
>>> order to support java 7/8.
>>>
>>
>> ...and that line of thinking is why it feels like commons projects
>> are
>> effectively stuck in the past.
>
> And maybe the ease of upgrade is why they are popular with users.
>
>> No one needs to upgrade. If your projects live in the past - there
>> are bug
>> fix releases.
>
> That's not the case in general. Very few commons projects maintain
> parallel releases.

And why not?

Gilles

>
>> But if you want the new shiny then you as well should be OK to put
>> in some
>> effort to do so.
>
> Why should the user have to do so?
>
>> Change should be easy - not just for our user but also for us.
>
> There are many more users than there are developers.
>
>> My 2 cents
>
> Suppose there are 10 developers on BCEL; that's 20 cents.
>
> There may be 1000 or more users.
>
> That's 20 dollars.


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [BCEL] 5.3 is going to be messy

Dave Brosius-2
In reply to this post by sebb-2-2


On 06/07/2016 06:39 AM, sebb wrote:
> On 7 June 2016 at 11:15, Torsten Curdt <[hidden email]> wrote:
>>> 1) I don't believe we should force users to migrate their code in
>>> order to support java 7/8.
>>>
>> ...and that line of thinking is why it feels like commons projects are
>> effectively stuck in the past.
> And maybe the ease of upgrade is why they are popular with users.

What upgrade? When have the users had to upgrade? like 3 years ago?
>
>> No one needs to upgrade. If your projects live in the past - there are bug
>> fix releases.
> That's not the case in general. Very few commons projects maintain
> parallel releases.
>
>> But if you want the new shiny then you as well should be OK to put in some
>> effort to do so.
> Why should the user have to do so?

There's one thing above all else that really is painful to the user. No
upgrades!
Why are there no upgrades? Because there are no developers!
Why are there no developers? Because they are punished with a horrendous
development experience. Oh boy, can't wait to develop with 1.5 in SVN!!
that's a treat.

>
>> Change should be easy - not just for our user but also for us.
> There are many more users than there are developers.
>
>> My 2 cents
> Suppose there are 10 developers on BCEL; that's 20 cents.
>
> There may be 1000 or more users.
>
> That's 20 dollars.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [BCEL] 5.3 is going to be messy

sebb-2-2
On 7 June 2016 at 14:29, Dave Brosius <[hidden email]> wrote:

>
>
> On 06/07/2016 06:39 AM, sebb wrote:
>>
>> On 7 June 2016 at 11:15, Torsten Curdt <[hidden email]> wrote:
>>>>
>>>> 1) I don't believe we should force users to migrate their code in
>>>> order to support java 7/8.
>>>>
>>> ...and that line of thinking is why it feels like commons projects are
>>> effectively stuck in the past.
>>
>> And maybe the ease of upgrade is why they are popular with users.
>
>
> What upgrade? When have the users had to upgrade? like 3 years ago?
>>
>>
>>> No one needs to upgrade. If your projects live in the past - there are
>>> bug
>>> fix releases.
>>
>> That's not the case in general. Very few commons projects maintain
>> parallel releases.
>>
>>> But if you want the new shiny then you as well should be OK to put in
>>> some
>>> effort to do so.
>>
>> Why should the user have to do so?
>
>
> There's one thing above all else that really is painful to the user. No
> upgrades!
> Why are there no upgrades? Because there are no developers!
> Why are there no developers? Because they are punished with a horrendous
> development experience. Oh boy, can't wait to develop with 1.5 in SVN!!
> that's a treat.

You are conflating several issues in one.

The Java version is orthogonal to compatibility.
The source code implementation is nothing to do with either the Java
version or compatibility.

>>
>>> Change should be easy - not just for our user but also for us.
>>
>> There are many more users than there are developers.
>>
>>> My 2 cents
>>
>> Suppose there are 10 developers on BCEL; that's 20 cents.
>>
>> There may be 1000 or more users.
>>
>> That's 20 dollars.
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [BCEL] 5.3 is going to be messy

Benedikt Ritter-4
In reply to this post by sebb-2-2
Hi,

sebb <[hidden email]> schrieb am Di., 7. Juni 2016 um 11:49 Uhr:

> On 6 June 2016 at 21:02, Gary Gregory <[hidden email]> wrote:
> > On Mon, Jun 6, 2016 at 12:44 PM, Benedikt Ritter <[hidden email]>
> 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: [hidden email] | [hidden email]
> > 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: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: [BCEL] 5.3 is going to be messy

Ralph Goers
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 <[hidden email]> wrote:
>
> Hi,
>
> sebb <[hidden email]> schrieb am Di., 7. Juni 2016 um 11:49 Uhr:
>
>> On 6 June 2016 at 21:02, Gary Gregory <[hidden email]> wrote:
>>> On Mon, Jun 6, 2016 at 12:44 PM, Benedikt Ritter <[hidden email]>
>> 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: [hidden email] | [hidden email]
>>> 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: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>

Reply | Threaded
Open this post in threaded view
|

Re: [BCEL] 5.3 is going to be messy

Andrey Loskutov
In reply to this post by Benedikt Ritter-4
On Tuesday 07 June 2016 15:24 Benedikt Ritter wrote:

> Hi,
>
> sebb <[hidden email]> schrieb am Di., 7. Juni 2016 um 11:49 Uhr:
> > 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.

What trouble do you mean? BTW if I can help testing, I'm ready to go.

> 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.

Sorry, IMHO the *only* reason to release 5.3 after many years *IS* the Java 7/8 compatibility.
We (user) just want something stable we can use on a modern JVM (and Java 7 is already *obsoleted*!), nothing more.
Before thinking about new API's, please just release something running on Java 7/8.

--
Kind regards,
google.com/+AndreyLoskutov

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [BCEL] 5.3 is going to be messy

Benedikt Ritter-4
Hello,

Andrey Loskutov <[hidden email]> schrieb am Di., 7. Juni 2016 um 17:35 Uhr:

> On Tuesday 07 June 2016 15:24 Benedikt Ritter wrote:
> > Hi,
> >
> > sebb <[hidden email]> schrieb am Di., 7. Juni 2016 um 11:49 Uhr:
> > > 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.
>
> What trouble do you mean? BTW if I can help testing, I'm ready to go.
>
> > 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.
>
> Sorry, IMHO the *only* reason to release 5.3 after many years *IS* the
> Java 7/8 compatibility.
> We (user) just want something stable we can use on a modern JVM (and Java
> 7 is already *obsoleted*!), nothing more.
> Before thinking about new API's, please just release something running on
> Java 7/8.
>

So that's a word from our users.

What now? Revert the Package rename in trunk back to org.apache.bcel and
finish that 5.3 release? I have no idea what's broken wrt to compatibility
because you  cant compare with the ne coords anymore.


>
> --
> Kind regards,
> google.com/+AndreyLoskutov
>
Reply | Threaded
Open this post in threaded view
|

Re: [BCEL] 5.3 is going to be messy

Andrey Loskutov
On Tuesday 07 June 2016 15:37 Benedikt Ritter wrote:

> > > 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.
> >
> > Sorry, IMHO the *only* reason to release 5.3 after many years *IS* the
> > Java 7/8 compatibility.
> > We (user) just want something stable we can use on a modern JVM (and Java
> > 7 is already *obsoleted*!), nothing more.
> > Before thinking about new API's, please just release something running on
> > Java 7/8.
> >
>
> So that's a word from our users.
>
> What now? Revert the Package rename in trunk back to org.apache.bcel and
> finish that 5.3 release? I have no idea what's broken wrt to compatibility
> because you  cant compare with the ne coords anymore.

Yes. Please undo "package rename" aka BCEL-222 thing first.
This is an easy task (requires ~5 minutes in the IDE), see commit https://github.com/iloveeclipse/commons-bcel/commit/ae98757798ab54992a6e7a1cf6429a2a44e0e67c
. After that we will see how bad/good the state is.
I don't think the state is really bad, otherwise I wouldn't be able to create experimental port of FB in few hours.
See https://github.com/findbugsproject/findbugs/issues/106 - the commits referenced there describe what I saw on breakage from the FindBugs side.
Of course that is only from the FindBugs point of view.

--
Kind regards,
google.com/+AndreyLoskutov

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

[BCEL] Revert package rename in trunk (Was: [BCEL] 5.3 is going to be messy)

Benedikt Ritter-4
Hi,

any objections against reverting the package rename in trunk back to
org.apache.bcel ? (For reasons see below)

Benedikt

---------- Forwarded message ---------
From: Andrey Loskutov <[hidden email]>
Date: Di., 7. Juni 2016 um 17:55 Uhr
Subject: Re: [BCEL] 5.3 is going to be messy
To: <[hidden email]>
Cc: Benedikt Ritter <[hidden email]>


On Tuesday 07 June 2016 15:37 Benedikt Ritter wrote:
> > > 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.
> >
> > Sorry, IMHO the *only* reason to release 5.3 after many years *IS* the
> > Java 7/8 compatibility.
> > We (user) just want something stable we can use on a modern JVM (and
Java
> > 7 is already *obsoleted*!), nothing more.
> > Before thinking about new API's, please just release something running
on
> > Java 7/8.
> >
>
> So that's a word from our users.
>
> What now? Revert the Package rename in trunk back to org.apache.bcel and
> finish that 5.3 release? I have no idea what's broken wrt to compatibility
> because you  cant compare with the ne coords anymore.

Yes. Please undo "package rename" aka BCEL-222 thing first.
This is an easy task (requires ~5 minutes in the IDE), see commit
https://github.com/iloveeclipse/commons-bcel/commit/ae98757798ab54992a6e7a1cf6429a2a44e0e67c
. After that we will see how bad/good the state is.
I don't think the state is really bad, otherwise I wouldn't be able to
create experimental port of FB in few hours.
See https://github.com/findbugsproject/findbugs/issues/106 - the commits
referenced there describe what I saw on breakage from the FindBugs side.
Of course that is only from the FindBugs point of view.


--
Kind regards,
google.com/+AndreyLoskutov
Reply | Threaded
Open this post in threaded view
|

Re: [BCEL] Revert package rename in trunk (Was: [BCEL] 5.3 is going to be messy)

sebb-2-2
Fine by me

On 7 June 2016 at 17:00, Benedikt Ritter <[hidden email]> wrote:

> Hi,
>
> any objections against reverting the package rename in trunk back to
> org.apache.bcel ? (For reasons see below)
>
> Benedikt
>
> ---------- Forwarded message ---------
> From: Andrey Loskutov <[hidden email]>
> Date: Di., 7. Juni 2016 um 17:55 Uhr
> Subject: Re: [BCEL] 5.3 is going to be messy
> To: <[hidden email]>
> Cc: Benedikt Ritter <[hidden email]>
>
>
> On Tuesday 07 June 2016 15:37 Benedikt Ritter wrote:
>> > > 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.
>> >
>> > Sorry, IMHO the *only* reason to release 5.3 after many years *IS* the
>> > Java 7/8 compatibility.
>> > We (user) just want something stable we can use on a modern JVM (and
> Java
>> > 7 is already *obsoleted*!), nothing more.
>> > Before thinking about new API's, please just release something running
> on
>> > Java 7/8.
>> >
>>
>> So that's a word from our users.
>>
>> What now? Revert the Package rename in trunk back to org.apache.bcel and
>> finish that 5.3 release? I have no idea what's broken wrt to compatibility
>> because you  cant compare with the ne coords anymore.
>
> Yes. Please undo "package rename" aka BCEL-222 thing first.
> This is an easy task (requires ~5 minutes in the IDE), see commit
> https://github.com/iloveeclipse/commons-bcel/commit/ae98757798ab54992a6e7a1cf6429a2a44e0e67c
> . After that we will see how bad/good the state is.
> I don't think the state is really bad, otherwise I wouldn't be able to
> create experimental port of FB in few hours.
> See https://github.com/findbugsproject/findbugs/issues/106 - the commits
> referenced there describe what I saw on breakage from the FindBugs side.
> Of course that is only from the FindBugs point of view.
>
>
> --
> Kind regards,
> google.com/+AndreyLoskutov

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [BCEL] Revert package rename in trunk (Was: [BCEL] 5.3 is going to be messy)

sebb-2-2
Also need to revert the Maven GA coords

On 7 June 2016 at 17:06, sebb <[hidden email]> wrote:

> Fine by me
>
> On 7 June 2016 at 17:00, Benedikt Ritter <[hidden email]> wrote:
>> Hi,
>>
>> any objections against reverting the package rename in trunk back to
>> org.apache.bcel ? (For reasons see below)
>>
>> Benedikt
>>
>> ---------- Forwarded message ---------
>> From: Andrey Loskutov <[hidden email]>
>> Date: Di., 7. Juni 2016 um 17:55 Uhr
>> Subject: Re: [BCEL] 5.3 is going to be messy
>> To: <[hidden email]>
>> Cc: Benedikt Ritter <[hidden email]>
>>
>>
>> On Tuesday 07 June 2016 15:37 Benedikt Ritter wrote:
>>> > > 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.
>>> >
>>> > Sorry, IMHO the *only* reason to release 5.3 after many years *IS* the
>>> > Java 7/8 compatibility.
>>> > We (user) just want something stable we can use on a modern JVM (and
>> Java
>>> > 7 is already *obsoleted*!), nothing more.
>>> > Before thinking about new API's, please just release something running
>> on
>>> > Java 7/8.
>>> >
>>>
>>> So that's a word from our users.
>>>
>>> What now? Revert the Package rename in trunk back to org.apache.bcel and
>>> finish that 5.3 release? I have no idea what's broken wrt to compatibility
>>> because you  cant compare with the ne coords anymore.
>>
>> Yes. Please undo "package rename" aka BCEL-222 thing first.
>> This is an easy task (requires ~5 minutes in the IDE), see commit
>> https://github.com/iloveeclipse/commons-bcel/commit/ae98757798ab54992a6e7a1cf6429a2a44e0e67c
>> . After that we will see how bad/good the state is.
>> I don't think the state is really bad, otherwise I wouldn't be able to
>> create experimental port of FB in few hours.
>> See https://github.com/findbugsproject/findbugs/issues/106 - the commits
>> referenced there describe what I saw on breakage from the FindBugs side.
>> Of course that is only from the FindBugs point of view.
>>
>>
>> --
>> Kind regards,
>> google.com/+AndreyLoskutov

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [BCEL] Revert package rename in trunk (Was: [BCEL] 5.3 is going to be messy)

Benedikt Ritter-4
Okay.

- I'm going to revert the package rename.
- We're going to create a binary compatible release for Java 7 and Java 8
support.
- We will bump the major version number to indicate that there are massive
changes in this release.

Benedikt

sebb <[hidden email]> schrieb am Di., 7. Juni 2016 um 18:16 Uhr:

> Also need to revert the Maven GA coords
>
> On 7 June 2016 at 17:06, sebb <[hidden email]> wrote:
> > Fine by me
> >
> > On 7 June 2016 at 17:00, Benedikt Ritter <[hidden email]> wrote:
> >> Hi,
> >>
> >> any objections against reverting the package rename in trunk back to
> >> org.apache.bcel ? (For reasons see below)
> >>
> >> Benedikt
> >>
> >> ---------- Forwarded message ---------
> >> From: Andrey Loskutov <[hidden email]>
> >> Date: Di., 7. Juni 2016 um 17:55 Uhr
> >> Subject: Re: [BCEL] 5.3 is going to be messy
> >> To: <[hidden email]>
> >> Cc: Benedikt Ritter <[hidden email]>
> >>
> >>
> >> On Tuesday 07 June 2016 15:37 Benedikt Ritter wrote:
> >>> > > 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.
> >>> >
> >>> > Sorry, IMHO the *only* reason to release 5.3 after many years *IS*
> the
> >>> > Java 7/8 compatibility.
> >>> > We (user) just want something stable we can use on a modern JVM (and
> >> Java
> >>> > 7 is already *obsoleted*!), nothing more.
> >>> > Before thinking about new API's, please just release something
> running
> >> on
> >>> > Java 7/8.
> >>> >
> >>>
> >>> So that's a word from our users.
> >>>
> >>> What now? Revert the Package rename in trunk back to org.apache.bcel
> and
> >>> finish that 5.3 release? I have no idea what's broken wrt to
> compatibility
> >>> because you  cant compare with the ne coords anymore.
> >>
> >> Yes. Please undo "package rename" aka BCEL-222 thing first.
> >> This is an easy task (requires ~5 minutes in the IDE), see commit
> >>
> https://github.com/iloveeclipse/commons-bcel/commit/ae98757798ab54992a6e7a1cf6429a2a44e0e67c
> >> . After that we will see how bad/good the state is.
> >> I don't think the state is really bad, otherwise I wouldn't be able to
> >> create experimental port of FB in few hours.
> >> See https://github.com/findbugsproject/findbugs/issues/106 - the
> commits
> >> referenced there describe what I saw on breakage from the FindBugs side.
> >> Of course that is only from the FindBugs point of view.
> >>
> >>
> >> --
> >> Kind regards,
> >> google.com/+AndreyLoskutov
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
12