Re: [csv] API design
Le 28/11/2011 21:33, Erhan Bagdemir a écrit :
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 ?
Collections are probably out of the scope of [csv]. The best we could do
is splitting a field on a secondary delimiter, something like this:
foo;bar;element1:element2
with a bean declaration like:
public class Bean {
@CSVField String foo;
@CSVField String bar;
@CSVField(split=:)
String[] elements;
}
Emmanuel Bourg
smime.p7s
Description: Signature cryptographique S/MIME
Re: [math] Inconsistencies (bugs) in PascalDistribution?
2011/11/29 Sébastien Brisard sebastien.bris...@m4x.org: 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 ;) ). No, you are more than welcome to do the patch and I'll review it :-). Thanks! Cheers, Mikkel. 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: [csv] API design
On Tue, Nov 29, 2011 at 2:34 AM, Emmanuel Bourg ebo...@apache.org wrote:
Le 28/11/2011 21:33, Erhan Bagdemir a écrit :
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 ?
Collections are probably out of the scope of [csv]. The best we could do is
splitting a field on a secondary delimiter, something like this:
foo;bar;element1:element2
with a bean declaration like:
public class Bean {
@CSVField String foo;
@CSVField String bar;
@CSVField(split=:)
String[] elements;
}
Well, assuming header-free CSV output you could do any odd thing like:
foo;bar;(2);element1;element2;
giving an open-ended format. Not saying such would be the greatest
idea, but could be usable under the right circumstances.
Alternatively, one could embed the collection:
foo;bar;{element1;element2}
Just food for thought,
Matt
Emmanuel Bourg
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Re: [dbutils] Releasing 1.5
On 29 November 2011 07:48, ma...@apache.org wrote: Henri Yandell flame...@gmail.com 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. And make sure the key has been uploaded to a public key server. Mark Hen On Mon, Nov 28, 2011 at 6:20 PM, William Speirs wspe...@apache.org 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 - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [csv] API design
Le 29/11/2011 14:43, Matt Benson a écrit :
Well, assuming header-free CSV output you could do any odd thing like:
foo;bar;(2);element1;element2;
giving an open-ended format. Not saying such would be the greatest
idea, but could be usable under the right circumstances.
Alternatively, one could embed the collection:
foo;bar;{element1;element2}
... and it starts to get fun when you want to escape the special
characters '', ';' and '}' in the collection ;)
It's possible to tailor a CSV like format that supports collections, but
if it doesn't interoperate with other CSV tools it's hardly useful. If
people want a more capable format without caring about interoperability
there are legions of alternative serialization APIs available.
That's why I think [csv] should focus on the simple format defined by
RFC4180, exotic features are for more ambitious projects (at least for now).
Emmanuel Bourg
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Re: [csv] API design
On 11/29/2011 2:26 PM, Emmanuel Bourg wrote:
Le 29/11/2011 14:43, Matt Benson a écrit :
Well, assuming header-free CSV output you could do any odd thing like:
foo;bar;(2);element1;element2;
giving an open-ended format. Not saying such would be the greatest
idea, but could be usable under the right circumstances.
Alternatively, one could embed the collection:
foo;bar;{element1;element2}
... and it starts to get fun when you want to escape the special
characters '', ';' and '}' in the collection ;)
It's possible to tailor a CSV like format that supports collections,
but if it doesn't interoperate with other CSV tools it's hardly
useful. If people want a more capable format without caring about
interoperability there are legions of alternative serialization APIs
available.
That's why I think [csv] should focus on the simple format defined by
RFC4180, exotic features are for more ambitious projects (at least for
now).
I agree. My personal software design philosophy is: Do one thing, and do
it really well.
-Adrian
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Re: [csv] API design
It really sounds like csv should just be a format that's plugged into
another library.
On Nov 29, 2011 9:29 AM, Emmanuel Bourg ebo...@apache.org wrote:
Le 29/11/2011 14:43, Matt Benson a écrit :
Well, assuming header-free CSV output you could do any odd thing like:
foo;bar;(2);element1;element2;
giving an open-ended format. Not saying such would be the greatest
idea, but could be usable under the right circumstances.
Alternatively, one could embed the collection:
foo;bar;{element1;element2}
... and it starts to get fun when you want to escape the special
characters '', ';' and '}' in the collection ;)
It's possible to tailor a CSV like format that supports collections, but
if it doesn't interoperate with other CSV tools it's hardly useful. If
people want a more capable format without caring about interoperability
there are legions of alternative serialization APIs available.
That's why I think [csv] should focus on the simple format defined by
RFC4180, exotic features are for more ambitious projects (at least for now).
Emmanuel Bourg
--**--**-
To unsubscribe, e-mail:
dev-unsubscribe@commons.**apache.orgdev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Re: [JEXL] binary compatibility
On 28 November 2011 16:26, sebb seb...@gmail.com wrote: On 28 November 2011 15:55, henrib hen...@apache.org 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. I've not found any issues - JMeter compiles and tests OK. However, JMeter does not use many of the its features. A better test would be to see what happens with the JUnit test cases from 2.0.1. Some of these are bound to fail, but if most pass, then that may indicate that the API is not too badly broken to release. 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. If it does prove necessary, then we should check that there aren't any other issues with the API that still need fixing. Otherwise the process will repeat ... 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: svn commit: r1207946 - /commons/proper/jexl/tags/COMMONS_JEXL_3_0/
On 29 November 2011 16:26, hen...@apache.org wrote: Author: henrib Date: Tue Nov 29 16:26:10 2011 New Revision: 1207946 URL: http://svn.apache.org/viewvc?rev=1207946view=rev Log: [maven-release-plugin] copy for tag COMMONS_JEXL_3_0 Added: commons/proper/jexl/tags/COMMONS_JEXL_3_0/ - copied from r1207945, commons/proper/jexl/trunk/ Where is the RC tag suffix? - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Release JEXL 3.0 based on RC1
Dear all,
JEXL 3.0 is ready for review.
The 2.1 attempt comments have been folded in; JEXL 3 being binary and source
code incompatible with JEXL 2, the code has moved to the new o.a.c.jexl3
package.
I've also moved some classes to the internal packages to make the public API
clearer for the future.
Here is a quick list of new features (from the release notes):
What's new in 3.0:
==
* 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 3.0:
* 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_3_0/
Site:
https://people.apache.org/~henrib/jexl-3.0
Binaries:
https://repository.apache.org/content/repositories/orgapachecommons-267/
This vote will close in 72 hours, 08:00PM GMT, Dec 3rd.
[ ] +1 Release these artifacts
[ ] +0 OK, but...
[ ] -0 OK, but really should fix...
[ ] -1 I oppose this release because...
Many thanks,
Regards.
Henrib
Re: svn commit: r1207946 - /commons/proper/jexl/tags/COMMONS_JEXL_3_0/
Missed... I'll copy the tag with RC1. -- View this message in context: http://apache-commons.680414.n4.nabble.com/Re-svn-commit-r1207946-commons-proper-jexl-tags-COMMONS-JEXL-3-0-tp4119802p4119911.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: svn commit: r1207946 - /commons/proper/jexl/tags/COMMONS_JEXL_3_0/
Done. https://svn.apache.org/repos/asf/commons/proper/jexl/tags/COMMONS_JEXL_3_0-RC1/ -- View this message in context: http://apache-commons.680414.n4.nabble.com/Re-svn-commit-r1207946-commons-proper-jexl-tags-COMMONS-JEXL-3-0-tp4119802p4119930.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: Release JEXL 3.0 based on RC1
On 29 November 2011 17:00, Henri Biestro hbies...@gmail.com wrote:
Dear all,
JEXL 3.0 is ready for review.
The 2.1 attempt comments have been folded in; JEXL 3 being binary and source
code incompatible with JEXL 2, the code has moved to the new o.a.c.jexl3
package.
I've also moved some classes to the internal packages to make the public API
clearer for the future.
Here is a quick list of new features (from the release notes):
What's new in 3.0:
==
* 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 3.0:
* 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_3_0/
Site:
https://people.apache.org/~henrib/jexl-3.0
Binaries:
https://repository.apache.org/content/repositories/orgapachecommons-267/
This vote will close in 72 hours, 08:00PM GMT, Dec 3rd.
[ ] +1 Release these artifacts
[ ] +0 OK, but...
[ ] -0 OK, but really should fix...
[X] -1 I oppose this release because...
The artifactId has not been changed; this will caused lots of
problems if released to Maven Central.
However, that is not the only reservation I have.
Are we sure that all API-breaking changes have been fixed in this release?
Until I have had time for further investigation, I must vote -1 even
if the artifactId issue is fixed.
This is not to say I think it's wrong to change the package name (and
artifactId) and release version.
But such a major change needs careful scrutiny to make sure all the
required changes are done at the same time.
Otherwise, there will likely need to be a further major release/rename.
I am also a bit disappointed that we don't seem to have fully explored
fixing the API breakages.
It may turn out to be necessary to go through the rename, but it would
be easier for all users if the release were a drop-in replacement.
Many thanks,
Regards.
Henrib
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Re: svn commit: r1207974 - /commons/proper/jexl/tags/COMMONS_JEXL_3_0-RC1/
On 29 November 2011 17:08, hen...@apache.org wrote: Author: henrib Date: Tue Nov 29 17:08:05 2011 New Revision: 1207974 URL: http://svn.apache.org/viewvc?rev=1207974view=rev Log: 3.0 RC1 Added: commons/proper/jexl/tags/COMMONS_JEXL_3_0-RC1/ - copied from r1207973, commons/proper/jexl/tags/COMMONS_JEXL_3_0/ The original tag should never have been created, but unfortunately it was. I think the tag should now be destroyed, because it does not correspond to an official release. Note: The RC1 VOTE must not succeed because the pom has the wrong artifactId, so the 3.0 tag as it stands can never correspond to an official release. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: Release JEXL 3.0 based on RC1
I dont understand what is expected anymore... There are some new features and fixes that break the API at the binary and source level; I'm merely applying the best practice recommendations - and previous 2.1 rejection basis. This version has been 18 months in the making, fixes quite a few bugs and adds what could be considered major functionalities; making it a new major version does not seem stupid. Besides, the very scarce JEXL's community is expecting these changes and no other Apache component really uses JEXL 2. Besides, anyone using a scripting engine in a binary safe way will (should) use it through JSR-223... What is the danger here, besides scaring off anyone trying to use JEXL ? Even if the next version is again a major one after 18 months (on average), would it be so bad ? I'm really puzzled and can't understand the motivation to reject (besides the artifactId). And if you feel disappointed, how would you feel if your work and time was only considered low quality or a waste by people who aren't actually using it? After all, may be OGNL is the way to go and JEXL moved to the attic... Sorry for the rant and thanks for another lesson in humility. Henrib -- View this message in context: http://apache-commons.680414.n4.nabble.com/Release-JEXL-3-0-based-on-RC1-tp4119894p4120071.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: svn commit: r1207974 - /commons/proper/jexl/tags/COMMONS_JEXL_3_0-RC1/
Removed the tag. And don't understand why the artifactId must change with the version. -- View this message in context: http://apache-commons.680414.n4.nabble.com/Re-svn-commit-r1207974-commons-proper-jexl-tags-COMMONS-JEXL-3-0-RC1-tp4120017p4120114.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: Release JEXL 3.0 based on RC1
Hi Henri, henrib wrote: I dont understand what is expected anymore... There are some new features and fixes that break the API at the binary and source level; I'm merely applying the best practice recommendations - and previous 2.1 rejection basis. This version has been 18 months in the making, fixes quite a few bugs and adds what could be considered major functionalities; making it a new major version does not seem stupid. Besides, the very scarce JEXL's community is expecting these changes and no other Apache component really uses JEXL 2. Besides, anyone using a scripting engine in a binary safe way will (should) use it through JSR-223... What is the danger here, besides scaring off anyone trying to use JEXL ? Even if the next version is again a major one after 18 months (on average), would it be so bad ? I'm really puzzled and can't understand the motivation to reject (besides the artifactId). And if you feel disappointed, how would you feel if your work and time was only considered low quality or a waste by people who aren't actually using it? After all, may be OGNL is the way to go and JEXL moved to the attic... Sorry for the rant and thanks for another lesson in humility. As you said, this release was in the making for 18 months - so why do you try to rush it now in this way? Yes, the policy is, that we rename package and artifactId if we release a binary incompatible version (API-wise). However, if there is a possibility to make a API-wise binary compatible drop-in release, this has always to be preferred, since then no-one has to change package names in his own sources to use the new version. And exactly that point is not yet cleared! Sebb tried to help by resolving the incompatible changes to make a preferred 2.1 release possible, but this research was not finished. If we break with every release the API of a component, it is also not a very good sign to our users also. And if it means to have some deprecated methods and classes - so what? - Jörg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: svn commit: r1207974 - /commons/proper/jexl/tags/COMMONS_JEXL_3_0-RC1/
henrib wrote: Removed the tag. And don't understand why the artifactId must change with the version. And how would you then declare dependencies for both versions at once? Maven will then always resolve to exactly one version to be used for your complete dependency tree and any component depending on the old version is immediately broken because it can no longer find its classes. - Jörg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
[CANCELLED] Release JEXL 3.0 based on RC1
I'm obviously unfit as RM. Sorry for the mess, feel free to remove any offending tag/branch/code. Regards. Henrib - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [CANCELLED] Release JEXL 3.0 based on RC1
On Tue, Nov 29, 2011 at 3:19 PM, Gary Gregory garydgreg...@gmail.com wrote: On Tue, Nov 29, 2011 at 2:09 PM, Henri Biestro hbies...@gmail.com wrote: I'm obviously unfit as RM. I do not think so. +1. I've only done the RM thing once, because it's such a PITA to get things right. This is one reason we need to release early and often, simply so that the release process will become so trivial that we will no longer fear it! Matt I always make a mini-mess of RCs. I just try again. And again. Until I get it right. Every time, it's a different problem I run into. Witness the current [codec] 1.6 RC cancellation. Don't give up! Just plug along and you'll get there! Gary Sorry for the mess, feel free to remove any offending tag/branch/code. Regards. Henrib - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org -- E-Mail: garydgreg...@gmail.com | ggreg...@apache.org JUnit in Action, 2nd Ed: http://goog_1249600977http://bit.ly/ECvg0 Spring Batch in Action: http://s.apache.org/HOqhttp://bit.ly/bqpbCK Blog: http://garygregory.wordpress.com Home: http://garygregory.com/ Tweet! http://twitter.com/GaryGregory - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: svn commit: r1208162 - /commons/proper/jexl/trunk/pom.xml
On 30 November 2011 00:55, s...@apache.org wrote: Author: sebb Date: Wed Nov 30 00:55:42 2011 New Revision: 1208162 URL: http://svn.apache.org/viewvc?rev=1208162view=rev Log: Revert to previous snapshot Change artifactId because package was changed This is just in case we end up doing a 3.0 release from trunk; did not want to forget the Maven id change. Modified: commons/proper/jexl/trunk/pom.xml Modified: commons/proper/jexl/trunk/pom.xml URL: http://svn.apache.org/viewvc/commons/proper/jexl/trunk/pom.xml?rev=1208162r1=1208161r2=1208162view=diff == --- commons/proper/jexl/trunk/pom.xml (original) +++ commons/proper/jexl/trunk/pom.xml Wed Nov 30 00:55:42 2011 @@ -23,8 +23,8 @@ /parent modelVersion4.0.0/modelVersion groupIdorg.apache.commons/groupId - artifactIdcommons-jexl/artifactId - version3.1-SNAPSHOT/version + artifactIdcommons-jexl3/artifactId + version3.0-SNAPSHOT/version nameCommons JEXL/name inceptionYear2001/inceptionYear descriptionThe Commons Jexl library is an implementation of the JSTL Expression Language with extensions./description - 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, and has been outstanding for 2 runs. 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 26 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.022 ms 64 bytes from 127.0.0.1: icmp_seq=2 ttl=64 time=0.026 ms 64 bytes from 127.0.0.1: icmp_seq=3 ttl=64 time=0.030 ms Process completed in 2005 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 2005 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 8016 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.786 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: Wed Nov 30 02:41:04 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 1330112011, vmgump.apache.org:vmgump:1330112011 Gump E-mail Identifier (unique within run) #19. -- 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-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 249 runs. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - commons-proxy-test : Apache Commons Full details are available at: http://vmgump.apache.org/gump/public/apache-commons/commons-proxy-test/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -WARNING- Overriding Maven settings: [/srv/gump/public/workspace/apache-commons/proxy/gump_mvn_settings.xml] -DEBUG- (Apache Gump generated) Apache Maven Settings in: /srv/gump/public/workspace/apache-commons/proxy/gump_mvn_settings.xml -INFO- Failed with reason build failed -DEBUG- Maven POM in: /srv/gump/public/workspace/apache-commons/proxy/pom.xml -INFO- Project Reports in: /srv/gump/public/workspace/apache-commons/proxy/target/surefire-reports The following work was performed: http://vmgump.apache.org/gump/public/apache-commons/commons-proxy-test/gump_work/build_apache-commons_commons-proxy-test.html Work Name: build_apache-commons_commons-proxy-test (Type: Build) Work ended in a state of : Failed Elapsed: 14 secs Command Line: /opt/maven2/bin/mvn --batch-mode --settings /srv/gump/public/workspace/apache-commons/proxy/gump_mvn_settings.xml test [Working Directory: /srv/gump/public/workspace/apache-commons/proxy] M2_HOME: /opt/maven2 - Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.003 sec Running org.apache.commons.proxy.factory.util.TestMethodSignature Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.002 sec Running org.apache.commons.proxy.provider.TestConstantProvider Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.003 sec Running org.apache.commons.proxy.interceptor.TestFilteredInterceptor Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.034 sec Running org.apache.commons.proxy.interceptor.filter.TestPatternFilter Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.003 sec Running org.apache.commons.proxy.interceptor.TestSerializingInterceptor Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.036 sec Running org.apache.commons.proxy.interceptor.TestInterceptorChain Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.008 sec Running org.apache.commons.proxy.invoker.TestNullInvoker Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.031 sec Running org.apache.commons.proxy.provider.remoting.TestBurlapProvider Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.012 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.042 sec Running org.apache.commons.proxy.factory.javassist.TestJavassistProxyFactory Tests run: 37, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.199 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.002 sec Running org.apache.commons.proxy.provider.TestBeanProvider Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.035 sec Results : Tests in error: testInvalidHandlerName(org.apache.commons.proxy.invoker.TestXmlRpcInvoker) Tests run: 179, Failures: 0, Errors: 1, Skipped: 0 [INFO] [ERROR] BUILD FAILURE [INFO] [INFO] There are test failures. Please refer to /srv/gump/public/workspace/apache-commons/proxy/target/surefire-reports for the individual test results. [INFO] [INFO] For more information, run Maven with the -e switch [INFO] [INFO] Total time: 12 seconds [INFO] Finished at: Wed Nov 30 06:27:41 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:
Re: [CANCELLED] Release JEXL 3.0 based on RC1
Le 29/11/2011 22:28, Matt Benson a écrit : On Tue, Nov 29, 2011 at 3:19 PM, Gary Gregory garydgreg...@gmail.com wrote: On Tue, Nov 29, 2011 at 2:09 PM, Henri Biestro hbies...@gmail.com wrote: I'm obviously unfit as RM. I do not think so. +1. I've only done the RM thing once, because it's such a PITA to get things right. This is one reason we need to release early and often, simply so that the release process will become so trivial that we will no longer fear it! +1 too. The release I made was on code considered clean and stable when I started. It took 6 RC before pushing it out. You are quite close now, there was only one comment about the artifacts. thanks for your efforts, Luc Matt I always make a mini-mess of RCs. I just try again. And again. Until I get it right. Every time, it's a different problem I run into. Witness the current [codec] 1.6 RC cancellation. Don't give up! Just plug along and you'll get there! Gary Sorry for the mess, feel free to remove any offending tag/branch/code. Regards. Henrib - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org -- E-Mail: garydgreg...@gmail.com | ggreg...@apache.org JUnit in Action, 2nd Ed: http://goog_1249600977http://bit.ly/ECvg0 Spring Batch in Action: http://s.apache.org/HOqhttp://bit.ly/bqpbCK Blog: http://garygregory.wordpress.com Home: http://garygregory.com/ Tweet! http://twitter.com/GaryGregory - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
