[GitHub] commons-io pull request #49: [IO-554] fixed: prevent input stream close

[mmariotti]

GitHub user mmariotti opened a pull request:

https://github.com/apache/commons-io/pull/49

[IO-554] fixed: prevent input stream close

[IO-554] FileUtils.copyToFile(InputStream source, File destination) closes 
input stream.
Fixed removing 'source' from try-with-resources.

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

$ git pull https://github.com/mmariotti/commons-io patch-1

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

https://github.com/apache/commons-io/pull/49.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 #49


commit c9fb10f0e45ec66cff342692fd440d06da250e88
Author: Michele Mariotti 
Date:   2017-11-05T09:32:16Z

[IO-554] fixed: prevent input stream close

[IO-554] FileUtils.copyToFile(InputStream source, File destination) closes 
input stream.
Fixed removing 'source' from try-with-resources.




---

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

Re: [PROPOSAL] Apache Commons JUnit

[Gary Gregory]

On Sat, Nov 4, 2017 at 1:44 AM, Romain Manni-Bucau 
wrote:

> Looks like a good idea but wonder if it fits commons. I kind of see a lot
> of modules already so maybe incubator?
>
> Ps: if interesting I m happy to give
> https://github.com/rmannibucau/rule-them-all and help integrating it with
> junit5 too
>

Thank you for pointing out your work.

I think we are going toward are multi-module project if only to manage
dependencies. I would not want to depend on commons-testing only to have a
ton of jars dragged in, optional or not. But I could see bringing in
commons-testing-ftp-server.

Gary


>
>
> Le 4 nov. 2017 05:45, "Bruno P. Kinoshita"
>  a écrit :
>
> > +1 for the idea and for looking at JUnit 5.x and maybe AssertJ.
> > CheersBruno
> >
> >   From: Matt Sicker 
> >  To: Commons Developers List 
> >  Sent: Saturday, 4 November 2017 1:44 PM
> >  Subject: Re: [PROPOSAL] Apache Commons JUnit
> >
> > I certainly like the idea, especially if the docs are good about pulling
> in
> > other related dependencies to complement the whole thing. General
> resource
> > management rules would be great, though, like the ones we have in Log4j.
> >
> > Also, I haven't looked closely at it yet, but supporting JUnit 5.x as
> well
> > would be nice.
> >
> > On 3 November 2017 at 18:11, Gary Gregory 
> wrote:
> >
> > > Hi All,
> > >
> > > I'd propose we start a new component called "Apache Commons JUnit".
> > >
> > > The goal would be to gather useful and reusable code like JUnit rules.
> > >
> > > This component would be focused on JUnit 4.x only.
> > >
> > > For example: org.apache.commons.collections4.junit.
> > > SetDefaultLocaleTestRule
> > >
> > > I have other rules stashed here and there as well, for example a Set
> > > Default Charset Rule.
> > >
> > > Thoughts?
> > >
> > > Gary
> > >
> >
> >
> >
> > --
> > Matt Sicker 
> >
> >
> >
>

Re: [PROPOSAL] Apache Commons JUnit

[Gary Gregory]

On Sat, Nov 4, 2017 at 11:12 AM, Gary Gregory 
wrote:

> So are you advocating for a multi-module project?
>
> - commons-testing
> - commons-testing-junit4
> - commons-testing-junit5
>
> ?
>
> Gary
>
>
> On Sat, Nov 4, 2017 at 10:58 AM, Bernd Eckenfels 
> wrote:
>
>> I like the idea (and prefer Commons Testing), for example a method to
>> list all non-daemon threads after a test run (to see there is no resource
>> leak) can be used independent of the Unit Test Framework.
>>
>
Do you have such a gadget?

Gary


>
>> Gruss
>> Bernd
>> --
>> http://bernd.eckenfels.net
>> 
>> From: Hasan Diwan 
>> Sent: Saturday, November 4, 2017 5:42:39 PM
>> To: Commons Developers List
>> Subject: Re: [PROPOSAL] Apache Commons JUnit
>>
>> How about "Apache Commons Testing"? -- H
>>
>> On 4 November 2017 at 09:10, Gary Gregory  wrote:
>>
>> > On Sat, Nov 4, 2017 at 9:32 AM, Pascal Schumacher <
>> > pascalschumac...@gmx.net>
>> > wrote:
>> >
>> > > JUnit 5 is not backwards compatible (Package/Annotation-Names have
>> > > changed, Rules were replaced by a new extension model), but it can run
>> > > JUnit 3 and JUnit 4 Tests if you add an additional dependency. See
>> > > http://junit.org/junit5/docs/current/user-guide/#migrating-f
>> rom-junit4
>> > > for details.
>> >
>> >
>> > OK, so "Apache Commons Extras for Junit 4"
>> >
>> > Gary
>> >
>> >
>> > >
>> > >
>> > > Am 04.11.2017 um 15:53 schrieb Gary Gregory:
>> > >
>> > >> I am assuming that JUnit 5 will be backward compatible with JUnit 4,
>> I
>> > >> might be wrong. I'd like to focus on a single dependency for now
>> (JUnit)
>> > >> and not do a multi-module project. If someone want to do the same for
>> > >> TestNG, then have at it. KISS and small for 1.0.
>> > >>
>> > >> Gary
>> > >>
>> > >> On Fri, Nov 3, 2017 at 10:41 PM, Bruno P. Kinoshita <
>> > >> brunodepau...@yahoo.com.br.invalid> wrote:
>> > >>
>> > >> +1 for the idea and for looking at JUnit 5.x and maybe AssertJ.
>> > >>> CheersBruno
>> > >>>
>> > >>>From: Matt Sicker 
>> > >>>   To: Commons Developers List 
>> > >>>   Sent: Saturday, 4 November 2017 1:44 PM
>> > >>>   Subject: Re: [PROPOSAL] Apache Commons JUnit
>> > >>>
>> > >>> I certainly like the idea, especially if the docs are good about
>> > pulling
>> > >>> in
>> > >>> other related dependencies to complement the whole thing. General
>> > >>> resource
>> > >>> management rules would be great, though, like the ones we have in
>> > Log4j.
>> > >>>
>> > >>> Also, I haven't looked closely at it yet, but supporting JUnit 5.x
>> as
>> > >>> well
>> > >>> would be nice.
>> > >>>
>> > >>> On 3 November 2017 at 18:11, Gary Gregory 
>> > >>> wrote:
>> > >>>
>> > >>> Hi All,
>> > 
>> >  I'd propose we start a new component called "Apache Commons JUnit".
>> > 
>> >  The goal would be to gather useful and reusable code like JUnit
>> rules.
>> > 
>> >  This component would be focused on JUnit 4.x only.
>> > 
>> >  For example: org.apache.commons.collections4.junit.
>> >  SetDefaultLocaleTestRule
>> > 
>> >  I have other rules stashed here and there as well, for example a
>> Set
>> >  Default Charset Rule.
>> > 
>> >  Thoughts?
>> > 
>> >  Gary
>> > 
>> > 
>> > >>>
>> > >>> --
>> > >>> Matt Sicker 
>> > >>>
>> > >>>
>> > >>>
>> > >>>
>> > >>>
>> > >
>> > > -
>> > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> > > For additional commands, e-mail: dev-h...@commons.apache.org
>> > >
>> > >
>> >
>>
>>
>>
>> --
>> OpenPGP:
>> https://sks-keyservers.net/pks/lookup?op=get&search=0xFEBAD7FFD041BBA1
>> If you wish to request my time, please do so using
>> http://bit.ly/hd1ScheduleRequest.
>> Si vous voudrais faire connnaisance, allez a
>> http://bit.ly/hd1ScheduleRequest.
>>
>> > >Sent
>> from my mobile device
>> Envoye de mon portable
>>
>
>

Re: [PROPOSAL] Apache Commons JUnit

[Gary Gregory]

[PROPOSAL REDUX]

Component Name: Apache Commons Testing

A multi-module project focused on providing code for testing applications
using various testing frameworks with an initial focus on JUnit 4.

Modules:

commons-testing: no dependencies, contains code like to list all non-daemon
threads after a test run (to see there is no resource leak) can be used
independent of the Unit Test Framework (as proposed by Oliver Heger.)

commons-testing-junit4: Depends on JUnit 4.12 only and provides code based
on JUnit 4 like JUnit "Rule"s.

SCM: Git.

Cut a 1.0-alpha1 from the above.

Gary


On Fri, Nov 3, 2017 at 5:11 PM, Gary Gregory  wrote:

> Hi All,
>
> I'd propose we start a new component called "Apache Commons JUnit".
>
> The goal would be to gather useful and reusable code like JUnit rules.
>
> This component would be focused on JUnit 4.x only.
>
> For example: org.apache.commons.collections4.junit.
> SetDefaultLocaleTestRule
>
> I have other rules stashed here and there as well, for example a Set
> Default Charset Rule.
>
> Thoughts?
>
> Gary
>
>

Re: [PROPOSAL] Apache Commons JUnit

[Romain Manni-Bucau]

This daemon thing is interesting, I something similar to dump each N
seconds threads to investigate some tests locking on a CI. Can goes
there as well probably.

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


2017-11-05 16:23 GMT+01:00 Gary Gregory :
> On Sat, Nov 4, 2017 at 11:12 AM, Gary Gregory 
> wrote:
>
>> So are you advocating for a multi-module project?
>>
>> - commons-testing
>> - commons-testing-junit4
>> - commons-testing-junit5
>>
>> ?
>>
>> Gary
>>
>>
>> On Sat, Nov 4, 2017 at 10:58 AM, Bernd Eckenfels 
>> wrote:
>>
>>> I like the idea (and prefer Commons Testing), for example a method to
>>> list all non-daemon threads after a test run (to see there is no resource
>>> leak) can be used independent of the Unit Test Framework.
>>>
>>
> Do you have such a gadget?
>
> Gary
>
>
>>
>>> Gruss
>>> Bernd
>>> --
>>> http://bernd.eckenfels.net
>>> 
>>> From: Hasan Diwan 
>>> Sent: Saturday, November 4, 2017 5:42:39 PM
>>> To: Commons Developers List
>>> Subject: Re: [PROPOSAL] Apache Commons JUnit
>>>
>>> How about "Apache Commons Testing"? -- H
>>>
>>> On 4 November 2017 at 09:10, Gary Gregory  wrote:
>>>
>>> > On Sat, Nov 4, 2017 at 9:32 AM, Pascal Schumacher <
>>> > pascalschumac...@gmx.net>
>>> > wrote:
>>> >
>>> > > JUnit 5 is not backwards compatible (Package/Annotation-Names have
>>> > > changed, Rules were replaced by a new extension model), but it can run
>>> > > JUnit 3 and JUnit 4 Tests if you add an additional dependency. See
>>> > > http://junit.org/junit5/docs/current/user-guide/#migrating-f
>>> rom-junit4
>>> > > for details.
>>> >
>>> >
>>> > OK, so "Apache Commons Extras for Junit 4"
>>> >
>>> > Gary
>>> >
>>> >
>>> > >
>>> > >
>>> > > Am 04.11.2017 um 15:53 schrieb Gary Gregory:
>>> > >
>>> > >> I am assuming that JUnit 5 will be backward compatible with JUnit 4,
>>> I
>>> > >> might be wrong. I'd like to focus on a single dependency for now
>>> (JUnit)
>>> > >> and not do a multi-module project. If someone want to do the same for
>>> > >> TestNG, then have at it. KISS and small for 1.0.
>>> > >>
>>> > >> Gary
>>> > >>
>>> > >> On Fri, Nov 3, 2017 at 10:41 PM, Bruno P. Kinoshita <
>>> > >> brunodepau...@yahoo.com.br.invalid> wrote:
>>> > >>
>>> > >> +1 for the idea and for looking at JUnit 5.x and maybe AssertJ.
>>> > >>> CheersBruno
>>> > >>>
>>> > >>>From: Matt Sicker 
>>> > >>>   To: Commons Developers List 
>>> > >>>   Sent: Saturday, 4 November 2017 1:44 PM
>>> > >>>   Subject: Re: [PROPOSAL] Apache Commons JUnit
>>> > >>>
>>> > >>> I certainly like the idea, especially if the docs are good about
>>> > pulling
>>> > >>> in
>>> > >>> other related dependencies to complement the whole thing. General
>>> > >>> resource
>>> > >>> management rules would be great, though, like the ones we have in
>>> > Log4j.
>>> > >>>
>>> > >>> Also, I haven't looked closely at it yet, but supporting JUnit 5.x
>>> as
>>> > >>> well
>>> > >>> would be nice.
>>> > >>>
>>> > >>> On 3 November 2017 at 18:11, Gary Gregory 
>>> > >>> wrote:
>>> > >>>
>>> > >>> Hi All,
>>> > 
>>> >  I'd propose we start a new component called "Apache Commons JUnit".
>>> > 
>>> >  The goal would be to gather useful and reusable code like JUnit
>>> rules.
>>> > 
>>> >  This component would be focused on JUnit 4.x only.
>>> > 
>>> >  For example: org.apache.commons.collections4.junit.
>>> >  SetDefaultLocaleTestRule
>>> > 
>>> >  I have other rules stashed here and there as well, for example a
>>> Set
>>> >  Default Charset Rule.
>>> > 
>>> >  Thoughts?
>>> > 
>>> >  Gary
>>> > 
>>> > 
>>> > >>>
>>> > >>> --
>>> > >>> Matt Sicker 
>>> > >>>
>>> > >>>
>>> > >>>
>>> > >>>
>>> > >>>
>>> > >
>>> > > -
>>> > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>>> > > For additional commands, e-mail: dev-h...@commons.apache.org
>>> > >
>>> > >
>>> >
>>>
>>>
>>>
>>> --
>>> OpenPGP:
>>> https://sks-keyservers.net/pks/lookup?op=get&search=0xFEBAD7FFD041BBA1
>>> If you wish to request my time, please do so using
>>> http://bit.ly/hd1ScheduleRequest.
>>> Si vous voudrais faire connnaisance, allez a
>>> http://bit.ly/hd1ScheduleRequest.
>>>
>>> >> >Sent
>>> from my mobile device
>>> Envoye de mon portable
>>>
>>
>>

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

Re: [PROPOSAL] Apache Commons JUnit

[Gary Gregory]

It sounds like we all like the idea of this new component. I'll create the
git repo tonight or by tomorrow morning at the latest.

Gary

On Sun, Nov 5, 2017 at 8:30 AM, Romain Manni-Bucau 
wrote:

> This daemon thing is interesting, I something similar to dump each N
> seconds threads to investigate some tests locking on a CI. Can goes
> there as well probably.
>
> Romain Manni-Bucau
> @rmannibucau |  Blog | Old Blog | Github | LinkedIn
>
>
> 2017-11-05 16:23 GMT+01:00 Gary Gregory :
> > On Sat, Nov 4, 2017 at 11:12 AM, Gary Gregory 
> > wrote:
> >
> >> So are you advocating for a multi-module project?
> >>
> >> - commons-testing
> >> - commons-testing-junit4
> >> - commons-testing-junit5
> >>
> >> ?
> >>
> >> Gary
> >>
> >>
> >> On Sat, Nov 4, 2017 at 10:58 AM, Bernd Eckenfels <
> e...@zusammenkunft.net>
> >> wrote:
> >>
> >>> I like the idea (and prefer Commons Testing), for example a method to
> >>> list all non-daemon threads after a test run (to see there is no
> resource
> >>> leak) can be used independent of the Unit Test Framework.
> >>>
> >>
> > Do you have such a gadget?
> >
> > Gary
> >
> >
> >>
> >>> Gruss
> >>> Bernd
> >>> --
> >>> http://bernd.eckenfels.net
> >>> 
> >>> From: Hasan Diwan 
> >>> Sent: Saturday, November 4, 2017 5:42:39 PM
> >>> To: Commons Developers List
> >>> Subject: Re: [PROPOSAL] Apache Commons JUnit
> >>>
> >>> How about "Apache Commons Testing"? -- H
> >>>
> >>> On 4 November 2017 at 09:10, Gary Gregory 
> wrote:
> >>>
> >>> > On Sat, Nov 4, 2017 at 9:32 AM, Pascal Schumacher <
> >>> > pascalschumac...@gmx.net>
> >>> > wrote:
> >>> >
> >>> > > JUnit 5 is not backwards compatible (Package/Annotation-Names have
> >>> > > changed, Rules were replaced by a new extension model), but it can
> run
> >>> > > JUnit 3 and JUnit 4 Tests if you add an additional dependency. See
> >>> > > http://junit.org/junit5/docs/current/user-guide/#migrating-f
> >>> rom-junit4
> >>> > > for details.
> >>> >
> >>> >
> >>> > OK, so "Apache Commons Extras for Junit 4"
> >>> >
> >>> > Gary
> >>> >
> >>> >
> >>> > >
> >>> > >
> >>> > > Am 04.11.2017 um 15:53 schrieb Gary Gregory:
> >>> > >
> >>> > >> I am assuming that JUnit 5 will be backward compatible with JUnit
> 4,
> >>> I
> >>> > >> might be wrong. I'd like to focus on a single dependency for now
> >>> (JUnit)
> >>> > >> and not do a multi-module project. If someone want to do the same
> for
> >>> > >> TestNG, then have at it. KISS and small for 1.0.
> >>> > >>
> >>> > >> Gary
> >>> > >>
> >>> > >> On Fri, Nov 3, 2017 at 10:41 PM, Bruno P. Kinoshita <
> >>> > >> brunodepau...@yahoo.com.br.invalid> wrote:
> >>> > >>
> >>> > >> +1 for the idea and for looking at JUnit 5.x and maybe AssertJ.
> >>> > >>> CheersBruno
> >>> > >>>
> >>> > >>>From: Matt Sicker 
> >>> > >>>   To: Commons Developers List 
> >>> > >>>   Sent: Saturday, 4 November 2017 1:44 PM
> >>> > >>>   Subject: Re: [PROPOSAL] Apache Commons JUnit
> >>> > >>>
> >>> > >>> I certainly like the idea, especially if the docs are good about
> >>> > pulling
> >>> > >>> in
> >>> > >>> other related dependencies to complement the whole thing. General
> >>> > >>> resource
> >>> > >>> management rules would be great, though, like the ones we have in
> >>> > Log4j.
> >>> > >>>
> >>> > >>> Also, I haven't looked closely at it yet, but supporting JUnit
> 5.x
> >>> as
> >>> > >>> well
> >>> > >>> would be nice.
> >>> > >>>
> >>> > >>> On 3 November 2017 at 18:11, Gary Gregory <
> garydgreg...@gmail.com>
> >>> > >>> wrote:
> >>> > >>>
> >>> > >>> Hi All,
> >>> > 
> >>> >  I'd propose we start a new component called "Apache Commons
> JUnit".
> >>> > 
> >>> >  The goal would be to gather useful and reusable code like JUnit
> >>> rules.
> >>> > 
> >>> >  This component would be focused on JUnit 4.x only.
> >>> > 
> >>> >  For example: org.apache.commons.collections4.junit.
> >>> >  SetDefaultLocaleTestRule
> >>> > 
> >>> >  I have other rules stashed here and there as well, for example a
> >>> Set
> >>> >  Default Charset Rule.
> >>> > 
> >>> >  Thoughts?
> >>> > 
> >>> >  Gary
> >>> > 
> >>> > 
> >>> > >>>
> >>> > >>> --
> >>> > >>> Matt Sicker 
> >>> > >>>
> >>> > >>>
> >>> > >>>
> >>> > >>>
> >>> > >>>
> >>> > >
> >>> > > 
> -
> >>> > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> >>> > > For additional commands, e-mail: dev-h...@commons.apache.org
> >>> > >
> >>> > >
> >>> >
> >>>
> >>>
> >>>
> >>> --
> >>> OpenPGP:
> >>> https://sks-keyservers.net/pks/lookup?op=get&search=0xFEBAD7FFD041BBA1
> >>> If you wish to request my time, please do so using
> >>> http://bit.ly/hd1ScheduleRequest.
> >>> Si vous voudrais faire connnaisance, allez a
> >>> http://bit.ly/hd1ScheduleRequest.
> >>>
> >>>  0xFEBAD7FFD041BBA1
> >>> >Sent
> >>> from my mobile device
> >>> 

Re: [jelly] Site build and Jellydoc plugin

[Oliver Heger]

Am 02.11.2017 um 00:33 schrieb Bruno P. Kinoshita:
> I think it may be worth to try to get in touch with Kohsuke. He became the 
> CTO of CloudBees some time ago, but is still involved in the project (not 
> writing as much code as before) mainly with decisions, and eventual pull 
> request review.
> You can find him sometimes on IRC / FreeNode, in the jenkins channel. But 
> given how busy he might be, probably dropping him an e-mail and waiting a bit 
> more might be a better idea.
> 
> Hope that helpsBruno

The PR is about 1.5 weeks old, so we should still give him some more time.

Do you know him in person, Bruno? Or did you have contact with him in
the past?

Thanks
Oliver

> 
>   From: Oliver Heger 
>  To: Commons Developers List  
>  Sent: Thursday, 2 November 2017 9:34 AM
>  Subject: [jelly] Site build and Jellydoc plugin
>
> Hi,
> 
> recently I did some work to get the Jelly site build with Maven running.
> As this is experimental, I created my own fork of the project for this
> purpose [1].
> 
> An important part of the documentation is the Jellydoc, an automatically
> generated documentation for the standard tag libs shipped with Jelly.
> This documentation is generated by the maven-jellydoc-plugin [2].
> Unfortunately, the plugin has a few bugs which cause the site build to fail.
> 
> I therefore created a pull request [3] that fixes these problems. With
> the patched version the build is now successful.
> 
> However, there has not yet been a reaction on this PR. Given the fact
> that the plugin code had not been touched for more than 6 years, it may
> well be possible that Kohsuke Kawaguchi, the author of the plugin, is no
> longer interested in this code base.
> 
> Any thoughts how we could proceed here?
> 
> Oliver
> 
> [1] https://github.com/oheger/commons-jelly/tree/siteBuild
> [2] https://github.com/kohsuke/maven-jellydoc-plugin
> [3] https://github.com/kohsuke/maven-jellydoc-plugin/pull/1
> 
> -
> 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

AW: [PROPOSAL][test] Apache Commons JUnit

[Bernd Eckenfels]

Hello,


commons-vfs does this (at the Moment it only dumps the threads and does not 
break the build)

https://github.com/apache/commons-vfs/blob/trunk/commons-vfs2/src/test/java/org/apache/commons/vfs2/test/AbstractTestSuite.java#L213


Gruss
Bernd
-- 
http://bernd.eckenfels.net

Von: Romain Manni-Bucau
Gesendet: Sonntag, 5. November 2017 16:31
An: Commons Developers List
Betreff: Re: [PROPOSAL] Apache Commons JUnit

This daemon thing is interesting, I something similar to dump each N
seconds threads to investigate some tests locking on a CI. Can goes
there as well probably.

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


2017-11-05 16:23 GMT+01:00 Gary Gregory :
> On Sat, Nov 4, 2017 at 11:12 AM, Gary Gregory 
> wrote:
>
>> So are you advocating for a multi-module project?
>>
>> - commons-testing
>> - commons-testing-junit4
>> - commons-testing-junit5
>>
>> ?
>>
>> Gary
>>
>>
>> On Sat, Nov 4, 2017 at 10:58 AM, Bernd Eckenfels 
>> wrote:
>>
>>> I like the idea (and prefer Commons Testing), for example a method to
>>> list all non-daemon threads after a test run (to see there is no resource
>>> leak) can be used independent of the Unit Test Framework.
>>>
>>
> Do you have such a gadget?
>
> Gary
>
>
>>
>>> Gruss
>>> Bernd
>>> --
>>> http://bernd.eckenfels.net
>>> 
>>> From: Hasan Diwan 
>>> Sent: Saturday, November 4, 2017 5:42:39 PM
>>> To: Commons Developers List
>>> Subject: Re: [PROPOSAL] Apache Commons JUnit
>>>
>>> How about "Apache Commons Testing"? -- H
>>>
>>> On 4 November 2017 at 09:10, Gary Gregory  wrote:
>>>
>>> > On Sat, Nov 4, 2017 at 9:32 AM, Pascal Schumacher <
>>> > pascalschumac...@gmx.net>
>>> > wrote:
>>> >
>>> > > JUnit 5 is not backwards compatible (Package/Annotation-Names have
>>> > > changed, Rules were replaced by a new extension model), but it can run
>>> > > JUnit 3 and JUnit 4 Tests if you add an additional dependency. See
>>> > > http://junit.org/junit5/docs/current/user-guide/#migrating-f
>>> rom-junit4
>>> > > for details.
>>> >
>>> >
>>> > OK, so "Apache Commons Extras for Junit 4"
>>> >
>>> > Gary
>>> >
>>> >
>>> > >
>>> > >
>>> > > Am 04.11.2017 um 15:53 schrieb Gary Gregory:
>>> > >
>>> > >> I am assuming that JUnit 5 will be backward compatible with JUnit 4,
>>> I
>>> > >> might be wrong. I'd like to focus on a single dependency for now
>>> (JUnit)
>>> > >> and not do a multi-module project. If someone want to do the same for
>>> > >> TestNG, then have at it. KISS and small for 1.0.
>>> > >>
>>> > >> Gary
>>> > >>
>>> > >> On Fri, Nov 3, 2017 at 10:41 PM, Bruno P. Kinoshita <
>>> > >> brunodepau...@yahoo.com.br.invalid> wrote:
>>> > >>
>>> > >> +1 for the idea and for looking at JUnit 5.x and maybe AssertJ.
>>> > >>> CheersBruno
>>> > >>>
>>> > >>>From: Matt Sicker 
>>> > >>>   To: Commons Developers List 
>>> > >>>   Sent: Saturday, 4 November 2017 1:44 PM
>>> > >>>   Subject: Re: [PROPOSAL] Apache Commons JUnit
>>> > >>>
>>> > >>> I certainly like the idea, especially if the docs are good about
>>> > pulling
>>> > >>> in
>>> > >>> other related dependencies to complement the whole thing. General
>>> > >>> resource
>>> > >>> management rules would be great, though, like the ones we have in
>>> > Log4j.
>>> > >>>
>>> > >>> Also, I haven't looked closely at it yet, but supporting JUnit 5.x
>>> as
>>> > >>> well
>>> > >>> would be nice.
>>> > >>>
>>> > >>> On 3 November 2017 at 18:11, Gary Gregory 
>>> > >>> wrote:
>>> > >>>
>>> > >>> Hi All,
>>> > 
>>> >  I'd propose we start a new component called "Apache Commons JUnit".
>>> > 
>>> >  The goal would be to gather useful and reusable code like JUnit
>>> rules.
>>> > 
>>> >  This component would be focused on JUnit 4.x only.
>>> > 
>>> >  For example: org.apache.commons.collections4.junit.
>>> >  SetDefaultLocaleTestRule
>>> > 
>>> >  I have other rules stashed here and there as well, for example a
>>> Set
>>> >  Default Charset Rule.
>>> > 
>>> >  Thoughts?
>>> > 
>>> >  Gary
>>> > 
>>> > 
>>> > >>>
>>> > >>> --
>>> > >>> Matt Sicker 
>>> > >>>
>>> > >>>
>>> > >>>
>>> > >>>
>>> > >>>
>>> > >
>>> > > -
>>> > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>>> > > For additional commands, e-mail: dev-h...@commons.apache.org
>>> > >
>>> > >
>>> >
>>>
>>>
>>>
>>> --
>>> OpenPGP:
>>> https://sks-keyservers.net/pks/lookup?op=get&search=0xFEBAD7FFD041BBA1
>>> If you wish to request my time, please do so using
>>> http://bit.ly/hd1ScheduleRequest.
>>> Si vous voudrais faire connnaisance, allez a
>>> http://bit.ly/hd1ScheduleRequest.
>>>
>>> >> >Sent
>>> from my mobile device
>>> Envoye de mon portable
>>>
>>
>>

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org

Re: AW: [PROPOSAL][test] Apache Commons JUnit

[Romain Manni-Bucau]

This is a bit different since my case was to get annoutput of where a test
can lock and not a diff. But technically it is close.

Le 5 nov. 2017 20:21, "Bernd Eckenfels"  a écrit :

> Hello,
>
>
> commons-vfs does this (at the Moment it only dumps the threads and does
> not break the build)
>
> https://github.com/apache/commons-vfs/blob/trunk/
> commons-vfs2/src/test/java/org/apache/commons/vfs2/test/
> AbstractTestSuite.java#L213
>
>
> Gruss
> Bernd
> --
> http://bernd.eckenfels.net
>
> Von: Romain Manni-Bucau
> Gesendet: Sonntag, 5. November 2017 16:31
> An: Commons Developers List
> Betreff: Re: [PROPOSAL] Apache Commons JUnit
>
> This daemon thing is interesting, I something similar to dump each N
> seconds threads to investigate some tests locking on a CI. Can goes
> there as well probably.
>
> Romain Manni-Bucau
> @rmannibucau |  Blog | Old Blog | Github | LinkedIn
>
>
> 2017-11-05 16:23 GMT+01:00 Gary Gregory :
> > On Sat, Nov 4, 2017 at 11:12 AM, Gary Gregory 
> > wrote:
> >
> >> So are you advocating for a multi-module project?
> >>
> >> - commons-testing
> >> - commons-testing-junit4
> >> - commons-testing-junit5
> >>
> >> ?
> >>
> >> Gary
> >>
> >>
> >> On Sat, Nov 4, 2017 at 10:58 AM, Bernd Eckenfels <
> e...@zusammenkunft.net>
> >> wrote:
> >>
> >>> I like the idea (and prefer Commons Testing), for example a method to
> >>> list all non-daemon threads after a test run (to see there is no
> resource
> >>> leak) can be used independent of the Unit Test Framework.
> >>>
> >>
> > Do you have such a gadget?
> >
> > Gary
> >
> >
> >>
> >>> Gruss
> >>> Bernd
> >>> --
> >>> http://bernd.eckenfels.net
> >>> 
> >>> From: Hasan Diwan 
> >>> Sent: Saturday, November 4, 2017 5:42:39 PM
> >>> To: Commons Developers List
> >>> Subject: Re: [PROPOSAL] Apache Commons JUnit
> >>>
> >>> How about "Apache Commons Testing"? -- H
> >>>
> >>> On 4 November 2017 at 09:10, Gary Gregory 
> wrote:
> >>>
> >>> > On Sat, Nov 4, 2017 at 9:32 AM, Pascal Schumacher <
> >>> > pascalschumac...@gmx.net>
> >>> > wrote:
> >>> >
> >>> > > JUnit 5 is not backwards compatible (Package/Annotation-Names have
> >>> > > changed, Rules were replaced by a new extension model), but it can
> run
> >>> > > JUnit 3 and JUnit 4 Tests if you add an additional dependency. See
> >>> > > http://junit.org/junit5/docs/current/user-guide/#migrating-f
> >>> rom-junit4
> >>> > > for details.
> >>> >
> >>> >
> >>> > OK, so "Apache Commons Extras for Junit 4"
> >>> >
> >>> > Gary
> >>> >
> >>> >
> >>> > >
> >>> > >
> >>> > > Am 04.11.2017 um 15:53 schrieb Gary Gregory:
> >>> > >
> >>> > >> I am assuming that JUnit 5 will be backward compatible with JUnit
> 4,
> >>> I
> >>> > >> might be wrong. I'd like to focus on a single dependency for now
> >>> (JUnit)
> >>> > >> and not do a multi-module project. If someone want to do the same
> for
> >>> > >> TestNG, then have at it. KISS and small for 1.0.
> >>> > >>
> >>> > >> Gary
> >>> > >>
> >>> > >> On Fri, Nov 3, 2017 at 10:41 PM, Bruno P. Kinoshita <
> >>> > >> brunodepau...@yahoo.com.br.invalid> wrote:
> >>> > >>
> >>> > >> +1 for the idea and for looking at JUnit 5.x and maybe AssertJ.
> >>> > >>> CheersBruno
> >>> > >>>
> >>> > >>>From: Matt Sicker 
> >>> > >>>   To: Commons Developers List 
> >>> > >>>   Sent: Saturday, 4 November 2017 1:44 PM
> >>> > >>>   Subject: Re: [PROPOSAL] Apache Commons JUnit
> >>> > >>>
> >>> > >>> I certainly like the idea, especially if the docs are good about
> >>> > pulling
> >>> > >>> in
> >>> > >>> other related dependencies to complement the whole thing. General
> >>> > >>> resource
> >>> > >>> management rules would be great, though, like the ones we have in
> >>> > Log4j.
> >>> > >>>
> >>> > >>> Also, I haven't looked closely at it yet, but supporting JUnit
> 5.x
> >>> as
> >>> > >>> well
> >>> > >>> would be nice.
> >>> > >>>
> >>> > >>> On 3 November 2017 at 18:11, Gary Gregory <
> garydgreg...@gmail.com>
> >>> > >>> wrote:
> >>> > >>>
> >>> > >>> Hi All,
> >>> > 
> >>> >  I'd propose we start a new component called "Apache Commons
> JUnit".
> >>> > 
> >>> >  The goal would be to gather useful and reusable code like JUnit
> >>> rules.
> >>> > 
> >>> >  This component would be focused on JUnit 4.x only.
> >>> > 
> >>> >  For example: org.apache.commons.collections4.junit.
> >>> >  SetDefaultLocaleTestRule
> >>> > 
> >>> >  I have other rules stashed here and there as well, for example a
> >>> Set
> >>> >  Default Charset Rule.
> >>> > 
> >>> >  Thoughts?
> >>> > 
> >>> >  Gary
> >>> > 
> >>> > 
> >>> > >>>
> >>> > >>> --
> >>> > >>> Matt Sicker 
> >>> > >>>
> >>> > >>>
> >>> > >>>
> >>> > >>>
> >>> > >>>
> >>> > >
> >>> > > 
> -
> >>> > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> >>> > > For additional commands, e-mail: dev-h...@commons.apache.org
> >>> > >
> >>> > >
> >>>

Re: AW: [PROPOSAL][test] Apache Commons JUnit

[Mark Fortner]

Just out of curiosity, wouldn't it be easier (and more intuitive) for users
of JUnit to find a collection of JUnit-related tools on the JUnit project
site?

Regards,

Mark

On 5 Nov 2017 11:51 a.m., "Romain Manni-Bucau" 
wrote:

> This is a bit different since my case was to get annoutput of where a test
> can lock and not a diff. But technically it is close.
>
> Le 5 nov. 2017 20:21, "Bernd Eckenfels"  a écrit :
>
> > Hello,
> >
> >
> > commons-vfs does this (at the Moment it only dumps the threads and does
> > not break the build)
> >
> > https://github.com/apache/commons-vfs/blob/trunk/
> > commons-vfs2/src/test/java/org/apache/commons/vfs2/test/
> > AbstractTestSuite.java#L213
> >
> >
> > Gruss
> > Bernd
> > --
> > http://bernd.eckenfels.net
> >
> > Von: Romain Manni-Bucau
> > Gesendet: Sonntag, 5. November 2017 16:31
> > An: Commons Developers List
> > Betreff: Re: [PROPOSAL] Apache Commons JUnit
> >
> > This daemon thing is interesting, I something similar to dump each N
> > seconds threads to investigate some tests locking on a CI. Can goes
> > there as well probably.
> >
> > Romain Manni-Bucau
> > @rmannibucau |  Blog | Old Blog | Github | LinkedIn
> >
> >
> > 2017-11-05 16:23 GMT+01:00 Gary Gregory :
> > > On Sat, Nov 4, 2017 at 11:12 AM, Gary Gregory 
> > > wrote:
> > >
> > >> So are you advocating for a multi-module project?
> > >>
> > >> - commons-testing
> > >> - commons-testing-junit4
> > >> - commons-testing-junit5
> > >>
> > >> ?
> > >>
> > >> Gary
> > >>
> > >>
> > >> On Sat, Nov 4, 2017 at 10:58 AM, Bernd Eckenfels <
> > e...@zusammenkunft.net>
> > >> wrote:
> > >>
> > >>> I like the idea (and prefer Commons Testing), for example a method to
> > >>> list all non-daemon threads after a test run (to see there is no
> > resource
> > >>> leak) can be used independent of the Unit Test Framework.
> > >>>
> > >>
> > > Do you have such a gadget?
> > >
> > > Gary
> > >
> > >
> > >>
> > >>> Gruss
> > >>> Bernd
> > >>> --
> > >>> http://bernd.eckenfels.net
> > >>> 
> > >>> From: Hasan Diwan 
> > >>> Sent: Saturday, November 4, 2017 5:42:39 PM
> > >>> To: Commons Developers List
> > >>> Subject: Re: [PROPOSAL] Apache Commons JUnit
> > >>>
> > >>> How about "Apache Commons Testing"? -- H
> > >>>
> > >>> On 4 November 2017 at 09:10, Gary Gregory 
> > wrote:
> > >>>
> > >>> > On Sat, Nov 4, 2017 at 9:32 AM, Pascal Schumacher <
> > >>> > pascalschumac...@gmx.net>
> > >>> > wrote:
> > >>> >
> > >>> > > JUnit 5 is not backwards compatible (Package/Annotation-Names
> have
> > >>> > > changed, Rules were replaced by a new extension model), but it
> can
> > run
> > >>> > > JUnit 3 and JUnit 4 Tests if you add an additional dependency.
> See
> > >>> > > http://junit.org/junit5/docs/current/user-guide/#migrating-f
> > >>> rom-junit4
> > >>> > > for details.
> > >>> >
> > >>> >
> > >>> > OK, so "Apache Commons Extras for Junit 4"
> > >>> >
> > >>> > Gary
> > >>> >
> > >>> >
> > >>> > >
> > >>> > >
> > >>> > > Am 04.11.2017 um 15:53 schrieb Gary Gregory:
> > >>> > >
> > >>> > >> I am assuming that JUnit 5 will be backward compatible with
> JUnit
> > 4,
> > >>> I
> > >>> > >> might be wrong. I'd like to focus on a single dependency for now
> > >>> (JUnit)
> > >>> > >> and not do a multi-module project. If someone want to do the
> same
> > for
> > >>> > >> TestNG, then have at it. KISS and small for 1.0.
> > >>> > >>
> > >>> > >> Gary
> > >>> > >>
> > >>> > >> On Fri, Nov 3, 2017 at 10:41 PM, Bruno P. Kinoshita <
> > >>> > >> brunodepau...@yahoo.com.br.invalid> wrote:
> > >>> > >>
> > >>> > >> +1 for the idea and for looking at JUnit 5.x and maybe AssertJ.
> > >>> > >>> CheersBruno
> > >>> > >>>
> > >>> > >>>From: Matt Sicker 
> > >>> > >>>   To: Commons Developers List 
> > >>> > >>>   Sent: Saturday, 4 November 2017 1:44 PM
> > >>> > >>>   Subject: Re: [PROPOSAL] Apache Commons JUnit
> > >>> > >>>
> > >>> > >>> I certainly like the idea, especially if the docs are good
> about
> > >>> > pulling
> > >>> > >>> in
> > >>> > >>> other related dependencies to complement the whole thing.
> General
> > >>> > >>> resource
> > >>> > >>> management rules would be great, though, like the ones we have
> in
> > >>> > Log4j.
> > >>> > >>>
> > >>> > >>> Also, I haven't looked closely at it yet, but supporting JUnit
> > 5.x
> > >>> as
> > >>> > >>> well
> > >>> > >>> would be nice.
> > >>> > >>>
> > >>> > >>> On 3 November 2017 at 18:11, Gary Gregory <
> > garydgreg...@gmail.com>
> > >>> > >>> wrote:
> > >>> > >>>
> > >>> > >>> Hi All,
> > >>> > 
> > >>> >  I'd propose we start a new component called "Apache Commons
> > JUnit".
> > >>> > 
> > >>> >  The goal would be to gather useful and reusable code like
> JUnit
> > >>> rules.
> > >>> > 
> > >>> >  This component would be focused on JUnit 4.x only.
> > >>> > 
> > >>> >  For example: org.apache.commons.collections4.junit.
> > >>> >  SetDefaultLocaleTestRule
> > >>> > 
> > >>> >  I have other rul

Re: [VOTE] Release Apache Commons Lang 3.7 based on RC1

[Oliver Heger]

Build works fine with Java 1.7 and 1.8 on Windows 10. Artifacts and site
look good.

+1

Oliver

Am 04.11.2017 um 19:50 schrieb Gary Gregory:
> We have fixed a few bugs since Apache Commons Lang 3.6 was released, so I
> would like to release Apache Commons Lang 3.7.
> 
> Apache Commons Lang 3.7 RC1 is available for review here:
> https://dist.apache.org/repos/dist/dev/commons/lang at revision: 22853
> Get it like this: svn co
> https://dist.apache.org/repos/dist/dev/commons/lang
> 
> The tag is here:
> 
> https://git-wip-us.apache.org/repos/asf?p=commons-lang.git;a=tag;h=refs/tags/LANG_3_7_RC1
> object 425d8085cfcaab5a78bf0632f9ae77b7e9127cf8
> 
> Maven artifacts are here:
> https://repository.apache.org/content/repositories/orgapachecommons-1288
> 
> These are the artifacts and their SHA1 hashes:
> 
> /org/apache/commons/commons-lang3/3.7/commons-lang3-3.7-test-sources.jar.asc
> (SHA1: b9d6588eba0ee1cef9edf51283bf2004fcb71238)
> /org/apache/commons/commons-lang3/3.7/commons-lang3-3.7-tests.jar.asc
> (SHA1: e300353ba37288f4308534c38488792a57e52e3b)
> /org/apache/commons/commons-lang3/3.7/commons-lang3-3.7-src.zip
> (SHA1: 6316036a39e10dc61f7996672af13be0cddd03d5)
> /org/apache/commons/commons-lang3/3.7/commons-lang3-3.7-sources.jar
> (SHA1: e7e36219edde1c66c93495a75490d8f526c377cb)
> /org/apache/commons/commons-lang3/3.7/commons-lang3-3.7-javadoc.jar.asc
> (SHA1: deba56c5874a5c023ad209f0d7b9f7690830a6fd)
> /org/apache/commons/commons-lang3/3.7/commons-lang3-3.7-src.zip.asc
> (SHA1: 31f67cddf7f5bb5a933dcd2667da8af3a86c40ef)
> /org/apache/commons/commons-lang3/3.7/commons-lang3-3.7-bin.zip.asc
> (SHA1: dcee70c101432b6a61ec03f3282cf3512c61645d)
> /org/apache/commons/commons-lang3/3.7/commons-lang3-3.7-tests.jar
> (SHA1: e2b2ef23bf522cbfa9c49a905fb278ba1fd4eadb)
> /org/apache/commons/commons-lang3/3.7/commons-lang3-3.7-bin.tar.gz.asc
> (SHA1: ee9f3adcbe2b7bb93f1300ec843c9d3f25d215db)
> /org/apache/commons/commons-lang3/3.7/commons-lang3-3.7-test-sources.jar
> (SHA1: f51e03bffa2fd21efa309e562213803b38d3b5b2)
> /org/apache/commons/commons-lang3/3.7/commons-lang3-3.7-src.tar.gz.asc
> (SHA1: 7019c1310c9dcba3375ef03ea509b9caa2de8f6c)
> /org/apache/commons/commons-lang3/3.7/commons-lang3-3.7-sources.jar.asc
> (SHA1: 2bb88579e6ced65c30a9f5615f4a83584edba0ce)
> /org/apache/commons/commons-lang3/3.7/commons-lang3-3.7-bin.tar.gz
> (SHA1: b7ff9054614d9a3c58798fe93cab468b241b8496)
> /org/apache/commons/commons-lang3/3.7/commons-lang3-3.7.pom
> (SHA1: c445be3b6442b41cbea539d4218be3aea9428a55)
> /org/apache/commons/commons-lang3/3.7/commons-lang3-3.7.jar
> (SHA1: 557edd918fd41f9260963583ebf5a61a43a6b423)
> /org/apache/commons/commons-lang3/3.7/commons-lang3-3.7-src.tar.gz
> (SHA1: 1027d100c5099634a244a9c517e304518507c466)
> /org/apache/commons/commons-lang3/3.7/commons-lang3-3.7-javadoc.jar
> (SHA1: 08d6fb4d39bedef08da171550c73b5d84e8c1125)
> /org/apache/commons/commons-lang3/3.7/commons-lang3-3.7.pom.asc
> (SHA1: 43481d694125cced7ebba307634d716c96229c69)
> /org/apache/commons/commons-lang3/3.7/commons-lang3-3.7-bin.zip
> (SHA1: 18f12e2e26b820ec1680889c3afa0c6a9f65b68a)
> /org/apache/commons/commons-lang3/3.7/commons-lang3-3.7.jar.asc
> (SHA1: cdcce5ca9a5df3ee087148c815266ba8567ea7aa)
> 
> I tested this RC using 'mvn clean verify' on Microsoft Windows [Version
> 10.0.16299.19] with:
> 
> - Oracle Java 7
> - Oracle Java 8
> - Oracle Java 9
> - Oracle Java 10 EA b29
> - IBM Java 8
> 
> Apache Maven 3.5.2 (138edd61fd100ec658bfa2d307c43b76940a5d7d;
> 2017-10-18T01:58:13-06:00)
> Maven home: C:\Java\apache-maven-3.5.2\bin\..
> Java version: 1.7.0_80, vendor: Oracle Corporation
> Java home: C:\Program Files\Java\jdk1.7.0_80\jre
> Default locale: en_US, platform encoding: Cp1252
> OS name: "windows 8.1", version: "6.3", arch: "amd64", family: "windows"
> 
> Apache Maven 3.5.2 (138edd61fd100ec658bfa2d307c43b76940a5d7d;
> 2017-10-18T01:58:13-06:00)
> Maven home: C:\Java\apache-maven-3.5.2\bin\..
> Java version: 1.8.0_152, vendor: Oracle Corporation
> Java home: C:\Program Files\Java\jdk1.8.0_152\jre
> Default locale: en_US, platform encoding: Cp1252
> OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"
> 
> Apache Maven 3.5.2 (138edd61fd100ec658bfa2d307c43b76940a5d7d;
> 2017-10-18T01:58:13-06:00)
> Maven home: C:\Java\apache-maven-3.5.2\bin\..
> Java version: 9.0.1, vendor: Oracle Corporation
> Java home: C:\Program Files\Java\jdk-9.0.1
> Default locale: en_US, platform encoding: Cp1252
> OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"
> 
> Apache Maven 3.5.2 (138edd61fd100ec658bfa2d307c43b76940a5d7d;
> 2017-10-18T01:58:13-06:00)
> Maven home: C:\Java\apache-maven-3.5.2\bin\..
> Java version: 10-ea, vendor: Oracle Corporation
> Java home: C:\Program Files\Java\jdk-10
> Default locale: en_US, platform encoding: Cp1252
> OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"
> 
> Apache Maven 3.5.2 (138edd61fd100ec658bfa2d307c43b76940a5d7d;
> 2017-10-18T01

Re: AW: [PROPOSAL][test] Apache Commons JUnit

[Romain Manni-Bucau]

@Mark: this is already not the case and users are used to gather them
putside Junit. Also it is pby as true as saying it would be easier to push
commons in openjdk directly no?

I see a lot of values to have a uniform backbone - rule API - and making it
easy to reuse accross test stacks so commons testing really makes sense for
me on the long term even if v1 target junit 4 only.

Le 5 nov. 2017 21:21, "Mark Fortner"  a écrit :

Just out of curiosity, wouldn't it be easier (and more intuitive) for users
of JUnit to find a collection of JUnit-related tools on the JUnit project
site?

Regards,

Mark

On 5 Nov 2017 11:51 a.m., "Romain Manni-Bucau" 
wrote:

> This is a bit different since my case was to get annoutput of where a test
> can lock and not a diff. But technically it is close.
>
> Le 5 nov. 2017 20:21, "Bernd Eckenfels"  a écrit :
>
> > Hello,
> >
> >
> > commons-vfs does this (at the Moment it only dumps the threads and does
> > not break the build)
> >
> > https://github.com/apache/commons-vfs/blob/trunk/
> > commons-vfs2/src/test/java/org/apache/commons/vfs2/test/
> > AbstractTestSuite.java#L213
> >
> >
> > Gruss
> > Bernd
> > --
> > http://bernd.eckenfels.net
> >
> > Von: Romain Manni-Bucau
> > Gesendet: Sonntag, 5. November 2017 16:31
> > An: Commons Developers List
> > Betreff: Re: [PROPOSAL] Apache Commons JUnit
> >
> > This daemon thing is interesting, I something similar to dump each N
> > seconds threads to investigate some tests locking on a CI. Can goes
> > there as well probably.
> >
> > Romain Manni-Bucau
> > @rmannibucau |  Blog | Old Blog | Github | LinkedIn
> >
> >
> > 2017-11-05 16:23 GMT+01:00 Gary Gregory :
> > > On Sat, Nov 4, 2017 at 11:12 AM, Gary Gregory 
> > > wrote:
> > >
> > >> So are you advocating for a multi-module project?
> > >>
> > >> - commons-testing
> > >> - commons-testing-junit4
> > >> - commons-testing-junit5
> > >>
> > >> ?
> > >>
> > >> Gary
> > >>
> > >>
> > >> On Sat, Nov 4, 2017 at 10:58 AM, Bernd Eckenfels <
> > e...@zusammenkunft.net>
> > >> wrote:
> > >>
> > >>> I like the idea (and prefer Commons Testing), for example a method
to
> > >>> list all non-daemon threads after a test run (to see there is no
> > resource
> > >>> leak) can be used independent of the Unit Test Framework.
> > >>>
> > >>
> > > Do you have such a gadget?
> > >
> > > Gary
> > >
> > >
> > >>
> > >>> Gruss
> > >>> Bernd
> > >>> --
> > >>> http://bernd.eckenfels.net
> > >>> 
> > >>> From: Hasan Diwan 
> > >>> Sent: Saturday, November 4, 2017 5:42:39 PM
> > >>> To: Commons Developers List
> > >>> Subject: Re: [PROPOSAL] Apache Commons JUnit
> > >>>
> > >>> How about "Apache Commons Testing"? -- H
> > >>>
> > >>> On 4 November 2017 at 09:10, Gary Gregory 
> > wrote:
> > >>>
> > >>> > On Sat, Nov 4, 2017 at 9:32 AM, Pascal Schumacher <
> > >>> > pascalschumac...@gmx.net>
> > >>> > wrote:
> > >>> >
> > >>> > > JUnit 5 is not backwards compatible (Package/Annotation-Names
> have
> > >>> > > changed, Rules were replaced by a new extension model), but it
> can
> > run
> > >>> > > JUnit 3 and JUnit 4 Tests if you add an additional dependency.
> See
> > >>> > > http://junit.org/junit5/docs/current/user-guide/#migrating-f
> > >>> rom-junit4
> > >>> > > for details.
> > >>> >
> > >>> >
> > >>> > OK, so "Apache Commons Extras for Junit 4"
> > >>> >
> > >>> > Gary
> > >>> >
> > >>> >
> > >>> > >
> > >>> > >
> > >>> > > Am 04.11.2017 um 15:53 schrieb Gary Gregory:
> > >>> > >
> > >>> > >> I am assuming that JUnit 5 will be backward compatible with
> JUnit
> > 4,
> > >>> I
> > >>> > >> might be wrong. I'd like to focus on a single dependency for
now
> > >>> (JUnit)
> > >>> > >> and not do a multi-module project. If someone want to do the
> same
> > for
> > >>> > >> TestNG, then have at it. KISS and small for 1.0.
> > >>> > >>
> > >>> > >> Gary
> > >>> > >>
> > >>> > >> On Fri, Nov 3, 2017 at 10:41 PM, Bruno P. Kinoshita <
> > >>> > >> brunodepau...@yahoo.com.br.invalid> wrote:
> > >>> > >>
> > >>> > >> +1 for the idea and for looking at JUnit 5.x and maybe AssertJ.
> > >>> > >>> CheersBruno
> > >>> > >>>
> > >>> > >>>From: Matt Sicker 
> > >>> > >>>   To: Commons Developers List 
> > >>> > >>>   Sent: Saturday, 4 November 2017 1:44 PM
> > >>> > >>>   Subject: Re: [PROPOSAL] Apache Commons JUnit
> > >>> > >>>
> > >>> > >>> I certainly like the idea, especially if the docs are good
> about
> > >>> > pulling
> > >>> > >>> in
> > >>> > >>> other related dependencies to complement the whole thing.
> General
> > >>> > >>> resource
> > >>> > >>> management rules would be great, though, like the ones we have
> in
> > >>> > Log4j.
> > >>> > >>>
> > >>> > >>> Also, I haven't looked closely at it yet, but supporting JUnit
> > 5.x
> > >>> as
> > >>> > >>> well
> > >>> > >>> would be nice.
> > >>> > >>>
> > >>> > >>> On 3 November 2017 at 18:11, Gary Gregory <
> > garydgreg...@gmail.com>
> > >>> > >>> wrote:
> > >>> > >>>
> > >>> > >>> Hi All,
> > >>> > 
> > >>> >  

Re: [jelly] Site build and Jellydoc plugin

[Bruno P. Kinoshita]

>The PR is about 1.5 weeks old, so we should still give him some more time.

+1

>Do you know him in person, Bruno? Or did you have contact with him in the past?

He helped me to organize the Brazilian Jenkins mailing list, and the two first 
conferences in Brazil. He flew there to help organize and give keynote 
presentations too.


One of the most intelligent and humble programmers I had a chance to chat in 
person.
Bruno





From: Oliver Heger 
To: dev@commons.apache.org 
Sent: Monday, 6 November 2017 4:55 AM
Subject: Re: [jelly] Site build and Jellydoc plugin





Am 02.11.2017 um 00:33 schrieb Bruno P. Kinoshita:
> I think it may be worth to try to get in touch with Kohsuke. He became the 
> CTO of CloudBees some time ago, but is still involved in the project (not 
> writing as much code as before) mainly with decisions, and eventual pull 
> request review.
> You can find him sometimes on IRC / FreeNode, in the jenkins channel. But 
> given how busy he might be, probably dropping him an e-mail and waiting a bit 
> more might be a better idea.
> 
> Hope that helpsBruno

The PR is about 1.5 weeks old, so we should still give him some more time.

Do you know him in person, Bruno? Or did you have contact with him in
the past?

Thanks
Oliver

> 
>   From: Oliver Heger 
>  To: Commons Developers List  
>  Sent: Thursday, 2 November 2017 9:34 AM
>  Subject: [jelly] Site build and Jellydoc plugin
>
> Hi,
> 
> recently I did some work to get the Jelly site build with Maven running.
> As this is experimental, I created my own fork of the project for this
> purpose [1].
> 
> An important part of the documentation is the Jellydoc, an automatically
> generated documentation for the standard tag libs shipped with Jelly.
> This documentation is generated by the maven-jellydoc-plugin [2].
> Unfortunately, the plugin has a few bugs which cause the site build to fail.
> 
> I therefore created a pull request [3] that fixes these problems. With
> the patched version the build is now successful.
> 
> However, there has not yet been a reaction on this PR. Given the fact
> that the plugin code had not been touched for more than 6 years, it may
> well be possible that Kohsuke Kawaguchi, the author of the plugin, is no
> longer interested in this code base.
> 
> Any thoughts how we could proceed here?
> 
> Oliver
> 
> [1] https://github.com/oheger/commons-jelly/tree/siteBuild
> [2] https://github.com/kohsuke/maven-jellydoc-plugin
> [3] https://github.com/kohsuke/maven-jellydoc-plugin/pull/1
> 
> -
> 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: [PROPOSAL] Apache Commons JUnit

[Claude Warren]

I don't know if this fits but I have junit-contract-testing (
https://github.com/Claudenw/junit-contracts) that I would like to
contribute.

It is an extension that performs contract tests for java interface
implementations.

Cluade

On Fri, Nov 3, 2017 at 11:11 PM, Gary Gregory 
wrote:

> Hi All,
>
> I'd propose we start a new component called "Apache Commons JUnit".
>
> The goal would be to gather useful and reusable code like JUnit rules.
>
> This component would be focused on JUnit 4.x only.
>
> For example: org.apache.commons.collections4.junit.
> SetDefaultLocaleTestRule
>
> I have other rules stashed here and there as well, for example a Set
> Default Charset Rule.
>
> Thoughts?
>
> Gary
>



-- 
I like: Like Like - The likeliest place on the web

LinkedIn: http://www.linkedin.com/in/claudewarren

Re: [PROPOSAL] Apache Commons JUnit

[Martin van den Bemt]

I still have some code lying around in this area. Need refreshing though :

http://mvdb.org/projects/beanunit/
It tests getters and setters automagically.
Maybe because of the magic code involved the code is not very "clean"
and maybe not suitable for a commons test component.

Mvgr,
Martin


On Sat, Nov 4, 2017 at 12:11 AM, Gary Gregory  wrote:
> Hi All,
>
> I'd propose we start a new component called "Apache Commons JUnit".
>
> The goal would be to gather useful and reusable code like JUnit rules.
>
> This component would be focused on JUnit 4.x only.
>
> For example: org.apache.commons.collections4.junit.SetDefaultLocaleTestRule
>
> I have other rules stashed here and there as well, for example a Set
> Default Charset Rule.
>
> Thoughts?
>
> Gary

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

Re: [lang] release 3.7

[Gary Gregory]

On Sat, Nov 4, 2017 at 9:54 AM, Pascal Schumacher 
wrote:

> Sorry if I haven't made myself clear. I was speaking of already commited
> fixes (I'm not currently planning/working on any new ones.)


Thank you for clarifying! I like clarity :-) We can loose so much in email
comms.

Gary


>
>
> Am 04.11.2017 um 15:40 schrieb Gary Gregory:
>
>> Right now, I am just looking at what is in git master. Feel free to patch
>> away ;-)
>>
>> Gary
>>
>> On Sat, Nov 4, 2017 at 8:22 AM, Pascal Schumacher <
>> pascalschumac...@gmx.net>
>> wrote:
>>
>> +1, there are also some bugfixes for that it would be nice to have a
>>> release
>>>
>>> Am 03.11.2017 um 18:36 schrieb Gary Gregory:
>>>
>>> Hi All:

 I propose we release 3.7 principally to pick up
 https://issues.apache.org/jira/browse/LANG-1365 to support those brave
 souls trying out Java 10 EA.

 Gary


 -
>>> 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: [VOTE] Release Apache Commons Lang 3.7 based on RC1

[Gary Gregory]

My +1

Gary

On Sat, Nov 4, 2017 at 12:50 PM, Gary Gregory 
wrote:

> We have fixed a few bugs since Apache Commons Lang 3.6 was released, so I
> would like to release Apache Commons Lang 3.7.
>
> Apache Commons Lang 3.7 RC1 is available for review here:
> https://dist.apache.org/repos/dist/dev/commons/lang at revision: 22853
> Get it like this: svn co https://dist.apache.org/repos/
> dist/dev/commons/lang
>
> The tag is here:
> https://git-wip-us.apache.org/repos/asf?p=commons-lang.git;
> a=tag;h=refs/tags/LANG_3_7_RC1
> object 425d8085cfcaab5a78bf0632f9ae77b7e9127cf8
>
> Maven artifacts are here:
> https://repository.apache.org/content/repositories/
> orgapachecommons-1288
>
> These are the artifacts and their SHA1 hashes:
>
> /org/apache/commons/commons-lang3/3.7/commons-lang3-3.7-
> test-sources.jar.asc
> (SHA1: b9d6588eba0ee1cef9edf51283bf2004fcb71238)
> /org/apache/commons/commons-lang3/3.7/commons-lang3-3.7-tests.jar.asc
> (SHA1: e300353ba37288f4308534c38488792a57e52e3b)
> /org/apache/commons/commons-lang3/3.7/commons-lang3-3.7-src.zip
> (SHA1: 6316036a39e10dc61f7996672af13be0cddd03d5)
> /org/apache/commons/commons-lang3/3.7/commons-lang3-3.7-sources.jar
> (SHA1: e7e36219edde1c66c93495a75490d8f526c377cb)
> /org/apache/commons/commons-lang3/3.7/commons-lang3-3.7-javadoc.jar.asc
> (SHA1: deba56c5874a5c023ad209f0d7b9f7690830a6fd)
> /org/apache/commons/commons-lang3/3.7/commons-lang3-3.7-src.zip.asc
> (SHA1: 31f67cddf7f5bb5a933dcd2667da8af3a86c40ef)
> /org/apache/commons/commons-lang3/3.7/commons-lang3-3.7-bin.zip.asc
> (SHA1: dcee70c101432b6a61ec03f3282cf3512c61645d)
> /org/apache/commons/commons-lang3/3.7/commons-lang3-3.7-tests.jar
> (SHA1: e2b2ef23bf522cbfa9c49a905fb278ba1fd4eadb)
> /org/apache/commons/commons-lang3/3.7/commons-lang3-3.7-bin.tar.gz.asc
> (SHA1: ee9f3adcbe2b7bb93f1300ec843c9d3f25d215db)
> /org/apache/commons/commons-lang3/3.7/commons-lang3-3.7-test-sources.jar
> (SHA1: f51e03bffa2fd21efa309e562213803b38d3b5b2)
> /org/apache/commons/commons-lang3/3.7/commons-lang3-3.7-src.tar.gz.asc
> (SHA1: 7019c1310c9dcba3375ef03ea509b9caa2de8f6c)
> /org/apache/commons/commons-lang3/3.7/commons-lang3-3.7-sources.jar.asc
> (SHA1: 2bb88579e6ced65c30a9f5615f4a83584edba0ce)
> /org/apache/commons/commons-lang3/3.7/commons-lang3-3.7-bin.tar.gz
> (SHA1: b7ff9054614d9a3c58798fe93cab468b241b8496)
> /org/apache/commons/commons-lang3/3.7/commons-lang3-3.7.pom
> (SHA1: c445be3b6442b41cbea539d4218be3aea9428a55)
> /org/apache/commons/commons-lang3/3.7/commons-lang3-3.7.jar
> (SHA1: 557edd918fd41f9260963583ebf5a61a43a6b423)
> /org/apache/commons/commons-lang3/3.7/commons-lang3-3.7-src.tar.gz
> (SHA1: 1027d100c5099634a244a9c517e304518507c466)
> /org/apache/commons/commons-lang3/3.7/commons-lang3-3.7-javadoc.jar
> (SHA1: 08d6fb4d39bedef08da171550c73b5d84e8c1125)
> /org/apache/commons/commons-lang3/3.7/commons-lang3-3.7.pom.asc
> (SHA1: 43481d694125cced7ebba307634d716c96229c69)
> /org/apache/commons/commons-lang3/3.7/commons-lang3-3.7-bin.zip
> (SHA1: 18f12e2e26b820ec1680889c3afa0c6a9f65b68a)
> /org/apache/commons/commons-lang3/3.7/commons-lang3-3.7.jar.asc
> (SHA1: cdcce5ca9a5df3ee087148c815266ba8567ea7aa)
>
> I tested this RC using 'mvn clean verify' on Microsoft Windows [Version
> 10.0.16299.19] with:
>
> - Oracle Java 7
> - Oracle Java 8
> - Oracle Java 9
> - Oracle Java 10 EA b29
> - IBM Java 8
>
> Apache Maven 3.5.2 (138edd61fd100ec658bfa2d307c43b76940a5d7d;
> 2017-10-18T01:58:13-06:00)
> Maven home: C:\Java\apache-maven-3.5.2\bin\..
> Java version: 1.7.0_80, vendor: Oracle Corporation
> Java home: C:\Program Files\Java\jdk1.7.0_80\jre
> Default locale: en_US, platform encoding: Cp1252
> OS name: "windows 8.1", version: "6.3", arch: "amd64", family: "windows"
>
> Apache Maven 3.5.2 (138edd61fd100ec658bfa2d307c43b76940a5d7d;
> 2017-10-18T01:58:13-06:00)
> Maven home: C:\Java\apache-maven-3.5.2\bin\..
> Java version: 1.8.0_152, vendor: Oracle Corporation
> Java home: C:\Program Files\Java\jdk1.8.0_152\jre
> Default locale: en_US, platform encoding: Cp1252
> OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"
>
> Apache Maven 3.5.2 (138edd61fd100ec658bfa2d307c43b76940a5d7d;
> 2017-10-18T01:58:13-06:00)
> Maven home: C:\Java\apache-maven-3.5.2\bin\..
> Java version: 9.0.1, vendor: Oracle Corporation
> Java home: C:\Program Files\Java\jdk-9.0.1
> Default locale: en_US, platform encoding: Cp1252
> OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"
>
> Apache Maven 3.5.2 (138edd61fd100ec658bfa2d307c43b76940a5d7d;
> 2017-10-18T01:58:13-06:00)
> Maven home: C:\Java\apache-maven-3.5.2\bin\..
> Java version: 10-ea, vendor: Oracle Corporation
> Java home: C:\Program Files\Java\jdk-10
> Default locale: en_US, platform encoding: Cp1252
> OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"
>
> Apache Maven 3.5.2 (138edd61fd100ec658bfa2d307c43b76940a5d7d;
> 2017-10-18T01:58:13-06:00)
> Maven home: C:\Java\apache-maven-3.5.2\bin\..
> Java versio

Re: [dbcp] update to pool 2.4.3.

[Gary Gregory]

Hi Matt,

Any chance you get take a look this week?

Gary

On Tue, Oct 31, 2017 at 10:58 AM, Mark Thomas  wrote:

> On 31/10/17 14:44, Gary Gregory wrote:
> > On Tue, Oct 31, 2017 at 8:33 AM, Matt Sicker  wrote:
> >
> >> On 31 October 2017 at 04:21, Mark Thomas  wrote:
> >>>
> >>> If the methods are required then that makes 2.4.3 broken in my view. In
> >>> which case we should wait for 2.4.4 before updating the version DBCP
> >>> depends on. I don't think we should adapt the test. The test is telling
> >>> us something is broken. We should fix the root cause not change the
> test.
> >>>
> >>
> >> Regarding this, if the method names were expected in the output, then a
> >> unit test should have existed to verify that. The existing test was only
> >> checking for class names, so I'm assuming that's why I made the change a
> >> while back to optimize it for that use case. I think I asked on the
> mailing
> >> lists first, but that was a while ago.
> >>
> >
> > It sounds like the missing unit test in [pool] was actually in [dbcp]!
> :-p
> >
> > Matt or Mark, would you mind pitching in to fill out this missing test?
>
> I'll help out when I can but I'm heads down working through the DAEMON
> issues at the moment. It is probably going to be a few days before I'm
> done there.
>
> Mark
>
>
> >
> > Thank you,
> > Gary
> >
> >
> >>
> >>> - fix pool
> >>> - release pool 2.4.4
> >>> - update DBCP to pool 2.4.4
> >>> - release DBCP
> >>>
> >>
> >> Sounds good to me. This can be done by just removing the SecurityManager
> >> version since a StackWalker version of CallStack could be implemented
> for
> >> Java 9, so it would be pointless to fully revert the change.
> >>
> >> --
> >> Matt Sicker 
> >>
> >
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: [VOTE] Release Apache Commons JCS 2.2.1 (roll 2)

[Gary Gregory]

On Fri, Oct 27, 2017 at 4:51 AM, Thomas Vandahl  wrote:

> Hi Gary,
>
> On 25.10.17 05:24, Gary Gregory wrote:
> > Our process documented here http://commons.apache.org/
> releases/prepare.html
> > makes it pretty clear that the RC tag should be labeled as such and that
> a
> > tag like "commons-jcs-2.2.1" should only be created after a VOTE passes.
>
> as this release is created using the Maven Release plugin, the automatic
> process is to create a tag identical to the release version. The docs
> you mention tell nothing about how to handle the RC case. Does the RC
> tag need to be renamed, copied or re-created?
>

The document http://commons.apache.org/releases/prepare.html clearly shows
an example of an RC tag being labeled with the "RC1" postfix.

Gary


>
> BTW, there was no such request when I created the previous three releases.
>
> Bye, Thomas
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: [VOTE] Release Apache Commons JCS 2.2.1 (roll 2)

[Gary Gregory]

On Sat, Oct 28, 2017 at 1:01 AM, Benedikt Ritter  wrote:

>
>
> > Am 27.10.2017 um 12:51 schrieb Thomas Vandahl :
> >
> > Hi Gary,
> >
> > On 25.10.17 05:24, Gary Gregory wrote:
> >> Our process documented here http://commons.apache.org/
> releases/prepare.html
> >> makes it pretty clear that the RC tag should be labeled as such and
> that a
> >> tag like "commons-jcs-2.2.1" should only be created after a VOTE passes.
> >
> > as this release is created using the Maven Release plugin, the automatic
> > process is to create a tag identical to the release version. The docs
> > you mention tell nothing about how to handle the RC case. Does the RC
> > tag need to be renamed, copied or re-created?
> >
> > BTW, there was no such request when I created the previous three
> releases.
>
> I agree, we shouldn’t be to picky, since releasing components is already a
> PITA.
>

I agree that the release process is a PITA. I've complained about it many
times before on this ML but I've never contributed a solution to improve
the process.

I think there is talk of improving the commons build plugin... but I am not
sure how.

Surely, having to publish to both "dist" and Nexus is a pain.

Gary


>
> Benedikt
>
> >
> > 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: [dbcp] update to pool 2.4.3.

[Matt Sicker]

I probably can, yeah. Totally slipped my mind about this, though!

On 5 November 2017 at 21:46, Gary Gregory  wrote:

> Hi Matt,
>
> Any chance you get take a look this week?
>
> Gary
>
> On Tue, Oct 31, 2017 at 10:58 AM, Mark Thomas  wrote:
>
> > On 31/10/17 14:44, Gary Gregory wrote:
> > > On Tue, Oct 31, 2017 at 8:33 AM, Matt Sicker  wrote:
> > >
> > >> On 31 October 2017 at 04:21, Mark Thomas  wrote:
> > >>>
> > >>> If the methods are required then that makes 2.4.3 broken in my view.
> In
> > >>> which case we should wait for 2.4.4 before updating the version DBCP
> > >>> depends on. I don't think we should adapt the test. The test is
> telling
> > >>> us something is broken. We should fix the root cause not change the
> > test.
> > >>>
> > >>
> > >> Regarding this, if the method names were expected in the output, then
> a
> > >> unit test should have existed to verify that. The existing test was
> only
> > >> checking for class names, so I'm assuming that's why I made the
> change a
> > >> while back to optimize it for that use case. I think I asked on the
> > mailing
> > >> lists first, but that was a while ago.
> > >>
> > >
> > > It sounds like the missing unit test in [pool] was actually in [dbcp]!
> > :-p
> > >
> > > Matt or Mark, would you mind pitching in to fill out this missing test?
> >
> > I'll help out when I can but I'm heads down working through the DAEMON
> > issues at the moment. It is probably going to be a few days before I'm
> > done there.
> >
> > Mark
> >
> >
> > >
> > > Thank you,
> > > Gary
> > >
> > >
> > >>
> > >>> - fix pool
> > >>> - release pool 2.4.4
> > >>> - update DBCP to pool 2.4.4
> > >>> - release DBCP
> > >>>
> > >>
> > >> Sounds good to me. This can be done by just removing the
> SecurityManager
> > >> version since a StackWalker version of CallStack could be implemented
> > for
> > >> Java 9, so it would be pointless to fully revert the change.
> > >>
> > >> --
> > >> Matt Sicker 
> > >>
> > >
> >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > For additional commands, e-mail: dev-h...@commons.apache.org
> >
> >
>



-- 
Matt Sicker 

Re: [VOTE] Release Apache Commons JCS 2.2.1 (roll 2)

[Romain Manni-Bucau]

Dist/Nexus is a manual step but ok. Rc creation is a blocker since it
prevent to use maven tools - release plugin. Did we - as commons - already
open a feature request to maven?

Anyway dont think it blocks the release *now* so can we proceed?

Also moving to git can solve it by design too since we dont need to push
upstream the branch before the release is done.

Le 6 nov. 2017 04:50, "Gary Gregory"  a écrit :

> On Sat, Oct 28, 2017 at 1:01 AM, Benedikt Ritter 
> wrote:
>
> >
> >
> > > Am 27.10.2017 um 12:51 schrieb Thomas Vandahl :
> > >
> > > Hi Gary,
> > >
> > > On 25.10.17 05:24, Gary Gregory wrote:
> > >> Our process documented here http://commons.apache.org/
> > releases/prepare.html
> > >> makes it pretty clear that the RC tag should be labeled as such and
> > that a
> > >> tag like "commons-jcs-2.2.1" should only be created after a VOTE
> passes.
> > >
> > > as this release is created using the Maven Release plugin, the
> automatic
> > > process is to create a tag identical to the release version. The docs
> > > you mention tell nothing about how to handle the RC case. Does the RC
> > > tag need to be renamed, copied or re-created?
> > >
> > > BTW, there was no such request when I created the previous three
> > releases.
> >
> > I agree, we shouldn’t be to picky, since releasing components is already
> a
> > PITA.
> >
>
> I agree that the release process is a PITA. I've complained about it many
> times before on this ML but I've never contributed a solution to improve
> the process.
>
> I think there is talk of improving the commons build plugin... but I am not
> sure how.
>
> Surely, having to publish to both "dist" and Nexus is a pain.
>
> Gary
>
>
> >
> > Benedikt
> >
> > >
> > > 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: [VOTE] Release Apache Commons JCS 2.2.1 (roll 2)

[Gary Gregory]

The blocker part is that the VOTE email does not follow the process or the
format outlined on http://commons.apache.org/releases/prepare.html

Specifically,
- the tag does not contain an "RC2" postfix (since this is the 2nd RC).
- there is not tag for RC1 so we've lost what we voted on for RC1 (too late
for that.)
- the email does not contain the file names with hashes (see the email
Nexus sent you when you "closed" the repository.)
- the links to SVN resources do not contain SVN revision numbers (required
since SVN tags are mutable)

This is all fixable without an RC3, you just need to send a VOTE email that
follows the format in http://commons.apache.org/releases/prepare.html

Gary

On Sun, Nov 5, 2017 at 10:55 PM, Romain Manni-Bucau 
wrote:

> Dist/Nexus is a manual step but ok. Rc creation is a blocker since it
> prevent to use maven tools - release plugin. Did we - as commons - already
> open a feature request to maven?
>
> Anyway dont think it blocks the release *now* so can we proceed?
>
> Also moving to git can solve it by design too since we dont need to push
> upstream the branch before the release is done.
>
> Le 6 nov. 2017 04:50, "Gary Gregory"  a écrit :
>
> > On Sat, Oct 28, 2017 at 1:01 AM, Benedikt Ritter 
> > wrote:
> >
> > >
> > >
> > > > Am 27.10.2017 um 12:51 schrieb Thomas Vandahl :
> > > >
> > > > Hi Gary,
> > > >
> > > > On 25.10.17 05:24, Gary Gregory wrote:
> > > >> Our process documented here http://commons.apache.org/
> > > releases/prepare.html
> > > >> makes it pretty clear that the RC tag should be labeled as such and
> > > that a
> > > >> tag like "commons-jcs-2.2.1" should only be created after a VOTE
> > passes.
> > > >
> > > > as this release is created using the Maven Release plugin, the
> > automatic
> > > > process is to create a tag identical to the release version. The docs
> > > > you mention tell nothing about how to handle the RC case. Does the RC
> > > > tag need to be renamed, copied or re-created?
> > > >
> > > > BTW, there was no such request when I created the previous three
> > > releases.
> > >
> > > I agree, we shouldn’t be to picky, since releasing components is
> already
> > a
> > > PITA.
> > >
> >
> > I agree that the release process is a PITA. I've complained about it many
> > times before on this ML but I've never contributed a solution to improve
> > the process.
> >
> > I think there is talk of improving the commons build plugin... but I am
> not
> > sure how.
> >
> > Surely, having to publish to both "dist" and Nexus is a pain.
> >
> > Gary
> >
> >
> > >
> > > Benedikt
> > >
> > > >
> > > > 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: [VOTE] Release Apache Commons JCS 2.2.1 (roll 2)

[Romain Manni-Bucau]

Answers inline.

2017-11-06 7:08 GMT+01:00 Gary Gregory :
> The blocker part is that the VOTE email does not follow the process or the
> format outlined on http://commons.apache.org/releases/prepare.html
>
> Specifically,
> - the tag does not contain an "RC2" postfix (since this is the 2nd RC).
> - there is not tag for RC1 so we've lost what we voted on for RC1 (too late
> for that.)

It is fine I think to not have the tags since they are "dead tags"
anyway. No need to recreate them now probably.

> - the email does not contain the file names with hashes (see the email
> Nexus sent you when you "closed" the repository.)

Will need to check but seems our nexus is not accessible ATM

> - the links to SVN resources do not contain SVN revision numbers (required
> since SVN tags are mutable)

r1809493

>
> This is all fixable without an RC3, you just need to send a VOTE email that
> follows the format in http://commons.apache.org/releases/prepare.html
>
> Gary
>
> On Sun, Nov 5, 2017 at 10:55 PM, Romain Manni-Bucau 
> wrote:
>
>> Dist/Nexus is a manual step but ok. Rc creation is a blocker since it
>> prevent to use maven tools - release plugin. Did we - as commons - already
>> open a feature request to maven?
>>
>> Anyway dont think it blocks the release *now* so can we proceed?
>>
>> Also moving to git can solve it by design too since we dont need to push
>> upstream the branch before the release is done.
>>
>> Le 6 nov. 2017 04:50, "Gary Gregory"  a écrit :
>>
>> > On Sat, Oct 28, 2017 at 1:01 AM, Benedikt Ritter 
>> > wrote:
>> >
>> > >
>> > >
>> > > > Am 27.10.2017 um 12:51 schrieb Thomas Vandahl :
>> > > >
>> > > > Hi Gary,
>> > > >
>> > > > On 25.10.17 05:24, Gary Gregory wrote:
>> > > >> Our process documented here http://commons.apache.org/
>> > > releases/prepare.html
>> > > >> makes it pretty clear that the RC tag should be labeled as such and
>> > > that a
>> > > >> tag like "commons-jcs-2.2.1" should only be created after a VOTE
>> > passes.
>> > > >
>> > > > as this release is created using the Maven Release plugin, the
>> > automatic
>> > > > process is to create a tag identical to the release version. The docs
>> > > > you mention tell nothing about how to handle the RC case. Does the RC
>> > > > tag need to be renamed, copied or re-created?
>> > > >
>> > > > BTW, there was no such request when I created the previous three
>> > > releases.
>> > >
>> > > I agree, we shouldn’t be to picky, since releasing components is
>> already
>> > a
>> > > PITA.
>> > >
>> >
>> > I agree that the release process is a PITA. I've complained about it many
>> > times before on this ML but I've never contributed a solution to improve
>> > the process.
>> >
>> > I think there is talk of improving the commons build plugin... but I am
>> not
>> > sure how.
>> >
>> > Surely, having to publish to both "dist" and Nexus is a pain.
>> >
>> > Gary
>> >
>> >
>> > >
>> > > Benedikt
>> > >
>> > > >
>> > > > 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
>> > >
>> > >
>> >
>>

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

Maven release plugin?

[Romain Manni-Bucau]

Hi guys,

due to the RCx procedure we cant use the maven release plugin, any
plan to make it working with commons release procedure or do we just
wait to move all to git?

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

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