Re: Common checkstyle (was Re: [vfs] checkstyle)
Am 19.02.2012 22:57, schrieb Simone Tripodi: I think it is reasonable to have Commons wide defaults but let projects override them if they want to. I think that is, what Gary meant in the first place ;-) http://mail-archives.apache.org/mod_mbox/commons-dev/201202.mbox/%3C-662605764588844473%40unknownmsgid%3E To be honest, I'm really indifferent regarding what style to use. But I've come to the conclusion, that coding style is an important thing for some of you. I think the result of this discussion should be an easy way for everyone to switch between components, even if some components are developed by a few committers only (that is why I suggested to put the IDE configuration files on the website). Regards, Benedikt that is much more than reasonable, we are on the same path now! :) -Simo http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ On Sun, Feb 19, 2012 at 10:49 PM, Ralph Goersrgo...@apache.org wrote: On Feb 19, 2012, at 12:26 PM, Simone Tripodisimonetrip...@apache.org wrote: While I agree that checkstyle has to be consistent inside each component, so I would be +1 on having the plugin in the parent (with PMD and Findbugs as mentioned by Gary), I am still reluctant with adopting a general checkstyle *configuration* for all components, and I make you a sample: commons-ognl. main OGNL contributors have been olamy, mcucchiara, grobmeier and simonetripodihttp://svnsearch.org/svnsearch/repos/ASF/search?path=%2Fcommons%2Fproper%2Fognl%2Ftrunk. We all (except grobmeier :P) like the mvn style (brought by checkstyle-plugin) and we are comfortable on working with it. No one else committed on OGNL. So please explain me why the PMC should force OGNL guys on adopting a different style in a component where just a small subset of commons people (mainly Struts guys) is interested. Concluding: PMD, findbugs and checkstyle by default: +1; deciding which style has to be applied: -1. Good practice are one thing, strict rules are different. I think it is reasonable to have Commons wide defaults but let projects override them if they want to. Ralph - 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: Common checkstyle (was Re: [vfs] checkstyle)
On 20 February 2012 09:10, Benedikt Ritter b...@systemoutprintln.de wrote: Am 19.02.2012 22:57, schrieb Simone Tripodi: I think it is reasonable to have Commons wide defaults but let projects override them if they want to. I think that is, what Gary meant in the first place ;-) http://mail-archives.apache.org/mod_mbox/commons-dev/201202.mbox/%3C-662605764588844473%40unknownmsgid%3E To be honest, I'm really indifferent regarding what style to use. But I've come to the conclusion, that coding style is an important thing for some of you. I think the result of this discussion should be an easy way for everyone to switch between components, even if some components are developed by a few committers only (that is why I suggested to put the IDE configuration files on the website). If there were a single coding style that all present and future Commons committers could agree on, then it would make sense to make that the Commons style. However, the fact that we are having these discussions proves that there is no such style. Any style chosen today will necessarily depend on those voting at the time - at a later date, a different style will probably be chosen. Does it really make sense to change all the components to suit a style that is - not agreed by all at present - may become a minority style choice in future? == However, there may be some style aspects that we can agree on: - tabs are banned - indentation (Java = 4; xml = 2 or 4 ) I'm not sure there's anything else that has not been contentious at some point. Regards, Benedikt that is much more than reasonable, we are on the same path now! :) -Simo http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ On Sun, Feb 19, 2012 at 10:49 PM, Ralph Goersrgo...@apache.org wrote: On Feb 19, 2012, at 12:26 PM, Simone Tripodisimonetrip...@apache.org wrote: While I agree that checkstyle has to be consistent inside each component, so I would be +1 on having the plugin in the parent (with PMD and Findbugs as mentioned by Gary), I am still reluctant with adopting a general checkstyle *configuration* for all components, and I make you a sample: commons-ognl. main OGNL contributors have been olamy, mcucchiara, grobmeier and simonetripodihttp://svnsearch.org/svnsearch/repos/ASF/search?path=%2Fcommons%2Fproper%2Fognl%2Ftrunk. We all (except grobmeier :P) like the mvn style (brought by checkstyle-plugin) and we are comfortable on working with it. No one else committed on OGNL. So please explain me why the PMC should force OGNL guys on adopting a different style in a component where just a small subset of commons people (mainly Struts guys) is interested. Concluding: PMD, findbugs and checkstyle by default: +1; deciding which style has to be applied: -1. Good practice are one thing, strict rules are different. I think it is reasonable to have Commons wide defaults but let projects override them if they want to. Ralph - 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: Common checkstyle (was Re: [vfs] checkstyle)
On Feb 20, 2012, at 7:28 AM, sebb wrote: On 20 February 2012 09:10, Benedikt Ritter b...@systemoutprintln.de wrote: Am 19.02.2012 22:57, schrieb Simone Tripodi: I think it is reasonable to have Commons wide defaults but let projects override them if they want to. I think that is, what Gary meant in the first place ;-) http://mail-archives.apache.org/mod_mbox/commons-dev/201202.mbox/%3C-662605764588844473%40unknownmsgid%3E To be honest, I'm really indifferent regarding what style to use. But I've come to the conclusion, that coding style is an important thing for some of you. I think the result of this discussion should be an easy way for everyone to switch between components, even if some components are developed by a few committers only (that is why I suggested to put the IDE configuration files on the website). If there were a single coding style that all present and future Commons committers could agree on, then it would make sense to make that the Commons style. However, the fact that we are having these discussions proves that there is no such style. Any style chosen today will necessarily depend on those voting at the time - at a later date, a different style will probably be chosen. Does it really make sense to change all the components to suit a style that is - not agreed by all at present - may become a minority style choice in future? == However, there may be some style aspects that we can agree on: - tabs are banned - indentation (Java = 4; xml = 2 or 4 ) I'm not sure there's anything else that has not been contentious at some point. Actually, I'd bet a lot of things can be agreed on: 1. Is whitespace after ( and before ) permitted? 2. Is whitespace required before and after operators (i.e. a=1 vs a = 1). 3. Do public static final objects require their names be in all caps. and many more The item that typically is the point of contention is how curly braces are used. I used to care but I've worked on so many code bases that I gave up caring a long time ago. To me, the issue is really about making it easy to work on multiple projects and have the IDE be able to tell you about style errors. In IntelliJ, and I assume Eclipse, each project can be configured with its own style. If there is a default that also provides the IDE rules and we were to require projects to provide IDE rules for whatever style they want to use I would expect more projects would select the default. But even if they didn't, having the checkstyle rules available for every project would still make it easier. Ralph
Re: Common checkstyle (was Re: [vfs] checkstyle)
On Mon, Feb 20, 2012 at 4:10 AM, Benedikt Ritter b...@systemoutprintln.dewrote: Am 19.02.2012 22:57, schrieb Simone Tripodi: I think it is reasonable to have Commons wide defaults but let projects override them if they want to. I think that is, what Gary meant in the first place ;-) http://mail-archives.apache.**org/mod_mbox/commons-dev/**201202.mbox/%3C-* *662605764588844473%**40unknownmsgid%3Ehttp://mail-archives.apache.org/mod_mbox/commons-dev/201202.mbox/%3C-662605764588844473%40unknownmsgid%3E Yes indeed, thank you for pointing that out in the link above. I do not like to repeat myself. A advantage to an overridable default is that it is quicker to get a new project off and running without letting it go wild with yet another set of conventions. Right now, every time I want to work with one of the 20+ commons components (!= project), I have to create yet another IDE set of formatter settings, it's become intolerable and sadly ironic for a project named Commons. Gary To be honest, I'm really indifferent regarding what style to use. But I've come to the conclusion, that coding style is an important thing for some of you. I think the result of this discussion should be an easy way for everyone to switch between components, even if some components are developed by a few committers only (that is why I suggested to put the IDE configuration files on the website). Regards, Benedikt that is much more than reasonable, we are on the same path now! :) -Simo http://people.apache.org/~**simonetripodi/http://people.apache.org/%7Esimonetripodi/ http://simonetripodi.**livejournal.com/http://simonetripodi.livejournal.com/ http://twitter.com/**simonetripodi http://twitter.com/simonetripodi http://www.99soft.org/ On Sun, Feb 19, 2012 at 10:49 PM, Ralph Goersrgo...@apache.org wrote: On Feb 19, 2012, at 12:26 PM, Simone Tripodisimonetripodi@apache.**orgsimonetrip...@apache.org wrote: While I agree that checkstyle has to be consistent inside each component, so I would be +1 on having the plugin in the parent (with PMD and Findbugs as mentioned by Gary), I am still reluctant with adopting a general checkstyle *configuration* for all components, and I make you a sample: commons-ognl. main OGNL contributors have been olamy, mcucchiara, grobmeier and simonetripodihttp://**svnsearch.org/svnsearch/repos/** ASF/search?path=%2Fcommons%**2Fproper%2Fognl%2Ftrunkhttp://svnsearch.org/svnsearch/repos/ASF/search?path=%2Fcommons%2Fproper%2Fognl%2Ftrunk . We all (except grobmeier :P) like the mvn style (brought by checkstyle-plugin) and we are comfortable on working with it. No one else committed on OGNL. So please explain me why the PMC should force OGNL guys on adopting a different style in a component where just a small subset of commons people (mainly Struts guys) is interested. Concluding: PMD, findbugs and checkstyle by default: +1; deciding which style has to be applied: -1. Good practice are one thing, strict rules are different. I think it is reasonable to have Commons wide defaults but let projects override them if they want to. Ralph --**--** - To unsubscribe, e-mail: dev-unsubscribe@commons.**apache.orgdev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org --**--**- To unsubscribe, e-mail: dev-unsubscribe@commons.**apache.orgdev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org --**--**- To unsubscribe, e-mail: dev-unsubscribe@commons.**apache.orgdev-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://goog_1249600977http://bit.ly/ECvg0 Spring Batch in Action: http://s.apache.org/HOqhttp://bit.ly/bqpbCK Blog: http://garygregory.wordpress.com Home: http://garygregory.com/ Tweet! http://twitter.com/GaryGregory
[SANDBOX][BeanUtils2] Some thoughts on indexed properties
Hi, today I got the time to write some more code for BeanUtils2, so I started to implement setIndexed(). Now, that I'm nearly done with it, there are two things that I'm unsure how to handle. 1. out of bounds indices: If the user passes in an index that is out of bounds, he will see a InvocationTargetException, that wraps an ArrayOutOfBoundsException (if the indexed property is backed up by an array). Can we live with that or should we implement some logic, that checks if the index is available and if not throws the appropriate exception? (this would also have to be applied to getIndexed) 2. wrong property names: If the user passes a property name, that doesn't specify a property on the given bean, he will see a NullPointerException. This is, because we do at first try to retrieve a property descriptor from PropertyDescriptor registry and then just do a checkNotNull with it. I thing it would be more appropriate to throw a NoSuchMethodException, if a string was passed in, that does not correspond to any of the properties (to differentiate this case from a null argument been passed). If you agree the implementation of set(String), get(String) getIndexed(String) will have to change as well. Regards, Benedikt - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [graph] renaming weight operations
Hi Simone and all, On 19/02/2012 22:12, Simone Tripodi wrote: Hi (and sorry for the late) I personally don't see the reason to be open to *Operations until *Monoid (actually, wrongly, *Weight) until there is the real need of. Anyway, please share a patch in the issue you filled - code talks much better, I could finally see what I am currently missing ;) I uploaded a patch on JIRA[1] as requested. I hope that helps convincing you ;) Ciao, Claudio [1] https://issues.apache.org/jira/browse/SANDBOX-395?focusedCommentId=13212017page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13212017 looking forward to it! -Simo http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ On Sun, Feb 19, 2012 at 5:05 PM, Claudio Squarcella squar...@dia.uniroma3.it wrote: Hi, * Doubles can also be multiplied, but so far we did not need to include that in our stack of operations and properties. If we ever need to do so, it will be enough to create another interface extending OrderedMonoid and change the implemented interface in DoubleWeightOperations. isn't it a different monoid? I mean, multiplier operator, the 1 identifier and real numbers are a monoid, or my math became terribly bad? :P you're right! Your math is cool don't worry :) But see, maybe we could let it implement both an addiction monoid and a multiplication monoid. We could even create Addition (and later maybe Multiplication?) as interface extending Monoid, so that we also solve the other aspect pointed out by Axel days ago: the Monoid would offer a generic applyOperation, while Addition would wrap it as sum (and Multiplication as multiply). Cool? * Also, there might be properties and/or operations that are unrelated to each other, hence DoubleWeightOperations might implement more than one interface in the future. that sounds good, anyway before to apply any potential improvement because users may need of XXX I'd want to make sure that custom behaviors can be applied to our APIs just estending existing component, rather than blindly provide potential features we don't need. I mean... if we do have the real need of having more operations than the OrderedMonoid already provides, so go for it; otherwise, users shall be able to define their on *Operator by extending ours and implementing their custom interface. then we could use the pattern *WeightBaseOperations (e.g. DoubleWeightBaseOperations): so that we developers are free to extend it with more properties over time, as well as the users in their implementations -- and the name is IMHO self-explanatory and unambiguous. In other words: Doubles (as well as the other types) are not *only* monoids. So I feel we would be much more blind sticking to the term monoid in the implementation: we need more flexibility, and I hope the above *WeightBaseOperations sound good as a candidate. Thank you for the discussion, waiting for further input! Claudio I would be to support the minimum extensible set of features rather than supporting all the potential cases, unless we really have the practical need of them to implement new algos. Thoughts? -Simo http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ On Sun, Feb 19, 2012 at 2:59 PM, Claudio Squarcella squar...@dia.uniroma3.itwrote: Hello Simone, It would be much more naturally to my hears hearing it as BigDecimalOrderedMonoid, doesn't it? you have a valid point. However my intention is to decouple implementations from underlying interfaces, because they might evolve and grow over time. Let me give you two examples: * Doubles can also be multiplied, but so far we did not need to include that in our stack of operations and properties. If we ever need to do so, it will be enough to create another interface extending OrderedMonoid and change the implemented interface in DoubleWeightOperations. * Also, there might be properties and/or operations that are unrelated to each other, hence DoubleWeightOperations might implement more than one interface in the future. How does that sound? 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 -- Claudio Squarcella PhD student at Roma Tre University http://www.dia.uniroma3.it/~squarcel http://squarcella.com/ - To unsubscribe, e-mail:
Re: [Math] Toward releasing 3.0 ?
Hi. How do we proceed from here in order to release 3.0? Cf. ticket MATH-746, Things to do before releasing 3.0. Can we start to talk about an expected release date? Thanks, Gilles - 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
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 18 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 39 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: 1329790956554
[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 [40.560s]
[INFO] Apache Commons Digester :: Core ... SUCCESS [31.891s]
[INFO] Apache Commons Digester :: Annotations Processor .. SUCCESS [2.219s]
[INFO] Commons Digester :: Examples .. SUCCESS [0.456s]
[INFO] Apache Commons Digester :: Examples :: Annotations :: Atom SUCCESS
[3.158s]
[INFO] Apache Commons Digester :: Examples :: API :: Address Book SUCCESS
[3.009s]
[INFO] Apache Commons Digester :: Examples :: API :: Catalog . SUCCESS [1.881s]
[INFO] Apache Commons Digester :: Examples :: API :: DB Insert SUCCESS [2.089s]
[INFO] Apache Commons Digester :: Examples :: API :: Document Markup SUCCESS
[1.831s]
[INFO] Apache Commons Digester :: Examples :: EDSL :: Atom ... SUCCESS [1.992s]
[INFO] Apache Commons Digester :: Examples :: Plugins :: Pipeline SUCCESS
[1.689s]
[INFO] Apache Commons Digester :: Examples :: RSS
[GUMP@vmgump]: Project commons-proxy-test (in module apache-commons) failed
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 415 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.014 sec Running org.apache.commons.proxy.interceptor.TestSerializingInterceptor Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.018 sec Running org.apache.commons.proxy.interceptor.TestInterceptorChain Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.006 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.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.024 sec Running org.apache.commons.proxy.factory.javassist.TestJavassistProxyFactory Tests run: 37, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.138 sec Running org.apache.commons.proxy.exception.TestProxyFactoryException Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.007 sec Running org.apache.commons.proxy.interceptor.filter.TestReturnTypeFilter Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.004 sec Running org.apache.commons.proxy.provider.TestBeanProvider Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.014 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: Tue Feb 21 05:53:53 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:
[GUMP@vmgump]: Project commons-vfs2-test (in module apache-commons) failed
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 14 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 36 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@4760a26f(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@1d2940b3(org.apache.commons.vfs2.test.CacheTestSuite): 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 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 junit.framework.TestSuite@3dbbd23f(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@5d3ad33d(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@33d6f122(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@21aed5f9(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@7f724a9d(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@236527f(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.
Re: Common checkstyle (was Re: [vfs] checkstyle)
Sorry but I lost you, at that point I don't understand what meaning we want to attribute to the checkstyle configuration can be overridden sentence. Do you mean that we add the suppressions file, in order to skip some violations (i.e. signature too long of the default 80 char estimated by the default rules) or committers can define their own config files? TIA, -Simo http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ On Mon, Feb 20, 2012 at 5:35 PM, Gary Gregory garydgreg...@gmail.com wrote: On Mon, Feb 20, 2012 at 4:10 AM, Benedikt Ritter b...@systemoutprintln.dewrote: Am 19.02.2012 22:57, schrieb Simone Tripodi: I think it is reasonable to have Commons wide defaults but let projects override them if they want to. I think that is, what Gary meant in the first place ;-) http://mail-archives.apache.**org/mod_mbox/commons-dev/**201202.mbox/%3C-* *662605764588844473%**40unknownmsgid%3Ehttp://mail-archives.apache.org/mod_mbox/commons-dev/201202.mbox/%3C-662605764588844473%40unknownmsgid%3E Yes indeed, thank you for pointing that out in the link above. I do not like to repeat myself. A advantage to an overridable default is that it is quicker to get a new project off and running without letting it go wild with yet another set of conventions. Right now, every time I want to work with one of the 20+ commons components (!= project), I have to create yet another IDE set of formatter settings, it's become intolerable and sadly ironic for a project named Commons. Gary To be honest, I'm really indifferent regarding what style to use. But I've come to the conclusion, that coding style is an important thing for some of you. I think the result of this discussion should be an easy way for everyone to switch between components, even if some components are developed by a few committers only (that is why I suggested to put the IDE configuration files on the website). Regards, Benedikt that is much more than reasonable, we are on the same path now! :) -Simo http://people.apache.org/~**simonetripodi/http://people.apache.org/%7Esimonetripodi/ http://simonetripodi.**livejournal.com/http://simonetripodi.livejournal.com/ http://twitter.com/**simonetripodi http://twitter.com/simonetripodi http://www.99soft.org/ On Sun, Feb 19, 2012 at 10:49 PM, Ralph Goersrgo...@apache.org wrote: On Feb 19, 2012, at 12:26 PM, Simone Tripodisimonetripodi@apache.**orgsimonetrip...@apache.org wrote: While I agree that checkstyle has to be consistent inside each component, so I would be +1 on having the plugin in the parent (with PMD and Findbugs as mentioned by Gary), I am still reluctant with adopting a general checkstyle *configuration* for all components, and I make you a sample: commons-ognl. main OGNL contributors have been olamy, mcucchiara, grobmeier and simonetripodihttp://**svnsearch.org/svnsearch/repos/** ASF/search?path=%2Fcommons%**2Fproper%2Fognl%2Ftrunkhttp://svnsearch.org/svnsearch/repos/ASF/search?path=%2Fcommons%2Fproper%2Fognl%2Ftrunk . We all (except grobmeier :P) like the mvn style (brought by checkstyle-plugin) and we are comfortable on working with it. No one else committed on OGNL. So please explain me why the PMC should force OGNL guys on adopting a different style in a component where just a small subset of commons people (mainly Struts guys) is interested. Concluding: PMD, findbugs and checkstyle by default: +1; deciding which style has to be applied: -1. Good practice are one thing, strict rules are different. I think it is reasonable to have Commons wide defaults but let projects override them if they want to. Ralph --**--** - To unsubscribe, e-mail: dev-unsubscribe@commons.**apache.orgdev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org --**--**- To unsubscribe, e-mail: dev-unsubscribe@commons.**apache.orgdev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org --**--**- To unsubscribe, e-mail: dev-unsubscribe@commons.**apache.orgdev-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://goog_1249600977http://bit.ly/ECvg0 Spring Batch in Action: http://s.apache.org/HOqhttp://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: [graph] renaming weight operations
lol, I'll take a look at it as soon as possible!!! thanks! -Simo http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ On Mon, Feb 20, 2012 at 7:27 PM, Claudio Squarcella squar...@dia.uniroma3.it wrote: Hi Simone and all, On 19/02/2012 22:12, Simone Tripodi wrote: Hi (and sorry for the late) I personally don't see the reason to be open to *Operations until *Monoid (actually, wrongly, *Weight) until there is the real need of. Anyway, please share a patch in the issue you filled - code talks much better, I could finally see what I am currently missing ;) I uploaded a patch on JIRA[1] as requested. I hope that helps convincing you ;) Ciao, Claudio [1] https://issues.apache.org/jira/browse/SANDBOX-395?focusedCommentId=13212017page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13212017 looking forward to it! -Simo http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ On Sun, Feb 19, 2012 at 5:05 PM, Claudio Squarcella squar...@dia.uniroma3.it wrote: Hi, * Doubles can also be multiplied, but so far we did not need to include that in our stack of operations and properties. If we ever need to do so, it will be enough to create another interface extending OrderedMonoid and change the implemented interface in DoubleWeightOperations. isn't it a different monoid? I mean, multiplier operator, the 1 identifier and real numbers are a monoid, or my math became terribly bad? :P you're right! Your math is cool don't worry :) But see, maybe we could let it implement both an addiction monoid and a multiplication monoid. We could even create Addition (and later maybe Multiplication?) as interface extending Monoid, so that we also solve the other aspect pointed out by Axel days ago: the Monoid would offer a generic applyOperation, while Addition would wrap it as sum (and Multiplication as multiply). Cool? * Also, there might be properties and/or operations that are unrelated to each other, hence DoubleWeightOperations might implement more than one interface in the future. that sounds good, anyway before to apply any potential improvement because users may need of XXX I'd want to make sure that custom behaviors can be applied to our APIs just estending existing component, rather than blindly provide potential features we don't need. I mean... if we do have the real need of having more operations than the OrderedMonoid already provides, so go for it; otherwise, users shall be able to define their on *Operator by extending ours and implementing their custom interface. then we could use the pattern *WeightBaseOperations (e.g. DoubleWeightBaseOperations): so that we developers are free to extend it with more properties over time, as well as the users in their implementations -- and the name is IMHO self-explanatory and unambiguous. In other words: Doubles (as well as the other types) are not *only* monoids. So I feel we would be much more blind sticking to the term monoid in the implementation: we need more flexibility, and I hope the above *WeightBaseOperations sound good as a candidate. Thank you for the discussion, waiting for further input! Claudio I would be to support the minimum extensible set of features rather than supporting all the potential cases, unless we really have the practical need of them to implement new algos. Thoughts? -Simo http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ On Sun, Feb 19, 2012 at 2:59 PM, Claudio Squarcella squar...@dia.uniroma3.it wrote: Hello Simone, It would be much more naturally to my hears hearing it as BigDecimalOrderedMonoid, doesn't it? you have a valid point. However my intention is to decouple implementations from underlying interfaces, because they might evolve and grow over time. Let me give you two examples: * Doubles can also be multiplied, but so far we did not need to include that in our stack of operations and properties. If we ever need to do so, it will be enough to create another interface extending OrderedMonoid and change the implemented interface in DoubleWeightOperations. * Also, there might be properties and/or operations that are unrelated to each other, hence DoubleWeightOperations might implement more than one interface in the future. How does that sound? 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: [SANDBOX][BeanUtils2] Some thoughts on indexed properties
Hi, today I got the time to write some more code for BeanUtils2, so I started to implement setIndexed(). nice, it is missing indeed. 1. out of bounds indices: If the user passes in an index that is out of bounds, he will see a InvocationTargetException, that wraps an ArrayOutOfBoundsException (if the indexed property is backed up by an array). Can we live with that or should we implement some logic, that checks if the index is available and if not throws the appropriate exception? (this would also have to be applied to getIndexed) to perform that check, you should get the original property, that non necessarily could/has to be exposed in real use cases, and then verify the index is available. Refer how the original BeanUtils handles that, that is something users are already used to. 2. wrong property names: If the user passes a property name, that doesn't specify a property on the given bean, he will see a NullPointerException. This is, because we do at first try to retrieve a property descriptor from PropertyDescriptor registry and then just do a checkNotNull with it. I thing it would be more appropriate to throw a NoSuchMethodException, if a string was passed in, that does not correspond to any of the properties (to differentiate this case from a null argument been passed). If you agree the implementation of set(String), get(String) getIndexed(String) will have to change as well. go for NoSuchMethodException - but please don't mix stuff, please provide separated patches - maybe the NoSuchMethodException first, then setIndexedProperty() implementation. TIA, -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
