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
