On 2013-10-23, Emmanuel Bourg wrote:
The test coverage is much better, thank you Stefan.
Thank you for making me find a serious bug by pointing out the low
coverage :-)
test7zDecryptUnarchive failed on Linux using the Java 6 JDK (not
OpenJDK6) due to the lack of the strong crypto policy.
On 2013-10-23, Jörg Schaible wrote:
boolean supportedKeyLength(int keyLen) throws NoSuchAlgorithmException
{
if (Cipher.getMaxAllowedKeyLength(AES/ECB/PKCS5Padding) keyLen) {
System.err.println(WARNING: + getName()
+ not executed, environment does not support + keyLen
On 2013-10-23, Bear Giles wrote:
Should that be PKCS7Padding? Or would that be worse - I don't recall
if it's one of the must have paddings in the spec.
7z uses AES/CBC/NoPadding and that's what I use during the check
inside the unit tests as well now.
Stefan
On 2013-10-23, Paul Benedict wrote:
In my own research on strong crypto, I found out that US law allows
strong crypto to be exported for open source software. That was some
provision recently carved out in the last 10 years. I think there are
some limitations and procedures wrapped around it
On 2013-10-23, Gary Gregory wrote:
Consider using JUnit's Assume to skip testing, this will allow IDEs and
tools to know a test has been skipped.
Unfortunately the test like many of Compress' tests is in JUnit 3.x land
- something to change if we ever get 2.x off the ground.
Stefan
On 2013-10-23, Mark Fortner wrote:
As you're probably aware, aes is export restricted.
Commons Compress already has a crypto notice, see also
http://www.apache.org/licenses/exports/
7z uses 256bit AES when encrypting so if we want to provide code that
can read encrypted archives there is
On 2013-10-22, Mark Thomas wrote:
On 22/10/2013 08:12, Emmanuel Bourg wrote:
Le 22/10/2013 00:33, Mark Thomas a écrit :
On 21/10/2013 23:31, Emmanuel Bourg wrote:
Thatis using Fileupload as a noun which isn't the correct usage of the
trademark.
But how is it different from Apache Tomcat
On 2013-10-21, Gary Gregory wrote:
On Mon, Oct 21, 2013 at 11:11 AM, Stefan Bodewig bode...@apache.org wrote:
at the same time I'll update the release notes to reflect the potential
backwards incompatible change as well.
OK, sounds good. I'll look forward to the next RC.
See http
On 2013-10-22, Gary Gregory wrote:
On Tue, Oct 22, 2013 at 11:02 AM, Stefan Bodewig bode...@apache.org wrote:
On 2013-10-21, Gary Gregory wrote:
On Mon, Oct 21, 2013 at 11:11 AM, Stefan Bodewig bode...@apache.org
wrote:
at the same time I'll update the release notes to reflect
of changes since 1.5 are in the release notes:
http://people.apache.org/~bodewig/cc-1.6-rc3/RELEASE-NOTES.txt
http://people.apache.org/~bodewig/cc-1.6-rc3/site/changes-report.html
The tag is here:
https://svn.apache.org/repos/asf/commons/proper/compress/tags/COMPRESS-1.6-RC3/
(svn
Hi,
while writing additional tests I found SevenZOutFile wasn't handling
directories correctly - or rather its handling of anything empty isn't
correct.
I'll add new tests, fix the implementation and re-roll another RC -
at the same time I'll update the release notes to reflect the potential
On 2013-10-15, Stefan Bodewig wrote:
Please review the release candidate and vote.
+1
[making my own vote explicit]
Stefan
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h
On 2013-10-16, Gary Gregory wrote:
Now that we have a new cleaned up RC, I want to make sure that we
understand that, strictly speaking and while unlikely in practice,
1.6-RC2 breaks binary compatibility with 1.5 (see Clirr). I think we
started discussing this and after some hand-waving some
Hi
I'm going to address Dave's three mails in a single response
dam6923 . wrote:
In SevenZFile.java
Constructor...
1) Close file on exception instead of the current technique of keeping
a succeeded flag.
This means I have to catch and rethrow the exception. I don't think I
like this
On 2013-10-15, Stefan Bodewig wrote:
But we probably should store the password as a char[] anyway
s/char/byte/
Stefan
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h
On 2013-10-14, Henri Yandell wrote:
These are all sitting in our pull request queue:
https://github.com/apache/commons-lang/pulls?direction=descpage=1sort=createdstate=open
Not all are open, I know #1 is in the code but I don't know how to close
the requests.
In a similar situation in Ant
On 2013-10-14, Oliver Heger wrote:
Am 14.10.2013 06:11, schrieb Stefan Bodewig:
On 2013-10-13, Oliver Heger wrote:
When I build the site locally, I get a different clirr report showing 9
errors because some public methods have been made final.
Strange. Why would Clirr create different
On 2013-10-13, Gary Gregory wrote:
+1
Thanks.
BUT the following are not blockers but should be improved if another RC is
cut:
- Low (27%) code coverage for the new class
Hi all
in the recent release vote for Compress Gary and I had very different
opinions on the importance of the site build for release candidates.
On 2013-10-13, Gary Gregory wrote:
On Sun, Oct 13, 2013 at 1:31 AM, Stefan Bodewig bode...@apache.org wrote:
I have not created a RC website
On 2013-10-13, Phil Steitz wrote:
I am sorry. I forgot one other thing to verify. The clirr report
complains about dropping a field. Is this spurious / not really an
issue?
Ah yes, I should have talked about that.
It is a protected field in the Tar*Stream classes which should have
never
On 2013-10-13, Oliver Heger wrote:
The artifacts look good, the build works fine with Java 1.7 on Windows
7. I tried to build with Java 1.5, but got:
Tests in error:
SevenZTestCase.testSevenZArchiveCreationUsingLZMA2:37-testSevenZArchiveCreati
on:59 ╗ OutOfMemory
I think enough issues have been identified to warrant a second RC.
I'll take care of the bad version number in the release notes as well as
the PMD warnings in the ARJ-Package. ArjArchiveEntry's test coverage
has already been increased in trunk.
We should talk about the Clirr report further and
On 2013-10-14, sebb wrote:
On 9 October 2013 05:43, Stefan Bodewig bode...@apache.org wrote:
why vote on Nexus staged artifacts if the tarball is fine? I'm not
talking about releasing to MC directly but rather about not pushing
anything to Nexus before the vote on the tarball has passed
Hi
since Compress 1.5 we've fixed a few bugs but most notably added
read-only support for LZMA standalone, uncompressed ARJ and full support
for 7z.
I have not created a RC website as the only difference to the current
website would be the download page and the version number - and I'd
Hi all,
I've made some progress:
On 2013-10-11, bode...@apache.org wrote:
Author: bodewig
Date: Fri Oct 11 09:13:42 2013
New Revision: 1531235
URL: http://svn.apache.org/r1531235
Log:
add bzip2/deflate compression support when writing 7z archives
Unfortunately LZMA2OutputStream
On 2013-10-11, Stefan Bodewig wrote:
Unfortunately LZMA2OutputStream is not public in XZ for Java
But LZMA2Options#getOutputStream is - looks as if there was a way.
Stefan
-
To unsubscribe, e-mail: dev-unsubscr
On 2013-10-11, Emmanuel Bourg wrote:
The parent pom currently attaches the -bin and -src archives to the
deploy phase, which means we have to delete them manually in Nexus.
Can we agree to change that?
Sebb did some investigation back in May, I think. IIRC this implies
they won't get signed
On 2013-10-06, Stefan Bodewig wrote:
Should go into the release:
* support for writing compressed 7z archives. In particular I'd love to
have SevenZOutputFile default to LZMA2 compression with the release.
* look into and potentially fix date and permission handling issues in
arj
On 2013-10-11, Matt Benson wrote:
We're all still talking about the release process, but in all honesty I've
not done it for several years at Commons. I think it would be immensely
helpful for those of us who have been at least part way through the process
fairly recently (Emmanuel, Gary,
On 2013-10-08, Emmanuel Bourg wrote:
Le 07/10/2013 20:14, Benedikt Ritter a écrit :
- loosen API compatibility policy?
This topic alone deserves its own thread I think.
Ensuring binary/source compatibility is very important.
+1
I guess I've done too much ruby with every bundle update
On 2013-10-08, James Carman wrote:
How about this for an idea? What if instead of waiting until *after*
a new JDK comes out (and in some cases MANY years later), we start
with pre-release versions in a branch or something to start using the
new language features?
Maybe I'm just naive, but
compatibility
is simple and makes sense.
It's OK to put some burden on the users when upgrading - as long as the
expectations are set correctly.
But I am pretty sure we discussed that before and some people did not
agree.
cheers,
Torsten
On Tue, Oct 8, 2013 at 12:08 PM, Stefan Bodewig bode
On 2013-10-08, James Carman wrote:
I am not saying we rule it out or anything. I'm talking about ideas
that could be fun. I don't remember us ever doing something like
that.
Well, my vision is somewhat narrow as I tend to stay in my little corner
in compress and only occasionaly lurk
On 2013-10-08, Benedikt Ritter wrote:
you are involved in other projects (like log4j2) how do they do it? Is
it easier to release log4j2 than it is to release for example [lang]?
Over the past year I've cut releases at the ASF for Commons Compress,
Ant and log4net and outside of the ASF of a
On 2013-10-01, Damjan Jovanovic wrote:
On Tue, Oct 1, 2013 at 6:09 AM, Stefan Bodewig bode...@apache.org wrote:
Reading may be simpler, here you can store the meta-information from the
start of the file in memory and then read entries as you go, ZipFile
inside the zip package does something
Hi all
we've already had users asking for a new release - in particular because
of 7z support.
From the top of my head there are two things I'd like to address before
the release and one that would be nice but I know I won't find time to
look into.
Should go into the release:
* support for
On 2013-10-06, Stefan Bodewig wrote:
* look into and potentially fix date and permission handling issues in
arj.
done - inside the Ant compress antlib I now have archives created on
Windows and Linux and I get the correct date/time on both of them - one
has to consider the OS flag describing
On 2013-10-06, Gary Gregory wrote:
In general I like the release early, release often model.
I don't think we differ here. But before we cut a release we should be
happy with the APIas we'll be forced to live with that for some time.
Stefan
On 2013-10-06, James Carman wrote:
Version numbers are cheap.
Again, no argument.
I wonder where you or Gregory got the idea it could be different.
All I said was here is my list of things I intend to do - which
contained two items and one of them has been done five hours later - and
asked
On 2013-09-30, Benedikt Ritter wrote:
2013/9/30 Stefan Bodewig bode...@apache.org
I'm in no way as familiar with the format as Damian is but IMHO it is
feasible - but likely pretty memory hungry. Even more so for the
writing side. Similar to zip some information is stored in a central
Hi all,
over this weekend I added 7z support to the compress antlib which I also
like to use as a second testbed for Commons Compress - I even found a
bug for archives that only contain empty directories.
The antlib is based on the interface provided by Archive*Stream even
when it is not using
On 2013-09-29, Torsten Curdt wrote:
Hm - it is indeed a little misleading. So I am +0 for an inclusion.
This is what I feel as well.
Is a stream based implementation of 7z somewhat feasible - at least in
theory?
I'm in no way as familiar with the format as Damian is but IMHO it is
feasible
On 2013-09-22, Jie CDL Zhang wrote:
This is Calvin from IBM. I am making a product that need to use the 7z
archive function. I am very lucky to find that commons-compress supports
it! But the bad news is the latest release 1.5 does not contain those part.
How can I get a new release jar file
On 2013-09-22, Stefan Bodewig wrote:
One thing holding up the release is that I personally would love to have
LZMA support for 7z in as well - this is the compression method used for
header fields by default and without it 7z support is pretty much
limited. This one depends on XZ for Java
On 2013-09-20, Matt Benson wrote:
I hereby propose a vote to promote the [weaver] sandbox component to
Commons proper.
+1
Stefan
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands,
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
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-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
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-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
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-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-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
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
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
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
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-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
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-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
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-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
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-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-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-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-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-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-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:
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
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,
[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
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
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
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
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-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
701 - 800 of 1221 matches
Mail list logo
