Re: [VOTE][LAZY] Migrate Apache Commons IO to git

2016-06-07 Thread Jochen Wiedmann
+1 (go for it) On Tue, Jun 7, 2016 at 8:37 AM, Kristian Rosenvold wrote: > Hello, > > I'd like to call a VOTE by LAZY > consensus for migrating the Apache Commons IO component to git. Please > object to this vote if you see a problem with this. Otherwise this vote > will be considered as passed

Re: [ALL] About binary compatibility

2016-06-07 Thread Jochen Wiedmann
On Mon, Jun 6, 2016 at 10:07 PM, Ralph Goers wrote: > From what I have been reading on the core-libs-dev mailing list that feature > is part of the > Java 9 EA releases that are currently being delivered. From this thread it > appears > you can build currently build multi-release jars with Mave

Re: [ALL] About binary compatibility

2016-06-07 Thread Benedikt Ritter
Hi, Gary Gregory schrieb am Mo., 6. Juni 2016 um 22:30 Uhr: > On Mon, Jun 6, 2016 at 11:44 AM, Ralph Goers > wrote: > > > > > > On Jun 6, 2016, at 11:38 AM, Gary Gregory > > wrote: > > > > > > On Mon, Jun 6, 2016 at 11:11 AM, Jochen Wiedmann < > > jochen.wiedm...@gmail.com

Re: [VOTE] Apache Commons BeanUtils 1.9.3 RC1

2016-06-07 Thread Benedikt Ritter
Hello Gary, Gary Gregory schrieb am Di., 7. Juni 2016 um 07:31 Uhr: > On Mon, Jun 6, 2016 at 10:25 PM, Benedikt Ritter > wrote: > > > Hello Gary, > > > > Gary Gregory schrieb am Mo., 6. Juni 2016 um > > 23:34 Uhr: > > > > > On Mon, Jun 6, 2016 at 8:53 AM, Benedikt Ritter > > > wrote: > > > >

Re: [VOTE][LAZY] Migrate Apache Commons IO to git

2016-06-07 Thread Gary Gregory
+1 Gary On Mon, Jun 6, 2016 at 11:37 PM, Kristian Rosenvold wrote: > Hello, > > I'd like to call a VOTE by LAZY > consensus for migrating the Apache Commons IO component to git. Please > object to this vote if you see a problem with this. Otherwise this vote > will be considered as passed after

Re: Re: Build failed in Jenkins: Commons-Codec #3

2016-06-07 Thread Dennis Kieselhorst
Am 07.06.2016 um 01:58 schrieb Gary Gregory: > On Mon, Jun 6, 2016 at 4:48 PM, Ralph Goers > wrote: > >> If that file is bad I would suspect every build running on that server >> would be failing. The server is jenkins-test-c83. As you know we were >> told not to use any of the jerkins-test serv

Re: [VOTE][LAZY] Migrate Apache Commons IO to git

2016-06-07 Thread Sergio Fernández
+1 On Tue, Jun 7, 2016 at 10:18 AM, Gary Gregory wrote: > +1 > > Gary > > On Mon, Jun 6, 2016 at 11:37 PM, Kristian Rosenvold > > wrote: > > > Hello, > > > > I'd like to call a VOTE by LAZY > > consensus for migrating the Apache Commons IO component to git. Please > > object to this vote if you

Build failed in Jenkins: Commons-configuration #6

2016-06-07 Thread Apache Jenkins Server
See -- [...truncated 515 lines...] AU src/main/java/org/apache/commons/configuration2/reloading/ReloadingEvent.java AU src/main/java/org/apache/commons/configuration2/reloading/Periodic

[BCEL] Move to Git?

2016-06-07 Thread Andrey Loskutov
Hi all, I'm not a BCEL developer, just a user, but may I trigger a discussion to move BCEL development from SVN to Git? I see there is already a Github mirror, so may be it is not that complicated? The main resson is to simplify contributions. I've made few smaller commits on BCEL trunk via G

Re: [BCEL] Move to Git?

2016-06-07 Thread Gary Gregory
We have a bunch of components that just got in the queue to migrate from Svn to Git. BCEL would just be another one... Gary On Tue, Jun 7, 2016 at 1:40 AM, Andrey Loskutov wrote: > Hi all, > > I'm not a BCEL developer, just a user, but may I trigger a discussion to > move BCEL development from

Re: [BCEL] Move to Git?

2016-06-07 Thread Jochen Wiedmann
On Tue, Jun 7, 2016 at 10:43 AM, Gary Gregory wrote: > We have a bunch of components that just got in the queue to migrate from > Svn to Git. BCEL would just be another one... Maybe we could take the discussion for all components now, and would just do the actual move componentwise? - Would spa

Re: [VOTE][LAZY] Migrate Apache Commons CSV to git

2016-06-07 Thread Sergio Fernández
+1 On Mon, Jun 6, 2016 at 10:03 PM, Gary Gregory wrote: > +1 > > Gary > > On Mon, Jun 6, 2016 at 12:17 PM, Benedikt Ritter > wrote: > > > Hello, > > > > as done before for other components, I'd like to call a VOTE by LAZY > > consensus for migrating the Apache Commons CSV component to git. Plea

Re: [VOTE] Apache Commons BeanUtils 1.9.3 RC1

2016-06-07 Thread Stian Soiland-Reyes
Agree that my other negatives are not blockers, but we really should be supporting building with Java 1.8 when that is the current version. I would love to have a quick look; the errors hint it is just a bug in the test, but I'm a bit stretched right now, so I can't make a firm promise.. On 6 Jun

Re: svn commit: r1747119 [1/4] - in /commons/proper/net/trunk/src/main/java/org/apache/commons/net: ./ bsd/ chargen/ daytime/ discard/ echo/ finger/ ftp/ ftp/parser/ imap/ io/ nntp/ ntp/ pop3/ smtp/ t

2016-06-07 Thread sebb
On 7 June 2016 at 03:22, wrote: > Author: ggregory > Date: Tue Jun 7 02:22:24 2016 > New Revision: 1747119 > > URL: http://svn.apache.org/viewvc?rev=1747119&view=rev > Log: (empty) Please don't use empty log messages. What was this change about? ---

Re: BCEL 6 API breakage

2016-06-07 Thread sebb
On 7 June 2016 at 03:50, Charles Honton wrote: > How Apache Commons BCEL got to where it is currently. > > 1. I wanted to release a version of BCEL which would support Java 6 and 7. > 2. I updated several classes that handled the new instructions and new code > attributes. > 3. This required new

Re: [BCEL] 5.3 is going to be messy

2016-06-07 Thread sebb
On 6 June 2016 at 21:02, Gary Gregory wrote: > On Mon, Jun 6, 2016 at 12:44 PM, Benedikt Ritter wrote: > >> Hi all, >> >> I had a brief look at the state of BCEL wrt doing a last 5.x release. Well, >> it feels like that is going to be a mess: >> >> - We have @since 6.0 annotations all over the co

Re: [net] Javadoc format

2016-06-07 Thread sebb
On 7 June 2016 at 03:22, Gary Gregory wrote: > Why do some [net] Javadoc comments come in the form: > > /*** > ... > ***/ > > Instead of the regular: > > /** > ... > */ History. They still work, so why bother to fix them? > ? > > Thank you, > Gary > > -- > E-Mail: garydgreg...@gmail.com |

Re: svn commit: r1747119 [1/4] - in /commons/proper/net/trunk/src/main/java/org/apache/commons/net: ./ bsd/ chargen/ daytime/ discard/ echo/ finger/ ftp/ ftp/parser/ imap/ io/ nntp/ ntp/ pop3/ smtp/ t

2016-06-07 Thread Gary Gregory
Oops, fixed. Thank you for the catch! Gary On Tue, Jun 7, 2016 at 2:25 AM, sebb wrote: > On 7 June 2016 at 03:22, wrote: > > Author: ggregory > > Date: Tue Jun 7 02:22:24 2016 > > New Revision: 1747119 > > > > URL: http://svn.apache.org/viewvc?rev=1747119&view=rev > > Log: (empty) > > Please

Re: [net] Javadoc format

2016-06-07 Thread Gary Gregory
On Tue, Jun 7, 2016 at 2:52 AM, sebb wrote: > On 7 June 2016 at 03:22, Gary Gregory wrote: > > Why do some [net] Javadoc comments come in the form: > > > > /*** > > ... > > ***/ > > > > Instead of the regular: > > > > /** > > ... > > */ > > History. > > They still work, so why bother to fix

Re: [BCEL] Move to Git?

2016-06-07 Thread Gary Gregory
On Tue, Jun 7, 2016 at 1:46 AM, Jochen Wiedmann wrote: > On Tue, Jun 7, 2016 at 10:43 AM, Gary Gregory > wrote: > > > We have a bunch of components that just got in the queue to migrate from > > Svn to Git. BCEL would just be another one... > > Maybe we could take the discussion for all componen

Re: [BCEL] 5.3 is going to be messy

2016-06-07 Thread Torsten Curdt
> > 1) I don't believe we should force users to migrate their code in > order to support java 7/8. > ...and that line of thinking is why it feels like commons projects are effectively stuck in the past. No one needs to upgrade. If your projects live in the past - there are bug fix releases. But i

Re: [BCEL] 5.3 is going to be messy

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

Re: [VOTE][LAZY] Migrate Apache Commons IO to git

2016-06-07 Thread James Carman
+1 On Tue, Jun 7, 2016 at 2:37 AM Kristian Rosenvold wrote: > Hello, > > I'd like to call a VOTE by LAZY > consensus for migrating the Apache Commons IO component to git. Please > object to this vote if you see a problem with this. Otherwise this vote > will be considered as passed after 72 hour

Re: [BCEL] 5.3 is going to be messy

2016-06-07 Thread James Carman
+1 Torsten On Tue, Jun 7, 2016 at 6:17 AM Torsten Curdt wrote: > > > > 1) I don't believe we should force users to migrate their code in > > order to support java 7/8. > > > > ...and that line of thinking is why it feels like commons projects are > effectively stuck in the past. > > No one needs

Re: [BCEL] Move to Git?

2016-06-07 Thread James Carman
This was proposed long ago. On Tue, Jun 7, 2016 at 4:46 AM Jochen Wiedmann wrote: > On Tue, Jun 7, 2016 at 10:43 AM, Gary Gregory > wrote: > > > We have a bunch of components that just got in the queue to migrate from > > Svn to Git. BCEL would just be another one... > > Maybe we could take the

Re: BCEL 6 API breakage

2016-06-07 Thread James Carman
We have to be willing to reevaluate the BC stringency we have had. Is it working for our users? Is it worth the trouble it causes (people have left this community over it)? Are there better options? Is it too strict and could just be relaxed? Our BC policies sound good on paper and do address thin

Re: [BCEL] 5.3 is going to be messy

2016-06-07 Thread Gilles
On Tue, 7 Jun 2016 11:39:09 +0100, sebb wrote: On 7 June 2016 at 11:15, Torsten Curdt wrote: 1) I don't believe we should force users to migrate their code in order to support java 7/8. ...and that line of thinking is why it feels like commons projects are effectively stuck in the past.

Re: BCEL 6 API breakage

2016-06-07 Thread Jochen Wiedmann
On Tue, Jun 7, 2016 at 12:57 PM, James Carman wrote: > We have to be willing to reevaluate the BC stringency we have had. Is it > working for our users? Is it worth the trouble it causes (people have left > this community over it)? Are there better options? Is it too strict and > could just be rel

Re: BCEL 6 API breakage

2016-06-07 Thread James Carman
On Tue, Jun 7, 2016 at 8:15 AM Jochen Wiedmann wrote: > In the light of the current discussions, you may be right. > > However, what I still don't understand: Why is BC such an issue for people? > > I think, it is perfectly reasonable to do, what other projects do: > > - Maintain several release

Re: [BCEL] 5.3 is going to be messy

2016-06-07 Thread Dave Brosius
On 06/07/2016 06:39 AM, sebb wrote: On 7 June 2016 at 11:15, Torsten Curdt wrote: 1) I don't believe we should force users to migrate their code in order to support java 7/8. ...and that line of thinking is why it feels like commons projects are effectively stuck in the past. And maybe the

Re: [BCEL] 5.3 is going to be messy

2016-06-07 Thread sebb
On 7 June 2016 at 14:29, Dave Brosius wrote: > > > On 06/07/2016 06:39 AM, sebb wrote: >> >> On 7 June 2016 at 11:15, Torsten Curdt wrote: 1) I don't believe we should force users to migrate their code in order to support java 7/8. >>> ...and that line of thinking is why it fe

Re: svn commit: r1747238 - /commons/proper/io/trunk/src/main/java/org/apache/commons/io/FileUtils.java

2016-06-07 Thread Benedikt Ritter
schrieb am Di., 7. Juni 2016 um 15:56 Uhr: > Author: sebb > Date: Tue Jun 7 13:56:34 2016 > New Revision: 1747238 > > URL: http://svn.apache.org/viewvc?rev=1747238&view=rev > Log: > Now using Java 7 so can avoid the deprecated constant > > Modified: > > commons/proper/io/trunk/src/main/java/org/

Re: [BCEL] Move to Git?

2016-06-07 Thread Benedikt Ritter
James Carman schrieb am Di., 7. Juni 2016 um 12:51 Uhr: > This was proposed long ago. > exactly. So it's probably a good idea to rethink our decision now more people have the necessary experience with git. > > On Tue, Jun 7, 2016 at 4:46 AM Jochen Wiedmann > wrote: > > > On Tue, Jun 7, 2016 a

Re: [BCEL] Move to Git?

2016-06-07 Thread Benedikt Ritter
Hello Andrey, right now I think it would be better to focus on the next release and do the migration afterwards. Benedikt Andrey Loskutov schrieb am Di., 7. Juni 2016 um 10:40 Uhr: > Hi all, > > I'm not a BCEL developer, just a user, but may I trigger a discussion to > move BCEL development fr

Re: svn commit: r1747238 - /commons/proper/io/trunk/src/main/java/org/apache/commons/io/FileUtils.java

2016-06-07 Thread sebb
On 7 June 2016 at 15:52, Benedikt Ritter wrote: > schrieb am Di., 7. Juni 2016 um 15:56 Uhr: > >> Author: sebb >> Date: Tue Jun 7 13:56:34 2016 >> New Revision: 1747238 >> >> URL: http://svn.apache.org/viewvc?rev=1747238&view=rev >> Log: >> Now using Java 7 so can avoid the deprecated constant >

Re: [BCEL] Move to Git?

2016-06-07 Thread Andrey Loskutov
On Tuesday 07 June 2016 15:10 Benedikt Ritter wrote: > Hello Andrey, > > right now I think it would be better to focus on the next release and do > the migration afterwards. My point was: I'm willing to help as far as I can (we need a solid BCEL release for FindBugs), but I'm not willing to use

Re: [BCEL] 5.3 is going to be messy

2016-06-07 Thread Benedikt Ritter
Hi, sebb schrieb am Di., 7. Juni 2016 um 11:49 Uhr: > On 6 June 2016 at 21:02, Gary Gregory wrote: > > On Mon, Jun 6, 2016 at 12:44 PM, Benedikt Ritter > wrote: > > > >> Hi all, > >> > >> I had a brief look at the state of BCEL wrt doing a last 5.x release. > Well, > >> it feels like that is g

Re: [BCEL] Move to Git?

2016-06-07 Thread Benedikt Ritter
Hello Andrey, Andrey Loskutov schrieb am Di., 7. Juni 2016 um 17:19 Uhr: > On Tuesday 07 June 2016 15:10 Benedikt Ritter wrote: > > Hello Andrey, > > > > right now I think it would be better to focus on the next release and do > > the migration afterwards. > > My point was: I'm willing to help a

Re: [BCEL] Move to Git?

2016-06-07 Thread Andrey Loskutov
On Tuesday 07 June 2016 15:25 Benedikt Ritter wrote: > Hello Andrey, > > Andrey Loskutov schrieb am Di., 7. Juni 2016 um 17:19 Uhr: > > > On Tuesday 07 June 2016 15:10 Benedikt Ritter wrote: > > > Hello Andrey, > > > > > > right now I think it would be better to focus on the next release and do

Re: [BCEL] 5.3 is going to be messy

2016-06-07 Thread Ralph Goers
I suspect Gary wants a 5.3 release because the CLIRR Maven plugin fails in Java 8 which has resulted in https://github.com/mojohaus/clirr-maven-plugin/issues/3 , LANG-1025, and WICKET-5836 among others. We ran into this in Log4j, which I a

Re: [BCEL] 5.3 is going to be messy

2016-06-07 Thread Andrey Loskutov
On Tuesday 07 June 2016 15:24 Benedikt Ritter wrote: > Hi, > > sebb schrieb am Di., 7. Juni 2016 um 11:49 Uhr: > > 0) I think we are fairly close to being able to release compatible > > code with all the necessary fixes > > > > 1) I don't believe we should force users to migrate their code in > >

Re: [BCEL] 5.3 is going to be messy

2016-06-07 Thread Benedikt Ritter
Hello, Andrey Loskutov schrieb am Di., 7. Juni 2016 um 17:35 Uhr: > On Tuesday 07 June 2016 15:24 Benedikt Ritter wrote: > > Hi, > > > > sebb schrieb am Di., 7. Juni 2016 um 11:49 Uhr: > > > 0) I think we are fairly close to being able to release compatible > > > code with all the necessary fix

Re: BCEL 6 API breakage

2016-06-07 Thread Benedikt Ritter
James Carman schrieb am Di., 7. Juni 2016 um 14:36 Uhr: > On Tue, Jun 7, 2016 at 8:15 AM Jochen Wiedmann > wrote: > > > In the light of the current discussions, you may be right. > > > > However, what I still don't understand: Why is BC such an issue for > people? > > > > I think, it is perfectl

Re: [crypto] Logging dependency

2016-06-07 Thread Benedikt Ritter
Hello Gary, Gary Gregory schrieb am Di., 7. Juni 2016 um 04:01 Uhr: > Hi All: > > IMO. if [crypto] is to have a dependency on a logging framework, it should > be Log4j 2, not Commons Logging. Log4j 2 has an API module, which you can > pair with any number of implementations: Log4j's own Core, JU

Re: [crypto] On Java 6, really?

2016-06-07 Thread Benedikt Ritter
Hello Gary, Gary Gregory schrieb am Di., 7. Juni 2016 um 04:18 Uhr: > Are we really starting a new component on a dead platform like Java 6? > As far as I understand the whole point of crypto was to bring this kind of crypto performance to Java 6. > > Gary > > -- > E-Mail: garydgreg...@gmail.

Re: [crypto] On Java 6, really?

2016-06-07 Thread Marcelo Vanzin
I thought there was a discussion after the project was set up to move to Java 7? That being said I see that the pom still defines 1.6 as the target... On Mon, Jun 6, 2016 at 7:18 PM, Gary Gregory wrote: > Are we really starting a new component on a dead platform like Java 6? > > Gary > > -- > E-

Re: [BCEL] 5.3 is going to be messy

2016-06-07 Thread Andrey Loskutov
On Tuesday 07 June 2016 15:37 Benedikt Ritter wrote: > > > I propose we create the 5.x branch now. Those who want/need a compatible > > > release can work that out in that branch. All others can work on trunk to > > > get BCEL 6 out of the door with Java 7 and Java 8 compatibility. > > > > Sorry, I

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

2016-06-07 Thread Benedikt Ritter
Hi, any objections against reverting the package rename in trunk back to org.apache.bcel ? (For reasons see below) Benedikt -- Forwarded message - From: Andrey Loskutov Date: Di., 7. Juni 2016 um 17:55 Uhr Subject: Re: [BCEL] 5.3 is going to be messy To: Cc: Benedikt Ritter

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

2016-06-07 Thread sebb
Fine by me On 7 June 2016 at 17:00, Benedikt Ritter wrote: > Hi, > > any objections against reverting the package rename in trunk back to > org.apache.bcel ? (For reasons see below) > > Benedikt > > -- Forwarded message - > From: Andrey Loskutov > Date: Di., 7. Juni 2016 um 17:55

Re: [crypto] Logging dependency

2016-06-07 Thread sebb
On 7 June 2016 at 16:42, Benedikt Ritter wrote: > Hello Gary, > > Gary Gregory schrieb am Di., 7. Juni 2016 um > 04:01 Uhr: > >> Hi All: >> >> IMO. if [crypto] is to have a dependency on a logging framework, it should >> be Log4j 2, not Commons Logging. Log4j 2 has an API module, which you can >>

Re: [crypto] On Java 6, really?

2016-06-07 Thread sebb
Does the project *need* to use any Java7 features? Is it working OK now with Java 6 as the minimum? If the answers are No and Yes then moving to Java 7 seems to me to be unnecessary for the initial release. On 7 June 2016 at 16:49, Marcelo Vanzin wrote: > I thought there was a discussion after

[BCEL] next compatible release version number - 5.3 or 6.0?

2016-06-07 Thread sebb
There have been quite a lot of changes to BCEL since 5.2. Lots of places currently mention 6.0 (@since; JIRA; probably elsewhere). So whilst 5.3 might be OK as the next release version, it's going to be a lot of work to change all the references. I therefore propose we should use 6.0 for the bac

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

2016-06-07 Thread sebb
Also need to revert the Maven GA coords On 7 June 2016 at 17:06, sebb wrote: > Fine by me > > On 7 June 2016 at 17:00, Benedikt Ritter wrote: >> Hi, >> >> any objections against reverting the package rename in trunk back to >> org.apache.bcel ? (For reasons see below) >> >> Benedikt >> >> --

Re: [BCEL] next compatible release version number - 5.3 or 6.0?

2016-06-07 Thread Andrey Loskutov
On Tuesday 07 June 2016 17:15 sebb wrote: > There have been quite a lot of changes to BCEL since 5.2. > > Lots of places currently mention 6.0 (@since; JIRA; probably elsewhere). > > So whilst 5.3 might be OK as the next release version, it's going to > be a lot of work to change all the referenc

Re: [BCEL] next compatible release version number - 5.3 or 6.0?

2016-06-07 Thread sebb
On 7 June 2016 at 17:18, Andrey Loskutov wrote: > On Tuesday 07 June 2016 17:15 sebb wrote: >> There have been quite a lot of changes to BCEL since 5.2. >> >> Lots of places currently mention 6.0 (@since; JIRA; probably elsewhere). >> >> So whilst 5.3 might be OK as the next release version, it's

Re: [BCEL] next compatible release version number - 5.3 or 6.0?

2016-06-07 Thread Andrey Loskutov
On Tuesday 07 June 2016 17:26 sebb wrote: > On 7 June 2016 at 17:18, Andrey Loskutov wrote: > > On Tuesday 07 June 2016 17:15 sebb wrote: > >> There have been quite a lot of changes to BCEL since 5.2. > >> > >> Lots of places currently mention 6.0 (@since; JIRA; probably elsewhere). > >> > >> So w

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

2016-06-07 Thread Benedikt Ritter
Okay. - I'm going to revert the package rename. - We're going to create a binary compatible release for Java 7 and Java 8 support. - We will bump the major version number to indicate that there are massive changes in this release. Benedikt sebb schrieb am Di., 7. Juni 2016 um 18:16 Uhr: > Also

Re: [crypto] On Java 6, really?

2016-06-07 Thread Benedikt Ritter
Hello Sebb, sebb schrieb am Di., 7. Juni 2016 um 18:09 Uhr: > Does the project *need* to use any Java7 features? > > Is it working OK now with Java 6 as the minimum? > > If the answers are No and Yes then moving to Java 7 seems to me to be > unnecessary for the initial release. > I think people

Re: [BCEL] next compatible release version number - 5.3 or 6.0?

2016-06-07 Thread Ralph Goers
Actually, a 6.0 release with the same coordinates would imply that there are behavioral changes but the API is sufficiently compatible that you won’t get things like NoSuchMethodError. Ralph > On Jun 7, 2016, at 9:33 AM, Andrey Loskutov wrote: > > On Tuesday 07 June 2016 17:26 sebb wrote: >>

Re: [crypto] On Java 6, really?

2016-06-07 Thread James Carman
+1 On Tue, Jun 7, 2016 at 1:11 PM Benedikt Ritter wrote: > Hello Sebb, > > sebb schrieb am Di., 7. Juni 2016 um 18:09 Uhr: > > > Does the project *need* to use any Java7 features? > > > > Is it working OK now with Java 6 as the minimum? > > > > If the answers are No and Yes then moving to Java 7

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

2016-06-07 Thread Benedikt Ritter
I messed up the rename. I'm currently fixing that. Benedikt Ritter schrieb am Di., 7. Juni 2016 um 19:01 Uhr: > Okay. > > - I'm going to revert the package rename. > - We're going to create a binary compatible release for Java 7 and Java 8 > support. > - We will bump the major version number to

Re: [crypto] On Java 6, really?

2016-06-07 Thread sebb
On 7 June 2016 at 18:11, Benedikt Ritter wrote: > Hello Sebb, > > sebb schrieb am Di., 7. Juni 2016 um 18:09 Uhr: > >> Does the project *need* to use any Java7 features? >> >> Is it working OK now with Java 6 as the minimum? >> >> If the answers are No and Yes then moving to Java 7 seems to me to

Build failed in Jenkins: commons-bcel #1

2016-06-07 Thread Apache Jenkins Server
See -- Started by user britter [EnvInject] - Loading node environment variables. Building remotely on beam3 (beam) in workspace java.io.IOException: Failed to i

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

2016-06-07 Thread Andrey Loskutov
On Tuesday 07 June 2016 17:01 Benedikt Ritter wrote: > Okay. > > - I'm going to revert the package rename. > - We're going to create a binary compatible release for Java 7 and Java 8 > support. > - We will bump the major version number to indicate that there are massive > changes in this release.

Re: Build failed in Jenkins: commons-bcel #1

2016-06-07 Thread Ralph Goers
This build isn’t restricted as to where it can run. Should it be? I have no idea what server “beam3” actually is. Ralph > On Jun 7, 2016, at 10:30 AM, Apache Jenkins Server > wrote: > > See > > -- > Start

Re: Build failed in Jenkins: commons-bcel #1

2016-06-07 Thread Benedikt Ritter
I've just created the build. I'll have a look into this. Thank you for the pointer! Benedikt Ralph Goers schrieb am Di., 7. Juni 2016 um 19:52: > This build isn’t restricted as to where it can run. Should it be? I have > no idea what server “beam3” actually is. > > Ralph > > > On Jun 7, 2016, a

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

2016-06-07 Thread Benedikt Ritter
Andrey Loskutov schrieb am Di., 7. Juni 2016 um 19:49 Uhr: > On Tuesday 07 June 2016 17:01 Benedikt Ritter wrote: > > Okay. > > > > - I'm going to revert the package rename. > > - We're going to create a binary compatible release for Java 7 and Java 8 > > support. > > - We will bump the major ver

Re: [crypto] On Java 6, really?

2016-06-07 Thread Benedikt Ritter
Hello Sebb, sebb schrieb am Di., 7. Juni 2016 um 19:27 Uhr: > On 7 June 2016 at 18:11, Benedikt Ritter wrote: > > Hello Sebb, > > > > sebb schrieb am Di., 7. Juni 2016 um 18:09 Uhr: > > > >> Does the project *need* to use any Java7 features? > >> > >> Is it working OK now with Java 6 as the mi

Build failed in Jenkins: commons-bcel » Apache Commons BCEL #2

2016-06-07 Thread Apache Jenkins Server
See -- Established TCP socket on 43873 maven32-agent.jar already up to date maven32-interceptor.jar already up to date maven3-interceptor-commons.jar already up to date <===[JENKINS REMOTIN

Build failed in Jenkins: commons-bcel #2

2016-06-07 Thread Apache Jenkins Server
See -- [...truncated 626 lines...] [INFO] Building Apache Commons BCEL 6.0-SNAPSHOT [INFO] [INFO] [INFO] --- maven-clean-plugin:3.0.0:cl

Fwd: svn commit: r1747292 - /commons/proper/bcel/trunk/pom.xml

2016-06-07 Thread Benedikt Ritter
Is this something worth adding to commons parent? -- Forwarded message - From: Date: Di., 7. Juni 2016 um 20:31 Uhr Subject: svn commit: r1747292 - /commons/proper/bcel/trunk/pom.xml To: Author: britter Date: Tue Jun 7 18:31:37 2016 New Revision: 1747292 URL: http://svn.apach

Jenkins build is back to normal : commons-bcel » Apache Commons BCEL #3

2016-06-07 Thread Apache Jenkins Server
See - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org

Jenkins build is back to normal : commons-bcel #3

2016-06-07 Thread Apache Jenkins Server
See - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org

Re: [BCEL] next compatible release version number - 5.3 or 6.0?

2016-06-07 Thread Matt Sicker
What version number would you use to indicate that the API barely matches anymore then? Different group or artifact IDs? On 7 June 2016 at 12:12, Ralph Goers wrote: > Actually, a 6.0 release with the same coordinates would imply that there > are behavioral changes but the API is sufficiently com

Re: [BCEL] next compatible release version number - 5.3 or 6.0?

2016-06-07 Thread Ralph Goers
I have no problem with changing the artifactId to Foo2 and the packages to match and then starting at 1.0. I’d also be OK with increasing the version number. If the API really is incompatible IMO changing the artifactId is the best indicator of that. Ralph > On Jun 7, 2016, at 11:47 AM, Matt S

Re: [crypto] On Java 6, really?

2016-06-07 Thread Jochen Wiedmann
> Gary Gregory wrote on Tue., 7. Juni 2016 > >> Are we really starting a new component on a dead platform like Java 6? You are, of course, right, that the component is more than welcome to use another version. OTOH, given our latest experiences: Is this really someting, that we should care for?

Re: BCEL 6 API breakage

2016-06-07 Thread Andrey Loskutov
Hi all, following on the recent discussion and on the recent mails regarding the keeping the "old" BCEL namespace for 6.0 I just wanted to share my view on the BCEL API compatibility story, both from the API contributor/consumer sides, since I'm playing both roles in projects below. ### TL;DR

Re: [crypto] On Java 6, really?

2016-06-07 Thread sebb
I have just checked Oracle support for Java 6. The Support Life for Java 6 has been extended to Dec 2018 [1] I think this means that there are critical systems that cannot yet be updated to Java 7+. This does not mean that we should ensure that all Commons code still works on Java 6. But it shoul

Re: [crypto] On Java 6, really?

2016-06-07 Thread ecki
Hello, IBM, SAP and HP also maintain/support Java 6 runtimes for still some time. The audience get smaller and we should not restrict developers to use/provide Java 8 features but if a component team is happy to start a new project with Java 6, why not... (especially since there are also Hadoop

[NET] - FtpClient.getStatus(path) does not seem to be working as documented.

2016-06-07 Thread Clark Stuth
We think we've identified a mis-documented feature with FTPClient in commons-net, specifically the getStatus() methods. According to the FTP protocol, STAT should return server status information. However, according to the FTPClient documentation (https://github.com/apache/commons-net/blob/trunk/sr

Re: BCEL 6 API breakage

2016-06-07 Thread Matt Benson
AFAIK ASM already put its users through the pain of BC breakage when they went from an interface-based design to one based on abstract classes (3 to 4 or 4 to 5) but mixing versions across that boundary is the very definition of jar hell and is why ASM recommends that their classes be shaded into a

Re: [crypto] On Java 6, really?

2016-06-07 Thread Ralph Goers
I really don’t think the premier & extended support dates should really mean much, except as an indicator of how many users of that version might still exist. Basically, no new features are going to be added to Java so I don’t think we should be targeting new features there either. If there is

Re: [NET] - FtpClient.getStatus(path) does not seem to be working as documented.

2016-06-07 Thread ecki
According to RFC959 the STAT command can be used with a pathname (and without while transfer is ongoing). I think your problem in the sample output is, that your FTP command client is not really issuing a STAT command. I would recommand you use a raw TCP connection like netcat/telnet to debug th

Re: [BCEL] 5.3 is going to be messy

2016-06-07 Thread Gary Gregory
On Jun 7, 2016 3:17 AM, "Torsten Curdt" wrote: > > > > > 1) I don't believe we should force users to migrate their code in > > order to support java 7/8. > > > > ...and that line of thinking is why it feels like commons projects are > effectively stuck in the past. +1! > > No one needs to upgrad

Re: [Math] Commons Math (r)evolution

2016-06-07 Thread Gilles
On Mon, 6 Jun 2016 10:10:17 +0300, Artem Barger wrote: On Mon, Jun 6, 2016 at 3:49 AM, Gilles wrote: According to JIRA, among 180 issues currently targeted for the next major release (v4.0), 139 have been resolved (75 of which were not in v3.6.1). ​Huh, it's above of 75% completion :)​

[GitHub] commons-bcel pull request #4: Eclipse, Git and FindBugs metadata + 2 small f...

2016-06-07 Thread iloveeclipse
GitHub user iloveeclipse opened a pull request: https://github.com/apache/commons-bcel/pull/4 Eclipse, Git and FindBugs metadata + 2 small fixes Eclipse user who are trying to import the BCEL from Github currently face the problem that the project data is not there and configuration

Re: [crypto] On Java 6, really?

2016-06-07 Thread Gary Gregory
Let's not forget that customers are paying Oracle to get Java 6 updates. Gary On Jun 7, 2016 1:24 PM, "Ralph Goers" wrote: > I really don’t think the premier & extended support dates should really > mean much, except as an indicator of how many users of that version might > still exist. Basical

Re: [GitHub] commons-bcel pull request #4: Eclipse, Git and FindBugs metadata + 2 small f...

2016-06-07 Thread Gary Gregory
We do not store IDE metadata in repos, esp in their default locations. It makes a mess when people use different versions of different IDEs. Is M2E not working? Gary On Jun 7, 2016 2:33 PM, "iloveeclipse" wrote: > GitHub user iloveeclipse opened a pull request: > > https://github.com/apache/

Re: [Math] Commons Math (r)evolution

2016-06-07 Thread Gilles
On Mon, 6 Jun 2016 10:31:28 +0200, Eric Barnhill wrote: I am not a mathematician so I would not be able to play a particularly catholic role in commons-math. I don't think that the majority of contributors would have qualified themselves as "mathematician". In the current situation, it would

Re: [NET] - FtpClient.getStatus(path) does not seem to be working as documented.

2016-06-07 Thread sebb
On 6 June 2016 at 15:53, Clark Stuth wrote: > We think we've identified a mis-documented feature with FTPClient in > commons-net, specifically the getStatus() methods. According to the FTP > protocol, STAT should return server status information. However, > according to the FTPClient documentation

Re: [crypto] On Java 6, really?

2016-06-07 Thread Matt Sicker
I'd imagine that close to 100% of users who are on Java 6 are not upgrading anything else, either, nor would they be adding in new dependencies. Every Java 6 project I've come across lately has been in legacy maintenance mode (just like Java 6 itself). On 7 June 2016 at 16:47, Gary Gregory wrote:

Re: [crypto] Logging dependency

2016-06-07 Thread Chris Nauroth
Could you please elaborate on the argument for not logging at all? As a potential user of commons-crypto, I'll be reluctant to use it if it doesn't provide adequate diagnostic logging when something goes wrong. Regarding the choice of Log4J 2, this is also something that could prevent uptake. Fo

[GitHub] commons-bcel pull request #4: Eclipse, Git and FindBugs metadata + 2 small f...

2016-06-07 Thread asfgit
Github user asfgit closed the pull request at: https://github.com/apache/commons-bcel/pull/4 --- 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

Re: [crypto] Logging dependency

2016-06-07 Thread Matt Sicker
No library depends on (or should depend on) log4j 1.x as it ties you to log4j 1.x. Most projects have been using commons-logging or slf4j, but commons-logging has been superseded by log4j 2.x. Which logging library is actually used for configuration and the actual logging should be left to the end

Re: [crypto] Logging dependency

2016-06-07 Thread Gary Gregory
Log4j 2 provides minimal support for v1 properties file, and its not documented yet beyond the code itself. Log4j 2 does support the Log4j 1 API though, which is the most important level of compatibility. You make it sound like some folks will not adopt a new library and API because of the format

Re: [crypto] Logging dependency

2016-06-07 Thread ecki
Loggin Infrastructure can be quite complex including formatters, filters, api- or file based reconfiguration and so on. It can inckude dynamcally registering loggers and stuff. Switching the loggin backend is a (non-functional) major work in larger products/systems and app servers. It would be

Re: [crypto] Logging dependency

2016-06-07 Thread Chris Nauroth
No, properties vs. XML is not the issue. The issue is that it seems any migration from Log4J 1 to Log4J 2 invalidates existing configuration files. This is backward-incompatible for system administrators, because it forces them to translate their logging configuration to a new format before it wi

Re: [crypto] Logging dependency

2016-06-07 Thread Gary Gregory
On Jun 7, 2016 9:07 AM, "sebb" wrote: > > On 7 June 2016 at 16:42, Benedikt Ritter wrote: > > Hello Gary, > > > > Gary Gregory schrieb am Di., 7. Juni 2016 um > > 04:01 Uhr: > > > >> Hi All: > >> > >> IMO. if [crypto] is to have a dependency on a logging framework, it should > >> be Log4j 2, not

Re: [crypto] Logging dependency

2016-06-07 Thread Marcelo Vanzin
I'd be a little worried about switching to log4j 2. Two of the main targets of this library when it was proposed were Spark and Hadoop, both of which do not use log4j 2; you might be able to configure them too, but Spark at least has functionality built on top of log4j 1.2, and I'm not sure how wel

[CANCEL][VOTE] Apache Commons BeanUtils 1.9.3 RC1

2016-06-07 Thread Gary Gregory
This VOTE thread is canceled to address testing on Java 8. Gary On Tue, Jun 7, 2016 at 2:08 AM, Stian Soiland-Reyes wrote: > Agree that my other negatives are not blockers, but we really should be > supporting building with Java 1.8 when that is the current version. > > I would love to have a q

  1   2   >