You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by ianmca86 <ia...@gmail.com> on 2015/03/02 21:37:57 UTC
Re: [VOTE] Release BCEL 6.0 based on RC3
+1
no one has really answered ben's question yet. if bcel 209
<https://issues.apache.org/jira/browse/BCEL-209> is committed could we cut
a release? it seems like everyone is okay with the general approach taken
there
my company also is mandating all projects move to java 8 this month since
java 7 is discontinued next month. i'm quite nervous that patch has been
outstanding for a month already and we're blocking on it. nine years is too
long between releases and we don't need to drag this out more
regards
ian
--
View this message in context: http://apache-commons.680414.n4.nabble.com/VOTE-Release-BCEL-6-0-based-on-RC3-tp4667129p4673380.html
Sent from the Commons - Dev mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [VOTE] Release BCEL 6.0 based on RC3
Posted by Emmanuel Bourg <eb...@apache.org>.
Le 02/03/2015 23:21, ianmca86 a écrit :
> i don't like the policy of changing the package name to make a tiny change
> to binary compatibility. it makes it impossible to release often
And users don't like having deep conflicting libraries in their
dependency tree :)
> but we're getting way off base. my question is the same as ben's which was
> never answered. can we check in the patch for 209 and then release a new
> version?
There are other important issues besides BCEL-209, the LVTT issues
should be fixed for example if we want to claim Java 5 support.
If your company needs a BCEL version compatible with Java 8 you can
compile the version from the 6.0-RC3 tag, it isn't perfect but still
better than the latest stable release.
Emmanuel Bourg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [VOTE] Release BCEL 6.0 based on RC3
Posted by Gary Gregory <ga...@gmail.com>.
WRT Tangent: The thing with BC is that it's a Boolean property, not a
quantitative...
On Mon, Mar 2, 2015 at 2:21 PM, ianmca86 <ia...@gmail.com> wrote:
> i don't like the policy of changing the package name to make a tiny change
> to binary compatibility. it makes it impossible to release often
>
> but we're getting way off base. my question is the same as ben's which was
> never answered. can we check in the patch for 209 and then release a new
> version?
>
>
> On Mon, Mar 2, 2015 at 2:04 PM, garydgregory [via Apache Commons] <
> ml-node+s680414n4673389h91@n4.nabble.com> wrote:
>
> > On Mon, Mar 2, 2015 at 2:07 PM, sebb <[hidden email]
> > <http:///user/SendEmail.jtp?type=node&node=4673389&i=0>> wrote:
> >
> > > On 2 March 2015 at 21:33, Gary Gregory <[hidden email]
> > <http:///user/SendEmail.jtp?type=node&node=4673389&i=1>> wrote:
> > > > I'm all for RERO if the release manager is willing.
> > >
> > > RM willingness is only part of it.
> > >
> > > RERO is all very well if:
> > > - the API is stable; or
> > > - frequent changes of package name/Maven coords are acceptable to
> > > consumers; or
> > > - one does not care about binary compatibilty
> > >
> > > IMO it's unhelpful to keep pushing the RERO mantra in isolation.
> > >
> >
> > Yes, agreed. I was assuming we all see eye to eye on the semantics.
> >
> > Gary
> >
> > >
> > > > Gary
> > > >
> > > > On Mon, Mar 2, 2015 at 12:37 PM, ianmca86 <[hidden email]
> > <http:///user/SendEmail.jtp?type=node&node=4673389&i=2>> wrote:
> > > >
> > > >> +1
> > > >>
> > > >> no one has really answered ben's question yet. if bcel 209
> > > >> <https://issues.apache.org/jira/browse/BCEL-209> is committed
> > could
> > > we
> > > >> cut
> > > >> a release? it seems like everyone is okay with the general approach
> > > taken
> > > >> there
> > > >>
> > > >> my company also is mandating all projects move to java 8 this month
> > > since
> > > >> java 7 is discontinued next month. i'm quite nervous that patch has
> > been
> > > >> outstanding for a month already and we're blocking on it. nine years
> > is
> > > too
> > > >> long between releases and we don't need to drag this out more
> > > >>
> > > >> regards
> > > >> ian
> > > >>
> > > >>
> > > >>
> > > >> --
> > > >> View this message in context:
> > > >>
> > >
> >
> http://apache-commons.680414.n4.nabble.com/VOTE-Release-BCEL-6-0-based-on-RC3-tp4667129p4673380.html
> > > >> Sent from the Commons - Dev mailing list archive at Nabble.com.
> > > >>
> > > >>
> ---------------------------------------------------------------------
> > > >> To unsubscribe, e-mail: [hidden email]
> > <http:///user/SendEmail.jtp?type=node&node=4673389&i=3>
> > > >> For additional commands, e-mail: [hidden email]
> > <http:///user/SendEmail.jtp?type=node&node=4673389&i=4>
> > > >>
> > > >>
> > > >
> > > >
> > > > --
> > > > E-Mail: [hidden email]
> > <http:///user/SendEmail.jtp?type=node&node=4673389&i=5> | [hidden email]
> > <http:///user/SendEmail.jtp?type=node&node=4673389&i=6>
> > > > 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]
> > <http:///user/SendEmail.jtp?type=node&node=4673389&i=7>
> > > For additional commands, e-mail: [hidden email]
> > <http:///user/SendEmail.jtp?type=node&node=4673389&i=8>
> > >
> > >
> >
> >
> > --
> > E-Mail: [hidden email]
> > <http:///user/SendEmail.jtp?type=node&node=4673389&i=9> | [hidden email]
> > <http:///user/SendEmail.jtp?type=node&node=4673389&i=10>
> > 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
> >
> >
> > ------------------------------
> > If you reply to this email, your message will be added to the discussion
> > below:
> >
> >
> http://apache-commons.680414.n4.nabble.com/VOTE-Release-BCEL-6-0-based-on-RC3-tp4667129p4673389.html
> > To unsubscribe from [VOTE] Release BCEL 6.0 based on RC3, click here
> > <
> http://apache-commons.680414.n4.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=4667129&code=aWFubWNhODZAZ21haWwuY29tfDQ2NjcxMjl8NTMyODIwMzEy
> >
> > .
> > NAML
> > <
> http://apache-commons.680414.n4.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml
> >
> >
>
>
>
>
> --
> View this message in context:
> http://apache-commons.680414.n4.nabble.com/VOTE-Release-BCEL-6-0-based-on-RC3-tp4667129p4673390.html
> Sent from the Commons - Dev mailing list archive at Nabble.com.
--
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
Re: [VOTE] Release BCEL 6.0 based on RC3
Posted by ianmca86 <ia...@gmail.com>.
i don't like the policy of changing the package name to make a tiny change
to binary compatibility. it makes it impossible to release often
but we're getting way off base. my question is the same as ben's which was
never answered. can we check in the patch for 209 and then release a new
version?
On Mon, Mar 2, 2015 at 2:04 PM, garydgregory [via Apache Commons] <
ml-node+s680414n4673389h91@n4.nabble.com> wrote:
> On Mon, Mar 2, 2015 at 2:07 PM, sebb <[hidden email]
> <http:///user/SendEmail.jtp?type=node&node=4673389&i=0>> wrote:
>
> > On 2 March 2015 at 21:33, Gary Gregory <[hidden email]
> <http:///user/SendEmail.jtp?type=node&node=4673389&i=1>> wrote:
> > > I'm all for RERO if the release manager is willing.
> >
> > RM willingness is only part of it.
> >
> > RERO is all very well if:
> > - the API is stable; or
> > - frequent changes of package name/Maven coords are acceptable to
> > consumers; or
> > - one does not care about binary compatibilty
> >
> > IMO it's unhelpful to keep pushing the RERO mantra in isolation.
> >
>
> Yes, agreed. I was assuming we all see eye to eye on the semantics.
>
> Gary
>
> >
> > > Gary
> > >
> > > On Mon, Mar 2, 2015 at 12:37 PM, ianmca86 <[hidden email]
> <http:///user/SendEmail.jtp?type=node&node=4673389&i=2>> wrote:
> > >
> > >> +1
> > >>
> > >> no one has really answered ben's question yet. if bcel 209
> > >> <https://issues.apache.org/jira/browse/BCEL-209> is committed
> could
> > we
> > >> cut
> > >> a release? it seems like everyone is okay with the general approach
> > taken
> > >> there
> > >>
> > >> my company also is mandating all projects move to java 8 this month
> > since
> > >> java 7 is discontinued next month. i'm quite nervous that patch has
> been
> > >> outstanding for a month already and we're blocking on it. nine years
> is
> > too
> > >> long between releases and we don't need to drag this out more
> > >>
> > >> regards
> > >> ian
> > >>
> > >>
> > >>
> > >> --
> > >> View this message in context:
> > >>
> >
> http://apache-commons.680414.n4.nabble.com/VOTE-Release-BCEL-6-0-based-on-RC3-tp4667129p4673380.html
> > >> Sent from the Commons - Dev mailing list archive at Nabble.com.
> > >>
> > >> ---------------------------------------------------------------------
> > >> To unsubscribe, e-mail: [hidden email]
> <http:///user/SendEmail.jtp?type=node&node=4673389&i=3>
> > >> For additional commands, e-mail: [hidden email]
> <http:///user/SendEmail.jtp?type=node&node=4673389&i=4>
> > >>
> > >>
> > >
> > >
> > > --
> > > E-Mail: [hidden email]
> <http:///user/SendEmail.jtp?type=node&node=4673389&i=5> | [hidden email]
> <http:///user/SendEmail.jtp?type=node&node=4673389&i=6>
> > > 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]
> <http:///user/SendEmail.jtp?type=node&node=4673389&i=7>
> > For additional commands, e-mail: [hidden email]
> <http:///user/SendEmail.jtp?type=node&node=4673389&i=8>
> >
> >
>
>
> --
> E-Mail: [hidden email]
> <http:///user/SendEmail.jtp?type=node&node=4673389&i=9> | [hidden email]
> <http:///user/SendEmail.jtp?type=node&node=4673389&i=10>
> 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
>
>
> ------------------------------
> If you reply to this email, your message will be added to the discussion
> below:
>
> http://apache-commons.680414.n4.nabble.com/VOTE-Release-BCEL-6-0-based-on-RC3-tp4667129p4673389.html
> To unsubscribe from [VOTE] Release BCEL 6.0 based on RC3, click here
> <http://apache-commons.680414.n4.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=4667129&code=aWFubWNhODZAZ21haWwuY29tfDQ2NjcxMjl8NTMyODIwMzEy>
> .
> NAML
> <http://apache-commons.680414.n4.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>
>
--
View this message in context: http://apache-commons.680414.n4.nabble.com/VOTE-Release-BCEL-6-0-based-on-RC3-tp4667129p4673390.html
Sent from the Commons - Dev mailing list archive at Nabble.com.
Re: [VOTE] Release BCEL 6.0 based on RC3
Posted by sebb <se...@gmail.com>.
On 13 March 2015 at 17:40, Sarah Murray <sa...@gmail.com> wrote:
> It's absurd to have a library where no released version works on any
> supported version of Java. End of story
Well, there are 2 solutions to that.
1) BCEL is abandoned/retired.
2) BCEL is updated to support recent versions of Java.
> On Wed, Mar 11, 2015 at 7:04 PM, sebb <se...@gmail.com> wrote:
>
>> On 12 March 2015 at 01:25, Niall Pemberton <ni...@gmail.com>
>> wrote:
>> > On Fri, Mar 6, 2015 at 7:42 PM, sarahkm1972 <sa...@gmail.com>
>> wrote:
>> >
>> >> +100 to RERO. +1000 to release before we're all dead. It's been a decade
>> >> people. Just cut a release already. You can always cut another one
>> later.
>> >> Stop with the excuses
>> >>
>> >> Whatever you want to call it - alpha, beta, RC, final, anything. Java 8
>> >> users are left in a lurch. Compiling libraries is not a realistic
>> solution.
>> >> As stated previously by others we would also have to patch and compile
>> >> libraries depending on BCEL and also figure the transitive dependency
>> graph
>> >> for everything we use since we can't use Maven to do that due to BCEL
>> not
>> >> being in Maven. This is a huge huge pain because we're big Scala users
>> and
>> >> rely heavily on the Typesafe ecosystem which is dropping support for
>> Java 7
>> >> in all of its products and already has in Play Framework and Akka as
>> well
>> >> as
>> >> others like its Config library.
>> >>
>> >
>> > You say "stop with the excuses" and then go on to list a whole bunch of
>> > excuses why its too much effort for you to build BCEL and test it. Yes it
>> > would be an effort - but it would be invaluable to have some pre-release
>> > testing and feedback and help to get it our faster.
>>
>> It's not even necessary to build BCEL in order to test against trunk,
>> because you can get BCEL snapshots from the Apache Maven Snapshot
>> repository.
>> If the CI system is working, the SNAPSHOTs wll be updated regularly
>> when there have been commits.
>> If it appears that the snapshot has not been built for some while
>> since the last commit (e.g. 24 hrs), ask here and someone can prod the
>> CI system (or just deploy another snapshot).
>>
>> Of course such builds have no guarantees, and should not be relied on
>> long-term (they may be replaced at any time), but for test purposes
>> they will do.
>>
>> > Niall
>> >
>> >
>> >
>> >> --S.
>> >>
>> >>
>> >>
>> >> --
>> >> View this message in context:
>> >>
>> http://apache-commons.680414.n4.nabble.com/VOTE-Release-BCEL-6-0-based-on-RC3-tp4667129p4673474.html
>> >> Sent from the Commons - Dev mailing list archive at Nabble.com.
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> >> For additional commands, e-mail: dev-help@commons.apache.org
>> >>
>> >>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [VOTE] Release BCEL 6.0 based on RC3
Posted by Sarah Murray <sa...@gmail.com>.
It's absurd to have a library where no released version works on any
supported version of Java. End of story
On Wed, Mar 11, 2015 at 7:04 PM, sebb <se...@gmail.com> wrote:
> On 12 March 2015 at 01:25, Niall Pemberton <ni...@gmail.com>
> wrote:
> > On Fri, Mar 6, 2015 at 7:42 PM, sarahkm1972 <sa...@gmail.com>
> wrote:
> >
> >> +100 to RERO. +1000 to release before we're all dead. It's been a decade
> >> people. Just cut a release already. You can always cut another one
> later.
> >> Stop with the excuses
> >>
> >> Whatever you want to call it - alpha, beta, RC, final, anything. Java 8
> >> users are left in a lurch. Compiling libraries is not a realistic
> solution.
> >> As stated previously by others we would also have to patch and compile
> >> libraries depending on BCEL and also figure the transitive dependency
> graph
> >> for everything we use since we can't use Maven to do that due to BCEL
> not
> >> being in Maven. This is a huge huge pain because we're big Scala users
> and
> >> rely heavily on the Typesafe ecosystem which is dropping support for
> Java 7
> >> in all of its products and already has in Play Framework and Akka as
> well
> >> as
> >> others like its Config library.
> >>
> >
> > You say "stop with the excuses" and then go on to list a whole bunch of
> > excuses why its too much effort for you to build BCEL and test it. Yes it
> > would be an effort - but it would be invaluable to have some pre-release
> > testing and feedback and help to get it our faster.
>
> It's not even necessary to build BCEL in order to test against trunk,
> because you can get BCEL snapshots from the Apache Maven Snapshot
> repository.
> If the CI system is working, the SNAPSHOTs wll be updated regularly
> when there have been commits.
> If it appears that the snapshot has not been built for some while
> since the last commit (e.g. 24 hrs), ask here and someone can prod the
> CI system (or just deploy another snapshot).
>
> Of course such builds have no guarantees, and should not be relied on
> long-term (they may be replaced at any time), but for test purposes
> they will do.
>
> > Niall
> >
> >
> >
> >> --S.
> >>
> >>
> >>
> >> --
> >> View this message in context:
> >>
> http://apache-commons.680414.n4.nabble.com/VOTE-Release-BCEL-6-0-based-on-RC3-tp4667129p4673474.html
> >> Sent from the Commons - Dev mailing list archive at Nabble.com.
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> >> For additional commands, e-mail: dev-help@commons.apache.org
> >>
> >>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
Re: [VOTE] Release BCEL 6.0 based on RC3
Posted by sebb <se...@gmail.com>.
On 12 March 2015 at 01:25, Niall Pemberton <ni...@gmail.com> wrote:
> On Fri, Mar 6, 2015 at 7:42 PM, sarahkm1972 <sa...@gmail.com> wrote:
>
>> +100 to RERO. +1000 to release before we're all dead. It's been a decade
>> people. Just cut a release already. You can always cut another one later.
>> Stop with the excuses
>>
>> Whatever you want to call it - alpha, beta, RC, final, anything. Java 8
>> users are left in a lurch. Compiling libraries is not a realistic solution.
>> As stated previously by others we would also have to patch and compile
>> libraries depending on BCEL and also figure the transitive dependency graph
>> for everything we use since we can't use Maven to do that due to BCEL not
>> being in Maven. This is a huge huge pain because we're big Scala users and
>> rely heavily on the Typesafe ecosystem which is dropping support for Java 7
>> in all of its products and already has in Play Framework and Akka as well
>> as
>> others like its Config library.
>>
>
> You say "stop with the excuses" and then go on to list a whole bunch of
> excuses why its too much effort for you to build BCEL and test it. Yes it
> would be an effort - but it would be invaluable to have some pre-release
> testing and feedback and help to get it our faster.
It's not even necessary to build BCEL in order to test against trunk,
because you can get BCEL snapshots from the Apache Maven Snapshot
repository.
If the CI system is working, the SNAPSHOTs wll be updated regularly
when there have been commits.
If it appears that the snapshot has not been built for some while
since the last commit (e.g. 24 hrs), ask here and someone can prod the
CI system (or just deploy another snapshot).
Of course such builds have no guarantees, and should not be relied on
long-term (they may be replaced at any time), but for test purposes
they will do.
> Niall
>
>
>
>> --S.
>>
>>
>>
>> --
>> View this message in context:
>> http://apache-commons.680414.n4.nabble.com/VOTE-Release-BCEL-6-0-based-on-RC3-tp4667129p4673474.html
>> Sent from the Commons - Dev mailing list archive at Nabble.com.
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [VOTE] Release BCEL 6.0 based on RC3
Posted by Niall Pemberton <ni...@gmail.com>.
On Fri, Mar 6, 2015 at 7:42 PM, sarahkm1972 <sa...@gmail.com> wrote:
> +100 to RERO. +1000 to release before we're all dead. It's been a decade
> people. Just cut a release already. You can always cut another one later.
> Stop with the excuses
>
> Whatever you want to call it - alpha, beta, RC, final, anything. Java 8
> users are left in a lurch. Compiling libraries is not a realistic solution.
> As stated previously by others we would also have to patch and compile
> libraries depending on BCEL and also figure the transitive dependency graph
> for everything we use since we can't use Maven to do that due to BCEL not
> being in Maven. This is a huge huge pain because we're big Scala users and
> rely heavily on the Typesafe ecosystem which is dropping support for Java 7
> in all of its products and already has in Play Framework and Akka as well
> as
> others like its Config library.
>
You say "stop with the excuses" and then go on to list a whole bunch of
excuses why its too much effort for you to build BCEL and test it. Yes it
would be an effort - but it would be invaluable to have some pre-release
testing and feedback and help to get it our faster.
Niall
> --S.
>
>
>
> --
> View this message in context:
> http://apache-commons.680414.n4.nabble.com/VOTE-Release-BCEL-6-0-based-on-RC3-tp4667129p4673474.html
> Sent from the Commons - Dev mailing list archive at Nabble.com.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
Re: [VOTE] Release BCEL 6.0 based on RC3
Posted by Sarah Murray <sa...@gmail.com>.
Thanks for taking the time to review those patches Mark.
I guarantee you that Mark and Jerome do not know that their patches are
considered difficult to review in a timely manner. The last comment on all
of their patches is from them and they're waiting for a response. If the
issues are considered not clear enough and require more explanation, it
would be helpful to let them and the community know that instead of letting
the issues languish. They seem very willing to do some work to get their
patches in. Let them know what an ideal to review patch looks like and how
there's still a lot of burden on the reviewer in the ones they've submitted.
Mark, Jerome, perhaps you could review each others patches? If you agree to
review each others patches, it could help your patches get in much more
quickly. I know it's not fair I ask you to do more work without doing it
myself, but I'm nowhere near familiar enough with the codebase to be of any
help. Perhaps I could offer my assistance in some other way? I can run
tests on various JVMs, write Java code that doesn't require such complex
knowedge of bytecode, or make a monetary donation to the Apache Foundation
if any of those things would help.
Doing what I can, I just took some time to look at 183
<https://issues.apache.org/jira/browse/BCEL-183>. I guess you're right that
the patch could be split between one patch for field name and one patch for
method name if that seems helpful. Would you want me to open new issues
with the patch split in two for that? Should we check with Jerome and
Emmanuel before doing that? What is it that you're thinking we could do in
terms of a common test framework? I don't see a lot of code duplication or
anything.
--S.
On Fri, Mar 6, 2015 at 3:19 PM, Mark Thomas <ma...@apache.org> wrote:
> On 06/03/2015 21:05, Sarah Murray wrote:
> > - 187 <https://issues.apache.org/jira/browse/BCEL-187> - has a test
> > case. no committer review for 2 months
>
> Neither has anyone else reviewed it. It isn't just committers that can
> review patches. I've got the necessary commit karma and after looking at
> that issue for a minute or two I can see a whole pile of work that needs
> to be done before I'd even think about committing anything. Just from
> that quick look:
> 1. Review the svn history to see if there are any pointers to which part
> of the JVM spec defines the restriction.
> 2. Review the JVM spec to see if I can see the restriction
> 3. Look at the byte code for the provided example to see which class the
> invoke opcode references. Better yet, write a disabled BCEL unit test to
> show this.
> 4. The structure of the test case looks odd. I suspect it aligns with
> other patches for other issues but nowhere is that explained.
> 5. The class files provided do not have any attached source. Without the
> source code, we have no idea (OK I could fire up a decompiler but that
> is another task) what is actually in those classes.
>
> To put it another way, the current code asserts one behaviour. The bug
> report asserts another. No evidence is provided to support either
> position. Given that most (all?) the current committers likely to work
> on BCEL don't have a deep knowledge of the JVM specs some research is
> required to figure out which is correct. I've set out above how I'd do
> the research. I'm sure there are other, better approaches. Doing the
> research doesn't require commit karma.
>
> > - 188 <https://issues.apache.org/jira/browse/BCEL-188> - has a test
> > case. no committer review for 2 months
>
> Looks to be in better shape than 187 but still no source provided for
> one of the test classes.
>
> > - 183 <https://issues.apache.org/jira/browse/BCEL-183> - has a test
> > case. no committer review for 3 months
>
> It is not at all clear how much of the original issue (if any) was fixed
> by the change reported 19-Dec-2014.
>
> The potential for the required behaviour to vary with class file version
> is a complicating factor.
>
> This issues seems to be bundling up a number of smaller issues. That
> makes it harder to work with even if they are all in the same area.
>
> Generally for all of these issues some pointers to the relevant parts of
> the JVM spec - preferably as comments in the patch - would make it
> easier for folks to review the patches and easier for future maintainers
> to understand what the code is doing.
>
> Also generally, it looks like a number of the patches could be reduced
> in size by pulling out the common testing framework.
>
>
> > The problem is that there's one area where help is really lacking and the
> > community can't contribute there because not everyone has the commit
> access
> > that's needed to get things flowing again.
>
> I disagree with that analysis. There is plenty that could be done to
> move these issues forwards without commit access. I can find the odd
> hour here and there to look at BCEL issues but looking at the three
> issues you quoted above all of them would require far more than an hours
> work to get to a position where I'd be happy to commit something. Pretty
> much all of that work could be done by anyone on this list.
>
> > Perhaps we could add more committers since it's currently a bottleneck?
>
> Committers will be added as and when folks demonstrate the appropriate
> merit.
>
> > E.g. Mark and Jerome both have submitted numerous high quality patches
> and
> > seem to be well-regarded members of the community. Can we give them
> commit
> > access?
>
> I agree they look to be heading in the right direction. I'm not familiar
> enough with the BCEL code base to judge the quality of the patches in
> their current form.
>
> > If we're nervous about maintaining high code quality we can add
> > guidelines such as there must be a test case for any commit and you can't
> > commit your own code - someone else needs to review it.
>
> You really don't want to introduce those sorts of rules if you can help
> it. It would slow progress even further.
>
> > There was talk of an alpha release and it seems like folks are in favor
> of
> > it. Is there anything I can help to do with regards to that?
>
> Right now the most useful thing folks can do is pick a bug that matters
> to them and then work with the community to get the issue to the point
> where a current committer can resolve it with no more than 60 minutes of
> effort.
>
> I can find 60 minutes over the next few days. Which issue do you want to
> fix first?
>
> I'm also more than happy to commit common test code to reduce the
> size/complexity of any proposed patches.
>
> Mark
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
Re: [VOTE] Release BCEL 6.0 based on RC3
Posted by Mark Thomas <ma...@apache.org>.
On 06/03/2015 21:05, Sarah Murray wrote:
> - 187 <https://issues.apache.org/jira/browse/BCEL-187> - has a test
> case. no committer review for 2 months
Neither has anyone else reviewed it. It isn't just committers that can
review patches. I've got the necessary commit karma and after looking at
that issue for a minute or two I can see a whole pile of work that needs
to be done before I'd even think about committing anything. Just from
that quick look:
1. Review the svn history to see if there are any pointers to which part
of the JVM spec defines the restriction.
2. Review the JVM spec to see if I can see the restriction
3. Look at the byte code for the provided example to see which class the
invoke opcode references. Better yet, write a disabled BCEL unit test to
show this.
4. The structure of the test case looks odd. I suspect it aligns with
other patches for other issues but nowhere is that explained.
5. The class files provided do not have any attached source. Without the
source code, we have no idea (OK I could fire up a decompiler but that
is another task) what is actually in those classes.
To put it another way, the current code asserts one behaviour. The bug
report asserts another. No evidence is provided to support either
position. Given that most (all?) the current committers likely to work
on BCEL don't have a deep knowledge of the JVM specs some research is
required to figure out which is correct. I've set out above how I'd do
the research. I'm sure there are other, better approaches. Doing the
research doesn't require commit karma.
> - 188 <https://issues.apache.org/jira/browse/BCEL-188> - has a test
> case. no committer review for 2 months
Looks to be in better shape than 187 but still no source provided for
one of the test classes.
> - 183 <https://issues.apache.org/jira/browse/BCEL-183> - has a test
> case. no committer review for 3 months
It is not at all clear how much of the original issue (if any) was fixed
by the change reported 19-Dec-2014.
The potential for the required behaviour to vary with class file version
is a complicating factor.
This issues seems to be bundling up a number of smaller issues. That
makes it harder to work with even if they are all in the same area.
Generally for all of these issues some pointers to the relevant parts of
the JVM spec - preferably as comments in the patch - would make it
easier for folks to review the patches and easier for future maintainers
to understand what the code is doing.
Also generally, it looks like a number of the patches could be reduced
in size by pulling out the common testing framework.
> The problem is that there's one area where help is really lacking and the
> community can't contribute there because not everyone has the commit access
> that's needed to get things flowing again.
I disagree with that analysis. There is plenty that could be done to
move these issues forwards without commit access. I can find the odd
hour here and there to look at BCEL issues but looking at the three
issues you quoted above all of them would require far more than an hours
work to get to a position where I'd be happy to commit something. Pretty
much all of that work could be done by anyone on this list.
> Perhaps we could add more committers since it's currently a bottleneck?
Committers will be added as and when folks demonstrate the appropriate
merit.
> E.g. Mark and Jerome both have submitted numerous high quality patches and
> seem to be well-regarded members of the community. Can we give them commit
> access?
I agree they look to be heading in the right direction. I'm not familiar
enough with the BCEL code base to judge the quality of the patches in
their current form.
> If we're nervous about maintaining high code quality we can add
> guidelines such as there must be a test case for any commit and you can't
> commit your own code - someone else needs to review it.
You really don't want to introduce those sorts of rules if you can help
it. It would slow progress even further.
> There was talk of an alpha release and it seems like folks are in favor of
> it. Is there anything I can help to do with regards to that?
Right now the most useful thing folks can do is pick a bug that matters
to them and then work with the community to get the issue to the point
where a current committer can resolve it with no more than 60 minutes of
effort.
I can find 60 minutes over the next few days. Which issue do you want to
fix first?
I'm also more than happy to commit common test code to reduce the
size/complexity of any proposed patches.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [VOTE] Release BCEL 6.0 based on RC3
Posted by Sarah Murray <sa...@gmail.com>.
Sorry for the frustration I expressed. It was probably not the most
constructive way to voice my opinion.
A well described bug with a patch and a test case tends to get committed very
> quickly.
I'm not sure you've looked at the issue tracker lately. This really isn't
true as far as I can see, which is the cause of my exasperation. We're
blocking on a release until issues are resolved. But no one with commit
access is accepting changes, so we've just stalled out.
If you think some of the BCEL bugs are in this state and being over looked
> feel free to add a "What else is needed to get this committed?" question
> on the bug.
I'm happy to do this, but I think it'd be more annoying than helpful. Most
BCEL bugs I've seen are in this state. Putting the same comment on every
bug doesn't seem helpful. Of the four issues marked to 6.0, three of them
are stalled on having someone review and commit the patches:
- 187 <https://issues.apache.org/jira/browse/BCEL-187> - has a test
case. no committer review for 2 months
- 188 <https://issues.apache.org/jira/browse/BCEL-188> - has a test
case. no committer review for 2 months
- 183 <https://issues.apache.org/jira/browse/BCEL-183> - has a test
case. no committer review for 3 months
We don't have suppliers and customers at the ASF. We have a community. Everyone
> has a part to play.
The problem is that there's one area where help is really lacking and the
community can't contribute there because not everyone has the commit access
that's needed to get things flowing again. Perhaps we could add more
committers since it's currently a bottleneck? I've seen that work really
well when other projects either start to get overwhelmed or fizzle out.
E.g. Mark and Jerome both have submitted numerous high quality patches and
seem to be well-regarded members of the community. Can we give them commit
access? If we're nervous about maintaining high code quality we can add
guidelines such as there must be a test case for any commit and you can't
commit your own code - someone else needs to review it.
There was talk of an alpha release and it seems like folks are in favor of
it. Is there anything I can help to do with regards to that?
--S.
On Fri, Mar 6, 2015 at 12:10 PM, Mark Thomas <ma...@apache.org> wrote:
> All,
>
> This is a community of volunteers. If you want to see something happen,
> demanding that other people do something is not the way to achieve your
> aims. At best your demands will have no impact. At worst, they will
> irritate folks that might have otherwise done the very thing you want to
> see happen.
>
> If you want to see a BCEL release then the best thing you can do is
> pitch in and help. Jira shows 49 open BCEL issues 4 of which are tagged
> for 6.0.
>
> Take a look at those 4 issues. What needs to be done to resolve them? Is
> a patch required? Is a review required? Would a test case that
> demonstrates the issue help (answer "yes!" unless one already exists).
>
> A well described bug with a patch and a test case tends to get committed
> very quickly. If you think some of the BCEL bugs are in this state and
> being over looked feel free to add a "What else is needed to get this
> committed?" question on the bug.
>
> Of the other 45 issues which ones need to be fixed in 6.0? 6.x? 7.0? I'd
> me amazed if all of those 45 were valid. Which ones can be closed? If
> you need versions created in Jira, ask. If you need more karma to assign
> issues to versions, ask. If you aren't sure what criteria should be used
> to decide which version to assign issues to, ask. Better still propose
> some criteria to start the discussion.
>
> We don't have suppliers and customers at the ASF. We have a community.
> Everyone has a part to play.
>
> Mark
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
Re: [VOTE] Release BCEL 6.0 based on RC3
Posted by Mark Thomas <ma...@apache.org>.
All,
This is a community of volunteers. If you want to see something happen,
demanding that other people do something is not the way to achieve your
aims. At best your demands will have no impact. At worst, they will
irritate folks that might have otherwise done the very thing you want to
see happen.
If you want to see a BCEL release then the best thing you can do is
pitch in and help. Jira shows 49 open BCEL issues 4 of which are tagged
for 6.0.
Take a look at those 4 issues. What needs to be done to resolve them? Is
a patch required? Is a review required? Would a test case that
demonstrates the issue help (answer "yes!" unless one already exists).
A well described bug with a patch and a test case tends to get committed
very quickly. If you think some of the BCEL bugs are in this state and
being over looked feel free to add a "What else is needed to get this
committed?" question on the bug.
Of the other 45 issues which ones need to be fixed in 6.0? 6.x? 7.0? I'd
me amazed if all of those 45 were valid. Which ones can be closed? If
you need versions created in Jira, ask. If you need more karma to assign
issues to versions, ask. If you aren't sure what criteria should be used
to decide which version to assign issues to, ask. Better still propose
some criteria to start the discussion.
We don't have suppliers and customers at the ASF. We have a community.
Everyone has a part to play.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [VOTE] Release BCEL 6.0 based on RC3
Posted by sarahkm1972 <sa...@gmail.com>.
+100 to RERO. +1000 to release before we're all dead. It's been a decade
people. Just cut a release already. You can always cut another one later.
Stop with the excuses
Whatever you want to call it - alpha, beta, RC, final, anything. Java 8
users are left in a lurch. Compiling libraries is not a realistic solution.
As stated previously by others we would also have to patch and compile
libraries depending on BCEL and also figure the transitive dependency graph
for everything we use since we can't use Maven to do that due to BCEL not
being in Maven. This is a huge huge pain because we're big Scala users and
rely heavily on the Typesafe ecosystem which is dropping support for Java 7
in all of its products and already has in Play Framework and Akka as well as
others like its Config library.
--S.
--
View this message in context: http://apache-commons.680414.n4.nabble.com/VOTE-Release-BCEL-6-0-based-on-RC3-tp4667129p4673474.html
Sent from the Commons - Dev mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [VOTE] Release BCEL 6.0 based on RC3
Posted by Ian McAllister <ia...@gmail.com>.
Do you have ideas for when an alpha release will be pushed to Maven?
ian
On Thu, Mar 5, 2015 at 11:09 AM, Ben McCann <be...@benmccann.com> wrote:
> I'd much rather an imperfect version of BCEL be released than we continue
> to wait for perfection and never release. I'm very concerned that we're
> going to be waiting at least a year for the 6.0 release. Mark submitted
> about a dozen issues around six weeks ago and probably only one or two have
> been closed. At the current rate it will be a year before they're all
> addressed. And who's to say that no new issues will be filed in the next
> year pushing the release ever further out?
>
> We could easily release 6.0 now, which we've been on the verge of doing.
> There were 3 RCs for it and it's been 7 months since voting on the first
> RC. In a year when all of Mark's issues are addressed we can release 7.0.
> Changing package names again in another year doesn't seem so bad. It's an
> easy sed script to update your code to a new package name. If we don't cut
> a release then no released version of BCEL will work with any supported
> version of Java.
>
> -Ben
>
>
>
> On Wed, Mar 4, 2015 at 10:13 AM, Ian McAllister <ia...@gmail.com>
> wrote:
>
> > quick follow up on this... were you by chance able to create an alpha
> > release yet? very much looking forward to having the code in maven!!
> >
> > ian
> >
> > On Mon, Mar 2, 2015 at 3:11 PM, ianmca86 <ia...@gmail.com> wrote:
> >
> > > yes, that would be perfect! (agreed it would have to go to maven)
> > >
> > > thanks so much for taking the suggestion into consideration!
> > >
> > > -ian
> > >
> > >
> > > On Mon, Mar 2, 2015 at 3:08 PM, Emmanuel Bourg-3 [via Apache Commons] <
> > > ml-node+s680414n4673398h70@n4.nabble.com> wrote:
> > >
> > > > Le 03/03/2015 00:03, Gary Gregory a écrit :
> > > > > We could release an Alpha to make it clear that we are still
> working
> > on
> > > > > possibly important changes.
> > > >
> > > > But we would have to upload it to Maven Central to make it really
> > > > useful. If there is a consensus to do that I'm ok to cut a release
> > soon.
> > > >
> > > > Emmanuel Bourg
> > > >
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: [hidden email]
> > > > <http:///user/SendEmail.jtp?type=node&node=4673398&i=0>
> > > > For additional commands, e-mail: [hidden email]
> > > > <http:///user/SendEmail.jtp?type=node&node=4673398&i=1>
> > > >
> > > >
> > > >
> > > > ------------------------------
> > > > If you reply to this email, your message will be added to the
> > discussion
> > > > below:
> > > >
> > > >
> > >
> >
> http://apache-commons.680414.n4.nabble.com/VOTE-Release-BCEL-6-0-based-on-RC3-tp4667129p4673398.html
> > > > To unsubscribe from [VOTE] Release BCEL 6.0 based on RC3, click here
> > > > <
> > >
> >
> http://apache-commons.680414.n4.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=4667129&code=aWFubWNhODZAZ21haWwuY29tfDQ2NjcxMjl8NTMyODIwMzEy
> > > >
> > > > .
> > > > NAML
> > > > <
> > >
> >
> http://apache-commons.680414.n4.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml
> > > >
> > > >
> > >
> > >
> > >
> > >
> > > --
> > > View this message in context:
> > >
> >
> http://apache-commons.680414.n4.nabble.com/VOTE-Release-BCEL-6-0-based-on-RC3-tp4667129p4673399.html
> > > Sent from the Commons - Dev mailing list archive at Nabble.com.
> > >
> >
>
>
>
> --
> about.me/benmccann
>
Re: [VOTE] Release BCEL 6.0 based on RC3
Posted by Ben McCann <be...@benmccann.com>.
I'd much rather an imperfect version of BCEL be released than we continue
to wait for perfection and never release. I'm very concerned that we're
going to be waiting at least a year for the 6.0 release. Mark submitted
about a dozen issues around six weeks ago and probably only one or two have
been closed. At the current rate it will be a year before they're all
addressed. And who's to say that no new issues will be filed in the next
year pushing the release ever further out?
We could easily release 6.0 now, which we've been on the verge of doing.
There were 3 RCs for it and it's been 7 months since voting on the first
RC. In a year when all of Mark's issues are addressed we can release 7.0.
Changing package names again in another year doesn't seem so bad. It's an
easy sed script to update your code to a new package name. If we don't cut
a release then no released version of BCEL will work with any supported
version of Java.
-Ben
On Wed, Mar 4, 2015 at 10:13 AM, Ian McAllister <ia...@gmail.com> wrote:
> quick follow up on this... were you by chance able to create an alpha
> release yet? very much looking forward to having the code in maven!!
>
> ian
>
> On Mon, Mar 2, 2015 at 3:11 PM, ianmca86 <ia...@gmail.com> wrote:
>
> > yes, that would be perfect! (agreed it would have to go to maven)
> >
> > thanks so much for taking the suggestion into consideration!
> >
> > -ian
> >
> >
> > On Mon, Mar 2, 2015 at 3:08 PM, Emmanuel Bourg-3 [via Apache Commons] <
> > ml-node+s680414n4673398h70@n4.nabble.com> wrote:
> >
> > > Le 03/03/2015 00:03, Gary Gregory a écrit :
> > > > We could release an Alpha to make it clear that we are still working
> on
> > > > possibly important changes.
> > >
> > > But we would have to upload it to Maven Central to make it really
> > > useful. If there is a consensus to do that I'm ok to cut a release
> soon.
> > >
> > > Emmanuel Bourg
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: [hidden email]
> > > <http:///user/SendEmail.jtp?type=node&node=4673398&i=0>
> > > For additional commands, e-mail: [hidden email]
> > > <http:///user/SendEmail.jtp?type=node&node=4673398&i=1>
> > >
> > >
> > >
> > > ------------------------------
> > > If you reply to this email, your message will be added to the
> discussion
> > > below:
> > >
> > >
> >
> http://apache-commons.680414.n4.nabble.com/VOTE-Release-BCEL-6-0-based-on-RC3-tp4667129p4673398.html
> > > To unsubscribe from [VOTE] Release BCEL 6.0 based on RC3, click here
> > > <
> >
> http://apache-commons.680414.n4.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=4667129&code=aWFubWNhODZAZ21haWwuY29tfDQ2NjcxMjl8NTMyODIwMzEy
> > >
> > > .
> > > NAML
> > > <
> >
> http://apache-commons.680414.n4.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml
> > >
> > >
> >
> >
> >
> >
> > --
> > View this message in context:
> >
> http://apache-commons.680414.n4.nabble.com/VOTE-Release-BCEL-6-0-based-on-RC3-tp4667129p4673399.html
> > Sent from the Commons - Dev mailing list archive at Nabble.com.
> >
>
--
about.me/benmccann
Re: [VOTE] Release BCEL 6.0 based on RC3
Posted by Ian McAllister <ia...@gmail.com>.
quick follow up on this... were you by chance able to create an alpha
release yet? very much looking forward to having the code in maven!!
ian
On Mon, Mar 2, 2015 at 3:11 PM, ianmca86 <ia...@gmail.com> wrote:
> yes, that would be perfect! (agreed it would have to go to maven)
>
> thanks so much for taking the suggestion into consideration!
>
> -ian
>
>
> On Mon, Mar 2, 2015 at 3:08 PM, Emmanuel Bourg-3 [via Apache Commons] <
> ml-node+s680414n4673398h70@n4.nabble.com> wrote:
>
> > Le 03/03/2015 00:03, Gary Gregory a écrit :
> > > We could release an Alpha to make it clear that we are still working on
> > > possibly important changes.
> >
> > But we would have to upload it to Maven Central to make it really
> > useful. If there is a consensus to do that I'm ok to cut a release soon.
> >
> > Emmanuel Bourg
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [hidden email]
> > <http:///user/SendEmail.jtp?type=node&node=4673398&i=0>
> > For additional commands, e-mail: [hidden email]
> > <http:///user/SendEmail.jtp?type=node&node=4673398&i=1>
> >
> >
> >
> > ------------------------------
> > If you reply to this email, your message will be added to the discussion
> > below:
> >
> >
> http://apache-commons.680414.n4.nabble.com/VOTE-Release-BCEL-6-0-based-on-RC3-tp4667129p4673398.html
> > To unsubscribe from [VOTE] Release BCEL 6.0 based on RC3, click here
> > <
> http://apache-commons.680414.n4.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=4667129&code=aWFubWNhODZAZ21haWwuY29tfDQ2NjcxMjl8NTMyODIwMzEy
> >
> > .
> > NAML
> > <
> http://apache-commons.680414.n4.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml
> >
> >
>
>
>
>
> --
> View this message in context:
> http://apache-commons.680414.n4.nabble.com/VOTE-Release-BCEL-6-0-based-on-RC3-tp4667129p4673399.html
> Sent from the Commons - Dev mailing list archive at Nabble.com.
>
Re: [VOTE] Release BCEL 6.0 based on RC3
Posted by ianmca86 <ia...@gmail.com>.
yes, that would be perfect! (agreed it would have to go to maven)
thanks so much for taking the suggestion into consideration!
-ian
On Mon, Mar 2, 2015 at 3:08 PM, Emmanuel Bourg-3 [via Apache Commons] <
ml-node+s680414n4673398h70@n4.nabble.com> wrote:
> Le 03/03/2015 00:03, Gary Gregory a écrit :
> > We could release an Alpha to make it clear that we are still working on
> > possibly important changes.
>
> But we would have to upload it to Maven Central to make it really
> useful. If there is a consensus to do that I'm ok to cut a release soon.
>
> Emmanuel Bourg
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> <http:///user/SendEmail.jtp?type=node&node=4673398&i=0>
> For additional commands, e-mail: [hidden email]
> <http:///user/SendEmail.jtp?type=node&node=4673398&i=1>
>
>
>
> ------------------------------
> If you reply to this email, your message will be added to the discussion
> below:
>
> http://apache-commons.680414.n4.nabble.com/VOTE-Release-BCEL-6-0-based-on-RC3-tp4667129p4673398.html
> To unsubscribe from [VOTE] Release BCEL 6.0 based on RC3, click here
> <http://apache-commons.680414.n4.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=4667129&code=aWFubWNhODZAZ21haWwuY29tfDQ2NjcxMjl8NTMyODIwMzEy>
> .
> NAML
> <http://apache-commons.680414.n4.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>
>
--
View this message in context: http://apache-commons.680414.n4.nabble.com/VOTE-Release-BCEL-6-0-based-on-RC3-tp4667129p4673399.html
Sent from the Commons - Dev mailing list archive at Nabble.com.
Re: [VOTE] Release BCEL 6.0 based on RC3
Posted by Emmanuel Bourg <eb...@apache.org>.
Le 03/03/2015 00:03, Gary Gregory a écrit :
> We could release an Alpha to make it clear that we are still working on
> possibly important changes.
But we would have to upload it to Maven Central to make it really
useful. If there is a consensus to do that I'm ok to cut a release soon.
Emmanuel Bourg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [VOTE] Release BCEL 6.0 based on RC3
Posted by Ben McCann <be...@benmccann.com>.
+1 to releasing an Alpha or making 6.0-RC3 available via Maven. Compiling
it ourselves is a really painful solution. It means we also need to setup
our own public Maven repository or make other drastic changes to our
release engineering.
On Mon, Mar 2, 2015 at 3:03 PM, Gary Gregory <ga...@gmail.com> wrote:
> We could release an Alpha to make it clear that we are still working on
> possibly important changes.
>
> G
>
> On Mon, Mar 2, 2015 at 2:46 PM, ianmca86 <ia...@gmail.com> wrote:
>
> > Perhaps we could at least get a milestone release (i.e. pre-RC)? I'd
> like
> > to see if I can submit a branch to jibx where I get them to use the
> latest
> > bcel code. jibx won't work with Java 8 because we're waiting on a bcel
> > release. It's hard to work on making jibx compatible with Java 8 as long
> as
> > we're blocked on bcel, but if there were a milestone or rc release that
> > would allow us to get some work done towards this goal and also help test
> > the past nine years of changes to unearth any possible bcel problems
> >
> > On Mon, Mar 2, 2015 at 2:37 PM, Emmanuel Bourg-3 [via Apache Commons] <
> > ml-node+s680414n4673392h84@n4.nabble.com> wrote:
> >
> > > Le 02/03/2015 22:33, Gary Gregory a écrit :
> > > > I'm all for RERO if the release manager is willing.
> > >
> > > I tend to agree with RERO, but if the API is not ready I don't think
> > > it's right to rush into a release, and the deeper I dig into BCEL the
> > > more I'm bothered by the issues I find.
> > >
> > > Once BCEL is back in shape it'll be easier to release often.
> > >
> > > Emmanuel Bourg
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: [hidden email]
> > > <http:///user/SendEmail.jtp?type=node&node=4673392&i=0>
> > > For additional commands, e-mail: [hidden email]
> > > <http:///user/SendEmail.jtp?type=node&node=4673392&i=1>
> > >
> > >
> > >
> > > ------------------------------
> > > If you reply to this email, your message will be added to the
> discussion
> > > below:
> > >
> > >
> >
> http://apache-commons.680414.n4.nabble.com/VOTE-Release-BCEL-6-0-based-on-RC3-tp4667129p4673392.html
> > > To unsubscribe from [VOTE] Release BCEL 6.0 based on RC3, click here
> > > <
> >
> http://apache-commons.680414.n4.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=4667129&code=aWFubWNhODZAZ21haWwuY29tfDQ2NjcxMjl8NTMyODIwMzEy
> > >
> > > .
> > > NAML
> > > <
> >
> http://apache-commons.680414.n4.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml
> > >
> > >
> >
> >
> >
> >
> > --
> > View this message in context:
> >
> http://apache-commons.680414.n4.nabble.com/VOTE-Release-BCEL-6-0-based-on-RC3-tp4667129p4673393.html
> > Sent from the Commons - Dev mailing list archive at Nabble.com.
>
>
>
>
> --
> 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
>
--
about.me/benmccann
Re: [VOTE] Release BCEL 6.0 based on RC3
Posted by Gary Gregory <ga...@gmail.com>.
We could release an Alpha to make it clear that we are still working on
possibly important changes.
G
On Mon, Mar 2, 2015 at 2:46 PM, ianmca86 <ia...@gmail.com> wrote:
> Perhaps we could at least get a milestone release (i.e. pre-RC)? I'd like
> to see if I can submit a branch to jibx where I get them to use the latest
> bcel code. jibx won't work with Java 8 because we're waiting on a bcel
> release. It's hard to work on making jibx compatible with Java 8 as long as
> we're blocked on bcel, but if there were a milestone or rc release that
> would allow us to get some work done towards this goal and also help test
> the past nine years of changes to unearth any possible bcel problems
>
> On Mon, Mar 2, 2015 at 2:37 PM, Emmanuel Bourg-3 [via Apache Commons] <
> ml-node+s680414n4673392h84@n4.nabble.com> wrote:
>
> > Le 02/03/2015 22:33, Gary Gregory a écrit :
> > > I'm all for RERO if the release manager is willing.
> >
> > I tend to agree with RERO, but if the API is not ready I don't think
> > it's right to rush into a release, and the deeper I dig into BCEL the
> > more I'm bothered by the issues I find.
> >
> > Once BCEL is back in shape it'll be easier to release often.
> >
> > Emmanuel Bourg
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [hidden email]
> > <http:///user/SendEmail.jtp?type=node&node=4673392&i=0>
> > For additional commands, e-mail: [hidden email]
> > <http:///user/SendEmail.jtp?type=node&node=4673392&i=1>
> >
> >
> >
> > ------------------------------
> > If you reply to this email, your message will be added to the discussion
> > below:
> >
> >
> http://apache-commons.680414.n4.nabble.com/VOTE-Release-BCEL-6-0-based-on-RC3-tp4667129p4673392.html
> > To unsubscribe from [VOTE] Release BCEL 6.0 based on RC3, click here
> > <
> http://apache-commons.680414.n4.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=4667129&code=aWFubWNhODZAZ21haWwuY29tfDQ2NjcxMjl8NTMyODIwMzEy
> >
> > .
> > NAML
> > <
> http://apache-commons.680414.n4.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml
> >
> >
>
>
>
>
> --
> View this message in context:
> http://apache-commons.680414.n4.nabble.com/VOTE-Release-BCEL-6-0-based-on-RC3-tp4667129p4673393.html
> Sent from the Commons - Dev mailing list archive at Nabble.com.
--
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
Re: [VOTE] Release BCEL 6.0 based on RC3
Posted by ianmca86 <ia...@gmail.com>.
Perhaps we could at least get a milestone release (i.e. pre-RC)? I'd like
to see if I can submit a branch to jibx where I get them to use the latest
bcel code. jibx won't work with Java 8 because we're waiting on a bcel
release. It's hard to work on making jibx compatible with Java 8 as long as
we're blocked on bcel, but if there were a milestone or rc release that
would allow us to get some work done towards this goal and also help test
the past nine years of changes to unearth any possible bcel problems
On Mon, Mar 2, 2015 at 2:37 PM, Emmanuel Bourg-3 [via Apache Commons] <
ml-node+s680414n4673392h84@n4.nabble.com> wrote:
> Le 02/03/2015 22:33, Gary Gregory a écrit :
> > I'm all for RERO if the release manager is willing.
>
> I tend to agree with RERO, but if the API is not ready I don't think
> it's right to rush into a release, and the deeper I dig into BCEL the
> more I'm bothered by the issues I find.
>
> Once BCEL is back in shape it'll be easier to release often.
>
> Emmanuel Bourg
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> <http:///user/SendEmail.jtp?type=node&node=4673392&i=0>
> For additional commands, e-mail: [hidden email]
> <http:///user/SendEmail.jtp?type=node&node=4673392&i=1>
>
>
>
> ------------------------------
> If you reply to this email, your message will be added to the discussion
> below:
>
> http://apache-commons.680414.n4.nabble.com/VOTE-Release-BCEL-6-0-based-on-RC3-tp4667129p4673392.html
> To unsubscribe from [VOTE] Release BCEL 6.0 based on RC3, click here
> <http://apache-commons.680414.n4.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=4667129&code=aWFubWNhODZAZ21haWwuY29tfDQ2NjcxMjl8NTMyODIwMzEy>
> .
> NAML
> <http://apache-commons.680414.n4.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>
>
--
View this message in context: http://apache-commons.680414.n4.nabble.com/VOTE-Release-BCEL-6-0-based-on-RC3-tp4667129p4673393.html
Sent from the Commons - Dev mailing list archive at Nabble.com.
Re: [VOTE] Release BCEL 6.0 based on RC3
Posted by Gary Gregory <ga...@gmail.com>.
On Mon, Mar 2, 2015 at 2:44 PM, Emmanuel Bourg <eb...@apache.org> wrote:
> Le 02/03/2015 22:33, Gary Gregory a écrit :
> > I'm all for RERO if the release manager is willing.
>
> I tend to agree with RERO, but if the API is not ready I don't think
> it's right to rush into a release, and the deeper I dig into BCEL the
> more I'm bothered by the issues I find.
>
> Once BCEL is back in shape it'll be easier to release often.
>
I, for one, am grateful you are keeping a close eye on this. Thank you!
Gary
>
> Emmanuel Bourg
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
--
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
Re: [VOTE] Release BCEL 6.0 based on RC3
Posted by Emmanuel Bourg <eb...@apache.org>.
Le 02/03/2015 22:33, Gary Gregory a écrit :
> I'm all for RERO if the release manager is willing.
I tend to agree with RERO, but if the API is not ready I don't think
it's right to rush into a release, and the deeper I dig into BCEL the
more I'm bothered by the issues I find.
Once BCEL is back in shape it'll be easier to release often.
Emmanuel Bourg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [VOTE] Release BCEL 6.0 based on RC3
Posted by Gary Gregory <ga...@gmail.com>.
On Mon, Mar 2, 2015 at 2:07 PM, sebb <se...@gmail.com> wrote:
> On 2 March 2015 at 21:33, Gary Gregory <ga...@gmail.com> wrote:
> > I'm all for RERO if the release manager is willing.
>
> RM willingness is only part of it.
>
> RERO is all very well if:
> - the API is stable; or
> - frequent changes of package name/Maven coords are acceptable to
> consumers; or
> - one does not care about binary compatibilty
>
> IMO it's unhelpful to keep pushing the RERO mantra in isolation.
>
Yes, agreed. I was assuming we all see eye to eye on the semantics.
Gary
>
> > Gary
> >
> > On Mon, Mar 2, 2015 at 12:37 PM, ianmca86 <ia...@gmail.com> wrote:
> >
> >> +1
> >>
> >> no one has really answered ben's question yet. if bcel 209
> >> <https://issues.apache.org/jira/browse/BCEL-209> is committed could
> we
> >> cut
> >> a release? it seems like everyone is okay with the general approach
> taken
> >> there
> >>
> >> my company also is mandating all projects move to java 8 this month
> since
> >> java 7 is discontinued next month. i'm quite nervous that patch has been
> >> outstanding for a month already and we're blocking on it. nine years is
> too
> >> long between releases and we don't need to drag this out more
> >>
> >> regards
> >> ian
> >>
> >>
> >>
> >> --
> >> View this message in context:
> >>
> http://apache-commons.680414.n4.nabble.com/VOTE-Release-BCEL-6-0-based-on-RC3-tp4667129p4673380.html
> >> Sent from the Commons - Dev mailing list archive at Nabble.com.
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> >> For additional commands, e-mail: dev-help@commons.apache.org
> >>
> >>
> >
> >
> > --
> > 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
>
>
--
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
Re: [VOTE] Release BCEL 6.0 based on RC3
Posted by sebb <se...@gmail.com>.
On 2 March 2015 at 21:33, Gary Gregory <ga...@gmail.com> wrote:
> I'm all for RERO if the release manager is willing.
RM willingness is only part of it.
RERO is all very well if:
- the API is stable; or
- frequent changes of package name/Maven coords are acceptable to consumers; or
- one does not care about binary compatibilty
IMO it's unhelpful to keep pushing the RERO mantra in isolation.
> Gary
>
> On Mon, Mar 2, 2015 at 12:37 PM, ianmca86 <ia...@gmail.com> wrote:
>
>> +1
>>
>> no one has really answered ben's question yet. if bcel 209
>> <https://issues.apache.org/jira/browse/BCEL-209> is committed could we
>> cut
>> a release? it seems like everyone is okay with the general approach taken
>> there
>>
>> my company also is mandating all projects move to java 8 this month since
>> java 7 is discontinued next month. i'm quite nervous that patch has been
>> outstanding for a month already and we're blocking on it. nine years is too
>> long between releases and we don't need to drag this out more
>>
>> regards
>> ian
>>
>>
>>
>> --
>> View this message in context:
>> http://apache-commons.680414.n4.nabble.com/VOTE-Release-BCEL-6-0-based-on-RC3-tp4667129p4673380.html
>> Sent from the Commons - Dev mailing list archive at Nabble.com.
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>
>
> --
> 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
Re: [VOTE] Release BCEL 6.0 based on RC3
Posted by Gary Gregory <ga...@gmail.com>.
I'm all for RERO if the release manager is willing.
Gary
On Mon, Mar 2, 2015 at 12:37 PM, ianmca86 <ia...@gmail.com> wrote:
> +1
>
> no one has really answered ben's question yet. if bcel 209
> <https://issues.apache.org/jira/browse/BCEL-209> is committed could we
> cut
> a release? it seems like everyone is okay with the general approach taken
> there
>
> my company also is mandating all projects move to java 8 this month since
> java 7 is discontinued next month. i'm quite nervous that patch has been
> outstanding for a month already and we're blocking on it. nine years is too
> long between releases and we don't need to drag this out more
>
> regards
> ian
>
>
>
> --
> View this message in context:
> http://apache-commons.680414.n4.nabble.com/VOTE-Release-BCEL-6-0-based-on-RC3-tp4667129p4673380.html
> Sent from the Commons - Dev mailing list archive at Nabble.com.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
--
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