You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Henri Yandell <ba...@generationjava.com> on 2002/09/13 17:16:38 UTC
[lang][collection][util] Open Symphony OSCore
I talked to Mike Cannon Brookes of Jira and Open Symphony fame. He
mentioned that we might want to look in the OSCore package there:
http://www.opensymphony.com/oscore
and consider aggregating in any applicable works in there. I took a quick
look at TextUtils and expect to roll a few methods in at some stage.
Thought I'd let you all know that it's open season on OSCore :)
I was going to reimplement the TextUtils ones as they were quite light, at
least the first ones I was considering, but I think we could probably
discuss a formal submission of something if there was something complex
that looked like a good fit.
Another thing we could do is provide an API map showing which Jakarta
Commons classes could easily replace theirs. They might be interested.
Licence wise, it's a modified Apache, so hopefully compatible.
Hen
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [lang][util] GUIDs: was Open Symphony OSCore
Posted by Stephen Colebourne <sc...@btopenworld.com>.
All your points are well made. It was late and I wasn't thinking straight
;-)
I think I agree that using [lang] is better than using [util], which isn't
really going places.
IMHO:
[lang] = java.lang helpers + java.util helpers - java.util Collection
helpers
Stephen
From: "Steve Downey" <st...@netfolio.com>
On Friday 13 September 2002 06:50 pm, Stephen Colebourne wrote:
> My point is that the identifier generators in pattern shouldn't be in
> [pattern]. But equally, given the dependencies on security and logging,
> your UUID code can't be in [lang].
>
Logging is avoidable. And java.lang itself has dependencies on
java.security.
As well as java.util, java.io, and a bunch of others. Use of the rest of the
standard API shouldn't exclude a class. Otherwise CompareToBuilder will need
to go elsewhere, since Comparator is in java.util. [reductio ad absurdum
arguments never work with me, either]
The java.security dependency is internal. It's actually a dependency on
SecureRandom, which has been in place since JDK 1.1.8 (at least).
It really does belong in a 'util' package, for the same reasons that Date,
Calendar, Properties, Random, ... are in java.util. They're foundational,
but
not language support. I'm arguing that we're already putting those classes
into commons.lang. Except for collections. Which Sun should have separated
out, anyway.
> This leaves [util] or a new [identifier] package. This is the recurring
> problem with [util], in that a collection of useful utilities doesn't make
> a releaseable project.
>
> If it was a separate [identifier] project, it could include the typesafe
> class given below, plus the other implementations of identifiers from
> [pattern]. It would depend on [lang] and [pattern]. Longer term it would
be
> included in the core.jar combined build.
You can't include the typesafe class. If you do, it's not typesafe. <g>
The idea is that concrete types that need a unique identifier declare their
own ID class whose supertype is Object. Otherwise you end up with APIs that
take generic IDs that should take only a specific types.
>
> Stephen
>
> BTW: You left a netfolio constant in your attachment ;-)
>
Yeah, I know. But getting rid of it would have required more surgery than I
was willing to do at the moment. The right thing to do is to add a namespace
parameter to fromReadableString().
--
To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
For additional commands, e-mail:
<ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [lang][util] GUIDs: was Open Symphony OSCore
Posted by Steve Downey <st...@netfolio.com>.
On Friday 13 September 2002 06:50 pm, Stephen Colebourne wrote:
>
>
> My point is that the identifier generators in pattern shouldn't be in
> [pattern]. But equally, given the dependencies on security and logging,
> your UUID code can't be in [lang].
>
Logging is avoidable. And java.lang itself has dependencies on java.security.
As well as java.util, java.io, and a bunch of others. Use of the rest of the
standard API shouldn't exclude a class. Otherwise CompareToBuilder will need
to go elsewhere, since Comparator is in java.util. [reductio ad absurdum
arguments never work with me, either]
The java.security dependency is internal. It's actually a dependency on
SecureRandom, which has been in place since JDK 1.1.8 (at least).
It really does belong in a 'util' package, for the same reasons that Date,
Calendar, Properties, Random, ... are in java.util. They're foundational, but
not language support. I'm arguing that we're already putting those classes
into commons.lang. Except for collections. Which Sun should have separated
out, anyway.
> This leaves [util] or a new [identifier] package. This is the recurring
> problem with [util], in that a collection of useful utilities doesn't make
> a releaseable project.
>
> If it was a separate [identifier] project, it could include the typesafe
> class given below, plus the other implementations of identifiers from
> [pattern]. It would depend on [lang] and [pattern]. Longer term it would be
> included in the core.jar combined build.
You can't include the typesafe class. If you do, it's not typesafe. <g>
The idea is that concrete types that need a unique identifier declare their
own ID class whose supertype is Object. Otherwise you end up with APIs that
take generic IDs that should take only a specific types.
>
> Stephen
>
> BTW: You left a netfolio constant in your attachment ;-)
>
Yeah, I know. But getting rid of it would have required more surgery than I
was willing to do at the moment. The right thing to do is to add a namespace
parameter to fromReadableString().
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [lang][util] GUIDs: was Open Symphony OSCore
Posted by Stephen Colebourne <sc...@btopenworld.com>.
From: "Steve Downey" <st...@netfolio.com>
> I don't think they should go into Pattern, although pattern would use
them.
> They're a little more fundemental than pattern. In my system, they're in
> util, but the sandbox util is being spread across many packages.
>
> I've put them into lang in what I've attached. They aren't to dissimilar
in
> spirit to RandomStringUtils. Although they do have dependencies outside of
> java.lang. In particular java.security. And logging, at the moment, is JDK
> 1.4. Logging could be dropped. It's only where exceptions are thrown, and
the
> information could be carried in the exception.
My point is that the identifier generators in pattern shouldn't be in
[pattern]. But equally, given the dependencies on security and logging, your
UUID code can't be in [lang].
This leaves [util] or a new [identifier] package. This is the recurring
problem with [util], in that a collection of useful utilities doesn't make a
releaseable project.
If it was a separate [identifier] project, it could include the typesafe
class given below, plus the other implementations of identifiers from
[pattern]. It would depend on [lang] and [pattern]. Longer term it would be
included in the core.jar combined build.
Stephen
BTW: You left a netfolio constant in your attachment ;-)
> I will also say that I've found, in practice, using UUIDs in raw form can
be
> very dangerous. You lose type safety. A UUID in an API conveys all the
safety
> of Object, or (void*) in C. In use I wrap (not inherit) them like so:
public class StrategyID implements Serializable {
private UUID id;
public StrategyID() {
setID(new UUID());
}
public StrategyID(UUID id) {
setID(id);
}
public StrategyID(String id) {
setID(new UUID(id));
}
public void setID(UUID id) {
this.id = id;
}
public UUID getID() {
return id;
}
public String toString() {
return id.toString();
}
public int hashCode() {
return id.hashCode();
}
public boolean equals(Object o) {
if (o == this)
return true;
if (!(o instanceof StrategyID))
return false;
StrategyID rhs = (StrategyID) o;
return this.getID().equals(rhs.getID());
}
}
On Friday 13 September 2002 04:18 pm, Stephen Colebourne wrote:
> Two points:
> 1) We have been a little slow in getting all the code offered from Avalon
> included in commons. We have to be careful not to take too much on.
>
> 2) I'm not certain as to which of the OSCore methods fit with commons yet.
>
> Having said that, here's a first look:
> BeanUtils to [beanutils]
> Data/DataUtil is a little odd. If the use is explained, maybe [util]
> DateUtil could go with [lang]s upcoming date code.
> FileUtils to [io]
> GUID would fit with the identifier factories in [pattern]. (Although they
> shouldn't be in pattern)
> TextUtils contains a lot of HTML specific methods which don't apply to
> [lang].
> XMLUtils might fit with [util] but it adds to the dependencies.
>
> Stephen
>
> ----- Original Message -----
> From: "Daniel Rall" <dl...@finemaltcoding.com>
> To: "Jakarta Commons Developers List" <co...@jakarta.apache.org>
> Sent: Friday, September 13, 2002 6:52 PM
> Subject: Re: [lang][collection][util] Open Symphony OSCore
>
> > Henri Yandell <ba...@generationjava.com> writes:
> > > I talked to Mike Cannon Brookes of Jira and Open Symphony fame. He
> > > mentioned that we might want to look in the OSCore package there:
> > >
> > > http://www.opensymphony.com/oscore
> > >
> > > and consider aggregating in any applicable works in there. I took a
>
> quick
>
> > > look at TextUtils and expect to roll a few methods in at some stage.
> > > Thought I'd let you all know that it's open season on OSCore :)
> > >
> > > I was going to reimplement the TextUtils ones as they were quite
light,
>
> at
>
> > > least the first ones I was considering, but I think we could probably
> > > discuss a formal submission of something if there was something
complex
> > > that looked like a good fit.
> > >
> > > Another thing we could do is provide an API map showing which Jakarta
> > > Commons classes could easily replace theirs. They might be interested.
> > >
> > > Licence wise, it's a modified Apache, so hopefully compatible.
> >
> > Henri, sounds good. Does this mean we should branch? It seems like
> > quite a bit of functionality is getting added in between beta and
> > release candidate (though you guys are doing a great job with the unit
> > tests!).
> > --
> >
> > Daniel Rall <dl...@finemaltcoding.com>
> >
> > --
> > To unsubscribe, e-mail:
>
> <ma...@jakarta.apache.org>
>
> > For additional commands, e-mail:
>
> <ma...@jakarta.apache.org>
----------------------------------------------------------------------------
----
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [lang][util] GUIDs: was Open Symphony OSCore
Posted by Steve Downey <st...@netfolio.com>.
I took a quick look, and the GUID's aren't. It's a stringification in base 36
of a 160 bit random number. A nice random identifier, to be sure, but it's
not a GUID.
A GUID is a specific form of a DCE UUID. And DCE UUID's have a fairly specific
internal structure. The best reference is here
http://ftp.ics.uci.edu/pub/ietf/webdav/uuid-guid/draft-leach-uuids-guids-01.txt
Althought the draft is expired, parts were adopted into the DCE spec, and
parts into the WebDAV spec (RFC 2518)
The actual DCE spec is here:
http://www.opengroup.org/onlinepubs/9629399/apdxa.htm
(I know a couple people who do real DCE work. They refer to the Leach I-D. DCE
took what they needed. Then the IETF decided not to standardise UUIDs, since
there was an ISO standard that defined them. Typical standardese muddle.)
Now, I wouldn't be complaining if I didn't have a solution. I use UUIDs
extensively. And the class that implements them is pretty good. It does need
work in the javadocs.
I don't think they should go into Pattern, although pattern would use them.
They're a little more fundemental than pattern. In my system, they're in
util, but the sandbox util is being spread across many packages.
I've put them into lang in what I've attached. They aren't to dissimilar in
spirit to RandomStringUtils. Although they do have dependencies outside of
java.lang. In particular java.security. And logging, at the moment, is JDK
1.4. Logging could be dropped. It's only where exceptions are thrown, and the
information could be carried in the exception.
I will also say that I've found, in practice, using UUIDs in raw form can be
very dangerous. You lose type safety. A UUID in an API conveys all the safety
of Object, or (void*) in C. In use I wrap (not inherit) them like so:
public class StrategyID implements Serializable {
private UUID id;
public StrategyID() {
setID(new UUID());
}
public StrategyID(UUID id) {
setID(id);
}
public StrategyID(String id) {
setID(new UUID(id));
}
public void setID(UUID id) {
this.id = id;
}
public UUID getID() {
return id;
}
public String toString() {
return id.toString();
}
public int hashCode() {
return id.hashCode();
}
public boolean equals(Object o) {
if (o == this)
return true;
if (!(o instanceof StrategyID))
return false;
StrategyID rhs = (StrategyID) o;
return this.getID().equals(rhs.getID());
}
}
On Friday 13 September 2002 04:18 pm, Stephen Colebourne wrote:
> Two points:
> 1) We have been a little slow in getting all the code offered from Avalon
> included in commons. We have to be careful not to take too much on.
>
> 2) I'm not certain as to which of the OSCore methods fit with commons yet.
>
> Having said that, here's a first look:
> BeanUtils to [beanutils]
> Data/DataUtil is a little odd. If the use is explained, maybe [util]
> DateUtil could go with [lang]s upcoming date code.
> FileUtils to [io]
> GUID would fit with the identifier factories in [pattern]. (Although they
> shouldn't be in pattern)
> TextUtils contains a lot of HTML specific methods which don't apply to
> [lang].
> XMLUtils might fit with [util] but it adds to the dependencies.
>
> Stephen
>
> ----- Original Message -----
> From: "Daniel Rall" <dl...@finemaltcoding.com>
> To: "Jakarta Commons Developers List" <co...@jakarta.apache.org>
> Sent: Friday, September 13, 2002 6:52 PM
> Subject: Re: [lang][collection][util] Open Symphony OSCore
>
> > Henri Yandell <ba...@generationjava.com> writes:
> > > I talked to Mike Cannon Brookes of Jira and Open Symphony fame. He
> > > mentioned that we might want to look in the OSCore package there:
> > >
> > > http://www.opensymphony.com/oscore
> > >
> > > and consider aggregating in any applicable works in there. I took a
>
> quick
>
> > > look at TextUtils and expect to roll a few methods in at some stage.
> > > Thought I'd let you all know that it's open season on OSCore :)
> > >
> > > I was going to reimplement the TextUtils ones as they were quite light,
>
> at
>
> > > least the first ones I was considering, but I think we could probably
> > > discuss a formal submission of something if there was something complex
> > > that looked like a good fit.
> > >
> > > Another thing we could do is provide an API map showing which Jakarta
> > > Commons classes could easily replace theirs. They might be interested.
> > >
> > > Licence wise, it's a modified Apache, so hopefully compatible.
> >
> > Henri, sounds good. Does this mean we should branch? It seems like
> > quite a bit of functionality is getting added in between beta and
> > release candidate (though you guys are doing a great job with the unit
> > tests!).
> > --
> >
> > Daniel Rall <dl...@finemaltcoding.com>
> >
> > --
> > To unsubscribe, e-mail:
>
> <ma...@jakarta.apache.org>
>
> > For additional commands, e-mail:
>
> <ma...@jakarta.apache.org>
Re: [lang][util] Open Symphony OSCore
Posted by Henri Yandell <ba...@generationjava.com>.
On Fri, 13 Sep 2002, Stephen Colebourne wrote:
> Two points:
> 1) We have been a little slow in getting all the code offered from Avalon
> included in commons. We have to be careful not to take too much on.
It'll continue to go slowly, takes time for such a large chunk of code to
be picked over like the vultures we are :) Also, there's no reason to
accomodate code just because it could be added in this case.
>
> 2) I'm not certain as to which of the OSCore methods fit with commons yet.
>
> Having said that, here's a first look:
> BeanUtils to [beanutils]
> Data/DataUtil is a little odd. If the use is explained, maybe [util]
> DateUtil could go with [lang]s upcoming date code.
> FileUtils to [io]
> GUID would fit with the identifier factories in [pattern]. (Although they
> shouldn't be in pattern)
> TextUtils contains a lot of HTML specific methods which don't apply to
> [lang].
> XMLUtils might fit with [util] but it adds to the dependencies.
Anything that isn't a clean fit can happily be ignored.
Hen
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [lang][util] Open Symphony OSCore
Posted by Stephen Colebourne <sc...@btopenworld.com>.
Two points:
1) We have been a little slow in getting all the code offered from Avalon
included in commons. We have to be careful not to take too much on.
2) I'm not certain as to which of the OSCore methods fit with commons yet.
Having said that, here's a first look:
BeanUtils to [beanutils]
Data/DataUtil is a little odd. If the use is explained, maybe [util]
DateUtil could go with [lang]s upcoming date code.
FileUtils to [io]
GUID would fit with the identifier factories in [pattern]. (Although they
shouldn't be in pattern)
TextUtils contains a lot of HTML specific methods which don't apply to
[lang].
XMLUtils might fit with [util] but it adds to the dependencies.
Stephen
----- Original Message -----
From: "Daniel Rall" <dl...@finemaltcoding.com>
To: "Jakarta Commons Developers List" <co...@jakarta.apache.org>
Sent: Friday, September 13, 2002 6:52 PM
Subject: Re: [lang][collection][util] Open Symphony OSCore
> Henri Yandell <ba...@generationjava.com> writes:
>
> > I talked to Mike Cannon Brookes of Jira and Open Symphony fame. He
> > mentioned that we might want to look in the OSCore package there:
> >
> > http://www.opensymphony.com/oscore
> >
> > and consider aggregating in any applicable works in there. I took a
quick
> > look at TextUtils and expect to roll a few methods in at some stage.
> > Thought I'd let you all know that it's open season on OSCore :)
> >
> > I was going to reimplement the TextUtils ones as they were quite light,
at
> > least the first ones I was considering, but I think we could probably
> > discuss a formal submission of something if there was something complex
> > that looked like a good fit.
> >
> > Another thing we could do is provide an API map showing which Jakarta
> > Commons classes could easily replace theirs. They might be interested.
> >
> > Licence wise, it's a modified Apache, so hopefully compatible.
>
> Henri, sounds good. Does this mean we should branch? It seems like
> quite a bit of functionality is getting added in between beta and
> release candidate (though you guys are doing a great job with the unit
> tests!).
> --
>
> Daniel Rall <dl...@finemaltcoding.com>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [lang] Release Was: OSCore
Posted by Daniel Rall <dl...@finemaltcoding.com>.
"Stephen Colebourne" <sc...@btopenworld.com> writes:
> The exception issues must be sorted before 1.0.
Sounds like we're all in agreement on that one. :)
> The builder subpackage makes it easy to exclude or include as desired. I
> would prefer to see all four builders in there before the release, as this
> shouldn't take long now.
Sounds good.
> Other than that, the package is ready to roll subject to release
> notes/status.html etc. Whatever, we really do need to cut the
> release so we can move on to reflection.
I would very much like to see at least a release candidate tagged. We
could do that sooner, and work on release notes et al between then and
the tagging of the final.
--
Daniel Rall <dl...@finemaltcoding.com>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [lang] Release Was: OSCore
Posted by Stephen Colebourne <sc...@btopenworld.com>.
The exception issues must be sorted before 1.0.
The builder subpackage makes it easy to exclude or include as desired. I
would prefer to see all four builders in there before the release, as this
shouldn't take long now.
Other than that, the package is ready to roll subject to release
notes/status.html etc. Whatever, we really do need to cut the release so we
can move on to reflection.
Stephen
----- Original Message -----
From: "Steven Caswell" <st...@caswell.name>
> I've got a JDK 1.3.1/1.4 version issue to resolve with the
> NestedException stuff. I plan to look at that over the weekend. IMHO it
> should be resolved before the release.
>
>
> Steven Caswell
> steven@caswell.name
> a.k.a Mungo Knotwise of Michel Delving
> "One ring to rule them all, one ring to find them..."
>
>
> > -----Original Message-----
> > From: Henri Yandell [mailto:bayard@generationjava.com]
> > Sent: Friday, September 13, 2002 1:02 PM
> > To: Jakarta Commons Developers List
> > Subject: Release Was: OSCore
> >
> >
> > There's no need to be rushing it.
> >
> > I'm a bit unsure of where we are in the release as the
> > Builders have been added, but also the NetstedException work
> > seems to have been done. [I've been focused on String
> > Taglib's impending release :) ]
> >
> > Are the builders planned for release, or will we be ignoring
> > them when the release package is built??
> >
> > Are we ready for release??
> >
> > Hen
> >
> >
> >
> > On 13 Sep 2002, Daniel Rall wrote:
> >
> > > Henri Yandell <ba...@generationjava.com> writes:
> > >
> > > > I talked to Mike Cannon Brookes of Jira and Open Symphony
> > fame. He
> > > > mentioned that we might want to look in the OSCore package there:
> > > >
> > > > http://www.opensymphony.com/oscore
> > > >
> > > > and consider aggregating in any applicable works in
> > there. I took a
> > > > quick look at TextUtils and expect to roll a few methods
> > in at some
> > > > stage. Thought I'd let you all know that it's open season
> > on OSCore
> > > > :)
> > > >
> > > > I was going to reimplement the TextUtils ones as they were quite
> > > > light, at least the first ones I was considering, but I think we
> > > > could probably discuss a formal submission of something
> > if there was
> > > > something complex that looked like a good fit.
> > > >
> > > > Another thing we could do is provide an API map showing which
> > > > Jakarta Commons classes could easily replace theirs. They
> > might be
> > > > interested.
> > > >
> > > > Licence wise, it's a modified Apache, so hopefully compatible.
> > >
> > > Henri, sounds good. Does this mean we should branch? It
> > seems like
> > > quite a bit of functionality is getting added in between beta and
> > > release candidate (though you guys are doing a great job
> > with the unit
> > > tests!).
> > > --
> > >
> > > Daniel Rall <dl...@finemaltcoding.com>
> > >
> > > --
> > > To unsubscribe, e-mail:
> > <mailto:commons-dev-> unsubscribe@jakarta.apache.org>
> > > For
> > additional commands,
> > e-mail:
> > > <ma...@jakarta.apache.org>
> > >
> > >
> >
> >
> > --
> > To unsubscribe, e-mail:
> > <mailto:commons-dev-> unsubscribe@jakarta.apache.org>
> > For
> > additional commands,
> > e-mail: <ma...@jakarta.apache.org>
> >
> >
>
>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Release Was: OSCore
Posted by Steven Caswell <st...@caswell.name>.
I've got a JDK 1.3.1/1.4 version issue to resolve with the
NestedException stuff. I plan to look at that over the weekend. IMHO it
should be resolved before the release.
Steven Caswell
steven@caswell.name
a.k.a Mungo Knotwise of Michel Delving
"One ring to rule them all, one ring to find them..."
> -----Original Message-----
> From: Henri Yandell [mailto:bayard@generationjava.com]
> Sent: Friday, September 13, 2002 1:02 PM
> To: Jakarta Commons Developers List
> Subject: Release Was: OSCore
>
>
> There's no need to be rushing it.
>
> I'm a bit unsure of where we are in the release as the
> Builders have been added, but also the NetstedException work
> seems to have been done. [I've been focused on String
> Taglib's impending release :) ]
>
> Are the builders planned for release, or will we be ignoring
> them when the release package is built??
>
> Are we ready for release??
>
> Hen
>
>
>
> On 13 Sep 2002, Daniel Rall wrote:
>
> > Henri Yandell <ba...@generationjava.com> writes:
> >
> > > I talked to Mike Cannon Brookes of Jira and Open Symphony
> fame. He
> > > mentioned that we might want to look in the OSCore package there:
> > >
> > > http://www.opensymphony.com/oscore
> > >
> > > and consider aggregating in any applicable works in
> there. I took a
> > > quick look at TextUtils and expect to roll a few methods
> in at some
> > > stage. Thought I'd let you all know that it's open season
> on OSCore
> > > :)
> > >
> > > I was going to reimplement the TextUtils ones as they were quite
> > > light, at least the first ones I was considering, but I think we
> > > could probably discuss a formal submission of something
> if there was
> > > something complex that looked like a good fit.
> > >
> > > Another thing we could do is provide an API map showing which
> > > Jakarta Commons classes could easily replace theirs. They
> might be
> > > interested.
> > >
> > > Licence wise, it's a modified Apache, so hopefully compatible.
> >
> > Henri, sounds good. Does this mean we should branch? It
> seems like
> > quite a bit of functionality is getting added in between beta and
> > release candidate (though you guys are doing a great job
> with the unit
> > tests!).
> > --
> >
> > Daniel Rall <dl...@finemaltcoding.com>
> >
> > --
> > To unsubscribe, e-mail:
> <mailto:commons-dev-> unsubscribe@jakarta.apache.org>
> > For
> additional commands,
> e-mail:
> > <ma...@jakarta.apache.org>
> >
> >
>
>
> --
> To unsubscribe, e-mail:
> <mailto:commons-dev-> unsubscribe@jakarta.apache.org>
> For
> additional commands,
> e-mail: <ma...@jakarta.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Release Was: OSCore
Posted by Henri Yandell <ba...@generationjava.com>.
There's no need to be rushing it.
I'm a bit unsure of where we are in the release as the Builders have been
added, but also the NetstedException work seems to have been done. [I've
been focused on String Taglib's impending release :) ]
Are the builders planned for release, or will we be ignoring them when the
release package is built??
Are we ready for release??
Hen
On 13 Sep 2002, Daniel Rall wrote:
> Henri Yandell <ba...@generationjava.com> writes:
>
> > I talked to Mike Cannon Brookes of Jira and Open Symphony fame. He
> > mentioned that we might want to look in the OSCore package there:
> >
> > http://www.opensymphony.com/oscore
> >
> > and consider aggregating in any applicable works in there. I took a quick
> > look at TextUtils and expect to roll a few methods in at some stage.
> > Thought I'd let you all know that it's open season on OSCore :)
> >
> > I was going to reimplement the TextUtils ones as they were quite light, at
> > least the first ones I was considering, but I think we could probably
> > discuss a formal submission of something if there was something complex
> > that looked like a good fit.
> >
> > Another thing we could do is provide an API map showing which Jakarta
> > Commons classes could easily replace theirs. They might be interested.
> >
> > Licence wise, it's a modified Apache, so hopefully compatible.
>
> Henri, sounds good. Does this mean we should branch? It seems like
> quite a bit of functionality is getting added in between beta and
> release candidate (though you guys are doing a great job with the unit
> tests!).
> --
>
> Daniel Rall <dl...@finemaltcoding.com>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [lang][collection][util] Open Symphony OSCore
Posted by Daniel Rall <dl...@finemaltcoding.com>.
Henri Yandell <ba...@generationjava.com> writes:
> I talked to Mike Cannon Brookes of Jira and Open Symphony fame. He
> mentioned that we might want to look in the OSCore package there:
>
> http://www.opensymphony.com/oscore
>
> and consider aggregating in any applicable works in there. I took a quick
> look at TextUtils and expect to roll a few methods in at some stage.
> Thought I'd let you all know that it's open season on OSCore :)
>
> I was going to reimplement the TextUtils ones as they were quite light, at
> least the first ones I was considering, but I think we could probably
> discuss a formal submission of something if there was something complex
> that looked like a good fit.
>
> Another thing we could do is provide an API map showing which Jakarta
> Commons classes could easily replace theirs. They might be interested.
>
> Licence wise, it's a modified Apache, so hopefully compatible.
Henri, sounds good. Does this mean we should branch? It seems like
quite a bit of functionality is getting added in between beta and
release candidate (though you guys are doing a great job with the unit
tests!).
--
Daniel Rall <dl...@finemaltcoding.com>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>