I'll second contacting the db lists =) This type of library has been
created so many times by so many people that we practically *need* a
strong implementation in (\w+)-commons so we can all stop writing it
again (and again).
-Brian (from the distant db.apache.org land)
On Jan 17, 2004, at
Speaking of JXPath and OJB integration... one thing that has been
brought up a couple times is an XPath style query engine for OJB. I
would love to see this happen, and the process of doing it for OJB 1.1
will help to make sure that the OTM API is as flexible as we
want^H^H^H^H need it to be
I would like to receive commit privileges on the
jakarta-commons-sandbox in order to work on tbm
I am already a db.apache.org committer.
Thank You!
-Brian McCallister
-
To unsubscribe, e-mail: [EMAIL PROTECTED
Thank you, requested.
-Brian
On Dec 9, 2003, at 7:21 PM, Craig R. McClanahan wrote:
Quoting Brian McCallister [EMAIL PROTECTED]:
I would like to receive commit privileges on the
jakarta-commons-sandbox in order to work on tbm
I am already a db.apache.org committer.
Thank You!
-Brian
Several people, prodded by Glenn Nielson, discussed putting together a
project to overcome the shortcoming of Date and Calendar, ranging from
their pita to use-ness to their massive performance bottlenecks.
I know Glenn has had the flu so don't think he has gotten the ball
rolling, but this
at present.
This doesn't exclude changes to DateUtils, but should limit the
expansion on that class. (DateUtils should simplify tasks that have to
use the JDK date classes)
Stephen
from:Brian McCallister [EMAIL PROTECTED]
Several people, prodded by Glenn Nielson, discussed putting
On Dec 8, 2003, at 10:38 PM, Phil Steitz wrote:
I missed your earlier comments, unless you mean on the
CompositeCollection submission.
* Please try to follow the [collections] style for braces.
No problem, I figured this was just an autoformat via tool of choice --
can do so if it needs it. I
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Dec 7, 2003, at 7:08 PM, Stephen Colebourne wrote:
I think that they probably are useful additions, however the review and
commit may take some time :-)
No worries =) I don't have an immediate or near future need for them to
be in
PM, Stephen Colebourne wrote:
Did you have any particular use case in mind, or a specific jakarta
project?
Stephen
- Original Message -
From: Brian McCallister [EMAIL PROTECTED]
To: Jakarta Commons Developers List [EMAIL PROTECTED]
Sent: Saturday, December 06, 2003 7:40 PM
Subject
non-binding +1 on IterableMap
It is longer, but Map2 is painful.
-Brian
On Tuesday, December 2, 2003, at 04:22 PM, Stephen Colebourne wrote:
There is no obvious 'standard' to follow here, other than adding '2'
to the
end (LayoutManager2). But even Sun tends to use descriptive alternate
names
strategy. If no strategy is provided then add is unsupported.
*
* @since Commons Collections 3.0
* @version $Revision: $ $Date: $
*
* @author Brian McCallister
*/
public class CompositeCollection implements Collection {
/** CollectionMutator to handle changes to the collection
On Monday, November 3, 2003, at 07:48 PM, Stephen Colebourne wrote:
I've updated the class in line with commons standards/documentation
etc. It
will probably end up in the decorators subpackage, as it decorates
other
collections.
A few style questions about this...
You have changed the array
On Wednesday, November 5, 2003, at 09:26 AM, __matthewHawthorne wrote:
I, for one, like the idea of commons projects depending on each other
when necessary. There is always a lot of controversy with regards to
including another jar that I don't quite understand. I agree that
if there are
Collections 3.0
* @version $Revision: $ $Date: $
*
* @author Brian McCallister
*/
public class CompositeCollection implements Collection
{
/** CollectionMutator to handle changes to the collection */
protected CollectionMutator mutator;
/** Collections in the composite
On Tuesday, November 4, 2003, at 04:00 PM, Stephen Colebourne wrote:
The main aim of the Mutator change was to make the implementation
obvious
and typesafe. IMO it does fit better with the collections API.
Okay, I don't feel strongly about it, and if it stays as an inner class
it will work fine.
On Monday, November 3, 2003, at 07:48 PM, Stephen Colebourne wrote:
I've updated the class in line with commons standards/documentation
etc.
Much appreciated!
I've also changed the way the Mutator works - see what you think, it
seems
cleaner/quicker I think.
Also a lot less flexible. Mutator
collections. See individual methods
* for specific behaviors in regard to mutators.
*
* @author a href=mailto:[EMAIL PROTECTED]Brian McCallister/a
*/
public class CompositeCollection implements Collection
{
/** Mutator to handle calls to add(Object) */
private Mutator addStrat
behaviors in regard to mutators.
*
* @author a href=mailto:[EMAIL PROTECTED]Brian McCallister/a
*/
public class CompositeCollection implements Collection
{
/** Mutator to handle calls to add(Object) */
protected Mutator addStrat;
/** Mutator to handle calls to addAll(Collection c
18 matches
Mail list logo
