[RNG][ALL] mvn commons:download-page

Hi. Running $ mvn commons:download-page generates a file that contains links to commons-rng-1.0-* files; but not to any of the modules files. Is there an alternative command for modular components? Gilles - To unsubsc

Re: [lang] Thread safety annotations

I think adding the additional clazz/runtime package would be a little overkill if you only include one packaging option for now. On 27 November 2016 at 00:04, Gary Gregory wrote: > On Nov 26, 2016 8:40 PM, "Matt Sicker" wrote: > > > > I can think of a couple use cases for runtime retention for

Re: [lang] Thread safety annotations

On Nov 26, 2016 8:40 PM, "Matt Sicker" wrote: > > I can think of a couple use cases for runtime retention for thread safety > annotations, but they're not specific to commons lang. > > 1. A framework could choose what type of data structure or algorithm to use > at runtime based on the presence of

Re: [lang] Thread safety annotations

I can think of a couple use cases for runtime retention for thread safety annotations, but they're not specific to commons lang. 1. A framework could choose what type of data structure or algorithm to use at runtime based on the presence of which thread safety annotation is on. Same for mutability

Re: [lang] Thread safety annotations

On Sat, Nov 26, 2016 at 3:54 PM, sebb wrote: > On 26 November 2016 at 19:25, Gary Gregory wrote: > > On a [crypto] thread, I mentioned http://pastebin.com/RKPGGdJ9 to add > the > > "classic" four javax.annotation.concurrent annotations to two packages > > (.clazz and .runtime) in Commons Lang fo

Re: [DISCUSS] Jenkins Pipeline DSL

On 26 November 2016 at 15:45, Gary Gregory wrote: > That sounds even more complicated to deal with :-( I would have to fiddle > with branches just to make a Jenkins build change? Is there a precedent for > such a set up? Huh? Surely the Jenkins setup script is independent of the build. The prec

Re: [lang] Thread safety annotations

On 26 November 2016 at 19:25, Gary Gregory wrote: > On a [crypto] thread, I mentioned http://pastebin.com/RKPGGdJ9 to add the > "classic" four javax.annotation.concurrent annotations to two packages > (.clazz and .runtime) in Commons Lang for CLASS and RUNTIME retentions. > > You'd use the CLASS v

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

Gary Gregory wrote: > On Sat, Nov 26, 2016 at 9:06 AM, Jörg Schaible > wrote: > >> Sorry, for me this is going down the wrong road. For me different >> versions mean different components. Allowing multiple versions for >> modules in one component will exactly open the can of worms Gilles >> desc

[lang] Thread safety annotations

On a [crypto] thread, I mentioned http://pastebin.com/RKPGGdJ9 to add the "classic" four javax.annotation.concurrent annotations to two packages (.clazz and .runtime) in Commons Lang for CLASS and RUNTIME retentions. You'd use the CLASS version to avoid a hard dependency on [lang]. RUNTIME to keep

[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 Hi @OleHornischer, 1) Can you update your patch based on our Git master. 2) Can you provide a unit test that shows the bug in action before if your patch is not applied.

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

My experience suggests that the "one repository, one version" rule works best. This, however, does not solve the concern of allowing quick releases with multiple simultaneous features. This concern is better solved with feature branches. Mainline branch, (“master”) must be releasable at any

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

On Sat, Nov 26, 2016 at 9:28 AM, Rob Tompkins wrote: > I've always thought that versioning sat at a repository level. When you > check out (or clone or whatever) code it feels counterintuitive to have > several different potential versions floating around in what you just got. > So I would argue

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

On Sat, Nov 26, 2016 at 9:06 AM, Jörg Schaible wrote: > Sorry, for me this is going down the wrong road. For me different versions > mean different components. Allowing multiple versions for modules in one > component will exactly open the can of worms Gilles described below. We had > that alread

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

I've always thought that versioning sat at a repository level. When you check out (or clone or whatever) code it feels counterintuitive to have several different potential versions floating around in what you just got. So I would argue for the general guideline of one repository, one overall ver

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

Sorry, for me this is going down the wrong road. For me different versions mean different components. Allowing multiple versions for modules in one component will exactly open the can of worms Gilles described below. We had that already with Jakarta. I still propose commons-rng-tools as separat

Re: [RNG] Help with Jenkins

On Wed, 23 Nov 2016 14:53:35 +0100, Gilles wrote: On Wed, 23 Nov 2016 08:14:25 +0100, Jan Matèrne wrote: https://builds.apache.org/view/Apache%20Commons/job/Commons_Rng/77/org > .apache.commons$commons-rng-examples/console From what I read in the "configure" page of the Jenkins interface, it

Re: [MATH] [Complex] FFT

Hi. JIRA project is available: https://issues.apache.org/jira/browse/COMPLEX Regards, Gilles On Thu, 24 Nov 2016 13:33:45 +0100, Eric Barnhill wrote: Since FFT discussions appear to have begun...I have long noticed that the FFT in CM is only a Radix-4 implementation. Bernd, is improving t

Re: [text] Text-27 Moving StringEscapeUtils into text

Hello Robert, Rob Tompkins schrieb am Sa., 26. Nov. 2016 um 15:42 Uhr: > I’ve got a couple of questions here. > > (1) We’ve established that text can depend upon lang so, I’m going to > leave references to “StringUtils” in text. > agreed. > (2) The unit test for StringEscapeUtils uses io. Do

[ALL] Version number(s) for modular components

Hello. As a follow-up of http://markmail.org/message/jckbknphndecglns and http://markmail.org/message/f3g33kvevf52xohf I summarize what I think should be allowed for versioning modularized components of the "Commons" project. Assume there are two modules in project "Commons ModProj": commo

Re: [DISCUSS] Jenkins Pipeline DSL

That sounds even more complicated to deal with :-( I would have to fiddle with branches just to make a Jenkins build change? Is there a precedent for such a set up? I do like the idea of having the Jenkins build file right there like Travis CI but it is slightly worrisome that we have more files t

[text] Text-27 Moving StringEscapeUtils into text

I’ve got a couple of questions here. (1) We’ve established that text can depend upon lang so, I’m going to leave references to “StringUtils” in text. (2) The unit test for StringEscapeUtils uses io. Do we want to declare io as a test dependency or not? If not, then I’ll work around that need, a

[RESULT] [VOTE] Accept Commons RDF as a new component

On 23 November 2016 at 13:47, Stian Soiland-Reyes wrote: > [Note: this is the Commons PMC vote on dev@commons - there's a > concurrent IPMC VOTE thread on general@incubator] > > Please VOTE on graduating Commons RDF as new component: Thanks to everyone who voted! The results from the Commons PMC

Re: [DISCUSS] Jenkins Pipeline DSL

Seems OK to me. However I think the script should be added to its own separate SVN/Git branch (not trunk/master). It's not a part of the source release per se, and as you write, it can be applied to multiple branches. Having it in the main source trees would be confusing, and more copies to merge

Re: [DISCUSS] Jenkins Pipeline DSL

+1 for the PoC We can achieve something similar to what we have in Travis-CI through the Pipeline Plug-in (née Workflow Plug-in). Here are some examples of what the Jenkinsfile looks like. In the Jenkinsfile you define, as Benedikt said, your job configuration with the DSL. It is not very diff

[DISCUSS] Jenkins Pipeline DSL

Hello, currently we define our Jenkins job through the Jenkins UI. The problem with this is, that there is no connection between the source code and the way it is build. The Build job configuration is versioned separately from the source code in Jenkins it self. With the Jenkins Pipeline Plugin [

Jenkins build is back to normal : Commons-CRYPTO-JDK1.8 #133

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-CRYPTO-JDK1.8 #132

See Changes: [beneritter] Fix broken JavaDoc link [beneritter] Sort pom.xml elements -- Started by an SCM change [EnvInject] - Loading node environment variables. Building remotely on H12 (

Re: [CRYPTO] Feedback from ApacheCON Europe

Hello, Ke, Xianda schrieb am Do., 24. Nov. 2016 um 03:49 Uhr: > Hi Benedict, > > >>1) Why does Commons Crypto implement it's own Crypto API instead of > providing a JCE provider? > Dapeng has answered the question. Here are some additional details > The deployment of JCE provider is tedious for