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

Reply via email to