[GitHub] commons-fileupload issue #5: Update DiskFileItem.java: Avoiding NPE when not...

Github user garydgregory commented on the issue: https://github.com/apache/commons-fileupload/pull/5 You might have to catch up your fork to the HEAD of the master branch. See https://garygregory.wordpress.com/2016/11/10/how-to-catch-up-my-git-fork-to-master/ --- If your project is

Re: [ALL] Version number(s) for modular components

Gilles wrote: > On Mon, 28 Nov 2016 07:31:36 -0700, Apache wrote: >> Gilles, >> >> If you try to do this you are going to get very frustrated with >> Maven. You cannot use the Maven Release plugin if all the versions >> are >> not SNAPSHOTs, and if they always have to be SNAPSHOTs it makes very

Re: [text] Next steps.

+1 to removing the human name code for 1.0. Put it in a branch IMO. Gary On Mon, Nov 28, 2016 at 3:12 PM, Bruno P. Kinoshita < brunodepau...@yahoo.com.br.invalid> wrote: > Hi Rob, > > First of all, kudos for the great work moving things from [lang] into > [text]. > > I got a copy of the

Re: [ALL] Version number(s) for modular components

On Mon, Nov 28, 2016 at 2:57 PM, Gilles wrote: > On Mon, 28 Nov 2016 07:31:36 -0700, Apache wrote: > >> Gilles, >> >> If you try to do this you are going to get very frustrated with >> Maven. You cannot use the Maven Release plugin if all the versions are >> not

Re: [text] Next steps.

If it were just me, I would: - Port all relevant (with appropriate agreements from the community) code from [lang] to [text]. - Release [text] 1.0 - Deprecate code in [lang] - Release [lang] 3.6. - Continue [text] on to 1.1 with NEW functionality. IOW, I do not see the point of delaying [text]

Re: [text] Next steps.

Hi Rob, First of all, kudos for the great work moving things from [lang] into [text]. I got a copy of the Lothaire book last weekend, but haven't had a chance to read it yet. There was also some discussion around the name-parser, and since we couldn't reach a consensus, I think we could

Re: [ALL] Version number(s) for modular components

On Mon, 28 Nov 2016 07:31:36 -0700, Apache wrote: Gilles, If you try to do this you are going to get very frustrated with Maven. You cannot use the Maven Release plugin if all the versions are not SNAPSHOTs, and if they always have to be SNAPSHOTs it makes very little sense to have them be

[text] Next steps.

Hello, I'm a tad curious what folks (along with Gary, Benedikt, and Bruno) think the next steps are for text in the hopeful thought that we are eventually heading towards a 1.0 release. Some thoughts that come to mind are: (1) Go over lang with fine tooth comb and see what we think should move,

Re: [lang] Thread safety annotations

WRT licensing, I re-implemented the annotations in git master. Notice that all Javadocs are different and much simpler for now. Feel free to write more. Gary On Mon, Nov 28, 2016 at 12:55 PM, Gary Gregory wrote: > On Mon, Nov 28, 2016 at 12:18 PM, Matt Benson

Re: svn commit: r1771815 - /commons/proper/daemon/trunk/src/native/windows/src/service.c

On 28/11/2016 21:08, Bernd Eckenfels wrote: > Hello Mark, > > are we sure the removed TODO is not related with apxPoolAlloc() return > code? Yes. > (I also miss the inserted closing brace, does it still compile? Is that > a different commit?) See the commit log. Mark > > Gruss > Bernd > >

Re: svn commit: r1771815 - /commons/proper/daemon/trunk/src/native/windows/src/service.c

Hello Mark, are we sure the removed TODO is not related with apxPoolAlloc() return code? (I also miss the inserted closing brace, does it still compile? Is that a different commit?) Gruss Bernd Am Mon, 28 Nov 2016 21:04:06 - schrieb ma...@apache.org: > Author: markt > Date: Mon Nov 28

Re: [lang] Thread safety annotations

On Mon, Nov 28, 2016 at 12:18 PM, Matt Benson wrote: > I hoped to stay out of this. :) Points: > > * "provided" scope is another Maven mechanism that compiles against a > given dependency but does not pull the dependency in as a runtime > dependency. I personally prefer it

Re: [lang] Thread safety annotations

I hoped to stay out of this. :) Points: * "provided" scope is another Maven mechanism that compiles against a given dependency but does not pull the dependency in as a runtime dependency. I personally prefer it to marking a dependency optional. * For annotations with only classfile retention, a

Re: [lang] Thread safety annotations

Groovy had to change the license of its documentation from CC-A 3.0 to the Apache License during incubation: https://issues.apache.org/jira/browse/LEGAL-167 http://markmail.org/message/2e7tehlwtpx625q4 https://issues.apache.org/jira/browse/GROOVY-7470 So I guess Commons is probably not allowed

Re: [lang] Thread safety annotations

On Mon, Nov 28, 2016 at 7:15 AM, Jochen Wiedmann wrote: > On Mon, Nov 28, 2016 at 4:06 PM, sebb wrote: > > > The code would not run without the JCIP jar. > > Are there licensing issues regarding that jar? > Hm, according to

Re: [lang] Thread safety annotations

On 28 November 2016 at 15:15, Jochen Wiedmann wrote: > On Mon, Nov 28, 2016 at 4:06 PM, sebb wrote: > >> The code would not run without the JCIP jar. > > Are there licensing issues regarding that jar? I think there were, but regardless, the jar

Re: [lang] Thread safety annotations

On Mon, Nov 28, 2016 at 4:13 PM, sebb wrote: > Either you have to allow a separate release cycle for that jar. > Or you have to release a new version of the jar with every LANG release. > The content will likely be identical for each one unless the Javadoc is > tweaked. I'd

Re: [lang] Thread safety annotations

On Mon, Nov 28, 2016 at 4:06 PM, sebb wrote: > The code would not run without the JCIP jar. Are there licensing issues regarding that jar? Jochen -- The next time you hear: "Don't reinvent the wheel!"

Re: [lang] Thread safety annotations

On 28 November 2016 at 13:12, Jochen Wiedmann wrote: > On Mon, Nov 28, 2016 at 12:08 PM, sebb wrote: > >> No, I'm suggesting that the annotations become an independent Commons >> component. >> If we don't want these used outside Commons (probably a

Re: [lang] Thread safety annotations

On 28 November 2016 at 13:10, Jochen Wiedmann wrote: > On Mon, Nov 28, 2016 at 12:03 PM, sebb wrote: >> Yes, we started with the ones from JCIP, but these had runtime >> retention, which caused issues. > > What kind of problems, if I may ask? The

Re: [ALL] Version number(s) for modular components

Gilles, If you try to do this you are going to get very frustrated with Maven. You cannot use the Maven Release plugin if all the versions are not SNAPSHOTs, and if they always have to be SNAPSHOTs it makes very little sense to have them be out of sync. If you don’t use the release plugin then

Re: [lang] Thread safety annotations

On Mon, 28 Nov 2016 14:12:48 +0100, Jochen Wiedmann wrote: On Mon, Nov 28, 2016 at 12:08 PM, sebb wrote: No, I'm suggesting that the annotations become an independent Commons component. If we don't want these used outside Commons (probably a good idea) then we can make this

Re: [ALL] Version number(s) for modular components

On Sun, 27 Nov 2016 20:35:51 -0600, Matt Sicker wrote: Here's an example of a confusing versioning situation: 1. commons-foo-base version 1.1 is released 2. commons-foo-utils is still at version 1.0 as no code was updated. Do you release a 1.0.1 with a dependency update on commons-foo-base

Re: [lang] Thread safety annotations

On Mon, Nov 28, 2016 at 12:08 PM, sebb wrote: > No, I'm suggesting that the annotations become an independent Commons > component. > If we don't want these used outside Commons (probably a good idea) > then we can make this clear through Javadoc and package naming etc. > > The

Re: [lang] Thread safety annotations

On Mon, Nov 28, 2016 at 12:03 PM, sebb wrote: > Yes, we started with the ones from JCIP, but these had runtime > retention, which caused issues. What kind of problems, if I may ask? Thanks, Jochen - To

[GitHub] commons-fileupload issue #5: Update DiskFileItem.java: Avoiding NPE when not...

Github user OleHornischer commented on the issue: https://github.com/apache/commons-fileupload/pull/5 Hi @garydgregory I created a Unit test illustrating the issue. However, since this is my first pull request, I am not sure what you mean by updating the patch. I forked the

[RDF] Graduating Commons RDF to Commons PMC

The Commons RDF graduation vote passed on Commons and Incubator, so Commons RDF will now formally move to become a component of Apache Commons. Thanks everyone who voted! I will continue on Wednesday with doing the technical bureaucracy like updating Incubator meta-files, moving repositories,

Re: [lang] Thread safety annotations

On 28 November 2016 at 01:55, Gary Gregory wrote: > Are you suggesting [lang] becomes a multi-module project? No, I'm suggesting that the annotations become an independent Commons component. If we don't want these used outside Commons (probably a good idea) then we can

Re: [lang] Thread safety annotations

Yes, we started with the ones from JCIP, but these had runtime retention, which caused issues. I e-mailed JCIP asking if the retention could be changed, but no joy. We therefore created our own from elsewhere. Not sure why we eventually dropped them. On 28 November 2016 at 04:06, Matt Sicker