My speculation/suggestion is if you do an experiment by cutting a
release (regardless o the implementation) of the common libraries
(with higher version numbers) but are compiled and explicitly claim to
only run on 1.5+ or 1.6+, I bet there will be more downloads of it
than all the other pre-1.5 re
So, Lang 2.4 is starting to get pretty close.
Matt's got his new feature in the works, and I'm going to look through
the 3.0 ones for things to pull down (hint to anyone waiting... having
a patch is the criteria).
There's only one issue needing major discussion currently, and that's:
https://iss
Users use Websphere :)
The naive bit is that your vote to stop active development pre-1.5
will fail. Not everyone wants to dump pre 1.5, and there's not enough
activity amongst those who want to do so in making 1.5+ updates of the
components.
Both Collections and Lang have 1.5+ development branch
> I seem to recall there being a strong view that we didn't want
> Collections to be glossy painted with 1.5, but that whole APIs should
> be rethought as they contained workarounds to the lack of generics.
But can't the library be first moved to a point where one can say the
new releases will run
> 2) direct all effort and resources towards new development in 1.5; and
I mean 1.5+, of course.
On 10/25/07, Hanson Char <[EMAIL PROTECTED]> wrote:
> Naive may I be, On the 1.5 issue, why not just have a big vote to
>
> 1) stop active development work on anything pre-1.5;
> 2) direct all effort
Naive may I be, On the 1.5 issue, why not just have a big vote to
1) stop active development work on anything pre-1.5;
2) direct all effort and resources towards new development in 1.5; and
3) only devote maintenance/backport effort to existing pre-1.5 releases ?
It would be a more beautiful worl
> a) I hate APIs that force me to think in terms of File/URL and not in
> term of streams. It's like not having piping in unix.
Well then you would certainly hate TextIterable, for it is
intentionally designed to operate at a higher level ie File, Resource,
URL. No streams. Just iterate.
As a c
Afaiu, the main reluctance is that no one has stepped up and started
organizing it.
I seem to recall there being a strong view that we didn't want
Collections to be glossy painted with 1.5, but that whole APIs should
be rethought as they contained workarounds to the lack of generics.
+1 on pullin
On 10/25/07, Hanson Char <[EMAIL PROTECTED]> wrote:
> Henri,
>
> LineIterator is intended/designed to be a hidden implementation behind
> TextIterable. It's like putting the cart in front of the horse.
> Things don't make much sense if LineIterator is taken out of context
> as a standalone public
On 2nd thought, encodings do need to be supported, and is now supported :)
http://hansonchar.blogspot.com/2007/10/textiterable.html
Hanson Char
On 10/25/07, Hanson Char <[EMAIL PROTECTED]> wrote:
> Henri,
>
> LineIterator is intended/designed to be a hidden implementation behind
> TextIterable
BTW, there already exists a public standalone class LineIterator:
http://commons.apache.org/io/apidocs/org/apache/commons/io/LineIterator.html
Same name but for different uses/intents :)
Hanson Char
On 10/25/07, Hanson Char <[EMAIL PROTECTED]> wrote:
> Henri,
>
> LineIterator is intended/desi
Henri,
LineIterator is intended/designed to be a hidden implementation behind
TextIterable. It's like putting the cart in front of the horse.
Things don't make much sense if LineIterator is taken out of context
as a standalone public class - issues of InputStream vs Reader,
encoding, closing of i
On 10/25/07, Hanson Char <[EMAIL PROTECTED]> wrote:
> Would anyone be interested in including the proposed TextIterable in
> the commons lang or commons io library ?
>
> http://hansonchar.blogspot.com/2007/10/textiterable.html
Things that jump out:
* Definitely more IO than Lang.
* 1.5 specific
Maybe we should set up a wiki page to discuss this 1.5 problem for
collections (and maybe other projects). We should outline why we have
been reluctant as of yet to "genericize" collections (binary
compatibility, serialization issues, etc.). That way folks don't have
to try to search through the
Hi,
What's the status of the JDK 1.5 branch? It seems the developers are split as
to if it's a good thing, and if so, if the API should be different or the same.
Most advice I see says to use the collections15 project on SourceForge.
What I would like, is a drop in replacement, with binary
Hi Nicholas,
I helped out getting a CLI 1.1 bug fix release out a few months ago. I've
turned my attention to CLI 2.0, but I haven't given it the attention it needs.
What I would like to see is a stable 2.0 release, and then possibly a 2.1
release with additional features.
Wolfgang Roessler,
Thanks Oliver,
I'll look into why those files are missing.
Oliver Heger wrote:
Hi,
the artifacts look good to me. Building from source also worked fine.
The only issue I have is that the jars for the javadocs, sources and
tests do not contain the LICENSE and NOTICE files. I think these files
Hi,
the artifacts look good to me. Building from source also worked fine.
The only issue I have is that the jars for the javadocs, sources and
tests do not contain the LICENSE and NOTICE files. I think these files
must be contained in all artifacts we distribute.
Otherwise I'd be +1.
Oliver
Torsten Curdt wrote:
On 21.10.2007, at 12:37, Oliver Heger wrote:
(this may be a stupid question, but I did not follow the setup of
Continuum too closely)
Not stupid at all. I would imagine the artifacts go into the local maven
repo of vmbuild.apache.org Would be nice to expose that properl
Hi,
I would like to know the current status for CLI 2.0. Is there anyone working
on it? How far does it from for becoming a release? I am considering using it
and even working on it.
Thanks.
Nicholas
Would anyone be interested in including the proposed TextIterable in
the commons lang or commons io library ?
http://hansonchar.blogspot.com/2007/10/textiterable.html
Cheers,
Hanson Char
-
To unsubscribe, e-mail: [EMAIL PROTEC
To whom it may engage...
This is an automated request, but not an unsolicited one. For
more information please visit http://gump.apache.org/nagged.html,
and/or contact the folk at [EMAIL PROTECTED]
Project commons-jelly-tags-jaxme has an issue affecting its community
integration.
This
To whom it may engage...
This is an automated request, but not an unsolicited one. For
more information please visit http://gump.apache.org/nagged.html,
and/or contact the folk at [EMAIL PROTECTED]
Project commons-jelly-tags-jsl-test has an issue affecting its community
integration.
Th
On Thu, 25 Oct 2007 11:09:05 +0200, Thorbjørn Ravn Andersen wrote:
> Oliver Zeigermann skrev den 03-10-2007 22:29:
>> Right. Such a component would contain evertything that is NOT in j.u.c.,
>> but still useful. This means it, it would be an addtion, not a
>> replacement for j.u.c.
>>
>>
> You mi
Oliver Zeigermann skrev den 03-10-2007 22:29:
Right. Such a component would contain evertything that is NOT in
j.u.c., but still useful. This means it, it would be an addtion, not a
replacement for j.u.c.
You might find
http://dcl.mathcs.emory.edu/util/backport-util-concurrent/index.php
in
25 matches
Mail list logo
