This is Gump running on commons-graph for the first time it has
re-entered the Sandbox.
I've set it up to run mvn2's install goal on trunk of commons-graph.
vmgump runs openjdk6.
Stefan
-
To unsubscribe, e-mail:
Hi all,
I've been working on COMPRESS-183 which is a more general version of
COMPRESS-114 we fixed a while ago. It asks for support of non-ASCII
file names in tar archives by using an explicit encoding (COMPRESS-114
made things work for ISO-8859-1 and any other encoding that creates the
same
Hi all,
Compress' trunk has been sitting on valuable content for too long now:
* XZ compression
* BZIP2 now reads streams created by pbzip2 (parallel bzip2)
* TAR has been largely improved to support reading and writing big
files, old files and files with long names - as well as encodings
On 2012-03-31, sebb wrote:
There are a few places where the default charset is being used.
It's not clear whether these are intentional or not, so I have marked
them with TODOs.
Thanks (and thanks for the other fixes as well).
We should either document that the default is OK, or use a fixed
On 2012-03-31, Christian Grobmeier wrote:
Before ages when I wrote the ChangeSet stuff I have marked them as
experimental. Have not heard any complains yet... we should discuss
if we remove that label or if need some more tweaks there. Probably
after 1.4?
I must admit I've never used that
On 2012-03-31, Gary Gregory wrote:
The trunk looks good now IMO. I'll let others decide about the change set
docs.
The only item that stick out but could wait for another release:
- the large code dup in BZip2CompressorInputStream as noted by CPD.
I've seen that but must admit I didn't see
On 2012-04-01, Ralph Goers wrote:
I have real problems with Gump. I find it very difficult to determine
what the problem actually is much less diagnose it. Other than that I
know it is supposed to be using the latest source in trunk it is tough
to figure out how to reproduce a problem as it
On 2012-04-01, Ralph Goers wrote:
From the vfs2 log it looks like it is running into a binary
incompatibility with SLF4J. vfs2 is specifying SLF4J 1.5.5 but mvn
dependency:tree is showing me that Jackrabbit is referencing
jcl-over-slf4j and is using 1.5.3. I've added that to the vfs2 pom in
On 2012-04-01, Christian Grobmeier wrote:
On Sun, Apr 1, 2012 at 7:01 AM, Stefan Bodewig bode...@apache.org wrote:
On 2012-03-31, Christian Grobmeier wrote:
Before ages when I wrote the ChangeSet stuff I have marked them as
experimental. Have not heard any complains yet... we should discuss
Hi all,
as indicated last weekend Compress' trunk has accumulated so much new
goodness it requires a new release.
Tarballs of Compress 1.4 RC1 are available here
http://people.apache.org/~bodewig/commons-compress-1.4RC1/
Maven artifacts are here:
On 2012-04-05, sebb wrote:
On 4 April 2012 21:00, Stefan Bodewig bode...@apache.org wrote:
http://people.apache.org/~luckyrm/foo-1.2-RC1/site/
Does not exist; looks like a left-over from an e-mail template.
*blush* - sorry. A bit too much copy-paste 8-)
Stefan
On 2012-04-05, Emmanuel Bourg wrote:
The new Charsets class in the utils package is not used by the code. I
think it should be removed from the API. I'd would also argue that
CharsetNames has not its place in [compress], I would rather stick to
strings and rely on [io] or [lang] to provide an
On 2012-04-05, Emmanuel Bourg wrote:
The new Charsets class in the utils package is not used by the code. I
think it should be removed from the API. I'd would also argue that
CharsetNames has not its place in [compress], I would rather stick to
strings and rely on [io] or [lang] to provide an
Oops, I never voted explicitly.
On 2012-04-04, Stefan Bodewig wrote:
as indicated last weekend Compress' trunk has accumulated so much new
goodness it requires a new release.
Tarballs of Compress 1.4 RC1 are available here
http://people.apache.org/~bodewig/commons-compress-1.4RC1
Hi all,
the vote has passed with six +1s (sebb, Gary, Oliver, Torsten, Jörg and
myself) and no other votes. I'll now proceed with the release process.
Stefan
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For
.
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
[1] http
On 2012-04-16, ggreg...@apache.org wrote:
[IO-324] Add Charset sister APIs to method that take a String charset name.
The new methods cause problems for people who pass in null for the
charset as they want the platform's system default. The compiler
doesn't know which of the writeStringToFile
On 2012-05-21, sebb wrote:
FIxed
Thanks!
When merging the changes to Ant I ran into conflicts and resolved one
hunk the wrong way around by accident (and didn't realize I was changing
more than the comments on the subsequent commit).
For some reason I also missed the Continuum build failure.
Hi all,
I'd like to release Compress 1.4.1.
Compress 1.4.1 RC1 is available for review here:
http://people.apache.org/~bodewig/cc/
Maven artifacts are here:
https://repository.apache.org/content/repositories/orgapachecommons-111/org/apache/commons/commons-compress/1.4.1/
Details
On 2012-05-22, Stefan Bodewig wrote:
I'd like to release Compress 1.4.1.
Compress 1.4.1 RC1 is available for review here:
http://people.apache.org/~bodewig/cc/
The tag is here:
https://svn.apache.org/repos/asf/commons/proper/compress/tags/COMPRESS_1.4.1_RC1/
Votes, please
On 2012-05-22, Gary Gregory wrote:
[X] -0 OK, but really should fix...
- The logo is missing its TM per Apache branding requirements.
The commons compress logo in the upper right corner? It is the same
logo as the one that's currently online.
Anyway, we can fix the site independent of any
On 2012-05-22, Gary Gregory wrote:
I fixed the logo in SVN ;)
Great, thanks
Stefan
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Hi all,
the vote has passed with +1s by Luc, Christian, Oliver and myself.
I'll now go ahead and publish the tarballs.
Stefan
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail:
On 2012-07-08, sebb wrote:
On 7 July 2012 20:34, bode...@apache.org wrote:
Modified:
commons/proper/compress/trunk/src/main/java/org/apache/commons/compress/archivers/ArchiveStreamFactory.java
+private String entryEncoding = null;
The class is currently tagged as:
* @Immutable
This
Hi all,
COMPRESS-202 and COMPRESS-206 only talk about TAR but something similar
aplies at least to ZIP as well: once we detect that an archive doesn't
contain any more entries, we stop reading the input stream, even if it
contains more stuff that is part of the archive. This causes problems
for
Hi Julius,
can you please record the changes in src/chanhes/changes.xml as well -
and add yourself as developer to the POM if you feel like it?
Thanks
Stefan
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
On 2013-01-08, Gump wrote:
at java.lang.Short.parseShort(Short.java:143)
at
org.powermock.modules.junit4.common.internal.impl.VersionCompatibility.getJUnitVersion(VersionCompatibility.java:40)
...
initializationError(org.apache.commons.mail.MultiPartEmailTest): Value out
of
On 2013-01-08, Thomas Neidhart wrote:
I would like to keep powermock, but we could disable the tests in question
until the version format changes?
We can split the commons-email build into two - one that builds and one
that runs the tests - and disable nagging for the test build until the
On 2013-01-09, Julius Davies wrote:
On Mon, Jan 7, 2013 at 9:16 PM, Stefan Bodewig bode...@apache.org wrote:
can you please record the changes in src/chanhes/changes.xml as well -
and add yourself as developer to the POM if you feel like it?
Thanks for the tip. Done!
Great, thanks
On 2013-01-10, Gary Gregory wrote:
The new HDFS provider only works on Linux and it works for me on Ubuntu
(via VirtualBox on Win7). How can Gump be fixed?
vmgump is Ubuntu 10.04 which may be too old, we also have FreeBSD and
MacOS nodes.
One option may be to Check for the proper environment
On 2013-01-10, Julius Davies wrote:
This is one my unit tests that I recently added that's failing.
They fail on my machine as well (GMT+1 right now) and create times one
hour different from vmgump which runs in GMT.
The times that are different from the expected times are the times taken
On 2013-01-11, Stefan Bodewig wrote:
On 2013-01-10, Julius Davies wrote:
This is one my unit tests that I recently added that's failing.
They fail on my machine as well (GMT+1 right now) and create times one
hour different from vmgump which runs in GMT.
The times that are different from
On 2013-01-11, Stefan Bodewig wrote:
In particular I didn't try a system where DST is active on new years
day - the test likely needs to take this into account as well.
I've modified the test further so I think it should now work for
regions with DST in January as well.
Stefan
On 2013-01-17, Torsten Curdt wrote:
If we see `getNextEntry` return null we should position the stream at
the end of the archive. I think that's your (1). Sounds simpler and
more straight forward from an API POV. IIUC that reading should only
be a few bytes. A second EOF marker for TAR for
On 2013-01-17, Bear Giles wrote:
I think a number of applications use a concatenation of a standard archive
format and custom data.
Absolutely, and I think we should support that use-case.
I'll try to free up some coding time this weekend.
Stefan
Hi all,
I've just published the compress site using mvn site-deploy.
The process failed to commit the modified site since it couldn't
authenticate itself. This is likely due to the fact that svn doesn't
store my password - is there any way to tell the
maven-scm-publish-plugin that it should
On 2013-03-03, Stefan Bodewig wrote:
I've then committed the changes manually (in fact, the process is still
going on) - is there anything the plugin would do after that or is the
process finished?
at least the site looks OK to me now.
Stefan
Hi all,
Compress has about 25 fixed JIRAs since the last release, most of which
are bug fixes - some of them pretty serious.
I'd like to cut a 1.5.0 release sometime this coming week.
Any objections, anything anybody is working on that I should wait for?
Cheers
Stefan
On 2013-03-03, sebb wrote:
On 3 March 2013 17:20, Stefan Bodewig bode...@apache.org wrote:
I'd like to cut a 1.5.0 release sometime this coming week.
OK by me, but note that the dist/ deployment process is currently
changing ...
Yes, thanks, I'll be looking out for it. The migration
Hi all,
[took me a few days longer since I wanted to incorporate fixes for the
two issues that popped up last week. So here we go.]
With 30 JIRA issues fixed it is about time to cut a new release of
Commons Compress.
Tarballs:
http://people.apache.org/~bodewig/cc-1.5/
Maven artifacts
http://svn.apache.org/viewvc/commons/proper/compress/tags/COMPRESS-1.5_RC1/
On 2013-03-11, Gary Gregory wrote:
The tag is wrong, it is:
http://svn.apache.org/repos/asf/commons/proper/compress/tags/COMPRESS-1.5_RC1
Right. I copy-pasted the example vote mail from the compress site and
it also
On 2013-03-11, sebb wrote:
Minor nit: the addition of implements Serializable to ZipLong,
ZipShort and ZipEightBightInteger is not documented in the Javadoc.
Is there a formal way to document implements Foo since 1.5 other than
free form text in a class level comment? I'd like to add it in
On 2013-03-11, Gary Gregory wrote:
- Some (maybe not all) of the PMD/CPD issues seems easy to fix
At least the CPD one looks easier than it is - it uses a lot of
variables that are mutated and used outside of the block.
Many of the PMDs have reasons as well like overriding equals when not
On 2013-03-11, Benedikt Ritter wrote:
I've noticed, that the src archives differ from the RC tag. The following
files are missing:
.gitattributes
.gitignore
doap_compress.rdf
PROPOSAL.txt
Is this intended?
In a way, yes. They are not listed inside the assembly descriptor. The
.git
On 2013-03-11, sebb wrote:
On 11 March 2013 06:10, bode...@apache.org wrote:
Author: bodewig
Date: Mon Mar 11 06:10:51 2013
New Revision: 1455005
URL: http://svn.apache.org/r1455005
Log:
Tagging first RC for Compress 1.5
Please don't recreate a tag with the same name.
If you need to
On 2013-03-12, sebb wrote:
The DOAP files are currently held under
/commons/proper/component/trunk/doap_component.rdf
This is sort of convenient for editting, but means the doap file gets
included in tags and branches and may get included in source.
If included in source, the release date
The vote has passed with +1s by Gary, Sebb, Benedict, Jörg and myself
(which I didn't cast expplicitly, sorry) - four of which are binding.
I'll promote the staging and copy over the tarballs now. I'll update
the site and send out the announcement later today once the mirrors have
picked up the
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.4.9 (GNU/Linux)
iEYEARECAAYFAlFCA
On 2013-03-14, Gary Gregory wrote:
In the past, I've have felt (disgusted is too strong a word) discouraged
from releasing often by the our release process, and it's a 'process' all
right. First, I had started to follow:
https://commons.apache.org/releases/index.html
but finding it
Hi all,
I've started to update the releasing page in the staging area - not
much, yet, will take time - and stumbld over the commons.rc.version
property.
I've set it by adhering to our guidelines but never asked myself why I
was doing so. Now that I try to update the docs I'm trying to
On 2013-03-17, sebb wrote:
a name=Manual Methodh4Manual Method/h4/a
Surely names are normally lower-case only and no spaces?
I think spaces make the links look odd (and awkward to type).
Uses the same syntax as the mvn site plugin created for subsection now
(with s/h3/h4/), i.e.
On 2013-03-18, William Speirs wrote:
On Sun, Mar 17, 2013 at 5:34 PM, sebb seb...@gmail.com wrote:
Maven artifacts are here:
http://people.apache.org/~wspeirs/commons-dbutils-2.0-RC1/maven
Maven artifacts must be uploaded to Nexus.
How do I do this? I was following the directions here:
On 2013-03-21, Gary Gregory wrote:
Some links are broken like:
https://commons.apache.org/proper/releases/index.html
Does anyone else see this?
Where is this page linked from? Releases from the main nav points to
https://commons.apache.org/downloads/index.html
Stefan
On 2013-03-22, sebb wrote:
On 19 March 2013 17:05, sebb seb...@gmail.com wrote:
Commons is currently still publishing mon-Maven releases from
people.a.o dist/commons.
There is an outstanding JIRA issue for this to be changed to svnpubsub:
https://issues.apache.org/jira/browse/INFRA-5929
On 2013-03-22, sebb wrote:
I don't know whether you want to mention the dist/dev tree - that can
be used for staging releases instead of a user's home directory.
Yes, that's what we do in Ant and I wanted to mirror that experience.
I'm not sure where I'd recommend to put the staging website,
Hi,
I've just updated the releasing guide up to the point in time where the
release vote happens. It covers publishing via Nexus and svnpubsub for
releases. This has not been published, yet:
http://commons.staging.apache.org/releases/prepare.html
Feedback and corrections more than welcome.
On 2013-03-23, Phil Steitz wrote:
I have one question: I have not cut a release in a while and was
always able before to avoid Nexus and the maven release plugin. I
understand now there is no way around using these. First, that is
correct, right?
There is no way around Nexus. I haven't
On 2013-03-23, Stefan Bodewig wrote:
I'll start working on the follow-up document soonish.
Now also done: http://commons.staging.apache.org/releases/release.html
Please review it and correct my mistakes before the site gets published.
Stefan
On 2013-03-28, Emmanuel Bourg wrote:
Hi,
I just noticed that for the recent releases the source and binary
packages have been published in the Maven repository. I saw that with
fileupload 1.3 and daemon = 1.0.11.
Is this a standard practice?
I would hope it is not. When I released
On 2013-04-04, Mladen Turk wrote:
So it seems the gpg-sign plugin in #28 uses gpg differently. And it
seems running gpg-agent is needed and sloves the issue. Just in case
someone else bumps into that.
Could you add this piece of knowledge to
On 2013-04-23, sebb wrote:
As to the (non-Maven) tarballs: another approach would be to create them in
Nexus as per usual, but move them (copy/delete) to the svnpubsub staging
area [1] before the vote starts.
It would make the reviewers job slighly harder - one extra URL to download
and
On 2013-05-06, Damjan Jovanovic wrote:
I've been hacking on a patch that adds support for reading 7zip archives.
COMPRESS-54 is the most popular issue so you'd make quite a few people
happy.
You are talking about read-only suppport, right?
AFAIR there've been either legal/license or technical
Hi
I've rushed through Damjan's addition of (readonly) 7z and really like
it. It might need some more docs but it is a great start. There are
quite a few FIXMEs that we may want to address in one way or another.
As for LZMA compression, the required code in XZ for Java's lzma
subpackage
On 2013-05-12, Damjan Jovanovic wrote:
On Sun, May 12, 2013 at 12:34 PM, Stefan Bodewig bode...@apache.org wrote:
I'm off to read the format spec so I can have a more detailed look.
The 7zFormat.txt in 7z920.tar.bz2 is more up-to-date than the one in
lzma920.tar.bz2, but neither
On 2013-05-12, Damjan Jovanovic wrote:
On Sun, May 12, 2013 at 4:27 PM, Damjan Jovanovic damjan@gmail.com
wrote:
On Sun, May 12, 2013 at 12:34 PM, Stefan Bodewig bode...@apache.org wrote:
As for LZMA compression, the required code in XZ for Java's lzma
subpackage doesn't lend itself
Hi,
over in Ant land a bug was raised that points at a problem in ZipFile
(Commons Compress' zip package is a fork of Ant's code and I try to keep
them in sync).
When an archive contains duplicate entries - which is totally valid in
ZIPs - ZipFile's getEntry can sometimes return ZipArchiveEntry
On 2013-05-20, sebb wrote:
On 20 May 2013 16:48, Stefan Bodewig bode...@apache.org wrote:
I've for now fixed it in trunk by ignoring all but the last entry od the
same name seen while parsing the central directory. I've chosen to pick
the last since this is what ZipFile used to do
On 2013-05-28, Gary Gregory wrote:
On Tue, May 28, 2013 at 2:08 PM, sebb seb...@gmail.com wrote:
On 25 May 2013 18:47, bode...@apache.org wrote:
+ import java.util.Deque;
That requires Java 1.6; Compress currently targets 1.5
Well, let's change the requirement to Java 6 for Compress 1.6.
On 2013-05-29, s...@apache.org wrote:
Unnecessary @SuppressWarnings(unchecked) - these are not used for casts
javac was whining until I added them, strange.
Stefan
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
On 2013-05-29, sebb wrote:
On 29 May 2013 05:13, Stefan Bodewig bode...@apache.org wrote:
On 2013-05-28, Gary Gregory wrote:
On Tue, May 28, 2013 at 2:08 PM, sebb seb...@gmail.com wrote:
On 25 May 2013 18:47, bode...@apache.org wrote:
import java.util.Deque;
That requires Java 1.6
Hi,
in compress I've added a method to ZipFile that provides access to a
subset of the entries. It already contained a method returning an
Enumeration of all entries - Enumeration as it mimics java.util.ZipFile
which was invented in Java 1.0.
For this new method I've chosen to return an
On 2013-06-03, Gary Gregory wrote:
Why not have the class implement Iterable?
Oh, I'm returning just a subset, so making the whole class iterable
doesn't make sense. I'm talking about
public IteratorZipArchiveEntry getEntries(String name)
Stefan
PS: For the general case of all entries
On 2013-06-03, Matt Benson wrote:
On Mon, Jun 3, 2013 at 9:15 AM, Jörg Schaible
joerg.schai...@scalaris.comwrote:
Emmanuel Bourg wrote:
Le 03/06/2013 13:44, Stefan Bodewig a écrit :
My personal preference would be Iterable as well as the consumer may
iterate over the return value
Hi all,
Lasse Collin has added LZMA read support to XZ for Java in its git
master branch. Given XZ for Java doesn't publish SNAPSHOT releases it
one has to install it manually so I'll create a branch that we can merge
back once XZ has a new release.
Stefan
Here is how I installed my own
Hi,
when I added support for decompressing .lzma files I left out matches()
and you can only get an LZMACompressorInputStream from
CompressorStreamFactory if you use the version that explicitly specifies
the format.
The reason is that the old .lzma format doesn't have any sort of
signature at
On 2013-06-10, Damjan Jovanovic wrote:
The problem is not unique to LZMA, and since LZMA can contain almost
any bytes at the beginning, it could also be misdetected as another
compression format.
Right, that's why I suggested to put LZMA detection at the end, if at
all.
If we can't
On 2013-06-10, Emmanuel Bourg wrote:
Le 10/06/2013 11:02, Torsten Curdt a écrit :
Of course we could be user friendly and add the heuristic but that's
like opening a can of worms.
I agree. And considering the format has been deprecated in favor of xz I
wouldn't worry too much.
Sounds like
On 2013-06-12, Bear Giles wrote:
What is the status on strong encryption in zip files? That is - I know we
don't have it, but is there a reason why it hasn't been added or is it just
an itch that hasn't been scratched?
I can see several levels of values
1. add ZipExtraField handlers for
On 2013-06-12, Siegfried Goeschl wrote:
Hi folks,
don't know if this was already mentioned but providing strong
encryption causes administrative head-ache
Actually, it doesn't. All that has to be done, is editing a page in the
CMS, adding a notice to the README and sending a single email.
On 2013-06-13, Stefan Bodewig wrote:
Hmm, we already have AES support in the new 7z package. I'll take
care of the crypto policy stuff.
Done, the ECCN page has been updated and the notice sent.
Stefan
-
To unsubscribe, e
On 2013-06-17, Bear Giles wrote:
I also don't want to post code snippets here if it will cause people
problems.
IANAL but I don't think posting snippets would have caused problems for
anybody.
Anyway, I've notified the crypto folks of the US government since we
already do AES in the 7zip
Dear Community
Apache Gump builds some of your projects and it is quite possible you
don't know or have by now forgotten about it.
More than half a year ago a technical problem has forced us to turn off
emails on build failures as we would have been sending out lots of false
alarms.
Before we
On 2013-07-20, dam6923 . wrote:
I am a big fan of the commons VFS and commons compress libraries. I
use them a lot of work and have been real time savers. Having dug
through the code of commons compress, I noticed a big TODO comment
about the TarInputStream#skip() method. I have corrected
On 2013-07-20, dam6923 . wrote:
So, I'm fairly new to the world of compression implementations. Is
ZLIB (RFC 1950) supported by the current COMPRESS library?
No.
If not, perhaps we can borrow from APACHE MINA?
From what I can tell the use jzlib which lives in the jsch SSH ecosystem
and
On 2013-08-07, ebo...@apache.org wrote:
Author: ebourg
Date: Wed Aug 7 13:52:00 2013
New Revision: 1511316
URL: http://svn.apache.org/r1511316
Log:
Changed the return type of CpioArchiveInputStream.getNextEntry() to avoid
casting to CpioArchiveEntry
please don't. Let's leave that for
On 2013-08-07, ebo...@apache.org wrote:
-public BZip2CompressorInputStream(final InputStream in,
- final boolean decompressConcatenated)
-throws IOException {
-
+public BZip2CompressorInputStream(final InputStream in, final boolean
On 2013-08-07, Emmanuel Bourg wrote:
Le 07/08/2013 17:15, Stefan Bodewig a écrit :
I'm not sure whether we have any policy on this, but so far I've tried
to stick with 80 columns max. Maybe that's a sign of me being old
fashioned, don't know :-)
80 columns is quite restrictive
Hi,
while working on the Zip64 stuff I deliberately created some invalid
archives to test I get the expected exceptions. While doing so I
realized I couldn't close the underlying stream because
ZipArchiveOutputStream's close would throw an exception as finish()
failed before ever closing the
On 2011-08-15, sebb wrote:
/home/continuum/continuum-base/data/working-directory/64/src/main/java/org/apache/commons/compress/archivers/dump/DumpArchiveException.java:[38,8]
cannot find symbol
symbol : constructor IOException(java.lang.Throwable)
That's Java 1.6+
Yes, will fix it in one of
On 2011-08-15, sebb wrote:
On 15 August 2011 09:56, Stefan Bodewig bode...@apache.org wrote:
Hi,
while working on the Zip64 stuff I deliberately created some invalid
archives to test I get the expected exceptions. While doing so I
realized I couldn't close the underlying stream because
On 2011-08-17, bay...@apache.org wrote:
Propchange: commons/trunks-proper/
--
--- svn:externals (original)
+++ svn:externals Wed Aug 17 04:25:55 2011
@@ -2,6 +2,7 @@ attributes https://svn.apache.org/repos/
bcel
On 2011-08-17, sebb wrote:
On 17 August 2011 03:42, Stefan Bodewig bode...@apache.org wrote:
On 2011-08-15, sebb wrote:
For input, there might be a use case for leaving the stream open, in
case some kind of recovery is possible.
It would be useful to have a way of determining the input
Hi,
with svn revision 1158060 the bcel.generic.Visitor interface has become
package private, breaking the Gump builds of Xalan XSLTC,
commons-javaflow and likely other downstream code.
Has this change been intentional?
Stefan
On 2011-08-17, Honton, Charles wrote:
Why guard against closing System.in? If the client application needs that
sort of functionality, it should wrap the incoming stream in a proxy that
doesn't delegate the close method to the underlying stream.
You and I agree here - there even has been a
Hi,
I've just committed Converter*Stream implementations for Pack200[1]
which is a bit unusual in several ways.
First of all it will (by design of the format) only work on compressing
valid jar files. Actually the result isn't likely to be compressed (in
the sense of smaller than the original)
On 2011-09-04, sebb wrote:
You must have put a lot of thought into this
Well, I was without network access for almost two weeks 8-)
it would be useful to record these design decisions and investigations
in the code somewhere. e.g. as package Javadoc.
The current package.html already
On 2011-09-05, Emmanuel Bourg wrote:
That looks interesting. Does it provide a repack mode suitable for
signing compressed jars?
I assume you mean
,
| Note that packing and unpacking a JAR will in general alter the bytewise
| contents of classfiles in the JAR. This means that packing and
On 2011-09-09, Oliver Heger wrote:
After the version number in pom.xml was changed to 1.8-SNAPSHOT the
gump build fails. IIUC, it still searches for a jar ending in
1.7-SNAPSHOT.
I had a look at the gump descriptor in commons-proper.xml, but I did
not find a place where the version number
On 2011-09-05, Stefan Bodewig wrote:
On 2011-09-05, Emmanuel Bourg wrote:
That looks interesting. Does it provide a repack mode suitable for
signing compressed jars?
I assume you mean
,
| Note that packing and unpacking a JAR will in general alter the bytewise
| contents
On 2011-09-05, Stefan Bodewig wrote:
On 2011-09-05, Emmanuel Bourg wrote:
That looks interesting. Does it provide a repack mode suitable for
signing compressed jars?
I assume you mean
,
| Note that packing and unpacking a JAR will in general alter the bytewise
| contents
1 - 100 of 1182 matches
Mail list logo
