Re: [LANG] Add alphabet conversion API

Hi, I personally think it would a very "nice to have" feature, I had to face similar issues in the past and, if that feature was available would have saved me developing time. I just have a small request/suggestion: since int/char can be casted to each other, I would use BitSets rather than Sets.

Re: [proxy] toward a 2.0 release

OH amazing news, thanks Matt!!! http://people.apache.org/~simonetripodi/ http://twitter.com/simonetripodi On Wed, Mar 19, 2014 at 3:49 PM, Matt Benson wrote: > Bill Speirs and I were talking offline and we'd like to (finally) move > forward with the next version of the [proxy] component. We hope

Re: [VOTE] Move Commons Betwixt to dormant

+1 http://people.apache.org/~simonetripodi/ http://twitter.com/simonetripodi On Tue, Mar 11, 2014 at 9:08 PM, Benedikt Ritter wrote: > Hi all, > > as discussed, I'd like to propose to move Apache Commons Betwixt to > dormant. > > Reasons: > - no real activity for a long while [1] > - last releas

Re: [SANDBOX] Getting rid of sandbox parent?

makes sense, +1 http://people.apache.org/~simonetripodi/ http://twitter.com/simonetripodi On Sat, Mar 8, 2014 at 1:37 PM, Emmanuel Bourg wrote: > Le 08/03/2014 13:04, Benedikt Ritter a écrit : > > > Thoughts? > > I would even suggest getting rid of the physical distinction between the > sandbo

Re: svn commit: r1573561 - /commons/proper/dbcp/trunk/src/main/java/org/apache/commons/dbcp2/DelegatingConnection.java

r.com/simonetripodi On Mon, Mar 3, 2014 at 9:38 PM, Mark Thomas wrote: > On 03/03/2014 16:31, Gary Gregory wrote: > > It reads better to me. > > > > Gary > > > > ---- Original message > > From: Simone Tripodi > > Date:03/03/2014

Re: svn commit: r1573561 - /commons/proper/dbcp/trunk/src/main/java/org/apache/commons/dbcp2/DelegatingConnection.java

Hi there, just a matter of curiosity: would +if(traces != null && !traces.isEmpty() { be better or not compared to +if(traces != null && traces.size() > 0) { That should be the same, right? TIA all the best -Simo http://people.apache.org/~simonetripodi/ http://twitter.com/simon

Re: [beanutils] porting fluent APIs from BU2 to BU

tificially is maybe not the > > best option. > > > > As I said... If someone has the time and energy to do this, go for it :-) > It may probably be better to get BU2 out of the door. > > bq. If someone has the time and energy to do this, go for it :-) http://people.apache.o

Re: [beanutils2] Assertions class vs. lang Validate

go for it! :) http://people.apache.org/~simonetripodi/ http://twitter.com/simonetripodi On Mon, Mar 3, 2014 at 10:53 AM, Benedikt Ritter wrote: > Hello André > > 2014-03-03 9:57 GMT+01:00 André Diermann : > > > 2014-03-03 9:10 GMT+01:00 Benedikt Ritter : > > > > > > > > > The stuff that we hav

Re: [beanutils2] Assertions class vs. lang Validate

On Mon, Mar 3, 2014 at 9:13 AM, Benedikt Ritter wrote: > Hi, > > > 2014-03-02 11:42 GMT+01:00 Simone Tripodi : > > > Hi all, > > > > between all options, Matt's one would be the one I'd support. > > > > Shading may be a solution. But tbh

Re: [beanutils] porting fluent APIs from BU2 to BU

Hi Oliver! > > I am not sure about this, also because of the energy required to make > the port happen. Wouldn't it be better to put this energy directly into > BU2? > > for "porting" I just meant enabling the fluent interfaces, ina separated package, which implementations just rely on existing

Re: [beanutils2] Assertions class vs. lang Validate

Hi all, between all options, Matt's one would be the one I'd support. All the best, -Simo http://people.apache.org/~simonetripodi/ http://twitter.com/simonetripodi On Sat, Mar 1, 2014 at 8:45 PM, Matt Benson wrote: > And just to add fuel to the fire and ensure every possible opinion is > rep

Re: [beanutils2] Assertions class vs. lang Validate

Salut André, to avoid to depend to an external lib just to get benefit of 3 methods :) Best, -Simo http://people.apache.org/~simonetripodi/ http://twitter.com/simonetripodi On Sat, Mar 1, 2014 at 5:27 PM, André Diermann wrote: > Hello, > > I noticed that the majority (all?) functionality of t

[beanutils] porting fluent APIs from BU2 to BU

Hi all mates, even if in a stealth mode, I still lurk the ML - unfortunately my recent task at $work didn't let me so much energies/spare time for my hobbies projects. I really feel sorry for the abandoned status of BU2 but I just had the idea to port, in a separate package, the fluent APIs to BU

Re: [SITE] New design is finally online

OH what a wonderful surprise, that makes me feel touched :) -Simo http://people.apache.org/~simonetripodi/ http://twitter.com/simonetripodi On Tue, Feb 18, 2014 at 6:51 PM, Benedikt Ritter wrote: > Hi all, > > I've just published our website. The new skin is now online. [1] > Since site publi

Re: [graph] is now ****** up :(

Are you sure?!? [1] [1] http://svn.apache.org/repos/asf/commons/sandbox/graph/trunk/src/test/java/org/apache/commons/graph/model/BaseLabeledVertex.java http://people.apache.org/~simonetripodi/ http://twitter.com/simonetripodi On Fri, Sep 20, 2013 at 1:30 PM, Rodion Efremov wrote: > Hello, y'al

Re: [graph] Breadth-Fist Search library to commons graph?

Hi Rodion, BFS is already implemented in commons-graph[1] you can provide a GraphVisitHandler[2] implementation to handle the case when you have found the target node, so the search is now complete. HTH, -Best [1] http://svn.apache.org/repos/asf/commons/sandbox/graph/trunk/src/test/java/org/apac

Re: [VOTE] Commons Staging Plugin - move to proper from sandbox

There is an existing plugin[1] that supports checksums generation applying a wider range of digest algorithm, it could help on inspiring the ASF one. my 0.02 EU ;) [1] http://nicoulaj.github.io/checksum-maven-plugin/examples/using-custom-checksum-algorithms.html http://people.apache.org/~simone

Re: [CHAIN] Thoughts about o.a.c.chain2.Chain, o.a.c.chain2.Command and the base classes

Hi Jonas, > > I will provide a patch for > CHAIN-98tomorow. The > patch will only cover the refactoring of CONTINUE and > COMPLETED processing results. > nice to read that, looking forward to the patch! :) > But, I do not understand how exceptions

Re: [CHAIN] Thoughts about o.a.c.chain2.Chain, o.a.c.chain2.Command and the base classes

> I'm not sure if we need ABORTED. What is the difference between COMPLETE > and ABORTED from the PoV of the Chain? Chain defines an algorithm for > processing and I currently don't see how ABORTED fits in there. > OTOH I see some potential here: * COMPLETE: all chain commands have completed the

Re: [CHAIN] Thoughts about o.a.c.chain2.Chain, o.a.c.chain2.Command and the base classes

tes? > > - CONTINUE > - COMPLETE > - ABORTED > > Ticket CHAIN-98 <https://issues.apache.org/jira/browse/CHAIN-98> has been > created to cover this task. > > regards, > Jonas > > 2013/6/20 Simone Tripodi > >> Hallo Bene, >> >> > * JavaDo

Re: [ALL] Proposed tarball staging process

+1 http://people.apache.org/~simonetripodi/ http://twitter.com/simonetripodi On Thu, Jun 20, 2013 at 8:53 PM, sebb wrote: > The current tarball (*) staging process uses Nexus, which works well > for Maven jars and is OK as a means of staging tarballs for voting. > > However: once the vote succe

Re: svn commit: r1494980 - in /commons: proper/commons-gpg-plugin/ sandbox/commons-gpg-plugin/

On Thu, Jun 20, 2013 at 4:06 PM, sebb wrote: > On 20 June 2013 14:48, Simone Tripodi wrote: >> Don't you think it would worth at least announcing it, before moving a >> component from sandbox to proper? > > I did, yesterday. > So, to move Graph from sandbox to prop

Re: svn commit: r1494980 - in /commons: proper/commons-gpg-plugin/ sandbox/commons-gpg-plugin/

Don't you think it would worth at least announcing it, before moving a component from sandbox to proper? http://people.apache.org/~simonetripodi/ http://twitter.com/simonetripodi On Thu, Jun 20, 2013 at 3:26 PM, wrote: > Author: sebb > Date: Thu Jun 20 13:26:52 2013 > New Revision: 1494980 > >

Re: [CHAIN] Thoughts about o.a.c.chain2.Chain, o.a.c.chain2.Command and the base classes

Hallo Bene, > * JavaDoc of Command says that commands have to be designed in a > thread-safe manner, yet all the base implementations are not thread safe! I > have created CHAIN-96 [1] for this, because this definitely has to be fixed > before 2.0 +1 > * The same is true for o.a.c.chain2.Chain

Re: [CHAIN] CopyCommand implements two commands at once

go ahead with copy/override, I think is a nice idea. best, -Simo http://people.apache.org/~simonetripodi/ http://twitter.com/simonetripodi On Tue, Jun 18, 2013 at 9:06 PM, Benedikt Ritter wrote: > > Am 16.06.2013 um 13:46 schrieb Benedikt Ritter : > >> >> Am 15.06.2013 um 15:52 schrieb Benedik

Re: [CHAIN] Add an ExceptionHandler to Chain?

Nice thought, feel free to give a try - I'd use the observer/observable pattern for this best, -Simo http://people.apache.org/~simonetripodi/ http://twitter.com/simonetripodi On Sun, Jun 16, 2013 at 11:21 AM, Benedikt Ritter wrote: > Hi, > > I'm thinking about adding an ExceptionHandler to Cha

Re: svn commit: r1492833 - in /commons/proper/chain/trunk/configuration/xml/src/test: java/org/apache/commons/chain2/config/xml/ resources/org/apache/commons/chain2/config/xml/

go for it! http://people.apache.org/~simonetripodi/ http://twitter.com/simonetripodi On Thu, Jun 13, 2013 at 9:54 PM, Benedikt Ritter wrote: > I'm still not really satisfied, since the only thing thats different between > XmlConfigParserTestCase and XmlConfigParser2TestCase is the config locat

Re: svn commit: r1491924 - /commons/proper/chain/trunk/core/src/main/java/org/apache/commons/chain2/impl/ChainBase.java

I usually don't take too much care to this kind of warnings... My opinion is you can feel free to keep the best option you like :P best and thanks, -Simo http://people.apache.org/~simonetripodi/ http://twitter.com/simonetripodi On Tue, Jun 11, 2013 at 9:50 PM, Benedikt Ritter wrote: > This wi

Re: [chain] improving current registry and configuration APIs

Hi Bene, thanks a lot for following up the discussion, much more than appreciated :) > * The xml module has dependencies to digister. This should be removed if > possible What I don't like is not the Digester dependency itself, but rather the fact that: * The XML config module *exposes* Diges

Re: [Followup][Graph] the future of commons-graph and modularization

per/functor/trunk/ > [2] http://builds.tupilabs.com/job/commons-graph-modularization/1/tasksResult/ > > Bruno P. Kinoshita > http://kinoshita.eti.br > http://tupilabs.com > > > --- Em ter, 28/5/13, Simone Tripodi escreveu: > >> De: Simone Tripodi >> Assunto

Re: [DISCUSS] Accept BeanShell to Commons Sandbox (Was: [VOTE] Accept Apache BeanShell in the Incubator)

l Libbrecht wrote: >> >>> Being a happy user of BeanShell (in the jEdit world) and being a sleepy >>> Apache Commons committer. I'm all in favor of seeing beanshell come in here. >>> >>> paul >>> >>> On 28 mai 2013, at 09:34, Simon

Re: [DISCUSS] Accept BeanShell to Commons Sandbox (Was: [VOTE] Accept Apache BeanShell in the Incubator)

, Luc Maisonobe wrote: > Hi Simone, > > Le 28/05/2013 09:34, Simone Tripodi a écrit : >> Hi all PMC members, > > This message was sent to the global developers list, not to the PMC > list. I guess it can remain here so everyone can tell their opinion. > >> >

[Followup][Graph] the future of commons-graph and modularization

26, 2013 at 5:35 PM, Simone Tripodi wrote: > Hi all, mates, > > after a long while I haven't touched commons-graph, I had the > opportunity to get influenced by some activities at my paid work that > made me think twice on what as been already done in that component, > and

Re: [chain] improving current registry and configuration APIs

On Tue, May 28, 2013 at 8:43 AM, Benedikt Ritter wrote: > Hi Simo, > > > 2013/5/27 Simone Tripodi > >> Hi all Chain-ers, >> >> I had yet another small review yesterday[1] at current Configuration >> APIs and I am not satisfied yet for the following

[DISCUSS] Accept BeanShell to Commons Sandbox (Was: [VOTE] Accept Apache BeanShell in the Incubator)

Hi all PMC members, I started a VOTE thread in general@incubator to accept BeanShell in the incubating projects, Bertrand Delacretaz and Ant Elder made interesting observations (pasted below) about accepting BeanShell directly to Commons. I think we are in the similar past situations when we vote

[chain] improving current registry and configuration APIs

Hi all Chain-ers, I had yet another small review yesterday[1] at current Configuration APIs and I am not satisfied yet for the following reasons: * org.apache.commons.chain2.CatalogFactory should maybe moved from `core` module to the `api` module; * org.apache.commons.chain2.CatalogFactory is

Re: [Graph] the future of commons-graph and modularization

ons-graph :-) > > I am currently using it for a research project in my lab, so hopefully I'll > be able to come back with more feedback. In the meantime I agree with what > you guys wrote so far. > > Cheers, > Claudio > > > On 26/05/2013 20:46, Simone Tripodi wrote

Re: [Graph] the future of commons-graph and modularization

mo http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ On Sun, May 26, 2013 at 6:10 PM, Rodion Efremov wrote: > Simone Tripodi kirjoitti 26.05.2013 18:35: > >> Hi all, mates, >> >> after a lo

[Graph] the future of commons-graph and modularization

Hi all, mates, after a long while I haven't touched commons-graph, I had the opportunity to get influenced by some activities at my paid work that made me think twice on what as been already done in that component, and would like to bring new experiences in. So, what I still like about it: * gr

Re: [Graph] On activity of Sandbox Graph

Hi again Rodion, I had a look at your patch at is simply *amazing* I have no words to say thank you for that great contribution! :) I just attached 2 observations to the issue, if you could re-submit the patch applying that 2 small request, it would be great. I really hope you'll continue get inv

Re: [Graph] On activity of Sandbox Graph

Hi Rodde, thanks a lot for contributing to commons-graph, muh more than appreciated! See replies inline: > (a) What is the average duration between sending a patch P and getting it > reviewed by a committer, assuming P will draw some attention eventually? generally speaking, there is no such ave

Re: [CHAIN] Chain 2.0

his could be accommodated in > commons-chain. There has not been any response to this email (apologies to > Christian), but it does raise an interesting question about where does the > wider community want commons-chain to go. > > Simone Tripodi summarised his view of the 2.0 release recentl

Re: [fileupload] - Custom OutputStream and digest on the fly

Hola Francisco, I'd opt for option #2 - would you be able to submit a patch? TIA, all the best! -Simo http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ On Wed, Apr 10, 2013 at 10:03 PM, Francisco Carriedo Sche

Re: svn commit: r1466591 - /commons/proper/csv/trunk/src/test/java/org/apache/commons/csv/CSVLexerTest.java

just an idea: the `test` prefix on methods signature can be now omitted, since they are already marked with @Test my 0.0002 cents, -Simo http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ On Wed, Apr 10, 2013 at

Re: A proposal for Bug Commons IO/IO-354

Hi Peter, Thanks for contributing to apache commons! code snippets don't properly work in email messages, the best way to contribute code is by submitting patches, attaching them in JIRA issue - test cases are recommended! :) HTH, -Simo http://people.apache.org/~simonetripodi/ http://simonetri

Re: [all] How to prevent mvn deploy to skip certain artifacts

On Thu, Apr 4, 2013 at 6:25 AM, Mladen Turk wrote: > >> > Why? It's a RM's job to sign the files at the time he proposes a vote. > That's the only time this stuff is needed. > The best would be to have some sort of 'dist' target that would prepare > the stuff for non-maven publishing. Other then

Re: [all] How to prevent mvn deploy to skip certain artifacts

Hi Mladen! artifacts produced by the assembly-plugin can be detached from the project by setting to `false` the `attach`[1] property. In that way, -(src|bin)\.(zip|tar\.gz) artifacts won't be deployed. HTH! -Simo [1] http://maven.apache.org/plugins/maven-assembly-plugin/single-mojo.html#attach

Re: [OGNL] JIRA issue ID

Hi Mau, I noticed it as well last week, I doubted I was stoned, but your comment gives me the confirmation that the import of old issues modified added issues behaviour. Agreed that linking commits with issue is now completely confusing :( -Simo http://people.apache.org/~simonetripodi/ http://s

Re: [site] look and feel

: > Hm, but this https://maven.apache.org/index.html looks different from your > [1] site. Is is not fully implemented? > > G > > > On Sat, Mar 30, 2013 at 10:28 AM, Simone Tripodi > wrote: > >> Hi Gary, >> >> defining a skin is the way to share a design acro

Re: [all] Source and binary distributions in Maven

> >> There's only a slightly problem with that approach: the Maven central >> repo is not under the ASF control, while the old traditional dist area >> is, so I guess "official" releases _must_ be placed in the ASF space. > > I agree, our releases must go to an ASF space first. However one could >

Re: [all] Source and binary distributions in Maven

Salut Manu, > > Sure that's what they do. But the "usual" location is different for > every library. If it can be standardized within the Maven infrastructure > that would greatly simplify the downstream packaging. Any library (from > Apache or elsewhere) could be downloaded in a buildable form di

Re: [OGNL] A new release

t; > On Wed, Mar 27, 2013 at 8:39 PM, Simone Tripodi > wrote: > >> > Is there list of changes, sort of a release notes? >> > >> >> Sure, we track resolved issues with fix version: >> >> >> https://issues.apache.org/jira/secure/ReleaseNote.jsp

Re: [all] Source and binary distributions in Maven

I don't think we can speak about "standard" practices, but Maven itself[1] publishes -src and -bin artifacts on the central repo. +1 on NOT publishing them on central repo, but we should find an automated way to deploy them on SvnPubSub along the signature and checksums. best, -Simo [1] http://r

Re: svn commit: r1461628 - /commons/proper/ognl/trunk/src/main/assembly/src.xml

>> >> That assumes reviewers compare the tag with the releases - does anyone >> apart from me do that? >> > everybody HAS to do it and I assume everybody does it, otherwise we have to be aware we are voting poor releases > I do that :) > great! :) -Simo http://people.apache.org/~simonetripodi/

Re: svn commit: r1461628 - /commons/proper/ognl/trunk/src/main/assembly/src.xml

>> cannot come from anywhere since it declares the fileset from ${basedir} > > I meant, the file could have been copied from anywhere and > accidentally left in the directory structure. > this is too general, it happens everywhere - like generated sources accidentally included in bin archives, OSG

Re: svn commit: r1461628 - /commons/proper/ognl/trunk/src/main/assembly/src.xml

> The problem is another file which could come from anywhere. cannot come from anywhere since it declares the fileset from ${basedir} http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ ---

[ANN] Apache Commons-FileUpload 1.3 released

The Apache Commons team is pleased to announce the Apache Commons-FileUpload 1.3 release! The FileUpload component provides a simple yet flexible means of adding support for multipart file upload functionality to servlets and web applications. Changes in this version include (you can download the

Re: svn commit: r1461628 - /commons/proper/ognl/trunk/src/main/assembly/src.xml

> > No, sorry, it's just not as safe. > > I'd rather a file be missing from the release than have a release with > a spurious file that could contain anything. The only risk we have ATM is that the RM includes Idea's or Netbean's dedicated files - and produced archives are reviewed and voted, so i

Re: svn commit: r1461628 - /commons/proper/ognl/trunk/src/main/assembly/src.xml

we just voted a component which -src assembly descriptor[1] uses that one would you reconsider the -1 to -0? [1] http://svn.apache.org/repos/asf/commons/proper/fileupload/trunk/src/main/assembly/src.xml http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitte

[RESULT][VOTE] Release Apache Commons-FIleUpload 1.3 based on RC2

Hi all, more than 72h have passed and the current thread vote can be considered closed and passes with following resolution: three +1 votes from PMC members: * Simone Tripodi * Gary Gregory * Jörg Schaible we got also a +1 vote from Benedikt Ritter. I am going to promote the artifacts and

Re: [OGNL] A new release

> Is there list of changes, sort of a release notes? > Sure, we track resolved issues with fix version: https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12313525&version=12323958 HTH! -Simo http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twi

Re: [CSV] Should the Builder API be optional?

> > Well I understand not everybody is comfortable with a fluent API, that's > probably not what we are used to see in the Java sphere, but we see more > and more successful projects following this pattern. > > > There are already several CSV APIs built around the traditional > constructors/accesso

Re: svn commit: r1461185 - /commons/proper/fileupload/trunk/src/main/assembly/bin.xml

> > Surely it's often useful to have at least the main Javadocs in the bin > archive? > yup we already include uncompressed javadoc, that is why we can be strict to the main artifact only http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetrip

Re: [VOTE] Release Apache Commons-FIleUpload 1.3 based on RC2

p://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ On Tue, Mar 26, 2013 at 12:16 AM, Emmanuel Bourg wrote: > Le 25/03/2013 23:48, Simone Tripodi a écrit : > >> Please note that what Apache really releases are the *source

Re: [VOTE] Release Apache Commons-FIleUpload 1.3 based on RC2

Hallo! > > build works fine with my environment, which is: > > Apache Maven 3.0.3 (r1075438; 2011-02-28 18:31:09+0100) > Maven home: D:\Entwicklung\maven\3.0.3 > Java version: 1.7.0_13, vendor: Oracle Corporation > Java home: D:\Entwicklung\Java\jdk1.7.0_13-x64\jre > Default locale: de_DE, platfor

Re: [VOTE] Release Apache Commons-FIleUpload 1.3 based on RC2

Hi Gary! > > FWIW: I fixed a site nit in trunk to add a hyperlink for an RFC. > it does and I really appreciate it, thanks a lot! All the best! -Simo http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ --

Re: [VOTE] Release Apache Commons-FIleUpload 1.3 based on RC2

n they rely on Ant. This doesn't affect fileupload specifically since > its Debian package is built with Maven, but there was a similar issue > with the build.xml file shipped with Commons Pool 1.6 and it prevented > the Debian package from building. > > Emmanuel Bourg >

Re: svn commit: r1460373 - /commons/proper/csv/trunk/pom.xml

>> >> you missed the `The` part, is `The Apache Software Foundation` have a >> look at ${project.name} on the apache parent pom[1] > > Seems to be a general problem with component poms. > I can fix the proper ones shortly. > Thanks! http://people.apache.org/~simonetripodi/ http://simonetripodi.li

Re: svn commit: r1460373 - /commons/proper/csv/trunk/pom.xml

> Change organization from 'Apache' to 'Apache Software Foundation' you missed the `The` part, is `The Apache Software Foundation` have a look at ${project.name} on the apache parent pom[1] HTH, -Simo [1] http://search.maven.org/#artifactdetails%7Corg.apache%7Capache%7C13%7Cpom http://people.ap

Re: [VOTE] Release Apache Commons-FIleUpload 1.3 based on RC2

+1 http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ On Sun, Mar 24, 2013 at 2:13 PM, Simone Tripodi wrote: > Hi all, > > I've prepared the RC1 of Apache Commons-FileUpload 1.3 so I am here &

[VOTE] Release Apache Commons-FIleUpload 1.3 based on RC2

Hi all, I've prepared the RC1 of Apache Commons-FileUpload 1.3 so I am here to call for a vote: Release Notes: http://people.apache.org/builds/commons/fileupload/1.3/RC2/RELEASE-NOTES.txt Tag: https://svn.apache.org/repos/asf/commons/proper/fileupload/tags/FILEUPLOAD_1_3_RC2 Site: http://pe

Re: [CSV] Extract interfaces?

> > I agree. Interfaces would make sense if you expected to have many different > implementations. > +1 http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ -

Re: [fileupload] towards 1.3 release - feedbacks required

Thanks a lot for the priceless effort on B64, Seb! what's the status ATM, do you think it can be included in a RC? TIA, all the best, -Simo http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ On Thu, Mar 21, 201

Re: [logging] maven central sync of latest release

Hi Thomas, the best thing to do, in such cases, is dropping an email to our repository fellows on reposit...@apache.org It worked for me in the past :P Best, -Simo http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.or

Re: [Chain] Any future plans for commons-chain?

away from XML-centric configuration is >> certainly desirable. >> >> For CHAIN-76, I will apply the prototype patch to a copy of the 2.0 over the >> weekend and take a closer look at what you submitted. I need to refresh my >> memory on commons-chain (its been a while.

Re: [fileupload] towards 1.3 release - feedbacks required

My proposal is: let's go ahead with Java5 compatibility for 1.3, let's increase for 1.6 in 1.4 or 2.0 > > If we do not want to go with Java 6 and that method, we should > probably treat concatenated encodings the same way it does. > But of course we won't emulate the crash! > +1 My 2 cents, -Sim

Re: [fileupload] towards 1.3 release - feedbacks required

> > As far as I know, it already behaves as per the article, except I have > just noticed that RFC2045 requires invalid characters to be ignored. > That should be trivial to fix now that the code has been re-organised. > unfortunately, after a (not deep) search, the most useful place I found, wher

Re: [fileupload] towards 1.3 release - feedbacks required

priceless!!! > At present it treats an embedded PAD as the end of input (as per > Codec) but maybe it would be better to only allow 1 or 2 PADs at the > end? IMHO having such behaviour is acceptable, but if it doesn't cost you too much, having the behaviour described in Wikipedia[1] is a 'nice to

Re: svn commit: r1458266 - /commons/proper/fileupload/trunk/src/test/java/org/apache/commons/fileupload/util/mime/Base64DecoderTestCase.java

3 commits? :O sorry, I have no clue, svn history shows that only once... -Simo stripodi$ svn log r1458278 | simonetripodi | 2013-03-19 14:44:37 +0100 (Tue, 19 Mar 2013) | 1 line [FILEUPLOAD-232] initial checkin of QuotedP

Re: [fileupload] towards 1.3 release - feedbacks required

Hi there, >> is there anything you want to discuss before I go ahead with a new RC? >> I am performing some ITs in non-public projects and I planned to cut a >> new RC in 1-2 days... > > I think there are still some issues in Base64Decoder (this time not > ones I accidentally introduced - sorry ab

[fileupload] towards 1.3 release - feedbacks required

Hi all guys, is there anything you want to discuss before I go ahead with a new RC? I am performing some ITs in non-public projects and I planned to cut a new RC in 1-2 days... What about FILEUPLOAD-137? @Thomas: we didn't get any feedback from Tina on FILEUPLOAD-202, did she try to contact you

Re: svn commit: r1457869 - /commons/proper/collections/trunk/src/test/java/org/apache/commons/collections/CollectionUtilsTest.java

wrote: > Well, but given that a release cannot be vetoed, it's probably better to > catch fundamental design problems earlier rather than later. > > Matt > > > On Tue, Mar 19, 2013 at 2:12 AM, Simone Tripodi > wrote: > >> >> I 150% agree with you mate

Re: svn commit: r1458220 - /commons/proper/fileupload/trunk/src/main/java/org/apache/commons/fileupload/FileUploadBase.java

e.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ On Tue, Mar 19, 2013 at 12:22 PM, Mark Thomas wrote: > On 19/03/2013 11:13, Simone Tripodi wrote: >> Hi Mark! :) >> >> are you running current FU snapshot and Tom

Re: svn commit: r1458220 - /commons/proper/fileupload/trunk/src/main/java/org/apache/commons/fileupload/FileUploadBase.java

, 2013 at 12:06 PM, Mark Thomas wrote: > On 19/03/2013 11:01, Simone Tripodi wrote: >> cool, thanks! > > No problem. Thanks for all your recent work on FileUpload (and to you > sebb). It is much appreciated. > > Mark > > >> >> http:/

Re: svn commit: r1458220 - /commons/proper/fileupload/trunk/src/main/java/org/apache/commons/fileupload/FileUploadBase.java

cool, thanks! http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ On Tue, Mar 19, 2013 at 11:56 AM, wrote: > Author: markt > Date: Tue Mar 19 10:56:17 2013 > New Revision: 1458220 > > URL: http://svn.apache.org/

Re: [ALL] Pushing out releases, one component at a time

+1 to Gary. personally speaking, while I would really like to be involved in Bene's vision, I *have to* put effort where I _need_ to, ATM; I have more work and spare time to contribute just for the joy of participate is a benefit that I don't have ATM, so my PQ is driven by what I need for my dail

Re: svn commit: r1457788 - in /commons/proper/fileupload/trunk/src/test/java/org/apache/commons/fileupload/utils: ./ mime/ mime/MimeUtilityTestCase.java

Hi Bene, >> >> which is the side effect of having them enabled and not used? >> we are no longer using Revision and Date for the known reason, so even >> if they are enabled... what's the downside? >> > > I'm playing the devil's advocate here: aren't you the guy you tries to > avoid unnecessary co

Re: svn commit: r1457788 - in /commons/proper/fileupload/trunk/src/test/java/org/apache/commons/fileupload/utils: ./ mime/ mime/MimeUtilityTestCase.java

> Best not to enable Date or HeadURL; they are both dependent on the > user's settings (Locale and http/https) > > Not sure there is a use-case for Author either. > > For a short way to identify a file version, use $Revision$; for the > longer version use $Id$ > I don't think there's any need for a

Re: svn commit: r1457869 - /commons/proper/collections/trunk/src/test/java/org/apache/commons/collections/CollectionUtilsTest.java

>> I 150% agree with you mate - it's pity here we regularly miss both the >> `early` and the `often` :) > > The downside is that if you rush out a release and it contains a > broken API it will be very difficult to fix without causing problems > for end-users. that is why we vote releases, right?

Re: svn commit: r1457869 - /commons/proper/collections/trunk/src/test/java/org/apache/commons/collections/CollectionUtilsTest.java

> but there are too many discussions about checkstyle rules and "perfect" > releases. We should aim to follow more the open-source credo: release > early, release often, imho. I 150% agree with you mate - it's pity here we regularly miss both the `early` and the `often` :) http://people.apache.or

Re: svn commit: r1457869 - /commons/proper/collections/trunk/src/test/java/org/apache/commons/collections/CollectionUtilsTest.java

we were just kidding, mate :D you didn't get our sense of humor ;) http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ On Mon, Mar 18, 2013 at 8:56 PM, Thomas Neidhart wrote: > On 03/18/2013 08:44 PM

Re: svn commit: r1457869 - /commons/proper/collections/trunk/src/test/java/org/apache/commons/collections/CollectionUtilsTest.java

> > Are you sure, that we don't have a checkstyle rule for too smart code? > > ;-) lol, that violates the `Avoid inline conditionals.` rule! :D http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/

Re: svn commit: r1457869 - /commons/proper/collections/trunk/src/test/java/org/apache/commons/collections/CollectionUtilsTest.java

> Well, it could be recoded like this: > > return !(o1.intValue() % 2 == 0 ^ o2.intValue() % 2 == 0); > > which is not really clearer but it is fewer chars.. > > Gary > well, looks smart to me! :) http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/si

Re: svn commit: r1457869 - /commons/proper/collections/trunk/src/test/java/org/apache/commons/collections/CollectionUtilsTest.java

Salut Gary, > +if (o1.intValue() % 2 == 0 ^ o2.intValue() % 2 == 0) { > +return false; > +} else { > +return true; > +} FWIW, you don't need the `else` here. my 2 cents, -Simo http://people.apache.org/~simon

Re: svn commit: r1457003 - /commons/proper/fileupload/trunk/src/main/java/org/apache/commons/fileupload/util/mime/Base64Decoder.java

I took care about it reverting the MagicNumber constants, see r1457865 http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ On Mon, Mar 18, 2013 at 12:12 PM, sebb wrote: > On 18 March 2013 10:45, Simone Trip

Re: [FILEUPLOAD] Package protected classes have public methods - make these package protected?

> The new utils.mime classes for MIME decoding are mostly package-protected. > > However, they have public methods (and ctors) which is a bit misleading. > > I think it would make sense to reduce the visibility to package protected. > > Any objections? > No objections http://people.apache.org/~si

Re: svn commit: r1457003 - /commons/proper/fileupload/trunk/src/main/java/org/apache/commons/fileupload/util/mime/Base64Decoder.java

feel free to adjust them by yourself and make checkstyle silent about that rules - I am not so worried as you are about internal-use only classes which are intended to be used by fileupload and are not part of the APIs. http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/

Re: [jira] [Commented] (DIGESTER-171) Add DefaultThrowingErrorHandler to Digester API.

> To whatever decision we come here, please let us document it somewhere in > the wiki... + 1 http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ ---

Re: [jira] [Commented] (DIGESTER-171) Add DefaultThrowingErrorHandler to Digester API.

http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ On Mon, Mar 18, 2013 at 9:51 AM, sebb wrote: > On 18 March 2013 08:46, Sebb (JIRA) wrote: >> >> [ >> https://issues.apache.org/jira/browse/DIGESTER-171?pag

Re: svn commit: r1456645 - /commons/proper/fileupload/trunk/src/main/java/org/apache/commons/fileupload/util/mime/Base64Decoder.java

>> checkstyle: Variable 'encodingTable' must be private and have accessor >> methods > > Log comment does not agree with the change below. OUCH! http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ ---

  1   2   3   4   5   6   7   8   9   10   >