My job responsibilities just recently involved converting 25K lines of
code to java 5. I can take on the varargs and generics stuff.
Paul
On Sat, Mar 14, 2009 at 10:19 PM, Henri Yandell wrote:
> There'll be a lot of work in 3.0 I suspect. I'm going to pretend to
> organize it, y'all willing.
>
>
I think the use of JCIP annotations should be an Apache Commons-wide
decision. It would only be sensible to share the annotations across
projects. Otherwise, we could get fragmentation pretty easily.
Paul
On Wed, Mar 18, 2009 at 9:48 PM, sebb wrote:
> On 19/03/2009, Stephen Colebourne wrote:
>>
-- if you want to use them -- is the canonical
bug-detecting annotations for any Commons project. Let's just avoid
duplication.
Paul
On Thu, Mar 19, 2009 at 6:07 AM, sebb wrote:
> On 19/03/2009, Paul Benedict wrote:
>> I think the use of JCIP annotations should be an Apache Commons-wid
Sebb,
After Lang 3.0 gets released, why not branch just for the JCIP stuff?
Sometimes you can only convince my demonstration. I think that would
be an acceptable evaluation.
Paul
On Thu, Mar 19, 2009 at 9:26 PM, Niall Pemberton
wrote:
> On Fri, Mar 20, 2009 at 1:24 AM, sebb wrote:
>> On 20/03/
The Maven folks verified that putting a dependency in
provided will not create a runtime dependency. This
should equal a compile-only scope.
PS: Java 7 will not be defining any source-level annotations for bug
tracking. That will be up to individual tools.
On Fri, Mar 20, 2009 at 12:38 AM, Henri
I'd rather see it in Commons Lang.
On Fri, Jul 3, 2009 at 4:09 PM, Henri Yandell wrote:
> Pondering an idea of a Commons Time package that would sit on top of
> Joda Time/JSR 310. Lang's time package functionality would go in
> there, along with various enhancement ideas. The less core stuff than
Sat, Jul 4, 2009 at 7:42 AM, Paul Benedict wrote:
>> I'd rather see it in Commons Lang.
>>
>> On Fri, Jul 3, 2009 at 4:09 PM, Henri Yandell wrote:
>>> Pondering an idea of a Commons Time package that would sit on top of
>>> Joda Time/JSR 310. Lang'
ommons Time sub-project. I'd hope
> that Commons Time would move faster than Java SE anyway...
>
> Craig
>>
>> On Sat, Jul 4, 2009 at 7:42 AM, Paul Benedict wrote:
>>>
>>> I'd rather see it in Commons Lang.
>>>
>>> On Fri, Jul 3, 2009 at 4
provide
> some features now and not wait possibly years before the JSR completes.
>
> Craig
>
> On Jul 7, 2009, at 9:09 AM, Paul Benedict wrote:
>
>> Perhaps we're approaching this wrong. If we need common utilities for
>> a JSR that's yet to be released, why n
I think NullArgumentException should be deprecated and removed. It is
becoming a best practice to use NPE for null arguments. Joshua Bloch
has produced two books containing such advice, and Google Collections
has gone this way too. By the way, it's because the JDK has set this
precedent.
Paul
On
I have no problem with copying null to null.
On Mon, Nov 25, 2013 at 2:26 PM, Oliver Heger
wrote:
> Any updates here? Also, I would like to hear what others think about
> BEANUTILS-454 [1].
>
> Thanks
> Oliver
>
> [1] https://issues.apache.org/jira/browse/BEANUTILS-454
>
> Am 10.11.2013 22:36, s
There's nothing wrong with the name. Even the spec experts follow this
convention. See methods getContentLength() vs getContentLengthLong().
tomcat.apache.org/tomcat-8.0-doc/servletapi/javax/servlet/ServletRequest.html
On Thu, Jan 2, 2014 at 4:08 PM, Gary Gregory wrote:
> There is no good shor
I think it would be better to make sure this is up to date and link to it
alone:
http://people.apache.org/committers-by-project.html
On Wed, Jan 8, 2014 at 12:37 PM, Phil Steitz wrote:
> Why not just drop it? I would rather see collective energy go
> toward maintaining the individual component
Splitting with an empty string doesn't make any sense to me. Nothing should
match that -- even an empty string. It's a lack of a token.
On Mon, Jan 13, 2014 at 11:00 AM, Benedikt Ritter wrote:
> ping, any thought on this?
>
>
> 2014/1/11 Benedikt Ritter
>
> > Hi,
> >
> > while looking through t
FWIW, there's no solution that can make someone happy. Personally, I always
alphabetize my methods because it's the most straightforward ordering -- no
one has to guess why things are grouped together and sometimes groupings
can get complex. I simply let people follow the javadocs/comments to make
Yes, and Gary's argument is a very high priority driver behind my
alphabetizing. I don't want to maintain groupings. I have concluded a long
time ago that my time is wasted doing that stuff in code.
On Thu, Jan 23, 2014 at 11:18 AM, Gary Gregory wrote:
> Adopting a guideline like this is still a
One thing I would prefer in a BeanUtils 2 is the removal of static utility
classes. I like beans; they allow me to subclass and customize. I can't do
that with static access.
On Wed, Feb 12, 2014 at 2:43 PM, Benedikt Ritter wrote:
> Hell André
>
>
> 2014-02-11 20:01 GMT+01:00 André Diermann :
>
Because eyes are always on the code (thank you very much commit mailing
list), people want to know the real differences between the files. It's
extremely difficult to know what a developer did if a commit to fix
something also includes cosmetic fixes. Separate the two out always and let
the commit
I recommend copying the source of the Commons Lang classes you use and
maintain it privately. It is only two classes, right?
On Mar 1, 2014 12:51 PM, "André Diermann" wrote:
> But will upgrading to 1.7 will solve the core "issue", that some features
> (in detail: Assertions, MethodUitl and TypeUt
I don't know if removing @since 1.0 should be pursued. Coming from a
research perspective, the lack of them either indicates (1) since 1.0 or
(2) an omission. There's no way to know how someone would interpret their
omission so I would recommend keeping them so it's clear which methods
existed sinc
Sebb, maybe I missed the context of the proposal. If the @since 1.0 is on
the class, there's no need for it to be on methods unless the methods are
of another version. I think that's the standard javadoc way from Oracle
anyway.
On Thu, Mar 27, 2014 at 10:35 AM, sebb wrote:
> Indeed.
>
> The poi
I think starting the classes should be @since tagged; that's standard
procedure in the javadoc world, as far as i know. Regarding what's
forgotten, I never worried about that and fixing it is easy.
On Thu, Mar 27, 2014 at 11:18 AM, sebb wrote:
> On 27 March 2014 15:47, Paul Be
The downside of it returning an empty collection is you either have (1) to
instantiate a collection just to say you have nothing or (2) you use an
immutable collection. #1 is bad in itself and #2 is only as bad if the
collection is otherwise writable. For example, it would be really strange
for the
FYI, for anyone maintaining the site, the javadoc is not present from the
site's links.
--
Cheers,
Paul
Yup. I have depend on Lang 3 for my own code and many of my transitive
dependencies relies on Lang 2. There's no problem with having both
libraries in your code.
On Tue, Apr 22, 2014 at 9:22 AM, Matt Benson wrote:
> Note that you can use [lang] v2 and v3 together in the same project as both
> t
JDK Javadoc only supports HTML. It doesn't support XHTML. I remember
someone saying this on the OpenJDK lists but don't know where it is... but
I do remember that.
On Tue, Apr 29, 2014 at 8:12 PM, Gary Gregory wrote:
> Bernd,
>
> For paragraphs I use la di da, never the concept of a "line
> sepa
That's actually a really good point :-)
On Tue, Apr 29, 2014 at 8:50 PM, Gary Gregory wrote:
> Well, it does not support HTML in the sense that you MUST close all tags.
> No lonely s...
>
> Gary
>
>
> On Tue, Apr 29, 2014 at 9:35 PM, Paul Benedict
> wrote:
>
&g
Looks like I found the message I alluded to. Make sure you read the whole
thread for fun ;-)
http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-July/019269.html
On Wed, Apr 30, 2014 at 12:36 AM, Thomas Neidhart wrote:
> On 04/30/2014 03:50 AM, Gary Gregory wrote:
> > Well, it does not su
Wrong syntax is different than missing syntax. The former affects
readability while the other just affects usability. Glad you found a way to
catch the former but ignore the latter.
On Thu, May 1, 2014 at 5:22 AM, Mark Struberg wrote:
> Actually the ',' causes a bug in the maven-javadoc-plugin.
Personally, I don't see a reason to revert the javadoc changes. There's no
turning back the clock on the javadoc processing engine -- it's not like 9
or 10 is going to stop warning about malformed HTML. Although I am not a
Math contributor/commiter, I support the change since going forward it will
Gilles,
Javadoc is not XHTML but HTML... and not just HTML, but an HTML fragment.
Documentation writers need to remember that their content is being placed
within a bigger document so correct tag usage is important to get
predictable results.
I think all Math committers will find this thread abou
s, buys you nothing. What buys you something is properly
formatted HTML in an HTML document.
Cheers,
Paul
On Thu, May 1, 2014 at 5:02 PM, Gilles wrote:
> On Thu, 1 May 2014 16:31:13 -0500, Paul Benedict wrote:
>
>> Gilles,
>>
>> Javadoc is not XHTML but HTML... and
ing Javadoc was XML, I'll
gladly eat my words and enjoy learning something new. But why fight the
technology? Javadoc isn't ever going to be XML so why continue going down
that path?
On Thu, May 1, 2014 at 9:15 PM, Phil Steitz wrote:
> On 5/1/14, 2:31 PM, Paul Benedict wrote:
> &
NPE is implicit if the method does not allow an argument to be null. This
doesn't have to be the case. This has nothing to do with the JDK vs. 3rd
party source. It's just about the contract. As long as you document which
arguments can be null, then you're good -- otherwise throw an NPE to
capture t
nd in Joshua Bloch's book.
Cheers,
Paul
On Tue, May 6, 2014 at 3:50 PM, Duncan Jones wrote:
> On 6 May 2014 19:19, Paul Benedict wrote:
> > NPE is implicit if the method does not allow an argument to be null. This
> > doesn't have to be the case. This has nothing to d
Yes, it's supposed to throw NPE for the reasons stated a couple times in
this thread. That's by design, not accident. The "official" version in
java.lang.Objects (JDK 7+) does the same thing.
Cheers,
Paul
On Tue, May 6, 2014 at 4:00 PM, Duncan Jones wrote:
> On 6 May 2014 20:41, Phil Steitz
This is not a matter of law. If Oracle/Sun set a direction on how to use
NPE, it's a really good idea to follow them -- even if you don't agree, do
it for the sake of consistency. I don't think using IAE is somehow "better"
Java than what they are doing. And I give weight to what Joshua said
becaus
ttle because the
march is going the other direction.
Paul
Cheers,
Paul
On Tue, May 6, 2014 at 6:27 PM, sebb wrote:
> On 6 May 2014 22:54, Paul Benedict wrote:
> > This is not a matter of law. If Oracle/Sun set a direction on how to use
> > NPE, it's a really good idea to
For anyone here in Commons who likes API designing, take a look at this new
proposal coming down the pike. The proposal helps simplify/specify how APIs
declare their type parameters and the impact (better, hopefully) for
clients of those APIs.
https://bugs.openjdk.java.net/browse/JDK-8043488
Make
Gary, 1.2 of what?
Cheers,
Paul
On Mon, Jul 7, 2014 at 3:38 PM, Gary Gregory wrote:
> Note that 1.2 is about to be released.
>
> Gary
>
> Original message From: brit...@apache.org
> Date:07/07/2014 15:36 (GMT-05:00) To:
> comm...@commons.apache.org Subject: svn commit: r160
Is there an itch to scratch (need) by moving to git as opposed to just
continue using svn?
Cheers,
Paul
On Tue, Sep 9, 2014 at 9:49 AM, sebb wrote:
> On 9 September 2014 15:32, Gary Gregory wrote:
> > On Tue, Sep 9, 2014 at 9:17 AM, sebb wrote:
> >
> >> On 9 September 2014 14:10, Gary Gregor
o
> hasn't tried git, to add a small feature, add some comments, or add a unit
> test, we'll learn enough. The project lead can look at the impact on the
> release process, and report any findings. At least at that point, we'll
> have learned enough from the process to
I think some people find it unseemly to have both commons 2 and 3 jars in
the classpath. It's OK. This is how a project can make major improvements
and not affect previous clients -- because the package names are different.
The two can live together just fine.
Cheers,
Paul
On Fri, Oct 17, 2014 a
FWIW, I have found no difficulty moving code from lang2 to lang3. It's a
breeze. I did a wholesale replacement of the package name and then fixed
any compiler problems due to API differences.
Cheers,
Paul
On Fri, Oct 17, 2014 at 3:51 PM, sebb wrote:
> On 17 October 2014 21:37, Romain Manni-Buc
ebb" a écrit :
> >
> > On 17 October 2014 21:57, Paul Benedict wrote:
> > > FWIW, I have found no difficulty moving code from lang2 to lang3. It's
> a
> > > breeze. I did a wholesale replacement of the package name and then
> fixed
> > > any com
You are not including duplicate artifacts, they are totally distinct.
I do not not like "final" used this way. Unless you have a constant or a
language mandating "final" for a particular usage, this is unnecessary
noise to the code.
Cheers,
Paul
On Thu, Oct 23, 2014 at 2:34 PM, Oliver Heger
wrote:
> There was no reaction on my comment so far.
>
> I am tempted to
Even I must admit that the use of "final" here is more of a formality than
a necessity. I believe that's why it's been called a "stylistic" commit.
The compiler isn't driving you to use it for what you need to accomplish,
and there is no pressing technical need to use it aside from it enforces
some
Whenever I've felt like there is "too much work and too little people to do
it", I remind myself Apache is not a job (unless someone is paying you for
your work), but a volunteer organization. Everyone does what he/she wants
to do... and if it's not personally fun or interesting, those people will
Devang, you can immediately start by going to JIRA [1] and finding some
"low hanging fruit" that interests you. Look for an easy ticket and submit
a patch. This will start your code contribution to the community.
[1] https://issues.apache.org/jira/browse/COLLECTIONS
Cheers,
Paul
On Thu, Dec 4,
;
> On Fri, Dec 5, 2014 at 6:33 AM, Paul Benedict
> wrote:
>
> > Devang, you can immediately start by going to JIRA [1] and finding some
> > "low hanging fruit" that interests you. Look for an easy ticket and
> submit
> > a patch. This will start y
I don't see a problem with having builds generated only on changes. I would
prefer that. But will all of ASF do the same? I would find it difficult to
determine what group is doing what: either nightly auto-builds or builds
daily only on commit.
Paul
On 8/26/07, Brett Porter <[EMAIL PROTECTED]> w
The menu has erroneous links for its user guides (1.8 and 1.7). Both
versions are pointing to the API docs instead.
Paul
Simon, thanks for pointing that out. I didn't find that obvious :-) Perhaps
the package documentation could be titled User Guide.
Paul
On 9/6/07, simon <[EMAIL PROTECTED]> wrote:
>
> On Tue, 2007-09-04 at 14:21 -0500, Paul Benedict wrote:
> > The menu has erroneous links f
I've always wondered this:
What is the policy on copying code from an external non-Apache ASF-licensed
project? For example, if someone wanted to take a class from Spring and plop
it in an Apache project. Is simply being from ASF-licensed code enough?
Paul
On 9/20/07, Torsten Curdt <[EMAIL PROTE
Please provide a working example.
On 9/20/07, Bhupesh Naik <[EMAIL PROTECTED]> wrote:
>
> action-descriptor.xml
>
> Hello,
>
> We have been using apache commons validator extensively; we have found
> that a common pattern can be identified in the way the apache commons
> validator work.
>
> Apac
+1
Niall,
Can you add a copy of this email to the Validator wiki? I think this is
project plan information that's too good to let go.
Paul
On 10/11/07, Ben Speakmon <[EMAIL PROTECTED]> wrote:
>
> Makes perfect sense.
>
> In the spirit of starting slow, I think I'll look at porting oro regexes
> to
>
> --- Ben Speakmon <[EMAIL PROTECTED]> wrote:
>
> > Another issue is that Sun has end-of-lifed JDK 1.3.
> > It doesn't make sense to
> > me to continue to support a platform even Sun has
> > given up on.
>
Since all contributions are on a volunteer-basis, if somebody really wants
it fixed for 1.
Only Ant can specify the actual target JDK used to compile the code in the
Manifest. Maven has an open issue for this in the jar plugin. Alot of people
want to write the target JDK to the manifest, but unfortunately the actual
JDK version (e.g., 1.6) appears.
Paul
On Jan 16, 2008 8:58 AM, Niall P
Henri,
How do you know that the reports are GPL? I knew Cobertura is written under
GPL, but how does that extend to the report generation?
Paul
On Jan 19, 2008 1:51 PM, Henri Yandell <[EMAIL PROTECTED]> wrote:
> Just wanting to share concern about a couple of things:
>
> 1) Using Cobertura. It'
The "JavaDocs (SVN Latest)" link points to 3.0, but 2.4 is actually the
latest version being maintained. Can that be repointed? Or a
2.4-SNAPSHOTlink be added?
Just going to throw in my two cents here...
When a project chooses a different package structure (struts/struts2,
io/io2, etc.), it's advertising itself as truly independent implementations.
That is, you could run Struts 1 and Struts 2 in one application, and also
use Commons IO 1 and Commons IO 2
Niall, I agree as well. I don't see a strong reason for keeping any
deprecations if the package structure is changing. It is no longer binary
compatible -- especially if you begin at version 1.0 again.
Paul
On Feb 6, 2008 9:46 AM, Niall Pemberton <[EMAIL PROTECTED]> wrote:
> On Feb 6, 2008 1:44
; wrote:
> On 2/6/08, Paul Benedict <[EMAIL PROTECTED]> wrote:
> > Niall, I agree as well. I don't see a strong reason for keeping any
> > deprecations if the package structure is changing. It is no longer
> binary
> > compatible -- especially if you b
+1
How does removing the parameter solve the leaking?
Paul
On Thu, Mar 13, 2008 at 10:15 PM, Niall Pemberton <[EMAIL PROTECTED]>
wrote:
> I've been looking at the memory leaks described in BEANUTILS-291[1]
> and am considering making API changes that will break compatibility
> with the BeanUtils 1.
I checked out trunk and built myself and could not reproduce the
2.4.1version in any of my artifacts. Everything is
2.4.
Paul
On Thu, Mar 13, 2008 at 10:15 AM, Henri Yandell <[EMAIL PROTECTED]> wrote:
> On Thu, Mar 13, 2008 at 4:31 AM, Torsten Curdt <[EMAIL PROTECTED]> wrote:
> > > Strange Thing
Ugh.
>
> I guess, hard code the version in the assembly is another option, and
> seems far and away the best one :)
>
> Will do an RC2 with a hardcoded assembly/src.xml for 2.4.
>
> Hen
>
> On Thu, Mar 13, 2008 at 11:24 PM, Paul Benedict <[EMAIL PROTECTED]>
> w
+1
On Fri, Mar 14, 2008 at 11:30 AM, Rahul Akolkar <[EMAIL PROTECTED]>
wrote:
> On 3/14/08, Henri Yandell <[EMAIL PROTECTED]> wrote:
> > On Thu, Mar 13, 2008 at 8:27 PM, Niall Pemberton
> >
> > <[EMAIL PROTECTED]> wrote:
> >
> > > On Fri, Ma
Henri, why not setup Continuum to run all these jdk versions?
On Sat, Mar 15, 2008 at 2:19 PM, Henri Yandell <[EMAIL PROTECTED]> wrote:
> On Sat, Mar 15, 2008 at 5:32 AM, sebb <[EMAIL PROTECTED]> wrote:
> > On 15/03/2008, Henri Yandell <[EMAIL PROTECTED]> wrote:
> > > Compiling against 1.2, we h
Something is wrong with the OSGi bundle description in the manifest. It's
trivial, but notice how it is totally formatted incorrectly. Lots of
whitespaces everywhere.
+1
Paul
On Sat, Mar 15, 2008 at 10:50 PM, Henri Yandell <[EMAIL PROTECTED]> wrote:
> Here's the Lang 2.4 RC3 for your delectatio
I would be +1 to split it into multiple bundles. I usually need only a
subset of the functionality -- for a particular collection type. I think the
difficulty is going to know where to split the bundles.
Paul
On Tue, Mar 25, 2008 at 12:07 PM, Matt Benson <[EMAIL PROTECTED]> wrote:
> In particula
The project is active :-) but it is not getting it's due attention at the
moment.
Go to JIRA and you can see there is a Validator2 ticket list to implemetn
JSR 303.
Paul
On Wed, Mar 26, 2008 at 9:06 AM, Mohammad Nour El-Din <[EMAIL PROTECTED]>
wrote:
> Hi All...
>
> Recently an EDR JSR#303 has
Is there any reason left to rename packages if you're OSGi compliant?
Different versions should be in different class loaders.
On Thu, May 15, 2008 at 4:59 PM, Rory Winston <[EMAIL PROTECTED]>
wrote:
> Just my 2c, but I think package renaming for major releases is ugly and
> unecessary.
>
> Phil
Perhaps the Serializations should be looked at. Most web app servers
serialize all their info out when restarting.
+1 on the release, btw
Paul
On Wed, May 21, 2008 at 7:52 PM, sebb <[EMAIL PROTECTED]> wrote:
> Not sure if this should be regarded as a problem or not, but I get a
> test failure w
+1
On Thu, May 22, 2008 at 9:21 PM, Niall Pemberton <[EMAIL PROTECTED]>
wrote:
> On Thu, May 22, 2008 at 10:43 PM, Emmanuel Bourg <[EMAIL PROTECTED]>
> wrote:
> > I'm a bit concerned by the low test coverage (64% lines and 55% branches
> > according to Cobertura). Some classes like CommandListene
Phil, was there a vote attached to your suggestion?
On Sat, May 24, 2008 at 10:45 PM, Phil Steitz <[EMAIL PROTECTED]> wrote:
> On Thu, May 22, 2008 at 7:10 PM, Niall Pemberton
> <[EMAIL PROTECTED]> wrote:
> > On Thu, May 22, 2008 at 9:35 PM, Luc Maisonobe <[EMAIL PROTECTED]>
> wrote:
> >> A few c
+1
On Fri, May 30, 2008 at 4:19 PM, Rahul Akolkar <[EMAIL PROTECTED]>
wrote:
> +1
>
> Built site on Windows and Linux (aside: the findbugs plugin is a memory
> hog).
>
> -Rahul
>
>
> On 5/29/08, Niall Pemberton <[EMAIL PROTECTED]> wrote:
> > The main changes since RC2 are:
> > - Fix serializati
Don't forget to move Commons into the Ex-Jakarta section of the home page.
On 7/27/07, Antonio Petrelli <[EMAIL PROTECTED]> wrote:
>
> 2007/7/27, Niall Pemberton <[EMAIL PROTECTED]>:
> >
> > On 7/27/07, Henri Yandell <[EMAIL PROTECTED]> wrote:
> > > 1) We need a logo.
> >
> > I hacked a basic one
Simon, my thoughts are the same. I don't see commons being exclusively
Java. Perhaps APR library and the C++ template would sit in here too.
Paul
simon wrote:
On Sat, 2007-07-28 at 00:47 -0700, Henri Yandell wrote:
I'm sure there's stuff I've missed, but http://commons.apache.org is
now li
ble sitting on a PMC with APR or C++ libraries being
released. I would have no measure by which to judge their release
worthiness, or to handle issues from them.
Stephen
Paul Benedict wrote:
Simon, my thoughts are the same. I don't see commons being
exclusively Java. Perhaps APR library
+1
201 - 283 of 283 matches
Mail list logo
