You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Rahul Akolkar <ra...@gmail.com> on 2008/05/16 02:08:02 UTC
[VOTE] Release Commons SCXML 0.8
This is a vote to release the following artifacts as Commons SCXML 0.8:
http://people.apache.org/builds/commons/scxml/0.8/RC2/
------------
[ ] +1 for release
[ ] +0
[ ] -0
[ ] -1 for release because...
------------
Vote will close no sooner than Sunday, May 18th (same time).
TIA for your time,
-Rahul
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [VOTE] Release Commons SCXML 0.8
Posted by Rahul Akolkar <ra...@gmail.com>.
Thanks sebb ...
On 5/16/08, sebb <se...@gmail.com> wrote:
<snip/>
>
> Looks generally OK to me.
>
> Some minor points to consider (for next release?):
>
<snap/>
Yup, will look into these post release.
> TestingTestSuite does not seem to run any tests - it creates a suite,
> but does not add any tests to it. This results in 0% pass rate (but
> still a pass!) in the Surefire test report.
>
<snip/>
Agreed, suite best removed from the surefire report until it has tests.
> Ant build.xml does not have any source or target compiler options set.
>
<snip/>
Will add.
-Rahul
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [VOTE] Release Commons SCXML 0.8
Posted by sebb <se...@gmail.com>.
On 16/05/2008, Rahul Akolkar <ra...@gmail.com> wrote:
> This is a vote to release the following artifacts as Commons SCXML 0.8:
>
> http://people.apache.org/builds/commons/scxml/0.8/RC2/
>
> ------------
> [ ] +1 for release
+1
> [ ] +0
> [ ] -0
> [ ] -1 for release because...
> ------------
>
> Vote will close no sooner than Sunday, May 18th (same time).
Looks generally OK to me.
Some minor points to consider (for next release?):
TestingTestSuite does not seem to run any tests - it creates a suite,
but does not add any tests to it. This results in 0% pass rate (but
still a pass!) in the Surefire test report.
Ant build.xml does not have any source or target compiler options set.
>
> TIA for your time,
> -Rahul
>
> ---------------------------------------------------------------------
> 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: [RESULT][VOTE] Release Commons SCXML 0.8
Posted by Rahul Akolkar <ra...@gmail.com>.
On 5/20/08, Niall Pemberton <ni...@gmail.com> wrote:
<snip/>
>
> You probably know this, but in case you don't - because this is
> SCXML's first m2 release (or the first release of a new groupId in the
> m2 repo - i.e. "commons-scxml" in this case) you need to ping
> repository@apache.org to ask them to add that groupId to the Sync -
> otherwise it will never reach http://repo1.maven.org/maven2/
>
<snap/>
Yup, I've done that already, thanks.
-Rahul
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [RESULT][VOTE] Release Commons SCXML 0.8
Posted by Niall Pemberton <ni...@gmail.com>.
On Mon, May 19, 2008 at 6:53 PM, Rahul Akolkar <ra...@gmail.com> wrote:
> Adding my own vote, this vote passes with 6 +1s from:
>
> Phil Steitz
> Oliver Heger
> Sebb
> Luc Maisonobe
> Niall Pemberton
> Rahul Akolkar
>
> Thanks for your time and all the feedback on the process as well. I'll
> complete the related tasks in a day or two.
You probably know this, but in case you don't - because this is
SCXML's first m2 release (or the first release of a new groupId in the
m2 repo - i.e. "commons-scxml" in this case) you need to ping
repository@apache.org to ask them to add that groupId to the Sync -
otherwise it will never reach http://repo1.maven.org/maven2/
Niall
> -Rahul
>
>
> On 5/15/08, Rahul Akolkar <ra...@gmail.com> wrote:
>> This is a vote to release the following artifacts as Commons SCXML 0.8:
>>
>> http://people.apache.org/builds/commons/scxml/0.8/RC2/
>>
>> ------------
>> [ ] +1 for release
>> [ ] +0
>> [ ] -0
>> [ ] -1 for release because...
>> ------------
>>
>> Vote will close no sooner than Sunday, May 18th (same time).
>>
>> TIA for your time,
>>
>> -Rahul
>>
>
> ---------------------------------------------------------------------
> 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
[RESULT][VOTE] Release Commons SCXML 0.8
Posted by Rahul Akolkar <ra...@gmail.com>.
Adding my own vote, this vote passes with 6 +1s from:
Phil Steitz
Oliver Heger
Sebb
Luc Maisonobe
Niall Pemberton
Rahul Akolkar
Thanks for your time and all the feedback on the process as well. I'll
complete the related tasks in a day or two.
-Rahul
On 5/15/08, Rahul Akolkar <ra...@gmail.com> wrote:
> This is a vote to release the following artifacts as Commons SCXML 0.8:
>
> http://people.apache.org/builds/commons/scxml/0.8/RC2/
>
> ------------
> [ ] +1 for release
> [ ] +0
> [ ] -0
> [ ] -1 for release because...
> ------------
>
> Vote will close no sooner than Sunday, May 18th (same time).
>
> TIA for your time,
>
> -Rahul
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [VOTE] Release Commons SCXML 0.8
Posted by Rahul Akolkar <ra...@gmail.com>.
On 5/17/08, Luc Maisonobe <Lu...@free.fr> wrote:
<snip/>
>
> OK. Everything seems therefore to be either under control or false positive
> from findbugs.
>
> I therefore change my vote to +1.
>
<snap/>
Great, thanks for taking another look.
-Rahul
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [VOTE] Release Commons SCXML 0.8
Posted by Luc Maisonobe <Lu...@free.fr>.
Rahul Akolkar a écrit :
> Thanks Luc, and I appreciate the findbugs run!
>
> On 5/17/08, Luc Maisonobe <Lu...@free.fr> wrote:
> <snip/>
>> Generating the site on Linux, with maven 2 and JDK 1.6.0_06 gives me a few
>> warnings for tests javadoc (references not found for @link pointing to SCXML
>> itself). This are details.
>>
> <snap/>
>
> True, seems the test Javadoc isn't finding the source classes, will
> need to look into the configuration.
>
>
>> What bother me a little more is that I have run findbugs-maven-plugin
>> version 1.1.1 with default settings on the release candidate, and it found a
>> few bugs (27). These bugs fall into a small set of categories:
>> - incomplete synchronization on some fields,
>> - non-transient and non-serializable fields
>> - missing serialVersionUID
>> - fields not initialized in constructors
>> - non-localized toLowerCase
>> - use of System.exit
>>
>> Of course, some of them may be false positive (probably the two last).
>>
>> I don't know if the synchronization problems are real problems or not. So I
>> would temporarily vote -1 and can change it if you tell me these problems
>> are not real.
>>
> <snip/>
>
> I ran the plugin myself and have appended the report here [3].
>
> Heres the breakdown listed a bit differently:
>
> * 19 serialization issues - Most are non-transient non-serializable
> fields which are interface types whose implementations are expected to
> be serializable (for instance, JCL/ACL Log is mostly considered OK
> from a serialization perspective in v1.0.4+). Moreover, the JUnit
> tests actually test for serialization, they will at random try to
> write active instances to disk (see target/serialization directory
> where you should find 100+ of serialized instances written out) and
> read them back in before proceeding with the rest of the test. We know
> serialization works atleast for the subset the tests exercise.
>
> * 5 synchronization issues (2 inconsistent sync, 3 field not
> initialized in constructor) - This has to do with library-specific
> patterns. For the inconsistent sync ones, see Javadoc notes in
> getter/setter for SCXMLExecutor.stateMachine (IOW, some bits are
> considered immutable once configured for the lifetime of the executor)
> and this thread [1] as an example. Separately, findbugs is not always
> able to recognize lazy initialization. For the not initialized in
> constructor reports, see the Invoker lifecycle documented here [2]
> etc. Multiple folks have reported stress testing the library over the
> three years so there is also some anecdotal evidence that it works
> when used as designed :-)
>
> * 2 issues in StandaloneUtils class in test package - Its a command
> line tool / toy that can be used to better understand SCXML (you can
> load up a document, fire events using the command line, watch
> transitions etc.), the merit of the issues reported in this context is
> debatable.
>
> * 1 performance issue - Doesn't seem to be a deal breaker.
>
> If you think any of these should be fixed immediately, I'll gladly do
> it, but please also suggest a fix if you can (I don't know what the
> fixes would be since I think in a particular way on each of these
> issues and I'll have to fabricate fixes which I don't care to do :-).
>
OK. Everything seems therefore to be either under control or false
positive from findbugs.
I therefore change my vote to +1.
Luc
> -Rahul
>
> [1] http://markmail.org/message/4zvgpo36o3kgoyz5
>
> [2] http://commons.apache.org/scxml/0.7/apidocs/org/apache/commons/scxml/invoke/Invoker.html
>
> [3]
> Inconsistent synchronization of
> org.apache.commons.scxml.SCXMLExecutor.errorReporter; locked 76% of
> time MT_CORRECTNESS IS2_INCONSISTENT_SYNC 337
>
> Inconsistent synchronization of
> org.apache.commons.scxml.SCXMLExecutor.stateMachine; locked 77% of
> time MT_CORRECTNESS IS2_INCONSISTENT_SYNC 340
>
> Method org.apache.commons.scxml.SCXMLExecutor.updateStatus(Step) uses
> Collection.toArray() with zero-length array argument PERFORMANCE
> ITA_INEFFICIENT_TO_ARRAY 549
>
> Class org.apache.commons.scxml.SCXMLExecutor defines non-transient
> non-serializable instance field log BAD_PRACTICE SE_BAD_FIELD Not
> available
>
> Class org.apache.commons.scxml.env.SimpleContext defines non-transient
> non-serializable instance field log BAD_PRACTICE SE_BAD_FIELD Not
> available
>
> Class org.apache.commons.scxml.env.SimpleDispatcher defines
> non-transient non-serializable instance field log BAD_PRACTICE
> SE_BAD_FIELD Not available
>
> Class org.apache.commons.scxml.env.SimpleErrorHandler defines
> non-transient non-serializable instance field log BAD_PRACTICE
> SE_BAD_FIELD Not available
>
> Class org.apache.commons.scxml.env.SimpleErrorReporter defines
> non-transient non-serializable instance field log BAD_PRACTICE
> SE_BAD_FIELD Not available
>
> Class org.apache.commons.scxml.env.SimpleSCXMLListener defines
> non-transient non-serializable instance field log BAD_PRACTICE
> SE_BAD_FIELD Not available
>
> Class org.apache.commons.scxml.env.SimpleScheduler defines
> non-transient non-serializable instance field log BAD_PRACTICE
> SE_BAD_FIELD Not available
>
> Class org.apache.commons.scxml.env.Tracer defines non-transient
> non-serializable instance field errHandler BAD_PRACTICE SE_BAD_FIELD
> Not available
>
> Class org.apache.commons.scxml.env.Tracer defines non-transient
> non-serializable instance field scxmlListener BAD_PRACTICE
> SE_BAD_FIELD Not available
>
> Class org.apache.commons.scxml.env.URLResolver defines non-transient
> non-serializable instance field log BAD_PRACTICE SE_BAD_FIELD Not
> available
>
> Class org.apache.commons.scxml.env.jsp.ELEvaluator defines
> non-transient non-serializable instance field log BAD_PRACTICE
> SE_BAD_FIELD Not available
>
> The field org.apache.commons.scxml.env.jsp.ELEvaluator.ee is transient
> but isn't set by deserialization BAD_PRACTICE
> SE_TRANSIENT_FIELD_NOT_RESTORED Not available
>
> Class org.apache.commons.scxml.env.jsp.ELEvaluator$BuiltinFunctionMapper
> defines non-transient non-serializable instance field log BAD_PRACTICE
> SE_BAD_FIELD Not available
>
> Class org.apache.commons.scxml.env.jsp.ELEvaluator$ContextWrapper
> defines non-transient non-serializable instance field log BAD_PRACTICE
> SE_BAD_FIELD Not available
>
> org.apache.commons.scxml.env.jsp.RootContext is Serializable; consider
> declaring a serialVersionUID BAD_PRACTICE SE_NO_SERIALVERSIONID Not
> available
>
> SimpleSCXMLInvoker.executor not initialized in constructor STYLE
> UWF_FIELD_NOT_INITIALIZED_IN_CONSTRUCTOR Not available
>
> SimpleSCXMLInvoker.parentSCInstance not initialized in constructor
> STYLE UWF_FIELD_NOT_INITIALIZED_IN_CONSTRUCTOR Not available
>
> Class org.apache.commons.scxml.model.Assign defines non-transient
> non-serializable instance field pathResolver BAD_PRACTICE SE_BAD_FIELD
> Not available
>
> Class org.apache.commons.scxml.model.Data defines non-transient
> non-serializable instance field node BAD_PRACTICE SE_BAD_FIELD Not
> available
>
> Class org.apache.commons.scxml.model.Invoke defines non-transient
> non-serializable instance field pathResolver BAD_PRACTICE SE_BAD_FIELD
> Not available
>
> Send.delay not initialized in constructor STYLE
> UWF_FIELD_NOT_INITIALIZED_IN_CONSTRUCTOR Not available
>
> Class org.apache.commons.scxml.semantics.SCXMLSemanticsImpl defines
> non-transient non-serializable instance field appLog BAD_PRACTICE
> SE_BAD_FIELD Not available
>
> org.apache.commons.scxml.test.StandaloneUtils Use of non-localized
> String.toUpperCase() or String.toLowerCase I18N DM_CONVERT_CASE 157
>
> org.apache.commons.scxml.test.StandaloneUtils.execute(String,
> Evaluator) invokes System.exit(...), which shuts down the entire
> virtual machine BAD_PRACTICE DM_EXIT 83
>
> ---------------------------------------------------------------------
> 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 SCXML 0.8
Posted by Rahul Akolkar <ra...@gmail.com>.
Thanks Luc, and I appreciate the findbugs run!
On 5/17/08, Luc Maisonobe <Lu...@free.fr> wrote:
<snip/>
>
> Generating the site on Linux, with maven 2 and JDK 1.6.0_06 gives me a few
> warnings for tests javadoc (references not found for @link pointing to SCXML
> itself). This are details.
>
<snap/>
True, seems the test Javadoc isn't finding the source classes, will
need to look into the configuration.
> What bother me a little more is that I have run findbugs-maven-plugin
> version 1.1.1 with default settings on the release candidate, and it found a
> few bugs (27). These bugs fall into a small set of categories:
> - incomplete synchronization on some fields,
> - non-transient and non-serializable fields
> - missing serialVersionUID
> - fields not initialized in constructors
> - non-localized toLowerCase
> - use of System.exit
>
> Of course, some of them may be false positive (probably the two last).
>
> I don't know if the synchronization problems are real problems or not. So I
> would temporarily vote -1 and can change it if you tell me these problems
> are not real.
>
<snip/>
I ran the plugin myself and have appended the report here [3].
Heres the breakdown listed a bit differently:
* 19 serialization issues - Most are non-transient non-serializable
fields which are interface types whose implementations are expected to
be serializable (for instance, JCL/ACL Log is mostly considered OK
from a serialization perspective in v1.0.4+). Moreover, the JUnit
tests actually test for serialization, they will at random try to
write active instances to disk (see target/serialization directory
where you should find 100+ of serialized instances written out) and
read them back in before proceeding with the rest of the test. We know
serialization works atleast for the subset the tests exercise.
* 5 synchronization issues (2 inconsistent sync, 3 field not
initialized in constructor) - This has to do with library-specific
patterns. For the inconsistent sync ones, see Javadoc notes in
getter/setter for SCXMLExecutor.stateMachine (IOW, some bits are
considered immutable once configured for the lifetime of the executor)
and this thread [1] as an example. Separately, findbugs is not always
able to recognize lazy initialization. For the not initialized in
constructor reports, see the Invoker lifecycle documented here [2]
etc. Multiple folks have reported stress testing the library over the
three years so there is also some anecdotal evidence that it works
when used as designed :-)
* 2 issues in StandaloneUtils class in test package - Its a command
line tool / toy that can be used to better understand SCXML (you can
load up a document, fire events using the command line, watch
transitions etc.), the merit of the issues reported in this context is
debatable.
* 1 performance issue - Doesn't seem to be a deal breaker.
If you think any of these should be fixed immediately, I'll gladly do
it, but please also suggest a fix if you can (I don't know what the
fixes would be since I think in a particular way on each of these
issues and I'll have to fabricate fixes which I don't care to do :-).
-Rahul
[1] http://markmail.org/message/4zvgpo36o3kgoyz5
[2] http://commons.apache.org/scxml/0.7/apidocs/org/apache/commons/scxml/invoke/Invoker.html
[3]
Inconsistent synchronization of
org.apache.commons.scxml.SCXMLExecutor.errorReporter; locked 76% of
time MT_CORRECTNESS IS2_INCONSISTENT_SYNC 337
Inconsistent synchronization of
org.apache.commons.scxml.SCXMLExecutor.stateMachine; locked 77% of
time MT_CORRECTNESS IS2_INCONSISTENT_SYNC 340
Method org.apache.commons.scxml.SCXMLExecutor.updateStatus(Step) uses
Collection.toArray() with zero-length array argument PERFORMANCE
ITA_INEFFICIENT_TO_ARRAY 549
Class org.apache.commons.scxml.SCXMLExecutor defines non-transient
non-serializable instance field log BAD_PRACTICE SE_BAD_FIELD Not
available
Class org.apache.commons.scxml.env.SimpleContext defines non-transient
non-serializable instance field log BAD_PRACTICE SE_BAD_FIELD Not
available
Class org.apache.commons.scxml.env.SimpleDispatcher defines
non-transient non-serializable instance field log BAD_PRACTICE
SE_BAD_FIELD Not available
Class org.apache.commons.scxml.env.SimpleErrorHandler defines
non-transient non-serializable instance field log BAD_PRACTICE
SE_BAD_FIELD Not available
Class org.apache.commons.scxml.env.SimpleErrorReporter defines
non-transient non-serializable instance field log BAD_PRACTICE
SE_BAD_FIELD Not available
Class org.apache.commons.scxml.env.SimpleSCXMLListener defines
non-transient non-serializable instance field log BAD_PRACTICE
SE_BAD_FIELD Not available
Class org.apache.commons.scxml.env.SimpleScheduler defines
non-transient non-serializable instance field log BAD_PRACTICE
SE_BAD_FIELD Not available
Class org.apache.commons.scxml.env.Tracer defines non-transient
non-serializable instance field errHandler BAD_PRACTICE SE_BAD_FIELD
Not available
Class org.apache.commons.scxml.env.Tracer defines non-transient
non-serializable instance field scxmlListener BAD_PRACTICE
SE_BAD_FIELD Not available
Class org.apache.commons.scxml.env.URLResolver defines non-transient
non-serializable instance field log BAD_PRACTICE SE_BAD_FIELD Not
available
Class org.apache.commons.scxml.env.jsp.ELEvaluator defines
non-transient non-serializable instance field log BAD_PRACTICE
SE_BAD_FIELD Not available
The field org.apache.commons.scxml.env.jsp.ELEvaluator.ee is transient
but isn't set by deserialization BAD_PRACTICE
SE_TRANSIENT_FIELD_NOT_RESTORED Not available
Class org.apache.commons.scxml.env.jsp.ELEvaluator$BuiltinFunctionMapper
defines non-transient non-serializable instance field log BAD_PRACTICE
SE_BAD_FIELD Not available
Class org.apache.commons.scxml.env.jsp.ELEvaluator$ContextWrapper
defines non-transient non-serializable instance field log BAD_PRACTICE
SE_BAD_FIELD Not available
org.apache.commons.scxml.env.jsp.RootContext is Serializable; consider
declaring a serialVersionUID BAD_PRACTICE SE_NO_SERIALVERSIONID Not
available
SimpleSCXMLInvoker.executor not initialized in constructor STYLE
UWF_FIELD_NOT_INITIALIZED_IN_CONSTRUCTOR Not available
SimpleSCXMLInvoker.parentSCInstance not initialized in constructor
STYLE UWF_FIELD_NOT_INITIALIZED_IN_CONSTRUCTOR Not available
Class org.apache.commons.scxml.model.Assign defines non-transient
non-serializable instance field pathResolver BAD_PRACTICE SE_BAD_FIELD
Not available
Class org.apache.commons.scxml.model.Data defines non-transient
non-serializable instance field node BAD_PRACTICE SE_BAD_FIELD Not
available
Class org.apache.commons.scxml.model.Invoke defines non-transient
non-serializable instance field pathResolver BAD_PRACTICE SE_BAD_FIELD
Not available
Send.delay not initialized in constructor STYLE
UWF_FIELD_NOT_INITIALIZED_IN_CONSTRUCTOR Not available
Class org.apache.commons.scxml.semantics.SCXMLSemanticsImpl defines
non-transient non-serializable instance field appLog BAD_PRACTICE
SE_BAD_FIELD Not available
org.apache.commons.scxml.test.StandaloneUtils Use of non-localized
String.toUpperCase() or String.toLowerCase I18N DM_CONVERT_CASE 157
org.apache.commons.scxml.test.StandaloneUtils.execute(String,
Evaluator) invokes System.exit(...), which shuts down the entire
virtual machine BAD_PRACTICE DM_EXIT 83
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [VOTE] Release Commons SCXML 0.8
Posted by Luc Maisonobe <Lu...@free.fr>.
Rahul Akolkar a écrit :
> This is a vote to release the following artifacts as Commons SCXML 0.8:
>
> http://people.apache.org/builds/commons/scxml/0.8/RC2/
>
> ------------
> [ ] +1 for release
> [ ] +0
> [ ] -0
> [ ] -1 for release because...
> ------------
>
> Vote will close no sooner than Sunday, May 18th (same time).
>
> TIA for your time,
> -Rahul
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
Generating the site on Linux, with maven 2 and JDK 1.6.0_06 gives me a
few warnings for tests javadoc (references not found for @link pointing
to SCXML itself). This are details.
What bother me a little more is that I have run findbugs-maven-plugin
version 1.1.1 with default settings on the release candidate, and it
found a few bugs (27). These bugs fall into a small set of categories:
- incomplete synchronization on some fields,
- non-transient and non-serializable fields
- missing serialVersionUID
- fields not initialized in constructors
- non-localized toLowerCase
- use of System.exit
Of course, some of them may be false positive (probably the two last).
I don't know if the synchronization problems are real problems or not.
So I would temporarily vote -1 and can change it if you tell me these
problems are not real.
Luc
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [VOTE] Release Commons SCXML 0.8
Posted by Niall Pemberton <ni...@gmail.com>.
On Fri, May 16, 2008 at 6:14 PM, Rahul Akolkar <ra...@gmail.com> wrote:
> Thanks for your time Phil, comments below ...
>
> On 5/16/08, Phil Steitz <ph...@gmail.com> wrote:
>> On Thu, May 15, 2008 at 5:08 PM, Rahul Akolkar <ra...@gmail.com> wrote:
>> > This is a vote to release the following artifacts as Commons SCXML 0.8:
>> >
>> > http://people.apache.org/builds/commons/scxml/0.8/RC2/
>> >
>> > ------------
>>
>> > [ X] +1 for release
>>
>> > [ ] +0
>> > [ ] -0
>> > [ ] -1 for release because...
>> > ------------
>> >
>>
>>
>> Checked sigs, hashes, tag, m1, m2, Ant builds - all fine. I assume
>> the OSGi stuff in the jar manifest is OK, despite funny formatting.
>> Please someone verify.
>>
> <snip/>
>
> AIUI, the OSGi plugin just enforces the manifest line width
> restrictions. Ofcourse, happy to have more people verify.
Looks OK to me - like you, I assume Phil's "funny formatting" comment
relates to the Import-Package/Export-Package statements being wrapped
to 72 characters. Its worth remembering that the MANIFEST is intended
for "machine-consumption" rather than human-readable. The
maven-bundle-plugin that generates those OSGi entries formats them
correctly as per the manifest spec.
Niall
>> I guess its the release plugin that does this:
>> <connection>scm:svn:http://svn.apache.org/repos/asf/commons/proper/scxml/tags/SCXML_0_8_RC2</connection>
>> ?
>>
> <snap/>
>
> Yes, but under my tutelage, so I'll take all the blame on this one :-)
>
> I did spend some time thinking about this beforehand. Of these two approaches:
>
> 1. Tag each RC as if it were the final / release tag. Delete tag if
> RC++, and redo.
> 2. Tag RCs as RCs. Copy tag for passing RC as release tag.
>
> ... I personally prefer the latter, since:
>
> * I don't like the idea of a release tag existing before a release
> passes muster
> * I think its good housekeeping to retain RC tags
>
>
>> The site builds fine from the source distro, but will point to the RC2
>> tag in project info. I guess this is OK, since the tag is going to be
>> copied on release.
>>
> <snip/>
>
> Yes, it'll be copied to SCXML_0_8 if vote passes. The way the Commons
> SCXML site on c.a.o is deployed, its always the latest / snapshot
> (there are separate pointers in site navbar for release documentation,
> such as Javadocs), so the c.a.o site will have the correct bits in
> project info. Folks building from 0.8 source will indeed get the RC2
> tag (the tag will not be removed).
>
> Finally, if anyone wants to discuss tagging with the release plugin
> any more (though not too much more :-), I'm happy to do that in a new
> thread.
>
> -Rahul
>
>
>> Phil
>>
>
> ---------------------------------------------------------------------
> 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 SCXML 0.8
Posted by Niall Pemberton <ni...@gmail.com>.
On Sat, May 17, 2008 at 9:37 PM, Niall Pemberton
<ni...@gmail.com> wrote:
> On Fri, May 16, 2008 at 6:14 PM, Rahul Akolkar <ra...@gmail.com> wrote:
>> Thanks for your time Phil, comments below ...
>>
>> On 5/16/08, Phil Steitz <ph...@gmail.com> wrote:
>>> On Thu, May 15, 2008 at 5:08 PM, Rahul Akolkar <ra...@gmail.com> wrote:
>>> > This is a vote to release the following artifacts as Commons SCXML 0.8:
>>> >
>>> > http://people.apache.org/builds/commons/scxml/0.8/RC2/
>>> >
>>> > ------------
>>>
>>> > [ X] +1 for release
>>>
>>> > [ ] +0
>>> > [ ] -0
>>> > [ ] -1 for release because...
>>> > ------------
>>> >
>>>
>>>
>>> Checked sigs, hashes, tag, m1, m2, Ant builds - all fine. I assume
>>> the OSGi stuff in the jar manifest is OK, despite funny formatting.
>>> Please someone verify.
>>>
>> <snip/>
>>
>> AIUI, the OSGi plugin just enforces the manifest line width
>> restrictions. Ofcourse, happy to have more people verify.
>>
>>
>>> I guess its the release plugin that does this:
>>> <connection>scm:svn:http://svn.apache.org/repos/asf/commons/proper/scxml/tags/SCXML_0_8_RC2</connection>
>>> ?
>>>
>> <snap/>
>>
>> Yes, but under my tutelage, so I'll take all the blame on this one :-)
>>
>> I did spend some time thinking about this beforehand. Of these two approaches:
>>
>> 1. Tag each RC as if it were the final / release tag. Delete tag if
>> RC++, and redo.
>> 2. Tag RCs as RCs. Copy tag for passing RC as release tag.
>>
>> ... I personally prefer the latter, since:
>>
>> * I don't like the idea of a release tag existing before a release
>> passes muster
>> * I think its good housekeeping to retain RC tags
>>
>>
>>> The site builds fine from the source distro, but will point to the RC2
>>> tag in project info. I guess this is OK, since the tag is going to be
>>> copied on release.
>>>
>> <snip/>
>>
>> Yes, it'll be copied to SCXML_0_8 if vote passes. The way the Commons
>> SCXML site on c.a.o is deployed, its always the latest / snapshot
>> (there are separate pointers in site navbar for release documentation,
>> such as Javadocs), so the c.a.o site will have the correct bits in
>> project info. Folks building from 0.8 source will indeed get the RC2
>> tag (the tag will not be removed).
>
> IMO this is another reason to not use the release plugin - along with
> the facts that 1) if you don't remember to do a "dryRun" it may remove
> the license header and 2) it generates an awful lot of commit noise to
> just change the version number. The only downside to manually
> releasing IMo is that you have to hand-edit the maven-metadata.xml.
>
> While its not a show-stopper that the pom points to the RC2 tag - its
> not desirable at all - but if people to want to use the release plugin
> then IMO it would be much better to do the svn tag manually and skip
> the "release:prepare" step altogether. AIUI you can run the
> release:perform and specify the tag on the command line, something
> like
>
> mvn -Prc -Dtag=SCXML_0_8_RC2 release:perform
My mistake, I think its connectionUrl, rather than tag:
http://maven.apache.org/plugins/maven-release-plugin/examples/perform-release.html
Niall
Alternatively, from looking at the docs, theres also an option to not update the
> Niall
>
>
>> Finally, if anyone wants to discuss tagging with the release plugin
>> any more (though not too much more :-), I'm happy to do that in a new
>> thread.
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [VOTE] Release Commons SCXML 0.8
Posted by Niall Pemberton <ni...@gmail.com>.
On Fri, May 16, 2008 at 6:14 PM, Rahul Akolkar <ra...@gmail.com> wrote:
> Thanks for your time Phil, comments below ...
>
> On 5/16/08, Phil Steitz <ph...@gmail.com> wrote:
>> On Thu, May 15, 2008 at 5:08 PM, Rahul Akolkar <ra...@gmail.com> wrote:
>> > This is a vote to release the following artifacts as Commons SCXML 0.8:
>> >
>> > http://people.apache.org/builds/commons/scxml/0.8/RC2/
>> >
>> > ------------
>>
>> > [ X] +1 for release
>>
>> > [ ] +0
>> > [ ] -0
>> > [ ] -1 for release because...
>> > ------------
>> >
>>
>>
>> Checked sigs, hashes, tag, m1, m2, Ant builds - all fine. I assume
>> the OSGi stuff in the jar manifest is OK, despite funny formatting.
>> Please someone verify.
>>
> <snip/>
>
> AIUI, the OSGi plugin just enforces the manifest line width
> restrictions. Ofcourse, happy to have more people verify.
>
>
>> I guess its the release plugin that does this:
>> <connection>scm:svn:http://svn.apache.org/repos/asf/commons/proper/scxml/tags/SCXML_0_8_RC2</connection>
>> ?
>>
> <snap/>
>
> Yes, but under my tutelage, so I'll take all the blame on this one :-)
>
> I did spend some time thinking about this beforehand. Of these two approaches:
>
> 1. Tag each RC as if it were the final / release tag. Delete tag if
> RC++, and redo.
> 2. Tag RCs as RCs. Copy tag for passing RC as release tag.
>
> ... I personally prefer the latter, since:
>
> * I don't like the idea of a release tag existing before a release
> passes muster
> * I think its good housekeeping to retain RC tags
>
>
>> The site builds fine from the source distro, but will point to the RC2
>> tag in project info. I guess this is OK, since the tag is going to be
>> copied on release.
>>
> <snip/>
>
> Yes, it'll be copied to SCXML_0_8 if vote passes. The way the Commons
> SCXML site on c.a.o is deployed, its always the latest / snapshot
> (there are separate pointers in site navbar for release documentation,
> such as Javadocs), so the c.a.o site will have the correct bits in
> project info. Folks building from 0.8 source will indeed get the RC2
> tag (the tag will not be removed).
IMO this is another reason to not use the release plugin - along with
the facts that 1) if you don't remember to do a "dryRun" it may remove
the license header and 2) it generates an awful lot of commit noise to
just change the version number. The only downside to manually
releasing IMo is that you have to hand-edit the maven-metadata.xml.
While its not a show-stopper that the pom points to the RC2 tag - its
not desirable at all - but if people to want to use the release plugin
then IMO it would be much better to do the svn tag manually and skip
the "release:prepare" step altogether. AIUI you can run the
release:perform and specify the tag on the command line, something
like
mvn -Prc -Dtag=SCXML_0_8_RC2 release:perform
Niall
> Finally, if anyone wants to discuss tagging with the release plugin
> any more (though not too much more :-), I'm happy to do that in a new
> thread.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [VOTE] Release Commons SCXML 0.8
Posted by Rahul Akolkar <ra...@gmail.com>.
Thanks for your time Phil, comments below ...
On 5/16/08, Phil Steitz <ph...@gmail.com> wrote:
> On Thu, May 15, 2008 at 5:08 PM, Rahul Akolkar <ra...@gmail.com> wrote:
> > This is a vote to release the following artifacts as Commons SCXML 0.8:
> >
> > http://people.apache.org/builds/commons/scxml/0.8/RC2/
> >
> > ------------
>
> > [ X] +1 for release
>
> > [ ] +0
> > [ ] -0
> > [ ] -1 for release because...
> > ------------
> >
>
>
> Checked sigs, hashes, tag, m1, m2, Ant builds - all fine. I assume
> the OSGi stuff in the jar manifest is OK, despite funny formatting.
> Please someone verify.
>
<snip/>
AIUI, the OSGi plugin just enforces the manifest line width
restrictions. Ofcourse, happy to have more people verify.
> I guess its the release plugin that does this:
> <connection>scm:svn:http://svn.apache.org/repos/asf/commons/proper/scxml/tags/SCXML_0_8_RC2</connection>
> ?
>
<snap/>
Yes, but under my tutelage, so I'll take all the blame on this one :-)
I did spend some time thinking about this beforehand. Of these two approaches:
1. Tag each RC as if it were the final / release tag. Delete tag if
RC++, and redo.
2. Tag RCs as RCs. Copy tag for passing RC as release tag.
... I personally prefer the latter, since:
* I don't like the idea of a release tag existing before a release
passes muster
* I think its good housekeeping to retain RC tags
> The site builds fine from the source distro, but will point to the RC2
> tag in project info. I guess this is OK, since the tag is going to be
> copied on release.
>
<snip/>
Yes, it'll be copied to SCXML_0_8 if vote passes. The way the Commons
SCXML site on c.a.o is deployed, its always the latest / snapshot
(there are separate pointers in site navbar for release documentation,
such as Javadocs), so the c.a.o site will have the correct bits in
project info. Folks building from 0.8 source will indeed get the RC2
tag (the tag will not be removed).
Finally, if anyone wants to discuss tagging with the release plugin
any more (though not too much more :-), I'm happy to do that in a new
thread.
-Rahul
> Phil
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [VOTE] Release Commons SCXML 0.8
Posted by Phil Steitz <ph...@gmail.com>.
On Thu, May 15, 2008 at 5:08 PM, Rahul Akolkar <ra...@gmail.com> wrote:
> This is a vote to release the following artifacts as Commons SCXML 0.8:
>
> http://people.apache.org/builds/commons/scxml/0.8/RC2/
>
> ------------
> [ X] +1 for release
> [ ] +0
> [ ] -0
> [ ] -1 for release because...
> ------------
>
Checked sigs, hashes, tag, m1, m2, Ant builds - all fine. I assume
the OSGi stuff in the jar manifest is OK, despite funny formatting.
Please someone verify.
I guess its the release plugin that does this:
<connection>scm:svn:http://svn.apache.org/repos/asf/commons/proper/scxml/tags/SCXML_0_8_RC2</connection>
?
The site builds fine from the source distro, but will point to the RC2
tag in project info. I guess this is OK, since the tag is going to be
copied on release.
Phil
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [VOTE] Release Commons SCXML 0.8
Posted by Rahul Akolkar <ra...@gmail.com>.
On 5/17/08, Niall Pemberton <ni...@gmail.com> wrote:
> Firstly +1 from me on this release.
>
> A couple of minor points...
>
> 1) The changes report usually has links to the JIRA tickets, but these
> seem to be missing.
> 2) The dependencyManagement section in the parent pom only affects
> <build>, and not <reporting>, so would be good pratice to specify
> plugin version numbers in the reporting section to make the build
> repeatable.
>
> I fixed this in the trunk for next time:
> http://svn.apache.org/viewvc?view=rev&revision=657456
>
<snip/>
Many thanks for the fixes Niall !
-Rahul
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [VOTE] Release Commons SCXML 0.8
Posted by Niall Pemberton <ni...@gmail.com>.
Firstly +1 from me on this release.
A couple of minor points...
1) The changes report usually has links to the JIRA tickets, but these
seem to be missing.
2) The dependencyManagement section in the parent pom only affects
<build>, and not <reporting>, so would be good pratice to specify
plugin version numbers in the reporting section to make the build
repeatable.
I fixed this in the trunk for next time:
http://svn.apache.org/viewvc?view=rev&revision=657456
Niall
On Fri, May 16, 2008 at 1:08 AM, Rahul Akolkar <ra...@gmail.com> wrote:
> This is a vote to release the following artifacts as Commons SCXML 0.8:
>
> http://people.apache.org/builds/commons/scxml/0.8/RC2/
>
> ------------
> [ ] +1 for release
> [ ] +0
> [ ] -0
> [ ] -1 for release because...
> ------------
>
> Vote will close no sooner than Sunday, May 18th (same time).
>
> TIA for your time,
> -Rahul
>
> ---------------------------------------------------------------------
> 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 SCXML 0.8
Posted by Emmanuel Bourg <eb...@apache.org>.
Rahul Akolkar a écrit :
> <OT>
> Whats the deal with linking to J6, as you were discussing in some JIRA comments?
> </OT>
No idea, Henri stated that we can't link to Java 6 in COMMONSSITE-29,
but I don't know why.
Emmanuel Bourg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [VOTE] Release Commons SCXML 0.8
Posted by Rahul Akolkar <ra...@gmail.com>.
On 5/17/08, Emmanuel Bourg <eb...@apache.org> wrote:
<snip/>
>
> The Javadoc would be nicer with external links to the JDK, JEE and
> Digester. You just have to add this in the POM:
>
> <reporting>
> <plugins>
> <plugin>
> <groupId>org.apache.maven.plugins</groupId>
> <artifactId>maven-javadoc-plugin</artifactId>
> <configuration>
> <linksource>true</linksource>
> <links>
>
> <link>http://java.sun.com/javase/6/docs/api</link>
>
> <link>http://java.sun.com/javaee/5/docs/api/</link>
>
> <link>http://commons.apache.org/digester/apidocs/</link>
> </links>
> </configuration>
> </plugin>
> </plugins>
> </reporting>
>
<snap/>
OK.
<OT>
Whats the deal with linking to J6, as you were discussing in some JIRA comments?
</OT>
-Rahul
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [VOTE] Release Commons SCXML 0.8
Posted by Emmanuel Bourg <eb...@apache.org>.
Rahul Akolkar a écrit :
> On 5/17/08, Emmanuel Bourg <eb...@apache.org> wrote:
>> The links to the javadoc are broken on the site, is this intentional ?
>>
> <snip/>
>
> Its a combination of staging and the way the Commons SCXML site is
> organized on c.a.o.
>
> On the staged site, you can get to the release Javadocs from "Project Reports":
>
> http://people.apache.org/builds/commons/scxml/0.8/RC2/site/apidocs/index.html
>
> -Rahul
The Javadoc would be nicer with external links to the JDK, JEE and
Digester. You just have to add this in the POM:
<reporting>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-javadoc-plugin</artifactId>
<configuration>
<linksource>true</linksource>
<links>
<link>http://java.sun.com/javase/6/docs/api</link>
<link>http://java.sun.com/javaee/5/docs/api/</link>
<link>http://commons.apache.org/digester/apidocs/</link>
</links>
</configuration>
</plugin>
</plugins>
</reporting>
Emmanuel Bourg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [VOTE] Release Commons SCXML 0.8
Posted by Rahul Akolkar <ra...@gmail.com>.
On 5/17/08, Emmanuel Bourg <eb...@apache.org> wrote:
> The links to the javadoc are broken on the site, is this intentional ?
>
<snip/>
Its a combination of staging and the way the Commons SCXML site is
organized on c.a.o.
On the staged site, you can get to the release Javadocs from "Project Reports":
http://people.apache.org/builds/commons/scxml/0.8/RC2/site/apidocs/index.html
-Rahul
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [VOTE] Release Commons SCXML 0.8
Posted by Emmanuel Bourg <eb...@apache.org>.
The links to the javadoc are broken on the site, is this intentional ?
Emmanuel Bourg
Rahul Akolkar a écrit :
> This is a vote to release the following artifacts as Commons SCXML 0.8:
>
> http://people.apache.org/builds/commons/scxml/0.8/RC2/
>
> ------------
> [ ] +1 for release
> [ ] +0
> [ ] -0
> [ ] -1 for release because...
> ------------
>
> Vote will close no sooner than Sunday, May 18th (same time).
>
> TIA for your time,
> -Rahul
>
> ---------------------------------------------------------------------
> 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 SCXML 0.8
Posted by Rahul Akolkar <ra...@gmail.com>.
Thanks for taking a look Oliver ...
On 5/16/08, Oliver Heger <ol...@oliver-heger.de> wrote:
> +1
>
> Build works fine on JDK 1.6, all artifacts look good.
>
> The only minor nit I have is the checkstyle report containing 164 errors,
> but I guess this is of minor importance.
>
<snip/>
Ugh, missed that. There seem to be some changes in the m1 vs. m2
checkstyle reports, here [1] is a m1-generated report which seems to
account for @see tags etc. I'm fairly sure no new checkstyle errors
were added between v0.7 and the v0.8 RCs. I'll try to tidy up the m2
report down the road.
-Rahul
[1] http://people.apache.org/~rahul/commons/scxml-0.7/rc2/site/checkstyle-report.html
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [VOTE] Release Commons SCXML 0.8
Posted by Oliver Heger <ol...@oliver-heger.de>.
+1
Build works fine on JDK 1.6, all artifacts look good.
The only minor nit I have is the checkstyle report containing 164
errors, but I guess this is of minor importance.
Oliver
Rahul Akolkar schrieb:
> This is a vote to release the following artifacts as Commons SCXML 0.8:
>
> http://people.apache.org/builds/commons/scxml/0.8/RC2/
>
> ------------
> [ ] +1 for release
> [ ] +0
> [ ] -0
> [ ] -1 for release because...
> ------------
>
> Vote will close no sooner than Sunday, May 18th (same time).
>
> TIA for your time,
> -Rahul
>
> ---------------------------------------------------------------------
> 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