Re: Build failed in Jenkins: commons-fileupload #9

On Sun, Jun 12, 2016 at 11:43 PM, Benedikt Ritter wrote: > Hi, > > I've created INFRA-12098 [1] for this. > Thank you Benedikt; I voted for the issue. Gary > > Benedikt > > [1] > https://issues.apache.org/jira/servicedesk/customer/portal/1/INFRA-12098 > > Benedikt Ritter schrieb am So., 12.

Re: svn commit: r1748095 - /commons/proper/csv/trunk/src/test/java/org/apache/commons/csv/CSVPrinterTest.java

On Sun, Jun 12, 2016 at 11:59 PM, Benedikt Ritter wrote: > Can we drop the dependency to lang3 now? > Nope, it's still used by the benchmarks. It's a test-only dependency, no big deal IMO. Gary > Benedikt > > schrieb am Mo., 13. Juni 2016 um 08:57: > > > Author: ggregory > > Date: Mon Jun 13

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

On 13 June 2016 at 03:06, Rob Tompkins wrote: > With all of that said, then I'm a: +1 (binding). AIUI this is a Common vote, as such only PMC member votes are considered binding. However you don't appear to be listed as a PMC member? > -Rob > >> On Jun 12, 2016, at 9:27 PM, Niall Pemberton >>

[compress] change behavior of bzip-output finalize?

Hi all I'm trying to bring a discussion from COMPRESS-357 over to the list. 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 fo

Jenkins build is still unstable: commons-net » Apache Commons Net #3

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

Jenkins build is still unstable: commons-net #3

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

Jenkins build is still unstable: commons-net #4

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

Jenkins build is still unstable: commons-net » Apache Commons Net #4

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

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

On 13 June 2016 at 10:19, Stefan Bodewig wrote: > Hi all > > I'm trying to bring a discussion from COMPRESS-357 over to the list. > > 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

Jenkins build is still unstable: commons-net » Apache Commons Net #5

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

Jenkins build is still unstable: commons-net #5

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

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

> > AIUI finalize() is not guaranteed to be called, so any code that > relies on it is liable to be disappointed from time to time. > > IMO at best one can use finalize() - *if* indeed it gets called - to > warn users that they have not closed a resource. > +1

Jenkins build is back to stable : commons-net #6

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 stable : commons-net » Apache Commons Net #6

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

[ALL] beware of URLs that represent file system locations

A Commons NET test was failing on Jenkins, but worked fine locally. And previously had been working on Continuum. Turns out this was because Jenkins uses path names of the form .../commons-net@n/. The test code was using the following to get the source location: java.security.CodeSource.getLocat

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

Thank you for bringing this up and for fixing the Problem! sebb schrieb am Mo., 13. Juni 2016 um 12:32: > A Commons NET test was failing on Jenkins, but worked fine locally. > And previously had been working on Continuum. > > Turns out this was because Jenkins uses path names of the form > .../c

[GitHub] commons-bcel pull request #6: Fix for BCEL-273

Github user iloveeclipse closed the pull request at: https://github.com/apache/commons-bcel/pull/6 --- 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 featu

Re: Re: [BCEL] Latest Clirr report

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 Serializable is not important for us at all, so I don't care. We had a discussion here on the list

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

> On Jun 13, 2016, at 4:29 AM, sebb wrote: > > On 13 June 2016 at 03:06, Rob Tompkins wrote: >> With all of that said, then I'm a: +1 (binding). > > AIUI this is a Common vote, as such only PMC member votes are > considered binding. > However you don't appear to be listed as a PMC member? Agr

Re: [VOTE] Move Apache Commons Primitives to dormant

Yes, but non-binding. On 13 June 2016 at 01:29, Benedikt Ritter wrote: > Matt Sicker schrieb am So., 12. Juni 2016 um 19:56 Uhr: > > > Chances are that this library may be obsoleted in Java 10 with value > types > > anyways, but that is years from now. > > > > So that's a +1 from your side? > >

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

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 ... > sebb schrieb am Mo., 13. Juni 2016 um 12:32: > >> A Commons NET test was failing on Jenkins, but worked fine locally. >> And previously had been working on Co

Re: [VOTE] Move Apache Commons Primitives to dormant

+1 12. jun. 2016 5.18 p.m. skrev "Benedikt Ritter" : > 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 sin

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

IMO, the primary advantagae of the incubator would be, that the project could have its own mailing list, etc. Thus, it would be independent from the happenings at dev@commons, etc. Which is, (IMO) exactly, what is required right now. Jochen On Sun, Jun 12, 2016 at 11:27 PM, Ralph Goers wrote:

Re: [BCEL] Latest Clirr report

On Mon, Jun 13, 2016 at 12:03 AM, sebb wrote: >> I'd suggest to leave the java.io.Serializable stuff, as it is. In >> practice, this will only be noticed, if anyone is actually >> serializing/deserializing these items, and I assume that the interface >> has been removed for a reason. (Meaning: Al

Re: [csv] Update to Java 8

7 (email) or 8 (subject)? I'm +1 for either - but I'm not sure if CSV would benefit much from Java 8 features, or are you thinking Java 8 Streams for CSV? (That would be really cool!) On 13 June 2016 at 03:18, Gary Gregory wrote: > Now that we pushed out 1.4, I plan on updating the platform re

Re: [csv] Update to Java 8

Java 7. Right now I'm thinking of adding convenience APIs for NIO Path, and old school File. Java 8 streams would be interesting for sure. Later for me... Gary On Mon, Jun 13, 2016 at 10:10 AM, Stian Soiland-Reyes wrote: > 7 (email) or 8 (subject)? > > I'm +1 for either - but I'm not sure if C

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

+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 letting everyone get a say in what direction

Re: [csv] Update to Java 8

NIO Path and AutoClosable try blocks are good enough reasons for me! :) On 13 June 2016 at 18:13, Gary Gregory wrote: > Java 7. Right now I'm thinking of adding convenience APIs for NIO Path, and > old school File. > > Java 8 streams would be interesting for sure. Later for me... > > Gary >

Re: [ALL] About binary compatibility

On 05.06.16 20:33, James Carman wrote: > Not quite. OSGi is a special case. It's much more restrictive than simple > J2SE, because it can be. In the general case, the public API for OSGi is > different from the public API for J2SE. Let's not confuse the two. My intention was to use the OSGi meta d

Re: [ALL] About binary compatibility

On Mon, Jun 13, 2016 at 8:49 PM, Thomas Vandahl wrote: > On 05.06.16 20:33, James Carman wrote: >> Not quite. OSGi is a special case. It's much more restrictive than simple >> J2SE, because it can be. In the general case, the public API for OSGi is >> different from the public API for J2SE. Let's

Re: [ALL] About binary compatibility

I'd rather not make it (the OSGi metadata) the "source of truth". On Mon, Jun 13, 2016 at 2:49 PM Thomas Vandahl wrote: > On 05.06.16 20:33, James Carman wrote: > > Not quite. OSGi is a special case. It's much more restrictive than simple > > J2SE, because it can be. In the general case, the pub

Re: [ALL] About binary compatibility

On 13.06.16 20:54, Jochen Wiedmann wrote: > On Mon, Jun 13, 2016 at 8:49 PM, Thomas Vandahl wrote: >> On 05.06.16 20:33, James Carman wrote: >>> Not quite. OSGi is a special case. It's much more restrictive than simple >>> J2SE, because it can be. In the general case, the public API for OSGi is >>

Re: [ALL] About binary compatibility

On 13.06.16 20:57, James Carman wrote: > I'd rather not make it (the OSGi metadata) the "source of truth". I'm not insisting on OSGi meta data but I strongly believe that one (single) source of truth is required. Suggest something else. Bye, Thomas. -

Re: [ALL] About binary compatibility

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! :). On Mon, Jun 13, 2016 at 3:05 PM Thomas Vandahl wrote: > On 13.06.16 20:57, James

Re: [ALL] About binary compatibility

Tomcat does this with a simple text file in the root of the distribution. Compare Tomcat 9 [1] (currently in development) with Tomcat 8 [2] (stable release). We actually don't guarantee very much but Tomcat is a very different type of project. The idea, however, could be re-used. Mark [1] http:/

Re: [VOTE] Move Apache Commons Primitives to dormant

+1 (binding) > [X] +1, yes move Primitives to dormant - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org

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

Hi. On Mon, 13 Jun 2016 01:30:20 +0100, Niall Pemberton wrote: On Sun, Jun 12, 2016 at 11:08 PM, Gilles wrote: On Sun, 12 Jun 2016 14:33:58 -0700, Dennis E. Hamilton wrote: -1 (non-binding) Reason for objection: I think the framing of this vote is confusing. 1. There appears to be les

Re: [csv] Update to Java 8

The ability to push Lambda's into a CSV processing library, to avoid users having to implement a "while(hasNext())" loop correctly/efficiently each time shouldn't underestimated. I have written a utility method myself to do this for my projects. It uses Jackson CSV right now but the pattern should

[lang] replace clirr with japicmp

Now that lang is compiled with java6, clirr is broken. Do we want to update to a more modern report like japicmp ? The pom change is something like com.github.siom79.japicmp japicmp-maven-plugin 0.8.0 true true

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 with Java 8. It shou

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 Uhr: > Author: ggregory

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 < >> https://siom79.github.io/japicmp/>? >> > > The site

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 > http://svn.apache.org/repos/asf/commons/proper/primitives/trunk I did n

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 japicmp < > > https://siom79.github.io/ja

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 use case. > Small i

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 java6, clirr is broken. Do we want to > >> update to a more modern

[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

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 schrieb am Di., 14. Juni 2016 um > 07:29 > > Uhr: > > > > > >> Now that lang is co

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 going through > incubat

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 > Serializable is not important

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 ... > > > sebb schrieb am Mo., 13. Juni 2016

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 strategy upon clirr. So I wonder whether we > > sho

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 through >> incubation). We

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 wheel!" http://www.keystonedevelopment.

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 the current state of trunk?! Sure. Sooner is

[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: [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 upon clirr. So I wonder whether we > >> should foster

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 >> solve the license problem. >> > > Sounds lik

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 let