You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Christian Grobmeier <gr...@gmail.com> on 2010/05/21 06:50:30 UTC
[compress] Last issues before 1.1
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
parsing the octal
Suggestion from Sebb available. If a trailing NUL is in the tar specs,
I wold go for option 2 otherwise 1.
COMPRESS-18
JarArchiveEntry does not populate manifestAttributes or certificates
I undestood this one has been solved in another way from Stefan
If possible, lets close 75 and 18 and try to decide with 113. Then we
can finally go on with C1.1 :-)
Cheers
Christian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [compress] Last issues before 1.1
Posted by Niall Pemberton <ni...@gmail.com>.
On Fri, May 21, 2010 at 11:02 AM, Christian Grobmeier
<gr...@gmail.com> wrote:
>> 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 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.
>
> I can do it with Nexus, but I really don't have a big clue of it. Are
> there any documents I can read which are explaining me more on this?
> To be honest its the first time I heard of it (except some mentions on
> some mailinglist)
If you look at the description of INFRA-1896 there are some links to
docs in that
https://issues.apache.org/jira/browse/INFRA-1896
Niall
>> 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.
>
> OK, so I would create this snapshot locally and then upload it manually?
> Where does it need to go, is it a webinterface?
>
>> 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.
>
> The tag is done by the tool itself?
>
> Sorry for dump questions. I am lost with this process but willing to
> learn since the last time I was not too happy with the mvn release
> process
> Christian
>
>
>>>
>>> Stefan
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [compress] Last issues before 1.1
Posted by Christian Grobmeier <gr...@gmail.com>.
> 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 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.
I can do it with Nexus, but I really don't have a big clue of it. Are
there any documents I can read which are explaining me more on this?
To be honest its the first time I heard of it (except some mentions on
some mailinglist)
> 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.
OK, so I would create this snapshot locally and then upload it manually?
Where does it need to go, is it a webinterface?
> 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.
The tag is done by the tool itself?
Sorry for dump questions. I am lost with this process but willing to
learn since the last time I was not too happy with the mvn release
process
Christian
>>
>> Stefan
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [compress] Last issues before 1.1
Posted by sebb <se...@gmail.com>.
On 21/05/2010, Stefan Bodewig <bo...@apache.org> 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
> <http://www.freebsd.org/cgi/man.cgi?query=tar&sektion=5&manpath=FreeBSD+8-current>
> 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.
+1
>
> > Then we can finally go on with C1.1 :-)
>
>
> Thank you for taking care of it.
+1
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 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: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [compress] Last issues before 1.1
Posted by Stefan Bodewig <bo...@apache.org>.
On 2010-05-22, Christian Grobmeier wrote:
>> 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 ahead in my opinion
+1
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [compress] Last issues before 1.1
Posted by sebb <se...@gmail.com>.
On 22/05/2010, Torsten Curdt <tc...@vafer.org> wrote:
> On Sat, May 22, 2010 at 09:39, Christian Grobmeier <gr...@gmail.com> wrote:
> >>>
> >>> > 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 ahead in my opinion
>
>
> Same here.
Thanks!
Yes, it is fairly rudimentary at present, but it does work.
I think it would be useful to release it as it is, so I'll do that.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [compress] Last issues before 1.1
Posted by Torsten Curdt <tc...@vafer.org>.
On Sat, May 22, 2010 at 09:39, Christian Grobmeier <gr...@gmail.com> wrote:
>>>
>>> > 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 ahead in my opinion
Same here.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [compress] Last issues before 1.1
Posted by Christian Grobmeier <gr...@gmail.com>.
>>
>> > 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 ahead in my opinion
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [compress] Last issues before 1.1
Posted by sebb <se...@gmail.com>.
On 21/05/2010, Stefan Bodewig <bo...@apache.org> 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
> <http://www.freebsd.org/cgi/man.cgi?query=tar&sektion=5&manpath=FreeBSD+8-current>
> 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 :-)
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?
S///
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [compress] Last issues before 1.1
Posted by Stefan Bodewig <bo...@apache.org>.
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
<http://www.freebsd.org/cgi/man.cgi?query=tar&sektion=5&manpath=FreeBSD+8-current>
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.
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [compress] Last issues before 1.1
Posted by Christian Grobmeier <gr...@gmail.com>.
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
<gr...@gmail.com> wrote:
> 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
> parsing the octal
> Suggestion from Sebb available. If a trailing NUL is in the tar specs,
> I wold go for option 2 otherwise 1.
>
>
> COMPRESS-18
> JarArchiveEntry does not populate manifestAttributes or certificates
> I undestood this one has been solved in another way from Stefan
>
>
> If possible, lets close 75 and 18 and try to decide with 113. Then we
> can finally go on with C1.1 :-)
>
> Cheers
> Christian
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org