commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebb <>
Subject Re: [compress] Last issues before 1.1
Date Fri, 21 May 2010 09:26:49 GMT
On 21/05/2010, Stefan Bodewig <> wrote:
> On 2010-05-21, Christian Grobmeier wrote:
>  > COMPRESS-75
>  > ZipArchiveInputStream does not show location in file where a problem occurred
>  > Seems to be fixed
> Agreed (with the "seems to be fixed" part).
>  > COMPRESS-113
>  > TarArchiveEntry.parseTarHeader() includes the trailing space/NUL when
>  > parsing the octal
>  > Suggestion from Sebb available. If a trailing NUL is in the tar specs,
>  > I wold go for option 2 otherwise 1.
> If only there was *the* tar spec.  The best source I know is the FreeBSD
>  man page
>  <>
>  and it says "must end in a space" for 'old archives' and "allows
>  [numeric fields] to be terminated with either space or NUL".  Similar
>  rules (slightly twisted for 'old archives') apply to other fields than
>  size as well, like mode or uid.
>  I'd go with "insist on a trailing space or NUL".
>  > COMPRESS-18
>  > JarArchiveEntry does not populate manifestAttributes or certificates
>  > I undestood this one has been solved in another way from Stefan
> If we decided to adopt the patch it would need some additional work to
>  update the byte count, no biggie but that would delay the release
>  further.  We could as well move the issue to 1.2.


>  > Then we can finally go on with C1.1 :-)
> Thank you for taking care of it.


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 /

The big advantage is that the vote can take place on the actual
artifacts that will be released, not a separately generated copy.
Also, the uploaded files are held in a staging area which can be
dropped and recreated if there are problems (whereas normal deploy
goes straight to the repo forge).

Would you be willing to try this? I can help if you run into problems.

The suggested approach is to start with deploying directly from trunk,
i.e. a SNAPSHOT version. This goes to a snapshot repo where the
contents can be inspected. It cannot be released from there.

When the tag has been built, the deploy process will upload to a
staging repo instead, which can either be dropped or promoted if the
vote succeeds.

>  Stefan
>  ---------------------------------------------------------------------
>  To unsubscribe, e-mail:
>  For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message