Re: [compress] Changes to allow multithreaded creation of zip files

[Stefan Bodewig]

On 2014-12-15, Kristian Rosenvold wrote:

> There is also the issue of determining if the MANIFEST.MF file really
> needs to be the first file in the jar, which puts an interesting
> constraint on the parallelism.

I've found this for Ant which caused us to implement that logic (in 2001):

https://issues.apache.org/bugzilla/show_bug.cgi?id=3287

It seems this is an implementation detail of JarInputStream that Ant and
Maven have learned to cope with.  And it still seems to be true:

http://hg.openjdk.java.net/jdk9/jdk9/jdk/file/9ade71a206f9/src/java.base/share/classes/java/util/jar/JarInputStream.java#l79

I wouldn't be suprised if other tools relied on it as well.

Stefan

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

Re: [text] Update .gitignore, using [lang]'s as basis

[Bruno P. Kinoshita]

Very good idea Sebb!
Done in 1a236bada5163388a3051083fba454b19edc1fb8, thanks!!
Bruno
 
  From: sebb 
 To: Commons Developers List ; Bruno P. Kinoshita 
 
 Sent: Monday, December 15, 2014 8:27 AM
 Subject: Re: [text] Update .gitignore, using [lang]'s as basis
   
I suggest you add a comment to .gitignore to document this decision.



On 14 December 2014 at 20:20, Bruno P. Kinoshita
 wrote:
> Good point Benedikt! Changes reverted! Thank you!
> https://git-wip-us.apache.org/repos/asf?p=commons-text.git;a=commitdiff;h=37c78040
>
>
>
>      From: Benedikt Ritter 
>  To: Commons Developers List ; Bruno P. Kinoshita 
>
>  Sent: Sunday, December 14, 2014 6:10 PM
>  Subject: Re: [text] Update .gitignore, using [lang]'s as basis
>
> 2014-12-14 20:54 GMT+01:00 Bruno P. Kinoshita :
>>
>> +1 Benedikt!
>> Just learned that I can have a global .gitignore :-)
>> For others that didn't know, here's what I read to grok it.
>> https://help.github.com/articles/ignoring-files/
>>
>> @Benedikt, should we delete the .gitignore then or revert to what it was?
>>
>
> I think we should revert it to it's initial state. My opinion is, that a
> project should ignore any files that are used by build tools in the
> project, but nothing more. So in our case we ignore the maven target
> directory and the site-content directory we need for our side build.
>
> Can you do that?
>
> TIA!
> Benedikt
>
>
>> ThanksBurno
>>
>>      From: Benedikt Ritter 
>>  To: Commons Developers List 
>>  Sent: Sunday, December 14, 2014 5:50 PM
>>  Subject: Re: [text] Update .gitignore, using [lang]'s as basis
>>
>> I know we have this in lang's .gitignore. I've added that back when I
>> didn't know git too well. Today I tend to say that this does not belong
>> into a project's .gitignore. Ignores for tooling have to go to your global
>> gitignore imho.
>>
>> WDYT?
>>
>> Benedikt
>>
>>
>>
>> 2014-12-13 4:22 GMT+01:00 :
>> >
>> > Repository: commons-text
>> > Updated Branches:
>> >  refs/heads/master 7570eb016 -> 182154e5b
>> >
>> >
>> > Update .gitignore, using [lang]'s as basis
>> >
>> >
>> > Project: http://git-wip-us.apache.org/repos/asf/commons-text/repo
>> > Commit:
>> > http://git-wip-us.apache.org/repos/asf/commons-text/commit/182154e5
>> > Tree: http://git-wip-us.apache.org/repos/asf/commons-text/tree/182154e5
>> > Diff: http://git-wip-us.apache.org/repos/asf/commons-text/diff/182154e5
>> >
>> > Branch: refs/heads/master
>> > Commit: 182154e5bd4f7f52ffba3728fc03987ff0afda4c
>> > Parents: 7570eb0
>> > Author: Bruno P. Kinoshita 
>> > Authored: Sat Dec 13 01:22:12 2014 -0200
>> > Committer: Bruno P. Kinoshita 
>> > Committed: Sat Dec 13 01:22:12 2014 -0200
>> >
>> > --
>> >  .gitignore | 16 +++-
>> >  1 file changed, 15 insertions(+), 1 deletion(-)
>> > --
>> >
>> >
>> >
>> >
>> http://git-wip-us.apache.org/repos/asf/commons-text/blob/182154e5/.gitignore
>> > --
>> > diff --git a/.gitignore b/.gitignore
>> > index c2b8af5..338a65b 100644
>> > --- a/.gitignore
>> > +++ b/.gitignore
>> > @@ -1,3 +1,17 @@
>> > -target/
>> > +# Maven build files
>> > +target
>> > +*.log
>> > +maven-eclipse.xml
>> > +build.properties
>> >  site-content
>> >
>> > +# IntelliJ IDEA files
>> > +.idea
>> > +.iws
>> > +*.iml
>> > +*.ipr
>> > +
>> > +# Eclipse files
>> > +.settings
>> > +.classpath
>> > +.project
>> >
>> >
>>
>> --
>> http://people.apache.org/~britter/
>> http://www.systemoutprintln.de/
>> http://twitter.com/BenediktRitter
>> http://github.com/britter
>
>
>>
>>
>>
>>
>
> --
> http://people.apache.org/~britter/
> http://www.systemoutprintln.de/
> http://twitter.com/BenediktRitter
> http://github.com/britter
>
>
>


   

Re: [2/4] [math] Merge branch 'master' of https://git-wip-us.apache.org/repos/asf/commons-math

[Phil Steitz]

Sorry for the noise here and I trust this commit did not actually do
anything to master. 

Phil

On 12/15/14 4:49 PM, pste...@apache.org wrote:
> Merge branch 'master' of https://git-wip-us.apache.org/repos/asf/commons-math
>
>
> Project: http://git-wip-us.apache.org/repos/asf/commons-math/repo
> Commit: http://git-wip-us.apache.org/repos/asf/commons-math/commit/37695876
> Tree: http://git-wip-us.apache.org/repos/asf/commons-math/tree/37695876
> Diff: http://git-wip-us.apache.org/repos/asf/commons-math/diff/37695876
>
> Branch: refs/heads/master
> Commit: 376958763cda7cc546e4446243638418fefd1568
> Parents: f80f577 809f0f8
> Author: Phil Steitz 
> Authored: Mon Dec 15 14:58:44 2014 -0700
> Committer: Phil Steitz 
> Committed: Mon Dec 15 14:58:44 2014 -0700
>
> --
>  .../math3/distribution/BetaDistribution.java| 20 +---
>  .../distribution/BinomialDistribution.java  | 13 +++---
>  .../math3/distribution/CauchyDistribution.java  | 16 -
>  .../distribution/ChiSquaredDistribution.java|  7 ++
>  .../distribution/EnumeratedDistribution.java|  7 ++
>  .../EnumeratedIntegerDistribution.java  |  8 +++
>  .../EnumeratedRealDistribution.java |  7 ++
>  .../distribution/ExponentialDistribution.java   | 19 +--
>  .../math3/distribution/FDistribution.java   | 18 --
>  .../math3/distribution/GammaDistribution.java   | 18 --
>  .../distribution/GeometricDistribution.java |  9 ++-
>  .../math3/distribution/GumbelDistribution.java  |  7 ++
>  .../HypergeometricDistribution.java |  9 ++-
>  .../math3/distribution/LaplaceDistribution.java |  7 ++
>  .../math3/distribution/LevyDistribution.java| 19 +++
>  .../distribution/LogNormalDistribution.java | 25 ++--
>  .../distribution/LogisticDistribution.java  |  7 ++
>  .../MixtureMultivariateNormalDistribution.java  | 19 ++-
>  .../MixtureMultivariateRealDistribution.java| 12 --
>  .../MultivariateNormalDistribution.java |  7 ++
>  .../distribution/NakagamiDistribution.java  | 14 +++
>  .../math3/distribution/NormalDistribution.java  | 25 ++--
>  .../math3/distribution/ParetoDistribution.java  | 20 +---
>  .../math3/distribution/PascalDistribution.java  | 11 +++--
>  .../math3/distribution/PoissonDistribution.java | 20 +---
>  .../math3/distribution/TDistribution.java   | 14 +++
>  .../distribution/TriangularDistribution.java|  9 ++-
>  .../UniformIntegerDistribution.java |  7 ++
>  .../distribution/UniformRealDistribution.java   | 14 +++
>  .../math3/distribution/WeibullDistribution.java | 20 +---
>  .../math3/distribution/ZipfDistribution.java|  9 ++-
>  31 files changed, 382 insertions(+), 35 deletions(-)
> --
>
>
>


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

Re: [math] adding a profil for Ekstasi test optimizer

[Phil Steitz]

On 12/15/14 2:50 PM, Luc Maisonobe wrote:
> Hi all,
>
> A fex weeks ago, Milos Gligoric proposed to add his Ekstazi project to
> improve tests runs during development time (see
> ). The rationale is that
> after a first (long) and complete test run, some fingerprints are stored
> and only a subset of test is rerun if only a few classes have changed.
> The project home is .
>
> I have tested it and the latest version worked pretty well for me.
> Typically the latest changes from today between commits 59fe593 and
> 809f0f8 did change 31 files, but in fact most changes were javadoc and
> only one class really changed (LevyDistribution with an added
> constructor). This was detected and only the Levy distribution tests
> were run, which is a huge speedup for a project with as many tests as we
> have in [math].
>
> In order to activate this, the only thing required is to add a profile
> in our pom which will pull a maven plugin. Milos did prepare the patch
> for us here: .
> Once the patch is applied, if we run tests with the profile activated
> (i.e. with -Pekstasi in the maven command line), then tests are run
> according to the profile. The first time it is done all tests are run
> and a .eksazi folder is created to hold the fingerprints (we should
> probably also add it to .gitignore). If we don't use the profile, all
> tests are run as usual.
>
> Accroding to what I have seen on the project homepage, they intend to
> publish the project under Apache V2 license, but the source code seems
> not yet available (anyway, it is a build tool, not a code dependency).
>
> Do you agree with adding this profile to our pom?

I don't have a problem with it.  I rely heavily on -Dtest=... to
limit execution when I am working on stuff, but then before a push I
run the full suite (actually running it now ;). I can see the value
of what you are proposing and might grow to trust it (or at least
use it instead of -Dtest).  So no objections from me.

Phil
>
> best regards,
> Luc
>
> -
> 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

[math] adding a profil for Ekstasi test optimizer

[Luc Maisonobe]

Hi all,

A fex weeks ago, Milos Gligoric proposed to add his Ekstazi project to
improve tests runs during development time (see
). The rationale is that
after a first (long) and complete test run, some fingerprints are stored
and only a subset of test is rerun if only a few classes have changed.
The project home is .

I have tested it and the latest version worked pretty well for me.
Typically the latest changes from today between commits 59fe593 and
809f0f8 did change 31 files, but in fact most changes were javadoc and
only one class really changed (LevyDistribution with an added
constructor). This was detected and only the Levy distribution tests
were run, which is a huge speedup for a project with as many tests as we
have in [math].

In order to activate this, the only thing required is to add a profile
in our pom which will pull a maven plugin. Milos did prepare the patch
for us here: .
Once the patch is applied, if we run tests with the profile activated
(i.e. with -Pekstasi in the maven command line), then tests are run
according to the profile. The first time it is done all tests are run
and a .eksazi folder is created to hold the fingerprints (we should
probably also add it to .gitignore). If we don't use the profile, all
tests are run as usual.

Accroding to what I have seen on the project homepage, they intend to
publish the project under Apache V2 license, but the source code seems
not yet available (anyway, it is a build tool, not a code dependency).

Do you agree with adding this profile to our pom?

best regards,
Luc

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

Re: [VOTE] Release Configuration 2.0-alpha2 based on RC1

[Oliver Heger]

Am 14.12.2014 um 22:45 schrieb Benedikt Ritter:
> Hey Oliver,
> 
> 2014-12-14 22:25 GMT+01:00 Oliver Heger :
>>
>> My own +1.
>>
>> Seems to be no good time for a vote...
>>
> 
> It's holiday time, so... :o)
> 
> I will have some time on Tuesday evening to review this RC. One thing
> already caught my eye: The Clirr report compares with alpha2-SNAPSHOT. Can
> you configure the report to compare with alpha1 instead and update the site?

Done.

Thanks
Oliver

> 
> Benedikt
> 
> 
>>
>> Oliver
>>
>> Am 12.12.2014 um 21:38 schrieb Oliver Heger:
>>> Hi all,
>>>
>>> this is a vote for the second alpha version of [configuration] 2.0 based
>>> on the first release candidate. After the first alpha version, a couple
>>> of enhancement requests have been implemented causing some minor changes
>>> on interfaces. Details are available in the release notes.
>>>
>>> The same disclaimer applies as for the first alpha release:
>>> - This release is according to the "release often and early" mantra. It
>>> is not yet perfect (e.g. there are lots of checkstyle errors, and it is
>>> expected that there are still some API changes). The purpose is to get
>>> feedback from the community regarding the new concepts implemented in
>>> this version. I hope, I have made this clear in the release notes.
>>> - In the past we decided that alpha releases should not go to Maven
>>> central. Therefore, I did not deploy the artifacts to Nexus; only the
>>> distributions were created.
>>>
>>> Configuration 2.0-alpha2 RC1 is available for review here:
>>> https://dist.apache.org/repos/dist/dev/commons/configuration
>>> (revision 7395)
>>>
>>> Details of changes since 1.10 and the first alpha version are in the
>>> release notes:
>>>
>>>
>> https://dist.apache.org/repos/dist/dev/commons/configuration/RELEASE-NOTES.txt
>>>
>>>
>> http://people.apache.org/~oheger/configuration-2.0-alpha2-rc1/changes-report.html
>>>
>>> Here is the tag:
>>>
>>>
>> http://svn.apache.org/repos/asf/commons/proper/configuration/tags/CONFIGURATION_2_0_alpha2_RC1
>>> (revision 1644517)
>>>
>>> Site:
>>>http://people.apache.org/~oheger/configuration-2.0-alpha2-rc1/
>>> (note some links in the menu for version 1.10 are not yet working)
>>>
>>> KEYS:
>>>   http://www.apache.org/dist/commons/KEYS
>>>
>>> Please review the release candidate and vote.
>>> This vote will close no sooner than 72 hours from now, i.e. after 2000
>>> GMT 15-December 2014
>>>
>>>   [ ] +1 Release these artifacts
>>>   [ ] +0 OK, but...
>>>   [ ] -0 OK, but really should fix...
>>>   [ ] -1 I oppose this release because...
>>>
>>> Thanks!
>>> Oliver
>>>
>>> -
>>> 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: Separate mailing list for CMS buildbot commits?

[sebb]

This has now been implemented.

Buildbot commit mails should now end up in

notifications@commons.a.o

rather than

commits@c.a.o

If there are any problems, the original JIRA was INFRA-8866

Hopefully commits@ will now be a bit easier to review.


On 4 December 2014 at 13:28, Emmanuel Bourg  wrote:
> Le 04/12/2014 12:36, sebb a écrit :
>
>> Thoughts?
>
> +1, Good idea
>
> Emmanuel Bourg
>
>
> -
> 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

Missing commit mails have been regenerated by Infra

[sebb]

Infra recently regenerated all the SVN commit mails that may have been
lost during the SVN outage about 10 days ago.

There are some duplicates, but all the previously missing ones are now
accounted for.

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

Re: [compress] Changes to allow multithreaded creation of zip files

[sebb]

On 15 December 2014 at 17:47, Kristian Rosenvold  wrote:
> 2014-12-15 17:39 GMT+01:00 Stefan Bodewig :
>> On 2014-12-15, Kristian Rosenvold wrote:
>>
>>> There is also the issue of determining if the MANIFEST.MF file really
>>> needs to be the first file in the jar, which puts an interesting
>>> constraint on the parallelism. I have been unable to understand if the
>>> jar spec actually requires this or if it's just stuff from the old
>>> days.
>>
>> AFAIR the jar spec does not require it, but many tools do - maybe even
>> java.util.jar, but I'm not sure.
>>
>> When distinguishing a jar from a "normal" zip most tools require the
>> "jar marker" to be the first zip extra field of the first entry - and
>> IIRC some tools we've come across required this entry to be the META-INF
>> directory.
>
> Some of our code in maven goes through some serious hoops to preserve
> this, so I've been prepared for this although I really don't like it
> :) In the context of parallel streams it just means there'll be a
> "root" stream which will be the start of the archive. It might even
> end up being more efficient than our current algorithm, which scans
> the input filenames twice to determine if there is manifest-worthy
> content.
>
> My git repo now has a first *crude* working version of the code with a
> passing testcase, which means I can merge multiple streams. The
> hacking continues :)

Just wondering if this feature might help with another recent request,
which was to allow entries to be copied from one archive to another
without having to unpack/repack them?
Seems to me that the parallel streams are presumably already
compressed, so the "only" part that is missing is extraction of the
compressed data from the input zip.
Of course, that may be the hardest part.
Just a thought in case it affects the merge API.

> K
>
> -
> 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] Changes to allow multithreaded creation of zip files

[Kristian Rosenvold]

2014-12-15 17:39 GMT+01:00 Stefan Bodewig :
> On 2014-12-15, Kristian Rosenvold wrote:
>
>> There is also the issue of determining if the MANIFEST.MF file really
>> needs to be the first file in the jar, which puts an interesting
>> constraint on the parallelism. I have been unable to understand if the
>> jar spec actually requires this or if it's just stuff from the old
>> days.
>
> AFAIR the jar spec does not require it, but many tools do - maybe even
> java.util.jar, but I'm not sure.
>
> When distinguishing a jar from a "normal" zip most tools require the
> "jar marker" to be the first zip extra field of the first entry - and
> IIRC some tools we've come across required this entry to be the META-INF
> directory.

Some of our code in maven goes through some serious hoops to preserve
this, so I've been prepared for this although I really don't like it
:) In the context of parallel streams it just means there'll be a
"root" stream which will be the start of the archive. It might even
end up being more efficient than our current algorithm, which scans
the input filenames twice to determine if there is manifest-worthy
content.

My git repo now has a first *crude* working version of the code with a
passing testcase, which means I can merge multiple streams. The
hacking continues :)

K

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

Re: [compress] Changes to allow multithreaded creation of zip files

[Stefan Bodewig]

On 2014-12-15, Kristian Rosenvold wrote:

> There is also the issue of determining if the MANIFEST.MF file really
> needs to be the first file in the jar, which puts an interesting
> constraint on the parallelism. I have been unable to understand if the
> jar spec actually requires this or if it's just stuff from the old
> days.

AFAIR the jar spec does not require it, but many tools do - maybe even
java.util.jar, but I'm not sure.

When distinguishing a jar from a "normal" zip most tools require the
"jar marker" to be the first zip extra field of the first entry - and
IIRC some tools we've come across required this entry to be the META-INF
directory.

Stefan

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

Re: [math] javadoc warnings

[Gilles]

On Mon, 15 Dec 2014 08:40:27 -0700, Phil Steitz wrote:

Cleaning up javadoc for the Bessel stuff I am readying for commit, I
noticed these:

[WARNING]

/Users/psteitz/math-git/commons-math/src/main/java/org/apache/commons/math3/analysis/interpolation/BicubicInterpolator.java:42:
warning - Tag @link: missing '#': "isValidPoint(double,double)"
[WARNING]

/Users/psteitz/math-git/commons-math/src/main/java/org/apache/commons/math3/analysis/interpolation/BicubicInterpolator.java:42:
warning - Tag @link: can't find isValidPoint(double,double) in
org.apache.commons.math3.analysis.interpolation.BicubicInterpolator
[WARNING]

/Users/psteitz/math-git/commons-math/src/main/java/org/apache/commons/math3/fitting/SimpleCurveFitter.java:70:
warning - Tag @link: reference not found: ParameterGuesser
[WARNING]

/Users/psteitz/math-git/commons-math/src/main/java/org/apache/commons/math3/geometry/partitioning/AbstractRegion.java:310:
warning - Tag @link: reference not found: Location#INSIDE
[WARNING]

/Users/psteitz/math-git/commons-math/src/main/java/org/apache/commons/math3/geometry/partitioning/AbstractRegion.java:310:
warning - Tag @link: reference not found: Location#OUTSIDE
[WARNING]

/Users/psteitz/math-git/commons-math/src/main/java/org/apache/commons/math3/geometry/partitioning/AbstractRegion.java:310:
warning - Tag @link: reference not found: Location#BOUNDARY


Fixed.

Gilles


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

[ANNOUNCEMENT] Apache Commons grants write access to all ASF committers

[Benedikt Ritter]

Dear fellow committers,

The Apache Commons Team is pleased to announce that write access to the
Apache Commons Subversion and Git repositories has been granted to all ASF
committers.

Apache Commons is an Apache project focused on all aspects of reusable Java
components. As such, the components maintained by the Apache Commons project
may be of interest to a variety of other Apache projects.

The Apache Commons community would like to invite you to share and maintain
useful code.

While Apache Commons is a Commit-Then-Review community, we would consider
it polite and helpful for contributors to announce their intentions and
plans on the dev mailing list [1] before committing code.


Have fun,

Benedikt Ritter,
on behalf of the Apache Commons Community

[1] http://commons.apache.org/mail-lists.html

-- 
http://people.apache.org/~britter/
http://www.systemoutprintln.de/
http://twitter.com/BenediktRitter
http://github.com/britter

[math] javadoc warnings

[Phil Steitz]

Cleaning up javadoc for the Bessel stuff I am readying for commit, I
noticed these:

[WARNING]
/Users/psteitz/math-git/commons-math/src/main/java/org/apache/commons/math3/analysis/interpolation/BicubicInterpolator.java:42:
warning - Tag @link: missing '#': "isValidPoint(double,double)"
[WARNING]
/Users/psteitz/math-git/commons-math/src/main/java/org/apache/commons/math3/analysis/interpolation/BicubicInterpolator.java:42:
warning - Tag @link: can't find isValidPoint(double,double) in
org.apache.commons.math3.analysis.interpolation.BicubicInterpolator
[WARNING]
/Users/psteitz/math-git/commons-math/src/main/java/org/apache/commons/math3/fitting/SimpleCurveFitter.java:70:
warning - Tag @link: reference not found: ParameterGuesser
[WARNING]
/Users/psteitz/math-git/commons-math/src/main/java/org/apache/commons/math3/geometry/partitioning/AbstractRegion.java:310:
warning - Tag @link: reference not found: Location#INSIDE
[WARNING]
/Users/psteitz/math-git/commons-math/src/main/java/org/apache/commons/math3/geometry/partitioning/AbstractRegion.java:310:
warning - Tag @link: reference not found: Location#OUTSIDE
[WARNING]
/Users/psteitz/math-git/commons-math/src/main/java/org/apache/commons/math3/geometry/partitioning/AbstractRegion.java:310:
warning - Tag @link: reference not found: Location#BOUNDARY

Phil

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

Re: [Math] MATH-1180

[Gilles]

On Mon, 15 Dec 2014 11:43:22 +0100, Gilles wrote:

On Sun, 14 Dec 2014 19:15:08 -0700, Phil Steitz wrote:

On 12/14/14 5:10 PM, Gilles wrote:

Hi.

Any objection to my adding this:
 https://issues.apache.org/jira/browse/MATH-1180
?


If you have use for something like that in [math], I am fine with
it, but it should be called something else.


It's just happened that I could use this generalization
of something already in Commons Math.


 The name "natural" for
the existing method is "natural" (pun intended) since it returns an
array representing the argument - e.g., natural(5) is {0, .., 4}
which *is* 5 in set-theoretic terms.



How about "sequence"?

Perhaps we could even already further generalize to
  sequence(int size, int start, int stride)

OK?


I've committed it already, to be shipped with 3.4. :-)

Gilles



P.S. The "natural" method would still be defined as "sequence(n, 0, 
1)".





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

Re: [compress] Changes to allow multithreaded creation of zip files

[Kristian Rosenvold]

As far as I understand there will be no thread pools coming into
commons-compress, this has to be done by the caller. The caller will
basically in some shape or another keep at ThreadLocal<
ZipArchiveOutputStream> that will receive entries for each thread.
When everyone is finished they will be merged (or maybe just appended
to the "one" ZipArchiveOutputStream that is "master" and already
pointing to the final file).

All c-compress needs to do is have support for transferring already
compressed content from one outputstream to another, probably by
reversing the outputstream back to an inputstream and appending all
the entries to a different outputstream through regular iteration.

There is also the issue of determining if the MANIFEST.MF file really
needs to be the first file in the jar, which puts an interesting
constraint on the parallelism. I have been unable to understand if the
jar spec actually requires this or if it's just stuff from the old
days.

In maven we use plexus-archiver, which allows higher-level creation of
zip archives (add a bunch of "source" specifications to archiver and
say "execute" and you get your zip/tar files etc). The executor will
be in plexus-archiver for our code. I've been tweaking this code for
some time now with an eye to parallelize the whole thing; som now I'm
moving for the kill :)

Kristian





2014-12-15 13:06 GMT+01:00 Gary Gregory :
> Sounds cool. Do you plan on allowing  an executor service to be passed in to 
> some APIs?
>
> Gary
>
>  Original message From: Kristian Rosenvold 
>  Date:12/15/2014  02:49  (GMT-05:00) 
> To: Commons Developers List  
> Cc:  Subject: [compress] Changes to allow multithreaded 
> creation of zip files 
> I just thought I'd let you know I'm working on changes to allow
> multiple threads to output to different ZipArchiveOutputStream
> instances (backed  by commons-io DeferredFileOutputStream or similar)
> and then stitch the results back together as a single Zip file. I'm
> currently just researching the scope of the required changes (which
> seems to be fairly small) and working on test cases. I expect to be
> working with this for a few weeks, my code can be seen at
> https://github.com/krosenvold/commons-compress
>
> (And I'll be implementing this in maven once it's good).
>
> Kristian
>
> -
> 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] Changes to allow multithreaded creation of zip files

[Gary Gregory]

Sounds cool. Do you plan on allowing  an executor service to be passed in to 
some APIs?

Gary 

 Original message From: Kristian Rosenvold 
 Date:12/15/2014  02:49  (GMT-05:00) 
To: Commons Developers List  Cc:  
Subject: [compress] Changes to allow multithreaded creation of zip 
files 
I just thought I'd let you know I'm working on changes to allow
multiple threads to output to different ZipArchiveOutputStream
instances (backed  by commons-io DeferredFileOutputStream or similar)
and then stitch the results back together as a single Zip file. I'm
currently just researching the scope of the required changes (which
seems to be fairly small) and working on test cases. I expect to be
working with this for a few weeks, my code can be seen at
https://github.com/krosenvold/commons-compress

(And I'll be implementing this in maven once it's good).

Kristian

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

Re: [Math] MATH-1180

[Gilles]

On Sun, 14 Dec 2014 19:15:08 -0700, Phil Steitz wrote:

On 12/14/14 5:10 PM, Gilles wrote:

Hi.

Any objection to my adding this:
 https://issues.apache.org/jira/browse/MATH-1180
?


If you have use for something like that in [math], I am fine with
it, but it should be called something else.


It's just happened that I could use this generalization
of something already in Commons Math.


 The name "natural" for
the existing method is "natural" (pun intended) since it returns an
array representing the argument - e.g., natural(5) is {0, .., 4}
which *is* 5 in set-theoretic terms.



How about "sequence"?

Perhaps we could even already further generalize to
  sequence(int size, int start, int stride)

OK?


Gilles

P.S. The "natural" method would still be defined as "sequence(n, 0, 
1)".



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

Re: [compress] Changes to allow multithreaded creation of zip files

[Emmanuel Bourg]

Le 15/12/2014 11:36, Stefan Bodewig a écrit :

> [as an aside, maybe we should think about moving Compress to git]

+1

Emmanuel


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

Re: [compress] Changes to allow multithreaded creation of zip files

[Stefan Bodewig]

On 2014-12-15, Kristian Rosenvold wrote:

> I just thought I'd let you know I'm working on changes to allow
> multiple threads to output to different ZipArchiveOutputStream
> instances (backed  by commons-io DeferredFileOutputStream or similar)
> and then stitch the results back together as a single Zip file. I'm
> currently just researching the scope of the required changes (which
> seems to be fairly small) and working on test cases.

Great, I'm looking forward to them.

> I expect to be working with this for a few weeks, my code can be seen
> at https://github.com/krosenvold/commons-compress

[as an aside, maybe we should think about moving Compress to git]

> (And I'll be implementing this in maven once it's good).

AFAIU Damjan would like to see a new Compress release to move Imaging
forward; I'd volunteer to manage a new release after we've integrated
and tested your changes.

Stefan

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

Re: [text] Update .gitignore, using [lang]'s as basis

[sebb]

I suggest you add a comment to .gitignore to document this decision.

On 14 December 2014 at 20:20, Bruno P. Kinoshita
 wrote:
> Good point Benedikt! Changes reverted! Thank you!
> https://git-wip-us.apache.org/repos/asf?p=commons-text.git;a=commitdiff;h=37c78040
>
>
>
>   From: Benedikt Ritter 
>  To: Commons Developers List ; Bruno P. Kinoshita 
> 
>  Sent: Sunday, December 14, 2014 6:10 PM
>  Subject: Re: [text] Update .gitignore, using [lang]'s as basis
>
> 2014-12-14 20:54 GMT+01:00 Bruno P. Kinoshita :
>>
>> +1 Benedikt!
>> Just learned that I can have a global .gitignore :-)
>> For others that didn't know, here's what I read to grok it.
>> https://help.github.com/articles/ignoring-files/
>>
>> @Benedikt, should we delete the .gitignore then or revert to what it was?
>>
>
> I think we should revert it to it's initial state. My opinion is, that a
> project should ignore any files that are used by build tools in the
> project, but nothing more. So in our case we ignore the maven target
> directory and the site-content directory we need for our side build.
>
> Can you do that?
>
> TIA!
> Benedikt
>
>
>> ThanksBurno
>>
>>  From: Benedikt Ritter 
>>  To: Commons Developers List 
>>  Sent: Sunday, December 14, 2014 5:50 PM
>>  Subject: Re: [text] Update .gitignore, using [lang]'s as basis
>>
>> I know we have this in lang's .gitignore. I've added that back when I
>> didn't know git too well. Today I tend to say that this does not belong
>> into a project's .gitignore. Ignores for tooling have to go to your global
>> gitignore imho.
>>
>> WDYT?
>>
>> Benedikt
>>
>>
>>
>> 2014-12-13 4:22 GMT+01:00 :
>> >
>> > Repository: commons-text
>> > Updated Branches:
>> >  refs/heads/master 7570eb016 -> 182154e5b
>> >
>> >
>> > Update .gitignore, using [lang]'s as basis
>> >
>> >
>> > Project: http://git-wip-us.apache.org/repos/asf/commons-text/repo
>> > Commit:
>> > http://git-wip-us.apache.org/repos/asf/commons-text/commit/182154e5
>> > Tree: http://git-wip-us.apache.org/repos/asf/commons-text/tree/182154e5
>> > Diff: http://git-wip-us.apache.org/repos/asf/commons-text/diff/182154e5
>> >
>> > Branch: refs/heads/master
>> > Commit: 182154e5bd4f7f52ffba3728fc03987ff0afda4c
>> > Parents: 7570eb0
>> > Author: Bruno P. Kinoshita 
>> > Authored: Sat Dec 13 01:22:12 2014 -0200
>> > Committer: Bruno P. Kinoshita 
>> > Committed: Sat Dec 13 01:22:12 2014 -0200
>> >
>> > --
>> >  .gitignore | 16 +++-
>> >  1 file changed, 15 insertions(+), 1 deletion(-)
>> > --
>> >
>> >
>> >
>> >
>> http://git-wip-us.apache.org/repos/asf/commons-text/blob/182154e5/.gitignore
>> > --
>> > diff --git a/.gitignore b/.gitignore
>> > index c2b8af5..338a65b 100644
>> > --- a/.gitignore
>> > +++ b/.gitignore
>> > @@ -1,3 +1,17 @@
>> > -target/
>> > +# Maven build files
>> > +target
>> > +*.log
>> > +maven-eclipse.xml
>> > +build.properties
>> >  site-content
>> >
>> > +# IntelliJ IDEA files
>> > +.idea
>> > +.iws
>> > +*.iml
>> > +*.ipr
>> > +
>> > +# Eclipse files
>> > +.settings
>> > +.classpath
>> > +.project
>> >
>> >
>>
>> --
>> http://people.apache.org/~britter/
>> http://www.systemoutprintln.de/
>> http://twitter.com/BenediktRitter
>> http://github.com/britter
>
>
>>
>>
>>
>>
>
> --
> http://people.apache.org/~britter/
> http://www.systemoutprintln.de/
> http://twitter.com/BenediktRitter
> http://github.com/britter
>
>
>

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

Re: commons-parent maven pom highly broken?

[sebb]

On 13 December 2014 at 18:22, Mark Struberg  wrote:
> Just file an JIRA if something doesn't work and you are done.

Not sure what you are referring to there, but if it was my comments
about ASF pom bugs, I did file bugs, but as I recall, nothing happened
for over a year.

>
>> Releasing is tedious because Maven does not really support non-Maven
>> release directories (i.e. www.apache.org/dist/commons)
> This is totally non-ASF style. Just use the standard stuff like every other 
> ASF project and you are again done.

That's all well and good, but if the output is not correct (as it was
not) then that is not helpful.

>
>> Until very recently the ASF parent pom was broken, and with no sign of
>> any fixes.To me'not fixing anything' would mean that all the apache-parent 
>> releases would be useless?
>
> Or you just did not check it?

Again, not sure what this is responding to.

>
>> There are stil issues with LICENSE and NOTICE, because the
>> automatically created ones are not always correct.
> The rule is straight forward. If you provide your own one then it will be 
> used. If not, then a standard one will be packaged.

>
>> The Commons Pom includes a lot of common setup that would otherwise
>> have to be added to each component's parent pom.
> And that would be? Most of the stuff is taken over from the old ant builds 
> and nowadays do not reflect reality anymore.
>

Standard reports
Standard Manifest settings
Mailing list names
N&L files in test & javadoc jars
Enforcer
Fixing bug in Felix
Standardise JIRA and changes report
etc.

As I already wrote, there is a lot of common Commons stuff that needs
to go somewhere.
It cannot go in the ASF pom.

Then there are utility optional profiles:
- jacoco
- cobertura
- java-1.x - allows build/test with different Java from default used
to run Maven
- test-deploy
- release-notes

Of course all of these could be deployed in component poms on an
as-needed basis.
But that rather goes against the spirit of re-usable code.


>> There are various other additional optional features in the Commons
>> pom which are useful for testing.
> what more than testng OR junit (depending on the project) + maybe mock tools 
> do you need?
>

Not Unit testing - see above.

>
>> I think the CP pom works fine for single module projects.
>> I'm not sure about multimodule projects, but is the ASF pom any better?
> Well, most of todays projects are multi-module ones.

That is not true of Commons.
Which is probably why there are some issues with such components.

> And this works perfectly fine with the ASF parent pom.
>

Are you sure?
Have you checked that all the generated artifacts are complete?

The Commons Parent pom is intended to abstract common functions which
would otherwise be needed in all Commons components.
If there are aspects of it that are not working, file JIRAs that
clearly state what the problem is:
- what you tried
- what happened
- what you expected to happen

>
>
> LieGrue,
> strub
>
>
>
>
>> On Saturday, 13 December 2014, 18:41, sebb  wrote:
>> > On 13 December 2014 at 12:26, Mark Struberg  wrote:
>>>  Hi!
>>>
>>>  I've never seen any other ASF project where it is such a torture to
>> release.
>>>  This is partly because the quality level is really high, but a big part of
>> it is that we don't have a mature parent pom.
>>
>> Sorry, but I don't think that is at all relevant.
>> Releasing is tedious because Maven does not really support non-Maven
>> release directories (i.e. www.apache.org/dist/commons) so work-rounds
>> are needed.
>> This is true whatever the parent pom is used.
>>
>> It's partly also that Maven does some things well, but when
>> adjustments are needed, it can be all but impossible to work out how
>> to coax it to do what's needed.
>>
>>>
>>>  I have no clue why we don't just use the common apache parent pom.
>> I've NEVER experienced such issues like missing NOTICE and LICENSE with it.
>> It's really much more solid than our own one.
>>
>> Until very recently the ASF parent pom was broken, and with no sign of
>> any fixes.
>> For example, it did not allow override of the compiler plugin version,
>> and there were a few other issues with it.
>>
>> There are stil issues with LICENSE and NOTICE, because the
>> automatically created ones are not always correct.
>> I'm not sure it creates the appropriate source and javadoc jars either.
>>
>> And it does not create decent manifests.
>>
>> The Commons Pom includes a lot of common setup that would otherwise
>> have to be added to each component's parent pom.
>> That is not an efficient way of proceeding.
>>
>> There are various other additional optional features in the Commons
>> pom which are useful for testing.
>>
>> I think the CP pom works fine for single module projects.
>> I'm not sure about multimodule projects, but is the ASF pom any better?
>>
>> Rather than raise unsubstantiated criticisms of the CP pom, file bugs
>> for any problems and/or try fixing them.
>>
>>
>>>  LieGrue,
>>>  strub
>>>
>>>  

Re: [Math] MATH-1180

[Luc Maisonobe]

Le 15/12/2014 03:15, Phil Steitz a écrit :
> On 12/14/14 5:10 PM, Gilles wrote:
>> Hi.
>>
>> Any objection to my adding this:
>>  https://issues.apache.org/jira/browse/MATH-1180
>> ?

I'm fine with any such methods.

best regards,
Luc

> 
> If you have use for something like that in [math], I am fine with
> it, but it should be called something else.  The name "natural" for
> the existing method is "natural" (pun intended) since it returns an
> array representing the argument - e.g., natural(5) is {0, .., 4}
> which *is* 5 in set-theoretic terms.
> 
> Phil
>>
>> Gilles
>>
>>
>> -
>> 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: [DRAFT][ANNOUNCE] Apache Commons grants write access to all ASF committers

[Duncan Jones]

On 15 December 2014 at 08:25, Benedikt Ritter  wrote:
> 2014-12-15 4:02 GMT+01:00 Gary Gregory :
>>
>> Nice feedback all around. Here is a version that includes some of these
>> thoughts:
>> --
>>
>> Dear fellow committers,
>>
>> The Apache Commons Team is pleased to announce that write access to the
>> Apache Commons Subversion and Git repositories has been granted to all ASF
>> committers.
>>
>> Apache Commons is an Apache project focused on all aspects of reusable Java
>> components. As such, the components maintained by the Apache Commons
>> project
>> may be of interest to a variety of other Apache projects.
>>
>> The Apache Commons community would like to invite you to share and maintain
>> useful code.
>>
>> While Apache Commons is a Commit-Then-Review community, we would consider
>> it polite and helpful for contributors to announce their intentions and
>> plans on the dev mailing list before committing code.
>>
>>
>> Have fun,
>>
>> The Apache Commons Community.
>> --
>> Gary
>>
>
> Very nice! I'll send the announcement tonight.

+1 I think this is an excellent idea.


>
> Benedikt
>
>
>>
>>
>> On Sun, Dec 14, 2014 at 3:13 PM, Gilles 
>> wrote:
>> >
>> > On Sun, 14 Dec 2014 12:57:02 -0700, Phil Steitz wrote:
>> >
>> >> On 12/14/14 12:49 PM, Gilles wrote:
>> >>
>> >>> On Sun, 14 Dec 2014 20:28:37 +0100, Benedikt Ritter wrote:
>> >>>
>>  Hi all,
>> 
>>  here is my draft for the announcement to committers@
>> 
>>  Regards,
>>  Benedikt
>> 
>>  --
>> 
>>  Dear fellow committers,
>> 
>>  the Apache Commons Team is pleased to announce that write access
>>  to the
>>  Apache Commons SVN and git repositories has been granted to all ASF
>>  committers.
>> 
>>  Apache Commons is an Apache project focused on all aspects of
>>  reusable Java
>>  components. As such the components maintained by the Apache
>>  Commons project
>>  may be of interest for a variety of other Apache projects.
>> 
>>  The Apache Commons community would like to invite you to share
>>  useful code
>>  which may be useful for other projects as well.
>>  Please let us know before you start working on the code, by
>>  writing a short
>>  mail to the dev mailing list [1].
>> 
>> >>>
>> >>> I'd be more careful (better safe than sorry) and add something like:
>> >>>
>> >>> [...] before committing code, consensus about the modifications
>> >>> should be
>> >>> reached on the dev ML.
>> >>>
>> >>
>> >> We are CTR so that is not necessary.  We might just want to refer to
>> >> and update [1].
>> >>
>> >
>> > IMHO, it is more efficient to discuss first (with the assumption that
>> > no objection amounts to green light).
>> >
>> >  The upshot there is that before starting to commit
>> >> to a component, it is polite to announce intention to start working
>> >> on it and let people know what you have in mind.
>> >>
>> >
>> > In the same vein, it is more polite to ask first whether there is an
>> > objection).
>> > It is also nicer, for all parties, to not have to veto a commit.
>> >
>> >
>> > Gilles
>> >
>> >
>> >
>> >  Phil
>> >>
>> >> [1] http://wiki.apache.org/commons/CommonsEtiquette
>> >>
>> >>>
>> >>>
>> >>> Thanks,
>> >>> Gilles
>> >>>
>> >>>
>>  Benedikt Ritter,
>>  on behalf of the Apache Commons community
>> 
>>  [1] http://commons.apache.org/mail-lists.html
>> 
>> >>>
>> >>>
>> >>>
>> >>> -
>> >>> 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
>> >
>> >
>>
>> --
>> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
>> Java Persistence with Hibernate, Second Edition
>> 
>> JUnit in Action, Second Edition 
>> Spring Batch in Action 
>> Blog: http://garygregory.wordpress.com
>> Home: http://garygregory.com/
>> Tweet! http://twitter.com/GaryGregory
>>
>
>
> --
> http://people.apache.org/~britter/
> http://www.systemoutprintln.de/
> http://twitter.com/BenediktRitter
> http://github.com/britter

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

Re: [DRAFT][ANNOUNCE] Apache Commons grants write access to all ASF committers

[Benedikt Ritter]

2014-12-15 4:02 GMT+01:00 Gary Gregory :
>
> Nice feedback all around. Here is a version that includes some of these
> thoughts:
> --
>
> Dear fellow committers,
>
> The Apache Commons Team is pleased to announce that write access to the
> Apache Commons Subversion and Git repositories has been granted to all ASF
> committers.
>
> Apache Commons is an Apache project focused on all aspects of reusable Java
> components. As such, the components maintained by the Apache Commons
> project
> may be of interest to a variety of other Apache projects.
>
> The Apache Commons community would like to invite you to share and maintain
> useful code.
>
> While Apache Commons is a Commit-Then-Review community, we would consider
> it polite and helpful for contributors to announce their intentions and
> plans on the dev mailing list before committing code.
>
>
> Have fun,
>
> The Apache Commons Community.
> --
> Gary
>

Very nice! I'll send the announcement tonight.

Benedikt


>
>
> On Sun, Dec 14, 2014 at 3:13 PM, Gilles 
> wrote:
> >
> > On Sun, 14 Dec 2014 12:57:02 -0700, Phil Steitz wrote:
> >
> >> On 12/14/14 12:49 PM, Gilles wrote:
> >>
> >>> On Sun, 14 Dec 2014 20:28:37 +0100, Benedikt Ritter wrote:
> >>>
>  Hi all,
> 
>  here is my draft for the announcement to committers@
> 
>  Regards,
>  Benedikt
> 
>  --
> 
>  Dear fellow committers,
> 
>  the Apache Commons Team is pleased to announce that write access
>  to the
>  Apache Commons SVN and git repositories has been granted to all ASF
>  committers.
> 
>  Apache Commons is an Apache project focused on all aspects of
>  reusable Java
>  components. As such the components maintained by the Apache
>  Commons project
>  may be of interest for a variety of other Apache projects.
> 
>  The Apache Commons community would like to invite you to share
>  useful code
>  which may be useful for other projects as well.
>  Please let us know before you start working on the code, by
>  writing a short
>  mail to the dev mailing list [1].
> 
> >>>
> >>> I'd be more careful (better safe than sorry) and add something like:
> >>>
> >>> [...] before committing code, consensus about the modifications
> >>> should be
> >>> reached on the dev ML.
> >>>
> >>
> >> We are CTR so that is not necessary.  We might just want to refer to
> >> and update [1].
> >>
> >
> > IMHO, it is more efficient to discuss first (with the assumption that
> > no objection amounts to green light).
> >
> >  The upshot there is that before starting to commit
> >> to a component, it is polite to announce intention to start working
> >> on it and let people know what you have in mind.
> >>
> >
> > In the same vein, it is more polite to ask first whether there is an
> > objection).
> > It is also nicer, for all parties, to not have to veto a commit.
> >
> >
> > Gilles
> >
> >
> >
> >  Phil
> >>
> >> [1] http://wiki.apache.org/commons/CommonsEtiquette
> >>
> >>>
> >>>
> >>> Thanks,
> >>> Gilles
> >>>
> >>>
>  Benedikt Ritter,
>  on behalf of the Apache Commons community
> 
>  [1] http://commons.apache.org/mail-lists.html
> 
> >>>
> >>>
> >>>
> >>> -
> >>> 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
> >
> >
>
> --
> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
> Java Persistence with Hibernate, Second Edition
> 
> JUnit in Action, Second Edition 
> Spring Batch in Action 
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory
>


-- 
http://people.apache.org/~britter/
http://www.systemoutprintln.de/
http://twitter.com/BenediktRitter
http://github.com/britter

Re: [compress] Changes to allow multithreaded creation of zip files

[Benedikt Ritter]

Hello Kristian,

2014-12-15 8:49 GMT+01:00 Kristian Rosenvold :
>
> I just thought I'd let you know I'm working on changes to allow
> multiple threads to output to different ZipArchiveOutputStream
> instances (backed  by commons-io DeferredFileOutputStream or similar)
> and then stitch the results back together as a single Zip file. I'm
> currently just researching the scope of the required changes (which
> seems to be fairly small) and working on test cases. I expect to be
> working with this for a few weeks, my code can be seen at
> https://github.com/krosenvold/commons-compress
>
> (And I'll be implementing this in maven once it's good).
>

Very nice! Can you please also file a jira for your changes?

TIA!
Benedikt


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

-- 
http://people.apache.org/~britter/
http://www.systemoutprintln.de/
http://twitter.com/BenediktRitter
http://github.com/britter