On 2015-01-04, Stefan Bodewig wrote:
I'll try to reproduce this as a unit test for compress later today,
svn revision 1649312 - run via
$ mvn test -Dtest=Zip64SupportIT#writeAndRead5GBOfZerosUsingZipFile
I'll leave my box alone to run the whole suite of ZIP64 ITs (i.e. enable
the run-zipit
Hi
building the compress antlib in Gump fails (and has been failing for a
few days but I didn't notice):
http://vmgump.apache.org/gump/public/antlibs-compress/compress-antlib-test/gump_work/build_antlibs-compress_compress-antlib-test.html
The test creates a ZIP with a single 5GB entry and then
Re backwards compatibility: ZipArchiveOutputStream's deflate method has
been protected and now has gone.
On 2014-12-31, Kristian Rosenvold wrote:
On a related note, I just added the *last* substantial change I intend
to do. I will do a tweak or two, and I'm sure that last class will
trigger a
On 2014-12-31, krosenv...@apache.org wrote:
static ScatterGatherBackingStoreSupplier defaultSupplier = new
DefaultSupplier();
This one could be instance variable (and made final when set in the
constructor). I think this would be a cleaner approach to overriding
the supplier that setting
On 2015-01-02, Kristian Rosenvold wrote:
2015-01-02 16:22 GMT+01:00 Stefan Bodewig bode...@apache.org:
On 2014-12-31, krosenv...@apache.org wrote:
... all else fixed in r1649128..
I thought you'd need a way to override the
ScatterGatherBackingStoreSupplier from Plexus, maybe I was wrong
On 2015-01-02, Kristian Rosenvold wrote:
All fixed :)
Thanks a lot!
Stefan
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
On 2014-12-31, Jochen Wiedmann wrote:
On Mon, Dec 29, 2014 at 3:16 PM, Stefan Bodewig bode...@apache.org wrote:
Just as a letter of intent - I'd prefer to cut Compress 1.10 while
we're still in svn (as I know how to do it, I'm in the avoid the
release plugin camp) and call for a vote
On 2014-12-30, Kristian Rosenvold wrote:
I fixed all comments and reinstated the protected Deflater.
Thanks, looks good.
The whole ZipArchiveOutputStream class reminds me of a few of the
3000+ LOC java classes I refactored in maven core; sometimes the only
acceptable solution is to extract
On 2014-12-28, Kristian Rosenvold wrote:
Stefan, I looked at your changes in the github repo
https://github.com/bodewig/commons-compress/commits/scatter-backing-store
I think they look great. Please commit them :)
Done
Stefan
On 2014-12-29, Kristian Rosenvold wrote:
The refactoring os ZipArchiveOutputStream to use StreamCompressor is now done
in
the branch https://github.com/krosenvold/commons-compress
Some code comments:
* the fields writtenToOutputStream, sourcePayloadLength and actualCrc in
StreamCompressor
On 2014-12-29, Gary Gregory wrote:
but I encourage Git 'pushers' (pun intended) to just bring up a VOTE for a
component and move the process along if you care about Git.
Just as a letter of intent - I'd prefer to cut Compress 1.10 while
we're still in svn (as I know how to do it, I'm in the
Welcome Sumit Gaur!
On 2014-12-29, Sumit Gaur wrote:
I am new to Open Source Development. I’ve been part of various Java,
J2EE, WebServices (SOAP,Rest), Spring based projects. I’ve some
questions regarding project life cycle at ASF. Kindly spare some time
to answer the following:
This is
On 2014-12-28, Luc Maisonobe wrote:
I regularly check a few mirrors to see if they have mirrored the recent
[math] release, and many still seem to not know about it. I will
certainly not check all of them. Is there an accepted delay before
sending the official announce of the release, even if
On 2014-12-26, Kristian Rosenvold wrote:
Yup; I'm taking care of the duplication in trunk on my github fork.
The other interesting branch to look at is the somewhat stale
concurrentSupport branch and in particular the class
ConcurrentZipCreator. This is my primary goal, I just went off on a
On 2014-12-28, Kristian Rosenvold wrote:
2014-12-28 11:35 GMT+01:00 Stefan Bodewig bode...@apache.org:
On 2014-12-26, Kristian Rosenvold wrote:
D) Look at performance in the gather phase. It's too slow right now,
even with my last commit on trunk. Consider moving the creation of the
LFH
Benedikt Ritter wrote:
Maybe it's finally time to start upgrading all components to Java 1.6.
All compontents that don't explicitly want to defer the upgrade. No
need to force this on all components IMHO.
On 2014-12-26, Jörg Schaible wrote:
Just add a profile that sets the two properties
On 2014-12-23, Stefan Bodewig wrote:
Your commit message calls out writeOut as a particilar problem.
Fortunately this is one is final, so we don't have to retain the effect
of subclasses overriding it. Wouldn't it be possible to have writeOut
call the StreamCompressor's writeOut method so
On 2014-12-24, krosenv...@apache.org wrote:
It seems like OpenJDK calendar operations are somewhat different from
sun jdk, so this is not a viable test to make
Actually the reason is that zips - at least those created by Commons
Compress - store time in UTC and you need to adjust for the
On 2014-12-24, Bernd Eckenfels wrote:
I wonder, is it intentional, that this is no longer required/defined,
or just an oversight?
We're not very explicit about this, but at least a part of the releasing
guide for components says:
,
| Edit the SCM entries in the parent POM. Note: use the
On 2014-12-18, krosenv...@apache.org wrote:
public void addRawArchiveEntry(ZipArchiveEntry entry, InputStream
rawStream)
Technically entry could be a java.util.zip.ZipEntry, I'm not sure this
would open up new opportunities, though.
/**
* Transfer selected entries from this
On 2014-12-22, krosenv...@apache.org wrote:
* It is possible to extend this class to support different kinds of backing
storage, the default
* implementation only supports file-based backing.
Wouldn't it be possible to create a proper interface for backing
stores and have
On 2014-12-22, Kristian Rosenvold wrote:
There are quite a few extension points in this class that make
changing it really hard.
ACK
I just committed r1647329 which basically duplicates some code from
this class into another class. As much as I hate duplication, I wasn't
able to achieve
On 2014-12-16, Kristian Rosenvold wrote:
At least for maven's code, introducing the concept of a root stream
that will be the start of the physical zip stream can simplify things
quite a lot.
Yes, I can see the same for my compress antlib (Ant tasks based on
Commons Compress) as well. It
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
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
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):
On 2014-11-29, Benedikt Ritter wrote:
currently I feel really overwhelmed by the stuff I'd like to do at commons
and the little time I can spend for it.
As many others have already said, most of us know exactly what you are
talking about and IMHO the only solution for you is to not pick too
On 2014-11-12, Emmanuel Bourg wrote:
Le 12/11/2014 19:51, Stefan Bodewig a écrit :
A while ago I had already added a guard to ensure nobody tried to read
more than 32 bits since bits are accumulated inside an int - but
actually we can't do that as readBits returns -1 on EOF, so we can't
On 2014-11-13, Damjan Jovanovic wrote:
On Wed, Nov 12, 2014 at 8:51 PM, Stefan Bodewig bode...@apache.org wrote:
One thing BitStream and BitInputStream have in common is what happens
when I request more bits than are available from the underlying stream,
both will signal an EOF and discard
On 2014-11-14, sebb wrote:
On 12 November 2014 20:40, Emmanuel Bourg ebo...@apache.org wrote:
Le 12/11/2014 21:02, bode...@apache.org a écrit :
public int readBits(final int count) throws IOException {
-if (count 0 || count 32) {
if (count 0 || count 31) {
Hi
I wanted to write a few additional unit test for BitInputStream and
maybe later replace the zip package's BitStream with it (IMPLODE uses
that under the covers).
A while ago I had already added a guard to ensure nobody tried to read
more than 32 bits since bits are accumulated inside an int -
Apart from EOF handling there also is the byte-order case.
As it stands I'll get different bits in LITTLE_ENDIAN order if I read
eight bits twice or sixteen bits at once, this is now what I'd expect.
Should byte order imply we are always reading bytes in chunks of a given
number?
Right now I
On 2014-11-12, Stefan Bodewig wrote:
As it stands I'll get different bits in LITTLE_ENDIAN order if I read
eight bits twice or sixteen bits at once, this is now what I'd expect.
And it's not true, I just need to think about the returned ints in a
different way, all is fine :-)
Stefan
Hi all
Gump builds commons-collection's 3.x branch since it is a dependency of
Forrest and the XML Graphics projects that still enjoy using Gump.
After we've switched to using Java8 we found Collections 3.x cannot be
built on Java8 because of some addition to the Map interface.
default boolean
Hi
a few days ago Compress' pom was changed to use the newest PMD plugin
version 3.2, this one depends on PMD 5.1.2. When I built the site
locally it claimed to find about ten instances of unused private
functions - all of them false positives.
Since the changelog of PMD 5.1.3 [1] lists at
On 2014-10-23, Damjan Jovanovic wrote:
I've been hoping to steal commons-compress's cleaner and faster LZW
decompressor, and use it in commons-imaging for TIFF and GIF files,
and I've finally managed to make a patch to that effect.
Cool.
This requires moving LZWInputStream to a
, 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.4.9 (GNU/Linux)
iEYEARECAAYFAlQ4Bi0ACgkQohFa4V9ri3JTfgCePodWpLt1EAh0S0qPfl0IN3sC
Hi all
with +1s by Emmanuel, Gary, Jörg and myself the vote has passed. I'll
take the next steps of the release process and wait for the mirrors to
catch up before sending the announcement - as usual.
Many thanks to all who reviewed the release.
Stefan
On 2014-10-06, Stefan Bodewig wrote:
Please review the release candidate and vote.
This vote will close no sooner that 72 hours from now, i.e. after 0530
GMT 09-October 2014
My own +1
Stefan
-
To unsubscribe, e-mail
Just a note on the GPG key, it might be a good idea to upgrade to a
stronger one. 1024 bits keys are discouraged nowadays.
http://www.apache.org/dev/release-signing
I know, but leaving behind a key that has accumulated signatures over
more than ten years is hard ...
Stefan
On 2014-10-06, Emmanuel Bourg wrote:
Le 06/10/2014 09:16, Stefan Bodewig a écrit :
I know, but leaving behind a key that has accumulated signatures over
more than ten years is hard ...
My suggestion was actually a subtle plan to get you to invite us to
drink a beer and sign your new key
On 2014-10-06, sebb wrote:
On 6 October 2014 08:16, Stefan Bodewig bode...@apache.org wrote:
Just a note on the GPG key, it might be a good idea to upgrade to a
stronger one. 1024 bits keys are discouraged nowadays.
http://www.apache.org/dev/release-signing
I know, but leaving behind
Hi all,
nothing big this time but a few accumulated bug fixes and support for
raw DEFLATE streams.
Compress 1.9 RC1 is available for review here:
https://dist.apache.org/repos/dist/dev/commons/compress/
(svn revision 6728)
Maven artifacts are here:
On 2014-09-27, Gary Gregory wrote:
Still closing in on 1.9 ;-)
Stefan, are you ready to cut a released?
Distracted by real life, might get around to it tomorrow, but it is
quite possible I'll have to push it off to the next weekend.
Stefan
On 2014-09-27, Gary Gregory wrote:
What is the status of this VOTE?
http://mail-archives.apache.org/mod_mbox/commons-dev/201409.mbox/%3C541FF178.1030204%40apache.org%3E
Stefan
-
To unsubscribe, e-mail:
+1
could see the signature on my Win7 VM and Windows seemed to like it.
Stefan
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
[on the original topic: I personally like git but would leave the
decision to move on to the components]
On 2014-09-10, Gilles wrote:
[The advantages of git must be somewhere else.]
Not sure about the advantage, but let me show you an example where a
DVCS (any DVCS) would have been really
Hi
I've just added a link to the security page inside the main navigation,
see
http://commons.staging.apache.org/security.html
The page is inside the staging area only, but I'd like to publish it
sooner rather than later - and update the commons parent to include the
same link.
Should the
On 2014-09-10, Gary Gregory wrote:
Hm... The requested URL /security.html was not found on this server.
I copy pasted the link from my browser. The page has been there for
almost two weeks now, so we can rule out stale caches.
Are you sure you are trying the URL that contains staging inside
On 2014-09-01, sebb wrote:
On 1 September 2014 04:53, Stefan Bodewig bode...@apache.org wrote:
On 2014-09-01, sebb wrote:
The page mentions denial of service - not sure that applies to any of
the Commons components?
The one issue with Compress could be used for a DoS attack.
I think
On 2014-09-02, sebb wrote:
Propchange: commons/cms-site/trunk/content/xdoc/security.xml
--
svn:mime-type = application/xml
-1 (for the property)
SVN treats that mime-type as binary; either drop it or use
Hi all
I was just browsing the security pages of some ASF projects and the
guidelines set by our security team[1] (preparing a talk, not because
there was any issue) and realized Commons didn't have a page describing
how to report security issues.
Since I'm the one who created the page for
On 2014-08-31, Gary Gregory wrote:
Great idea!
Every Commons component should have such a page indeed, can be a link
to the same page for all of Commons IMO.
Some changes though are needed.
It should be made clearer that there is an important distinction
between undisclosed and disclosed
Hi all,
I've put together a security page for Commons so people have a place to
get information quickly, it is based on the recommendations by our
security team[1] and the existing page of Compress[2].
http://commons.staging.apache.org/security.html
this one is still in staging so we
On 2014-08-31, Gary Gregory wrote:
I get a 404...
strange. Take note of staging in the URL
http://commons.staging.apache.org/security.html
Stefan
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional
Hi all
it's only four issues we've closed since the 1.8.1 release but I
consider COMPRESS-286 pretty serious - it looks as if reading 7z
archives using LZMA (not LZMA2) was in trouble.
One thing that bothers me is COMPRESS-284 as I simply cannot reproduce
it - and don't see the bug by reading
On 2014-09-01, sebb wrote:
Might be useful to add a link to the security page under General
Information.
Right.
The page mentions denial of service - not sure that applies to any of
the Commons components?
The one issue with Compress could be used for a DoS attack.
Stefan
On 2014-08-22, Benedikt Ritter wrote:
Okay... TBH, I don't like that BCEL is treated special. Looks like a
different versioning schema to me. Also other groupId and artifactId. But
if you RM, it's your decision :-) I won't block a release because of this
if BCEL was always released like this.
On 2014-08-20, Benedikt Ritter wrote:
I've committed a new mojo to the commons build plugin, which generates a
README.md file for a component [1].
Without looking at the code, do you plan to make it so that projects can
override the default README.md with a template of their own - much like
we
On 2014-08-20, Benedikt Ritter wrote:
2014-08-20 13:13 GMT+02:00 Stefan Bodewig bode...@apache.org:
On 2014-08-20, Benedikt Ritter wrote:
I've committed a new mojo to the commons build plugin, which generates a
README.md file for a component [1].
Without looking at the code, do you plan
On 2014-08-18, sebb wrote:
I suspect just using a volatile enum would be sufficient as enums are
thread-safe so it is just necessary to ensure safe publication.
I went with the volatile route since the code never used compareAndSet
or one of its friends anyway.
Stefan
On 2014-07-25, Gary Gregory wrote:
It's that or we agree never to publish a SNAPSHOT site.
For the record, I do value SNAPSHOT sites so we can also show what we
are working on. I'm not convinced we need to enforce the same policy
for all components. OTOH I don't feel strong enough about it to
The dependency on org.tukaani:xz is now marked as optional.
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
Hi all
with a -1 by Gary Gregory and +1s by Emmanuel Bourg, Luc Maisonobe, Phil
Steitz and myself the vote has passed.
I'll publish all artefacts and update the site/announce the release
after the mirrors had time to catch up.
Thanks
Stefan
On 2014-05-11, Emmanuel Bourg wrote:
There is a typo in the changes report:
ArchiveStreams now validate there is a current entry before rreading or
writing entry data.
Thanks, will fix the site post-release.
Stefan
-
To
Hi all,
delayed because I wanted to wait for mails to arrive again.
Compress 1.8.1 RC1 is available for review here:
https://dist.apache.org/repos/dist/dev/commons/compress/
(svn revision 5300)
Maven artifacts are here:
On 2014-05-11, Gary Gregory wrote:
-1 There are 58 Javadoc failures under Java 8.
So we'll need 4 +1s in this case :-)
Please not that apart from some missing @params and @returns there is a
clear bug in Java 8's javadoc that I don't think we can work around.
On 2014-05-11, Stefan Bodewig wrote:
On 2014-05-11, Gary Gregory wrote:
-1 There are 58 Javadoc failures under Java 8.
So we'll need 4 +1s in this case :-)
Nonsense. 3 +1s and more +1s than -1s, that's all.
Stefan
On 2014-05-11, Stefan Bodewig wrote:
Hi all,
delayed because I wanted to wait for mails to arrive again.
Compress 1.8.1 RC1 is available for review here:
https://dist.apache.org/repos/dist/dev/commons/compress/
(svn revision 5300)
Maven artifacts are here:
https
Hi all,
two months since the last release and we've accumumlated a few bugfixes,
most notably in tar (again, one would expect that part of the code base
to be the most mature). I'd like to create a new release.
We have changed the POM to mark our dependency on XZ for Java as
optional but still
On 2014-04-23, Ate Douma wrote:
But it would be great to hear who *might* be interested in
participating in such a Apache Commons track, about what
topic/component you'd like to talk about, etc. Just to determine if
this might be a feasible setup, already next ApacheCon or maybe
sometimes
On 2014-04-06, Benedikt Ritter wrote:
Note that we're still having problems with Java 8 / DocLint. mvn install
works (thanks to the fixes Niall has made) but mvn site still fails because
the test code contains malformed JavaDoc comments. I've documented this
problem on the main page (and hope
On 2014-04-03, ebo...@apache.org wrote:
Don't use '_' as an identifier to avoid a compiler warning with Java 8
why is Java8 complaining?
Stefan
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional
On 2014-04-03, Benedikt Ritter wrote:
I didn't now that '_' is a valid identifier at all.
That's a different point. :-)
_ is used as an identifier in many funtional languages to mean any
argument, I don't care for it anyway when you need to have an argument
for a certain contract but won't use
On 2014-04-03, Emmanuel Bourg wrote:
Le 03/04/2014 10:27, Stefan Bodewig a écrit :
why is Java8 complaining?
I don't know, it says '_' is deprecated and may become illegal in the
future. I guess '_' may be used for a new language feature.
OK, thanks, didn't know that. I've by noe found
On 2014-04-03, Benedikt Ritter wrote:
2014-04-03 12:05 GMT+02:00 Stefan Bodewig bode...@apache.org:
On 2014-04-03, Benedikt Ritter wrote:
I didn't now that '_' is a valid identifier at all.
That's a different point. :-)
_ is used as an identifier in many funtional languages to mean any
On 2014-04-03, Emmanuel Bourg wrote:
http://openjdk.5641.n7.nabble.com/Warning-about-single-underscore-identifier-td145974.html
They are deprecating the use of _ for method argument names so that
one day I may be able to use it for the exact same purpose I've done so
for :-)
Stefan
The vote has passed with +1s by
Emmanuel Bourg
Oliver Heger
Luc Maisonobe
Gary Gregory
Jörg Schaible
and no other votes.
I'll proceed with publishing the release artifacts but it may take a bit
longer than usual to update the site as I'm traveling right now. Should
be done by Friday the
Commons Compress website:
http://commons.apache.org/compress/
Stefan Bodewig, on behalf of the Apache Commons community
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
iEYEARECAAYFAlMhRewACgkQohFa4V9ri3JILACgqpPksDdKQPHq+U9gAQ2yZYTA
OqcAnRQcpMPZT6mFHchKTUGkYzzCsw/i
=NgWC
-END PGP
On 2014-03-09, Oliver Heger wrote:
When building with Java 1.5 I get the test failures below (this was
already the case for the previous releases, so probably no reason to
worry about).
It looks as if LZMA2 requires a lot of memory, all the failing tests are
using LZMA2 with default setting.
Hi all
I talked about cutting Compress 1.8 in particular because of
COMPRESS-264 but delayed it waiting for a new XZ for Java release.
Compress 1.8 RC1 is available for review here:
https://dist.apache.org/repos/dist/dev/commons/compress/
(svn revision 4610)
Maven artifacts are
On 2014-03-01, sebb wrote:
On 1 March 2014 05:57, Stefan Bodewig bode...@apache.org wrote:
On 2014-02-28, s...@apache.org wrote:
Add serialVersionUID
to a private inner class that is a subclass of HashMap.
Why?
Eclipse complained; it won't do any harm.
Sure not, I was just curious
On 2014-03-02, sebb wrote:
On 1 March 2014 19:53, Matt Benson gudnabr...@gmail.com wrote:
I've said it before: doocracy. If someone wants to take on the work to
provide 1.5 support, they've widened the audience of the component, which
should be seen as a win if it didn't cause anyone else a
Apart from the bugfixing we've added better support for 7z compression
methods - you can now chose a stack of more than one method when writing
(this has always been possible when reading), pass options to the
methods and use different configurations per entry. The core of this
are the new
Hi,
I've managed to implement the major BCJ filters for 7z (special filters
for native executables) by simply invoking the XZ for Java
implementations for it. This is needed for COMPRESS-257.
Unfortunately there is a bug in XZ for Java that has already been fixed
in git. When using a released
On 2014-02-28, sebb wrote:
Can Compress catch the specific Assertion Error and convert it to a
message that explains the issue? Perhaps even provide a link to a
Wiki FAQ?
not without catching all AssertionErrors
java.lang.AssertionError: null
at
On 2014-02-28, Gary Gregory wrote:
Do we have any idea WRT a new release of XZ?
I've reported the problem a few hours ago and Lasse fixed it within
minutes. This single line change is the only change since the 1.4
release cut six or seven month ago.
Not sure whether he'd like to create a new
On 2014-02-28, s...@apache.org wrote:
Add serialVersionUID
to a private inner class that is a subclass of HashMap.
Why?
Stefan
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail:
On 2014-02-28, sebb wrote:
On 28 February 2014 17:47, Stefan Bodewig bode...@apache.org wrote:
On 2014-02-28, sebb wrote:
Alternatively, can Compress detect the XZ version and refuse to run
BCJ, again with suitable message?
No way short of parsing the OSGi attributes from the manifest
On 2014-02-27, Benedikt Ritter wrote:
the project reports look good to me. Some package have low test coverage
but I think you've already said that it's pretty hard to write tests for
this areas of the code. PMD shows four violations. The first three look
like they can be fixed easily.
Not
On 2014-02-27, luc wrote:
Is this failure expected? I am running the tests suite on a Linux
computer, maybe MicrosoftTagTest is windows-specific?
all tests pass for me:
$ uname -a
Linux brick 3.5.0-46-generic #70-Ubuntu SMP Wed Jan 8 18:40:46 UTC 2014
x86_64 x86_64 x86_64 GNU/Linux
$ java
On 2014-02-26, Mark Thomas wrote:
I'm wondering what to do about @since markers. As DBCP2 is in a
completely new package, arguably everything is new for this release. The
existing @since markers don't make a lot of sense. Therefore, I am
currently considering removing all @since markers from
Hi all,
this is a heads-up that I intend to cut a RC for Compress 1.8 soon. We
have accumulated a few bugfixes and at least COMPRESS-264 is pretty
serious.
I've already updated the website from trunk (basically to have the new
skin online) so you can already have a look at the reports.
Before
On 2014-02-21, Mark Thomas wrote:
The Pool 2.2 RC2 is available for review here:
https://dist.apache.org/repos/dist/dev/commons/pool/ (r4457)
Maven artifacts are here:
https://repository.apache.org/content/repositories/orgapachecommons-1009
Details of changes since 2.1 are in the
On 2014-02-20, Benedikt Ritter wrote:
I'd like to call a vote for moving Commons Attributes to dormant.
Reasons:
- years have passed since the last real activity in attributes [1].
- the last release is from 2006.
- the code is pre Java 5.
+1
Stefan
On 2014-02-06, Mark Thomas wrote:
The FileUpload 1.3.1 RC1 is available for review here:
https://dist.apache.org/repos/dist/dev/commons/fileupload/ (r4317)
Maven artifacts are here:
https://repository.apache.org/content/repositories/orgapachecommons-1005/
Details of changes since 1.3
Hi
while pondering the API of Compress 2.x I already moaned about the lack
of decorator support in Channels, in particular pushback would be needed
in Compress in many places, but also stuff like counting, verifying
checksums and other Filter*Stream stuff.
When I started to look around I didn't
On 2014-01-27, Benedikt Ritter wrote:
I've planned to do some work on IO after [lang] 3.3, but you know how
it often turn's out with my plans ;-) so I cannot promise anything.
tell me - I'll go MIA for most of the next two or three weeks, I'm
afraid.
One thing I don't understand is: are you
On 2014-01-25, Damjan Jovanovic wrote:
On Fri, Jan 24, 2014 at 6:06 PM, Stefan Bodewig bode...@apache.org wrote:
On 2013-12-30, Stefan Bodewig wrote:
Compress 1.x is at Java5, personally I don't think Java6 would give us
any benefits. I don't know about the other improvements in NIO2
On 2013-12-30, Stefan Bodewig wrote:
Compress 1.x is at Java5, personally I don't think Java6 would give us
any benefits. I don't know about the other improvements in NIO2 but the
java.nio.file package looks useful for compress.
In the meantime it has been pointed out to me that Android
501 - 600 of 1182 matches
Mail list logo
