Re: [dbutils] Releasing 1.5
Henri Yandell wrote: >I think you just PGP with your release key. Later on we can strengthen >the signing by adding you to the web-of-trust. +1. Don't forget to add your public key to the KEYS file. That is a must. Being in the web of trust is a (very) nice to have. Mark >Hen > >On Mon, Nov 28, 2011 at 6:20 PM, William Speirs >wrote: >> One potential issue though, I have not created an Apache PGP key yet, >so I >> will not have a chance to get it signed by anyone. What is the >protocol for >> getting one's key signed? >> >> Thanks... >> >> Bill- - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [dbutils] Releasing 1.5
I think you just PGP with your release key. Later on we can strengthen the signing by adding you to the web-of-trust. Hen On Mon, Nov 28, 2011 at 6:20 PM, William Speirs wrote: > I haven't forgotten about this... been tied up at work with a new employee. > > One potential issue though, I have not created an Apache PGP key yet, so I > will not have a chance to get it signed by anyone. What is the protocol for > getting one's key signed? > > Thanks... > > Bill- > > On Sat, Nov 26, 2011 at 4:09 PM, Simone Tripodi > wrote: > >> Hi Bill, >> Continuum just notified a build failure :P >> If you intend to cut a new release, read our `Creating Releases` page >> on wiki[1], count on me if you need help (I was the last on cutting a >> DbUtils release) >> Have a nice weekend, all the best! >> Simo >> >> [1] http://wiki.apache.org/commons/CreatingReleases >> >> http://people.apache.org/~simonetripodi/ >> http://simonetripodi.livejournal.com/ >> http://twitter.com/simonetripodi >> http://www.99soft.org/ >> >> >> >> On Sat, Nov 26, 2011 at 9:22 PM, Bill Speirs >> wrote: >> > Does anyone have thoughts on releasing commons-dbutils 1.5? There are >> > 5 changes since 1.4 (issues 84, 77, 73, 67, and 66), and I think >> > that's probably enough to warrant a new release. >> > >> > I'm new to this whole process, so I'm unsure as to what to do next. >> > >> > Thanks... >> > >> > Bill- >> > >> > - >> > 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
[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 247 runs. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - commons-proxy-test : Apache Commons Full details are available at: http://vmgump.apache.org/gump/public/apache-commons/commons-proxy-test/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -WARNING- Overriding Maven settings: [/srv/gump/public/workspace/apache-commons/proxy/gump_mvn_settings.xml] -DEBUG- (Apache Gump generated) Apache Maven Settings in: /srv/gump/public/workspace/apache-commons/proxy/gump_mvn_settings.xml -INFO- Failed with reason build failed -DEBUG- Maven POM in: /srv/gump/public/workspace/apache-commons/proxy/pom.xml -INFO- Project Reports in: /srv/gump/public/workspace/apache-commons/proxy/target/surefire-reports The following work was performed: http://vmgump.apache.org/gump/public/apache-commons/commons-proxy-test/gump_work/build_apache-commons_commons-proxy-test.html Work Name: build_apache-commons_commons-proxy-test (Type: Build) Work ended in a state of : Failed Elapsed: 11 secs Command Line: /opt/maven2/bin/mvn --batch-mode --settings /srv/gump/public/workspace/apache-commons/proxy/gump_mvn_settings.xml test [Working Directory: /srv/gump/public/workspace/apache-commons/proxy] M2_HOME: /opt/maven2 - Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.003 sec Running org.apache.commons.proxy.factory.util.TestMethodSignature Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.003 sec Running org.apache.commons.proxy.provider.TestConstantProvider Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.003 sec Running org.apache.commons.proxy.interceptor.TestFilteredInterceptor Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.033 sec Running org.apache.commons.proxy.interceptor.filter.TestPatternFilter Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.004 sec Running org.apache.commons.proxy.interceptor.TestSerializingInterceptor Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.016 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.012 sec Running org.apache.commons.proxy.factory.javassist.TestJavassistProxyFactory Tests run: 37, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.186 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.022 sec Results : Tests in error: testInvalidHandlerName(org.apache.commons.proxy.invoker.TestXmlRpcInvoker) Tests run: 179, Failures: 0, Errors: 1, Skipped: 0 [INFO] [ERROR] BUILD FAILURE [INFO] [INFO] There are test failures. Please refer to /srv/gump/public/workspace/apache-commons/proxy/target/surefire-reports for the individual test results. [INFO] [INFO] For more information, run Maven with the -e switch [INFO] [INFO] Total time: 10 seconds [INFO] Finished at: Tue Nov 29 06:05:23 UTC 2011 [INFO] Final Memory: 24M/58M [INFO] - To subscribe to this information via syndicated feeds: - RSS: http://vmgump.apache.org/gump/public/apache-commons/commons-proxy-test/rss.xml - Atom: http://vmgump.apache.
[GUMP@vmgump]: Project commons-chain (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-chain has an issue affecting its community integration. This issue affects 1 projects. The current state of this project is 'Failed', with reason 'Configuration Failed'. For reference only, the following projects are affected by this: - commons-chain : GoF "Chain of Responsibility" pattern Full details are available at: http://vmgump.apache.org/gump/public/apache-commons/commons-chain/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-chain-29112011.jar] identifier set to project name -INFO- Failed with reason configuration failed -ERROR- Circular Dependency. Path: [Project:castor-core, Project:castor-reactor, Project:castor, Project:portals-pluto-api-1.0, Project:commons-chain, Project:doxia-site-renderer, Project:slf4j, Project:mina-core, Project:mina, Project:shared-i18n, Project:shared-asn1-api, Project:shared-ldap-codec-core, Project:shared-ldap-extras-codec] -> slf4j. -ERROR- Circular Dependency. Path: [Project:castor-reactor, Project:castor, Project:portals-pluto-api-1.0, Project:commons-chain, Project:doxia-site-renderer, Project:slf4j, Project:mina-core, Project:mina, Project:shared-i18n, Project:shared-asn1-api, Project:shared-ldap-codec-core, Project:shared-ldap-extras-codec] -> doxia-site-renderer. -ERROR- Circular Dependency. Path: [Project:httpcomponents-core, Project:httpcomponents-client, Project:castor-reactor, Project:castor, Project:portals-pluto-api-1.0, Project:commons-chain, Project:doxia-site-renderer, Project:slf4j, Project:mina-core, Project:mina, Project:shared-i18n, Project:shared-asn1-api, Project:shared-ldap-codec-core, Project:shared-ldap-extras-codec] -> doxia-site-renderer. -INFO- Failed to extract fallback artifacts from Gump Repository To subscribe to this information via syndicated feeds: - RSS: http://vmgump.apache.org/gump/public/apache-commons/commons-chain/rss.xml - Atom: http://vmgump.apache.org/gump/public/apache-commons/commons-chain/atom.xml == Gump Tracking Only === Produced by Apache Gump(TM) version 2.3. Gump Run 1229112011, vmgump.apache.org:vmgump:1229112011 Gump E-mail Identifier (unique within run) #37. -- Apache Gump http://gump.apache.org/ [Instance: vmgump] - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
[GUMP@vmgump]: Project commons-fileupload (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-fileupload has an issue affecting its community integration.
This issue affects 9 projects.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
- commons-fileupload : Commons File Upload Package
- jakarta-tomcat-4.0 : Servlet 2.3 and JSP 1.2 Reference Implementation
- jakarta-tomcat-catalina : Servlet 2.4 Reference Implementation
- jakarta-tomcat-coyote-tomcat4 : Connectors to various web servers
- jakarta-tomcat-jk : Connectors to various web servers
- portals-pluto-portal-1.0 : JSR168 Container
- solr : Java Based Search Engine
- solr-test : Java Based Search Engine
- tomcat-catalina : Servlet 2.3 and JSP 1.2 Reference Implementation
Full details are available at:
http://vmgump.apache.org/gump/public/apache-commons/commons-fileupload/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-fileupload-29112011.jar] identifier set to
project name
-INFO- Failed with reason build failed
-INFO- Failed to extract fallback artifacts from Gump Repository
The following work was performed:
http://vmgump.apache.org/gump/public/apache-commons/commons-fileupload/gump_work/build_apache-commons_commons-fileupload.html
Work Name: build_apache-commons_commons-fileupload (Type: Build)
Work ended in a state of : Failed
Elapsed: 3 secs
Command Line: /usr/lib/jvm/java-6-openjdk/bin/java -Djava.awt.headless=true
-Dbuild.sysclasspath=only
-Xbootclasspath/p:/srv/gump/public/workspace/xml-xerces2/build/xercesImpl.jar:/srv/gump/public/workspace/xml-commons/java/external/build/xml-apis.jar
org.apache.tools.ant.Main -Dgump.merge=/srv/gump/public/gump/work/merge.xml
-Dmaven.final.name=commons-fileupload-29112011 -f build-gump.xml jar
[Working Directory: /srv/gump/public/workspace/apache-commons/fileupload]
CLASSPATH:
/usr/lib/jvm/java-6-openjdk/lib/tools.jar:/srv/gump/public/workspace/apache-commons/fileupload/target/classes:/srv/gump/public/workspace/ant/dist/lib/ant.jar:/srv/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/srv/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/srv/gump/public/workspace/ant/dist/lib/ant-junit.jar:/srv/gump/public/workspace/ant/dist/lib/ant-swing.jar:/srv/gump/public/workspace/ant/dist/lib/ant-apache-resolver.jar:/srv/gump/public/workspace/ant/dist/lib/ant-apache-xalan2.jar:/srv/gump/public/workspace/xml-commons/java/build/resolver.jar:/srv/gump/public/workspace/xml-commons/java/external/build/xml-apis-ext.jar:/srv/gump/public/workspace/apache-commons/beanutils/dist/commons-beanutils-29112011.jar:/srv/gump/public/workspace/jakarta-servletapi-5/jsr154/dist/lib/servlet-api.jar:/srv/gump/public/workspace/portals-pluto-1.0/api/target/portlet-api-1.0.jar:/srv/gump/public/workspace/apache-commons/io/target/commons-io-2.2-SNAPSHOT.jar
-
Buildfile: /srv/gump/public/workspace/apache-commons/fileupload/build-gump.xml
jar:
[mkdir] Created dir:
/srv/gump/public/workspace/apache-commons/fileupload/target/classes
[javac] Compiling 28 source files to
/srv/gump/public/workspace/apache-commons/fileupload/target/classes
[javac]
/srv/gump/public/workspace/apache-commons/fileupload/src/java/org/apache/commons/fileupload/portlet/PortletFileUpload.java:22:
package javax.portlet does not exist
[javac] import javax.portlet.ActionRequest;
[javac] ^
[javac]
/srv/gump/public/workspace/apache-commons/fileupload/src/java/org/apache/commons/fileupload/portlet/PortletFileUpload.java:69:
cannot find symbol
[javac] symbol : class ActionRequest
[javac] location: class
org.apache.commons.fileupload.portlet.PortletFileUpload
[javac] public static final boolean isMultipartContent(ActionRequest
request) {
[javac]^
[javac]
/srv/gump/public/workspace/apache-commons/fileupload/src/java/org/apache/commons/fileupload/portlet/PortletFileUpload.java:117:
cannot find symbol
[javac] symbol : class ActionRequest
[javac] location: class
org.apache.commons.fileupload.portlet.PortletFileUpload
[javac] public List /* FileItem */ parseRequest(ActionRequest request)
[javac] ^
[javac]
/srv/gump/public/workspace/apache-commons/fileupload/src/java/org/apache/commons/fileupload/portlet/PortletFileUpload.java:138:
cannot find symbol
[javac] symbol : class ActionRequest
[javac] location: class
org.apache.commons.fileupload.portlet.PortletFileUpload
[javac] public FileItemIterator getItemI
Re: [dbutils] Releasing 1.5
I haven't forgotten about this... been tied up at work with a new employee. One potential issue though, I have not created an Apache PGP key yet, so I will not have a chance to get it signed by anyone. What is the protocol for getting one's key signed? Thanks... Bill- On Sat, Nov 26, 2011 at 4:09 PM, Simone Tripodi wrote: > Hi Bill, > Continuum just notified a build failure :P > If you intend to cut a new release, read our `Creating Releases` page > on wiki[1], count on me if you need help (I was the last on cutting a > DbUtils release) > Have a nice weekend, all the best! > Simo > > [1] http://wiki.apache.org/commons/CreatingReleases > > http://people.apache.org/~simonetripodi/ > http://simonetripodi.livejournal.com/ > http://twitter.com/simonetripodi > http://www.99soft.org/ > > > > On Sat, Nov 26, 2011 at 9:22 PM, Bill Speirs > wrote: > > Does anyone have thoughts on releasing commons-dbutils 1.5? There are > > 5 changes since 1.4 (issues 84, 77, 73, 67, and 66), and I think > > that's probably enough to warrant a new release. > > > > I'm new to this whole process, so I'm unsure as to what to do next. > > > > Thanks... > > > > Bill- > > > > - > > 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: [math] Inconsistencies (bugs) in PascalDistribution?
Hi Mikkel > > Thanks for discovering this! I did the implementation, and apparently > assumed notation as the referred source. Sorry for this. > I think there is nothing wrong in the source. Only, you adopted a different definition of the random variable represented by the implemented PascalDistribution: 1. In wikipedia, the r-parameter is the total number of failures, 2. In the CM implementation, the Javadoc states that r is the total number of successes, and the PMF is (correctly) derived accordingly. > > We should also check the variance - this might be suffering from wrong > notation as well. > Yes, I'll do that, too! > > Cheers, Mikkel. > > Now is not a good time to work on o.a.c.m.distribution, since Christian is working on MATH-703. Once this is done, I'll commit a patch to correct this. You will be very welcome to review the changes (except of course if you want to alter your baby yourself ;) ). Sébastien - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [csv] API design
We do need rewrite rfc4180
which seemed to me always a little too short.
Am 29.11.2011 um 00:05 schrieb Matt Benson:
> On Mon, Nov 28, 2011 at 4:55 PM, Erhan Bagdemir
> wrote:
>> I meant the Collection members of beans.
>> I think that it won't be so easy to
>> hold a complex data structure in human-readable form in a "singe" csv file.
>
> This doesn't seem different from what I proposed. Difficult != impossible.
>
> Matt
>
>>
>>
>>
>> Am 28.11.2011 um 22:28 schrieb Simone Tripodi:
>>
>>> What do you mean by collections? A single collection of CSV annotated
>>> elements, or inner collection of a CSV annotated element?
>>> I have doubts on option #2, I would expect that any CSV record is
>>> mapped to a single Java POJO... or not?
>>> Simo
>>>
>>> http://people.apache.org/~simonetripodi/
>>> http://simonetripodi.livejournal.com/
>>> http://twitter.com/simonetripodi
>>> http://www.99soft.org/
>>>
>>>
>>>
>>> On Mon, Nov 28, 2011 at 9:33 PM, Erhan Bagdemir
>>> wrote:
Apache JCA
Java CSV API :-)
It is a very cool approach to use annotations for mapping CSV fields with
beans.
It can be even configured using a class annotation like this:
@CSVEntity(seperator= COMMA, quotas=true|false,... )
public class Person {
@CSVField(header="NAME", width=15)
}
But how will the Collections be handled ?
Am 28.11.2011 um 21:14 schrieb Simone Tripodi:
> Hi all,
> I like the idea of having annotations, and here in CVS you are
> proposing IMHO a very good approach. If you need some support, as
> mentioned by Matt, I already deeply explored Annotations analysis at
> runtime, have a look at[1]
>
> @Matt: you reminded me an old idea I had about opening the digester to
> other formats, not just XML... coming soon with a new proposal :)
>
> Have a nice day,
> Simo
>
> [1] http://commons.apache.org/digester/guide/annotations.html
>
> http://people.apache.org/~simonetripodi/
> http://simonetripodi.livejournal.com/
> http://twitter.com/simonetripodi
> http://www.99soft.org/
>
>
>
> On Mon, Nov 28, 2011 at 6:09 PM, Matt Benson wrote:
>> On Fri, Nov 11, 2011 at 12:50 PM, Emmanuel Bourg
>> wrote:
>> [SNIP]
>>>
>>> The other idea relates to the bean mapping feature. CSVFormat could be
>>> generified and work on annotated classes. I imagine something like this:
>>>
>>>public class Person {
>>>@CSVField(trim = true)
>>>private String firstname;
>>>
>>>@CSVField(header="NAME", width=12)
>>>private String lastname;
>>>
>>>@CSVField(header="DATE", format="-MM-dd")
>>>private Date birthdate;
>>>}
>>>
>>> then:
>>>
>>>CSVFormat format = new CSVFormat().withType(Person.class);
>>>
>>>for (Person person : format.parse(in)) {
>>>
>>>}
>>>
>>>
>>> What do you think?
>>
>> These make me think of the annotation support Simo added to
>> [digester]. I wonder if there would be any value in extending
>> [digester]'s scope to formats beyond XML including CSV/flat files/etc.
>>
>> Matt
>>
>>>
>>>
>>> Emmanuel Bourg
>>>
>>>
>>>
>>>
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> For additional commands, e-mail: dev-h...@commons.apache.org
>>
>>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
-
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
>
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Re: [csv] API design
On Mon, Nov 28, 2011 at 4:55 PM, Erhan Bagdemir
wrote:
> I meant the Collection members of beans.
> I think that it won't be so easy to
> hold a complex data structure in human-readable form in a "singe" csv file.
This doesn't seem different from what I proposed. Difficult != impossible.
Matt
>
>
>
> Am 28.11.2011 um 22:28 schrieb Simone Tripodi:
>
>> What do you mean by collections? A single collection of CSV annotated
>> elements, or inner collection of a CSV annotated element?
>> I have doubts on option #2, I would expect that any CSV record is
>> mapped to a single Java POJO... or not?
>> Simo
>>
>> http://people.apache.org/~simonetripodi/
>> http://simonetripodi.livejournal.com/
>> http://twitter.com/simonetripodi
>> http://www.99soft.org/
>>
>>
>>
>> On Mon, Nov 28, 2011 at 9:33 PM, Erhan Bagdemir
>> wrote:
>>> Apache JCA
>>> Java CSV API :-)
>>> It is a very cool approach to use annotations for mapping CSV fields with
>>> beans.
>>>
>>> It can be even configured using a class annotation like this:
>>> @CSVEntity(seperator= COMMA, quotas=true|false,... )
>>> public class Person {
>>> @CSVField(header="NAME", width=15)
>>> }
>>>
>>> But how will the Collections be handled ?
>>>
>>>
>>> Am 28.11.2011 um 21:14 schrieb Simone Tripodi:
>>>
Hi all,
I like the idea of having annotations, and here in CVS you are
proposing IMHO a very good approach. If you need some support, as
mentioned by Matt, I already deeply explored Annotations analysis at
runtime, have a look at[1]
@Matt: you reminded me an old idea I had about opening the digester to
other formats, not just XML... coming soon with a new proposal :)
Have a nice day,
Simo
[1] http://commons.apache.org/digester/guide/annotations.html
http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/
On Mon, Nov 28, 2011 at 6:09 PM, Matt Benson wrote:
> On Fri, Nov 11, 2011 at 12:50 PM, Emmanuel Bourg
> wrote:
> [SNIP]
>>
>> The other idea relates to the bean mapping feature. CSVFormat could be
>> generified and work on annotated classes. I imagine something like this:
>>
>> public class Person {
>> @CSVField(trim = true)
>> private String firstname;
>>
>> @CSVField(header="NAME", width=12)
>> private String lastname;
>>
>> @CSVField(header="DATE", format="-MM-dd")
>> private Date birthdate;
>> }
>>
>> then:
>>
>> CSVFormat format = new CSVFormat().withType(Person.class);
>>
>> for (Person person : format.parse(in)) {
>>
>> }
>>
>>
>> What do you think?
>
> These make me think of the annotation support Simo added to
> [digester]. I wonder if there would be any value in extending
> [digester]'s scope to formats beyond XML including CSV/flat files/etc.
>
> Matt
>
>>
>>
>> Emmanuel Bourg
>>
>>
>>
>>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
>>>
>>>
>>> -
>>> 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: [csv] API design
I meant the Collection members of beans.
I think that it won't be so easy to
hold a complex data structure in human-readable form in a "singe" csv file.
Am 28.11.2011 um 22:28 schrieb Simone Tripodi:
> What do you mean by collections? A single collection of CSV annotated
> elements, or inner collection of a CSV annotated element?
> I have doubts on option #2, I would expect that any CSV record is
> mapped to a single Java POJO... or not?
> Simo
>
> http://people.apache.org/~simonetripodi/
> http://simonetripodi.livejournal.com/
> http://twitter.com/simonetripodi
> http://www.99soft.org/
>
>
>
> On Mon, Nov 28, 2011 at 9:33 PM, Erhan Bagdemir
> wrote:
>> Apache JCA
>> Java CSV API :-)
>> It is a very cool approach to use annotations for mapping CSV fields with
>> beans.
>>
>> It can be even configured using a class annotation like this:
>> @CSVEntity(seperator= COMMA, quotas=true|false,... )
>> public class Person {
>>@CSVField(header="NAME", width=15)
>> }
>>
>> But how will the Collections be handled ?
>>
>>
>> Am 28.11.2011 um 21:14 schrieb Simone Tripodi:
>>
>>> Hi all,
>>> I like the idea of having annotations, and here in CVS you are
>>> proposing IMHO a very good approach. If you need some support, as
>>> mentioned by Matt, I already deeply explored Annotations analysis at
>>> runtime, have a look at[1]
>>>
>>> @Matt: you reminded me an old idea I had about opening the digester to
>>> other formats, not just XML... coming soon with a new proposal :)
>>>
>>> Have a nice day,
>>> Simo
>>>
>>> [1] http://commons.apache.org/digester/guide/annotations.html
>>>
>>> http://people.apache.org/~simonetripodi/
>>> http://simonetripodi.livejournal.com/
>>> http://twitter.com/simonetripodi
>>> http://www.99soft.org/
>>>
>>>
>>>
>>> On Mon, Nov 28, 2011 at 6:09 PM, Matt Benson wrote:
On Fri, Nov 11, 2011 at 12:50 PM, Emmanuel Bourg wrote:
[SNIP]
>
> The other idea relates to the bean mapping feature. CSVFormat could be
> generified and work on annotated classes. I imagine something like this:
>
>public class Person {
>@CSVField(trim = true)
>private String firstname;
>
>@CSVField(header="NAME", width=12)
>private String lastname;
>
>@CSVField(header="DATE", format="-MM-dd")
>private Date birthdate;
>}
>
> then:
>
>CSVFormat format = new CSVFormat().withType(Person.class);
>
>for (Person person : format.parse(in)) {
>
>}
>
>
> What do you think?
These make me think of the annotation support Simo added to
[digester]. I wonder if there would be any value in extending
[digester]'s scope to formats beyond XML including CSV/flat files/etc.
Matt
>
>
> Emmanuel Bourg
>
>
>
>
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
>>>
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>>> For additional commands, e-mail: dev-h...@commons.apache.org
>>>
>>
>>
>> -
>> 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: [math] Inconsistencies (bugs) in PascalDistribution?
2011/11/28 Phil Steitz :
> On 11/28/11 12:18 AM, Sébastien Brisard wrote:
>> Hello,
>> while working on MATH-711, I think I stumbled upon some
>> inconsistencies in the implementation of the Pascal distribution. In
>> fact, these might well be a bug, but since I'm a bit rusty on
>> probabilities, I would be grateful for some feedback.
>> Here is the thing. The header of the Javadoc states that the random
>> variable (say X) being represented by this class is the number of
>> *failures*. First of all, I'm not questioning this convention, but I
>> think the current Javadoc is slightly confusing, because it refers to
>> the Wikipedia website, where the opposite convention is adopted (X is
>> the number of *successes*). This would not matter too much, but the
>> Javadoc would require some alterations -- I think.
>> More disturbing: the names of the parameters of the distribution are
>> not consistent with the wikipedia page being referred to:
>> - p is the probability of success in both cases: OK,
>> - r is the number of failures in Wikipedia, but the number of
>> successes in CM... I would suggest that we at least rename this
>> parameter s or something. Except if it is generally accepted by the
>> "Pascal community" that the first parameter should always be called r,
>> no matter the convention. In which case I would recommend that the
>> references to Wikipedia be removed.
>>
>> Finally, the bug. According to my hand-calcs, I think that with the
>> notations of CM, the mean of X is given by
>> mean(X) = r * (1 - p) / p,
>> while the currently implemented formula is
>> r * p / (1 - p),
>> which is actually the formula corresponding to the Wikipedia convention.
>>
>> Here is a very naive piece of code supporting my calcs
>> {code}
>> public class PascalDistributionDemo {
>> public static void main(String[] args) {
>> final int r = 10;
>> final double p = 0.2;
>> final int numTerms = 1000;
>> final PascalDistribution distribution = new PascalDistribution(r, p);
>> double mean = 0.;
>> for (int k = numTerms - 1; k >= 0; k--) {
>> mean += k * distribution.probability(k);
>> }
>> // The following prints 40.12
>> System.out.println("Estimate of the mean = " + mean);
>> // The following prints 2.5
>> System.out.println("CM implementation = " +
>> distribution.getNumericalMean());
>> // The following prints 2.5
>> System.out.println("r * p / (1 - p) = " + (r * p / (1 - p)));
>> // The following prints 40.0
>> System.out.println("r * (1 - p) / p = " + (r * (1 - p) / p));
>> }
>> }
>> {code}
>>
>> Again, I'm not an expert in this area, so I might be very, very wrong,
>> and I apologize beforehand if that's the case. If I'm right, though, I
>> think that
>> 1. the Javadoc needs to be seriously rewritten, and the convention
>> adopted *must* be stated very clearly,
>> 2. the implementation needs thorough verification.
>
> I looked a little more carefully at this. I think the mean formula
> is incorrect, so this is a bug. Regarding the convention used, it
> is clearly stated in the class javadoc, but you are right it should
> be made more clear exactly what is being computed. I am -0 for
> changing the implementation, because that would force current users
> to switch success/failure. It would be best, I think to add full
> formulas to the javadoc. I don't think it is necessary to use the
> same letters as the references do.
>
> Phil
>>
>> I'm happy to do that and open a ticket on this issue once you give me the
>> go...
>>
>> Best,
>> Sébastien
>>
>>
Thanks for discovering this! I did the implementation, and apparently
assumed notation as the referred source. Sorry for this.
We should also check the variance - this might be suffering from wrong
notation as well.
Cheers, Mikkel.
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Re: [csv] API design
On Mon, Nov 28, 2011 at 3:28 PM, Simone Tripodi
wrote:
> What do you mean by collections? A single collection of CSV annotated
> elements, or inner collection of a CSV annotated element?
> I have doubts on option #2, I would expect that any CSV record is
> mapped to a single Java POJO... or not?
I would be in favor of handling collections, etc., mapped to/from the
top-level POJO. How to execute this might be a little tricky,
however. However you present the embedded collection in a markup-free
language, you'd presumably need some piece of data to indicate the
collection's boundaries, at least for input. This type of issue is an
outstanding problem in [flatfile], FWIW.
Matt
> Simo
>
> http://people.apache.org/~simonetripodi/
> http://simonetripodi.livejournal.com/
> http://twitter.com/simonetripodi
> http://www.99soft.org/
>
>
>
> On Mon, Nov 28, 2011 at 9:33 PM, Erhan Bagdemir
> wrote:
>> Apache JCA
>> Java CSV API :-)
>> It is a very cool approach to use annotations for mapping CSV fields with
>> beans.
>>
>> It can be even configured using a class annotation like this:
>> @CSVEntity(seperator= COMMA, quotas=true|false,... )
>> public class Person {
>> @CSVField(header="NAME", width=15)
>> }
>>
>> But how will the Collections be handled ?
>>
>>
>> Am 28.11.2011 um 21:14 schrieb Simone Tripodi:
>>
>>> Hi all,
>>> I like the idea of having annotations, and here in CVS you are
>>> proposing IMHO a very good approach. If you need some support, as
>>> mentioned by Matt, I already deeply explored Annotations analysis at
>>> runtime, have a look at[1]
>>>
>>> @Matt: you reminded me an old idea I had about opening the digester to
>>> other formats, not just XML... coming soon with a new proposal :)
>>>
>>> Have a nice day,
>>> Simo
>>>
>>> [1] http://commons.apache.org/digester/guide/annotations.html
>>>
>>> http://people.apache.org/~simonetripodi/
>>> http://simonetripodi.livejournal.com/
>>> http://twitter.com/simonetripodi
>>> http://www.99soft.org/
>>>
>>>
>>>
>>> On Mon, Nov 28, 2011 at 6:09 PM, Matt Benson wrote:
On Fri, Nov 11, 2011 at 12:50 PM, Emmanuel Bourg wrote:
[SNIP]
>
> The other idea relates to the bean mapping feature. CSVFormat could be
> generified and work on annotated classes. I imagine something like this:
>
> public class Person {
> @CSVField(trim = true)
> private String firstname;
>
> @CSVField(header="NAME", width=12)
> private String lastname;
>
> @CSVField(header="DATE", format="-MM-dd")
> private Date birthdate;
> }
>
> then:
>
> CSVFormat format = new CSVFormat().withType(Person.class);
>
> for (Person person : format.parse(in)) {
>
> }
>
>
> What do you think?
These make me think of the annotation support Simo added to
[digester]. I wonder if there would be any value in extending
[digester]'s scope to formats beyond XML including CSV/flat files/etc.
Matt
>
>
> Emmanuel Bourg
>
>
>
>
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
>>>
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>>> For additional commands, e-mail: dev-h...@commons.apache.org
>>>
>>
>>
>> -
>> 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: [csv] API design
What do you mean by collections? A single collection of CSV annotated
elements, or inner collection of a CSV annotated element?
I have doubts on option #2, I would expect that any CSV record is
mapped to a single Java POJO... or not?
Simo
http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/
On Mon, Nov 28, 2011 at 9:33 PM, Erhan Bagdemir
wrote:
> Apache JCA
> Java CSV API :-)
> It is a very cool approach to use annotations for mapping CSV fields with
> beans.
>
> It can be even configured using a class annotation like this:
> @CSVEntity(seperator= COMMA, quotas=true|false,... )
> public class Person {
> @CSVField(header="NAME", width=15)
> }
>
> But how will the Collections be handled ?
>
>
> Am 28.11.2011 um 21:14 schrieb Simone Tripodi:
>
>> Hi all,
>> I like the idea of having annotations, and here in CVS you are
>> proposing IMHO a very good approach. If you need some support, as
>> mentioned by Matt, I already deeply explored Annotations analysis at
>> runtime, have a look at[1]
>>
>> @Matt: you reminded me an old idea I had about opening the digester to
>> other formats, not just XML... coming soon with a new proposal :)
>>
>> Have a nice day,
>> Simo
>>
>> [1] http://commons.apache.org/digester/guide/annotations.html
>>
>> http://people.apache.org/~simonetripodi/
>> http://simonetripodi.livejournal.com/
>> http://twitter.com/simonetripodi
>> http://www.99soft.org/
>>
>>
>>
>> On Mon, Nov 28, 2011 at 6:09 PM, Matt Benson wrote:
>>> On Fri, Nov 11, 2011 at 12:50 PM, Emmanuel Bourg wrote:
>>> [SNIP]
The other idea relates to the bean mapping feature. CSVFormat could be
generified and work on annotated classes. I imagine something like this:
public class Person {
@CSVField(trim = true)
private String firstname;
@CSVField(header="NAME", width=12)
private String lastname;
@CSVField(header="DATE", format="-MM-dd")
private Date birthdate;
}
then:
CSVFormat format = new CSVFormat().withType(Person.class);
for (Person person : format.parse(in)) {
}
What do you think?
>>>
>>> These make me think of the annotation support Simo added to
>>> [digester]. I wonder if there would be any value in extending
>>> [digester]'s scope to formats beyond XML including CSV/flat files/etc.
>>>
>>> Matt
>>>
Emmanuel Bourg
>>>
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>>> For additional commands, e-mail: dev-h...@commons.apache.org
>>>
>>>
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> For additional commands, e-mail: dev-h...@commons.apache.org
>>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Re: [csv] API design
Apache JCA
Java CSV API :-)
It is a very cool approach to use annotations for mapping CSV fields with
beans.
It can be even configured using a class annotation like this:
@CSVEntity(seperator= COMMA, quotas=true|false,... )
public class Person {
@CSVField(header="NAME", width=15)
}
But how will the Collections be handled ?
Am 28.11.2011 um 21:14 schrieb Simone Tripodi:
> Hi all,
> I like the idea of having annotations, and here in CVS you are
> proposing IMHO a very good approach. If you need some support, as
> mentioned by Matt, I already deeply explored Annotations analysis at
> runtime, have a look at[1]
>
> @Matt: you reminded me an old idea I had about opening the digester to
> other formats, not just XML... coming soon with a new proposal :)
>
> Have a nice day,
> Simo
>
> [1] http://commons.apache.org/digester/guide/annotations.html
>
> http://people.apache.org/~simonetripodi/
> http://simonetripodi.livejournal.com/
> http://twitter.com/simonetripodi
> http://www.99soft.org/
>
>
>
> On Mon, Nov 28, 2011 at 6:09 PM, Matt Benson wrote:
>> On Fri, Nov 11, 2011 at 12:50 PM, Emmanuel Bourg wrote:
>> [SNIP]
>>>
>>> The other idea relates to the bean mapping feature. CSVFormat could be
>>> generified and work on annotated classes. I imagine something like this:
>>>
>>>public class Person {
>>>@CSVField(trim = true)
>>>private String firstname;
>>>
>>>@CSVField(header="NAME", width=12)
>>>private String lastname;
>>>
>>>@CSVField(header="DATE", format="-MM-dd")
>>>private Date birthdate;
>>>}
>>>
>>> then:
>>>
>>>CSVFormat format = new CSVFormat().withType(Person.class);
>>>
>>>for (Person person : format.parse(in)) {
>>>
>>>}
>>>
>>>
>>> What do you think?
>>
>> These make me think of the annotation support Simo added to
>> [digester]. I wonder if there would be any value in extending
>> [digester]'s scope to formats beyond XML including CSV/flat files/etc.
>>
>> Matt
>>
>>>
>>>
>>> Emmanuel Bourg
>>>
>>>
>>>
>>>
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> For additional commands, e-mail: dev-h...@commons.apache.org
>>
>>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Re: [csv] API design
Hi all,
I like the idea of having annotations, and here in CVS you are
proposing IMHO a very good approach. If you need some support, as
mentioned by Matt, I already deeply explored Annotations analysis at
runtime, have a look at[1]
@Matt: you reminded me an old idea I had about opening the digester to
other formats, not just XML... coming soon with a new proposal :)
Have a nice day,
Simo
[1] http://commons.apache.org/digester/guide/annotations.html
http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/
On Mon, Nov 28, 2011 at 6:09 PM, Matt Benson wrote:
> On Fri, Nov 11, 2011 at 12:50 PM, Emmanuel Bourg wrote:
> [SNIP]
>>
>> The other idea relates to the bean mapping feature. CSVFormat could be
>> generified and work on annotated classes. I imagine something like this:
>>
>> public class Person {
>> @CSVField(trim = true)
>> private String firstname;
>>
>> @CSVField(header="NAME", width=12)
>> private String lastname;
>>
>> @CSVField(header="DATE", format="-MM-dd")
>> private Date birthdate;
>> }
>>
>> then:
>>
>> CSVFormat format = new CSVFormat().withType(Person.class);
>>
>> for (Person person : format.parse(in)) {
>>
>> }
>>
>>
>> What do you think?
>
> These make me think of the annotation support Simo added to
> [digester]. I wonder if there would be any value in extending
> [digester]'s scope to formats beyond XML including CSV/flat files/etc.
>
> Matt
>
>>
>>
>> Emmanuel Bourg
>>
>>
>>
>>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Re: [math] Inconsistencies (bugs) in PascalDistribution?
On 11/28/11 12:18 AM, Sébastien Brisard wrote:
> Hello,
> while working on MATH-711, I think I stumbled upon some
> inconsistencies in the implementation of the Pascal distribution. In
> fact, these might well be a bug, but since I'm a bit rusty on
> probabilities, I would be grateful for some feedback.
> Here is the thing. The header of the Javadoc states that the random
> variable (say X) being represented by this class is the number of
> *failures*. First of all, I'm not questioning this convention, but I
> think the current Javadoc is slightly confusing, because it refers to
> the Wikipedia website, where the opposite convention is adopted (X is
> the number of *successes*). This would not matter too much, but the
> Javadoc would require some alterations -- I think.
> More disturbing: the names of the parameters of the distribution are
> not consistent with the wikipedia page being referred to:
> - p is the probability of success in both cases: OK,
> - r is the number of failures in Wikipedia, but the number of
> successes in CM... I would suggest that we at least rename this
> parameter s or something. Except if it is generally accepted by the
> "Pascal community" that the first parameter should always be called r,
> no matter the convention. In which case I would recommend that the
> references to Wikipedia be removed.
>
> Finally, the bug. According to my hand-calcs, I think that with the
> notations of CM, the mean of X is given by
> mean(X) = r * (1 - p) / p,
> while the currently implemented formula is
> r * p / (1 - p),
> which is actually the formula corresponding to the Wikipedia convention.
>
> Here is a very naive piece of code supporting my calcs
> {code}
> public class PascalDistributionDemo {
> public static void main(String[] args) {
> final int r = 10;
> final double p = 0.2;
> final int numTerms = 1000;
> final PascalDistribution distribution = new PascalDistribution(r, p);
> double mean = 0.;
> for (int k = numTerms - 1; k >= 0; k--) {
> mean += k * distribution.probability(k);
> }
> // The following prints 40.12
> System.out.println("Estimate of the mean = " + mean);
> // The following prints 2.5
> System.out.println("CM implementation = " +
>distribution.getNumericalMean());
> // The following prints 2.5
> System.out.println("r * p / (1 - p) = " + (r * p / (1 - p)));
> // The following prints 40.0
> System.out.println("r * (1 - p) / p = " + (r * (1 - p) / p));
> }
> }
> {code}
>
> Again, I'm not an expert in this area, so I might be very, very wrong,
> and I apologize beforehand if that's the case. If I'm right, though, I
> think that
> 1. the Javadoc needs to be seriously rewritten, and the convention
> adopted *must* be stated very clearly,
> 2. the implementation needs thorough verification.
I looked a little more carefully at this. I think the mean formula
is incorrect, so this is a bug. Regarding the convention used, it
is clearly stated in the class javadoc, but you are right it should
be made more clear exactly what is being computed. I am -0 for
changing the implementation, because that would force current users
to switch success/failure. It would be best, I think to add full
formulas to the javadoc. I don't think it is necessary to use the
same letters as the references do.
Phil
>
> I'm happy to do that and open a ticket on this issue once you give me the
> go...
>
> Best,
> Sébastien
>
>
> -
> 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: [digester] help on fixing DIGESTER-153
Hi Matt! :)
thanks a lot in advance for your help, you cannot imagine how many
tries I already gave - and how many different bytecode FW I tested -
without success! You would be my hero of 2011! :)
ALL THE BEST!
Simo
http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/
On Mon, Nov 28, 2011 at 3:48 AM, Matt Benson wrote:
> Sorry, I missed this. I've done something like this before. Ping me
> in a few days. :)
>
> Matt
>
> On Mon, Nov 14, 2011 at 5:58 AM, Simone Tripodi
> wrote:
>> Hi James!
>> many thanks in advance!!! All the best,
>> Simo
>>
>> http://people.apache.org/~simonetripodi/
>> http://simonetripodi.livejournal.com/
>> http://twitter.com/simonetripodi
>> http://www.99soft.org/
>>
>>
>>
>> On Mon, Nov 14, 2011 at 12:51 PM, James Carman
>> wrote:
>>> Sounds easy enough, but it might involve rethinking the guts of digester a
>>> bit. Let me "digest" on that a bit, but I think we can do it somewhat
>>> easily.
>>>
>>> Sent from tablet device. Please excuse typos and brevity.
>>> On Nov 14, 2011 3:02 AM, "Simone Tripodi" wrote:
>>>
Hi all guys,
I'm writing to ask you all a big help on fixing that issues that is
spoling my sweet dreams and completely blocking for the rest :)
The well known issue is that the Digester has been able to create
objects using only the default empty constructor, that is because
instances are created when the XML elements begin.
Thanks to Matt Benson's effort, using CGLIB it is possible to create
instances using arbitrary constructors, extracting arguments from the
same matching XML element attributes.
I am sure we can do even more, extracting constructor arguments from
nested elements, I mean, given the following POJO:
class MyBean
{
// (g|s)etter omitted
private float floatProperty;
public MyBean( double doubleProperty, boolean booleanProperty )
...
}
and the following XML snippet
true
5.5
I would like - but don't know how, that's here that I need help - via
CGLIB (or something similar) implementing a Lazy Initialization policy
that allows us creating a proxy that tracks the Object methods
invocations, but the constructor and methods will be invoked only when
the matchin XML element terminates.
Just to be more clear:
true
5.5
Do you think that would be possible?
Many thanks in advance, all the best!
Simo
http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
>>>
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> For additional commands, e-mail: dev-h...@commons.apache.org
>>
>>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Re: [csv] API design
On Fri, Nov 11, 2011 at 12:50 PM, Emmanuel Bourg wrote:
[SNIP]
>
> The other idea relates to the bean mapping feature. CSVFormat could be
> generified and work on annotated classes. I imagine something like this:
>
> public class Person {
> @CSVField(trim = true)
> private String firstname;
>
> @CSVField(header="NAME", width=12)
> private String lastname;
>
> @CSVField(header="DATE", format="-MM-dd")
> private Date birthdate;
> }
>
> then:
>
> CSVFormat format = new CSVFormat().withType(Person.class);
>
> for (Person person : format.parse(in)) {
>
> }
>
>
> What do you think?
These make me think of the annotation support Simo added to
[digester]. I wonder if there would be any value in extending
[digester]'s scope to formats beyond XML including CSV/flat files/etc.
Matt
>
>
> Emmanuel Bourg
>
>
>
>
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Re: [JEXL] binary compatibility
On 28 November 2011 15:55, henrib wrote: > I added @since 2.1, renamed the Uberspect.getConstructor, removed final for > silent & strict in Interpreter (although Interpreter instances probably > never need to change those at runtime) but there are still 21 clirr errors > that I'm afraid many will consider as show-stoppers for release. Not if they can be shown to be unused by end-users. > I'm pretty sure that no active JEXL user would really be bothered by the 2.1 > API modifications - and even less so by the binary incompatibility - but I > don't see how the case can be made... JMeter uses Jexl2 - don't have time to try it now, but I will try tomorrow and see if it is affected by the API breaks. > Any hint/advice/idea ? There are still a few errors that could be fixed. e.g. the visit() changes - would it work to re-introduce dummy deprecated classes ASTFloatLiteral and ASTIntegerLiteral? Or define them in terms of the new classes? JexlArithmetic.strict can be made non-final Likewise the method changes in UnifiedJEXL$Expression could be reverted (and pending changes flagged). I think it's now quite close, apart from the Script interface, which may be allowed. > I've got a migrated-to jexl3 code base ready just in case jexl2 is a > dead-end. > > Cheers, > Henrib > > > > > -- > View this message in context: > http://apache-commons.680414.n4.nabble.com/JEXL-binary-compatibility-tp4114818p4115683.html > Sent from the Commons - Dev mailing list archive at Nabble.com. > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [JEXL] binary compatibility
I added @since 2.1, renamed the Uberspect.getConstructor, removed final for silent & strict in Interpreter (although Interpreter instances probably never need to change those at runtime) but there are still 21 clirr errors that I'm afraid many will consider as show-stoppers for release. I'm pretty sure that no active JEXL user would really be bothered by the 2.1 API modifications - and even less so by the binary incompatibility - but I don't see how the case can be made... Any hint/advice/idea ? I've got a migrated-to jexl3 code base ready just in case jexl2 is a dead-end. Cheers, Henrib -- View this message in context: http://apache-commons.680414.n4.nabble.com/JEXL-binary-compatibility-tp4114818p4115683.html Sent from the Commons - Dev mailing list archive at Nabble.com. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [JEXL] binary compatibility
On 28 November 2011 14:35, henrib wrote: > @since, will do. > > On the Script interface, I suspect anyone implementing it derives > ExpressionImpl which does carry default implementations... That then might be an acceptable break in compatibility. > On the new Script methods (getVariables etc), I'd like to keep the API > simple and avoid multiplying interfaces (esp for 2/3 methods at a time). > > Thanks for the review The additional final qualifiers could easily be removed and the set methods deprecated. > Henrib > > -- > View this message in context: > http://apache-commons.680414.n4.nabble.com/JEXL-binary-compatibility-tp4114818p4115380.html > Sent from the Commons - Dev mailing list archive at Nabble.com. > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VOTE] Release JEXL 2.1 based on RC1
On 28 November 2011 14:30, sebb wrote: > On 28 November 2011 14:19, henrib wrote: >> Thanks for tidying up my mess. >> >> About org.apache.commons.jexl2.UnifiedJEXL$Expression, its subclasses are >> private because only that base class is supposed to be usable by end-users; >> one declares 'UnifiedJEXL.Expression expr' and the engine manages the rest. > > That's a pity. > >> org.apache.commons.jexl2.internal is definitely internal (sic :-)). > > OK, I'll exclude it. Done. >> org.apache.commons.jexl2.introspection is intended to be used as a base to >> customization so should be considered public (albeit most likely never used >> by anyone); Uberspect.getConstructor was not carrying the proper signature >> in 2.0.x. Would it be possible to add a new method to the Impl that has the correct sig and deprecate the old one? e.g. getConstructorMethod ? If the interface is unlikely to be directly used externally, then it might be OK to allow that as an API break. >> >> The amount of work to try to make the release binary compatible seems >> unfortunately much greater than switching to a new package name... > > Are you sure? > > I thought so originally with NET which needed quite a major refactor, > but found that I could add new methods and deprecate old ones. > > I'm happy to do some of the work, but as indicated I'm not entirely > sure what is intended to be external. > >> Thanks again for your help, >> Henrib >> >> >> -- >> View this message in context: >> http://apache-commons.680414.n4.nabble.com/VOTE-Release-JEXL-2-1-based-on-RC1-tp4113403p4115331.html >> Sent from the Commons - Dev mailing list archive at Nabble.com. >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org >> >> > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [JEXL] binary compatibility
@since, will do. On the Script interface, I suspect anyone implementing it derives ExpressionImpl which does carry default implementations... On the new Script methods (getVariables etc), I'd like to keep the API simple and avoid multiplying interfaces (esp for 2/3 methods at a time). Thanks for the review Henrib -- View this message in context: http://apache-commons.680414.n4.nabble.com/JEXL-binary-compatibility-tp4114818p4115380.html Sent from the Commons - Dev mailing list archive at Nabble.com. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [CANCELLED][VOTE] Release JEXL 2.1 based on RC1
On 28 November 2011 13:51, henrib wrote: > One might argue that JEXL does not have that many users so jar hell is very > (very) unlikely - no Apache project depends on jexl2 afaik - and that > forcing "up to date/snapshot" users to switch to a new package when they're > already used to recompile against the latest JEXL version is adding burden > on their side (i.e. replace all o.a.c.jexl2 imports with o.a.c.jexl3, update > maven dependencies, etc.) with no practical benefit. Yes, JEXL is more of an edge case than say NET or Lang or Logging. > However, following the commons best practice being the wisest route to > release, I'll re-attempt an RC after migration to o.a.c.jexl3. > > Regards, > Henrib > > -- > View this message in context: > http://apache-commons.680414.n4.nabble.com/CANCELLED-VOTE-Release-JEXL-2-1-based-on-RC1-tp4114443p4115226.html > Sent from the Commons - Dev mailing list archive at Nabble.com. > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VOTE] Release JEXL 2.1 based on RC1
On 28 November 2011 14:19, henrib wrote: > Thanks for tidying up my mess. > > About org.apache.commons.jexl2.UnifiedJEXL$Expression, its subclasses are > private because only that base class is supposed to be usable by end-users; > one declares 'UnifiedJEXL.Expression expr' and the engine manages the rest. That's a pity. > org.apache.commons.jexl2.internal is definitely internal (sic :-)). OK, I'll exclude it. > org.apache.commons.jexl2.introspection is intended to be used as a base to > customization so should be considered public (albeit most likely never used > by anyone); Uberspect.getConstructor was not carrying the proper signature > in 2.0.x. > > The amount of work to try to make the release binary compatible seems > unfortunately much greater than switching to a new package name... Are you sure? I thought so originally with NET which needed quite a major refactor, but found that I could add new methods and deprecate old ones. I'm happy to do some of the work, but as indicated I'm not entirely sure what is intended to be external. > Thanks again for your help, > Henrib > > > -- > View this message in context: > http://apache-commons.680414.n4.nabble.com/VOTE-Release-JEXL-2-1-based-on-RC1-tp4113403p4115331.html > Sent from the Commons - Dev mailing list archive at Nabble.com. > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [math] KolmogorovSmirnovDistribution not part of the distribution hierarchy
IIRC this was implemented in support of one of the non-parametric tests new in
3.0. I will have a look later. We should probably either finish the impl or
move it and give it package scope.
Phil
On Nov 28, 2011, at 12:22 AM, Sébastien Brisard
wrote:
> Hi,
> while working on MATH-711, I noticed that the above-mentioned
> distribution does not implement any of the interfaces provided. Is
> there a reason for us providing only the cdf? If yes, shouldn't this
> method be renamed {{cumulativeProbability}}, in order to be consistent
> with other implementations in the same package?
>
> Best regards,
> Sébastien
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VOTE] Release JEXL 2.1 based on RC1
Thanks for tidying up my mess. About org.apache.commons.jexl2.UnifiedJEXL$Expression, its subclasses are private because only that base class is supposed to be usable by end-users; one declares 'UnifiedJEXL.Expression expr' and the engine manages the rest. org.apache.commons.jexl2.internal is definitely internal (sic :-)). org.apache.commons.jexl2.introspection is intended to be used as a base to customization so should be considered public (albeit most likely never used by anyone); Uberspect.getConstructor was not carrying the proper signature in 2.0.x. The amount of work to try to make the release binary compatible seems unfortunately much greater than switching to a new package name... Thanks again for your help, Henrib -- View this message in context: http://apache-commons.680414.n4.nabble.com/VOTE-Release-JEXL-2-1-based-on-RC1-tp4113403p4115331.html Sent from the Commons - Dev mailing list archive at Nabble.com. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [math] Inconsistencies (bugs) in PascalDistribution?
On 11/28/11 12:18 AM, Sébastien Brisard wrote:
> Hello,
> while working on MATH-711, I think I stumbled upon some
> inconsistencies in the implementation of the Pascal distribution. In
> fact, these might well be a bug, but since I'm a bit rusty on
> probabilities, I would be grateful for some feedback.
> Here is the thing. The header of the Javadoc states that the random
> variable (say X) being represented by this class is the number of
> *failures*. First of all, I'm not questioning this convention, but I
> think the current Javadoc is slightly confusing, because it refers to
> the Wikipedia website, where the opposite convention is adopted (X is
> the number of *successes*). This would not matter too much, but the
> Javadoc would require some alterations -- I think.
> More disturbing: the names of the parameters of the distribution are
> not consistent with the wikipedia page being referred to:
> - p is the probability of success in both cases: OK,
> - r is the number of failures in Wikipedia, but the number of
> successes in CM... I would suggest that we at least rename this
> parameter s or something. Except if it is generally accepted by the
> "Pascal community" that the first parameter should always be called r,
> no matter the convention. In which case I would recommend that the
> references to Wikipedia be removed.
>
> Finally, the bug. According to my hand-calcs, I think that with the
> notations of CM, the mean of X is given by
> mean(X) = r * (1 - p) / p,
> while the currently implemented formula is
> r * p / (1 - p),
> which is actually the formula corresponding to the Wikipedia convention.
>
> Here is a very naive piece of code supporting my calcs
> {code}
> public class PascalDistributionDemo {
> public static void main(String[] args) {
> final int r = 10;
> final double p = 0.2;
> final int numTerms = 1000;
> final PascalDistribution distribution = new PascalDistribution(r, p);
> double mean = 0.;
> for (int k = numTerms - 1; k >= 0; k--) {
> mean += k * distribution.probability(k);
> }
> // The following prints 40.12
> System.out.println("Estimate of the mean = " + mean);
> // The following prints 2.5
> System.out.println("CM implementation = " +
>distribution.getNumericalMean());
> // The following prints 2.5
> System.out.println("r * p / (1 - p) = " + (r * p / (1 - p)));
> // The following prints 40.0
> System.out.println("r * (1 - p) / p = " + (r * (1 - p) / p));
> }
> }
> {code}
>
> Again, I'm not an expert in this area, so I might be very, very wrong,
> and I apologize beforehand if that's the case. If I'm right, though, I
> think that
> 1. the Javadoc needs to be seriously rewritten, and the convention
> adopted *must* be stated very clearly,
> 2. the implementation needs thorough verification.
>
> I'm happy to do that and open a ticket on this issue once you give me the
> go...
Go ahead an open a ticket.
Phil
>
> Best,
> Sébastien
>
>
> -
> 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: [CANCELLED][VOTE] Release JEXL 2.1 based on RC1
One might argue that JEXL does not have that many users so jar hell is very (very) unlikely - no Apache project depends on jexl2 afaik - and that forcing "up to date/snapshot" users to switch to a new package when they're already used to recompile against the latest JEXL version is adding burden on their side (i.e. replace all o.a.c.jexl2 imports with o.a.c.jexl3, update maven dependencies, etc.) with no practical benefit. However, following the commons best practice being the wisest route to release, I'll re-attempt an RC after migration to o.a.c.jexl3. Regards, Henrib -- View this message in context: http://apache-commons.680414.n4.nabble.com/CANCELLED-VOTE-Release-JEXL-2-1-based-on-RC1-tp4114443p4115226.html Sent from the Commons - Dev mailing list archive at Nabble.com. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
[GUMP@vmgump]: Project commons-exec-test (in module apache-commons) failed
To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at gene...@gump.apache.org. Project commons-exec-test has an issue affecting its community integration. This issue affects 1 projects. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - commons-exec-test : Apache Commons Full details are available at: http://vmgump.apache.org/gump/public/apache-commons/commons-exec-test/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -WARNING- Overriding Maven settings: [/srv/gump/public/workspace/apache-commons/exec/gump_mvn_settings.xml] -DEBUG- (Apache Gump generated) Apache Maven Settings in: /srv/gump/public/workspace/apache-commons/exec/gump_mvn_settings.xml -INFO- Failed with reason build failed -DEBUG- Maven POM in: /srv/gump/public/workspace/apache-commons/exec/pom.xml -INFO- Project Reports in: /srv/gump/public/workspace/apache-commons/exec/target/surefire-reports The following work was performed: http://vmgump.apache.org/gump/public/apache-commons/commons-exec-test/gump_work/build_apache-commons_commons-exec-test.html Work Name: build_apache-commons_commons-exec-test (Type: Build) Work ended in a state of : Failed Elapsed: 1 min 27 secs Command Line: /opt/maven2/bin/mvn --batch-mode --settings /srv/gump/public/workspace/apache-commons/exec/gump_mvn_settings.xml test [Working Directory: /srv/gump/public/workspace/apache-commons/exec] M2_HOME: /opt/maven2 - FOO.. gdal_translate HDF5:"/home/kk/grass/data/4404.he5"://HDFEOS/GRIDS/OMI_Column_Amount_O3/Data_Fields/ColumnAmountO3/home/kk/4.tif FOO.. PING 127.0.0.1 (127.0.0.1) 56(84) bytes of data. 64 bytes from 127.0.0.1: icmp_seq=1 ttl=64 time=0.021 ms 64 bytes from 127.0.0.1: icmp_seq=2 ttl=64 time=0.025 ms 64 bytes from 127.0.0.1: icmp_seq=3 ttl=64 time=0.024 ms Process completed in 2004 millis; below is its output Process timed out and was killed by watchdog. org.apache.commons.exec.ExecuteException: Process exited with an error: 143 (Exit value: 143) Process completed in 2004 millis; below is its output Process timed out and was killed. Preparing to execute process - commandLine=[/bin/ls, /opt] Process spun off successfully - process=/bin/ls Preparing to execute process - commandLine=[/bin/ls, /opt] Process spun off successfully - process=/bin/ls Executing [sh, -c, src/test/scripts/invoker.sh] invoker.sh -- going to start daemon process invoker.sh -- daemon process was started cd: 21: can't cd to ../../../target Process completed in 8015 millis; above is its output 0: process has terminated: false 1: process has terminated: false 2: process has terminated: false 3: process has terminated: false 4: process has terminated: false 5: process has terminated: false Tests run: 40, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 74.795 sec <<< FAILURE! Results : Failed tests: testExec_60(org.apache.commons.exec.DefaultExecutorTest) Tests run: 95, Failures: 1, Errors: 0, Skipped: 0 [INFO] [ERROR] BUILD FAILURE [INFO] [INFO] There are test failures. Please refer to /srv/gump/public/workspace/apache-commons/exec/target/surefire-reports for the individual test results. [INFO] [INFO] For more information, run Maven with the -e switch [INFO] [INFO] Total time: 1 minute 25 seconds [INFO] Finished at: Mon Nov 28 13:48:33 UTC 2011 [INFO] Final Memory: 25M/65M [INFO] - To subscribe to this information via syndicated feeds: - RSS: http://vmgump.apache.org/gump/public/apache-commons/commons-exec-test/rss.xml - Atom: http://vmgump.apache.org/gump/public/apache-commons/commons-exec-test/atom.xml == Gump Tracking Only === Produced by Apache Gump(TM) version 2.3. Gump Run 06001228112011, vmgump.apache.org:vmgump:06001228112011 Gump E-mail Identifier (unique within run) #1. -- Apache Gump http://gump.apache.org/ [Instance: vmgump] - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [discuss] adopt a new skin for commons sites
reports selection is already supported, have a look at[1] HTH, Simo [1] http://maven.apache.org/plugins/maven-project-info-reports-plugin/examples/selective-project-info-reports.html http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ On Mon, Nov 28, 2011 at 1:38 PM, sebb wrote: > On 28 November 2011 12:10, Gary Gregory wrote: >> On Nov 28, 2011, at 1:13, Emmanuel Bourg wrote: >> >>> I like the skin. Does it also provide syntax highlighting for Java >>> snippets ? >>> >>> I haven't tested the skin on a wide screen, does it expand on the whole >>> width or is there a maximum width? The readability is usually considered >>> better when the lines of text aren't too long. >>> >>> A new skin could be the opportunity to rethink the content of the sites. >>> In particular I find the menus too verbose and messy. The Maven reports >>> are often useless for a public website, for example who cares about the >>> Checkstyle or the Findbugs reports besides the developers? >> >> The reports can give you a feel for the level of attention to detail a >> project has. I say "can" and not "do" because they can be configured >> to ignore a lot. It's too bad the reports don't show how they are >> configured as part of the report. > > Agreed - why not raise enhancement requests for this? > Even send a patch?? > >> Gary >>> >>> Emmanuel Bourg >>> >>> >>> Le 26/11/2011 22:07, Simone Tripodi a écrit : Hi all guys, at Maven we have just released a new skin[1], I quickly did an experiment and applied it on my beloved digester, deploying the site on my personal [2] ASF space. WDYT? Is there any chance to have it applied here at commons? It would involve a little modification to the parent pom[3]. Any feedback would me much more than appreciated, many thanks in advance! Simo [1] http://maven.apache.org/skins/maven-fluido-skin/ [2] http://people.apache.org/~simonetripodi/digester [3] https://gist.github.com/1396291 http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org >>> >>> - >>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>> For additional commands, e-mail: dev-h...@commons.apache.org >>> >> >> - >> 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: [discuss] adopt a new skin for commons sites
On 28 November 2011 12:10, Gary Gregory wrote: > On Nov 28, 2011, at 1:13, Emmanuel Bourg wrote: > >> I like the skin. Does it also provide syntax highlighting for Java >> snippets ? >> >> I haven't tested the skin on a wide screen, does it expand on the whole >> width or is there a maximum width? The readability is usually considered >> better when the lines of text aren't too long. >> >> A new skin could be the opportunity to rethink the content of the sites. >> In particular I find the menus too verbose and messy. The Maven reports >> are often useless for a public website, for example who cares about the >> Checkstyle or the Findbugs reports besides the developers? > > The reports can give you a feel for the level of attention to detail a > project has. I say "can" and not "do" because they can be configured > to ignore a lot. It's too bad the reports don't show how they are > configured as part of the report. Agreed - why not raise enhancement requests for this? Even send a patch?? > Gary >> >> Emmanuel Bourg >> >> >> Le 26/11/2011 22:07, Simone Tripodi a écrit : >>> Hi all guys, >>> at Maven we have just released a new skin[1], I quickly did an >>> experiment and applied it on my beloved digester, deploying the site >>> on my personal [2] ASF space. >>> WDYT? Is there any chance to have it applied here at commons? >>> It would involve a little modification to the parent pom[3]. >>> Any feedback would me much more than appreciated, many thanks in advance! >>> Simo >>> >>> [1] http://maven.apache.org/skins/maven-fluido-skin/ >>> [2] http://people.apache.org/~simonetripodi/digester >>> [3] https://gist.github.com/1396291 >>> >>> http://people.apache.org/~simonetripodi/ >>> http://simonetripodi.livejournal.com/ >>> http://twitter.com/simonetripodi >>> http://www.99soft.org/ >>> >>> - >>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>> For additional commands, e-mail: dev-h...@commons.apache.org >>> >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org >> > > - > 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: [CANCELLED][VOTE] Release JEXL 2.1 based on RC1
On 28 November 2011 12:03, James Carman wrote: > I don't think that is either an apache thing or a rule. It's more of a > commons best practice. It's one we strongly suggest for good reason, > though. Yes, because commons components are generally low-level libraries which can be part of a dependency chain. > Make sure the maven artifactId (and probably groupId too) changes > correspondingly. This will allow older versions to coexist with new ones. Package name changes must be accompanied by Maven id changes and vice-versa to avoid jar-hell This is because Maven relocation does not work with Maven Central. > On Nov 28, 2011 2:52 AM, "Henri Biestro" wrote: > >> Gary and Sebb pointed out that, per apache release rules, incompatible >> binaries require new package name (i.e. jexl3). >> My bad, sorry. >> Henrib >> >> >> - >> 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: [Validator] won't be continued ?
On Sun, 27 Nov 2011, | Erhan Bagdemir wrote: Is there any plan or improvement for Validator project? I was hoping to get another release out during ApacheCon, but alas I didn't get the time. It is on my todo list, but if someone fancied helping by working up a patch to fix the issues raised in the last release vote, that'd speed things up :) I see on Jira that the second version was already planed some time ago and includes JSR303 in which i'm very interested. As Matt has pointed out, if you're interested in JSR303 then you should be using BeanValidator, as that's where the development of the functionality at Apache has occured Nick - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [discuss] adopt a new skin for commons sites
On Nov 28, 2011, at 1:13, Emmanuel Bourg wrote: > I like the skin. Does it also provide syntax highlighting for Java > snippets ? > > I haven't tested the skin on a wide screen, does it expand on the whole > width or is there a maximum width? The readability is usually considered > better when the lines of text aren't too long. > > A new skin could be the opportunity to rethink the content of the sites. > In particular I find the menus too verbose and messy. The Maven reports > are often useless for a public website, for example who cares about the > Checkstyle or the Findbugs reports besides the developers? The reports can give you a feel for the level of attention to detail a project has. I say "can" and not "do" because they can be configured to ignore a lot. It's too bad the reports don't show how they are configured as part of the report. Gary > > Emmanuel Bourg > > > Le 26/11/2011 22:07, Simone Tripodi a écrit : >> Hi all guys, >> at Maven we have just released a new skin[1], I quickly did an >> experiment and applied it on my beloved digester, deploying the site >> on my personal [2] ASF space. >> WDYT? Is there any chance to have it applied here at commons? >> It would involve a little modification to the parent pom[3]. >> Any feedback would me much more than appreciated, many thanks in advance! >> Simo >> >> [1] http://maven.apache.org/skins/maven-fluido-skin/ >> [2] http://people.apache.org/~simonetripodi/digester >> [3] https://gist.github.com/1396291 >> >> http://people.apache.org/~simonetripodi/ >> http://simonetripodi.livejournal.com/ >> http://twitter.com/simonetripodi >> http://www.99soft.org/ >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org >> > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [CANCELLED][VOTE] Release JEXL 2.1 based on RC1
I don't think that is either an apache thing or a rule. It's more of a commons best practice. It's one we strongly suggest for good reason, though. Make sure the maven artifactId (and probably groupId too) changes correspondingly. This will allow older versions to coexist with new ones. On Nov 28, 2011 2:52 AM, "Henri Biestro" wrote: > Gary and Sebb pointed out that, per apache release rules, incompatible > binaries require new package name (i.e. jexl3). > My bad, sorry. > Henrib > > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > >
Re: [configuration] Talk at Paris JUG next month
Hi Emmanuel, thanks for sharing!!! Unfortunately I cannot open .odp ATM, I'll download OO later :) It would be very nice indeed for me to come back to Paris, I worked there for one year and I really miss that city - and friend above all that live there :) Have a nice day! Simo http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ On Mon, Nov 28, 2011 at 11:42 AM, Emmanuel Bourg wrote: > I've uploaded the slides of my talk (in french), feel free to reuse it. It's > a quick overview of the main features of Commons Configuration > > http://people.apache.org/~ebourg/2011-11-08%20ParisJUG%20Commons%20Configuration.odp > > Also worth noting, if you feel like coming and talking at ParisJUG some day, > speakers are offered a beer after the talks ;) > > > Emmanuel Bourg > > > > Le 10/10/2011 11:20, Emmanuel Bourg a écrit : >> >> Hi, >> >> The Paris JUG has kindly invited me to give a short talk on Commons >> Configuration next month. >> >> I'd like to give some real world examples of the usage of Commons >> Configuration. I'd be interested in hearing how people actually use the >> API, what features they find the most useful, and why they couldn't live >> without this component. >> >> Any input is welcome! >> >> >> Emmanuel Bourg >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org >> > > > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
[JEXL] binary compatibility
The interface org.apache.commons.jexl2.Script has been extended with several methods. There's no default abstract implementation so I assume this will cause problems for client code. Would it be make sense to implement the new methods in a sub-interface? Or an independent interface? In particular, the Callable methods seem to be rather different. Even the parameters/variables seem to be different from the original interface. == BTW, just noticed that the new methods etc. don't have @since markers. Should really be added before release. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [configuration] Talk at Paris JUG next month
I've uploaded the slides of my talk (in french), feel free to reuse it. It's a quick overview of the main features of Commons Configuration http://people.apache.org/~ebourg/2011-11-08%20ParisJUG%20Commons%20Configuration.odp Also worth noting, if you feel like coming and talking at ParisJUG some day, speakers are offered a beer after the talks ;) Emmanuel Bourg Le 10/10/2011 11:20, Emmanuel Bourg a écrit : Hi, The Paris JUG has kindly invited me to give a short talk on Commons Configuration next month. I'd like to give some real world examples of the usage of Commons Configuration. I'd be interested in hearing how people actually use the API, what features they find the most useful, and why they couldn't live without this component. Any input is welcome! Emmanuel Bourg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org smime.p7s Description: Signature cryptographique S/MIME
Re: [discuss] adopt a new skin for commons sites
On 28 November 2011 10:23, Emmanuel Bourg wrote: > Le 28/11/2011 10:37, sebb a écrit : > >> +1. >> >> The reports are not displayed by default, so I don't see what the problem >> is. >> Besides, as Luc says, they are useful to some. > > Some reports are displayed by default and completely useless in my opinion, > for example the project plugins and the plugin management pages: > > http://commons.apache.org/configuration/plugins.html > http://commons.apache.org/configuration/plugin-management.html I agree on those. > The "About" link under "Project Information" is also redundant with the > "Home" link. And the Apache License is also linked twice. I agree the information links could/should be tidied. In particular, the License link is incorrect. However, people may expect to find an About link, so I'm not so sure about removing that. The tidyup should be done regardless of any change to the skin. And I assume (hope!) it is independent of any change to the skin. > >> As to Checkstyle - remember that the ASF releases source primarily. >> So if someone wants to work on extending the source, it is a >> potentially important factor. > > I agree the source is important, but not the sporadic misaligned braces in a > random snapshot of the code that was used to publish the site. > > These reports would be meaningful if they were generated automatically as > part of a continuous build system. > > > Emmanuel Bourg > > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [discuss] adopt a new skin for commons sites
Le 28/11/2011 10:37, sebb a écrit : +1. The reports are not displayed by default, so I don't see what the problem is. Besides, as Luc says, they are useful to some. Some reports are displayed by default and completely useless in my opinion, for example the project plugins and the plugin management pages: http://commons.apache.org/configuration/plugins.html http://commons.apache.org/configuration/plugin-management.html The "About" link under "Project Information" is also redundant with the "Home" link. And the Apache License is also linked twice. As to Checkstyle - remember that the ASF releases source primarily. So if someone wants to work on extending the source, it is a potentially important factor. I agree the source is important, but not the sporadic misaligned braces in a random snapshot of the code that was used to publish the site. These reports would be meaningful if they were generated automatically as part of a continuous build system. Emmanuel Bourg smime.p7s Description: Signature cryptographique S/MIME
Re: [VOTE] Release JEXL 2.1 based on RC1
On 28 November 2011 09:40, sebb wrote:
> On 28 November 2011 01:40, sebb wrote:
>> On 28 November 2011 01:03, Gary Gregory wrote:
>>> I see 35 Clirr Errors that point to backwards incompatibility.
>>
>> Many of these relate to the parser, which is not really part of the public
>> API.
>
> Just checked, and the clirr plugin supports an excludes configuration
> element which could be used to ignore these.
I've fixed the pom so it ignores the parser classes (and tidied up a
bit; there were some unnecessary entries).
There are possibly one or two other ignorable classes - e.g. the nested class
org.apache.commons.jexl2.UnifiedJEXL$Expression
All its existing subclasses are private, so I wonder why it is public?
It's OK to break binary compat if the class is not part of the API, so
it's worth checking what is public because it is part of the API and
what is public merely because the code uses multiple package names
(and so needs public rather than package access).
What about the following packages:
org.apache.commons.jexl2.internal
org.apache.commons.jexl2.introspection
I assume the former is not part of the API - what about the latter?
>> However, there are some which do look like they break binary compatibility
>>
>>> So... do we have a Commons-wide policy of changing package names and making
>>> a major release (3.0 vs. 2.1 here) or not?
>>
>> I think Jexl should be binary compatible.
>>
>> If the changes cannot be re-done in a binary compatible way, then I
>> think Jexl needs a major release and package change.
>>
>>> Gary
>>>
>>> On Sun, Nov 27, 2011 at 1:34 PM, Henri Biestro wrote:
>>>
Dear all,
After a pretty long cycle, JEXL 2.1 is ready for review.
Here is a quick list of new features (from the release notes):
What's new in 2.1:
==
* A more thorough arithmetic (JexlArithmetic) that allows fine control
over decimals (scale and precision), a
new syntax for numeric literals (OGNL inspired Big and Huge notations)
and a better type handling keeping the most
appropriate representation in casual operations.
* The introduction of script variables and parameters that reduce context
dependencies and methods; this allows to
perform checks after script creation (light static checking hints). Plus
the ability to call script from scripts.
* A sandoxing feature to restrict and rename what JEXL can access from the
environment allowing tighter control over security.
* Extensions to UnifiedJEXL that allow the creation of templates.
New features in 2.1:
* JEXL-114: Allow scripts to create local variables // Add return
keyword
* JEXL-113: Add functions to extract which variables, parameters and
local variables are used to evaluate a script
* JEXL-118: Provide an IN operator
* JEXL-115: Add support for asynchronous script execution and
cancellation
* JEXL-116: Add control over classes, methods, constructors and
properties allowed in scripts
* JEXL-120: Add simple template features
* JEXL-119: Allow indexed properties container resolution in
expressions
Tested against Java 1.{5,6} / Maven{2,3}, Windows 7/Linux/Mac OS.
Tag:
https://svn.apache.org/repos/asf/commons/proper/jexl/tags/COMMONS_JEXL_2_1_RC1/
Site:
https://people.apache.org/~henrib/jexl-2.1
Binaries:
https://repository.apache.org/content/repositories/orgapachecommons-258/
This vote will close in 72 hours, 08:00PM GMT, Nov 30th.
[ ] +1 Release these artifacts
[ ] +0 OK, but...
[ ] -0 OK, but really should fix...
[ ] -1 I oppose this release because...
Many thanks,
Regards.
Henrib
>>>
>>>
>>> --
>>> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
>>> JUnit in Action, 2nd Ed: http://bit.ly/ECvg0
>>> Spring Batch in Action: http://bit.ly/bqpbCK
>>> Blog: http://garygregory.wordpress.com
>>> Home: http://garygregory.com/
>>> Tweet! http://twitter.com/GaryGregory
>>>
>>
>
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VOTE] Release JEXL 2.1 based on RC1
On 28 November 2011 01:40, sebb wrote:
> On 28 November 2011 01:03, Gary Gregory wrote:
>> I see 35 Clirr Errors that point to backwards incompatibility.
>
> Many of these relate to the parser, which is not really part of the public
> API.
Just checked, and the clirr plugin supports an excludes configuration
element which could be used to ignore these.
> However, there are some which do look like they break binary compatibility
>
>> So... do we have a Commons-wide policy of changing package names and making
>> a major release (3.0 vs. 2.1 here) or not?
>
> I think Jexl should be binary compatible.
>
> If the changes cannot be re-done in a binary compatible way, then I
> think Jexl needs a major release and package change.
>
>> Gary
>>
>> On Sun, Nov 27, 2011 at 1:34 PM, Henri Biestro wrote:
>>
>>>
>>> Dear all,
>>>
>>> After a pretty long cycle, JEXL 2.1 is ready for review.
>>> Here is a quick list of new features (from the release notes):
>>>
>>> What's new in 2.1:
>>> ==
>>> * A more thorough arithmetic (JexlArithmetic) that allows fine control
>>> over decimals (scale and precision), a
>>> new syntax for numeric literals (OGNL inspired Big and Huge notations)
>>> and a better type handling keeping the most
>>> appropriate representation in casual operations.
>>> * The introduction of script variables and parameters that reduce context
>>> dependencies and methods; this allows to
>>> perform checks after script creation (light static checking hints). Plus
>>> the ability to call script from scripts.
>>> * A sandoxing feature to restrict and rename what JEXL can access from the
>>> environment allowing tighter control over security.
>>> * Extensions to UnifiedJEXL that allow the creation of templates.
>>>
>>> New features in 2.1:
>>>
>>> * JEXL-114: Allow scripts to create local variables // Add return
>>> keyword
>>> * JEXL-113: Add functions to extract which variables, parameters and
>>> local variables are used to evaluate a script
>>> * JEXL-118: Provide an IN operator
>>> * JEXL-115: Add support for asynchronous script execution and
>>> cancellation
>>> * JEXL-116: Add control over classes, methods, constructors and
>>> properties allowed in scripts
>>> * JEXL-120: Add simple template features
>>> * JEXL-119: Allow indexed properties container resolution in
>>> expressions
>>>
>>> Tested against Java 1.{5,6} / Maven{2,3}, Windows 7/Linux/Mac OS.
>>>
>>> Tag:
>>>
>>>
>>> https://svn.apache.org/repos/asf/commons/proper/jexl/tags/COMMONS_JEXL_2_1_RC1/
>>>
>>> Site:
>>>
>>> https://people.apache.org/~henrib/jexl-2.1
>>>
>>> Binaries:
>>>
>>> https://repository.apache.org/content/repositories/orgapachecommons-258/
>>>
>>> This vote will close in 72 hours, 08:00PM GMT, Nov 30th.
>>>
>>> [ ] +1 Release these artifacts
>>> [ ] +0 OK, but...
>>> [ ] -0 OK, but really should fix...
>>> [ ] -1 I oppose this release because...
>>>
>>> Many thanks,
>>> Regards.
>>> Henrib
>>>
>>>
>>>
>>
>>
>> --
>> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
>> JUnit in Action, 2nd Ed: http://bit.ly/ECvg0
>> Spring Batch in Action: http://bit.ly/bqpbCK
>> Blog: http://garygregory.wordpress.com
>> Home: http://garygregory.com/
>> Tweet! http://twitter.com/GaryGregory
>>
>
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Re: [discuss] adopt a new skin for commons sites
On 28 November 2011 07:35, Luc Maisonobe wrote: > Hi Emmanuel, > > Le 28/11/2011 07:12, Emmanuel Bourg a écrit : >> I like the skin. Does it also provide syntax highlighting for Java >> snippets ? >> >> I haven't tested the skin on a wide screen, does it expand on the whole >> width or is there a maximum width? The readability is usually considered >> better when the lines of text aren't too long. >> >> A new skin could be the opportunity to rethink the content of the sites. >> In particular I find the menus too verbose and messy. The Maven reports >> are often useless for a public website, for example who cares about the >> Checkstyle or the Findbugs reports besides the developers? > > People who discover the product for the first time and want to see if it > is stable or good quality are interested. > In fact, I even miss the cobertura reports on the public site that have > been removed in some components. +1. The reports are not displayed by default, so I don't see what the problem is. Besides, as Luc says, they are useful to some. As to Checkstyle - remember that the ASF releases source primarily. So if someone wants to work on extending the source, it is a potentially important factor. > Luc > >> >> Emmanuel Bourg >> >> >> Le 26/11/2011 22:07, Simone Tripodi a écrit : >>> Hi all guys, >>> at Maven we have just released a new skin[1], I quickly did an >>> experiment and applied it on my beloved digester, deploying the site >>> on my personal [2] ASF space. >>> WDYT? Is there any chance to have it applied here at commons? >>> It would involve a little modification to the parent pom[3]. >>> Any feedback would me much more than appreciated, many thanks in advance! >>> Simo >>> >>> [1] http://maven.apache.org/skins/maven-fluido-skin/ >>> [2] http://people.apache.org/~simonetripodi/digester >>> [3] https://gist.github.com/1396291 >>> >>> http://people.apache.org/~simonetripodi/ >>> http://simonetripodi.livejournal.com/ >>> http://twitter.com/simonetripodi >>> http://www.99soft.org/ >>> >>> - >>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>> For additional commands, e-mail: dev-h...@commons.apache.org >>> >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org >> > > > - > 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: [chain][v2] chain-58
Hi Elijah,
brilliant, thanks for contributing one again! I'll give a review of
your patch as son as I get the chance today, unfortunately I'm in a
little busy era due to my job, but this evening I'll have the chance
to have a look at it :)
Have a nice day, all the best!
Simo
http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/
On Sun, Nov 27, 2011 at 9:23 PM, Elijah Zupancic wrote:
> Hi Everyone,
>
> After a bunch of work, I was able to genericize chain into using contexts
> with the signature Context as per Paul's suggestion. It took sweeping
> code changes to the chain codebase. Please see the patch attached to the
> issue: https://issues.apache.org/jira/browse/CHAIN-58
>
> The primary approach that I took was to assume that all functionality
> outside of the core Context interface are implemented as Context Object>. This allowed me to build off of the current contract. Now, the
> library builds with no warnings and all SuppressWarnings("unchecked") are
> commented. Although their comments are often just stating that we are
> following the existing contract.
>
> I realize that this will take a while to review, but my hope is that these
> changes will please all parties who felt that the changes to the Context
> generic's signature were too drastic.
>
> Please let me know what you think.
>
> After this, I would love to get onto removing deprecated methods,
> genericizing the unit tests and breaking apart the portlet, servlet, etc
> code into different maven packages.
>
> Thanks,
> -Elijah
>
> On Tue, Sep 20, 2011 at 1:22 AM, Simone Tripodi
> wrote:
>
>> Hi Elijah,
>> by default Maven doesn't show warnings, you have to modify the pom.xml
>> in that way:
>>
>> {code}
>>
>> org.apache.maven.plugins
>> maven-compiler-plugin
>> 2.1
>>
>> ${maven.compile.source}
>> ${maven.compile.target}
>> -Xlint:all
>> true
>>
>>
>> {code}
>>
>> If you try to run {{mvn clean compile}} to vanilla [chain] code, you
>> can already notice some warnings:
>>
>> $ mvn --version
>> Apache Maven 3.0.3 (r1075438; 2011-02-28 18:31:09+0100)
>> Maven home: /Applications/apache-maven-3.0.3
>> Java version: 1.5.0_30, vendor: Apple Inc.
>> Java home: /System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/Home
>> Default locale: en_US, platform encoding: MacRoman
>> OS name: "mac os x", version: "10.7.1", arch: "i386", family: "unix"
>>
>>
>>
>> $ mvn clean compile
>>
>> [INFO] Compiling 63 source files to
>> /Users/simonetripodi/Documents/workspace/commons-chain/target/classes
>> [WARNING]
>> /Users/simonetripodi/Documents/workspace/commons-chain/src/main/java/org/apache/commons/chain/impl/ContextBase.java:[633,46]
>> [unchecked] unchecked conversion
>> found : java.util.Map.Entry
>> required: java.util.Map.Entry
>>
>> [WARNING]
>> /Users/simonetripodi/Documents/workspace/commons-chain/src/main/java/org/apache/commons/chain/impl/ContextBase.java:[652,76]
>> [unchecked] unchecked cast
>> found : java.lang.Object
>> required: java.util.Map.Entry
>>
>> [WARNING]
>> /Users/simonetripodi/Documents/workspace/commons-chain/src/main/java/org/apache/commons/chain/impl/ContextBase.java:[779,48]
>> [unchecked] unchecked conversion
>> found : java.util.Map.Entry
>> required: java.util.Map.Entry
>>
>> [WARNING]
>> /Users/simonetripodi/Documents/workspace/commons-chain/src/main/java/org/apache/commons/chain/web/faces/FacesWebContext.java:[133,58]
>> [unchecked] unchecked conversion
>> found : java.util.Map
>> required: java.util.Map
>>
>> [WARNING]
>> /Users/simonetripodi/Documents/workspace/commons-chain/src/main/java/org/apache/commons/chain/web/faces/FacesWebContext.java:[133,11]
>> [unchecked] unchecked conversion
>> found : java.util.Map
>> required: java.util.Map
>>
>> [WARNING]
>> /Users/simonetripodi/Documents/workspace/commons-chain/src/main/java/org/apache/commons/chain/web/faces/FacesWebContext.java:[145,60]
>> [unchecked] unchecked conversion
>> found : java.util.Map
>> required: java.util.Map
>>
>> [WARNING]
>> /Users/simonetripodi/Documents/workspace/commons-chain/src/main/java/org/apache/commons/chain/web/faces/FacesWebContext.java:[145,11]
>> [unchecked] unchecked conversion
>> found : java.util.Map
>> required: java.util.Map
>>
>> [WARNING]
>> /Users/simonetripodi/Documents/workspace/commons-chain/src/main/java/org/apache/commons/chain/web/faces/FacesWebContext.java:[157,66]
>> [unchecked] unchecked conversion
>> found : java.util.Map
>> required: java.util.Map
>>
>> [WARNING]
>> /Users/simonetripodi/Documents/workspace/commons-chain/src/main/java/org/apache/commons/chain/web/faces/FacesWebContext.java:[157,11]
>> [unchecked] unchecked conversion
>> found : java.util.Map
>> required: java.uti
