If you are bumping the minimum java version, this should be really 1.5.
Technically the bump won't be a true drop in for someone on 1.4 but who
is on 1.4 anymore? Your call.
On Jan 5, 2015 10:11 AM, "Benedikt Ritter" wrote:
>
>
> Send from my mobile device
>
> > Am 05.01.2015 um 16:34 schrieb
Odd way to use versions, imo. Sounds like "discussion" and "review patch"
and "patch needed" tags would be the better tool.
Cheers,
Paul
On Wed, Apr 15, 2015 at 3:18 PM, Duncan Jones wrote:
> Hi folks,
>
> Currently the "Review Patch" fix version seems to be applied whenever
> code has been su
If you are changing the groupId, there's no point in changing the artifactId.
On Sat, Oct 16, 2010 at 9:38 PM, Phil Steitz wrote:
> I just created a dbcp 1.4 legacy branch, so we can now start work toward
> dbcp 2.0 in trunk. Pool is already off to the races. As we have discussed,
> I would lik
s-dbcp:1.4
org.apache.commons:commons-dbcp:2.0
org.apache.commons:commons-dbcp:3.0
Paul
On Sat, Oct 16, 2010 at 11:29 PM, Phil Steitz wrote:
> On 10/16/10 11:02 PM, Paul Benedict wrote:
>>
>> If you are changing the groupId, there's no point in changing the
>> artifactId.
>
>
It makes perfect sense if you want multiple versions of DBCP on the
classpath. We had that discussion with Lang 3 as well.
Paul
On Sun, Oct 17, 2010 at 10:52 AM, Simone Tripodi
wrote:
> Hi Phil,
> I'm sure the build will be broken at least at the beginning, this
> morning I migrated the commons-
Has any thought been given to simply rolling the projects into one?
On Sun, Oct 17, 2010 at 2:13 PM, Phil Steitz wrote:
> On 10/17/10 2:58 PM, Gary Gregory wrote:
>>
>> Shouldnt we talk more across these two projects? Perhaps making sure we
>> have good reuse and cross pollination
>
> Commons is
wouldn't like adding a generic pool library that brings the JDBC
> connection pooling stuff, IMHO it continues making sense keeping the 2
> separated.
> Just my 2 cents,
> Simo
>
> http://people.apache.org/~simonetripodi/
> http://www.99soft.org/
>
>
>
> On Mon
Niall, congratulations on your hard work and persistence with this
release. Nice job.
Paul
On Sat, Oct 23, 2010 at 8:12 AM, Niall Pemberton wrote:
> The Apache Commons team is pleased to announce the release of Commons IO 2.0.
>
> Commons IO 2.0 requires a minimum of JDK 1.5, but is otherwise
>
+1 for softening all exceptions. The fact is, what reasonable recourse
is there to the user if a file operation fails? That's what checked
exceptions were supposed to be for -- mandate handling code. It's
tough to say we need to mandate handling these errors.
Paul
On Mon, Oct 25, 2010 at 10:49 AM
Checked exceptions throw a burden onto the developer. He is forced to
do something. Why force this burden? It assumes something SHOULD be
done for these particular errors. I don't think that's realistic
(they're OS errors -- not business errors), which is why checked
exceptions have fallen well out
I believe you're looking for JDK 7 method handles:
http://java.sun.com/developer/technicalArticles/DynTypeLang/
Paul
On Mon, Jan 3, 2011 at 11:45 AM, Michael Giannakopoulos <
miccagi...@gmail.com> wrote:
> Hello to all Apache Commons Developers!
> I wish a happy new year and i hope that all your
Michael,
Primitives are passed by value in Java. If you want to "modify" primitives,
use the MutableXXX wrappers in Commons Lang.
Paul
On Mon, Jan 3, 2011 at 3:01 PM, Michael Giannakopoulos wrote:
> I mean exactly the same thing as C# but from the replies i see that's a
> difficult task and al
I don't understand. Is the enum changing values or is it just getting new
values? The latter is perfectly acceptable. The JDK adds new enum values
where required too, but it won't reorder them or delete existing ones.
On Sun, Jan 30, 2011 at 3:29 PM, Niall Pemberton
wrote:
> IMO this is a really
I like this the best:
http://api.dpml.net/openjdk/module/20070627/java/module/Version.html
On Sun, Jan 30, 2011 at 5:43 PM, Henri Yandell wrote:
> The enum is less to do with Android and more to do with the float and
> int APIs being bizarre. The enum is to have something more useable.
>
> We co
I believe re-organizing the exception hierarchy is a great feature for a
major release. For minor releases, avoid refactoring that would break
current code.
Paul
On Fri, Feb 11, 2011 at 1:23 PM, Phil Steitz wrote:
> So from the user perspective, the compatibility issue is that code
> that catch
Struts 2 is a big consumer of OGNL. The Struts community already consumed
XWork's IP and now own it. Aren't both of those projects from OpenSymphony?
If so, I would say it should go over to Struts.
On Tue, Mar 1, 2011 at 12:50 PM, Stephen Colebourne wrote:
> Based on what I know of OGNL, it is/wa
Giannakopoulos,
It's a debate that goes on. Josh Bloch in his Effective Java book says NPE
is perfectly acceptable for bad arguments. So it really depends on your
perspective what an NPE represents. I prefer Josh's opinion but only because
every single argument probably creates lots of branch-chec
BTW, you can find precedence in the JVM for many methods that throw NPE on
null arguments. I am not saying this is the "right way", since such things
are subjective and are a matter of design, but many people have concluded
it's better.
On Tue, Mar 1, 2011 at 9:16 PM, Bill Barker wrote:
>
>
> --
I neglected to mention that Commons Math *should* document what exceptions
are to be expected. If a method is designed to throw NPE because of a null
argument (whether through explicit checking or not), @throws should mention
that.
Paul
On Wed, Mar 2, 2011 at 10:36 AM, Adrian Crum <
adrian.c...@s
FYI
http://mail-archives.apache.org/mod_mbox/jakarta-jmeter-dev/200402.mbox/%3c4039f65e.7020...@atg.com%3E
Paul
On Mon, Apr 4, 2011 at 6:49 PM, Gary Gregory wrote:
> On Apr 4, 2011, at 17:23, Phil Steitz wrote:
>
> > On 4/4/11 2:18 PM, Torsten Curdt wrote:
> >>> I thought we had settled on '@
The only benefit of the @version tag is that it shows up in javadoc. The
$Id$, if at the top of the file, does not. It's nice to see the subversion
number in API documents. I prefer that since it lets me track down the
actual version in a repository.
Paul
On Tue, Apr 5, 2011 at 8:58 AM, Gary Greg
I thought I sent this link previously, but I can no longer such an email:
http://mail-archives.apache.org/mod_mbox/jakarta-jmeter-dev/200402.mbox/%3c4039f65e.7020...@atg.com%3E
Does anyone have thoughts on this? This is the rule I thought Apache was
following across the board, which is to remove @
I think "tuple" is a better package name. In geo-coordinates, I don't think
it's proper to call Longtitude a key and Latitude a value. It's just a tuple
of values. Same thing for 3d dimension space, etc.
On Tue, Apr 12, 2011 at 12:33 PM, Gary Gregory wrote:
> On Tue, Apr 12, 2011 at 12:16 PM, Ste
-1
POM changes can have big impacts, especially if an erroneous one is
released. It's not that I don't trust the person who makes the changes, but
I would like several people to approve the changes before the ecosystem is
impacted. Checks and balances.
If it turns out I am the only -1 vote, I wil
Here is Apache's Release FAQ:
http://www.apache.org/dev/release.html
There is a line that says "Each PMC must obey the ASF requirements on
approving any release" but then doesn't divulge those rules. I imagine the
+3 rules applies universally. If they don't, I am about to learn something
new.
Pau
100% agreement with Torsten I carried my Effective Java 2nd Edition book
in to work today.
It's item #7. On Page 29 says, Josh says, "While there is no guarantee
that the finalizer will be invoked promptly, it may be better to free the
resource
late than never, in those (hopefully rare) cases
Sorry, 100% agreement with sebb. I read the attribution wrong :-)
On Tue, Apr 19, 2011 at 10:26 AM, Paul Benedict wrote:
> I carried my Effective Java 2nd Edition book in to work today.
>
> It's item #7. On Page 29 says, Josh says, "While there is no guarantee
> that
Is it too radical to suggest POOL 2 be 1.5 and POOL 3 be 1.6? Just
bump up major version every time you target a new major JDK.
On Fri, May 6, 2011 at 10:35 AM, Mark Thomas wrote:
> On 06/05/2011 16:24, Phil Steitz wrote:
>> On 5/6/11 3:43 AM, Mark Thomas wrote:
>>> Before I go too far down the r
Would you guys be willing to start at 4.0-SNAPSHOT so there's a direct
continuation of versioning? Just a novel thought since it might help
others to see it's not a re-invention of OGNL, per se, but the
continuation of it.
On Wed, May 11, 2011 at 8:38 AM, Gary Gregory wrote:
> On May 11, 2011, at
Is it wrong to assume that a Range is always a 2-dimensional set? Can
ranges ever be Nth dimensional?
On Thu, May 19, 2011 at 8:41 AM, Gary Gregory wrote:
> On Wed, May 18, 2011 at 1:03 PM, Matthew Pocock <
> turingatemyhams...@gmail.com> wrote:
>
>> Range is not a sub-type of pair. You can think
Or is it like having a new grandchild? ... and you get to say, "hey, i
get to be a grandpa again!"
On Tue, May 24, 2011 at 9:40 AM, James Carman
wrote:
> On Tue, May 24, 2011 at 6:11 AM, Siegfried Goeschl
> wrote:
>> But it is good to see the all the "grandpa's" returning :-)
>>
>
> I would
You sure it's not a bug in the JDK? Just asking. The results are curious.
On Tue, Jul 12, 2011 at 5:52 PM, Stephen Colebourne
wrote:
> On 12 July 2011 18:56, Jörg Schaible wrote:
>> 1/ FastDateFormat
>> The date format " yyy yy y" is formatted with JDK 7 as "2003 2003 03
>> 2003" instead of
Congrats! Long Live Commons Lang 3.
On Tue, Jul 19, 2011 at 4:02 AM, Simone Tripodi
wrote:
> Great achievement Henri,
> and congrats for the release!!!
> I'm so sorry I didn't take part to the review process but honestly not
> being familiar with Lang I was a little worried on influencing both
>
As long as Commons IO is marked as a test dependency, I am okay with
it. I just don't want it to be a compile-time dependency for the main
source.
On Tue, Jul 19, 2011 at 8:24 AM, Gary Gregory wrote:
> On Mon, Jul 18, 2011 at 9:25 PM, Henri Yandell wrote:
>
>> Interesting issue; though thankfull
ry Gregory wrote:
>> On Tue, Jul 19, 2011 at 9:28 AM, Paul Benedict wrote:
>>
>>> As long as Commons IO is marked as a test dependency, I am okay with
>>> it. I just don't want it to be a compile-time dependency for the main
>>> source.
>>>
&g
. This isn't a -1 veto, but its
>> a strong disapproval.
>>
>> Stephen
>>
>>
>> On 19 July 2011 15:13, Gary Gregory wrote:
>> > On Tue, Jul 19, 2011 at 9:28 AM, Paul Benedict
>> wrote:
>> >
>> >> As long as Commons IO i
Yes. The reason the package name was changed was so that 1.x-2.x and
3.0 can coexist together in an application. Since Commons
Configuration relies on a previous version, as Stephen said, you will
need both dependencies.
On Wed, Jul 27, 2011 at 7:53 AM, Stephen Colebourne
wrote:
> You will need b
the
>>> following components depend on Lang:
>>>
>>> * Chain
>>> * Configuration
>>> * JCS
>>> * Proxy
>>>
>>> and in the Sandbox:
>>>
>>> * Flatfile
>>> * Pipeline
>>>
>>> Hen
>>>
+1. I have done some of this privately (like generics). Having an
official version would be so useful.
On Wed, Jul 27, 2011 at 10:46 PM, Elijah Zupancic wrote:
> Hi,
>
> I've been a active user for a number of years now and a big fan of the
> project. I'm a total beginner when it comes to contrib
On Thu, Jul 28, 2011 at 2:01 PM, Simone Tripodi
wrote:
> * please don't migrate to slf4j. here at commons we continue using
> commons-logging
I haven't heard this before. How come? Just curious.
Paul
-
To unsubscribe, e-mail:
Good deal Ralph! Didn't the creator of Log4j abandon the 1.2/1.3
branch to make SLF4J? Anyways, I have no idea why all the creativity
for logging went outside of Apache, but I would definitely like to see
a version 2.0.
You taking feature requests yet in JIRA? :-)
Paul
On Thu, Jul 28, 2011 at 7:
Would there be any merit in combining the log4j and commons logging
code? Given a hypothetical Log4j 2 and JCL 2, how much different could
they really be in terms of their goals and add-ins?
On Fri, Jul 29, 2011 at 4:51 AM, Gilles Sadowski
wrote:
> Hello.
>
>> I would have done that but some of t
I prefer Apache driven projects when possible. If LOG4J2 takes off,
feature requests would be implemented quicker, I hope.
On Wed, Aug 3, 2011 at 9:27 AM, Ralph Goers wrote:
>
> On Aug 3, 2011, at 6:07 AM, David Karlsen wrote:
>
>> Hasn't the time for both CL and log4j passed by? The trend nowada
On Wed, Aug 3, 2011 at 9:51 AM, Gary Gregory wrote:
>
> I like Log4J just fine thank you very much :)
>
> I'm looking forward to 2.0.
>
> Gary
>
I concur with Gary. All my apps use LOG4J, not JCL or SLF4J. My
dependencies do, however, but LOG4J works great minus a few
enhancements I'd like to see
Or do a pure generics release as 3.5 to satisfy that need... which
allows 4.0 to have generics plus the benefit of major refactoring if
necessary (could also be called 4.0 and 5.0).
On Wed, Aug 3, 2011 at 9:55 AM, Matt Benson wrote:
> On Wed, Aug 3, 2011 at 9:48 AM, Gary Gregory wrote:
>> The mo
On Mon, Aug 8, 2011 at 2:03 PM, Raman Gupta wrote:
> Perhaps I'm missing something, but what exactly is wrong with simply
> using slf4j? It is an extremely simple, widely used library that
> provides out of the box hooks for many logging frameworks including
> log4j and logback, simple to configur
I agree with sebb. I prefer an organization where everyone gets one
vote. This is obviously not the only way an organization can run, but
I like neither having a diminished or overwhelming power with my vote.
The best part of having only +1 is that you can't use your merit to
strong-arm decisions o
+1
On Mon, Aug 15, 2011 at 10:19 AM, Henri Yandell wrote:
> +1 (Commons PMC).
>
> On Mon, Aug 15, 2011 at 6:51 AM, Christian Grobmeier
> wrote:
>> OGNL [1] has checked off all status items in the incubator.
>>
>> Most of the OGNL developers are already commons developers and the
>> risk of failu
I may have missed the discussion... but are we releasing a Java 5
genericized version first before major refactoring?
On Tue, Aug 16, 2011 at 3:35 PM, Elijah Zupancic wrote:
> Hi Simo,
>
> Yes, the patch is binary compatible with the old chain with one exception:
>
> org.apache.commons.chain.web.
actoring?
>
> Thanks,
> -Elijah
>
> On Tue, Aug 16, 2011 at 1:42 PM, Paul Benedict wrote:
>> I may have missed the discussion... but are we releasing a Java 5
>> genericized version first before major refactoring?
>>
>> On Tue, Aug 16, 2011 at 3:35 PM, Elijah
Any thoughts on dumping the checked exception?
public interface Command { ... boolean execute(T
context) throws Exception; }
Paul
On Mon, Aug 22, 2011 at 9:46 AM, Matt Benson wrote:
> I am generally in favor. I think it could be good to apply his patch
> on a branch so we can discuss the clirr
I am curious about the change of normal collections to concurrent
collections. Is there overhead with the concurrent stuff? Most of my
context access is not multithreaded.
On Mon, Aug 29, 2011 at 2:53 PM, Simone Tripodi
wrote:
> Hi all guys,
> I just fixed the clirr report generation and deployed
On Wed, Aug 31, 2011 at 9:45 AM, Simone Tripodi
wrote:
> Hi all guys,
> I noticed that properly setting the 1.5 as target compliance level,
> there are some @Override annotations that in cases of interfaces
> methods implementation should be dropped. Do you agree on it?
Yes, @Override from interf
On Wed, Aug 31, 2011 at 12:02 PM, Simone Tripodi
wrote:
> Hi Paul,
> if I remember correctly, maven should be able to aggregate submodules
> apidocs, I will ask to mvn ML.
Yes, it can. The javadoc plugin has an aggregate option.
Paul
-
> At the same time, everybody: do you agree on replacing package.html
> with package-info.java?
+1
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
; Simo
>
> http://people.apache.org/~simonetripodi/
> http://www.99soft.org/
>
>
>
> On Wed, Aug 31, 2011 at 9:08 PM, Paul Benedict wrote:
>>> At the same time, everybody: do you agree on replacing package.html
>>> with package-info.java?
>>
>> +1
>>
>&g
I want to get rid of it extending map. Have it define as asMap()
function instead. Especially since JDK 8 is bringing in extension
methods, which adds new (and default) methods to all collections, it
won't look very nice. Let's make a break now.
On Sun, Sep 4, 2011 at 9:20 PM, Raman Gupta wrote:
Major versions don't need to keep compatibility. Even if it is
laudable goal to try, I rather have a better designed software and do
30 minutes of upgrading code than keep dragging along old decisions.
On Mon, Sep 5, 2011 at 10:49 AM, Raman Gupta wrote:
> On 09/05/2011 08:51 AM, Simone Tripodi wr
Make the sun class be loaded dynamically -- not statically -- and if
it is not present, just throw an UnsupportedOperationException? I
think that would solve Android's problem.
On Tue, Sep 6, 2011 at 8:36 AM, sebb wrote:
> On 6 September 2011 05:44, David Karlsen wrote:
>> I think tying to sun c
Here's my +1 non-binding.
On Thu, Sep 8, 2011 at 1:38 PM, Simone Tripodi wrote:
> Hi all,
> The proposal of making the 2.0-work brach as proper codebase in /trunk
> for the [chain] component passes with 3 +1 binding votes from
>
> * Simone Tripodi
> * James Carman
> * Matt Benson
>
> no other
On Fri, Sep 9, 2011 at 1:47 PM, Elijah Zupancic wrote:
> Thanks for your comments Nail.
>
> I think that I've come around to see your point after sleeping on it.
> What do you think about this:
>
> Context.java - would be defined as so:
>
> public interface Context extends Map
Isn't that identica
I go with what I said. Extending from Object is sulfurous since all
type parameters extend at least from Object.
On Fri, Sep 9, 2011 at 1:56 PM, Elijah Zupancic wrote:
> Paul,
>
> You may be right. Which one is more idiomatic?
>
> Thanks,
> -Elijah
>
> On Fri, Sep 9
ng your thoughts!!!
> All the best,
> Simo
>
> http://people.apache.org/~simonetripodi/
> http://www.99soft.org/
>
>
>
> On Fri, Sep 9, 2011 at 8:56 PM, Elijah Zupancic wrote:
>> Paul,
>>
>> You may be right. Which one is more idiomatic?
>>
>>
On Fri, Sep 9, 2011 at 3:06 PM, Simone Tripodi wrote:
> Hi Paul,
> the use of that method is to automatically infer the assigned type,
> instead of writing
>
> MyPojo myPojo = (MyPojo) context.get( "myKey" );
>
> the retrieve method allows to
>
> MyPojo myPojo = context.retrieve( "myKey" );
On Fri, Sep 9, 2011 at 3:15 PM, Elijah Zupancic wrote:
> Specifying Object for V would be the most likely use case.
>
> On Fri, Sep 9, 2011 at 1:12 PM, Paul Benedict wrote:
>> On Fri, Sep 9, 2011 at 3:06 PM, Simone Tripodi
>> wrote:
>>> Hi Paul,
>>> the
nk anyway putting types to Context would make Filter, Command,
> Chain, ... classes over engineered IMHO
>
> best,
> Simo
>
> [1] http://s.apache.org/xfj
>
> http://people.apache.org/~simonetripodi/
> http://www.99soft.org/
>
>
>
> On Fri, Sep 9, 2011 at 10:20
.apache.org/~simonetripodi/
> http://www.99soft.org/
>
>
>
> On Fri, Sep 9, 2011 at 11:02 PM, Paul Benedict wrote:
>> The purpose of Generics is to provide type safety with the implicit
>> casts. Implicit casts because of typing shouldn't cause a
>> ClassCastEx
The basic context should be Context and then use interface
composition to define other things like:
public interface PropertyContext extends Context,
Map
It can be done... I think :-)
Paul
On Fri, Sep 16, 2011 at 3:40 PM, Simone Tripodi
wrote:
> Hi Elijah,
> I spent some spare time trying to f
l!
>>>> yes it can be done, of course :) I'm not convinced anyway by the heavy
>>>> notation that, modifying the Context, would impact the Command and
>>>> Filter classes. I think it is because just a matter of taste :P
>>>> Feedbacks/suggestion
I think a boolean is a good indicator for whether the operation was
honored or not.
Paul
On Tue, Sep 20, 2011 at 11:41 PM, Gary Gregory wrote:
> On Wed, Sep 21, 2011 at 12:09 AM, Phil Steitz wrote:
>
>> On 9/20/11 8:24 PM, Gary Gregory wrote:
>> > That sounds reasonable.
>> >
>> > Would any cal
Any product called the Gigester gets my +1 vote!
On Sun, Dec 11, 2011 at 10:56 AM, Oliver Heger wrote:
> +1
>
> Build works fine with Java 1.5 on Windows 7. Artifacts and site look good.
>
> One minor nit: In the release notes the following recommended dependencies
> are listed:
> "The Recommend
-0
I think project names are ASF property (like a trademark). Without
clarification from the board or legal, the vote seems premature.
On Dec 22, 2011 5:32 AM, "Mark Thomas" wrote:
> On 19/12/2011 14:54, Gary Gregory wrote:
> > This is a VOTE to [ALL] to rename Commons Sanselan to Commons Image.
FYI, the website no longer hosts the API and user guide. The links are
broken.
Paul
FYI, the site points to non-existent API and user guide. The links are
broken on both the LHS navigation and the main content.
Paul
yes :-)
On Tue, Apr 23, 2013 at 4:58 PM, sebb wrote:
> On 23 April 2013 22:53, Paul Benedict wrote:
>
> > FYI, the site points to non-existent API and user guide. The links are
> > broken on both the LHS navigation and the main content.
> >
> >
> Beans d
I always thought changes.xml was to describe the release package. If the
ticket produced no artifact update, why does it need to be part of the
distribution?
On Tue, Jun 11, 2013 at 10:30 AM, Gary Gregory wrote:
> I see no harm as adding it to changes.xml, it's a doc change that we might
> as we
AFAIK, a release is a release. If you're voting on a project, a successful
vote creates an Apache artifact that needs to be published to the world.
Maven just released their 3.1.0-alpha. That release will be forever out
there, but since it's not production quality, usage will eventually
drop-off on
Don't try to solve how to stop an alpha release from becoming integrated.
If someone does that, there's inherit risk involved. I don't see how this
is any different, per se, a beta or RC release. If you build on unstable
code, the only support advice I'd will get is: upgrade to the latest GA. :-)
Because Strings hold onto their internal char[], unreferencing a String
password means it hangs around in memory until the JVM garbage collects it.
If you can ever prevent it from becoming a String, keep it as a char[] or
byte[] -- then zero it all out before the array is unreferenced.
Paul
On M
None of these methods document exceptions if the conversion fails (eg, not
an integer). Also, how strict is the conversion? Can "x" represent boolean
false or is that an exception?
On Aug 1, 2013 9:00 AM, "Gary Gregory" wrote:
> I would like to note this CSVRecord addition I am planning on:
>
>
You might want to think of a conversion addon package using Common
BeanUtils. That project is skilled at conversions from String and has
pluggable capability to customize conversion types.
On Aug 1, 2013 6:51 PM, "Paul Benedict" wrote:
> None of these methods document exce
is going to blow up
> really quickly, by the way (registering new converter types, etc.). I
> don't see how having a few little helper methods in CSV is that big of
> an issue, personally.
>
> On Thu, Aug 1, 2013 at 7:59 PM, Paul Benedict
> wrote:
> > You might want to thin
Adrian, the conversions would be configurable. At least that's how I
envisioned it using existing BeanUtils functionality. Gary has a request
our to me to demo that.
On Aug 3, 2013 11:10 AM, "Adrian Crum"
wrote:
> Inline...
>
> On 8/3/2013 9:05 AM, Gary Gregory wrote:
>
>> On Sat, Aug 3, 2013 at
vert. The applications developer is
> free to create any wrappers/facades necessary to connect the two.
>
> -Adrian
>
>
> On 8/3/2013 9:18 AM, Paul Benedict wrote:
>
>> Adrian, the conversions would be configurable. At least that's how I
>> envisioned it using exist
If Convert and BeanUtils do the same thing, I think Commons needs to figure
out how to solve this dilemma because duplicated functionality is usually
frowned upon here. For example, when Commons Lang began doing math, they
moved that to Commons Math (and the same thing happened for BeanUtils from
L
I wonder how many were waiting in silence to see if someone else would
speak up for a rename.
On Tue, Aug 6, 2013 at 3:16 PM, Matt Benson wrote:
> Actually I think by "function name" he was referring to the unfortunate
> English-language sexual innuendo incurred by the abbreviation of the word
Perhaps we're going down the wrong path here. I think having an iterator()
and a parser conflict with each other. The former seems like a leaky
abstraction of the latter. I would propose the parser uses an iterator
internally, or there's an API to get an iterator from a data source (but
not expose
The only danger of static methods is that you can't override them.
BeanUtils first suffered from this fate and they then made an instance
version (BeanUtils2). Just said plainly, you can't customize well using
factory classes/methods.
On Wed, Aug 14, 2013 at 3:04 PM, Emmanuel Bourg wrote:
> Le
Emmanuel, yes. Both the CVSParser and Iterator are two distinct designs.
Both are types of parsers here. So it's really a question of design. Do you
want your users to use the parser directly or work through the iterator or
both? But they shouldn't interfere with each other.
Example:
CVSParser p =
Two weeks ago, I mentioned that BeanUtils and Convert heavily overlap. Some
others agreed. Do we want to fold one project into the other? Or can we
find justification to have 2 separate conversion projects?
--
Cheers,
Paul
A good resource if you didn't know it existed:
http://commons.apache.org/releases/versioning.html
On Tue, Oct 8, 2013 at 3:54 PM, Gary Gregory wrote:
> On Tue, Oct 8, 2013 at 4:50 PM, Siegfried Goeschl
> wrote:
> > That's a reasonable style of versioning :)
> >
> > I had many issues with binar
The dots aren't decimal separators and version numbers are not true
numbers. 0.9 goes to 0.10 goes to 0.11, etc. If they were true decimal
numbers, you couldn't have more than one dot.
0.9 to 1.0 is a major version jump. However, 0.X usually indicates
pre-release quality (i.e., not ready for produ
I don't like the idea of putting inactive components in the attic -- unless
there is some unreasonable length of time that goes by without any
development (3 years?). People who want to get things out of the attic are
usually a sole passionate fellow. Can a sole fellow unilaterally get a
component
I am glad to hear being "dormant" is not the same thing as being in the
"attic"
I also prefer that being "dormant" doesn't cause a SVN/GitHub folder move.
The projects should just live where they are, even when sleeping. Only move
them if they actually go into an "attic"
On Thu, Oct 17, 2013 at
I don't think any duplication will occur if we follow simple rules. Unless
the object performs validation -- which can determined if an exception is
thrown on validation failure -- then you have a method for ObjectUtils;
otherwise it belongs in Validate.
On Fri, Oct 18, 2013 at 1:26 PM, Gary Greg
If you can subclass, the class will likely be mutable somehow (accessing
protected or package-private data?) -- even introducing new variables
exclusive to the subclass. The "final" keyword is used well here.
On Tue, Oct 22, 2013 at 12:15 PM, sebb wrote:
> On 22 October 2013 18:10, Gary Gregory
t;
> > > >> Matt
> > > >>
> > > >>
> > > >> On Tue, Oct 22, 2013 at 2:29 PM, Gary Gregory <
> garydgreg...@gmail.com
> > > >> >wrote:
> > > >>
> > > >> >
> > > >> >
>
In my own research on strong crypto, I found out that US law allows strong
crypto to be exported for open source software. That was some provision
recently carved out in the last 10 years. I think there are some
limitations and procedures wrapped around it -- like submitting the URL to
the source c
I don't think anything like that exists. If your # of entries were
reasonable, a theoretical implementation could allocate a big long[] array
and hash into that. However, 150,000 is very large for an array; possible
but I never done it. So I think the only thing you can really rely on is
the standa
Same here. I didn't know this existed. Thanks.
On Tue, Nov 5, 2013 at 10:49 PM, Gary Gregory wrote:
> Thank you all for replying.
>
> HPPC looks promising and it's Apache 2 licensed. I'll give it a closer
> look.
>
> Gary
>
>
> On Tue, Nov 5, 2013 at 8:59 PM, Ted Dunning wrote:
>
> > Trove is G
1 - 100 of 283 matches
Mail list logo
