Re: Maintenance release for JCS 2.2

[Jean-Louis MONTEIRO]

Yes a 2.2.1 would be awesome.
Thanks guys.

Lemme know if there is anything I can do to help

On mar. 19 sept. 2017 à 08:54 Romain Manni-Bucau 
wrote:

> Hi JL,
>
> I'm planning to work on it this week-end or next week (depending how long
> it will be to setup my new computer).
>
> Will probably be a 2.2.1 from a branch from the previous discussions we had
> so we will need to backport the changes but nothing blocking.
>
>
> Romain Manni-Bucau
> @rmannibucau  |  Blog
>  | Old Blog
>  | Github <
> https://github.com/rmannibucau> |
> LinkedIn  | JavaEE Factory
> 
>
> 2017-09-18 18:29 GMT+02:00 Gary Gregory :
>
> > Hi,
> >
> > JCS 2.2 is out already: https://commons.apache.org/proper/commons-jcs/
> >
> > Do you mean the _next_ release?
> >
> > Gary
> >
> > On Mon, Sep 18, 2017 at 9:28 AM, Jean-Louis MONTEIRO  >
> > wrote:
> >
> > > Hi,
> > >
> > > I am currently facing performance issues with the CDI integration
> because
> > > of the reflection.
> > > I have successfully tested the patch from Romain and would like to know
> > if
> > > there is a maintenance release planned soon?
> > >
> > > Thanks
> > > Jean-Louis
> > >
> >
>

Re: [All][RNG] Generate signatures and checksums (Was: [COLLECTIONS] Time for 4.2)

[Stefan Bodewig]

On 2017-09-20, Gilles wrote:

> On Wed, 20 Sep 2017 17:49:38 +0200, Stefan Bodewig wrote:
>> On 2017-09-20, Gilles wrote:

>>> On Wed, 20 Sep 2017 07:33:55 -0600, Gary Gregory wrote:

 How about dealing with the Automatic-Module-Name MANIFEST header in
 the parent POM and releasing that POM first?

>>> Is there a solution to this issue:
>>>   https://issues.apache.org/jira/browse/RNG-31

>> I'm afraid Gary and you are talking about completely different things
>> (and either of you as well as myself should have changed the subject
>> line ;-)

> I did some 20 minutes ago. :-)


>> Unfortunately I cannot answer the question about signatures for
>> modular
>> builds, I'm not really a maven person. What I can say is that I never
>> invoke any "assembly" goal when I create a release, the signatures
>> are
>> created as a byproduct of running "deploy".

> "deploy" will upload to the nexus server, and there is no
> problem (signatures are generated automagically).

mvn deploy -Ptest-deploy -Prelease

creates all signatures but doesn't actually perform the upload. This is
what I use.

Stefan

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

RNG-37

[Olga]

Hello,I could help with 
https://helpwanted.apache.org/task.html?9d71a269c2a31ebaccfee57001865cb3059b9e54ThanksOlga

Re: [All][RNG] Generate signatures and checksums (Was: [COLLECTIONS] Time for 4.2)

[Ralph Goers]

> On Sep 20, 2017, at 8:27 AM, Gilles  wrote:
> 
> On Wed, 20 Sep 2017 09:19:35 -0600, Gary Gregory wrote:
 [...]
 
>>> 
>>> Is there a solution to this issue:
>>>  https://issues.apache.org/jira/browse/RNG-31
>>> 
>>> IOW how do other modular components handle the creation of signatures
>>> and checksums for all their modules?
>>> 
>> 
>> Some Maven magic does that.
> 
> How come that [RNG] is immune to that magic?

Do you use the Maven release plugin to perform releases? It does that 
automatically.

Ralph



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

Re: Fwd: Re: [JCS] missing 2.2 release in jira?

[Romain Manni-Bucau]

back on the release topic (sorry for the delay, have been very busy
lately): does it sound ok for everyone  if I backport the jcache changes in
2.2 and release it from here (Some pointer on which branch I can reuse or
if I should create one from the 2.2 tag would be welcomed)?

as a side note for anyone with some time we should probably upgrade master
to 3.0-SNAPSHOT from what I understood, no?


Romain Manni-Bucau
@rmannibucau  |  Blog
 | Old Blog
 | Github  |
LinkedIn  | JavaEE Factory


2017-09-10 20:57 GMT+02:00 Oliver Heger :

>
>
> Am 10.09.2017 um 17:28 schrieb Thomas Vandahl:
> > Hi folks,
> >
> > I found out again that replying to the list did reply to the sender
> > instead. Does that happen to anyone else or is it my Thunderbird setting?
>
> Me too! This seems to be a new feature of Thunderbird which came in on a
> recent update. In addition to the "Reply" button I always used to press
> there is a new "Reply to list" button. Obviously, one must use the
> latter one. However, I keep using "Reply" and then wonder why my mail
> does not show up on the list.
>
> Oliver
>
> >
> > Bye, Thomas
> >
> >  Forwarded Message 
> > Subject: Re: [JCS] missing 2.2 release in jira?
> > Date: Sat, 9 Sep 2017 10:58:54 +0200
> > From: Thomas Vandahl 
> > To: Romain Manni-Bucau 
> >
> > On 08.09.17 16:41, Romain Manni-Bucau wrote:
> >> So it would be a 3.0. Do we expect anything else in a potential 3.0?
> >
> > I made an attempt to integrate the ConcurrentLinkedHashMap by Ben Manes.
> > See
> > https://svn.apache.org/repos/asf/commons/proper/jcs/
> branches/jcs-core-with-clhm
> > This would be a candidate feature for 3.0.
> > However, several (apparently unrelated) tests started to fail. Moreover,
> > the performance tests showed little or no improvement. If you want to
> > give it another shot, feel free.
> >
> > Bye, Thomas
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > For additional commands, e-mail: dev-h...@commons.apache.org
> >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: [ANNOUNCE] Apache Commons BCEL 6.1 released!

[Pascal Schumacher]

Thank you very much Benedikt!

This should make the spotbugs team happy, as they were waiting for this 
to happen, see:


https://github.com/spotbugs/spotbugs/issues/89
https://github.com/spotbugs/spotbugs/issues/327

Cheers,
Pascal

Am 19.09.2017 um 10:37 schrieb Benedikt Ritter:

Hello,

the Apache Commons Community is happy to announce the release of Apache Commons 
BCEL 6.1.

The Byte Code Engineering Library (Apache Commons BCEL) is intended to give 
users a convenient way to analyze, create, and manipulate (binary) Java class 
files (those ending with .class). Classes are represented by objects which 
contain all the symbolic information of the given class: methods, fields and 
byte code instructions, in particular.

Source and binary distributions are available for download from the Apache 
Commons download site:
http://commons.apache.org/proper/commons-bcel/download_bcel.cgi

When downloading, please verify signatures using the KEYS file available at the 
above location.

Alternatively the release can be pulled via maven:

   org.apache.bcel
   bcel
   6.1


The release notes can be viewed at:
http://www.apache.org/dist/commons/bcel/RELEASE-NOTES.txt

For complete information on Commons BCEL, including instructions on how to 
submit bug reports, patches, or suggestions for improvement, see the Apache 
Commons BCEL website:

http://commons.apache.org/proper/commons-bcel/

Best regards,
Benedikt Ritter
on behalf of the Apache Commons community


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




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

Re: [VFS] toward releasing 2.2

[Gary Gregory]

Bugs fixed. I plan on starting the release process ASAP.

Gary


On Wed, Sep 6, 2017 at 8:11 AM, Gary Gregory  wrote:

> Great thank you. I just found out we have a bug at work that might only
> affect 2.2-SNAPSHOT, so I have to take a look at that first anyway.
>
> Gary
>
> On Wed, Sep 6, 2017 at 1:27 AM, Bruno P. Kinoshita <
> brunodepau...@yahoo.com.br.invalid> wrote:
>
>> Going to Australia in a couple of weeks, so if I volunteered now I could
>> be unable to proceed with the release if the first RC failed.
>>
>>
>> Should no one volunteers, and if you haven't already cut the release, I'd
>> be glad to try releasing a SVN + multi-module project in mid-October, and
>> at the same time review - and learn with - our release process.
>> Cheers
>> Bruno
>>
>>
>>
>> 
>> From: Gary Gregory 
>> To: Commons Developers List 
>> Sent: Tuesday, 5 September 2017 5:39 AM
>> Subject: [VFS] toward releasing 2.2
>>
>>
>>
>> Hi All,
>>
>>
>> I would live to see a release for VFS so I can pickup some bug fixes.
>>
>>
>> If any one wants to RM, great, otherwise I will have to put that on my
>>
>> TO-DO list.
>>
>>
>> If you want to perform changes, now is the time. The sooner the better.
>>
>>
>> Gary
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> For additional commands, e-mail: dev-h...@commons.apache.org
>>
>>
>

Re: [VOTE] Release commons-jelly-1.0.1 based on RC6

[Gary Gregory]

On Wed, Sep 20, 2017 at 1:45 PM, Oliver Heger 
wrote:

> Hi Rob,
>
> build works fine with jdk1.5.0_21 on Windows 10. Artifacts look good.
>
> The only minor nit I found is that the release notes state "This is the
> first stable release of Jelly.", which is not true; but no blocker.
>

Fixed in SVN.

Thank you!
Gary


>
> So +1, great work!
> Oliver
>
> Am 20.09.2017 um 15:36 schrieb Rob Tompkins:
> > Hello,
> >
> > Commons Jelly 1.0.1 RC6 is available for review here:
> >   https://dist.apache.org/repos/dist/dev/commons/jelly (svn revision
> 21718)
> >
> > The tag is here (tag commit 1808993):
> >   https://svn.apache.org/repos/asf/commons/proper/jelly/tags/
> commons-jelly-1.0.1-RC6
> >
> > Commit the tag points at:
> >   1808992
> >
> > Maven Artifacts:
> >   https://repository.apache.org/content/repositories/
> orgapachecommons-1264
> >
> > These are the Maven artifacts and their hashes:
> >
> > /commons-jelly/commons-jelly/1.0.1/commons-jelly-1.0.1-javadoc.jar
> >  orgapachecommons-1264/commons-jelly/commons-jelly/1.0.1/
> commons-jelly-1.0.1-javadoc.jar>
> > (SHA1: 3a81887847dac154c12171028f01e4dd252a0fd0)
> > /commons-jelly/commons-jelly/1.0.1/commons-jelly-1.0.1-javadoc.jar.asc
> >  orgapachecommons-1264/commons-jelly/commons-jelly/1.0.1/
> commons-jelly-1.0.1-javadoc.jar.asc>
> > (SHA1: 465eea91cc0a7f088ea8bd571e4633ef1904713a)
> > /commons-jelly/commons-jelly/1.0.1/commons-jelly-1.0.1-sources.jar
> >  orgapachecommons-1264/commons-jelly/commons-jelly/1.0.1/
> commons-jelly-1.0.1-sources.jar>
> > (SHA1: c6c6c1a54b12f268d24abc6a0f920bd2e5896d4c)
> > /commons-jelly/commons-jelly/1.0.1/commons-jelly-1.0.1-sources.jar.asc
> >  orgapachecommons-1264/commons-jelly/commons-jelly/1.0.1/
> commons-jelly-1.0.1-sources.jar.asc>
> > (SHA1: e24cc221bed60203d74f17b93cdfb12d5ca607f6)
> > /commons-jelly/commons-jelly/1.0.1/commons-jelly-1.0.1-test-sources.jar
> >  orgapachecommons-1264/commons-jelly/commons-jelly/1.0.1/
> commons-jelly-1.0.1-test-sources.jar>
> > (SHA1: 71b63b2619a8767d9d0ac0530dcb208f307261ff)
> > /commons-jelly/commons-jelly/1.0.1/commons-jelly-1.0.1-
> test-sources.jar.asc
> >  orgapachecommons-1264/commons-jelly/commons-jelly/1.0.1/
> commons-jelly-1.0.1-test-sources.jar.asc>
> > (SHA1: f07dc38b9e4da5860fdad861c815876814184570)
> > /commons-jelly/commons-jelly/1.0.1/commons-jelly-1.0.1-tests.jar
> >  orgapachecommons-1264/commons-jelly/commons-jelly/1.0.1/
> commons-jelly-1.0.1-tests.jar>
> > (SHA1: 59525df8d5ac104d72c77792da2f72cf381f4420)
> > /commons-jelly/commons-jelly/1.0.1/commons-jelly-1.0.1-tests.jar.asc
> >  orgapachecommons-1264/commons-jelly/commons-jelly/1.0.1/
> commons-jelly-1.0.1-tests.jar.asc>
> > (SHA1: c99baf87964992e674435f69e7d4270803c5b956)
> > /commons-jelly/commons-jelly/1.0.1/commons-jelly-1.0.1.jar
> >  orgapachecommons-1264/commons-jelly/commons-jelly/1.0.1/
> commons-jelly-1.0.1.jar>
> > (SHA1: a20261c0f6be2fa4d6572fe22da0450d93195de9)
> > /commons-jelly/commons-jelly/1.0.1/commons-jelly-1.0.1.jar.asc
> >  orgapachecommons-1264/commons-jelly/commons-jelly/1.0.1/
> commons-jelly-1.0.1.jar.asc>
> > (SHA1: 68fb5704f4ca3aefe4fa3369c85b3257be7bfa2c)
> > /commons-jelly/commons-jelly/1.0.1/commons-jelly-1.0.1.pom
> >  orgapachecommons-1264/commons-jelly/commons-jelly/1.0.1/
> commons-jelly-1.0.1.pom>
> > (SHA1: ea2c451db75da2384ab5a51e9f1dc2b21c8e14cb)
> > /commons-jelly/commons-jelly/1.0.1/commons-jelly-1.0.1.pom.asc
> >  orgapachecommons-1264/commons-jelly/commons-jelly/1.0.1/
> commons-jelly-1.0.1.pom.asc>
> > (SHA1: 4f1945ac4669c0bdb186f37d4bc56a864a6c5050)
> >
> > I have tested this with JDK 1.5.0_22-b03 using Ant 1.6.0. Notes on
> building can
> > be found in the
> > BUILDING.md, included in the source distributions. And, the only changes
> between
> > release candidates are documentation and build script changes.
> >
> > Details of changes since 1.0 are in the release notes:
> > https://dist.apache.org/repos/dist/dev/commons/jelly/
> RELEASE-NOTES.txt
> >
> > Site:
> >   I have no site as this was generated with ant. My plan was to
> simply make
> > minimal
> >   changes to the existant site for the purpose of documenting the
> patch.
> >
> > KEYS:
> >   https://www.apache.org/dist/commons/KEYS
> >
> > Please review the release candidate and vote.
> > This vote will close no sooner that 

Re: [VOTE] Release commons-jelly-1.0.1 based on RC6

[Oliver Heger]

Hi Rob,

build works fine with jdk1.5.0_21 on Windows 10. Artifacts look good.

The only minor nit I found is that the release notes state "This is the
first stable release of Jelly.", which is not true; but no blocker.

So +1, great work!
Oliver

Am 20.09.2017 um 15:36 schrieb Rob Tompkins:
> Hello,
> 
> Commons Jelly 1.0.1 RC6 is available for review here:
>   https://dist.apache.org/repos/dist/dev/commons/jelly (svn revision 21718)
> 
> The tag is here (tag commit 1808993):
>   
> https://svn.apache.org/repos/asf/commons/proper/jelly/tags/commons-jelly-1.0.1-RC6
> 
> Commit the tag points at:
>   1808992
> 
> Maven Artifacts:
>   https://repository.apache.org/content/repositories/orgapachecommons-1264
> 
> These are the Maven artifacts and their hashes:
> 
> /commons-jelly/commons-jelly/1.0.1/commons-jelly-1.0.1-javadoc.jar
> 
> (SHA1: 3a81887847dac154c12171028f01e4dd252a0fd0)
> /commons-jelly/commons-jelly/1.0.1/commons-jelly-1.0.1-javadoc.jar.asc
> 
> (SHA1: 465eea91cc0a7f088ea8bd571e4633ef1904713a)
> /commons-jelly/commons-jelly/1.0.1/commons-jelly-1.0.1-sources.jar
> 
> (SHA1: c6c6c1a54b12f268d24abc6a0f920bd2e5896d4c)
> /commons-jelly/commons-jelly/1.0.1/commons-jelly-1.0.1-sources.jar.asc
> 
> (SHA1: e24cc221bed60203d74f17b93cdfb12d5ca607f6)
> /commons-jelly/commons-jelly/1.0.1/commons-jelly-1.0.1-test-sources.jar
> 
> (SHA1: 71b63b2619a8767d9d0ac0530dcb208f307261ff)
> /commons-jelly/commons-jelly/1.0.1/commons-jelly-1.0.1-test-sources.jar.asc
> 
> (SHA1: f07dc38b9e4da5860fdad861c815876814184570)
> /commons-jelly/commons-jelly/1.0.1/commons-jelly-1.0.1-tests.jar
> 
> (SHA1: 59525df8d5ac104d72c77792da2f72cf381f4420)
> /commons-jelly/commons-jelly/1.0.1/commons-jelly-1.0.1-tests.jar.asc
> 
> (SHA1: c99baf87964992e674435f69e7d4270803c5b956)
> /commons-jelly/commons-jelly/1.0.1/commons-jelly-1.0.1.jar
> 
> (SHA1: a20261c0f6be2fa4d6572fe22da0450d93195de9)
> /commons-jelly/commons-jelly/1.0.1/commons-jelly-1.0.1.jar.asc
> 
> (SHA1: 68fb5704f4ca3aefe4fa3369c85b3257be7bfa2c)
> /commons-jelly/commons-jelly/1.0.1/commons-jelly-1.0.1.pom
> 
> (SHA1: ea2c451db75da2384ab5a51e9f1dc2b21c8e14cb)
> /commons-jelly/commons-jelly/1.0.1/commons-jelly-1.0.1.pom.asc
> 
> (SHA1: 4f1945ac4669c0bdb186f37d4bc56a864a6c5050)
> 
> I have tested this with JDK 1.5.0_22-b03 using Ant 1.6.0. Notes on building 
> can
> be found in the 
> BUILDING.md, included in the source distributions. And, the only changes 
> between
> release candidates are documentation and build script changes.
> 
> Details of changes since 1.0 are in the release notes:
> https://dist.apache.org/repos/dist/dev/commons/jelly/RELEASE-NOTES.txt
> 
> Site:
>   I have no site as this was generated with ant. My plan was to simply 
> make
> minimal 
>   changes to the existant site for the purpose of documenting the patch.
> 
> KEYS:
>   https://www.apache.org/dist/commons/KEYS
> 
> Please review the release candidate and vote.
> This vote will close no sooner that 72 hours from now,
> i.e. sometime after 14:00 (UTC) 23-September 2017
> 
>   [ ] +1 Release these artifacts
>   [ ] +0 OK, but...
>   [ ] -0 OK, but really should fix...
>   [ ] -1 I oppose this release because...
> 
> Thanks!
> Rob
> -
> To unsubscribe, e-mail: 

[GitHub] commons-text pull request #63: small-code-quality-improvements

[TheRealHaui]

GitHub user TheRealHaui opened a pull request:

https://github.com/apache/commons-text/pull/63

small-code-quality-improvements

Made small code quality improvements.

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/TheRealHaui/commons-text 
small-code-quality-improvements

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/commons-text/pull/63.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #63


commit d5c840c19792b6c0dee03e0779ac791c73f296cf
Author: Michael Hausegger 
Date:   2017-09-20T18:03:24Z

small-code-quality-improvements Made small code quality improvements.




---

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

Re: [VOTE] Release commons-jelly-1.0.1 based on RC6

[Rob Tompkins]

> On Sep 20, 2017, at 1:10 PM, Gary Gregory  wrote:
> 
> Yep, that does it! Bug in the BUILDING.md then. Not a blocker but should be
> fixed in the repo ASAP.
> 

Fixed in the 1.X branch.

Cheers,
-Rob

> Gary
> 
> On Wed, Sep 20, 2017 at 11:03 AM, Rob Tompkins  wrote:
> 
>> I think the "x" on the volume mount with /root/commons-jelly-1.X needs to
>> be capitalized.
>> 
>>> On Sep 20, 2017, at 12:44 PM, Gary Gregory 
>> wrote:
>>> 
>>> Should the answer.txt and install.sh files be in the src zip file?
>>> 
>>> Gary
>>> 
>>> On Wed, Sep 20, 2017 at 10:42 AM, Gary Gregory 
>>> wrote:
>>> 
 Hi,
 
 I think I missed a step... I get:
 
 C:\temp\rc\commons-jelly-1.0.1-src>docker run -v
 C:\temp\rc\commons-jelly-1.0.1-src:/root/commons-jelly-1.x
 commons-jelly-build-env ant dist
 Buildfile: build.xml does not exist!
 Build failed
 
 Here is my session: https://pastebin.com/y7kFnNfn
 
 Help?
 
 Gary
 
> On Wed, Sep 20, 2017 at 7:36 AM, Rob Tompkins 
>> wrote:
> 
> Hello,
> 
> Commons Jelly 1.0.1 RC6 is available for review here:
> https://dist.apache.org/repos/dist/dev/commons/jelly (svn revision
> 21718)
> 
> The tag is here (tag commit 1808993):
> https://svn.apache.org/repos/asf/commons/proper/jelly/tags/c
> ommons-jelly-1.0.1-RC6
> 
> Commit the tag points at:
> 1808992
> 
> Maven Artifacts:
> https://repository.apache.org/content/repositories/orgapache
> commons-1264
> 
> These are the Maven artifacts and their hashes:
> 
> /commons-jelly/commons-jelly/1.0.1/commons-jelly-1.0.1-javadoc.jar
>  ecommons-1264/commons-jelly/commons-jelly/1.0.1/commons-
> jelly-1.0.1-javadoc.jar>
> (SHA1: 3a81887847dac154c12171028f01e4dd252a0fd0)
> /commons-jelly/commons-jelly/1.0.1/commons-jelly-1.0.1-javadoc.jar.asc
>  ecommons-1264/commons-jelly/commons-jelly/1.0.1/commons-
> jelly-1.0.1-javadoc.jar.asc>
> (SHA1: 465eea91cc0a7f088ea8bd571e4633ef1904713a)
> /commons-jelly/commons-jelly/1.0.1/commons-jelly-1.0.1-sources.jar
>  ecommons-1264/commons-jelly/commons-jelly/1.0.1/commons-
> jelly-1.0.1-sources.jar>
> (SHA1: c6c6c1a54b12f268d24abc6a0f920bd2e5896d4c)
> /commons-jelly/commons-jelly/1.0.1/commons-jelly-1.0.1-sources.jar.asc
>  ecommons-1264/commons-jelly/commons-jelly/1.0.1/commons-
> jelly-1.0.1-sources.jar.asc>
> (SHA1: e24cc221bed60203d74f17b93cdfb12d5ca607f6)
> /commons-jelly/commons-jelly/1.0.1/commons-jelly-1.0.1-
>> test-sources.jar
>  ecommons-1264/commons-jelly/commons-jelly/1.0.1/commons-
> jelly-1.0.1-test-sources.jar>
> (SHA1: 71b63b2619a8767d9d0ac0530dcb208f307261ff)
> /commons-jelly/commons-jelly/1.0.1/commons-jelly-1.0.1-test-
> sources.jar.asc
>  ecommons-1264/commons-jelly/commons-jelly/1.0.1/commons-
> jelly-1.0.1-test-sources.jar.asc>
> (SHA1: f07dc38b9e4da5860fdad861c815876814184570 <(681)%20418-4570>)
> /commons-jelly/commons-jelly/1.0.1/commons-jelly-1.0.1-tests.jar
>  ecommons-1264/commons-jelly/commons-jelly/1.0.1/commons-
> jelly-1.0.1-tests.jar>
> (SHA1: 59525df8d5ac104d72c77792da2f72cf381f4420)
> /commons-jelly/commons-jelly/1.0.1/commons-jelly-1.0.1-tests.jar.asc
>  ecommons-1264/commons-jelly/commons-jelly/1.0.1/commons-
> jelly-1.0.1-tests.jar.asc>
> (SHA1: c99baf87964992e674435f69e7d4270803c5b956)
> /commons-jelly/commons-jelly/1.0.1/commons-jelly-1.0.1.jar
>  ecommons-1264/commons-jelly/commons-jelly/1.0.1/commons-
>> jelly-1.0.1.jar>
> (SHA1: a20261c0f6be2fa4d6572fe22da0450d93195de9)
> /commons-jelly/commons-jelly/1.0.1/commons-jelly-1.0.1.jar.asc
>  ecommons-1264/commons-jelly/commons-jelly/1.0.1/commons-
> jelly-1.0.1.jar.asc>
> (SHA1: 68fb5704f4ca3aefe4fa3369c85b3257be7bfa2c)
> /commons-jelly/commons-jelly/1.0.1/commons-jelly-1.0.1.pom
>  ecommons-1264/commons-jelly/commons-jelly/1.0.1/commons-
>> jelly-1.0.1.pom>
> (SHA1: ea2c451db75da2384ab5a51e9f1dc2b21c8e14cb)
> /commons-jelly/commons-jelly/1.0.1/commons-jelly-1.0.1.pom.asc
> 

Re: [VOTE] Release commons-jelly-1.0.1 based on RC6

[Gary Gregory]

+1

>From src zip: ASC, MD5, SHA1 OK.

Apache RAT check OK
Apache CLIRR check OK

OK: docker run -v
C:\temp\rc\commons-jelly-1.0.1-src:/root/commons-jelly-1.x
commons-jelly-build-env ant dist

Docker version 17.06.2-ce, build cec0b72

Gary


On Wed, Sep 20, 2017 at 7:36 AM, Rob Tompkins  wrote:

> Hello,
>
> Commons Jelly 1.0.1 RC6 is available for review here:
>   https://dist.apache.org/repos/dist/dev/commons/jelly (svn revision
> 21718)
>
> The tag is here (tag commit 1808993):
>   https://svn.apache.org/repos/asf/commons/proper/jelly/tags/
> commons-jelly-1.0.1-RC6
>
> Commit the tag points at:
>   1808992
>
> Maven Artifacts:
>   https://repository.apache.org/content/repositories/orgapachecommons-1264
>
> These are the Maven artifacts and their hashes:
>
> /commons-jelly/commons-jelly/1.0.1/commons-jelly-1.0.1-javadoc.jar
>  orgapachecommons-1264/commons-jelly/commons-jelly/1.0.1/
> commons-jelly-1.0.1-javadoc.jar>
> (SHA1: 3a81887847dac154c12171028f01e4dd252a0fd0)
> /commons-jelly/commons-jelly/1.0.1/commons-jelly-1.0.1-javadoc.jar.asc
>  orgapachecommons-1264/commons-jelly/commons-jelly/1.0.1/
> commons-jelly-1.0.1-javadoc.jar.asc>
> (SHA1: 465eea91cc0a7f088ea8bd571e4633ef1904713a)
> /commons-jelly/commons-jelly/1.0.1/commons-jelly-1.0.1-sources.jar
>  orgapachecommons-1264/commons-jelly/commons-jelly/1.0.1/
> commons-jelly-1.0.1-sources.jar>
> (SHA1: c6c6c1a54b12f268d24abc6a0f920bd2e5896d4c)
> /commons-jelly/commons-jelly/1.0.1/commons-jelly-1.0.1-sources.jar.asc
>  orgapachecommons-1264/commons-jelly/commons-jelly/1.0.1/
> commons-jelly-1.0.1-sources.jar.asc>
> (SHA1: e24cc221bed60203d74f17b93cdfb12d5ca607f6)
> /commons-jelly/commons-jelly/1.0.1/commons-jelly-1.0.1-test-sources.jar
>  orgapachecommons-1264/commons-jelly/commons-jelly/1.0.1/
> commons-jelly-1.0.1-test-sources.jar>
> (SHA1: 71b63b2619a8767d9d0ac0530dcb208f307261ff)
> /commons-jelly/commons-jelly/1.0.1/commons-jelly-1.0.1-
> test-sources.jar.asc
>  orgapachecommons-1264/commons-jelly/commons-jelly/1.0.1/
> commons-jelly-1.0.1-test-sources.jar.asc>
> (SHA1: f07dc38b9e4da5860fdad861c815876814184570)
> /commons-jelly/commons-jelly/1.0.1/commons-jelly-1.0.1-tests.jar
>  orgapachecommons-1264/commons-jelly/commons-jelly/1.0.1/
> commons-jelly-1.0.1-tests.jar>
> (SHA1: 59525df8d5ac104d72c77792da2f72cf381f4420)
> /commons-jelly/commons-jelly/1.0.1/commons-jelly-1.0.1-tests.jar.asc
>  orgapachecommons-1264/commons-jelly/commons-jelly/1.0.1/
> commons-jelly-1.0.1-tests.jar.asc>
> (SHA1: c99baf87964992e674435f69e7d4270803c5b956)
> /commons-jelly/commons-jelly/1.0.1/commons-jelly-1.0.1.jar
>  orgapachecommons-1264/commons-jelly/commons-jelly/1.0.1/
> commons-jelly-1.0.1.jar>
> (SHA1: a20261c0f6be2fa4d6572fe22da0450d93195de9)
> /commons-jelly/commons-jelly/1.0.1/commons-jelly-1.0.1.jar.asc
>  orgapachecommons-1264/commons-jelly/commons-jelly/1.0.1/
> commons-jelly-1.0.1.jar.asc>
> (SHA1: 68fb5704f4ca3aefe4fa3369c85b3257be7bfa2c)
> /commons-jelly/commons-jelly/1.0.1/commons-jelly-1.0.1.pom
>  orgapachecommons-1264/commons-jelly/commons-jelly/1.0.1/
> commons-jelly-1.0.1.pom>
> (SHA1: ea2c451db75da2384ab5a51e9f1dc2b21c8e14cb)
> /commons-jelly/commons-jelly/1.0.1/commons-jelly-1.0.1.pom.asc
>  orgapachecommons-1264/commons-jelly/commons-jelly/1.0.1/
> commons-jelly-1.0.1.pom.asc>
> (SHA1: 4f1945ac4669c0bdb186f37d4bc56a864a6c5050)
>
> I have tested this with JDK 1.5.0_22-b03 using Ant 1.6.0. Notes on
> building can
> be found in the
> BUILDING.md, included in the source distributions. And, the only changes
> between
> release candidates are documentation and build script changes.
>
> Details of changes since 1.0 are in the release notes:
> https://dist.apache.org/repos/dist/dev/commons/jelly/RELEASE-NOTES.txt
>
> Site:
>   I have no site as this was generated with ant. My plan was to simply
> make
> minimal
>   changes to the existant site for the purpose of documenting the
> patch.
>
> KEYS:
>   https://www.apache.org/dist/commons/KEYS
>
> Please review the release candidate and vote.
> This vote will close no sooner that 72 hours from now,
> i.e. sometime after 14:00 (UTC) 23-September 2017
>
>   [ ] +1 Release these artifacts
>   [ ] +0 OK, but...
>   [ ] -0 OK, but really should fix...
>   [ ] -1 I oppose this release because...
>
> Thanks!
> Rob
> 

Re: [VOTE] Release commons-jelly-1.0.1 based on RC6

[Gary Gregory]

Yep, that does it! Bug in the BUILDING.md then. Not a blocker but should be
fixed in the repo ASAP.

Gary

On Wed, Sep 20, 2017 at 11:03 AM, Rob Tompkins  wrote:

> I think the "x" on the volume mount with /root/commons-jelly-1.X needs to
> be capitalized.
>
> > On Sep 20, 2017, at 12:44 PM, Gary Gregory 
> wrote:
> >
> > Should the answer.txt and install.sh files be in the src zip file?
> >
> > Gary
> >
> > On Wed, Sep 20, 2017 at 10:42 AM, Gary Gregory 
> > wrote:
> >
> >> Hi,
> >>
> >> I think I missed a step... I get:
> >>
> >> C:\temp\rc\commons-jelly-1.0.1-src>docker run -v
> >> C:\temp\rc\commons-jelly-1.0.1-src:/root/commons-jelly-1.x
> >> commons-jelly-build-env ant dist
> >> Buildfile: build.xml does not exist!
> >> Build failed
> >>
> >> Here is my session: https://pastebin.com/y7kFnNfn
> >>
> >> Help?
> >>
> >> Gary
> >>
> >>> On Wed, Sep 20, 2017 at 7:36 AM, Rob Tompkins 
> wrote:
> >>>
> >>> Hello,
> >>>
> >>> Commons Jelly 1.0.1 RC6 is available for review here:
> >>>  https://dist.apache.org/repos/dist/dev/commons/jelly (svn revision
> >>> 21718)
> >>>
> >>> The tag is here (tag commit 1808993):
> >>>  https://svn.apache.org/repos/asf/commons/proper/jelly/tags/c
> >>> ommons-jelly-1.0.1-RC6
> >>>
> >>> Commit the tag points at:
> >>>  1808992
> >>>
> >>> Maven Artifacts:
> >>>  https://repository.apache.org/content/repositories/orgapache
> >>> commons-1264
> >>>
> >>> These are the Maven artifacts and their hashes:
> >>>
> >>> /commons-jelly/commons-jelly/1.0.1/commons-jelly-1.0.1-javadoc.jar
> >>>  >>> ecommons-1264/commons-jelly/commons-jelly/1.0.1/commons-
> >>> jelly-1.0.1-javadoc.jar>
> >>> (SHA1: 3a81887847dac154c12171028f01e4dd252a0fd0)
> >>> /commons-jelly/commons-jelly/1.0.1/commons-jelly-1.0.1-javadoc.jar.asc
> >>>  >>> ecommons-1264/commons-jelly/commons-jelly/1.0.1/commons-
> >>> jelly-1.0.1-javadoc.jar.asc>
> >>> (SHA1: 465eea91cc0a7f088ea8bd571e4633ef1904713a)
> >>> /commons-jelly/commons-jelly/1.0.1/commons-jelly-1.0.1-sources.jar
> >>>  >>> ecommons-1264/commons-jelly/commons-jelly/1.0.1/commons-
> >>> jelly-1.0.1-sources.jar>
> >>> (SHA1: c6c6c1a54b12f268d24abc6a0f920bd2e5896d4c)
> >>> /commons-jelly/commons-jelly/1.0.1/commons-jelly-1.0.1-sources.jar.asc
> >>>  >>> ecommons-1264/commons-jelly/commons-jelly/1.0.1/commons-
> >>> jelly-1.0.1-sources.jar.asc>
> >>> (SHA1: e24cc221bed60203d74f17b93cdfb12d5ca607f6)
> >>> /commons-jelly/commons-jelly/1.0.1/commons-jelly-1.0.1-
> test-sources.jar
> >>>  >>> ecommons-1264/commons-jelly/commons-jelly/1.0.1/commons-
> >>> jelly-1.0.1-test-sources.jar>
> >>> (SHA1: 71b63b2619a8767d9d0ac0530dcb208f307261ff)
> >>> /commons-jelly/commons-jelly/1.0.1/commons-jelly-1.0.1-test-
> >>> sources.jar.asc
> >>>  >>> ecommons-1264/commons-jelly/commons-jelly/1.0.1/commons-
> >>> jelly-1.0.1-test-sources.jar.asc>
> >>> (SHA1: f07dc38b9e4da5860fdad861c815876814184570 <(681)%20418-4570>)
> >>> /commons-jelly/commons-jelly/1.0.1/commons-jelly-1.0.1-tests.jar
> >>>  >>> ecommons-1264/commons-jelly/commons-jelly/1.0.1/commons-
> >>> jelly-1.0.1-tests.jar>
> >>> (SHA1: 59525df8d5ac104d72c77792da2f72cf381f4420)
> >>> /commons-jelly/commons-jelly/1.0.1/commons-jelly-1.0.1-tests.jar.asc
> >>>  >>> ecommons-1264/commons-jelly/commons-jelly/1.0.1/commons-
> >>> jelly-1.0.1-tests.jar.asc>
> >>> (SHA1: c99baf87964992e674435f69e7d4270803c5b956)
> >>> /commons-jelly/commons-jelly/1.0.1/commons-jelly-1.0.1.jar
> >>>  >>> ecommons-1264/commons-jelly/commons-jelly/1.0.1/commons-
> jelly-1.0.1.jar>
> >>> (SHA1: a20261c0f6be2fa4d6572fe22da0450d93195de9)
> >>> /commons-jelly/commons-jelly/1.0.1/commons-jelly-1.0.1.jar.asc
> >>>  >>> ecommons-1264/commons-jelly/commons-jelly/1.0.1/commons-
> >>> jelly-1.0.1.jar.asc>
> >>> (SHA1: 68fb5704f4ca3aefe4fa3369c85b3257be7bfa2c)
> >>> /commons-jelly/commons-jelly/1.0.1/commons-jelly-1.0.1.pom
> >>>  >>> ecommons-1264/commons-jelly/commons-jelly/1.0.1/commons-
> jelly-1.0.1.pom>
> >>> (SHA1: ea2c451db75da2384ab5a51e9f1dc2b21c8e14cb)
> >>> /commons-jelly/commons-jelly/1.0.1/commons-jelly-1.0.1.pom.asc
> >>>  >>> ecommons-1264/commons-jelly/commons-jelly/1.0.1/commons-
> >>> jelly-1.0.1.pom.asc>
> >>> (SHA1: 

Re: [VOTE] Release commons-jelly-1.0.1 based on RC6

[Rob Tompkins]

I think the "x" on the volume mount with /root/commons-jelly-1.X needs to be 
capitalized. 

> On Sep 20, 2017, at 12:44 PM, Gary Gregory  wrote:
> 
> Should the answer.txt and install.sh files be in the src zip file?
> 
> Gary
> 
> On Wed, Sep 20, 2017 at 10:42 AM, Gary Gregory 
> wrote:
> 
>> Hi,
>> 
>> I think I missed a step... I get:
>> 
>> C:\temp\rc\commons-jelly-1.0.1-src>docker run -v
>> C:\temp\rc\commons-jelly-1.0.1-src:/root/commons-jelly-1.x
>> commons-jelly-build-env ant dist
>> Buildfile: build.xml does not exist!
>> Build failed
>> 
>> Here is my session: https://pastebin.com/y7kFnNfn
>> 
>> Help?
>> 
>> Gary
>> 
>>> On Wed, Sep 20, 2017 at 7:36 AM, Rob Tompkins  wrote:
>>> 
>>> Hello,
>>> 
>>> Commons Jelly 1.0.1 RC6 is available for review here:
>>>  https://dist.apache.org/repos/dist/dev/commons/jelly (svn revision
>>> 21718)
>>> 
>>> The tag is here (tag commit 1808993):
>>>  https://svn.apache.org/repos/asf/commons/proper/jelly/tags/c
>>> ommons-jelly-1.0.1-RC6
>>> 
>>> Commit the tag points at:
>>>  1808992
>>> 
>>> Maven Artifacts:
>>>  https://repository.apache.org/content/repositories/orgapache
>>> commons-1264
>>> 
>>> These are the Maven artifacts and their hashes:
>>> 
>>> /commons-jelly/commons-jelly/1.0.1/commons-jelly-1.0.1-javadoc.jar
>>> >> ecommons-1264/commons-jelly/commons-jelly/1.0.1/commons-
>>> jelly-1.0.1-javadoc.jar>
>>> (SHA1: 3a81887847dac154c12171028f01e4dd252a0fd0)
>>> /commons-jelly/commons-jelly/1.0.1/commons-jelly-1.0.1-javadoc.jar.asc
>>> >> ecommons-1264/commons-jelly/commons-jelly/1.0.1/commons-
>>> jelly-1.0.1-javadoc.jar.asc>
>>> (SHA1: 465eea91cc0a7f088ea8bd571e4633ef1904713a)
>>> /commons-jelly/commons-jelly/1.0.1/commons-jelly-1.0.1-sources.jar
>>> >> ecommons-1264/commons-jelly/commons-jelly/1.0.1/commons-
>>> jelly-1.0.1-sources.jar>
>>> (SHA1: c6c6c1a54b12f268d24abc6a0f920bd2e5896d4c)
>>> /commons-jelly/commons-jelly/1.0.1/commons-jelly-1.0.1-sources.jar.asc
>>> >> ecommons-1264/commons-jelly/commons-jelly/1.0.1/commons-
>>> jelly-1.0.1-sources.jar.asc>
>>> (SHA1: e24cc221bed60203d74f17b93cdfb12d5ca607f6)
>>> /commons-jelly/commons-jelly/1.0.1/commons-jelly-1.0.1-test-sources.jar
>>> >> ecommons-1264/commons-jelly/commons-jelly/1.0.1/commons-
>>> jelly-1.0.1-test-sources.jar>
>>> (SHA1: 71b63b2619a8767d9d0ac0530dcb208f307261ff)
>>> /commons-jelly/commons-jelly/1.0.1/commons-jelly-1.0.1-test-
>>> sources.jar.asc
>>> >> ecommons-1264/commons-jelly/commons-jelly/1.0.1/commons-
>>> jelly-1.0.1-test-sources.jar.asc>
>>> (SHA1: f07dc38b9e4da5860fdad861c815876814184570 <(681)%20418-4570>)
>>> /commons-jelly/commons-jelly/1.0.1/commons-jelly-1.0.1-tests.jar
>>> >> ecommons-1264/commons-jelly/commons-jelly/1.0.1/commons-
>>> jelly-1.0.1-tests.jar>
>>> (SHA1: 59525df8d5ac104d72c77792da2f72cf381f4420)
>>> /commons-jelly/commons-jelly/1.0.1/commons-jelly-1.0.1-tests.jar.asc
>>> >> ecommons-1264/commons-jelly/commons-jelly/1.0.1/commons-
>>> jelly-1.0.1-tests.jar.asc>
>>> (SHA1: c99baf87964992e674435f69e7d4270803c5b956)
>>> /commons-jelly/commons-jelly/1.0.1/commons-jelly-1.0.1.jar
>>> >> ecommons-1264/commons-jelly/commons-jelly/1.0.1/commons-jelly-1.0.1.jar>
>>> (SHA1: a20261c0f6be2fa4d6572fe22da0450d93195de9)
>>> /commons-jelly/commons-jelly/1.0.1/commons-jelly-1.0.1.jar.asc
>>> >> ecommons-1264/commons-jelly/commons-jelly/1.0.1/commons-
>>> jelly-1.0.1.jar.asc>
>>> (SHA1: 68fb5704f4ca3aefe4fa3369c85b3257be7bfa2c)
>>> /commons-jelly/commons-jelly/1.0.1/commons-jelly-1.0.1.pom
>>> >> ecommons-1264/commons-jelly/commons-jelly/1.0.1/commons-jelly-1.0.1.pom>
>>> (SHA1: ea2c451db75da2384ab5a51e9f1dc2b21c8e14cb)
>>> /commons-jelly/commons-jelly/1.0.1/commons-jelly-1.0.1.pom.asc
>>> >> ecommons-1264/commons-jelly/commons-jelly/1.0.1/commons-
>>> jelly-1.0.1.pom.asc>
>>> (SHA1: 4f1945ac4669c0bdb186f37d4bc56a864a6c5050)
>>> 
>>> I have tested this with JDK 1.5.0_22-b03 using Ant 1.6.0. Notes on
>>> building can
>>> be found in the
>>> BUILDING.md, included in the source distributions. And, the only changes
>>> between
>>> release candidates are documentation and build script changes.
>>> 
>>> Details of changes since 1.0 are in the release notes:
>>>

Re: [COLLECTIONS] module-info.java and Java 9 (Was: [COLLECTIONS] Time for 4.2)

[Gary Gregory]

On Wed, Sep 20, 2017 at 10:46 AM, Stephen Colebourne 
wrote:

> On 20 September 2017 at 17:12, Benedikt Ritter  wrote:
> >> Von: Stephen Colebourne 
> >> I've not got maven to work with actual module-info.java files yet on
> >> the Joda projects, but they are a more complex setup. Maybe
> >> [collections] could be the first to get a real module-info? There are
> >> no dependencies, right?
> >
> > There are test dependencies.
> >
> > And I wonder how we can create a jar that is also valid on JVM 7 and 8.
> Do they ignore the module-info.class which would be included? Or do we have
> to create a Multi-Release jar? The build will definitely require Java 9.
>
> I've not managed to get this pattern to work on my projects yet:
> http://maven.apache.org/plugins/maven-compiler-plugin/
> examples/module-info.html
>
> There should be no need for a multi-release jar - the
> module-info.class file will just be ignored (not class loaded) by
> previous versions even though it is in the jar file.
>

One reason NOT to do this now is that other tools will see this class file,
try to load it, and blow up, as I've seen with Android tools :-(

Gary

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

Re: [COLLECTIONS] module-info.java and Java 9 (Was: [COLLECTIONS] Time for 4.2)

[Stephen Colebourne]

On 20 September 2017 at 17:12, Benedikt Ritter  wrote:
>> Von: Stephen Colebourne 
>> I've not got maven to work with actual module-info.java files yet on
>> the Joda projects, but they are a more complex setup. Maybe
>> [collections] could be the first to get a real module-info? There are
>> no dependencies, right?
>
> There are test dependencies.
>
> And I wonder how we can create a jar that is also valid on JVM 7 and 8. Do 
> they ignore the module-info.class which would be included? Or do we have to 
> create a Multi-Release jar? The build will definitely require Java 9.

I've not managed to get this pattern to work on my projects yet:
http://maven.apache.org/plugins/maven-compiler-plugin/examples/module-info.html

There should be no need for a multi-release jar - the
module-info.class file will just be ignored (not class loaded) by
previous versions even though it is in the jar file.
Stephen

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

Re: [COLLECTIONS] Time for 4.2

[Stephen Colebourne]

On 20 September 2017 at 17:21, Matt Benson  wrote:
> On Sep 20, 2017 11:08 AM, "Stephen Colebourne"  wrote:
>
> I think its worth the extra step of checking the conditions are right
> for adding the Automatic-Module-Name manifest entry.
>
>
> Wouldn't that just offload the decision to "when to update the parent
> version in the component?"

No, I expect that not all commons components will be suitable to be modules.
Stephen

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

Re: [VOTE] Release commons-jelly-1.0.1 based on RC6

[Gary Gregory]

Should the answer.txt and install.sh files be in the src zip file?

Gary

On Wed, Sep 20, 2017 at 10:42 AM, Gary Gregory 
wrote:

> Hi,
>
> I think I missed a step... I get:
>
> C:\temp\rc\commons-jelly-1.0.1-src>docker run -v
> C:\temp\rc\commons-jelly-1.0.1-src:/root/commons-jelly-1.x
> commons-jelly-build-env ant dist
> Buildfile: build.xml does not exist!
> Build failed
>
> Here is my session: https://pastebin.com/y7kFnNfn
>
> Help?
>
> Gary
>
> On Wed, Sep 20, 2017 at 7:36 AM, Rob Tompkins  wrote:
>
>> Hello,
>>
>> Commons Jelly 1.0.1 RC6 is available for review here:
>>   https://dist.apache.org/repos/dist/dev/commons/jelly (svn revision
>> 21718)
>>
>> The tag is here (tag commit 1808993):
>>   https://svn.apache.org/repos/asf/commons/proper/jelly/tags/c
>> ommons-jelly-1.0.1-RC6
>>
>> Commit the tag points at:
>>   1808992
>>
>> Maven Artifacts:
>>   https://repository.apache.org/content/repositories/orgapache
>> commons-1264
>>
>> These are the Maven artifacts and their hashes:
>>
>> /commons-jelly/commons-jelly/1.0.1/commons-jelly-1.0.1-javadoc.jar
>> > ecommons-1264/commons-jelly/commons-jelly/1.0.1/commons-
>> jelly-1.0.1-javadoc.jar>
>> (SHA1: 3a81887847dac154c12171028f01e4dd252a0fd0)
>> /commons-jelly/commons-jelly/1.0.1/commons-jelly-1.0.1-javadoc.jar.asc
>> > ecommons-1264/commons-jelly/commons-jelly/1.0.1/commons-
>> jelly-1.0.1-javadoc.jar.asc>
>> (SHA1: 465eea91cc0a7f088ea8bd571e4633ef1904713a)
>> /commons-jelly/commons-jelly/1.0.1/commons-jelly-1.0.1-sources.jar
>> > ecommons-1264/commons-jelly/commons-jelly/1.0.1/commons-
>> jelly-1.0.1-sources.jar>
>> (SHA1: c6c6c1a54b12f268d24abc6a0f920bd2e5896d4c)
>> /commons-jelly/commons-jelly/1.0.1/commons-jelly-1.0.1-sources.jar.asc
>> > ecommons-1264/commons-jelly/commons-jelly/1.0.1/commons-
>> jelly-1.0.1-sources.jar.asc>
>> (SHA1: e24cc221bed60203d74f17b93cdfb12d5ca607f6)
>> /commons-jelly/commons-jelly/1.0.1/commons-jelly-1.0.1-test-sources.jar
>> > ecommons-1264/commons-jelly/commons-jelly/1.0.1/commons-
>> jelly-1.0.1-test-sources.jar>
>> (SHA1: 71b63b2619a8767d9d0ac0530dcb208f307261ff)
>> /commons-jelly/commons-jelly/1.0.1/commons-jelly-1.0.1-test-
>> sources.jar.asc
>> > ecommons-1264/commons-jelly/commons-jelly/1.0.1/commons-
>> jelly-1.0.1-test-sources.jar.asc>
>> (SHA1: f07dc38b9e4da5860fdad861c815876814184570 <(681)%20418-4570>)
>> /commons-jelly/commons-jelly/1.0.1/commons-jelly-1.0.1-tests.jar
>> > ecommons-1264/commons-jelly/commons-jelly/1.0.1/commons-
>> jelly-1.0.1-tests.jar>
>> (SHA1: 59525df8d5ac104d72c77792da2f72cf381f4420)
>> /commons-jelly/commons-jelly/1.0.1/commons-jelly-1.0.1-tests.jar.asc
>> > ecommons-1264/commons-jelly/commons-jelly/1.0.1/commons-
>> jelly-1.0.1-tests.jar.asc>
>> (SHA1: c99baf87964992e674435f69e7d4270803c5b956)
>> /commons-jelly/commons-jelly/1.0.1/commons-jelly-1.0.1.jar
>> > ecommons-1264/commons-jelly/commons-jelly/1.0.1/commons-jelly-1.0.1.jar>
>> (SHA1: a20261c0f6be2fa4d6572fe22da0450d93195de9)
>> /commons-jelly/commons-jelly/1.0.1/commons-jelly-1.0.1.jar.asc
>> > ecommons-1264/commons-jelly/commons-jelly/1.0.1/commons-
>> jelly-1.0.1.jar.asc>
>> (SHA1: 68fb5704f4ca3aefe4fa3369c85b3257be7bfa2c)
>> /commons-jelly/commons-jelly/1.0.1/commons-jelly-1.0.1.pom
>> > ecommons-1264/commons-jelly/commons-jelly/1.0.1/commons-jelly-1.0.1.pom>
>> (SHA1: ea2c451db75da2384ab5a51e9f1dc2b21c8e14cb)
>> /commons-jelly/commons-jelly/1.0.1/commons-jelly-1.0.1.pom.asc
>> > ecommons-1264/commons-jelly/commons-jelly/1.0.1/commons-
>> jelly-1.0.1.pom.asc>
>> (SHA1: 4f1945ac4669c0bdb186f37d4bc56a864a6c5050)
>>
>> I have tested this with JDK 1.5.0_22-b03 using Ant 1.6.0. Notes on
>> building can
>> be found in the
>> BUILDING.md, included in the source distributions. And, the only changes
>> between
>> release candidates are documentation and build script changes.
>>
>> Details of changes since 1.0 are in the release notes:
>> https://dist.apache.org/repos/dist/dev/commons/jelly/RELEASE
>> -NOTES.txt
>>
>> Site:
>>   I have no site as this was generated with ant. My plan was to
>> simply make
>> minimal
>>   changes to the existant site for the purpose of documenting the
>> patch.
>>
>> KEYS:
>>   

Re: [VOTE] Release commons-jelly-1.0.1 based on RC6

[Gary Gregory]

Hi,

I think I missed a step... I get:

C:\temp\rc\commons-jelly-1.0.1-src>docker run -v
C:\temp\rc\commons-jelly-1.0.1-src:/root/commons-jelly-1.x
commons-jelly-build-env ant dist
Buildfile: build.xml does not exist!
Build failed

Here is my session: https://pastebin.com/y7kFnNfn

Help?

Gary

On Wed, Sep 20, 2017 at 7:36 AM, Rob Tompkins  wrote:

> Hello,
>
> Commons Jelly 1.0.1 RC6 is available for review here:
>   https://dist.apache.org/repos/dist/dev/commons/jelly (svn revision
> 21718)
>
> The tag is here (tag commit 1808993):
>   https://svn.apache.org/repos/asf/commons/proper/jelly/tags/
> commons-jelly-1.0.1-RC6
>
> Commit the tag points at:
>   1808992
>
> Maven Artifacts:
>   https://repository.apache.org/content/repositories/orgapachecommons-1264
>
> These are the Maven artifacts and their hashes:
>
> /commons-jelly/commons-jelly/1.0.1/commons-jelly-1.0.1-javadoc.jar
>  orgapachecommons-1264/commons-jelly/commons-jelly/1.0.1/
> commons-jelly-1.0.1-javadoc.jar>
> (SHA1: 3a81887847dac154c12171028f01e4dd252a0fd0)
> /commons-jelly/commons-jelly/1.0.1/commons-jelly-1.0.1-javadoc.jar.asc
>  orgapachecommons-1264/commons-jelly/commons-jelly/1.0.1/
> commons-jelly-1.0.1-javadoc.jar.asc>
> (SHA1: 465eea91cc0a7f088ea8bd571e4633ef1904713a)
> /commons-jelly/commons-jelly/1.0.1/commons-jelly-1.0.1-sources.jar
>  orgapachecommons-1264/commons-jelly/commons-jelly/1.0.1/
> commons-jelly-1.0.1-sources.jar>
> (SHA1: c6c6c1a54b12f268d24abc6a0f920bd2e5896d4c)
> /commons-jelly/commons-jelly/1.0.1/commons-jelly-1.0.1-sources.jar.asc
>  orgapachecommons-1264/commons-jelly/commons-jelly/1.0.1/
> commons-jelly-1.0.1-sources.jar.asc>
> (SHA1: e24cc221bed60203d74f17b93cdfb12d5ca607f6)
> /commons-jelly/commons-jelly/1.0.1/commons-jelly-1.0.1-test-sources.jar
>  orgapachecommons-1264/commons-jelly/commons-jelly/1.0.1/
> commons-jelly-1.0.1-test-sources.jar>
> (SHA1: 71b63b2619a8767d9d0ac0530dcb208f307261ff)
> /commons-jelly/commons-jelly/1.0.1/commons-jelly-1.0.1-
> test-sources.jar.asc
>  orgapachecommons-1264/commons-jelly/commons-jelly/1.0.1/
> commons-jelly-1.0.1-test-sources.jar.asc>
> (SHA1: f07dc38b9e4da5860fdad861c815876814184570)
> /commons-jelly/commons-jelly/1.0.1/commons-jelly-1.0.1-tests.jar
>  orgapachecommons-1264/commons-jelly/commons-jelly/1.0.1/
> commons-jelly-1.0.1-tests.jar>
> (SHA1: 59525df8d5ac104d72c77792da2f72cf381f4420)
> /commons-jelly/commons-jelly/1.0.1/commons-jelly-1.0.1-tests.jar.asc
>  orgapachecommons-1264/commons-jelly/commons-jelly/1.0.1/
> commons-jelly-1.0.1-tests.jar.asc>
> (SHA1: c99baf87964992e674435f69e7d4270803c5b956)
> /commons-jelly/commons-jelly/1.0.1/commons-jelly-1.0.1.jar
>  orgapachecommons-1264/commons-jelly/commons-jelly/1.0.1/
> commons-jelly-1.0.1.jar>
> (SHA1: a20261c0f6be2fa4d6572fe22da0450d93195de9)
> /commons-jelly/commons-jelly/1.0.1/commons-jelly-1.0.1.jar.asc
>  orgapachecommons-1264/commons-jelly/commons-jelly/1.0.1/
> commons-jelly-1.0.1.jar.asc>
> (SHA1: 68fb5704f4ca3aefe4fa3369c85b3257be7bfa2c)
> /commons-jelly/commons-jelly/1.0.1/commons-jelly-1.0.1.pom
>  orgapachecommons-1264/commons-jelly/commons-jelly/1.0.1/
> commons-jelly-1.0.1.pom>
> (SHA1: ea2c451db75da2384ab5a51e9f1dc2b21c8e14cb)
> /commons-jelly/commons-jelly/1.0.1/commons-jelly-1.0.1.pom.asc
>  orgapachecommons-1264/commons-jelly/commons-jelly/1.0.1/
> commons-jelly-1.0.1.pom.asc>
> (SHA1: 4f1945ac4669c0bdb186f37d4bc56a864a6c5050)
>
> I have tested this with JDK 1.5.0_22-b03 using Ant 1.6.0. Notes on
> building can
> be found in the
> BUILDING.md, included in the source distributions. And, the only changes
> between
> release candidates are documentation and build script changes.
>
> Details of changes since 1.0 are in the release notes:
> https://dist.apache.org/repos/dist/dev/commons/jelly/RELEASE-NOTES.txt
>
> Site:
>   I have no site as this was generated with ant. My plan was to simply
> make
> minimal
>   changes to the existant site for the purpose of documenting the
> patch.
>
> KEYS:
>   https://www.apache.org/dist/commons/KEYS
>
> Please review the release candidate and vote.
> This vote will close no sooner that 72 hours from now,
> i.e. sometime after 14:00 (UTC) 23-September 2017
>
>   [ ] +1 Release these artifacts
>   [ ] +0 OK, but...
>   [ ] -0 OK, but really should fix...
>   [ ] -1 I oppose this release 

Re: [COLLECTIONS] Time for 4.2

[Matt Benson]

On Sep 20, 2017 11:08 AM, "Stephen Colebourne"  wrote:

I think its worth the extra step of checking the conditions are right
for adding the Automatic-Module-Name manifest entry.


Wouldn't that just offload the decision to "when to update the parent
version in the component?"

Matt


I've not got maven to work with actual module-info.java files yet on
the Joda projects, but they are a more complex setup. Maybe
[collections] could be the first to get a real module-info? There are
no dependencies, right?

Stephen



On 20 September 2017 at 17:03, Benedikt Ritter  wrote:
> Hi,
>
>> Am 20.09.2017 um 15:33 schrieb Gary Gregory :
>>
>> How about dealing with the Automatic-Module-Name MANIFEST header in the
>> parent POM and releasing that POM first?
>
> Stephen Colebourne said that we have to check on a per component basis
whether the component is ready to be released as Java 9 module. For this
reason we wanted to add this to every component individually. At least that
is what I recall.
>
> Benedikt
>
>>
>> Gary
>>
>> On Wed, Sep 20, 2017 at 1:20 AM, Benedikt Ritter 
wrote:
>>
>>> Hi,
>>>
>>> I’d like to release Commons Collections 4.2 soon, because I want to get
>>> COLLECTIONS-658 [1] (Automatic-Module-Name MANIFEST header) out of the
>>> door. Please let me know if you want to add something.
>>>
>>> Regards,
>>> Benedikt
>>>
>>> [1] https://issues.apache.org/jira/browse/COLLECTIONS-658
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>>> For additional commands, e-mail: dev-h...@commons.apache.org
>>>
>>>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>

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

[COLLECTIONS] module-info.java and Java 9 (Was: [COLLECTIONS] Time for 4.2)

[Benedikt Ritter]

Hi,

> Anfang der weitergeleiteten Nachricht:
> 
> Von: Stephen Colebourne 
> Betreff: Aw: [COLLECTIONS] Time for 4.2
> Datum: 20. September 2017 um 18:08:33 MESZ
> An: Commons Developers List 
> Antwort an: "Commons Developers List" 
> 
> I think its worth the extra step of checking the conditions are right
> for adding the Automatic-Module-Name manifest entry.
> 
> I've not got maven to work with actual module-info.java files yet on
> the Joda projects, but they are a more complex setup. Maybe
> [collections] could be the first to get a real module-info? There are
> no dependencies, right?

There are test dependencies. 

And I wonder how we can create a jar that is also valid on JVM 7 and 8. Do they 
ignore the module-info.class which would be included? Or do we have to create a 
Multi-Release jar? The build will definitely require Java 9.

Cheers,
Benedikt

> 
> Stephen
> 
> 
> 
> On 20 September 2017 at 17:03, Benedikt Ritter  wrote:
>> Hi,
>> 
>>> Am 20.09.2017 um 15:33 schrieb Gary Gregory :
>>> 
>>> How about dealing with the Automatic-Module-Name MANIFEST header in the
>>> parent POM and releasing that POM first?
>> 
>> Stephen Colebourne said that we have to check on a per component basis 
>> whether the component is ready to be released as Java 9 module. For this 
>> reason we wanted to add this to every component individually. At least that 
>> is what I recall.
>> 
>> Benedikt
>> 
>>> 
>>> Gary
>>> 
>>> On Wed, Sep 20, 2017 at 1:20 AM, Benedikt Ritter  wrote:
>>> 
 Hi,
 
 I’d like to release Commons Collections 4.2 soon, because I want to get
 COLLECTIONS-658 [1] (Automatic-Module-Name MANIFEST header) out of the
 door. Please let me know if you want to add something.
 
 Regards,
 Benedikt
 
 [1] https://issues.apache.org/jira/browse/COLLECTIONS-658
 -
 To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
 For additional commands, e-mail: dev-h...@commons.apache.org
 
 
>> 
>> 
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> For additional commands, e-mail: dev-h...@commons.apache.org
>> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
> 

Re: [COLLECTIONS] Time for 4.2

[Gary Gregory]

On Wed, Sep 20, 2017 at 10:08 AM, Stephen Colebourne 
wrote:

> I think its worth the extra step of checking the conditions are right
> for adding the Automatic-Module-Name manifest entry.
>
> I've not got maven to work with actual module-info.java files yet on
> the Joda projects, but they are a more complex setup. Maybe
> [collections] could be the first to get a real module-info? There are
> no dependencies, right?
>

Hi,

Correct, [collections4] has no runtime dependencies, only test
dependencies: JUnit and EasyMock.

Gary

>
> Stephen
>
>
>
> On 20 September 2017 at 17:03, Benedikt Ritter  wrote:
> > Hi,
> >
> >> Am 20.09.2017 um 15:33 schrieb Gary Gregory :
> >>
> >> How about dealing with the Automatic-Module-Name MANIFEST header in the
> >> parent POM and releasing that POM first?
> >
> > Stephen Colebourne said that we have to check on a per component basis
> whether the component is ready to be released as Java 9 module. For this
> reason we wanted to add this to every component individually. At least that
> is what I recall.
> >
> > Benedikt
> >
> >>
> >> Gary
> >>
> >> On Wed, Sep 20, 2017 at 1:20 AM, Benedikt Ritter 
> wrote:
> >>
> >>> Hi,
> >>>
> >>> I’d like to release Commons Collections 4.2 soon, because I want to get
> >>> COLLECTIONS-658 [1] (Automatic-Module-Name MANIFEST header) out of the
> >>> door. Please let me know if you want to add something.
> >>>
> >>> Regards,
> >>> Benedikt
> >>>
> >>> [1] https://issues.apache.org/jira/browse/COLLECTIONS-658
> >>> -
> >>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> >>> For additional commands, e-mail: dev-h...@commons.apache.org
> >>>
> >>>
> >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > For additional commands, e-mail: dev-h...@commons.apache.org
> >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: [COLLECTIONS] Time for 4.2

[Stephen Colebourne]

I think its worth the extra step of checking the conditions are right
for adding the Automatic-Module-Name manifest entry.

I've not got maven to work with actual module-info.java files yet on
the Joda projects, but they are a more complex setup. Maybe
[collections] could be the first to get a real module-info? There are
no dependencies, right?

Stephen



On 20 September 2017 at 17:03, Benedikt Ritter  wrote:
> Hi,
>
>> Am 20.09.2017 um 15:33 schrieb Gary Gregory :
>>
>> How about dealing with the Automatic-Module-Name MANIFEST header in the
>> parent POM and releasing that POM first?
>
> Stephen Colebourne said that we have to check on a per component basis 
> whether the component is ready to be released as Java 9 module. For this 
> reason we wanted to add this to every component individually. At least that 
> is what I recall.
>
> Benedikt
>
>>
>> Gary
>>
>> On Wed, Sep 20, 2017 at 1:20 AM, Benedikt Ritter  wrote:
>>
>>> Hi,
>>>
>>> I’d like to release Commons Collections 4.2 soon, because I want to get
>>> COLLECTIONS-658 [1] (Automatic-Module-Name MANIFEST header) out of the
>>> door. Please let me know if you want to add something.
>>>
>>> Regards,
>>> Benedikt
>>>
>>> [1] https://issues.apache.org/jira/browse/COLLECTIONS-658
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>>> For additional commands, e-mail: dev-h...@commons.apache.org
>>>
>>>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>

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

Re: commons-collections git commit: COLLECTIONS-658: Add Automatic-Module-Name MANIFEST entry for Java 9 compatibility.

[Benedikt Ritter]

> Am 20.09.2017 um 15:33 schrieb Gary Gregory :
> 
> Why not do this in the parent POM and release it then? ;-)

See the other thread. We can not do this for all components since we need to 
review on a per component basis whether the component is ready to be released 
as Java 9 module.

Cheers,
Benedikt

> 
> Gary
> 
> On Wed, Sep 20, 2017 at 1:17 AM,  wrote:
> 
>> Repository: commons-collections
>> Updated Branches:
>>  refs/heads/master d95543d81 -> 80ec288ee
>> 
>> 
>> COLLECTIONS-658: Add Automatic-Module-Name MANIFEST entry for Java 9
>> compatibility.
>> 
>> 
>> Project: http://git-wip-us.apache.org/repos/asf/commons-collections/repo
>> Commit: http://git-wip-us.apache.org/repos/asf/commons-collections/
>> commit/80ec288e
>> Tree: http://git-wip-us.apache.org/repos/asf/commons-collections/
>> tree/80ec288e
>> Diff: http://git-wip-us.apache.org/repos/asf/commons-collections/
>> diff/80ec288e
>> 
>> Branch: refs/heads/master
>> Commit: 80ec288ee76bc278d70aa234cbea407a2c9e82a2
>> Parents: d95543d
>> Author: Benedikt Ritter 
>> Authored: Wed Sep 20 09:16:53 2017 +0200
>> Committer: Benedikt Ritter 
>> Committed: Wed Sep 20 09:16:53 2017 +0200
>> 
>> --
>> pom.xml | 19 +++
>> src/changes/changes.xml |  3 +++
>> 2 files changed, 22 insertions(+)
>> --
>> 
>> 
>> http://git-wip-us.apache.org/repos/asf/commons-collections/
>> blob/80ec288e/pom.xml
>> --
>> diff --git a/pom.xml b/pom.xml
>> index d98ad2d..d122e56 100644
>> --- a/pom.xml
>> +++ b/pom.xml
>> @@ -570,6 +570,25 @@
>>   
>> 
>>   
>> +  
>> +org.apache.maven.plugins
>> +maven-jar-plugin
>> +
>> +  
>> +
>> +  test-jar
>> +
>> +  
>> +
>> +
>> +
>> +  
>> +
>> +  org.apache.commons.collections4> Automatic-Module-Name>
>> +
>> +  
>> +
>> +  
>> 
>>   
>> 
>> 
>> http://git-wip-us.apache.org/repos/asf/commons-collections/
>> blob/80ec288e/src/changes/changes.xml
>> --
>> diff --git a/src/changes/changes.xml b/src/changes/changes.xml
>> index efc7a9b..c355be7 100644
>> --- a/src/changes/changes.xml
>> +++ b/src/changes/changes.xml
>> @@ -21,6 +21,9 @@
>>   
>>   
>>   
>> +
>> +  Add Automatic-Module-Name MANIFEST entry for Java 9 compatibility
>> +
>> 
>>   Fix site build on Java 8
>> 
>> 
>> 


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

Re: [COLLECTIONS] Time for 4.2

[Benedikt Ritter]

Hi,

> Am 20.09.2017 um 15:33 schrieb Gary Gregory :
> 
> How about dealing with the Automatic-Module-Name MANIFEST header in the
> parent POM and releasing that POM first?

Stephen Colebourne said that we have to check on a per component basis whether 
the component is ready to be released as Java 9 module. For this reason we 
wanted to add this to every component individually. At least that is what I 
recall.

Benedikt

> 
> Gary
> 
> On Wed, Sep 20, 2017 at 1:20 AM, Benedikt Ritter  wrote:
> 
>> Hi,
>> 
>> I’d like to release Commons Collections 4.2 soon, because I want to get
>> COLLECTIONS-658 [1] (Automatic-Module-Name MANIFEST header) out of the
>> door. Please let me know if you want to add something.
>> 
>> Regards,
>> Benedikt
>> 
>> [1] https://issues.apache.org/jira/browse/COLLECTIONS-658
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> For additional commands, e-mail: dev-h...@commons.apache.org
>> 
>> 


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

Re: [COLLECTIONS] Time for 4.2

[Gilles]

On Wed, 20 Sep 2017 17:49:38 +0200, Stefan Bodewig wrote:

On 2017-09-20, Gilles wrote:


On Wed, 20 Sep 2017 07:33:55 -0600, Gary Gregory wrote:



How about dealing with the Automatic-Module-Name MANIFEST header in
the parent POM and releasing that POM first?



Is there a solution to this issue:
  https://issues.apache.org/jira/browse/RNG-31


I'm afraid Gary and you are talking about completely different things
(and either of you as well as myself should have changed the subject
line ;-)


I did some 20 minutes ago. :-)



Unfortunately I cannot answer the question about signatures for 
modular

builds, I'm not really a maven person. What I can say is that I never
invoke any "assembly" goal when I create a release, the signatures 
are

created as a byproduct of running "deploy".


"deploy" will upload to the nexus server, and there is no
problem (signatures are generated automagically).
The problem is for the official distribution (on "dist"): a complete
archive is generated but not signed. :-/
[At least that was what "parent" was (not) doing when RNG v1.0.]

Gilles



Stefan



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

Re: [COLLECTIONS] Time for 4.2

[Stefan Bodewig]

On 2017-09-20, Gilles wrote:

> On Wed, 20 Sep 2017 07:33:55 -0600, Gary Gregory wrote:

>> How about dealing with the Automatic-Module-Name MANIFEST header in
>> the parent POM and releasing that POM first?

> Is there a solution to this issue:
>   https://issues.apache.org/jira/browse/RNG-31

I'm afraid Gary and you are talking about completely different things
(and either of you as well as myself should have changed the subject
line ;-)

Unfortunately I cannot answer the question about signatures for modular
builds, I'm not really a maven person. What I can say is that I never
invoke any "assembly" goal when I create a release, the signatures are
created as a byproduct of running "deploy".

Stefan

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

[All][RNG] Generate signatures and checksums (Was: [COLLECTIONS] Time for 4.2)

[Gilles]

On Wed, 20 Sep 2017 09:19:35 -0600, Gary Gregory wrote:

[...]



Is there a solution to this issue:
  https://issues.apache.org/jira/browse/RNG-31

IOW how do other modular components handle the creation of 
signatures

and checksums for all their modules?



Some Maven magic does that.


How come that [RNG] is immune to that magic?

Gilles


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

Re: [COLLECTIONS] Time for 4.2

[Gary Gregory]

On Wed, Sep 20, 2017 at 7:57 AM, Gilles 
wrote:

> On Wed, 20 Sep 2017 07:33:55 -0600, Gary Gregory wrote:
>
>> How about dealing with the Automatic-Module-Name MANIFEST header in the
>> parent POM
>>
>
> +1
>
> and releasing that POM first?
>>
>
> Is there a solution to this issue:
>   https://issues.apache.org/jira/browse/RNG-31
>
> IOW how do other modular components handle the creation of signatures
> and checksums for all their modules?
>

Some Maven magic does that.

Gary


>
> Thanks,
> Gilles
>
>
>> Gary
>>
>> On Wed, Sep 20, 2017 at 1:20 AM, Benedikt Ritter 
>> wrote:
>>
>> Hi,
>>>
>>> I’d like to release Commons Collections 4.2 soon, because I want to get
>>> COLLECTIONS-658 [1] (Automatic-Module-Name MANIFEST header) out of the
>>> door. Please let me know if you want to add something.
>>>
>>> Regards,
>>> Benedikt
>>>
>>> [1] https://issues.apache.org/jira/browse/COLLECTIONS-658
>>>
>>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: [COLLECTIONS] Time for 4.2

[Rob Tompkins]

> On Sep 20, 2017, at 9:57 AM, Gilles  wrote:
> 
>> On Wed, 20 Sep 2017 07:33:55 -0600, Gary Gregory wrote:
>> How about dealing with the Automatic-Module-Name MANIFEST header in the
>> parent POM

I went through all of the pom's and added a property that could be used in the 
parent for the sake of generating this. Do we want to try to do a release of 
parent to get this in to all of the artifacts?

-Rob

> 
> +1
> 
>> and releasing that POM first?
> 
> Is there a solution to this issue:
>  https://issues.apache.org/jira/browse/RNG-31
> 
> IOW how do other modular components handle the creation of signatures
> and checksums for all their modules?
> 
> Thanks,
> Gilles
> 
>> 
>> Gary
>> 
>>> On Wed, Sep 20, 2017 at 1:20 AM, Benedikt Ritter  wrote:
>>> 
>>> Hi,
>>> 
>>> I’d like to release Commons Collections 4.2 soon, because I want to get
>>> COLLECTIONS-658 [1] (Automatic-Module-Name MANIFEST header) out of the
>>> door. Please let me know if you want to add something.
>>> 
>>> Regards,
>>> Benedikt
>>> 
>>> [1] https://issues.apache.org/jira/browse/COLLECTIONS-658
> 
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
> 

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

Re: [COLLECTIONS] Time for 4.2

[Gilles]

On Wed, 20 Sep 2017 07:33:55 -0600, Gary Gregory wrote:
How about dealing with the Automatic-Module-Name MANIFEST header in 
the

parent POM


+1


and releasing that POM first?


Is there a solution to this issue:
  https://issues.apache.org/jira/browse/RNG-31

IOW how do other modular components handle the creation of signatures
and checksums for all their modules?

Thanks,
Gilles



Gary

On Wed, Sep 20, 2017 at 1:20 AM, Benedikt Ritter  
wrote:



Hi,

I’d like to release Commons Collections 4.2 soon, because I want to 
get
COLLECTIONS-658 [1] (Automatic-Module-Name MANIFEST header) out of 
the

door. Please let me know if you want to add something.

Regards,
Benedikt

[1] https://issues.apache.org/jira/browse/COLLECTIONS-658




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

[VOTE] Release commons-jelly-1.0.1 based on RC6

[Rob Tompkins]

Hello,

Commons Jelly 1.0.1 RC6 is available for review here:
  https://dist.apache.org/repos/dist/dev/commons/jelly (svn revision 21718)

The tag is here (tag commit 1808993):
  
https://svn.apache.org/repos/asf/commons/proper/jelly/tags/commons-jelly-1.0.1-RC6

Commit the tag points at:
  1808992

Maven Artifacts:
  https://repository.apache.org/content/repositories/orgapachecommons-1264

These are the Maven artifacts and their hashes:

/commons-jelly/commons-jelly/1.0.1/commons-jelly-1.0.1-javadoc.jar

(SHA1: 3a81887847dac154c12171028f01e4dd252a0fd0)
/commons-jelly/commons-jelly/1.0.1/commons-jelly-1.0.1-javadoc.jar.asc

(SHA1: 465eea91cc0a7f088ea8bd571e4633ef1904713a)
/commons-jelly/commons-jelly/1.0.1/commons-jelly-1.0.1-sources.jar

(SHA1: c6c6c1a54b12f268d24abc6a0f920bd2e5896d4c)
/commons-jelly/commons-jelly/1.0.1/commons-jelly-1.0.1-sources.jar.asc

(SHA1: e24cc221bed60203d74f17b93cdfb12d5ca607f6)
/commons-jelly/commons-jelly/1.0.1/commons-jelly-1.0.1-test-sources.jar

(SHA1: 71b63b2619a8767d9d0ac0530dcb208f307261ff)
/commons-jelly/commons-jelly/1.0.1/commons-jelly-1.0.1-test-sources.jar.asc

(SHA1: f07dc38b9e4da5860fdad861c815876814184570)
/commons-jelly/commons-jelly/1.0.1/commons-jelly-1.0.1-tests.jar

(SHA1: 59525df8d5ac104d72c77792da2f72cf381f4420)
/commons-jelly/commons-jelly/1.0.1/commons-jelly-1.0.1-tests.jar.asc

(SHA1: c99baf87964992e674435f69e7d4270803c5b956)
/commons-jelly/commons-jelly/1.0.1/commons-jelly-1.0.1.jar

(SHA1: a20261c0f6be2fa4d6572fe22da0450d93195de9)
/commons-jelly/commons-jelly/1.0.1/commons-jelly-1.0.1.jar.asc

(SHA1: 68fb5704f4ca3aefe4fa3369c85b3257be7bfa2c)
/commons-jelly/commons-jelly/1.0.1/commons-jelly-1.0.1.pom

(SHA1: ea2c451db75da2384ab5a51e9f1dc2b21c8e14cb)
/commons-jelly/commons-jelly/1.0.1/commons-jelly-1.0.1.pom.asc

(SHA1: 4f1945ac4669c0bdb186f37d4bc56a864a6c5050)

I have tested this with JDK 1.5.0_22-b03 using Ant 1.6.0. Notes on building can
be found in the 
BUILDING.md, included in the source distributions. And, the only changes between
release candidates are documentation and build script changes.

Details of changes since 1.0 are in the release notes:
https://dist.apache.org/repos/dist/dev/commons/jelly/RELEASE-NOTES.txt

Site:
  I have no site as this was generated with ant. My plan was to simply make
minimal 
  changes to the existant site for the purpose of documenting the patch.

KEYS:
  https://www.apache.org/dist/commons/KEYS

Please review the release candidate and vote.
This vote will close no sooner that 72 hours from now,
i.e. sometime after 14:00 (UTC) 23-September 2017

  [ ] +1 Release these artifacts
  [ ] +0 OK, but...
  [ ] -0 OK, but really should fix...
  [ ] -1 I oppose this release because...

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

Re: [COLLECTIONS] Time for 4.2

[Gary Gregory]

How about dealing with the Automatic-Module-Name MANIFEST header in the
parent POM and releasing that POM first?

Gary

On Wed, Sep 20, 2017 at 1:20 AM, Benedikt Ritter  wrote:

> Hi,
>
> I’d like to release Commons Collections 4.2 soon, because I want to get
> COLLECTIONS-658 [1] (Automatic-Module-Name MANIFEST header) out of the
> door. Please let me know if you want to add something.
>
> Regards,
> Benedikt
>
> [1] https://issues.apache.org/jira/browse/COLLECTIONS-658
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: commons-collections git commit: COLLECTIONS-658: Add Automatic-Module-Name MANIFEST entry for Java 9 compatibility.

[Gary Gregory]

Why not do this in the parent POM and release it then? ;-)

Gary

On Wed, Sep 20, 2017 at 1:17 AM,  wrote:

> Repository: commons-collections
> Updated Branches:
>   refs/heads/master d95543d81 -> 80ec288ee
>
>
> COLLECTIONS-658: Add Automatic-Module-Name MANIFEST entry for Java 9
> compatibility.
>
>
> Project: http://git-wip-us.apache.org/repos/asf/commons-collections/repo
> Commit: http://git-wip-us.apache.org/repos/asf/commons-collections/
> commit/80ec288e
> Tree: http://git-wip-us.apache.org/repos/asf/commons-collections/
> tree/80ec288e
> Diff: http://git-wip-us.apache.org/repos/asf/commons-collections/
> diff/80ec288e
>
> Branch: refs/heads/master
> Commit: 80ec288ee76bc278d70aa234cbea407a2c9e82a2
> Parents: d95543d
> Author: Benedikt Ritter 
> Authored: Wed Sep 20 09:16:53 2017 +0200
> Committer: Benedikt Ritter 
> Committed: Wed Sep 20 09:16:53 2017 +0200
>
> --
>  pom.xml | 19 +++
>  src/changes/changes.xml |  3 +++
>  2 files changed, 22 insertions(+)
> --
>
>
> http://git-wip-us.apache.org/repos/asf/commons-collections/
> blob/80ec288e/pom.xml
> --
> diff --git a/pom.xml b/pom.xml
> index d98ad2d..d122e56 100644
> --- a/pom.xml
> +++ b/pom.xml
> @@ -570,6 +570,25 @@
>
>  
>
> +  
> +org.apache.maven.plugins
> +maven-jar-plugin
> +
> +  
> +
> +  test-jar
> +
> +  
> +
> +
> +
> +  
> +
> +  org.apache.commons.collections4 Automatic-Module-Name>
> +
> +  
> +
> +  
>  
>
>
>
> http://git-wip-us.apache.org/repos/asf/commons-collections/
> blob/80ec288e/src/changes/changes.xml
> --
> diff --git a/src/changes/changes.xml b/src/changes/changes.xml
> index efc7a9b..c355be7 100644
> --- a/src/changes/changes.xml
> +++ b/src/changes/changes.xml
> @@ -21,6 +21,9 @@
>
>
>
> +
> +  Add Automatic-Module-Name MANIFEST entry for Java 9 compatibility
> +
>  
>Fix site build on Java 8
>  
>
>

Re: [Math][Numbers] Move Field, etc. to numbers?

[Raymond DeCampo]

On Wed, Sep 20, 2017 at 7:29 AM, Gilles 
wrote:

> On Sat, 16 Sep 2017 14:19:04 -0400, Raymond DeCampo wrote:
>
>> [...]
>>
>>>
>>> So from the POV of a "Commons Numbers" developer, what is the
>>> added value of "Field"?
>>> [IMO none at the moment (but that could change).]
>>>
>>
>>
>> I'm not looking at it from the POV of a CN developer.  I am looking at it
>> from the POV of a CN user.
>>
>
> If "Commons Numbers" were only to be a copy from what is/was
> in CM I'd have to agree that there was no point in having a
> new component in the first place.
>
>
Well perhaps we have different philosophies here.  I thought the main goal
was to slice up CM into manageable pieces to allow for better releases and
to allow people to focus on the portions of the library which are important
to them without being held back by the portions which are not of interest.


> Since there are no users right now, it seems reasonable to
> me that the KISS principle should apply.
>
> I believe this is covered in the following
>> paragraph you quoted.
>>
>
> It is a nice feature, but as with any feature implemented on
> top of a more basic utility, we should first look for a solution
> that is compatible with the upstream dependency.
>
> Since Java is strongly typed and does not support duck typing without
>>>
 resorting to reflection gymnastics, there is currently no way to write
 an
 algorithm using e.g. the add() method which could be applied to
 o.a.c.n.f.Fraction and o.a.c.n.c.Complex without duplication, reflection
 or
 pointless wrapper extensions.

>>>
> You may be right.
> But is the CM solution the best we can do, now that it is
> the moment where other solutions can be explored?
>
> [...]
>>>
>>> To be blunt I don't agree with the approach
>>
>
> Which one?
>
> so I am not about to devote
>> time and effort to supporting it.
>>
>
> You are smarter than I ever was, since I devoted a lot of time
> to implement compromise decisions in CM, although I knew that
> they were bad (and proven to be so later on).
>
> You are definitely right that the wrapper approach takes a
> lot of time, mainly because of the awful amount of duplication
> in the CM unit tests classes.
> [I spent countless hours fixing the same in the RNG code.]
>
> I badly underestimated the task for "Fraction"/"BigFraction". :-/
>
> I'm also not particularly interested in
>> arguing about it.  So I have completed the portions where we have
>> agreement
>> and left the rest.
>>
>> Summarizing the other issues I found while trying to eliminate
>> BigFraction,
>> Fraction and Complex from CM:
>>
>> I found nine test classes which use FractionField, those would need to be
>> rewritten.  I imagine they could use a different Field implementation
>> without a great deal of difficulty.
>>
>
> You are quite right; the "main" code is easy to adapt.
> Adapting the unit tests, however, is a nightmare (+100 errors).
>
> And I don't understand why it had to be, since the common "Field"
> interfaces should in principle have allowed to write a test base
> class, with the actual types be automatically exercised through
> factory subclasses.


I think that the issue with the unit tests is that they used Fraction
and/or BigFraction for this purpose, i.e. a convenient implementation of
FieldElement when one was needed.


>
>
> I also found a couple of public methods in MatrixUtils that I imagine will
>> need to be deleted.  I don't think they would be missed but OTOH they were
>> added because somebody wanted them.
>>
>> What you do propose to do about the ComplexField, FractionField and
>> BigFractionField classes?  These were part of the CM API in the last
>> release are is the plan to just drop them?
>>
>
> I'd have thought they could be modified so that under the hood,
> they use the "Numbers" implementations.
>
>
The issue with this is that the Field interface specifies a method
returning the corresponding FieldElement class.  So you need FieldElement
wrapper implementations for the classes as well.  Then all you are doing is
implementing delegating methods in Fraction/BigFraction/Complex with the
wrappers - it's enough to make you want to work in a language with duck
typing.

I'm not in front of the code right now so I'm not sure this would work but,
how would you feel about including just the FieldElement interface (name
negotiable) in numbers and leaving Field in CM?

Re: [Math][Numbers] Move Field, etc. to numbers?

[Gilles]

On Sat, 16 Sep 2017 14:19:04 -0400, Raymond DeCampo wrote:

[...]


So from the POV of a "Commons Numbers" developer, what is the
added value of "Field"?
[IMO none at the moment (but that could change).]



I'm not looking at it from the POV of a CN developer.  I am looking 
at it

from the POV of a CN user.


If "Commons Numbers" were only to be a copy from what is/was
in CM I'd have to agree that there was no point in having a
new component in the first place.

Since there are no users right now, it seems reasonable to
me that the KISS principle should apply.


I believe this is covered in the following
paragraph you quoted.


It is a nice feature, but as with any feature implemented on
top of a more basic utility, we should first look for a solution
that is compatible with the upstream dependency.

Since Java is strongly typed and does not support duck typing 
without
resorting to reflection gymnastics, there is currently no way to 
write an

algorithm using e.g. the add() method which could be applied to
o.a.c.n.f.Fraction and o.a.c.n.c.Complex without duplication, 
reflection

or
pointless wrapper extensions.


You may be right.
But is the CM solution the best we can do, now that it is
the moment where other solutions can be explored?


[...]


To be blunt I don't agree with the approach


Which one?


so I am not about to devote
time and effort to supporting it.


You are smarter than I ever was, since I devoted a lot of time
to implement compromise decisions in CM, although I knew that
they were bad (and proven to be so later on).

You are definitely right that the wrapper approach takes a
lot of time, mainly because of the awful amount of duplication
in the CM unit tests classes.
[I spent countless hours fixing the same in the RNG code.]

I badly underestimated the task for "Fraction"/"BigFraction". :-/


I'm also not particularly interested in
arguing about it.  So I have completed the portions where we have 
agreement

and left the rest.

Summarizing the other issues I found while trying to eliminate 
BigFraction,

Fraction and Complex from CM:

I found nine test classes which use FractionField, those would need 
to be

rewritten.  I imagine they could use a different Field implementation
without a great deal of difficulty.


You are quite right; the "main" code is easy to adapt.
Adapting the unit tests, however, is a nightmare (+100 errors).

And I don't understand why it had to be, since the common "Field"
interfaces should in principle have allowed to write a test base
class, with the actual types be automatically exercised through
factory subclasses.

I also found a couple of public methods in MatrixUtils that I imagine 
will
need to be deleted.  I don't think they would be missed but OTOH they 
were

added because somebody wanted them.

What you do propose to do about the ComplexField, FractionField and
BigFractionField classes?  These were part of the CM API in the last
release are is the plan to just drop them?


I'd have thought they could be modified so that under the hood,
they use the "Numbers" implementations.

Gilles


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

Re: [COLLECTIONS] Time for 4.2

[Bruno P. Kinoshita]

There is another thread about failing tests on Windows that would need 
attention before the release. I am still debugging it, but am off to Australia 
in a few days, and back only in 3 weeks, so not sure if will be able to explain 
why it's happening.
CheersBruno 

  From: Benedikt Ritter 
 To: Commons Developers List  
 Sent: Wednesday, 20 September 2017 7:20 PM
 Subject: [COLLECTIONS] Time for 4.2
   
Hi,

I’d like to release Commons Collections 4.2 soon, because I want to get 
COLLECTIONS-658 [1] (Automatic-Module-Name MANIFEST header) out of the door. 
Please let me know if you want to add something.

Regards,
Benedikt

[1] https://issues.apache.org/jira/browse/COLLECTIONS-658
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org


   

[COLLECTIONS] Time for 4.2

[Benedikt Ritter]

Hi,

I’d like to release Commons Collections 4.2 soon, because I want to get 
COLLECTIONS-658 [1] (Automatic-Module-Name MANIFEST header) out of the door. 
Please let me know if you want to add something.

Regards,
Benedikt

[1] https://issues.apache.org/jira/browse/COLLECTIONS-658
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org