Le 29/11/2011 22:28, Matt Benson a écrit :
> On Tue, Nov 29, 2011 at 3:19 PM, Gary Gregory wrote:
>> On Tue, Nov 29, 2011 at 2:09 PM, Henri Biestro 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
> t
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
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 i
On 30 November 2011 00:55, wrote:
> Author: sebb
> Date: Wed Nov 30 00:55:42 2011
> New Revision: 1208162
>
> URL: http://svn.apache.org/viewvc?rev=1208162&view=rev
> Log:
> Revert to previous snapshot
> Change artifactId because package was changed
This is just in case we end up doing a 3.0 rel
On Tue, Nov 29, 2011 at 3:19 PM, Gary Gregory wrote:
> On Tue, Nov 29, 2011 at 2:09 PM, Henri Biestro 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
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.apa
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 de
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
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 a
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 an
On 29 November 2011 17:08, wrote:
> Author: henrib
> Date: Tue Nov 29 17:08:05 2011
> New Revision: 1207974
>
> URL: http://svn.apache.org/viewvc?rev=1207974&view=rev
> Log:
> 3.0 RC1
>
> Added:
> commons/proper/jexl/tags/COMMONS_JEXL_3_0-RC1/
> - copied from r1207973, commons/proper/jexl
On 29 November 2011 17:00, Henri Biestro 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 t
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 archiv
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.
--
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
On 29 November 2011 16:26, wrote:
> Author: henrib
> Date: Tue Nov 29 16:26:10 2011
> New Revision: 1207946
>
> URL: http://svn.apache.org/viewvc?rev=1207946&view=rev
> Log:
> [maven-release-plugin] copy for tag COMMONS_JEXL_3_0
>
> Added:
> commons/proper/jexl/tags/COMMONS_JEXL_3_0/
> -
On 28 November 2011 16:26, sebb wrote:
> 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
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" 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;
>
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 t
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 cou
On 29 November 2011 07:48, wrote:
> 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 (ve
On Tue, Nov 29, 2011 at 2:34 AM, Emmanuel Bourg 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:
>> @
2011/11/29 Sébastien Brisard :
> 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 rep
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 {
24 matches
Mail list logo
