[lang] testTimeZoneStrategyPattern() runs twice for no apparent gain
Hi everyone, Lang takes a few minutes to build on my system, so I was examining execution times of tests to see if anything can be improved. I noticed that FastDateParserTest.testTimeZoneStrategyPattern() takes quite a long time to execute (over 40 seconds for me). Then I noticed this is executed twice, once for FastDateParserTest and once for the subclass FastDateFormat_ParserTest. Yet the method doesn't appear to use the result of getInstance(). As a result, we don't want this being executed by subclasses as it gains us nothing. Before I refactor this test, possibly into a separate TimeZoneStrategyTest class, can anyone suggest a reason not to? Or a better solution / location for the test? Duncan - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [lang] testTimeZoneStrategyPattern() runs twice for no apparent gain
Duncan, Nothing lost by moving into separate test class. Speed gained. Chas On Apr 11, 2015, at 12:02 AM, Duncan Jones dun...@wortharead.com wrote: Hi everyone, Lang takes a few minutes to build on my system, so I was examining execution times of tests to see if anything can be improved. I noticed that FastDateParserTest.testTimeZoneStrategyPattern() takes quite a long time to execute (over 40 seconds for me). Then I noticed this is executed twice, once for FastDateParserTest and once for the subclass FastDateFormat_ParserTest. Yet the method doesn't appear to use the result of getInstance(). As a result, we don't want this being executed by subclasses as it gains us nothing. Before I refactor this test, possibly into a separate TimeZoneStrategyTest class, can anyone suggest a reason not to? Or a better solution / location for the test? Duncan - 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: [COMMONSRDF] GroupID for incubation releases
On Mon, Mar 30, 2015 at 2:07 PM, Benedikt Ritter brit...@apache.org wrote: Hello Reto, 2015-03-30 14:45 GMT+02:00 Reto Gmür r...@apache.org: Hi all, The clerezza commons RDF proposal that was in the sandbox and is now in the clerezza-rdf-core repository has been changed to use org.apache.clerezza.commons-rdf. As you know if all goes well clerezza will be based in the result of the incubating project. If however this project should unfortunately not lead to something generic enough to be used for interfacing arbitrary data as RDF and thus be usable for clerezza, then clerezza might reactivate its commons-rdf proposal. It would then be up to commons to decide which proposal to adopt and under which name. We (the Apache Commons community) have already stated, that we don't have the necessary knowledge about RDF to make such a decision. I would prefer more people from clerezza joining this ML and build consensus with the incubating commons rdf community about how an implementation of the RDF specification should look like. It might be hard to reach an acceptable solution if the result of one year on Github are taken as unmodifiable except when there is 100% agreement on a change. Even without having the commons community diving deep into RDF it might become clear that one API is better suited for triple stores and their requirement while the other is more suitable to exposing arbitrary data source using the RDF model. So if the result is not something that can be used in all usecases having two commons project relating to RDF but with an distinct goal might also be an option. Cheers, Reto Till then I would prefer this project to use a group ID outside org.apache.commons. Yes it would probably be better to resolve this conflict and build consensus before publishing artifacts under the commons group id. Benedikt Cheers, Reto Hi all, all this looks sensible to me. cheers, Enrico -- Enrico Daga http://about.me/enridaga On 29 March 2015 at 17:25, Sergio Fernández wik...@apache.org wrote: On 28/03/15 17:40, Benedikt Ritter wrote: So for Commons RDF I would recommend the following: parent: org.apache.commons:commons-rdf-parent api: org.apache.commons:commons-rdf-api impl: org.apache.commons:commons-rdf-impl Would that work for you? Yes, it does. I've just implemented it (commit 1296de032601ada0d244cca51591d6eeeba449cc). I'd like to ask: does it work for everybody? -- Sergio Fernández Partner Technology Manager Redlink GmbH m: +43 660 2747 925 e: sergio.fernan...@redlink.co w: http://redlink.co - 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 -- http://people.apache.org/~britter/ http://www.systemoutprintln.de/ http://twitter.com/BenediktRitter http://github.com/britter
Re: [COMMONSRDF] GroupID for incubation releases
On 11 April 2015 at 22:11, Reto Gmür r...@apache.org wrote: On Mon, Mar 30, 2015 at 2:07 PM, Benedikt Ritter brit...@apache.org wrote: Hello Reto, 2015-03-30 14:45 GMT+02:00 Reto Gmür r...@apache.org: Hi all, The clerezza commons RDF proposal that was in the sandbox and is now in the clerezza-rdf-core repository has been changed to use org.apache.clerezza.commons-rdf. As you know if all goes well clerezza will be based in the result of the incubating project. If however this project should unfortunately not lead to something generic enough to be used for interfacing arbitrary data as RDF and thus be usable for clerezza, then clerezza might reactivate its commons-rdf proposal. It would then be up to commons to decide which proposal to adopt and under which name. We (the Apache Commons community) have already stated, that we don't have the necessary knowledge about RDF to make such a decision. I would prefer more people from clerezza joining this ML and build consensus with the incubating commons rdf community about how an implementation of the RDF specification should look like. It might be hard to reach an acceptable solution if the result of one year on Github are taken as unmodifiable except when there is 100% agreement on a change. You were privy to all of the public discussions on GitHub, and many of the private discussions just before setting up the project publicly. Please do not imply that this was your first opportunity to bring up these issues, or that we had not responded at all to the issues you did bring up in the past. Apart from the structural constraints of having an entire interface driven API, and there being no clear reason why the interface names themselves should be changed to suit you, do you have other issues where getting ~100 percent agreement has failed and you would like some further discussion. Even without having the commons community diving deep into RDF it might become clear that one API is better suited for triple stores and their requirement while the other is more suitable to exposing arbitrary data source using the RDF model. So if the result is not something that can be used in all usecases having two commons project relating to RDF but with an distinct goal might also be an option. If you could articulate why the current interface based method makes it unsuitable for your use cases it would definitely help. In particular, some examples of where Clerezza could map a data source to RDF somewhow, but it would be impossible with commons-rdf-api, then we can start to discuss it further. Right now you have only implied that the difficulty exists without articulating it. Thanks, Peter - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
[functor] [PATCH] Add predicates
Hi all, FUNCTOR-30 [1] contains a patch for [functor] that I'd like to merge. I will spend one or two other days reviewing the code style tests, and will wait till the middle of the week before merging, so that others can take some time to review too. The patch provides several predicates to use with Strings, such as IsNull, IsAlpha, IsAlphanumeric, etc. Most of them calling existing methods in [lang]'s StringUtils. All the best,Bruno [1] https://issues.apache.org/jira/browse/FUNCTOR-30
