Re: [ALL] Volunteers for a Math IPMC?

On Tue, Jun 14, 2016 at 11:29 PM, John D. Ament wrote: > We generally expect some kind of backing community to bring this to. We > have seen pretty consistently that starting from an empty community doesn't > work. It doesn't mean that it's impossible, but very hard to

Re: Build failed in Jenkins: commons-net #7

Looks like a new Jenkins related problem. The ClassNotFoundException we saw in the build jobs of FileUpload and Validator seem to have go away. Apache Jenkins Server schrieb am Mi., 15. Juni 2016 um 02:23: > See >

Re: [lang] replace clirr with japicmp

Hello Charles, as I said in response to Jochen, I'm fine with giving japicmp a try. But for tools as important to us as clirr, I've come to the conclusion that it would be better to have them at the ASF. Benedikt Charles Honton schrieb am Mi., 15. Juni 2016 um 06:45: >

Re: [lang] replace clirr with japicmp

According to clirr-maven-plugin pom, it depends on net.sf.clirr:chirr-core:0.6 (released on 11-Feb-2006) org.apache.bcel:bel:5.2 (release on 13-Jun-2006) net.sf.clirr:chirr-core:0.6 had an excluded dependency on bcel:bel:5.1 (released 22-Nov-2005 and modified 20-Oct-2010) Yes, japicmp has

Re: [compress] change behavior of bzip-output finalize?

On 2016-06-13, Stefan Bodewig wrote: > The bzip2 output stream has a finish method that is used to ensure all > data has been written to the stream and a separate close method that > invokes finish. And it overrides finalize to invoke finish in case > people have forgotten to close the stream -

Build failed in Jenkins: commons-net #7

See Changes: [sebb] Unnecessary; done by connect(String,int) -- [...truncated 170 lines...] AU src/main/java/org/apache/commons/net/ftp/parser/FTPFileEntryParserFactory.java AU

Jenkins build is back to normal : commons-validator #5

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

Jenkins build is unstable: commons-fileupload #12

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

Jenkins build is unstable: commons-fileupload » Apache Commons FileUpload #12

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

Re: [ALL] Volunteers for a Math IPMC?

On Tue, Jun 14, 2016 at 2:29 PM, John D. Ament wrote: > We generally expect some kind of backing community to bring this to. We > have seen pretty consistently that starting from an empty community doesn't > work. It doesn't mean that it's impossible, but very hard to

Re: [ALL] Volunteers for a Math IPMC?

Generally speaking, incubation is to nurture a community to adopting the Apache Way. This includes self governance, community growth and licensing policies. We generally expect some kind of backing community to bring this to. We have seen pretty consistently that starting from an empty

Re: svn commit: r1748347 - in /commons/proper/csv/trunk/src: changes/changes.xml main/java/org/apache/commons/csv/CSVFormat.java test/java/org/apache/commons/csv/CSVPrinterTest.java

Just as an info, [configuration] has a similar problem. There is a FileHandler class (in the io subpackage) which allows defining a target file in various ways and does the conversion to streams. Oliver Am 14.06.2016 um 18:33 schrieb Benedikt Ritter: > How about something like: > > on

Re: [ALL] Volunteers for a Math IPMC?

On Sat, Jun 11, 2016 at 12:25 PM, James Carman wrote: > We (the Commons PMC) have not decided yet what to do, but I just wanted to > gauge the interest in joining the math IPMC if we choose to go TLP by way > of the incubator. The idea would be that math (whatever its

Re: [ALL] Volunteers for a Math IPMC?

On Tue, Jun 14, 2016 at 8:54 PM, Ted Dunning wrote: > Looking back through the discussion, it is a bit of a problem that one of > the major reasons given for the fork is that the team thought that they > didn't have a large enough PMC and that incubation wouldn't get them

Re: [ALL] Volunteers for a Math IPMC?

Looking back through the discussion, it is a bit of a problem that one of the major reasons given for the fork is that the team thought that they didn't have a large enough PMC and that incubation wouldn't get them enough additional contributors. That made it seem like the project should go

Re: [DISCUSS] Brining clirr to the ASF?

Thank you for the clarification, Dennis! Dennis E. Hamilton schrieb am Di., 14. Juni 2016 um 19:57: > [Chiming in lest those on the Commons PMC who know the answer don't and > leave the LGPL question dangling.] > > > -Original Message- > > From: Gary Gregory

Re: [ALL] Volunteers for a Math IPMC?

I thought this had been made clear. Several months Commons voted to make Math a TLP. But shortly after that most of the people involved with Commons Math felt that a TLP at the ASF would not work for them, so they forked the project and left, effectively voiding the TLP vote since the proposed

RE: [DISCUSS] Brining clirr to the ASF?

[Chiming in lest those on the Commons PMC who know the answer don't and leave the LGPL question dangling.] > -Original Message- > From: Gary Gregory [mailto:garydgreg...@gmail.com] > Sent: Monday, June 13, 2016 23:23 > To: Commons Developers List > Subject: Re:

Re: [ALL] Volunteers for a Math IPMC?

If you have a functioning community around Commons Math already, why do you feel you need Incubation? People on a Math TLP would come out of the Commons PMC and simply submit a Board Resolution, and I doubt that there would be any objects. There are no legal concerns, no community training, no

Re: svn commit: r1748347 - in /commons/proper/csv/trunk/src: changes/changes.xml main/java/org/apache/commons/csv/CSVFormat.java test/java/org/apache/commons/csv/CSVPrinterTest.java

How about something like: on CSVFormat: public PrintingOps print() And the PrintingOps class would implement all the different printing methods, combining the CSVFormat and a printer. The call would look like: CSVFormat.EXCEL.print().contentsOf(file, StandardCharsets.UTF_8) sebb

RE: [BCEL] Release Candidate on Thursday

People, please look at the data base before you post. There has been a fix available since August of last year. (Shortly before the last effort to produce a 6.0 pooped out.) There is also a test case that demonstrates the problem. > -Original Message- > From: Andrey Loskutov

RE: [BCEL] Release Candidate on Thursday

1) You mentioned "private Daikon" build. Can you propose a patch? 2) The bcel-243 reads as an enhancement (some functionality from 1.8 is missing). Is this true? Are there any regressions or any errors which can be demonstrated with current trunk state? It would be nice to add this info to Jira

Re: [BCEL] Release Candidate on Thursday

Is it not a showstopper for BCEL itself, though. Do we have a solution to these two issues readily available? Is it something that we need to noodle about for a little while and maybe we can just get a release out while we do that? On Tue, Jun 14, 2016 at 12:04 PM Mark Roberts

RE: [BCEL] Release Candidate on Thursday

243 is a show stopper for Daikon. It will continue to be shipped with our private version of BCEL if it is not fixed. > -Original Message- > From: James Carman [mailto:ja...@carmanconsulting.com] > Sent: Tuesday, June 14, 2016 8:51 AM > To: Commons Developers List > Subject: Re: [BCEL]

Re: [BCEL] Release Candidate on Thursday

Hello Mark, thank you for pointing this out. Saves me a lot of time :-) I will have a look when Jira is reachable again. Benedikt Mark Roberts schrieb am Di., 14. Juni 2016 um 17:50: > I can tell you right now I would vote -1 as you have not picked up the fix > for

Re: [BCEL] Release Candidate on Thursday

Are they show stoppers? On Tue, Jun 14, 2016 at 11:50 AM Mark Roberts wrote: > I can tell you right now I would vote -1 as you have not picked up the fix > for https://issues.apache.org/jira/browse/BCEL-243. > > Also, I think

RE: [BCEL] Release Candidate on Thursday

I can tell you right now I would vote -1 as you have not picked up the fix for https://issues.apache.org/jira/browse/BCEL-243. Also, I think https://issues.apache.org/jira/browse/BCEL-195 is fixed, but has not been closed. Thank you, Mark Roberts > -Original Message- > From: Benedikt

Re: svn commit: r1748347 - in /commons/proper/csv/trunk/src: changes/changes.xml main/java/org/apache/commons/csv/CSVFormat.java test/java/org/apache/commons/csv/CSVPrinterTest.java

On 14 June 2016 at 16:27, Gary Gregory wrote: > On Jun 14, 2016 5:19 AM, "James Carman" wrote: >> >> Are Readers that hard to create? > > No, but remembering how to do this is a pain: > > File out = ... > > Charset charset = ... > >

Re: svn commit: r1748347 - in /commons/proper/csv/trunk/src: changes/changes.xml main/java/org/apache/commons/csv/CSVFormat.java test/java/org/apache/commons/csv/CSVPrinterTest.java

Can folks perhaps combine commons-io to help? On Tue, Jun 14, 2016 at 11:27 AM Gary Gregory wrote: > On Jun 14, 2016 5:19 AM, "James Carman" > wrote: > > > > Are Readers that hard to create? > > No, but remembering how to do this is a pain: >

Re: svn commit: r1748347 - in /commons/proper/csv/trunk/src: changes/changes.xml main/java/org/apache/commons/csv/CSVFormat.java test/java/org/apache/commons/csv/CSVPrinterTest.java

On Jun 14, 2016 5:19 AM, "James Carman" wrote: > > Are Readers that hard to create? No, but remembering how to do this is a pain: File out = ... Charset charset = ... CSVPrinter printer = new CSVPrinter(new OutputStreamWriter(new

Re: Re: [ALL] About binary compatibility

Perhaps the new ASM-based replacement for CLIRR could have those as one of its "components" in its TLP? On Tue, Jun 14, 2016 at 11:00 AM Matt Benson wrote: > On Jun 14, 2016 9:55 AM, "Gary Gregory" wrote: > > > > > > On Jun 14, 2016 7:45 AM, "Matt

Re: Re: [ALL] About binary compatibility

On Jun 14, 2016 9:55 AM, "Gary Gregory" wrote: > > > On Jun 14, 2016 7:45 AM, "Matt Benson" wrote: > > > > On Tue, Jun 14, 2016 at 2:14 AM, Andrey Loskutov wrote: > > > > > I like the way Eclipse it does for years: > > > > > > 1)

Re: [crypto] On Java 6, really?

The trick is if we want to require a major version upgrade to bump JDK levels. That's why you'd want to bump it now if possible. On Tue, Jun 14, 2016 at 10:41 AM Matt Sicker wrote: > I'd prefer to get to 1.7 as soon as possible, but if the API is ready for a > 1.0 release

Re: [crypto] On Java 6, really?

On Jun 14, 2016 7:51 AM, "James Carman" wrote: > > The trick is if we want to require a major version upgrade to bump JDK > levels. That's why you'd want to bump it now if possible. We've not required major version bumps for Java bumps in the past. Gary > > On Tue,

Re: Re: [ALL] About binary compatibility

On Jun 14, 2016 7:45 AM, "Matt Benson" wrote: > > On Tue, Jun 14, 2016 at 2:14 AM, Andrey Loskutov wrote: > > > I like the way Eclipse it does for years: > > > > 1) Everything inside **/internal/ packages is non API by definition > > 2) MANIFEST.MF to use

Re: Re: [ALL] About binary compatibility

On Tue, Jun 14, 2016 at 2:14 AM, Andrey Loskutov wrote: > I like the way Eclipse it does for years: > > 1) Everything inside **/internal/ packages is non API by definition > 2) MANIFEST.MF to use OSGI "Export-Package" attribute for "published" > packages > 3) Javadoc @noextend

Re: [crypto] On Java 6, really?

I'd prefer to get to 1.7 as soon as possible, but if the API is ready for a 1.0 release already, we could wait for 1.1 or 1.2 before going full 1.7. On 14 June 2016 at 06:16, Stian Soiland-Reyes wrote: > +1 to JDK7 on crypto > On 14 Jun 2016 10:25 a.m., "Sun, Dapeng"

Re: [DISCUSS] Brining clirr to the ASF?

For any Gradle users, Cédric put together a little Gradle plugin based around the japicmp library which we use in Groovy, see here: https://github.com/apache/groovy/blob/master/gradle/binarycompatibility.gradle Cheers, Paul. On Tue, Jun 14, 2016 at 9:56 PM, James Carman

Re: svn commit: r1748347 - in /commons/proper/csv/trunk/src: changes/changes.xml main/java/org/apache/commons/csv/CSVFormat.java test/java/org/apache/commons/csv/CSVPrinterTest.java

Are Readers that hard to create? On Tue, Jun 14, 2016 at 2:17 AM Gary Gregory wrote: > On Mon, Jun 13, 2016 at 11:13 PM, Benedikt Ritter > wrote: > > > I don't like how we're evolving CSVFormat. It is becoming a dumping > ground > > for anything that

Re: [DISCUSS] Brining clirr to the ASF?

+1 to Jochen's idea and I'd love to contribute to that effort! On Tue, Jun 14, 2016 at 2:40 AM Jochen Wiedmann wrote: > On Tue, Jun 14, 2016 at 8:23 AM, Gary Gregory > wrote: > > >> as Jochen has pointed out, Clirr seems to be unmaintained.

RE: [crypto] On Java 6, really?

+1 to JDK7 on crypto On 14 Jun 2016 10:25 a.m., "Sun, Dapeng" wrote: > > Then next release(after 1.0.0) must be a major release you mean? > > If there are no potential users looking for JDK 1.6, dropping now should > be good idea IMO. > > Thank Uma, I just checked there is

Re: [DISCUSS] Brining clirr to the ASF?

As Clirr is internally based on BCEL, I'd rather see us build a new tool on top of ASM, which is very well maintained. Besides, that would solve the license problem. Sounds like a existing idea. I'm interested in to contribute. -- barthel

Re: svn commit: r1748347 - in /commons/proper/csv/trunk/src: changes/changes.xml main/java/org/apache/commons/csv/CSVFormat.java test/java/org/apache/commons/csv/CSVPrinterTest.java

On 14 June 2016 at 07:17, Gary Gregory wrote: > On Mon, Jun 13, 2016 at 11:13 PM, Benedikt Ritter > wrote: > >> I don't like how we're evolving CSVFormat. It is becoming a dumping ground >> for anything that may be useful or convenient. The more

Re: svn commit: r1748347 - in /commons/proper/csv/trunk/src: changes/changes.xml main/java/org/apache/commons/csv/CSVFormat.java test/java/org/apache/commons/csv/CSVPrinterTest.java

On 14 June 2016 at 07:13, Benedikt Ritter wrote: > I don't like how we're evolving CSVFormat. It is becoming a dumping ground > for anything that may be useful or convenient. The more methods we add, the > harder it becomes for users to find the right method for their use

RE: [crypto] On Java 6, really?

> Then next release(after 1.0.0) must be a major release you mean? > If there are no potential users looking for JDK 1.6, dropping now should be > good idea IMO. Thank Uma, I just checked there is no much changes on upgrading JDK to 1.7, I think we can upgrade before this release. Is there

Re: [VOTE] Move Apache Commons Primitives to dormant

+1 (IMO, primitives is redundant anyways, because of commons-lang) Jochen On Tue, Jun 14, 2016 at 9:06 AM, Jörg Schaible wrote: > Benedikt Ritter wrote: > >> Hi, >> >> there hasn't been any activity in the primitives component for a long >> while: >> >> - last

Re: [crypto] On Java 6, really?

On 6/14/16, 1:23 AM, "Gary Gregory" wrote: >On Tue, Jun 14, 2016 at 1:21 AM, Gangumalla, Uma > >wrote: > >> Then next release(after 1.0.0) must be a major release you mean? >> If there are no potential users looking for JDK 1.6, dropping now

Re: [crypto] On Java 6, really?

On Tue, Jun 14, 2016 at 1:21 AM, Gangumalla, Uma wrote: > Then next release(after 1.0.0) must be a major release you mean? > If there are no potential users looking for JDK 1.6, dropping now should > be good idea IMO. > > I also remembered that we wanted to mark 1.0.0

Re: [crypto] On Java 6, really?

Then next release(after 1.0.0) must be a major release you mean? If there are no potential users looking for JDK 1.6, dropping now should be good idea IMO. I also remembered that we wanted to mark 1.0.0 release as Alpha right? (just a question) Regards, Uma On 6/14/16, 12:27 AM, "Sun, Dapeng"

RE: [crypto] On Java 6, really?

Thank Gary, Benedikt, Marcelo, sebb, James, Jochen, ecki, Ralph and Matt for all your input. How about make a conservative decision: regarding the first release(1.0.0), we keep the JDK version as 1.6, and we wouldn't support JDK 1.6 for the releases after 1.0.0. Regards Dapeng -Original

Re: Re: [ALL] About binary compatibility

I like the way Eclipse it does for years: 1) Everything inside **/internal/ packages is non API by definition 2) MANIFEST.MF to use OSGI "Export-Package" attribute for "published" packages 3) Javadoc @noextend tag for classes not intended to be extended 4) Javadoc @noimplement tag for interfaces

Re: [VOTE] Move Apache Commons Primitives to dormant

Benedikt Ritter wrote: > Hi, > > there hasn't been any activity in the primitives component for a long > while: > > - last release dates back to 2003-11-05 > - using svn log -l 50 > http://svn.apache.org/repos/asf/commons/proper/primitives/trunk I did not > find a single commit that changed any

Re: [ALL] About binary compatibility

Hi, James Carman wrote: > Agree we should have a "source of truth". Is there something wrong with > using an "internal" or "impl" package name? The bundle plugin for OSGi > doesn't export these by default, which would be a nice side effect! :). While it is a step in the right direction, a

Re: [VOTE] Move Commons Math to TLP (again)...

Stian Soiland-Reyes wrote: > +1 for a move to Incubator, rather than a TLP, as Math now needs to > find its new ground and direction, and in particular grow its active > developer base. > > > The incubator is great for reducing the distance for moving from > contributor to committer, and for

Re: [DISCUSS] Brining clirr to the ASF?

On Tue, Jun 14, 2016 at 8:50 AM, Benedikt Ritter wrote: > Jochen Wiedmann schrieb am Di., 14. Juni 2016 >> As Clirr is internally based on BCEL, I'd rather see us build a new >> tool on top of ASM, which is very well maintained. Besides, that would

Re: [DISCUSS] Brining clirr to the ASF?

Jochen Wiedmann schrieb am Di., 14. Juni 2016 um 08:40 Uhr: > On Tue, Jun 14, 2016 at 8:23 AM, Gary Gregory > wrote: > > >> as Jochen has pointed out, Clirr seems to be unmaintained. However we > build > >> a good part of our release strategy

[BCEL] Release Candidate on Thursday

Hi, I'm going to try to create an RC for BCEL 6.0 on friday. Please have a look at the current state of the code base and report any issues you see. Thank you! Benedikt

Re: Re: Re: [BCEL] Latest Clirr report

> From: "Benedikt Ritter" > To: "Commons Developers List" > Subject: Re: Re: [BCEL] Latest Clirr report > > So from my limited FindBugs point of view we can release BCEL6 as it is > > today on trunk. > > > > Okay, so you would like to see an RC with

Re: Re: [BCEL] Latest Clirr report

On Tue, Jun 14, 2016 at 8:24 AM, Benedikt Ritter wrote: > Andrey Loskutov schrieb am Mo., 13. Juni 2016 um > 14:15 Uhr: > Okay, so you would like to see an RC with the current state of trunk?! +1 Jochen -- The next time you hear: "Don't reinvent the

Re: [DISCUSS] Brining clirr to the ASF?

On Tue, Jun 14, 2016 at 8:23 AM, Gary Gregory wrote: >> as Jochen has pointed out, Clirr seems to be unmaintained. However we build >> a good part of our release strategy upon clirr. So I wonder whether we >> should foster bringing clirr to the ASF (for example by going

Re: [DISCUSS] Brining clirr to the ASF?

Gary Gregory schrieb am Di., 14. Juni 2016 um 08:23 Uhr: > On Mon, Jun 13, 2016 at 11:19 PM, Benedikt Ritter > wrote: > > > Hi, > > > > as Jochen has pointed out, Clirr seems to be unmaintained. However we > build > > a good part of our release

Re: [ALL] beware of URLs that represent file system locations

Well, I created the Jenkins Job, so we both hat our share ;-) sebb schrieb am Mo., 13. Juni 2016 um 16:03 Uhr: > On 13 June 2016 at 12:43, Benedikt Ritter wrote: > > Thank you for bringing this up and for fixing the Problem! > > I probably caused it ... >

Re: Re: [BCEL] Latest Clirr report

Andrey Loskutov schrieb am Mo., 13. Juni 2016 um 14:15 Uhr: > Hi, > > from FindBugs point of view, the biggest issue was the removal of > "intermediate" org.apache.bcel.classfile.StackMapTable / > org.apache.bcel.classfile.StackMapTableEntry classes. The removal of >

Re: [DISCUSS] Brining clirr to the ASF?

On Mon, Jun 13, 2016 at 11:19 PM, Benedikt Ritter wrote: > Hi, > > as Jochen has pointed out, Clirr seems to be unmaintained. However we build > a good part of our release strategy upon clirr. So I wonder whether we > should foster bringing clirr to the ASF (for example by

Re: [lang] replace clirr with japicmp

On Mon, Jun 13, 2016 at 11:18 PM, Benedikt Ritter wrote: > Jochen Wiedmann schrieb am Di., 14. Juni 2016 > um 08:14 Uhr: > > > On Tue, Jun 14, 2016 at 8:11 AM, Benedikt Ritter > > wrote: > > > > > Charles Honton

[DISCUSS] Brining clirr to the ASF?

Hi, as Jochen has pointed out, Clirr seems to be unmaintained. However we build a good part of our release strategy upon clirr. So I wonder whether we should foster bringing clirr to the ASF (for example by going through incubation). We're probably not the only ASF project using Clirr. Benedikt

Re: [lang] replace clirr with japicmp

Jochen Wiedmann schrieb am Di., 14. Juni 2016 um 08:14 Uhr: > On Tue, Jun 14, 2016 at 8:11 AM, Benedikt Ritter > wrote: > > > Charles Honton schrieb am Di., 14. Juni 2016 um 07:29 > Uhr: > > > >> Now that lang is compiled with

Re: svn commit: r1748347 - in /commons/proper/csv/trunk/src: changes/changes.xml main/java/org/apache/commons/csv/CSVFormat.java test/java/org/apache/commons/csv/CSVPrinterTest.java

On Mon, Jun 13, 2016 at 11:13 PM, Benedikt Ritter wrote: > I don't like how we're evolving CSVFormat. It is becoming a dumping ground > for anything that may be useful or convenient. The more methods we add, the > harder it becomes for users to find the right method for their

Re: [lang] replace clirr with japicmp

On Mon, Jun 13, 2016 at 11:11 PM, Benedikt Ritter wrote: > Hello Charles, > > Charles Honton schrieb am Di., 14. Juni 2016 um 07:29 > Uhr: > > > Now that lang is compiled with java6, clirr is broken. Do we want to > > update to a more modern report like

Re: [VOTE] Move Apache Commons Primitives to dormant

My +1 Benedikt Ritter schrieb am So., 12. Juni 2016 um 17:17 Uhr: > Hi, > > there hasn't been any activity in the primitives component for a long > while: > > - last release dates back to 2003-11-05 > - using svn log -l 50 >

Re: [lang] replace clirr with japicmp

On Tue, Jun 14, 2016 at 8:11 AM, Benedikt Ritter wrote: > Charles Honton schrieb am Di., 14. Juni 2016 um 07:29 Uhr: > >> Now that lang is compiled with java6, clirr is broken. Do we want to >> update to a more modern report like japicmp < >>

Re: svn commit: r1748347 - in /commons/proper/csv/trunk/src: changes/changes.xml main/java/org/apache/commons/csv/CSVFormat.java test/java/org/apache/commons/csv/CSVPrinterTest.java

I don't like how we're evolving CSVFormat. It is becoming a dumping ground for anything that may be useful or convenient. The more methods we add, the harder it becomes for users to find the right method for their use case. Benedikt schrieb am Di., 14. Juni 2016 um 07:53

Re: [lang] replace clirr with japicmp

Hello Charles, Charles Honton schrieb am Di., 14. Juni 2016 um 07:29 Uhr: > Now that lang is compiled with java6, clirr is broken. Do we want to > update to a more modern report like japicmp < > https://siom79.github.io/japicmp/>? > The site build is only broken when build