Re: [commons-release-plugin] (Was: svn commit: r24003 - in /dev/commons/text: ./ binaries/ source/)

[Rob Tompkins]

I think that I’ve accommodated for that, but to be certain I’ll stage the lang3 
snapshot in the dev dust area in the morning to be certain. 

-Rob

> On Jan 3, 2018, at 10:46 PM, Gary Gregory  wrote:
> 
> Did you see my message about lang vs lang3, where the folder name does not
> match the artifact ID?
> 
> Gary
> 
>> On Jan 3, 2018 19:07, "Rob Tompkins"  wrote:
>> 
>> Hello all,
>> 
>> So, now I have a plugin that detaches the distributions, zips the site,
>> and then commits the zipped site, RELEASE-NOTES.txt (from the root), and
>> the distributions to the svn staging area. All from:
>> 
>> mvn clean site deploy -Prelease -Duser.name=chtompki
>> -Duser.password=
>> 
>> Thoughts on pulling this in as a new component and starting to get it to a
>> more formal state? I’m sure we could add more, but this does take away a
>> considerable portion of the manual steps.
>> 
>> Also, as I said before I’ve not written any maven unit/integration tests.
>> I do know that I could contrive some unit tests using PowerMockito (but
>> that feels mildly pointless because it is indeed a contrivance with little
>> value). So, I will try to investigate the maven testing mechanics, but what
>> I currently have does indeed work.
>> 
>> Should I call a vote for the new component?
>> 
>> Cheers,
>> -Rob
>> 
>> 
>> 
>>> On Jan 3, 2018, at 8:59 PM, chtom...@apache.org wrote:
>>> 
>>> Author: chtompki
>>> Date: Thu Jan  4 01:59:44 2018
>>> New Revision: 24003
>>> 
>>> Log:
>>> Removing commons-text-1.3-SNAPSHOT
>>> 
>>> Removed:
>>>  dev/commons/text/RELEASE-NOTES.txt
>>>  dev/commons/text/binaries/commons-text-1.3-SNAPSHOT-bin.tar.gz
>>>  dev/commons/text/binaries/commons-text-1.3-SNAPSHOT-bin.tar.gz.asc
>>>  dev/commons/text/binaries/commons-text-1.3-SNAPSHOT-bin.tar.gz.md5
>>>  dev/commons/text/binaries/commons-text-1.3-SNAPSHOT-bin.tar.gz.sha1
>>>  dev/commons/text/binaries/commons-text-1.3-SNAPSHOT-bin.zip
>>>  dev/commons/text/binaries/commons-text-1.3-SNAPSHOT-bin.zip.asc
>>>  dev/commons/text/binaries/commons-text-1.3-SNAPSHOT-bin.zip.md5
>>>  dev/commons/text/binaries/commons-text-1.3-SNAPSHOT-bin.zip.sha1
>>>  dev/commons/text/site.zip
>>>  dev/commons/text/source/commons-text-1.3-SNAPSHOT-src.tar.gz
>>>  dev/commons/text/source/commons-text-1.3-SNAPSHOT-src.tar.gz.asc
>>>  dev/commons/text/source/commons-text-1.3-SNAPSHOT-src.tar.gz.md5
>>>  dev/commons/text/source/commons-text-1.3-SNAPSHOT-src.tar.gz.sha1
>>>  dev/commons/text/source/commons-text-1.3-SNAPSHOT-src.zip
>>>  dev/commons/text/source/commons-text-1.3-SNAPSHOT-src.zip.asc
>>>  dev/commons/text/source/commons-text-1.3-SNAPSHOT-src.zip.md5
>>>  dev/commons/text/source/commons-text-1.3-SNAPSHOT-src.zip.sha1
>>> 
>> 
>> 
>> -
>> 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-release-plugin] (Was: svn commit: r24003 - in /dev/commons/text: ./ binaries/ source/)

[Gary Gregory]

Did you see my message about lang vs lang3, where the folder name does not
match the artifact ID?

Gary

On Jan 3, 2018 19:07, "Rob Tompkins"  wrote:

> Hello all,
>
> So, now I have a plugin that detaches the distributions, zips the site,
> and then commits the zipped site, RELEASE-NOTES.txt (from the root), and
> the distributions to the svn staging area. All from:
>
> mvn clean site deploy -Prelease -Duser.name=chtompki
> -Duser.password=
>
> Thoughts on pulling this in as a new component and starting to get it to a
> more formal state? I’m sure we could add more, but this does take away a
> considerable portion of the manual steps.
>
> Also, as I said before I’ve not written any maven unit/integration tests.
> I do know that I could contrive some unit tests using PowerMockito (but
> that feels mildly pointless because it is indeed a contrivance with little
> value). So, I will try to investigate the maven testing mechanics, but what
> I currently have does indeed work.
>
> Should I call a vote for the new component?
>
> Cheers,
> -Rob
>
>
>
> > On Jan 3, 2018, at 8:59 PM, chtom...@apache.org wrote:
> >
> > Author: chtompki
> > Date: Thu Jan  4 01:59:44 2018
> > New Revision: 24003
> >
> > Log:
> > Removing commons-text-1.3-SNAPSHOT
> >
> > Removed:
> >   dev/commons/text/RELEASE-NOTES.txt
> >   dev/commons/text/binaries/commons-text-1.3-SNAPSHOT-bin.tar.gz
> >   dev/commons/text/binaries/commons-text-1.3-SNAPSHOT-bin.tar.gz.asc
> >   dev/commons/text/binaries/commons-text-1.3-SNAPSHOT-bin.tar.gz.md5
> >   dev/commons/text/binaries/commons-text-1.3-SNAPSHOT-bin.tar.gz.sha1
> >   dev/commons/text/binaries/commons-text-1.3-SNAPSHOT-bin.zip
> >   dev/commons/text/binaries/commons-text-1.3-SNAPSHOT-bin.zip.asc
> >   dev/commons/text/binaries/commons-text-1.3-SNAPSHOT-bin.zip.md5
> >   dev/commons/text/binaries/commons-text-1.3-SNAPSHOT-bin.zip.sha1
> >   dev/commons/text/site.zip
> >   dev/commons/text/source/commons-text-1.3-SNAPSHOT-src.tar.gz
> >   dev/commons/text/source/commons-text-1.3-SNAPSHOT-src.tar.gz.asc
> >   dev/commons/text/source/commons-text-1.3-SNAPSHOT-src.tar.gz.md5
> >   dev/commons/text/source/commons-text-1.3-SNAPSHOT-src.tar.gz.sha1
> >   dev/commons/text/source/commons-text-1.3-SNAPSHOT-src.zip
> >   dev/commons/text/source/commons-text-1.3-SNAPSHOT-src.zip.asc
> >   dev/commons/text/source/commons-text-1.3-SNAPSHOT-src.zip.md5
> >   dev/commons/text/source/commons-text-1.3-SNAPSHOT-src.zip.sha1
> >
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

[commons-release-plugin] (Was: svn commit: r24003 - in /dev/commons/text: ./ binaries/ source/)

[Rob Tompkins]

Hello all,

So, now I have a plugin that detaches the distributions, zips the site, and 
then commits the zipped site, RELEASE-NOTES.txt (from the root), and the 
distributions to the svn staging area. All from:

mvn clean site deploy -Prelease -Duser.name=chtompki 
-Duser.password=

Thoughts on pulling this in as a new component and starting to get it to a more 
formal state? I’m sure we could add more, but this does take away a 
considerable portion of the manual steps.

Also, as I said before I’ve not written any maven unit/integration tests. I do 
know that I could contrive some unit tests using PowerMockito (but that feels 
mildly pointless because it is indeed a contrivance with little value). So, I 
will try to investigate the maven testing mechanics, but what I currently have 
does indeed work.

Should I call a vote for the new component?

Cheers,
-Rob



> On Jan 3, 2018, at 8:59 PM, chtom...@apache.org wrote:
> 
> Author: chtompki
> Date: Thu Jan  4 01:59:44 2018
> New Revision: 24003
> 
> Log:
> Removing commons-text-1.3-SNAPSHOT
> 
> Removed:
>   dev/commons/text/RELEASE-NOTES.txt
>   dev/commons/text/binaries/commons-text-1.3-SNAPSHOT-bin.tar.gz
>   dev/commons/text/binaries/commons-text-1.3-SNAPSHOT-bin.tar.gz.asc
>   dev/commons/text/binaries/commons-text-1.3-SNAPSHOT-bin.tar.gz.md5
>   dev/commons/text/binaries/commons-text-1.3-SNAPSHOT-bin.tar.gz.sha1
>   dev/commons/text/binaries/commons-text-1.3-SNAPSHOT-bin.zip
>   dev/commons/text/binaries/commons-text-1.3-SNAPSHOT-bin.zip.asc
>   dev/commons/text/binaries/commons-text-1.3-SNAPSHOT-bin.zip.md5
>   dev/commons/text/binaries/commons-text-1.3-SNAPSHOT-bin.zip.sha1
>   dev/commons/text/site.zip
>   dev/commons/text/source/commons-text-1.3-SNAPSHOT-src.tar.gz
>   dev/commons/text/source/commons-text-1.3-SNAPSHOT-src.tar.gz.asc
>   dev/commons/text/source/commons-text-1.3-SNAPSHOT-src.tar.gz.md5
>   dev/commons/text/source/commons-text-1.3-SNAPSHOT-src.tar.gz.sha1
>   dev/commons/text/source/commons-text-1.3-SNAPSHOT-src.zip
>   dev/commons/text/source/commons-text-1.3-SNAPSHOT-src.zip.asc
>   dev/commons/text/source/commons-text-1.3-SNAPSHOT-src.zip.md5
>   dev/commons/text/source/commons-text-1.3-SNAPSHOT-src.zip.sha1
> 


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

Re: [release-plugin/text] Going to stage snapshot artifacts and remove them

[Rob Tompkins]

Will do. Ran out of time yesterday debugging the svn authentication. 

> On Jan 3, 2018, at 2:27 PM, Jochen Wiedmann  wrote:
> 
> Go on.
> 
> Jochen
> 
> 
>> On Tue, Jan 2, 2018 at 9:17 PM, Rob Tompkins  wrote:
>> Just as a heads up. I’m getting to a place where I’m fiddling around with 
>> the svn commit into the dev region of the dist svn repo. To effectively test 
>> that my code works properly, I’m going to commit "commons-text-1.3-SNAPSHOT” 
>> to the dist staging area, and then remove it.
>> 
>> Let me know if I’m doing something improper here, but I don’t think that it 
>> should cause any issues.
>> 
>> Cheers,
>> -Rob
>> -
>> 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: Hello and possible addition

[Otto Fowler]

https://github.com/apache/commons-lang/pull/311


On January 3, 2018 at 09:05:37, Benedikt Ritter (brit...@apache.org) wrote:



> Am 03.01.2018 um 15:02 schrieb Otto Fowler :
>
> Just to check, Java 7 is the required language level?

Yes

>
>
> On January 3, 2018 at 07:12:03, Otto Fowler (ottobackwa...@gmail.com)
wrote:
>
> While working on adding some timing functionality to a Metron feature, I
> came across the
> Stopwatch
> <
https://commons.apache.org/proper/commons-lang/javadocs/api-release/org/apache/commons/lang3/time/StopWatch.html>

> class, but found that it didn’t suite my needs.
>
> What I wanted to do was to create a timing from a top level function in
our
> Stellar
> <
https://github.com/apache/metron/tree/master/metron-stellar/stellar-common>
> dsl, and have have a group of related timings, such that the end result
> was the overall time of the call, and nested timings of other calls
> executed during the dsl execution of that function. These timings would
all
> be named, and have a path for identification and include timing the
> language compiler/execution as well as the function execution itself. It
> would be helpful if they were tagged in some way as well, such that the
> consumer could filter during visitation.
>
> So I have written StackWatch 
to
> provide this functionality, and submitted it in a Metron PR
> .
>
> From the PR description:
> StackWatch
>
> A set of utility classes under the new package stellar.common.timing have
> been added. These provide the StackWatch functionality.
>
> StackWatch provides an abstraction over the Apache Commons StopWatch
class
> that allows callers to create multiple named and possibly nested timing
> operations.
>
> <…>
>
> This class may be more generally useful to this and other projects, but I
> am not sure where it would live since we wouldn’t want it in common.
>
> StackWatch uses a combination of Deque and a custom Tree implementation
to
> create, start and end timing operations.
>
> A Visitor pattern is also implemented to allow for retrieving the results
> after the completion of the operation.
>
> See the StackWatch tests for examples of nested function timings.
> --
>
> A quick look at the PR and it’s test or the github project ( they are in
> sync ) should show the idea.
>
> I am sending this to see if this functionality would be appropriate for
> commons in some way. If so, the I can create the jira and submit the pr.
> Even if it is not appropriate, any feedback or pr’s on the github project
> would still be most welcome.
>
> Thanks for all the work that has made commons so valuable to other Apache
> projects and java developers in general!


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

Re: [release-plugin/text] Going to stage snapshot artifacts and remove them

[Jochen Wiedmann]

Go on.

Jochen


On Tue, Jan 2, 2018 at 9:17 PM, Rob Tompkins  wrote:
> Just as a heads up. I’m getting to a place where I’m fiddling around with the 
> svn commit into the dev region of the dist svn repo. To effectively test that 
> my code works properly, I’m going to commit "commons-text-1.3-SNAPSHOT” to 
> the dist staging area, and then remove it.
>
> Let me know if I’m doing something improper here, but I don’t think that it 
> should cause any issues.
>
> Cheers,
> -Rob
> -
> 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] code coverage too low?

[Gary Gregory]

Hi All:

[INFO] --- jacoco-maven-plugin:0.7.9:check (check) @ commons-collections4
---
[INFO] Loading execution data file
C:\vcs\git\apache\commons\commons-collections\target\jacoco.exec
[INFO] Analyzed bundle 'commons-collections4' with 474 classes
[WARNING] Rule violated for bundle commons-collections4: classes covered
ratio is 0.98, but expected minimum is 1.00
[WARNING] Rule violated for bundle commons-collections4: instructions
covered ratio is 0.85, but expected minimum is 0.90
[WARNING] Rule violated for bundle commons-collections4: methods covered
ratio is 0.86, but expected minimum is 0.95
[WARNING] Rule violated for bundle commons-collections4: branches covered
ratio is 0.80, but expected minimum is 0.85
[WARNING] Rule violated for bundle commons-collections4: lines covered
ratio is 0.86, but expected minimum is 0.90
[WARNING] Rule violated for bundle commons-collections4: complexity covered
ratio is 0.78, but expected minimum is 0.85
[WARNING] Coverage checks have not been met. See log for details.

If anyone wants to scratch that itch...

Gary

Re: [compress] AR docs confusion

[Torsten Curdt]

Thanks - that was quick :)

On Wed, Jan 3, 2018 at 5:20 PM, Stefan Bodewig  wrote:

> On 2018-01-03, Torsten Curdt wrote:
>
> > I think I'd just add a little table. OK?
>
> I've gone ahead and added a table, just not regenerated the site,
>
> Stefan
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: [compress] AR docs confusion

[Stefan Bodewig]

On 2018-01-03, Torsten Curdt wrote:

> I think I'd just add a little table. OK?

I've gone ahead and added a table, just not regenerated the site,

Stefan

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

Re: [beanutils] Moving to beanutils2

[Gary Gregory]

Since the old 2.0 branch is so... "sleepy" and I've not seen Simone here in
a long time, I'd rather keep the train moving as it is and if someone
really wants a breaking BC release, maybe that would be for a 3.0... or is
this simple a case of changing BU APIs from returning [collections]
concrete classes and/or interfaces instead of JRE interfaces?

Gary

On Mon, Jan 1, 2018 at 8:12 AM, Benedikt Ritter  wrote:

> Hi,
>
> > Am 30.12.2017 um 16:24 schrieb Gary Gregory :
> >
> > Who can speak to that code base?
>
> I’ve worked on BeanUtils2 some years ago together with Simone Tripodi. I
> think we should better work on this redesign instead oh pushing the old
> code base as 2.0 just to fix some dependencies. In fact I think that
> BeanUtils 1 exposes classes from Commons Collections in its public API is a
> big mess that we should fix when we roll a new major release.
>
> Benedikt
>
> >
> > Gary
> >
> > On Dec 30, 2017 03:54, "Benedikt Ritter"  wrote:
> >
> >>
> >>
> >>> Am 29.12.2017 um 19:58 schrieb Gary Gregory :
> >>>
> >>> On Wed, Dec 27, 2017 at 11:55 AM, Gary Gregory  >
> >>> wrote:
> >>>
>  The changes for:
> 
>  BEANUTILS-500 Upgrade commons-collections to 4
> 
>  break BC (see BEANUTILS-500).
> 
>  Therefore, I created BEANUTILS-503: Change packaging from
>  org.apache.commons.beanutils to org.apache.commons.beanutils2
> 
>  This change should happen sooner rather than later IMO to allow folks
>  using SNAPSHOT builds to adapt.
> 
>  Thoughts?
> 
> >>>
> >>> This is done is SVN trunk.
> >>
> >> We already have a complete rewrite of the BeanUtils API in the sandbox
> >> [1]. What do we want to do with that?
> >>
> >> Regards,
> >> Benedikt
> >>
> >> [1] http://svn.apache.org/viewvc/commons/sandbox/beanutils2/trunk/
> >>
> >>>
> >>> Gary
> >>>
> >>>
> 
>  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: [collections] toward 4.2

[Gary Gregory]

I've asked for some feedback on some old tickets, so we'll see if that gets
any attention. If nothing happens, I'll likely want to push out 4.2 RC1
after commons-parent 43 is out.

Gary

On Mon, Jan 1, 2018 at 8:08 AM, Benedikt Ritter  wrote:

> Hi,
>
> > Am 30.12.2017 um 20:07 schrieb Gary Gregory :
> >
> > On Dec 30, 2017 03:55, "Benedikt Ritter"  wrote:
> >
> > Hi,
> >
> > +1! We should finally get COLLECTIONS-653 out of the door.
> >
> >
> > Do you mean that the Javado is Java-8-clean?
>
> No, the Java 9 Module Manifest headers. The fix is already in trunk and
> just needs to be released.
>
> Regards,
> Benedikt
>
> >
> > Gary
> >
> >
> > Benedikt
> >
> >> Am 29.12.2017 um 18:58 schrieb Gary Gregory :
> >>
> >> Hi All,
> >>
> >> Does anyone want to fix some issues for 4.2? I am thinking of pushing
> out
> >> an RC soon.
> >>
> >> This is what we have so far:
> >>
> >> 
> >>due-to="Vamsi
> >> Kavuri">
> >> Unit tests MapUtilsTest and ListIteratorWrapperTest no longer fail
> on
> >> Java 9.
> >>   
> >>   
> >> Intermittent test failures in Windows for HashSetValuedHashMap.
> >>   
> >>   
> >> Uncomment test in AbstractMapTest regarding LRUMap equals.
> >>   
> >>   
> >> Add Automatic-Module-Name MANIFEST entry for Java 9 compatibility.
> >>   
> >>   
> >> Fix site build on Java 8.
> >>   
> >>   
> >> Update Javadoc to Build on Java 1.8.
> >>   
> >>due-to="Vamsi
> >> Kavuri">
> >> Build status, Coverage status and Maven central weren't in README.md
> >>   
> >>   
> >> Improve efficiency of DefaultedMap.get.
> >>   
> >>due-to="Artem
> >> Konovalov">
> >> Small improvements for generics, conditional statements, and
> warnings
> >> suppressions.
> >>   
> >>   
> >> Update platform from Java 6 to Java 7.
> >>   
> >>due-to="Javen
> >> O'Neal">
> >> Web site spelling error: MultiValuedMapeList.
> >>   
> >>>> due-to="Enrique">
> >>  Correction of Javadoc for
> >> org.apache.commons.collections4.functors.CatchAndRethrowClosure.
> >>   
> >>   
> >> Add null-safe MapUtils.size(Map?, ?>) method.
> >>   
> >>>> due-to="Shailender Bathula, Gary Gregory">
> >> PatriciaTrie prefixMap clear throws NullPointerException.
> >>   
> >>   
> >> Add class SortedProperties to sort keys.
> >>   
> >> 
> >>
> >> 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: [compress] TarArchiveEntry and Windows drive letter

[Gary Gregory]

I do not see how skipping the drive letter on Windows is not normalizing,
it is _moving_ sounds like a bug to me.

Gary

On Wed, Jan 3, 2018 at 8:46 AM, Torsten Curdt  wrote:

> I just found a new issue with compress.
>
> It's the "normalizeFileName" in TarArchiveEntry again.
> On Windows it just strips the drive letter
>
> https://github.com/apache/commons-compress/blob/master/src/
> main/java/org/apache/commons/compress/archivers/tar/
> TarArchiveEntry.java#L1337
>
> which I think is a questionable default behaviour IMO.
>
>TarArchiveEntry("C:\foo\bar") -> "/foo/bar"
>TarArchiveEntry("D:\foo\bar") -> "/foo/bar"
>
> Is that in line with how other unix tool ports handle things on windows?
>
> cheers,
> Torsten
>
> PS: Just for you sebb ;)
>

Re: [VOTE][LAZY] Release Apache Commons Parent 43 based on RC1

[Gary Gregory]

Let's also see what Rob comes up with with his new plugin...

On Wed, Jan 3, 2018 at 8:56 AM, Gary Gregory  wrote:

> OK, for the next go-around then.
>
> Gary
>
> On Wed, Jan 3, 2018 at 8:44 AM, Jörg Schaible 
> wrote:
>
>>
>> Sorry, I've missed the start of the vote, but I've changed the parent in
>> the meanwhile to build these artifacts
>> in the normal build.
>>
>> Am Tue, 02 Jan 2018 13:19:48 -0700 schrieb Gary Gregory:
>>
>> > We have updated plugins and are now ready to use Java 9 to build sites,
>> > so I would like to release Apache Commons Parent 43.
>> >
>> > Commons Parent 43 RC1 is available for review here:
>> > https://dist.apache.org/repos/dist/dev/commons/commons-parent/
>> > revision: 23984
>> >
>> > The tag is here:
>> >
>> > https://svn.apache.org/repos/asf/commons/proper/commons-pare
>> nt/tags/commons-parent-43-RC1/
>> > (svn revision 1819873)
>> > N.B. the SVN revision is required because SVN tags are not
>> > immutable.
>> >
>> > Maven artifacts are here:
>> >
>> > https://repository.apache.org/content/repositories/orgapache
>> commons-1301/org/apache/commons/
>> commons-parent/43/
>> 
>> >
>> > These are the Maven artifacts and their hashes
>> >
>> > /org/apache/commons/commons-parent/43/commons-parent-43-src.tar.gz
>> > (SHA1: dd3bbcc8714a5577e0670cc85ac8731a22046476)
>> > /org/apache/commons/commons-parent/43/commons-parent-43.pom.asc (SHA1:
>> > 567c63651185f47250b063de869265f1f95c746a)
>> > /org/apache/commons/commons-parent/43/commons-parent-43-site.xml.asc
>> > (SHA1: 1a3bd2240f6acd0c44d736b9e06eca4a903ef195)
>> > /org/apache/commons/commons-parent/43/commons-parent-43-site.xml (SHA1:
>> > a76e03e9059f31abc5e3c22f4e857366e689068f)
>> > /org/apache/commons/commons-parent/43/commons-parent-43-src.zip (SHA1:
>> > 95c7c17ef5dbdc94670e7153471102e8782ab362)
>> > /org/apache/commons/commons-parent/43/commons-parent-43-src.zip.asc
>> > (SHA1: 4f616bfb294a3f427f26dd594c98b4a08b8d0b90)
>> > /org/apache/commons/commons-parent/43/commons-parent-43.pom (SHA1:
>> > a24c1d164086ee8f10c11879da2f86f52cbea7fb)
>> > /org/apache/commons/commons-parent/43/commons-parent-43-src.tar.gz.asc
>> > (SHA1: 8b9620989da3be2c69e54689ca2d278d66fc25e1)
>> >
>> > I have tested this with:
>> >
>> > 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"
>> >
>> > I also tested building Apache Commons Collections 4.2-SNAPSHOT.
>> >
>> > Details of changes since version 42 are in the release notes:
>> >
>> > https://dist.apache.org/repos/dist/dev/commons/commons-paren
>> t/RELEASE-NOTES.txt
>> >
>> > Site (not used on commons.apache.org):
>> > https://dist.apache.org/repos/dist/dev/commons/
>> commons-parent/site.zip
>> > revision: 23985
>> >
>> > Clirr Report (compared to 42): Does not apply.
>> >
>> > RAT Report:
>> > See rat-report.html in zipped site.
>> >
>> > KEYS:
>> >   https://www.apache.org/dist/commons/KEYS
>> >
>> > This is a LAZY VOTE. Still, please feel free to review the release
>> > candidate and vote. This vote will close no sooner that 72 hours from
>> > now,
>> > i.e. sometime after 21:00 UTC 5-January 2018.
>> >
>> >   [ ] +1 Release these artifacts [ ] +0 OK, but...
>> >   [ ] -0 OK, but really should fix...
>> >   [ ] -1 I oppose this release because...
>> >
>> > Thanks!
>> >
>> > Gary Gregory Apache Commons V.P.
>>
>>
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> For additional commands, e-mail: dev-h...@commons.apache.org
>>
>>
>

Re: [VOTE][LAZY] Release Apache Commons Parent 43 based on RC1

[Gary Gregory]

OK, for the next go-around then.

Gary

On Wed, Jan 3, 2018 at 8:44 AM, Jörg Schaible  wrote:

>
> Sorry, I've missed the start of the vote, but I've changed the parent in
> the meanwhile to build these artifacts
> in the normal build.
>
> Am Tue, 02 Jan 2018 13:19:48 -0700 schrieb Gary Gregory:
>
> > We have updated plugins and are now ready to use Java 9 to build sites,
> > so I would like to release Apache Commons Parent 43.
> >
> > Commons Parent 43 RC1 is available for review here:
> > https://dist.apache.org/repos/dist/dev/commons/commons-parent/
> > revision: 23984
> >
> > The tag is here:
> >
> > https://svn.apache.org/repos/asf/commons/proper/commons-
> parent/tags/commons-parent-43-RC1/
> > (svn revision 1819873)
> > N.B. the SVN revision is required because SVN tags are not
> > immutable.
> >
> > Maven artifacts are here:
> >
> > https://repository.apache.org/content/repositories/
> orgapachecommons-1301/org/apache/commons/
> commons-parent/43/
> >
> > These are the Maven artifacts and their hashes
> >
> > /org/apache/commons/commons-parent/43/commons-parent-43-src.tar.gz
> > (SHA1: dd3bbcc8714a5577e0670cc85ac8731a22046476)
> > /org/apache/commons/commons-parent/43/commons-parent-43.pom.asc (SHA1:
> > 567c63651185f47250b063de869265f1f95c746a)
> > /org/apache/commons/commons-parent/43/commons-parent-43-site.xml.asc
> > (SHA1: 1a3bd2240f6acd0c44d736b9e06eca4a903ef195)
> > /org/apache/commons/commons-parent/43/commons-parent-43-site.xml (SHA1:
> > a76e03e9059f31abc5e3c22f4e857366e689068f)
> > /org/apache/commons/commons-parent/43/commons-parent-43-src.zip (SHA1:
> > 95c7c17ef5dbdc94670e7153471102e8782ab362)
> > /org/apache/commons/commons-parent/43/commons-parent-43-src.zip.asc
> > (SHA1: 4f616bfb294a3f427f26dd594c98b4a08b8d0b90)
> > /org/apache/commons/commons-parent/43/commons-parent-43.pom (SHA1:
> > a24c1d164086ee8f10c11879da2f86f52cbea7fb)
> > /org/apache/commons/commons-parent/43/commons-parent-43-src.tar.gz.asc
> > (SHA1: 8b9620989da3be2c69e54689ca2d278d66fc25e1)
> >
> > I have tested this with:
> >
> > 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"
> >
> > I also tested building Apache Commons Collections 4.2-SNAPSHOT.
> >
> > Details of changes since version 42 are in the release notes:
> >
> > https://dist.apache.org/repos/dist/dev/commons/commons-
> parent/RELEASE-NOTES.txt
> >
> > Site (not used on commons.apache.org):
> > https://dist.apache.org/repos/dist/dev/commons/commons-
> parent/site.zip
> > revision: 23985
> >
> > Clirr Report (compared to 42): Does not apply.
> >
> > RAT Report:
> > See rat-report.html in zipped site.
> >
> > KEYS:
> >   https://www.apache.org/dist/commons/KEYS
> >
> > This is a LAZY VOTE. Still, please feel free to review the release
> > candidate and vote. This vote will close no sooner that 72 hours from
> > now,
> > i.e. sometime after 21:00 UTC 5-January 2018.
> >
> >   [ ] +1 Release these artifacts [ ] +0 OK, but...
> >   [ ] -0 OK, but really should fix...
> >   [ ] -1 I oppose this release because...
> >
> > Thanks!
> >
> > Gary Gregory Apache Commons V.P.
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

[compress] TarArchiveEntry and Windows drive letter

[Torsten Curdt]

I just found a new issue with compress.

It's the "normalizeFileName" in TarArchiveEntry again.
On Windows it just strips the drive letter

https://github.com/apache/commons-compress/blob/master/src/
main/java/org/apache/commons/compress/archivers/tar/
TarArchiveEntry.java#L1337

which I think is a questionable default behaviour IMO.

   TarArchiveEntry("C:\foo\bar") -> "/foo/bar"
   TarArchiveEntry("D:\foo\bar") -> "/foo/bar"

Is that in line with how other unix tool ports handle things on windows?

cheers,
Torsten

PS: Just for you sebb ;)

Re: [VOTE][LAZY] Release Apache Commons Parent 43 based on RC1

[Jörg Schaible]

Sorry, I've missed the start of the vote, but I've changed the parent in the 
meanwhile to build these artifacts 
in the normal build.

Am Tue, 02 Jan 2018 13:19:48 -0700 schrieb Gary Gregory:

> We have updated plugins and are now ready to use Java 9 to build sites,
> so I would like to release Apache Commons Parent 43.
> 
> Commons Parent 43 RC1 is available for review here:
> https://dist.apache.org/repos/dist/dev/commons/commons-parent/
> revision: 23984
> 
> The tag is here:
> 
> https://svn.apache.org/repos/asf/commons/proper/commons-parent/tags/commons-parent-43-RC1/
> (svn revision 1819873)
> N.B. the SVN revision is required because SVN tags are not
> immutable.
> 
> Maven artifacts are here:
> 
> https://repository.apache.org/content/repositories/orgapachecommons-1301/org/apache/commons/
commons-parent/43/
> 
> These are the Maven artifacts and their hashes
> 
> /org/apache/commons/commons-parent/43/commons-parent-43-src.tar.gz
> (SHA1: dd3bbcc8714a5577e0670cc85ac8731a22046476)
> /org/apache/commons/commons-parent/43/commons-parent-43.pom.asc (SHA1:
> 567c63651185f47250b063de869265f1f95c746a)
> /org/apache/commons/commons-parent/43/commons-parent-43-site.xml.asc
> (SHA1: 1a3bd2240f6acd0c44d736b9e06eca4a903ef195)
> /org/apache/commons/commons-parent/43/commons-parent-43-site.xml (SHA1:
> a76e03e9059f31abc5e3c22f4e857366e689068f)
> /org/apache/commons/commons-parent/43/commons-parent-43-src.zip (SHA1:
> 95c7c17ef5dbdc94670e7153471102e8782ab362)
> /org/apache/commons/commons-parent/43/commons-parent-43-src.zip.asc
> (SHA1: 4f616bfb294a3f427f26dd594c98b4a08b8d0b90)
> /org/apache/commons/commons-parent/43/commons-parent-43.pom (SHA1:
> a24c1d164086ee8f10c11879da2f86f52cbea7fb)
> /org/apache/commons/commons-parent/43/commons-parent-43-src.tar.gz.asc
> (SHA1: 8b9620989da3be2c69e54689ca2d278d66fc25e1)
> 
> I have tested this with:
> 
> 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"
> 
> I also tested building Apache Commons Collections 4.2-SNAPSHOT.
> 
> Details of changes since version 42 are in the release notes:
> 
> https://dist.apache.org/repos/dist/dev/commons/commons-parent/RELEASE-NOTES.txt
> 
> Site (not used on commons.apache.org):
> https://dist.apache.org/repos/dist/dev/commons/commons-parent/site.zip
> revision: 23985
> 
> Clirr Report (compared to 42): Does not apply.
> 
> RAT Report:
> See rat-report.html in zipped site.
> 
> KEYS:
>   https://www.apache.org/dist/commons/KEYS
> 
> This is a LAZY VOTE. Still, please feel free to review the release
> candidate and vote. This vote will close no sooner that 72 hours from
> now,
> i.e. sometime after 21:00 UTC 5-January 2018.
> 
>   [ ] +1 Release these artifacts [ ] +0 OK, but...
>   [ ] -0 OK, but really should fix...
>   [ ] -1 I oppose this release because...
> 
> Thanks!
> 
> Gary Gregory Apache Commons V.P.



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

Re: [compress] AR docs confusion

[sebb]

On 3 January 2018 at 13:34, Torsten Curdt  wrote:
...

> I got one more thing... :)
> I just found a new issue with compress.
> It's the "normalizeFileName" in TarArchiveEntry again. On Windows it just
> strips the drive letter
>
>
> https://github.com/apache/commons-compress/blob/master/src/main/java/org/apache/commons/compress/archivers/tar/TarArchiveEntry.java#L1337
>
> which I think is a questionable default behaviour IMO.
>
>   TarArchiveEntry("C:\foo\bar") -> "/foo/bar"
>   TarArchiveEntry("D:\foo\bar") -> "/foo/bar"
>
> Is that in line with how other unix tool ports handle things on windows?

Please use a separate email (with new subject) for different questions.

> cheers,
> Torsten

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

Re: Hello and possible addition

[Benedikt Ritter]

> Am 03.01.2018 um 15:02 schrieb Otto Fowler :
> 
> Just to check, Java 7 is the required language level?

Yes

> 
> 
> On January 3, 2018 at 07:12:03, Otto Fowler (ottobackwa...@gmail.com) wrote:
> 
> While working on adding some timing functionality to a Metron feature, I
> came across the
> Stopwatch
> 
> class, but found that it didn’t suite my needs.
> 
> What I wanted to do was to create a timing from a top level function in our
> Stellar
> 
> dsl, and have have a group of related timings, such that the end result
> was the overall time of the call, and nested timings of other calls
> executed during the dsl execution of that function. These timings would all
> be named, and have a path for identification and include timing the
> language compiler/execution as well as the function execution itself. It
> would be helpful if they were tagged in some way as well, such that the
> consumer could filter during visitation.
> 
> So I have written StackWatch  to
> provide this functionality, and submitted it in a Metron PR
> .
> 
> From the PR description:
> StackWatch
> 
> A set of utility classes under the new package stellar.common.timing have
> been added. These provide the StackWatch functionality.
> 
> StackWatch provides an abstraction over the Apache Commons StopWatch class
> that allows callers to create multiple named and possibly nested timing
> operations.
> 
> <…>
> 
> This class may be more generally useful to this and other projects, but I
> am not sure where it would live since we wouldn’t want it in common.
> 
> StackWatch uses a combination of Deque and a custom Tree implementation to
> create, start and end timing operations.
> 
> A Visitor pattern is also implemented to allow for retrieving the results
> after the completion of the operation.
> 
> See the StackWatch tests for examples of nested function timings.
> --
> 
> A quick look at the PR and it’s test or the github project ( they are in
> sync ) should show the idea.
> 
> I am sending this to see if this functionality would be appropriate for
> commons in some way. If so, the I can create the jira and submit the pr.
> Even if it is not appropriate, any feedback or pr’s on the github project
> would still be most welcome.
> 
> Thanks for all the work that has made commons so valuable to other Apache
> projects and java developers in general!


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

Re: Hello and possible addition

[Otto Fowler]

Just to check, Java 7 is the required language level?


On January 3, 2018 at 07:12:03, Otto Fowler (ottobackwa...@gmail.com) wrote:

While working on adding some timing functionality to a Metron feature, I
came across the
Stopwatch

 class, but found that it didn’t suite my needs.

What I wanted to do was to create a timing from a top level function in our
Stellar

 dsl, and have have a group of related timings, such that the end result
was the overall time of the call, and nested timings of other calls
executed during the dsl execution of that function. These timings would all
be named, and have a path for identification and include timing the
language compiler/execution as well as the function execution itself. It
would be helpful if they were tagged in some way as well, such that the
consumer could filter during visitation.

So I have written StackWatch  to
provide this functionality, and submitted it in a Metron PR
.

>From the PR description:
StackWatch

A set of utility classes under the new package stellar.common.timing have
been added. These provide the StackWatch functionality.

StackWatch provides an abstraction over the Apache Commons StopWatch class
that allows callers to create multiple named and possibly nested timing
operations.

<…>

This class may be more generally useful to this and other projects, but I
am not sure where it would live since we wouldn’t want it in common.

StackWatch uses a combination of Deque and a custom Tree implementation to
create, start and end timing operations.

A Visitor pattern is also implemented to allow for retrieving the results
after the completion of the operation.

See the StackWatch tests for examples of nested function timings.
--

A quick look at the PR and it’s test or the github project ( they are in
sync ) should show the idea.

I am sending this to see if this functionality would be appropriate for
commons in some way. If so, the I can create the jira and submit the pr.
Even if it is not appropriate, any feedback or pr’s on the github project
would still be most welcome.

Thanks for all the work that has made commons so valuable to other Apache
projects and java developers in general!

Re: [compress] AR docs confusion

[Torsten Curdt]

> >   https://github.com/tcurdt/jdeb/issues/241
>
> [WRT to that issue, LONGFILE_POSIX should be the preferred option if it
> works in debs. LONGFILE_GNU is considered deprecated even by GNU tar.]
>

Thanks! I will give that a try.


> and I have to say I was a little confused about the docs on the AR support
> > in compress
>
> >   https://commons.apache.org/proper/commons-compress/examples.html
>
> >> Commons Compress 1.0 to 1.2 can only read archives using the GNU/SRV4
> >> variant, support for the BSD variant has been added in Commons Compress
> >> 1.3. Commons Compress 1.3 also optionally supports writing archives with
> >> file names longer than 16 characters using the BSD dialect, writing the
> >> SVR4/GNU dialect is not supported.
>
> Please help us improve it. To me (the one who wrote the paragraph) it is
> totally clear. ;-)
>

Happy to :)


Should it explicitly state that all versions of Compress can read and
> write the original format that is limited to 16 char names?
>

I think I'd just add a little table. OK?


> Is this what it means?
>
> > 1.0:
> >   Original: r/w
> >   GNU/SRV4: r
> >   BSD: unsupported
>
> > 1.2:
> >   Original: r/w
> >   GNU/SRV4: r
> >   BSD: unsupported
>
> > 1.3+:
> >   Original: r/w
> >   GNU/SRV4: r
> >   BSD: r/w
>
> Yes.
>

Cool. Thanks!


I got one more thing... :)
I just found a new issue with compress.
It's the "normalizeFileName" in TarArchiveEntry again. On Windows it just
strips the drive letter


https://github.com/apache/commons-compress/blob/master/src/main/java/org/apache/commons/compress/archivers/tar/TarArchiveEntry.java#L1337

which I think is a questionable default behaviour IMO.

  TarArchiveEntry("C:\foo\bar") -> "/foo/bar"
  TarArchiveEntry("D:\foo\bar") -> "/foo/bar"

Is that in line with how other unix tool ports handle things on windows?

cheers,
Torsten

Re: Hello and possible addition

[Otto Fowler]

Thanks,

I will definitely do a PR and get a review.  I am sure review will make it
better.



On January 3, 2018 at 02:06:37, Benedikt Ritter (brit...@apache.org) wrote:

Hello Otto,

> Am 02.01.2018 um 04:28 schrieb Otto Fowler :
>
> Hello Commons,
>
> My name is Otto Fowler ( ottobackwards on github, otto -AT- apache.org at
> apache ), and I’m a PMC member of the Apache Metron
>  project.
>
> While working on adding some timing functionality to a Metron feature, I
> came across the
> Stopwatch
> <
https://commons.apache.org/proper/commons-lang/javadocs/api-release/org/apache/commons/lang3/time/StopWatch.html>

> class, but found that it didn’t suite my needs.
>
> What I wanted to do was to create a timing from a top level function in
our
> Stellar
> <
https://github.com/apache/metron/tree/master/metron-stellar/stellar-common>
> dsl, and have have a group of related timings, such that the end result
was
> the overall time of the call, and nested timings of other calls executed
> during the dsl execution of that function. These timings would all be
> named, and have a path for identification and include timing the language
> compiler/execution as well as the function execution itself. It would be
> helpful if they were tagged in some way as well, such that the consumer
> could filter during visitation.
>
> So I have written StackWatch 

> to provide this functionality, and submitted it in a Metron PR
> .
>
> From the PR description:
> StackWatch
>
> A set of utility classes under the new package stellar.common.timing have
> been added. These provide the StackWatch functionality.
>
> StackWatch provides an abstraction over the Apache Commons StopWatch
class
> that allows callers to create multiple named and possibly nested timing
> operations.
>
> <…>
>
> This class may be more generally useful to this and other projects, but I
> am not sure where it would live since we wouldn’t want it in common.
>
> StackWatch uses a combination of Deque and a custom Tree implementation
to
> create, start and end timing operations.
>
> A Visitor pattern is also implemented to allow for retrieving the results
> after the completion of the operation.
>
> See the StackWatch tests for examples of nested function timings.
> --
>
> A quick look at the PR and it’s test or the github project ( they are in
> sync ) should show the idea.
>
> I am sending this to see if this functionality would be appropriate for
> commons in some way. If so, the I can create the jira and submit the pr.
> Even if it is not appropriate, any feedback or pr’s on the github project
> would still be most welcome.
>
> Thanks for all the work that has made commons so valuable to other Apache
> projects and java developers in general!

This sounds like a useful tool. Nobody objected against adding it to
commons lang, so I don’t see a reason not to include it. All Apache
committers have write access to the commons repositories, so you good go
ahead and add it yourself! But maybe it makes sense to create a Pull
Request against the commons lang GitHub mirror so people are triggered to
have a look :-)

Regards,
Benedikt


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

[GitHub] commons-collections pull request #25: COLLECTIONS-575: Add synchronized queu...

[Xaerxess]

Github user Xaerxess closed the pull request at:

https://github.com/apache/commons-collections/pull/25


---

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

[GitHub] commons-collections pull request #25: COLLECTIONS-575: Add synchronized queu...

[Xaerxess]

Github user Xaerxess closed the pull request at:

https://github.com/apache/commons-collections/pull/25


---

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

[GitHub] commons-collections issue #25: COLLECTIONS-575: Add synchronized queue wrapp...

[Xaerxess]

Github user Xaerxess commented on the issue:

https://github.com/apache/commons-collections/pull/25
  
As per comment in 
[COLLECTIONS-575](https://issues.apache.org/jira/browse/COLLECTIONS-575?focusedCommentId=16309068=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16309068),
 I'm closing this PR (merged in c6dc370abbbf0b487a13bd7f564287a41755bf71).


---

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