On 2009-03-23, Siegfried Goeschl siegfried.goes...@it20one.at wrote:
'mvn site' fails due to a missing checkstyle.xml in pom.xml - is that
file missing or the pom wrong?
AFAICT there has never been such a file.
I've just now commented out the checkstyle plugin, hope it helps to
get you
On 2009-03-24, Dennis Lundberg denn...@apache.org wrote:
Stefan Bodewig wrote:
* setup a new JIRA project for compress and move the SANDBOX issues
for component Compress over there.
Neither my JIRA karma nor knowledge are up to this task, we need
help.
JIRA is now set up to handle
On 2009-03-24, Dennis Lundberg denn...@apache.org wrote:
Niall Pemberton wrote:
I updated the main commons site to move compress from the Sandbox to
proper page. Looks like Dennis corrected the urls, so I have deployed
a new version of compress site under proper - should be there after
the
On 2009-03-25, Jörg Schaible joerg.schai...@gmx.de wrote:
BTW: What is the difference in Gump's project descriptor between the
optional and depend tags?
If the project you depend on doesn't build in Gump, your project won't
be built at all if you use depend and will still build if you use
On 2009-03-24, Torsten Curdt tcu...@apache.org wrote:
Personally I am not a big fan of checkstyle enforcement at all.
I can perfectly well live without it as well.
Stefan
-
To unsubscribe, e-mail:
Hi,
how do I tell Continuum that compress has been promoted?
Thanks for any hint
Stefan
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
On 2009-03-26, Christian Grobmeier grobme...@gmail.com wrote:
This should make sure that CPIO classes work like all the other classes.
Thanks.
I've moved the finish() call in close() inside the !closed branch
since otherwise finish's ensureOpen would cause trouble for repeated
calls to close
On 2009-03-26, Jukka Zitting jukka.zitt...@gmail.com wrote:
The commons-compress NOTICE file currently contains the following entries:
Original BZip2 classes contributed by Keiron Liddle
kei...@aftexsw.com, Aftex Software to the Apache Ant project
Original Tar classes from
On 2009-03-26, bode...@apache.org wrote:
support as much as possible of ZipFile as a stream can do in
ZipArchiveInputStream, COMPRESS-47
This is Harmony's ZipInputStream combined with compress's parsing of
the local file header - so we do get encoding support in
ZipArchiveInputStream.
I need
On 2009-03-26, Torsten Curdt tcu...@apache.org wrote:
If the code has been tested by the folks at hadoop I trust it very
much. (They do extensive testing!) and would be all for replacing the
current code base.
I just did it 8-)
svn revision 759143
Stefan
On 2009-03-27, tcu...@apache.org wrote:
fixed the testcase
You didn't, fails for me on Linux (and apparently inside Gump as well).
I intended to update the site, but will hold back now because I don't
want the surefire report to show failing tests.
Stefan
On 2009-03-28, sebb seb...@gmail.com wrote:
pReading entries from an ar archive:/p
source![CDATA[
ArArchiveEntry entry = (ArArchiveEntry) arInput.getNextEntry();
byte[] content = new byte[entry.getSize()];
LOOP UNTIL entry.getSize() HAS BEEN READ {
I thought the idea was that the
On 2009-03-28, sebb seb...@gmail.com wrote:
On 28/03/2009, Stefan Bodewig bode...@apache.org wrote:
On 2009-03-28, sebb seb...@gmail.com wrote:
I thought the idea was that the ArchiveInputStreams would not allow
one to read past the end of the entry, so one can just read until
read
your API suggesteions sound useful.
On 2009-03-30, sebb seb...@gmail.com wrote:
On 29/03/2009, sebb seb...@gmail.com wrote:
On 29/03/2009, sebb seb...@gmail.com wrote:
The current ChangeSet API allows for:
deletion of entries by name
The same method call is currently used for both deleting
I think I see why Gump's mvn repository proxy doesn't work here - it
currently doesn't work for group-ids that contain dots.
Do you want me to turn off nags until this gets fixed (shouldn't take
longer than a few days, I hope)?
Stefan
On 2009-03-30, sebb seb...@gmail.com wrote:
The abstract parent class for archive output streams has the method
putArchiveEntry(ArchiveEntry)
but all the implementations - apart from Ar - also define the specific method
putNextEntry(xxxArchiveEntry) where xxx = Zip, Jar, etc.
Do we
On 2009-03-30, sebb seb...@gmail.com wrote:
What about the corresponding getNextxxxEntry() methods?
I suppose they do avoid a cast.
Yes, in one case (tar IIRC) they have been explicitly asked for via
JIRA.
Stefan
-
To
On 2009-03-30, sebb seb...@gmail.com wrote:
Might it not be better to throw an Exception if methods are called out
of sequence?
We are pretty inconsistent here. In general I agree it would be
better to throw an exception, but we seem to swallow other errors in
other classes.
Stefan
On 2009-03-30, sebb seb...@gmail.com wrote:
On 30/03/2009, Stefan Bodewig bode...@apache.org wrote:
On 2009-03-30, sebb seb...@gmail.com wrote:
Might it not be better to throw an Exception if methods are called out
of sequence?
We are pretty inconsistent here. In general I agree it would
On 2009-03-30, sebb seb...@gmail.com wrote:
On 30/03/2009, Stefan Bodewig bode...@apache.org wrote:
On 2009-03-30, sebb seb...@gmail.com wrote:
What about the corresponding getNextxxxEntry() methods?
I suppose they do avoid a cast.
Yes, in one case (tar IIRC) they have been explicitly
On 2009-03-31, s...@apache.org wrote:
URL: http://svn.apache.org/viewvc?rev=760390view=rev
Log:
Set some attributes from the File
public ZipArchiveEntry(File inputFile, String entryName) {
this(entryName);
+ setSize(inputFile.length());
+
On 2009-03-31, sebb seb...@gmail.com wrote:
On 31/03/2009, Stefan Bodewig bode...@apache.org wrote:
setSize is dangerous here since it may very well 0 for directories
on Unix like systems.
Oops!
However it should be OK for regular files, no?
I hope so. I recall some problems
On 2009-03-31, Ralph Goers ralph.go...@dslextreme.com wrote:
On Mar 31, 2009, at 1:59 AM, Stefan Bodewig wrote:
I did not have the necessary permission to deploy to
people.apache.org, so I deployed the snapshot to the new M2 repo at
repository.apache.org. However, I commons configuration
On 2009-04-02, sebb seb...@gmail.com wrote:
So I'd like to rename the TarUtils getXXX() methods to formatXXX()
instead, as that is what the methods actually do - they format the
input long or stringbuffer into a byte buffer.
Also, TarArchiveEntry mostly uses StringBuffer rather than String.
Now that commons-configuration gets the latest and greates vfs it also
gets the latest of Xalan and we are back to this failure
All errors I checked look like this one
On 2009-04-07, Jörg Schaible joerg.schai...@gmx.de wrote:
Stefan Bodewig wrote at Dienstag, 7. April 2009 11:34:
On 2009-04-07, Gump iss...@commons.apache.org wrote:
[snip]
This happens because I've set maven.test.skip to true (since one of
VFS' unit tests is failing in Gump and I wanted
On 2009-04-07, Gump iss...@commons.apache.org wrote:
Missing:
--
1) org.apache.commons:commons-vfs:test-jar:tests:2.0-SNAPSHOT
Try downloading the file manually from the project website.
Then, install it using the command:
mvn install:install-file
Hi Mladen,
On 2009-04-07, mt...@apache.org wrote:
URL: http://svn.apache.org/viewvc?rev=762766view=rev
Log:
Opps. Now you know from where this class originated :)
-/*
- * SIGHT - System information gathering hybrid tool
- *
- * Copyright(c) 2007 Red Hat Middleware, LLC,
...
- *
- *
On 2009-04-07, Mladen Turk mt...@apache.org wrote:
Stefan Bodewig wrote:
Hi Mladen,
In the later case well need a software grant for it since we cannot
simply fork a LGPLed code base under the Apache License.
It's not a fork, cause it was never released.
This was just a testing code
Christian Grobmeier has been elected as a new Commons committer about
two weeks ago and this has been his first commit
On 2009-04-07, grobme...@apache.org wrote:
Author: grobmeier
Date: Tue Apr 7 16:56:00 2009
New Revision: 762849
Welcome!
Stefan
On 2009-04-09, Christian Grobmeier grobme...@gmail.com wrote:
Sine I really don't like those System.err.println stuff I would like
to remove it from the classes including the debug flag.
+1
Stefan
-
To unsubscribe, e-mail:
On 2009-04-14, Christian Grobmeier grobme...@gmail.com wrote:
Open and unscheduled Issues are:
* COMPRESS-62 Need many more test cases to check that can read
real archives
* COMPRESS-64 Are the public finish() methods ArchiveOutputStream
implementations necessary and safe?
On 2009-04-27, sebb seb...@gmail.com wrote:
Just remembered - what about ZipArchiveInputStream.useUnicodeExtraFields?
This field is currently unused - what are the plans for it?
It should never have been unimplemented at all 8-)
This was the last piece I wanted to do while working on the code
testCpioUnarchive fails when building from the source tarball on
Windows because test1.xml has Unix linefeeds and thus is four bytes
shorter than expected - no reason to block the relase for me.
All my other tests passed.
There shouldn't be md5/sha1 checksums for the PGP signatures (they
On 2009-05-18, sebb seb...@gmail.com wrote:
On 15/05/2009, Oliver Heger oliver.he...@oliver-heger.de wrote:
I think md5 checksums are required for all artifacts. They are currently
missing.
Agreed.
Could perhaps add sha1 as well, but not essential
md5s and sha1s are now there and match.
Hi,
I've started to implement a commons-compress based antlib over in Ant
land
https://svn.apache.org/repos/asf/ant/sandbox/antlibs/compress/trunk/
and just realized we don't have a common getLastModified() method in
ArchiveEntry - maybe we should have.
What seems to be worse is that we don't
On 2009-07-31, Emmanuel Bourg ebo...@apache.org wrote:
Stefan Bodewig a écrit :
I've started to implement a commons-compress based antlib over in Ant
land
https://svn.apache.org/repos/asf/ant/sandbox/antlibs/compress/trunk/
Nice! Do you plan to replace the archive/compress tasks in Ant
On 2009-08-01, Emmanuel Bourg ebo...@apache.org wrote:
Stefan Bodewig a écrit :
That's what I assume as well, I'm just hoping that anybody else would
know for sure before I fix it.
I created an archive with GNU ar to check the timestamp, I confirm
it's in seconds.
Thanks for the check
Hi,
over in Ant land we've received a bug report that Ant's ftp task
wouldn't compile against commons-net 2,0 because the IMAGE_FILE_TYPE
constant was removed from the FTP class.
Given that trunk still has that constant, is trunk in net sort of
obsolete and we should consider one of the branches
On 2009-09-15, Gump iss...@commons.apache.org wrote:
Project commons-collections has an issue affecting its community integration.
...
[javac]
/srv/gump/public/workspace/apache-commons/collections/src/test/org/apache/commons/collections/TestCollectionUtils.java:275:
cannot find symbol
Hi all,
as expected, Gump found a few projects that have been broken by the
recent merge in Collections - that's what it's there fore anyway.
The first ones I have found (there will be more, I'm sure are):
Torque: uses FastArrayList and OrderedMap#orderedMapIterator()
Jelly: uses BeanMap
On 2009-09-17, Henri Yandell flame...@gmail.com wrote:
Though it wouldn't make Gump's life any easier. In fact life would get
worse until they set up a separate v3 version anyway. Which I think is
what's happened for Lang.
Yes this is what we did - and likely will do for collections.
So the
On 2009-09-18, Stefan Bodewig bode...@apache.org wrote:
On 2009-09-17, Henri Yandell flame...@gmail.com wrote:
Though it wouldn't make Gump's life any easier. In fact life would get
worse until they set up a separate v3 version anyway. Which I think is
what's happened for Lang.
Yes
On 2009-09-18, Henri Yandell flame...@gmail.com wrote:
On Thu, Sep 17, 2009 at 9:08 PM, Stefan Bodewig bode...@apache.org wrote:
On 2009-09-18, Stefan Bodewig bode...@apache.org wrote:
On 2009-09-17, Henri Yandell flame...@gmail.com wrote:
Though it wouldn't make Gump's life any easier
To whom it may engage...
This is an automated request, but not an unsolicited one. For
more information please visit http://gump.apache.org/nagged.html,
and/or contact the folk at [EMAIL PROTECTED]
Project commons-openpgp has an issue affecting its community integration.
This issue
To whom it may engage...
This is an automated request, but not an unsolicited one. For
more information please visit http://gump.apache.org/nagged.html,
and/or contact the folk at [EMAIL PROTECTED]
Project commons-cli has an issue affecting its community integration,
and has been
To whom it may engage...
This is an automated request, but not an unsolicited one. For
more information please visit http://gump.apache.org/nagged.html,
and/or contact the folk at [EMAIL PROTECTED]
Project commons-cli has an issue affecting its community integration,
and has been
To whom it may engage...
This is an automated request, but not an unsolicited one. For
more information please visit http://gump.apache.org/nagged.html,
and/or contact the folk at [EMAIL PROTECTED]
Project commons-math has an issue affecting its community integration.
This issue
To whom it may engage...
This is an automated request, but not an unsolicited one. For
more information please visit http://gump.apache.org/nagged.html,
and/or contact the folk at [EMAIL PROTECTED]
Project commons-math has an issue affecting its community integration.
This issue
To whom it may engage...
This is an automated request, but not an unsolicited one. For
more information please visit http://gump.apache.org/nagged.html,
and/or contact the folk at [EMAIL PROTECTED]
Project commons-net has an issue affecting its community integration.
This issue affects
On Tue, 5 Feb 2008, Simon Kitching [EMAIL PROTECTED] wrote:
In my experience these weird execute bits are quite common; if a
unix text file gets this bit set on it for some reason, then svn add
will helpfully set the executable flag.
Many times the Cygwin svn client is to blame, it seems to
To whom it may engage...
This is an automated request, but not an unsolicited one. For
more information please visit http://gump.apache.org/nagged.html,
and/or contact the folk at [EMAIL PROTECTED]
Project commons-daemon has an issue affecting its community integration.
This issue
To whom it may engage...
This is an automated request, but not an unsolicited one. For
more information please visit http://gump.apache.org/nagged.html,
and/or contact the folk at [EMAIL PROTECTED]
Project commons-xmlio has an issue affecting its community integration.
This issue
my fault, I introduced a dependency cycle in Gump which should be
fixed now.
sorry for the noise
Stefan
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To whom it may engage...
This is an automated request, but not an unsolicited one. For
more information please visit http://gump.apache.org/nagged.html,
and/or contact the folk at [EMAIL PROTECTED]
Project commons-net has an issue affecting its community integration.
This issue affects
To whom it may engage...
This is an automated request, but not an unsolicited one. For
more information please visit http://gump.apache.org/nagged.html,
and/or contact the folk at [EMAIL PROTECTED]
Project commons-net has an issue affecting its community integration.
This issue affects
To whom it may engage...
This is an automated request, but not an unsolicited one. For
more information please visit http://gump.apache.org/nagged.html,
and/or contact the folk at [EMAIL PROTECTED]
Project commons-net has an issue affecting its community integration.
This issue affects
To whom it may engage...
This is an automated request, but not an unsolicited one. For
more information please visit http://gump.apache.org/nagged.html,
and/or contact the folk at [EMAIL PROTECTED]
Project commons-net has an issue affecting its community integration.
This issue affects
On Thu, 03 Apr 2008, [EMAIL PROTECTED] wrote:
+ available property=dom.available classname=w3c.dom.Node /
I think you mean org.w3c.dom.Node (missing org.).
Stefan
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional
The descriptor said maven which is Maven1, I changed it to mvn
(Gump speak for Maven2) so I hope it will work better on the next run.
Stefan
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL
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-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-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.
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-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
[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
+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 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:
/content/repositories/orgapachecommons-1049/org/apache/commons/commons-compress/1.9/
Details of changes since 1.8.1 are in the release notes:
https://dist.apache.org/repos/dist/dev/commons/compress/RELEASE-NOTES.txt
http://people.apache.org/~bodewig/COMPRESS-1.9-RC1/changes-report.html
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
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
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
, 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
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
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
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
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
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) {
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-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-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-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
601 - 700 of 1221 matches
Mail list logo
