date:20160602

Apache Commons BeanUtils 1.9.3 RC1 is available for review here:

https://dist.apache.org/repos/dist/dev/commons/beanutils/
(revision 13874)

commons-beanutils-1.9.3-bin.tar.gz
(SHA1: 5c66783bb2bce21992cc3515a7b78f36f17c8709)
commons-beanutils-1.9.3-bin.zip
(SHA1: 3508ced3e244bc1583f6f4be119f50fe4fd162b3)
commons-beanutils-1.9.3-src.tar.gz
(SHA1: 51879c555ae045f2c09a24eb69a68b6af0544c06)
commons-beanutils-1.9.3-src.zip
(SHA1: 0a16325c44dfee1a29e1e6788115930acbb13313)

Maven artifacts are here:

https://repository.apache.org/content/repositories/orgapachecommons-1176/commons-beanutils/commons-beanutils/1.9.3/

These are the artifacts and their hashes:

commons-beanutils-1.9.3-test-sources.jar
(SHA1: 5365ebf268504d69941c21007a2c0a1334589e8f)
commons-beanutils-1.9.3-sources.jar
(SHA1: 53bae8809672897cb9954669775fb214623c6b89)
commons-beanutils-1.9.3.pom
(SHA1: dbedbbc25b2a981a7598f647100092ce5cb28a55)
commons-beanutils-1.9.3.jar
(SHA1: 15f7207f3ccfb6aa607eb93414723bf8a0c9297c)
commons-beanutils-1.9.3-javadoc.jar
(SHA1:71f2729e5b5bc5f969233c190c105607f55859bf)
commons-beanutils-1.9.3-tests.jar
(SHA1: 3c0a8818f23da165b6e825874c3287e1cbec403b)

Details of changes since 1.9.2 are in the release notes:

https://dist.apache.org/repos/dist/dev/commons/beanutils/RELEASE-NOTES.txttxt
http://home.apache.org/~ggregory/beanutils-1.9.3-rc1/site/changes-report.html


The tag is here:
https://svn.apache.org/repos/asf/commons/proper/beanutils/tags/beanutils-1.9.3-RC1/
(revision 1745420)

Site:
http://home.apache.org/~ggregory/beanutils-1.9.3-rc1/site/

(some *relative* links are broken - these will be OK once the site
is deployed)

Clirr Report (compared to 1.9.2):
http://home.apache.org/~ggregory/beanutils-1.9.3-rc1/site/clirr-report.html

RAT Report:
http://home.apache.org/~ggregory/beanutils-1.9.3-rc1/site/rat-report.html

KEYS:
https://www.apache.org/dist/commons/KEYS

Please review the release candidate and vote.

This vote will close no sooner than 72 hours from now, i.e. sometime after
18:00 PST 5 June 2016


[ ] +1 Release these artifacts
[ ] +0 OK, but...
[ ] -0 OK, but really should fix...
[ ] -1 I oppose this release because...

Thanks!
Gary Gregory


-- 
E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
Java Persistence with Hibernate, Second Edition

JUnit in Action, Second Edition 
Spring Batch in Action 
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory

[GitHub] commons-io pull request #12: Update BoundedReader.java

2016-06-02 Thread zhanhb

Github user zhanhb closed the pull request at:

https://github.com/apache/commons-io/pull/12


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: svn commit: r1746655 - /commons/proper/beanutils/tags/beanutils-1.9.3-RC1/

bleharch! Or ack! (Like the cat in Bloom County).

I am reducing my headache factor by following
https://commons.apache.org/releases/prepare.html

Gary

On Thu, Jun 2, 2016 at 4:10 PM, Benedikt Ritter 
wrote:

> The other tags are all upper case with underscore.
>  schrieb am Fr., 3. Juni 2016 um 01:07:
>
> > Author: ggregory
> > Date: Thu Jun  2 23:07:29 2016
> > New Revision: 1746655
> >
> > URL: http://svn.apache.org/viewvc?rev=1746655&view=rev
> > Log:
> > Creating beanutils-1.9.3-RC1 tag
> >
> > Added:
> > commons/proper/beanutils/tags/beanutils-1.9.3-RC1/   (props changed)
> >   - copied from r1746654, commons/proper/beanutils/trunk/
> >
> > Propchange: commons/proper/beanutils/tags/beanutils-1.9.3-RC1/
> >
> >
> --
> > --- svn:ignore (added)
> > +++ svn:ignore Thu Jun  2 23:07:29 2016
> > @@ -0,0 +1,14 @@
> > +build.properties
> > +dist
> > +target
> > +beanutils.ipr
> > +maven.log
> > +velocity.log
> > +.classpath
> > +.project
> > +.settings
> > +.externalToolBuilders
> > +maven-eclipse.xml
> > +.pmd
> > +.idea
> > +*.iml
> >
> > Propchange: commons/proper/beanutils/tags/beanutils-1.9.3-RC1/
> >
> >
> --
> > svn:mergeinfo =
> > /commons/proper/beanutils/branches/java5:1532038-1540184
> >
> >
> >
>



-- 
E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
Java Persistence with Hibernate, Second Edition

JUnit in Action, Second Edition 
Spring Batch in Action 
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory

Re: svn commit: r1746655 - /commons/proper/beanutils/tags/beanutils-1.9.3-RC1/

The other tags are all upper case with underscore.
 schrieb am Fr., 3. Juni 2016 um 01:07:

> Author: ggregory
> Date: Thu Jun  2 23:07:29 2016
> New Revision: 1746655
>
> URL: http://svn.apache.org/viewvc?rev=1746655&view=rev
> Log:
> Creating beanutils-1.9.3-RC1 tag
>
> Added:
> commons/proper/beanutils/tags/beanutils-1.9.3-RC1/   (props changed)
>   - copied from r1746654, commons/proper/beanutils/trunk/
>
> Propchange: commons/proper/beanutils/tags/beanutils-1.9.3-RC1/
>
> --
> --- svn:ignore (added)
> +++ svn:ignore Thu Jun  2 23:07:29 2016
> @@ -0,0 +1,14 @@
> +build.properties
> +dist
> +target
> +beanutils.ipr
> +maven.log
> +velocity.log
> +.classpath
> +.project
> +.settings
> +.externalToolBuilders
> +maven-eclipse.xml
> +.pmd
> +.idea
> +*.iml
>
> Propchange: commons/proper/beanutils/tags/beanutils-1.9.3-RC1/
>
> --
> svn:mergeinfo =
> /commons/proper/beanutils/branches/java5:1532038-1540184
>
>
>

Re: [ALL] About binary compatibility

2016-06-02 Thread Matt Benson

On Thu, Jun 2, 2016 at 3:42 PM, Benedikt Ritter  wrote:

> Hi,
>
> we do seem to have different opinions when it comes to binary compatibility
> and how it should be handled. Usually we would say "this should be decided
> on a component basis". However this discussion is coming up again and again
> and I think we should try the impossible and agree on something that we can
> document.
>
> So here is my view on the topic:
>
> - since our components are depended upon by a lot of projects, we need to
> take special care regarding compatibility.
> - we must not break BC in a release that could collide with an earlier
> version. In other words, when we break BC, we have to change package and
> maven coordinates.
> - BUT since we're all doing this on our spare time, there is no need to
> hold on old APIs just for the sake of it. For this reason, BC may be broken
> any time, if the steps above a followed and it has been discussed on the
> ML. Fixes can always be backported to old releases, by people who need it.
> - If there are committers who are willing to work on old version and
> committers who want to work on API redesigns, we can branch and work in
> paralell.
> - Changing the Java Language requirement does not break BC and can
> therefore be done without pumping the major version.
>
> What is your view on the topic?
>
> +1 to all points

Matt


> Benedikt
>

Re: [ALL] About binary compatibility

Benson Margulies  schrieb am Fr., 3. Juni 2016 um
00:43 Uhr:

> Just to cite a fact:
>
> If you write:
>
> 
>
>   
>   ...
>   x
> ...
>
> You will get x. Even if transitive dependencies ask for x+10. I only
> learned this recently.
>

Yes thats true. Coming back to our example you could specify:

My-Project
 | -> A -> B -> C 1.2
 | -> D -> C 2.0
 | -> C 1.2

Maven will use the dependency which is closest to the project root. So in
the first example C 2.0 was closed. Now we have defined a direct dependency
to C 1.2. maven will use this one instead.

But what do you win by this? Your app is still broken. This is a problem
you can't resolve in your pom. This is the reason we're changing maven and
package coords so you can have both versions.

Benedikt


>
>
> On Thu, Jun 2, 2016 at 6:20 PM, Gary Gregory 
> wrote:
> > On Thu, Jun 2, 2016 at 3:11 PM, Ralph Goers 
> > wrote:
> >
> >> Dependency management does not cure this if C 1.2 and C 2.0 are not
> binary
> >> compatible. Code compiled with the 1.2 version will fail if those
> methods
> >> and classes are not in 2.0.
> >>
> >
> > Indeed, hence the BC break -> Maven Coord change requirement.
> >
> > Gary
> >
> >
> >> Ralph
> >>
> >> > On Jun 2, 2016, at 3:03 PM, Benson Margulies 
> >> wrote:
> >> >
> >> > Dependency management cures this; if you don't want to pick up newer
> >> > versions, you can prevent it. Since dep management doesn't know about
> >> > ranges or semantic versioning, you need to then pay attention if you
> >> > want a compatible version that comes along.
> >> >
> >> > I guess it's a question of which poison you prefer. If people here
> >> > prefer bumping artifactids and package names, so be it.
> >> >
> >> >
> >> > On Thu, Jun 2, 2016 at 6:01 PM, Benedikt Ritter 
> >> wrote:
> >> >> Hello Benson,
> >> >>
> >> >> Benson Margulies  schrieb am Do., 2. Juni
> 2016
> >> um
> >> >> 23:36 Uhr:
> >> >>
> >> >>> I don't understand what's wrong with semantic versioning and keeping
> >> >>> the same maven coordinates. No sane person should be using RELEASE
> or
> >> >>> LATEST.
> >> >>>
> >> >>
> >> >> The problem are transitive dependencies. Consider this example:
> >> >>
> >> >> My-Project
> >> >> | -> A -> B -> C 1.2
> >> >> | -> D -> C 2.0
> >> >>
> >> >> In this case my project depends directly on A and D. A depends on B
> >> which
> >> >> depends on C in version 1.2. D depends on C in version 2.0. In this
> >> case I
> >> >> have no control over the dependencies to C but my project will be
> >> broken at
> >> >> run time, because C 1.2 and C 2.0 can not exist at once in the same
> >> >> classpath.
> >> >>
> >> >> Benedikt
> >> >>
> >> >>
> >> >>>
> -
> >> >>> 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
> >>
> >>
> >
> >
> > --
> > E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
> > Java Persistence with Hibernate, Second Edition
> > 
> > JUnit in Action, Second Edition 
> > Spring Batch in Action 
> > 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
>
>

Re: [jexl] Release from the 2.0 branch

I think you best bet is to migrate to JEXL 3.0.

Gary

On Thu, Jun 2, 2016 at 3:57 PM, Bhowmik, Bindul 
wrote:

> Hello,
>
> Does anyone have a few spare cycles to do a release from the Commons
> Jexl 2.0 branch (v 2.1.2)? 2.1.1 release is from Dec 2011, and there
> have been quite a few fixes on that branch since.
>
> Also, I tried to look in JIRA for issues tagged to version 2.1.2; and
> even though the version page exists [1], the version does not show up
> on any of the Versions, Change Log, or Road Map links in the JEXL
> JIRA. It almost seems like the version existed at some point and was
> subsequently deleted with issues tagged to it.
>
> Regards,
> Bindul
>
> [1]
> https://issues.apache.org/jira/browse/JEXL/fixforversion/12320177/?selectedTab=com.atlassian.jira.jira-projects-plugin:version-summary-panel
>
> -
> 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

JUnit in Action, Second Edition 
Spring Batch in Action 
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory

[jexl] Release from the 2.0 branch

2016-06-02 Thread Bhowmik, Bindul

Hello,

Does anyone have a few spare cycles to do a release from the Commons
Jexl 2.0 branch (v 2.1.2)? 2.1.1 release is from Dec 2011, and there
have been quite a few fixes on that branch since.

Also, I tried to look in JIRA for issues tagged to version 2.1.2; and
even though the version page exists [1], the version does not show up
on any of the Versions, Change Log, or Road Map links in the JEXL
JIRA. It almost seems like the version existed at some point and was
subsequently deleted with issues tagged to it.

Regards,
Bindul

[1] 
https://issues.apache.org/jira/browse/JEXL/fixforversion/12320177/?selectedTab=com.atlassian.jira.jira-projects-plugin:version-summary-panel

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [ALL] About binary compatibility

2016-06-02 Thread Emmanuel Bourg

Le 3/06/2016 à 00:09, Gary Gregory a écrit :

> -1
> 
> Timing is irrelevant. You cannot control what will end up in an app stack.
> Once released, that's it unfortunately, otherwise, the door to jar hell is
> open.

Timing is relevant because the probability of jar hell increases with
time. If the version has been in use for 1 year there are more chances
that the API you'd like to break has been used somewhere than with a
version released only one week ago. And if someone complains we can
still revert the change and release foo 1.3.2.

I would call this "optimistic compatibility breakage", we should be able
to assess if the change is likely to cause issues in sensible use cases,
and if we make a mistake, just revert it.

Emmanuel Bourg


-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [ALL] About binary compatibility

Just to cite a fact:

If you write:


   
  
  ...
  x
...

You will get x. Even if transitive dependencies ask for x+10. I only
learned this recently.


On Thu, Jun 2, 2016 at 6:20 PM, Gary Gregory  wrote:
> On Thu, Jun 2, 2016 at 3:11 PM, Ralph Goers 
> wrote:
>
>> Dependency management does not cure this if C 1.2 and C 2.0 are not binary
>> compatible. Code compiled with the 1.2 version will fail if those methods
>> and classes are not in 2.0.
>>
>
> Indeed, hence the BC break -> Maven Coord change requirement.
>
> Gary
>
>
>> Ralph
>>
>> > On Jun 2, 2016, at 3:03 PM, Benson Margulies 
>> wrote:
>> >
>> > Dependency management cures this; if you don't want to pick up newer
>> > versions, you can prevent it. Since dep management doesn't know about
>> > ranges or semantic versioning, you need to then pay attention if you
>> > want a compatible version that comes along.
>> >
>> > I guess it's a question of which poison you prefer. If people here
>> > prefer bumping artifactids and package names, so be it.
>> >
>> >
>> > On Thu, Jun 2, 2016 at 6:01 PM, Benedikt Ritter 
>> wrote:
>> >> Hello Benson,
>> >>
>> >> Benson Margulies  schrieb am Do., 2. Juni 2016
>> um
>> >> 23:36 Uhr:
>> >>
>> >>> I don't understand what's wrong with semantic versioning and keeping
>> >>> the same maven coordinates. No sane person should be using RELEASE or
>> >>> LATEST.
>> >>>
>> >>
>> >> The problem are transitive dependencies. Consider this example:
>> >>
>> >> My-Project
>> >> | -> A -> B -> C 1.2
>> >> | -> D -> C 2.0
>> >>
>> >> In this case my project depends directly on A and D. A depends on B
>> which
>> >> depends on C in version 1.2. D depends on C in version 2.0. In this
>> case I
>> >> have no control over the dependencies to C but my project will be
>> broken at
>> >> run time, because C 1.2 and C 2.0 can not exist at once in the same
>> >> classpath.
>> >>
>> >> Benedikt
>> >>
>> >>
>> >>> -
>> >>> 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
>>
>>
>
>
> --
> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
> Java Persistence with Hibernate, Second Edition
> 
> JUnit in Action, Second Edition 
> Spring Batch in Action 
> 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

[beanutils] forthcoming RC

FYI, a heads up to avoid wasting an RC with JRE version discussions: Update
Java requirement from Java 5 to 6.

--

The Apache Commons BeanUtils team is pleased to announce the
commons-beanutils-1.9.3-SNAPSHOT release!

Apache Commons BeanUtils provides an easy-to-use but flexible wrapper
around reflection and introspection.

Changes in this version include:


Fixed Bugs:
o Precision lost when converting BigDecimal  Issue: BEANUTILS-470. Thanks
to Tommy Tynjä.
o Indexed List Setters no longer work  Issue: BEANUTILS-465. Thanks to
Daniel Atallah.

Changes:
o Update dependency from JUnit 3.8.1 to 4.12.  Issue: BEANUTILS-433. Thanks
to Benedikt Ritter, Gary Gregory.
o Update Java requirement from Java 5 to 6.  Issue: BEANUTILS-490. Thanks
to Gary Gregory.
o FluentPropertyBeanIntrospector does not use the same naming algorithm as
DefaultBeanIntrospector.  Issue: BEANUTILS-474. Thanks to Michael Grove.
o Update commons-collections from 3.2.1 to 3.2.2.  Issue: BEANUTILS-482.
Thanks to Gary Gregory.
o Update commons-logging from 1.1.1 to 1.2.  Issue: BEANUTILS-469. Thanks
to Gary Gregory.


Have fun!
-Apache Commons BeanUtils team


-- 
E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
Java Persistence with Hibernate, Second Edition

JUnit in Action, Second Edition 
Spring Batch in Action 
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory

Re: [ALL] About binary compatibility

On Thu, Jun 2, 2016 at 3:11 PM, Ralph Goers 
wrote:

> Dependency management does not cure this if C 1.2 and C 2.0 are not binary
> compatible. Code compiled with the 1.2 version will fail if those methods
> and classes are not in 2.0.
>

Indeed, hence the BC break -> Maven Coord change requirement.

Gary


> Ralph
>
> > On Jun 2, 2016, at 3:03 PM, Benson Margulies 
> wrote:
> >
> > Dependency management cures this; if you don't want to pick up newer
> > versions, you can prevent it. Since dep management doesn't know about
> > ranges or semantic versioning, you need to then pay attention if you
> > want a compatible version that comes along.
> >
> > I guess it's a question of which poison you prefer. If people here
> > prefer bumping artifactids and package names, so be it.
> >
> >
> > On Thu, Jun 2, 2016 at 6:01 PM, Benedikt Ritter 
> wrote:
> >> Hello Benson,
> >>
> >> Benson Margulies  schrieb am Do., 2. Juni 2016
> um
> >> 23:36 Uhr:
> >>
> >>> I don't understand what's wrong with semantic versioning and keeping
> >>> the same maven coordinates. No sane person should be using RELEASE or
> >>> LATEST.
> >>>
> >>
> >> The problem are transitive dependencies. Consider this example:
> >>
> >> My-Project
> >> | -> A -> B -> C 1.2
> >> | -> D -> C 2.0
> >>
> >> In this case my project depends directly on A and D. A depends on B
> which
> >> depends on C in version 1.2. D depends on C in version 2.0. In this
> case I
> >> have no control over the dependencies to C but my project will be
> broken at
> >> run time, because C 1.2 and C 2.0 can not exist at once in the same
> >> classpath.
> >>
> >> Benedikt
> >>
> >>
> >>> -
> >>> 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
>
>


-- 
E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
Java Persistence with Hibernate, Second Edition

JUnit in Action, Second Edition 
Spring Batch in Action 
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory

Re: [ALL] About binary compatibility

2016-06-02 Thread James Carman

I don't think it has anything to do necessarily with framework or not. The
class loading model is just much easier to deal with these situations. As
Benson said, however, there are definitely other issues to contend with.
On Thu, Jun 2, 2016 at 6:14 PM Benedikt Ritter  wrote:

> James Carman  schrieb am Fr., 3. Juni 2016 um
> 00:04 Uhr:
>
> > You've been in karaf land for too long! ;)
> >
>
> It's probably a different story when you're working on a framework. It
> pretty unlikely to end up with two version of Spring or Hibernate in your
> app. But for a library as wildly used as commons-lang it becomes more
> likely.
>
>
> >
> > On Thu, Jun 2, 2016 at 5:36 PM Benson Margulies 
> > wrote:
> >
> > > I don't understand what's wrong with semantic versioning and keeping
> > > the same maven coordinates. No sane person should be using RELEASE or
> > > LATEST.
> > >
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > > For additional commands, e-mail: dev-h...@commons.apache.org
> > >
> > >
> >
>

Re: [all] Automatic site update

One big pain is releasing IMO is having to manage BOTH Nexus (with the
extra checksum mess) AND SVN dist/dev + dist/release.

It would be nice if Nexus had a menu option as part of Closing a repo to
"remove extra checksum"...

Gary

On Thu, Jun 2, 2016 at 2:39 PM, Emmanuel Bourg  wrote:

> Hi all,
>
> A part of the release process is to update the web site. I wonder if
> this could be simplified with a Jenkins job watching for the release
> tags and building/uploading the new site automatically. That would make
> one less thing to think about when releasing new versions. I suspect the
> most difficult issue to solve is to let Jenkins publish the content
> without compromising the security.
>
> Thoughts?
>
> Emmanuel Bourg
>
> -
> 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

JUnit in Action, Second Edition 
Spring Batch in Action 
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory

Re: [all] Automatic site update

On Thu, Jun 2, 2016 at 2:57 PM, Benedikt Ritter  wrote:

> Emmanuel Bourg  schrieb am Do., 2. Juni 2016 um
> 23:39 Uhr:
>
> > Hi all,
> >
> > A part of the release process is to update the web site. I wonder if
> > this could be simplified with a Jenkins job watching for the release
> > tags and building/uploading the new site automatically. That would make
> > one less thing to think about when releasing new versions. I suspect the
> > most difficult issue to solve is to let Jenkins publish the content
> > without compromising the security.
>
>
> > Thoughts?
> >
>
> I'm all for automation. The only problem I see is, that I usually publish
> the final site from a dirty working copy. This is because I don't put the
> release date into changes.xml until after the release.


I like to use the RC date for changes.xml (which I forgot to do when I
recently RM'd Commons CSV 1.4!)

If the RC becomes the release, then you are done. If the RC does not, then
update the date again for the next RC. I think that is 'sane' step.

Our Maven plugin could be changed to do this so it becomes a command line
thing instead of a manual edit.

Gary

However I have
> realized that for example maven central uses that date the RC was upload to
> the staging repo as the release date. We could simply adopt this and use
> that date in changes.xml and commit it to the release tag.
>
> I'm sure it would even be possible to let jenkins create site archives as
> we're currently doing for some components.
>
> I have no idea about the security implications of this proposal.
>
> Benedikt
>
>
> >
> > Emmanuel Bourg
> >
> > -
> > 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

JUnit in Action, Second Edition 
Spring Batch in Action 
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory

Re: [ALL] About binary compatibility

James Carman  schrieb am Fr., 3. Juni 2016 um
00:04 Uhr:

> You've been in karaf land for too long! ;)
>

It's probably a different story when you're working on a framework. It
pretty unlikely to end up with two version of Spring or Hibernate in your
app. But for a library as wildly used as commons-lang it becomes more
likely.

>
> On Thu, Jun 2, 2016 at 5:36 PM Benson Margulies 
> wrote:
>
> > I don't understand what's wrong with semantic versioning and keeping
> > the same maven coordinates. No sane person should be using RELEASE or
> > LATEST.
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > For additional commands, e-mail: dev-h...@commons.apache.org
> >
> >
>

Re: [ALL] About binary compatibility

2016-06-02 Thread Ralph Goers

Dependency management does not cure this if C 1.2 and C 2.0 are not binary 
compatible. Code compiled with the 1.2 version will fail if those methods and 
classes are not in 2.0.

Ralph

> On Jun 2, 2016, at 3:03 PM, Benson Margulies  wrote:
> 
> Dependency management cures this; if you don't want to pick up newer
> versions, you can prevent it. Since dep management doesn't know about
> ranges or semantic versioning, you need to then pay attention if you
> want a compatible version that comes along.
> 
> I guess it's a question of which poison you prefer. If people here
> prefer bumping artifactids and package names, so be it.
> 
> 
> On Thu, Jun 2, 2016 at 6:01 PM, Benedikt Ritter  wrote:
>> Hello Benson,
>> 
>> Benson Margulies  schrieb am Do., 2. Juni 2016 um
>> 23:36 Uhr:
>> 
>>> I don't understand what's wrong with semantic versioning and keeping
>>> the same maven coordinates. No sane person should be using RELEASE or
>>> LATEST.
>>> 
>> 
>> The problem are transitive dependencies. Consider this example:
>> 
>> My-Project
>> | -> A -> B -> C 1.2
>> | -> D -> C 2.0
>> 
>> In this case my project depends directly on A and D. A depends on B which
>> depends on C in version 1.2. D depends on C in version 2.0. In this case I
>> have no control over the dependencies to C but my project will be broken at
>> run time, because C 1.2 and C 2.0 can not exist at once in the same
>> classpath.
>> 
>> Benedikt
>> 
>> 
>>> -
>>> 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

Re: [ALL] About binary compatibility

On Thu, Jun 2, 2016 at 3:01 PM, Benedikt Ritter  wrote:

> Hello Benson,
>
> Benson Margulies  schrieb am Do., 2. Juni 2016 um
> 23:36 Uhr:
>
> > I don't understand what's wrong with semantic versioning and keeping
> > the same maven coordinates. No sane person should be using RELEASE or
> > LATEST.
> >
>
> The problem are transitive dependencies. Consider this example:
>
> My-Project
>  | -> A -> B -> C 1.2
>  | -> D -> C 2.0
>
> In this case my project depends directly on A and D. A depends on B which
> depends on C in version 1.2. D depends on C in version 2.0. In this case I
> have no control over the dependencies to C but my project will be broken at
> run time, because C 1.2 and C 2.0 can not exist at once in the same
> classpath.
>

For a fun example, I once had a server stack with dependencies on Apache
CXF and JBoss Teiid, 100's jars... lots of t-deps...

Gary


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

JUnit in Action, Second Edition 
Spring Batch in Action 
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory

Re: [ALL] About binary compatibility

On Thu, Jun 2, 2016 at 2:26 PM, Emmanuel Bourg  wrote:

> Le 2/06/2016 à 22:42, Benedikt Ritter a écrit :
>
> > - since our components are depended upon by a lot of projects, we need to
> > take special care regarding compatibility.
>
> +1, thanks God Apache Commons isn't like Guava or BouncyCastle.
>
>
> > - we must not break BC in a release that could collide with an earlier
> > version. In other words, when we break BC, we have to change package and
> > maven coordinates.
>
> I tend to agree but I think some exceptions should be allowed:
> * If the element affected by the BC issue was released very recently, we
> should be able to roll out a new release changing it. For example if foo
> 1.3 added a protected method to a class, we should be able to make it
> private in foo 1.3.1 if we release it shortly after (let's say less than
> 2 months after foo 1.3).
>
-1

Timing is irrelevant. You cannot control what will end up in an app stack.
Once released, that's it unfortunately, otherwise, the door to jar hell is
open.

Gary


> * If the API affected is just internal stuff not intended to be used
> directly, it should be possible to change it.
>
>
> > - BUT since we're all doing this on our spare time, there is no need to
> > hold on old APIs just for the sake of it. For this reason, BC may be
> broken
> > any time, if the steps above a followed and it has been discussed on the
> > ML. Fixes can always be backported to old releases, by people who need
> it.
>
> Ok but this can only work if our release process is simplified, because
> backporting means publishing more releases
>
>
> > - Changing the Java Language requirement does not break BC and can
> > therefore be done without pumping the major version.
>
> I agree, bumping the major version isn't mandatory in this case.
>
> Emmanuel Bourg
>
>
> -
> 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

JUnit in Action, Second Edition 
Spring Batch in Action 
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory

Re: [bcel] Deprecated InstructionConstants

Gary Gregory  schrieb am Fr., 3. Juni 2016 um
00:06 Uhr:

> On Thu, Jun 2, 2016 at 2:15 PM, Jörg Schaible 
> wrote:
>
> > Gary Gregory wrote:
> >
> > > On Thu, Jun 2, 2016 at 1:34 PM, Benedikt Ritter 
> > > wrote:
> > >
> > >> dbrosIus  schrieb am Do., 2. Juni 2016 um
> > >> 22:32 Uhr:
> > >>
> > >> > It is still not functionally compatible.  People parsing UNKNOWN
> > >> > annotations looking for generics (as was the right way before)  will
> > >> > now
> > >> > fail.   Better rip the generic support out too.
> > >> >
> > >>
> > >> Okay, if this is the case I haven't understood the situation
> correctly.
> > >> If our plan is to make a release that covers Java 8, we should go all
> > the
> > >> way.
> > >>
> > >
> > > I think the immediate need is to avoid blowing up on Java 8. I see this
> > as
> > > a 5.x BC release needed ASAP that the Maven plugin(s) can pick up, also
> > > ASAP.
> >
> > That's why I proposed a 5.x with minimal effort and keep the majority of
> > changes in bcel6.
> >
>
> But today, we are in a place where bcel6 has already changes to work with
> 5.x if we do the package change...
>

I'll create a release branch for the 5.x release and rename the packages
their. Otherwise it will look like a complete mess in the trunk history.
Let's just get the fixes into trunk, we need for a compatible release and
I'll take care of preparing the RC.

Benedikt


>
> Gary
>
>
>
> >
> > Cheers,
> > Jörg
> >
> >
> > -
> > 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
> 
> JUnit in Action, Second Edition 
> Spring Batch in Action 
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory
>

Re: [ALL] About binary compatibility

2016-06-02 Thread James Carman

Yep, those pesky duplicate chains.
On Thu, Jun 2, 2016 at 6:05 PM Benson Margulies 
wrote:

> On Thu, Jun 2, 2016 at 6:04 PM, James Carman 
> wrote:
> > You've been in karaf land for too long! ;)
>
> I took my team into OSGi to get away from these messes. Of course, we
> got some other messes in their places.
>
> >
> > On Thu, Jun 2, 2016 at 5:36 PM Benson Margulies 
> > wrote:
> >
> >> I don't understand what's wrong with semantic versioning and keeping
> >> the same maven coordinates. No sane person should be using RELEASE or
> >> LATEST.
> >>
> >> -
> >> 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
>
>

Re: [bcel] Deprecated InstructionConstants

On Thu, Jun 2, 2016 at 2:15 PM, Jörg Schaible  wrote:

> Gary Gregory wrote:
>
> > On Thu, Jun 2, 2016 at 1:34 PM, Benedikt Ritter 
> > wrote:
> >
> >> dbrosIus  schrieb am Do., 2. Juni 2016 um
> >> 22:32 Uhr:
> >>
> >> > It is still not functionally compatible.  People parsing UNKNOWN
> >> > annotations looking for generics (as was the right way before)  will
> >> > now
> >> > fail.   Better rip the generic support out too.
> >> >
> >>
> >> Okay, if this is the case I haven't understood the situation correctly.
> >> If our plan is to make a release that covers Java 8, we should go all
> the
> >> way.
> >>
> >
> > I think the immediate need is to avoid blowing up on Java 8. I see this
> as
> > a 5.x BC release needed ASAP that the Maven plugin(s) can pick up, also
> > ASAP.
>
> That's why I proposed a 5.x with minimal effort and keep the majority of
> changes in bcel6.
>

But today, we are in a place where bcel6 has already changes to work with
5.x if we do the package change...

Gary



>
> Cheers,
> Jörg
>
>
> -
> 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

JUnit in Action, Second Edition 
Spring Batch in Action 
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory

Re: [ALL] About binary compatibility

On Thu, Jun 2, 2016 at 6:04 PM, James Carman  wrote:
> You've been in karaf land for too long! ;)

I took my team into OSGi to get away from these messes. Of course, we
got some other messes in their places.

>
> On Thu, Jun 2, 2016 at 5:36 PM Benson Margulies 
> wrote:
>
>> I don't understand what's wrong with semantic versioning and keeping
>> the same maven coordinates. No sane person should be using RELEASE or
>> LATEST.
>>
>> -
>> 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

Re: [ALL] About binary compatibility

2016-06-02 Thread James Carman

You've been in karaf land for too long! ;)

On Thu, Jun 2, 2016 at 5:36 PM Benson Margulies 
wrote:

> I don't understand what's wrong with semantic versioning and keeping
> the same maven coordinates. No sane person should be using RELEASE or
> LATEST.
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: [ALL] About binary compatibility

Dependency management cures this; if you don't want to pick up newer
versions, you can prevent it. Since dep management doesn't know about
ranges or semantic versioning, you need to then pay attention if you
want a compatible version that comes along.

I guess it's a question of which poison you prefer. If people here
prefer bumping artifactids and package names, so be it.


On Thu, Jun 2, 2016 at 6:01 PM, Benedikt Ritter  wrote:
> Hello Benson,
>
> Benson Margulies  schrieb am Do., 2. Juni 2016 um
> 23:36 Uhr:
>
>> I don't understand what's wrong with semantic versioning and keeping
>> the same maven coordinates. No sane person should be using RELEASE or
>> LATEST.
>>
>
> The problem are transitive dependencies. Consider this example:
>
> My-Project
>  | -> A -> B -> C 1.2
>  | -> D -> C 2.0
>
> In this case my project depends directly on A and D. A depends on B which
> depends on C in version 1.2. D depends on C in version 2.0. In this case I
> have no control over the dependencies to C but my project will be broken at
> run time, because C 1.2 and C 2.0 can not exist at once in the same
> classpath.
>
> Benedikt
>
>
>> -
>> 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

Re: [ALL] About binary compatibility

Hello Benson,

Benson Margulies  schrieb am Do., 2. Juni 2016 um
23:36 Uhr:

> I don't understand what's wrong with semantic versioning and keeping
> the same maven coordinates. No sane person should be using RELEASE or
> LATEST.
>

The problem are transitive dependencies. Consider this example:

My-Project
 | -> A -> B -> C 1.2
 | -> D -> C 2.0

In this case my project depends directly on A and D. A depends on B which
depends on C in version 1.2. D depends on C in version 2.0. In this case I
have no control over the dependencies to C but my project will be broken at
run time, because C 1.2 and C 2.0 can not exist at once in the same
classpath.

Benedikt


> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: [all] Automatic site update

Emmanuel Bourg  schrieb am Do., 2. Juni 2016 um
23:39 Uhr:

> Hi all,
>
> A part of the release process is to update the web site. I wonder if
> this could be simplified with a Jenkins job watching for the release
> tags and building/uploading the new site automatically. That would make
> one less thing to think about when releasing new versions. I suspect the
> most difficult issue to solve is to let Jenkins publish the content
> without compromising the security.


> Thoughts?
>

I'm all for automation. The only problem I see is, that I usually publish
the final site from a dirty working copy. This is because I don't put the
release date into changes.xml until after the release. However I have
realized that for example maven central uses that date the RC was upload to
the staging repo as the release date. We could simply adopt this and use
that date in changes.xml and commit it to the release tag.

I'm sure it would even be possible to let jenkins create site archives as
we're currently doing for some components.

I have no idea about the security implications of this proposal.

Benedikt


>
> Emmanuel Bourg
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

[all] Automatic site update

2016-06-02 Thread Emmanuel Bourg

Hi all,

A part of the release process is to update the web site. I wonder if
this could be simplified with a Jenkins job watching for the release
tags and building/uploading the new site automatically. That would make
one less thing to think about when releasing new versions. I suspect the
most difficult issue to solve is to let Jenkins publish the content
without compromising the security.

Thoughts?

Emmanuel Bourg

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [ALL] About binary compatibility

I don't understand what's wrong with semantic versioning and keeping
the same maven coordinates. No sane person should be using RELEASE or
LATEST.

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [ALL] About binary compatibility

Emmanuel Bourg  schrieb am Do., 2. Juni 2016 um
23:26 Uhr:

> Le 2/06/2016 à 22:42, Benedikt Ritter a écrit :
>
> > - since our components are depended upon by a lot of projects, we need to
> > take special care regarding compatibility.
>
> +1, thanks God Apache Commons isn't like Guava or BouncyCastle.
>
>
> > - we must not break BC in a release that could collide with an earlier
> > version. In other words, when we break BC, we have to change package and
> > maven coordinates.
>
> I tend to agree but I think some exceptions should be allowed:
> * If the element affected by the BC issue was released very recently, we
> should be able to roll out a new release changing it. For example if foo
> 1.3 added a protected method to a class, we should be able to make it
> private in foo 1.3.1 if we release it shortly after (let's say less than
> 2 months after foo 1.3).
> * If the API affected is just internal stuff not intended to be used
> directly, it should be possible to change it.
>
>
> > - BUT since we're all doing this on our spare time, there is no need to
> > hold on old APIs just for the sake of it. For this reason, BC may be
> broken
> > any time, if the steps above a followed and it has been discussed on the
> > ML. Fixes can always be backported to old releases, by people who need
> it.
>
> Ok but this can only work if our release process is simplified, because
> backporting means publishing more releases
>

Great idea! Let's start a discussion about our release process right after
we have settled an agreement about the BC topic.


>
>
> > - Changing the Java Language requirement does not break BC and can
> > therefore be done without pumping the major version.
>
> I agree, bumping the major version isn't mandatory in this case.
>
> Emmanuel Bourg
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: [ALL] About binary compatibility

2016-06-02 Thread Emmanuel Bourg

Le 2/06/2016 à 22:42, Benedikt Ritter a écrit :

> - since our components are depended upon by a lot of projects, we need to
> take special care regarding compatibility.

+1, thanks God Apache Commons isn't like Guava or BouncyCastle.


> - we must not break BC in a release that could collide with an earlier
> version. In other words, when we break BC, we have to change package and
> maven coordinates.

I tend to agree but I think some exceptions should be allowed:
* If the element affected by the BC issue was released very recently, we
should be able to roll out a new release changing it. For example if foo
1.3 added a protected method to a class, we should be able to make it
private in foo 1.3.1 if we release it shortly after (let's say less than
2 months after foo 1.3).
* If the API affected is just internal stuff not intended to be used
directly, it should be possible to change it.


> - BUT since we're all doing this on our spare time, there is no need to
> hold on old APIs just for the sake of it. For this reason, BC may be broken
> any time, if the steps above a followed and it has been discussed on the
> ML. Fixes can always be backported to old releases, by people who need it.

Ok but this can only work if our release process is simplified, because
backporting means publishing more releases


> - Changing the Java Language requirement does not break BC and can
> therefore be done without pumping the major version.

I agree, bumping the major version isn't mandatory in this case.

Emmanuel Bourg


-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [ALL] About binary compatibility

2016-06-02 Thread Jörg Schaible

Hi Benedikt,

Benedikt Ritter wrote:

> Hi,
> 
> we do seem to have different opinions when it comes to binary
> compatibility and how it should be handled. Usually we would say "this
> should be decided on a component basis". However this discussion is coming
> up again and again and I think we should try the impossible and agree on
> something that we can document.
> 
> So here is my view on the topic:
> 
> - since our components are depended upon by a lot of projects, we need to
> take special care regarding compatibility.
> - we must not break BC in a release that could collide with an earlier
> version. In other words, when we break BC, we have to change package and
> maven coordinates.
> - BUT since we're all doing this on our spare time, there is no need to
> hold on old APIs just for the sake of it. For this reason, BC may be
> broken any time, if the steps above a followed and it has been discussed
> on the ML. Fixes can always be backported to old releases, by people who
> need it. - If there are committers who are willing to work on old version
> and committers who want to work on API redesigns, we can branch and work
> in paralell.
> - Changing the Java Language requirement does not break BC and can
> therefore be done without pumping the major version.
> 
> What is your view on the topic?

+1

We need a fine balance between BC requirement and ongoing development and 
you nicely summed it up.

Cheers,
Jörg


-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [bcel] Deprecated InstructionConstants

2016-06-02 Thread Jörg Schaible

Gary Gregory wrote:

> On Thu, Jun 2, 2016 at 1:34 PM, Benedikt Ritter 
> wrote:
> 
>> dbrosIus  schrieb am Do., 2. Juni 2016 um
>> 22:32 Uhr:
>>
>> > It is still not functionally compatible.  People parsing UNKNOWN
>> > annotations looking for generics (as was the right way before)  will
>> > now
>> > fail.   Better rip the generic support out too.
>> >
>>
>> Okay, if this is the case I haven't understood the situation correctly.
>> If our plan is to make a release that covers Java 8, we should go all the
>> way.
>>
> 
> I think the immediate need is to avoid blowing up on Java 8. I see this as
> a 5.x BC release needed ASAP that the Maven plugin(s) can pick up, also
> ASAP.

That's why I proposed a 5.x with minimal effort and keep the majority of 
changes in bcel6.

Cheers,
Jörg


-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [LANG] Ready for 3.5?

2016-06-02 Thread Pascal Schumacher

should be "If somebody else would like to RM, I'm also very happy with
that."

Sorry,
Pascal

Am 02.06.2016 um 23:14 schrieb Pascal Schumacher:

Hello Benedikt

guess a 3.5 is overdue as 3.4 was released over a year ago. There are
88 fixed jira issues:

https://issues.apache.org/jira/issues/?jql=project%20%3D%20LANG%20AND%20status%20in%20%28Resolved%2C%20Closed%29%20AND%20fixVersion%20%3D%203.5%20ORDER%20BY%20priority%20DESC

With your help I am willing to give RMing a try. :) Of course I
somebody else would like to do I'm also very happy with that. :)

I think LANG-1229: "Performance regression due to cyclic hashCode
guard" should be solved before a release. This issue has been caused
by the fix for https://issues.apache.org/jira/browse/LANG-456
"HashCodeBuilder throws StackOverflowError in bidirectional navigable
association". The suggested solution at
https://issues.apache.org/jira/browse/LANG-1229 is to add a new method
to HashCodeBuilder which allows appending with a cycle check. Any
input on how to name this method or other solutions for this is very
welcome. (Of course if no good solution is found we can always reopen
LANG-456, as it not been released.)

Thanks,
Pascal

Am 02.06.2016 um 22:48 schrieb Benedikt Ritter:

Hello Pascal,

you have been working through the issues of [LANG] recently. Would
you like
to do RM for 3.5? I can help you with that. I've done it several
times in

the past.

Benedikt

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [LANG] Ready for 3.5?

2016-06-02 Thread Pascal Schumacher


Hello Benedikt

guess a 3.5 is overdue as 3.4 was released over a year ago. There are 88 
fixed jira issues:


https://issues.apache.org/jira/issues/?jql=project%20%3D%20LANG%20AND%20status%20in%20%28Resolved%2C%20Closed%29%20AND%20fixVersion%20%3D%203.5%20ORDER%20BY%20priority%20DESC

With your help I am willing to give RMing a try. :) Of course I somebody 
else would like to do I'm also very happy with that. :)


I think LANG-1229: "Performance regression due to cyclic hashCode guard" 
should be solved before a release. This issue has been caused by the fix 
for https://issues.apache.org/jira/browse/LANG-456 "HashCodeBuilder 
throws StackOverflowError in bidirectional navigable association". The 
suggested solution at https://issues.apache.org/jira/browse/LANG-1229 is 
to add a new method to HashCodeBuilder which allows appending with a 
cycle check. Any input on how to name this method or other solutions for 
this is very welcome. (Of course if no good solution is found we can 
always reopen LANG-456, as it not been released.)


Thanks,
Pascal

Am 02.06.2016 um 22:48 schrieb Benedikt Ritter:

Hello Pascal,

you have been working through the issues of [LANG] recently. Would you like
to do RM for 3.5? I can help you with that. I've done it several times in
the past.

Benedikt




-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [ALL] About binary compatibility

On Thu, Jun 2, 2016 at 1:42 PM, Benedikt Ritter  wrote:

> Hi,
>
> we do seem to have different opinions when it comes to binary compatibility
> and how it should be handled. Usually we would say "this should be decided
> on a component basis". However this discussion is coming up again and again
> and I think we should try the impossible and agree on something that we can
> document.
>
> So here is my view on the topic:
>
> - since our components are depended upon by a lot of projects, we need to
> take special care regarding compatibility.
>
+1


> - we must not break BC in a release that could collide with an earlier
> version. In other words, when we break BC, we have to change package and
> maven coordinates.
>
+1


> - BUT since we're all doing this on our spare time, there is no need to
> hold on old APIs just for the sake of it. For this reason, BC may be broken
> any time, if the steps above a followed and it has been discussed on the
> ML. Fixes can always be backported to old releases, by people who need it.
>
+1


> - If there are committers who are willing to work on old version and
> committers who want to work on API redesigns, we can branch and work in
> paralell.
>
+1


> - Changing the Java Language requirement does not break BC and can
> therefore be done without pumping the major version.
>
+1

I would also be OK to actually bump the major release version of a
component when the Java plaform changes _without_ changing the package
name. This would just be a nice indication that something important have
changed that WILL break applications stuck on older JREs.

Nice email. You have beaten me to the punch!

Gary


> What is your view on the topic?
>
> Benedikt
>



-- 
E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
Java Persistence with Hibernate, Second Edition

JUnit in Action, Second Edition 
Spring Batch in Action 
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory

Re: [LANG] Ready for 3.5?

On Thu, Jun 2, 2016 at 2:01 PM, Gary Gregory  wrote:

> On Thu, Jun 2, 2016 at 1:48 PM, Benedikt Ritter 
> wrote:
>
>> Hello Pascal,
>>
>> you have been working through the issues of [LANG] recently. Would you
>> like
>> to do RM for 3.5? I can help you with that. I've done it several times in
>> the past.
>>
>
> +1 for RERO. No need to rush more stuff in a release.
>

I love the new activity. Thank you Pascal!

I'd like we make sure what we have in there now really is in scope...;-)

Gary


>
> Gary
>
>
>>
>> Benedikt
>>
>
>
>
> --
> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
> Java Persistence with Hibernate, Second Edition
> 
> JUnit in Action, Second Edition 
> Spring Batch in Action 
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory
>



-- 
E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
Java Persistence with Hibernate, Second Edition

JUnit in Action, Second Edition 
Spring Batch in Action 
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory

Re: [LANG] Ready for 3.5?

On Thu, Jun 2, 2016 at 1:48 PM, Benedikt Ritter  wrote:

> Hello Pascal,
>
> you have been working through the issues of [LANG] recently. Would you like
> to do RM for 3.5? I can help you with that. I've done it several times in
> the past.
>

+1 for RERO. No need to rush more stuff in a release.

Gary

>
> Benedikt
>

-- 
E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
Java Persistence with Hibernate, Second Edition

JUnit in Action, Second Edition 
Spring Batch in Action 
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory

Re: [bcel] Deprecated InstructionConstants

On Thu, Jun 2, 2016 at 1:44 PM, Benedikt Ritter  wrote:

> Gary Gregory  schrieb am Do., 2. Juni 2016 um
> 22:40 Uhr:
>
> > On Thu, Jun 2, 2016 at 1:40 PM, Gary Gregory 
> > wrote:
> >
> > > On Thu, Jun 2, 2016 at 1:34 PM, Benedikt Ritter 
> > > wrote:
> > >
> > >> dbrosIus  schrieb am Do., 2. Juni 2016 um
> > >> 22:32 Uhr:
> > >>
> > >> > It is still not functionally compatible.  People parsing UNKNOWN
> > >> > annotations looking for generics (as was the right way before)  will
> > now
> > >> > fail.   Better rip the generic support out too.
> > >> >
> > >>
> > >> Okay, if this is the case I haven't understood the situation
> correctly.
> > If
> > >> our plan is to make a release that covers Java 8, we should go all the
> > >> way.
> > >>
> > >
> > > I think the immediate need is to avoid blowing up on Java 8. I see this
> > as
> > > a 5.x BC release needed ASAP that the Maven plugin(s) can pick up, also
> > > ASAP.
> > >
> >
> > It's a Maven plugin that blows up IIRC.
> >
>
> Okay, if some one goes ahead and fixes the two interface problems, I can
> RM.
>


@Benedikt: Thank you for volunteering to RM!

@Sebb: Are you available for this task?

Gary


>
> Benedikt
>
>
> >
> > Gary
> >
> >
> > > Gary
> > >
> > >
> > >>
> > >> >
> > >> >  Original message 
> > >> > From: Benedikt Ritter 
> > >> > Date: 06/02/2016  4:22 PM  (GMT-05:00)
> > >> > To: Commons Developers List 
> > >> > Subject: Re: [bcel] Deprecated InstructionConstants
> > >> >
> > >> > Okay, so were are we now?
> > >> >
> > >> > - people are waiting for a new release
> > >> > - package coords have changed - BC is broken
> > >> > - sebb has put effort into making all changes compatible
> > >> > - two interface changes remain
> > >> >
> > >> > Is that correct? Then let's just get over with this two interfaces
> > mach
> > >> > make the API redesign afterwards. Let's create two extension
> > interfaces
> > >> > release this stuff with the old package and maven coord and we're
> > done.
> > >> >
> > >> > sebb  schrieb am Do., 2. Juni 2016 um 14:19 Uhr:
> > >> >
> > >> > > On 2 June 2016 at 12:35, Jörg Schaible <
> > >> joerg.schai...@bpm-inspire.com>
> > >> > > wrote:
> > >> > > > Hi,
> > >> > > >
> > >> > > > sebb 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.
> > >> > > >
> > >> > > > The question is, why does one want to have a BC release? If
> Oliver
> > >> uses
> > >> > > it
> > >> > > > as drop-in replacement, he will not use any new stuff, i.e. he
> > >> might be
> > >> > > > interested to get simply a version working with Java 8 runtime.
> > >> > > >
> > >> > > >> 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.
> > >> > > >
> > >> > > > I'd really go on with bcel6 and new GAV using Java 8 as minimum
> > and
> > >> > > backport
> > >> > > > anything to 5.x that is required to let BCEL run on Java 8
> > runtime,
> > >> but
> > >> > > > nothing else.
> > >> > > >
> > >> > > > I am normally also in the BC camp, but I realize that we stress
> it
> > >> > > sometimes
> > >> > > > too much and actually harm further development of a component.
> > After
> > >> > > several
> > >> > > > years of (public) inactivity of a component, we should really
> take
> > >> the
> > >> > > > advantage for a cut.
> > >> > > >
> > >> > > > The effort to release an additional 5.x after a major 6.0 is
> > >> negligible
> > >> > >
> > >> > > Not sure I agree the effort is negligible.
> > >> > >
> > >> > > > compared to the constant annoyance by the limits of ancient JDKs
> > >> > working
> > >> > > on
> > >> > > > the interesting stuff for a component.
> > >> > >
> > >> > > The JDK required to run BCEL is orthogonal to compatibility.
> > >> > >
> > >> > > Indeed there was a proposal to use Java 8 default interface
> methods
> > to
> > >> > > get round the issue with compatibility.
> > >> > >
> > >> > > Please let's not conflate the two issues.
> > >> > >
> > >> > > > Cheer

Re: [ALL] About binary compatibility

2016-06-02 Thread ecki

Hello,

Unhappy with it but agreeing that your definition sounds like it should apply.

I would vote for always bumping at least the minor version when requiring newer 
dependencies (including Java Version). Strictly speaking semver would require a 
major version but with our policy of using new package names for major versions 
that would annoy lots of users.

And we really really need to avoid VFS-style release congestions (because 
backporting becomes prohibitively painful).

Gruss
Bernd

-- 
http://bernd.eckenfels.net

-Original Message-
From: Benedikt Ritter 
To: Commons Developers List 
Sent: Do., 02 Juni 2016 22:43
Subject: [ALL] About binary compatibility

Hi,

we do seem to have different opinions when it comes to binary compatibility
and how it should be handled. Usually we would say "this should be decided
on a component basis". However this discussion is coming up again and again
and I think we should try the impossible and agree on something that we can
document.

So here is my view on the topic:

- since our components are depended upon by a lot of projects, we need to
take special care regarding compatibility.
- we must not break BC in a release that could collide with an earlier
version. In other words, when we break BC, we have to change package and
maven coordinates.
- BUT since we're all doing this on our spare time, there is no need to
hold on old APIs just for the sake of it. For this reason, BC may be broken
any time, if the steps above a followed and it has been discussed on the
ML. Fixes can always be backported to old releases, by people who need it.
- If there are committers who are willing to work on old version and
committers who want to work on API redesigns, we can branch and work in
paralell.
- Changing the Java Language requirement does not break BC and can
therefore be done without pumping the major version.

What is your view on the topic?

Benedikt

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

[LANG] Ready for 3.5?

Hello Pascal,

you have been working through the issues of [LANG] recently. Would you like
to do RM for 3.5? I can help you with that. I've done it several times in
the past.

Benedikt

Re: [bcel] Deprecated InstructionConstants

Gary Gregory  schrieb am Do., 2. Juni 2016 um
22:40 Uhr:

> On Thu, Jun 2, 2016 at 1:40 PM, Gary Gregory 
> wrote:
>
> > On Thu, Jun 2, 2016 at 1:34 PM, Benedikt Ritter 
> > wrote:
> >
> >> dbrosIus  schrieb am Do., 2. Juni 2016 um
> >> 22:32 Uhr:
> >>
> >> > It is still not functionally compatible.  People parsing UNKNOWN
> >> > annotations looking for generics (as was the right way before)  will
> now
> >> > fail.   Better rip the generic support out too.
> >> >
> >>
> >> Okay, if this is the case I haven't understood the situation correctly.
> If
> >> our plan is to make a release that covers Java 8, we should go all the
> >> way.
> >>
> >
> > I think the immediate need is to avoid blowing up on Java 8. I see this
> as
> > a 5.x BC release needed ASAP that the Maven plugin(s) can pick up, also
> > ASAP.
> >
>
> It's a Maven plugin that blows up IIRC.
>

Okay, if some one goes ahead and fixes the two interface problems, I can RM.

Benedikt


>
> Gary
>
>
> > Gary
> >
> >
> >>
> >> >
> >> >  Original message 
> >> > From: Benedikt Ritter 
> >> > Date: 06/02/2016  4:22 PM  (GMT-05:00)
> >> > To: Commons Developers List 
> >> > Subject: Re: [bcel] Deprecated InstructionConstants
> >> >
> >> > Okay, so were are we now?
> >> >
> >> > - people are waiting for a new release
> >> > - package coords have changed - BC is broken
> >> > - sebb has put effort into making all changes compatible
> >> > - two interface changes remain
> >> >
> >> > Is that correct? Then let's just get over with this two interfaces
> mach
> >> > make the API redesign afterwards. Let's create two extension
> interfaces
> >> > release this stuff with the old package and maven coord and we're
> done.
> >> >
> >> > sebb  schrieb am Do., 2. Juni 2016 um 14:19 Uhr:
> >> >
> >> > > On 2 June 2016 at 12:35, Jörg Schaible <
> >> joerg.schai...@bpm-inspire.com>
> >> > > wrote:
> >> > > > Hi,
> >> > > >
> >> > > > sebb 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.
> >> > > >
> >> > > > The question is, why does one want to have a BC release? If Oliver
> >> uses
> >> > > it
> >> > > > as drop-in replacement, he will not use any new stuff, i.e. he
> >> might be
> >> > > > interested to get simply a version working with Java 8 runtime.
> >> > > >
> >> > > >> 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.
> >> > > >
> >> > > > I'd really go on with bcel6 and new GAV using Java 8 as minimum
> and
> >> > > backport
> >> > > > anything to 5.x that is required to let BCEL run on Java 8
> runtime,
> >> but
> >> > > > nothing else.
> >> > > >
> >> > > > I am normally also in the BC camp, but I realize that we stress it
> >> > > sometimes
> >> > > > too much and actually harm further development of a component.
> After
> >> > > several
> >> > > > years of (public) inactivity of a component, we should really take
> >> the
> >> > > > advantage for a cut.
> >> > > >
> >> > > > The effort to release an additional 5.x after a major 6.0 is
> >> negligible
> >> > >
> >> > > Not sure I agree the effort is negligible.
> >> > >
> >> > > > compared to the constant annoyance by the limits of ancient JDKs
> >> > working
> >> > > on
> >> > > > the interesting stuff for a component.
> >> > >
> >> > > The JDK required to run BCEL is orthogonal to compatibility.
> >> > >
> >> > > Indeed there was a proposal to use Java 8 default interface methods
> to
> >> > > get round the issue with compatibility.
> >> > >
> >> > > Please let's not conflate the two issues.
> >> > >
> >> > > > Cheers,
> >> > > > Jörg
> >> > > >
> >> > > >
> >> > > >
> >> -
> >> > > > 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 additio

[ALL] About binary compatibility

Hi,

we do seem to have different opinions when it comes to binary compatibility
and how it should be handled. Usually we would say "this should be decided
on a component basis". However this discussion is coming up again and again
and I think we should try the impossible and agree on something that we can
document.

So here is my view on the topic:

- since our components are depended upon by a lot of projects, we need to
take special care regarding compatibility.
- we must not break BC in a release that could collide with an earlier
version. In other words, when we break BC, we have to change package and
maven coordinates.
- BUT since we're all doing this on our spare time, there is no need to
hold on old APIs just for the sake of it. For this reason, BC may be broken
any time, if the steps above a followed and it has been discussed on the
ML. Fixes can always be backported to old releases, by people who need it.
- If there are committers who are willing to work on old version and
committers who want to work on API redesigns, we can branch and work in
paralell.
- Changing the Java Language requirement does not break BC and can
therefore be done without pumping the major version.

What is your view on the topic?

Benedikt

Re: [bcel] Deprecated InstructionConstants

On Thu, Jun 2, 2016 at 1:40 PM, Gary Gregory  wrote:

> On Thu, Jun 2, 2016 at 1:34 PM, Benedikt Ritter 
> wrote:
>
>> dbrosIus  schrieb am Do., 2. Juni 2016 um
>> 22:32 Uhr:
>>
>> > It is still not functionally compatible.  People parsing UNKNOWN
>> > annotations looking for generics (as was the right way before)  will now
>> > fail.   Better rip the generic support out too.
>> >
>>
>> Okay, if this is the case I haven't understood the situation correctly. If
>> our plan is to make a release that covers Java 8, we should go all the
>> way.
>>
>
> I think the immediate need is to avoid blowing up on Java 8. I see this as
> a 5.x BC release needed ASAP that the Maven plugin(s) can pick up, also
> ASAP.
>

It's a Maven plugin that blows up IIRC.

Gary


> Gary
>
>
>>
>> >
>> >  Original message 
>> > From: Benedikt Ritter 
>> > Date: 06/02/2016  4:22 PM  (GMT-05:00)
>> > To: Commons Developers List 
>> > Subject: Re: [bcel] Deprecated InstructionConstants
>> >
>> > Okay, so were are we now?
>> >
>> > - people are waiting for a new release
>> > - package coords have changed - BC is broken
>> > - sebb has put effort into making all changes compatible
>> > - two interface changes remain
>> >
>> > Is that correct? Then let's just get over with this two interfaces mach
>> > make the API redesign afterwards. Let's create two extension interfaces
>> > release this stuff with the old package and maven coord and we're done.
>> >
>> > sebb  schrieb am Do., 2. Juni 2016 um 14:19 Uhr:
>> >
>> > > On 2 June 2016 at 12:35, Jörg Schaible <
>> joerg.schai...@bpm-inspire.com>
>> > > wrote:
>> > > > Hi,
>> > > >
>> > > > sebb 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.
>> > > >
>> > > > The question is, why does one want to have a BC release? If Oliver
>> uses
>> > > it
>> > > > as drop-in replacement, he will not use any new stuff, i.e. he
>> might be
>> > > > interested to get simply a version working with Java 8 runtime.
>> > > >
>> > > >> 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.
>> > > >
>> > > > I'd really go on with bcel6 and new GAV using Java 8 as minimum and
>> > > backport
>> > > > anything to 5.x that is required to let BCEL run on Java 8 runtime,
>> but
>> > > > nothing else.
>> > > >
>> > > > I am normally also in the BC camp, but I realize that we stress it
>> > > sometimes
>> > > > too much and actually harm further development of a component. After
>> > > several
>> > > > years of (public) inactivity of a component, we should really take
>> the
>> > > > advantage for a cut.
>> > > >
>> > > > The effort to release an additional 5.x after a major 6.0 is
>> negligible
>> > >
>> > > Not sure I agree the effort is negligible.
>> > >
>> > > > compared to the constant annoyance by the limits of ancient JDKs
>> > working
>> > > on
>> > > > the interesting stuff for a component.
>> > >
>> > > The JDK required to run BCEL is orthogonal to compatibility.
>> > >
>> > > Indeed there was a proposal to use Java 8 default interface methods to
>> > > get round the issue with compatibility.
>> > >
>> > > Please let's not conflate the two issues.
>> > >
>> > > > Cheers,
>> > > > Jörg
>> > > >
>> > > >
>> > > >
>> -
>> > > > 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
> 
> JUnit in Action, Second Edition 
> Spring Batch in Action 
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twit

Re: [bcel] Deprecated InstructionConstants

On Thu, Jun 2, 2016 at 1:34 PM, Benedikt Ritter 
wrote:

> dbrosIus  schrieb am Do., 2. Juni 2016 um
> 22:32 Uhr:
>
> > It is still not functionally compatible.  People parsing UNKNOWN
> > annotations looking for generics (as was the right way before)  will now
> > fail.   Better rip the generic support out too.
> >
>
> Okay, if this is the case I haven't understood the situation correctly. If
> our plan is to make a release that covers Java 8, we should go all the way.
>

I think the immediate need is to avoid blowing up on Java 8. I see this as
a 5.x BC release needed ASAP that the Maven plugin(s) can pick up, also
ASAP.

Gary


>
> >
> >  Original message 
> > From: Benedikt Ritter 
> > Date: 06/02/2016  4:22 PM  (GMT-05:00)
> > To: Commons Developers List 
> > Subject: Re: [bcel] Deprecated InstructionConstants
> >
> > Okay, so were are we now?
> >
> > - people are waiting for a new release
> > - package coords have changed - BC is broken
> > - sebb has put effort into making all changes compatible
> > - two interface changes remain
> >
> > Is that correct? Then let's just get over with this two interfaces mach
> > make the API redesign afterwards. Let's create two extension interfaces
> > release this stuff with the old package and maven coord and we're done.
> >
> > sebb  schrieb am Do., 2. Juni 2016 um 14:19 Uhr:
> >
> > > On 2 June 2016 at 12:35, Jörg Schaible  >
> > > wrote:
> > > > Hi,
> > > >
> > > > sebb 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.
> > > >
> > > > The question is, why does one want to have a BC release? If Oliver
> uses
> > > it
> > > > as drop-in replacement, he will not use any new stuff, i.e. he might
> be
> > > > interested to get simply a version working with Java 8 runtime.
> > > >
> > > >> 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.
> > > >
> > > > I'd really go on with bcel6 and new GAV using Java 8 as minimum and
> > > backport
> > > > anything to 5.x that is required to let BCEL run on Java 8 runtime,
> but
> > > > nothing else.
> > > >
> > > > I am normally also in the BC camp, but I realize that we stress it
> > > sometimes
> > > > too much and actually harm further development of a component. After
> > > several
> > > > years of (public) inactivity of a component, we should really take
> the
> > > > advantage for a cut.
> > > >
> > > > The effort to release an additional 5.x after a major 6.0 is
> negligible
> > >
> > > Not sure I agree the effort is negligible.
> > >
> > > > compared to the constant annoyance by the limits of ancient JDKs
> > working
> > > on
> > > > the interesting stuff for a component.
> > >
> > > The JDK required to run BCEL is orthogonal to compatibility.
> > >
> > > Indeed there was a proposal to use Java 8 default interface methods to
> > > get round the issue with compatibility.
> > >
> > > Please let's not conflate the two issues.
> > >
> > > > Cheers,
> > > > Jörg
> > > >
> > > >
> > > > -
> > > > 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

JUnit in Action, Second Edition 
Spring Batch in Action 
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory

Re: [bcel] Deprecated InstructionConstants

dbrosIus  schrieb am Do., 2. Juni 2016 um
22:32 Uhr:

> It is still not functionally compatible.  People parsing UNKNOWN
> annotations looking for generics (as was the right way before)  will now
> fail.   Better rip the generic support out too.
>

Okay, if this is the case I haven't understood the situation correctly. If
our plan is to make a release that covers Java 8, we should go all the way.


>
>  Original message 
> From: Benedikt Ritter 
> Date: 06/02/2016  4:22 PM  (GMT-05:00)
> To: Commons Developers List 
> Subject: Re: [bcel] Deprecated InstructionConstants
>
> Okay, so were are we now?
>
> - people are waiting for a new release
> - package coords have changed - BC is broken
> - sebb has put effort into making all changes compatible
> - two interface changes remain
>
> Is that correct? Then let's just get over with this two interfaces mach
> make the API redesign afterwards. Let's create two extension interfaces
> release this stuff with the old package and maven coord and we're done.
>
> sebb  schrieb am Do., 2. Juni 2016 um 14:19 Uhr:
>
> > On 2 June 2016 at 12:35, Jörg Schaible 
> > wrote:
> > > Hi,
> > >
> > > sebb 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.
> > >
> > > The question is, why does one want to have a BC release? If Oliver uses
> > it
> > > as drop-in replacement, he will not use any new stuff, i.e. he might be
> > > interested to get simply a version working with Java 8 runtime.
> > >
> > >> 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.
> > >
> > > I'd really go on with bcel6 and new GAV using Java 8 as minimum and
> > backport
> > > anything to 5.x that is required to let BCEL run on Java 8 runtime, but
> > > nothing else.
> > >
> > > I am normally also in the BC camp, but I realize that we stress it
> > sometimes
> > > too much and actually harm further development of a component. After
> > several
> > > years of (public) inactivity of a component, we should really take the
> > > advantage for a cut.
> > >
> > > The effort to release an additional 5.x after a major 6.0 is negligible
> >
> > Not sure I agree the effort is negligible.
> >
> > > compared to the constant annoyance by the limits of ancient JDKs
> working
> > on
> > > the interesting stuff for a component.
> >
> > The JDK required to run BCEL is orthogonal to compatibility.
> >
> > Indeed there was a proposal to use Java 8 default interface methods to
> > get round the issue with compatibility.
> >
> > Please let's not conflate the two issues.
> >
> > > Cheers,
> > > Jörg
> > >
> > >
> > > -
> > > 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
> >
> >
>

Re: [bcel] Deprecated InstructionConstants

2016-06-02 Thread dbrosIus

It is still not functionally compatible.  People parsing UNKNOWN annotations 
looking for generics (as was the right way before)  will now fail.   Better rip 
the generic support out too. 

 Original message 
From: Benedikt Ritter  
Date: 06/02/2016  4:22 PM  (GMT-05:00) 
To: Commons Developers List  
Subject: Re: [bcel] Deprecated InstructionConstants 

Okay, so were are we now?

- people are waiting for a new release
- package coords have changed - BC is broken
- sebb has put effort into making all changes compatible
- two interface changes remain

Is that correct? Then let's just get over with this two interfaces mach
make the API redesign afterwards. Let's create two extension interfaces
release this stuff with the old package and maven coord and we're done.

sebb  schrieb am Do., 2. Juni 2016 um 14:19 Uhr:

> On 2 June 2016 at 12:35, Jörg Schaible 
> wrote:
> > Hi,
> >
> > sebb 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.
> >
> > The question is, why does one want to have a BC release? If Oliver uses
> it
> > as drop-in replacement, he will not use any new stuff, i.e. he might be
> > interested to get simply a version working with Java 8 runtime.
> >
> >> 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.
> >
> > I'd really go on with bcel6 and new GAV using Java 8 as minimum and
> backport
> > anything to 5.x that is required to let BCEL run on Java 8 runtime, but
> > nothing else.
> >
> > I am normally also in the BC camp, but I realize that we stress it
> sometimes
> > too much and actually harm further development of a component. After
> several
> > years of (public) inactivity of a component, we should really take the
> > advantage for a cut.
> >
> > The effort to release an additional 5.x after a major 6.0 is negligible
>
> Not sure I agree the effort is negligible.
>
> > compared to the constant annoyance by the limits of ancient JDKs working
> on
> > the interesting stuff for a component.
>
> The JDK required to run BCEL is orthogonal to compatibility.
>
> Indeed there was a proposal to use Java 8 default interface methods to
> get round the issue with compatibility.
>
> Please let's not conflate the two issues.
>
> > Cheers,
> > Jörg
> >
> >
> > -
> > 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
>
>

Re: [bcel] Deprecated InstructionConstants

On Thu, Jun 2, 2016 at 1:22 PM, Benedikt Ritter  wrote:

> Okay, so were are we now?
>
> - people are waiting for a new release
> - package coords have changed - BC is broken
> - sebb has put effort into making all changes compatible
> - two interface changes remain
>
> Is that correct? Then let's just get over with this two interfaces mach
> make the API redesign afterwards. Let's create two extension interfaces
> release this stuff with the old package and maven coord and we're done.
>

Check. Do you want to RM? Or Sebb?

Gary


>
> sebb  schrieb am Do., 2. Juni 2016 um 14:19 Uhr:
>
> > On 2 June 2016 at 12:35, Jörg Schaible 
> > wrote:
> > > Hi,
> > >
> > > sebb 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.
> > >
> > > The question is, why does one want to have a BC release? If Oliver uses
> > it
> > > as drop-in replacement, he will not use any new stuff, i.e. he might be
> > > interested to get simply a version working with Java 8 runtime.
> > >
> > >> 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.
> > >
> > > I'd really go on with bcel6 and new GAV using Java 8 as minimum and
> > backport
> > > anything to 5.x that is required to let BCEL run on Java 8 runtime, but
> > > nothing else.
> > >
> > > I am normally also in the BC camp, but I realize that we stress it
> > sometimes
> > > too much and actually harm further development of a component. After
> > several
> > > years of (public) inactivity of a component, we should really take the
> > > advantage for a cut.
> > >
> > > The effort to release an additional 5.x after a major 6.0 is negligible
> >
> > Not sure I agree the effort is negligible.
> >
> > > compared to the constant annoyance by the limits of ancient JDKs
> working
> > on
> > > the interesting stuff for a component.
> >
> > The JDK required to run BCEL is orthogonal to compatibility.
> >
> > Indeed there was a proposal to use Java 8 default interface methods to
> > get round the issue with compatibility.
> >
> > Please let's not conflate the two issues.
> >
> > > Cheers,
> > > Jörg
> > >
> > >
> > > -
> > > 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

JUnit in Action, Second Edition 
Spring Batch in Action 
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory

Re: [beanutils] release 1.9.3?

On Thu, Jun 2, 2016 at 1:03 PM, Oliver Heger 
wrote:

>
>
> Am 01.06.2016 um 22:09 schrieb Gary Gregory:
> > On Wed, Jun 1, 2016 at 12:46 PM, Oliver Heger <
> oliver.he...@oliver-heger.de>
> > wrote:
> >
> >>
> >>
> >> Am 31.05.2016 um 23:31 schrieb Gary Gregory:
> >>> While there is not much new for 1.9.3, just two fixes, I would not mind
> >>> pushing out a release, just to get the refreshed dependency on Commons
> >>> Collection out since there has been noise about it related to security.
> >>>
> >>> Thoughts?
> >>
> >> +1, would it be possible to fix BEANUTILS-477? This came up already
> >> multiple times. It is probably only suppressing some log output.
> >>
> >> I am currently pretty busy, otherwise I would look into it myself.
> >>
> >
> > Well, we can RERO and do a 1.9.4 and get to it when you can dig in.
>
> Changed priorities and fixed it.
>

Sweet, thank you.

I'll roll an RC today I hope.

Gary

>
> Oliver
>
> >
> > Gary
> >
> >
> >> Thanks
> >> Oliver
> >>
> >>>
> >>> Gary
> >>>
> >>
> >> -
> >> 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

JUnit in Action, Second Edition 
Spring Batch in Action 
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory

Re: [bcel] Deprecated InstructionConstants

Okay, so were are we now?

- people are waiting for a new release
- package coords have changed - BC is broken
- sebb has put effort into making all changes compatible
- two interface changes remain

Is that correct? Then let's just get over with this two interfaces mach
make the API redesign afterwards. Let's create two extension interfaces
release this stuff with the old package and maven coord and we're done.

sebb  schrieb am Do., 2. Juni 2016 um 14:19 Uhr:

> On 2 June 2016 at 12:35, Jörg Schaible 
> wrote:
> > Hi,
> >
> > sebb 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.
> >
> > The question is, why does one want to have a BC release? If Oliver uses
> it
> > as drop-in replacement, he will not use any new stuff, i.e. he might be
> > interested to get simply a version working with Java 8 runtime.
> >
> >> 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.
> >
> > I'd really go on with bcel6 and new GAV using Java 8 as minimum and
> backport
> > anything to 5.x that is required to let BCEL run on Java 8 runtime, but
> > nothing else.
> >
> > I am normally also in the BC camp, but I realize that we stress it
> sometimes
> > too much and actually harm further development of a component. After
> several
> > years of (public) inactivity of a component, we should really take the
> > advantage for a cut.
> >
> > The effort to release an additional 5.x after a major 6.0 is negligible
>
> Not sure I agree the effort is negligible.
>
> > compared to the constant annoyance by the limits of ancient JDKs working
> on
> > the interesting stuff for a component.
>
> The JDK required to run BCEL is orthogonal to compatibility.
>
> Indeed there was a proposal to use Java 8 default interface methods to
> get round the issue with compatibility.
>
> Please let's not conflate the two issues.
>
> > Cheers,
> > Jörg
> >
> >
> > -
> > 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
>
>

Re: [beanutils] release 1.9.3?

2016-06-02 Thread Oliver Heger



Am 01.06.2016 um 22:09 schrieb Gary Gregory:
> On Wed, Jun 1, 2016 at 12:46 PM, Oliver Heger 
> wrote:
> 
>>
>>
>> Am 31.05.2016 um 23:31 schrieb Gary Gregory:
>>> While there is not much new for 1.9.3, just two fixes, I would not mind
>>> pushing out a release, just to get the refreshed dependency on Commons
>>> Collection out since there has been noise about it related to security.
>>>
>>> Thoughts?
>>
>> +1, would it be possible to fix BEANUTILS-477? This came up already
>> multiple times. It is probably only suppressing some log output.
>>
>> I am currently pretty busy, otherwise I would look into it myself.
>>
> 
> Well, we can RERO and do a 1.9.4 and get to it when you can dig in.

Changed priorities and fixed it.

Oliver

> 
> Gary
> 
> 
>> Thanks
>> Oliver
>>
>>>
>>> Gary
>>>
>>
>> -
>> 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

Re: US Export classification & ECCN registration for encryption in commons?

If you know how so get this right for VFS, go for it!

Stian Soiland-Reyes  schrieb am Do., 2. Juni 2016 um
16:35:

> Thanks! It's already on https://www.apache.org/licenses/exports/
>
> I've added to the Commons Crypto README:
>
> https://github.com/apache/commons-crypto#export-restrictions
>
> (if changing, modify this text in pom.xml  and regenerate
> README.md)
>
>
> Shall I add VFS2 as well? Then Gary can send a joint notification message.
>
>
>
>
> On 1 June 2016 at 03:01, Sun, Dapeng  wrote:
> > Thank Stian for your review!
> >
> >>We also need a second  for the (future) source/binary
> distributions with ControlledSource href=
> https://www.apache.org/dist/commons/crypto/ - you would need to duplicate
> the OpenSSL and JavaSE  for that. See other examples in
> the XML file.
> > Thank you for pointing it out, we should add it.
> >
> >> is it 1.0.0 we're targeting for the first Commons Crypto release?
> > Yes, 1.0.0 would be the first release.
> >
> > I have updated the staging website.
> http://www.staging.apache.org/licenses/exports/index.html
> >
> >
> > Regards
> > Dapeng
> >
> > -Original Message-
> > From: Stian Soiland-Reyes [mailto:st...@apache.org]
> > Sent: Tuesday, May 31, 2016 6:45 PM
> > To: Commons Developers List
> > Subject: Re: US Export classification & ECCN registration for encryption
> in commons?
> >
> > Thanks! Looks good.
> >
> > We also need a second  for the (future) source/binary
> distributions with ControlledSource href=
> https://www.apache.org/dist/commons/crypto/ - you would need to duplicate
> the OpenSSL and JavaSE  for that. See other examples in
> the XML file.
> >
> > In the second Version you can say 1.0.0 and later - is it
> 1.0.0 we're targeting for the first Commons Crypto release?
> >
> > On 31 May 2016 at 11:03, Sun, Dapeng  wrote:
> >> Thank Stian and Haifeng, I have updated the file at my cms workspace.
> >> If the change is okay for you, I will try to commit it to
> >> http://www.staging.apache.org/licenses/exports/
> >>
> >> Index: trunk/content/licenses/exports/index.page/eccnmatrix.xml
> >> ===
> >> --- trunk/content/licenses/exports/index.page/eccnmatrix.xml
> (revision 1655892)
> >> +++ trunk/content/licenses/exports/index.page/eccnmatrix.xml
> (working copy)
> >> @@ -212,6 +212,25 @@
> >>  
> >>
> >>
> >> +Apache Commons Crypto
> >> +
> >> +  development
> >> +  5D002
> >> +  https://git-wip-us.apache.org/repos/asf/commons-crypto.git";>
> >> +ASF
> >> +designed for use with encryption library
> >> +  
> >> +  http://www.openssl.org/source/";>
> >> +The OpenSSL Project
> >> +general-purpose cryptography library included with
> OpenSSL
> >> +  
> >> +  http://www.oracle.com/technetwork/java/javase/downloads/index.html";>
> >> +Oracle
> >> +general-purpose cryptography library (JCE) included with
> Java
> >> +  
> >> +
> >> +  
> >> +  
> >>  Apache Commons OpenPGP
> >>  
> >>development
> >>
> >>
> >> Regards
> >> Dapeng
> >>
> >> -Original Message-
> >> From: Stian Soiland-Reyes [mailto:st...@apache.org]
> >> Sent: Monday, May 30, 2016 5:20 PM
> >> To: Commons Developers List
> >> Subject: RE: US Export classification & ECCN registration for
> encryption in commons?
> >>
> >> I think we are good to continue as a "normal" 5D002 self-classification.
> >>
> >> Great if you will have a go, let me know if you would like me to help
> or review!
> >>
> >> See http://www.apache.org/dev/crypto.html#sources for svn details,
> >> linking to
> >> https://svn.apache.org/repos/asf/infrastructure/site/trunk/content/lic
> >> enses/exports/index.page/eccnmatrix.xml
> >>
> >> I found just being a committer was enough to update the svn, after
> >> which it should be live on
> >> http://www.staging.apache.org/licenses/exports/
> >>
> >> If that works fine, then any ASF member can publish it using
> >> https://cms.apache.org/ for the main website (it can be a bit slow)
> >>
> >> Normally it is the PMC Chair that sends the registration email after
> that.
> >> On 30 May 2016 8:09 a.m., "Chen, Haifeng" 
> wrote:
> >>
> >> Hi Stian,
> >> If we decide to go ECCN 5D002 self-classify category, do you have an
> idea that what I can proceed next?
> >>
> >> I saw you updated eccnmatrix.xml file for Taverna. Would you please
> help share where is the place of the file and who has the privilege to make
> an similar update for Commons Crypto?
> >>
> >> Thanks for your help.
> >>
> >> Haifeng
> >>
> >>
> >> -Original Message-
> >> From: Chen, Haifeng [mailto:haifeng.c...@intel.com]
> >> Sent: Thursday, May 26, 2016 9:42 AM
> >> To: Commons Developers List 
> >> Subject: RE: US Export classification & ECCN registration for
> encryption in commons?
> >>
> >> https://issues.apache.org/jira/browse/LEGAL-256 is created and
> commented to track this.
> >>
> >> If we think this analysis

Re: [VFS] NIO Version Questions

2016-06-02 Thread Ralph Goers

My intention since I first saw the NIO stuff before it came out was to replace 
Commons VFS file system stuff with Java’s but to try to minimize the changes to 
the existing providers as much as possible. That said, this is surely going to 
break backward compatibility but that has never been a concern of mine.

I do not think each provider should be in its own repo. Performing a Maven 
release across multiple repos is a pain and I don’t think each provider should 
be released independently. I view all the ones we currently have as a core set 
that people want.

I haven’t considered virtual roots. 

Ralph

> On Jun 1, 2016, at 8:48 AM, Mark Fortner  wrote:
> 
> There was some discussion during the last release about a NIO-compatible
> version of VFS.  This raised a few questions in my mind.
> 
>   1. Is there a branch where this work should start?
>   2. Are there any specific API proposals, if so where are they (or will
>   they) be documented?  Would there be branches with specific proposal code,
>   or a wiki?
>   3. Does anyone have an "out of the gate" proposal? A proposed file
>   system implementation that they're willing to contribute/collaborate on?
>   Preferably something that's easy to test without additional server setup.
>   Perhaps a db-based file system that could use java db?
>   4. How would the code be organized? Would each implementation have to
>   have its own repo? If so, this might slow down initial API development.
>   And you always run into the danger that any API changes you make break
>   implementing code.
>   5. Has anyone considered support for virtual roots in file system URLs?
>   Like "home://", "documents://", "music://", etc.
> 
> 
> Cheers,
> 
> Mark

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: US Export classification & ECCN registration for encryption in commons?

2016-06-02 Thread Stian Soiland-Reyes

Thanks! It's already on https://www.apache.org/licenses/exports/

I've added to the Commons Crypto README:

https://github.com/apache/commons-crypto#export-restrictions

(if changing, modify this text in pom.xml  and regenerate
README.md)


Shall I add VFS2 as well? Then Gary can send a joint notification message.




On 1 June 2016 at 03:01, Sun, Dapeng  wrote:
> Thank Stian for your review!
>
>>We also need a second  for the (future) source/binary distributions 
>>with ControlledSource href=https://www.apache.org/dist/commons/crypto/ - you 
>>would need to duplicate the OpenSSL and JavaSE  for that. 
>>See other examples in the XML file.
> Thank you for pointing it out, we should add it.
>
>> is it 1.0.0 we're targeting for the first Commons Crypto release?
> Yes, 1.0.0 would be the first release.
>
> I have updated the staging website. 
> http://www.staging.apache.org/licenses/exports/index.html
>
>
> Regards
> Dapeng
>
> -Original Message-
> From: Stian Soiland-Reyes [mailto:st...@apache.org]
> Sent: Tuesday, May 31, 2016 6:45 PM
> To: Commons Developers List
> Subject: Re: US Export classification & ECCN registration for encryption in 
> commons?
>
> Thanks! Looks good.
>
> We also need a second  for the (future) source/binary distributions 
> with ControlledSource href=https://www.apache.org/dist/commons/crypto/ - you 
> would need to duplicate the OpenSSL and JavaSE  for that. 
> See other examples in the XML file.
>
> In the second Version you can say 1.0.0 and later - is it 
> 1.0.0 we're targeting for the first Commons Crypto release?
>
> On 31 May 2016 at 11:03, Sun, Dapeng  wrote:
>> Thank Stian and Haifeng, I have updated the file at my cms workspace.
>> If the change is okay for you, I will try to commit it to
>> http://www.staging.apache.org/licenses/exports/
>>
>> Index: trunk/content/licenses/exports/index.page/eccnmatrix.xml
>> ===
>> --- trunk/content/licenses/exports/index.page/eccnmatrix.xml(revision 
>> 1655892)
>> +++ trunk/content/licenses/exports/index.page/eccnmatrix.xml(working 
>> copy)
>> @@ -212,6 +212,25 @@
>>  
>>
>>
>> +Apache Commons Crypto
>> +
>> +  development
>> +  5D002
>> +  > href="https://git-wip-us.apache.org/repos/asf/commons-crypto.git";>
>> +ASF
>> +designed for use with encryption library
>> +  
>> +  http://www.openssl.org/source/";>
>> +The OpenSSL Project
>> +general-purpose cryptography library included with 
>> OpenSSL
>> +  
>> +  > href="http://www.oracle.com/technetwork/java/javase/downloads/index.html";>
>> +Oracle
>> +general-purpose cryptography library (JCE) included with 
>> Java
>> +  
>> +
>> +  
>> +  
>>  Apache Commons OpenPGP
>>  
>>development
>>
>>
>> Regards
>> Dapeng
>>
>> -Original Message-
>> From: Stian Soiland-Reyes [mailto:st...@apache.org]
>> Sent: Monday, May 30, 2016 5:20 PM
>> To: Commons Developers List
>> Subject: RE: US Export classification & ECCN registration for encryption in 
>> commons?
>>
>> I think we are good to continue as a "normal" 5D002 self-classification.
>>
>> Great if you will have a go, let me know if you would like me to help or 
>> review!
>>
>> See http://www.apache.org/dev/crypto.html#sources for svn details,
>> linking to
>> https://svn.apache.org/repos/asf/infrastructure/site/trunk/content/lic
>> enses/exports/index.page/eccnmatrix.xml
>>
>> I found just being a committer was enough to update the svn, after
>> which it should be live on
>> http://www.staging.apache.org/licenses/exports/
>>
>> If that works fine, then any ASF member can publish it using
>> https://cms.apache.org/ for the main website (it can be a bit slow)
>>
>> Normally it is the PMC Chair that sends the registration email after that.
>> On 30 May 2016 8:09 a.m., "Chen, Haifeng"  wrote:
>>
>> Hi Stian,
>> If we decide to go ECCN 5D002 self-classify category, do you have an idea 
>> that what I can proceed next?
>>
>> I saw you updated eccnmatrix.xml file for Taverna. Would you please help 
>> share where is the place of the file and who has the privilege to make an 
>> similar update for Commons Crypto?
>>
>> Thanks for your help.
>>
>> Haifeng
>>
>>
>> -Original Message-
>> From: Chen, Haifeng [mailto:haifeng.c...@intel.com]
>> Sent: Thursday, May 26, 2016 9:42 AM
>> To: Commons Developers List 
>> Subject: RE: US Export classification & ECCN registration for encryption in 
>> commons?
>>
>> https://issues.apache.org/jira/browse/LEGAL-256 is created and commented to 
>> track this.
>>
>> If we think this analysis makes sense, we will choose to go ECCN 5D002 
>> self-classify category. Will wait for a few days for feedbacks.
>>
>> Regards,
>> Haifeng
>>
>> -Original Message-
>> From: Chen, Haifeng [mailto:haifeng.c...@intel.com]
>> Sent: Tuesday, May 24, 2016 3:57 PM
>> To: Commons Developers List 
>> Subject: RE: US

Re: [bcel] Deprecated InstructionConstants

On 2 June 2016 at 12:35, Jörg Schaible  wrote:
> Hi,
>
> sebb 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.
>
> The question is, why does one want to have a BC release? If Oliver uses it
> as drop-in replacement, he will not use any new stuff, i.e. he might be
> interested to get simply a version working with Java 8 runtime.
>
>> 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.
>
> I'd really go on with bcel6 and new GAV using Java 8 as minimum and backport
> anything to 5.x that is required to let BCEL run on Java 8 runtime, but
> nothing else.
>
> I am normally also in the BC camp, but I realize that we stress it sometimes
> too much and actually harm further development of a component. After several
> years of (public) inactivity of a component, we should really take the
> advantage for a cut.
>
> The effort to release an additional 5.x after a major 6.0 is negligible

Not sure I agree the effort is negligible.

> compared to the constant annoyance by the limits of ancient JDKs working on
> the interesting stuff for a component.

The JDK required to run BCEL is orthogonal to compatibility.

Indeed there was a proposal to use Java 8 default interface methods to
get round the issue with compatibility.

Please let's not conflate the two issues.

> Cheers,
> Jörg
>
>
> -
> 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

Re: [bcel] Deprecated InstructionConstants

2016-06-02 Thread Jörg Schaible

Hi,

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

The question is, why does one want to have a BC release? If Oliver uses it 
as drop-in replacement, he will not use any new stuff, i.e. he might be 
interested to get simply a version working with Java 8 runtime.

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

I'd really go on with bcel6 and new GAV using Java 8 as minimum and backport 
anything to 5.x that is required to let BCEL run on Java 8 runtime, but 
nothing else.

I am normally also in the BC camp, but I realize that we stress it sometimes 
too much and actually harm further development of a component. After several 
years of (public) inactivity of a component, we should really take the 
advantage for a cut.

The effort to release an additional 5.x after a major 6.0 is negligible 
compared to the constant annoyance by the limits of ancient JDKs working on 
the interesting stuff for a component.

Cheers,
Jörg

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [bcel] Deprecated InstructionConstants

On 2 June 2016 at 11:20, Dave Brosius  wrote:
> 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.

Fine, provided that there is consensus to do so.

But I have yet to see agreement that breaking compatibility is acceptable.
There are several people who value compatibility over modernity.

Note that it would also be possible to release BCEL as two separate versions.
One which maintains compatibility, and the other which starts again
with a new design/package/coords.

>
>
>
> 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  wrote:
>>>
>>> This is the problem with Commons.
>>>
>>>  Original message 
>>> From: sebb 
>>> Date: 06/02/2016  5:15 AM  (GMT-05:00)
>>> To: Commons Developers List 
>>> Subject: Re: [bcel] Deprecated InstructionConstants
>>>
>>> On 2 June 2016 at 07:56, Benedikt Ritter  wrote:

 Gary Gregory  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  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)  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
> 
> JUnit in Action, Second Edition 
> Spring Batch in Action 
> 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
>>
>>
>
>
> ---

Re: [VFS] NIO Version Questions

2016-06-02 Thread Schalk Cronjé


On 02/06/2016 08:45, Stian Soiland-Reyes wrote:




As each filesystem provider in nio2 only does one URI scheme we would
probably need nested URIs or multiple providers.

I would like to see how that one will get solved. It is definitely one 
of the joys of VFS.



--
Schalk W. Cronjé
Twitter / Ello / Toeter : @ysb33r

Re: [bcel] Deprecated InstructionConstants

2016-06-02 Thread Dave Brosius

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  wrote:

This is the problem with Commons.

 Original message 
From: sebb 
Date: 06/02/2016  5:15 AM  (GMT-05:00)
To: Commons Developers List 
Subject: Re: [bcel] Deprecated InstructionConstants

On 2 June 2016 at 07:56, Benedikt Ritter  wrote:

Gary Gregory  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  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)  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

JUnit in Action, Second Edition 
Spring Batch in Action 
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

Re: [bcel] Deprecated InstructionConstants

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  wrote:
> This is the problem with Commons.
>
>  Original message 
> From: sebb 
> Date: 06/02/2016  5:15 AM  (GMT-05:00)
> To: Commons Developers List 
> Subject: Re: [bcel] Deprecated InstructionConstants
>
> On 2 June 2016 at 07:56, Benedikt Ritter  wrote:
>> Gary Gregory  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  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)  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
>>> 
>>> JUnit in Action, Second Edition 
>>> Spring Batch in Action 
>>> 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

Re: [bcel] Deprecated InstructionConstants

2016-06-02 Thread dbrosIus

This is the problem with Commons.  

 Original message 
From: sebb  
Date: 06/02/2016  5:15 AM  (GMT-05:00) 
To: Commons Developers List  
Subject: Re: [bcel] Deprecated InstructionConstants 

On 2 June 2016 at 07:56, Benedikt Ritter  wrote:
> Gary Gregory  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  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)  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
>> 
>> JUnit in Action, Second Edition 
>> Spring Batch in Action 
>> 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

Re: [bcel] Deprecated InstructionConstants