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
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 no
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-chain has an issue affecting its community integration.
This issue
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
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:
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 PascalDistrib
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
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
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
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
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?
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://simonetripo
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)
}
B
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 digest
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 feed
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/
ht
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
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
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
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),
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 'Unifi
@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
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 a
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
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 n
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 def
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 feed
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
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
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
h
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
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 depen
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
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 th
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
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.apac
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,
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 som
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
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 mana
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
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
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
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.o
45 matches
Mail list logo
