You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Henri Yandell <fl...@gmail.com> on 2009/03/11 04:58:54 UTC
[VOTE] Release Commons CLI 1.2 (RC6)
One more try :)
Stating that the Java version is 1.4 on the website will be done
post-release (I'm going to split the CLI and CLI2 websites).
---
Tag:
https://svn.apache.org/repos/asf/commons/proper/cli/tags/cli-1.2-RC6
Site remains unchanged:
http://people.apache.org/~bayard/cli-1.2-rc1
Binaries:
http://people.apache.org/builds/commons/cli/1.2/RC6/staged/commons-cli/commons-cli/1.2/
[ ] +1 release it
[ ] +0 go ahead I don't care
[ ] -1 no, do not release it because
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [VOTE] Release Commons CLI 1.2 (RC6)
Posted by Henri Yandell <fl...@gmail.com>.
On Fri, Mar 13, 2009 at 12:51 AM, Russel Winder
<ru...@concertant.com> wrote:
> On Thu, 2009-03-12 at 21:00 -0700, Henri Yandell wrote:
> [ . . . ]
>> The site is the CLI2 site. Post release I'm going to create a CLI-1
>> site and split the two, demoting the CLI2 site to the sandbox. Anyone
>> at Apache will then be open to digging in on CLI2 and bringing it to a
>> release state.
>>
>> Lesson being... rewrites are new components. New components start in
>> the sandbox.
>
> Does this mean there will be changes to the structure of the Commons CLI
> related Subversion repository?
>
> (I ask because I currently use Bazaar and Git as my Subversion clients
> and doing a fresh branch/clone of Commons CLI (or any branch thereof)
> takes a couple of days because all the Commons are in a single
> Subversion repository and that repository has quite a lot of revisions
> (>750k).)
Yes. trunk/cli would become the cli-1.x and the current cli would move
to sandbox/cli2.
Hen
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [VOTE] Release Commons CLI 1.2 (RC6)
Posted by Russel Winder <ru...@concertant.com>.
On Thu, 2009-03-12 at 21:00 -0700, Henri Yandell wrote:
[ . . . ]
> The site is the CLI2 site. Post release I'm going to create a CLI-1
> site and split the two, demoting the CLI2 site to the sandbox. Anyone
> at Apache will then be open to digging in on CLI2 and bringing it to a
> release state.
>
> Lesson being... rewrites are new components. New components start in
> the sandbox.
Does this mean there will be changes to the structure of the Commons CLI
related Subversion repository?
(I ask because I currently use Bazaar and Git as my Subversion clients
and doing a fresh branch/clone of Commons CLI (or any branch thereof)
takes a couple of days because all the Commons are in a single
Subversion repository and that repository has quite a lot of revisions
(>750k).)
--
Russel.
============================================================
Dr Russel Winder Partner
Concertant LLP t: +44 20 7585 2200, +44 20 7193 9203
41 Buckmaster Road, f: +44 8700 516 084 voip: sip:russel.winder@ekiga.net
London SW11 1EN, UK. m: +44 7770 465 077 xmpp: russel@russel.org.uk
Re: [VOTE] Release Commons CLI 1.2 (RC6)
Posted by Henri Yandell <fl...@gmail.com>.
On Fri, Mar 13, 2009 at 6:56 AM, sebb <se...@gmail.com> wrote:
> On 13/03/2009, Henri Yandell <fl...@gmail.com> wrote:
>> On Thu, Mar 12, 2009 at 4:12 PM, Jörg Schaible <jo...@gmx.de> wrote:
>> > Henri Yandell wrote:
>> >
>> >> One more try :)
>> >>
>> >> Stating that the Java version is 1.4 on the website will be done
>> >> post-release (I'm going to split the CLI and CLI2 websites).
>>
>>
>> > Another problem of the site:
>> >
>> > Project Documentation/Project Reports/Javadoc is the following link:
>> > http://people.apache.org/~bayard/cli-1.2-rc1/apidocs/index.html
>> >
>> > However, this is Javadoc of CLI2 ?!?
>> >
>> > Actually most Maven reports (Project Summary, Checkstyle, Cobertura Test
>> > Coverage, JavaDocs, JDepend, RAT Report, Source Xref, Surefire Report, Test
>> > JavaDocs and Test Source Xref) cover CLI2.
>>
>>
>> Easy one first while I digest the Test resolution.
>>
>> The site is the CLI2 site. Post release I'm going to create a CLI-1
>> site and split the two, demoting the CLI2 site to the sandbox. Anyone
>> at Apache will then be open to digging in on CLI2 and bringing it to a
>> release state.
>>
>> Lesson being... rewrites are new components. New components start in
>> the sandbox.
>
> nitpick: I assume you mean rewrites that substantially change the API
> here. A rewrite that (largely) preserves API compatibility is a new
> release.
>
> In the case of CLI1/CLI2 (and Avalon) the APIs are completely different.
Absolutely. Lang 3.0 for example is perfectly fine in trunk as it's
not looking to rewrite from scratch, just evolve. Generics
Collections.... less sure.
The tricky part is that CLI2 started that way, but hit a point where
it decided to rewrite. That was the point where it should have started
anew.
I feel this vote thread has got away from me :) Time to read Jörg's
bug and get us thinking about another RC.
Hen
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [VOTE] Release Commons CLI 1.2 (RC6)
Posted by sebb <se...@gmail.com>.
On 13/03/2009, Henri Yandell <fl...@gmail.com> wrote:
> On Thu, Mar 12, 2009 at 4:12 PM, Jörg Schaible <jo...@gmx.de> wrote:
> > Henri Yandell wrote:
> >
> >> One more try :)
> >>
> >> Stating that the Java version is 1.4 on the website will be done
> >> post-release (I'm going to split the CLI and CLI2 websites).
>
>
> > Another problem of the site:
> >
> > Project Documentation/Project Reports/Javadoc is the following link:
> > http://people.apache.org/~bayard/cli-1.2-rc1/apidocs/index.html
> >
> > However, this is Javadoc of CLI2 ?!?
> >
> > Actually most Maven reports (Project Summary, Checkstyle, Cobertura Test
> > Coverage, JavaDocs, JDepend, RAT Report, Source Xref, Surefire Report, Test
> > JavaDocs and Test Source Xref) cover CLI2.
>
>
> Easy one first while I digest the Test resolution.
>
> The site is the CLI2 site. Post release I'm going to create a CLI-1
> site and split the two, demoting the CLI2 site to the sandbox. Anyone
> at Apache will then be open to digging in on CLI2 and bringing it to a
> release state.
>
> Lesson being... rewrites are new components. New components start in
> the sandbox.
nitpick: I assume you mean rewrites that substantially change the API
here. A rewrite that (largely) preserves API compatibility is a new
release.
In the case of CLI1/CLI2 (and Avalon) the APIs are completely different.
> Hen
>
>
> ---------------------------------------------------------------------
> 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: [VOTE] Release Commons CLI 1.2 (RC6)
Posted by Henri Yandell <fl...@gmail.com>.
On Thu, Mar 12, 2009 at 4:12 PM, Jörg Schaible <jo...@gmx.de> wrote:
> Henri Yandell wrote:
>
>> One more try :)
>>
>> Stating that the Java version is 1.4 on the website will be done
>> post-release (I'm going to split the CLI and CLI2 websites).
> Another problem of the site:
>
> Project Documentation/Project Reports/Javadoc is the following link:
> http://people.apache.org/~bayard/cli-1.2-rc1/apidocs/index.html
>
> However, this is Javadoc of CLI2 ?!?
>
> Actually most Maven reports (Project Summary, Checkstyle, Cobertura Test
> Coverage, JavaDocs, JDepend, RAT Report, Source Xref, Surefire Report, Test
> JavaDocs and Test Source Xref) cover CLI2.
Easy one first while I digest the Test resolution.
The site is the CLI2 site. Post release I'm going to create a CLI-1
site and split the two, demoting the CLI2 site to the sandbox. Anyone
at Apache will then be open to digging in on CLI2 and bringing it to a
release state.
Lesson being... rewrites are new components. New components start in
the sandbox.
Hen
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [VOTE] Release Commons CLI 1.2 (RC6)
Posted by Henri Yandell <fl...@gmail.com>.
On Thu, Mar 12, 2009 at 4:12 PM, Jörg Schaible <jo...@gmx.de> wrote:
> Henri Yandell wrote:
>
>> One more try :)
>>
>> Stating that the Java version is 1.4 on the website will be done
>> post-release (I'm going to split the CLI and CLI2 websites).
>
> Actually I could not let go this failing test with IBM JDK running on Maven
> without any reason. And finally I found out the problem. Looking at the
> failing test, it was clear that something must have been left in the
> OptionBuilder from a previous test. Therefore I've added some code to
> OptionBuilder.create that printed out the last method on the stack that was
> not from OptionBuilder. I found out that the last test before the failing
> HelpFormatterTest.printOptionGroupUsage that made usage of the
> OptionBuilder was OptionBuilderTest.testCreateIncompleteOption. In this
> method an argument is added and then create fails throwing an IAE and the
> OptionBuilder.reset method is therefore not called. A lot of unit tests
> later the HelpFormatterTest.printOptionGroupUsage is the first test that
> makes usage of the OptionBuilder again ... and "inherits" that old
> argument. The problem appears only because the sequence of the tests are
> different for the IBM JDK 6 in Maven.
>
> The question is: What should a user expect from the OptionBuilder? If
> OptionBuilder.create() throws IAE (or he forgets to call create), the next
> usage of the builder will "inherit" the old settings. OTOH both situations
> are programming errors. This might be viewed as minor problem though, since
> the OptionBuilder is normally used in an early stage of the application
> flow only. At least something should be in the JavaDoc that this class is
> not thread safe and that create() must be called to reset the builder for
> the next usage.
>
> Therefore we may either ensure that a call to create will always reset the
> builder in case of an IAE (CLI-177) or we can simply fix the tests that use
> the builder by calling reset manually in the setUp (actually we must create
> a simple option, since reset is private). Shall I commit this?
I think fixing the tests and adding javadoc is best right now. We can
evaluate CLI-177 after that, but I don't want to hold up a release and
this is the kind of fix that would be nice to have sitting in trunk
for a while being picked up by people before baking it in.
Let me know when you've done that and I'll spin another RC out.
Many thanks,
Hen
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [VOTE] Release Commons CLI 1.2 (RC6)
Posted by Jörg Schaible <jo...@gmx.de>.
Henri Yandell wrote:
> One more try :)
>
> Stating that the Java version is 1.4 on the website will be done
> post-release (I'm going to split the CLI and CLI2 websites).
Actually I could not let go this failing test with IBM JDK running on Maven
without any reason. And finally I found out the problem. Looking at the
failing test, it was clear that something must have been left in the
OptionBuilder from a previous test. Therefore I've added some code to
OptionBuilder.create that printed out the last method on the stack that was
not from OptionBuilder. I found out that the last test before the failing
HelpFormatterTest.printOptionGroupUsage that made usage of the
OptionBuilder was OptionBuilderTest.testCreateIncompleteOption. In this
method an argument is added and then create fails throwing an IAE and the
OptionBuilder.reset method is therefore not called. A lot of unit tests
later the HelpFormatterTest.printOptionGroupUsage is the first test that
makes usage of the OptionBuilder again ... and "inherits" that old
argument. The problem appears only because the sequence of the tests are
different for the IBM JDK 6 in Maven.
The question is: What should a user expect from the OptionBuilder? If
OptionBuilder.create() throws IAE (or he forgets to call create), the next
usage of the builder will "inherit" the old settings. OTOH both situations
are programming errors. This might be viewed as minor problem though, since
the OptionBuilder is normally used in an early stage of the application
flow only. At least something should be in the JavaDoc that this class is
not thread safe and that create() must be called to reset the builder for
the next usage.
Therefore we may either ensure that a call to create will always reset the
builder in case of an IAE (CLI-177) or we can simply fix the tests that use
the builder by calling reset manually in the setUp (actually we must create
a simple option, since reset is private). Shall I commit this?
Another problem of the site:
Project Documentation/Project Reports/Javadoc is the following link:
http://people.apache.org/~bayard/cli-1.2-rc1/apidocs/index.html
However, this is Javadoc of CLI2 ?!?
Actually most Maven reports (Project Summary, Checkstyle, Cobertura Test
Coverage, JavaDocs, JDepend, RAT Report, Source Xref, Surefire Report, Test
JavaDocs and Test Source Xref) cover CLI2.
- Jörg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
RE: [VOTE] Release Commons CLI 1.2 (RC6)
Posted by Gary Gregory <GG...@seagullsoftware.com>.
+1
Builds and tests pass on Sun Java 1.6.0_12 on Windows XP SP3 with current patches.
Gary
-----Original Message-----
From: Henri Yandell [mailto:flamefew@gmail.com]
Sent: Tuesday, March 10, 2009 8:59 PM
To: Commons Developers List
Subject: [VOTE] Release Commons CLI 1.2 (RC6)
One more try :)
Stating that the Java version is 1.4 on the website will be done
post-release (I'm going to split the CLI and CLI2 websites).
---
Tag:
https://svn.apache.org/repos/asf/commons/proper/cli/tags/cli-1.2-RC6
Site remains unchanged:
http://people.apache.org/~bayard/cli-1.2-rc1
Binaries:
http://people.apache.org/builds/commons/cli/1.2/RC6/staged/commons-cli/commons-cli/1.2/
[ ] +1 release it
[ ] +0 go ahead I don't care
[ ] -1 no, do not release it because
---------------------------------------------------------------------
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: [VOTE] Release Commons CLI 1.2 (RC6)
Posted by Oliver Heger <ol...@oliver-heger.de>.
+1
Oliver
Henri Yandell schrieb:
> One more try :)
>
> Stating that the Java version is 1.4 on the website will be done
> post-release (I'm going to split the CLI and CLI2 websites).
>
> ---
>
> Tag:
>
> https://svn.apache.org/repos/asf/commons/proper/cli/tags/cli-1.2-RC6
>
> Site remains unchanged:
>
> http://people.apache.org/~bayard/cli-1.2-rc1
>
> Binaries:
>
> http://people.apache.org/builds/commons/cli/1.2/RC6/staged/commons-cli/commons-cli/1.2/
>
> [ ] +1 release it
> [ ] +0 go ahead I don't care
> [ ] -1 no, do not release it because
>
> ---------------------------------------------------------------------
> 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