[GUMP@vmgump]: Project commons-vfs2-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-vfs2-test has an issue affecting its community integration.
This issue affects 1 projects,
 and has been outstanding for 30 runs.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
- commons-vfs2-test :  Apache Commons


Full details are available at:

http://vmgump.apache.org/gump/public/apache-commons/commons-vfs2-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/vfs/gump_mvn_settings.xml]
 -DEBUG- (Apache Gump generated) Apache Maven Settings in: 
/srv/gump/public/workspace/apache-commons/vfs/gump_mvn_settings.xml
 -INFO- Failed with reason build failed
 -DEBUG- Maven POM in: /srv/gump/public/workspace/apache-commons/vfs/pom.xml
 -INFO- Project Reports in: 
/srv/gump/public/workspace/apache-commons/vfs/core/target/surefire-reports



The following work was performed:
http://vmgump.apache.org/gump/public/apache-commons/commons-vfs2-test/gump_work/build_apache-commons_commons-vfs2-test.html
Work Name: build_apache-commons_commons-vfs2-test (Type: Build)
Work ended in a state of : Failed
Elapsed: 2 mins 7 secs
Command Line: /opt/maven2/bin/mvn --batch-mode --settings 
/srv/gump/public/workspace/apache-commons/vfs/gump_mvn_settings.xml package 
[Working Directory: /srv/gump/public/workspace/apache-commons/vfs]
M2_HOME: /opt/maven2
-
Tests in error: 
  
testDefaultInstance(org.apache.commons.vfs2.test.FileSystemManagerFactoryTestCase):
 Could not create a file system manager of class 
"org.apache.commons.vfs2.impl.StandardFileSystemManager".
  org.apache.commons.vfs2.PatternFileSelectorTest: Could not create a file 
system manager of class 
"org.apache.commons.vfs2.impl.StandardFileSystemManager".
  org.apache.commons.vfs2.FileTypeSelectorTest: Could not create a file system 
manager of class "org.apache.commons.vfs2.impl.StandardFileSystemManager".
  org.apache.commons.vfs2.FileIteratorTest: Could not create a file system 
manager of class "org.apache.commons.vfs2.impl.StandardFileSystemManager".
  
junit.framework.TestSuite@c75e4fc(org.apache.commons.vfs2.test.CacheTestSuite): 
org.slf4j.spi.LocationAwareLogger.log(Lorg/slf4j/Marker;Ljava/lang/String;ILjava/lang/String;Ljava/lang/Throwable;)V
  
junit.framework.TestSuite@7e78fc6(org.apache.commons.vfs2.test.CacheTestSuite): 
org.slf4j.spi.LocationAwareLogger.log(Lorg/slf4j/Marker;Ljava/lang/String;ILjava/lang/String;Ljava/lang/Throwable;)V
  
testDelegatingBad(org.apache.commons.vfs2.util.DelegatingFileSystemOptionsBuilderTest):
 
org.slf4j.spi.LocationAwareLogger.log(Lorg/slf4j/Marker;Ljava/lang/String;ILjava/lang/String;Ljava/lang/Throwable;)V
  
testConfiguration(org.apache.commons.vfs2.util.DelegatingFileSystemOptionsBuilderTest):
 
org.slf4j.spi.LocationAwareLogger.log(Lorg/slf4j/Marker;Ljava/lang/String;ILjava/lang/String;Ljava/lang/Throwable;)V
  
testDelegatingGood(org.apache.commons.vfs2.util.DelegatingFileSystemOptionsBuilderTest):
 
org.slf4j.spi.LocationAwareLogger.log(Lorg/slf4j/Marker;Ljava/lang/String;ILjava/lang/String;Ljava/lang/Throwable;)V
  
junit.framework.TestSuite@379e8f17(org.apache.commons.vfs2.test.ProviderTestSuite):
 
org.slf4j.spi.LocationAwareLogger.log(Lorg/slf4j/Marker;Ljava/lang/String;ILjava/lang/String;Ljava/lang/Throwable;)V
  
junit.framework.TestSuite@39385660(org.apache.commons.vfs2.test.ProviderTestSuite):
 
org.slf4j.spi.LocationAwareLogger.log(Lorg/slf4j/Marker;Ljava/lang/String;ILjava/lang/String;Ljava/lang/Throwable;)V
  
junit.framework.TestSuite@44a613f8(org.apache.commons.vfs2.test.ProviderTestSuite):
 
org.slf4j.spi.LocationAwareLogger.log(Lorg/slf4j/Marker;Ljava/lang/String;ILjava/lang/String;Ljava/lang/Throwable;)V
  
junit.framework.TestSuite@40589e56(org.apache.commons.vfs2.test.ProviderTestSuite):
 
org.slf4j.spi.LocationAwareLogger.log(Lorg/slf4j/Marker;Ljava/lang/String;ILjava/lang/String;Ljava/lang/Throwable;)V
  
junit.framework.TestSuite@6c69d02b(org.apache.commons.vfs2.provider.ftp.test.FtpProviderTestCase$1):
 
org.slf4j.spi.LocationAwareLogger.log(Lorg/slf4j/Marker;Ljava/lang/String;ILjava/lang/String;Ljava/lang/Throwable;)V
  
junit.framework.TestSuite@7c0b6548(org.apache.commons.vfs2.test.ProviderTestSuite):
 
org.slf4j.spi.LocationAwareLogger.log(Lorg/slf4j/Marker;Ljava/lang/String;ILjava/lang/String;Ljava/lang/Throwable;)V
  org.apache.commons.vfs2.provider.test.FileObjectSortTestCase: Could not 
create a file system manager of class 
"org.apache.commons.vfs2.impl.StandardFileSystemManager".
  
junit.framework.TestSuite@50269997(org.apa

[GUMP@vmgump]: Project commons-id (in module commons-sandbox) 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-id has an issue affecting its community integration.
This issue affects 1 projects,
 and has been outstanding for 4 runs.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
- commons-id :  Commons Identifier Package


Full details are available at:
http://vmgump.apache.org/gump/public/commons-sandbox/commons-id/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-id-14032012.jar] identifier set to project 
name
 -DEBUG- (Apache Gump generated) Apache Maven Properties in: 
/srv/gump/public/workspace/commons-sandbox/id/build.properties
 -INFO- Failed with reason build failed
 -DEBUG- Maven POM in: /srv/gump/public/workspace/commons-sandbox/id/project.xml
 -DEBUG- Maven project properties in: 
/srv/gump/public/workspace/commons-sandbox/id/project.properties
 -INFO- Failed to extract fallback artifacts from Gump Repository



The following work was performed:
http://vmgump.apache.org/gump/public/commons-sandbox/commons-id/gump_work/build_commons-sandbox_commons-id.html
Work Name: build_commons-sandbox_commons-id (Type: Build)
Work ended in a state of : Failed
Elapsed: 24 secs
Command Line: maven --offline jar 
[Working Directory: /srv/gump/public/workspace/commons-sandbox/id]
-
[junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 0.385 sec
[junit] Running org.apache.commons.id.uuid.state.NodeTest
[junit] Tests run: 8, Failures: 0, Errors: 0, Time elapsed: 0.335 sec
[junit] Running 
org.apache.commons.id.uuid.state.ReadOnlyResourceStateImplTest
[junit] Tests run: 5, Failures: 0, Errors: 0, Time elapsed: 0.45 sec
[junit] Running org.apache.commons.id.uuid.state.ReadWriteFileStateImplTest
[junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0.453 sec
[junit] Running org.apache.commons.id.uuid.state.StateHelperTest
[junit] Tests run: 6, Failures: 0, Errors: 0, Time elapsed: 0.327 sec
[junit] Running org.apache.commons.id.uuid.state.InMemoryStateImplTest
[junit] Tests run: 5, Failures: 1, Errors: 0, Time elapsed: 0.354 sec
[junit] [ERROR] TEST org.apache.commons.id.uuid.state.InMemoryStateImplTest 
FAILED
[junit] Running org.apache.commons.id.uuid.UUIDTest
[junit] Tests run: 17, Failures: 0, Errors: 0, Time elapsed: 0.272 sec
[junit] Running org.apache.commons.id.uuid.NodeManagerImplTest
[junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0.442 sec
[junit] Running org.apache.commons.id.uuid.task.UUIDTaskTest
[junit] Tests run: 5, Failures: 0, Errors: 0, Time elapsed: 0.543 sec
[junit] Running org.apache.commons.id.uuid.clock.ThreadClockImplTest
[junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 0.259 sec
[junit] Running org.apache.commons.id.uuid.clock.SystemClockImplTest
[junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 0.26 sec
[junit] Running org.apache.commons.id.serial.AlphanumericGeneratorTest
[junit] Tests run: 9, Failures: 0, Errors: 0, Time elapsed: 0.275 sec
[junit] Running org.apache.commons.id.serial.LongGeneratorTest
[junit] Tests run: 8, Failures: 0, Errors: 0, Time elapsed: 0.281 sec
[junit] Running org.apache.commons.id.serial.PrefixedNumericGeneratorTest
[junit] Tests run: 4, Failures: 0, Errors: 0, Time elapsed: 0.284 sec
[junit] Running org.apache.commons.id.serial.NumericGeneratorTest
[junit] Tests run: 8, Failures: 0, Errors: 0, Time elapsed: 0.266 sec
[junit] Running 
org.apache.commons.id.serial.PrefixedLeftPaddedNumericGeneratorTest
[junit] Tests run: 4, Failures: 0, Errors: 0, Time elapsed: 0.263 sec
[junit] Running 
org.apache.commons.id.serial.PrefixedAlphanumericGeneratorTest
[junit] Tests run: 4, Failures: 0, Errors: 0, Time elapsed: 0.262 sec
[junit] Running 
org.apache.commons.id.serial.TimeBasedAlphanumericIdentifierGeneratorTest
[junit] Tests run: 12, Failures: 0, Errors: 0, Time elapsed: 0.742 sec
[junit] Running org.apache.commons.id.CompositeIdentifierGeneratorTest
[junit] Tests run: 7, Failures: 0, Errors: 0, Time elapsed: 0.268 sec
[junit] Running org.apache.commons.id.ConstantIdentifierGeneratorTest
[junit] Tests run: 6, Failures: 0, Errors: 0, Time elapsed: 0.257 sec

BUILD FAILED
File.. /home/gump/.maven/cache/maven-test-plugin-1.6.2/plugin.jelly
Element... fail
Line.. 181
Column 54
There were test failures.
Total time: 24 seconds
Finished at: Wed Mar 14 06:41:04 UTC 2012

-

To subscribe to this information via syndicate

[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 30 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: 11 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
-
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.003 sec
Running org.apache.commons.proxy.factory.util.TestMethodSignature
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.002 sec
Running org.apache.commons.proxy.provider.TestConstantProvider
Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.003 sec
Running org.apache.commons.proxy.interceptor.TestFilteredInterceptor
Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.033 sec
Running org.apache.commons.proxy.interceptor.filter.TestPatternFilter
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.003 sec
Running org.apache.commons.proxy.interceptor.TestSerializingInterceptor
Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.035 sec
Running org.apache.commons.proxy.interceptor.TestInterceptorChain
Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.004 sec
Running org.apache.commons.proxy.invoker.TestNullInvoker
Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.014 sec
Running org.apache.commons.proxy.provider.remoting.TestBurlapProvider
Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.011 sec
Running org.apache.commons.proxy.exception.TestDelegateProviderException
Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.003 sec
Running org.apache.commons.proxy.invoker.TestChainInvoker
Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.013 sec
Running org.apache.commons.proxy.factory.javassist.TestJavassistProxyFactory
Tests run: 37, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.192 sec
Running org.apache.commons.proxy.exception.TestProxyFactoryException
Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.01 sec
Running org.apache.commons.proxy.interceptor.filter.TestReturnTypeFilter
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.002 sec
Running org.apache.commons.proxy.provider.TestBeanProvider
Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.008 sec

Results :

Tests in error: 
  testInvalidHandlerName(org.apache.commons.proxy.invoker.TestXmlRpcInvoker)

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

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

Please refer to 
/srv/gump/public/workspace/apache-commons/proxy/target/surefire-reports for the 
individual test results.
[INFO] 
[INFO] For more information, run Maven with the -e switch
[INFO] 
[INFO] Total time: 10 seconds
[INFO] Finished at: Wed Mar 14 06:23:12 UTC 2012
[INFO] Final Memory: 24M/58M
[INFO] 
-

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

[GUMP@vmgump]: Project commons-configuration-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-configuration-test has an issue affecting its community 
integration.
This issue affects 1 projects,
 and has been outstanding for 43 runs.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
- commons-configuration-test :  Apache Commons


Full details are available at:

http://vmgump.apache.org/gump/public/apache-commons/commons-configuration-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/configuration/gump_mvn_settings.xml]
 -DEBUG- (Apache Gump generated) Apache Maven Settings in: 
/srv/gump/public/workspace/apache-commons/configuration/gump_mvn_settings.xml
 -INFO- Failed with reason build failed
 -DEBUG- Maven POM in: 
/srv/gump/public/workspace/apache-commons/configuration/pom.xml
 -INFO- Project Reports in: 
/srv/gump/public/workspace/apache-commons/configuration/target/surefire-reports



The following work was performed:
http://vmgump.apache.org/gump/public/apache-commons/commons-configuration-test/gump_work/build_apache-commons_commons-configuration-test.html
Work Name: build_apache-commons_commons-configuration-test (Type: Build)
Work ended in a state of : Failed
Elapsed: 1 min 45 secs
Command Line: /opt/maven2/bin/mvn --batch-mode --settings 
/srv/gump/public/workspace/apache-commons/configuration/gump_mvn_settings.xml 
test 
[Working Directory: /srv/gump/public/workspace/apache-commons/configuration]
M2_HOME: /opt/maven2
-
Running org.apache.commons.configuration.TestHierarchicalConfigurationXMLReader
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.009 sec
Running org.apache.commons.configuration.TestNullCompositeConfiguration
Tests run: 23, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.178 sec
Running org.apache.commons.configuration.interpol.TestConfigurationInterpolator
Tests run: 22, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.03 sec
Running org.apache.commons.configuration.interpol.TestEnvironmentLookup
Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.007 sec
Running org.apache.commons.configuration.interpol.TestExprLookup
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.029 sec
Running org.apache.commons.configuration.interpol.TestConstantLookup
Tests run: 8, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.007 sec
Running org.apache.commons.configuration.TestPropertiesConfigurationLayout
Tests run: 38, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.055 sec
Running org.apache.commons.configuration.TestConfigurationConverter
Tests run: 6, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.028 sec
Running org.apache.commons.configuration.TestFileConfiguration
Tests run: 31, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 1.047 sec
Running org.apache.commons.configuration.TestPatternSubtreeConfiguration
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.009 sec
Running org.apache.commons.configuration.TestPropertyConverter
Tests run: 28, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.022 sec
Running org.apache.commons.configuration.TestConfigurationMap
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.001 sec
Running org.apache.commons.configuration.reloading.TestManagedReloadingStrategy
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.013 sec
Running 
org.apache.commons.configuration.reloading.TestVFSFileChangedReloadingStrategy
Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 4.013 sec
Running 
org.apache.commons.configuration.reloading.TestFileChangedReloadingStrategy
Tests run: 7, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 5.966 sec

Results :

Failed tests:   
testValidation2(org.apache.commons.configuration.TestVFSConfigurationBuilder): 
The test key was not located

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

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

Please refer to 
/srv/gump/public/workspace/apache-commons/configuration/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 43 seconds
[INFO] Finished at: Wed Mar 14 06:21:20 UTC 2012
[INFO] Final Memor

[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 43 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: 21 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.169 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.078 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]

[GUMP@vmgump]: Project commons-collections4-testframework (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-collections4-testframework has an issue affecting its community 
integration.
This issue affects 1 projects.
The current state of this project is 'Failed', with reason 'Missing Build 
Outputs'.
For reference only, the following projects are affected by this:
- commons-collections4-testframework :  Apache Commons


Full details are available at:

http://vmgump.apache.org/gump/public/apache-commons/commons-collections4-testframework/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-collections-testframework-*[0-9T].jar] 
identifier set to project name
 -INFO- Failed with reason missing build outputs
 -ERROR- Missing Output: 
/srv/gump/public/workspace/apache-commons/collections/target/commons-collections-testframework-*[0-9T].jar
 -ERROR- See Directory Listing Work for Missing Outputs
 -INFO- Failed to extract fallback artifacts from Gump Repository

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

== Gump Tracking Only ===
Produced by Apache Gump(TM) version 2.3.
Gump Run 1214032012, vmgump.apache.org:vmgump:1214032012
Gump E-mail Identifier (unique within run) #19.

--
Apache Gump
http://gump.apache.org/ [Instance: vmgump]

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

[GUMP@vmgump]: Project commons-exec-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-exec-test has an issue affecting its community integration.
This issue affects 1 projects.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
- commons-exec-test :  Apache Commons


Full details are available at:

http://vmgump.apache.org/gump/public/apache-commons/commons-exec-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/exec/gump_mvn_settings.xml]
 -DEBUG- (Apache Gump generated) Apache Maven Settings in: 
/srv/gump/public/workspace/apache-commons/exec/gump_mvn_settings.xml
 -INFO- Failed with reason build failed
 -DEBUG- Maven POM in: /srv/gump/public/workspace/apache-commons/exec/pom.xml
 -INFO- Project Reports in: 
/srv/gump/public/workspace/apache-commons/exec/target/surefire-reports



The following work was performed:
http://vmgump.apache.org/gump/public/apache-commons/commons-exec-test/gump_work/build_apache-commons_commons-exec-test.html
Work Name: build_apache-commons_commons-exec-test (Type: Build)
Work ended in a state of : Failed
Elapsed: 1 min 25 secs
Command Line: /opt/maven2/bin/mvn --batch-mode --settings 
/srv/gump/public/workspace/apache-commons/exec/gump_mvn_settings.xml test 
[Working Directory: /srv/gump/public/workspace/apache-commons/exec]
M2_HOME: /opt/maven2
-
FOO..
org.apache.commons.exec.ExecuteException: Process exited with an error: 143 
(Exit value: 143)
Process completed in 2080 millis; below is its output
Process timed out and was killed.
Executing [sh, -c, src/test/scripts/invoker.sh]
invoker.sh -- going to start daemon process
invoker.sh --  daemon process was started
cd: 21: can't cd to ../../../target
Process completed in 8027 millis; above is its output
0: process has terminated: false
1: process has terminated: false
2: process has terminated: false
3: process has terminated: false
4: process has terminated: false
5: process has terminated: false
Preparing to execute process - commandLine=[/bin/ls, /opt]
Process spun off successfully - process=/bin/ls
PING 127.0.0.1 (127.0.0.1) 56(84) bytes of data.
64 bytes from 127.0.0.1: icmp_seq=1 ttl=64 time=0.021 ms
64 bytes from 127.0.0.1: icmp_seq=2 ttl=64 time=0.024 ms
64 bytes from 127.0.0.1: icmp_seq=3 ttl=64 time=0.025 ms
Process completed in 2004 millis; below is its output
Process timed out and was killed by watchdog.
gdal_translate
HDF5:"/home/kk/grass/data/4404.he5"://HDFEOS/GRIDS/OMI_Column_Amount_O3/Data_Fields/ColumnAmountO3/home/kk/4.tif
FOO..
Preparing to execute process - commandLine=[/bin/ls, /opt]
Process spun off successfully - process=/bin/ls
Tests run: 40, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 72.898 sec <<< 
FAILURE!

Results :

Failed tests: 
  testExec_60(org.apache.commons.exec.DefaultExecutorTest)

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

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

Please refer to 
/srv/gump/public/workspace/apache-commons/exec/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 24 seconds
[INFO] Finished at: Wed Mar 14 02:43:36 UTC 2012
[INFO] Final Memory: 25M/65M
[INFO] 
-

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

== Gump Tracking Only ===
Produced by Apache Gump(TM) version 2.3.
Gump Run 1214032012, vmgump.apache.org:vmgump:1214032012
Gump E-mail Identifier (unique within run) #15.

--
Apache Gump
http://gump.apache.org/ [Instance: vmgump]

-
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 62 runs.
The current state of this project is 'Failed', with reason 'Missing Build 
Outputs'.
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
 -DEBUG- Maven POM in: 
/srv/gump/public/workspace/apache-commons/digester/pom.xml
 -INFO- Failed with reason missing build outputs
 -ERROR- Missing Output: 
/srv/gump/public/workspace/apache-commons/digester/target/commons-digester3-*[0-9T].jar
 -ERROR- See Directory Listing Work for Missing Outputs
 -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 : Success
Elapsed: 2 mins 26 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
-
Downloading: 
http://localhost:8192/maven2/org/codehaus/plexus/plexus-archiver/1.1/plexus-archiver-1.1.pom

Downloading: 
http://localhost:8192/maven2/org/apache/maven/shared/maven-shared-io/1.1/maven-shared-io-1.1.pom

Downloading: 
http://localhost:8192/maven2/org/apache/maven/shared/maven-repository-builder/1.0-alpha-2/maven-repository-builder-1.0-alpha-2.pom

Downloading: 
http://localhost:8192/maven2/org/apache/maven/shared/maven-common-artifact-filters/1.0-alpha-1/maven-common-artifact-filters-1.0-alpha-1.pom

Downloading: 
http://localhost:8192/maven2/org/apache/maven/shared/maven-shared-components/6/maven-shared-components-6.pom

Downloading: 
http://localhost:8192/maven2/org/codehaus/plexus/plexus-archiver/1.1/plexus-archiver-1.1.jar
Downloading: 
http://localhost:8192/maven2/org/apache/maven/shared/maven-shared-io/1.1/maven-shared-io-1.1.jar

Downloading: 
http://localhost:8192/maven2/org/apache/maven/shared/maven-repository-builder/1.0-alpha-2/maven-repository-builder-1.0-alpha-2.jar


[INFO] [assembly:single {execution: default}]
[INFO] Reading assembly descriptor: 
/srv/gump/public/workspace/apache-commons/digester/dist/src/main/assembly/bin.xml
[INFO] Reading assembly descriptor: 
/srv/gump/public/workspace/apache-commons/digester/dist/src/main/assembly/src.xml
[INFO] Building tar : 
/srv/gump/public/workspace/apache-commons/digester/dist/target/commons-digester3-3.3-SNAPSHOT-bin.tar.gz
[INFO] Building zip: 
/srv/gump/public/workspace/apache-commons/digester/dist/target/commons-digester3-3.3-SNAPSHOT-bin.zip
[INFO] Building tar : 
/srv/gump/public/workspace/apache-commons/digester/dist/target/commons-digester3-3.3-SNAPSHOT-src.tar.gz
[INFO] Building zip: 
/srv/gump/public/workspace/apache-commons/digester/dist/target/commons-digester3-3.3-SNAPSHOT-src.zip
[INFO] 
[INFO] 
[INFO] 
[INFO] Reactor Summary:
[INFO] 
[INFO] Apache Commons Digester ... SUCCESS [9.994s]
[INFO] Apache Commons Digester :: Core ... SUCCESS [31.365s]
[INFO] Apache Commons Digester :: Annotations Processor .. SUCCESS [2.599s]
[INFO] Commons Digester :: Examples .. SUCCESS [0.543s]
[INFO] Apache Commons Digester :: Examples :: Annotations :: Atom  SUCCESS 
[3.116s]
[INFO] Apache Commons Digester :: Examples :: API :: Address Book  SUCCESS 
[2.456s]
[INFO] Apache Commons Digester :: Examples :: API :: Catalog . SUCCESS [1.952s]
[INFO] Apache Commons Digester :: Examples :: API :: DB Insert  SUCCESS [2.164s]
[INFO] Apache Commons Digester :: Examples :: API :: Document Markup  SUCCESS 
[1.703s]
[INFO] Apache Commons Digester :: Examples :: EDSL :: Atom ... SUCCESS [1.986s]
[INFO] Apache Commons Digester :: Examples :: Plugins :: Pipeline  SUCCESS 
[1.638s]
[INFO] Apache Commons Digester :: Exam

Re: svn commit: r1300429 - in /commons/proper/commons-parent/trunk: pom.xml src/changes/changes.xml

[sebb]

On 14 March 2012 01:17, Gary Gregory  wrote:
> Here is what we have in [io] now:
>
>        
>          ${basedir}/src/changes/changes.xml
>          %URL%/%ISSUE%
>          Fix
> Version,Key,Component,Summary,Type,Resolution,Status
>          
>          Key DESC,Type,Fix Version DESC
>          Fixed
>          Resolved,Closed
>          
>          Bug,New Feature,Task,Improvement,Wish,Test
>          300
>        
>
> I would be nice to use properties for maxEntries so the whole config does
> not have to be repeated.
>
> Thoughts?

Try it and see whether that works.

> Gary
>
> On Tue, Mar 13, 2012 at 8:43 PM,  wrote:
>
>> Author: sebb
>> Date: Wed Mar 14 00:43:23 2012
>> New Revision: 1300429
>>
>> URL: http://svn.apache.org/viewvc?rev=1300429&view=rev
>> Log:
>> Add changes and Jira reports
>>
>> Modified:
>>    commons/proper/commons-parent/trunk/pom.xml
>>    commons/proper/commons-parent/trunk/src/changes/changes.xml
>>
>> Modified: commons/proper/commons-parent/trunk/pom.xml
>> URL:
>> http://svn.apache.org/viewvc/commons/proper/commons-parent/trunk/pom.xml?rev=1300429&r1=1300428&r2=1300429&view=diff
>>
>> ==
>> --- commons/proper/commons-parent/trunk/pom.xml (original)
>> +++ commons/proper/commons-parent/trunk/pom.xml Wed Mar 14 00:43:23 2012
>> @@ -39,6 +39,7 @@ Version 25:
>>   Updated various plugin versions:
>>     clirr-maven-plugin: 2.3 => 2.4;
>>     clirr & RAT added to pluginManagement so can override the version from
>> Apache POM
>> +    Add changes and jira reports
>>
>>  For full details see:
>>
>> http://svn.apache.org/repos/asf/commons/proper/commons-parent/tags/commons-parent-25/RELEASE-NOTES.txt
>> @@ -471,6 +472,29 @@ http://svn.apache.org/repos/asf/commons/
>>       
>>       
>>         org.apache.maven.plugins
>> +        maven-changes-plugin
>> +        ${commons.changes.version}
>> +        
>> +          ${basedir}/src/changes/changes.xml
>> +          Fix
>> Version,Key,Component,Summary,Type,Resolution,Status
>> +          
>> +          Key DESC,Type,Fix Version
>> DESC
>> +          Fixed
>> +          Resolved,Closed
>> +          
>> +          Bug,New Feature,Task,Improvement,Wish,Test
>> +        
>> +        
>> +          
>> +            
>> +              changes-report
>> +              jira-report
>> +            
>> +          
>> +        
>> +      
>> +      
>> +        org.apache.maven.plugins
>>         maven-javadoc-plugin
>>         ${commons.javadoc.version}
>>         
>>
>> Modified: commons/proper/commons-parent/trunk/src/changes/changes.xml
>> URL:
>> http://svn.apache.org/viewvc/commons/proper/commons-parent/trunk/src/changes/changes.xml?rev=1300429&r1=1300428&r2=1300429&view=diff
>>
>> ==
>> --- commons/proper/commons-parent/trunk/src/changes/changes.xml (original)
>> +++ commons/proper/commons-parent/trunk/src/changes/changes.xml Wed Mar 14
>> 00:43:23 2012
>> @@ -59,8 +59,9 @@ The  type attribute can be add,u
>>         
>>             
>>             Updated various plugin versions:
>> -            clirr-maven-plugin: 2.3 => 2.4
>> -            clirr & RAT added to pluginManagement so can override the
>> version from Apache POM
>> +            clirr-maven-plugin: 2.3 => 2.4
>> +            clirr & RAT added to pluginManagement so can override the
>> version from Apache POM
>> +            Add changes and jira reports
>>             
>>         
>>         
>>
>>
>>
>
>
> --
> 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

Re: svn commit: r1300429 - in /commons/proper/commons-parent/trunk: pom.xml src/changes/changes.xml

[Gary Gregory]

Here is what we have in [io] now:


  ${basedir}/src/changes/changes.xml
  %URL%/%ISSUE%
  Fix
Version,Key,Component,Summary,Type,Resolution,Status
  
  Key DESC,Type,Fix Version DESC
  Fixed
  Resolved,Closed
  
  Bug,New Feature,Task,Improvement,Wish,Test
  300


I would be nice to use properties for maxEntries so the whole config does
not have to be repeated.

Thoughts?

Gary

On Tue, Mar 13, 2012 at 8:43 PM,  wrote:

> Author: sebb
> Date: Wed Mar 14 00:43:23 2012
> New Revision: 1300429
>
> URL: http://svn.apache.org/viewvc?rev=1300429&view=rev
> Log:
> Add changes and Jira reports
>
> Modified:
>commons/proper/commons-parent/trunk/pom.xml
>commons/proper/commons-parent/trunk/src/changes/changes.xml
>
> Modified: commons/proper/commons-parent/trunk/pom.xml
> URL:
> http://svn.apache.org/viewvc/commons/proper/commons-parent/trunk/pom.xml?rev=1300429&r1=1300428&r2=1300429&view=diff
>
> ==
> --- commons/proper/commons-parent/trunk/pom.xml (original)
> +++ commons/proper/commons-parent/trunk/pom.xml Wed Mar 14 00:43:23 2012
> @@ -39,6 +39,7 @@ Version 25:
>   Updated various plugin versions:
> clirr-maven-plugin: 2.3 => 2.4;
> clirr & RAT added to pluginManagement so can override the version from
> Apache POM
> +Add changes and jira reports
>
>  For full details see:
>
> http://svn.apache.org/repos/asf/commons/proper/commons-parent/tags/commons-parent-25/RELEASE-NOTES.txt
> @@ -471,6 +472,29 @@ http://svn.apache.org/repos/asf/commons/
>   
>   
> org.apache.maven.plugins
> +maven-changes-plugin
> +${commons.changes.version}
> +
> +  ${basedir}/src/changes/changes.xml
> +  Fix
> Version,Key,Component,Summary,Type,Resolution,Status
> +  
> +  Key DESC,Type,Fix Version
> DESC
> +  Fixed
> +  Resolved,Closed
> +  
> +  Bug,New Feature,Task,Improvement,Wish,Test
> +
> +
> +  
> +
> +  changes-report
> +  jira-report
> +
> +  
> +
> +  
> +  
> +org.apache.maven.plugins
> maven-javadoc-plugin
> ${commons.javadoc.version}
> 
>
> Modified: commons/proper/commons-parent/trunk/src/changes/changes.xml
> URL:
> http://svn.apache.org/viewvc/commons/proper/commons-parent/trunk/src/changes/changes.xml?rev=1300429&r1=1300428&r2=1300429&view=diff
>
> ==
> --- commons/proper/commons-parent/trunk/src/changes/changes.xml (original)
> +++ commons/proper/commons-parent/trunk/src/changes/changes.xml Wed Mar 14
> 00:43:23 2012
> @@ -59,8 +59,9 @@ The  type attribute can be add,u
> 
> 
> Updated various plugin versions:
> -clirr-maven-plugin: 2.3 => 2.4
> -clirr & RAT added to pluginManagement so can override the
> version from Apache POM
> +clirr-maven-plugin: 2.3 => 2.4
> +clirr & RAT added to pluginManagement so can override the
> version from Apache POM
> +Add changes and jira reports
> 
> 
> 
>
>
>


-- 
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: [lang] Longest common substring / Suffix Tree

[James Carman]

It would have come in handy for me while doing bioinformatics work in the
past.  But, you're right, they have very cool tools out there.  I was
amazed at some of the stuff they can do.
On Mar 13, 2012 7:08 PM, "Thomas Neidhart" 
wrote:

> On 03/13/2012 08:55 AM, Luc Maisonobe wrote:
> > Le 13/03/2012 00:53, James Carman a écrit :
> >> A lot of bioinformaticians would love us if we added this!
>
> I picked this topic up as I find it interesting to myself and it would
> be a useful addition for many other people too I guess, but from what I
> have seen so far, bioinformaticians wouldn't be necessarily impressed by
> that ;-). Afaik they have pretty good tools, and there exist special
> algorithms to compute suffix trees for really large strings in clusters
> or on disk as they wont fit in memory anymore.
>
> > In the same spirit, I know an implementation of the Myers difference
> > algorithm that runs on any object implementing equals and also provides
> > an API for browsing the "edit script" resulting from the comparison.
> > This allows for example to retrieve only the shared elements, or only
> > the ones in the first or the second sequence, or "running" the script,
> > or whatever.
> >
> > If you consider this could be a good addition to [lang] or another
> > component ([graph] ?) I can ask for a grant for this.
>
> this would be a perfect companion for the longest common substring
> problem, the o.a.c.l.text package looks like a good fit for these things
> imho.
>
> Thomas
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: [lang] Longest common substring / Suffix Tree

[Thomas Neidhart]

On 03/13/2012 08:55 AM, Luc Maisonobe wrote:
> Le 13/03/2012 00:53, James Carman a écrit :
>> A lot of bioinformaticians would love us if we added this!

I picked this topic up as I find it interesting to myself and it would
be a useful addition for many other people too I guess, but from what I
have seen so far, bioinformaticians wouldn't be necessarily impressed by
that ;-). Afaik they have pretty good tools, and there exist special
algorithms to compute suffix trees for really large strings in clusters
or on disk as they wont fit in memory anymore.

> In the same spirit, I know an implementation of the Myers difference
> algorithm that runs on any object implementing equals and also provides
> an API for browsing the "edit script" resulting from the comparison.
> This allows for example to retrieve only the shared elements, or only
> the ones in the first or the second sequence, or "running" the script,
> or whatever.
> 
> If you consider this could be a good addition to [lang] or another
> component ([graph] ?) I can ask for a grant for this.

this would be a perfect companion for the longest common substring
problem, the o.a.c.l.text package looks like a good fit for these things
imho.

Thomas

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

Re: svn commit: r1300298 - in /commons/proper/io/trunk/src/site: site.xml xdoc/index.xml xdoc/upgradeto2_2.xml

[sebb]

On 13 March 2012 19:29,   wrote:
> Author: ggregory
> Date: Tue Mar 13 19:29:16 2012
> New Revision: 1300298
>
> URL: http://svn.apache.org/viewvc?rev=1300298&view=rev
> Log:
> Preparing 2.2 release.
>
> Added:
>    commons/proper/io/trunk/src/site/xdoc/upgradeto2_2.xml
> Modified:
>    commons/proper/io/trunk/src/site/site.xml
>    commons/proper/io/trunk/src/site/xdoc/index.xml
>
> Modified: commons/proper/io/trunk/src/site/site.xml
> URL: 
> http://svn.apache.org/viewvc/commons/proper/io/trunk/src/site/site.xml?rev=1300298&r1=1300297&r2=1300298&view=diff
> ==
> --- commons/proper/io/trunk/src/site/site.xml (original)
> +++ commons/proper/io/trunk/src/site/site.xml Tue Mar 13 19:29:16 2012
> @@ -24,14 +24,15 @@
>
>     
>         
> -            
> -             href="http://commons.apache.org/io/download_io.cgi"/>
> -            
> -             href="/bestpractices.html"/>
> -             href="api-release/index.html"/>
> -             href="api-2.0.1/index.html"/>
> -            
> -            
> +            
> +             href="http://commons.apache.org/io/download_io.cgi"/>
> +            
> +            
> +            
> +            
> +            
> +            

Surely 2.0/2.0.1 could be dropped now?

> +            
>         
>

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

Re: [io] Help with CharSequenceInputStream [WAS: [GUMP@vmgump]: Project commons-io-test (in module apache-commons) failed]

[sebb]

On 13 March 2012 18:17, Gary Gregory  wrote:
> On Tue, Mar 13, 2012 at 12:27 PM, sebb  wrote:
>
>> On 13 March 2012 13:23, Gary Gregory  wrote:
>> > Hello All,
>> >
>> > Can the author/committer of CharSequenceInputStream[Test] take a look at
>> > why Gump is failing?
>>
>> Seems to be intermittent.
>>
>> I've added a bit more debug which I hope will help next time.
>>
>
> I initially thought that the issue was that UTF-8 bytes where compared
> against the default platform encoding but that would happen all the time
> not some of the time...

It was the random generator used to generate the offset and length
values for testing.

The code was not handling length == 0 properly.

> Gary
>
>>
>> > Thank you,
>> > Gary
>> >
>> > On Mon, Mar 12, 2012 at 10:04 PM, Gump 
>> wrote:
>> >
>> >> 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 11 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 34 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.104
>> sec
>> >> Running org.apache.commons.io.comparator.DefaultFileComparatorTest
>> >> Tests run: 7, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.085
>> sec
>> >> Running org.apache.commons.io.comparator.DirectoryFileComparatorTest
>> >> Tests run: 7, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.101
>> sec
>> >> Running org.apache.commons.io.comparator.ExtensionFileComparatorTest
>> >> Tests run: 8, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.087
>> sec
>> >> Running org.apache.commons.io.comparator.PathFileComparatorTest
>> >> Tests run: 8, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.09 sec
>> >> Running org.apache.commons.io.comparator.NameFileComparatorTest
>> >> Tests run: 8, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.086
>> sec
>> >> Running org.apache.commons.io.IOUtilsTestCase
>> >> Tests run: 41, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.398
>> sec
>> >> Running org.apache.commons.io.IOCaseTestCase
>> >> Tests run: 17, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.094
>> sec
>> >> Running org.apache.commons.io.LineIteratorTestCase
>> >> Tests run: 16, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.251
>> sec
>> >> Running org.apache.commons.io.FileUtilsCleanDirectoryTestCase
>> >> Tests run: 5, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.133
>> sec
>> >> Running org.apache.commons.io.IOUtilsWriteTestCase
>> >> Tests run: 53, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.288
>> sec
>> >> Running org.apache.commons.io.FilenameUtilsWildcardTestCase
>> >> Tests run: 7, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.122
>> sec
>> >> Running org.apache.commons.io.FileUtilsListFilesTestCase
>> >> Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.103
>> sec
>> >> Running org.apache.commons.io.FileSystemUtilsTestCase
>> >> Tests run: 28, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.266
>> sec
>> >> Running org.apache.commons.io.DirectoryWalkerTestCaseJava4
>> >> Tests run: 14, Failure

Re: [io] Help with CharSequenceInputStream [WAS: [GUMP@vmgump]: Project commons-io-test (in module apache-commons) failed]

[Gary Gregory]

On Tue, Mar 13, 2012 at 12:27 PM, sebb  wrote:

> On 13 March 2012 13:23, Gary Gregory  wrote:
> > Hello All,
> >
> > Can the author/committer of CharSequenceInputStream[Test] take a look at
> > why Gump is failing?
>
> Seems to be intermittent.
>
> I've added a bit more debug which I hope will help next time.
>

I initially thought that the issue was that UTF-8 bytes where compared
against the default platform encoding but that would happen all the time
not some of the time...

Gary

>
> > Thank you,
> > Gary
> >
> > On Mon, Mar 12, 2012 at 10:04 PM, Gump 
> wrote:
> >
> >> 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 11 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 34 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.104
> sec
> >> Running org.apache.commons.io.comparator.DefaultFileComparatorTest
> >> Tests run: 7, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.085
> sec
> >> Running org.apache.commons.io.comparator.DirectoryFileComparatorTest
> >> Tests run: 7, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.101
> sec
> >> Running org.apache.commons.io.comparator.ExtensionFileComparatorTest
> >> Tests run: 8, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.087
> sec
> >> Running org.apache.commons.io.comparator.PathFileComparatorTest
> >> Tests run: 8, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.09 sec
> >> Running org.apache.commons.io.comparator.NameFileComparatorTest
> >> Tests run: 8, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.086
> sec
> >> Running org.apache.commons.io.IOUtilsTestCase
> >> Tests run: 41, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.398
> sec
> >> Running org.apache.commons.io.IOCaseTestCase
> >> Tests run: 17, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.094
> sec
> >> Running org.apache.commons.io.LineIteratorTestCase
> >> Tests run: 16, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.251
> sec
> >> Running org.apache.commons.io.FileUtilsCleanDirectoryTestCase
> >> Tests run: 5, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.133
> sec
> >> Running org.apache.commons.io.IOUtilsWriteTestCase
> >> Tests run: 53, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.288
> sec
> >> Running org.apache.commons.io.FilenameUtilsWildcardTestCase
> >> Tests run: 7, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.122
> sec
> >> Running org.apache.commons.io.FileUtilsListFilesTestCase
> >> Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.103
> sec
> >> Running org.apache.commons.io.FileSystemUtilsTestCase
> >> Tests run: 28, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.266
> sec
> >> Running org.apache.commons.io.DirectoryWalkerTestCaseJava4
> >> Tests run: 14, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.179
> sec
> >>
> >> Results :
> >>
> >> Failed tests:
> >>
> testLargeUTF8WithBufferedRead(org.apache.commons.io.input.CharSequenceInputStreamTest):
> >> expected:<4733> but was:<4800>
> >>
> >> Tests run: 904, Failures: 1, Errors: 0, Skipped: 0
> >>
> >> [IN

Re: [ALL] Commons Parent reports

[Gary Gregory]

On Mar 13, 2012, at 14:05, sebb  wrote:

> On 13 March 2012 17:59, Gary Gregory  wrote:
>> On Mar 13, 2012, at 12:40, Gilles Sadowski  
>> wrote:
>>
>>> Hi.
>>>
>
>>> [...]
>>>
>>> The tools are there, but you have to tell people that they _must_ use 
>>> them.
>>
>> Commons has already enough rules and process. As long as the releases
>> are have clean code I wouldn't be too anal about the commits in
>> between.
>
> I think that the main disagreement is here. Source code must be a clear 
> read
> for the _developers_. To put it bluntly, I don't care that the releases 
> have
> cleanly formatted code, as almost nobody is going to read those packaged
> sources!
>>
>> And another thing: the formatting /is/ important in released sources
>> because, again, this is what most users will see in their debuggers.
>> Have you seen some of the JRE sources? Some files are a mess, others
>> have blank lines in the middle of headers. Others look like they were
>> entered by a prisoner blinded in the noon day sun after spending a
>> month in the hole with bread and water ration and then given a stick
>> of butter for lunch.
>
> No, that was a 'tab' of butter (which then sometimes got stuck into the 
> source).

Darn, I should have checkstyled my message!

Gary

>
>> Gary
>>

 Nobody objects using Checkstyle. Personally I object a default
 Checkstyle config, which everybody must override. Nearly every
 components has specifics, so everybody MUST override. What if you
 don't want to use Checkstyle? Can you disable it?
 What, if you use Sun conventions and Maven conventions are the
 default? Much work! Please leave the checkstyle question to where it
 belongs, and this is not parent pom, but the individual component.

 And thats what I meant with: as long as we don't have a common
 codestyle, i does not make much sense to have a common checkstyle
 configuration.
>>>
>>> I thought that the question was whether to generate a CheckStyle report, not
>>> whether the configuration should be the same...
>>>
 Secondly, I have not had the feeling in the past years that checkstyle
 helped me so much (including non open source projects). And so far, my
 code was readable.
>>>
>>> My code is also readable...
>>>
>>> I forgot to mention earlier in this thread that a code formatter will not
>>> detect missing comments; I've also seen that some people using IDE let the
>>> software generate totally useless "place-holder" Javadoc comments. Hence
>>> no tool can afterwards detect that documentation is missing.
>>>
>>>
>>> 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
>>
>
> -
> 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: [ALL] Commons Parent reports

[sebb]

On 13 March 2012 17:59, Gary Gregory  wrote:
> On Mar 13, 2012, at 12:40, Gilles Sadowski  
> wrote:
>
>> Hi.
>>

>> [...]
>>
>> The tools are there, but you have to tell people that they _must_ use 
>> them.
>
> Commons has already enough rules and process. As long as the releases
> are have clean code I wouldn't be too anal about the commits in
> between.

 I think that the main disagreement is here. Source code must be a clear 
 read
 for the _developers_. To put it bluntly, I don't care that the releases 
 have
 cleanly formatted code, as almost nobody is going to read those packaged
 sources!
>
> And another thing: the formatting /is/ important in released sources
> because, again, this is what most users will see in their debuggers.
> Have you seen some of the JRE sources? Some files are a mess, others
> have blank lines in the middle of headers. Others look like they were
> entered by a prisoner blinded in the noon day sun after spending a
> month in the hole with bread and water ration and then given a stick
> of butter for lunch.

No, that was a 'tab' of butter (which then sometimes got stuck into the source).

> Gary
>
>>>
>>> Nobody objects using Checkstyle. Personally I object a default
>>> Checkstyle config, which everybody must override. Nearly every
>>> components has specifics, so everybody MUST override. What if you
>>> don't want to use Checkstyle? Can you disable it?
>>> What, if you use Sun conventions and Maven conventions are the
>>> default? Much work! Please leave the checkstyle question to where it
>>> belongs, and this is not parent pom, but the individual component.
>>>
>>> And thats what I meant with: as long as we don't have a common
>>> codestyle, i does not make much sense to have a common checkstyle
>>> configuration.
>>
>> I thought that the question was whether to generate a CheckStyle report, not
>> whether the configuration should be the same...
>>
>>> Secondly, I have not had the feeling in the past years that checkstyle
>>> helped me so much (including non open source projects). And so far, my
>>> code was readable.
>>
>> My code is also readable...
>>
>> I forgot to mention earlier in this thread that a code formatter will not
>> detect missing comments; I've also seen that some people using IDE let the
>> software generate totally useless "place-holder" Javadoc comments. Hence
>> no tool can afterwards detect that documentation is missing.
>>
>>
>> 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
>

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

Re: [ALL] Commons Parent reports

[Honton, Charles]

When I'm researching competing open-source implementations, I use reports
as part of my evaluation.  The ones that are important to me are:

Javadoc
Findbugs
Surefire
Failsafe
Cobertura

If I'm evaluating an upgrade, I'll look at:

Changes
Clirr


Chas Honton


>Le 13/03/2012 17:52, Gilles Sadowski a écrit :
>
> What about the "Useful for the developer" category?


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

Re: [ALL] Commons Parent reports

[Gary Gregory]

On Mar 13, 2012, at 12:40, Gilles Sadowski  wrote:

> Hi.
>
>>>
> [...]
>
> The tools are there, but you have to tell people that they _must_ use 
> them.

 Commons has already enough rules and process. As long as the releases
 are have clean code I wouldn't be too anal about the commits in
 between.
>>>
>>> I think that the main disagreement is here. Source code must be a clear read
>>> for the _developers_. To put it bluntly, I don't care that the releases have
>>> cleanly formatted code, as almost nobody is going to read those packaged
>>> sources!

And another thing: the formatting /is/ important in released sources
because, again, this is what most users will see in their debuggers.
Have you seen some of the JRE sources? Some files are a mess, others
have blank lines in the middle of headers. Others look like they were
entered by a prisoner blinded in the noon day sun after spending a
month in the hole with bread and water ration and then given a stick
of butter for lunch.

Gary

>>
>> Nobody objects using Checkstyle. Personally I object a default
>> Checkstyle config, which everybody must override. Nearly every
>> components has specifics, so everybody MUST override. What if you
>> don't want to use Checkstyle? Can you disable it?
>> What, if you use Sun conventions and Maven conventions are the
>> default? Much work! Please leave the checkstyle question to where it
>> belongs, and this is not parent pom, but the individual component.
>>
>> And thats what I meant with: as long as we don't have a common
>> codestyle, i does not make much sense to have a common checkstyle
>> configuration.
>
> I thought that the question was whether to generate a CheckStyle report, not
> whether the configuration should be the same...
>
>> Secondly, I have not had the feeling in the past years that checkstyle
>> helped me so much (including non open source projects). And so far, my
>> code was readable.
>
> My code is also readable...
>
> I forgot to mention earlier in this thread that a code formatter will not
> detect missing comments; I've also seen that some people using IDE let the
> software generate totally useless "place-holder" Javadoc comments. Hence
> no tool can afterwards detect that documentation is missing.
>
>
> 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: [ALL] Commons Parent reports

[Gary Gregory]

On Mar 13, 2012, at 12:40, Gilles Sadowski  wrote:

>>>
> [...]
>
> The tools are there, but you have to tell people that they _must_ use 
> them.

 Commons has already enough rules and process. As long as the releases
 are have clean code I wouldn't be too anal about the commits in
 between.
>>>
>>> I think that the main disagreement is here. Source code must be a clear read
>>> for the _developers_. To put it bluntly, I don't care that the releases have
>>> cleanly formatted code, as almost nobody is going to read those packaged
>>> sources!

Au contraire, most users will /only/ look at the source jar because
that is what you use in the debugger!

Gary

>>
>> Nobody objects using Checkstyle. Personally I object a default
>> Checkstyle config, which everybody must override. Nearly every
>> components has specifics, so everybody MUST override. What if you
>> don't want to use Checkstyle? Can you disable it?
>> What, if you use Sun conventions and Maven conventions are the
>> default? Much work! Please leave the checkstyle question to where it
>> belongs, and this is not parent pom, but the individual component.
>>
>> And thats what I meant with: as long as we don't have a common
>> codestyle, i does not make much sense to have a common checkstyle
>> configuration.
>
> I thought that the question was whether to generate a CheckStyle report, not
> whether the configuration should be the same...
>
>> Secondly, I have not had the feeling in the past years that checkstyle
>> helped me so much (including non open source projects). And so far, my
>> code was readable.
>
> My code is also readable...
>
> I forgot to mention earlier in this thread that a code formatter will not
> detect missing comments; I've also seen that some people using IDE let the
> software generate totally useless "place-holder" Javadoc comments. Hence
> no tool can afterwards detect that documentation is missing.
>
>
> 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: [ALL] Commons Parent reports

[Gary Gregory]

On Mar 13, 2012, at 12:23, Emmanuel Bourg  wrote:

> I'd like to see less reports by default. Most of them are only useful for 
> checking a release candidate by the commons devs, otherwise it just clutters 
> the sites with useless information for a general usage.
>
> The most important reports to publish for the public are:
> - Javadoc
> - JXR
> - Clirr
> - Changes (I prefer the changes plugin, it's much more explicit than a list 
> of issues in JIRA)
>
>
> The reports only visible when voting on a release candidate:
> - Cobertura
> - Surefire

These two are important IMO. It shows that we are not releasing
garbage, at least if the tests pass 100% with decent code coverage.
This is part of the "open" in open source IMO. Here is our component,
warts and all, use this information as a guide to help you decide if
this component meets your quality standard. Could you imagine
Microsoft releasing Office with this information? Never! That would
help competitors too much. Hey look at this over there, they don't
even test it. Or, looky here, they released knowing this test fails!

Gary

> - RAT
> - Findbugs
> - Checkstyle
>
> The useless ones:
> - JDepend
>
>
> Emmanuel Bourg
>
>
> Le 13/03/2012 12:48, sebb a écrit :
>> Commons Parent 24 includes the following reports:
>>
>> Javadoc
>> Jxr
>> Surefire
>> RAT
>> Cobertura
>> Clirr
>> JDepend
>>
>> I think the following should be added:
>>
>> Changes/JIRA
>>
>> The following could be added:
>>
>> Findbugs
>> Checkstyle
>>
>> Any others?
>>
>> -
>> 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: [ALL] Commons Parent reports

[Emmanuel Bourg]

Le 13/03/2012 17:52, Gilles Sadowski a écrit :


What about the "Useful for the developer" category?


They are useful at release time only, then they become quickly outdated 
as the code evolves after the release.


If I want to help Commons Math, I'll checkout the code and build the 
reports. Then I might inspect the Findbugs report and see if there is 
something to fix. But I'll never go to the website and browse months old 
reports.


The point is, these reports are valuable if they are updated 
continuously, but that's not possible to do that, because if the 
documentation is updated, the site will expose information that is not 
applicable to the latest release, but to the next one.


What I'd like to see is a more user oriented site, something clear and 
simple, and a developer oriented site with all the reports you want, 
automatically updated everyday.


Emmanuel Bourg



smime.p7s
Description: S/MIME Cryptographic Signature

Re: [ALL] Commons Parent reports

[Christian Grobmeier]

On Tue, Mar 13, 2012 at 5:40 PM, Gilles Sadowski
 wrote:
>> And thats what I meant with: as long as we don't have a common
>> codestyle, i does not make much sense to have a common checkstyle
>> configuration.
>
> I thought that the question was whether to generate a CheckStyle report, not
> whether the configuration should be the same...

if you add a checkstyle report without a custom config, it has the
default configuration, right? In other terms, everybody would create a
report based on this. Or am I wrong?

>> Secondly, I have not had the feeling in the past years that checkstyle
>> helped me so much (including non open source projects). And so far, my
>> code was readable.
>
> My code is also readable...

Sure, I didn't want to say otherwise :-)

> I forgot to mention earlier in this thread that a code formatter will not
> detect missing comments; I've also seen that some people using IDE let the
> software generate totally useless "place-holder" Javadoc comments. Hence
> no tool can afterwards detect that documentation is missing.

Right. I really like Torsten old blog post on JavaDoc comments:
http://vafer.org/blog/20050323095453/

If you have no good javadoc, leave it out. Sometimes you simply do not
have good javadocs checkdoc should not complain about my
decisions.

Cheers

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



-- 
http://www.grobmeier.de
https://www.timeandbill.de

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

Re: [ALL] Commons Parent reports

[Gilles Sadowski]

On Tue, Mar 13, 2012 at 05:23:06PM +0100, Emmanuel Bourg wrote:
> I'd like to see less reports by default. Most of them are only
> useful for checking a release candidate by the commons devs,
> otherwise it just clutters the sites with useless information for a
> general usage.
> 
> The most important reports to publish for the public are:
> - Javadoc
> - JXR
> - Clirr
> - Changes (I prefer the changes plugin, it's much more explicit than
> a list of issues in JIRA)
> 
> 
> The reports only visible when voting on a release candidate:
> - Cobertura
> - Surefire
> - RAT
> - Findbugs
> - Checkstyle
> 
> The useless ones:
> - JDepend
> 

What about the "Useful for the developer" category? 

I think that we originally mentioned a way to enable/disable the running of
the report generators. E.g. one could call from the command-line:

 mvn site -Dcheckstyle=off -Dfindbugs=on

The issue is to provide a top-level working config, then everyone can easily
run whatever they need.
 

Gilles

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

Re: [ALL] Commons Parent reports

[Gilles Sadowski]

Hi.

> >
> >> > [...]
> >> >
> >> > The tools are there, but you have to tell people that they _must_ use 
> >> > them.
> >>
> >> Commons has already enough rules and process. As long as the releases
> >> are have clean code I wouldn't be too anal about the commits in
> >> between.
> >
> > I think that the main disagreement is here. Source code must be a clear read
> > for the _developers_. To put it bluntly, I don't care that the releases have
> > cleanly formatted code, as almost nobody is going to read those packaged
> > sources!
> 
> Nobody objects using Checkstyle. Personally I object a default
> Checkstyle config, which everybody must override. Nearly every
> components has specifics, so everybody MUST override. What if you
> don't want to use Checkstyle? Can you disable it?
> What, if you use Sun conventions and Maven conventions are the
> default? Much work! Please leave the checkstyle question to where it
> belongs, and this is not parent pom, but the individual component.
> 
> And thats what I meant with: as long as we don't have a common
> codestyle, i does not make much sense to have a common checkstyle
> configuration.

I thought that the question was whether to generate a CheckStyle report, not
whether the configuration should be the same...

> Secondly, I have not had the feeling in the past years that checkstyle
> helped me so much (including non open source projects). And so far, my
> code was readable.

My code is also readable...

I forgot to mention earlier in this thread that a code formatter will not
detect missing comments; I've also seen that some people using IDE let the
software generate totally useless "place-holder" Javadoc comments. Hence
no tool can afterwards detect that documentation is missing.


Regards,
Gilles

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

Re: [io] Help with CharSequenceInputStream [WAS: [GUMP@vmgump]: Project commons-io-test (in module apache-commons) failed]

[sebb]

On 13 March 2012 13:23, Gary Gregory  wrote:
> Hello All,
>
> Can the author/committer of CharSequenceInputStream[Test] take a look at
> why Gump is failing?

Seems to be intermittent.

I've added a bit more debug which I hope will help next time.

> Thank you,
> Gary
>
> On Mon, Mar 12, 2012 at 10:04 PM, Gump  wrote:
>
>> 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 11 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 34 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.104 sec
>> Running org.apache.commons.io.comparator.DefaultFileComparatorTest
>> Tests run: 7, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.085 sec
>> Running org.apache.commons.io.comparator.DirectoryFileComparatorTest
>> Tests run: 7, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.101 sec
>> Running org.apache.commons.io.comparator.ExtensionFileComparatorTest
>> Tests run: 8, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.087 sec
>> Running org.apache.commons.io.comparator.PathFileComparatorTest
>> Tests run: 8, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.09 sec
>> Running org.apache.commons.io.comparator.NameFileComparatorTest
>> Tests run: 8, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.086 sec
>> Running org.apache.commons.io.IOUtilsTestCase
>> Tests run: 41, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.398 sec
>> Running org.apache.commons.io.IOCaseTestCase
>> Tests run: 17, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.094 sec
>> Running org.apache.commons.io.LineIteratorTestCase
>> Tests run: 16, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.251 sec
>> Running org.apache.commons.io.FileUtilsCleanDirectoryTestCase
>> Tests run: 5, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.133 sec
>> Running org.apache.commons.io.IOUtilsWriteTestCase
>> Tests run: 53, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.288 sec
>> Running org.apache.commons.io.FilenameUtilsWildcardTestCase
>> Tests run: 7, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.122 sec
>> Running org.apache.commons.io.FileUtilsListFilesTestCase
>> Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.103 sec
>> Running org.apache.commons.io.FileSystemUtilsTestCase
>> Tests run: 28, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.266 sec
>> Running org.apache.commons.io.DirectoryWalkerTestCaseJava4
>> Tests run: 14, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.179 sec
>>
>> Results :
>>
>> Failed tests:
>> testLargeUTF8WithBufferedRead(org.apache.commons.io.input.CharSequenceInputStreamTest):
>> expected:<4733> but was:<4800>
>>
>> Tests run: 904, Failures: 1, Errors: 0, Skipped: 0
>>
>> [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 in

Re: [ALL] Commons Parent reports

[Emmanuel Bourg]

I'd like to see less reports by default. Most of them are only useful 
for checking a release candidate by the commons devs, otherwise it just 
clutters the sites with useless information for a general usage.


The most important reports to publish for the public are:
- Javadoc
- JXR
- Clirr
- Changes (I prefer the changes plugin, it's much more explicit than a 
list of issues in JIRA)



The reports only visible when voting on a release candidate:
- Cobertura
- Surefire
- RAT
- Findbugs
- Checkstyle

The useless ones:
- JDepend


Emmanuel Bourg


Le 13/03/2012 12:48, sebb a écrit :

Commons Parent 24 includes the following reports:

Javadoc
Jxr
Surefire
RAT
Cobertura
Clirr
JDepend

I think the following should be added:

Changes/JIRA

The following could be added:

Findbugs
Checkstyle

Any others?

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






smime.p7s
Description: S/MIME Cryptographic Signature

Re: [ALL] Commons Parent reports

[Christian Grobmeier]

On Tue, Mar 13, 2012 at 5:00 PM, Gilles Sadowski
 wrote:
> Hi.
>
>> > [...]
>> >
>> > The tools are there, but you have to tell people that they _must_ use them.
>>
>> Commons has already enough rules and process. As long as the releases
>> are have clean code I wouldn't be too anal about the commits in
>> between.
>
> I think that the main disagreement is here. Source code must be a clear read
> for the _developers_. To put it bluntly, I don't care that the releases have
> cleanly formatted code, as almost nobody is going to read those packaged
> sources!

Nobody objects using Checkstyle. Personally I object a default
Checkstyle config, which everybody must override. Nearly every
components has specifics, so everybody MUST override. What if you
don't want to use Checkstyle? Can you disable it?
What, if you use Sun conventions and Maven conventions are the
default? Much work! Please leave the checkstyle question to where it
belongs, and this is not parent pom, but the individual component.

And thats what I meant with: as long as we don't have a common
codestyle, i does not make much sense to have a common checkstyle
configuration.

Secondly, I have not had the feeling in the past years that checkstyle
helped me so much (including non open source projects). And so far, my
code was readable.



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



-- 
http://www.grobmeier.de
https://www.timeandbill.de

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

Re: [ALL] Commons Parent reports

[Gilles Sadowski]

Hi.

> > [...]
> >
> > The tools are there, but you have to tell people that they _must_ use them.
> 
> Commons has already enough rules and process. As long as the releases
> are have clean code I wouldn't be too anal about the commits in
> between.

I think that the main disagreement is here. Source code must be a clear read
for the _developers_. To put it bluntly, I don't care that the releases have
cleanly formatted code, as almost nobody is going to read those packaged
sources!

> [...]

Gilles

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

Re: [ALL] Commons Parent reports

[Simone Tripodi]

> Unless I'm missing something:
>
>  (Using CheckStyle) != (Using the same formatting style in all projects)

+1

http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/

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

Re: [ALL] Commons Parent reports

[Ralph Goers]

On Mar 13, 2012, at 6:44 AM, Benedikt Ritter wrote:

> Am 13. März 2012 14:15 schrieb Gary Gregory :
>> On Tue, Mar 13, 2012 at 8:39 AM, Torsten Curdt  wrote:
>> 
>>> I find checkstyle to be not very useful. It's more hassle than it's
>>> worth. It's like pointing fingers instead of helping. If you want to
>>> foster a certain code style provide eclipse and intellij formatter
>>> settings instead - that's actually helping. Especially if you run them
>>> before a release.
>>> 
>> 
>> I'd /love/ to have IDE settings for formatting saved in a project. This is
>> the 21st century, all IDEs support this, if you do not use an IDE (hi
>> Gilles), then, well, you probably also like driving a stick for "control"
>> :) The only tricky part is how organize such a folder to account for
>> different IDEs and versions. For example ide/eclipse/3.7.1,
>> ide/intellij/10.5.3, and so on. Then you can move the IDE files to where
>> each IDE wants it.
>> 
> 
> Very big +1 Gary! It would make contributing to the various components
> so much easier (at least for people how use an IDE ;). I guess we
> should discuss this on a new thread.

Although I would also like to have the checkstyle configuration for IntelliJ as 
part of the project, I also like having the checkstyle report to get the 
overview of the whole project.

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

Re: [ALL] Commons Parent reports

[Gilles Sadowski]

On Tue, Mar 13, 2012 at 03:08:01PM +0100, Christian Grobmeier wrote:
> +1 on the mentioned plugins, except:
> -1 on checkstyle.
> 
> I dont see a benefit in making checkstyle default. If somebody wants
> to use that tool, he can.
> 
> What checkstyle-style would be the default? Sun conventions or maven
> style? I am for sun, Simone is for maven (i guess). Probably there is
> another component with more specific desires. I really don't want to
> discuss this issue...
> 
> We are all grown up here and a small party. And we have commit
> notifications. And if a component wishes, it can use checkstyle. Just
> don't make a specific style default... it probably makes a little bit
> more sense if components would all use the same style. But we don't
> even manage to agree on a uni-build system, I really see no way to
> make it uni-styled.

Unless I'm missing something:

  (Using CheckStyle) != (Using the same formatting style in all projects)


Gilles

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

Re: [ALL] Commons Parent reports

[Torsten Curdt]

> I didn't think we disagreed on refusing to spend a lot of time of correcting 
> formatting mess.

Not on that one :)

I just argue that in the days of code formatters "lot of time" has
become is quite significant.

>> Then you are probably a vocal minority here.
>
> Because I don't use an IDE or because I like clean code?

I hope that's a rhetorical question. I would think most java people use an IDE.

>> As long as there is someone that can run a code formatter before a
>> release that does not matter though.
>
> But would you be against running a formatter before committing the code.

It would be nice - but I would not want to require it.

>>  Menu > "Format Source Code" > Done.
>
> ... if they don't perform the above, CheckStyle is there to remind them they
> forgot to do it.

Why not just run the formatter in the very moment you are annoyed?

>> And I say - better let's give people the tools and not just point at them.
>
> The tools are there, but you have to tell people that they _must_ use them.

Commons has already enough rules and process. As long as the releases
are have clean code I wouldn't be too anal about the commits in
between.

Summary: if you guys insist - add it ...as long as components are OK
to disable it.
I personally just don't find it useful. But I can live with the fact
that you disagree.

Now that was already 4 cents :)

cheers,
Torsten

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

Re: [ALL] Commons Parent reports

[Christian Grobmeier]

+1 on the mentioned plugins, except:
-1 on checkstyle.

I dont see a benefit in making checkstyle default. If somebody wants
to use that tool, he can.

What checkstyle-style would be the default? Sun conventions or maven
style? I am for sun, Simone is for maven (i guess). Probably there is
another component with more specific desires. I really don't want to
discuss this issue...

We are all grown up here and a small party. And we have commit
notifications. And if a component wishes, it can use checkstyle. Just
don't make a specific style default... it probably makes a little bit
more sense if components would all use the same style. But we don't
even manage to agree on a uni-build system, I really see no way to
make it uni-styled.


On Tue, Mar 13, 2012 at 2:27 PM, Torsten Curdt  wrote:
>> CheckStyle reports should be checked regularly. Only doing so just before a
>> release indeed leads to a lot of tedious work, because coders did not
>> respect the basic, agreed on, style.
>
> I guess we are disagreeing here.
>
>> I don't use an IDE, so for me, CheckStyle helps but formatter IDE plugins
>> would not. Our mileage do vary but the end-product (clean code) should not.
>
> Then you are probably a vocal minority here.
> As long as there is someone that can run a code formatter before a
> release that does not matter though.
>
>> As said in another post, you can always disable reports that you find
>> unhelpful.
>
> Fair enough. But projects that find it useful could also just add the report 
> :)
> We are discussing about what should be the default here.
> That said I rather just disable it in the POM that continue with the 
> discussion.
>
>>> The basic code style is like logging - people spent just wait too much
>>> time on this.
>
> ...because I dont' want to contribute to that time any more.
>
>> The real problem is that some coders do not do their part of the job when
>> they commit badly formatted code.
>> Those whose spend too much time are the ones who try to clean up the mess
>> afterwards.
>
> If you prefer to not use code formatter - that is. But that's your decision.
>
>  Menu > "Format Source Code" > Done.
>
> ...plus I am bet there are ways to set up code formatting for vim and
> friends - if one wanted to.
>
>> CheckStyle indeed points a finger to the right person, which IMHO helps by
>> making this person aware that he should fix it.
>
> And I say - better let's give people the tools and not just point at them.
>
> cheers,
> Torsten
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>



-- 
http://www.grobmeier.de
https://www.timeandbill.de

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

Re: [ALL] Commons Parent reports

[Simone Tripodi]

Hi again Torsten!

I thought it would be useful having a checkstyle also becasue it is
not just a matter of code formatting rules, there are also useful
basic checks  that help
- me, at least - on taking care of some rules I can occasionally
forget to apply.

> And I say - better let's give people the tools and not just point at them.

I agree. IIUC the proposal of putting checkstyle in the parent came
out because it is plugged in every plugin, so the purpose is more
generalize rather then point to it.

All the best!
-Simo

http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/



On Tue, Mar 13, 2012 at 2:27 PM, Torsten Curdt  wrote:
>> CheckStyle reports should be checked regularly. Only doing so just before a
>> release indeed leads to a lot of tedious work, because coders did not
>> respect the basic, agreed on, style.
>
> I guess we are disagreeing here.
>
>> I don't use an IDE, so for me, CheckStyle helps but formatter IDE plugins
>> would not. Our mileage do vary but the end-product (clean code) should not.
>
> Then you are probably a vocal minority here.
> As long as there is someone that can run a code formatter before a
> release that does not matter though.
>
>> As said in another post, you can always disable reports that you find
>> unhelpful.
>
> Fair enough. But projects that find it useful could also just add the report 
> :)
> We are discussing about what should be the default here.
> That said I rather just disable it in the POM that continue with the 
> discussion.
>
>>> The basic code style is like logging - people spent just wait too much
>>> time on this.
>
> ...because I dont' want to contribute to that time any more.
>
>> The real problem is that some coders do not do their part of the job when
>> they commit badly formatted code.
>> Those whose spend too much time are the ones who try to clean up the mess
>> afterwards.
>
> If you prefer to not use code formatter - that is. But that's your decision.
>
>  Menu > "Format Source Code" > Done.
>
> ...plus I am bet there are ways to set up code formatting for vim and
> friends - if one wanted to.
>
>> CheckStyle indeed points a finger to the right person, which IMHO helps by
>> making this person aware that he should fix it.
>
> And I say - better let's give people the tools and not just point at them.
>
> cheers,
> Torsten
>
> -
> 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: [ALL] Commons Parent reports

[Gilles Sadowski]

On Tue, Mar 13, 2012 at 02:27:32PM +0100, Torsten Curdt wrote:
> > CheckStyle reports should be checked regularly. Only doing so just before a
> > release indeed leads to a lot of tedious work, because coders did not
> > respect the basic, agreed on, style.
> 
> I guess we are disagreeing here.

I didn't think we disagreed on refusing to spend a lot of time of correcting
formatting mess.

> 
> > I don't use an IDE, so for me, CheckStyle helps but formatter IDE plugins
> > would not. Our mileage do vary but the end-product (clean code) should not.
> 
> Then you are probably a vocal minority here.

Because I don't use an IDE or because I like clean code?

> As long as there is someone that can run a code formatter before a
> release that does not matter though.

But would you be against running a formatter before committing the code.

"Modern" editors would do this as you type (like e.g. in emacs or the IDE
plugins referred to in this thread).
It's tiresome to have to read badly formatted code and it leads to spurios
commits just to straighten up the formatting.

> > As said in another post, you can always disable reports that you find
> > unhelpful.
> 
> Fair enough. But projects that find it useful could also just add the report 
> :)
> We are discussing about what should be the default here.
> That said I rather just disable it in the POM that continue with the 
> discussion.
> 
> >> The basic code style is like logging - people spent just wait too much
> >> time on this.
> 
> ...because I dont' want to contribute to that time any more.
> 
> > The real problem is that some coders do not do their part of the job when
> > they commit badly formatted code.
> > Those whose spend too much time are the ones who try to clean up the mess
> > afterwards.
> 
> If you prefer to not use code formatter - that is. But that's your decision.

Did I say so?
I just said the opposite: I don't like that people commit badly formatted
code and...

>  Menu > "Format Source Code" > Done.

... if they don't perform the above, CheckStyle is there to remind them they
forgot to do it.

> ...plus I am bet there are ways to set up code formatting for vim and
> friends - if one wanted to.

I hope that misunderstanding has been cleared now.

> > CheckStyle indeed points a finger to the right person, which IMHO helps by
> > making this person aware that he should fix it.
> 
> And I say - better let's give people the tools and not just point at them.

The tools are there, but you have to tell people that they _must_ use them.

Regards,
Gilles

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

Re: [ALL] Commons Parent reports

[Benedikt Ritter]

Am 13. März 2012 14:15 schrieb Gary Gregory :
> On Tue, Mar 13, 2012 at 8:39 AM, Torsten Curdt  wrote:
>
>> I find checkstyle to be not very useful. It's more hassle than it's
>> worth. It's like pointing fingers instead of helping. If you want to
>> foster a certain code style provide eclipse and intellij formatter
>> settings instead - that's actually helping. Especially if you run them
>> before a release.
>>
>
> I'd /love/ to have IDE settings for formatting saved in a project. This is
> the 21st century, all IDEs support this, if you do not use an IDE (hi
> Gilles), then, well, you probably also like driving a stick for "control"
> :) The only tricky part is how organize such a folder to account for
> different IDEs and versions. For example ide/eclipse/3.7.1,
> ide/intellij/10.5.3, and so on. Then you can move the IDE files to where
> each IDE wants it.
>

Very big +1 Gary! It would make contributing to the various components
so much easier (at least for people how use an IDE ;). I guess we
should discuss this on a new thread.

> Gary
>
>
>> The basic code style is like logging - people spent just wait too much
>> time on this. Thinks we really should care about are in the findbugs
>> and PMD report. I don't see why we should make checkstyle part of the
>> projects by default.
>
>
>> My 2 cents,
>> Torsten
>>
>> On Tue, Mar 13, 2012 at 1:14 PM, Simone Tripodi
>>  wrote:
>> > Hi Torsten!
>> >
>> >> -1 for checkstyle
>> >
>> > With my +1 I meant that, as we discussed in another thread, the parent
>> > could provide a default - but overridable - configuration; I think
>> > that having at least one metric of code style measure in each
>> > component would be nice to have, so unless other preferences, the
>> > parent "suggests" a default config
>> >
>> > I would like to understand better your PoV (that would influence
>> > mine): which are your concerns about having the checkstyle?
>> >
>> > many thanks in advance, all the best,
>> > -Simo
>> >
>> > http://people.apache.org/~simonetripodi/
>> > http://simonetripodi.livejournal.com/
>> > http://twitter.com/simonetripodi
>> > http://www.99soft.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
>>
>>
>
>
> --
> 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

Re: [ALL] Commons Parent reports

[Torsten Curdt]

> CheckStyle reports should be checked regularly. Only doing so just before a
> release indeed leads to a lot of tedious work, because coders did not
> respect the basic, agreed on, style.

I guess we are disagreeing here.

> I don't use an IDE, so for me, CheckStyle helps but formatter IDE plugins
> would not. Our mileage do vary but the end-product (clean code) should not.

Then you are probably a vocal minority here.
As long as there is someone that can run a code formatter before a
release that does not matter though.

> As said in another post, you can always disable reports that you find
> unhelpful.

Fair enough. But projects that find it useful could also just add the report :)
We are discussing about what should be the default here.
That said I rather just disable it in the POM that continue with the discussion.

>> The basic code style is like logging - people spent just wait too much
>> time on this.

...because I dont' want to contribute to that time any more.

> The real problem is that some coders do not do their part of the job when
> they commit badly formatted code.
> Those whose spend too much time are the ones who try to clean up the mess
> afterwards.

If you prefer to not use code formatter - that is. But that's your decision.

 Menu > "Format Source Code" > Done.

...plus I am bet there are ways to set up code formatting for vim and
friends - if one wanted to.

> CheckStyle indeed points a finger to the right person, which IMHO helps by
> making this person aware that he should fix it.

And I say - better let's give people the tools and not just point at them.

cheers,
Torsten

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

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

[Gary Gregory]

Hello All,

Can the author/committer of CharSequenceInputStream[Test] take a look at
why Gump is failing?

Thank you,
Gary

On Mon, Mar 12, 2012 at 10:04 PM, Gump  wrote:

> 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 11 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 34 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.104 sec
> Running org.apache.commons.io.comparator.DefaultFileComparatorTest
> Tests run: 7, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.085 sec
> Running org.apache.commons.io.comparator.DirectoryFileComparatorTest
> Tests run: 7, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.101 sec
> Running org.apache.commons.io.comparator.ExtensionFileComparatorTest
> Tests run: 8, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.087 sec
> Running org.apache.commons.io.comparator.PathFileComparatorTest
> Tests run: 8, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.09 sec
> Running org.apache.commons.io.comparator.NameFileComparatorTest
> Tests run: 8, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.086 sec
> Running org.apache.commons.io.IOUtilsTestCase
> Tests run: 41, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.398 sec
> Running org.apache.commons.io.IOCaseTestCase
> Tests run: 17, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.094 sec
> Running org.apache.commons.io.LineIteratorTestCase
> Tests run: 16, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.251 sec
> Running org.apache.commons.io.FileUtilsCleanDirectoryTestCase
> Tests run: 5, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.133 sec
> Running org.apache.commons.io.IOUtilsWriteTestCase
> Tests run: 53, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.288 sec
> Running org.apache.commons.io.FilenameUtilsWildcardTestCase
> Tests run: 7, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.122 sec
> Running org.apache.commons.io.FileUtilsListFilesTestCase
> Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.103 sec
> Running org.apache.commons.io.FileSystemUtilsTestCase
> Tests run: 28, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.266 sec
> Running org.apache.commons.io.DirectoryWalkerTestCaseJava4
> Tests run: 14, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.179 sec
>
> Results :
>
> Failed tests:
> testLargeUTF8WithBufferedRead(org.apache.commons.io.input.CharSequenceInputStreamTest):
> expected:<4733> but was:<4800>
>
> Tests run: 904, Failures: 1, Errors: 0, Skipped: 0
>
> [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 33 seconds
> [INFO] Finished at: Tue Mar 13 02:04:28 UTC 2012
> [INFO] Final Memory: 32M/77M

Re: [ALL] Commons Parent reports

[Gary Gregory]

On Tue, Mar 13, 2012 at 8:39 AM, Torsten Curdt  wrote:

> I find checkstyle to be not very useful. It's more hassle than it's
> worth. It's like pointing fingers instead of helping. If you want to
> foster a certain code style provide eclipse and intellij formatter
> settings instead - that's actually helping. Especially if you run them
> before a release.
>

I'd /love/ to have IDE settings for formatting saved in a project. This is
the 21st century, all IDEs support this, if you do not use an IDE (hi
Gilles), then, well, you probably also like driving a stick for "control"
:) The only tricky part is how organize such a folder to account for
different IDEs and versions. For example ide/eclipse/3.7.1,
ide/intellij/10.5.3, and so on. Then you can move the IDE files to where
each IDE wants it.

Gary


> The basic code style is like logging - people spent just wait too much
> time on this. Thinks we really should care about are in the findbugs
> and PMD report. I don't see why we should make checkstyle part of the
> projects by default.


> My 2 cents,
> Torsten
>
> On Tue, Mar 13, 2012 at 1:14 PM, Simone Tripodi
>  wrote:
> > Hi Torsten!
> >
> >> -1 for checkstyle
> >
> > With my +1 I meant that, as we discussed in another thread, the parent
> > could provide a default - but overridable - configuration; I think
> > that having at least one metric of code style measure in each
> > component would be nice to have, so unless other preferences, the
> > parent "suggests" a default config
> >
> > I would like to understand better your PoV (that would influence
> > mine): which are your concerns about having the checkstyle?
> >
> > many thanks in advance, all the best,
> > -Simo
> >
> > http://people.apache.org/~simonetripodi/
> > http://simonetripodi.livejournal.com/
> > http://twitter.com/simonetripodi
> > http://www.99soft.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
>
>


-- 
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: [ALL] Commons Parent reports

[Gilles Sadowski]

On Tue, Mar 13, 2012 at 01:39:40PM +0100, Torsten Curdt wrote:
> I find checkstyle to be not very useful. It's more hassle than it's
> worth. It's like pointing fingers instead of helping. If you want to
> foster a certain code style provide eclipse and intellij formatter
> settings instead - that's actually helping. Especially if you run them
> before a release.

CheckStyle reports should be checked regularly. Only doing so just before a
release indeed leads to a lot of tedious work, because coders did not
respect the basic, agreed on, style.

I don't use an IDE, so for me, CheckStyle helps but formatter IDE plugins
would not. Our mileage do vary but the end-product (clean code) should not.  

As said in another post, you can always disable reports that you find
unhelpful.

> The basic code style is like logging - people spent just wait too much
> time on this.

The real problem is that some coders do not do their part of the job when
they commit badly formatted code.
Those whose spend too much time are the ones who try to clean up the mess
afterwards.
CheckStyle indeed points a finger to the right person, which IMHO helps by
making this person aware that he should fix it.

> Thinks we really should care about are in the findbugs
> and PMD report. I don't see why we should make checkstyle part of the
> projects by default.

They are all useful in different ways.

Best regards,
Gilles

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

Re: [ALL] Commons Parent reports

[Torsten Curdt]

I find checkstyle to be not very useful. It's more hassle than it's
worth. It's like pointing fingers instead of helping. If you want to
foster a certain code style provide eclipse and intellij formatter
settings instead - that's actually helping. Especially if you run them
before a release.

The basic code style is like logging - people spent just wait too much
time on this. Thinks we really should care about are in the findbugs
and PMD report. I don't see why we should make checkstyle part of the
projects by default.

My 2 cents,
Torsten

On Tue, Mar 13, 2012 at 1:14 PM, Simone Tripodi
 wrote:
> Hi Torsten!
>
>> -1 for checkstyle
>
> With my +1 I meant that, as we discussed in another thread, the parent
> could provide a default - but overridable - configuration; I think
> that having at least one metric of code style measure in each
> component would be nice to have, so unless other preferences, the
> parent "suggests" a default config
>
> I would like to understand better your PoV (that would influence
> mine): which are your concerns about having the checkstyle?
>
> many thanks in advance, all the best,
> -Simo
>
> http://people.apache.org/~simonetripodi/
> http://simonetripodi.livejournal.com/
> http://twitter.com/simonetripodi
> http://www.99soft.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: [ALL] Commons Parent reports

[Gary Gregory]

On Tue, Mar 13, 2012 at 8:14 AM, Simone Tripodi wrote:

> Hi Torsten!
>
> > -1 for checkstyle
>
> With my +1 I meant that, as we discussed in another thread, the parent
> could provide a default - but overridable - configuration; I think
> that having at least one metric of code style measure in each
> component would be nice to have, so unless other preferences, the
> parent "suggests" a default config
>

+1. We need a default, Commons components can continue to override or
decide to use the default. New components coming should use the default.

Gary

>
> I would like to understand better your PoV (that would influence
> mine): which are your concerns about having the checkstyle?
>
> many thanks in advance, all the best,
> -Simo
>
> http://people.apache.org/~simonetripodi/
> http://simonetripodi.livejournal.com/
> http://twitter.com/simonetripodi
> http://www.99soft.org/
>
> -
> 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

Re: [ALL] Commons Parent reports

[Simone Tripodi]

Hi Torsten!

> -1 for checkstyle

With my +1 I meant that, as we discussed in another thread, the parent
could provide a default - but overridable - configuration; I think
that having at least one metric of code style measure in each
component would be nice to have, so unless other preferences, the
parent "suggests" a default config

I would like to understand better your PoV (that would influence
mine): which are your concerns about having the checkstyle?

many thanks in advance, all the best,
-Simo

http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/

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

Re: [ALL] Commons Parent reports

[Torsten Curdt]

> The following could be added:
>
> Findbugs
> Checkstyle

+1 for findbugs
-1 for checkstyle

cheers,
Torsten

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

Re: [ALL] Commons Parent reports

[Simone Tripodi]

Hi!

> Commons Parent 24 includes the following reports:
>
> Javadoc
> Jxr
> Surefire
> RAT
> Cobertura
> Clirr
> JDepend
>
> I think the following should be added:
>
> Changes/JIRA

+1 the pattern is always the same

>
> The following could be added:
>
> Findbugs
> Checkstyle

+1

>
> Any others?

PMD/CPD would be fine as well, then I think it would be complete!
best,
-Simo

http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/

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

[ALL] Commons Parent reports

[sebb]

Commons Parent 24 includes the following reports:

Javadoc
Jxr
Surefire
RAT
Cobertura
Clirr
JDepend

I think the following should be added:

Changes/JIRA

The following could be added:

Findbugs
Checkstyle

Any others?

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

Re: [csv] Headers

[Benedikt Ritter]

I think transforming the result of the parse process into instances of
some class is a different concern. That should not be part of as
CSVParser. In Hibernate they use ResultTransformers for this purpose
[1]. I think we should separate this concerns as well.

[1] 
http://docs.jboss.org/hibernate/orm/3.3/api/org/hibernate/transform/ResultTransformer.html

Am 13. März 2012 10:03 schrieb Emmanuel Bourg :
> Le 13/03/2012 09:56, sebb a écrit :
>
>
>> It needs to be possible to access columns by index without having to
>> use annotations.
>
>
> That's still possible with the low level API. I'm just exploring the
> features I would expect of a bean mapping.
>
> Emmanuel Bourg
>

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

Re: [MATH] Does website really need Javadoc for versions prior to 2.2?

[Thomas Neidhart]

On Tue, Mar 13, 2012 at 11:28 AM, Gilles Sadowski <
gil...@harfang.homelinux.org> wrote:

> On Mon, Mar 12, 2012 at 08:22:27PM +0100, Luc Maisonobe wrote:
> > Le 12/03/2012 16:50, sebb a écrit :
> > > In addition to Javadoc for 3.0 and 2.2, the website still offers the
> following:
>

I have found another thing that is missing. The changes report is not there
anymore, or at least has not been generated for the 3.0 release.
If you access the URL directly at
http://commons.apache.org/math/changes-report.html, you can still access
the old one (3.0-SNAPSHOT).

Thomas

Re: [MATH] Does website really need Javadoc for versions prior to 2.2?

[Gilles Sadowski]

On Mon, Mar 12, 2012 at 08:22:27PM +0100, Luc Maisonobe wrote:
> Le 12/03/2012 16:50, sebb a écrit :
> > In addition to Javadoc for 3.0 and 2.2, the website still offers the 
> > following:
> > 
> > Javadoc (2.1 release)
> > Javadoc (2.0 release)
> > Javadoc (1.2 release)
> > Javadoc (1.1 release)
> > Javadoc (1.0 release)
> > 
> > This seems rather unnecessary. Surely we should only offer Javadoc for
> > current releases?
> 
> I agree. These versions are really old now and we don't get any requests
> from user about them.

+0
Maybe some users would like to have a quick way to discover how the API has
changed.
For the time being, maybe keep 2.1 (see recent post from a team that did
not upgrade to 2.2).

Gilles

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

Re: [csv] Performance comparison

[Emmanuel Bourg]

Le 13/03/2012 02:47, Niall Pemberton a écrit :


IMO performance should be taken out of the equation by using the
Readable interface[1]. That way the users can use whatever
implementation suits them (for example using an underlying buffered
InputStream) to change/improve performance.


I you mean that the performance of BufferedReader should be taken out of 
the equation then I agree. All CSV parsers should be compared with the 
same input source, otherwise the comparison isn't fair.


Using Readable would be really nice, but that's very low level. We would 
have to build line reading and mark/reset on top of that, that's almost 
equivalent to reimplementing BufferedReader.


If [io] could provide a BufferedReader implementation that:
- takes a Readable in the constructor
- does not synchronize reads
- recognizes unicode line separators (and the classic ones)

then I buy it right away!

Emmanuel Bourg



smime.p7s
Description: S/MIME Cryptographic Signature

[ANNOUNCE] Commons Parent 24 released

[sebb]

Commons Parent has been released.

Main changes:
- added tests and test-source jars to the release profile.
- Added cobertura: 2.5.1 to reporting and buildManagement
- Add default project info reports: excluded license/plugins/plugin management

Release notes (including all changes):

https://svn.apache.org/repos/asf/commons/proper/commons-parent/tags/commons-parent-24/RELEASE-NOTES.txt

When upgrading to CP24, please take a moment to check if the component
pom can be simplified.
The parent pom now handles a lot more by default.

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

Re: [csv] Performance comparison

[sebb]

On 13 March 2012 09:01, Emmanuel Bourg  wrote:
> Le 13/03/2012 01:44, sebb a écrit :
>
>
>> I don't think we should be trying to recode JDK classes.
>
>
> I'd rather not, but we have done that in the past. FastDateFormat and
> StrBuilder come to mind.

And now Java has StringBuilder, which means StrBuilder is perhaps no
longer necessary...

> Emmanuel Bourg
>

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

Re: [csv] Headers

[Emmanuel Bourg]

Le 13/03/2012 09:56, sebb a écrit :


It needs to be possible to access columns by index without having to
use annotations.


That's still possible with the low level API. I'm just exploring the 
features I would expect of a bean mapping.


Emmanuel Bourg



smime.p7s
Description: S/MIME Cryptographic Signature

Re: [csv] Performance comparison

[Emmanuel Bourg]

Le 13/03/2012 01:44, sebb a écrit :


I don't think we should be trying to recode JDK classes.


I'd rather not, but we have done that in the past. FastDateFormat and 
StrBuilder come to mind.


Emmanuel Bourg



smime.p7s
Description: S/MIME Cryptographic Signature

Re: [csv] Headers

[sebb]

On 13 March 2012 08:52, Emmanuel Bourg  wrote:
> Le 13/03/2012 09:21, Jörg Schaible a écrit :
>
>
>>> If the file has a header, the fields are matched by attribute name, and
>>> an annotation can override the name of the column associated to an
>>> attribute.
>>
>>
>> Yeah, but that's not required. Just because you can read the names of the
>> columns does not mean that you want to address them by name. Why pay the
>> price for creating the map and accessing the values by name just for a
>> one-
>> time information?
>
>
> Sorry I forgot the end of my message, I meant to access the fields by name
> OR by index when the header is present. That would be configured with the
> annotations.

It needs to be possible to access columns by index without having to
use annotations.

> Emmanuel Bourg
>

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

Re: [csv] Headers

[Emmanuel Bourg]

Le 13/03/2012 09:21, Jörg Schaible a écrit :


If the file has a header, the fields are matched by attribute name, and
an annotation can override the name of the column associated to an
attribute.


Yeah, but that's not required. Just because you can read the names of the
columns does not mean that you want to address them by name. Why pay the
price for creating the map and accessing the values by name just for a one-
time information?


Sorry I forgot the end of my message, I meant to access the fields by 
name OR by index when the header is present. That would be configured 
with the annotations.


Emmanuel Bourg



smime.p7s
Description: S/MIME Cryptographic Signature

Re: [csv] Headers

[Jörg Schaible]

Emmanuel Bourg wrote:

> Le 13/03/2012 00:56, sebb a écrit :
> 
>>> 1. Do nothing and address it in the next release with the bean mapping.
>>> Parsing the file would then look like this:
>>>
>>>   CSVFormat  format = CSVFormat.DEFAULT.withType(Person.class);
>>>   for (Person person : format.parse(in)) {
>>>   persons.add(person);
>>>   }
>>>
>>
>> Does this automatically mean that the file has a header?
>> Or is there another way to link columns to Person attributes?
> 
> If the file doesn't have a header, the fields are matched by index
> (either the natural ordering of the attributes in the class, or
> specified by an annotation).
> 
> If the file has a header, the fields are matched by attribute name, and
> an annotation can override the name of the column associated to an
> attribute.

Yeah, but that's not required. Just because you can read the names of the 
columns does not mean that you want to address them by name. Why pay the 
price for creating the map and accessing the values by name just for a one-
time information?

- Jörg


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

Re: [lang] Longest common substring / Suffix Tree

[Luc Maisonobe]

Le 13/03/2012 00:53, James Carman a écrit :
> A lot of bioinformaticians would love us if we added this!

In the same spirit, I know an implementation of the Myers difference
algorithm that runs on any object implementing equals and also provides
an API for browsing the "edit script" resulting from the comparison.
This allows for example to retrieve only the shared elements, or only
the ones in the first or the second sequence, or "running" the script,
or whatever.

If you consider this could be a good addition to [lang] or another
component ([graph] ?) I can ask for a grant for this.

Luc

> On Mar 12, 2012 4:20 PM, "Thomas Neidhart" 
> wrote:
> 
>> Hi,
>>
>> on the weekend, I started to work on issue LANG-680
>> (https://issues.apache.org/jira/browse/LANG-680), which is about adding
>> support for finding the longest common substring of a set of Strings.
>>
>> Suffix Trees are a standard data structure to efficiently solve this
>> problem, and I created a variant of Ukkonen's algorithm to construct
>> such a tree in linear time.
>>
>> After some research to create a generalized version of it (to support
>> multiple strings), I found a very nice implementation from Alessandro
>> Bahgat (https://github.com/abahgat/suffixtree), which is very similar to
>> my own, and contacted the author if he is interested to put his code
>> under apache license (which he did already).
>>
>> So the question basically is how to proceed, as adding a data structure
>> like a Suffix Tree to commons-lang may be out-of-scope. On the other
>> hand there are several string related problems that can be efficiently
>> solved with a Suffix Tree:
>>
>>  * longest common substring
>>  * longest repeated substring
>>  * exact string set matching
>>  * palindrom finding
>>  * finding frequent substrings
>>
>> Implementing a longest common substring for two strings is trivial
>> (using dynamic programming ~20 lines of code), but for a set of strings
>> a suffix tree would be needed.
>>
>> Henri already outlined a possible API as comment to the issue, which I
>> like, so what do other people think about adding a suffix tree to
>> commons-lang?
>>
>> 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

Re: [csv] Headers

[Luc Maisonobe]

Le 13/03/2012 00:56, sebb a écrit :
> On 12 March 2012 22:11, Emmanuel Bourg  wrote:
>> [csv] is missing some elements to ease the use of headers. I have no clear
>> idea on how to address this, here are my thoughts.
>>
>> Headers are used when the fields are accessed by the column name rather than
>> by the index. This provides some flexibility because the input file can be
>> slightly modified by reordering the columns or by inserting new columns
>> without breaking the existing code.
>>
>> Using the current API here is how one would work with headers:
>>
>>  CSVParser parser = new CSVParser(in);
>>  Iterator it = parser.iterator();
>>
>>  // read the header
>>  String[] header = it.next();
>>
>>  // build a name to index mapping
>>  Map mapping = new HashMap<>();
>>  for (int i = 0; i < header.length; i++) {
>>  mapping.put(header[i], i);
>>  }
>>
>>  // parse the records
>>  for (String[] record : parser) {
>>  Person person = new Person();
>>  person.setName(record[mapping.get("name")]);
>>  person.setEmail(record[mapping.get("email")]);
>>  person.setPhone(record[mapping.get("phone")]);
>>  persons.add(person);
>>  }
>>
>> The user has to take care of the mapping, which is not very friendly. I have
>> several solutions in mind:
>>
>> 1. Do nothing and address it in the next release with the bean mapping.
>> Parsing the file would then look like this:
>>
>>  CSVFormat format = CSVFormat.DEFAULT.withType(Person.class);
>>  for (Person person : format.parse(in)) {
>>  persons.add(person);
>>  }
>>
> 
> Does this automatically mean that the file has a header?
> Or is there another way to link columns to Person attributes?
> 
> I don't think this should be the only way of handling named columns;
> it's not always convenient to create a type.

I agree. Sometimes, the colums are just a part of a class that would
need other parameters not in the columns (but perhaps in a custom
comment of the header, if these parameters are constant throughout the
file. So providing intermediate level API (with mapping already done,
but still access to individual fields) is a must.

> 
>> 2. Add a parser returning a Map instead of a String[]
>>
>>  // declare the header in the format,
>>  // the header line will be parsed automatically
>>  CSVFormat format = CSVFormat.DEFAULT.withHeader();
>>
>>  for (Map record : new CSVMapParser(in, format))) {
>>  Person person = new Person();
>>  person.setName(record.get("name"));
>>  person.setEmail(record.get("email"));
>>  person.setPhone(record.get("phone"));
>>  persons.add(person);
>>  }
> 
> That seems OK; one can also just use the column values directly.

+1


Luc

> 
>>
>> 2bis. Have the same CSVParser class returning String[] or Map> String> depending on a generic parameter. Not sure it's possible with type
>> erasure.
>>
> 
> It's not possible for two methods to differ only by return parameter
> type, so this can only be done if the method parameters are different
> after type erasure.
> 
>> 3. Have the parser maintain the name->index mapping. The parser read the
>> first line automatically if the format declares a header, and a
>> getColumnIndex() method is exposed.
>>
>>  CSVFormat format = CSVFormat.DEFAULT.withHeader();
>>  CSVParser parser = new CSVParser(in, format);
>>
>>  // parse the records
>>  for (String[] record : parser) {
>>  Person person = new Person();
>>  person.setName(record[parser.getColumnIndex("name")]);
>>  person.setEmail(record[parser.getColumnIndex("email")]);
>>  person.setPhone(record[parser.getColumnIndex("phone")]);
>>  persons.add(person);
>>  }
> 
> Quite awkard to use.
> 
>>
>> What do you think?
>>
>> 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