Re: [crypto] Logging dependency

I am not sure what you are speaking to here. No logging facade does any better with fronting Log4j 1 than Log4j 2 does. You cannot manipulate the logging configuration through any facade - including SLF4J’s and Commons Logging. Ralph > On Jun 7, 2016, at 3:55 PM, e...@zusammenkunft.net wrote:

Re: [crypto] Logging dependency

Here we have been arguing about whether to move to Java 7 (or 8) or not and you are saying users need to stick with Log4j 1. Wow. Log4j 1.2 is still at Java 1.2, so it can’t even use java.util.concurrent. The Logging PMC officially announced EOL for Log4j last August [1]. But in reality it

Re: BCEL 6 API breakage

I have almost certainly the largest FindBugs plug in.  I expect it will take less than 15 minutes to update it to use a breaking package/api version of BCEL if it ever was to go out.  I've got this fancy thing called a text editor with search/replace. I pity those who haven't adopted this new

Re: BCEL 6 API breakage

While I am a big fan of ASM it feels a bit strange to put it forth as a great example in this regard. Indeed some ASM API changes were simple - some weren't so much. And many required source level changes. Some changes are often just a quick refactor away. If we'd allow just that we'd be a good

Re: [BCEL] 5.3 is going to be messy

> > >> 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 they are popular with users. >

[CANCEL][VOTE] Apache Commons BeanUtils 1.9.3 RC1

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

Re: [crypto] Logging dependency

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

Re: [crypto] Logging dependency

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

Re: [crypto] Logging dependency

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

Re: [crypto] Logging dependency

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

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

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

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

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

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.

Re: [crypto] On Java 6, really?

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

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

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

Re: [Math] Commons Math (r)evolution

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: [GitHub] commons-bcel pull request #4: Eclipse, Git and FindBugs metadata + 2 small f...

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

Re: [crypto] On Java 6, really?

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

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

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

Re: [Math] Commons Math (r)evolution

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

Re: [BCEL] 5.3 is going to be messy

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

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

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

Re: [crypto] On Java 6, really?

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: BCEL 6 API breakage

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

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

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?

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

Re: [crypto] On Java 6, really?

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

Re: BCEL 6 API breakage

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?

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

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

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

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

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

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

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 » Apache Commons BCEL #3

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

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

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

Build failed in Jenkins: commons-bcel #2

See -- [...truncated 626 lines...] [INFO] Building Apache Commons BCEL 6.0-SNAPSHOT [INFO] [INFO] [INFO] ---

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

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

Re: [crypto] On Java 6, really?

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

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

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

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

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

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

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

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

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.

Build failed in Jenkins: commons-bcel #1

See -- Started by user britter [EnvInject] - Loading node environment variables. Building remotely on beam3 (beam) in workspace java.io.IOException: Failed to

Re: [crypto] On Java 6, really?

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

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

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

Re: [crypto] On Java 6, really?

+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

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

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

Re: [crypto] On Java 6, really?

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

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

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

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

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

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

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

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

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

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

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

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

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

Re: [crypto] On Java 6, really?

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

Re: [crypto] Logging dependency

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

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

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

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

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:

Re: [BCEL] 5.3 is going to be messy

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,

Re: [crypto] On Java 6, really?

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

Re: [crypto] On Java 6, really?

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

Re: [crypto] Logging dependency

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

Re: BCEL 6 API breakage

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

Re: [BCEL] 5.3 is going to be messy

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 >

Re: [BCEL] 5.3 is going to be messy

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

Re: [BCEL] 5.3 is going to be messy

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

Re: [BCEL] Move to Git?

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

Re: [BCEL] Move to Git?

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

Re: [BCEL] 5.3 is going to be messy

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

Re: [BCEL] Move to Git?

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: svn commit: r1747238 - /commons/proper/io/trunk/src/main/java/org/apache/commons/io/FileUtils.java

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=rev >> Log: >> Now using Java 7 so

Re: [BCEL] Move to Git?

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

Re: [BCEL] Move to Git?

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

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

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=rev > Log: > Now using Java 7 so can avoid the deprecated constant > > Modified: > >

Re: [BCEL] 5.3 is going to be messy

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

Re: [BCEL] 5.3 is going to be messy

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

Re: BCEL 6 API breakage

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

Re: BCEL 6 API breakage

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

Re: [BCEL] 5.3 is going to be messy

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

Re: BCEL 6 API breakage

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

Re: [BCEL] Move to Git?

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

Re: [BCEL] 5.3 is going to be messy

+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

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

+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

Re: [BCEL] 5.3 is going to be messy

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

Re: [BCEL] 5.3 is going to be messy

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

Re: [BCEL] Move to Git?

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

Re: [net] Javadoc format

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: > > > > /** > > ... > > */ > >

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

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:

Re: [net] Javadoc format

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:

Re: [BCEL] 5.3 is going to be messy

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

Re: BCEL 6 API breakage

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.

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

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=rev > Log: (empty) Please don't use empty log messages. What was this change about?

Re: [VOTE] Apache Commons BeanUtils 1.9.3 RC1

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: [VOTE][LAZY] Migrate Apache Commons CSV to git

+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

Re: [BCEL] Move to Git?

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

Re: [BCEL] Move to Git?

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

[BCEL] Move to Git?

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

Build failed in Jenkins: Commons-configuration #6

See -- [...truncated 515 lines...] AU src/main/java/org/apache/commons/configuration2/reloading/ReloadingEvent.java AU

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

+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

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

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

  1   2   >