On 12/05/2009, Christian Grobmeier <grobme...@gmail.com> wrote: > >> 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 as I don't know enough Maven. > > > 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. > > >> Site: > >> http://people.apache.org/builds/commons/compress/1.0/RC1/site/index.html > > > > Could not find any reference to the required JVM version. > > > I added 1.4.2 as required java version. Thanks. > > Also the front page still refers partly to sandbox status: > > > > # The code is unreleased > > # Methods and classes can and will appear and disappear without warning > > # If you like the code and want to push it towards a release, join the > > mailing list! > > > > > Its deleted. Thanks. > > > > >> Binaries: > >> > http://people.apache.org/builds/commons/compress/1.0/RC1/staged/org/apache/commons/commons-compress/1.0/ > > > > Hashes of sigs (.asc.md5 and .asc.sha1) are created by Maven, but > > should be deleted as they serve no purpose. > > > OK I deleted them, just for the sake of completnes. Thanks - they just mess up distributions. Maybe one day Maven will be fixed to avoid creating them... > > The OSGI information in commons-compress-1.0.jar looks wrong - surely > > the compress packages should only be listed in the Export section, and > > not the Import section as well? > > > > Presumably this is a pom.xml config error rather than a plugin error, > > but I have no idea how to fix it. > > > > I think the Import section should be empty, as compress has no > > dependencies (apart from junit for testing). I don't know if that > > means it should be omitted, or just left empty. > > > no idea... this is defined in parent pom. > > but is it really an error? > The new dbutils has it in it too: > > Import-Package: javax.sql,org.apache.commons.dbutils;version="1.2",org > .apache.commons.dbutils.handlers;version="1.2",org.apache.commons.dbu > tils.wrappers;version="1.2" > OK, let's assume it's correct. > > CpioArchiveInputStreamTest.java does not have an AL header. > > > fixed > > > > Some of the test files don't have AL headers either, but that's probably > OK. > > > i think so > > > > > testCpioUnarchive(org.apache.commons.compress.archivers.CpioTestCase) > > junit.framework.AssertionFailedError: length of > > C:\DOCUME~1\User\LOCALS~1\Temp\dir20685\test1.xml expected:<80> but > > was:<76> > > > > Perhaps this is an EOL issue? > > > it runs on my box (OS X 10.4) - which system are you using? WinXP. But I think the problem is that the release archive was created on a different OS to the one where it was tested. You created the release using EOL=LF (I assume), I tested using EOL=CRLF, so the file size calculation was incorrect, because it assumed the file had EOL=CRLF. I've changed the test to use file.length() instead, but it would be useful if you could check that this still works on MacOs. > > > I think there's no point releasing with the OSGI error. > > > if it is one :-) Indeed. One other change needed to SVN: svn ps svn:eol-style native src/main/java/org/apache/commons/compress/changes/ChangeSetResults.java svn ps svn:eol-style native src/site/xdoc/download_compress.xml svn ps svn:eol-style native src/test/java/org/apache/commons/compress/archivers/ArchiveOutputStreamTest.java I think these files were added on an OS with EOL=LF, so best if you apply the properties rather than me. Although there is not much wrong with the existing release, I would be happier if it was redone to incorporate the recent fixes. Would you mind very much re-doing the release? > Cheers Christian > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org