Re: [VOTE] Release Compress 1.13 based on RC1

[Jörg Schaible]

+1

Builds successfully from source tarball with my compiler zoo except Java 9. 
However, this is currently such a moving target, therefore I consider its 
report more as a heads-up:

 %< ==
Failed tests: 
  X5455_ExtendedTimestampTest.testSampleFile:185 
expected:<[2105-01-01/00:00:02] +> but was:<[1968-11-25/02:31:45] +>
Tests in error: 
  SevenZNativeHeapTest.initializationError » Objenesis 
java.lang.reflect.Invocat...
 %< ==
$ mvn -version
Apache Maven 3.3.9 (bb52d8502b132ec0a5a3f4c09453c07478323dc5; 
2015-11-10T17:41:47+01:00)
Maven home: /usr/share/maven-bin-3.3
Java version: 9-ea, vendor: Oracle Corporation
Java home: /opt/oracle-jdk-bin-1.9.0.0_beta116
Default locale: en_US, platform encoding: UTF-8
OS name: "linux", version: "4.4.39-gentoo", arch: "amd64", family: "unix"
 %< ==

Cheers,
Jörg

Stefan Bodewig wrote:

> The Release Candidate is available for review at:
>   https://dist.apache.org/repos/dist/dev/commons/compress/
>   (svn revision 17569)
> 
> Maven artifacts are here:
>   
https://repository.apache.org/content/repositories/orgapachecommons-1231/org/apache/commons/commons-compress/1.13/
> 
> These are the Maven artifacts and their hashes
> 
> d8e592b12f192a77c59d52ba7936279c04f6ff1a  commons-compress-1.13.pom
> 15c5e9584200122924e50203ae210b57616b75ee  commons-compress-1.13.jar
> 922598114ed03152c489a56510b3bbf9d5182a66 
> commons-compress-1.13-javadoc.jar
> 68ace8baf343f0384ba1fc995944c1d60f41f660 
> commons-compress-1.13-sources.jar
> afcc0429fa13803f7c029fdf5116db8fdf21376f  commons-compress-1.13-tests.jar
> 3121ecf5ac04dfc06924b518dd6c7fdf387a0f91 
> commons-compress-1.13-test-sources.jar
> 
> Details of changes since 1.12 are in the release notes:
>   https://dist.apache.org/repos/dist/dev/commons/compress/RELEASE-NOTES.txt
>   http://stefan.samaflost.de/staging/commons-compress-1.13/changes-report.html
> 
> The tag is here:
>   
> https://git-wip-us.apache.org/repos/asf?p=commons-compress.git;a=commit;h=45438471726fc5005a41cefecbf62d4d26eb15b2
> 
> Site:
>   http://stefan.samaflost.de/staging/commons-compress-1.13
> 
>   as usual when I cut releases this is *not* the site that I'm going to
>   publish after the relase. I'll update changes.xml when I know the
>   release date. Also the javadocs for 1.13 and "latest release" are
>   missing for now (they are identical to the "GIT latest" ones) and the
>   download page doesn't work on my server.
> 
> japicmp Report (compared to 1.12):
>   http://stefan.samaflost.de/staging/commons-compress-1.13/japicmp.html
> 
>   this is a bit harder to read than Clirr but Clirr dies with an NPE for
>   me.
> 
>   Binary serialization of UnsupportedZipFeatureException has changed,
>   but prior to 1.13 the class hasn't technically been serializable at
>   all.
> 
> RAT Report:
>   http://stefan.samaflost.de/staging/commons-compress-1.13/rat-report.html
> 
> KEYS:
>   https://www.apache.org/dist/commons/KEYS
> 
> Please review the release candidate and vote.
> Given the time of the year this vote will close no sooner that 96 hours
> from now, i.e. sometime after 13:00 UTC 29-December 2016
> 
>   [ ] +1 Release these artifacts
>   [ ] +0 OK, but...
>   [ ] -0 OK, but really should fix...
>   [ ] -1 I oppose this release because...
> 
> Thanks!
> 
> Stefan



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

Re: [VOTE][LAZY] Release Commons Parent 42 Based on RC3

[Jörg Schaible]

+1

Stefan Bodewig wrote:

> Hi all
> 
> as far as I can tell there has benver been a vote for RC2 but the tag
> exists, therefore I went with RC3
> 
> Parent 42 RC3 is available for review here:
> https://dist.apache.org/repos/dist/dev/commons/commons-parent/42-RC3/
> (svn revision 17566)
> 
> The tag is here:
> 
> http://svn.apache.org/viewvc/commons/proper/commons-parent/tags/commons-parent-42-RC3/
> (svn revision 1775956)
> 
> Maven artifacts are here:
> 
https://repository.apache.org/content/repositories/orgapachecommons-1230/org/apache/commons/commons-parent/42/
> 
> These are the Maven artifacts and their hashes
> 
> commons-parent-42-site.xml
> (SHA1: 02b3b54d26d97a72fd55b20d027040ca0daf52b7)
> commons-parent-42.pom
> (SHA1: 558c399c01d067bb1c3e8b808505fa00)
> 
> Details of changes since 41 are in the release notes:
> 
> https://dist.apache.org/repos/dist/dev/commons/commons-parent/42-RC3/RELEASE-NOTES.txt
> 
> Please review the release candidate and vote.
> Given the time of the year this vote will close no sooner than 120 hours
> from now, i.e. sometime after 15:00 UTC 29-December 2016
> 
>   [ ] +1 Release these artifacts
>   [ ] +0 OK, but...
>   [ ] -0 OK, but really should fix...
>   [ ] -1 I oppose this release because...
> 
> Thanks!
> 
> Stefan



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

[RESULT][LAZY] Release Commons Parent 42 Based on RC3

[Stefan Bodewig]

Given this is a lazy vote, the two +1 by Jörg Schaible and myself are
enough.

I'll finish the release process now.

Thanks

Stefan

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

Re: [VOTE] Release Apache Commons JCS 2.0 based on RC1

[Jörg Schaible]

+1

builds from source tarball with my compiler zoo except Java 9 (jar-plugin 
fails, unrelated to jcs).

The layout of the binary tarball is somewhat different compared to other 
commons releases:
- bin archive extracts into commons-jcs-2.0-bin instead of commons-jcs-2.0
- bin archive contains all these .asc files
- missing .txt extension for LICENSE and NOTICE
- javadocs are normally also contained extracted

BUILDING.txt:
- build with Java 6 requires Maven 3.2 or usage of java-1.6 profile with 
Maven 3.3 or higher

None of the issues is critical though.

Cheers,
Jörg

Thomas Vandahl wrote:

> I would like to release the [jcs] component.
> 
> Apache Commons JCS 2.0 RC1 is available for review at:
>   https://dist.apache.org/repos/dist/dev/commons/jcs/ (r17574).
> 
> Maven artifacts are at:
>   https://repository.apache.org/content/repositories/orgapachecommons-1232
>   .
> 
> The Subversion tag is:
> 
> https://svn.apache.org/repos/asf/commons/proper/jcs/tags/commons-jcs-2.0
> (r1776032).
> 
> The release notes are at:
> 
> https://svn.apache.org/repos/asf/commons/proper/jcs/tags/commons-jcs-2.0/RELEASE-NOTES.txt
> (r1776032).
> 
> The staged site is available as a tarball at
> 
> https://dist.apache.org/repos/dist/dev/commons/jcs/commons-jcs-site-2.0.tar.gz
> (r17575).
> 
> Please review the release candidate and vote.
> 
>   [ ] +1 Release these artifacts
>   [ ] +0 OK, but...
>   [ ] -0 OK, but really should fix...
>   [ ] -1 I oppose this release because...
> 
> Bye, Thomas



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

[text][TEXT-36] Dependency on "Commons RNG"

[Rob Tompkins]

Hello,

Because this Jira hasn’t gotten much traction over the last few days, I figured 
that I’d bubble the discussion up to the dev list to try to prompt more 
comments. The discussion thread follows below for convenience.

Cheers,
-Rob


Description  

This is a follow-up of a discussion held in TEXT-34.
IMHO, there is no harm in depending on the "commons-rng-client-api" module of 
Commons RNG; the "zero dependency" mantra does not hold here, since TEXT 
already depends on LANG.
OTOH, I see that it is counter-productive (i.e. it harms the Commons project as 
a whole) to not advertize or use other Commons components, despite the "own dog 
food" phrase appearing recurrently on the "dev" ML.
Rather than having people blindly use java.util.Random, we should allow them to 
choose wisely, based on full information.
IMO, that means to indeed use UniformRandomProvider in order to raise awareness 
about alternatives to the sub-optimal algorithm used by the JDK.
However, if some Commons developers do not trust that the UniformRandomProvider 
interface can be stable enough for TEXT, then we should follow Jochen 
Wiedemann's advice (cf. archive of the "dev" ML) and define TEXT's own 
interface to random numbers, with bridges to it from UniformRandomProvider and 
from java.util.Random.


Comments
 
Comment by Gary Gregory [ 21/Dec/16 ]
I can see a best of both worlds here based on your description. TEXT provides a 
random interface with 2 implementation: one to Java own random with a red 
waving flag on it and another impl based on RNG.

Comment by Bernd Eckenfels [ 21/Dec/16 ]
I would stick with the java.util.Random signature, if you want to specify a 
different random Generator you can subclass j.u.Random and overwrite protected 
int next(int).
In fact I would exepect RNG to provide such an Adapter already. Advantage is, 
that no dependency of TEXT to RNG is needed.

Comment by Duncan Jones [ 22/Dec/16 ]
It would be good to hear why people are concerned about a link between TEXT and 
RNG. Is it a fear of Maven jar hell? I.e. TEXT depends upon a specific version 
of RNG, which clashes somehow with the preferred version of the user's code?
If that's the concern, then I don't think Gregory's suggestion saves us 
anything, since we'd have to depend upon RNG to offer the interface.
IMO, the four options I can see in descending order of preference are:
Eat our own dog food - use RNG as the only visible option. Users can bridge to 
java.util.Random using RNG's bridge classes if they must.
As above, but explicitly offer overloads with java.util.Random.
Offer only java.util.Random in the interface, but shade RNG so that our 
internal default implementations are as good as can be.
Don't use RNG at all.

Comment by Gilles [ 22/Dec/16 ]
It would be good to hear why people are concerned about a link between TEXT and 
RNG.
+1
Indeed, are there technical objections?
There is nothing in favour of using the JDK's Random class in new applications 
(or libraries such as TEXT):
no speed of generation advantage,
no quality of randomness advantage,
no memory consumption advantage.
Over the course of developing what has become Commons RNG, I've made a summary 
of why not to use java.util.Random.
The only justification for using it is when applications are required to 
reproduce the same sequence as the particular algorithm implemented by Random 
(needless to say: It is not the most obvious case for "randomness").
Is it a fear of Maven jar hell?
This would be bogus, given that we don't release code that could create it (due 
to the change of package name and coordinates).
Eat our own dog food
+1
IOW tell the world to come and taste it too. 
And grow the community...
Users can bridge to java.util.Random using RNG's bridge classes
Not sure what you mean.
JDKRandomBridge is a bridge from Commons RNG's RandomSource to JDK's Random (so 
not applicable to pass to a TEXT API based on Commons RNG).
A user who would want to use Random as the underlying generator would create 
the corresponding UniformRandomProvider.
explicitly offer overloads with java.util.Random.
This is what Gary proposes.
Thus, assuming a TextRandomProvider interface:
import java.util.Random;

public class JdkRandomBridge implements TextRandomProvider {
private final Random delegate;

public JdkRandomBridge(Random rng) {
delegate = rng;
}

// TextRandomProvider methods.

/** {@inheritDoc} */
public int nextInt(int min, int max) {
// Generate an integer in range [min, max].
return delegate.nextInt(max + 1) + min;
}
}
import org.apache.commons.rng.UniformRandomProvider;

public class CommonsRngBridge implements TextRandomProvider {
private final UniformRandomProvider delegate;

public CommonsRngBridge(UniformRandomProvider rng) {
delegate = rng;
}

// TextRandomProvider methods.
// ...
}
Offer only java.util.Random in the interface, but shade RNG so that our 
inte

[VOTE][LAZY] Volunteer As Commons Text Release Manager

[Rob Tompkins]

Hello all,

I would like to volunteer as the commons-text release manager in hopes of 
performing the release in the coming weeks. Thus, I propose that I be the 
release manager for commons-text until another lazy consensus be reached for a 
different release manager at any future time.

I call for a vote for on this by lazy consensus. This vote will pass if nobody 
objects within the next 72 hours, until 01/01/2017, 17:00 UTC.

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

[RESULT] Release Compress 1.13 based on RC1

[Stefan Bodewig]

Hello

with +1 by Oliver Heger, Jörg Schaible and my own implicit one the vote
has passed and I'll start the release process.

I'll give the mirrors time to catch up before sending the announcement
or publishing th site.

Thanks

Stefan

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

Re: [VOTE][LAZY] Volunteer As Commons Text Release Manager

[Gary Gregory]

Thank you for volunteering Rob!

+1

Gary

On Dec 29, 2016 8:30 AM, "Rob Tompkins"  wrote:

Hello all,

I would like to volunteer as the commons-text release manager in hopes of
performing the release in the coming weeks. Thus, I propose that I be the
release manager for commons-text until another lazy consensus be reached
for a different release manager at any future time.

I call for a vote for on this by lazy consensus. This vote will pass if
nobody objects within the next 72 hours, until 01/01/2017, 17:00 UTC.

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

RE: [VOTE][LAZY] Volunteer As Commons Text Release Manager

[dbrosIus]

+1

 Original message 
From: Rob Tompkins  
Date: 12/29/16  11:30 AM  (GMT-05:00) 
To: Commons Developers List  
Subject: [VOTE][LAZY] Volunteer As Commons Text Release Manager 

Hello all,

I would like to volunteer as the commons-text release manager in hopes of 
performing the release in the coming weeks. Thus, I propose that I be the 
release manager for commons-text until another lazy consensus be reached for a 
different release manager at any future time.

I call for a vote for on this by lazy consensus. This vote will pass if nobody 
objects within the next 72 hours, until 01/01/2017, 17:00 UTC.

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

Re: [RESULT] Release Compress 1.13 based on RC1

[Gary Gregory]

Did you push to Maven Central too? Just curious.

Gary

On Thu, Dec 29, 2016 at 8:34 AM, Stefan Bodewig  wrote:

> Hello
>
> with +1 by Oliver Heger, Jörg Schaible and my own implicit one the vote
> has passed and I'll start the release process.
>
> I'll give the mirrors time to catch up before sending the announcement
> or publishing th site.
>
> Thanks
>
> Stefan
>
> -
> 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

Re: [RESULT] Release Compress 1.13 based on RC1

[Stefan Bodewig]

On 2016-12-29, Gary Gregory wrote:

> Did you push to Maven Central too? Just curious.

Yes, but I got confused by the Nexus UI and managed to "promote" Commons
Parent twice (didn't know this was possible). I realized this a few
hours later. I have seen Compress 1.13 in repo2.maven.org by now.

Will send the announcement tomorrow morning my time (UTC+1).

Stefan

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

[ANN] Apache Commons Compress 1.13 Released

[Stefan Bodewig]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

The Apache Commons Team is pleased to announce the release of Apache
Commons Compress 1.13.

Compress 1.13 adds write support for LZMA as raw streams as well as
inside 7z archives. Independently developed compressors and archivers
can now be added via the standard ServiceLocator mechanism and ZIP and
7z archives can now be read from a SeekableByteChannel rather than a
File.

Compress 1.13 is the first release that requires Java 7 at runtime.

The Apache Commons Compress Library defines a Java API for working with
ar, cpio, tar, zip, 7z, arj, dump, gzip, pack200, bzip2, lzma, snappy,
Z, xz and deflate files.

Source and binary distributions are available for download from the
Apache Commons download site:

http://commons.apache.org/proper/commons-compress/download_compress.cgi

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

Changes in this version include:

New features:
o SevenZFile, SevenZOutputFile, ZipFile and
  ZipArchiveOutputStream can now work on non-file resources if
  they can be accessed via SeekableByteChannel.
  Issue: COMPRESS-327.
o Allow compressor extensions through a standard JRE ServiceLoader.
  Issue: COMPRESS-368.
o Allow archive extensions through a standard JRE ServiceLoader.
  Issue: COMPRESS-369.
o Add write support for the legacy LZMA format, this requires XZ
  for Java 1.6.
  Issue: COMPRESS-373.
o Add write support for the legacy LZMA stream to 7z, this
  requires XZ for Java 1.6.
  Issue: COMPRESS-374.
o Allow the clients of ParallelScatterZipCreator to provide
  ZipArchiveEntryRequestSupplier.
  Issue: COMPRESS-375. Thanks to Plamen Totev.
o Add a version-independent link to the API docs of the latest
  release.
  Issue: COMPRESS-372.

Fixed Bugs:
o BitInputStream could return bad results when overflowing
  internally - if two consecutive reads tried to read more than
  64 bits.
  Issue: COMPRESS-363.
o ZipArchiveInputStream.closeEntry does not properly advance to
  next entry if there are junk bytes at end of data section.
  Issue: COMPRESS-364. Thanks to Mike Mole.
o ZipArchiveInputStream now throws an Exception if it encounters
  a broken ZIP archive rather than signaling end-of-archive.
  Issue: COMPRESS-367. Thanks to Mike Mole.
o ScatterZipOutputStream didn't close the StreamCompressor
  causing a potential resource leak.
  Issue: COMPRESS-377.

Changes:
o Update Java requirement from 6 to 7.
  Issue: COMPRESS-360.
o Clarified which TarArchiveEntry methods are useless for
  entries read from an archive.
  Issue: COMPRESS-366.

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

http://commons.apache.org/compress/

Stefan Bodewig, on behalf of the Apache Commons community
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iEYEARECAAYFAlhmBO0ACgkQohFa4V9ri3J7UgCeKXvTwNKeclhNeE52xQSlszPV
eFUAoIAGjm3yKwEKCDj940FCNe2DRhlY
=NPv1
-END PGP SIGNATURE-

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