Commons should be happy to ignore compatibility, update to 1.8, change
package and maven coordinates, change interfaces to take advantage of
generics, become a modern code base. Staying in the 1.5 world, BCEL,
which is already dying, will die. No competent developer coming in from
the outside will look at BCEL and say, now _that_ is something i want to
work on.
This was the plan all along, and then someone came along and said, why
are we breaking backwards compatibility, and undid everything.
This is a major version, can we please move forward.
On 06/02/2016 06:07 AM, sebb wrote:
No, it's a consequence of the way the Java classpath and Maven work.
If Commons wishes to release a compatible version of BCEL, it must use
the same Java package and Maven coordinates.
(as well as ensure that any changes to the public API are at least
binary-compatible)
If Commons is happy to ignore compatibility, it can release a new
version with different package and Maven coordinates.
However this means downstream users have to update and recompile their source.
On 2 June 2016 at 10:41, dbrosIus <dbros...@baybroadband.net> wrote:
This is the problem with Commons.
-------- Original message --------
From: sebb <seb...@gmail.com>
Date: 06/02/2016 5:15 AM (GMT-05:00)
To: Commons Developers List <dev@commons.apache.org>
Subject: Re: [bcel] Deprecated InstructionConstants
On 2 June 2016 at 07:56, Benedikt Ritter <brit...@apache.org> wrote:
Gary Gregory <garydgreg...@gmail.com> schrieb am Do., 2. Juni 2016 um
08:00 Uhr:
So trunk packages would be renamed _back_ from bcel6 to the 5.2 packages?
That's what I understood from sebb's last message.
Yes, that would need to happen to support BC.
Gary
On Wed, Jun 1, 2016 at 3:43 PM, sebb <seb...@gmail.com> wrote:
Hang on please.
There were plans to produce a new incompatible release with new Maven
coords and new package names.
However as I recall there was some pushback from users who wished to
have a drop-in release.
That is not possible unless the release is binary compatible.
So I spent quite a bit of effort reworking the changes so as to
facilitate a binary compatible release.
As far as I can recall, that effort was successful apart from changes
to an interface (or two).
There were some ideas as to how to resolve the interface
incompatibilty, but no agreement was reached.
I think the options were:
- introduce new interface(s) extending the old one(s)
- keep the interface(s) and handle any runtime errors
- use the Java 8 (?) facility which allows an interface to contain a
method implementation.
Note that the code does not yet support some Java 8 features.
On 1 June 2016 at 09:34, Jan Matèrne (jhm) <apa...@materne.de> wrote:
It does not make sense though. All of the code in the bcel6 package is
going to be released for the first time in the upcoming 6.0 release.
Ok, didnt know that.
Then I'm fine :)
Just wanted to give a hint.
Jan
---------------------------------------------------------------------
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
--
E-Mail: garydgreg...@gmail.com | ggreg...@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-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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
