date:20120212

[RESULT] was: [VOTE] Release Daemon 1.0.9 based on RC1

2012-02-12 Thread Mladen Turk


We have 3 +1's from Mark, Luc and Mladen
Thus the vote passed. I'll push the sources
and create an ANN later today.


Regards
--
^TM

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

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

2012-02-12 Thread 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 399 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: 12 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.004 sec
Running org.apache.commons.proxy.interceptor.TestFilteredInterceptor
Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.031 sec
Running org.apache.commons.proxy.interceptor.filter.TestPatternFilter
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.037 sec
Running org.apache.commons.proxy.interceptor.TestSerializingInterceptor
Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.02 sec
Running org.apache.commons.proxy.interceptor.TestInterceptorChain
Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.007 sec
Running org.apache.commons.proxy.invoker.TestNullInvoker
Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.019 sec
Running org.apache.commons.proxy.provider.remoting.TestBurlapProvider
Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.009 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.032 sec
Running org.apache.commons.proxy.factory.javassist.TestJavassistProxyFactory
Tests run: 37, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.159 sec
Running org.apache.commons.proxy.exception.TestProxyFactoryException
Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.008 sec
Running org.apache.commons.proxy.interceptor.filter.TestReturnTypeFilter
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.003 sec
Running org.apache.commons.proxy.provider.TestBeanProvider
Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.025 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: 11 seconds
[INFO] Finished at: Mon Feb 13 05:39:02 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.o

Re: [VOTE] Release Commons NET 3.1` based on RC1

2012-02-12 Thread sebb

On 13 February 2012 02:01, sebb  wrote:
> On 12 February 2012 16:09, Gary Gregory  wrote:
>> Hi Sebb,
>>
>> Sorry, -1: I get a build failure with my default set up using
>> https://repository.apache.org/content/repositories/orgapachecommons-218/commons-net/commons-net/3.1/
>> *commons-net-3.1-src.zip*. The checkstyle XML files are missing.
>>
>> Apache Maven 3.0.4 (r1232337; 2012-01-17 03:44:56-0500)
>> Maven home: C:\Java\apache-maven-3.0.4\bin\..
>> Java version: 1.6.0_29, vendor: Sun Microsystems Inc.
>> Java home: C:\Program Files\Java\jdk1.6.0_29\jre
>> Default locale: en_US, platform encoding: Cp1252
>> OS name: "windows 7", version: "6.1", arch: "amd64", family: "windows"
>>
>> [ERROR] Failed to execute goal
>> org.apache.maven.plugins:maven-site-plugin:3.0:site (default-site) on
>> project commons-net: Error during page generation: Error re
>> ndering Maven report: Failed during checkstyle execution: Unable to find
>> configuration file at location C:\temp\*commons-net-3.1-src/checkstyle.xm*l:
>> Could not fi
>> nd resource 'C:\temp\commons-net-3.1-src/checkstyle.xml'. -> [Help 1]
>> [ERROR]
>
> Strictly speaking the site build is not relevant to a release, but I
> agree the xml file should have been included.
>
>> I also get this warning at the begining which sounds related:
>>
>> [WARNING] Some problems were encountered while building the effective model
>> for commons-net:commons-net:jar:3.1
>> [WARNING] 'reporting.plugins.plugin.version' for
>> org.codehaus.mojo:findbugs-maven-plugin is missing. @ line 340, column 21
>> [WARNING]
>
> No, that is deliberate (and unrelated).
>
> I raised this very issue myself a while back and was told that the
> findbugs version should be omitted - I think the idea was that it then
> picks up the latest version.
>
> But if the consensus is to lock down all versions, I'm happy to change that.
>
>
>> Also, based on http://people.apache.org/~sebb/NET_3_1_RC1/site/:
>>
>> - Findbugs reports one issue. The code says:
>>
>> *//$FALL-THROUGH$ TODO change this if DEVICE_TYPE implemented
>>
>> *
>>
>> Is* $FALL-THROUGH$** *a special Findbugs comment designed to avoid avoid
>> the issue being reported?
>
> It's an Eclipse marker.
>
>> Is it supposed to cause the issue to not be reported?
>
> Yes, to avoid Eclipse reporting it.
>
> FIndbugs only checks class files, so warnings cannot be suppressed by 
> comments.
>
>>
>> - There are two checktyles reports! That is just plain weird.
>
> It seems one is the plain report and the other is an aggregate report.
> I don't know how that happened.

It's a bug in checkstyle 2.8

http://jira.codehaus.org/browse/MCHECKSTYLE-167

This is supposedly fixed in 2.9, but actually it's not.

>> - On the site, there is a Javadoc link for 1.4.1 and 3.0.1 but nothing for
>> 2.x, that seems inconsistent, not a blocker.
>
> 1.4 is the last of the Java 1.4-compatible releases; 2.x and 3.x are
> in the same release series, and both require Java 1.5
>
> We could perhaps drop 1.4 entirely.
>
>> - I wish the JIRAs had better titles, in the change report, I see "mlistDir
>> doc should be "MLSD" not "MSLD". Fixes
>> NET-441.
>> Thanks to consiliens." which does not tell me when protocol this deals
>> with. It would be nice if [net] tickets had a [protocol] prefix in the
>> title. Not a blocker.
>>
>> On Fri, Feb 10, 2012 at 9:27 PM, sebb  wrote:
>>
>>> This is a vote to release Apache Commons NET 3.1 based on RC1.
>>>
>>> [ ] +1 release it
>>> [ ] +0 go ahead I don't care
>>> [ ] -1 no, do not release it because...
>>>
>>> tag:
>>> https://svn.apache.org/repos/asf/commons/proper/net/tags/NET_3_1_RC1/(r1242993)
>>>
>>> site:
>>> http://people.apache.org/~sebb/NET_3_1_RC1/site/
>>>
>>> The Javadocs (1.4.1) link does not work, nor does the download link.
>>> These will be OK once the site is deployed.
>>>
>>> Source and binary archives (tar.gz and .zip) and Maven jars:
>>> https://repository.apache.org/content/repositories/orgapachecommons-218/
>>>
>>> [The tar.gz and .zip files will be moved to dist/commons/net before
>>> promoting the Maven jars to release status]
>>>
>>> Vote will remain open for at least 72 hours.
>>>
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>>> For additional commands, e-mail: dev-h...@commons.apache.org
>>>
>>>
>>
>>
>> --
>> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
>> JUnit in Action, 2nd Ed: http://bit.ly/ECvg0
>> Spring Batch in Action: http://bit.ly/bqpbCK
>> Blog: http://garygregory.wordpress.com
>> Home: http://garygregory.com/
>> Tweet! http://twitter.com/GaryGregory

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

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

2012-02-12 Thread 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 2 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: 1 min 42 secs
Command Line: /opt/maven2/bin/mvn --batch-mode -DskipTests=true --settings 
/srv/gump/public/workspace/apache-commons/digester/gump_mvn_settings.xml 
package 
[Working Directory: /srv/gump/public/workspace/apache-commons/digester]
M2_HOME: /opt/maven2
-
[INFO] Working directory: 
/srv/gump/public/workspace/apache-commons/digester/examples/xmlrules/addressbook
[INFO] Storing buildNumber: ?? at timestamp: 1329099074649
[INFO] Executing: /bin/sh -c cd 
/srv/gump/public/workspace/apache-commons/digester/examples/xmlrules/addressbook
 && svn --non-interactive info
[INFO] Working directory: 
/srv/gump/public/workspace/apache-commons/digester/examples/xmlrules/addressbook
[INFO] Storing buildScmBranch: UNKNOWN_BRANCH
[debug] execute contextualize
[INFO] [resources:resources {execution: default-resources}]
[INFO] Using 'iso-8859-1' encoding to copy filtered resources.
[INFO] skip non existing resourceDirectory 
/srv/gump/public/workspace/apache-commons/digester/examples/xmlrules/addressbook/src/main/resources
[INFO] Copying 0 resource to META-INF
[INFO] [compiler:compile {execution: default-compile}]
[INFO] Compiling 4 source files to 
/srv/gump/public/workspace/apache-commons/digester/examples/xmlrules/addressbook/target/classes
[INFO] [bundle:manifest {execution: bundle-manifest}]
[debug] execute contextualize
[INFO] [resources:testResources {execution: default-testResources}]
[INFO] Using 'iso-8859-1' encoding to copy filtered resources.
[INFO] skip non existing resourceDirectory 
/srv/gump/public/workspace/apache-commons/digester/examples/xmlrules/addressbook/src/test/resources
[INFO] Copying 0 resource to META-INF
[INFO] [compiler:testCompile {execution: default-testCompile}]
[INFO] No sources to compile
[INFO] [surefire:test {execution: default-test}]
[INFO] Tests are skipped.
[INFO] [jar:jar {execution: default-jar}]
[INFO] Building jar: 
/srv/gump/public/workspace/apache-commons/digester/examples/xmlrules/addressbook/target/commons-digester3-samples-xmlrules-addressbook-3.3-SNAPSHOT.jar
[INFO] 
[INFO] 
[INFO] 
[INFO] Reactor Summary:
[INFO] 
[INFO] Apache Commons Digester ... SUCCESS [41.536s]
[INFO] Apache Commons Digester :: Core ... SUCCESS [32.916s]
[INFO] Apache Commons Digester :: Annotations Processor .. SUCCESS [2.705s]
[INFO] Commons Digester :: Examples .. SUCCESS [0.456s]
[INFO] Apache Commons Digester :: Examples :: Annotations :: Atom  SUCCESS 
[3.283s]
[INFO] Apache Commons Digester :: Examples :: API :: Address Book  SUCCESS 
[2.525s]
[INFO] Apache Commons Digester :: Examples :: API :: Catalog . SUCCESS [2.026s]
[INFO] Apache Commons Digester :: Examples :: API :: DB Insert  SUCCESS [2.141s]
[INFO] Apache Commons Digester :: Examples :: API :: Document Markup  SUCCESS 
[1.881s]
[INFO] Apache Commons Digester :: Examples :: EDSL :: Atom ... SUCCESS [1.992s]
[INFO] Apache Commons Digester :: Examples :: Plugins :: Pipeline  SUCCESS 
[1.658s]
[INFO] Apache Commons Digester :: Examples :: RSS  SUCC

Re: [VOTE] Release Commons NET 3.1` based on RC1

2012-02-12 Thread sebb

On 12 February 2012 20:42, Oliver Heger  wrote:
> Hi,
>
> same problem with site generation here.
>
> In addition to Gary's findings I just noticed a very minor detail: The
> Built-By header in the manifest does not contain the actual user name, but
> just the text 'User'. Was this intended?

No, I forgot to provide the user name.

> Oliver
>
> Am 12.02.2012 17:09, schrieb Gary Gregory:
>
>> Hi Sebb,
>>
>> Sorry, -1: I get a build failure with my default set up using
>>
>> https://repository.apache.org/content/repositories/orgapachecommons-218/commons-net/commons-net/3.1/
>> *commons-net-3.1-src.zip*. The checkstyle XML files are missing.
>>
>> Apache Maven 3.0.4 (r1232337; 2012-01-17 03:44:56-0500)
>> Maven home: C:\Java\apache-maven-3.0.4\bin\..
>> Java version: 1.6.0_29, vendor: Sun Microsystems Inc.
>> Java home: C:\Program Files\Java\jdk1.6.0_29\jre
>> Default locale: en_US, platform encoding: Cp1252
>> OS name: "windows 7", version: "6.1", arch: "amd64", family: "windows"
>>
>> [ERROR] Failed to execute goal
>> org.apache.maven.plugins:maven-site-plugin:3.0:site (default-site) on
>> project commons-net: Error during page generation: Error re
>> ndering Maven report: Failed during checkstyle execution: Unable to find
>> configuration file at location
>> C:\temp\*commons-net-3.1-src/checkstyle.xm*l:
>> Could not fi
>> nd resource 'C:\temp\commons-net-3.1-src/checkstyle.xml'. ->  [Help 1]
>> [ERROR]
>>
>> I also get this warning at the begining which sounds related:
>>
>> [WARNING] Some problems were encountered while building the effective
>> model
>> for commons-net:commons-net:jar:3.1
>> [WARNING] 'reporting.plugins.plugin.version' for
>> org.codehaus.mojo:findbugs-maven-plugin is missing. @ line 340, column 21
>> [WARNING]
>>
>> Also, based on http://people.apache.org/~sebb/NET_3_1_RC1/site/:
>>
>> - Findbugs reports one issue. The code says:
>>
>> *//$FALL-THROUGH$ TODO change this if DEVICE_TYPE implemented
>>
>> *
>>
>> Is* $FALL-THROUGH$** *a special Findbugs comment designed to avoid avoid
>> the issue being reported? Is it supposed to cause the issue to not be
>> reported?
>>
>> - There are two checktyles reports! That is just plain weird.
>>
>> - On the site, there is a Javadoc link for 1.4.1 and 3.0.1 but nothing for
>> 2.x, that seems inconsistent, not a blocker.
>> - I wish the JIRAs had better titles, in the change report, I see
>> "mlistDir
>> doc should be "MLSD" not "MSLD". Fixes
>> NET-441.
>> Thanks to consiliens." which does not tell me when protocol this deals
>> with. It would be nice if [net] tickets had a [protocol] prefix in the
>> title. Not a blocker.
>>
>> On Fri, Feb 10, 2012 at 9:27 PM, sebb  wrote:
>>
>>> This is a vote to release Apache Commons NET 3.1 based on RC1.
>>>
>>> [ ] +1 release it
>>> [ ] +0 go ahead I don't care
>>> [ ] -1 no, do not release it because...
>>>
>>> tag:
>>>
>>> https://svn.apache.org/repos/asf/commons/proper/net/tags/NET_3_1_RC1/(r1242993)
>>>
>>> site:
>>> http://people.apache.org/~sebb/NET_3_1_RC1/site/
>>>
>>> The Javadocs (1.4.1) link does not work, nor does the download link.
>>> These will be OK once the site is deployed.
>>>
>>> Source and binary archives (tar.gz and .zip) and Maven jars:
>>> https://repository.apache.org/content/repositories/orgapachecommons-218/
>>>
>>> [The tar.gz and .zip files will be moved to dist/commons/net before
>>> promoting the Maven jars to release status]
>>>
>>> Vote will remain open for at least 72 hours.
>>>
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>>> For additional commands, e-mail: dev-h...@commons.apache.org
>>>
>>>
>>
>>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>

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

Re: [VOTE] Release Commons NET 3.1` based on RC1

2012-02-12 Thread sebb

On 12 February 2012 16:09, Gary Gregory  wrote:
> Hi Sebb,
>
> Sorry, -1: I get a build failure with my default set up using
> https://repository.apache.org/content/repositories/orgapachecommons-218/commons-net/commons-net/3.1/
> *commons-net-3.1-src.zip*. The checkstyle XML files are missing.
>
> Apache Maven 3.0.4 (r1232337; 2012-01-17 03:44:56-0500)
> Maven home: C:\Java\apache-maven-3.0.4\bin\..
> Java version: 1.6.0_29, vendor: Sun Microsystems Inc.
> Java home: C:\Program Files\Java\jdk1.6.0_29\jre
> Default locale: en_US, platform encoding: Cp1252
> OS name: "windows 7", version: "6.1", arch: "amd64", family: "windows"
>
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-site-plugin:3.0:site (default-site) on
> project commons-net: Error during page generation: Error re
> ndering Maven report: Failed during checkstyle execution: Unable to find
> configuration file at location C:\temp\*commons-net-3.1-src/checkstyle.xm*l:
> Could not fi
> nd resource 'C:\temp\commons-net-3.1-src/checkstyle.xml'. -> [Help 1]
> [ERROR]

Strictly speaking the site build is not relevant to a release, but I
agree the xml file should have been included.

> I also get this warning at the begining which sounds related:
>
> [WARNING] Some problems were encountered while building the effective model
> for commons-net:commons-net:jar:3.1
> [WARNING] 'reporting.plugins.plugin.version' for
> org.codehaus.mojo:findbugs-maven-plugin is missing. @ line 340, column 21
> [WARNING]

No, that is deliberate (and unrelated).

I raised this very issue myself a while back and was told that the
findbugs version should be omitted - I think the idea was that it then
picks up the latest version.

But if the consensus is to lock down all versions, I'm happy to change that.


> Also, based on http://people.apache.org/~sebb/NET_3_1_RC1/site/:
>
> - Findbugs reports one issue. The code says:
>
> *//$FALL-THROUGH$ TODO change this if DEVICE_TYPE implemented
>
> *
>
> Is* $FALL-THROUGH$** *a special Findbugs comment designed to avoid avoid
> the issue being reported?

It's an Eclipse marker.

> Is it supposed to cause the issue to not be reported?

Yes, to avoid Eclipse reporting it.

FIndbugs only checks class files, so warnings cannot be suppressed by comments.

>
> - There are two checktyles reports! That is just plain weird.

It seems one is the plain report and the other is an aggregate report.
I don't know how that happened.

> - On the site, there is a Javadoc link for 1.4.1 and 3.0.1 but nothing for
> 2.x, that seems inconsistent, not a blocker.

1.4 is the last of the Java 1.4-compatible releases; 2.x and 3.x are
in the same release series, and both require Java 1.5

We could perhaps drop 1.4 entirely.

> - I wish the JIRAs had better titles, in the change report, I see "mlistDir
> doc should be "MLSD" not "MSLD". Fixes
> NET-441.
> Thanks to consiliens." which does not tell me when protocol this deals
> with. It would be nice if [net] tickets had a [protocol] prefix in the
> title. Not a blocker.
>
> On Fri, Feb 10, 2012 at 9:27 PM, sebb  wrote:
>
>> This is a vote to release Apache Commons NET 3.1 based on RC1.
>>
>> [ ] +1 release it
>> [ ] +0 go ahead I don't care
>> [ ] -1 no, do not release it because...
>>
>> tag:
>> https://svn.apache.org/repos/asf/commons/proper/net/tags/NET_3_1_RC1/(r1242993)
>>
>> site:
>> http://people.apache.org/~sebb/NET_3_1_RC1/site/
>>
>> The Javadocs (1.4.1) link does not work, nor does the download link.
>> These will be OK once the site is deployed.
>>
>> Source and binary archives (tar.gz and .zip) and Maven jars:
>> https://repository.apache.org/content/repositories/orgapachecommons-218/
>>
>> [The tar.gz and .zip files will be moved to dist/commons/net before
>> promoting the Maven jars to release status]
>>
>> Vote will remain open for at least 72 hours.
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> For additional commands, e-mail: dev-h...@commons.apache.org
>>
>>
>
>
> --
> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
> JUnit in Action, 2nd Ed: http://bit.ly/ECvg0
> Spring Batch in Action: http://bit.ly/bqpbCK
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory

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

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

2012-02-12 Thread 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-email has an issue affecting its community integration.
This issue affects 1 projects,
 and has been outstanding for 5 runs.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
- commons-email :  Commons Email Package


Full details are available at:
http://vmgump.apache.org/gump/public/apache-commons/commons-email/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-email-*[0-9T].jar] identifier set to project 
name
 -DEBUG- (Apache Gump generated) Apache Maven Settings in: 
/srv/gump/public/workspace/apache-commons/email/gump_mvn_settings.xml
 -INFO- Failed with reason build failed
 -DEBUG- Maven POM in: /srv/gump/public/workspace/apache-commons/email/pom.xml
 -DEBUG- Extracted fallback artifacts from Gump Repository



The following work was performed:
http://vmgump.apache.org/gump/public/apache-commons/commons-email/gump_work/build_apache-commons_commons-email.html
Work Name: build_apache-commons_commons-email (Type: Build)
Work ended in a state of : Failed
Elapsed: 1 min 5 secs
Command Line: /opt/maven2/bin/mvn --batch-mode 
-Dmaven.jar.mail=/srv/gump/packages/javamail-1.4/mail.jar --settings 
/srv/gump/public/workspace/apache-commons/email/gump_mvn_settings.xml package 
[Working Directory: /srv/gump/public/workspace/apache-commons/email]
M2_HOME: /opt/maven2
-
Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.019 sec
Running org.apache.commons.mail.EmailLiveTest
Tests run: 7, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.234 sec
Running org.apache.commons.mail.MultiPartEmailTest
Tests run: 10, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.316 sec
Running org.apache.commons.mail.resolver.DataSourceFileResolverTest
Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0 sec
Running org.apache.commons.mail.resolver.DataSourceClassPathResolverTest
Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.009 sec
Running org.apache.commons.mail.resolver.DataSourceCompositeResolverTest
Tests run: 2, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.028 sec <<< 
FAILURE!
Running org.apache.commons.mail.resolver.DataSourceUrlResolverTest
Tests run: 3, Failures: 0, Errors: 2, Skipped: 0, Time elapsed: 0.009 sec <<< 
FAILURE!
Running org.apache.commons.mail.EmailTest
Tests run: 41, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.147 sec
Running org.apache.commons.mail.InvalidAddressTest
Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.008 sec
Running org.apache.commons.mail.ImageHtmlEmailTest
Tests run: 21, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 30.918 sec
Running org.apache.commons.mail.EmailAttachmentTest
Tests run: 5, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.109 sec
Running org.apache.commons.mail.InvalidInternetAddressTest
Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.007 sec
Running org.apache.commons.mail.util.MimeMessageParserTest
Tests run: 5, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.044 sec
Running org.apache.commons.mail.HtmlEmailTest
Tests run: 13, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.187 sec

Results :

Tests in error: 
  
testResolvingFilesLenient(org.apache.commons.mail.resolver.DataSourceCompositeResolverTest)
  
testResolvingHttpLenient(org.apache.commons.mail.resolver.DataSourceUrlResolverTest)
  
testResolvingHttpNonLenient(org.apache.commons.mail.resolver.DataSourceUrlResolverTest):
 Connection reset

Tests run: 123, Failures: 0, Errors: 3, Skipped: 0

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

Please refer to 
/srv/gump/public/workspace/apache-commons/email/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 3 seconds
[INFO] Finished at: Mon Feb 13 01:42:00 UTC 2012
[INFO] Final Memory: 43M/103M
[INFO] 
-

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

===

Re: [DISCUSS][POOL] Logging options for Pool2

2012-02-12 Thread Konstantin Kolinko

2012/2/13 Mark Thomas :
>
> General
> - Logging in pool, if any, should be minimal
>

Two general questions:
When there are several pools,
- is it possible to discern log messages from different pools?
- is it possible to control logging level for a single pool, or all
pools have the same logging configuration? E.g. to enable debug
logging for a single pool only (if debug logging is ever implemented
there).

>
> What do folks think to the following solution:
> - make logging of factory exceptions a factory responsibility - clearly
> documented in the JavaDoc for POOL2
> - add some JMX stats to POOL2 for number of destroy / passivate /
> activate exceptions
> - make the last n (10?) exceptions of each type accessible via JMX for POOL2
> ?
>

Overall this proposal looks good, but there is known caveat with
keeping Exception instances in memory:  Their stacktrace data is known
to pin classloaders in memory, preventing them from being garbage
collected and thus causing PermGen memory leaks in web applications.

This problem was reproduced in this Tomcat issue:
https://issues.apache.org/bugzilla/show_bug.cgi?id=50460
Discussion:
http://marc.info/?l=tomcat-dev&m=129211856426188&w=2

A workaround might be to print stacktraces as strings and keep the
strings in memory, but it may be time-consuming. The good point though
is that the time to print those exceptions to strings is comparable
with the one spent when printing them to a log file.

Best regards,
Konstantin Kolinko

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

Re: [DISCUSS][POOL] Logging options for Pool2

2012-02-12 Thread Mark Thomas

Thanks to all who contributed to this thread. I thought it might be
useful to summarize the discussion so far.

Preferences have been expressed for:
- java.util.logging (jul)
- commons logging   (cl)
- SLF4J

General
- Logging in pool, if any, should be minimal

jul
- Anything other than jul adds a new dependency
- not a good choice for JavaEE environments
- very inefficient to bridge to something else

cl
- has a minimal API
- fine for JavaEE

slf4j
- fine for JavaEE


Revisiting the issue (POOL-131) that triggered this, an argument could
be made that this is a DBCP problem rather than a POOL one since DBCP is
throwing a factory exception and not logging it. See POOL-142 for why
this is a factory problem. However, all that does is move the same
problem to DBCP.

What do folks think to the following solution:
- make logging of factory exceptions a factory responsibility - clearly
documented in the JavaDoc for POOL2
- add some JMX stats to POOL2 for number of destroy / passivate /
activate exceptions
- make the last n (10?) exceptions of each type accessible via JMX for POOL2
?

Mark

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

Re: [Graph] On graph weight type(s)

2012-02-12 Thread Claudio Squarcella


Hi Simone,


the patch you mentioned was something I would have asked you, before or later :P


I know I can read your mind :)


Since we are on topic: is there any particular reason why Zero.zero()
can not be part of Semigroup interface? Or better: is there any
benefit we can get from keeping Zero and Semigroup separated?


basically the answer is in the following equation:
Monoid = Semigroup + Zero
And also:
OrderedMonoid = Semigroup + Zero + Comparator

The reason why we built all the stack was to allow fine granularity when 
defining properties of weights. E.g. it might happen for some reason 
that we need to sum weights without needing to know their "zero" value, 
or viceversa. In our current implementations OrderedMonoid takes most of 
the space (as expected), but also Zero and Monoid are explicitly used.


Ciao,
Claudio

--
Claudio Squarcella
PhD student at Roma Tre University
http://www.dia.uniroma3.it/~squarcel
http://squarcella.com/


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

Re: [Graph] On graph weight type(s)

2012-02-12 Thread Simone Tripodi

Hola Claudio,

the patch you mentioned was something I would have asked you, before or later :P

Since we are on topic: is there any particular reason why Zero.zero()
can not be part of Semigroup interface? Or better: is there any
benefit we can get from keeping Zero and Semigroup separated?

TIA,
-Simo

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



On Sun, Feb 12, 2012 at 11:36 PM, Claudio Squarcella
 wrote:
> Hi,
>
>
>>> * the mapping between primitive types and their respective default
>>>   *Operations is known and kept somewhere (abstract class, etc);
>>> * each algorithm specifies only once the set of primitive types that
>>>   it accepts;
>>> * with a bit of magic (?) we combine the above to provide shortcuts to
>>>   the user.
>>
>> +1
>>
>> I think that a mapper can be useful.
>> we can create a default mapper between primitives and *Operations and add
>> a void API like that
>> findMaxFlow( graph ).from( a ).to( g ).applying( void ).
>> we can choose the correct Operation mappimng directly on the default
>> constructor using our mapper.
>>
>> so for the primitives Integer, Double etc, the user doesn't  have to
>> specify anything.
>
>
> I thought about something similar. But I finally see two downsides:
>
>  * we would need to use reflection for generics or some better
>   alternative to actually understand the generic type of weight and
>   map it to the appropriate *Operations,
>  * we should throw an exception when non-primitive weights are
>   incorrectly passed without a handler.
>
> Now that I have a clearer picture in mind I'm almost convinced to give up...
>
> Anyway, expect a patch soon from me that at least incorporates suggestions
> on new names for primitive implementations and variable names ;)
>
> Ciao,
>
> Claudio
>
> --
> Claudio Squarcella
> PhD student at Roma Tre University
> http://www.dia.uniroma3.it/~squarcel
> http://squarcella.com/
>
>
> -
> 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: [Graph] On graph weight type(s)

2012-02-12 Thread Claudio Squarcella


Hi,


* the mapping between primitive types and their respective default
   *Operations is known and kept somewhere (abstract class, etc);
* each algorithm specifies only once the set of primitive types that
   it accepts;
* with a bit of magic (?) we combine the above to provide shortcuts to
   the user.

+1

I think that a mapper can be useful.
we can create a default mapper between primitives and *Operations and add a 
void API like that
findMaxFlow( graph ).from( a ).to( g ).applying( void ).
we can choose the correct Operation mappimng directly on the default 
constructor using our mapper.

so for the primitives Integer, Double etc, the user doesn't  have to specify 
anything.


I thought about something similar. But I finally see two downsides:

 * we would need to use reflection for generics or some better
   alternative to actually understand the generic type of weight and
   map it to the appropriate *Operations,
 * we should throw an exception when non-primitive weights are
   incorrectly passed without a handler.

Now that I have a clearer picture in mind I'm almost convinced to give up...

Anyway, expect a patch soon from me that at least incorporates 
suggestions on new names for primitive implementations and variable names ;)


Ciao,
Claudio

--
Claudio Squarcella
PhD student at Roma Tre University
http://www.dia.uniroma3.it/~squarcel
http://squarcella.com/


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

[continuum] BUILD FAILURE: Apache Commons - Apache Commons Digester - Default Maven 2 Build Definition (Java 1.5)

2012-02-12 Thread Continuum@vmbuild

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

Build statistics:
  State: Failed
  Previous State: Ok
  Started at: Sun 12 Feb 2012 21:40:59 +
  Finished at: Sun 12 Feb 2012 21:41:43 +
  Total time: 44s
  Build Trigger: Schedule
  Build Number: 162
  Exit code: 1
  Building machine hostname: vmbuild
  Operating system : Linux(unknown)
  Java Home version : 
  java version "1.6.0_30"
  Java(TM) SE Runtime Environment (build 1.6.0_30-b12)
  Java HotSpot(TM) 64-Bit Server VM (build 20.5-b03, mixed mode)

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


SCM Changes:

Changed: simonetripodi @ Sun 12 Feb 2012 20:32:38 +
Comment: restored the samples parent pom - too much common stuff, it doesn't 
make any sense replicating them for each sample. Samples are not deployed nor 
assembled
Files changed:
  /commons/proper/digester/trunk/examples/annotations/atom/pom.xml ( 1243318 )
  /commons/proper/digester/trunk/examples/api/addressbook/pom.xml ( 1243318 )
  /commons/proper/digester/trunk/examples/api/catalog/pom.xml ( 1243318 )
  /commons/proper/digester/trunk/examples/api/dbinsert/pom.xml ( 1243318 )
  /commons/proper/digester/trunk/examples/api/document-markup/pom.xml ( 1243318 
)
  /commons/proper/digester/trunk/examples/edsl/atom/pom.xml ( 1243318 )
  /commons/proper/digester/trunk/examples/plugins/pipeline/pom.xml ( 1243318 )
  /commons/proper/digester/trunk/examples/pom.xml ( 1243318 )
  /commons/proper/digester/trunk/examples/rss/pom.xml ( 1243318 )
  /commons/proper/digester/trunk/examples/xmlrules/addressbook/pom.xml ( 
1243318 )
  /commons/proper/digester/trunk/pom.xml ( 1243318 )

Changed: simonetripodi @ Sun 12 Feb 2012 21:08:04 +
Comment: initial checkin of DigesterAnnotationsProcessor stuff
Files changed:
  /commons/proper/digester/trunk/annotations-processor/src/main/java/org ( 
124 )
  /commons/proper/digester/trunk/annotations-processor/src/main/java/org/apache 
( 124 )
  
/commons/proper/digester/trunk/annotations-processor/src/main/java/org/apache/commons
 ( 124 )
  
/commons/proper/digester/trunk/annotations-processor/src/main/java/org/apache/commons/digester3
 ( 124 )
  
/commons/proper/digester/trunk/annotations-processor/src/main/java/org/apache/commons/digester3/annotations
 ( 124 )
  
/commons/proper/digester/trunk/annotations-processor/src/main/java/org/apache/commons/digester3/annotations/processor
 ( 124 )
  
/commons/proper/digester/trunk/annotations-processor/src/main/java/org/apache/commons/digester3/annotations/processor/DigesterAnnotationsProcessor.java
 ( 124 )
  
/commons/proper/digester/trunk/annotations-processor/src/main/java/org/apache/commons/digester3/annotations/processor/package-info.java
 ( 124 )


Dependencies Changes:

No dependencies changed



Build Definition:

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


Test Summary:

Tests: 207
Failures: 0
Errors: 0
Success Rate: 100
Total time: 2.235





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

Re: [Graph] On graph weight type(s)

2012-02-12 Thread Simone Tripodi

Hi *,

while the idea is fine, it is not clear to me how you intend
implementing it. Please fill an issue and attach a patch so we can
discuss also about the "how" and not only "what" :)

best,
-Simo

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



On Sun, Feb 12, 2012 at 10:26 PM, Marco Speranza
 wrote:
> Hi guys,
>
>> * the mapping between primitive types and their respective default
>>   *Operations is known and kept somewhere (abstract class, etc);
>> * each algorithm specifies only once the set of primitive types that
>>   it accepts;
>> * with a bit of magic (?) we combine the above to provide shortcuts to
>>   the user.
>
> +1
>
> I think that a mapper can be useful.
> we can create a default mapper between primitives and *Operations and add a 
> void API like that
> findMaxFlow( graph ).from( a ).to( g ).applying( void ).
> we can choose the correct Operation mappimng directly on the default 
> constructor using our mapper.
>
> so for the primitives Integer, Double etc, the user doesn't  have to specify 
> anything.
>
> for a graph that uses  a custom weight's type,  the user can use the 
> findMaxFlow( graph ).from( a ).to( g ).applying( OrderMonoid ) ) 
> API.
>
> WDYT ?
>
> ciao
>
>
> --
> Marco Speranza 
>
> Flickr: http://www.flickr.com/photos/marcosperanza79/
> Google Code: http://code.google.com/u/marco.speranza79/
>
>
>
>
> Il giorno 12/feb/2012, alle ore 21:20, Claudio Squarcella ha scritto:
>
>> Hi Simone,
>>
 Would it be so terrible to maintain such redundancy?
>>> IMHO, yes, because:
>>>
>>>  * it has to be applied in each class of algorithms we support;
>>>
>>>  * switching to proposed APIs, would proliferate that APIs in each 
>>> algorithm;
>>>
>>>  * weight types are driven by generics, so users cannot bind wrong
>>> weight monoid already at compile time.
>>>
>>> more proposals? :)
>>
>> ok fair enough, you were quite convincing :)
>>
>> Before giving up, one more alternative:
>>
>> * the mapping between primitive types and their respective default
>>   *Operations is known and kept somewhere (abstract class, etc);
>> * each algorithm specifies only once the set of primitive types that
>>   it accepts;
>> * with a bit of magic (?) we combine the above to provide shortcuts to
>>   the user.
>>
>> Note: I don't want to over-engineer, I would just like the user not to 
>> specify default *Operations, because that is also redundant from his/her 
>> point of view.
>>
>> Ciao and thanks,
>> Claudio
>>
>> --
>> Claudio Squarcella
>> PhD student at Roma Tre University
>> http://www.dia.uniroma3.it/~squarcel
>> http://squarcella.com/
>>
>>
>> -
>> 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: [SANDBOX][BeanUtils2] Discussion about cloneBean(), copyProperties() and cast() on DefaultBeanAccessor

2012-02-12 Thread Simone Tripodi

Hi Bene,

>
>
> yes I did (as I said ;-). So I guess, that we can implement it the way I
> said, but make sure Maps will be handled the way they were in BeanUtils1.
>

that would be acceptable since users are already used to that behavior

>
> Any thoughts about what James suggested? Just having to declare
> ReflectiveOperationException would be nice to clean up the interface. But I
> guess few people are already on Java 7. So better stay at Java 6?
>

I'm for keeping at least JDK6 compatibility

-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: [Graph] On graph weight type(s)

2012-02-12 Thread Marco Speranza

Hi guys,

> * the mapping between primitive types and their respective default
>   *Operations is known and kept somewhere (abstract class, etc);
> * each algorithm specifies only once the set of primitive types that
>   it accepts;
> * with a bit of magic (?) we combine the above to provide shortcuts to
>   the user.

+1

I think that a mapper can be useful.
we can create a default mapper between primitives and *Operations and add a 
void API like that 
findMaxFlow( graph ).from( a ).to( g ).applying( void ).
we can choose the correct Operation mappimng directly on the default 
constructor using our mapper.

so for the primitives Integer, Double etc, the user doesn't  have to specify 
anything.

for a graph that uses  a custom weight's type,  the user can use the 
findMaxFlow( graph ).from( a ).to( g ).applying( OrderMonoid ) ) API.

WDYT ?

ciao


--
Marco Speranza 

Flickr: http://www.flickr.com/photos/marcosperanza79/
Google Code: http://code.google.com/u/marco.speranza79/




Il giorno 12/feb/2012, alle ore 21:20, Claudio Squarcella ha scritto:

> Hi Simone,
> 
>>> Would it be so terrible to maintain such redundancy?
>> IMHO, yes, because:
>> 
>>  * it has to be applied in each class of algorithms we support;
>> 
>>  * switching to proposed APIs, would proliferate that APIs in each algorithm;
>> 
>>  * weight types are driven by generics, so users cannot bind wrong
>> weight monoid already at compile time.
>> 
>> more proposals? :)
> 
> ok fair enough, you were quite convincing :)
> 
> Before giving up, one more alternative:
> 
> * the mapping between primitive types and their respective default
>   *Operations is known and kept somewhere (abstract class, etc);
> * each algorithm specifies only once the set of primitive types that
>   it accepts;
> * with a bit of magic (?) we combine the above to provide shortcuts to
>   the user.
> 
> Note: I don't want to over-engineer, I would just like the user not to 
> specify default *Operations, because that is also redundant from his/her 
> point of view.
> 
> Ciao and thanks,
> Claudio
> 
> -- 
> Claudio Squarcella
> PhD student at Roma Tre University
> http://www.dia.uniroma3.it/~squarcel
> http://squarcella.com/
> 
> 
> -
> 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: [SANDBOX][BeanUtils2] Discussion about cloneBean(), copyProperties() and cast() on DefaultBeanAccessor

2012-02-12 Thread Benedikt Ritter


Am 12.02.2012 18:28, schrieb Simone Tripodi:

Hi Bene,



Hi!



[...]

copyProperties() can be implemented likewise. Is that really all we have to
do, or am I missing something? I've looked at BeanUtils1 and they are
handling Maps a little differently by coping all entries. So I guess we have
to do the same (to keep the user experience).



did you already check older BeanUtils?


yes I did (as I said ;-). So I guess, that we can implement it the way I 
said, but make sure Maps will be handled the way they were in BeanUtils1.





Another thing I was winking about is cast(). I don't understand how that is
supposed to work. Can it be, that there is an input parameter missing? To
make it work it has to be:

public  V cast(Class  targetType);



no, it doesn't "has to be", even if a little weird it doesn't require
the Class type. Have a look at[1] a give a try please with current
codebase ;)


Ah, okay... :) I've the latest code base checked out. So that can stay 
the way it is.


Any thoughts about what James suggested? Just having to declare 
ReflectiveOperationException would be nice to clean up the interface. 
But I guess few people are already on Java 7. So better stay at Java 6?


Ciao!
Benedikt



Alles gute,
-Simo

[1] 
http://stackoverflow.com/questions/338887/java-generics-generic-type-defined-as-return-type-only

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: [VOTE] Release Commons NET 3.1` based on RC1

2012-02-12 Thread Oliver Heger


Hi,

same problem with site generation here.

In addition to Gary's findings I just noticed a very minor detail: The 
Built-By header in the manifest does not contain the actual user name, 
but just the text 'User'. Was this intended?


Oliver

Am 12.02.2012 17:09, schrieb Gary Gregory:

Hi Sebb,

Sorry, -1: I get a build failure with my default set up using
https://repository.apache.org/content/repositories/orgapachecommons-218/commons-net/commons-net/3.1/
*commons-net-3.1-src.zip*. The checkstyle XML files are missing.

Apache Maven 3.0.4 (r1232337; 2012-01-17 03:44:56-0500)
Maven home: C:\Java\apache-maven-3.0.4\bin\..
Java version: 1.6.0_29, vendor: Sun Microsystems Inc.
Java home: C:\Program Files\Java\jdk1.6.0_29\jre
Default locale: en_US, platform encoding: Cp1252
OS name: "windows 7", version: "6.1", arch: "amd64", family: "windows"

[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-site-plugin:3.0:site (default-site) on
project commons-net: Error during page generation: Error re
ndering Maven report: Failed during checkstyle execution: Unable to find
configuration file at location C:\temp\*commons-net-3.1-src/checkstyle.xm*l:
Could not fi
nd resource 'C:\temp\commons-net-3.1-src/checkstyle.xml'. ->  [Help 1]
[ERROR]

I also get this warning at the begining which sounds related:

[WARNING] Some problems were encountered while building the effective model
for commons-net:commons-net:jar:3.1
[WARNING] 'reporting.plugins.plugin.version' for
org.codehaus.mojo:findbugs-maven-plugin is missing. @ line 340, column 21
[WARNING]

Also, based on http://people.apache.org/~sebb/NET_3_1_RC1/site/:

- Findbugs reports one issue. The code says:

*//$FALL-THROUGH$ TODO change this if DEVICE_TYPE implemented

*

Is* $FALL-THROUGH$** *a special Findbugs comment designed to avoid avoid
the issue being reported? Is it supposed to cause the issue to not be
reported?

- There are two checktyles reports! That is just plain weird.

- On the site, there is a Javadoc link for 1.4.1 and 3.0.1 but nothing for
2.x, that seems inconsistent, not a blocker.
- I wish the JIRAs had better titles, in the change report, I see "mlistDir
doc should be "MLSD" not "MSLD". Fixes
NET-441.
Thanks to consiliens." which does not tell me when protocol this deals
with. It would be nice if [net] tickets had a [protocol] prefix in the
title. Not a blocker.

On Fri, Feb 10, 2012 at 9:27 PM, sebb  wrote:


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

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

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

site:
http://people.apache.org/~sebb/NET_3_1_RC1/site/

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

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

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

Vote will remain open for at least 72 hours.

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








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

Re: [Graph] On graph weight type(s)

2012-02-12 Thread Claudio Squarcella


Hi Simone,


Would it be so terrible to maintain such redundancy?

IMHO, yes, because:

  * it has to be applied in each class of algorithms we support;

  * switching to proposed APIs, would proliferate that APIs in each algorithm;

  * weight types are driven by generics, so users cannot bind wrong
weight monoid already at compile time.

more proposals? :)


ok fair enough, you were quite convincing :)

Before giving up, one more alternative:

 * the mapping between primitive types and their respective default
   *Operations is known and kept somewhere (abstract class, etc);
 * each algorithm specifies only once the set of primitive types that
   it accepts;
 * with a bit of magic (?) we combine the above to provide shortcuts to
   the user.

Note: I don't want to over-engineer, I would just like the user not to 
specify default *Operations, because that is also redundant from his/her 
point of view.


Ciao and thanks,
Claudio

--
Claudio Squarcella
PhD student at Roma Tre University
http://www.dia.uniroma3.it/~squarcel
http://squarcella.com/


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

Re: [Graph] On graph weight type(s)

2012-02-12 Thread Simone Tripodi

Hola,

> Would it be so terrible to maintain such redundancy?

IMHO, yes, because:

 * it has to be applied in each class of algorithms we support;

 * switching to proposed APIs, would proliferate that APIs in each algorithm;

 * weight types are driven by generics, so users cannot bind wrong
weight monoid already at compile time.

more proposals? :)

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: [SANDBOX][BeanUtils2] Discussion about cloneBean(), copyProperties() and cast() on DefaultBeanAccessor

2012-02-12 Thread Simone Tripodi

Hi Bene,

>
> public B cloneBean()
>    throws aLotOfExceptions ;-)
> {
>    @SuppressWarnings( "unchecked" )
>    B clone = (B) bean.getClass().newInstance();
>    DefaultBeanAccessor cloneAccessor = new DefaultBeanAccessor( clone
> );
>    cloneAccessor.populate( this.describe() );
>    return clone;
> }
>
> copyProperties() can be implemented likewise. Is that really all we have to
> do, or am I missing something? I've looked at BeanUtils1 and they are
> handling Maps a little differently by coping all entries. So I guess we have
> to do the same (to keep the user experience).
>

did you already check older BeanUtils?

> Another thing I was winking about is cast(). I don't understand how that is
> supposed to work. Can it be, that there is an input parameter missing? To
> make it work it has to be:
>
> public  V cast(Class targetType);
>

no, it doesn't "has to be", even if a little weird it doesn't require
the Class type. Have a look at[1] a give a try please with current
codebase ;)

Alles gute,
-Simo

[1] 
http://stackoverflow.com/questions/338887/java-generics-generic-type-defined-as-return-type-only

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: [Graph] On graph weight type(s)

2012-02-12 Thread Claudio Squarcella


Hello Marco,


I understand and agree with you about your doubts - I don't have a
strong idea, anyway I wouldn't take the *Handler as first choice,
since it does not drive users to an event-handler alike programming
model, rather *Operations makes more sense...


+1


c00l :)

Furthermore I think that name of classes are congruent. In my opinion 
Monoid, OrderMonoid and Semigroup are the right names


I agree.

findMaxFlow( graph ).from( a ).to( g 
).applyingEdmondsKarp.withWeightOperation( new IntegerOperation() ) or 
something like that.


I would be more radical (chic) and add one shortcut for each primitive 
weight type allowed, e.g:
findMaxFlow( graph ).from( a ).to( g 
).applyingEdmondsKarp().usingWeightsAsIntegers()
findMaxFlow( graph ).from( a ).to( g 
).applyingEdmondsKarp().usingWeightsAsDoubles()

[...]

I know it's damn redundant. It would be nice to have a better shortcut 
to automagically use primitive weight operations when available and 
require an explicit *Operations otherwise, but it's not an easy task 
(not for me at least).


Note also that some algorithms may impose limits on the actual types 
(e.g. Ford-Fulkerson may not terminate with irrational numbers... 
although with floating point representation I guess we never face that 
risk), so creating explicit shortcuts could also reflect such constraints.


Would it be so terrible to maintain such redundancy?

--
Claudio Squarcella
PhD student at Roma Tre University
http://www.dia.uniroma3.it/~squarcel
http://squarcella.com/


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

Re: [VOTE] Release Commons NET 3.1` based on RC1

2012-02-12 Thread Gary Gregory

Hi Sebb,

Sorry, -1: I get a build failure with my default set up using
https://repository.apache.org/content/repositories/orgapachecommons-218/commons-net/commons-net/3.1/
*commons-net-3.1-src.zip*. The checkstyle XML files are missing.

Apache Maven 3.0.4 (r1232337; 2012-01-17 03:44:56-0500)
Maven home: C:\Java\apache-maven-3.0.4\bin\..
Java version: 1.6.0_29, vendor: Sun Microsystems Inc.
Java home: C:\Program Files\Java\jdk1.6.0_29\jre
Default locale: en_US, platform encoding: Cp1252
OS name: "windows 7", version: "6.1", arch: "amd64", family: "windows"

[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-site-plugin:3.0:site (default-site) on
project commons-net: Error during page generation: Error re
ndering Maven report: Failed during checkstyle execution: Unable to find
configuration file at location C:\temp\*commons-net-3.1-src/checkstyle.xm*l:
Could not fi
nd resource 'C:\temp\commons-net-3.1-src/checkstyle.xml'. -> [Help 1]
[ERROR]

I also get this warning at the begining which sounds related:

[WARNING] Some problems were encountered while building the effective model
for commons-net:commons-net:jar:3.1
[WARNING] 'reporting.plugins.plugin.version' for
org.codehaus.mojo:findbugs-maven-plugin is missing. @ line 340, column 21
[WARNING]

Also, based on http://people.apache.org/~sebb/NET_3_1_RC1/site/:

- Findbugs reports one issue. The code says:

*//$FALL-THROUGH$ TODO change this if DEVICE_TYPE implemented

*

Is* $FALL-THROUGH$** *a special Findbugs comment designed to avoid avoid
the issue being reported? Is it supposed to cause the issue to not be
reported?

- There are two checktyles reports! That is just plain weird.

- On the site, there is a Javadoc link for 1.4.1 and 3.0.1 but nothing for
2.x, that seems inconsistent, not a blocker.
- I wish the JIRAs had better titles, in the change report, I see "mlistDir
doc should be "MLSD" not "MSLD". Fixes
NET-441.
Thanks to consiliens." which does not tell me when protocol this deals
with. It would be nice if [net] tickets had a [protocol] prefix in the
title. Not a blocker.

On Fri, Feb 10, 2012 at 9:27 PM, sebb  wrote:

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

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

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

2012-02-12 Thread 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.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
- commons-digester3 :  XML to Java Object Configuration
- commons-digester3-test :  Apache Commons


Full details are available at:

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

That said, some information snippets are provided here.

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



The following work was performed:
http://vmgump.apache.org/gump/public/apache-commons/commons-digester3/gump_work/build_apache-commons_commons-digester3.html
Work Name: build_apache-commons_commons-digester3 (Type: Build)
Work ended in a state of : Failed
Elapsed: 1 min 14 secs
Command Line: /opt/maven2/bin/mvn --batch-mode -DskipTests=true --settings 
/srv/gump/public/workspace/apache-commons/digester/gump_mvn_settings.xml 
package 
[Working Directory: /srv/gump/public/workspace/apache-commons/digester]
M2_HOME: /opt/maven2
-
[INFO] [resources:testResources {execution: default-testResources}]
[INFO] Using 'iso-8859-1' encoding to copy filtered resources.
[INFO] Copying 57 resources
[INFO] Copying 0 resource to META-INF
[INFO] [compiler:testCompile {execution: default-testCompile}]
[INFO] Compiling 101 source files to 
/srv/gump/public/workspace/apache-commons/digester/core/target/test-classes
[INFO] [surefire:test {execution: default-test}]
[INFO] Tests are skipped.
Downloading: 
http://localhost:8192/maven2/org/codehaus/plexus/plexus-container-default/1.0-alpha-44/plexus-container-default-1.0-alpha-44.pom

Downloading: 
http://localhost:8192/maven2/org/codehaus/plexus/plexus-containers/1.0-alpha-44/plexus-containers-1.0-alpha-44.pom

Downloading: 
http://localhost:8192/maven2/aspectj/aspectjrt/1.5.3/aspectjrt-1.5.3.pom

Downloading: 
http://localhost:8192/maven2/org/codehaus/plexus/plexus-classworlds/1.2-alpha-10/plexus-classworlds-1.2-alpha-10.pom

Downloading: 
http://localhost:8192/maven2/org/codehaus/plexus/plexus-archiver/1.2/plexus-archiver-1.2.pom

Downloading: 
http://localhost:8192/maven2/org/codehaus/plexus/plexus-io/1.0.1/plexus-io-1.0.1.pom

Downloading: 
http://localhost:8192/maven2/org/codehaus/plexus/plexus-archiver/1.2/plexus-archiver-1.2.jar

Downloading: 
http://localhost:8192/maven2/org/codehaus/plexus/plexus-io/1.0.1/plexus-io-1.0.1.jar

[INFO] [jarjar:jarjar {execution: default}]
[INFO] Processing: 
/srv/gump/public/workspace/apache-commons/digester/core/target/classes
[INFO] Building zip: 
/srv/gump/public/workspace/apache-commons/digester/core/target/jarjar/uber-classes
[INFO] META-INF/LICENSE.txt already added, skipping
[INFO] META-INF/NOTICE.txt already added, skipping
[INFO] META-INF/LICENSE.txt already added, skipping
[INFO] META-INF/NOTICE.txt already added, skipping
[INFO] JarJar'ing to: 
/srv/gump/public/workspace/apache-commons/digester/core/target/classes-shaded
[INFO] [jar:jar {execution: default-jar}]
[INFO] Building jar: 
/srv/gump/public/workspace/apache-commons/digester/core/target/commons-digester3-3.3-SNAPSHOT.jar
[INFO] [antrun:run {execution: uberjar.resources}]
[INFO] Executing tasks

main:
[INFO] 
[ERROR] BUILD ERROR
[INFO] 
[INFO] An Ant BuildException has occured: 
/srv/gump/public/workspace/apache-commons/digester/core/src/main/assembly does 
not exist.

[INFO] 
[INFO] For more information, run Maven with the -e switch
[INFO] 
[INFO] Total time: 1 minute 13 seconds
[INFO] Finished at: Sun Feb 12 14:10:14 UTC 2012
[INFO] Final Memory: 59M/141M
[INFO] 
-

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

Re: [SANDBOX][BeanUtils2] Discussion about cloneBean(), copyProperties() and cast() on DefaultBeanAccessor

2012-02-12 Thread James Carman

If we jump to java 7, we can clean up our exceptions by using
ReflectiveOperationException.

Sent from tablet device.  Please excuse typos and brevity.
On Feb 12, 2012 6:28 AM, "Benedikt Ritter"  wrote:

> Hi,
>
> now that we have implemented describe() and populate() on
> DefaultBeanAccessor, cloneBean() and copyProperties(T target) seem very
> easy to implement. I would realize cloneBean() simply like:
>
> public B cloneBean()
>throws aLotOfExceptions ;-)
> {
>@SuppressWarnings( "unchecked" )
>B clone = (B) bean.getClass().newInstance();
>DefaultBeanAccessor cloneAccessor = new DefaultBeanAccessor(
> clone );
>cloneAccessor.populate( this.describe() );
>return clone;
> }
>
> copyProperties() can be implemented likewise. Is that really all we have
> to do, or am I missing something? I've looked at BeanUtils1 and they are
> handling Maps a little differently by coping all entries. So I guess we
> have to do the same (to keep the user experience).
>
> Another thing I was winking about is cast(). I don't understand how that
> is supposed to work. Can it be, that there is an input parameter missing?
> To make it work it has to be:
>
> public  V cast(Class targetType);
>
> Tell me what you think and I'll start implementing the missing methods.
>
> Regards,
> Benedikt
>
> --**--**-
> To unsubscribe, e-mail: 
> dev-unsubscribe@commons.**apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

[SANDBOX][BeanUtils2] Discussion about cloneBean(), copyProperties() and cast() on DefaultBeanAccessor

2012-02-12 Thread Benedikt Ritter


Hi,

now that we have implemented describe() and populate() on 
DefaultBeanAccessor, cloneBean() and copyProperties(T target) seem very 
easy to implement. I would realize cloneBean() simply like:


public B cloneBean()
throws aLotOfExceptions ;-)
{
@SuppressWarnings( "unchecked" )
B clone = (B) bean.getClass().newInstance();
DefaultBeanAccessor cloneAccessor = new DefaultBeanAccessor( 
clone );

cloneAccessor.populate( this.describe() );
return clone;
}

copyProperties() can be implemented likewise. Is that really all we have 
to do, or am I missing something? I've looked at BeanUtils1 and they are 
handling Maps a little differently by coping all entries. So I guess we 
have to do the same (to keep the user experience).


Another thing I was winking about is cast(). I don't understand how that 
is supposed to work. Can it be, that there is an input parameter 
missing? To make it work it has to be:


public  V cast(Class targetType);

Tell me what you think and I'll start implementing the missing methods.

Regards,
Benedikt

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

Re: [Graph] On graph weight type(s)

2012-02-12 Thread Marco Speranza

Hi all,

> I understand and agree with you about your doubts - I don't have a
> strong idea, anyway I wouldn't take the *Handler as first choice,
> since it does not drive users to an event-handler alike programming
> model, rather *Operations makes more sense...


+1


Furthermore I think that name of classes are congruent. In my opinion Monoid, 
OrderMonoid and Semigroup are the right names . In order to  help the users, we 
can add some fluent api
i.e.:   

findMaxFlow( graph ).from( a ).to( g ).applyingEdmondsKarp.withWeightOperation( 
new IntegerOperation() ) or something like that.


Ciao

--
Marco Speranza 

Flickr: http://www.flickr.com/photos/marcosperanza79/
Google Code: http://code.google.com/u/marco.speranza79/




Il giorno 11/feb/2012, alle ore 21:19, Simone Tripodi ha scritto:

> Ciao Claudio!
> 
> I understand and agree with you about your doubts - I don't have a
> strong idea, anyway I wouldn't take the *Handler as first choice,
> since it does not drive users to an event-handler alike programming
> model, rather *Operations makes more sense...
> 
> Let's take some time to think about it, excellent catch anyway :)
> 
> best,
> -Simo
> 
> http://people.apache.org/~simonetripodi/
> http://simonetripodi.livejournal.com/
> http://twitter.com/simonetripodi
> http://www.99soft.org/
> 
> 
> 
> On Sat, Feb 11, 2012 at 8:53 PM, Claudio Squarcella
>  wrote:
>> Hi,
>> 
>> 
>>> Maybe one last effort can be made to come up with more understandable
>>> names (e.g. for a user that does not know what a Semigroup or Monoid is).
>>> Suggestions are welcome.
>> 
>> 
>> I exhume this thread because I am still convinced that the "weight
>> architecture" would benefit from a bit of renaming. It is probably not the
>> case to touch mathematical concepts (Semigroup, Monoid), but rather the
>> actual implementations and/or variable names. Consider that with the current
>> fluent API the user has to deal with this stuff explicitly, specifying the
>> appropriate "handler" for weights.
>> 
>> So for example all primitive implementations[1] would change their name from
>> FooWeight to something like FooWeightHandler, or FooWeightOperations, or
>> something like that. Variable names (like in [2]) would change from e.g.
>> orderedMonoid to weightHandler, weightOperations, etc.
>> 
>> Any preference?
>> 
>> Ciao
>> Claudio
>> 
>> [1]
>> http://svn.apache.org/viewvc/commons/sandbox/graph/trunk/src/main/java/org/apache/commons/graph/weight/primitive/
>> [2] line 64:
>> http://svn.apache.org/viewvc/commons/sandbox/graph/trunk/src/main/java/org/apache/commons/graph/shortestpath/DefaultShortestPathAlgorithmSelector.java?view=markup
>> 
>> 
>> --
>> Claudio Squarcella
>> PhD student at Roma Tre University
>> E-mail address: squar...@dia.uniroma3.it
>> Phone: +39-06-57333215
>> Fax: +39-06-57333612
>> http://www.dia.uniroma3.it/~squarcel
>> 
>> 
>> -
>> 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
> 



smime.p7s
Description: S/MIME cryptographic signature

[RESULT] was: [VOTE] Release Daemon 1.0.9 based on RC1

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

Re: [VOTE] Release Commons NET 3.1` based on RC1

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

Re: [VOTE] Release Commons NET 3.1` based on RC1

Re: [VOTE] Release Commons NET 3.1` based on RC1

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

Re: [DISCUSS][POOL] Logging options for Pool2

Re: [DISCUSS][POOL] Logging options for Pool2

Re: [Graph] On graph weight type(s)

Re: [Graph] On graph weight type(s)

Re: [Graph] On graph weight type(s)

[continuum] BUILD FAILURE: Apache Commons - Apache Commons Digester - Default Maven 2 Build Definition (Java 1.5)

Re: [Graph] On graph weight type(s)

Re: [SANDBOX][BeanUtils2] Discussion about cloneBean(), copyProperties() and cast() on DefaultBeanAccessor

Re: [Graph] On graph weight type(s)

Re: [SANDBOX][BeanUtils2] Discussion about cloneBean(), copyProperties() and cast() on DefaultBeanAccessor

Re: [VOTE] Release Commons NET 3.1` based on RC1

Re: [Graph] On graph weight type(s)

Re: [Graph] On graph weight type(s)

Re: [SANDBOX][BeanUtils2] Discussion about cloneBean(), copyProperties() and cast() on DefaultBeanAccessor

Re: [Graph] On graph weight type(s)

Re: [VOTE] Release Commons NET 3.1` based on RC1

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

Re: [SANDBOX][BeanUtils2] Discussion about cloneBean(), copyProperties() and cast() on DefaultBeanAccessor

[SANDBOX][BeanUtils2] Discussion about cloneBean(), copyProperties() and cast() on DefaultBeanAccessor

Re: [Graph] On graph weight type(s)

27 matches

Site Navigation

Mail list logo

Footer information