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 packag

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: 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: [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: [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" w

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 release as Alpha right? > (j

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 should >> be good idea IMO. >> >> I also remembered t

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 release dates back to 2003-11-05 >

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 any

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 case. +1 And the more m

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 methods we add, the >> harder it becomes for users

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: [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 no much changes on upgr

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. However we > build > >> a good part of our release str

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 may be useful or convenient. The more method

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 wrote: > +1 to Jochen's

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" wrote: > > > > Then next re

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 tag for classes not

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 OSGI "Export-Package" attribute for "publ

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, Jun 14, 2016 at 10:41 AM Matt

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 already, we could wait

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) Everything inside **/internal/ packages is non API by definition >

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 Benson" wrote: > > > > > > On Tue, Jun 14, 201

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 FileOutputStream(out), charset), format); Instead

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

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 = ... > > CSVPrinter printer = new CSVPrinter(new OutputStr

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: [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 https://issues.apache.org/jira/browse/BCEL-195 is fixed, > but has not

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 https://issues.apache.org/ji

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

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 wrote: > 243 is a

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

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

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 schrieb am Di.

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 nee

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: [DISCUSS] Brining clirr to

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?

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 [mailto:garydgreg...@gmail.co

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 forward

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 enough > additional contr

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 name may be), > would go thro

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

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 community

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 do. > Frankly, the except

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

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

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 src/main/

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

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 singl

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: > According to clirr-maven

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 > > Changes: > > [sebb] Unnece

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 do. Understood. On the o

Re: [lang] replace clirr with japicmp

On Wed, Jun 15, 2016 at 6:45 AM, Charles Honton wrote: > 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 > (releas

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

The last failure was due to errors in the test suite. Should be fixed. Sorry, Jochen On Wed, Jun 15, 2016 at 1:51 AM, Apache Jenkins Server wrote: > See > > -- The next time you hear: "Don't reinv