On Fri, 2007-10-26 at 15:58 -0700, [EMAIL PROTECTED] wrote:
> Brian, thank you for the information. I have checked the JIRA issues.
> It seems to me that CLI 2 is kind of working and there is no big
> problems. Do you agree? Or I better use CLI 1.1?
>
> Actually, I am thinking about use CLI 2
BTW, since Jakarta commons is still in the pre-1.5 era, there is no
point to include TextIterable. So it has been a moot point in terms
of suggesting the inclusion of TextIterator in the commons library.
My bad.
Cheers,
Hanson Char
On 10/26/07, Hanson Char <[EMAIL PROTECTED]> wrote:
> The TextIt
The TextIterable's LineIterator was originally an inner private
supporting class which is NOT meant to be used as a standalone class
but rather just an internal implementation, whereas the commons-io's
LineIterator is. There is a difference in intent.
Hanson Char
On 10/26/07, Hanson Char <[EMAIL
Well one difference at least is that the LineIterator implements the
Iterator interface whereas TextIterable implements the Iterable
interface.
An Iterable can take advantage of the 1.5 special for-loop syntax,
whereas an Iterator cannot.
Hanson Char
On 10/26/07, Niall Pemberton <[EMAIL PROTECTE
On 10/26/07, Hanson Char <[EMAIL PROTECTED]> wrote:
> 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 :)
I don't get this - same name, same uses/intents
Brian, thank you for the information. I have checked the JIRA issues. It
seems to me that CLI 2 is kind of working and there is no big problems. Do you
agree? Or I better use CLI 1.1?
Actually, I am thinking about use CLI 2 for my application and work on CLI 2 at
the same time. It seems to
Collections has been on my long-term want-to-get-involved-with list too, but
I don't see a feasible technical plan for the desired generics refactoring.
In the past when I've done similar stuff I've found that you can't really do
it incrementally. If someone could throw together a roadmap that expl
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
Why don't we set up a page for all of Commons to discuss the
JDK5-ization (it's a word) of each of the components (if need be)? I
wouldn't mind helping with Collections.
On 10/26/07, Stephen Colebourne <[EMAIL PROTECTED]> wrote:
> Brian A. Egge wrote:
> > What I would like, is a drop in replaceme
Centralised null handling should also be on this list - whether to
gracefully handle null (as is) or allow a new syntax, e.g. velocity
uses $! and groovy uses a? to allow nulls
On 10/26/07, Dion Gillard <[EMAIL PROTECTED]> wrote:
> I've gotten JEXL 2 to the point now where it passes all of the 1.1
I've gotten JEXL 2 to the point now where it passes all of the 1.1 test cases.
There are a few issues open which were targeted at 2.0 and some others
I've added 2.0 as a Fix For Version in JIRA.
The idea for doing this was to make it easier to change the JEXL code
base, and separate the generated
Brian A. Egge wrote:
What I would like, is a drop in replacement, with binary backwards
compatibility with the 1.4 version. I want everything in the same
package name, and to have the same names.
Not all parts of [collections] can be generified in this manner. For
example, MultiMap and IIRC Bag
13 matches
Mail list logo
