can you add me please in the moderators list in #asfcommons on freenode?

[Simone Tripodi]

Hi all guys,

I just registered my nickname "simonetripodi" on freenode, IIUC Matt
and James are the channel owners - can you add me please in the
moderators list in #asfcommons channel?

TIA,
-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

Re: [digester] Documentation link broken

[Simone Tripodi]

Hi Elijah,

go ahead and many thanks in advance! :)

best,
-Simo

http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/


On Mon, Jul 23, 2012 at 9:20 PM, Elijah Zupancic  wrote:
> I just notice that the link to Core APIs on the front page of the
> Digester project is broken. It points to:
> http://commons.apache.org/digester/commons-digester-3.0/core.html
>
> When it probably should point to:
> http://commons.apache.org/digester/guide/core.html
>
> I can go ahead and fix this unless there are any objections.
>
> -Elijah
>
> -
> 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: [chain2] configuration façade APIs

[Simone Tripodi]

Hi Elijah,

not sure we understand each other there, please confirm IIUC - in my
mind I would have extracted "configurations APIs" (mainly interfaces
and few abstract classes maybe) from the configuration module and put
in the core, then renamed the actual configuration module to
`xml-configuration` and let the [digester] dependency - and make the
switch to [configuration] in a second step, taking care on ingesting
same type of input format.

did I understand correctly?
TIA!
-Simo

http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/


On Mon, Jul 23, 2012 at 9:34 PM, Elijah Zupancic  wrote:
> I've been going through the chain source for about a day looking for a
> way to decouple the digester configuration. Sadly, I don't think that
> I will be able to do it without removing digester. I may just jump
> ahead and remove [digester] completely and then move us to
> [configuration] for creating dynamic chains. That said, my final
> implementation may change because I haven't been able to prototype a
> good solution yet.
>
> Thanks,
> -Elijah
>
> On Mon, Jul 23, 2012 at 11:11 AM, Elijah Zupancic  wrote:
>> Hi Simo,
>>
>> That sounds good to me. However, I'm having trouble separating the
>> existing Catalog implementation from the rest of chain. Digester is
>> tightly coupled across components, so it is a non-trivial refactor to
>> make a configuration facade. I'm working on it, but it will take some
>> time.
>>
>> Thanks,
>> -Elijah
>>
>> On Mon, Jul 23, 2012 at 12:00 AM, Simone Tripodi
>>  wrote:
>>> Good morning all,
>>>
>>> so I continue proposing the already proposed roadmap: let's add the
>>> façade APIs for the [chain] configuration stuff, adapt the existing
>>> XML configuration reader, use the [configuration] in future releases
>>> for new [chain] configurations.
>>> How does it sound?
>>>
>>> best,
>>> -Simo
>>>
>>> http://people.apache.org/~simonetripodi/
>>> http://simonetripodi.livejournal.com/
>>> http://twitter.com/simonetripodi
>>> http://www.99soft.org/
>>>
>>>
>>> On Mon, Jul 23, 2012 at 7:01 AM, Elijah Zupancic  wrote:
>>>> Hi Oliver,
>>>>
>>>> Configuration seems like it might be useful if I end up redoing the
>>>> XML configuration portion. Are there any plans to support YAML?
>>>>
>>>> Thanks,
>>>> -Elijah
>>>>
>>>> On Sun, Jul 22, 2012 at 1:16 PM, Oliver Heger
>>>>  wrote:
>>>>> Hi Simo,
>>>>>
>>>>> Am 22.07.2012 17:54, schrieb Simone Tripodi:
>>>>>
>>>>>> Good point Oliver,
>>>>>>
>>>>>> I honestly didn't think about [configuration], please apologize! since
>>>>>> [chain] already had a way to be configured via an XML wrapper around
>>>>>> the Digester, we thought it would have been good having a façade and
>>>>>> plug other textual format...
>>>>>>
>>>>>> Anyway, we are open to suggestions - what would fit better for you? Do
>>>>>> you already have some hints to share?
>>>>>>
>>>>>> Many thanks in advance, all the best!
>>>>>> -Simo
>>>>>
>>>>>
>>>>> nothing concrete. I saw that you mentioned an XML configuration module, 
>>>>> and
>>>>> [configuration] contains a XMLConfiguration class. It also supports other
>>>>> configuration file formats, e.g. properties or ini files which can be
>>>>> accessed through the same Configuration interface.
>>>>>
>>>>> I don't know your concrete use cases. If you already have a working
>>>>> implementation based on Digester, there is probably not much benefit in
>>>>> switching to another API. But if you plan support for other configuration
>>>>> file formats, [configuration] may be worth a look.
>>>>>
>>>>> Oliver
>>>>>
>>>>>
>>>>>>
>>>>>> http://people.apache.org/~simonetripodi/
>>>>>> http://simonetripodi.livejournal.com/
>>>>>> http://twitter.com/simonetripodi
>>>>>> http://www.99soft.org/
>>>>>>
>>>>>>
>>>>>> On Sun, Jul 22, 2012 at 4:49 PM, Oliver Heger
>>>>&g

Re: [chain2] configuration façade APIs

[Simone Tripodi]

Thanks a lot Oliver, much more than appreciated!

If you could have a look at current configuration stuff at [chain2]
and share what you think would be already *great*!

then, feel free to put your hands and help us on defining the façade :)

alles gute,
-Simo

http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/


On Mon, Jul 23, 2012 at 9:43 PM, Oliver Heger
 wrote:
> Am 23.07.2012 09:00, schrieb Simone Tripodi:
>
>> Good morning all,
>>
>> so I continue proposing the already proposed roadmap: let's add the
>> façade APIs for the [chain] configuration stuff, adapt the existing
>> XML configuration reader, use the [configuration] in future releases
>> for new [chain] configurations.
>> How does it sound?
>
> +1
>
> If I can support you, let me know.
>
> @Elijah: There is a feature request for adding support for YAML [1]. IIRC,
> it was planned as a Google Summer of Code project, but it did not succeed.
>
> Oliver
>
> [1] https://issues.apache.org/jira/browse/CONFIGURATION-201
>
>
>>
>> best,
>> -Simo
>>
>> http://people.apache.org/~simonetripodi/
>> http://simonetripodi.livejournal.com/
>> http://twitter.com/simonetripodi
>> http://www.99soft.org/
>>
>>
>> On Mon, Jul 23, 2012 at 7:01 AM, Elijah Zupancic 
>> wrote:
>>>
>>> Hi Oliver,
>>>
>>> Configuration seems like it might be useful if I end up redoing the
>>> XML configuration portion. Are there any plans to support YAML?
>>>
>>> Thanks,
>>> -Elijah
>>>
>>> On Sun, Jul 22, 2012 at 1:16 PM, Oliver Heger
>>>  wrote:
>>>>
>>>> Hi Simo,
>>>>
>>>> Am 22.07.2012 17:54, schrieb Simone Tripodi:
>>>>
>>>>> Good point Oliver,
>>>>>
>>>>> I honestly didn't think about [configuration], please apologize! since
>>>>> [chain] already had a way to be configured via an XML wrapper around
>>>>> the Digester, we thought it would have been good having a façade and
>>>>> plug other textual format...
>>>>>
>>>>> Anyway, we are open to suggestions - what would fit better for you? Do
>>>>> you already have some hints to share?
>>>>>
>>>>> Many thanks in advance, all the best!
>>>>> -Simo
>>>>
>>>>
>>>>
>>>> nothing concrete. I saw that you mentioned an XML configuration module,
>>>> and
>>>> [configuration] contains a XMLConfiguration class. It also supports
>>>> other
>>>> configuration file formats, e.g. properties or ini files which can be
>>>> accessed through the same Configuration interface.
>>>>
>>>> I don't know your concrete use cases. If you already have a working
>>>> implementation based on Digester, there is probably not much benefit in
>>>> switching to another API. But if you plan support for other
>>>> configuration
>>>> file formats, [configuration] may be worth a look.
>>>>
>>>> Oliver
>>>>
>>>>
>>>>>
>>>>> http://people.apache.org/~simonetripodi/
>>>>> http://simonetripodi.livejournal.com/
>>>>> http://twitter.com/simonetripodi
>>>>> http://www.99soft.org/
>>>>>
>>>>>
>>>>> On Sun, Jul 22, 2012 at 4:49 PM, Oliver Heger
>>>>>  wrote:
>>>>>>
>>>>>>
>>>>>> Is there any relation or overlap to [configuration]?
>>>>>>
>>>>>> Depending on your concrete requirements, this is probably over-sized.
>>>>>> But
>>>>>> maybe a source of inspiration?
>>>>>>
>>>>>> Oliver
>>>>>>
>>>>>> Am 22.07.2012 10:00, schrieb Elijah Zupancic:
>>>>>>
>>>>>>> Thanks!
>>>>>>>
>>>>>>> On Sat, Jul 21, 2012 at 11:54 PM, Simone Tripodi
>>>>>>>  wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Just tracked CHAIN-72 and assigned to Elijah
>>>>>>>>
>>>>>>>> best,
>>>>>>>> -Simo
>>>>>>>>
>>>>>>>> http://people.apache.org/~simonetripodi/
>>

Re: [functor] Use Validate.notNull and remove unreachable code

[Simone Tripodi]

Olá Bruno,

> 0) I would like to add the method Validate.notNull(...) where necessary in 
> [functor], if no one objects. Right now, I'm working on the following 
> composite functors: TransformedProcedure, TransformedFunction, 
> TransformedBinaryProcedure and TransformedBinaryFunction. None of these 
> validates the arguments, while OTOH, TransposedFunction, TransposedPredicate 
> and TransposedProcedure, classes in the same package, use 
> Validate.notNull(...).

+1

> 1) There is also unreachable code, specially in equals() methods, that checks 
> if an object is null before accessing its methods. But this object can never 
> be null, as Validate.notNull(...) or throw NPE is used to assert this in the 
> constructor. There is no other way to set this object. (You can still change 
> it through reflection, but don't think it is worth keeping it only for this 
> reason). I was wondering if we could remove the unreachable code, as there is 
> no way to write test code for it. [2] is an example of unreachable code (one 
> of its conditions), with the tests in [3] (there is no way to have a null 
> predicate). It will simplify the code, reducing decision branches and will 
> increase the test coverage too.

sounds reasonable too, looking forward to see results!

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

[logging] failing tests

[Simone Tripodi]

Hi all guys,

this morning at the company a colleague of mine was having look to
[logging] on /trunk, when executing tests stumbled in the failing test
below; is there anything you are aware or we have to fill an issue?

TIA,
-Simo

---
 T E S T S
---
Running org.apache.commons.logging.WeakHashTableTestCase
Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 5.258
sec <<< FAILURE!
Running org.apache.commons.logging.avalon.AvalonLoggerTestCase
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0 sec

Results :

Failed tests:
testLOGGING_119(org.apache.commons.logging.WeakHashTableTestCase):
Attempt: 5 Stuck threads: 10

Tests run: 2, Failures: 1, Errors: 0, Skipped: 0

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

Re: [functor] Use Validate.notNull and remove unreachable code

[Simone Tripodi]

Kudos Bruno, parabéns!!!

best,
-Simo

http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/


On Wed, Jul 25, 2012 at 5:51 PM, Bruno P. Kinoshita
 wrote:
> Thanks Matt, Simo!
>
> I've updated the code to use Validate.notNull and removed unreachable code. 
> Tests were created as part of FUNCTOR-12 [1]. The issue was resolved today, 
> with line coverage of 99% and branch coverage of 96% (not being crazy about 
> coverage, just tried to cover important parts of the code :-).
>
> Cheers,
>
> [1] https://issues.apache.org/jira/browse/FUNCTOR-12
>
> Bruno P. Kinoshita
> http://kinoshita.eti.br
> http://tupilabs.com
>
>
>>
>> From: Matt Benson 
>>To: Commons Developers List 
>>Sent: Tuesday, 24 July 2012 12:46 PM
>>Subject: Re: [functor] Use Validate.notNull and remove unreachable code
>>
>>+1 to all FWIW
>>
>>Matt
>>
>>On Tue, Jul 24, 2012 at 4:28 AM, Simone Tripodi
>> wrote:
>>> Olá Bruno,
>>>
>>>> 0) I would like to add the method Validate.notNull(...) where necessary in 
>>>> [functor], if no one objects. Right now, I'm working on the following 
>>>> composite functors: TransformedProcedure, TransformedFunction, 
>>>> TransformedBinaryProcedure and TransformedBinaryFunction. None of these 
>>>> validates the arguments, while OTOH, TransposedFunction, 
>>>> TransposedPredicate and TransposedProcedure, classes in the same package, 
>>>> use Validate.notNull(...).
>>>
>>> +1
>>>
>>>> 1) There is also unreachable code, specially in equals() methods, that 
>>>> checks if an object is null before accessing its methods. But this object 
>>>> can never be null, as Validate.notNull(...) or throw NPE is used to assert 
>>>> this in the constructor. There is no other way to set this object. (You 
>>>> can still change it through reflection, but don't think it is worth 
>>>> keeping it only for this reason). I was wondering if we could remove the 
>>>> unreachable code, as there is no way to write test code for it. [2] is an 
>>>> example of unreachable code (one of its conditions), with the tests in [3] 
>>>> (there is no way to have a null predicate). It will simplify the code, 
>>>> reducing decision branches and will increase the test coverage too.
>>>
>>> sounds reasonable too, looking forward to see results!
>>>
>>> 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: [io] Problem with the FileUtils.byteCountToDisplaySize() method

[Simone Tripodi]

Hi Ninju,

welcome to Apache Commons! Usually these kind of questions should be
sent to users@, while on dev@ we discuss about components development.

Unfortunately I am not familiar with [io] so I am not in the position
to reply your question.

best,
-Simo

http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/


On Wed, Jul 25, 2012 at 6:16 PM, Ninju Bohra
 wrote:
> Hello all,
>
> First time poster so please be kind.
>
> I need to convert a filesize to a human-readable String and I saw the method 
> in FileUtils that I thought I could use.
>
> But I also searched StackOverflow.com and found the following question:
>
> http://stackoverflow.com/questions/3758606/how-to-convert-byte-size-into-human-readable-format-in-java
>
> It looks like the most popular answer appears to be more flexible and capable 
> (esp. for European concerns) that what is currently in FileUtils.java
>
> What is the process for getting this behavior available to FileUtils.java, 
> either as a new method(s) OR as an update to the existing implementation?
>
> Thanks,
>
> 
> Ninju Bohra
> (636) 534-5753 (desk)
> (636) 675-0639 (cell)
> ninju.bo...@technologypartners.co
>

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [io] Problem with the FileUtils.byteCountToDisplaySize() method

[Simone Tripodi]

> I've found that the best way to get
> something done is to offer to do it yourself.

that's the best quote of the day! :) Users have to contribute back!
-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

Re: [chain2] configuration façade APIs

[Simone Tripodi]

> I may draft up a prototype using YAML as a configuration source, just
> to make sure that it in fact is a good abstraction. I noticed that the
> SnakeYaml parser is under the Apache 2.0 license
> (http://code.google.com/p/snakeyaml/). I'm assuming that it wouldn't
> be a problem to take it as a dependency.

+1!

-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

Re: [chain2] configuration façade APIs

[Simone Tripodi]

Good!

hopefully Bruno can provide some help/advice to Elijah!

Thanks,
-Simo

http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/


On Thu, Jul 26, 2012 at 3:43 PM, Bruno P. Kinoshita
 wrote:
> +1
>
> I used SnakeYaml in a project [1] that parses TAP test streams and in some 
> Jenkins plug-ins, and had a look at the source code too. It works very well 
> with the latest YAML spec and the source code is very neat and with many 
> tests.
>
> TestNG uses SnakeYaml for parsing YAML configuration of test suites too [2].
>
> [1] http://www.tap4j.org
> [2] https://github.com/cbeust/testng/blob/master/pom.xml#L124
>
> Bruno P. Kinoshita
> http://kinoshita.eti.br
> http://tupilabs.com
>
>>____
>> From: Simone Tripodi 
>>To: Commons Developers List 
>>Sent: Thursday, 26 July 2012 4:58 AM
>>Subject: Re: [chain2] configuration façade APIs
>>
>>> I may draft up a prototype using YAML as a configuration source, just
>>> to make sure that it in fact is a good abstraction. I noticed that the
>>> SnakeYaml parser is under the Apache 2.0 license
>>> (http://code.google.com/p/snakeyaml/). I'm assuming that it wouldn't
>>> be a problem to take it as a dependency.
>>
>>+1!
>>
>>-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

Re: [chain2] configuration façade APIs

[Simone Tripodi]

Hi Oliver,

we are on the same path!!! I had the idea of realizing an "universal"
parser (XML/JSON/YAML/INI) just writing XML readers adapters :)

good thought!
-Simo

http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/


On Thu, Jul 26, 2012 at 9:37 PM, Oliver Heger
 wrote:
> Slightly off-topic:
>
> Do you think the following approach could work: Consider there is a central
> component - e.g. [flatfile] in sandbox - which implements parsers for
> various text-base formats like YAML, JSON, CSV, ... and a generic mechanism
> for transforming the parsed data into XML SAX events. Then in theory it
> would be possible that all XML-based Commons components like [digester],
> [configuration], or [jelly] could directly read such formats.
>
> WDYT?
> Oliver
>
> Am 26.07.2012 16:10, schrieb Simone Tripodi:
>
>> Good!
>>
>> hopefully Bruno can provide some help/advice to Elijah!
>>
>> Thanks,
>> -Simo
>>
>> http://people.apache.org/~simonetripodi/
>> http://simonetripodi.livejournal.com/
>> http://twitter.com/simonetripodi
>> http://www.99soft.org/
>>
>>
>> On Thu, Jul 26, 2012 at 3:43 PM, Bruno P. Kinoshita
>>  wrote:
>>>
>>> +1
>>>
>>> I used SnakeYaml in a project [1] that parses TAP test streams and in
>>> some Jenkins plug-ins, and had a look at the source code too. It works very
>>> well with the latest YAML spec and the source code is very neat and with
>>> many tests.
>>>
>>> TestNG uses SnakeYaml for parsing YAML configuration of test suites too
>>> [2].
>>>
>>> [1] http://www.tap4j.org
>>> [2] https://github.com/cbeust/testng/blob/master/pom.xml#L124
>>>
>>> Bruno P. Kinoshita
>>> http://kinoshita.eti.br
>>> http://tupilabs.com
>>>
>>>> 
>>>> From: Simone Tripodi 
>>>> To: Commons Developers List 
>>>> Sent: Thursday, 26 July 2012 4:58 AM
>>>> Subject: Re: [chain2] configuration façade APIs
>>>>
>>>>> I may draft up a prototype using YAML as a configuration source, just
>>>>> to make sure that it in fact is a good abstraction. I noticed that the
>>>>> SnakeYaml parser is under the Apache 2.0 license
>>>>> (http://code.google.com/p/snakeyaml/). I'm assuming that it wouldn't
>>>>> be a problem to take it as a dependency.
>>>>
>>>>
>>>> +1!
>>>>
>>>> -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
>

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [chain2] serialVersionUID

[Simone Tripodi]

Hi Elijah,

> I think that the date can work because we rarely update the ids.

+1

> In the end, I will change all of the ids to whatever format that we
> decide on. Do we want to have a vote or something about this?

not required IMHO, it can stay as you already modified them - maybe
just put a note/comment as a reminder for future committers.

As a 0.02 cents margin note: there are better serialization methods in
the place of default Java serialization, guess who's still using that
last one...

-Simo

http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/


On Thu, Jul 26, 2012 at 9:16 PM, Elijah Zupancic  wrote:
> @Benedikt - This reply isn't addressed to you I just replied to your
> message to continue the thread.
>
> Wow, folks. I had no idea that the serialization id would be such a
> big deal. I jumped the gun and checked in ids done in the date format
> because it sounded like a good enough solution. I really don't have an
> opinion on what approach that we use as long as we all agree on it.
>
> I think that the date can work because we rarely update the ids.
> Furthermore, all that matters is that a given id has been incremented
> from the last id.
>
> In the end, I will change all of the ids to whatever format that we
> decide on. Do we want to have a vote or something about this?
>
> Thanks,
> -Elijah
>
> On Thu, Jul 26, 2012 at 11:52 AM, Bruno P. Kinoshita
>  wrote:
>>
>>
>>>
>>> From: Benedikt Ritter 
>>>To: Commons Developers List 
>>>Sent: Thursday, 26 July 2012 3:28 PM
>>>Subject: Re: [chain2] serialVersionUID
>>>
>>>2012/7/26 sebb :
 On 26 July 2012 18:29, Brent Worden  wrote:
> On Thu, Jul 26, 2012 at 3:48 AM, sebb  wrote:
>> On 25 July 2012 07:54, Jörg Schaible  wrote:
>>> sebb wrote:
>>>
 On 24 July 2012 09:11, Jörg Schaible  
 wrote:
> Hi Elijah,
>
> Elijah Zupancic wrote:
>
>> Thanks Jörg!
>>
>> It sounds like we will need to change them all in chain because we
>> have changed the package name.
>
> Well, since they are all different objects now, the Java runtime will 
> not
> try to match them anyway, so it is for this special case not really
> required.

 +1


> However, if you consider a change, I'd like to propose to use 
> everywhere
> a constant that reflects the day of change:
>
> servialVersionUID = 20120724L; // format MMDD
>
> It's easier then to keep track of changes.

 +0

 Ideally the svuid is only changed when necessary.
 I don't think the id should be updated just because a new method was
 added, or code was updated.

 The danger with using the date is that maintainers may update the id
 whenever the source is updated.
>>>
>>> I did not say that.
>>
>> I know; but the fact that the id is a date may (mis)lead maintainers
>> into updating it too often.
>>
>> If we do decide to use the day, maybe it should have a comment such as:
>>
>> // MMDD date of last change to serialized form.
>>
>>> - Jörg
>>>
>
> Since the serialized form will never change without a release, the
> svuid could also be aligned to the component version.

 Yes, but the same issue applies: it may not be necessary to change the
 svuid for each new version.
 This is particularly true of patch releases.

>>>
>>>I really don't see an issue here. People who have commit access know
>>>what they do and their commits get reviewed by the ML. People who
>>>don't have commit access will get a double review. First from the
>>>person who applies a patch and then from the ML. I like Jörgs approach
>>>(and I have adopted it for my work).
>>>
>>>Benedikt
>>
>> Hi all,
>>
>>
>> I'm no specialist in Java serialization, but I have one question (that may 
>> be stupid so I apologize in advance :-) about using a date as svuid.
>>
>>
>> Say that someone from Japan (GMT +9) commits a class to [functor] using 
>> svuid 20120727 at 00:30 AM. Then some 12 hours later I (based in Brazil, GMT 
>> -3) find a bug in his class, modify a field or move the class to some other 
>> package.
>>
>>
>> Then I would have to update the svuid, but as in my current timezone the 
>> svuid is 20120727 too, I would have to take some action, like waiting until 
>> the next day, increase the time precision (+ timezone?) or ask here in the 
>> mailing list for help. What would be the correct action in situations like 
>> this?
>>
>>
>> And as I'm very lazy, I really like using the Eclipse feature to generate 
>> the svuid automagically (I believe it uses JDK serialver tool), but with 
>> some practice I could get used to using any other standard adopted by a 

Re: [chain2] configuration façade APIs

[Simone Tripodi]

Hi all [chain2] people,

looks like what we have in /trunk is good already to cut a first RC -
anyway I would like to spur all involved people to be more "visionary"
and do more work now :P

Just to put more food for thoughts, for the configuration side: I
would like to invite you on evaluating the Jackson[1] library wich is
natively JSON and now supports data binding for more formats[2], XML,
YAML and Smile included!
Hopefully, with Jackson we could get rif of the Digester and have a
universal underlying parser wich supports more formats... how does it
sound? Maybe we won't need multiple config submodules anymore!

About licensing, Jackson is available under ALv2.

This is something that worths investigate - WDYT?

all the best, have a nice day!
-Simo

[1] http://wiki.fasterxml.com/JacksonHome
[2] http://www.cowtowncoder.com/blog/archives/2012/04/entry_472.html

http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/


On Fri, Jul 27, 2012 at 3:55 AM, Elijah Zupancic  wrote:
> For this particular project I would rather take the approach of writing a
> [configuration] based configuration and then extending [configuration]  to
> support other formats.
>
> -Elijah
>
> On Thursday, July 26, 2012, Simone Tripodi wrote:
>
>> Hi Oliver,
>>
>> we are on the same path!!! I had the idea of realizing an "universal"
>> parser (XML/JSON/YAML/INI) just writing XML readers adapters :)
>>
>> good thought!
>> -Simo
>>
>> http://people.apache.org/~simonetripodi/
>> http://simonetripodi.livejournal.com/
>> http://twitter.com/simonetripodi
>> http://www.99soft.org/
>>
>>
>> On Thu, Jul 26, 2012 at 9:37 PM, Oliver Heger
>>  wrote:
>> > Slightly off-topic:
>> >
>> > Do you think the following approach could work: Consider there is a
>> central
>> > component - e.g. [flatfile] in sandbox - which implements parsers for
>> > various text-base formats like YAML, JSON, CSV, ... and a generic
>> mechanism
>> > for transforming the parsed data into XML SAX events. Then in theory it
>> > would be possible that all XML-based Commons components like [digester],
>> > [configuration], or [jelly] could directly read such formats.
>> >
>> > WDYT?
>> > Oliver
>> >
>> > Am 26.07.2012 16:10, schrieb Simone Tripodi:
>> >
>> >> Good!
>> >>
>> >> hopefully Bruno can provide some help/advice to Elijah!
>> >>
>> >> Thanks,
>> >> -Simo
>> >>
>> >> http://people.apache.org/~simonetripodi/
>> >> http://simonetripodi.livejournal.com/
>> >> http://twitter.com/simonetripodi
>> >> http://www.99soft.org/
>> >>
>> >>
>> >> On Thu, Jul 26, 2012 at 3:43 PM, Bruno P. Kinoshita
>> >>  wrote:
>> >>>
>> >>> +1
>> >>>
>> >>> I used SnakeYaml in a project [1] that parses TAP test streams and in
>> >>> some Jenkins plug-ins, and had a look at the source code too. It works
>> very
>> >>> well with the latest YAML spec and the source code is very neat and
>> with
>> >>> many tests.
>> >>>
>> >>> TestNG uses SnakeYaml for parsing YAML configuration of test suites too
>> >>> [2].
>> >>>
>> >>> [1] http://www.tap4j.org
>> >>> [2] https://github.com/cbeust/testng/blob/master/pom.xml#L124
>> >>>
>> >>> Bruno P. Kinoshita
>> >>> http://kinoshita.eti.br
>> >>> http://tupilabs.com
>> >>>
>> >>>> 
>> >>>> From: Simone Tripodi 
>> >>>> To: Commons Developers List 
>> >>>> Sent: Thursday, 26 July 2012 4:58 AM
>> >>>> Subject: Re: [chain2] configuration façade APIs
>> >>>>
>> >>>>> I may draft up a prototype using YAML as a configuration source, just
>> >>>>> to make sure that it in fact is a good abstraction. I noticed that
>> the
>> >>>>> SnakeYaml parser is under the Apache 2.0 license
>> >>>>> (http://code.google.com/p/snakeyaml/). I'm assuming that it wouldn't
>> >>>>> be a problem to take it as a dependency.
>> >>>>
>> >>>>
>> >>>> +1!
>> >>>>
>> >>>> -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

[chain2] configuration façade APIs - followup

[Simone Tripodi]

Hi Elijah/all,

I just checked out latest modifications to see the changes - well done
and thanks for leading that! - I have few questions:

 * the main façade is a little "obscure" to me - how the parser
returns the Catalog/Chain to Parser clients? Would it be useful adding
a method (or modify the current parse() signature) to get the built
object? I maybe missed something, can we clarify?

 * would it be useful adding a parser factory á-la slf4j?

 * what about reorganizing the configuration stuff in the following dirs:

configuration
├── api
├── xml\
...
└── yaml

? if you agree I can quickly take care of it, it is a matter of minutes

TIA, 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

Re: [chain2] configuration façade APIs - followup

[Simone Tripodi]

Hi Elijah,

thanks a lot for the prompt feedback! I will start just moving the
modules (don't think that this deserves an issue) than will fill
issues for new tasks - and feel free to submit code!!!

Thanks a lot!
-Simo

http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/


On Fri, Jul 27, 2012 at 3:55 PM, Elijah Zupancic  wrote:
> Simo,
>
> I love ALL of those ideas. It took me quite a bit of time to get to
> where we are now and I considered it a first draft that we would then
> refactor from. So, yes please!
>
> -Elijah
>
> On Fri, Jul 27, 2012 at 4:16 AM, Simone Tripodi
>  wrote:
>> Hi Elijah/all,
>>
>> I just checked out latest modifications to see the changes - well done
>> and thanks for leading that! - I have few questions:
>>
>>  * the main façade is a little "obscure" to me - how the parser
>> returns the Catalog/Chain to Parser clients? Would it be useful adding
>> a method (or modify the current parse() signature) to get the built
>> object? I maybe missed something, can we clarify?
>>
>>  * would it be useful adding a parser factory á-la slf4j?
>>
>>  * what about reorganizing the configuration stuff in the following dirs:
>>
>> configuration
>> ├── api
>> ├── xml\
>> ...
>> └── yaml
>>
>> ? if you agree I can quickly take care of it, it is a matter of minutes
>>
>> TIA, 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
>>
>
>
>
> --
> -Elijah
>
> -
> 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

[chain2] ChainConfigurationException?

[Simone Tripodi]

Hi Elijah,

I think something went wrong during the refactoring - when tried to
recompile, the core module fails for the following reason:

[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-compiler-plugin:2.3.2:compile
(default-compile) on project commons-chain2-core: Compilation failure
[ERROR] 
/commons-chain/core/src/main/java/org/apache/commons/chain2/ChainConfigurationException.java:[43,8]
cannot find symbol
[ERROR] symbol  : constructor
RuntimeException(java.lang.String,java.lang.Throwable,boolean,boolean)
[ERROR] location: class java.lang.RuntimeException

Moreover: shouldn't the ChainConfigurationException class be moved in
the configuration APIs module?

TIA!
-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

Re: svn commit: r1366299 - /commons/proper/functor/trunk/src/changes/changes.xml

[Simone Tripodi]

agreed!!!

I will rearrange them, thanks!

-Simo

http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/


On Sat, Jul 28, 2012 at 4:36 AM, sebb  wrote:
> On 27 July 2012 08:33,   wrote:
>> Author: simonetripodi
>> Date: Fri Jul 27 07:33:14 2012
>> New Revision: 1366299
>>
>> URL: http://svn.apache.org/viewvc?rev=1366299&view=rev
>> Log:
>> reorganized issues to follow the DESC order
>
>> Modified:
>> commons/proper/functor/trunk/src/changes/changes.xml
>>
>> Modified: commons/proper/functor/trunk/src/changes/changes.xml
>> URL: 
>> http://svn.apache.org/viewvc/commons/proper/functor/trunk/src/changes/changes.xml?rev=1366299&r1=1366298&r2=1366299&view=diff
>> ==
>> --- commons/proper/functor/trunk/src/changes/changes.xml (original)
>> +++ commons/proper/functor/trunk/src/changes/changes.xml Fri Jul 27 07:33:14 
>> 2012
>> @@ -26,9 +26,6 @@
>>
>>  Generify ComparableComparator.
>>
>> -  
>> -Reduce the use of raw types in test classes.
>> -  
>>
>>  Fix NPE in UnarySequence.
>>
>> @@ -62,6 +59,9 @@
>>
>>  Add easily accessible, user-friendly examples
>>
>> +  
>> +Reduce the use of raw types in test classes.
>> +  
>
> By the way, having the issue attribute first makes the order very
> clear in Eclipse overviews as it displays the first attribute.
>
> For example:
>
> 
>
> Also, the issue type should really be specified - the  type
> attribute can be add,update,fix,remove.
>
>>
>>  Improve Functor web page, removing Ant from building
>>
>>
>>
>
> -
> 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: [chain2] ChainConfigurationException?

[Simone Tripodi]

great, thanks! :)

-Simo

http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/


On Sat, Jul 28, 2012 at 7:18 AM, Elijah Zupancic  wrote:
> It should be fixed in 1366598.
>
> Thanks,
> -Elijah
>
> On Fri, Jul 27, 2012 at 10:13 PM, Elijah Zupancic  wrote:
>> Bingo. Just ran the build with the 1.6 jdk and I get the failure.
>> Attempting to fix now.
>>
>> Thanks,
>> -Elijah
>>
>> On Fri, Jul 27, 2012 at 7:20 PM, Elijah Zupancic  wrote:
>>> Hi Simon,
>>>
>>> I don't know what went wrong. I've been using the Jdk 1.7 with maven 3.0.4
>>> and it has been building many times for me. I must have missed something. I
>>> won't be able to work on it for another couple of hours.
>>>
>>> As for the ChainConfigurationException, my thought was that it should be a
>>> more generic exception and not limited to the configuration modules. What
>>> are your thoughts?
>>>
>>> Thanks,
>>> -Elijah
>>>
>>>
>>> On Friday, July 27, 2012, Simone Tripodi wrote:
>>>>
>>>> Hi Elijah,
>>>>
>>>> I think something went wrong during the refactoring - when tried to
>>>> recompile, the core module fails for the following reason:
>>>>
>>>> [ERROR] Failed to execute goal
>>>> org.apache.maven.plugins:maven-compiler-plugin:2.3.2:compile
>>>> (default-compile) on project commons-chain2-core: Compilation failure
>>>> [ERROR]
>>>> /commons-chain/core/src/main/java/org/apache/commons/chain2/ChainConfigurationException.java:[43,8]
>>>> cannot find symbol
>>>> [ERROR] symbol  : constructor
>>>> RuntimeException(java.lang.String,java.lang.Throwable,boolean,boolean)
>>>> [ERROR] location: class java.lang.RuntimeException
>>>>
>>>> Moreover: shouldn't the ChainConfigurationException class be moved in
>>>> the configuration APIs module?
>>>>
>>>> TIA!
>>>> -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

Re: [chain2] ChainConfigurationException?

[Simone Tripodi]

the build works like a charm now, anyway I am still confused about the
nature of this exception: it is thrown by the
CatalogueFactory#checkForValidConfigurationModule() method wich checks
the ConfiggParser in the current classloader...

All that looks like a Matrioska[1] - I _think_ we can drop that method
from the factory, move the ChainConfigurationException in the
config-api module, and revamp the parser adding a ConfigParserFactory
á-la slf4j...

thoughts?
TIA and have a nice weekend!
-Simo

[1] http://www.piattinicinesi.com/wp-content/uploads/2010/01/matrioska.jpg

http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/


On Sat, Jul 28, 2012 at 8:21 AM, Simone Tripodi
 wrote:
> great, thanks! :)
>
> -Simo
>
> http://people.apache.org/~simonetripodi/
> http://simonetripodi.livejournal.com/
> http://twitter.com/simonetripodi
> http://www.99soft.org/
>
>
> On Sat, Jul 28, 2012 at 7:18 AM, Elijah Zupancic  wrote:
>> It should be fixed in 1366598.
>>
>> Thanks,
>> -Elijah
>>
>> On Fri, Jul 27, 2012 at 10:13 PM, Elijah Zupancic  wrote:
>>> Bingo. Just ran the build with the 1.6 jdk and I get the failure.
>>> Attempting to fix now.
>>>
>>> Thanks,
>>> -Elijah
>>>
>>> On Fri, Jul 27, 2012 at 7:20 PM, Elijah Zupancic  wrote:
>>>> Hi Simon,
>>>>
>>>> I don't know what went wrong. I've been using the Jdk 1.7 with maven 3.0.4
>>>> and it has been building many times for me. I must have missed something. I
>>>> won't be able to work on it for another couple of hours.
>>>>
>>>> As for the ChainConfigurationException, my thought was that it should be a
>>>> more generic exception and not limited to the configuration modules. What
>>>> are your thoughts?
>>>>
>>>> Thanks,
>>>> -Elijah
>>>>
>>>>
>>>> On Friday, July 27, 2012, Simone Tripodi wrote:
>>>>>
>>>>> Hi Elijah,
>>>>>
>>>>> I think something went wrong during the refactoring - when tried to
>>>>> recompile, the core module fails for the following reason:
>>>>>
>>>>> [ERROR] Failed to execute goal
>>>>> org.apache.maven.plugins:maven-compiler-plugin:2.3.2:compile
>>>>> (default-compile) on project commons-chain2-core: Compilation failure
>>>>> [ERROR]
>>>>> /commons-chain/core/src/main/java/org/apache/commons/chain2/ChainConfigurationException.java:[43,8]
>>>>> cannot find symbol
>>>>> [ERROR] symbol  : constructor
>>>>> RuntimeException(java.lang.String,java.lang.Throwable,boolean,boolean)
>>>>> [ERROR] location: class java.lang.RuntimeException
>>>>>
>>>>> Moreover: shouldn't the ChainConfigurationException class be moved in
>>>>> the configuration APIs module?
>>>>>
>>>>> TIA!
>>>>> -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

Re: Trie data structure

[Simone Tripodi]

Hi Tom!

Sandbox is open to all ASF committers, and you as Member should not
have issues on getting the access :) Moreover, [graph] is hungry and
greedy, I'd would be more than pleased if you could contribute that
code!!

I am taking care of requesting you access to the Sandbox, stay tuned!
-Simo

http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/


On Wed, Aug 1, 2012 at 8:48 AM, Tommaso Teofili
 wrote:
> Hi all,
>
> recently I've been working on implementing the Trie [1] data structure for
> fast retrieval given a prefix thus, since I've now a first prototype
> implementation, I was wondering if Apache Commons would be interested in
> that as a possible contribution.
> Thanks in advance and have a nice day,
>
> Tommaso
>
>
> [1] : http://en.wikipedia.org/wiki/Trie

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [graph] renaming packages

[Simone Tripodi]

Hi Claudio!

happy to read from you here :)

I just noticed that the weight/primitives sub-package contains classes
which name convention refers to *Weight - WDYT renaming them to
*SumMonoid ?

best and TIA!
-Simo

http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/


On Thu, Aug 2, 2012 at 12:45 AM,   wrote:
> Hi Simone!
>
> Both changes sound good to me. You are more familiar than me with
> "builder" so I trust your word; and also "s/weight/math" sounds indeed
> more appropriate given the general purpose classes that it contains.
>
> Cheers
> Claudio
>
>> Hi all grap-ers,
>>
>> I am doing the n-th review on [graph] and noticed small things could
>> be improved, such as 2 packages names that IMHO could be improved:
>>
>>  * s/builder/connect: nothing that really reflects the builder
>> pattern, rather a small EDSL to describe graph element connections;
>>
>>  * s/weight/math: Monoid and derivates sounds more familiar to a
>> generic math domain rather than pure weighted edges on graph.
>>
>> WDYT?
>> If there are no objections, I am going to apply that change.
>>
>> 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
>>
>>
>
>
> -
> This email was sent using SquirrelMail.
> https://email.dia.uniroma3.it
> Web Site: http://www.squirrelmail.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: [graph] renaming packages

[Simone Tripodi]

¡Hola!

> Also remember that if we ever want to deal with, say, multiplications,
> monoids are only going to be in the way (we already touched this topic
> before, see [1]). I'm still happy to update and simplify names, only
> following a different pattern: e.g. from "DoubleWeightBaseOperations" to
> "DoubleOperations". And I'd also replace "Monoid" with "Addition".

yeah thanks of the reminder - I was searching for it in the mail
archives and didn't find it :P

wouldn't "Multiplication" have exactly the same methods signature of
"Addition" aka Monoid? I wouldn't replicate stuff just to implement
markers...
Anyway I agree that algorithms need specific monoids, such as Dijkstra
that needs Addition - guess it wouldn't work with Subtractions :P

What about having Monoid with package visibility and then
"Addition/Multiplication... extends Monoid" ?

> After thinking a bit I'm also a bit perplexed about renaming "builder" to
> "connect", and in general about the name of the method "connect()". You
> know the meaning of "connected" in graph theory, while with our method we
> could actually create a graph which is not connected (e.g. one with no
> edges at all).

agreed!

> So I suggest to look for a less ambiguous alternative:
> "populate" (this gets my vote)? "declare"? "construct"? "assemble"?

+1 to "populate" (and related class renaming?)

thanks a lot for your feedbacks and enjoy vacations!
-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

Re: [graph] renaming packages

[Simone Tripodi]

!Hola!

> Addition would have signatures like "sum" and "negate", while Multiplication
> would have "multiply" and "invert".
>> What about having Monoid with package visibility and then
>> "Addition/Multiplication... extends Monoid" ?
>
>
> Then it would become a bit painless if a class had to implement both
> interfaces (the current "Integer[...]Operations" is an example). I'd just
> have them fully independent from each other, without a common ancestor
> (Monoid).

OK we have an agreement here :) I'll prepare a patch and attach to an
issue to let you review before applying it.

> cool. Class name = "GraphPopulator"? Though it sounds sooo bad to my ears...
> Maybe a mother tongue can help us with the matter :-)

agreed :) Any suggestion? TIA!!!

-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

[chain2] ServiceLoader in Chain2 to load Jackson supported formats

[Simone Tripodi]

Hi all guys,

I am prototyping the Jackson support as described in CHAIN-76 and
found an elegant solution with ServiceLoader to support, via Jackson,
multiple format support without hardcoding them in the ConfigParser
code but rather loading available parsers at runtime.

Since [chain2] hasn't been published yet and my prototype would
require an API which is not available on Java5, we have 3 options:

 * using the [discovery] component

 * using a backport[1] component I wrote time ago for java5 (it's ALv2)

 * upgrade to java6

The second option sounds to me the more reasonable since uses java
standard APIs and is Java6 compatible, while keeping Java5 backward
compatibility...

WDYT?
Many thanks in advance, all the best!
-Simo

[1] http://99soft.github.com/backport-spi/

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

Re: [chain2] ServiceLoader in Chain2 to load Jackson supported formats

[Simone Tripodi]

Democracy wins, long live Java6! :)

thanks for the feedbacks!

-Simo

http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/


On Mon, Aug 6, 2012 at 6:08 PM, Matt Benson  wrote:
> +1 for Java 6 as well.
>
> Matt
>
> On Mon, Aug 6, 2012 at 10:59 AM, James Carman
>  wrote:
>> +1 to upgrade to Java 6.
>>
>> On Mon, Aug 6, 2012 at 11:13 AM, Simone Tripodi
>>  wrote:
>>> Hi all guys,
>>>
>>> I am prototyping the Jackson support as described in CHAIN-76 and
>>> found an elegant solution with ServiceLoader to support, via Jackson,
>>> multiple format support without hardcoding them in the ConfigParser
>>> code but rather loading available parsers at runtime.
>>>
>>> Since [chain2] hasn't been published yet and my prototype would
>>> require an API which is not available on Java5, we have 3 options:
>>>
>>>  * using the [discovery] component
>>>
>>>  * using a backport[1] component I wrote time ago for java5 (it's ALv2)
>>>
>>>  * upgrade to java6
>>>
>>> The second option sounds to me the more reasonable since uses java
>>> standard APIs and is Java6 compatible, while keeping Java5 backward
>>> compatibility...
>>>
>>> WDYT?
>>> Many thanks in advance, all the best!
>>> -Simo
>>>
>>> [1] http://99soft.github.com/backport-spi/
>>>
>>> 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: Proposal Commons-JNDI

[Simone Tripodi]

+1

long time ago I was looking for something similar and didn't find
anything useful, full support from my side!

best,
-Simo

http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/


On Wed, Aug 8, 2012 at 8:02 AM, Jochen Wiedmann
 wrote:
> Hi,
>
> I'd like to propose a new component Commons JNDI for the sandbox.
>
> The aim would be to have a very lightweight JNDI implementation (no
> server, or something like that) that's not necessarily suitable for
> production, but ideally suited for use in test suites, and the like.
> For example, commons dbcp might use this to verify configuration via
> JNDI. The new implementation ought to be driven by property, XML, or
> JSON files.
> Possible starting points:
>
> - Import Simple JNDI, which already comes very close to the target.
> Henri Yandell, one of the Simple JNDI authors has given his agreement.
> - Import Tomcat JNDI, no contact with the Tomcat developers exists on
> that topic.
>
>
> WDYT?
>
> Jochen
>
> --
> In other words: what could be seen as a socially debilitating failure
> of character can certainly work to your advantage too. (Linus
> Torvalds, but the use in the signature tells something about me as
> well.)
>
> -
> 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: Proposal Commons-JNDI

[Simone Tripodi]

> Ever looked at simple-jndi? Now located at
> http://code.google.com/p/osjava/wiki/SimpleJNDI

nice for the immediate usage, thanks!

I continue supporting Jochen's proposal anyway, having a real
community driven developed component would be a benefit, IMHO.

my 2 cents,
-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

Re: svn commit: r1370883 - in /commons/proper/dbutils/trunk/src: main/java/org/apache/commons/dbutils/ test/java/org/apache/commons/dbutils/

[Simone Tripodi]

Hi Bill!

good, but the @since tag is missing on new methods!

HTH, best,
-Simo

http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/


On Wed, Aug 8, 2012 at 8:47 PM,   wrote:
> Author: wspeirs
> Date: Wed Aug  8 18:47:36 2012
> New Revision: 1370883
>
> URL: http://svn.apache.org/viewvc?rev=1370883&view=rev
> Log:
> - Applied patches from DBUTILS-87 to add insert methods
>
> Modified:
> 
> commons/proper/dbutils/trunk/src/main/java/org/apache/commons/dbutils/AsyncQueryRunner.java
> 
> commons/proper/dbutils/trunk/src/main/java/org/apache/commons/dbutils/QueryRunner.java
> 
> commons/proper/dbutils/trunk/src/test/java/org/apache/commons/dbutils/AsyncQueryRunnerTest.java
> 
> commons/proper/dbutils/trunk/src/test/java/org/apache/commons/dbutils/QueryRunnerTest.java
>
> Modified: 
> commons/proper/dbutils/trunk/src/main/java/org/apache/commons/dbutils/AsyncQueryRunner.java
> URL: 
> http://svn.apache.org/viewvc/commons/proper/dbutils/trunk/src/main/java/org/apache/commons/dbutils/AsyncQueryRunner.java?rev=1370883&r1=1370882&r2=1370883&view=diff
> ==
> --- 
> commons/proper/dbutils/trunk/src/main/java/org/apache/commons/dbutils/AsyncQueryRunner.java
>  (original)
> +++ 
> commons/proper/dbutils/trunk/src/main/java/org/apache/commons/dbutils/AsyncQueryRunner.java
>  Wed Aug  8 18:47:36 2012
> @@ -552,4 +552,65 @@ public class AsyncQueryRunner extends Ab
>  });
>  }
>
> +/**
> + * Executes {@link QueryRunner#insert(String, ResultSetHandler)} 
> asynchronously.
> + *
> + * @see QueryRunner#insert(String, ResultSetHandler)
> + */
> +public  Future insert(final String sql, final ResultSetHandler 
> rsh) throws SQLException {
> +   return executorService.submit(new Callable() {
> +
> +   @Override
> +   public T call() throws Exception {
> +   return queryRunner.insert(sql, rsh);
> +   }
> +
> +   });
> +}
> +
> +/**
> + * Executes {@link QueryRunner#insert(String, ResultSetHandler, 
> Object...)} asynchronously.
> + *
> + * @see QueryRunner#insert(String, ResultSetHandler, Object...)
> + */
> +public  Future insert(final String sql, final ResultSetHandler 
> rsh, final Object... params) throws SQLException {
> +   return executorService.submit(new Callable() {
> +
> +   @Override
> +   public T call() throws Exception {
> +   return queryRunner.insert(sql, rsh, params);
> +   }
> +   });
> +}
> +
> +/**
> + * Executes {@link QueryRunner#insert(Connection, String, 
> ResultSetHandler)} asynchronously.
> + *
> + * @see QueryRunner#insert(Connection, String, ResultSetHandler)
> + */
> +public  Future insert(final Connection conn, final String sql, 
> final ResultSetHandler rsh) throws SQLException {
> +   return executorService.submit(new Callable() {
> +
> +   @Override
> +   public T call() throws Exception {
> +   return queryRunner.insert(conn, sql, rsh);
> +   }
> +   });
> +}
> +
> +/**
> + * Executes {@link QueryRunner#insert(Connection, String, 
> ResultSetHandler, Object...)} asynchronously.
> + *
> + * @see QueryRunner#insert(Connection, String, ResultSetHandler, 
> Object...)
> + */
> +public  Future insert(final Connection conn, final String sql, 
> final ResultSetHandler rsh, final Object... params) throws SQLException {
> +   return executorService.submit(new Callable() {
> +
> +   @Override
> +   public T call() throws Exception {
> +   return queryRunner.insert(conn, sql, rsh, params);
> +   }
> +   });
> +}
> +
>  }
>
> Modified: 
> commons/proper/dbutils/trunk/src/main/java/org/apache/commons/dbutils/QueryRunner.java
> URL: 
> http://svn.apache.org/viewvc/commons/proper/dbutils/trunk/src/main/java/org/apache/commons/dbutils/QueryRunner.java?rev=1370883&r1=1370882&r2=1370883&view=diff
> ==
> --- 
> commons/proper/dbutils/trunk/src/main/java/org/apache/commons/dbutils/QueryRunner.java
>  (original)
> +++ 
> commons/proper/dbutils/trunk/src/main/java/org/apache/commons/dbutils/QueryRunner.java
>  Wed Aug  8 18:47:36 2012
> @@ -20,6 +20,7 @@ import java.sql.Connection;
>  import java.sql.PreparedStatement;
>  import java.sql.ResultSet;
>  import java.sql.SQLException;
> +import java.sql.Statement;
>
>  import javax.sql.DataSource;
>
> @@ -498,5 +499,60 @@ public class QueryRunner extends Abstrac
>
>  return rows;
>  }
> +
> +public  T insert(String sql, ResultSetHandler rsh) throws 
> SQLException {
> +return insert(this.prepareConnection(), true, sql, rsh, (Object[]) 
> null);
> +}
> +
> +public  T insert(String sql, ResultSetHand

Re: svn commit: r1370919 - /commons/proper/functor/trunk/src/test/java/org/apache/commons/functor/example/QuicksortExample.java

[Simone Tripodi]

Hi Matt!

wouldn't something like

> +public abstract  E evaluate(E head, List tail);

work?

best,
-Simo

http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/


On Wed, Aug 8, 2012 at 9:50 PM,   wrote:
> Author: mbenson
> Date: Wed Aug  8 19:50:46 2012
> New Revision: 1370919
>
> URL: http://svn.apache.org/viewvc?rev=1370919&view=rev
> Log:
> make sure all generic signatures match; eclipse was seemingly compiling in 
> such a way that method calls with casting were not routing properly
>
> Modified:
> 
> commons/proper/functor/trunk/src/test/java/org/apache/commons/functor/example/QuicksortExample.java
>
> Modified: 
> commons/proper/functor/trunk/src/test/java/org/apache/commons/functor/example/QuicksortExample.java
> URL: 
> http://svn.apache.org/viewvc/commons/proper/functor/trunk/src/test/java/org/apache/commons/functor/example/QuicksortExample.java?rev=1370919&r1=1370918&r2=1370919&view=diff
> ==
> --- 
> commons/proper/functor/trunk/src/test/java/org/apache/commons/functor/example/QuicksortExample.java
>  (original)
> +++ 
> commons/proper/functor/trunk/src/test/java/org/apache/commons/functor/example/QuicksortExample.java
>  Wed Aug  8 19:50:46 2012
> @@ -411,7 +411,7 @@ public class QuicksortExample {
>   */
>
>  public abstract class ObjectListFunction implements 
> BinaryFunction {
> -public abstract Object evaluate(Object head, List tail);
> +public abstract Object evaluate(Object head, List tail);
>
>  public Object evaluate(Object left, Object right) {
>  if (left != null && right instanceof List) {
> @@ -462,7 +462,7 @@ public class QuicksortExample {
>  @SuppressWarnings("rawtypes")
>  private BinaryFunction lesserTail = new 
> ObjectListFunction() {
>  @Override
> -public Object evaluate(Object head, List tail) {
> +public Object evaluate(Object head, List tail) {
>  return new FilteredGenerator(
>  IteratorToGeneratorAdapter.adapt(tail.iterator()),
>  IsLessThan.instance((Comparable) 
> head)).toCollection();
> @@ -477,7 +477,7 @@ public class QuicksortExample {
>  @SuppressWarnings("rawtypes")
>  private BinaryFunction greaterTail = new ObjectListFunction() {
>  @Override
> -public Object evaluate(Object head, List tail) {
> +public Object evaluate(Object head, List tail) {
>  return new FilteredGenerator(
>  IteratorToGeneratorAdapter.adapt(tail.iterator()),
>   IsGreaterThanOrEqual.instance((Comparable) 
> head)).toCollection();
>
>

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [configuration] Preparations for a new release

[Simone Tripodi]

Hi Oliver,

the same happened for DbUtils, I suggest you to send a ping to
@repository, they usually monitor the ML better than assigned issues.

HTH, alles gute!
-Simo

http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/


On Wed, Aug 8, 2012 at 9:48 PM, Oliver Heger
 wrote:
> Am 31.07.2012 21:30, schrieb Oliver Heger:
>>
>> Just a heads up: I plan to get out a 1.9 release with what we currently
>> have in trunk soon.
>>
>> Then I would like to switch to 2.0-SNAPSHOT in trunk, mainly to update
>> the [lang] dependency to 3.x (which is a binary incompatible change).
>> This has been requested multiple times. Therefore, it would be good if
>> the 2.0 release would not take too long. So a major refactoring is
>> probably not possible, but we can do some cleanup and see how far we
>> get. How does this sound?
>>
>> If you want some stuff included in 1.9, please speak up.
>>
>
> fyi, the preparation of the first RC currently hangs because I am unable to
> deploy to Nexus. Probably Nexus has to be setup to allow the
> commons-configuration groupId. I created a ticket [1], but there was no
> response yet.
>
> Oliver
>
> [1] https://issues.apache.org/jira/browse/INFRA-5115
>
>
> -
> 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: [configuration] Preparations for a new release

[Simone Tripodi]

> Done. Thanks for the tip!

you are welcome, hope they will quickly fix the issue!

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

Re: [BeanUtils2] WeakHashMap is not a cache (?)

[Simone Tripodi]

guten morgen Bene,

I have not a strong opinion about it, I am convinced anyway that the
original BU authors (BU2 at the beginning was a tentative to refurbish
BU) adopted the WeakHashMap NOT with the purpose of implementing a
`cache` in the strict sense we are used to. We should go back to the
ML history and find related discussions about it to understand that
decision.

If we need to switch implementation, in Apache Cocoon we developed a
simple LRU cache hacking the LinkedHashMap, we could import and adapt
that version - it would be better keeping BU2 dependencies-less.

Thanks,
-Simo

[1] http://s.apache.org/9zN

http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/


On Mon, Aug 13, 2012 at 1:11 PM, Benedikt Ritter  wrote:
> Hi,
>
> I just came across this post:
> http://www.codeinstructions.com/2008/09/weakhashmap-is-not-cache-understanding.html
> Now i'm wondering what you think about it, since we are using the
> WeakHashMap for BU2. Maybe we should be looking for an alternative
> caching mechanism?
> Any suggestions?
>
> Best regards,
> Benedikt
>
> -
> 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: [BeanUtils2] WeakHashMap is not a cache (?)

[Simone Tripodi]

Hi Adrian,

any direct link? TIA!
-Simo

http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/


On Mon, Aug 13, 2012 at 3:19 PM, Adrian Crum
 wrote:
> Apache OFBiz has a soft reference cache implementation.
>
> -Adrian
>
>
> On 8/13/2012 1:07 PM, Simone Tripodi wrote:
>>
>> guten morgen Bene,
>>
>> I have not a strong opinion about it, I am convinced anyway that the
>> original BU authors (BU2 at the beginning was a tentative to refurbish
>> BU) adopted the WeakHashMap NOT with the purpose of implementing a
>> `cache` in the strict sense we are used to. We should go back to the
>> ML history and find related discussions about it to understand that
>> decision.
>>
>> If we need to switch implementation, in Apache Cocoon we developed a
>> simple LRU cache hacking the LinkedHashMap, we could import and adapt
>> that version - it would be better keeping BU2 dependencies-less.
>>
>> Thanks,
>> -Simo
>>
>> [1] http://s.apache.org/9zN
>>
>> http://people.apache.org/~simonetripodi/
>> http://simonetripodi.livejournal.com/
>> http://twitter.com/simonetripodi
>> http://www.99soft.org/
>>
>>
>> On Mon, Aug 13, 2012 at 1:11 PM, Benedikt Ritter 
>> wrote:
>>>
>>> Hi,
>>>
>>> I just came across this post:
>>>
>>> http://www.codeinstructions.com/2008/09/weakhashmap-is-not-cache-understanding.html
>>> Now i'm wondering what you think about it, since we are using the
>>> WeakHashMap for BU2. Maybe we should be looking for an alternative
>>> caching mechanism?
>>> Any suggestions?
>>>
>>> Best regards,
>>> Benedikt
>>>
>>> -
>>> 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: [BeanUtils2] Working on mapped properties

[Simone Tripodi]

Hi Bene,

sounds a good plan, go for it and we'll follow up the discussion once
applying the the patch.

TIA,
-Simo

http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/


On Mon, Aug 13, 2012 at 9:47 PM, Benedikt Ritter  wrote:
> Hi all,
>
> I've started work on mapped properties and just want to be sure, that
> I'm going in the right direction.
> I've had a look at BU1 and found the MappedPropertyDescirptor class.
> Now my plan is to adapt that class to BU2 and use it to build up the
> functionality needed to handle mapped properties. I'll also copy
> related test classes.
> After that the DefaultBeanProperties class has to be extended so that
> it can handle mapped properties.
>
> Any comments?
>
> Regards,
> Benedikt
>
> -
> 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: [ALL] Deployment of component builds to Maven repo

[Simone Tripodi]

> Are any of the above definitely NOT going to make another release
> using the same groupId?

commons-discovery I think is one of these

> This could be because:
> [X] the component is dormant, or
> [ ]  future releases will use a groupId of o.a.c (and change package name!).

no more reasons to maintain a feature already provided by the JDK, and
the latest released works nicely in Java5, IMHO.

thanks for the followup!
-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

Re: [all] displaying some class and sequence diagrams for our components

[Simone Tripodi]

> Hm, I did not realize that this was not an automatic tool. Looks like a
> pain to maintain when you are doing refactorings...

ouch :(

I support/like anyway the idea of adding UML diagrams on doc site - I
requested time ago an OSS license for Objectaid [1] for Eclipse, but
never got a reply...

Maybe contacting them via members@ would be better?

best,
-Simo

[1] http://www.objectaid.com/

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

Re: [all] displaying some class and sequence diagrams for our components

[Simone Tripodi]

Hi Gary!

> I still like the idea! I was hoping at an automagic solution ;)

Me too! :)

The only kind of "automagic" product I found was Objectaid for
Eclipse, but unfortunately

 * it is (was, at the time of experimenting) not possible to have that
tool included in the build;

 * it is specific IDE oriented (Eclipse)

 * it requires a minimum of human-interaction - automatically arranged
layout could suck

 * it is not completely free - license expires :( I tried to contact
them to obtain a license for OSS projects only, but did not success...

This is a sample[1] a made for an assignment - it looks pretty good :P

best,
-Simo

[1] http://simonetripodi.github.com/shs/images/http-apis.png

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

Re: [all] displaying some class and sequence diagrams for our components

[Simone Tripodi]

Salut,

>
> Sorry, I don't think so. There are too many things in this diagram, we
> don't know what the use links are for, the complete list of enumeration
> constants is too large ...
>

you maybe missed that this tool is configurable as well[1] so you can
exclude what you're not interested.
For my assignment purpose, I had to give the complete set of info to
reviewers - lucky me you were not in the reviewers team :P

> So I understand this point of view is clearly not shared and I will
> therefore not include these diagrams in the documentation.
>

Why? Including diagrams in the doc should not find consensus in the
huge commons community - just for the record, I expressed an opinion
not an objection nor a veto - but decision should be delegated to
single component i.e. [math] people should be free to add diagrams if
they like, even if other components don't - take [pool] as a
reference, they decided to drop them recently, but they had been
included class/sequence for ages!

> best regards,
> Luc
>

best,
-Simo

[1] http://www.objectaid.com/class-diagram

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

Re: [pool][dbcp] POOL-229 (move AbandonedObjectPool to pool)

[Simone Tripodi]

Hi Phil,

FWIW the patch looks good on [pool] side - apologize but I have no
knowledge on [dbcp] internals.

best,
-Simo

http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/


On Wed, Aug 22, 2012 at 2:51 PM, Phil Steitz  wrote:
> Any feedback on the patch?  Should I go ahead and apply the [pool]
> patch?
>
> Phil
>
> -
> 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: [site] yet another proposal on how to restyle the commons site

[Simone Tripodi]

Salut Luc,

> These are good news. Would we be able with this setting to go to svnpubsub?

yes they will work, skin and SCM publishing are unrelated stuff -
Olivier Lamy, which is also commons committer, already did the job for
Apache DirectMemory via a new mvn plugin called scm-publish, hopefully
we can provide us a guideline.

I will invite him to publicly explain us how to manage the SvnPubSub.

Thanks!
-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

Re: [site] yet another proposal on how to restyle the commons site

[Simone Tripodi]

Hi all!

>> - I find the slider gadget thingy disconcerting. I do not know that it will
>> slide, I thought it was a bug and that the other components were missing
>> (see above). Then, poof!, it does slide. I would not use it so prominently
>> if at all.

table restored, more work on the carousel could improve the l'n'f IMHO
but let's back to the roots first :)

>> - Does not look good on my iPhone. The main issue is that the top menu bar
>> takes up a third of the screen. We need to consider mobile IMO.
>
> Agreed.

unfortunately Twitter Bootstrap just provides a responsive design wich
adapts the "desktop" components to mobile phones - and they announced
in the ML they don't have any plan (yet?) to write  aport on the
mobile.

Fortunately, I can still provide you a sample with the "classic"
sidebar menu navigation - as shown in[1] - which should adapt better
on mobile phones. Can you please verify it?
TIA!

> There's no Apache or Apache Commons logo, presumably because these use
> relative links, and the images are missing.
> Could you add the directory so we can see what it would look like?
>

done!

At that point I'll be working on applying the skin on a component to
see how it looks like to show you, hopefully we will find an agreement
and definitively upgrade the commons site :P

Have a nice day, all the best!
-Simo

[1] http://people.apache.org/~simonetripodi/commons-sidebar/index.html

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

Re: [site] yet another proposal on how to restyle the commons site

[Simone Tripodi]

as a side note: I think we could upgrade also the commons logo itself
starting from an svg the ASF made available[1], unfortunately I am not
good with inkscape... :(

best,
-Simo

[1] http://www.apache.org/foundation/press/kit/

http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/


On Thu, Aug 30, 2012 at 9:33 PM, Simone Tripodi
 wrote:
> Hi all!
>
>>> - I find the slider gadget thingy disconcerting. I do not know that it will
>>> slide, I thought it was a bug and that the other components were missing
>>> (see above). Then, poof!, it does slide. I would not use it so prominently
>>> if at all.
>
> table restored, more work on the carousel could improve the l'n'f IMHO
> but let's back to the roots first :)
>
>>> - Does not look good on my iPhone. The main issue is that the top menu bar
>>> takes up a third of the screen. We need to consider mobile IMO.
>>
>> Agreed.
>
> unfortunately Twitter Bootstrap just provides a responsive design wich
> adapts the "desktop" components to mobile phones - and they announced
> in the ML they don't have any plan (yet?) to write  aport on the
> mobile.
>
> Fortunately, I can still provide you a sample with the "classic"
> sidebar menu navigation - as shown in[1] - which should adapt better
> on mobile phones. Can you please verify it?
> TIA!
>
>> There's no Apache or Apache Commons logo, presumably because these use
>> relative links, and the images are missing.
>> Could you add the directory so we can see what it would look like?
>>
>
> done!
>
> At that point I'll be working on applying the skin on a component to
> see how it looks like to show you, hopefully we will find an agreement
> and definitively upgrade the commons site :P
>
> Have a nice day, all the best!
> -Simo
>
> [1] http://people.apache.org/~simonetripodi/commons-sidebar/index.html
>
> 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

Re: [site] yet another proposal on how to restyle the commons site

[Simone Tripodi]

>> I've uploaded a screenshot of that page taken with my mobile [1].
>> Doesn't look to well, anything you can do about that?

:(

> Step 1: Make "Welcome to the Apache Commons" half its current font size.

yup, I have no more bullets in my gun that the one Gary suggested, I
just re-uploaded the site[1]

How does it look?
TIA,
-Simo

[1] http://people.apache.org/~simonetripodi/commons-sidebar/

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

Re: [site] yet another proposal on how to restyle the commons site

[Simone Tripodi]

Hi again,

Thanks to Christian Grobmeier, we also added the responsive bootstrap css.

I re-uploaded the site, can you please have a look at it?
TIA,
-Simo

http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/


On Fri, Aug 31, 2012 at 8:58 AM, Simone Tripodi
 wrote:
>>> I've uploaded a screenshot of that page taken with my mobile [1].
>>> Doesn't look to well, anything you can do about that?
>
> :(
>
>> Step 1: Make "Welcome to the Apache Commons" half its current font size.
>
> yup, I have no more bullets in my gun that the one Gary suggested, I
> just re-uploaded the site[1]
>
> How does it look?
> TIA,
> -Simo
>
> [1] http://people.apache.org/~simonetripodi/commons-sidebar/
>
> 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

Re: [site] yet another proposal on how to restyle the commons site

[Simone Tripodi]

Hi Bene,

please ignore the topbar navigator, sounds it won't in consideration.

danke,
-Simo

http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/


On Fri, Aug 31, 2012 at 2:51 PM, Benedikt Ritter  wrote:
> Hi again,
>
> on my mobile, the top navi does not fit into the horizontal space
> causing a line break. That will display "Components" and "Sandbox"
> above the header of the side bar. I'll upload a screenshot as soon as
> I'm at home.
>
> Great work, Simo!
>
> Benedikt
>
> PS: I liked the side scrolling widget from the first version :-)
>
> 2012/8/31 Gary Gregory :
>> So much better on the iPhone! Thanks Simo. I agree with Sebb's
>> comments. Well done.
>>
>> Gary
>>
>> On Aug 31, 2012, at 5:09, Simone Tripodi  wrote:
>>
>>> Hi again,
>>>
>>> Thanks to Christian Grobmeier, we also added the responsive bootstrap css.
>>>
>>> I re-uploaded the site, can you please have a look at it?
>>> TIA,
>>> -Simo
>>>
>>> http://people.apache.org/~simonetripodi/
>>> http://simonetripodi.livejournal.com/
>>> http://twitter.com/simonetripodi
>>> http://www.99soft.org/
>>>
>>>
>>> On Fri, Aug 31, 2012 at 8:58 AM, Simone Tripodi
>>>  wrote:
>>>>>> I've uploaded a screenshot of that page taken with my mobile [1].
>>>>>> Doesn't look to well, anything you can do about that?
>>>>
>>>> :(
>>>>
>>>>> Step 1: Make "Welcome to the Apache Commons" half its current font size.
>>>>
>>>> yup, I have no more bullets in my gun that the one Gary suggested, I
>>>> just re-uploaded the site[1]
>>>>
>>>> How does it look?
>>>> TIA,
>>>> -Simo
>>>>
>>>> [1] http://people.apache.org/~simonetripodi/commons-sidebar/
>>>>
>>>> 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: [ALL] Commons Parent 27?

[Simone Tripodi]

> "Release early, release often" works well here since there is no
> possibility of API breakage and faulty versions can just be ignored.

+1

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

Re: [site] yet another proposal on how to restyle the commons site

[Simone Tripodi]

Hi Ralph!

> Actually, I am not sure that the full listing of the components on the main 
> page even needs to be there.  If you click on "components" in the left nav 
> you get pretty much the same thing.  So I would prefer to see a much shorter 
> section on Commons Proper, perhaps with the same link in that text.
>

That is indeed the reason why I originally put the carousel in the
first attempt[1] rather than the complete list, but I reverted for the
purpose to achieve the general agreement to apply the skin

> Is this work in preparation for moving to the CMS?

That is the idea - new way to publish the site, new skin.

all the best,
-Simo

[1] http://people.apache.org/~simonetripodi/commons/

http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/


On Fri, Aug 31, 2012 at 6:30 PM, Ralph Goers  wrote:

>
> Ralph
>
>
> On Aug 31, 2012, at 3:28 AM, sebb wrote:
>
>> On 31 August 2012 10:09, Simone Tripodi  wrote:
>>> Hi again,
>>>
>>> Thanks to Christian Grobmeier, we also added the responsive bootstrap css.
>>>
>>> I re-uploaded the site, can you please have a look at it?
>>> TIA,
>>> -Simo
>>
>> Looks much better now; seems to contain all the required elements, and
>> they are easier to find than on the horizontal menu.
>> Compared with the present design, it does look cleaner.
>>
>> However the pages are considerably longer; it's a pity that the lhs
>> menu does not fit on the first page.
>>
>> I'm not sure it makes sense to add the Google and Facebook links, but
>> if they are present, they should both have hover text; only Google
>> does at present.
>> Also, the ApacheCon advert is more important to the ASF, and should
>> appear before them.
>> Can they appear horizontally aligned?
>>
>> The text font on the Commons logo now looks out of place (and the TM
>> is missing - wrong file used?), so at some point it would be sensible
>> to redo it.
>>
>> -
>> 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: [VOTE] Release Commons Codec 1.7-RC1

[Simone Tripodi]

Hi Gary,

how you manage the non-maven assemblies? I mean, if the vote passes,
you just download them from Nexus to the dist machine?

TIA,
-Simo

http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/


On Mon, Sep 10, 2012 at 3:59 PM, Gary Gregory  wrote:
> Hello All:
>
> This is a VOTE to release Commons Codec 1.7-RC1.
>
> Changes in this version include:
>
> New features:
> o CODEC-157:  DigestUtils: Add MD2 APIs. Thanks to ggregory.
> o CODEC-156:  DigestUtils: add APIs named after standard algorithm name
> SHA-1. Thanks to ggregory.
> o CODEC-155:  DigestUtils.getDigest(String) should throw
> IllegalArgumentException instead of RuntimeException. Thanks to ggregory.
> o CODEC-153:  Create a class MessageDigestAlgorithms to define standard
> algorithm names. Thanks to ggregory.
> o CODEC-152:  DigestUtils.getDigest(String) loses the original exception.
> Thanks to ggregory.
> o CODEC-151:  Remove unnecessary attempt to fill up the salt variable in
> UnixCrypt. Thanks to lathspell.
> o CODEC-150:  Remove unnecessary call to Math.abs(). Thanks to lathspell.
> o CODEC-148:  More tests and minor things. Thanks to lathspell.
> o CODEC-146:  Added regression tests for PhoneticEngine based on
> Solr-3.6.0. Thanks to Julius Davies.
> o CODEC-139:  DigestUtils: add updateDigest methods and make methods
> public. Thanks to dsebastien.
> o CODEC-133:  Add classes for MD5/SHA1/SHA-512-based Unix crypt(3) hash
> variants. Thanks to lathspell.
> o CODEC-130:  Base64InputStream.skip skips underlying stream, not output.
> Thanks to tn.
> o CODEC-63:   Implement NYSIIS phonetic encoder. Thanks to bayard.
>
> Fixed Bugs:
> o CODEC-96:   Base64 encode() method is no longer thread-safe, breaking
> clients using it as a shared BinaryEncoder.
>   Note: the fix breaks binary compatibility, however the
> changes are to a class (BaseNCodec) which is
>   intended for internal use. Thanks to sebb.
> o CODEC-138:  Complete FilterInputStream interface for
> BaseNCodecInputStream.
> o CODEC-136:  Use Charset objects when possible, create Charsets for
> required character encodings.
> o CODEC-132:  BeiderMorseEncoder OOM issues. Thanks to rcmuir.
> o CODEC-131:  DoubleMetaphone javadoc contains dead links. Thanks to smolav.
>
> Changes:
> o CODEC-147:  BeiderMorseEncoder/PhoneticEngine: make results deterministic
> by using a LinkedHashSet
>   instead of a HashSet.
> o CODEC-143:  StringBuffer could be replaced by StringBuilder for local
> variables.
>
>
> Known issue only on IBM Java 5:
>
> ---
> Test set: org.apache.commons.codec.binary.Base64InputStreamTest
> ---
> Tests run: 15, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.287 sec
> <<< FAILURE!
> testInputStreamReader(org.apache.commons.codec.binary.Base64InputStreamTest)
> Time elapsed: 0.004 sec  <<< ERROR!
> sun.io.MalformedInputException
>at sun.io.ByteToCharUTF8.convert(ByteToCharUTF8.java:310)
>at
> sun.nio.cs.StreamDecoder$ConverterSD.convertInto(StreamDecoder.java:316)
>at
> sun.nio.cs.StreamDecoder$ConverterSD.implRead(StreamDecoder.java:366)
>at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:252)
>at java.io.InputStreamReader.read(InputStreamReader.java:212)
>at java.io.BufferedReader.fill(BufferedReader.java:157)
>at java.io.BufferedReader.readLine(BufferedReader.java:320)
>at java.io.BufferedReader.readLine(BufferedReader.java:383)
>at
> org.apache.commons.codec.binary.Base64InputStreamTest.testInputStreamReader(Base64InputStreamTest.java:110)
> ---
> $ java -version
> java version "1.5.0"
> Java(TM) 2 Runtime Environment, Standard Edition (build pxa64devifx-20110627
> (SR12 FP5 ))
> IBM J9 VM (build 2.3, J2RE 1.5.0 IBM J9 2.3 Linux amd64-64
> j9vmxa6423ifx-20110624 (JIT enabled)
> J9VM - 20110623_85457_LHdSMr
> JIT  - 20100623_16197ifx10_r8
> GC   - FP22011_06)
> JCL  - 20110627
> ---
>
> This VOTE is open for at least 72 hours until September 13 2012 at 10:00 AM
> EST.
>
> The files:
>
> https://repository.apache.org/content/repositories/orgapachecommons-046/
>
> The tag:
>
> https://svn.apache.org/repos/asf/commons/proper/codec/tags/1.7-RC1
>
> The site:
>
> https://people.apache.org/builds/commons/commons-codec/1.7/RC1/
>
> Note that the JIRA report is empty and it is a known issue in the Maven
> JIRA plugin and that requires a new plugin version.
>
> Thank you,
> Gary Gregory
>
> --
> 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

Re: [VOTE] Release Commons Codec 1.7-RC1

[Simone Tripodi]

Hi again Gary,

Not a blocker at all, but

 * RAT plugin shows Sha2CryptTest class does not have the ALv2 license header;

 * question: Clirr plugin shows some breakage, they all look like
"internal stuff", did you discuss about these breakage? Apologize but
I didn't follow the [codec] thread;

Trivial:

 * CPD shows some code redundancies - arrays initialization can be
safely ignored, maybe redundant code invocations could be improved

 * a couple of minor findbugs[4] notification.

I repeat, not blocker at all, but maybe the RAT issue worths another
RC, since what e really release at ASF are sources.

+1 anyway and thanks a lot for cutting the RC!
all the best,
-Simo

[1] 
https://people.apache.org/builds/commons/commons-codec/1.7/RC1/rat-report.html
[2] 
https://people.apache.org/builds/commons/commons-codec/1.7/RC1/clirr-report.html
[3] https://people.apache.org/builds/commons/commons-codec/1.7/RC1/cpd.html
[4] https://people.apache.org/builds/commons/commons-codec/1.7/RC1/findbugs.html

http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/


On Mon, Sep 10, 2012 at 5:14 PM, Gary Gregory  wrote:
> On Mon, Sep 10, 2012 at 10:36 AM, Simone Tripodi
> wrote:
>
>> Hi Gary,
>>
>> how you manage the non-maven assemblies? I mean, if the vote passes,
>> you just download them from Nexus to the dist machine?
>>
>
> Yes, the process is manual.
>
> Gary
>
>>
>> TIA,
>> -Simo
>>
>> http://people.apache.org/~simonetripodi/
>> http://simonetripodi.livejournal.com/
>> http://twitter.com/simonetripodi
>> http://www.99soft.org/
>>
>>
>> On Mon, Sep 10, 2012 at 3:59 PM, Gary Gregory  wrote:
>> > Hello All:
>> >
>> > This is a VOTE to release Commons Codec 1.7-RC1.
>> >
>> > Changes in this version include:
>> >
>> > New features:
>> > o CODEC-157:  DigestUtils: Add MD2 APIs. Thanks to ggregory.
>> > o CODEC-156:  DigestUtils: add APIs named after standard algorithm name
>> > SHA-1. Thanks to ggregory.
>> > o CODEC-155:  DigestUtils.getDigest(String) should throw
>> > IllegalArgumentException instead of RuntimeException. Thanks to ggregory.
>> > o CODEC-153:  Create a class MessageDigestAlgorithms to define standard
>> > algorithm names. Thanks to ggregory.
>> > o CODEC-152:  DigestUtils.getDigest(String) loses the original exception.
>> > Thanks to ggregory.
>> > o CODEC-151:  Remove unnecessary attempt to fill up the salt variable in
>> > UnixCrypt. Thanks to lathspell.
>> > o CODEC-150:  Remove unnecessary call to Math.abs(). Thanks to lathspell.
>> > o CODEC-148:  More tests and minor things. Thanks to lathspell.
>> > o CODEC-146:  Added regression tests for PhoneticEngine based on
>> > Solr-3.6.0. Thanks to Julius Davies.
>> > o CODEC-139:  DigestUtils: add updateDigest methods and make methods
>> > public. Thanks to dsebastien.
>> > o CODEC-133:  Add classes for MD5/SHA1/SHA-512-based Unix crypt(3) hash
>> > variants. Thanks to lathspell.
>> > o CODEC-130:  Base64InputStream.skip skips underlying stream, not output.
>> > Thanks to tn.
>> > o CODEC-63:   Implement NYSIIS phonetic encoder. Thanks to bayard.
>> >
>> > Fixed Bugs:
>> > o CODEC-96:   Base64 encode() method is no longer thread-safe, breaking
>> > clients using it as a shared BinaryEncoder.
>> >   Note: the fix breaks binary compatibility, however the
>> > changes are to a class (BaseNCodec) which is
>> >   intended for internal use. Thanks to sebb.
>> > o CODEC-138:  Complete FilterInputStream interface for
>> > BaseNCodecInputStream.
>> > o CODEC-136:  Use Charset objects when possible, create Charsets for
>> > required character encodings.
>> > o CODEC-132:  BeiderMorseEncoder OOM issues. Thanks to rcmuir.
>> > o CODEC-131:  DoubleMetaphone javadoc contains dead links. Thanks to
>> smolav.
>> >
>> > Changes:
>> > o CODEC-147:  BeiderMorseEncoder/PhoneticEngine: make results
>> deterministic
>> > by using a LinkedHashSet
>> >   instead of a HashSet.
>> > o CODEC-143:  StringBuffer could be replaced by StringBuilder for local
>> > variables.
>> >
>> >
>> > Known issue only on IBM Java 5:
>> >
>> >
>> ---
>> > Test set: org.apache.commons.codec.binary.Base64InputStreamTest
>> >
>> 

Re: [CSV] Release status?

[Simone Tripodi]

>> Any agreement (or objection) on changing that?
>
> Why? CSV is an acronym and as such capital letters are OK.

I remember a thread where we discussed about that, unfortunately I
cannot find it anymore (quickly tried a little on markmail but with no
success) - not sure we arrived somewhere - but I remember there where
two "schools of thought" about it: I personally prefer the Gary's one,
i.e. XmlParser rather than XMLParser.

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

Re: [VOTE] Release Commons Codec 1.7-RC2

[Simone Tripodi]

+1

http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/


On Tue, Sep 11, 2012 at 2:26 PM, Gary Gregory  wrote:
> Hello All:
>
> This is a VOTE to release Commons Codec 1.7-RC2.
>
> The differences with RC1 are:
>
> - Added missing ASF header to Sha2CryptTest.java
> - Fixed failing tests on IBM JVM and removed related release notes
> documentation.
> - Changes in changes.xml.
> - Added JRE requirement to release notes.
>
> Commons Codec 1.7 requires a minimum of Java 1.6
>
> Changes in this version include:
>
> New features:
> o CODEC-157:  DigestUtils: Add MD2 APIs. Thanks to ggregory.
> o CODEC-156:  DigestUtils: add APIs named after standard algorithm name
> SHA-1. Thanks to ggregory.
> o CODEC-155:  DigestUtils.getDigest(String) should throw
> IllegalArgumentException instead of RuntimeException. Thanks to ggregory.
> o CODEC-153:  Create a class MessageDigestAlgorithms to define standard
> algorithm names. Thanks to ggregory.
> o CODEC-152:  DigestUtils.getDigest(String) loses the original exception.
> Thanks to ggregory.
> o CODEC-151:  Remove unnecessary attempt to fill up the salt variable in
> UnixCrypt. Thanks to lathspell.
> o CODEC-150:  Remove unnecessary call to Math.abs(). Thanks to lathspell.
> o CODEC-148:  More tests and minor things. Thanks to lathspell.
> o CODEC-146:  Added regression tests for PhoneticEngine based on
> Solr-3.6.0. Thanks to Julius Davies.
> o CODEC-139:  DigestUtils: add updateDigest methods and make methods
> public. Thanks to dsebastien.
> o CODEC-133:  Add classes for MD5/SHA1/SHA-512-based Unix crypt(3) hash
> variants. Thanks to lathspell.
> o CODEC-130:  Base64InputStream.skip skips underlying stream, not output.
> Thanks to tn.
> o CODEC-63:   Implement NYSIIS phonetic encoder. Thanks to bayard.
>
> Fixed Bugs:
> o CODEC-96:   Base64 encode() method is no longer thread-safe, breaking
> clients using it as a shared BinaryEncoder.
>   Note: the fix breaks binary compatibility, however the
> changes are to a class (BaseNCodec) which is
>   intended for internal use. Thanks to sebb.
> o CODEC-138:  Complete FilterInputStream interface for
> BaseNCodecInputStream.
> o CODEC-136:  Use Charset objects when possible, create Charsets for
> required character encodings.
> o CODEC-132:  BeiderMorseEncoder OOM issues. Thanks to rcmuir.
> o CODEC-131:  DoubleMetaphone javadoc contains dead links. Thanks to smolav.
>
> Changes:
> o CODEC-147:  BeiderMorseEncoder/PhoneticEngine: make results deterministic
> by using a LinkedHashSet
>   instead of a HashSet.
> o CODEC-143:  StringBuffer could be replaced by StringBuilder for local
> variables.
>
> This VOTE is open for at least 72 hours until September 14 2012 at 9:30 AM
> EST.
>
> The files:
>
> https://repository.apache.org/content/repositories/orgapachecommons-051/
>
> The tag:
>
> https://svn.apache.org/repos/asf/commons/proper/codec/tags/1.7-RC2
>
> The site:
>
> https://people.apache.org/builds/commons/commons-codec/1.7/RC2/
>
> Note that the JIRA report is empty and it is a known issue in the Maven
> JIRA plugin and that requires a new plugin version.
>
> Thank you,
> Gary Gregory
>
>
> --
> 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: [CSV] Release status?

[Simone Tripodi]

Guten morgen, Jörg!

> JDK has actually XMLWriter as well as XmlWriter :D
>

lol indeed, that's fun! :D

> However, since is more of a personal preference, I'd not set up any rule for
> all Apache commons components, we should just try to keep it consistent
> within a component.
>

+1, no doubts!

> While I know that Gary would like to finalize the API for 1.0 I'd personally
> find it annoying if I had to change code just because of a personal
> preference (using SNAPSHOTs of CVS for long times - and I bet I am not the
> only one using SNAPSHOTs after so much years this component is floating
> around). As long as it's consistent I'd simply keep it now.

agreed, at Apache Any23 we are using CVS SNAPSHOTs as well, that would
imply a refactory...

all the best!
-Simo

http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/


On Wed, Sep 12, 2012 at 11:24 AM, Jörg Schaible
 wrote:
> Hi Simo,
>
> Simone Tripodi wrote:
>
>>>> Any agreement (or objection) on changing that?
>>>
>>> Why? CSV is an acronym and as such capital letters are OK.
>>
>> I remember a thread where we discussed about that, unfortunately I
>> cannot find it anymore (quickly tried a little on markmail but with no
>> success) - not sure we arrived somewhere - but I remember there where
>> two "schools of thought" about it: I personally prefer the Gary's one,
>> i.e. XmlParser rather than XMLParser.
>
> JDK has actually XMLWriter as well as XmlWriter :D
>
> However, since is more of a personal preference, I'd not set up any rule for
> all Apache commons components, we should just try to keep it consistent
> within a component.
>
> While I know that Gary would like to finalize the API for 1.0 I'd personally
> find it annoying if I had to change code just because of a personal
> preference (using SNAPSHOTs of CVS for long times - and I bet I am not the
> only one using SNAPSHOTs after so much years this component is floating
> around). As long as it's consistent I'd simply keep it now.
>
> - Jörg
>
>
> -
> 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] apachecon

[Simone Tripodi]

I'll be there, I am giving a talk about some works we've done in
commons (and other ASF components)

glad to meet other commons people!

-Simo

http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/


On Tue, Sep 18, 2012 at 9:29 PM, Thomas Neidhart
 wrote:
> Hi,
>
> does anybody plan to go to ApacheCon 2012?
> Would be nice to meet each other there.
>
> Thomas
>
> -
> 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: [functor] Patch for FUNCTOR-14, new Generators and Ranges

[Simone Tripodi]

Olá Bruno,

excellent work, congrats!! I will have a look tonight (my local TZ)
I'll try to let you know ASAP!

thanks, all the best!
-Simo

http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/


On Wed, Sep 19, 2012 at 4:12 AM, Bruno P. Kinoshita
 wrote:
> Hi all,
>
> me again bringing a new implementation idea for the Generators API
>
> in [functor], and looking forward to some thoughts on this :-)
>
> There is a separate branch for this issue [1], and here's what has been done.
>
> - Split Generator interface into Generator interface and LoopGenerator
> (abstract class). IMO, this will help in modularization (see this discussion 
> [2])
> in the Generators API, as the stop() method and the wrapped generators,
> for instance, had been added because of the generators created for handling
> execution flow control (e.g.: GenerateWhile, UntilGenerate, etc).
>
> - Moved LoopGenerator and its implementations under the newly created
> org.apache.commons.functor.generator.loop package.
>
> - Moved IntegerRange and LongRange from 
> org.apache.commons.functor.generator.util to
> the newly created org.apache.commons.functor.generator.range package.
>
> - Created a Range API, with a Range interface, a Ranges helper interface and
> some implementations (including existing IntegerRange and LongRange, and new
> ones like DoubleRange, FloatRange and CharacterRange).
>
> - Added steps different than 1 to Ranges (not the generator interface, as this
> is related only to ranges).
>
> - The Ranges implemented are all Generators too, what is very convenient, as 
> you
> can use Ranges to both define intervals and/or execute a procedure for each 
> of its
> elements.
>
> I've wrote a sample code using the existing Generators API [3] and wrote the
> same code for the new Generators API [4]. The API is compatible, but as some
> packages changed, you have to update existing code (but as [functor] hasn't 
> been
> released yet, it shouldn't be a problem I believe :-). Both codes produce the
> same output too (0 1 2 3 4 5 6 7 8 9 ).
>
> And here's an example [5] of creating Ranges and using them as Generators. 
> More
> examples can be found in the tests for the Generator and the Range API's.
>
> I've updated the examples page and added tests. I've also updated the parent
> pom to 26, but as this is not related to the FUNCTOR-14 issue, we can drop 
> this
>
> part when merging the code.
>
> I'll merge the changes to trunk if everybody thinks this new implementation is
> better than the current one.
>
> A side note: PHP recently got generators too [6], and an interesting thing 
> that I noticed in
> their Wiki was the discussion about callback functions. After reading the
> discussion, for me it looks like [functor] generators API is more similar to
> callback handler. Differently than the Python and PHP implementations with the
> yield statement.
>
> Thank you in advance!
>
> [1] 
> https://svn.apache.org/repos/asf/commons/proper/functor/branches/generators-FUNCTOR-14
> [2] http://markmail.org/message/nymsk7l64aj4csxi
> [3] https://gist.github.com/3747204
> [4] https://gist.github.com/3747207
> [5] https://gist.github.com/3747224
> [5] https://wiki.php.net/rfc/generators
>
> Bruno P. Kinoshita
> http://kinoshita.eti.br
> http://tupilabs.com
>
>>
>> From: Matt Benson 
>>To: Bruno P. Kinoshita 
>>Cc: Commons Developers List 
>>Sent: Wednesday, 6 June 2012 9:56 AM
>>Subject: Re: [functor] Patch for FUNCTOR-14, new Generators and Ranges
>>
>>On Tue, Jun 5, 2012 at 11:48 PM, Bruno P. Kinoshita
>> wrote:
>>> Hi Matt,
>>>
>>>
 Would there be a type of Range that could not be turned into a
 Generator given a compatible Step parameter?  If not, we could define:

 interface Range  {
 ...
Generator  toGenerator(S step);
 }

 This way, Range itself does not contain a step, but still maintains
 control over how a step is used to create a generator.
>>>
>>> I can't think of any type that could not be turned into a generator given
>>> the step parameter. But if a range has no step, I think we would have to
>>> remove the isEmpty(), contains(), containsAll() methods from range
>>> implementations, as using steps higher than 1, we need to use the step value
>>> to check if a range is empty or contains a certain element (e.g.: integer
>>> range (1, 2], step 3, check if contains(2) or isEmpty()).
>>>
>>
>>My thought was that by decoupling a Range from a step, you use only
>>the bound types/values to determine inclusion of a given value.  If a
>>Generator is created from (1, 2] with step 3, then that Generator will
>>only return 1, but that doesn't reflect on the Range, IMO.
>>
>>Matt
>>
>>>
 Either way, I like the notion that a Range is its own type that just
 *happens* to either provide access to, or an implementation of,
 Generator.
>>>
>>> +1, let it provide access or be an impl

Re: [VFS] HDFS provider

[Simone Tripodi]

Hi Dave!

Welcome to commons! :)
What you are proposing makes a lot of sense IMHO! Unfortunately I am
not so familiar with VFS to review & apply your modifications, guess
it would be easier to do if you could provide a patch via JIRA.

Good luck and all the best!
-Simo

http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/


On Thu, Sep 20, 2012 at 4:04 AM,   wrote:
>
> I did not see a provider for HDFS on the list of supported file systems. I 
> created a read-only HDFS provider while working on an Accumulo ticket. I was 
> wondering if one of the devs had time to review to see if I made any glaring 
> mistakes. I am in the process of becoming an Accumulo committer, so I'm 
> assuming that this file system provider could be included in the VFS project 
> if it makes sense. Thanks,
>
> Dave Marion

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [lang] StrBuilder append(String, Object...)

[Simone Tripodi]

+1 very well thought, Gary!

even if StrBuilder would look like java.util.Formatter, I think that
this is a nice addition.

best,
-Simo

http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/


On Thu, Sep 20, 2012 at 11:12 PM, Gary Gregory  wrote:
> I just wrote this up for a different project and it seems like a nice add
> for StrBuilder:
>
> @Test
> public void testAppendFormatted_Object() {
> StrBuilder sb;
>
> sb = new StrBuilder();
> sb.append("Hi", "Alice");
> assertEquals("Hi", sb.toString());
>
> sb = new StrBuilder();
> sb.append("Hi %s", "Alice");
> assertEquals("Hi Alice", sb.toString());
>
> sb = new StrBuilder();
> sb.append("Hi %s %,d", "Alice", 5000);
> assertEquals("Hi Alice 5,000", sb.toString());
> }
>
> /**
>  * Appends an formatted string to this string builder.
>  * Appending null will call {@link #appendNull()}.
>  *
>  * @param format  the format string, see {@link String#format(String,
> Object...)}
>  * @param objs  the objects to use in the format string
>  * @return this, to enable chaining
>  */
> public StrBuilder append(String format, Object... objs) {
> if (objs == null) {
> return appendNull();
> }
> return append(String.format(format, objs));
> }
>
> Thoughts?
>
>
> --
> 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: svn commit: r1388495 - in /commons/proper/dbutils/trunk/src: changes/changes.xml main/java/org/apache/commons/dbutils/BaseResultSetHandler.java test/java/org/apache/commons/dbutils/BaseResultSetHa

[Simone Tripodi]

> There should be some samples of how to use the class, as it's not
> immediately obvious.

I will add them in the xdoc samples, thanks

-Simo

http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/


On Fri, Sep 21, 2012 at 4:50 PM, sebb  wrote:
> On 21 September 2012 14:59,   wrote:
>> Author: simonetripodi
>> Date: Fri Sep 21 13:59:46 2012
>> New Revision: 1388495
>>
>> URL: http://svn.apache.org/viewvc?rev=1388495&view=rev
>> Log:
>> [DBUTILS-97] Add an Abstract ResultSetHandler implementation in order to 
>> reduce redundant 'resultSet' variable invocation
>>
>> Added:
>> 
>> commons/proper/dbutils/trunk/src/main/java/org/apache/commons/dbutils/BaseResultSetHandler.java
>>(with props)
>> 
>> commons/proper/dbutils/trunk/src/test/java/org/apache/commons/dbutils/BaseResultSetHandlerTestCase.java
>>(with props)
>> Modified:
>> commons/proper/dbutils/trunk/src/changes/changes.xml
>>
>> Modified: commons/proper/dbutils/trunk/src/changes/changes.xml
>> URL: 
>> http://svn.apache.org/viewvc/commons/proper/dbutils/trunk/src/changes/changes.xml?rev=1388495&r1=1388494&r2=1388495&view=diff
>> ==
>> --- commons/proper/dbutils/trunk/src/changes/changes.xml (original)
>> +++ commons/proper/dbutils/trunk/src/changes/changes.xml Fri Sep 21 13:59:46 
>> 2012
>> @@ -47,6 +47,9 @@ The  type attribute can be add,u
>>> issue="DBUTILS-98">
>>  Add missing JavaDoc to QueryRunner#insert
>>
>> +  
>> +Add an Abstract ResultSetHandler implementation in order to reduce 
>> redundant 'resultSet' variable invocation
>> +  
>>> issue="DBUTILS-87">
>>  Added insert methods to QueryRunner and AsyncQueryRunner that 
>> return the generated key.
>>
>>
>> Added: 
>> commons/proper/dbutils/trunk/src/main/java/org/apache/commons/dbutils/BaseResultSetHandler.java
>> URL: 
>> http://svn.apache.org/viewvc/commons/proper/dbutils/trunk/src/main/java/org/apache/commons/dbutils/BaseResultSetHandler.java?rev=1388495&view=auto
>> ==
>> --- 
>> commons/proper/dbutils/trunk/src/main/java/org/apache/commons/dbutils/BaseResultSetHandler.java
>>  (added)
>> +++ 
>> commons/proper/dbutils/trunk/src/main/java/org/apache/commons/dbutils/BaseResultSetHandler.java
>>  Fri Sep 21 13:59:46 2012
>> @@ -0,0 +1,1969 @@
>> +/*
>> + * Licensed to the Apache Software Foundation (ASF) under one or more
>> + * contributor license agreements.  See the NOTICE file distributed with
>> + * this work for additional information regarding copyright ownership.
>> + * The ASF licenses this file to You under the Apache License, Version 2.0
>> + * (the "License"); you may not use this file except in compliance with
>> + * the License.  You may obtain a copy of the License at
>> + *
>> + *  http://www.apache.org/licenses/LICENSE-2.0
>> + *
>> + * Unless required by applicable law or agreed to in writing, software
>> + * distributed under the License is distributed on an "AS IS" BASIS,
>> + * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
>> + * See the License for the specific language governing permissions and
>> + * limitations under the License.
>> + */
>> +package org.apache.commons.dbutils;
>> +
>> +import java.io.InputStream;
>> +import java.io.Reader;
>> +import java.math.BigDecimal;
>> +import java.net.URL;
>> +import java.sql.Array;
>> +import java.sql.Blob;
>> +import java.sql.Clob;
>> +import java.sql.Date;
>> +import java.sql.NClob;
>> +import java.sql.Ref;
>> +import java.sql.ResultSet;
>> +import java.sql.ResultSetMetaData;
>> +import java.sql.RowId;
>> +import java.sql.SQLException;
>> +import java.sql.SQLWarning;
>> +import java.sql.SQLXML;
>> +import java.sql.Statement;
>> +import java.sql.Time;
>> +import java.sql.Timestamp;
>> +import java.util.Calendar;
>> +import java.util.Map;
>> +
>> +/**
>> + * Extensions of this class convert ResultSets into other objects.
>> + *
>> + * According to the DRY principle (Don't Repeat Yourself), repeating 
>> resultSet
>> + * variable inside the {@link ResultSetHandler#handle(ResultSet)} over and 
>> over for each iteration
>> + * can get a little tedious, AbstractResultSetHandler 
>> implicitly gives users access to
>> + * ResultSet's methods.
>> + *
>
> There should be some samples of how to use the class, as it's not
> immediately obvious.
>
> -
> 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: r1388495 - in /commons/proper/dbutils/trunk/src: changes/changes.xml main/java/org/apache/commons/dbutils/BaseResultSetHandler.java test/java/org/apache/commons/dbutils/BaseResultSetHa

[Simone Tripodi]

>> +/**
>> + * @param columnIndex
>> + * @param scale
>> + * @return
>> + * @throws SQLException
>> + * @deprecated
>> + * @see java.sql.ResultSet#getBigDecimal(int, int)
>> + */
>
> Why add a new class with already deprecated methods?
>

I was a little in trouble when adding it indeed, but since the
BaseResultSetHandler exposes ResultSet methods shortcut... why hiding
that one? :)

> If they are to be kept, then one needs to add the @Deprecated annotation.
>
> Also, the @deprecated Javadoc entry should state what to use instead.

sure, that are missing indeed, thanks

-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

Re: [cli2] Is this now a dormant project?

[Simone Tripodi]

Hi Duncan,

thanks a lot for your interest in commons!

CLI2 never left the Sandbox - where components are still in a
prototypal state - the Dormant place is for Proper components that
became... ehm, Dormant :P

I am not aware of commons committers still interested on CLI2, I tried
getting more involved but I moved to Cedric Beust's JCommander[1]
because of its simplified APIs via annotations. Once adopted it, I
felt without any motivation on maintaining CLI(2).

I hope someone else will join you on getting CLI(2) released, good luck!
best,
-Simo

[1] http://jcommander.org/

http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/


On Fri, Sep 21, 2012 at 9:33 PM, Duncan Jones  wrote:
> Hi,
>
> The last code submission to CLI2 was in April 2010. There are six
> issues open in the main CLI JIRA page (last update Nov 2011) and
> nothing I can find in the Sandbox JIRA.
>
> I'd like to help get a version of CLI2 (finally) released, but I'm
> concerned any such efforts would be in vein due to:
>
>  - a lack of clarity over what needs to be done before a release is feasible
>  - a fear that there would be nobody to commit supplied patches
>
> Is anyone out there interested in pursuing this project? If so, shall
> we aim to get moving and put a release out the door before the end of
> the year?
>
> (If not, should this be voted to move into the Dormant projects?)
>
> Duncan
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [cli2] Is this now a dormant project?

[Simone Tripodi]

> the Dormant place is for Proper components that
> became... ehm, Dormant :P

According to the Dormant page, looks like I asserted a wrong sentence
- apologize!

-Simo

http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/


On Fri, Sep 21, 2012 at 10:25 PM, Simone Tripodi
 wrote:
> Hi Duncan,
>
> thanks a lot for your interest in commons!
>
> CLI2 never left the Sandbox - where components are still in a
> prototypal state - the Dormant place is for Proper components that
> became... ehm, Dormant :P
>
> I am not aware of commons committers still interested on CLI2, I tried
> getting more involved but I moved to Cedric Beust's JCommander[1]
> because of its simplified APIs via annotations. Once adopted it, I
> felt without any motivation on maintaining CLI(2).
>
> I hope someone else will join you on getting CLI(2) released, good luck!
> best,
> -Simo
>
> [1] http://jcommander.org/
>
> http://people.apache.org/~simonetripodi/
> http://simonetripodi.livejournal.com/
> http://twitter.com/simonetripodi
> http://www.99soft.org/
>
>
> On Fri, Sep 21, 2012 at 9:33 PM, Duncan Jones  wrote:
>> Hi,
>>
>> The last code submission to CLI2 was in April 2010. There are six
>> issues open in the main CLI JIRA page (last update Nov 2011) and
>> nothing I can find in the Sandbox JIRA.
>>
>> I'd like to help get a version of CLI2 (finally) released, but I'm
>> concerned any such efforts would be in vein due to:
>>
>>  - a lack of clarity over what needs to be done before a release is feasible
>>  - a fear that there would be nobody to commit supplied patches
>>
>> Is anyone out there interested in pursuing this project? If so, shall
>> we aim to get moving and put a release out the door before the end of
>> the year?
>>
>> (If not, should this be voted to move into the Dormant projects?)
>>
>> Duncan
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> For additional commands, e-mail: dev-h...@commons.apache.org
>>

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [SCXML] ANN: scxml-viz, scion-shell, and scion-web-simulation-environment

[Simone Tripodi]

Hi Jake,

good work, well done! I suggest you to FWD that message also to the
users@ ML in order to get commons-scxml users interested.

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 Fri, Oct 5, 2012 at 4:54 AM, Jacob Beard  wrote:
> Hi,
>
> I have released three new projects which may be of interest to the SCXML
> Commons community:
>
>- scxml-viz : A library for
>visualizing SCXML documents.
>- scion-shell : A simple shell
>environment for the SCION SCXML interpreter. It accepts SCXML events via
>stdin, and thus can be used to integrate SCXML with Unix shell programming.
>It integrates scxml-viz, so can also allow graphical simulation of SCXML
>models.
>- 
> scion-web-simulation-environment:
>A simple proof-of-concept web sandbox environment for developing SCXML.
>Code can be entered on the left, and visualized on the right. Furthermore,
>SCION is integrated, so code can be simulated and graphically animated. A
>demo can be found here: http://goo.gl/wG5cq
>
> All projects are licensed under an Apache 2.0 license. I look forward to
> your comments. Thanks,
>
> Jake

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

[VOTE] Apache Commons as Sponsor for BeanShell in Incubator

[Simone Tripodi]

Hi all,

(following up the discussion from private@)

I prepared the BeanShell[1] proposal to be submitted to the ASF
incubator and, as already discussed time ago with interested people
and the original author, we agreed Commons should be the best place
for BeanShell where living.

So, I'm here to call for a vote for Commons PMC be the BeanShell
Sponsor, please cast your votes

[ ] +1
[ ] +/- 0
[ ] -1, because...

We already collected ten +1 votes from following PMCs:

 * Simone Tripodi
 * Sebb
 * Oliver Heger
 * Phil Steitz
 * Christian Grobmeier
 * Ralph Goers
 * Luc Maisonobe
 * Rony G. Flatscher
 * Jörg Schaible
 * Thomas Neidhart

PMCs that already expressed their vote don't need to express it again.

This vote is open for at least 72hours and will close on ~October 12th
at 01:00pm GMT

Many thanks in advance, have a nice day!
Simo

[1] http://wiki.apache.org/incubator/BeanShellProposal

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

[RESULT][VOTE] Apache Commons as Sponsor for BeanShell in Incubator

[Simone Tripodi]

Hi all,

more than 72 hours have passed and the VOTE can be considered closed
and passes with following resolution:

Thirteen +1 binding votes from following PMCs:

 * Simone Tripodi
 * Sebb
 * Oliver Heger
 * Phil Steitz
 * Christian Grobmeier
 * Ralph Goers
 * Luc Maisonobe
 * Rony G. Flatscher
 * Jörg Schaible
 * Thomas Neidhart
 * Gary Gregory
 * James Carman
 * Thomas Vandahl

No other votes have been casted.

So, the Commons PMC is sponsoring BeanShell to join the incubator!

Thanks everybody who took part to the VOTE, have a nice weekend!
All the best,
-Simo

http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/


On Tue, Oct 9, 2012 at 3:12 PM, Simone Tripodi  wrote:
> Hi all,
>
> (following up the discussion from private@)
>
> I prepared the BeanShell[1] proposal to be submitted to the ASF
> incubator and, as already discussed time ago with interested people
> and the original author, we agreed Commons should be the best place
> for BeanShell where living.
>
> So, I'm here to call for a vote for Commons PMC be the BeanShell
> Sponsor, please cast your votes
>
> [ ] +1
> [ ] +/- 0
> [ ] -1, because...
>
> We already collected ten +1 votes from following PMCs:
>
>  * Simone Tripodi
>  * Sebb
>  * Oliver Heger
>  * Phil Steitz
>  * Christian Grobmeier
>  * Ralph Goers
>  * Luc Maisonobe
>  * Rony G. Flatscher
>  * Jörg Schaible
>  * Thomas Neidhart
>
> PMCs that already expressed their vote don't need to express it again.
>
> This vote is open for at least 72hours and will close on ~October 12th
> at 01:00pm GMT
>
> Many thanks in advance, have a nice day!
> Simo
>
> [1] http://wiki.apache.org/incubator/BeanShellProposal
>
> 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

Re: [chain2] Release Status

[Simone Tripodi]

Hi Elijah!!

nice to hear back from you!

If I recall correctly, we discussed two main topics before cutting the
first Release Candidate:

1) we agreed on dropping the confusing CatalogFactory, or at least
making it more user friendly

2) parser APIs change - there is a prototype patch on CHAIN-76 which
aims to drop Digester and adopt Jackson, in order to support multiple
formats - you spoke about YAML format to describe Chains, Jackson
would dinamically supply it (I mean, without adding new code!).
In the meanwhile, I started contributing to jackson to fill missing
parts (that I had to add in my Chain patch). I have to take a look if
latest Jackson releases contain my contribution and give another try
in Chain - the proposed patch is anyway a little far to be completed,
so I'll need your help to get it done!

All the best, have a nice day!
-Simo

http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/


On Mon, Oct 15, 2012 at 11:25 PM, Elijah Zupancic  wrote:
> Hi Simo and everyone else,
>
> I'm working on a project that I would like to bring in the release
> version of chain2 rather than the snapshot. What other things do we
> need to finish up on in order for us to cut a release?
>
> Thanks,
> -Elijah
>
> -
> 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] CSVFormat API names

[Simone Tripodi]

+1 to Jörg, that would be my recommendation as well!

my 0.02 cents,
-Simo

http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/


On Tue, Oct 16, 2012 at 3:14 PM, Jörg Schaible
 wrote:
> Hi Gary,
>
> Gary Gregory wrote:
>
>> Hi All:
>>
>> The format object can configure various aspects of input and output
>> formatting.
>>
>> With my recent addition of the Quote enum for [CSV-53], there are now two
>> aspects of quoting to configure: the quote character and the quote policy
>> (minimal, all, non-numeric, and none.) FYI, 'none' is currently not
>> implemented.
>>
>> First, I changed (without consulting this list, and please accept my
>> apologies for this) the - IMO - cryptic and burdensome terminology of
>> "encapsulator" to "quote char", and added "quote policy":
>>
>> - withQuoteChar(char)
>> - withQuotePolicy(Quote)
>>
>> My intention here is that all Quote APIs start with "withQuote" followed
>> by what aspect of quoting is being configured.
>>
>> Alternatively, we could have:
>>
>> - withQuote(char)
>> - withQuotePolicy(Quote)
>
> or
>
> - withQuote(char)
> - withQuote(Quote)
>
> ;-)
>
>> Which makes the API more consistent with the other char/Character based
>> properties:
>>
>> - withEscape
>> - withDelimiter
>> - withLineSeparator
>> - withCommentStart
>>
>> none of the above are post-fixed with a "Char" in the name.
>>
>> As far as reading, for me, the "-r" names are OK because the they are
>> nouns (things): "a delimiter", "a line separator." But I do not talk about
>> "an escape" because that would be an act (think Alcatraz) as opposed to
>> what we have here: a character used to /perform/ escapes.
>>
>> So I propose to change "escape" to "escape char" because "escaper" is not
>> a word.
>>
>> The name "comment start" is not great also because it implies (to me) that
>> there is a "comment end" missing. So plain "comment" or "comment char"
>> would be better.
>
> Who said it has to be a single char?
>
> .withEOLComment("//")
>
>
> Same applies to the line separator:
>
> .withLineSeparator("\n\r")
>
>> Circling back to "quote char" which I have the way it is now for the same
>> reason as for the "escape" property.
>>
>> In summary, using *Char names is better IMO.
>
> Only if it can be a single char only. If it can either be a single char or a
> String, I normally tend to use overloaded methods:
>
> - withEOLComment(char)
> - withEOLComment(CharSequence)
>
>> Discuss! :)
>
> Can or worms opened :))
>
> - Jörg
>
>
> -
> 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: Retiring as Apache Commons Committer and PMC

[Simone Tripodi]

+1

http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/


On Thu, Nov 1, 2012 at 2:26 PM, James Carman  wrote:
> Luc, can we let him respond first?  If he decides to just "take a break" as
> opposed to officially resigning (or going emeritus), then we don't need to
> vote him back in and what not.
>
>
> On Thu, Nov 1, 2012 at 9:23 AM, Luc Maisonobe  wrote:
>
>> Le 01/11/2012 12:48, Siegfried Goeschl a écrit :
>> > Hi folks,
>>
>> Hi Siegfried,
>>
>> >
>> > due to some unwelcome changes in my private life I want/need to retire
>> > from most of my Apache activities - in this case
>> >
>> >  * Apache Commons Committer
>> >  * Apache Commons PMC
>>
>> I am really sorry to hear that. I wish you the best and hope you will
>> come back one day.
>>
>> >
>> > I enjoyed the time and hope someone will step up to further maintain
>> > commons-email and commons-exec
>> >
>> > Cheers,
>> >
>> > Siegfried Goeschl
>> > Former Release Candidate Manager
>> >
>> > PS: Luc - Any other actions I need to take
>>
>> No, don't worry. I'll notify board about PMC changes.
>>
>> best regards,
>> Luc
>>
>> >
>>
>>
>> -
>> 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: [digester3] javadoc style

[Simone Tripodi]

Hi Ivan!

great, thanks a lot for your patch on Digester, I'm having a look at it ASAP!

Nice to see an active contribution on that component, hope to read
more from you! :)

All the best,
-Simo

http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/


On Thu, Dec 6, 2012 at 6:05 PM, iwo.diana  wrote:
> I sent a patch for issue https://issues.apache.org/jira/browse/DIGESTER-173
> but I have some questions about javadoc style, can I use @see with external
> resource (like to standard jdk javadoc)?
>
>
>
> --
> View this message in context: 
> http://apache-commons.680414.n4.nabble.com/digester3-javadoc-style-tp4642938.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: [functor] Using [fucntor] functional interfaces with Java 8 lambdas

[Simone Tripodi]

AMAZING

congrats Bruno!
-Simo

http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/


On Fri, Dec 21, 2012 at 8:22 PM, Bruno P. Kinoshita
 wrote:
> Hi all,
>
> Just wanted to let you guys know that I am successfully compiling and 
> executing code using [functor] and Java 8. And am also using [functor] 
> functional interfaces with lambdas.
>
> So instead of writing:
>
>
> UnaryPredicate isEven = new UnaryPredicate() {
> public boolean test(Integer obj) {
> return obj % 2 == 0;
> }
> };
>
> One can simply write:
>
> UnaryPredicate isEven = (Integer obj) -> { return obj % 2 == 0; };
>
> FWIW, Google Guava's Predicate [1] is not a functional interface, so it 
> cannot be used with lambdas, as in the example above.
>
> I'll continue to experiment with [functor] and Java 8. There are only two 
> open issues in Jira, one regarding generators (there's a branch with a 
> proposal implementation) and another one about the equals() method in the 
> [functor] API.
>
> I wrote a short blog post [2] about how I'm running Java 8 in Eclipse Juno, 
> in case anyone is interested in trying it too. The code is hosted at GitHub 
> [3].
>
> Cheers,
>
> [1] 
> http://code.google.com/p/guava-libraries/source/browse/guava/src/com/google/common/base/Predicate.java
> [2] 
> http://www.kinoshita.eti.br/2012/12/21/using-apache-commons-functor-functional-interfaces-with-java-8-lambdas/
> [3] https://github.com/kinow/try-lambdas
> Bruno P. Kinoshita
> http://kinoshita.eti.br
> http://tupilabs.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

[digester] dropping the annotations-processor module

[Simone Tripodi]

Hi all guys!

the annotations-processor module in Digester has been in a prototypal
status for a long time and I haven't had time/chances to make it
working, so, since it has never been released before and I am busy as
heel and won't have the opportunity to work on it, unless someone
submits a patch to DIGESTER-158, I would be for dropping it and make
the build work (and possibly cut a release).

Any objection?
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

Re: [digester] dropping the annotations-processor module

[Simone Tripodi]

Hi Mark!

until v3.2 the Digester supported runtime annotations to generate the
XML parser - the idea was having a processor that generates the XML
parser at compile-time, but unfortunately I haven't had enough time to
continue working on it...
So, since it is even broken and still at the early stage, I propose to
drop it to cut soon a new release, and postpone it to new versions.

Does weaver enhances the class bytecode or even generate classes?

TIA,
-Simo

http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/


On Sat, Dec 22, 2012 at 10:45 AM, Mark Struberg  wrote:
> I have no clue what the annotation processing is for, but might that be a 
> candidate for the upcoming commons-weaver (formerly privilizer) ?
> It takes CLASS/RUNTIME annotations a modifies the bytecode in the class 
> directly.
>
> LieGrue,
> strub
>
>
>
>
> ----- Original Message -
>> From: Simone Tripodi 
>> To: Commons Developers List 
>> Cc:
>> Sent: Friday, December 21, 2012 10:48 PM
>> Subject: [digester] dropping the annotations-processor module
>>
>> Hi all guys!
>>
>> the annotations-processor module in Digester has been in a prototypal
>> status for a long time and I haven't had time/chances to make it
>> working, so, since it has never been released before and I am busy as
>> heel and won't have the opportunity to work on it, unless someone
>> submits a patch to DIGESTER-158, I would be for dropping it and make
>> the build work (and possibly cut a release).
>>
>> Any objection?
>> 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

Re: [digester] dropping the annotations-processor module

[Simone Tripodi]

thanks for the explanation, I'll have a look at it! :)

all the best,
-Simo

http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/


On Sat, Dec 22, 2012 at 2:19 PM, Mark Struberg  wrote:
>
>> Does weaver enhances the class bytecode or even generate classes?
>
> You could do both. Currently the only 'plugin' for the weaver is Matts 
> privilizer. This one only 'enhances' an existing class. But there is no 
> further restriction and I see no reason why you could not generate classes. 
> But please note that this classes are only available _after_ the compilation. 
> So they cannot (sanely) be referenced by any java source code.
>
> LieGrue,
> strub
>
>
>
> - Original Message -
>> From: Simone Tripodi 
>> To: Commons Developers List 
>> Cc:
>> Sent: Saturday, December 22, 2012 1:16 PM
>> Subject: Re: [digester] dropping the annotations-processor module
>>
>> Hi Mark!
>>
>> until v3.2 the Digester supported runtime annotations to generate the
>> XML parser - the idea was having a processor that generates the XML
>> parser at compile-time, but unfortunately I haven't had enough time to
>> continue working on it...
>> So, since it is even broken and still at the early stage, I propose to
>> drop it to cut soon a new release, and postpone it to new versions.
>>
>> Does weaver enhances the class bytecode or even generate classes?
>>
>> TIA,
>> -Simo
>>
>> http://people.apache.org/~simonetripodi/
>> http://simonetripodi.livejournal.com/
>> http://twitter.com/simonetripodi
>> http://www.99soft.org/
>>
>>
>> On Sat, Dec 22, 2012 at 10:45 AM, Mark Struberg  wrote:
>>>  I have no clue what the annotation processing is for, but might that be a
>> candidate for the upcoming commons-weaver (formerly privilizer) ?
>>>  It takes CLASS/RUNTIME annotations a modifies the bytecode in the class
>> directly.
>>>
>>>  LieGrue,
>>>  strub
>>>
>>>
>>>
>>>
>>>  - Original Message -
>>>>  From: Simone Tripodi 
>>>>  To: Commons Developers List 
>>>>  Cc:
>>>>  Sent: Friday, December 21, 2012 10:48 PM
>>>>  Subject: [digester] dropping the annotations-processor module
>>>>
>>>>  Hi all guys!
>>>>
>>>>  the annotations-processor module in Digester has been in a prototypal
>>>>  status for a long time and I haven't had time/chances to make
>> it
>>>>  working, so, since it has never been released before and I am busy as
>>>>  heel and won't have the opportunity to work on it, unless someone
>>>>  submits a patch to DIGESTER-158, I would be for dropping it and make
>>>>  the build work (and possibly cut a release).
>>>>
>>>>  Any objection?
>>>>  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
>

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [commons-parent] drop cobertura

[Simone Tripodi]

> or just move it to a profile?

+1

-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

Re: BeanShell?

[Simone Tripodi]

Hi mate,

we had two "blocking" issues:

 * we took a little to have signed SGA and ICLA;

 * BeanShell people is re-licensing the software under ALv2 on
apache-extras[1] before moving to Incubator.

I have a very low activity ATM, if someone else wants to step up and
championize the proposal I am ready to step down as a champion.

Any volunteer?
TIA,
-Simo

[1] http://code.google.com/a/apache-extras.org/p/beanshell/

http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/


On Wed, Jan 2, 2013 at 7:02 PM, Christian Grobmeier  wrote:
> Hi folks,
>
> before 2 or 3 months we have voted to let BeanShell come to Commons.
>
> There is this page:
> http://wiki.apache.org/incubator/BeanShellProposal
>
> But there was never a vote on the incubator list. Nor did I see any
> sign of life from the original authors. Actually it seems to me this
> project is not very active at all and it makes me feel concerned. We
> already have many inactive components at Commons. I was looking into
> the mailinglist archives of BeanShell and it does not look very active
> at all:
>
> https://sourceforge.net/mailarchive/forum.php?forum_id=6969
>
> I am start to doubt if we really should bring this project to Commons.
>
> Any thoughts? Maybe I am wrong and missed some important communication.
>
> Cheers
> Christian
>
>
>
> --
> http://www.grobmeier.de
> https://www.timeandbill.de
>
> -
> 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: [functor] Patch for FUNCTOR-14, new Generators and Ranges

[Simone Tripodi]

Hi Matt,

I had a quick look at your branch and I honestly think it is a very
good work, maybe we could insert even more modules granularization,
but IMHO it worths to merge it in the main branch.
Do you see any blocker?

Best and thanks!
-Simo

http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/


On Sun, Jan 27, 2013 at 6:39 PM, Matt Benson  wrote:
> All:  I have merged Bruno's work to
> https://svn.apache.org/repos/asf/commons/proper/functor/branches/FUNCTOR-14-mmbased
> on functor's multi-module reorg.
>
> Matt
>
>
> On Wed, Sep 19, 2012 at 2:12 AM, Simone Tripodi 
> wrote:
>
>> Olá Bruno,
>>
>> excellent work, congrats!! I will have a look tonight (my local TZ)
>> I'll try to let you know ASAP!
>>
>> thanks, all the best!
>> -Simo
>>
>> http://people.apache.org/~simonetripodi/
>> http://simonetripodi.livejournal.com/
>> http://twitter.com/simonetripodi
>> http://www.99soft.org/
>>
>>
>> On Wed, Sep 19, 2012 at 4:12 AM, Bruno P. Kinoshita
>>  wrote:
>> > Hi all,
>> >
>> > me again bringing a new implementation idea for the Generators API
>> >
>> > in [functor], and looking forward to some thoughts on this :-)
>> >
>> > There is a separate branch for this issue [1], and here's what has been
>> done.
>> >
>> > - Split Generator interface into Generator interface and LoopGenerator
>> > (abstract class). IMO, this will help in modularization (see this
>> discussion [2])
>> > in the Generators API, as the stop() method and the wrapped generators,
>> > for instance, had been added because of the generators created for
>> handling
>> > execution flow control (e.g.: GenerateWhile, UntilGenerate, etc).
>> >
>> > - Moved LoopGenerator and its implementations under the newly created
>> > org.apache.commons.functor.generator.loop package.
>> >
>> > - Moved IntegerRange and LongRange from
>> org.apache.commons.functor.generator.util to
>> > the newly created org.apache.commons.functor.generator.range package.
>> >
>> > - Created a Range API, with a Range interface, a Ranges helper interface
>> and
>> > some implementations (including existing IntegerRange and LongRange, and
>> new
>> > ones like DoubleRange, FloatRange and CharacterRange).
>> >
>> > - Added steps different than 1 to Ranges (not the generator interface,
>> as this
>> > is related only to ranges).
>> >
>> > - The Ranges implemented are all Generators too, what is very
>> convenient, as you
>> > can use Ranges to both define intervals and/or execute a procedure for
>> each of its
>> > elements.
>> >
>> > I've wrote a sample code using the existing Generators API [3] and wrote
>> the
>> > same code for the new Generators API [4]. The API is compatible, but as
>> some
>> > packages changed, you have to update existing code (but as [functor]
>> hasn't been
>> > released yet, it shouldn't be a problem I believe :-). Both codes
>> produce the
>> > same output too (0 1 2 3 4 5 6 7 8 9 ).
>> >
>> > And here's an example [5] of creating Ranges and using them as
>> Generators. More
>> > examples can be found in the tests for the Generator and the Range API's.
>> >
>> > I've updated the examples page and added tests. I've also updated the
>> parent
>> > pom to 26, but as this is not related to the FUNCTOR-14 issue, we can
>> drop this
>> >
>> > part when merging the code.
>> >
>> > I'll merge the changes to trunk if everybody thinks this new
>> implementation is
>> > better than the current one.
>> >
>> > A side note: PHP recently got generators too [6], and an interesting
>> thing that I noticed in
>> > their Wiki was the discussion about callback functions. After reading the
>> > discussion, for me it looks like [functor] generators API is more
>> similar to
>> > callback handler. Differently than the Python and PHP implementations
>> with the
>> > yield statement.
>> >
>> > Thank you in advance!
>> >
>> > [1]
>> https://svn.apache.org/repos/asf/commons/proper/functor/branches/generators-FUNCTOR-14
>> > [2] http://markmail.org/message/nymsk7l64aj4csxi
>> > [3] https://gist.github.com/3747204
>> > [4] https://gist.github.com/3747207
>&

Re: svn commit: r1441731 - /commons/sandbox/beanutils2/trunk/NOTICE.txt

[Simone Tripodi]

Guten Tag Bene,

> The API is completely new and was created bei Simone Tripodi [1].
> BeanUtils2 does however contain code extracted from BeanUtils1. So better
> use BeanUtils1's year of introduction?

don't think so, since we just got inspiration from some BU internals
but redesigned BU2.

alles gute,
-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

Re: svn commit: r1441784 - /commons/sandbox/beanutils2/trunk/src/main/java/org/apache/commons/beanutils2/PropertyDescriptorsRegistry.java

[Simone Tripodi]

> Better make it explicit that getBeanInfo is not a member of 
> PropertyDescriptorsRegistry

why

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

Re: svn commit: r1441784 - /commons/sandbox/beanutils2/trunk/src/main/java/org/apache/commons/beanutils2/PropertyDescriptorsRegistry.java

[Simone Tripodi]

Guten Tag, Bene,

> I personally try to avoid static imports.
> Especially when you come to a legacy code base IMHO it makes the code
> harder to understand.

as BU2 user, would you write the following sentence

on( testBean ).invoke( "setBooleanProperty" ).with( argument( new
Boolean( false ) ) );

as

BeanUtils.on( testBean ).invoke( "setBooleanProperty" ).with(
Argument.argument( new Boolean( false ) ) );

?

Better switching back to old BU APIs, there's no benefit anymore on
switching to a functional-style approach APIs.

> You always have to look, where a method comes from.

Isn't the same thing we have to do with classes? when using a List,
what ensures you are using java.util.List rather than java.awt.List?
Why you consider methods case so different to classes?

> Also you may have the problem, that you accidentally override imported
> static methods, when defining a new static method with the same name.

same name, same arguments and same return type? It would be possible.
But, again, that would be possible doing it also with classes, same
package and same name; as exercise, create a project and import
commons-beanutils-1.7.0 + commons-collections-3.2.1: which version of
FastHashMap is taken by the classloader?

I still haven't found the reason why methods should be a special case.

What I am sure, there's no rule.

my 0.0002 though,
-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

Re: svn commit: r1442739 - /commons/sandbox/beanutils2/trunk/src/main/java/org/apache/commons/beanutils2/ClassLoaderBuilder.java

[Simone Tripodi]

Guten Morgen,

> +/**
> + * Use a custom {@link ClassLoader} for loading the class.
> + *
> + * @param classLoader the {@link ClassLoader} to load the class.
> + * @return the {@link ClassAccessor} for the class being loaded.
> + */
>  ClassAccessor loadWithClassLoader( ClassLoader classLoader );

I think we can reduce this sentence to `loadWith( ClassLoader
classLoader )` since the ClassLoader is the object, WDYT?
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

Re: svn commit: r1441784 - /commons/sandbox/beanutils2/trunk/src/main/java/org/apache/commons/beanutils2/PropertyDescriptorsRegistry.java

[Simone Tripodi]

> Boolean.valueOf( false ) ) ); // or just valueOf( false )? ;-)

or just

import static Boolean.FALSE

then

on( testBean ).invoke( "setBooleanProperty" ).with( argument( FALSE ) );

which is less verbose and avoids the potential naming conflict.
-Simo

http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/


On Wed, Feb 6, 2013 at 10:16 AM, Benedikt Ritter  wrote:
> 2013/2/5 Benedikt Ritter 
>
>> Hi Simo,
>>
>>
>> 2013/2/5 Simone Tripodi 
>>
>>> Guten Tag, Bene,
>>>
>>> > I personally try to avoid static imports.
>>> > Especially when you come to a legacy code base IMHO it makes the code
>>> > harder to understand.
>>>
>>> as BU2 user, would you write the following sentence
>>>
>>> on( testBean ).invoke( "setBooleanProperty" ).with( argument( new
>>> Boolean( false ) ) );
>>>
>>> as
>>>
>>> BeanUtils.on( testBean ).invoke( "setBooleanProperty" ).with(
>>> Argument.argument( new Boolean( false ) ) );
>>>
>>> ?
>>>
>>> Better switching back to old BU APIs, there's no benefit anymore on
>>> switching to a functional-style approach APIs.
>>>
>>
>> As I said, I haven't decided yet how to handle static imports.
>> You're right, when pointing out, that not using static imports here is
>> more verbose. But IMHO BU2 is a step forward compared to BU1 even without
>> static imports! :)
>>
>> I personally would probably do something like:
>> BeanUtils.on( testBean ).invoke( "setBooleanProperty" ).with( argument(
>> Boolean.valueOf( false ) ) ); // or just valueOf( false )? ;-)
>>
>
> In fact the valueOf() factory methods in the wrapper types a a good example
> of where not to use static imports.
> WDYT?
>
>
>>
>> This way I can see what API I'm entering. For the call to
>> Argument.argument(T) I would use a static import, because it is clear what
>> context it is coming from. In fact, this is, how I use EasyMock at work. I
>> qualify calls to expect(), replay(), verify() etc but use static import
>> when using the factory methods for IExpectationSetters.
>>
>> Makes sense? Probably only to me :) See, it's just a convention I've found
>> useful for myself.
>>
>>
>>>
>>> > You always have to look, where a method comes from.
>>>
>>> Isn't the same thing we have to do with classes? when using a List,
>>> what ensures you are using java.util.List rather than java.awt.List?
>>> Why you consider methods case so different to classes?
>>>
>>
>> Your right. I'd normally try to import java.util.List, because it is the
>> most common List implementation and qualify java.awt.List if I have to use
>> both in the same class. But again this is only a convention I have made for
>> myself.
>>
>>
>>>
>>> > Also you may have the problem, that you accidentally override imported
>>> > static methods, when defining a new static method with the same name.
>>>
>>> same name, same arguments and same return type? It would be possible.
>>> But, again, that would be possible doing it also with classes, same
>>> package and same name; as exercise, create a project and import
>>> commons-beanutils-1.7.0 + commons-collections-3.2.1: which version of
>>> FastHashMap is taken by the classloader?
>>>
>>> I still haven't found the reason why methods should be a special case.
>>>
>>
>> I guess I'll just revert that commit and we'll see were it gets us.
>> Thanks for sharing your thoughts!
>>
>> Benedikt
>>
>>
>>>
>>> What I am sure, there's no rule.
>>>
>>> my 0.0002 though,
>>> -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

Re: svn commit: r1442739 - /commons/sandbox/beanutils2/trunk/src/main/java/org/apache/commons/beanutils2/ClassLoaderBuilder.java

[Simone Tripodi]

> Definitely a good idea. This is what we did for other parts of the API as
> well.

yup I didn't remember where/with who I discussed already that.

Please back everything with an issue and don't forget to include the
issue key in the commit message.

alles gute,
-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

Re: svn commit: r1442739 - /commons/sandbox/beanutils2/trunk/src/main/java/org/apache/commons/beanutils2/ClassLoaderBuilder.java

[Simone Tripodi]

> Haven't done that for implementation of setMapped(). Should I create an
> issue

That would be the always ideal case, so we have the complete
perspective of things we've worked on.

>  and at least add it to changes.xml?

Yes please, if you do have the time also to review past issues would be great.

alles gute,
-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

Re: svn commit: r1442739 - /commons/sandbox/beanutils2/trunk/src/main/java/org/apache/commons/beanutils2/ClassLoaderBuilder.java

[Simone Tripodi]

> But I feel a bit confused now regarding which changes require a a ticket
> and which don't.

Any modification that have impacts to our users, such as APIs change -
in that case - a bug, a new feature, an improvement, ... worths an
issue.

Any trivial modification such as typos, missing javadoc, if-then-else
optimization, internal static imports, ... you can commit directly.

Alles Gute!
-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

Re: svn commit: r1443186 - /commons/sandbox/beanutils2/trunk/src/changes/changes.xml

[Simone Tripodi]

> +
> +  Implement setMapped on DefaultBeanAccessor
> +

you can drop the `due-to` field in that case - I used the `due-to`
field when you provided patches and I took the task to review and
apply, since you worked on that  `due-to` in no longer needed. It is
like saying "Fixed by Benedikt, thanks to Benedikt that reported it"
:)

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

Re: [cli] release 1.3?

[Simone Tripodi]

Hi Thomas!

> looks like a new feature request to me and not a bug report.
>
> I would prefer to release 1.3 and then work on promoting cli2 to proper.

I read the commit history and I think the component has matured
enough, so it's time to cut an RC and let it be voted by the PMC.

Thanks and congrats for the hard work!
-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

Re: svn commit: r1443696 - /commons/sandbox/beanutils2/trunk/src/main/java/org/apache/commons/beanutils2/Argument.java

[Simone Tripodi]

> How do you feel about this? Checkstyle complains about this, and I think it
> is sufficient to tell users that an argument must not be null.

sorry, which one?

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

Re: [Graph] On graph weight type(s)

[Simone Tripodi]

Hi Matthew!

at a first looks it is really interesting, just give me the time to
digest because at the same time I had the feeling of a little
over-engineering activity, I am worried that "5 minutes to run" users
would find it not so immediate.

Thanks for providing stuff to learn from!
All the best,
-Simo

http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/



On Thu, Dec 22, 2011 at 6:25 PM, Matthew Pocock
 wrote:
> Hi,
>
> Just thought I'd throw something out here. My experience is that I often
> take the same graph (as in the exact same data, same objects) but at
> different times want to use different weights. So, rather than having Edge
> extend Weighted, I'd factor weights out into their own interface:
>
> /**
>  * An edge weight function.
>  *
>  * note: perhaps this should more generally just be a Function1, if
> we have such a thing handy.
>  *
>  * @tparam E  edge type
>  * @tparam W weight type
>  */
> public interface EdgeWeight {
>  public W getWeight(E: Edge);
> }
>
> /**
>  * A combination of a monoid and comparator that satisfy monotinicity of
> the addition operation with respect to the comparator.
>  *
>  * ∀a: m.compare(m.zero, a) <= 0
>  * ∀a,b: m.compare(a, m.append(a, b)) <= 0
>  */
> public interface Monotonic extends Monoid, Comparator
>
> Also, some algorithms calculate all shortest paths at once, while others
> calculate them individually and independently. It's probably even possible
> to calculate some lazily. So, the interfaces for shortest paths should
> decouple setting up a strategy for all shortest paths from an object that
> can be used to fetch a specific shortest path.
>
> /**
>  * An algorithm for finding shortest paths between vertices of a graph,
> given some edge weighting function and
>  * a well-behaved combinator for edges between connected vertices.
>  */
> public interface ShortestPathFunction,
> G extends DirectedGraph, W> {
>  public ShortestPathResult makeResult(G graph, EdgeWeight
> weighting, Monotonic combineWith);
> }
>
> /**
>  * The shortest paths between vertices in a graph.
>  */
> public interface ShortestPathResult, W>
> {
>  public WeightedPath findShortestPath(V source, V target);
> }
>
> How does that look? You can then have standard implementations of these
> things in some static utility class or a spring-friendly resource. The
> brute-force algorithms that compute all paths at once would do all the work
> in makeResult() and simply store this in some state within the returned
> ShortestPathResult. Those that calculate individual pairs on the fly (or
> all shortest paths from some vertex) would capture state in makeResult()
> and perform the actual computation in findShortestPath().
>
> Matthew
>
> On 22 December 2011 16:39, Claudio Squarcella wrote:
>
>> Hi,
>>
>>
>>  I highly appreciated the last contributions (thanks guys!) but I also
>>> agree on this point, so let's start from the end.
>>> I think that, no matter what underlying structure we come up with, the
>>> user should be able to specify e.g. a weighted edge with something like
>>>
>>> public class MyEdge implements Edge, Weighted { ... }
>>>
>>> and be able to immediately use it as an input for all the algorithms,
>>> without extra steps required. So the average user is happy, while "graph
>>> geeks" can dig into advanced capabilities and forge their personalized
>>> weights :)
>>> I hope we all agree on this as a first step. Complexity comes after.
>>>
>>> I'll take my time as well to re-think.
>>>
>>
>> I did think and code a bit more. First of all please take a look at the
>> updated code: Weighted is an interface (weight W can be any type) and
>> all the algorithms require edges to implement Weighted for now --
>> we did not break it that much ;)
>>
>> About the "HasProperty-vs-Property" question (as in Comparable vs
>> Comparator, MonoidElement vs Monoid, etc) I would go for the second one
>> only. That is, external classes handle all operations on weights. Downside:
>> the # of method parameters would increase linearly with the number of
>> properties, but I can live with that (how many properties would weights
>> have anyway?). On the other hand we have a neat interface for each
>> property/class (Zero, Semigroup, Monoid, Ordering or Comparator, etc) and
>> one clean, generic implementation for each algorithm. Dijkstra's signature
>> becomes something like:
>>
>> public static , G extends
>> DirectedGraph> WeightedPath findShortestPath( G graph, V
>> source, V target, Monoid weightMonoid, Comparator weightComparator )
>>
>> Scary uh? But wait, default implementations for Double, Integer, etc. are
>> way easier. E.g. Dijkstra's shortcut for Double:
>>
>> public static , G
>> extends DirectedGraph> WeightedPath findShortestPath(
>> G graph, V source, V target )
>> {
>>    return findShortestPath(graph, source, target, new DoubleMonoid(), new
>> DoubleComparator());
>> }
>>
>> where DoubleMonoid 

Re: Google+ Apache Commons brand page

[Simone Tripodi]

Hi Christian!

I think that is something really useful, users like to take part of
such initiatives, see the Maven page on G+ or Maven group on
LinkedIn!!!

Thanks for taking care of it!
-Simo

http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/



On Fri, Dec 23, 2011 at 9:32 AM, Christian Grobmeier
 wrote:
> Hey there,
>
> I want to mention that I have reserved the G+ brand page "Apache Commons"
> https://plus.google.com/106381282762520124070
>
> At the moment we don't use such stuff, but we probably should do.
> Anyway once I can transfer ownership of this page to Commons and once
> this project wants to have that page, I am willing to transfer of
> course. In the meanwhile I can try to post updates to it on the
> Commons ongoings, if folks agree. So far i have not done anything with
> it.
>
> Let me know.
>
> Cheers
> Christian
>
> --
> http://www.grobmeier.de
> https://www.timeandbill.de
>
> -
> 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: [Graph] On graph weight type(s)

[Simone Tripodi]

Hi Matthew!

I think that your idea is great as a foundation for implementing
algorithms but I would not allow users use that APIs to resolve known
problems, unless they want to implement their own solutions or
contribute back to [graph] missing algorithms.

Usually algorithms (like Dijkstra) already have clear enunciates and
steps are known, so we could safety expose 1 APIs that hide all that
details to clients wrapping your proposals.

WDYT? Thanks again!!!
-Simo

http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/



On Fri, Dec 23, 2011 at 10:44 AM, Matthew Pocock
 wrote:
> Hi Simo,
>
> I guess the 5 minutes to run example would be:
>
> ShortestPathFunction.dijkstra
>  .makeResult(graph, EdgeWeight.forWeightedEdge, Monotonic.sumDouble)
>  .findShortestPath(source, target);
>
> I was assuming that there would be standard pallets of all the strategies
> available statically in the obvious places. Actually, now I see the code
> written out in full like that, I'd perhaps consider renaming makeResult to
> `calculate` or `prepare` or some other verb.
>
> Matthew
>
> On 23 December 2011 08:47, Simone Tripodi  wrote:
>
>> Hi Matthew!
>>
>> at a first looks it is really interesting, just give me the time to
>> digest because at the same time I had the feeling of a little
>> over-engineering activity, I am worried that "5 minutes to run" users
>> would find it not so immediate.
>>
>> Thanks for providing stuff to learn from!
>> All the best,
>> -Simo
>>
>> http://people.apache.org/~simonetripodi/
>> http://simonetripodi.livejournal.com/
>> http://twitter.com/simonetripodi
>> http://www.99soft.org/
>>
>>
>>
>> On Thu, Dec 22, 2011 at 6:25 PM, Matthew Pocock
>>  wrote:
>> > Hi,
>> >
>> > Just thought I'd throw something out here. My experience is that I often
>> > take the same graph (as in the exact same data, same objects) but at
>> > different times want to use different weights. So, rather than having
>> Edge
>> > extend Weighted, I'd factor weights out into their own interface:
>> >
>> > /**
>> >  * An edge weight function.
>> >  *
>> >  * note: perhaps this should more generally just be a Function1, if
>> > we have such a thing handy.
>> >  *
>> >  * @tparam E  edge type
>> >  * @tparam W weight type
>> >  */
>> > public interface EdgeWeight {
>> >  public W getWeight(E: Edge);
>> > }
>> >
>> > /**
>> >  * A combination of a monoid and comparator that satisfy monotinicity of
>> > the addition operation with respect to the comparator.
>> >  *
>> >  * ∀a: m.compare(m.zero, a) <= 0
>> >  * ∀a,b: m.compare(a, m.append(a, b)) <= 0
>> >  */
>> > public interface Monotonic extends Monoid, Comparator
>> >
>> > Also, some algorithms calculate all shortest paths at once, while others
>> > calculate them individually and independently. It's probably even
>> possible
>> > to calculate some lazily. So, the interfaces for shortest paths should
>> > decouple setting up a strategy for all shortest paths from an object that
>> > can be used to fetch a specific shortest path.
>> >
>> > /**
>> >  * An algorithm for finding shortest paths between vertices of a graph,
>> > given some edge weighting function and
>> >  * a well-behaved combinator for edges between connected vertices.
>> >  */
>> > public interface ShortestPathFunction> Edge,
>> > G extends DirectedGraph, W> {
>> >  public ShortestPathResult makeResult(G graph, EdgeWeight
>> > weighting, Monotonic combineWith);
>> > }
>> >
>> > /**
>> >  * The shortest paths between vertices in a graph.
>> >  */
>> > public interface ShortestPathResult,
>> W>
>> > {
>> >  public WeightedPath findShortestPath(V source, V target);
>> > }
>> >
>> > How does that look? You can then have standard implementations of these
>> > things in some static utility class or a spring-friendly resource. The
>> > brute-force algorithms that compute all paths at once would do all the
>> work
>> > in makeResult() and simply store this in some state within the returned
>> > ShortestPathResult. Those that calculate individual pairs on the fly (or
>> > all shortest paths from some vertex) would capture state in makeResult()
>> > and perform the ac

Re: [pool] [POOL-208] Support Java 1.5 Generics in version 1.x.

[Simone Tripodi]

Hi again Gary!

I had another review after your latest commits, I just fixed 1 missing
@param comment, and IMHO in therms of having generics-only, this
release should be ready...

Do you have any plan? Thanks for driving this!
-Simo

http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/



On Wed, Dec 21, 2011 at 2:13 PM, Gary Gregory  wrote:
> Hello Generics fan,
>
> Please review and continue on [POOL-208] Support Java 1.5 Generics in
> version 1.x.
>
> The code is in the POOL_1_X branch, cooking up for a 1.6 release very soon.
>
> There are NO code changes in the main code that should affect behavior.
> I've only touched code for adding generics.
>
> As we all know, this is binary compatible with 1.5.x because of type
> erasure.
>
> I have changed some of the tests because 100% source compatibility is not
> possible.
>
> APIs that I could not fully generify are:
>
> - org.apache.commons.pool.PoolUtils.adapt(KeyedObjectPool,
> Object)
> -
> org.apache.commons.pool.PoolUtils.adapt(KeyedPoolableObjectFactory V>)
>
> Please dig in and help to make Pool1 with generics the best it can be for
> 1.6.
>
> My goal is to ONLY change code for Generics.
>
> Other kind of fiddling like enhanced for-loops will make it harder to port
> fixes to and from 1.5.x.
>
> If you like enhanced for-loops or other Java 5 features, I won't stop you,
> but it is not my goal here.
>
> Thank you,
> Gary
>
> --
> 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: [pool] [POOL-208] Support Java 1.5 Generics in version 1.x.

[Simone Tripodi]

Hi all!

> If 1.6 is coming and this project does not support it, how can we> handle it? 
> After all we are not working for the Tomcat project, we are
> working for ourselves,

indeed. From the commons HP: "The Commons is an Apache project focused
on all aspects of reusable Java components."
I am personally here to serve the whole community and all users
without any restriction, but providing help to another (even non ASF)
community is totally different that receiving constraints. That is
*not* OSS, this is working for someone else! I'm not a Tomcat
committer (unfortunately for me) and not all users are Tomcat users as
well, so having this restriction is not IMHO a benefit for the
community.

That's alway why I stopped contributing on [pool2] after people
"kindly" decided to rollback all the activity Gary and I did - I am
guilty as well mainly because I accepted it and replaced all the work
done, but anyway was not an unanimous decision, unfair and driven by a
subset of all of us. That should be not an acceptable behavior.

> and Gary needs a generic version. I would not
> like to see him going and make up a github fork. People outside of
> this project are already saying we are like dinosaurs (collections vs
> guava).

That is exactly what is happening: just to mention yet another "bad"
feedback we recently got, please read the last comment on IO-279[1]:
"that should be fixed in my fork". I went to the project page, where
it is reported:

"Tayler is a log tailing implementation forked from Apache Commons IO,
providing improved performances, bug fixes, cleaner APIs and a
codebase which will be actively maintained and developed :)"

So, looks like users are interested on having something we are not
providing them.
Not everybody has the same needs and we are serving just a subset of
all potential users we could have.

Just my 0.002, all the best,
-Simo

[1] https://issues.apache.org/jira/browse/IO-279

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

Re: [pool] [POOL-208] Support Java 1.5 Generics in version 1.x.

[Simone Tripodi]

Hi again!!!

>
> My plan is simply to finish cleaning up the warnings that generics
> introduced, like the one you just fixed in javadocs.
>
> Still no runtime behavior changes. I did not even change to enhanced for 
> loops.
>

I agree, let's not break (potentially) the pool behavior, what we
wanted are just generics

> I plan building an RC soon. Because of the generics only aspect of the
> changes since 1.5.7, I do not see the need for more work than anything
> related to generics in the code. For the build, the POM can continue
> to pick up current versions of plugins IMO.
>
> Do you see anything else to do?

nope I'm totally on your same path :) I can provide you help on the RC
if needed!

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

Re: [Graph] On graph weight type(s)

[Simone Tripodi]

Hi Claudio!

just make your proposal and attach it to a jira Issue :)
Hope to hear from you soon, all the best!
-Simo

http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/



On Fri, Dec 23, 2011 at 6:02 PM,   wrote:
> Hi,
>
> I like the idea of external weights. Actually that could work for other
> properties of the graph as well. I see a couple of use cases there.
>
> As for lazy implementations, I like them too but with much less priority
> for now.
>
> Anyway, first things first: guys should I infer an implicit 'yes' from
> your answers and go ahead with the proposed change for weights? Anyone
> else has a word on this? I am just applying some lazy pattern here --
> discuss before coding ;)
>
> Claudio
>
>
>> On 23 December 2011 10:38, Simone Tripodi 
>> wrote:
>>
>>> Hi Matthew!
>>>
>>
>>
>>> Usually algorithms (like Dijkstra) already have clear enunciates and
>>> steps are known, so we could safety expose 1 APIs that hide all that
>>> details to clients wrapping your proposals.
>>>
>>
>> That's what façades are for. I totally agree with providing users with
>> utility methods that hide all the guts.
>>
>>
>>>
>>> WDYT? Thanks again!!!
>>> -Simo
>>>
>>> http://people.apache.org/~simonetripodi/
>>> http://simonetripodi.livejournal.com/
>>> http://twitter.com/simonetripodi
>>> http://www.99soft.org/
>>>
>>>
>>>
>>> On Fri, Dec 23, 2011 at 10:44 AM, Matthew Pocock
>>>  wrote:
>>> > Hi Simo,
>>> >
>>> > I guess the 5 minutes to run example would be:
>>> >
>>> > ShortestPathFunction.dijkstra
>>> >  .makeResult(graph, EdgeWeight.forWeightedEdge, Monotonic.sumDouble)
>>> >  .findShortestPath(source, target);
>>> >
>>> > I was assuming that there would be standard pallets of all the
>>> strategies
>>> > available statically in the obvious places. Actually, now I see the
>>> code
>>> > written out in full like that, I'd perhaps consider renaming
>>> makeResult
>>> to
>>> > `calculate` or `prepare` or some other verb.
>>> >
>>> > Matthew
>>> >
>>> > On 23 December 2011 08:47, Simone Tripodi 
>>> wrote:
>>> >
>>> >> Hi Matthew!
>>> >>
>>> >> at a first looks it is really interesting, just give me the time to
>>> >> digest because at the same time I had the feeling of a little
>>> >> over-engineering activity, I am worried that "5 minutes to run" users
>>> >> would find it not so immediate.
>>> >>
>>> >> Thanks for providing stuff to learn from!
>>> >> All the best,
>>> >> -Simo
>>> >>
>>> >> http://people.apache.org/~simonetripodi/
>>> >> http://simonetripodi.livejournal.com/
>>> >> http://twitter.com/simonetripodi
>>> >> http://www.99soft.org/
>>> >>
>>> >>
>>> >>
>>> >> On Thu, Dec 22, 2011 at 6:25 PM, Matthew Pocock
>>> >>  wrote:
>>> >> > Hi,
>>> >> >
>>> >> > Just thought I'd throw something out here. My experience is that I
>>> often
>>> >> > take the same graph (as in the exact same data, same objects) but
>>> at
>>> >> > different times want to use different weights. So, rather than
>>> having
>>> >> Edge
>>> >> > extend Weighted, I'd factor weights out into their own
>>> interface:
>>> >> >
>>> >> > /**
>>> >> >  * An edge weight function.
>>> >> >  *
>>> >> >  * note: perhaps this should more generally just be a Function1>> B>, if
>>> >> > we have such a thing handy.
>>> >> >  *
>>> >> >  * @tparam E  edge type
>>> >> >  * @tparam W weight type
>>> >> >  */
>>> >> > public interface EdgeWeight {
>>> >> >  public W getWeight(E: Edge);
>>> >> > }
>>> >> >
>>> >> > /**
>>> >> >  * A combination of a monoid and comparator that satisfy
>>> monotinicity
>>> of
>>> >> > 

[CLI] discuss experimental CLI binder APIs

[Simone Tripodi]

Hi all guys,
I have been experimenting a new set of CLI APIs outside the ASF,
taking the best from existing CLI and some other non-ASF libraries,
mainly Cédric's JCommander[1], the purposes are:

 * using fluent APIs;
 * simplify the Options building;
 * reducing the number of involved components;
 * triggering actions when options are parsed;

A simple (not working) APIs usage can be found on the GitHub's space[2].

So, I would much more than happy to move the effort to [commons] and
donate the prototype, if people think it would be a worth give a try
to innovate [cli].
Otherwise, I will have to finalize it outside the ASF.
Feedbacks are welcome, many thanks in advance!
-Simo

[1] http://jcommander.org/
[2] http://s.apache.org/xS

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

Re: [CLI] discuss experimental CLI binder APIs

[Simone Tripodi]

Hola Izio!

> Conversely, JCommander has a very low learning curve.

sure I'm JCommander user myself, but that are the reason why that
approach cannot universally applied

 * it's not complete (yet) since it doesn't support Java-alike dynamic
options such as `-Dproperty=value` (they need to be collected in a
Properties/Map instance)
 * it forces all parameters to be collected in POJOs - that is not
universally good (hey could be used to be passed in a pom.xml);
 * it doesn't support Posix parser;
 * wrong converters binding can be detected at runtime only - since
they are expressed in annotations, nothing can be done from the
compiler side;
 * it would be useful performing blocking actions when detecting some
parameters, i.e. like --help that prints the usage message and exit;
 * ... shall I continue? :)

> The example you provided is good enough, but it is still far away in terms
> of learning curve.

UH... Seriously? Being fluent-APIs should be at least easier of
current [cli] APIs...

Thanks for the feedbacks!

-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

Re: [VOTE] Release Commons Pool 1.6-RC1

[Simone Tripodi]

+1

 * tag build works fine;

 * binary signatures are OK;

 * site is updated with snippets including generics;

 * clirr doesn't show any single backward compatibility error;

 * changes report contains 1.6 release;

 * checkstyle is OK.

trivial notes:

 * RAT reports 3 Unapproved licenses but those files are not versioned
under svn, when redeploying the site froma  fresh checkout thos
warnings disappear;

 * findbugs, PMD and CPD show issues inherited from older releases -
that was not the purpose of this release fixing them anyway;

 * maven repo contains .asc.(md5|sha1) files that are generated during
the deploy phase by maven.

Thanks a lot for driving this release, all the best wishes for 2012!!!
-Simo

http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/



On Fri, Dec 30, 2011 at 4:48 AM, Gary Gregory  wrote:
> Good day to you all:
>
> I have prepared Commons Pool 1.6-RC1.
>
> The only changes from 1.5.7 are the additions of generics and therefore
> requires Java 5.
>
> Tag:
>
> https://svn.apache.org/repos/asf/commons/proper/pool/tags/POOL_1_6_RC1/
>
> Site:
>
> https://people.apache.org/builds/commons/pool/1.6/RC1/
>
> Binaries:
>
> https://repository.apache.org/content/repositories/orgapachecommons-004/
>
> The link above includes checksum files.
>
> [ ] +1 release it
> [ ] +0 almost, please fix:
> [ ] -1 no because:
>
> This VOTE is open for at least 72 hours (holidays, hangovers, and all),
> until Janurary 1 2011, 23:00 EST.
>
> Changes:
> o [POOL-208] Support Java 1.5 Generics in version 1.x.
>
> Thank you and happy new year,
> Gary
>
> --
> 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

[OGNL] Interesting Alfresco approach to OGNL

[Simone Tripodi]

Hi all OGNLers,
at MyBatis (which is OGNL client, just an older version) we received
feedbacks from Alfresco team that had to alter the OGNL caching
policy[1] to speedup the performances (just look for OGNL).
WDYT respect the work done to improve our caches?
TIA,
-Simo

[1] 
http://svn.alfresco.com/repos/alfresco-open-mirror/alfresco/HEAD/root/projects/3rd-party/src/mybatis-3.0.4-src.diff

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

Re: [VOTE] Release Commons Pool 1.6-RC2

[Simone Tripodi]

+1

happy new year!!!
-Simo

http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/



On Sat, Dec 31, 2011 at 8:21 PM, Gary Gregory  wrote:
> Good day to you all:
>
> I have prepared Commons Pool 1.6-RC2.
>
> The changes from RC1 are to fix: \
>
> - Relase notes txt are for 1.6, not 1.5.7.
> - Adjust copyright to 2012 from 2011.
> - Bin distro does not include SNAPSHOT files.
>
> The only changes from 1.5.7 are the additions of generics and therefore
> requires Java 5.
>
> Tag:
>
> https://svn.apache.org/repos/asf/commons/proper/pool/tags/POOL_1_6_RC2/
>
> Site:
>
> https://people.apache.org/builds/commons/pool/1.6/RC2/
>
> Binaries:
>
> https://repository.apache.org/content/repositories/orgapachecommons-006/
>
> The link above includes checksum files.
>
> [ ] +1 release it
> [ ] +0 almost, please fix:
> [ ] -1 no because:
>
> This VOTE is open for at least 72 hours (holidays, hangovers, and all),
> until Janurary 1 2011, 23:00 EST.
>
> Changes:
> o [POOL-208] Support Java 1.5 Generics in version 1.x.
>
> Thank you and happy new year,
> Gary
>
> --
> 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: [validator] Commons Validator 1.4.0 release

[Simone Tripodi]

Hi Nick,
I can help you for cutting the RC, I'll start to have a look at
[validator] stuff tonight.

best,
-Simo

http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/



On Tue, Jan 3, 2012 at 5:21 AM, Nick Burch  wrote:
> On Mon, 2 Jan 2012, Raminderjeet Singh wrote:
>>
>> We are using Common Validator in Apache Rave project and faced issue
>> related to validation of localhost URL's. Using 1.4.0-SNAPSHOT version i am
>> able to fix the problem but we cant release with Snapshot version jar. What
>> is the plan to Release 1.4.0 version?
>
>
> I was hoping to have some time in late December to roll another release, but
> alas I didn't :/
>
> There are a few user contributed fixes in JIRA that need to be applied
> (which fix issues raised in the last release vote), then the site needs a
> few updates, then a release can be built and the vote started
>
> If no-one beats me to it, I'll hopefully get a chance to do all that in a
> week or two
>
> Nick
>
> -
> 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: [GUMP@vmgump]: Project commons-digester3 (in module apache-commons) failed

[Simone Tripodi]

hi all guys,

I have to admit my n00b status on Annotations Processing and I just
started following the Oracle guide[1] to write it, but
com.sun.mirror.* classes are not present in the JVM invoked by Gump.
Do you have any hint/recommendation?
Thanks a lot in advance!
-Simo

[1] http://docs.oracle.com/javase/1.5.0/docs/guide/apt/GettingStarted.html

http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/



On Wed, Jan 4, 2012 at 3:12 AM, Gump  wrote:
> 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-digester3 has an issue affecting its community integration.
> This issue affects 2 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-digester3 :  XML to Java Object Configuration
>    - commons-digester3-test :  Apache Commons
>
>
> Full details are available at:
>    
> http://vmgump.apache.org/gump/public/apache-commons/commons-digester3/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-digester3-*[0-9T].jar] identifier set to 
> project name
>  -DEBUG- (Apache Gump generated) Apache Maven Settings in: 
> /srv/gump/public/workspace/apache-commons/digester/gump_mvn_settings.xml
>  -INFO- Failed with reason build failed
>  -DEBUG- Maven POM in: 
> /srv/gump/public/workspace/apache-commons/digester/pom.xml
>  -DEBUG- Extracted fallback artifacts from Gump Repository
>
>
>
> The following work was performed:
> http://vmgump.apache.org/gump/public/apache-commons/commons-digester3/gump_work/build_apache-commons_commons-digester3.html
> Work Name: build_apache-commons_commons-digester3 (Type: Build)
> Work ended in a state of : Failed
> Elapsed: 21 secs
> Command Line: /opt/maven2/bin/mvn --batch-mode -DskipTests=true --settings 
> /srv/gump/public/workspace/apache-commons/digester/gump_mvn_settings.xml 
> package
> [Working Directory: /srv/gump/public/workspace/apache-commons/digester]
> M2_HOME: /opt/maven2
> -
> /srv/gump/public/workspace/apache-commons/digester/src/main/java/org/apache/commons/digester3/annotations/processor/DigesterAnnotationProcessor.java:[28,26]
>  package com.sun.mirror.util does not exist
> /srv/gump/public/workspace/apache-commons/digester/src/main/java/org/apache/commons/digester3/annotations/processor/DigesterAnnotationProcessor.java:[37,15]
>  cannot find symbol
> symbol: class AnnotationProcessor
>    implements AnnotationProcessor
> /srv/gump/public/workspace/apache-commons/digester/src/main/java/org/apache/commons/digester3/annotations/processor/DigesterAnnotationProcessor.java:[40,18]
>  cannot find symbol
> symbol  : class AnnotationProcessorEnvironment
> location: class 
> org.apache.commons.digester3.annotations.processor.DigesterAnnotationProcessor
> /srv/gump/public/workspace/apache-commons/digester/src/main/java/org/apache/commons/digester3/annotations/processor/DigesterAnnotationProcessor.java:[42,33]
>  cannot find symbol
> symbol  : class AnnotationProcessorEnvironment
> location: class 
> org.apache.commons.digester3.annotations.processor.DigesterAnnotationProcessor
> /srv/gump/public/workspace/apache-commons/digester/src/main/java/org/apache/commons/digester3/annotations/processor/DigesterAnnotationProcessorFactory.java:[28,25]
>  package com.sun.mirror.apt does not exist
> /srv/gump/public/workspace/apache-commons/digester/src/main/java/org/apache/commons/digester3/annotations/processor/DigesterAnnotationProcessorFactory.java:[29,25]
>  package com.sun.mirror.apt does not exist
> /srv/gump/public/workspace/apache-commons/digester/src/main/java/org/apache/commons/digester3/annotations/processor/DigesterAnnotationProcessorFactory.java:[30,25]
>  package com.sun.mirror.apt does not exist
> /srv/gump/public/workspace/apache-commons/digester/src/main/java/org/apache/commons/digester3/annotations/processor/DigesterAnnotationProcessorFactory.java:[31,25]
>  package com.sun.mirror.apt does not exist
> /srv/gump/public/workspace/apache-commons/digester/src/main/java/org/apache/commons/digester3/annotations/processor/DigesterAnnotationProcessorFactory.java:[32,33]
>  package com.sun.mirror.declaration does not exist
> /srv/gump/public/workspace/apache-commons/digester/src/main/java/org/apache/commons/digester3/annotations/processor/DigesterAnnotationProcessorFactory.java:[41,15]
>  cannot find symbol
> symbol: class AnnotationProcessorFactory
>    implements AnnotationProcessorFactory
> /srv/gump/public/workspace/apache-commons/digester/src/main/java/org/apache/commons/dige