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.
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 mben...@apache.org wrote:
Bill Speirs and I were talking offline and we'd like to (finally) move
forward with the next version of the [proxy]
+1
http://people.apache.org/~simonetripodi/
http://twitter.com/simonetripodi
On Tue, Mar 11, 2014 at 9:08 PM, Benedikt Ritter brit...@apache.org 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]
-
makes sense, +1
http://people.apache.org/~simonetripodi/
http://twitter.com/simonetripodi
On Sat, Mar 8, 2014 at 1:37 PM, Emmanuel Bourg ebo...@apache.org wrote:
Le 08/03/2014 13:04, Benedikt Ritter a écrit :
Thoughts?
I would even suggest getting rid of the physical distinction between
/simonetripodi
On Mon, Mar 3, 2014 at 9:38 PM, Mark Thomas ma...@apache.org wrote:
On 03/03/2014 16:31, Gary Gregory wrote:
It reads better to me.
Gary
Original message
From: Simone Tripodi simonetrip...@apache.org
Date:03/03/2014 10:40 (GMT-05:00)
To: Commons
On Mon, Mar 3, 2014 at 9:13 AM, Benedikt Ritter brit...@apache.org wrote:
Hi,
2014-03-02 11:42 GMT+01:00 Simone Tripodi simonetrip...@apache.org:
Hi all,
between all options, Matt's one would be the one I'd support.
Shading may be a solution. But tbh I don't see a problem here. We
go for it! :)
http://people.apache.org/~simonetripodi/
http://twitter.com/simonetripodi
On Mon, Mar 3, 2014 at 10:53 AM, Benedikt Ritter brit...@apache.org wrote:
Hello André
2014-03-03 9:57 GMT+01:00 André Diermann andre.dierm...@gmail.com:
2014-03-03 9:10 GMT+01:00 Benedikt Ritter
of the door.
bq. If someone has the time and energy to do this, go for it :-)
http://people.apache.org/~simonetripodi/
http://twitter.com/simonetripodi
Benedikt
Oliver
2014-03-01 13:04 GMT+01:00 Simone Tripodi simonetrip...@apache.org:
Hi all mates,
even if in a stealth mode
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/
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 gudnabr...@gmail.com wrote:
And just to add fuel to the fire and ensure every
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 BU core
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
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 andre.dierm...@gmail.comwrote:
Hello,
I noticed that the majority
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 brit...@apache.org wrote:
Hi all,
I've just published our website. The new skin is now online. [1]
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]
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
Hi Jonas,
I will provide a patch for
CHAIN-98https://issues.apache.org/jira/browse/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 should
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
?
- 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 simonetrip...@apache.org
Hallo Bene,
* JavaDoc of Command says that commands have to be designed in a
thread
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 their
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 and
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, s...@apache.org wrote:
Author: sebb
Date: Thu Jun 20 13:26:52 2013
New
On Thu, Jun 20, 2013 at 4:06 PM, sebb seb...@gmail.com wrote:
On 20 June 2013 14:48, Simone Tripodi simonetrip...@apache.org 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
+1
http://people.apache.org/~simonetripodi/
http://twitter.com/simonetripodi
On Thu, Jun 20, 2013 at 8:53 PM, sebb seb...@gmail.com 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
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 benerit...@gmail.com wrote:
Hi,
I'm thinking about adding an
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 benerit...@gmail.com wrote:
Am 16.06.2013 um 13:46 schrieb Benedikt Ritter benerit...@gmail.com:
Am
go for it!
http://people.apache.org/~simonetripodi/
http://twitter.com/simonetripodi
On Thu, Jun 13, 2013 at 9:54 PM, Benedikt Ritter benerit...@gmail.com wrote:
I'm still not really satisfied, since the only thing thats different between
XmlConfigParserTestCase and XmlConfigParser2TestCase
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
P. Kinoshita
http://kinoshita.eti.br
http://tupilabs.com
--- Em ter, 28/5/13, Simone Tripodi simonetrip...@apache.org escreveu:
De: Simone Tripodi simonetrip...@apache.org
Assunto: [Followup][Graph] the future of commons-graph and modularization
Para: Commons Developers List dev
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*
, Luc Maisonobe l...@spaceroots.org 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.
I started a VOTE thread in general
...@hoplahup.net 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, Simone Tripodi wrote:
Hi all PMC members,
I started a VOTE thread in general@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
/
On Tue, May 28, 2013 at 8:43 AM, Benedikt Ritter brit...@apache.org wrote:
Hi Simo,
2013/5/27 Simone Tripodi simonetrip...@apache.org
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
26, 2013 at 5:35 PM, Simone Tripodi
simonetrip...@apache.org 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 would
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
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:
*
://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/
On Sun, May 26, 2013 at 6:10 PM, Rodion Efremov
rodion.efre...@cs.helsinki.fi wrote:
Simone Tripodi kirjoitti 26.05.2013 18:35:
Hi all, mates,
after a long while I haven't touched commons-graph, I had the
opportunity
on commons-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:
Hi Rodion,
Might the API look like
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
)
and pondered on whether aspects of this 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
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
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
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/
On Thu, Apr 4, 2013 at 6:25 AM, Mladen Turk mt...@apache.org 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.
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
...@gmail.com wrote:
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
simonetrip...@apache.orgwrote:
Hi Gary,
defining a skin is the way to share a design across all modules
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/
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/
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]
very neat.
On Wed, Mar 27, 2013 at 8:39 PM, Simone Tripodi
simonetrip...@apache.orgwrote:
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=12313525version=12323958
HTH
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 directly
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
say that
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=12313525version=12323958
HTH!
-Simo
http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
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
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/
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 if
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 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/
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/simonetripodi
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/accessors
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
Le 24/03/2013 14:13, Simone Tripodi a écrit
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/
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, platform
.
Thanks for reviewing!
-Simo
http://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 ebo...@apache.org wrote:
Le 25/03/2013 23:48, Simone Tripodi a écrit :
Please note
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/
+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
simonetrip...@apache.org wrote:
Hi all,
I've prepared the RC1 of Apache Commons-FileUpload 1.3 so I am
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
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/
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,
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
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
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, where
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,
-Simo
-chain (its been a while...) but I like to think I can get
up
to speed fairly quickly here.
Thanks again,
Steve
-Original Message-
From: simone.trip...@gmail.com [mailto:simone.trip...@gmail.com] On Behalf Of
Simone Tripodi
Sent: 13 March 2013 20:01
To: Commons Developers List
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?
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 anything
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 code/config as
+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
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, ma...@apache.org wrote:
Author: markt
Date: Tue Mar 19 10:56:17 2013
New Revision: 1458220
URL:
, 2013 at 12:06 PM, Mark Thomas ma...@apache.org 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://people.apache.org/~simonetripodi/
http
/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/
On Tue, Mar 19, 2013 at 12:22 PM, Mark Thomas ma...@apache.org wrote:
On 19/03/2013 11:13, Simone Tripodi wrote:
Hi Mark! :)
are you running current FU snapshot and Tomcat integration tests
gudnabr...@gmail.com 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
simonetrip...@apache.orgwrote:
I 150% agree with you mate - it's pity here
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
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 about
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
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 seb...@gmail.com wrote:
On 18 March 2013 08:46, Sebb (JIRA) j...@apache.org wrote:
[
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/
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/
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
, Simone Tripodi simonetrip...@apache.org wrote:
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.
See my other post - it's
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
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/
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/
/2013 08:44 PM, Simone Tripodi wrote:
Are you sure, that we don't have a checkstyle rule for too smart code?
;-)
lol, that violates the `Avoid inline conditionals.` rule! :D
checkstyle is just a tool, not our master!
Disable the rules that do not make sense,
just my 2c
Thomas
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` :)
: simone.trip...@gmail.com [mailto:simone.trip...@gmail.com] On Behalf Of
Simone Tripodi
Sent: 16 March 2013 21:04
To: Commons Developers List
Subject: Re: [Chain] Any future plans for commons-chain?
Hi again Steve,
another thing that came in my mind, is about a discussion between Elijah and
I
Hi Bene,
I have to dig in the ML to find the discussion, anyway IIRC the
CatalogFactory has been designed to be integrated in the XML/textual
configuration, mixing a lot of pattern - not in the best way.
With new Configuration design, we thought delegating the config
implementation to
/**
+ * the decoding table size.
+ */
+private static final int DECODING_TABLE_SIZE = 256;
+
The Javadoc does not say why the value 256 is used, so the number is
still a magic number ...
What should be added more than `the decoding table size` in javadoc?
I'd rather
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 - 100 of 1588 matches
Mail list logo
