[VOTE] Release Commons SCXML 0.8

[Rahul Akolkar]

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@...
For additional commands, e-mail: dev-help@...

[Phil Steitz]

On Thu, May 15, 2008 at 5:08 PM, Rahul Akolkar <rahul.akolkar@...> 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@...
For additional commands, e-mail: dev-help@...

[Rahul Akolkar]

Thanks for your time Phil, comments below ...

On 5/16/08, Phil Steitz <phil.steitz@...> wrote:

> On Thu, May 15, 2008 at 5:08 PM, Rahul Akolkar <rahul.akolkar@...> 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@...
For additional commands, e-mail: dev-help@...

[Oliver Heger-3]

+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@...
> For additional commands, e-mail: dev-help@...
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Rahul Akolkar]

Thanks for taking a look Oliver ...

On 5/16/08, Oliver Heger <oliver.heger@...> 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@...
For additional commands, e-mail: dev-help@...

[sebb-2-2]

On 16/05/2008, Rahul Akolkar <rahul.akolkar@...> 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@...
>  For additional commands, e-mail: dev-help@...
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Luc Maisonobe]

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@...
> For additional commands, e-mail: dev-help@...
>

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@...
For additional commands, e-mail: dev-help@...

[ebourg]

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@...
> For additional commands, e-mail: dev-help@...
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Rahul Akolkar]

Thanks Luc, and I appreciate the findbugs run!

On 5/17/08, Luc Maisonobe <Luc.Maisonobe@...> 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@...
For additional commands, e-mail: dev-help@...

[Rahul Akolkar]

Thanks sebb ...

On 5/16/08, sebb <sebbaz@...> 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@...
For additional commands, e-mail: dev-help@...

[Rahul Akolkar]

On 5/17/08, Emmanuel Bourg <ebourg@...> 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@...
For additional commands, e-mail: dev-help@...

[ebourg]

Rahul Akolkar a écrit :

> On 5/17/08, Emmanuel Bourg <ebourg@...> 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@...
For additional commands, e-mail: dev-help@...

[Rahul Akolkar]

On 5/17/08, Emmanuel Bourg <ebourg@...> 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@...
For additional commands, e-mail: dev-help@...

[Luc Maisonobe]

Rahul Akolkar a écrit :

> Thanks Luc, and I appreciate the findbugs run!
>
> On 5/17/08, Luc Maisonobe <Luc.Maisonobe@...> 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@...
> For additional commands, e-mail: dev-help@...
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Niall Pemberton-2]

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 <rahul.akolkar@...> 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@...
> For additional commands, e-mail: dev-help@...
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...