[g...@vmgump]: Project commons-scxml-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-scxml-test has an issue affecting its community integration. This issue affects 1 projects, and has been outstanding for 81 runs. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - commons-scxml-test : Apache Commons Full details are available at: http://vmgump.apache.org/gump/public/apache-commons/commons-scxml-test/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -WARNING- Overriding Maven settings: [/srv/gump/public/workspace/apache-commons/scxml/gump_mvn_settings.xml] -DEBUG- (Apache Gump generated) Apache Maven Settings in: /srv/gump/public/workspace/apache-commons/scxml/gump_mvn_settings.xml -INFO- Failed with reason build failed -DEBUG- Maven POM in: /srv/gump/public/workspace/apache-commons/scxml/pom.xml -INFO- Project Reports in: /srv/gump/public/workspace/apache-commons/scxml/target/surefire-reports The following work was performed: http://vmgump.apache.org/gump/public/apache-commons/commons-scxml-test/gump_work/build_apache-commons_commons-scxml-test.html Work Name: build_apache-commons_commons-scxml-test (Type: Build) Work ended in a state of : Failed Elapsed: 29 secs Command Line: /opt/maven2/bin/mvn --batch-mode --settings /srv/gump/public/workspace/apache-commons/scxml/gump_mvn_settings.xml test [Working Directory: /srv/gump/public/workspace/apache-commons/scxml] M2_HOME: /opt/maven2 - --- T E S T S --- Running org.apache.commons.scxml.invoke.InvokeTestSuite Tests run: 6, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 4.438 sec Running org.apache.commons.scxml.test.TestingTestSuite Tests run: 0, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.009 sec Running org.apache.commons.scxml.env.EnvTestSuite Tests run: 21, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.187 sec Running org.apache.commons.scxml.SCXMLTestSuite Tests run: 71, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 5.06 sec <<< FAILURE! Running org.apache.commons.scxml.issues.IssuesTestSuite Tests run: 5, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 1.105 sec Running org.apache.commons.scxml.model.ModelTestSuite Tests run: 78, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 3.358 sec <<< FAILURE! Running org.apache.commons.scxml.env.faces.EnvFacesTestSuite Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.027 sec Running org.apache.commons.scxml.semantics.SemanticsTestSuite Tests run: 6, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.006 sec Running org.apache.commons.scxml.env.jsp.EnvJspTestSuite Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.053 sec Running org.apache.commons.scxml.env.jexl.EnvJexlTestSuite Tests run: 6, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.034 sec Running org.apache.commons.scxml.env.servlet.EnvServletTestSuite Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.005 sec Running org.apache.commons.scxml.io.IOTestSuite Tests run: 30, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.508 sec Results : Failed tests: testNamespacePrefixedXPathsEL(org.apache.commons.scxml.NamespacePrefixedXPathsTest) testDatamodelSimultaneousJsp(org.apache.commons.scxml.model.DatamodelTest) Tests run: 228, Failures: 2, Errors: 0, Skipped: 0 [INFO] [ERROR] BUILD FAILURE [INFO] [INFO] There are test failures. Please refer to /srv/gump/public/workspace/apache-commons/scxml/target/surefire-reports for the individual test results. [INFO] [INFO] For more information, run Maven with the -e switch [INFO] [INFO] Total time: 28 seconds [INFO] Finished at: Tue Nov 30 10:02:27 UTC 2010 [INFO] Final Memory: 41M/100M [INFO] - To subscribe to this information via syndicated feeds: - RSS: http://vmgump.apache.org/gump/public/apache-commons/commons-scxml-test/rss.xml - Atom: http://vmgump.apache.org/gump/public/apache-commons/commons-scxml-test/atom.xml == Gump Tracking Only === Produced by Apache Gump(TM) version 2.3. Gump Run 0830112010, vmgump.apache.org:vmgump:0830112010 Gump E-mail Identifier (unique wit
[GUMP@vmgump]: Project commons-jelly-tags-quartz (in module commons-jelly) 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-jelly-tags-quartz has an issue affecting its community integration. This issue affects 1 projects, and has been outstanding for 31 runs. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - commons-jelly-tags-quartz : Commons Jelly Full details are available at: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-quartz/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-jelly-tags-quartz-30112010.jar] identifier set to project name -DEBUG- Dependency on logging-log4j-12 exists, no need to add for property maven.jar.log4j. -DEBUG- Dependency on xml-xerces exists, no need to add for property maven.jar.xerces. -DEBUG- Dependency on commons-jexl-1.x exists, no need to add for property maven.jar.commons-jexl. -DEBUG- (Apache Gump generated) Apache Maven Properties in: /srv/gump/public/workspace/commons-jelly/jelly-tags/quartz/build.properties -INFO- Failed with reason build failed -DEBUG- Maven POM in: /srv/gump/public/workspace/commons-jelly/jelly-tags/quartz/project.xml -DEBUG- Maven project properties in: /srv/gump/public/workspace/commons-jelly/jelly-tags/quartz/project.properties -INFO- Project Reports in: /srv/gump/public/workspace/commons-jelly/jelly-tags/quartz/target/test-reports -WARNING- No directory [/srv/gump/public/workspace/commons-jelly/jelly-tags/quartz/target/test-reports] -DEBUG- Extracted fallback artifacts from Gump Repository The following work was performed: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-quartz/gump_work/build_commons-jelly_commons-jelly-tags-quartz.html Work Name: build_commons-jelly_commons-jelly-tags-quartz (Type: Build) Work ended in a state of : Failed Elapsed: 5 secs Command Line: maven --offline jar [Working Directory: /srv/gump/public/workspace/commons-jelly/jelly-tags/quartz] - java:compile: [echo] Compiling to /srv/gump/public/workspace/commons-jelly/jelly-tags/quartz/target/classes [javac] Compiling 7 source files to /srv/gump/public/workspace/commons-jelly/jelly-tags/quartz/target/classes [javac] /srv/gump/public/workspace/commons-jelly/jelly-tags/quartz/src/java/org/apache/commons/jelly/tags/quartz/CronTriggerTag.java:198: org.quartz.CronTrigger is abstract; cannot be instantiated [javac] CronTrigger trigger = new CronTrigger( getName(), [javac] ^ [javac] /srv/gump/public/workspace/commons-jelly/jelly-tags/quartz/src/java/org/apache/commons/jelly/tags/quartz/CronTriggerTag.java:201: cannot find symbol [javac] symbol : method setCronExpression(java.lang.String) [javac] location: interface org.quartz.CronTrigger [javac] trigger.setCronExpression( getSpec() ); [javac]^ [javac] /srv/gump/public/workspace/commons-jelly/jelly-tags/quartz/src/java/org/apache/commons/jelly/tags/quartz/CronTriggerTag.java:206: cannot find symbol [javac] symbol : method setJobName(java.lang.String) [javac] location: interface org.quartz.CronTrigger [javac] trigger.setJobName( getJobName() ); [javac]^ [javac] /srv/gump/public/workspace/commons-jelly/jelly-tags/quartz/src/java/org/apache/commons/jelly/tags/quartz/CronTriggerTag.java:207: cannot find symbol [javac] symbol : method setJobGroup(java.lang.String) [javac] location: interface org.quartz.CronTrigger [javac] trigger.setJobGroup( getJobGroup() ); [javac]^ [javac] /srv/gump/public/workspace/commons-jelly/jelly-tags/quartz/src/java/org/apache/commons/jelly/tags/quartz/CronTriggerTag.java:208: cannot find symbol [javac] symbol : method setStartTime(java.util.Date) [javac] location: interface org.quartz.CronTrigger [javac] trigger.setStartTime( new Date() ); [javac]^ [javac] /srv/gump/public/workspace/commons-jelly/jelly-tags/quartz/src/java/org/apache/commons/jelly/tags/quartz/JobTag.java:118: org.quartz.JobDetail is abstract; cannot be instantiated [javac] JobDetail detail = new JobDetail( getName(), [javac]^ [javac] /srv/gump/public/workspace/commons-jelly/jelly-tags/quartz/src/java/org/apache/commons/jelly/tags/quartz/JobTag.java:122: cannot find symbol [javac] symbol : method setDurability(boolean) [javac] location: interface org.quartz.JobDetail [javac] detail.setDurability( true ); [javac] ^ [javac] /srv
[g...@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 81 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: 14 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.004 sec Running org.apache.commons.proxy.factory.util.TestMethodSignature Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.004 sec Running org.apache.commons.proxy.provider.TestConstantProvider Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.008 sec Running org.apache.commons.proxy.interceptor.TestFilteredInterceptor Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.045 sec Running org.apache.commons.proxy.interceptor.filter.TestPatternFilter Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.005 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.024 sec Running org.apache.commons.proxy.provider.remoting.TestBurlapProvider Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.016 sec Running org.apache.commons.proxy.exception.TestDelegateProviderException Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.004 sec Running org.apache.commons.proxy.invoker.TestChainInvoker Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.011 sec Running org.apache.commons.proxy.factory.javassist.TestJavassistProxyFactory Tests run: 37, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.158 sec Running org.apache.commons.proxy.exception.TestProxyFactoryException Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.003 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.101 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: 12 seconds [INFO] Finished at: Tue Nov 30 11:04:34 UTC 2010 [INFO] Final Memory: 39M/93M [INFO] - To subscribe to this information via syndicated feeds: - RSS: http://vmgump.apache.org/gump/public/apache-commons/commons-proxy-test/rss.xml - Atom: http://vmgump.apache.or
Re: [pool] Pool config vs. factory hierarchies.
Hi all guys,
sorry for resurrecting a zombie message, but I've been busy at work
and haven't had the chance to contribute at all.
I could re-start committing code according to the requirements
described by Phil, If it works for you, so other tasks like
JMX/autoconfigure can be unlocked, please let me know.
Have a nice day,
Simo
http://people.apache.org/~simonetripodi/
http://www.99soft.org/
On Wed, Nov 3, 2010 at 11:01 PM, Phil Steitz wrote:
>
>
>
>
> On Nov 3, 2010, at 5:03 PM, Steven Siebert wrote:
>
>>>
>>>
>>> You restore the pool fields that used to hold the configuration setting
>>> properties and leave the getters and setters (for the mutable ones) in
>>> place.
>>>
>>> Phil
>>>
>>>
>> so something like this?
>>
>> public class GOP extends {
>>
>> /**
>> * ref to immutable config reference, immutable config values are either
>> referred directly here
>> * or are copied to a final instance field
>> */
>> private GOPConfig config
>
> No. There is no config member. It is used only to encapsulate the
> parameters of the ctors. The GOP class stores the config data in individual
> fields, accessed by getters and setters. The setters at least are
> synchronized using the pool monitor. Look at the old code. What I am
> proposing is that we limit the use and lifetime of the config objects to the
> ctors and/or factories.
>
> Phil
>>
>>
>> //mutable configuration values are mutated/accessed from pool instance
>> private volatile int mut1; //probably better to use read/write locks
>> private volatile int mut2;
>>
>> public GOP (GOPConfig config) {
>> this.config = config;
>> reconfigure(config);
>> }
>>
>> /**
>> * using this model, this method isn't really required (at least not
>> public)
>> * but would be a convenience for "batch"/atomic changes to configuration
>> values -
>> * this is possible if we switch from volatile to a r/w locking mechanism
>> */
>> public void reconfigure (GOPConfig config) {
>> mut1 = config.getMut1;
>> mut2 = config.getMut2;
>> }
>>
>> public void setMut1 (int m) {
>> mut1 = m;
>> }
>>
>> public int getMut1 () {
>> return mut1;
>> }
>>
>>
>> }
>>
>> I wonder, with this modelwhat is the reason for having an immutable
>> configuration instance if we're going to copy the values locally for (at
>> least) mutability purposes? I believe the attraction of the immutable
>> configuration instance was for concurrency issues...but with this model, we
>> would need to use pool-local syncronization (locking) anyway.
>>
>> I wrote a quick mock-up implementation like this, using a
>> ReentrantReadWriteLock, and the amount of concurrency work in each
>> pool/factory started to pile up. We already identified that inheritance of
>> the Pool/Factory classes might not be the best approach (I agree with this
>> as well...which would cause POOL-177 to no longer be implemented)...so this
>> means duplication of synchronization code as well.
>>
>> I think I'm falling back to my initial thought on this in that the config
>> classes should, IMO, either be mutable (where appropriate) and made thread
>> safe (internally synchronized) to reduce the amount of concurrency work
>> needed in each class that aggregates the instance...or immutable and any
>> changes to the config instance needs to be done by going back to the Builder
>> (something like new Builder(configInstance).change().create());) and then
>> the config reference in each pool/factory could be made volatile.
>>
>> I know this is confusing in emailI would be glad to create a quick patch
>> or UML for this to clear things up if this would help.
>>
>> Thoughts?
>>
>> S
>
> -
> 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: VFS release
Hi All: I've removed unused imports. Any objection to organizing imports consistently? Gary > -Original Message- > From: Ralph Goers [mailto:ralph.go...@dslextreme.com] > Sent: Saturday, November 27, 2010 17:51 > To: Commons Developers List > Subject: VFS release > > I've gone through Jira and tried to make fixes where it looked like they would > require changes that could impact binary compatibility. > > There are many bugs related to the FTP variants and after taking several > passes I've decided to hold off for the time being. Most of the code either > isn't thread safe or implements concurrency in a manner that is difficult for > me to understand what it is trying to do. FtpFileObject synchronizes on the > file system which creates a huge bottleneck and without understanding how > commons net works it isn't clear to me why this is being done the way it is. > It almost feels like someone just tried to make it thread safe by brute force. > OTOH, SftpFileObject doesn't synchronize on anything which looks problematic > to me. But I have no familiarity with jsch so I suppose I could not be > understanding something. > > However, I don't believe addressing these issues will impact binary > compatibility so at this point I think I'm ready to try again to release 2.0. > > WDYT? > > 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
Re: VFS release
On Nov 30, 2010, at 8:40 AM, Gary Gregory wrote: > Hi All: > > I've removed unused imports. > > Any objection to organizing imports consistently? > Actually, those all show up in the checkstyle report. The ones you changed are all a consequence of the recent changes I made. I'd missed those but would have caught that the next time I ran checkstyle, although I haven't been paying much attention to the sandbox or examples projects. Ralph - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
RE: VFS release
> -Original Message- > From: Ralph Goers [mailto:ralph.go...@dslextreme.com] > Sent: Tuesday, November 30, 2010 12:00 > To: Commons Developers List > Subject: Re: VFS release > > > On Nov 30, 2010, at 8:40 AM, Gary Gregory wrote: > > > Hi All: > > > > I've removed unused imports. > > > > Any objection to organizing imports consistently? > > > > Actually, those all show up in the checkstyle report. The ones you changed > are all a consequence of the recent changes I made. I'd missed those but would > have caught that the next time I ran checkstyle, although I haven't been > paying much attention to the sandbox or examples projects. I just noticed them as warnings in Eclipse. I did not look at the checkstyle report as Maven is still giving me headaches (see my emails from yesterday.) Gary > > 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
RE: VFS release
Hm... I just noticed that VFS follows a different import convention that other [commons] projects. In [lang] and [io] for example, we list java packages first and the project's packages last. In VFS, it's the reverse. Consistency would be nice. Time to match [lang] and [io]? Time to wiki this as a guideline? Too micro? Gary > -Original Message- > From: Ralph Goers [mailto:ralph.go...@dslextreme.com] > Sent: Tuesday, November 30, 2010 12:00 > To: Commons Developers List > Subject: Re: VFS release > > > On Nov 30, 2010, at 8:40 AM, Gary Gregory wrote: > > > Hi All: > > > > I've removed unused imports. > > > > Any objection to organizing imports consistently? > > > > Actually, those all show up in the checkstyle report. The ones you changed > are all a consequence of the recent changes I made. I'd missed those but would > have caught that the next time I ran checkstyle, although I haven't been > paying much attention to the sandbox or examples projects. > > 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
Re: VFS release
On 30 November 2010 17:16, Gary Gregory wrote: > Hm... I just noticed that VFS follows a different import convention that > other [commons] projects. > > In [lang] and [io] for example, we list java packages first and the project's > packages last. In VFS, it's the reverse. Consistency would be nice. Time to > match [lang] and [io]? OK by me. > Time to wiki this as a guideline? Too micro? IMO, that would be fine as a guideline. Makes it a bit easier when adding new code. If there are currently no guidelines on imports, I would add: * never use wildcard imports, except perhaps for static imports of constants. > > Gary > >> -Original Message- >> From: Ralph Goers [mailto:ralph.go...@dslextreme.com] >> Sent: Tuesday, November 30, 2010 12:00 >> To: Commons Developers List >> Subject: Re: VFS release >> >> >> On Nov 30, 2010, at 8:40 AM, Gary Gregory wrote: >> >> > Hi All: >> > >> > I've removed unused imports. >> > >> > Any objection to organizing imports consistently? >> > >> >> Actually, those all show up in the checkstyle report. The ones you changed >> are all a consequence of the recent changes I made. I'd missed those but >> would >> have caught that the next time I ran checkstyle, although I haven't been >> paying much attention to the sandbox or examples projects. >> >> 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: VFS release
On Nov 30, 2010, at 9:28 AM, sebb wrote: > On 30 November 2010 17:16, Gary Gregory wrote: >> Hm... I just noticed that VFS follows a different import convention that >> other [commons] projects. >> >> In [lang] and [io] for example, we list java packages first and the >> project's packages last. In VFS, it's the reverse. Consistency would be >> nice. Time to match [lang] and [io]? > > OK by me. > >> Time to wiki this as a guideline? Too micro? > > IMO, that would be fine as a guideline. Makes it a bit easier when > adding new code. I usually have IntelliJ add the imports. I have no idea what controls the order it chooses. As long as like packages are grouped I really don't care what the order is. > > If there are currently no guidelines on imports, I would add: > * never use wildcard imports, except perhaps for static imports of constants. That is also reported as an error by checkstyle. Ralph - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
[Commons Wiki] Update of "FrontPage" by GaryGregory
Dear Wiki user, You have subscribed to a wiki page or wiki category on "Commons Wiki" for change notification. The "FrontPage" page has been changed by GaryGregory. http://wiki.apache.org/commons/FrontPage?action=diff&rev1=103&rev2=104 -- Welcome: CommonsEtiquette | CommonsResources | ArticlesAndTutorials - Developers: GettingInvolved | [[UsingSVN]] + Developers: GettingInvolved | [[UsingSVN]] | CodeGuidelines Committers: CommonsPeople | ComponentPlans | CommonsCommitters | CommonsOsgi | UsingNexus | CommonsGroupids | Maven3Plan - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
[Commons Wiki] Update of "FrontPage" by GaryGregory
Dear Wiki user, You have subscribed to a wiki page or wiki category on "Commons Wiki" for change notification. The "FrontPage" page has been changed by GaryGregory. http://wiki.apache.org/commons/FrontPage?action=diff&rev1=104&rev2=105 -- Welcome: CommonsEtiquette | CommonsResources | ArticlesAndTutorials - Developers: GettingInvolved | [[UsingSVN]] | CodeGuidelines + Developers: GettingInvolved | [[UsingSVN]] | CodeStyle Committers: CommonsPeople | ComponentPlans | CommonsCommitters | CommonsOsgi | UsingNexus | CommonsGroupids | Maven3Plan - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
[Commons Wiki] Update of "CodeStyle" by GaryGregory
Dear Wiki user, You have subscribed to a wiki page or wiki category on "Commons Wiki" for change notification. The "CodeStyle" page has been changed by GaryGregory. http://wiki.apache.org/commons/CodeStyle?action=diff&rev1=2&rev2=3 -- = Code Style = - - This page is the place where we collect and evaluate code style rules for Commons. The goal is to use this document as a base for a Commons wide Checkstyle configuration, and perhaps templates for IDE:s as well. + This page is the place where we collect and evaluate code style rules for Commons. The goal is to use this document as a base for a Commons wide Checkstyle configuration, and perhaps templates for IDE's as well. Feel free to add new rules to the table below. The rules will be tagged, now or later, on its severity. The proposed tags are: @@ -12, +11 @@ * ''error'' - This must must be fixed before the next release - || '''Rules''' || '''Severity''' || + ||'''Rules''' ||'''Severity''' || - || No tabs allowed in source files || error || + ||No tabs allowed in source files ||error || + ||Imports: No wildcards ||error || + ||Imports: Order by groups: java, javax, org, com ||error || + ||Imports: Order in alphabetical order with a group ||error || - || Add your rule here || warning || + ||Add your rule here ||warning || - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
RE: VFS release
Ok, I've added some entries here: http://wiki.apache.org/commons/CodeStyle See the latest VFS commits for this order of imports: java, javax, org, com. Same as [io] and [lang]. Gary > -Original Message- > From: Ralph Goers [mailto:ralph.go...@dslextreme.com] > Sent: Tuesday, November 30, 2010 14:43 > To: Commons Developers List > Subject: Re: VFS release > > > On Nov 30, 2010, at 9:28 AM, sebb wrote: > > > On 30 November 2010 17:16, Gary Gregory > wrote: > >> Hm... I just noticed that VFS follows a different import convention that > other [commons] projects. > >> > >> In [lang] and [io] for example, we list java packages first and the > project's packages last. In VFS, it's the reverse. Consistency would be nice. > Time to match [lang] and [io]? > > > > OK by me. > > > >> Time to wiki this as a guideline? Too micro? > > > > IMO, that would be fine as a guideline. Makes it a bit easier when > > adding new code. > > I usually have IntelliJ add the imports. I have no idea what controls the > order it chooses. As long as like packages are grouped I really don't care > what the order is. > > > > > If there are currently no guidelines on imports, I would add: > > * never use wildcard imports, except perhaps for static imports of > constants. > > That is also reported as an error by checkstyle. > > 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
Re: VFS release
On 30 November 2010 20:38, Gary Gregory wrote: > Ok, I've added some entries here: http://wiki.apache.org/commons/CodeStyle Thanks. But I think the page should be flagged as DRAFT until there is general agreement. For example, I think import order and group order are less important than wildcards, and deserve at most a warning. > See the latest VFS commits for this order of imports: java, javax, org, com. > Same as [io] and [lang]. That is the Eclipse default ordering scheme for imports. > Gary > >> -Original Message- >> From: Ralph Goers [mailto:ralph.go...@dslextreme.com] >> Sent: Tuesday, November 30, 2010 14:43 >> To: Commons Developers List >> Subject: Re: VFS release >> >> >> On Nov 30, 2010, at 9:28 AM, sebb wrote: >> >> > On 30 November 2010 17:16, Gary Gregory >> wrote: >> >> Hm... I just noticed that VFS follows a different import convention that >> other [commons] projects. >> >> >> >> In [lang] and [io] for example, we list java packages first and the >> project's packages last. In VFS, it's the reverse. Consistency would be nice. >> Time to match [lang] and [io]? >> > >> > OK by me. >> > >> >> Time to wiki this as a guideline? Too micro? >> > >> > IMO, that would be fine as a guideline. Makes it a bit easier when >> > adding new code. >> >> I usually have IntelliJ add the imports. I have no idea what controls the >> order it chooses. As long as like packages are grouped I really don't care >> what the order is. >> >> > >> > If there are currently no guidelines on imports, I would add: >> > * never use wildcard imports, except perhaps for static imports of >> constants. >> >> That is also reported as an error by checkstyle. >> >> 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
[Commons Wiki] Update of "CodeStyle" by GaryGregory
Dear Wiki user, You have subscribed to a wiki page or wiki category on "Commons Wiki" for change notification. The "CodeStyle" page has been changed by GaryGregory. http://wiki.apache.org/commons/CodeStyle?action=diff&rev1=3&rev2=4 -- - = Code Style = + = Code Style (DRAFT) = This page is the place where we collect and evaluate code style rules for Commons. The goal is to use this document as a base for a Commons wide Checkstyle configuration, and perhaps templates for IDE's as well. Feel free to add new rules to the table below. The rules will be tagged, now or later, on its severity. The proposed tags are: @@ -14, +14 @@ ||'''Rules''' ||'''Severity''' || ||No tabs allowed in source files ||error || ||Imports: No wildcards ||error || - ||Imports: Order by groups: java, javax, org, com ||error || + ||Imports: Order by groups: java, javax, org, com ||warning || - ||Imports: Order in alphabetical order with a group ||error || + ||Imports: Order in alphabetical order with a group ||warning || ||Add your rule here ||warning || - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
RE: VFS release
> -Original Message- > From: sebb [mailto:seb...@gmail.com] > Sent: Tuesday, November 30, 2010 15:57 > To: Commons Developers List > Subject: Re: VFS release > > On 30 November 2010 20:38, Gary Gregory wrote: > > Ok, I've added some entries here: http://wiki.apache.org/commons/CodeStyle > > Thanks. > But I think the page should be flagged as DRAFT until there is general > agreement. Done. > For example, I think import order and group order are less important > than wildcards, and deserve at most a warning. Done. Gary > > > See the latest VFS commits for this order of imports: java, javax, org, com. > Same as [io] and [lang]. > > That is the Eclipse default ordering scheme for imports. > > > Gary > > > >> -Original Message- > >> From: Ralph Goers [mailto:ralph.go...@dslextreme.com] > >> Sent: Tuesday, November 30, 2010 14:43 > >> To: Commons Developers List > >> Subject: Re: VFS release > >> > >> > >> On Nov 30, 2010, at 9:28 AM, sebb wrote: > >> > >> > On 30 November 2010 17:16, Gary Gregory > >> wrote: > >> >> Hm... I just noticed that VFS follows a different import convention that > >> other [commons] projects. > >> >> > >> >> In [lang] and [io] for example, we list java packages first and the > >> project's packages last. In VFS, it's the reverse. Consistency would be > nice. > >> Time to match [lang] and [io]? > >> > > >> > OK by me. > >> > > >> >> Time to wiki this as a guideline? Too micro? > >> > > >> > IMO, that would be fine as a guideline. Makes it a bit easier when > >> > adding new code. > >> > >> I usually have IntelliJ add the imports. I have no idea what controls the > >> order it chooses. As long as like packages are grouped I really don't care > >> what the order is. > >> > >> > > >> > If there are currently no guidelines on imports, I would add: > >> > * never use wildcard imports, except perhaps for static imports of > >> constants. > >> > >> That is also reported as an error by checkstyle. > >> > >> 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: VFS release
On Nov 30, 2010, at 12:38 PM, Gary Gregory wrote: > Ok, I've added some entries here: http://wiki.apache.org/commons/CodeStyle > > See the latest VFS commits for this order of imports: java, javax, org, com. > Same as [io] and [lang]. > Although the wiki is fine it would be better to use a common checkstyle.xml. I've imported VFS's checkstyle.xml into IntelliJ to run the checkstyle and correct errors in the past. Ralph
RE: VFS release
> -Original Message- > From: Ralph Goers [mailto:ralph.go...@dslextreme.com] > Sent: Tuesday, November 30, 2010 16:00 > To: Commons Developers List > Subject: Re: VFS release > > > On Nov 30, 2010, at 12:38 PM, Gary Gregory wrote: > > > Ok, I've added some entries here: http://wiki.apache.org/commons/CodeStyle > > > > See the latest VFS commits for this order of imports: java, javax, org, com. > Same as [io] and [lang]. > > > > Although the wiki is fine it would be better to use a common checkstyle.xml. Yes! Can we put that in commons-parent and have it kick in automagically? Gary > I've imported VFS's checkstyle.xml into IntelliJ to run the checkstyle and > correct errors in the past. > > Ralph - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: VFS release
On 30 November 2010 21:00, Ralph Goers wrote: > > On Nov 30, 2010, at 12:38 PM, Gary Gregory wrote: > >> Ok, I've added some entries here: http://wiki.apache.org/commons/CodeStyle >> >> See the latest VFS commits for this order of imports: java, javax, org, com. >> Same as [io] and [lang]. >> > > Although the wiki is fine it would be better to use a common checkstyle.xml. > I've imported VFS's checkstyle.xml into IntelliJ to run the checkstyle and > correct errors in the past. I think we need both. As I see it, the Wiki is useful for developing the rules; once agreed, they can be implemented, for example using checkstyle. > Ralph > > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: VFS release
On Nov 30, 2010, at 12:57 PM, sebb wrote: > On 30 November 2010 20:38, Gary Gregory wrote: >> Ok, I've added some entries here: http://wiki.apache.org/commons/CodeStyle > > Thanks. > But I think the page should be flagged as DRAFT until there is general > agreement. > For example, I think import order and group order are less important > than wildcards, and deserve at most a warning. > >> See the latest VFS commits for this order of imports: java, javax, org, com. >> Same as [io] and [lang]. > > That is the Eclipse default ordering scheme for imports. IntelliJ defaults to. import all other imports import javax.* import java.* import static all other imports I guess I've gotten used to this over the years. Ralph - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: VFS release
On Nov 30, 2010, at 1:02 PM, Gary Gregory wrote: >> >> Although the wiki is fine it would be better to use a common checkstyle.xml. > > Yes! Can we put that in commons-parent and have it kick in automagically? > Not unless commons-parent is changed from a project of type pom to a project of type jar. The checkstyle.xml would be the only thing in the jar. This is actually the way the checkstyle plugin team recommends incorporating a checkstyle.xml into a multiproject build. Ralph
[Commons Wiki] Update of "CodeStyle" by sebbapache
Dear Wiki user, You have subscribed to a wiki page or wiki category on "Commons Wiki" for change notification. The "CodeStyle" page has been changed by sebbapache. The comment on this change is: Some more suggested rules. http://wiki.apache.org/commons/CodeStyle?action=diff&rev1=4&rev2=5 -- ||Imports: No wildcards ||error || ||Imports: Order by groups: java, javax, org, com ||warning || ||Imports: Order in alphabetical order with a group ||warning || + ||Indentation: (Java) use 4 spaces || warning || + ||Indentation: (POM) prefer 4 spaces, allow 2, but be consistent within a file (1) || info || ||Add your rule here ||warning || + Notes: + 1. POMs tend to have quite deeply nested elements, and many elements can be long and awkward to wrap, so using 2 spaces is sometimes easier to read. + - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
RE: VFS release
> -Original Message- > From: Ralph Goers [mailto:ralph.go...@dslextreme.com] > Sent: Tuesday, November 30, 2010 16:06 > To: Commons Developers List > Subject: Re: VFS release > > > On Nov 30, 2010, at 12:57 PM, sebb wrote: > > > On 30 November 2010 20:38, Gary Gregory > wrote: > >> Ok, I've added some entries here: http://wiki.apache.org/commons/CodeStyle > > > > Thanks. > > But I think the page should be flagged as DRAFT until there is general > > agreement. > > For example, I think import order and group order are less important > > than wildcards, and deserve at most a warning. > > > >> See the latest VFS commits for this order of imports: java, javax, org, > com. Same as [io] and [lang]. > > > > That is the Eclipse default ordering scheme for imports. > > IntelliJ defaults to. > > import all other imports > > import javax.* > import java.* > > import static all other imports > > I guess I've gotten used to this over the years. That is, comically, the opposite of Eclipse. I don't care as much about the order as I do about consistency in [commons]. I am sure we could argue about which order 'makes sense' ;) but let's not go there unless we are so bored that we need something like that to talk about! :) Gary > > 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
Re: [Commons Wiki] Update of "CodeStyle" by sebbapache
On Nov 30, 2010, at 1:12 PM, Apache Wiki wrote: > Dear Wiki user, > > You have subscribed to a wiki page or wiki category on "Commons Wiki" for > change notification. > > The "CodeStyle" page has been changed by sebbapache. > The comment on this change is: Some more suggested rules. > http://wiki.apache.org/commons/CodeStyle?action=diff&rev1=4&rev2=5 > > -- > > ||Imports: No wildcards ||error || > ||Imports: Order by groups: java, javax, org, com ||warning || > ||Imports: Order in alphabetical order with a group ||warning || > + ||Indentation: (Java) use 4 spaces || warning || > + ||Indentation: (POM) prefer 4 spaces, allow 2, but be consistent within a > file (1) || info || > ||Add your rule here ||warning || > > + Notes: > + 1. POMs tend to have quite deeply nested elements, and many elements can be > long and awkward to wrap, so using 2 spaces is sometimes easier to read. > + Actually, I would have said prefer 2 spaces, allow 4. I prefer 2 spaces for all xml files for exactly the reason you stated - the elements can be long and awkward to wrap. When you need to add something to the pom and it becomes too long it means you have to respace the whole file which generates a lot of noise in the diff. Ralph - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
RE: VFS release
> -Original Message- > From: Ralph Goers [mailto:ralph.go...@dslextreme.com] > Sent: Tuesday, November 30, 2010 16:09 > To: Commons Developers List > Subject: Re: VFS release > > > On Nov 30, 2010, at 1:02 PM, Gary Gregory wrote: > >> > >> Although the wiki is fine it would be better to use a common > checkstyle.xml. > > > > Yes! Can we put that in commons-parent and have it kick in automagically? > > > > Not unless commons-parent is changed from a project of type pom to a project > of type jar. The checkstyle.xml would be the only thing in the jar. This is > actually the way the checkstyle plugin team recommends incorporating a > checkstyle.xml into a multiproject build. That's fine with me. The reuse is worth it. I am sure there are other things we can reuse as well. That make [commons] more, well, [commons]-felling. Would that break all projects? Gary > > Ralph - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: VFS release
On Nov 30, 2010, at 1:18 PM, Gary Gregory wrote: >> -Original Message- >> From: Ralph Goers [mailto:ralph.go...@dslextreme.com] >> Sent: Tuesday, November 30, 2010 16:06 >> To: Commons Developers List >> Subject: Re: VFS release >> >>> pse default ordering scheme for imports. >> >> IntelliJ defaults to. >> >> import all other imports >> >> import javax.* >> import java.* >> >> import static all other imports >> >> I guess I've gotten used to this over the years. > > That is, comically, the opposite of Eclipse. > > I don't care as much about the order as I do about consistency in [commons]. > I am sure we could argue about which order 'makes sense' ;) but let's not go > there unless we are so bored that we need something like that to talk about! > :) > I'm all for consistency. However, the order of groups of imports is not something I'm very concerned about. Most teams I've been involved with start from Sun's documented rules (http://www.oracle.com/technetwork/java/codeconv-138413.html) then publish exceptions to it, such as curly braces on the next line instead of the end of the line. Ralph - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
RE: [pool] Pool config vs. factory hierarchies.
Yes, I thought we were on a roll there! Lots of good discussions and then...
quiet. That's OK though. We all get busy. Time to come back and reflect.
I am still looking for these goals:
- Generics released ASAP. I would be OK for a earlier release just to get this
out.
- Better names for properties and methods
- Refactor to remove duplication
Gary
> -Original Message-
> From: Simone Tripodi [mailto:simone.trip...@gmail.com]
> Sent: Tuesday, November 30, 2010 09:33
> To: Commons Developers List
> Subject: Re: [pool] Pool config vs. factory hierarchies.
>
> Hi all guys,
> sorry for resurrecting a zombie message, but I've been busy at work
> and haven't had the chance to contribute at all.
> I could re-start committing code according to the requirements
> described by Phil, If it works for you, so other tasks like
> JMX/autoconfigure can be unlocked, please let me know.
> Have a nice day,
> Simo
>
> http://people.apache.org/~simonetripodi/
> http://www.99soft.org/
>
>
>
> On Wed, Nov 3, 2010 at 11:01 PM, Phil Steitz wrote:
> >
> >
> >
> >
> > On Nov 3, 2010, at 5:03 PM, Steven Siebert wrote:
> >
> >>>
> >>>
> >>> You restore the pool fields that used to hold the configuration setting
> >>> properties and leave the getters and setters (for the mutable ones) in
> >>> place.
> >>>
> >>> Phil
> >>>
> >>>
> >> so something like this?
> >>
> >> public class GOP extends {
> >>
> >> /**
> >> * ref to immutable config reference, immutable config values are either
> >> referred directly here
> >> * or are copied to a final instance field
> >> */
> >> private GOPConfig config
> >
> > No. There is no config member. It is used only to encapsulate the
> parameters of the ctors. The GOP class stores the config data in individual
> fields, accessed by getters and setters. The setters at least are
> synchronized using the pool monitor. Look at the old code. What I am
> proposing is that we limit the use and lifetime of the config objects to the
> ctors and/or factories.
> >
> > Phil
> >>
> >>
> >> //mutable configuration values are mutated/accessed from pool instance
> >> private volatile int mut1; //probably better to use read/write locks
> >> private volatile int mut2;
> >>
> >> public GOP (GOPConfig config) {
> >> this.config = config;
> >> reconfigure(config);
> >> }
> >>
> >> /**
> >> * using this model, this method isn't really required (at least not
> >> public)
> >> * but would be a convenience for "batch"/atomic changes to configuration
> >> values -
> >> * this is possible if we switch from volatile to a r/w locking mechanism
> >> */
> >> public void reconfigure (GOPConfig config) {
> >> mut1 = config.getMut1;
> >> mut2 = config.getMut2;
> >> }
> >>
> >> public void setMut1 (int m) {
> >> mut1 = m;
> >> }
> >>
> >> public int getMut1 () {
> >> return mut1;
> >> }
> >>
> >>
> >> }
> >>
> >> I wonder, with this modelwhat is the reason for having an immutable
> >> configuration instance if we're going to copy the values locally for (at
> >> least) mutability purposes? I believe the attraction of the immutable
> >> configuration instance was for concurrency issues...but with this model, we
> >> would need to use pool-local syncronization (locking) anyway.
> >>
> >> I wrote a quick mock-up implementation like this, using a
> >> ReentrantReadWriteLock, and the amount of concurrency work in each
> >> pool/factory started to pile up. We already identified that inheritance of
> >> the Pool/Factory classes might not be the best approach (I agree with this
> >> as well...which would cause POOL-177 to no longer be implemented)...so this
> >> means duplication of synchronization code as well.
> >>
> >> I think I'm falling back to my initial thought on this in that the config
> >> classes should, IMO, either be mutable (where appropriate) and made thread
> >> safe (internally synchronized) to reduce the amount of concurrency work
> >> needed in each class that aggregates the instance...or immutable and any
> >> changes to the config instance needs to be done by going back to the
> Builder
> >> (something like new Builder(configInstance).change().create());) and then
> >> the config reference in each pool/factory could be made volatile.
> >>
> >> I know this is confusing in emailI would be glad to create a quick
> patch
> >> or UML for this to clear things up if this would help.
> >>
> >> Thoughts?
> >>
> >> S
> >
> > -
> > 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: VFS release
On Nov 30, 2010, at 1:20 PM, Gary Gregory wrote: >> -Original Message- >> From: Ralph Goers [mailto:ralph.go...@dslextreme.com] >> Sent: Tuesday, November 30, 2010 16:09 >> To: Commons Developers List >> Subject: Re: VFS release >> >> >> On Nov 30, 2010, at 1:02 PM, Gary Gregory wrote: Although the wiki is fine it would be better to use a common >> checkstyle.xml. >>> >>> Yes! Can we put that in commons-parent and have it kick in automagically? >>> >> >> Not unless commons-parent is changed from a project of type pom to a project >> of type jar. The checkstyle.xml would be the only thing in the jar. This is >> actually the way the checkstyle plugin team recommends incorporating a >> checkstyle.xml into a multiproject build. > > That's fine with me. The reuse is worth it. I am sure there are other things > we can reuse as well. That make [commons] more, well, [commons]-felling. > > Would that break all projects? > It shouldn't. A project of type pom doesn't actually deliver an artifact and only deploys a pom to the repository. Any other type of project will deploy an artifact and a pom. However, I don't think I've ever worked with a project where the parent wasn't of type pom. Ralph - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
RE: VFS release
> -Original Message- > From: Ralph Goers [mailto:ralph.go...@dslextreme.com] > Sent: Tuesday, November 30, 2010 16:24 > To: Commons Developers List > Subject: Re: VFS release > > > On Nov 30, 2010, at 1:18 PM, Gary Gregory wrote: > > >> -Original Message- > >> From: Ralph Goers [mailto:ralph.go...@dslextreme.com] > >> Sent: Tuesday, November 30, 2010 16:06 > >> To: Commons Developers List > >> Subject: Re: VFS release > >> > >>> pse default ordering scheme for imports. > >> > >> IntelliJ defaults to. > >> > >> import all other imports > >> > >> import javax.* > >> import java.* > >> > >> import static all other imports > >> > >> I guess I've gotten used to this over the years. > > > > That is, comically, the opposite of Eclipse. > > > > I don't care as much about the order as I do about consistency in [commons]. > I am sure we could argue about which order 'makes sense' ;) but let's not go > there unless we are so bored that we need something like that to talk about! > :) > > > > I'm all for consistency. However, the order of groups of imports is not > something I'm very concerned about. Most teams I've been involved with start > from Sun's documented rules (http://www.oracle.com/technetwork/java/codeconv- > 138413.html) then publish exceptions to it, such as curly braces on the next > line instead of the end of the line. Ok, how about pushing checkstyle.xml up to commons-parent and associated Maven magic? Gary > > 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
[g...@vmgump]: Project commons-io-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-io-test has an issue affecting its community integration. This issue affects 1 projects. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - commons-io-test : Apache Commons Full details are available at: http://vmgump.apache.org/gump/public/apache-commons/commons-io-test/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -INFO- Optional dependency velocity-engine failed with reason build failed -WARNING- Overriding Maven settings: [/srv/gump/public/workspace/apache-commons/io/gump_mvn_settings.xml] -DEBUG- (Apache Gump generated) Apache Maven Settings in: /srv/gump/public/workspace/apache-commons/io/gump_mvn_settings.xml -INFO- Failed with reason build failed -DEBUG- Maven POM in: /srv/gump/public/workspace/apache-commons/io/pom.xml -INFO- Project Reports in: /srv/gump/public/workspace/apache-commons/io/target/surefire-reports The following work was performed: http://vmgump.apache.org/gump/public/apache-commons/commons-io-test/gump_work/build_apache-commons_commons-io-test.html Work Name: build_apache-commons_commons-io-test (Type: Build) Work ended in a state of : Failed Elapsed: 2 mins Command Line: /opt/maven2/bin/mvn --batch-mode --settings /srv/gump/public/workspace/apache-commons/io/gump_mvn_settings.xml test [Working Directory: /srv/gump/public/workspace/apache-commons/io] M2_HOME: /opt/maven2 - Running org.apache.commons.io.input.TailerTest Tests run: 3, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 1.241 sec <<< FAILURE! Running org.apache.commons.io.input.CountingInputStreamTest Tests run: 10, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.108 sec Running org.apache.commons.io.input.XmlStreamReaderTest Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.621 sec Running org.apache.commons.io.input.ProxyReaderTest Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.086 sec Running org.apache.commons.io.output.NullWriterTest Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.055 sec Running org.apache.commons.io.input.compatibility.XmlStreamReaderUtilitiesCompatibilityTest Tests run: 8, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.09 sec Running org.apache.commons.io.output.TeeOutputStreamTest Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.055 sec Running org.apache.commons.io.comparator.SizeFileComparatorTest Tests run: 9, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 1.802 sec Running org.apache.commons.io.FileUtilsListFilesTestCase Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.092 sec Running org.apache.commons.io.comparator.DirectoryFileComparatorTest Tests run: 7, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.069 sec Running org.apache.commons.io.filefilter.AndFileFilterTestCase Tests run: 5, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.065 sec Running org.apache.commons.io.TaggedIOExceptionTest Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.069 sec Running org.apache.commons.io.input.TaggedInputStreamTest Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.067 sec Running org.apache.commons.io.HexDumpTest Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.129 sec Running org.apache.commons.io.input.CloseShieldInputStreamTest Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.061 sec Results : Failed tests: Tests run: 749, Failures: 1, Errors: 0, Skipped: 0 [INFO] [ERROR] BUILD FAILURE [INFO] [INFO] There are test failures. Please refer to /srv/gump/public/workspace/apache-commons/io/target/surefire-reports for the individual test results. [INFO] [INFO] For more information, run Maven with the -e switch [INFO] [INFO] Total time: 1 minute 59 seconds [INFO] Finished at: Tue Nov 30 23:53:17 UTC 2010 [INFO] Final Memory: 38M/92M [INFO] - To subscribe to this information via syndicated feeds: - RSS: http://vmgump.apache.org/gump/public/apache-commons/commons-io-test/rss.xml - Atom: http://vmgump.apache.org/gump/public/apache-commons/commons-io-test/atom.xml == Gump Tracking Only === Produced b
Re: VFS release
On Nov 30, 2010, at 2:12 PM, Gary Gregory wrote: > > Ok, how about pushing checkstyle.xml up to commons-parent and associated > Maven magic? > Can we do that after releasing VFS 2.0? Ralph
RE: VFS release
> -Original Message- > From: Ralph Goers [mailto:ralph.go...@dslextreme.com] > Sent: Tuesday, November 30, 2010 18:59 > To: Commons Developers List > Subject: Re: VFS release > > > On Nov 30, 2010, at 2:12 PM, Gary Gregory wrote: > > > > > Ok, how about pushing checkstyle.xml up to commons-parent and associated > Maven magic? > > > > Can we do that after releasing VFS 2.0? Sure! Gary > > Ralph - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [pool] Pool config vs. factory hierarchies.
Hi Gary :)
thanks for the feedback, IMHO once the Configuration for
Generic(Keyed)ObjectPool(Factory) will be fixed, we could start
thinking about a new release of the new pool. This evening/tonight (in
my local time) I'll start re-arranging stuff, of course suggestions
will be more than appreciated.
About duplication: I agree with you, but after re-reading all the
mails we wrote about it, I recently become convinced that
Configuration for GKOB/GOB have different semantic even if some
configuration property have same name/type, what's your opinion about
it? Many thanks in advance!
Have a nice day,
Simo
http://people.apache.org/~simonetripodi/
http://www.99soft.org/
On Tue, Nov 30, 2010 at 11:02 PM, Gary Gregory
wrote:
> Yes, I thought we were on a roll there! Lots of good discussions and then...
> quiet. That's OK though. We all get busy. Time to come back and reflect.
>
> I am still looking for these goals:
> - Generics released ASAP. I would be OK for a earlier release just to get
> this out.
> - Better names for properties and methods
> - Refactor to remove duplication
>
> Gary
>
>> -Original Message-
>> From: Simone Tripodi [mailto:simone.trip...@gmail.com]
>> Sent: Tuesday, November 30, 2010 09:33
>> To: Commons Developers List
>> Subject: Re: [pool] Pool config vs. factory hierarchies.
>>
>> Hi all guys,
>> sorry for resurrecting a zombie message, but I've been busy at work
>> and haven't had the chance to contribute at all.
>> I could re-start committing code according to the requirements
>> described by Phil, If it works for you, so other tasks like
>> JMX/autoconfigure can be unlocked, please let me know.
>> Have a nice day,
>> Simo
>>
>> http://people.apache.org/~simonetripodi/
>> http://www.99soft.org/
>>
>>
>>
>> On Wed, Nov 3, 2010 at 11:01 PM, Phil Steitz wrote:
>> >
>> >
>> >
>> >
>> > On Nov 3, 2010, at 5:03 PM, Steven Siebert wrote:
>> >
>> >>>
>> >>>
>> >>> You restore the pool fields that used to hold the configuration setting
>> >>> properties and leave the getters and setters (for the mutable ones) in
>> >>> place.
>> >>>
>> >>> Phil
>> >>>
>> >>>
>> >> so something like this?
>> >>
>> >> public class GOP extends {
>> >>
>> >> /**
>> >> * ref to immutable config reference, immutable config values are either
>> >> referred directly here
>> >> * or are copied to a final instance field
>> >> */
>> >> private GOPConfig config
>> >
>> > No. There is no config member. It is used only to encapsulate the
>> parameters of the ctors. The GOP class stores the config data in individual
>> fields, accessed by getters and setters. The setters at least are
>> synchronized using the pool monitor. Look at the old code. What I am
>> proposing is that we limit the use and lifetime of the config objects to the
>> ctors and/or factories.
>> >
>> > Phil
>> >>
>> >>
>> >> //mutable configuration values are mutated/accessed from pool instance
>> >> private volatile int mut1; //probably better to use read/write locks
>> >> private volatile int mut2;
>> >>
>> >> public GOP (GOPConfig config) {
>> >> this.config = config;
>> >> reconfigure(config);
>> >> }
>> >>
>> >> /**
>> >> * using this model, this method isn't really required (at least not
>> >> public)
>> >> * but would be a convenience for "batch"/atomic changes to
>> >> configuration
>> >> values -
>> >> * this is possible if we switch from volatile to a r/w locking
>> >> mechanism
>> >> */
>> >> public void reconfigure (GOPConfig config) {
>> >> mut1 = config.getMut1;
>> >> mut2 = config.getMut2;
>> >> }
>> >>
>> >> public void setMut1 (int m) {
>> >> mut1 = m;
>> >> }
>> >>
>> >> public int getMut1 () {
>> >> return mut1;
>> >> }
>> >>
>> >>
>> >> }
>> >>
>> >> I wonder, with this modelwhat is the reason for having an immutable
>> >> configuration instance if we're going to copy the values locally for (at
>> >> least) mutability purposes? I believe the attraction of the immutable
>> >> configuration instance was for concurrency issues...but with this model,
>> >> we
>> >> would need to use pool-local syncronization (locking) anyway.
>> >>
>> >> I wrote a quick mock-up implementation like this, using a
>> >> ReentrantReadWriteLock, and the amount of concurrency work in each
>> >> pool/factory started to pile up. We already identified that inheritance
>> >> of
>> >> the Pool/Factory classes might not be the best approach (I agree with this
>> >> as well...which would cause POOL-177 to no longer be implemented)...so
>> >> this
>> >> means duplication of synchronization code as well.
>> >>
>> >> I think I'm falling back to my initial thought on this in that the config
>> >> classes should, IMO, either be mutable (where appropriate) and made thread
>> >> safe (internally synchronized) to reduce the amount of concurrency work
>> >> needed in each class that aggregates the instance...or immutable and any
>> >> changes to the confi
Re: [lang3] Test Fail in Headless Mode (at Least on a Mac)
On Fri, Nov 26, 2010 at 12:49 AM, Henri Yandell wrote: > On Wed, Nov 24, 2010 at 3:51 AM, sebb wrote: >> On 24 November 2010 11:02, Stefan Bodewig wrote: >>> On 2010-11-24, sebb wrote: >>> On 24 November 2010 09:46, Stefan Bodewig wrote: > On 2010-11-22, Jörg Schaible wrote: >>> >> Stefan Bodewig wrote: >>> >>> The commons-lang3 builds fail[2] and too me it looks as if this was >>> because AWT is not running in headless mode, >>> > confirmed by passing -DargLine=-Djava.awt.headless=true to mvn - the > builds now pass. >>> >>> I am suprised the problem doesn't show up in the other CI builds. >>> > Still surprised 8-) >>> > It doesn't show up inside Gump on Linux or FreeBSD running OpenJDK or > the FreeBSD port of Sun's VM either - maybe this codebase's AWT detects > there is no X-Server and switches to headless mode without any help. >>> Or are those nodes running a frame buffer (I think that is the correct name)? >>> >>> I don't recall installing Xvfb (the X server running in a virtual frame >>> buffer) but it could have been pulled in as a dependency - and I'm >>> pretty sure we don't start it even if it is installed. No, I don't >>> think the builds have any X server to connect to. >>> Since there are headless hosts, maybe code which is supposed to be able to run anywhere (e.g. LANG) needs to take this into account? >>> I.e. Perhaps MacGump has found a bug in Lang? >>> >>> The tests that failed are the ones for the event package. I don't see >>> any uses of AWT in the main code but the tests use AWT classes >>> (ActionEvent and ActionListener). It seems as if the static initializer >>> of either class already requires a working window system on a Mac - it >>> may not be required on OpenJDK's AWT. >>> >>> I don't think the lang3 code requires a window system - so no bug in the >>> main code - but its tests do. >> >> IMO the tests should then be fixed (I may have time to look later). >> >> If there is a suitable alternative to the AWT events then use that, >> otherwise allow for the test failure when running headless. >> >> Seems to me it's more useful for Gump to point out these problems than >> to try and hide them. > > +1. > > Perhaps: > > javax.naming.event.ObjectChangeListener > javax.naming.event.NamingEvent I've fixed this in r1040879. Generally I opted for using java.beans listeners. Hen - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
