[GUMP@vmgump]: Project commons-io-test (in module apache-commons) failed

[Gump]

To whom it may engage...

This is an automated request, but not an unsolicited one. For 
more information please visit http://gump.apache.org/nagged.html, 
and/or contact the folk at gene...@gump.apache.org.

Project commons-io-test has an issue affecting its community integration.
This issue affects 1 projects,
 and has been outstanding for 41 runs.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
- commons-io-test :  Apache Commons


Full details are available at:

http://vmgump.apache.org/gump/public/apache-commons/commons-io-test/index.html

That said, some information snippets are provided here.

The following annotations (debug/informational/warning/error messages) were 
provided:
 -WARNING- Overriding Maven settings: 
[/srv/gump/public/workspace/apache-commons/io/gump_mvn_settings.xml]
 -DEBUG- (Apache Gump generated) Apache Maven Settings in: 
/srv/gump/public/workspace/apache-commons/io/gump_mvn_settings.xml
 -INFO- Failed with reason build failed
 -DEBUG- Maven POM in: /srv/gump/public/workspace/apache-commons/io/pom.xml
 -INFO- Project Reports in: 
/srv/gump/public/workspace/apache-commons/io/target/surefire-reports



The following work was performed:
http://vmgump.apache.org/gump/public/apache-commons/commons-io-test/gump_work/build_apache-commons_commons-io-test.html
Work Name: build_apache-commons_commons-io-test (Type: Build)
Work ended in a state of : Failed
Elapsed: 1 min 56 secs
Command Line: /opt/maven2/bin/mvn --batch-mode --settings 
/srv/gump/public/workspace/apache-commons/io/gump_mvn_settings.xml test 
[Working Directory: /srv/gump/public/workspace/apache-commons/io]
M2_HOME: /opt/maven2
-
Running org.apache.commons.io.comparator.CompositeFileComparatorTest
Tests run: 10, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.159 sec
Running org.apache.commons.io.comparator.DefaultFileComparatorTest
Tests run: 7, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.133 sec
Running org.apache.commons.io.comparator.DirectoryFileComparatorTest
Tests run: 7, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.137 sec
Running org.apache.commons.io.comparator.ExtensionFileComparatorTest
Tests run: 8, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.137 sec
Running org.apache.commons.io.comparator.PathFileComparatorTest
Tests run: 8, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.136 sec
Running org.apache.commons.io.comparator.NameFileComparatorTest
Tests run: 8, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.135 sec
Running org.apache.commons.io.IOUtilsTestCase
Tests run: 63, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.632 sec
Running org.apache.commons.io.IOCaseTestCase
Tests run: 17, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.148 sec
Running org.apache.commons.io.LineIteratorTestCase
Tests run: 16, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.263 sec
Running org.apache.commons.io.FileUtilsCleanDirectoryTestCase
Tests run: 5, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.171 sec
Running org.apache.commons.io.IOUtilsWriteTestCase
Tests run: 53, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.405 sec
Running org.apache.commons.io.FilenameUtilsWildcardTestCase
Tests run: 7, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.206 sec
Running org.apache.commons.io.FileUtilsListFilesTestCase
Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.156 sec
Running org.apache.commons.io.FileSystemUtilsTestCase
Tests run: 28, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.291 sec
Running org.apache.commons.io.DirectoryWalkerTestCaseJava4
Tests run: 14, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.27 sec

Results :

Failed tests:   
testIO_356(org.apache.commons.io.input.CharSequenceInputStreamTest): 
bufferSize=10 dataSize=13: arrays first differed at element [0]; expected:<65> 
but was:<78>

Tests run: 985, Failures: 1, Errors: 0, Skipped: 1

[INFO] 
[ERROR] BUILD FAILURE
[INFO] 
[INFO] There are test failures.

Please refer to 
/srv/gump/public/workspace/apache-commons/io/target/surefire-reports for the 
individual test results.
[INFO] 
[INFO] For more information, run Maven with the -e switch
[INFO] 
[INFO] Total time: 1 minute 54 seconds
[INFO] Finished at: Tue Nov 27 08:34:53 UTC 2012
[INFO] Final Memory: 37M/89M
[INFO] 
-

To subscribe to this information via syndicated feeds:
- RSS: 
http://vmgump.apache.org/gump/public/apache-commons/commons-io-test/rss.xml
- Atom: 
http://vmgump

[GUMP@vmgump]: Project commons-digester3 (in module apache-commons) failed

[Gump]

To whom it may engage...

This is an automated request, but not an unsolicited one. For 
more information please visit http://gump.apache.org/nagged.html, 
and/or contact the folk at gene...@gump.apache.org.

Project commons-digester3 has an issue affecting its community integration.
This issue affects 2 projects,
 and has been outstanding for 40 runs.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
- commons-digester3 :  XML to Java Object Configuration
- commons-digester3-test :  Apache Commons


Full details are available at:

http://vmgump.apache.org/gump/public/apache-commons/commons-digester3/index.html

That said, some information snippets are provided here.

The following annotations (debug/informational/warning/error messages) were 
provided:
 -DEBUG- Sole jar output [commons-digester3-*[0-9T].jar] identifier set to 
project name
 -DEBUG- (Apache Gump generated) Apache Maven Settings in: 
/srv/gump/public/workspace/apache-commons/digester/gump_mvn_settings.xml
 -INFO- Failed with reason build failed
 -DEBUG- Maven POM in: 
/srv/gump/public/workspace/apache-commons/digester/pom.xml
 -INFO- Failed to extract fallback artifacts from Gump Repository



The following work was performed:
http://vmgump.apache.org/gump/public/apache-commons/commons-digester3/gump_work/build_apache-commons_commons-digester3.html
Work Name: build_apache-commons_commons-digester3 (Type: Build)
Work ended in a state of : Failed
Elapsed: 1 min 11 secs
Command Line: /opt/maven2/bin/mvn --batch-mode -DskipTests=true --settings 
/srv/gump/public/workspace/apache-commons/digester/gump_mvn_settings.xml 
package 
[Working Directory: /srv/gump/public/workspace/apache-commons/digester]
M2_HOME: /opt/maven2
-
[INFO] [remote-resources:process {execution: default}]
[INFO] [buildnumber:create {execution: default}]
[INFO] Checking for local modifications: skipped.
[INFO] Updating project files from SCM: skipped.
[INFO] Executing: /bin/sh -c cd 
/srv/gump/public/workspace/apache-commons/digester/annotations-processor && svn 
--non-interactive info
[INFO] Working directory: 
/srv/gump/public/workspace/apache-commons/digester/annotations-processor
[INFO] Storing buildNumber: ?? at timestamp: 1354010823459
[INFO] Executing: /bin/sh -c cd 
/srv/gump/public/workspace/apache-commons/digester/annotations-processor && svn 
--non-interactive info
[INFO] Working directory: 
/srv/gump/public/workspace/apache-commons/digester/annotations-processor
[INFO] Storing buildScmBranch: UNKNOWN_BRANCH
[debug] execute contextualize
[INFO] [resources:resources {execution: default-resources}]
[INFO] Using 'iso-8859-1' encoding to copy filtered resources.
[INFO] Copying 2 resources to META-INF
[INFO] [compiler:compile {execution: default-compile}]
[INFO] Compiling 5 source files to 
/srv/gump/public/workspace/apache-commons/digester/annotations-processor/target/classes
[INFO] [bundle:manifest {execution: bundle-manifest}]
[debug] execute contextualize
[INFO] [resources:testResources {execution: default-testResources}]
[INFO] Using 'iso-8859-1' encoding to copy filtered resources.
[INFO] skip non existing resourceDirectory 
/srv/gump/public/workspace/apache-commons/digester/annotations-processor/src/test/resources
[INFO] Copying 0 resource to META-INF
[INFO] [compiler:testCompile {execution: default-testCompile}]
[INFO] Compiling 3 source files to 
/srv/gump/public/workspace/apache-commons/digester/annotations-processor/target/test-classes
>@org.apache.commons.digester3.annotations.rules.ObjectCreate(pattern="rss/channel")
>@org.apache.commons.digester3.annotations.rules.ObjectCreate(pattern="rss/channel/image")
>@org.apache.commons.digester3.annotations.rules.ObjectCreate(pattern="rss/channel/item")
>
[INFO] -
[ERROR] COMPILATION ERROR : 
[INFO] -
[ERROR] error: Impossible to generate class 
org.apache.commons.digester3.annotations.processor.GeneratedRulesModule: 
Attempt to recreate a file for type 
org.apache.commons.digester3.annotations.processor.GeneratedRulesModule
[ERROR] error: Impossible to generate class 
org.apache.commons.digester3.annotations.processor.GeneratedRulesModule: 
Attempt to recreate a file for type 
org.apache.commons.digester3.annotations.processor.GeneratedRulesModule
[INFO] 2 errors 
[INFO] -
[INFO] 
[ERROR] BUILD FAILURE
[INFO] 
[INFO] Compilation failure

error: Impossible to generate class 
org.apache.commons.digester3.annotations.processor.GeneratedRulesModule: 
Attempt to recreate a file for type 
org.apache.commons.digester3.

Re: Moving to svnpubsub for dist releases

[sebb]

On 26 November 2012 17:41, Ralph Goers  wrote:
> Traceability by who?
>
> PMC members can easily verify that what is committed to dist matches what 
> they verified using what they downloaded and the MD5s that came with them.  
> They are the ones responsible for the vote and the artifacts so I don't see a 
> problem with that.  Why you would need some sort of formal linking once the 
> artifacts are published escapes me.

The point is that using the SVN URL+revsion in the vote thread
automatically identifies a unique set of artifacts, and is a single
item to check.

Yes, it is possible to trace files using a hash (apart from the
occasional collisions), but the voters would have to check every
single hash against the e-mail and the artifact in order to tie the
artifacts to the vote. And the same would have to be done for the
files once published.

This is tedious, and unlikely to be done by all voters (and how many
RMs provide the hashes?).
Whereas even if the voters don't check the SVN revision, provided that
the URL was not recreated within the time-frame of the vote, it would
be possible to prove which set of artifacts was voted on.

If an RM publishes a release with a valid PMC vote, then the ASF
provides legal protection if necessary.
AIUI this can only apply if the rules have been followed.

Having traceability allows the RM and ASF to prove that the released
artifacts were the ones voted on, should it prove necessary.

At present it would be very easy to accidentally release a file from
the wrong upload directory, e.g. if there were several RCs.

> Ralph
>
>
> On Nov 26, 2012, at 9:23 AM, sebb wrote:
>
>> On 26 November 2012 17:01, Ralph Goers  wrote:
>>> Actually, if you use the Release plugin the artifacts will be uploaded to 
>>> the staging repository. At least that is what VFS does.  They can be voted 
>>> on there and then checked into SVN.  You can easily verify they didn't 
>>> change because the MD5s go along with them.
>>
>> But do the MD5s get automatically added to the release vote?
>> And how can one prove later that the MD5s in the VOTE thread are the
>> same as the ones in the staging repo?
>>
>> AFAICT that is no different from uploading to anywhere else, unless I
>> misunderstand what the release staging repository is.
>>
>> The point is that uploading to SVN and voting on the URL+revision
>> automatically provides traceability.
>> Whereas AFAICT the other methods don't, at least not without
>> additional work by the RM and all reviewers.
>>
>>> Ralph
>>>
>>> On Nov 26, 2012, at 8:41 AM, sebb wrote:
>>>
 On 26 November 2012 11:24, sebb  wrote:
> On 26 November 2012 09:53, Emmanuel Bourg  wrote:
>> Le 26/11/2012 01:01, sebb a écrit :
>>
>>> Hope this all makes sense!
>>
>> Well, maybe I misunderstood, but committing the RC sites for review into
>> a SVN repository seems a bit convoluted to me. A good old upload on
>> people.apache.org was perfectly fine.
>
> AIUI that's what infra want.

 If the dist/dev URL (plus revision) is used in the vote thread, it's
 possible to easily trace the files from the ASF mirror back to the
 actual files used in the vote.

 This is not nearly so easy if the files are just uploaded to a user
 directory on minotaur - there's no proof that the the files that were
 voted on are the ones that were eventually released.

 At some point the files must be uploaded to SVN; once in SVN they can
 be moved around very cheaply.

>> Emmanuel Bourg
>>
>>

 -
 To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
 For additional commands, e-mail: dev-h...@commons.apache.org

>>>
>>>
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>>> For additional commands, e-mail: dev-h...@commons.apache.org
>>>
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> For additional commands, e-mail: dev-h...@commons.apache.org
>>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [math] Checking preconditions on package private functions

[Gilles Sadowski]

Hello.

> > > in classes Gamma and Beta, some functions are package private:
> > >   - logGammaSum
> > >   - logGammaMinusLogGammaSum (for lack of a better name)
> > >   - bcorr
> > > These functions are meant to be used by other functions,
> >
> > None of these functions seem to used. Am I missing something?
> >
> > None of these functions are used YET, they are going to be used in the new
> implementation of logBeta. I wouldn't have committed tortuous, useless,
> package private functions just for the sake of cluttering the code!

Of course, but it _could_ have been that you forgot to make the
necessary replacements since the functions are indeed not used at the
moment. I wouldn't have wondered if you had committed the code that do use
them at the same time.
Also, if (when) you do that, I can also answer your question above.
For example, if the functions are only used in class "Beta", they should
probably be defined there (and be "private"). Then the answer would be: no
check (since you know exactly what usage is made).


Best regards,
Gilles

> > [...]

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

[GUMP@vmgump]: Project commons-chain2 (in module apache-commons) failed

[Gump]

To whom it may engage...

This is an automated request, but not an unsolicited one. For 
more information please visit http://gump.apache.org/nagged.html, 
and/or contact the folk at gene...@gump.apache.org.

Project commons-chain2 has an issue affecting its community integration.
This issue affects 1 projects,
 and has been outstanding for 231 runs.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
- commons-chain2 :  GoF "Chain of Responsibility" pattern


Full details are available at:

http://vmgump.apache.org/gump/public/apache-commons/commons-chain2/index.html

That said, some information snippets are provided here.

The following annotations (debug/informational/warning/error messages) were 
provided:
 -DEBUG- Sole jar output [commons-chain2-*[0-9T].jar] identifier set to project 
name
 -DEBUG- Sole pom output [pom.xml] identifier set to project name
 -DEBUG- (Apache Gump generated) Apache Maven Settings in: 
/srv/gump/public/workspace/apache-commons/chain/gump_mvn_settings.xml
 -INFO- Failed with reason build failed
 -DEBUG- Maven POM in: /srv/gump/public/workspace/apache-commons/chain/pom.xml
 -INFO- Failed to extract fallback artifacts from Gump Repository



The following work was performed:
http://vmgump.apache.org/gump/public/apache-commons/commons-chain2/gump_work/build_apache-commons_commons-chain2.html
Work Name: build_apache-commons_commons-chain2 (Type: Build)
Work ended in a state of : Failed
Elapsed: 1 min 3 secs
Command Line: /opt/maven2/bin/mvn --batch-mode --settings 
/srv/gump/public/workspace/apache-commons/chain/gump_mvn_settings.xml package 
[Working Directory: /srv/gump/public/workspace/apache-commons/chain]
M2_HOME: /opt/maven2
-
[INFO] Building war: 
/srv/gump/public/workspace/apache-commons/chain/apps/cookbook-examples/target/chain-cookbook-examples-2.0-SNAPSHOT.war
[INFO] 
[INFO] Building Apache Commons Chain :: Distribution Packages
[INFO]task-segment: [package]
[INFO] 
[INFO] snapshot org.apache.commons:commons-chain2-configuration:2.0-SNAPSHOT: 
checking for updates from apache.snapshots
Downloading: 
http://localhost:8192/repo/m2-snapshot-repository/org/apache/commons/commons-chain2-configuration/2.0-SNAPSHOT/commons-chain2-configuration-2.0-SNAPSHOT.pom
[INFO] Unable to find resource 
'org.apache.commons:commons-chain2-configuration:pom:2.0-SNAPSHOT' in 
repository apache.snapshots (http://repository.apache.org/snapshots)
Downloading: 
http://localhost:8192/repo/m2-snapshot-repository/org/apache/commons/commons-chain2-configuration/2.0-SNAPSHOT/commons-chain2-configuration-2.0-SNAPSHOT.jar
[INFO] Unable to find resource 
'org.apache.commons:commons-chain2-configuration:jar:2.0-SNAPSHOT' in 
repository apache.snapshots (http://repository.apache.org/snapshots)
[INFO] 
[ERROR] BUILD ERROR
[INFO] 
[INFO] Failed to resolve artifact.

Missing:
--
1) org.apache.commons:commons-chain2-configuration:jar:2.0-SNAPSHOT

  Try downloading the file manually from the project website.

  Then, install it using the command: 
  mvn install:install-file -DgroupId=org.apache.commons 
-DartifactId=commons-chain2-configuration -Dversion=2.0-SNAPSHOT 
-Dpackaging=jar -Dfile=/path/to/file

  Alternatively, if you host your own repository you can deploy the file there: 
  mvn deploy:deploy-file -DgroupId=org.apache.commons 
-DartifactId=commons-chain2-configuration -Dversion=2.0-SNAPSHOT 
-Dpackaging=jar -Dfile=/path/to/file -Durl=[url] -DrepositoryId=[id]

  Path to dependency: 
1) org.apache.commons:commons-chain2:pom:2.0-SNAPSHOT
2) org.apache.commons:commons-chain2-configuration:jar:2.0-SNAPSHOT

--
1 required artifact is missing.

for artifact: 
  org.apache.commons:commons-chain2:pom:2.0-SNAPSHOT

from the specified remote repositories:
  gump-central (http://localhost:8192/maven2),
  gump-apache.snapshots (http://localhost:8192/repo/m2-snapshot-repository)



[INFO] 
[INFO] For more information, run Maven with the -e switch
[INFO] 
[INFO] Total time: 1 minute 1 second
[INFO] Finished at: Tue Nov 27 11:30:50 UTC 2012
[INFO] Final Memory: 114M/241M
[INFO] 
-

To subscribe to this information via syndicated feeds:
- RSS: 
http://vmgump.apache.org/gump/public/apache-commons/commons-chain2/rss.xml
- Atom: 
http://vmgump.apache.org/gump/public/apache-commons/commons

Re: [math] Second thoughts on MATH-803 and "zip-visitor" for vectors.

[Gilles Sadowski]

On Tue, Nov 27, 2012 at 04:44:27AM +0100, Sébastien Brisard wrote:
> Hi,
> 
> 
> 2012/11/27 Gilles Sadowski 
> 
> > Hello.
> >
> > > > > in MATH-803 [1] it was decided to deprecate
> > > > RealVector.ebeMultiply/Divide,
> > > > > because these methods were difficult to support with sparse vectors.
> > > > > However, in MATH-870, we decided to deprecate sparse vectors
> > altogether.
> > > > >
> > > > > I'm therefore having second thoughts on MATH-803. Since the
> > problematic
> > > > > implementations of RealVector are removed, why not keep these quite
> > handy
> > > > > methods?
> >
> > The goal was also to "clean up" the matrix and vector implementations.
> >
> > True, but all good scientific packages (matlab, scilab, numpy) have these
> operations. If we do not keep them in the interface of RealVector (which
> I'm OK about), we need to provide a clean alternative. At the moment,
> visitors are not clean.

Is "ebeDivide" a (mathematical) "vector" operation?
IMHO, it's an operation on 2 lists of values.

> 
> 
> > I'd rather suggest to add such features in the "MathArrays" class:
> > -
> > public static double[] ebeDivide(double[] numer,
> >  double[] denom) {
> >   if (numer.length != denom.length) {
> > throw new DimensionMismatchException(numer.length, denom.length);
> >   }
> >
> >   final double[] result = numer.clone();
> >   for (int i = 0; i < numer.length; i++) {
> > result[i] /= denom[i];
> >   }
> >
> >   return result;
> > }
> > -
> >
> 
> I'm not adverse to the idea, but actually, cleaning recently took place the
> other way round. In RealVector, we removed all methods which took an array
> in place of a vector, since constructing an ArrayRealVector from an array
> is almost costless (using the right constructor).

So?
This method is to be placed in "MathArrays", not "RealVector". Then, it
would be used (e.g. in "JacobiPreconditioner") as:
-
public RealVector operate(final RealVector x) {
  // Dimension check is carried out by ebeDivide
  // return x.ebeDivide(diag); // XXX deprecated.
  return new ArrayRealVector(MathArrays.ebeDivide(x.toArray(),
  diag.toArray()),
 false);
}
-


Regards,
Gilles

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

[GUMP@vmgump]: Project commons-proxy-test (in module apache-commons) failed

[Gump]

To whom it may engage...

This is an automated request, but not an unsolicited one. For 
more information please visit http://gump.apache.org/nagged.html, 
and/or contact the folk at gene...@gump.apache.org.

Project commons-proxy-test has an issue affecting its community integration.
This issue affects 1 projects,
 and has been outstanding for 45 runs.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
- commons-proxy-test :  Apache Commons


Full details are available at:

http://vmgump.apache.org/gump/public/apache-commons/commons-proxy-test/index.html

That said, some information snippets are provided here.

The following annotations (debug/informational/warning/error messages) were 
provided:
 -WARNING- Overriding Maven settings: 
[/srv/gump/public/workspace/apache-commons/proxy/gump_mvn_settings.xml]
 -DEBUG- (Apache Gump generated) Apache Maven Settings in: 
/srv/gump/public/workspace/apache-commons/proxy/gump_mvn_settings.xml
 -INFO- Failed with reason build failed
 -DEBUG- Maven POM in: /srv/gump/public/workspace/apache-commons/proxy/pom.xml
 -INFO- Project Reports in: 
/srv/gump/public/workspace/apache-commons/proxy/target/surefire-reports



The following work was performed:
http://vmgump.apache.org/gump/public/apache-commons/commons-proxy-test/gump_work/build_apache-commons_commons-proxy-test.html
Work Name: build_apache-commons_commons-proxy-test (Type: Build)
Work ended in a state of : Failed
Elapsed: 17 secs
Command Line: /opt/maven2/bin/mvn --batch-mode --settings 
/srv/gump/public/workspace/apache-commons/proxy/gump_mvn_settings.xml test 
[Working Directory: /srv/gump/public/workspace/apache-commons/proxy]
M2_HOME: /opt/maven2
-
Running org.apache.commons.proxy.factory.util.TestMethodSignature
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.003 sec

Results :

Tests in error: 
  
testSerialization(org.apache.commons.proxy.interceptor.TestMethodInterceptorAdapter)
  
testMethodInvocationImplementation(org.apache.commons.proxy.interceptor.TestMethodInterceptorAdapter)
  
testMethodInterception(org.apache.commons.proxy.interceptor.TestMethodInterceptorAdapter)
  testInvalidHandlerName(org.apache.commons.proxy.invoker.TestXmlRpcInvoker)
  
testMethodInvocation(org.apache.commons.proxy.invoker.TestInvocationHandlerAdapter)
  
testInterceptorWithSuperclass(org.apache.commons.proxy.factory.javassist.TestJavassistProxyFactory)
  
testInvokerWithSuperclass(org.apache.commons.proxy.factory.javassist.TestJavassistProxyFactory)
  
testProxiesWithClashingFinalMethodInSuperclass(org.apache.commons.proxy.factory.javassist.TestJavassistProxyFactory)
  
testInterceptorEquals(org.apache.commons.proxy.factory.javassist.TestJavassistProxyFactory)
  
testInvokerEquals(org.apache.commons.proxy.factory.javassist.TestJavassistProxyFactory)
  
testInterceptingProxySerializable(org.apache.commons.proxy.factory.javassist.TestJavassistProxyFactory)
  
testInterceptorProxyWithCheckedException(org.apache.commons.proxy.factory.javassist.TestJavassistProxyFactory)
  
testInterceptorProxyWithUncheckedException(org.apache.commons.proxy.factory.javassist.TestJavassistProxyFactory)
  
testInvokerProxy(org.apache.commons.proxy.factory.javassist.TestJavassistProxyFactory)
  
testInvokerProxyClassCaching(org.apache.commons.proxy.factory.javassist.TestJavassistProxyFactory)
  
testInvokerProxySerializable(org.apache.commons.proxy.factory.javassist.TestJavassistProxyFactory)
  
testMethodInvocationClassCaching(org.apache.commons.proxy.factory.javassist.TestJavassistProxyFactory)
  
testMethodInvocationDuplicateMethods(org.apache.commons.proxy.factory.javassist.TestJavassistProxyFactory)
  
testMethodInvocationImplementation(org.apache.commons.proxy.factory.javassist.TestJavassistProxyFactory)
  
testWithNonAccessibleTargetType(org.apache.commons.proxy.factory.javassist.TestJavassistProxyFactory)
  
testInterceptorHashCode(org.apache.commons.proxy.factory.javassist.TestJavassistProxyFactory)
  
testInvokerHashCode(org.apache.commons.proxy.factory.javassist.TestJavassistProxyFactory)
  
testBooleanInterceptorParameter(org.apache.commons.proxy.factory.javassist.TestJavassistProxyFactory)
  
testChangingArguments(org.apache.commons.proxy.factory.javassist.TestJavassistProxyFactory)
  
testCreateInterceptorProxy(org.apache.commons.proxy.factory.javassist.TestJavassistProxyFactory)
  
testInterceptingProxyClassCaching(org.apache.commons.proxy.factory.javassist.TestJavassistProxyFactory)
  testCreateNullObject(org.apache.commons.proxy.TestProxyUtils)
  testCreateNullObjectWithClassLoader(org.apache.commons.proxy.TestProxyUtils)

Tests run: 179, Failures: 0, Errors: 28, Skipped: 0

[INFO] 
[ERROR] BUILD FAILURE
[INFO] 
[INFO] There 

[GUMP@vmgump]: Project commons-dbutils (in module apache-commons) failed

[Gump]

To whom it may engage...

This is an automated request, but not an unsolicited one. For 
more information please visit http://gump.apache.org/nagged.html, 
and/or contact the folk at gene...@gump.apache.org.

Project commons-dbutils has an issue affecting its community integration.
This issue affects 1 projects,
 and has been outstanding for 209 runs.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
- commons-dbutils :  Commons DbUtils


Full details are available at:

http://vmgump.apache.org/gump/public/apache-commons/commons-dbutils/index.html

That said, some information snippets are provided here.

The following annotations (debug/informational/warning/error messages) were 
provided:
 -DEBUG- Sole jar output [commons-dbutils-*[0-9T].jar] identifier set to 
project name
 -INFO- Optional dependency mockito failed with reason build failed
 -DEBUG- (Apache Gump generated) Apache Maven Settings in: 
/srv/gump/public/workspace/apache-commons/dbutils/gump_mvn_settings.xml
 -INFO- Failed with reason build failed
 -DEBUG- Maven POM in: /srv/gump/public/workspace/apache-commons/dbutils/pom.xml
 -INFO- Project Reports in: 
/srv/gump/public/workspace/apache-commons/dbutils/target/surefire-reports
 -WARNING- No directory 
[/srv/gump/public/workspace/apache-commons/dbutils/target/surefire-reports]
 -INFO- Failed to extract fallback artifacts from Gump Repository



The following work was performed:
http://vmgump.apache.org/gump/public/apache-commons/commons-dbutils/gump_work/build_apache-commons_commons-dbutils.html
Work Name: build_apache-commons_commons-dbutils (Type: Build)
Work ended in a state of : Failed
Elapsed: 19 secs
Command Line: /opt/maven2/bin/mvn --batch-mode --settings 
/srv/gump/public/workspace/apache-commons/dbutils/gump_mvn_settings.xml package 
[Working Directory: /srv/gump/public/workspace/apache-commons/dbutils]
M2_HOME: /opt/maven2
-
1K downloaded  (mockito-core-1.9.0.pom)
Downloading: 
http://localhost:8192/maven2/org/hamcrest/hamcrest-all/1.1/hamcrest-all-1.1.pom
479b downloaded  (hamcrest-all-1.1.pom)
Downloading: 
http://localhost:8192/maven2/org/mockito/mockito-core/1.9.0/mockito-core-1.9.0.jar
Downloading: 
http://localhost:8192/maven2/org/hamcrest/hamcrest-all/1.1/hamcrest-all-1.1.jar
273K downloaded  (hamcrest-all-1.1.jar)
1381K downloaded  (mockito-core-1.9.0.jar)
[INFO] [antrun:run {execution: javadoc.resources}]
[INFO] Executing tasks

main:
 [copy] Copying 2 files to 
/srv/gump/public/workspace/apache-commons/dbutils/target/apidocs/META-INF
[INFO] Executed tasks
[WARNING] The parameter expression: 'project.build.resources' used in mojo: 
'process' has been deprecated. Use 'project.resources' instead.
[INFO] [remote-resources:process {execution: default}]
[INFO] [buildnumber:create {execution: default}]
[INFO] Checking for local modifications: skipped.
[INFO] Updating project files from SCM: skipped.
[INFO] Executing: /bin/sh -c cd 
/srv/gump/public/workspace/apache-commons/dbutils && svn --non-interactive info
[INFO] Working directory: /srv/gump/public/workspace/apache-commons/dbutils
[INFO] Storing buildNumber: ?? at timestamp: 1354018365619
[INFO] Executing: /bin/sh -c cd 
/srv/gump/public/workspace/apache-commons/dbutils && svn --non-interactive info
[INFO] Working directory: /srv/gump/public/workspace/apache-commons/dbutils
[INFO] Storing buildScmBranch: UNKNOWN_BRANCH
[debug] execute contextualize
[INFO] [resources:resources {execution: default-resources}]
[INFO] Using 'iso-8859-1' encoding to copy filtered resources.
[INFO] skip non existing resourceDirectory 
/srv/gump/public/workspace/apache-commons/dbutils/src/main/resources
[INFO] Copying 2 resources to META-INF
[INFO] [compiler:compile {execution: default-compile}]
[INFO] Compiling 29 source files to 
/srv/gump/public/workspace/apache-commons/dbutils/target/classes
[INFO] -
[ERROR] COMPILATION ERROR : 
[INFO] -
[ERROR] 
/srv/gump/public/workspace/apache-commons/dbutils/src/main/java/org/apache/commons/dbutils/DbUtils.java:[334,25]
 error: DriverProxy is not abstract and does not override abstract method 
getParentLogger() in Driver
[INFO] 1 error
[INFO] -
[INFO] 
[ERROR] BUILD FAILURE
[INFO] 
[INFO] Compilation failure
/srv/gump/public/workspace/apache-commons/dbutils/src/main/java/org/apache/commons/dbutils/DbUtils.java:[334,25]
 error: DriverProxy is not abstract and does not override abstract method 
getParentLogger() in Driver

[INFO] 
[INFO] For more information, run Mav

Re: [VOTE] Release Apache Commons Daemon 1.0.11

[Mladen Turk]

On 11/22/2012 02:22 PM, Mladen Turk wrote:


Apache Commons Daemon 1.0.11 is
   [X] +1 Release
   [ ] +0 OK, but...
   [ ] -0 OK, but really should fix...
   [ ] -1 I oppose this release because...




Just my vote FTR.

--
^TM

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

[RESULT] Was: [VOTE] Release Apache Commons Daemon 1.0.11

[Mladen Turk]

With 4 binding votes (Gary, Luc, Mladen and Sebastian)
this vote has been passed!

I'll copy the artefacts to dist site and create ANN
message after the mirrors pick up.


Regards
--
^TM

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: Moving to svnpubsub for dist releases

[Gilles Sadowski]

On Tue, Nov 27, 2012 at 10:55:14AM +, sebb wrote:
> On 26 November 2012 17:41, Ralph Goers  wrote:
> > Traceability by who?
> >
> > PMC members can easily verify that what is committed to dist matches what 
> > they verified using what they downloaded and the MD5s that came with them.  
> > They are the ones responsible for the vote and the artifacts so I don't see 
> > a problem with that.  Why you would need some sort of formal linking once 
> > the artifacts are published escapes me.
> 
> The point is that using the SVN URL+revsion in the vote thread
> automatically identifies a unique set of artifacts, and is a single
> item to check.

That seems a welcome simplification.


Regards,
Gilles

> [...]

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

[DAEMON] Where to publish maven artefacts

[Mladen Turk]

Think that @subject speaks for itself :)
Seems the /www/dist.apache.org/maven-repository is abandoned.
Where should I put the maven artefacts?

... or even better anyone with the karma is
very much welcome to copy them from
http://people.apache.org/~mturk/daemon-1.0.11/maven/
to corresponding location.


Regards
--
^TM

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [DAEMON] Where to publish maven artefacts

[Gary Gregory]

I usually follow http://wiki.apache.org/commons/UsingNexus

Gary

On Nov 27, 2012, at 8:38, Mladen Turk  wrote:

> Think that @subject speaks for itself :)
> Seems the /www/dist.apache.org/maven-repository is abandoned.
> Where should I put the maven artefacts?
>
> ... or even better anyone with the karma is
> very much welcome to copy them from
> http://people.apache.org/~mturk/daemon-1.0.11/maven/
> to corresponding location.
>
>
> Regards
> --
> ^TM
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

[GUMP@vmgump]: Project commons-scxml-test (in module apache-commons) failed

[Gump]

To whom it may engage...

This is an automated request, but not an unsolicited one. For 
more information please visit http://gump.apache.org/nagged.html, 
and/or contact the folk at gene...@gump.apache.org.

Project commons-scxml-test has an issue affecting its community integration.
This issue affects 1 projects,
 and has been outstanding for 214 runs.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
- commons-scxml-test :  Apache Commons


Full details are available at:

http://vmgump.apache.org/gump/public/apache-commons/commons-scxml-test/index.html

That said, some information snippets are provided here.

The following annotations (debug/informational/warning/error messages) were 
provided:
 -WARNING- Overriding Maven settings: 
[/srv/gump/public/workspace/apache-commons/scxml/gump_mvn_settings.xml]
 -DEBUG- (Apache Gump generated) Apache Maven Settings in: 
/srv/gump/public/workspace/apache-commons/scxml/gump_mvn_settings.xml
 -INFO- Failed with reason build failed
 -DEBUG- Maven POM in: /srv/gump/public/workspace/apache-commons/scxml/pom.xml
 -INFO- Project Reports in: 
/srv/gump/public/workspace/apache-commons/scxml/target/surefire-reports



The following work was performed:
http://vmgump.apache.org/gump/public/apache-commons/commons-scxml-test/gump_work/build_apache-commons_commons-scxml-test.html
Work Name: build_apache-commons_commons-scxml-test (Type: Build)
Work ended in a state of : Failed
Elapsed: 31 secs
Command Line: /opt/maven2/bin/mvn --batch-mode -Dsimplelog.defaultlog=info 
--settings 
/srv/gump/public/workspace/apache-commons/scxml/gump_mvn_settings.xml test 
[Working Directory: /srv/gump/public/workspace/apache-commons/scxml]
M2_HOME: /opt/maven2
-
[INFO] SimpleSCXMLListener - /s2/s2.1/e1.2
[INFO] SimpleSCXMLListener - /s2/s2.1/e1.2
[INFO] SimpleSCXMLListener - /s2/s2.1
[INFO] SimpleSCXMLListener - /s2
[INFO] SimpleSCXMLListener - transition (event = s2.1.done, cond = null, from = 
/s2, to = /s3)
[INFO] SimpleSCXMLListener - /s3
Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.416 sec
Running org.apache.commons.scxml.issues.Issue64Test
[INFO] SCXMLSemantics - null: Begin transition bug test ...
[INFO] SimpleSCXMLListener - /tranbug
[INFO] SimpleSCXMLListener - /tranbug
[INFO] SCXMLSemantics - null: somedata
[INFO] SCXMLSemantics - null: *somedata
[INFO] SimpleSCXMLListener - transition (event = show.bug, cond = null, from = 
/tranbug, to = /end)
[INFO] SimpleSCXMLListener - /end
[WARN] SCXMLParser - Ignoring element  in namespace 
"http://www.w3.org/2005/07/scxml"; at 
file:/srv/gump/public/workspace/apache-commons/scxml/target/test-classes/org/apache/commons/scxml/issues/issue64-02.xml:30:21
 and digester match "scxml/datamodel/misplaced"
[WARN] SCXMLParser - Ignoring element  in namespace 
"http://www.w3.org/2005/07/scxml"; at 
file:/srv/gump/public/workspace/apache-commons/scxml/target/test-classes/org/apache/commons/scxml/issues/issue64-02.xml:36:19
 and digester match "scxml/state/onentry/foo"
[WARN] SCXMLParser - Ignoring element  in namespace 
"http://my.foo.example/"; at 
file:/srv/gump/public/workspace/apache-commons/scxml/target/test-classes/org/apache/commons/scxml/issues/issue64-02.xml:37:22
 and digester match "scxml/state/onentry/bar"
[WARN] SCXMLParser - Ignoring element  in namespace 
"http://www.w3.org/2005/07/scxml"; at 
file:/srv/gump/public/workspace/apache-commons/scxml/target/test-classes/org/apache/commons/scxml/issues/issue64-02.xml:41:21
 and digester match "scxml/state/transition/datamodel"
[WARN] SCXMLParser - Ignoring element  in namespace 
"http://www.w3.org/2005/07/scxml"; at 
file:/srv/gump/public/workspace/apache-commons/scxml/target/test-classes/org/apache/commons/scxml/issues/issue64-02.xml:42:41
 and digester match "scxml/state/transition/datamodel/data"
[WARN] SCXMLParser - Ignoring element  in namespace 
"http://my.foo.example/"; at 
file:/srv/gump/public/workspace/apache-commons/scxml/target/test-classes/org/apache/commons/scxml/issues/issue64-02.xml:49:14
 and digester match "scxml/baz"
[INFO] SCXMLSemantics - null: Begin transition bug test ...
[INFO] SimpleSCXMLListener - /tranbug
[INFO] SimpleSCXMLListener - /tranbug
[INFO] SCXMLSemantics - null: null
[WARN] SimpleErrorReporter - EXPRESSION_ERROR (eval(''*' + dummy'):null): 
[INFO] SimpleSCXMLListener - transition (event = show.bug, cond = null, from = 
/tranbug, to = /end)
[INFO] SimpleSCXMLListener - /end
Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.092 sec

Results :

Failed tests: 
  testCustomActionCallbacks(org.apache.commons.scxml.model.CustomActionTest)

Tests run: 229, Failures: 1, Errors: 0, Skipped: 0

[INFO] 
[ERROR] BUILD FAILURE
[INFO] 
[INFO

Re: [DAEMON] Where to publish maven artefacts

[Mladen Turk]

On 11/27/2012 02:55 PM, Gary Gregory wrote:

I usually follow http://wiki.apache.org/commons/UsingNexus



Yeah, but doesn't this creates new set of binaries/artefacts
which at the end are not the same we voted for?
IMHO they at least have different time stamp.


Regards
--
^TM

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [math] Checking preconditions on package private functions

[Ted Dunning]

Actually, I would still recommend checks.  You may know what the code does
now, but you can't trust either yourself or somebody else in the future.
 Better to do the checks.

On Tue, Nov 27, 2012 at 3:27 AM, Gilles Sadowski <
gil...@harfang.homelinux.org> wrote:

> Then the answer would be: no
> check (since you know exactly what usage is made).
>

Re: [DAEMON] Where to publish maven artefacts

[Gary Gregory]

The process creates all you need in nexus. You have to move the -bin
and -src files out before you release to maven central though.

Gary

On Nov 27, 2012, at 9:24, Mladen Turk  wrote:

> On 11/27/2012 02:55 PM, Gary Gregory wrote:
>> I usually follow http://wiki.apache.org/commons/UsingNexus
>>
>
> Yeah, but doesn't this creates new set of binaries/artefacts
> which at the end are not the same we voted for?
> IMHO they at least have different time stamp.
>
>
> Regards
> --
> ^TM
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [math] Second thoughts on MATH-803 and "zip-visitor" for vectors.

[Gilles Sadowski]

On Tue, Nov 27, 2012 at 12:33:40PM +0100, Gilles Sadowski wrote:
> On Tue, Nov 27, 2012 at 04:44:27AM +0100, Sébastien Brisard wrote:
> > Hi,
> > 
> > 
> > 2012/11/27 Gilles Sadowski 
> > 
> > > Hello.
> > >
> > > > > > in MATH-803 [1] it was decided to deprecate
> > > > > RealVector.ebeMultiply/Divide,
> > > > > > because these methods were difficult to support with sparse vectors.
> > > > > > However, in MATH-870, we decided to deprecate sparse vectors
> > > altogether.
> > > > > >
> > > > > > I'm therefore having second thoughts on MATH-803. Since the
> > > problematic
> > > > > > implementations of RealVector are removed, why not keep these quite
> > > handy
> > > > > > methods?
> > >
> > > The goal was also to "clean up" the matrix and vector implementations.
> > >
> > > True, but all good scientific packages (matlab, scilab, numpy) have these
> > operations. If we do not keep them in the interface of RealVector (which
> > I'm OK about), we need to provide a clean alternative. At the moment,
> > visitors are not clean.

I also agree with that. It's not necessarily conflicting with what I propose
to solve MATH-895.

Replacing the current RealMatrix visitor interface is not obvious, partly
because we wish to have the same API for RealVector and RealMatrix (2
different types). [AFAICS, in Python for example, the arguments are just
"lists of (lists of) numbers".]

An alternative (to try and mimic what exists in those other languages) would
be to stick with the current CM design and add methods similar to "map":

  public static RealVector map(UnivariateFunction f,
   RealVector v)
  public static RealVector map(BivariateFunction f,
   RealVector v1,
   RealVector v2)
  public static RealVector map(TrivariateFunction f,
   RealVector v1,
   RealVector v2,
   RealVector v3)
  public static RealVector map(MultivariateFunction f,
   RealVector... vectors)


[I also think that this is actually not the same as the "visitor" pattern
(where the antries can be visisted in any order) whereas in the above cases,
the assumption is that iterating on each vector is done similarly to looping
over the index of the "getEntry(int index)" method.]

It also might make more sense to add these feature in "MathArrays":

  public static double[] map(UnivariateFunction f,
 double[] v)
  public static double[] map(BivariateFunction f,
 double[] v1,
 double[] v2)
  public static double[] map(TrivariateFunction f,
 double[] v1,
 double[] v2,
 double[] v3)
  public static double[] map(MultivariateFunction f,
 double[][] vectors)

[Where the assumption which I referred to above is trivially verified.]


Regards,
Gilles

> 
> Is "ebeDivide" a (mathematical) "vector" operation?
> IMHO, it's an operation on 2 lists of values.
> 
> > 
> > 
> > > I'd rather suggest to add such features in the "MathArrays" class:
> > > -
> > > public static double[] ebeDivide(double[] numer,
> > >  double[] denom) {
> > >   if (numer.length != denom.length) {
> > > throw new DimensionMismatchException(numer.length, denom.length);
> > >   }
> > >
> > >   final double[] result = numer.clone();
> > >   for (int i = 0; i < numer.length; i++) {
> > > result[i] /= denom[i];
> > >   }
> > >
> > >   return result;
> > > }
> > > -
> > >
> > 
> > I'm not adverse to the idea, but actually, cleaning recently took place the
> > other way round. In RealVector, we removed all methods which took an array
> > in place of a vector, since constructing an ArrayRealVector from an array
> > is almost costless (using the right constructor).
> 
> So?
> This method is to be placed in "MathArrays", not "RealVector". Then, it
> would be used (e.g. in "JacobiPreconditioner") as:
> -
> public RealVector operate(final RealVector x) {
>   // Dimension check is carried out by ebeDivide
>   // return x.ebeDivide(diag); // XXX deprecated.
>   return new ArrayRealVector(MathArrays.ebeDivide(x.toArray(),
>   diag.toArray()),
>  false);
> }
> -
> 
> 
> Regards,
> Gilles
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
> 

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [math] Checking preconditions on package private functions

[Gilles Sadowski]

On Tue, Nov 27, 2012 at 06:24:26AM -0800, Ted Dunning wrote:
> Actually, I would still recommend checks.  You may know what the code does
> now, but you can't trust either yourself or somebody else in the future.
>  Better to do the checks.

I don't agree because in this case, the situation is akin to a bug. [And we
don't introduce checks after each statement to ensure that the statement
did what it should.]

Those _private_ methods are there just to group a set of statements which
are valid under the documented conditions. We should start to assume that
the documentation could be wrong... [If it is, that's also a bug.]


Regards,
Gilles

> 
> On Tue, Nov 27, 2012 at 3:27 AM, Gilles Sadowski <
> gil...@harfang.homelinux.org> wrote:
> 
> > Then the answer would be: no
> > check (since you know exactly what usage is made).
> >

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [DAEMON] Where to publish maven artefacts

[Mladen Turk]

On 11/27/2012 03:32 PM, Gary Gregory wrote:

The process creates all you need in nexus. You have to move the -bin
and -src files out before you release to maven central though.



Hmm,
I did mvn -Prelease deploy -DskipTests
So suppose -bin and -src went away.

Can I revert that?

Regards
--
^TM

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [DAEMON] Where to publish maven artefacts

[Gary Gregory]

On Nov 27, 2012, at 9:54, Mladen Turk  wrote:

> On 11/27/2012 03:32 PM, Gary Gregory wrote:
>> The process creates all you need in nexus. You have to move the -bin
>> and -src files out before you release to maven central though.
>>
>
> Hmm,
> I did mvn -Prelease deploy -DskipTests
> So suppose -bin and -src went away.
>
> Can I revert that?

I can't recall but I know that every time I do a release I have to
carefully follow the process step by step. It's painful.

Gary
>
> Regards
> --
> ^TM
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [DAEMON] Where to publish maven artefacts

[sebb]

On 27 November 2012 15:01, Gary Gregory  wrote:
> On Nov 27, 2012, at 9:54, Mladen Turk  wrote:
>
>> On 11/27/2012 03:32 PM, Gary Gregory wrote:
>>> The process creates all you need in nexus. You have to move the -bin
>>> and -src files out before you release to maven central though.
>>>
>>
>> Hmm,
>> I did mvn -Prelease deploy -DskipTests

The deploy phase rebuilds the artifacts, so that should normally be
done before the vote; you then provide the Nexus staging dir in the
release vote.

However, provided the maven staging dir you used is still present,
Nexus can be used to upload those files and then release them.

It's a more convoluted process than using Maven deploy, but I have
done it a couple of times and can do it again here if you like.

>> So suppose -bin and -src went away.
>>
>> Can I revert that?

Yes, provided that you have not published the Nexus staging dir (and
I've not seem the commit messages).

I can delete it if you like.

>>
>> Regards
>> --
>> ^TM
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> For additional commands, e-mail: dev-h...@commons.apache.org
>>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [math] Checking preconditions on package private functions

[Phil Steitz]

On 11/27/12 6:42 AM, Gilles Sadowski wrote:
> On Tue, Nov 27, 2012 at 06:24:26AM -0800, Ted Dunning wrote:
>> Actually, I would still recommend checks.  You may know what the code does
>> now, but you can't trust either yourself or somebody else in the future.
>>  Better to do the checks.
> I don't agree because in this case, the situation is akin to a bug. [And we
> don't introduce checks after each statement to ensure that the statement
> did what it should.]
>
> Those _private_ methods are there just to group a set of statements which
> are valid under the documented conditions. We should start to assume that
> the documentation could be wrong... [If it is, that's also a bug.]

I agree with both of you :)

Easy to forget, new people shooting selves in foot later, etc. -
good point.

Violating clearly stated preconditions == bug - also good point.

If you read carefully what Sebastien is proposing, it addresses
both.  Key is to fully document in the javadoc what the
preconditions are and what exceptions will be thrown / what nonsense
will result if they are violated.  Then unit tests validate
correctness of the javdoc.  Given all of this, dropping the checks
just makes the contract a little trickier to specify.  If this can
be done clearly, I am OK with dropping the checks.  If not, I agree
with Ted it is better to just leave the checks in.  The real risk of
pulling them out is when we later change the code that uses them and
forget or emasculate the client side checks.  Depending on what
kinds of exceptions or meaninglessness happens when the
preconditions are violated, not encapsulating them in the methods
may also make documentation of the code that uses the methods
harder.  So I would say look at each one and ask if a) its own
javadoc and b) javadoc of the methods that now use it can be
specified fully and meaningfully in its activation context without
the checks in the code.  If "yes" go ahead and rip them out.  If
"no" leave them in.

Phil
>
>
> Regards,
> Gilles
>
>> On Tue, Nov 27, 2012 at 3:27 AM, Gilles Sadowski <
>> gil...@harfang.homelinux.org> wrote:
>>
>>> Then the answer would be: no
>>> check (since you know exactly what usage is made).
>>>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>


-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

[Math] Towards the 3.1 release (take 3)

[Gilles Sadowski]

Hello.

Quoting from the previous thread about this subject:
> As far as I am concerned, 3.1 could be released anytime now.
[Luc Maisonobe, September 14, 2012]

Plenty of needed work has been done since then. Most of it could have been
done _after_ releasing 3.1!
Most of the current contributors agree that releases should happen more
often; yet they don't.
I would like that a set of objective criteria be written down that would
define when a new release is deemed adequate. [I had suggested some.]
This discussion should be held in another thread since (as the above quote
summarizes), it was agreed that the 3.1 release was due.

At this point, I propose to start the release process using the "old" (about
to be deprecated) procedure.
Indeed, I surely do not want the release to be further delayed because of
"newbie" mistakes on using the new procedure (CMS for the site, etc.).
Let's "divide and conquer": We release 3.1 now and allow users to benefit
from the many new features and bug fixes. While they test the new release,
we begin to prepare 3.2 with the new procedure, starting with the site.

OK?


Best regards,
Gilles

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [DAEMON] Where to publish maven artefacts

[Mladen Turk]

On 11/27/2012 04:12 PM, sebb wrote:


Can I revert that?


Yes, provided that you have not published the Nexus staging dir (and
I've not seem the commit messages).

I can delete it if you like.



Sure, please do.


Regards
--
^TM

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [DAEMON] Where to publish maven artefacts

[sebb]

On 27 November 2012 15:31, Mladen Turk  wrote:
> On 11/27/2012 04:12 PM, sebb wrote:


 Can I revert that?
>>
>>
>> Yes, provided that you have not published the Nexus staging dir (and
>> I've not seem the commit messages).
>>
>> I can delete it if you like.
>>
>
> Sure, please do.
>

OK, done.

Do you also want me to upload the files from

http://people.apache.org/~mturk/daemon-1.0.11/maven/

ready for promotion?

[These are the ones that were voted on, so should be the ones to be released]

I propose to upload them and close the staging dir for review.

Someone else (e.g. you) can then double-check that the hashes/sigs
agree with the original files, and then the staging dir can be
promoted (released).
This would tie the release to the vote.

>
> Regards
> --
> ^TM
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [math] Checking preconditions on package private functions

[Gilles Sadowski]

On Tue, Nov 27, 2012 at 07:22:26AM -0800, Phil Steitz wrote:
> On 11/27/12 6:42 AM, Gilles Sadowski wrote:
> > On Tue, Nov 27, 2012 at 06:24:26AM -0800, Ted Dunning wrote:
> >> Actually, I would still recommend checks.  You may know what the code does
> >> now, but you can't trust either yourself or somebody else in the future.
> >>  Better to do the checks.
> > I don't agree because in this case, the situation is akin to a bug. [And we
> > don't introduce checks after each statement to ensure that the statement
> > did what it should.]
> >
> > Those _private_ methods are there just to group a set of statements which
> > are valid under the documented conditions. We should start to assume that
> > the documentation could be wrong... [If it is, that's also a bug.]
> 
> I agree with both of you :)
> 
> Easy to forget, new people shooting selves in foot later, etc. -
> good point.
> 
> Violating clearly stated preconditions == bug - also good point.
> 
> If you read carefully what Sebastien is proposing, it addresses
> both.  Key is to fully document in the javadoc what the
> preconditions are and what exceptions will be thrown / what nonsense
> will result if they are violated.  Then unit tests validate
> correctness of the javdoc.  Given all of this, dropping the checks
> just makes the contract a little trickier to specify.  If this can
> be done clearly, I am OK with dropping the checks.  If not, I agree
> with Ted it is better to just leave the checks in.  The real risk of
> pulling them out is when we later change the code that uses them and
> forget or emasculate the client side checks.

> Depending on what
> kinds of exceptions or meaninglessness happens when the
> preconditions are violated, not encapsulating them in the methods
> may also make documentation of the code that uses the methods
> harder.

That should not be the case here: the methods are an "implementation detail"
(replacing a set of statements by another, more precise, under the stated
conditions) that should not be Javadoc-documented; only code comments are
useful to figure why those methods are called there.

> So I would say look at each one and ask if a) its own
> javadoc and b) javadoc of the methods that now use it can be
> specified fully and meaningfully in its activation context without
> the checks in the code.  If "yes" go ahead and rip them out.  If
> "no" leave them in.

All you say is of course correct in the context of "public" or "protected"
or package-visible methods. My point is that _if_ the methods can be made
"private", then we can assume that they are used properly there (which is
the only place where they can be called). It's the same that we wouldn't
check whether, say, we wrote
  a + b
instead of
  a - b
If we did write the wrong statement, it is indeed a bug, and we would just
correct it, without writing additional checks to make sure that we do not
reintroduce the same bug some time later; at most, we would write a code
comment to remind future readers to be cautious about a possibly non-obvious
statement.


Regards,
Gilles

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [math] Checking preconditions on package private functions

[Ted Dunning]

I can only say from my own experience that people make mistakes over time and 
having the code warn them when that happens is a good thing.  

Your experience may be different but I have to admit that I have done some 
pretty silly things along the lines of forgetting to follow some constraint. 

On Nov 27, 2012, at 8:08 AM, Gilles Sadowski  
wrote:

> My point is that _if_ the methods can be made
> "private", then we can assume that they are used properly there (which is
> the only place where they can be called). It's the same that we wouldn't
> check whether, say, we wrote
>  a + b
> instead of
>  a - b

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [math] Checking preconditions on package private functions

[Gilles Sadowski]

On Tue, Nov 27, 2012 at 08:15:13AM -0800, Ted Dunning wrote:
> 
> I can only say from my own experience that people make mistakes over time and 
> having the code warn them when that happens is a good thing.  
> 
> Your experience may be different but I have to admit that I have done some 
> pretty silly things along the lines of forgetting to follow some constraint. 

That's exactly what I'm saying: We know that we can introduce bugs in code
but we cannot accompany every statement with a check!
Then, where you draw the line between "this must be checked" and "this does
not need a check" is indeed a matter of choice.


Gilles

> On Nov 27, 2012, at 8:08 AM, Gilles Sadowski  
> wrote:
> 
> > My point is that _if_ the methods can be made
> > "private", then we can assume that they are used properly there (which is
> > the only place where they can be called). It's the same that we wouldn't
> > check whether, say, we wrote
> >  a + b
> > instead of
> >  a - b
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
> 

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [DAEMON] Where to publish maven artefacts

[Mladen Turk]

On 11/27/2012 05:00 PM, sebb wrote:

On 27 November 2012 15:31, Mladen Turk  wrote:

On 11/27/2012 04:12 PM, sebb wrote:


I can delete it if you like.



Sure, please do.



OK, done.

Do you also want me to upload the files from

http://people.apache.org/~mturk/daemon-1.0.11/maven/

ready for promotion?



Sure. Thanks once again.


Regards
--
^TM

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: Moving to svnpubsub for dist releases

[Ralph Goers]

On Nov 27, 2012, at 5:12 AM, Gilles Sadowski wrote:

> On Tue, Nov 27, 2012 at 10:55:14AM +, sebb wrote:
>> On 26 November 2012 17:41, Ralph Goers  wrote:
>>> Traceability by who?
>>> 
>>> PMC members can easily verify that what is committed to dist matches what 
>>> they verified using what they downloaded and the MD5s that came with them.  
>>> They are the ones responsible for the vote and the artifacts so I don't see 
>>> a problem with that.  Why you would need some sort of formal linking once 
>>> the artifacts are published escapes me.
>> 
>> The point is that using the SVN URL+revsion in the vote thread
>> automatically identifies a unique set of artifacts, and is a single
>> item to check.
> 
> That seems a welcome simplification.
> 

If you use the release plugin it isn't simpler.  Maven is going to deploy all 
the artifacts to the staging repository, including the distribution artifacts.  
Reviewers then do "wget -e robots=off --cut-dirs=3 -r -p -np 
--no-check-certificate link", where link is the url to the staging repository.  
After that the reviewer will have all the artifacts for inspection.  With what 
Sebb is proposing you will have to still do this to verify the Maven artifacts 
but you will also have to checkout the distribution artifacts from SVN, which 
seems like a needless step to me.

Ralph

Re: Moving to svnpubsub for dist releases

[sebb]

On 27 November 2012 17:16, Ralph Goers  wrote:
>
> On Nov 27, 2012, at 5:12 AM, Gilles Sadowski wrote:
>
>> On Tue, Nov 27, 2012 at 10:55:14AM +, sebb wrote:
>>> On 26 November 2012 17:41, Ralph Goers  wrote:
 Traceability by who?

 PMC members can easily verify that what is committed to dist matches what 
 they verified using what they downloaded and the MD5s that came with them. 
  They are the ones responsible for the vote and the artifacts so I don't 
 see a problem with that.  Why you would need some sort of formal linking 
 once the artifacts are published escapes me.
>>>
>>> The point is that using the SVN URL+revsion in the vote thread
>>> automatically identifies a unique set of artifacts, and is a single
>>> item to check.
>>
>> That seems a welcome simplification.
>>
>
> If you use the release plugin it isn't simpler.  Maven is going to deploy all 
> the artifacts to the staging repository, including the distribution artifacts.

Actually that is true regardless of whether the release plugin is used
or not; deploy will generally include the dist artifacts.

> Reviewers then do "wget -e robots=off --cut-dirs=3 -r -p -np 
> --no-check-certificate link", where link is the url to the staging 
> repository.  After that the reviewer will have all the artifacts for 
> inspection.  With what Sebb is proposing you will have to still do this to 
> verify the Maven artifacts but you will also have to checkout the 
> distribution artifacts from SVN, which seems like a needless step to me.

Well, it's just one more command.

> Ralph

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

[DAEMON] Upload of Apache Commons Daemon 1.0.11 Maven artifacts to Nexus

[sebb]

I've uploaded the artifacts from the RC vote area:

http://people.apache.org/~mturk/daemon-1.0.11/maven/

to the Nexus staging area:

https://repository.apache.org/content/repositories/orgapachecommons-086/commons-daemon/commons-daemon/1.0.11/

The directory contents agree as far as I am concerned, but it would be
good if one or two others could confirm that the files are indeed the
same.

Thanks!

-- Forwarded message --
From: Nexus Repository Manager 
Date: 27 November 2012 18:41
Subject: Nexus: Staging Completed.
To: Sebastian Bazley , comm...@commons.apache.org


Description:

Prepare for potential 1.0.11 release

Details:

The following artifacts have been staged to the org.apache.commons-086
(u:sebb, a:80.176.146.62) repository.

archetype-catalog.xml
commons-daemon-1.0.11-src.tar.gz.asc
commons-daemon-1.0.11-bin.tar.gz.asc
commons-daemon-1.0.11-src.zip.asc
commons-daemon-1.0.11.pom.asc
commons-daemon-1.0.11-src.zip
commons-daemon-1.0.11-sources.jar
commons-daemon-1.0.11-native-src.zip
commons-daemon-1.0.11.jar.asc
commons-daemon-1.0.11.pom
commons-daemon-1.0.11-bin.zip
commons-daemon-1.0.11-bin-windows.zip.asc
commons-daemon-1.0.11-sources.jar.asc
commons-daemon-1.0.11-native-src.tar.gz.asc
commons-daemon-1.0.11-native-src.zip.asc
commons-daemon-1.0.11-javadoc.jar
commons-daemon-1.0.11-src.tar.gz
commons-daemon-1.0.11-native-src.tar.gz
commons-daemon-1.0.11-bin-windows.zip
commons-daemon-1.0.11-bin.tar.gz
commons-daemon-1.0.11-javadoc.jar.asc
commons-daemon-1.0.11.jar
commons-daemon-1.0.11-bin.zip.asc

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: Moving to svnpubsub for dist releases

[sebb]

On 27 November 2012 18:29, sebb  wrote:
> On 27 November 2012 17:16, Ralph Goers  wrote:
>>
>> On Nov 27, 2012, at 5:12 AM, Gilles Sadowski wrote:
>>
>>> On Tue, Nov 27, 2012 at 10:55:14AM +, sebb wrote:
 On 26 November 2012 17:41, Ralph Goers  wrote:
> Traceability by who?
>
> PMC members can easily verify that what is committed to dist matches what 
> they verified using what they downloaded and the MD5s that came with 
> them.  They are the ones responsible for the vote and the artifacts so I 
> don't see a problem with that.  Why you would need some sort of formal 
> linking once the artifacts are published escapes me.

 The point is that using the SVN URL+revsion in the vote thread
 automatically identifies a unique set of artifacts, and is a single
 item to check.
>>>
>>> That seems a welcome simplification.
>>>
>>
>> If you use the release plugin it isn't simpler.  Maven is going to deploy 
>> all the artifacts to the staging repository, including the distribution 
>> artifacts.
>
> Actually that is true regardless of whether the release plugin is used
> or not; deploy will generally include the dist artifacts.
>
>> Reviewers then do "wget -e robots=off --cut-dirs=3 -r -p -np 
>> --no-check-certificate link", where link is the url to the staging 
>> repository.  After that the reviewer will have all the artifacts for 
>> inspection.  With what Sebb is proposing you will have to still do this to 
>> verify the Maven artifacts but you will also have to checkout the 
>> distribution artifacts from SVN, which seems like a needless step to me.
>
> Well, it's just one more command.

And it's just occurred to me that at least one Commons component has
distribution archives that are not created using Maven.
Such files won't be uploaded to Nexus.

>> Ralph

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [Math] Towards the 3.1 release (take 3)

[Luc Maisonobe]

Le 27/11/2012 16:30, Gilles Sadowski a écrit :
> Hello.
> 
> Quoting from the previous thread about this subject:
>> As far as I am concerned, 3.1 could be released anytime now.
> [Luc Maisonobe, September 14, 2012]
> 
> Plenty of needed work has been done since then. Most of it could have been
> done _after_ releasing 3.1!
> Most of the current contributors agree that releases should happen more
> often; yet they don't.
> I would like that a set of objective criteria be written down that would
> define when a new release is deemed adequate. [I had suggested some.]
> This discussion should be held in another thread since (as the above quote
> summarizes), it was agreed that the 3.1 release was due.
> 
> At this point, I propose to start the release process using the "old" (about
> to be deprecated) procedure.
> Indeed, I surely do not want the release to be further delayed because of
> "newbie" mistakes on using the new procedure (CMS for the site, etc.).
> Let's "divide and conquer": We release 3.1 now and allow users to benefit
> from the many new features and bug fixes. While they test the new release,
> we begin to prepare 3.2 with the new procedure, starting with the site.
> 
> OK?

+1 to release now.

Luc

> 
> 
> Best regards,
> Gilles
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
> 
> 


-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [VOTE] Release NET 3.2 based on RC1

[Oliver Heger]

Build works fine with Java 1.5 on Windows 7, artifacts and site look good.

Minor nits:
- The cobertura report shows a pretty low coverage rate.
- There is a bunch of findbugs errors; most of them are related to 
encoding issues, so I guess this is nothing critical.


+1

Oliver

Am 26.11.2012 19:29, schrieb sebb:

This is a vote to release Apache Commons NET 3.2 based on RC1.

[ ] +1 release it
[ ] +0 go ahead I don't care
[ ] -1 no, do not release it because...

tag:
https://svn.apache.org/repos/asf/commons/proper/net/tags/NET_3_2_RC1/ (r1413727)

site:
http://people.apache.org/~sebb/net-3.2-RC1/

The Javadocs (1.4.1) link does not work, nor does the download link.
These will be OK once the site is deployed.

Source and binary archives (tar.gz and .zip) and Maven jars:
https://repository.apache.org/content/repositories/orgapachecommons-078/

[The tar.gz and .zip files will be moved to dist/commons/net before
promoting the Maven jars to release status]

Vote will remain open for at least 72 hours.

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org




-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [VOTE] Release NET 3.2 based on RC1

[Gary Gregory]

On Tue, Nov 27, 2012 at 3:51 PM, Oliver Heger
wrote:

> Build works fine with Java 1.5 on Windows 7, artifacts and site look good.
>
> Minor nits:
> - The cobertura report shows a pretty low coverage rate.
>

Patches? ;)


> - There is a bunch of findbugs errors; most of them are related to
> encoding issues, so I guess this is nothing critical.
>

This has been like this for a while, some are by design like: if
(enc==null) { foo.read(in) } else { foo.read(in, enc) }

but even that could be recoded to use
java.nio.charset.Charset.defaultCharset()...

Gary


>
> +1
>
> Oliver
>
> Am 26.11.2012 19:29, schrieb sebb:
>
>  This is a vote to release Apache Commons NET 3.2 based on RC1.
>>
>> [ ] +1 release it
>> [ ] +0 go ahead I don't care
>> [ ] -1 no, do not release it because...
>>
>> tag:
>> https://svn.apache.org/repos/**asf/commons/proper/net/tags/**NET_3_2_RC1/(r1413727)
>>
>> site:
>> http://people.apache.org/~**sebb/net-3.2-RC1/
>>
>> The Javadocs (1.4.1) link does not work, nor does the download link.
>> These will be OK once the site is deployed.
>>
>> Source and binary archives (tar.gz and .zip) and Maven jars:
>> https://repository.apache.org/**content/repositories/**
>> orgapachecommons-078/
>>
>> [The tar.gz and .zip files will be moved to dist/commons/net before
>> promoting the Maven jars to release status]
>>
>> Vote will remain open for at least 72 hours.
>>
>> --**--**-
>> To unsubscribe, e-mail: 
>> dev-unsubscribe@commons.**apache.org
>> For additional commands, e-mail: dev-h...@commons.apache.org
>>
>>
>
> --**--**-
> To unsubscribe, e-mail: 
> dev-unsubscribe@commons.**apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>


-- 
E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
JUnit in Action, 2nd Ed: http://bit.ly/ECvg0
Spring Batch in Action: http://bit.ly/bqpbCK
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory

Re: [Math] Towards the 3.1 release (take 3)

[Thomas Neidhart]

On 11/27/2012 04:30 PM, Gilles Sadowski wrote:
> Hello.
> 
> Quoting from the previous thread about this subject:
>> As far as I am concerned, 3.1 could be released anytime now.
> [Luc Maisonobe, September 14, 2012]
> 
> Plenty of needed work has been done since then. Most of it could have been
> done _after_ releasing 3.1!
> Most of the current contributors agree that releases should happen more
> often; yet they don't.
> I would like that a set of objective criteria be written down that would
> define when a new release is deemed adequate. [I had suggested some.]
> This discussion should be held in another thread since (as the above quote
> summarizes), it was agreed that the 3.1 release was due.
> 
> At this point, I propose to start the release process using the "old" (about
> to be deprecated) procedure.
> Indeed, I surely do not want the release to be further delayed because of
> "newbie" mistakes on using the new procedure (CMS for the site, etc.).
> Let's "divide and conquer": We release 3.1 now and allow users to benefit
> from the many new features and bug fixes. While they test the new release,
> we begin to prepare 3.2 with the new procedure, starting with the site.
> 
> OK?

+1

Thomas

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [math] Checking preconditions on package private functions

[Sébastien Brisard]

Hi,


2012/11/27 Gilles Sadowski 

> On Tue, Nov 27, 2012 at 07:22:26AM -0800, Phil Steitz wrote:
> > On 11/27/12 6:42 AM, Gilles Sadowski wrote:
> > > On Tue, Nov 27, 2012 at 06:24:26AM -0800, Ted Dunning wrote:
> > >> Actually, I would still recommend checks.  You may know what the code
> does
> > >> now, but you can't trust either yourself or somebody else in the
> future.
> > >>  Better to do the checks.
> > > I don't agree because in this case, the situation is akin to a bug.
> [And we
> > > don't introduce checks after each statement to ensure that the
> statement
> > > did what it should.]
> > >
> > > Those _private_ methods are there just to group a set of statements
> which
> > > are valid under the documented conditions. We should start to assume
> that
> > > the documentation could be wrong... [If it is, that's also a bug.]
> >
> > I agree with both of you :)
> >
> > Easy to forget, new people shooting selves in foot later, etc. -
> > good point.
> >
> > Violating clearly stated preconditions == bug - also good point.
> >
> > If you read carefully what Sebastien is proposing, it addresses
> > both.  Key is to fully document in the javadoc what the
> > preconditions are and what exceptions will be thrown / what nonsense
> > will result if they are violated.  Then unit tests validate
> > correctness of the javdoc.  Given all of this, dropping the checks
> > just makes the contract a little trickier to specify.  If this can
> > be done clearly, I am OK with dropping the checks.  If not, I agree
> > with Ted it is better to just leave the checks in.  The real risk of
> > pulling them out is when we later change the code that uses them and
> > forget or emasculate the client side checks.
>
> > Depending on what
> > kinds of exceptions or meaninglessness happens when the
> > preconditions are violated, not encapsulating them in the methods
> > may also make documentation of the code that uses the methods
> > harder.
>
> That should not be the case here: the methods are an "implementation
> detail"
> (replacing a set of statements by another, more precise, under the stated
> conditions) that should not be Javadoc-documented; only code comments are
> useful to figure why those methods are called there.
>
> > So I would say look at each one and ask if a) its own
> > javadoc and b) javadoc of the methods that now use it can be
> > specified fully and meaningfully in its activation context without
> > the checks in the code.  If "yes" go ahead and rip them out.  If
> > "no" leave them in.
>
> All you say is of course correct in the context of "public" or "protected"
> or package-visible methods. My point is that _if_ the methods can be made
> "private", then we can assume that they are used properly there (which is
> the only place where they can be called). It's the same that we wouldn't
> check whether, say, we wrote
>   a + b
> instead of
>   a - b
> If we did write the wrong statement, it is indeed a bug, and we would just
> correct it, without writing additional checks to make sure that we do not
> reintroduce the same bug some time later; at most, we would write a code
> comment to remind future readers to be cautious about a possibly
> non-obvious
> statement.
>
> Actually, I would like the methods to be tested, so they cannot be
private. That's the reason why I made them package private. If we remove
the checks (which I really have mixed feelings about) I ropose to fully
state in the javadoc that the preconditions are *not* checked, and that
it's the responsibility of the client to check them. But in fact, may be
it's too much risky work. It's probably better to leave the checks in
place.

>
> Regards,
> Gilles
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: [math] Second thoughts on MATH-803 and "zip-visitor" for vectors.

[Sébastien Brisard]

Hi Gilles,



2012/11/27 Gilles Sadowski 

> On Tue, Nov 27, 2012 at 12:33:40PM +0100, Gilles Sadowski wrote:
> > On Tue, Nov 27, 2012 at 04:44:27AM +0100, Sébastien Brisard wrote:
> > > Hi,
> > >
> > >
> > > 2012/11/27 Gilles Sadowski 
> > >
> > > > Hello.
> > > >
> > > > > > > in MATH-803 [1] it was decided to deprecate
> > > > > > RealVector.ebeMultiply/Divide,
> > > > > > > because these methods were difficult to support with sparse
> vectors.
> > > > > > > However, in MATH-870, we decided to deprecate sparse vectors
> > > > altogether.
> > > > > > >
> > > > > > > I'm therefore having second thoughts on MATH-803. Since the
> > > > problematic
> > > > > > > implementations of RealVector are removed, why not keep these
> quite
> > > > handy
> > > > > > > methods?
> > > >
> > > > The goal was also to "clean up" the matrix and vector
> implementations.
> > > >
> > > > True, but all good scientific packages (matlab, scilab, numpy) have
> these
> > > operations. If we do not keep them in the interface of RealVector
> (which
> > > I'm OK about), we need to provide a clean alternative. At the moment,
> > > visitors are not clean.
>
> I also agree with that. It's not necessarily conflicting with what I
> propose
> to solve MATH-895.
>
> Replacing the current RealMatrix visitor interface is not obvious, partly
> because we wish to have the same API for RealVector and RealMatrix (2
> different types). [AFAICS, in Python for example, the arguments are just
> "lists of (lists of) numbers".]
>
> An alternative (to try and mimic what exists in those other languages)
> would
> be to stick with the current CM design and add methods similar to "map":
>
>   public static RealVector map(UnivariateFunction f,
>RealVector v)
>   public static RealVector map(BivariateFunction f,
>RealVector v1,
>RealVector v2)
>   public static RealVector map(TrivariateFunction f,
>RealVector v1,
>RealVector v2,
>RealVector v3)
>   public static RealVector map(MultivariateFunction f,
>RealVector... vectors)
>
>
> I like that.


> [I also think that this is actually not the same as the "visitor" pattern
> (where the antries can be visisted in any order) whereas in the above
> cases,
> the assumption is that iterating on each vector is done similarly to
> looping
> over the index of the "getEntry(int index)" method.]
>
> It would be good if we could come up with a design which would exploit the
data structure (ie map over 2/3 ArrayRealVector should use the underlying
arrays).

> It also might make more sense to add these feature in "MathArrays":

>
>   public static double[] map(UnivariateFunction f,
>  double[] v)
>   public static double[] map(BivariateFunction f,
>  double[] v1,
>  double[] v2)
>   public static double[] map(TrivariateFunction f,
>  double[] v1,
>  double[] v2,
>  double[] v3)
>   public static double[] map(MultivariateFunction f,
>  double[][] vectors)
>
> [Where the assumption which I referred to above is trivially verified.]
>
> +1


> Regards,
> Gilles
>
> >
> > Is "ebeDivide" a (mathematical) "vector" operation?
> > IMHO, it's an operation on 2 lists of values.
> >
>
I agree, but it's still useful to have it on vectors... But I'm happy with
map.

> > >
> > >
> > > > I'd rather suggest to add such features in the "MathArrays" class:
> > > > -
> > > > public static double[] ebeDivide(double[] numer,
> > > >  double[] denom) {
> > > >   if (numer.length != denom.length) {
> > > > throw new DimensionMismatchException(numer.length, denom.length);
> > > >   }
> > > >
> > > >   final double[] result = numer.clone();
> > > >   for (int i = 0; i < numer.length; i++) {
> > > > result[i] /= denom[i];
> > > >   }
> > > >
> > > >   return result;
> > > > }
> > > > -
> > > >
> > >
> > > I'm not adverse to the idea, but actually, cleaning recently took
> place the
> > > other way round. In RealVector, we removed all methods which took an
> array
> > > in place of a vector, since constructing an ArrayRealVector from an
> array
> > > is almost costless (using the right constructor).
> >
> > So?
> > This method is to be placed in "MathArrays", not "RealVector". Then, it
> > would be used (e.g. in "JacobiPreconditioner") as:
> > -
> > public RealVector operate(final RealVector x) {
> >   // Dimension check is carried out by ebeDivide
> >   // return x.ebeDivide(diag); // XXX deprecated.
> >   return new ArrayRealVector(MathArrays.ebeDivide(x.toArray(),
> >   diag.toArray()),
> >  false);
> > }
> > --

Re: [math] Second thoughts on MATH-803 and "zip-visitor" for vectors.

[Sébastien Brisard]

Hi Gilles,


2012/11/27 Sébastien Brisard 

> Hi Gilles,
>
>
>
> 2012/11/27 Gilles Sadowski 
>
>> On Tue, Nov 27, 2012 at 12:33:40PM +0100, Gilles Sadowski wrote:
>> > On Tue, Nov 27, 2012 at 04:44:27AM +0100, Sébastien Brisard wrote:
>> > > Hi,
>> > >
>> > >
>> > > 2012/11/27 Gilles Sadowski 
>> > >
>> > > > Hello.
>> > > >
>> > > > > > > in MATH-803 [1] it was decided to deprecate
>> > > > > > RealVector.ebeMultiply/Divide,
>> > > > > > > because these methods were difficult to support with sparse
>> vectors.
>> > > > > > > However, in MATH-870, we decided to deprecate sparse vectors
>> > > > altogether.
>> > > > > > >
>> > > > > > > I'm therefore having second thoughts on MATH-803. Since the
>> > > > problematic
>> > > > > > > implementations of RealVector are removed, why not keep these
>> quite
>> > > > handy
>> > > > > > > methods?
>> > > >
>> > > > The goal was also to "clean up" the matrix and vector
>> implementations.
>> > > >
>> > > > True, but all good scientific packages (matlab, scilab, numpy) have
>> these
>> > > operations. If we do not keep them in the interface of RealVector
>> (which
>> > > I'm OK about), we need to provide a clean alternative. At the moment,
>> > > visitors are not clean.
>>
>> I also agree with that. It's not necessarily conflicting with what I
>> propose
>> to solve MATH-895.
>>
>> Replacing the current RealMatrix visitor interface is not obvious, partly
>> because we wish to have the same API for RealVector and RealMatrix (2
>> different types). [AFAICS, in Python for example, the arguments are just
>> "lists of (lists of) numbers".]
>>
>> An alternative (to try and mimic what exists in those other languages)
>> would
>> be to stick with the current CM design and add methods similar to "map":
>>
>>   public static RealVector map(UnivariateFunction f,
>>RealVector v)
>>   public static RealVector map(BivariateFunction f,
>>RealVector v1,
>>RealVector v2)
>>   public static RealVector map(TrivariateFunction f,
>>RealVector v1,
>>RealVector v2,
>>RealVector v3)
>>   public static RealVector map(MultivariateFunction f,
>>RealVector... vectors)
>>
>>
>> I like that.
>
>
>> [I also think that this is actually not the same as the "visitor" pattern
>> (where the antries can be visisted in any order) whereas in the above
>> cases,
>> the assumption is that iterating on each vector is done similarly to
>> looping
>> over the index of the "getEntry(int index)" method.]
>>
>> It would be good if we could come up with a design which would exploit
> the data structure (ie map over 2/3 ArrayRealVector should use the
> underlying arrays).
>
>
> > It also might make more sense to add these feature in "MathArrays":
>
>>
>>   public static double[] map(UnivariateFunction f,
>>  double[] v)
>>   public static double[] map(BivariateFunction f,
>>  double[] v1,
>>  double[] v2)
>>   public static double[] map(TrivariateFunction f,
>>  double[] v1,
>>  double[] v2,
>>  double[] v3)
>>   public static double[] map(MultivariateFunction f,
>>  double[][] vectors)
>>
>> [Where the assumption which I referred to above is trivially verified.]
>>
>> +1
>
>
>> Regards,
>> Gilles
>>
>> >
>> > Is "ebeDivide" a (mathematical) "vector" operation?
>> > IMHO, it's an operation on 2 lists of values.
>> >
>>
> I agree, but it's still a to have it on vectors... But I'm happy with map.
>

In fact, you convinced me. It's not a linear algebra operation, and should
therefore not be in the RealVector interface. It's true that users are most
likely to invoke those methods on array-based vectors anyway.

Best regards,
Sébastien

>  > >
>> > >
>> > > > I'd rather suggest to add such features in the "MathArrays" class:
>> > > > -
>> > > > public static double[] ebeDivide(double[] numer,
>> > > >  double[] denom) {
>> > > >   if (numer.length != denom.length) {
>> > > > throw new DimensionMismatchException(numer.length,
>> denom.length);
>> > > >   }
>> > > >
>> > > >   final double[] result = numer.clone();
>> > > >   for (int i = 0; i < numer.length; i++) {
>> > > > result[i] /= denom[i];
>> > > >   }
>> > > >
>> > > >   return result;
>> > > > }
>> > > > -
>> > > >
>> > >
>> > > I'm not adverse to the idea, but actually, cleaning recently took
>> place the
>> > > other way round. In RealVector, we removed all methods which took an
>> array
>> > > in place of a vector, since constructing an ArrayRealVector from an
>> array
>> > > is almost costless (using the right constructor).
>> >
>> > So?
>> > This method is to be placed in "MathArrays", not "RealVect

Re: [math] Checking preconditions on package private functions

[Gilles Sadowski]

Hello.

> > [...]
> Actually, I would like the methods to be tested, so they cannot be
> private. That's the reason why I made them package private.

You can indirectly test them by passing appropriate arguments to the public
methods that use them. Please do not select a visibility scope just for the
sake of unit testing.

> If we remove
> the checks (which I really have mixed feelings about) I ropose to fully
> state in the javadoc that the preconditions are *not* checked, and that
> it's the responsibility of the client to check them. But in fact, may be
> it's too much risky work. It's probably better to leave the checks in
> place.

Leave them then. They are not necessary but if efficiency is not going to
suffer noticeably, it certainly does not hurt to keep them.

Regards,
Gilles

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [math] Second thoughts on MATH-803 and "zip-visitor" for vectors.

[Gilles Sadowski]

Hi.
 
> > [...]
> > >
> > > Is "ebeDivide" a (mathematical) "vector" operation?
> > > IMHO, it's an operation on 2 lists of values.
> > >
> >
> I agree, but it's still useful to have it on vectors... But I'm happy with
> map.

Sorry, I've just implemented the MathArrays option.
We can always add that in 3.2, but it would need further thought to be sure
that we cannot come with a better alternative, as part of the overall
cleanup...


Gilles

> > > > [...]

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

[GUMP@vmgump]: Project commons-dbcp (in module commons-dbcp-1.x) failed

[Gump]

To whom it may engage...

This is an automated request, but not an unsolicited one. For 
more information please visit http://gump.apache.org/nagged.html, 
and/or contact the folk at gene...@gump.apache.org.

Project commons-dbcp has an issue affecting its community integration.
This issue affects 18 projects,
 and has been outstanding for 41 runs.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
- commons-dbcp :  Object Pooling
- db-ddlutils :  Easy-to-use component for working with Database Definition 
(...
- jakarta-tomcat-4.0 :  Servlet 2.3 and JSP 1.2 Reference Implementation
- jakarta-tomcat-catalina :  Servlet 2.4 Reference Implementation
- jakarta-tomcat-dbcp :  Servlet 2.4 and JSP 2.0 Reference Implementation
- jakarta-tomcat-jk :  Connectors to various web servers
- javax.el :  Java Servlet 2.5 & Server Pages JSP 2.1 implementation (for 
...
- javax.servlet :  Java Servlet 2.5 & Server Pages JSP 2.1 implementation 
(for ...
- javax.servlet.jsp :  Java Servlet 2.5 & Server Pages JSP 2.1 
implementation (for ...
- solr :  Java Based Search Engine
- solr-test :  Java Based Search Engine
- tomcat-tc6 :  Java Servlet 2.5 & Server Pages JSP 2.1 implementation (for 
...
- tomcat-tc7.0.x :  Tomcat 7.x, a web server implementing Java Servlet 3.0,
...
- tomcat-tc7.0.x-dbcp :  Tomcat 7.x, a web server implementing Java Servlet 
3.0,
...
- tomcat-tc7.0.x-test :  Tomcat 7.x, a web server implementing Java Servlet 
3.0,
...
- tomcat-trunk :  Tomcat 8.x, a web server implementing Java Servlet 3.1,
...
- tomcat-trunk-dbcp :  Tomcat 8.x, a web server implementing Java Servlet 
3.1,
...
- tomcat-trunk-test :  Tomcat 8.x, a web server implementing Java Servlet 
3.1,
...


Full details are available at:

http://vmgump.apache.org/gump/public/commons-dbcp-1.x/commons-dbcp/index.html

That said, some information snippets are provided here.

The following annotations (debug/informational/warning/error messages) were 
provided:
 -DEBUG- Sole jar output [commons-dbcp.jar] identifier set to project name
 -INFO- Failed with reason build failed
 -INFO- Failed to extract fallback artifacts from Gump Repository



The following work was performed:
http://vmgump.apache.org/gump/public/commons-dbcp-1.x/commons-dbcp/gump_work/build_commons-dbcp-1.x_commons-dbcp.html
Work Name: build_commons-dbcp-1.x_commons-dbcp (Type: Build)
Work ended in a state of : Failed
Elapsed: 9 secs
Command Line: /usr/lib/jvm/java-7-oracle/bin/java -Djava.awt.headless=true 
-Dbuild.sysclasspath=only 
-Xbootclasspath/p:/srv/gump/public/workspace/xml-xerces2/build/xercesImpl.jar:/srv/gump/public/workspace/xml-commons/java/external/build/xml-apis.jar
 org.apache.tools.ant.Main -Dgump.merge=/srv/gump/public/gump/work/merge.xml 
dist 
[Working Directory: /srv/gump/public/workspace/commons-dbcp-1.x]
CLASSPATH: 
/usr/lib/jvm/java-7-oracle/lib/tools.jar:/srv/gump/public/workspace/ant/dist/lib/ant.jar:/srv/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/srv/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/srv/gump/public/workspace/ant/dist/lib/ant-junit.jar:/srv/gump/public/workspace/ant/dist/lib/ant-swing.jar:/srv/gump/public/workspace/ant/dist/lib/ant-apache-resolver.jar:/srv/gump/public/workspace/ant/dist/lib/ant-apache-xalan2.jar:/srv/gump/public/workspace/xml-commons/java/build/resolver.jar:/srv/gump/public/workspace/xml-commons/java/external/build/xml-apis-ext.jar:/srv/gump/public/workspace/junit/dist/junit-28112012.jar:/srv/gump/public/workspace/junit/dist/junit-dep-28112012.jar:/srv/gump/packages/jta-spec1_0_1/jta-spec1_0_1.jar:/srv/gump/public/workspace/commons-pool-1.x/dist/commons-pool-1.6.1-SNAPSHOT.jar
-
[javac]^
[javac]   where T is a type-variable:
[javac] T extends Object declared in method 
getObject(String,Class)
[javac] 
/srv/gump/public/workspace/commons-dbcp-1.x/src/java/org/apache/commons/dbcp/DelegatingConnection.java:65:
 error: DelegatingConnection is not abstract and does not override abstract 
method getNetworkTimeout() in Connection
[javac] public class DelegatingConnection extends AbandonedTrace
[javac]^
[javac] 
/srv/gump/public/workspace/commons-dbcp-1.x/src/java/org/apache/commons/dbcp/DelegatingDatabaseMetaData.java:38:
 error: DelegatingDatabaseMetaData is not abstract and does not override 
abstract method generatedKeyAlwaysReturned() in DatabaseMetaData
[javac] public class DelegatingDatabaseMetaData extends AbandonedTrace
[javac]^
[javac] 
/srv/gump/public/workspace/commons-dbcp-1.x/src/java/org/apache/commons/dbcp/DelegatingResultSet.java:61:
 error: DelegatingResultSet is not abstract and does not override abstract 
method getObject(String,Class) in ResultSet
[javac] public class DelegatingResultSet extends Aban

[GUMP@vmgump]: Project commons-dbcp2 (in module apache-commons) failed

[Gump]

To whom it may engage...

This is an automated request, but not an unsolicited one. For 
more information please visit http://gump.apache.org/nagged.html, 
and/or contact the folk at gene...@gump.apache.org.

Project commons-dbcp2 has an issue affecting its community integration.
This issue affects 1 projects,
 and has been outstanding for 210 runs.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
- commons-dbcp2 :  Database Connection Pool


Full details are available at:
http://vmgump.apache.org/gump/public/apache-commons/commons-dbcp2/index.html

That said, some information snippets are provided here.

The following annotations (debug/informational/warning/error messages) were 
provided:
 -DEBUG- Sole jar output [commons-dbcp2-*[0-9T].jar] identifier set to project 
name
 -INFO- Failed with reason build failed
 -INFO- Failed to extract fallback artifacts from Gump Repository



The following work was performed:
http://vmgump.apache.org/gump/public/apache-commons/commons-dbcp2/gump_work/build_apache-commons_commons-dbcp2.html
Work Name: build_apache-commons_commons-dbcp2 (Type: Build)
Work ended in a state of : Failed
Elapsed: 9 secs
Command Line: /usr/lib/jvm/java-7-oracle/bin/java -Djava.awt.headless=true 
-Dbuild.sysclasspath=only 
-Xbootclasspath/p:/srv/gump/public/workspace/xml-xerces2/build/xercesImpl.jar:/srv/gump/public/workspace/xml-commons/java/external/build/xml-apis.jar
 org.apache.tools.ant.Main -Dgump.merge=/srv/gump/public/gump/work/merge.xml 
dist 
[Working Directory: /srv/gump/public/workspace/apache-commons/dbcp]
CLASSPATH: 
/usr/lib/jvm/java-7-oracle/lib/tools.jar:/srv/gump/public/workspace/apache-commons/dbcp/dist/classes:/srv/gump/public/workspace/ant/dist/lib/ant.jar:/srv/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/srv/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/srv/gump/public/workspace/ant/dist/lib/ant-junit.jar:/srv/gump/public/workspace/ant/dist/lib/ant-swing.jar:/srv/gump/public/workspace/ant/dist/lib/ant-apache-resolver.jar:/srv/gump/public/workspace/ant/dist/lib/ant-apache-xalan2.jar:/srv/gump/public/workspace/xml-commons/java/build/resolver.jar:/srv/gump/public/workspace/xml-commons/java/external/build/xml-apis-ext.jar:/srv/gump/packages/jta-spec1_0_1/jta-spec1_0_1.jar:/srv/gump/packages/jdbc2_0/jdbc2_0-stdext.jar:/srv/gump/public/workspace/junit/dist/junit-28112012.jar:/srv/gump/public/workspace/junit/dist/junit-dep-28112012.jar:/srv/gump/public/workspace/apache-commons/pool/dist/commons-pool2-2.0-SNAPSHOT.jar
-
[mkdir] Created dir: 
/srv/gump/public/workspace/apache-commons/dbcp/build/classes
[javac] Compiling 52 source files to 
/srv/gump/public/workspace/apache-commons/dbcp/build/classes
[javac] 
/srv/gump/public/workspace/apache-commons/dbcp/src/java/org/apache/commons/dbcp2/BasicDataSource.java:52:
 error: BasicDataSource is not abstract and does not override abstract method 
getParentLogger() in CommonDataSource
[javac] public class BasicDataSource implements DataSource {
[javac]^
[javac] 
/srv/gump/public/workspace/apache-commons/dbcp/src/java/org/apache/commons/dbcp2/DelegatingConnection.java:65:
 error: DelegatingConnection is not abstract and does not override abstract 
method getNetworkTimeout() in Connection
[javac] public class DelegatingConnection extends AbandonedTrace
[javac]^
[javac] 
/srv/gump/public/workspace/apache-commons/dbcp/src/java/org/apache/commons/dbcp2/DelegatingStatement.java:46:
 error: DelegatingStatement is not abstract and does not override abstract 
method isCloseOnCompletion() in Statement
[javac] public class DelegatingStatement extends AbandonedTrace implements 
Statement {
[javac]^
[javac] 
/srv/gump/public/workspace/apache-commons/dbcp/src/java/org/apache/commons/dbcp2/DelegatingPreparedStatement.java:57:
 error: DelegatingPreparedStatement is not abstract and does not override 
abstract method isCloseOnCompletion() in Statement
[javac] public class DelegatingPreparedStatement extends DelegatingStatement
[javac]^
[javac] 
/srv/gump/public/workspace/apache-commons/dbcp/src/java/org/apache/commons/dbcp2/DelegatingCallableStatement.java:58:
 error: DelegatingCallableStatement is not abstract and does not override 
abstract method getObject(String,Class) in CallableStatement
[javac] public class DelegatingCallableStatement extends 
DelegatingPreparedStatement
[javac]^
[javac]   where T is a type-variable:
[javac] T extends Object declared in method 
getObject(String,Class)
[javac] 
/srv/gump/public/workspace/apache-commons/dbcp/src/java/org/apache/commons/dbcp2/DelegatingDatabaseMetaData.java:36:
 error: DelegatingDatabaseMetaData is not abstract and does not override 
abstract method generatedKeyAlwaysReturned() in DatabaseMetaData
[javac] public clas

Re: svn commit: r1414470 - /commons/proper/math/trunk/src/changes/changes.xml

[Phil Steitz]

On 11/27/12 3:43 PM, er...@apache.org wrote:
> Author: erans
> Date: Tue Nov 27 23:43:06 2012
> New Revision: 1414470
>
> URL: http://svn.apache.org/viewvc?rev=1414470&view=rev
> Log:
> Contents for the release notes.
>
> Modified:
> commons/proper/math/trunk/src/changes/changes.xml
>
> Modified: commons/proper/math/trunk/src/changes/changes.xml
> URL: 
> http://svn.apache.org/viewvc/commons/proper/math/trunk/src/changes/changes.xml?rev=1414470&r1=1414469&r2=1414470&view=diff
> ==
> --- commons/proper/math/trunk/src/changes/changes.xml (original)
> +++ commons/proper/math/trunk/src/changes/changes.xml Tue Nov 27 23:43:06 2012
> @@ -51,6 +51,31 @@ If the output is not quite correct, chec
>
>
>  
>
>  Added element-by-element addition, subtraction, multiplication and 
> division
>
>
>
Nice work!  Definitely past time for a release :)

Phil

-- 


-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [Math] Towards the 3.1 release (take 3)

[Phil Steitz]

On 11/27/12 1:24 PM, Thomas Neidhart wrote:
> On 11/27/2012 04:30 PM, Gilles Sadowski wrote:
>> Hello.
>>
>> Quoting from the previous thread about this subject:
>>> As far as I am concerned, 3.1 could be released anytime now.
>> [Luc Maisonobe, September 14, 2012]
>>
>> Plenty of needed work has been done since then. Most of it could have been
>> done _after_ releasing 3.1!
>> Most of the current contributors agree that releases should happen more
>> often; yet they don't.
>> I would like that a set of objective criteria be written down that would
>> define when a new release is deemed adequate. [I had suggested some.]
>> This discussion should be held in another thread since (as the above quote
>> summarizes), it was agreed that the 3.1 release was due.
>>
>> At this point, I propose to start the release process using the "old" (about
>> to be deprecated) procedure.
>> Indeed, I surely do not want the release to be further delayed because of
>> "newbie" mistakes on using the new procedure (CMS for the site, etc.).
>> Let's "divide and conquer": We release 3.1 now and allow users to benefit
>> from the many new features and bug fixes. While they test the new release,
>> we begin to prepare 3.2 with the new procedure, starting with the site.

+1

Depending on how much happens bet 3.1 and the next one, we could
consider a 3.1.1.

I have some uncommitted stuff to address MATH-672, but I don't want
to hold up the release for this.  If I can't get it finished before
the first RC hits, I will get it in; otherwise it can wait.

Phil
>>
>> OK?
> +1
>
> Thomas
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>


-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

[GUMP@vmgump]: Project commons-io-test (in module apache-commons) failed

[Gump]

To whom it may engage...

This is an automated request, but not an unsolicited one. For 
more information please visit http://gump.apache.org/nagged.html, 
and/or contact the folk at gene...@gump.apache.org.

Project commons-io-test has an issue affecting its community integration.
This issue affects 1 projects,
 and has been outstanding for 42 runs.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
- commons-io-test :  Apache Commons


Full details are available at:

http://vmgump.apache.org/gump/public/apache-commons/commons-io-test/index.html

That said, some information snippets are provided here.

The following annotations (debug/informational/warning/error messages) were 
provided:
 -WARNING- Overriding Maven settings: 
[/srv/gump/public/workspace/apache-commons/io/gump_mvn_settings.xml]
 -DEBUG- (Apache Gump generated) Apache Maven Settings in: 
/srv/gump/public/workspace/apache-commons/io/gump_mvn_settings.xml
 -INFO- Failed with reason build failed
 -DEBUG- Maven POM in: /srv/gump/public/workspace/apache-commons/io/pom.xml
 -INFO- Project Reports in: 
/srv/gump/public/workspace/apache-commons/io/target/surefire-reports



The following work was performed:
http://vmgump.apache.org/gump/public/apache-commons/commons-io-test/gump_work/build_apache-commons_commons-io-test.html
Work Name: build_apache-commons_commons-io-test (Type: Build)
Work ended in a state of : Failed
Elapsed: 2 mins
Command Line: /opt/maven2/bin/mvn --batch-mode --settings 
/srv/gump/public/workspace/apache-commons/io/gump_mvn_settings.xml test 
[Working Directory: /srv/gump/public/workspace/apache-commons/io]
M2_HOME: /opt/maven2
-
Running org.apache.commons.io.comparator.CompositeFileComparatorTest
Tests run: 10, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.161 sec
Running org.apache.commons.io.comparator.DefaultFileComparatorTest
Tests run: 7, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.134 sec
Running org.apache.commons.io.comparator.DirectoryFileComparatorTest
Tests run: 7, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.152 sec
Running org.apache.commons.io.comparator.ExtensionFileComparatorTest
Tests run: 8, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.144 sec
Running org.apache.commons.io.comparator.PathFileComparatorTest
Tests run: 8, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.139 sec
Running org.apache.commons.io.comparator.NameFileComparatorTest
Tests run: 8, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.139 sec
Running org.apache.commons.io.IOUtilsTestCase
Tests run: 63, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.713 sec
Running org.apache.commons.io.IOCaseTestCase
Tests run: 17, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.149 sec
Running org.apache.commons.io.LineIteratorTestCase
Tests run: 16, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.239 sec
Running org.apache.commons.io.FileUtilsCleanDirectoryTestCase
Tests run: 5, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.173 sec
Running org.apache.commons.io.IOUtilsWriteTestCase
Tests run: 53, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.4 sec
Running org.apache.commons.io.FilenameUtilsWildcardTestCase
Tests run: 7, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.209 sec
Running org.apache.commons.io.FileUtilsListFilesTestCase
Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.152 sec
Running org.apache.commons.io.FileSystemUtilsTestCase
Tests run: 28, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.3 sec
Running org.apache.commons.io.DirectoryWalkerTestCaseJava4
Tests run: 14, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.231 sec

Results :

Failed tests:   
testIO_356(org.apache.commons.io.input.CharSequenceInputStreamTest): 
bufferSize=10 dataSize=13: arrays first differed at element [0]; expected:<65> 
but was:<78>

Tests run: 985, Failures: 1, Errors: 0, Skipped: 1

[INFO] 
[ERROR] BUILD FAILURE
[INFO] 
[INFO] There are test failures.

Please refer to 
/srv/gump/public/workspace/apache-commons/io/target/surefire-reports for the 
individual test results.
[INFO] 
[INFO] For more information, run Maven with the -e switch
[INFO] 
[INFO] Total time: 1 minute 59 seconds
[INFO] Finished at: Wed Nov 28 02:32:10 UTC 2012
[INFO] Final Memory: 37M/89M
[INFO] 
-

To subscribe to this information via syndicated feeds:
- RSS: 
http://vmgump.apache.org/gump/public/apache-commons/commons-io-test/rss.xml
- Atom: 
http://vmgump.apache.or

Re: [math] Second thoughts on MATH-803 and "zip-visitor" for vectors.

[Sébastien Brisard]

Hi Gilles,


2012/11/27 Gilles Sadowski 

> Hi.
>
> > > [...]
> > > >
> > > > Is "ebeDivide" a (mathematical) "vector" operation?
> > > > IMHO, it's an operation on 2 lists of values.
> > > >
> > >
> > I agree, but it's still useful to have it on vectors... But I'm happy
> with
> > map.
>
> Sorry, I've just implemented the MathArrays option.
> We can always add that in 3.2, but it would need further thought to be sure
> that we cannot come with a better alternative, as part of the overall
> cleanup...
>
> MathArrays is a good option. I just meant that map would be interesting on
top of that (for vectors which might not be array based). I agree, it needs
further thought.
Contrary to what I was satying previously, the visitor pattern might still
be a worthy option, since it allows nive idioms like
v.walkInXxxOrder(EbeMultiply.by(w)),
where EbeMultiply would be the class of the visitor, and EbeMultiply.by a
factory method which keeps a reference to w. I've implemented that locally,
it reads quite well. The downside is that the visitor keeps a local copy of
w.

Sébastien

Re: [Math] Towards the 3.1 release (take 3)

[Sébastien Brisard]

Hello,


2012/11/28 Phil Steitz 

> On 11/27/12 1:24 PM, Thomas Neidhart wrote:
> > On 11/27/2012 04:30 PM, Gilles Sadowski wrote:
> >> Hello.
> >>
> >> Quoting from the previous thread about this subject:
> >>> As far as I am concerned, 3.1 could be released anytime now.
> >> [Luc Maisonobe, September 14, 2012]
> >>
> >> Plenty of needed work has been done since then. Most of it could have
> been
> >> done _after_ releasing 3.1!
> >> Most of the current contributors agree that releases should happen more
> >> often; yet they don't.
> >> I would like that a set of objective criteria be written down that would
> >> define when a new release is deemed adequate. [I had suggested some.]
> >> This discussion should be held in another thread since (as the above
> quote
> >> summarizes), it was agreed that the 3.1 release was due.
> >>
> >> At this point, I propose to start the release process using the "old"
> (about
> >> to be deprecated) procedure.
> >> Indeed, I surely do not want the release to be further delayed because
> of
> >> "newbie" mistakes on using the new procedure (CMS for the site, etc.).
> >> Let's "divide and conquer": We release 3.1 now and allow users to
> benefit
> >> from the many new features and bug fixes. While they test the new
> release,
> >> we begin to prepare 3.2 with the new procedure, starting with the site.
>
> +1
>
> Depending on how much happens bet 3.1 and the next one, we could
> consider a 3.1.1.
>
> I have some uncommitted stuff to address MATH-672, but I don't want
> to hold up the release for this.  If I can't get it finished before
> the first RC hits, I will get it in; otherwise it can wait.
>
I'm +1 too. I also have some uncommitted code for MATH-738. It will have to
wait, and I will in fact remove some recently committed code (the package
private functions in Gamma and Beta) as I was hopping for more tome to play
around with their interface and location (and scope, cf. other thread).
This was in fact committed too early, but since it is a lot of code to get
Beta right, I was thinking of committing incrementally.

Best regards,
Sébastien

Re: svn commit: r1414470 - /commons/proper/math/trunk/src/changes/changes.xml

[Sébastien Brisard]

Hi,


2012/11/28 Phil Steitz 

> On 11/27/12 3:43 PM, er...@apache.org wrote:
> > Author: erans
> > Date: Tue Nov 27 23:43:06 2012
> > New Revision: 1414470
> >
> > URL: http://svn.apache.org/viewvc?rev=1414470&view=rev
> > Log:
> > Contents for the release notes.
> >
> > Modified:
> > commons/proper/math/trunk/src/changes/changes.xml
> >
> > Modified: commons/proper/math/trunk/src/changes/changes.xml
> > URL:
> http://svn.apache.org/viewvc/commons/proper/math/trunk/src/changes/changes.xml?rev=1414470&r1=1414469&r2=1414470&view=diff
> >
> ==
> > --- commons/proper/math/trunk/src/changes/changes.xml (original)
> > +++ commons/proper/math/trunk/src/changes/changes.xml Tue Nov 27
> 23:43:06 2012
> > @@ -51,6 +51,31 @@ If the output is not quite correct, chec
> >
> >
> >  
> >
> >  Added element-by-element addition, subtraction, multiplication
> and division
> >
> >
> >
> Nice work!  Definitely past time for a release :)
>
> Phil
>
> --
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

[continuum] BUILD FAILURE: Apache Commons - Commons Net -

[Continuum@vmbuild]

  Group (shared) Maven 2 Build Definition (Java 1.5)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Continuum-Build-Host: vmbuild
X-Continuum-Project-Id: 107
X-Continuum-Project-Name: Commons Net

Online report : 
http://vmbuild.apache.org/continuum/buildResult.action?buildId=25337&projectId=107

Build statistics:
  State: Failed
  Previous State: Ok
  Started at: Wed 28 Nov 2012 03:22:27 +
  Finished at: Wed 28 Nov 2012 03:22:44 +
  Total time: 17s
  Build Trigger: Schedule
  Build Number: 253
  Exit code: 1
  Building machine hostname: vmbuild
  Operating system : Linux(unknown)
  Java Home version : 
  java version "1.6.0_30"
  Java(TM) SE Runtime Environment (build 1.6.0_30-b12)
  Java HotSpot(TM) 64-Bit Server VM (build 20.5-b03, mixed mode)

  Builder version :
  Apache Maven 2.2.1 (r801777; 2009-08-06 19:16:01+)
  Java version: 1.6.0_30
  Java home: /usr/lib/jvm/jdk1.6.0_30/jre
  Default locale: en_US, platform encoding: ANSI_X3.4-1968
  OS name: "linux" version: "2.6.32-41-server" arch: "amd64" Family: 
"unix"


SCM Changes:

Changed: ggregory @ Wed 28 Nov 2012 02:40:39 +
Comment: Add a Charset field to the two root abstract socket classes that 
provide a common base implementation for socket-based subclasses. The default 
value is the platform encoding. Subclasses can now use this value instead of 
relying on APIs that do not specify an encoding. For example 
String#getBytes(Charset) instead of getBytes(). The behavior is unchanged but 
the FindBugs emits fewer warnings. Note that it is now easy for subclasses to 
specify an encoding consistently. If you search for "UTF-8", you find uses of 
the "UTF-8" encoding and of the platform encoding in the same class, which are 
likely bugs. These can now be fixed in a much easier and consistent manner.
Files changed:
  
/commons/proper/net/trunk/src/main/java/org/apache/commons/net/DatagramSocketClient.java
 ( 1414510 )
  
/commons/proper/net/trunk/src/main/java/org/apache/commons/net/SocketClient.java
 ( 1414510 )
  
/commons/proper/net/trunk/src/main/java/org/apache/commons/net/bsd/RExecClient.java
 ( 1414510 )
  
/commons/proper/net/trunk/src/main/java/org/apache/commons/net/daytime/DaytimeTCPClient.java
 ( 1414510 )
  
/commons/proper/net/trunk/src/main/java/org/apache/commons/net/daytime/DaytimeUDPClient.java
 ( 1414510 )
  
/commons/proper/net/trunk/src/main/java/org/apache/commons/net/finger/FingerClient.java
 ( 1414510 )
  
/commons/proper/net/trunk/src/main/java/org/apache/commons/net/ftp/FTPHTTPClient.java
 ( 1414510 )
  
/commons/proper/net/trunk/src/main/java/org/apache/commons/net/ftp/FTPListParseEngine.java
 ( 1414510 )
  
/commons/proper/net/trunk/src/main/java/org/apache/commons/net/imap/AuthenticatingIMAPClient.java
 ( 1414510 )
  
/commons/proper/net/trunk/src/main/java/org/apache/commons/net/pop3/ExtendedPOP3Client.java
 ( 1414510 )
  
/commons/proper/net/trunk/src/main/java/org/apache/commons/net/pop3/POP3Client.java
 ( 1414510 )
  
/commons/proper/net/trunk/src/main/java/org/apache/commons/net/smtp/AuthenticatingSMTPClient.java
 ( 1414510 )
  
/commons/proper/net/trunk/src/main/java/org/apache/commons/net/telnet/Telnet.java
 ( 1414510 )
  
/commons/proper/net/trunk/src/main/java/org/apache/commons/net/util/Charsets.java
 ( 1414510 )

Changed: ggregory @ Wed 28 Nov 2012 02:51:20 +
Comment: Refactor magic char into NULL_CHAR.
Files changed:
  
/commons/proper/net/trunk/src/main/java/org/apache/commons/net/bsd/RCommandClient.java
 ( 1414514 )
  
/commons/proper/net/trunk/src/main/java/org/apache/commons/net/bsd/RExecClient.java
 ( 1414514 )


Dependencies Changes:

No dependencies changed



Build Definition:

POM filename: pom.xml
Goals: clean deploy   
Arguments: --batch-mode -Pjava-1.5 -Dgpg.skip -Prelease
Build Fresh: false
Always Build: false
Default Build Definition: true
Schedule: COMMONS_SCHEDULE
Profile Name: Maven 2.2.1
Description: Group (shared) Maven 2 Build Definition (Java 1.5)


Test Summary:

Tests: 0
Failures: 0
Errors: 0
Total time: 0.0





-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

[GUMP@vmgump]: Project commons-digester3 (in module apache-commons) failed

[Gump]

To whom it may engage...

This is an automated request, but not an unsolicited one. For 
more information please visit http://gump.apache.org/nagged.html, 
and/or contact the folk at gene...@gump.apache.org.

Project commons-digester3 has an issue affecting its community integration.
This issue affects 2 projects,
 and has been outstanding for 41 runs.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
- commons-digester3 :  XML to Java Object Configuration
- commons-digester3-test :  Apache Commons


Full details are available at:

http://vmgump.apache.org/gump/public/apache-commons/commons-digester3/index.html

That said, some information snippets are provided here.

The following annotations (debug/informational/warning/error messages) were 
provided:
 -DEBUG- Sole jar output [commons-digester3-*[0-9T].jar] identifier set to 
project name
 -DEBUG- (Apache Gump generated) Apache Maven Settings in: 
/srv/gump/public/workspace/apache-commons/digester/gump_mvn_settings.xml
 -INFO- Failed with reason build failed
 -DEBUG- Maven POM in: 
/srv/gump/public/workspace/apache-commons/digester/pom.xml
 -INFO- Failed to extract fallback artifacts from Gump Repository



The following work was performed:
http://vmgump.apache.org/gump/public/apache-commons/commons-digester3/gump_work/build_apache-commons_commons-digester3.html
Work Name: build_apache-commons_commons-digester3 (Type: Build)
Work ended in a state of : Failed
Elapsed: 60 secs
Command Line: /opt/maven2/bin/mvn --batch-mode -DskipTests=true --settings 
/srv/gump/public/workspace/apache-commons/digester/gump_mvn_settings.xml 
package 
[Working Directory: /srv/gump/public/workspace/apache-commons/digester]
M2_HOME: /opt/maven2
-
[INFO] [remote-resources:process {execution: default}]
[INFO] [buildnumber:create {execution: default}]
[INFO] Checking for local modifications: skipped.
[INFO] Updating project files from SCM: skipped.
[INFO] Executing: /bin/sh -c cd 
/srv/gump/public/workspace/apache-commons/digester/annotations-processor && svn 
--non-interactive info
[INFO] Working directory: 
/srv/gump/public/workspace/apache-commons/digester/annotations-processor
[INFO] Storing buildNumber: ?? at timestamp: 1354075613599
[INFO] Executing: /bin/sh -c cd 
/srv/gump/public/workspace/apache-commons/digester/annotations-processor && svn 
--non-interactive info
[INFO] Working directory: 
/srv/gump/public/workspace/apache-commons/digester/annotations-processor
[INFO] Storing buildScmBranch: UNKNOWN_BRANCH
[debug] execute contextualize
[INFO] [resources:resources {execution: default-resources}]
[INFO] Using 'iso-8859-1' encoding to copy filtered resources.
[INFO] Copying 2 resources to META-INF
[INFO] [compiler:compile {execution: default-compile}]
[INFO] Compiling 5 source files to 
/srv/gump/public/workspace/apache-commons/digester/annotations-processor/target/classes
[INFO] [bundle:manifest {execution: bundle-manifest}]
[debug] execute contextualize
[INFO] [resources:testResources {execution: default-testResources}]
[INFO] Using 'iso-8859-1' encoding to copy filtered resources.
[INFO] skip non existing resourceDirectory 
/srv/gump/public/workspace/apache-commons/digester/annotations-processor/src/test/resources
[INFO] Copying 0 resource to META-INF
[INFO] [compiler:testCompile {execution: default-testCompile}]
[INFO] Compiling 3 source files to 
/srv/gump/public/workspace/apache-commons/digester/annotations-processor/target/test-classes
>@org.apache.commons.digester3.annotations.rules.ObjectCreate(pattern="rss/channel")
>@org.apache.commons.digester3.annotations.rules.ObjectCreate(pattern="rss/channel/image")
>@org.apache.commons.digester3.annotations.rules.ObjectCreate(pattern="rss/channel/item")
>
[INFO] -
[ERROR] COMPILATION ERROR : 
[INFO] -
[ERROR] error: Impossible to generate class 
org.apache.commons.digester3.annotations.processor.GeneratedRulesModule: 
Attempt to recreate a file for type 
org.apache.commons.digester3.annotations.processor.GeneratedRulesModule
[ERROR] error: Impossible to generate class 
org.apache.commons.digester3.annotations.processor.GeneratedRulesModule: 
Attempt to recreate a file for type 
org.apache.commons.digester3.annotations.processor.GeneratedRulesModule
[INFO] 2 errors 
[INFO] -
[INFO] 
[ERROR] BUILD FAILURE
[INFO] 
[INFO] Compilation failure

error: Impossible to generate class 
org.apache.commons.digester3.annotations.processor.GeneratedRulesModule: 
Attempt to recreate a file for type 
org.apache.commons.digester3.annota

[GUMP@vmgump]: Project commons-chain2 (in module apache-commons) failed

[Gump]

To whom it may engage...

This is an automated request, but not an unsolicited one. For 
more information please visit http://gump.apache.org/nagged.html, 
and/or contact the folk at gene...@gump.apache.org.

Project commons-chain2 has an issue affecting its community integration.
This issue affects 1 projects,
 and has been outstanding for 232 runs.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
- commons-chain2 :  GoF "Chain of Responsibility" pattern


Full details are available at:

http://vmgump.apache.org/gump/public/apache-commons/commons-chain2/index.html

That said, some information snippets are provided here.

The following annotations (debug/informational/warning/error messages) were 
provided:
 -DEBUG- Sole jar output [commons-chain2-*[0-9T].jar] identifier set to project 
name
 -DEBUG- Sole pom output [pom.xml] identifier set to project name
 -DEBUG- (Apache Gump generated) Apache Maven Settings in: 
/srv/gump/public/workspace/apache-commons/chain/gump_mvn_settings.xml
 -INFO- Failed with reason build failed
 -DEBUG- Maven POM in: /srv/gump/public/workspace/apache-commons/chain/pom.xml
 -INFO- Failed to extract fallback artifacts from Gump Repository



The following work was performed:
http://vmgump.apache.org/gump/public/apache-commons/commons-chain2/gump_work/build_apache-commons_commons-chain2.html
Work Name: build_apache-commons_commons-chain2 (Type: Build)
Work ended in a state of : Failed
Elapsed: 1 min 1 sec
Command Line: /opt/maven2/bin/mvn --batch-mode --settings 
/srv/gump/public/workspace/apache-commons/chain/gump_mvn_settings.xml package 
[Working Directory: /srv/gump/public/workspace/apache-commons/chain]
M2_HOME: /opt/maven2
-
[INFO] Building war: 
/srv/gump/public/workspace/apache-commons/chain/apps/cookbook-examples/target/chain-cookbook-examples-2.0-SNAPSHOT.war
[INFO] 
[INFO] Building Apache Commons Chain :: Distribution Packages
[INFO]task-segment: [package]
[INFO] 
[INFO] snapshot org.apache.commons:commons-chain2-configuration:2.0-SNAPSHOT: 
checking for updates from apache.snapshots
Downloading: 
http://localhost:8192/repo/m2-snapshot-repository/org/apache/commons/commons-chain2-configuration/2.0-SNAPSHOT/commons-chain2-configuration-2.0-SNAPSHOT.pom
[INFO] Unable to find resource 
'org.apache.commons:commons-chain2-configuration:pom:2.0-SNAPSHOT' in 
repository apache.snapshots (http://repository.apache.org/snapshots)
Downloading: 
http://localhost:8192/repo/m2-snapshot-repository/org/apache/commons/commons-chain2-configuration/2.0-SNAPSHOT/commons-chain2-configuration-2.0-SNAPSHOT.jar
[INFO] Unable to find resource 
'org.apache.commons:commons-chain2-configuration:jar:2.0-SNAPSHOT' in 
repository apache.snapshots (http://repository.apache.org/snapshots)
[INFO] 
[ERROR] BUILD ERROR
[INFO] 
[INFO] Failed to resolve artifact.

Missing:
--
1) org.apache.commons:commons-chain2-configuration:jar:2.0-SNAPSHOT

  Try downloading the file manually from the project website.

  Then, install it using the command: 
  mvn install:install-file -DgroupId=org.apache.commons 
-DartifactId=commons-chain2-configuration -Dversion=2.0-SNAPSHOT 
-Dpackaging=jar -Dfile=/path/to/file

  Alternatively, if you host your own repository you can deploy the file there: 
  mvn deploy:deploy-file -DgroupId=org.apache.commons 
-DartifactId=commons-chain2-configuration -Dversion=2.0-SNAPSHOT 
-Dpackaging=jar -Dfile=/path/to/file -Durl=[url] -DrepositoryId=[id]

  Path to dependency: 
1) org.apache.commons:commons-chain2:pom:2.0-SNAPSHOT
2) org.apache.commons:commons-chain2-configuration:jar:2.0-SNAPSHOT

--
1 required artifact is missing.

for artifact: 
  org.apache.commons:commons-chain2:pom:2.0-SNAPSHOT

from the specified remote repositories:
  gump-central (http://localhost:8192/maven2),
  gump-apache.snapshots (http://localhost:8192/repo/m2-snapshot-repository)



[INFO] 
[INFO] For more information, run Maven with the -e switch
[INFO] 
[INFO] Total time: 59 seconds
[INFO] Finished at: Wed Nov 28 05:17:41 UTC 2012
[INFO] Final Memory: 114M/241M
[INFO] 
-

To subscribe to this information via syndicated feeds:
- RSS: 
http://vmgump.apache.org/gump/public/apache-commons/commons-chain2/rss.xml
- Atom: 
http://vmgump.apache.org/gump/public/apache-commons/commons-chain2/

Re: svn commit: r1414470 - /commons/proper/math/trunk/src/changes/changes.xml

[Sébastien Brisard]

Hello,


2012/11/28 Sébastien Brisard 

> Hi,
>
>
> 2012/11/28 Phil Steitz 
>
>> On 11/27/12 3:43 PM, er...@apache.org wrote:
>> > Author: erans
>> > Date: Tue Nov 27 23:43:06 2012
>> > New Revision: 1414470
>> >
>> > URL: http://svn.apache.org/viewvc?rev=1414470&view=rev
>> > Log:
>> > Contents for the release notes.
>> >
>> > Modified:
>> > commons/proper/math/trunk/src/changes/changes.xml
>> >
>> > Modified: commons/proper/math/trunk/src/changes/changes.xml
>> > URL:
>> http://svn.apache.org/viewvc/commons/proper/math/trunk/src/changes/changes.xml?rev=1414470&r1=1414469&r2=1414470&view=diff
>> >
>> ==
>> > --- commons/proper/math/trunk/src/changes/changes.xml (original)
>> > +++ commons/proper/math/trunk/src/changes/changes.xml Tue Nov 27
>> 23:43:06 2012
>> > @@ -51,6 +51,31 @@ If the output is not quite correct, chec
>> >
>> >
>> >  
>> >
>> >  Added element-by-element addition, subtraction, multiplication
>> and division
>> >
>> >
>> >
>> Nice work!  Definitely past time for a release :)
>>
>> Phil
>>
>> --
>>
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> For additional commands, e-mail: dev-h...@commons.apache.org
>>
>>
>

[GUMP@vmgump]: Project commons-proxy-test (in module apache-commons) failed

[Gump]

To whom it may engage...

This is an automated request, but not an unsolicited one. For 
more information please visit http://gump.apache.org/nagged.html, 
and/or contact the folk at gene...@gump.apache.org.

Project commons-proxy-test has an issue affecting its community integration.
This issue affects 1 projects,
 and has been outstanding for 46 runs.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
- commons-proxy-test :  Apache Commons


Full details are available at:

http://vmgump.apache.org/gump/public/apache-commons/commons-proxy-test/index.html

That said, some information snippets are provided here.

The following annotations (debug/informational/warning/error messages) were 
provided:
 -WARNING- Overriding Maven settings: 
[/srv/gump/public/workspace/apache-commons/proxy/gump_mvn_settings.xml]
 -DEBUG- (Apache Gump generated) Apache Maven Settings in: 
/srv/gump/public/workspace/apache-commons/proxy/gump_mvn_settings.xml
 -INFO- Failed with reason build failed
 -DEBUG- Maven POM in: /srv/gump/public/workspace/apache-commons/proxy/pom.xml
 -INFO- Project Reports in: 
/srv/gump/public/workspace/apache-commons/proxy/target/surefire-reports



The following work was performed:
http://vmgump.apache.org/gump/public/apache-commons/commons-proxy-test/gump_work/build_apache-commons_commons-proxy-test.html
Work Name: build_apache-commons_commons-proxy-test (Type: Build)
Work ended in a state of : Failed
Elapsed: 16 secs
Command Line: /opt/maven2/bin/mvn --batch-mode --settings 
/srv/gump/public/workspace/apache-commons/proxy/gump_mvn_settings.xml test 
[Working Directory: /srv/gump/public/workspace/apache-commons/proxy]
M2_HOME: /opt/maven2
-
Running org.apache.commons.proxy.factory.util.TestMethodSignature
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.003 sec

Results :

Tests in error: 
  
testMethodInvocationImplementation(org.apache.commons.proxy.interceptor.TestMethodInterceptorAdapter)
  
testMethodInterception(org.apache.commons.proxy.interceptor.TestMethodInterceptorAdapter)
  
testSerialization(org.apache.commons.proxy.interceptor.TestMethodInterceptorAdapter)
  testInvalidHandlerName(org.apache.commons.proxy.invoker.TestXmlRpcInvoker)
  
testMethodInvocation(org.apache.commons.proxy.invoker.TestInvocationHandlerAdapter)
  
testInterceptorEquals(org.apache.commons.proxy.factory.javassist.TestJavassistProxyFactory)
  
testInvokerEquals(org.apache.commons.proxy.factory.javassist.TestJavassistProxyFactory)
  
testInterceptorWithSuperclass(org.apache.commons.proxy.factory.javassist.TestJavassistProxyFactory)
  
testInvokerWithSuperclass(org.apache.commons.proxy.factory.javassist.TestJavassistProxyFactory)
  
testProxiesWithClashingFinalMethodInSuperclass(org.apache.commons.proxy.factory.javassist.TestJavassistProxyFactory)
  
testInterceptorHashCode(org.apache.commons.proxy.factory.javassist.TestJavassistProxyFactory)
  
testInvokerHashCode(org.apache.commons.proxy.factory.javassist.TestJavassistProxyFactory)
  
testBooleanInterceptorParameter(org.apache.commons.proxy.factory.javassist.TestJavassistProxyFactory)
  
testChangingArguments(org.apache.commons.proxy.factory.javassist.TestJavassistProxyFactory)
  
testCreateInterceptorProxy(org.apache.commons.proxy.factory.javassist.TestJavassistProxyFactory)
  
testInterceptingProxyClassCaching(org.apache.commons.proxy.factory.javassist.TestJavassistProxyFactory)
  
testInterceptingProxySerializable(org.apache.commons.proxy.factory.javassist.TestJavassistProxyFactory)
  
testInterceptorProxyWithCheckedException(org.apache.commons.proxy.factory.javassist.TestJavassistProxyFactory)
  
testInterceptorProxyWithUncheckedException(org.apache.commons.proxy.factory.javassist.TestJavassistProxyFactory)
  
testInvokerProxy(org.apache.commons.proxy.factory.javassist.TestJavassistProxyFactory)
  
testInvokerProxyClassCaching(org.apache.commons.proxy.factory.javassist.TestJavassistProxyFactory)
  
testInvokerProxySerializable(org.apache.commons.proxy.factory.javassist.TestJavassistProxyFactory)
  
testMethodInvocationClassCaching(org.apache.commons.proxy.factory.javassist.TestJavassistProxyFactory)
  
testMethodInvocationDuplicateMethods(org.apache.commons.proxy.factory.javassist.TestJavassistProxyFactory)
  
testMethodInvocationImplementation(org.apache.commons.proxy.factory.javassist.TestJavassistProxyFactory)
  
testWithNonAccessibleTargetType(org.apache.commons.proxy.factory.javassist.TestJavassistProxyFactory)
  testCreateNullObject(org.apache.commons.proxy.TestProxyUtils)
  testCreateNullObjectWithClassLoader(org.apache.commons.proxy.TestProxyUtils)

Tests run: 179, Failures: 0, Errors: 28, Skipped: 0

[INFO] 
[ERROR] BUILD FAILURE
[INFO] 
[INFO] There 

[GUMP@vmgump]: Project commons-dbutils (in module apache-commons) failed

[Gump]

To whom it may engage...

This is an automated request, but not an unsolicited one. For 
more information please visit http://gump.apache.org/nagged.html, 
and/or contact the folk at gene...@gump.apache.org.

Project commons-dbutils has an issue affecting its community integration.
This issue affects 1 projects,
 and has been outstanding for 210 runs.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
- commons-dbutils :  Commons DbUtils


Full details are available at:

http://vmgump.apache.org/gump/public/apache-commons/commons-dbutils/index.html

That said, some information snippets are provided here.

The following annotations (debug/informational/warning/error messages) were 
provided:
 -DEBUG- Sole jar output [commons-dbutils-*[0-9T].jar] identifier set to 
project name
 -INFO- Optional dependency mockito failed with reason build failed
 -DEBUG- (Apache Gump generated) Apache Maven Settings in: 
/srv/gump/public/workspace/apache-commons/dbutils/gump_mvn_settings.xml
 -INFO- Failed with reason build failed
 -DEBUG- Maven POM in: /srv/gump/public/workspace/apache-commons/dbutils/pom.xml
 -INFO- Project Reports in: 
/srv/gump/public/workspace/apache-commons/dbutils/target/surefire-reports
 -WARNING- No directory 
[/srv/gump/public/workspace/apache-commons/dbutils/target/surefire-reports]
 -INFO- Failed to extract fallback artifacts from Gump Repository



The following work was performed:
http://vmgump.apache.org/gump/public/apache-commons/commons-dbutils/gump_work/build_apache-commons_commons-dbutils.html
Work Name: build_apache-commons_commons-dbutils (Type: Build)
Work ended in a state of : Failed
Elapsed: 17 secs
Command Line: /opt/maven2/bin/mvn --batch-mode --settings 
/srv/gump/public/workspace/apache-commons/dbutils/gump_mvn_settings.xml package 
[Working Directory: /srv/gump/public/workspace/apache-commons/dbutils]
M2_HOME: /opt/maven2
-
1K downloaded  (mockito-core-1.9.0.pom)
Downloading: 
http://localhost:8192/maven2/org/hamcrest/hamcrest-all/1.1/hamcrest-all-1.1.pom
479b downloaded  (hamcrest-all-1.1.pom)
Downloading: 
http://localhost:8192/maven2/org/mockito/mockito-core/1.9.0/mockito-core-1.9.0.jar
Downloading: 
http://localhost:8192/maven2/org/hamcrest/hamcrest-all/1.1/hamcrest-all-1.1.jar
273K downloaded  (hamcrest-all-1.1.jar)
1381K downloaded  (mockito-core-1.9.0.jar)
[INFO] [antrun:run {execution: javadoc.resources}]
[INFO] Executing tasks

main:
 [copy] Copying 2 files to 
/srv/gump/public/workspace/apache-commons/dbutils/target/apidocs/META-INF
[INFO] Executed tasks
[WARNING] The parameter expression: 'project.build.resources' used in mojo: 
'process' has been deprecated. Use 'project.resources' instead.
[INFO] [remote-resources:process {execution: default}]
[INFO] [buildnumber:create {execution: default}]
[INFO] Checking for local modifications: skipped.
[INFO] Updating project files from SCM: skipped.
[INFO] Executing: /bin/sh -c cd 
/srv/gump/public/workspace/apache-commons/dbutils && svn --non-interactive info
[INFO] Working directory: /srv/gump/public/workspace/apache-commons/dbutils
[INFO] Storing buildNumber: ?? at timestamp: 1354082174251
[INFO] Executing: /bin/sh -c cd 
/srv/gump/public/workspace/apache-commons/dbutils && svn --non-interactive info
[INFO] Working directory: /srv/gump/public/workspace/apache-commons/dbutils
[INFO] Storing buildScmBranch: UNKNOWN_BRANCH
[debug] execute contextualize
[INFO] [resources:resources {execution: default-resources}]
[INFO] Using 'iso-8859-1' encoding to copy filtered resources.
[INFO] skip non existing resourceDirectory 
/srv/gump/public/workspace/apache-commons/dbutils/src/main/resources
[INFO] Copying 2 resources to META-INF
[INFO] [compiler:compile {execution: default-compile}]
[INFO] Compiling 29 source files to 
/srv/gump/public/workspace/apache-commons/dbutils/target/classes
[INFO] -
[ERROR] COMPILATION ERROR : 
[INFO] -
[ERROR] 
/srv/gump/public/workspace/apache-commons/dbutils/src/main/java/org/apache/commons/dbutils/DbUtils.java:[334,25]
 error: DriverProxy is not abstract and does not override abstract method 
getParentLogger() in Driver
[INFO] 1 error
[INFO] -
[INFO] 
[ERROR] BUILD FAILURE
[INFO] 
[INFO] Compilation failure
/srv/gump/public/workspace/apache-commons/dbutils/src/main/java/org/apache/commons/dbutils/DbUtils.java:[334,25]
 error: DriverProxy is not abstract and does not override abstract method 
getParentLogger() in Driver

[INFO] 
[INFO] For more information, run Mav

Re: [VOTE] Release NET 3.2 based on RC1

[Gary Gregory]

On Mon, Nov 26, 2012 at 2:20 PM, sebb  wrote:

> On 26 November 2012 19:08, Gary Gregory  wrote:
> > Hi,
> >
> > I thought we had a policy to keep BC for minor releases?
>
> Yes.
>
> > I understand that the removed methods are not in core classes but it
> still
> > breaks BC. Are sure we want that? Are the removed methods confusing in a
> > way that can be construed as keeping them being a bug?
>
> If the code is not being used by external clients then BC
> compatibility is irrelevant.
> This is the case here.
>

+1

Gary


>
> > Gary
> >
> > On Mon, Nov 26, 2012 at 1:29 PM, sebb  wrote:
> >
> >> This is a vote to release Apache Commons NET 3.2 based on RC1.
> >>
> >> [ ] +1 release it
> >> [ ] +0 go ahead I don't care
> >> [ ] -1 no, do not release it because...
> >>
> >> tag:
> >>
> https://svn.apache.org/repos/asf/commons/proper/net/tags/NET_3_2_RC1/(r1413727)
> >>
> >> site:
> >> http://people.apache.org/~sebb/net-3.2-RC1/
> >>
> >> The Javadocs (1.4.1) link does not work, nor does the download link.
> >> These will be OK once the site is deployed.
> >>
> >> Source and binary archives (tar.gz and .zip) and Maven jars:
> >>
> https://repository.apache.org/content/repositories/orgapachecommons-078/
> >>
> >> [The tar.gz and .zip files will be moved to dist/commons/net before
> >> promoting the Maven jars to release status]
> >>
> >> Vote will remain open for at least 72 hours.
> >>
> >> -
> >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> >> For additional commands, e-mail: dev-h...@commons.apache.org
> >>
> >>
> >
> >
> > --
> > E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
> > JUnit in Action, 2nd Ed: http://bit.ly/ECvg0
> > Spring Batch in Action: http://bit.ly/bqpbCK
> > Blog: http://garygregory.wordpress.com
> > Home: http://garygregory.com/
> > Tweet! http://twitter.com/GaryGregory
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>


-- 
E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
JUnit in Action, 2nd Ed: http://bit.ly/ECvg0
Spring Batch in Action: http://bit.ly/bqpbCK
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory

[GUMP@vmgump]: Project commons-scxml-test (in module apache-commons) failed

[Gump]

To whom it may engage...

This is an automated request, but not an unsolicited one. For 
more information please visit http://gump.apache.org/nagged.html, 
and/or contact the folk at gene...@gump.apache.org.

Project commons-scxml-test has an issue affecting its community integration.
This issue affects 1 projects,
 and has been outstanding for 215 runs.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
- commons-scxml-test :  Apache Commons


Full details are available at:

http://vmgump.apache.org/gump/public/apache-commons/commons-scxml-test/index.html

That said, some information snippets are provided here.

The following annotations (debug/informational/warning/error messages) were 
provided:
 -WARNING- Overriding Maven settings: 
[/srv/gump/public/workspace/apache-commons/scxml/gump_mvn_settings.xml]
 -DEBUG- (Apache Gump generated) Apache Maven Settings in: 
/srv/gump/public/workspace/apache-commons/scxml/gump_mvn_settings.xml
 -INFO- Failed with reason build failed
 -DEBUG- Maven POM in: /srv/gump/public/workspace/apache-commons/scxml/pom.xml
 -INFO- Project Reports in: 
/srv/gump/public/workspace/apache-commons/scxml/target/surefire-reports



The following work was performed:
http://vmgump.apache.org/gump/public/apache-commons/commons-scxml-test/gump_work/build_apache-commons_commons-scxml-test.html
Work Name: build_apache-commons_commons-scxml-test (Type: Build)
Work ended in a state of : Failed
Elapsed: 23 secs
Command Line: /opt/maven2/bin/mvn --batch-mode -Dsimplelog.defaultlog=info 
--settings 
/srv/gump/public/workspace/apache-commons/scxml/gump_mvn_settings.xml test 
[Working Directory: /srv/gump/public/workspace/apache-commons/scxml]
M2_HOME: /opt/maven2
-
[INFO] SimpleSCXMLListener - /s2/s2.1/e1.2
[INFO] SimpleSCXMLListener - /s2/s2.1/e1.2
[INFO] SimpleSCXMLListener - /s2/s2.1
[INFO] SimpleSCXMLListener - /s2
[INFO] SimpleSCXMLListener - transition (event = s2.1.done, cond = null, from = 
/s2, to = /s3)
[INFO] SimpleSCXMLListener - /s3
Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.306 sec
Running org.apache.commons.scxml.issues.Issue64Test
[INFO] SCXMLSemantics - null: Begin transition bug test ...
[INFO] SimpleSCXMLListener - /tranbug
[INFO] SimpleSCXMLListener - /tranbug
[INFO] SCXMLSemantics - null: somedata
[INFO] SCXMLSemantics - null: *somedata
[INFO] SimpleSCXMLListener - transition (event = show.bug, cond = null, from = 
/tranbug, to = /end)
[INFO] SimpleSCXMLListener - /end
[WARN] SCXMLParser - Ignoring element  in namespace 
"http://www.w3.org/2005/07/scxml"; at 
file:/srv/gump/public/workspace/apache-commons/scxml/target/test-classes/org/apache/commons/scxml/issues/issue64-02.xml:30:21
 and digester match "scxml/datamodel/misplaced"
[WARN] SCXMLParser - Ignoring element  in namespace 
"http://www.w3.org/2005/07/scxml"; at 
file:/srv/gump/public/workspace/apache-commons/scxml/target/test-classes/org/apache/commons/scxml/issues/issue64-02.xml:36:19
 and digester match "scxml/state/onentry/foo"
[WARN] SCXMLParser - Ignoring element  in namespace 
"http://my.foo.example/"; at 
file:/srv/gump/public/workspace/apache-commons/scxml/target/test-classes/org/apache/commons/scxml/issues/issue64-02.xml:37:22
 and digester match "scxml/state/onentry/bar"
[WARN] SCXMLParser - Ignoring element  in namespace 
"http://www.w3.org/2005/07/scxml"; at 
file:/srv/gump/public/workspace/apache-commons/scxml/target/test-classes/org/apache/commons/scxml/issues/issue64-02.xml:41:21
 and digester match "scxml/state/transition/datamodel"
[WARN] SCXMLParser - Ignoring element  in namespace 
"http://www.w3.org/2005/07/scxml"; at 
file:/srv/gump/public/workspace/apache-commons/scxml/target/test-classes/org/apache/commons/scxml/issues/issue64-02.xml:42:41
 and digester match "scxml/state/transition/datamodel/data"
[WARN] SCXMLParser - Ignoring element  in namespace 
"http://my.foo.example/"; at 
file:/srv/gump/public/workspace/apache-commons/scxml/target/test-classes/org/apache/commons/scxml/issues/issue64-02.xml:49:14
 and digester match "scxml/baz"
[INFO] SCXMLSemantics - null: Begin transition bug test ...
[INFO] SimpleSCXMLListener - /tranbug
[INFO] SimpleSCXMLListener - /tranbug
[INFO] SCXMLSemantics - null: null
[WARN] SimpleErrorReporter - EXPRESSION_ERROR (eval(''*' + dummy'):null): 
[INFO] SimpleSCXMLListener - transition (event = show.bug, cond = null, from = 
/tranbug, to = /end)
[INFO] SimpleSCXMLListener - /end
Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.075 sec

Results :

Failed tests: 
  testCustomActionCallbacks(org.apache.commons.scxml.model.CustomActionTest)

Tests run: 229, Failures: 1, Errors: 0, Skipped: 0

[INFO] 
[ERROR] BUILD FAILURE
[INFO] 
[INFO