The javadoc and source JARs are expected to be in the Maven repo.
I'm not saying we should delete those.
However the bin and src zip and tar.gz archives are not supposed to be
in the Maven repo.
These at least triple the storage space required. For releases that
include bz2 archives as well
1) copy the released artifacts to the dist directory
(/x1/www/www.apache.org/dist/commons) on people.apache.org
Wasn't that step 1 in your list?
Yes but I cannot find the place from which I can copy from Nexus to
the dist folder.
I searched whole people server... so, where are the nexus
On Tue, Aug 17, 2010 at 12:06 PM, Christian Grobmeier
grobme...@gmail.com wrote:
Interesting... were is this content from? Has this been grabbed by
nexus automatically?
That's what we had been discussing initially. The projects I am aware
of are building the source and binary distributions
Which means:
1) I will copy it to apache dist from my local box to people
2) push the release button on nexus
You're free to do so. My personal procedure is to use wget -np -r
disturl to copy the files from the repository to the dist folder on
people.apache.org. Some shifting and removing
Thanks for voting!
This vote passed with 6x +1, 4 of them binding:
Binding:
- Oliver Hegner
- Torsten Curdt
- Stefan Bodewig
- Sebastian Bazley
Nonbinding:
- Jukka Zitting
- Christian Grobmeier
I will prepare the go-live the next time.
Best regards
Christian
On Fri, Aug 13, 2010 at 7:09 AM
On Mon, Aug 16, 2010 at 11:17 AM, sebb seb...@gmail.com wrote:
The -bin and -src files need to be moved to the commons/dist directory
tree (and removed from Nexus) *before* the Maven artifacts are
released from Nexus.
This is an error-prone operation, so I don't think any future Commons
...but anyway - let's give it another go?
Do you feel this requires another go? So far my vote count is 3 +1s and
and one -1 which means it is one its way to pass.
Two voted -1: Sebastian + Torsten
I think lets give another try - the problems are already solved and
the release process itself
On Thu, Aug 12, 2010 at 11:34 AM, Stefan Bodewig bode...@apache.org wrote:
On 2010-08-12, Christian Grobmeier wrote:
...but anyway - let's give it another go?
Do you feel this requires another go? So far my vote count is 3 +1s and
and one -1 which means it is one its way to pass.
Two
Hello,
Commons Compress 1.1 RC2 is available - please vote :-)
Tag:
https://svn.apache.org/repos/asf/commons/proper/compress/tags/commons-compress-1.1/
Site:
http://people.apache.org/builds/commons/compress/1.1/RC2/
Binaries:
Just looked at the site plugin. There is a chance we could use mvn
site:stage for this task:
http://maven.apache.org/plugins/maven-site-plugin/usage.html
One can stage with:
mvn site:stage-deploy -DstagingDirectory=C:\fullsite
-DstagingSiteURL=scp://www.mycompany.com/www/project/
or with:
site
Hello,
Commons Compress 1.1 is available for testing :-) Please have a look
at it and vote.
Note: this release has been made with Nexus and the new process described here:
http://wiki.apache.org/commons/UsingNexus
Tag:
Does it distribute the artifacts to the dist folders also?
Unfortunately not.
Nexus currently only handles Maven artifacts.
http://markmail.org/message/wmhm556j56757xt3#query:%22[Nexus]%20Only%20for%20Maven%20snapshots%20%2F%20releases%22+page:1+mid:wmhm556j56757xt3+state:results
thanks for
I am a bit puzzled about the new create SVN tag section. Isn't this
exactly what mvn release:prepare does?
Yes you are right... I used the manual way here described in some
other commons-documents. I will change it with the parts of the
M2-Procedure
But hey, this also will stage build artifacts to the staging repos we
had before -
I thought we would like to avoid this with Nexus. Therefore we cannot
use mvn release:prepare, except we want to keep the whole old
procedure except the last step.
On Sat, Aug 7, 2010 at 9:16 AM, Christian
Hello,
I updated the UsingNexus page with some more detailed instructions
(basically merged from our other release procedures. I saw that there
is nothing mentioned on the components website. In the old fashioned
way we included the website to the vote thread. How should we do this
now?
Is it:
-
The how to i followed:
http://wiki.apache.org/commons/UsingNexus
is very good, no objections.
Hate the stored passwords though :)
OT
Which is why I no longer use the release plugin for my personal projects.
http://github.com/tcurdt/scripts
/OT
mvnrelease is actually intersting :-)
Hello,
I just configured everything for Nexus and successfully created a snapshot:
https://repository.apache.org/content/repositories/snapshots/org/apache/commons/commons-compress/1.1-SNAPSHOT/
The how to i followed:
http://wiki.apache.org/commons/UsingNexus
is very good, no objections.
I did
...maybe then there is one more thing to squeeze in then
...or at least start the discussion so you can think about while lying
in the sun ;-)
Thanks that I am lying in the sun while thinking about your suggestion ;-)
whenever one want to get to the properties of an ArchiveEntry one has
to
Same to me - Stefan and I will coop after the holiday for getting this
release done.
On Tue, Jul 20, 2010 at 6:53 AM, Stefan Bodewig bode...@apache.org wrote:
On 2010-07-19, Torsten Curdt wrote:
Ups - thought we already released it!? What about a release now-ish?
+1 in general, but I'll be
Hello,
according discussion, I have updated the Jira issues. There is
compress-113 left and the comandline interface needs to be added to
the code.
Best
Christian
On Fri, May 21, 2010 at 6:50 AM, Christian Grobmeier
grobme...@gmail.com wrote:
Hello
in Jira are only three issues open. 2
I've just realised that the non-snapshot deploy probably won't work as
intended, because the Commons parent POM messes with the deployment
URLs.
I assume this would change if most commons-projects would go with Nexus, right?
Christian
As a test, I've uploaded a snapshot of compress to the Nexus repo:
https://repository.apache.org/content/repositories/snapshots/org/apache/commons/commons-compress/
I used the following command:
mvn deploy -Prelease -Dgpg.skip -DskipTests
why did you skipTests? I would have thought that
Then we can finally go on with C1.1 :-)
What about COMPRESS-108 - Command-line interface?
Any objections if I add it to SVN, and change the pom to define it as
the Main-Class?
I was under the impression that it was a first draft. If you feel
thats already doing whats expected of it, go
BTW, I have just been working through using Nexus in the BSF release
(not yet complete, but nothing to do with Nexus) and it does seem to
be much more convenient for handling Maven artifact voting /
releasing.
The big advantage is that the vote can take place on the actual
artifacts that
I've just started using Nexus on Jakarta BSF, and it is easy to use,
as well has having the benefits of:
+ avoiding accidental release
+ providing access to final artifacts for inspection/voting before release.
+ allowing snapshot release for inspection
+ checks that sigs are OK (I forgot to
Hello
in Jira are only three issues open. 2 of them seem possible to be
closed, 1 seems to be minor.
COMPRESS-75
ZipArchiveInputStream does not show location in file where a problem occurred
Seems to be fixed
COMPRESS-113
TarArchiveEntry.parseTarHeader() includes the trailing space/NUL when
On Tue, May 11, 2010 at 9:04 PM, Torsten Curdt tcu...@vafer.org wrote:
In the code we call it Archivername. That should be changed
accordingly to type then IMO. (getArchiveName() could be a little
ambiguous)
no objections against the type, but: really change? I was thinking on
backwards
antoni_my...@poczta.onet.pl wrote:
W dniu 2010-04-13 18:21, Christian Grobmeier pisze:
Oh yes... thanks for the reminder. there is one code review open, then
we can discuss to proceed. [...]
Which code review do you have in mind? I've taken a look at the Jira and
there is 1 issue for 1.0
o COMPRESS-106: Remove unnecessary method
ZipFile.OFFSET_COMPARATOR.new Comparator() {...}.equals(Object o)
That method never existed in 1.0, it was added and later removed between
1.0 and now. I may have a different idea about what constitutes
RELEASE-NOTES but is it really worth
Re: 1.1 vs 1.0.1; There's new public API in the codebase, so we should
call the release 1.1.
+1. We've been using a snapshot version of compress in Aperture framework
since august 2009. issues 73,87 and 89 are important to us and all are
resolved.
pretty please...
Oh yes... thanks for the
Hi,
Do we have a date yet for the compress 1.1 release? There are a few features
in it that I need to use.
not yet, but we already discussed that its time for a new release.
Stefan/Torsten - you are mainly active on compress right now, how is the state?
I see there are 3 issues open for 1.1.
On Fri, Feb 19, 2010 at 6:49 PM, Torsten Curdt tcu...@vafer.org wrote:
While I am fine with the changes itself I find the naming canRead on
an InputStream a little ambiguous.
Maybe canReadArchiveEntry? Open to other suggestions.
I'm not attached to names and can live with either. I don't
Hi,
Stefan has made several bugfixes - I wonder if we should do a 1.1 quite soon.
Since I have not done to much code changes lately due to other
project, I volunteer for preparing the 1.1 release in three weeks, if
we think its already time. And I think it is
Cheers
Christian
[INFO] Tagging release with the label JEXL_2_0_RC1...
[INFO] Executing: /bin/sh -c cd
/Users/henri/Java/apache-commons/rc1/commons/jexl-2.0 svn
--non-interactive copy --file
/var/folders/Ya/YaSJZzgsHu4O4NXovx-nNE+++TI/-Tmp-/maven-scm-1545582656.commit
--revision 836226
I'm sure glad there is help; there are a few project that are just going
/
went through that process (commons-exec for instance) . Is there anyone
involved willing to share their successful publishing process ?
We definitely need to do that and it is on my todo list to document
the
Great news, welcome Henri! :-)
Christian
On Thu, Aug 27, 2009 at 3:45 AM, Rahul Akolkarrahul.akol...@gmail.com wrote:
Welcoming Henri as a new committer to Commons.
Henri has been contributing tirelessly to the JEXL 2.0 branch and has
been instrumental in adding new JEXL features and other
Most other Commons projects don't store the Eclipse files.
compare the files with mvn eclipse:clipse. If it matches, they can
actually be deleted anyway.
I removed those files, they can be generated with mvn eclipse:eclipse
Cheers
Hi Alexander,
please create a Jira Issue with patch for your contributions:
https://issues.apache.org/jira/browse/SANDBOX/component/12311182
or add a patch to an existing.
If you are doing big patches, its recommend to have a ICLA submitted:
http://www.apache.org/licenses/icla.txt
Please have
I think one needs to remove the mime-type first:
svn pd svn:mime-type
That did the trick, thanks you great master of this magic tool! :-)
[And I need to update my script to check for such anomalies!]
Defintly :-) Is this script somewhere accessible?
Thanks,
Christian
Thanks,
Henri,
just applied the patch.
Additionally I have removed the M1 and the ant build as already
announced on this list.
Thanks for contribution!
Christian
-- Forwarded message --
From: Henrib hbies...@gmail.com
Date: Mon, Jun 15, 2009 at 2:13 PM
Subject: Re: Is JEXL an active
Thanks for looking at these patch(es) :-)
Can you add svn props to the above files and fix your client config?
Yes, sorry. I have done so now and fixed all the files sebb suggested
(checked it too with svn propset -R svn:eol-style native * )
However doing this on the files
svn ps
Thanks a lot Christian. I promise next patches will be smaller.
Good :-)
I noticed a few things whilst re-reviewing;
I goofed when moving back to commons logging (there are remnants of
java.util.logging in a few places) and I'll address this in the next (small)
patch (the
Hi there,
just thought it would be nice removing M1 support from the 2.0 branch,
which deals with java 5 and such. I don't think it makes any sense to
support M1.
If you agree, I'll open an issue.
Cheers,
Christian
-
To
I just applied the patch.
Henri, please make sure to make smaller patches :-) This one was quite
hard to review :-)
Hope I got it all in correctly, you may want to have a look.
Thanks guy!
Christian
On Mon, Jun 8, 2009 at 8:23 AM, Christian Grobmeiergrobme...@gmail.com wrote:
I've updated
I've updated https://issues.apache.org/jira/browse/JEXL-55 , a big patch on
the 2.0 svn branch.
Any review/comment welcome.
I'll try to have a look at it during this week and apply or come back
with questions, if any.
Cheers + Thanks,
Christian
Is there still any committer interested in releasing JEXL 2.0?
I have some interest (I did work through to get 1.1 out) but its
really not high priority. Left to me, it may realistically be weeks
before things like JEXL-55 get looked at. Obviously, if someone else
jumps in, that could be
On Thu, May 28, 2009 at 9:05 PM, Rahul Akolkar rahul.akol...@gmail.com wrote:
On Thu, May 28, 2009 at 3:00 PM, Christian Grobmeier
grobme...@gmail.com wrote:
Is there still any committer interested in releasing JEXL 2.0?
I have some interest (I did work through to get 1.1 out) but its
Hi ,
Looking at the number of issues, commits messages, it looks like JEXL does
not have a very voicefull community; are there still some committers around
or is the project in a semi-abandoned state?
all Commons Committers can (theoretically) apply patches. But it
cannot be too bad to bring
Hi,
before ages VFS included the compress classes with own namespace,
cause compress wasn't released and VFS had to go ahead. It was planned
to replace those vfs.compress classes with a dependency to commons
compress. If this is still the plan, I will create an issue for it and
would do it
Next dev. snapshot is 1.1.
One has to wonder why we put the version number on the site :) It's
completely meaningless and just leads to confusion.
I think it dates in Maven from the notion that your site would be your
documentation. However websites serve a completely different purpose
Another minor glitch I noticed just now. All pages seem to include a
green 1.1-SNAPSHOT in the grey headline, which may come in via the
generating style sheet or an ant property (I didn't check how the site
is generated).
Thanks, but it looks like know issue:
: Christian Grobmeier grobme...@gmail.com
Date: Thu, May 14, 2009 at 7:54 AM
Subject: [VOTE] Release commons-compress-1.0 based on RC2 (Rev: 774630)
To: Commons Developers List dev@commons.apache.org
Hi all,
RC2 is based on SVN revision: 774630
It includes minor changes on the site, corrects svn
Hi,
I did the rest in http://wiki.apache.org/commons/CreatingReleases
Checking everything, I figured out that everyting is on
http://www.apache.org/dist/commons but not available on
http://repo1.maven.org/maven2/.
http://repo1.maven.org/maven2/commons-compress/commons-compress/
doesn't contain
Thanks Rainer.
I did the fix and wait for the mirroring now. Hopefully everything works then.
I don't think this does require a new vote, RC, etc. since it was just
a broker link... right guys?
Thanks again,
Christian
Concerning the download page:
I think you need to add the cgi page named
thanks, i removed downloads - its not longer necessary
cgi works now too :-)
Cheers
On Thu, May 21, 2009 at 11:16 PM, Rainer Jung rainer.j...@kippdata.de wrote:
On 21.05.2009 22:58, Christian Grobmeier wrote:
Thanks Rainer.
I did the fix and wait for the mirroring now. Hopefully everything
The Commons Compress team is pleased to announce the
commons-compress-1.0 release!
Commons Compress is a component that contains Ar, Cpio, Jar, Tar, Zip
and BZip2 packages
Source and binary distributions are available for download from the
Apache Commons download site:
Hi,
of which project are you talking about? VFS? Please put the components
name in your subject, like:
[vfs] Fix for race condition in forceMkdir
to be heard.
The issue is not attached to the mail. Please make sure you
additonally added it to a Jira issue. if there is none, please create
one :-)
The link from: http://commons.apache.org/resources/source-repository.html is
working correctly.
The browse link on: http://commons.apache.org/resources/ is not though.
This link points to proper instead of sandbox
Cheers
-
As a commons committer, you can start things in the sandbox without a
formal
vote. You should probably execute a grant for the stuff done outside the
ASF. Does Yonik have sandbox karma? If not, just ask. Happy hacking!
Great to hear! Just wanted to ask before bringing stuff in! I will
I think md5 checksums are required for all artifacts. They are currently
missing.
Could perhaps add sha1 as well, but not essential
No need to re-roll the release; just create the hashes.
Hashes are available now
Thanks
Christian
i like the common-chain. That is a simple and nice. But chain in one jar has
a problem. The chain has a dependency to servlet api. I think this not gut.
The better was it separate to chain-core.jar (for project without servlet
api) and chain- web.jar(for web.). And with maven module was
I am a new in dev group and I don't how I it's make? Can you me help with
this?
Please read this:
http://commons.apache.org/patches.html
basically it says you should check out the component, do your mod and
then create the patch. If you use eclipse, it has some cool features
in the context
-1.0
RA layer request failed
svn: Server sent unexpected return value (403 Forbidden) in response
to MKACTIVITY request for
'/repos/asf/!svn/act/505eedcc-66b4-46d0-a84a-95e5cae3fb9a'
Who can delete this tag please?
Thanks,
Christian
On Wed, May 13, 2009 at 7:09 AM, Christian Grobmeier
grobme
:09 AM, Christian Grobmeier
grobme...@gmail.com wrote:
On Tue, May 12, 2009 at 7:41 PM, Dan Fabulich d...@fabulich.com
wrote:
When I ran it, the release plugin prompted me for the tag name to
create.
Rather than accept defaults, I manually typed in the appropriate tag
name
If it is only the file names that contain the -RC2 suffix, then we can
just rename those too.
[May also need to edit the hash files, but that is easy to automate]
I am not sure if the steps afterwards fail since they are looking for
those filenames. Its maybe fixed int he newly created
Matt,
Cool--note that ANTLR 3 is designed to be much faster than ANTLR 2 IIRC.
I read about ANTLR and checked out examples and faq and such. ANTLR
feels very mighty to me, and it urges me to create an php parser with
it one day :-)
However - ANTLR great stuff but I am thinking that I don't
Hi all,
RC2 is based on SVN revision: 774630
It includes minor changes on the site, corrects svn properties and
makes a testcase run on win xp.
Please vote:
Tag:
https://svn.apache.org/repos/asf/commons/proper/compress/tags/commons-compress-1.0/
Site:
I think similar, but this has been done automatically when following:
http://wiki.apache.org/commons/CreatingReleases
Yes, I know; the original instructions (shown as outdated, at the
bottom) imply that it is possible; seems to me it would be a lot
better.
No its not outdated - just the
Hi,
currently the
mvn -Prc release:perform
creates a tag with the release name instead of f.e. commons-compress-1_0-RC1.
1) Do I have to remove the tag commons-compress-1_0 manually when
doing a second release candidate? Just want to make sure, don't want
to break the rules.
2) Is it really
Yes, I know; the original instructions (shown as outdated, at the
bottom) imply that it is possible; seems to me it would be a lot
better.
No its not outdated - just the last paragraph is outdated by the above
writings:
That's what I meant - the last para is marked as outdated.
ah
if you did some moe rcs:
http://svn.apache.org/viewvc/commons/proper/dbutils/tags/
Did you delete the old tags afterwards?
Christian
-Dan
Christian Grobmeier wrote:
Hi,
currently the
mvn -Prc release:perform
creates a tag with the release name instead of f.e.
commons-compress-1_0-RC1
Christian Grobmeier wrote:
Hi,
currently the
mvn -Prc release:perform
creates a tag with the release name instead of f.e.
commons-compress-1_0-RC1.
1) Do I have to remove the tag commons-compress-1_0 manually when
doing a second release candidate? Just want to make sure, don't want
to break
I think there is some work ongoing on the infrastructure side just now.
Try again in a few hours.
It has something to do with my password. How is authentification done
in that plugin? I had to set -D parameters for username and password
to make this work.
Christian
jRPM appears to use AL 1.1 rather than AL 2.0, so the license text
From the jrpm project should be added to LICENSE file.
ISTR the code has been granted to the ASF and we have relicensed it -
I can't seem to find any paper trail, though.
jRPM has updated the license themself after i
jRPM has updated the license themself after i requested it.
See:
http://jrpm.svn.sourceforge.net/viewvc/jrpm/trunk/LICENSE.txt?revision=25view=markup
I see.
That's actually the AL header, rather than the AL 2.0 License.
The web-site still has:
Tag:
https://svn.apache.org/repos/asf/commons/proper/compress/tags/commons-compress-1.0/
I don't like the use of final tag names for release candidates; tags
should be immutable, so how can one generate another release candidate
if this one fails?
I'm not sure what the solution to this is
...@carmanconsulting.com wrote:
You can set those in your ~/.m2/settings.xml file, too
On Mon, May 11, 2009 at 3:37 AM, Christian Grobmeier
grobme...@gmail.com wrote:
I think there is some work ongoing on the infrastructure side just now.
Try again in a few hours.
It has something to do with my
Hi,
the current changes file of compress is rather empty. Since it is the
first release, is it necessary to insert the complete list of issue
resolved?
Regards,
Christian
-
To unsubscribe, e-mail:
Hi all,
i am doing the compress RC atm but got an maven error - don't know
what happened, maybe one of you guys know.
I did: mvn -Prc release:prepare
The archives of the release has been created, signatures have been done too.
Then it tried to commit something and I got the following error:
Hi all,
as already discussed, I just created a RC1 for the first [compress] release :-)
Let me know if you can find any problems.
Cheers,
Christian
Tag:
https://svn.apache.org/repos/asf/commons/proper/compress/tags/commons-compress-1.0/
Site:
Hi Valentin,
I must confess I don't know where to start, and what project really need
an effort and should be good to put my eyes on. Could somebody guide a
poor little Java dev like me ?
i think the best place to start is the project which gives you the most joy!
After choosing your project,
gpg: Can't check signature: public key not found
[CraigRussell:~/Downloads] clr% gpg --recv-keys 42196CA8
gpg: requesting key 42196CA8 from hkp server subkeys.pgp.net
gpgkeys: key 42196CA8 not found on keyserver
Thanks, i sent it to several keyservers now :-)
Can you try again?
Christian
Can you upload the public key?
http://people.apache.org/~grobmeier/test/grobmeier-codesigning.pub
It will need to be added to KEYS at some point if you are to use it.
Yes. I didn't understood when a key is beeing considered trusted at apache.
Meanwhile I think there is not such a policy.
http://people.apache.org/~grobmeier/test/grobmeier-codesigning.pub
Thanks, that has allowed me to check the signature. Validates OK.
Cool!
However I was unable to download the key from a keyserver - maybe
there was a problem with the server I was using.
Strange... I uploaded it to:
Hi,
as far as I remember CACert is about X.509 certificates and not PGP
keys. If that assumption is true than this key is not usable for
PGP-signing.
yes, but if you are assured at CACert they offer signing your PGP too.
Thanks
Christian
Why not try creating a signature for an existing Commons release, e.g. IO?
Upload it to your home directory on people, along with the public key,
and some of us can see if it is usable.
That would be great! Thanks!
Here are the urls:
Hi Jörg,
thanks for asking!
I would like to add:
- no dependencies!
- Creates JSON Strings of Objects and vice versa
... and a bit more on the mapping this mechanism.
Basically you have a JSONValue which can be JSONString, JSONNumber
etc. If you call toJSON at this object, you'll get a
Why do you consider a dependency on Antlr a negative (the runtime is 148k),
JSON is a formally defined language after all.
I don't know a person face to face who actually can handle antlr. Its
a cool tool, but if you need to create a patch for your json lib, it
can be hell. Plain java is
Matt,
I don't know about folks you (or I) know face-to-face, but I know that
several ASF committers and members have popped up around the ANTLR lists over
the years, including, off the top of my head, myself, Torsten, O.Ziegermann,
H.L. Ship, and probably others. I personally am quite
Oh, BTW, I don't see any other issues preventing the 1.0 release.
thanks all, that was quick!
I already read the releases wiki site and will dive into it a bit more
now. I am quite sure I will need help :-)
Cheers,
Christian
-
Hi Min Cha,
is it possible to enhance Chain1 with RobustTask features instead of a
complete replacement? All is very similar, and sometimes even Chain1
looks better to my eyes than RobustTask (for example i don't think
that throwing with RuntimExceptions is a very good idea). But there
are some
Hi all,
we have fixed all bugs we mentioned for 1.0 release. The API looks
quite good for my eyes (even when Sebastian finds some stuff here and
there :-)) and I would like to think about a release again. Is there
anything speaking against this step? Anything we really need to do
before
The only minor issue I have is with finish() and close().
I think it is going to be annoying for users to have to call finish()
separately from close().
I would prefer to see finish() being optional, i.e. close() should
call it if necessary.
But the code should check to make sure that
Just remembered - what about ZipArchiveInputStream.useUnicodeExtraFields?
This field is currently unused - what are the plans for it?
Maybe just add a JIRA so it is not overlooked?
yes, definitly!
I found before a few days and forgot about it agian. Will create ticket for it.
I have update
On Thu, Apr 23, 2009 at 1:06 PM, sebb seb...@gmail.com wrote:
On 23/04/2009, grobme...@apache.org grobme...@apache.org wrote:
Author: grobmeier
Date: Thu Apr 23 05:30:06 2009
New Revision: 767804
URL: http://svn.apache.org/viewvc?rev=767804view=rev
Log:
added javadocs
And reflowed
On Thu, Apr 23, 2009 at 1:49 PM, Torsten Curdt tcu...@apache.org wrote:
Similarly for other methods. The Abstract class would be responsible
for maintaining the current state and checking that the method is
valid for the state.
Hm ... sounds a bit like overkill to me.
for me too.. I had this
Well, it may involve a bit more work now - which I don't mind doing -
but adding a new archiver should be easier, as it would not have to do
the state checking.
The idea is to have the re-usable code in the abstract super-class.
I completly understand your point. But does this bring so much
tests for this
- added equals methods and hashCode to the ArchiveEntrys for the features above
This should address most problems in this thread - comments welcome!
Cheers,
Christian
On Thu, Apr 16, 2009 at 5:13 PM, Christian Grobmeier
grobme...@gmail.com wrote:
I just added testDeletePlusAddSame
I just added testDeletePlusAddSame() and found out that it works like
expected (removes file A and adds file B under the same name as file
A).
However, it does not work exactly the same as Add then Delete, because
that removes all trace of the Add from the Set.
Yes.
If you make Add and
Hi all,
today we have resolved all remaining issues in Jira.
Open and unscheduled Issues are:
* COMPRESS-62Need many more test cases to check that can read
real archives
* COMPRESS-64 Are the public finish() methods ArchiveOutputStream
implementations necessary and safe?
*
301 - 400 of 496 matches
Mail list logo
