You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Jon Scott Stevens <jo...@latchkey.com> on 2002/12/15 21:37:54 UTC
GenerateUniqueId.java
http://cvs.apache.org/viewcvs.cgi/jakarta-commons-sandbox/util/src/java/org/
apache/commons/util/identifier/
You removed the GenerateUniqueId.java class and replaced it with some whole
subset of code which I'm sure is that much better, but the fact of the
matter is that there was other code which depended on GenerateUniqueId.java
being there and you didn't go and fix it (specifically the code in
commons-email). You need to learn how to do deprecation properly.
So, either put GenerateUniqueId.java back or fix commons-email and next time
please learn how to use deprecation properly.
-jon
--
StudioZ.tv /\ Bar/Nightclub/Entertainment
314 11th Street @ Folsom /\ San Francisco
http://studioz.tv/
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: GenerateUniqueId.java
Posted by Sam Ruby <ru...@apache.org>.
Henri Yandell wrote:
>
>>>In broader terms however:
>>>a) The status of both the [util] and [email] components within
>>>jakarta-commons-sandbox is that of unreleased code, no matter how stable.
>>>Deprecation is not required.
>>
>>Indefinately? Is that good for the [util], [email], commons, jakarta,
>>or the ASF?
>
> That unreleased code is considered to not be something which a user has a
> right to believe the ASF are maintaining? Definitely.
That wasn't the question I was asking.
Do you think it is good for the ASF to allow code to be remain in CVS
indefinately without ever having a release?
- Sam Ruby
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: GenerateUniqueId.java
Posted by Henri Yandell <ba...@generationjava.com>.
On Mon, 16 Dec 2002, Sam Ruby wrote:
> Stephen Colebourne wrote:
> >
> > In broader terms however:
> > a) The status of both the [util] and [email] components within
> > jakarta-commons-sandbox is that of unreleased code, no matter how stable.
> > Deprecation is not required.
>
> Indefinately? Is that good for the [util], [email], commons, jakarta,
> or the ASF?
That unreleased code is considered to not be something which a user has a
right to believe the ASF are maintaining? Definitely.
>
> > b) The [util] component is generally viewed as a 'dumping ground' for code
> > that doesn't fit in elsewhere, and might better be named 'misc' or
> > 'homeless'. The changes were designed to give [util] a chance of a release.
>
> ...dumped and homeless...
[util] is an oddball in that it is a dumping ground, effectively the
Commons of the Commons.
Raises another question. Is it right to cvs remove files or should they be
being 'trashcanned' in a more readable place? When a piece of code is
considered to be unwanted, rather than just a cvs remove in the day to day
action of a piece of code changing name etc.
> > c) Commons must have the right to make changes to code and manage its own
> > releases and components. This should apply whether it is code written
> > specifically for commons, or donated to commons from another jakarta
> > project. If this is not the case then commons is simply a 'dumping ground'
> > for other jakarta projects hoping to off-load maintainance, rather than a
> > vibrant community in its own right.
>
> Self-managed would be nice. Can you honestly say that's what we have now?
What you have now is a dichotomy between the owners of the code, ie) other
project members, and the people wanting to maintain and take the code
forward, ie) commons developers.
The charter suggests they should be one and the same, but they're not. I
think I'm a prime example of why not. I came to Commons from the Taglibs
project, and now spend far more time in Commons on Lang/Collections etc
than I do on the String Taglib. I imagine most people do the opposite to
me as the projects they come from are larger than the code they donate.
Jon's issue here is understandable from his side of the wedge, 1 class,
but I don't believe in it from the other side, lots of classes all being
merged, sifted and squeezed.
Incidentally, while I don't think Stephen is alluding to this, the charter
mentions that the PMC are meant to ratify every release etc. Is this being
done stealthily at the moment, will the PMC be doing it in the future [how
do we fit into that system?] or will that be removed from the charter?
Hen
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: GenerateUniqueId.java
Posted by Sam Ruby <ru...@apache.org>.
Stephen Colebourne wrote:
>
> In broader terms however:
> a) The status of both the [util] and [email] components within
> jakarta-commons-sandbox is that of unreleased code, no matter how stable.
> Deprecation is not required.
Indefinately? Is that good for the [util], [email], commons, jakarta,
or the ASF?
> b) The [util] component is generally viewed as a 'dumping ground' for code
> that doesn't fit in elsewhere, and might better be named 'misc' or
> 'homeless'. The changes were designed to give [util] a chance of a release.
...dumped and homeless...
> c) Commons must have the right to make changes to code and manage its own
> releases and components. This should apply whether it is code written
> specifically for commons, or donated to commons from another jakarta
> project. If this is not the case then commons is simply a 'dumping ground'
> for other jakarta projects hoping to off-load maintainance, rather than a
> vibrant community in its own right.
Self-managed would be nice. Can you honestly say that's what we have now?
- Sam Ruby
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: GenerateUniqueId.java
Posted by Incze Lajos <in...@mail.matav.hu>.
> > > I would like deprecation to happen for a time period before deletion, if
> > > the code was not part of a release, especially in Commons, where the code
> > > is by design meant to be used by others. And the code base can be stable,
> > > without a release for a long time.
> > > </rant>
> >
> > Bless you dIon.
> >
> > More frequent releases and/or policies like you describe would help.
> >
> > But mostly, we need people to care and work together.
> >
>
> I agree that "working together" is important. IMHO, that includes a few
> more steps by the people that extract a reusable chunk of code from some
> other project into a sandbox module -- if the originating project adopts a
> dependency on a sandbox project, there's a fair degree of "shame on you"
> for them as well as for people working on the sandbox library.
>
> And yes, I'm currently in the same boat on one of my big projects (Struts
> HEAD depends on commons-resources from the sandbox). The difference is
> that there is no way I'd ever do a final release of Struts 1.1 without
> having commons-resources promoted to the Commons and released (or removing
> the dependency).
>
> > - Sam Ruby
> >
>
> Craig McClanahan
>
(An outsider's point.)
What about the IBM eclipse practice? They have
- nightly builds (same way as gump)
- intergration builds (this can be the mediator concept between realeases
and simple builds and they have them cca. every week)
- milestone releases (dev releases in jakarta parlance)
- beta releases
- and releases.
incze
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: GenerateUniqueId.java
Posted by "Craig R. McClanahan" <cr...@apache.org>.
On Mon, 16 Dec 2002, Sam Ruby wrote:
> Date: Mon, 16 Dec 2002 20:54:40 -0500
> From: Sam Ruby <ru...@apache.org>
> Reply-To: Jakarta Commons Developers List <co...@jakarta.apache.org>
> To: commons-dev@jakarta.apache.org
> Subject: Re: GenerateUniqueId.java
>
> dion@multitask.com.au wrote:
> > <rant>
> > I think Gump is the best tool we have for doing this, and we need to be
> > nicer citizens.
> >
> > Having just been bitten by HttpClient deleting methods that have been
> > available for months in CVS, I'm starting to question the current process
> > of only deprecating if a method has been available in a 'release' product.
> >
> > I would like deprecation to happen for a time period before deletion, if
> > the code was not part of a release, especially in Commons, where the code
> > is by design meant to be used by others. And the code base can be stable,
> > without a release for a long time.
> > </rant>
>
> Bless you dIon.
>
> More frequent releases and/or policies like you describe would help.
>
> But mostly, we need people to care and work together.
>
I agree that "working together" is important. IMHO, that includes a few
more steps by the people that extract a reusable chunk of code from some
other project into a sandbox module -- if the originating project adopts a
dependency on a sandbox project, there's a fair degree of "shame on you"
for them as well as for people working on the sandbox library.
And yes, I'm currently in the same boat on one of my big projects (Struts
HEAD depends on commons-resources from the sandbox). The difference is
that there is no way I'd ever do a final release of Struts 1.1 without
having commons-resources promoted to the Commons and released (or removing
the dependency).
> - Sam Ruby
>
Craig McClanahan
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: GenerateUniqueId.java
Posted by Henri Yandell <ba...@generationjava.com>.
On Mon, 16 Dec 2002, Sam Ruby wrote:
> dion@multitask.com.au wrote:
> > <rant>
> > Having just been bitten by HttpClient deleting methods that have been
> > available for months in CVS, I'm starting to question the current process
> > of only deprecating if a method has been available in a 'release' product.
> >
> > I would like deprecation to happen for a time period before deletion, if
> > the code was not part of a release, especially in Commons, where the code
> > is by design meant to be used by others. And the code base can be stable,
> > without a release for a long time.
> > </rant>
>
> Bless you dIon.
>
> More frequent releases and/or policies like you describe would help.
More frequent releases would be a very good thing, but I think it would
lead to a diminishing in the focus spent on a release.
Maybe development releases should be more automatically pushed. We release
a 1.0.1-dev automatically and it's really just a cvs snapshot.
Another idea is that we could have a larger release a la Combo, which
might allow the effort of a release to be dealt with in one component. I
think this would fail though.
> But mostly, we need people to care and work together.
Agreed. Doesn't remove disagreements, but the biggest problem with code is
usually that people don't care about it.
Hen
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: GenerateUniqueId.java
Posted by Sam Ruby <ru...@apache.org>.
dion@multitask.com.au wrote:
> <rant>
> I think Gump is the best tool we have for doing this, and we need to be
> nicer citizens.
>
> Having just been bitten by HttpClient deleting methods that have been
> available for months in CVS, I'm starting to question the current process
> of only deprecating if a method has been available in a 'release' product.
>
> I would like deprecation to happen for a time period before deletion, if
> the code was not part of a release, especially in Commons, where the code
> is by design meant to be used by others. And the code base can be stable,
> without a release for a long time.
> </rant>
Bless you dIon.
More frequent releases and/or policies like you describe would help.
But mostly, we need people to care and work together.
- Sam Ruby
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: GenerateUniqueId.java
Posted by Sam Ruby <ru...@apache.org>.
dion@multitask.com.au wrote:
> Henri Yandell <ba...@generationjava.com> wrote on 17/12/2002 12:31:41 PM:
>
>>It's still stealthware to me, but that's my fault for not having found
>>where on the website it is linked in and checking it regularly.
>
> Emails on failures are sent to the -dev lists....
http://marc.theaimsgroup.com/?t=102095231800003&r=1&w=2
- Sam Ruby
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: GenerateUniqueId.java
Posted by Sam Ruby <ru...@apache.org>.
Henri Yandell wrote:
>
> Sounds good. Where are the nag addresses documented? [Just so I can know
> who the Nag person is for projects I work on, it's something I'm happy to
> do, so if they're notkeen on it I can volunteer]
http://cvs.apache.org/viewcvs/jakarta-alexandria/proposal/gump/project/
Patches welcome. mailto:alexandria-dev@jakarta.apache.org
- Sam Ruby
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: GenerateUniqueId.java
Posted by Henri Yandell <ba...@generationjava.com>.
On Tue, 17 Dec 2002 dion@multitask.com.au wrote:
> Henri Yandell <ba...@generationjava.com> wrote on 17/12/2002 03:26:08 PM:
> > On Tue, 17 Dec 2002 dion@multitask.com.au wrote:
> >
> > > Henri Yandell <ba...@generationjava.com> wrote on 17/12/2002 12:31:41
> PM:
> > I do have one request here. The emails do not specify who should be
> talked
> > to in an effort to fix the build.
>
> ? The -dev list gets emailed. The developer(s) should be listening.
>
> > Do the Gump people listen to all the lists they build, is their a gump
> > list? I'd normally expect to reply to the email..
>
> Then you would have replied to me :) The nag has me as the from address.
Sounds good. Where are the nag addresses documented? [Just so I can know
who the Nag person is for projects I work on, it's something I'm happy to
do, so if they're notkeen on it I can volunteer]
> [snip]
> > > > -1
> > >
> > > Some explanation/technical justification please?
> >
> > I don't think a project which lacks a stable core of classes should
> become
> > a Commons Project.
>
> Core set of classes be damned. It's more important to have developers
> working together on making things better.
Sure, but [util] has neither :) If a project has developers working avidly
on it, I would expect a core set of classes pronto.
> > Thus the work at building some functionality into util with the
> identifier
> > sub-package.
> >
> > > > > 2) Email should be moved to commons proper.
> > > >
> > > > +0 [assuming it is current and not out of date, and that it is ready
> > > > codewise]
> > >
> > > Can you clarify what 'ready' is?
> >
> > i) Does it have a suitable level of javadoc. Not enough for an actual
> > release, but the bare minimum.
> Who cares about javadoc if there isn't usage documentation. For a 'common'
> component, isn't that more important?
Definitely. http://www.flamefew.net/~hen/jakarta-tutorial.html hopefully
shows that I'm in agreement here, even if it's a slow process.
> > ii) Does it have maturity. That is, has it spent some time in the
> sandbox
> > while the developers use it, modified versions or extended versions
> > in other projects.
> Maybe the code's been used to death before getting into commons?
So it has maturity.
> > iii) Does the project contain enough in the way of Unit Tests to show
> that
> > the developers are serious about testing.
> Is this a particular %age Code coverage?
If a number is needed. Really I just think it's a devotion to
professionalism that Apache demands. Having UTs is a definite show of
this.
> > iv) Is there a community, or is it a single developer. Does it have
> link
> > to another project which will show a scope for its community
> growth.
> > v) Does it have a webpage yet?
> Web pages are easy to generate....and harder to keep up to date. Check
> http://jakarta.apache.org/commons/, it's got old components listed. Or
> http://jakarta.apache.org/commons/lang.html which has virtually no
> documentation on using the library. Which sort of defeats the purpose of
> making a reusable library....
Yep, criticism accepted. Not having a webpage though shows that the
project has not even begun to think about how to communicate to its future
users.
What are the old components on commons?
> [snip]
> > > <devils-advocate>
> > > Ok, but for what purpose. It's obvious no developers are building it
> from
> > > source on a regular basis. Given you'd rather not move it to commons,
> why
> > > don't we just delete it and move the code that's needed back where
> they
> > > came from?
> > > </devils-advocate>
> >
> > Definitely a good view. It seems there are two options, kill it or find
> > functionality for it.
> >
> > I'd say there are 7 bits in there:
> >
> > 1) BitField => Collections possibly. or Lang.
> Yep.
Kay. I'll make a move for this to head in one of those directions. See if
people there are happy.
> > 2) Interpolator => Kill.
> > 3) StopWatch ?
This is the only thing in Util which really leaps out as util to me [which
is ironic as it's originally from a library of mine called test, though
I've seen it mentioned in books as well].
> > 4) WordWrapUtils => Lang's sandbox. It's a break off of StringUtils
> which
> > was not very stable at release time.
> Sounds like it belongs back in StringUtils.
Yeah, has crappy bugs that need rewriting. I have to do this for String
Taglib so it's fast climbing my todo list.
> > 5) XmlUtils => Kill.
> > 6) identifier/ => Find somewhere
> > 7) GenerateUniqueId => Help commons-email with how to use identifier, or
> > commons-email contains this code
> I've fixed commons-email to use identifier.
Are yourself or Jon satisified that the identifier code happily replaces
the GUId code, or should we aim to replace it?
> I suppose the hassle is the lack of direction about util. It seems to be a
> dumping ground, which, IMHO, aint such a good thing. I was under the vague
> impression it, like lang, was a collection of helpers to go with
> java.util.....
It's supposed to be, but think about it. Most of java.util is the
Collection API. util.Date/Calendar vanish off into Lang or other projects
as Date is really a special type. Similar for Currency if any of us were
coding to 1.4. Sub-project things like util.zip/util.jar are currently
hiding away in io.compress [need moving, I don't know to where]. So it's
no surprise that Jakarta Util is now pretty empty [once lang, and io, and
others left... in fact the old jakarta.util probably = the commons core
that Stephen and I talk about].
To go further [now I have javadoc open]:
Event stuff would be in BeanUtils.
Resource stuff is in Resources(?) or in some i18n/text package in the
future.
It pretty much ends up that Util = Random, and that's really a Math class.
So java.util is pointless, and jakarta.util is even more so pointless.
I wonder if the java.util API is a dumping ground between the JDK creators
when they can't agree :)
Hen
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: GenerateUniqueId.java
Posted by di...@multitask.com.au.
Henri Yandell <ba...@generationjava.com> wrote on 17/12/2002 03:26:08 PM:
> On Tue, 17 Dec 2002 dion@multitask.com.au wrote:
>
> > Henri Yandell <ba...@generationjava.com> wrote on 17/12/2002 12:31:41
PM:
> >
> > > On Tue, 17 Dec 2002 dion@multitask.com.au wrote:
> > > > I'd like to see a move of both of these components to commons.
> > >
> > > I'd like to see there actually be code in util worthy of a commons
> > > project. Currently it's a tiny smattering of classes and while
there's
> > > nothing to say a project needs a certain size, you'd expect it to be
a
> > bit
> > > bigger.
> >
> > So when does it become worthy? What's the criteria being applied here?
>
> Ought to have Unit Tests? More than just 4 or 5 odd classes?
Nah...in that case most of Ant would never have gotten going. It takes a
while before reasonable unit testing is reached in most projects.
> I do have one request here. The emails do not specify who should be
talked
> to in an effort to fix the build.
? The -dev list gets emailed. The developer(s) should be listening.
> Do the Gump people listen to all the lists they build, is their a gump
> list? I'd normally expect to reply to the email..
Then you would have replied to me :) The nag has me as the from address.
[snip]
> > > -1
> >
> > Some explanation/technical justification please?
>
> I don't think a project which lacks a stable core of classes should
become
> a Commons Project.
Core set of classes be damned. It's more important to have developers
working together on making things better.
> Thus the work at building some functionality into util with the
identifier
> sub-package.
>
> > > > 2) Email should be moved to commons proper.
> > >
> > > +0 [assuming it is current and not out of date, and that it is ready
> > > codewise]
> >
> > Can you clarify what 'ready' is?
>
> i) Does it have a suitable level of javadoc. Not enough for an actual
> release, but the bare minimum.
Who cares about javadoc if there isn't usage documentation. For a 'common'
component, isn't that more important?
> ii) Does it have maturity. That is, has it spent some time in the
sandbox
> while the developers use it, modified versions or extended versions
> in other projects.
Maybe the code's been used to death before getting into commons?
> iii) Does the project contain enough in the way of Unit Tests to show
that
> the developers are serious about testing.
Is this a particular %age Code coverage?
> iv) Is there a community, or is it a single developer. Does it have
link
> to another project which will show a scope for its community
growth.
> v) Does it have a webpage yet?
Web pages are easy to generate....and harder to keep up to date. Check
http://jakarta.apache.org/commons/, it's got old components listed. Or
http://jakarta.apache.org/commons/lang.html which has virtually no
documentation on using the library. Which sort of defeats the purpose of
making a reusable library....
[snip]
> > <devils-advocate>
> > Ok, but for what purpose. It's obvious no developers are building it
from
> > source on a regular basis. Given you'd rather not move it to commons,
why
> > don't we just delete it and move the code that's needed back where
they
> > came from?
> > </devils-advocate>
>
> Definitely a good view. It seems there are two options, kill it or find
> functionality for it.
>
> I'd say there are 7 bits in there:
>
> 1) BitField => Collections possibly. or Lang.
Yep.
> 2) Interpolator => Kill.
> 3) StopWatch ?
> 4) WordWrapUtils => Lang's sandbox. It's a break off of StringUtils
which
> was not very stable at release time.
Sounds like it belongs back in StringUtils.
> 5) XmlUtils => Kill.
> 6) identifier/ => Find somewhere
> 7) GenerateUniqueId => Help commons-email with how to use identifier, or
> commons-email contains this code
I've fixed commons-email to use identifier.
I suppose the hassle is the lack of direction about util. It seems to be a
dumping ground, which, IMHO, aint such a good thing. I was under the vague
impression it, like lang, was a collection of helpers to go with
java.util.....
--
dIon Gillard, Multitask Consulting
Blog: http://www.freeroller.net/page/dion/Weblog
Work: http://www.multitask.com.au
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: GenerateUniqueId.java
Posted by Henri Yandell <ba...@generationjava.com>.
On Tue, 17 Dec 2002 dion@multitask.com.au wrote:
> Henri Yandell <ba...@generationjava.com> wrote on 17/12/2002 12:31:41 PM:
>
> > On Tue, 17 Dec 2002 dion@multitask.com.au wrote:
> > > I'd like to see a move of both of these components to commons.
> >
> > I'd like to see there actually be code in util worthy of a commons
> > project. Currently it's a tiny smattering of classes and while there's
> > nothing to say a project needs a certain size, you'd expect it to be a
> bit
> > bigger.
>
> So when does it become worthy? What's the criteria being applied here?
Ought to have Unit Tests? More than just 4 or 5 odd classes?
> > > > b) The [util] component is generally viewed as a 'dumping ground'
> for
> > > code
> > > > that doesn't fit in elsewhere, and might better be named 'misc' or
> > > > 'homeless'. The changes were designed to give [util] a chance of a
> > > release.
> > > How about moving it to commons rather than leaving it in sandbox?
> >
> > If it's ready, sure.
>
> Ready for?
Basically the above. If something lacks classes for a promotion from
sandbox, it suggests that it has a poor scope.
> > > <rant>
> > > I think Gump is the best tool we have for doing this, and we need to
> be
> > > nicer citizens.
> >
> > It's still stealthware to me, but that's my fault for not having found
> > where on the website it is linked in and checking it regularly.
> Emails on failures are sent to the -dev lists....
I do have one request here. The emails do not specify who should be talked
to in an effort to fix the build.
Do the Gump people listen to all the lists they build, is their a gump
list? I'd normally expect to reply to the email..
> > > Having just been bitten by HttpClient deleting methods that have been
> > > available for months in CVS, I'm starting to question the current
> process
> > > of only deprecating if a method has been available in a 'release'
> product.
> >
> > Changing this means that we need a new layer for playing in. Forcing
> > developers to consider any checked in code to be in a release cycle will
> > seriously hamper creativity/play.
>
> Well, if the code has been untouched for months, I'd consider that we
> should at least deprecate things before deleting them. But this is no
> substitute for releasing.
I'm definitely in favour of releasing.
> > > Proposals:
> > > 1) Util should be moved to commons proper.
> >
> > -1
>
> Some explanation/technical justification please?
I don't think a project which lacks a stable core of classes should become
a Commons Project.
Thus the work at building some functionality into util with the identifier
sub-package.
> > > 2) Email should be moved to commons proper.
> >
> > +0 [assuming it is current and not out of date, and that it is ready
> > codewise]
>
> Can you clarify what 'ready' is?
i) Does it have a suitable level of javadoc. Not enough for an actual
release, but the bare minimum.
ii) Does it have maturity. That is, has it spent some time in the sandbox
while the developers use it, modified versions or extended versions
in other projects.
iii) Does the project contain enough in the way of Unit Tests to show that
the developers are serious about testing.
iv) Is there a community, or is it a single developer. Does it have link
to another project which will show a scope for its community growth.
v) Does it have a webpage yet?
> > > Things to do:
> > > 1) Fix the ant and maven builds of both components so that they work.
> > > Having the gump build as the only one available, and the jars unable
> to be
> > > built from source is not acceptable.
> >
> > Will happily fix [util]'s ant and maven.
>
> <devils-advocate>
> Ok, but for what purpose. It's obvious no developers are building it from
> source on a regular basis. Given you'd rather not move it to commons, why
> don't we just delete it and move the code that's needed back where they
> came from?
> </devils-advocate>
Definitely a good view. It seems there are two options, kill it or find
functionality for it.
I'd say there are 7 bits in there:
1) BitField => Collections possibly. or Lang.
2) Interpolator => Kill.
3) StopWatch ?
4) WordWrapUtils => Lang's sandbox. It's a break off of StringUtils which
was not very stable at release time.
5) XmlUtils => Kill.
6) identifier/ => Find somewhere
7) GenerateUniqueId => Help commons-email with how to use identifier, or
commons-email contains this code
The death of Util might leave a gap. Should there be a loose structure for
holding 'usefulness'. ie) a waiting room. Or should this merely be a
series of patches etc in a holding space in Bugzilla/mail list.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: GenerateUniqueId.java
Posted by di...@multitask.com.au.
Henri Yandell <ba...@generationjava.com> wrote on 17/12/2002 12:31:41 PM:
> On Tue, 17 Dec 2002 dion@multitask.com.au wrote:
> > I'd like to see a move of both of these components to commons.
>
> I'd like to see there actually be code in util worthy of a commons
> project. Currently it's a tiny smattering of classes and while there's
> nothing to say a project needs a certain size, you'd expect it to be a
bit
> bigger.
So when does it become worthy? What's the criteria being applied here?
> > > b) The [util] component is generally viewed as a 'dumping ground'
for
> > code
> > > that doesn't fit in elsewhere, and might better be named 'misc' or
> > > 'homeless'. The changes were designed to give [util] a chance of a
> > release.
> > How about moving it to commons rather than leaving it in sandbox?
>
> If it's ready, sure.
Ready for?
> > <rant>
> > I think Gump is the best tool we have for doing this, and we need to
be
> > nicer citizens.
>
> It's still stealthware to me, but that's my fault for not having found
> where on the website it is linked in and checking it regularly.
Emails on failures are sent to the -dev lists....
> > Having just been bitten by HttpClient deleting methods that have been
> > available for months in CVS, I'm starting to question the current
process
> > of only deprecating if a method has been available in a 'release'
product.
>
> Changing this means that we need a new layer for playing in. Forcing
> developers to consider any checked in code to be in a release cycle will
> seriously hamper creativity/play.
Well, if the code has been untouched for months, I'd consider that we
should at least deprecate things before deleting them. But this is no
substitute for releasing.
> > I would like deprecation to happen for a time period before deletion,
if
> > the code was not part of a release, especially in Commons, where the
code
> > is by design meant to be used by others. And the code base can be
stable,
> > without a release for a long time.
> > </rant>
>
> Why doesn't the user just depend on a tagged date and not HEAD?
Even if they do, they will still eventually be bitten when they go to
upgrade. Gump is all about early warning.
> > Proposals:
> > 1) Util should be moved to commons proper.
>
> -1
Some explanation/technical justification please?
> > 2) Email should be moved to commons proper.
>
> +0 [assuming it is current and not out of date, and that it is ready
> codewise]
Can you clarify what 'ready' is?
> > Things to do:
> > 1) Fix the ant and maven builds of both components so that they work.
> > Having the gump build as the only one available, and the jars unable
to be
> > built from source is not acceptable.
>
> Will happily fix [util]'s ant and maven.
<devils-advocate>
Ok, but for what purpose. It's obvious no developers are building it from
source on a regular basis. Given you'd rather not move it to commons, why
don't we just delete it and move the code that's needed back where they
came from?
</devils-advocate>
--
dIon Gillard, Multitask Consulting
Blog: http://www.freeroller.net/page/dion/Weblog
Work: http://www.multitask.com.au
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: GenerateUniqueId.java
Posted by Henri Yandell <ba...@generationjava.com>.
On Tue, 17 Dec 2002 dion@multitask.com.au wrote:
> "Stephen Colebourne" <sc...@btopenworld.com> wrote on 17/12/2002
> 11:35:17 AM:
>
> [snip]
>
> > In broader terms however:
> > a) The status of both the [util] and [email] components within
> > jakarta-commons-sandbox is that of unreleased code, no matter how
> stable.
> > Deprecation is not required.
> Unfortunate, but true. It's the community part that's missing here.
>
> I'd like to see a move of both of these components to commons.
I'd like to see there actually be code in util worthy of a commons
project. Currently it's a tiny smattering of classes and while there's
nothing to say a project needs a certain size, you'd expect it to be a bit
bigger.
> > b) The [util] component is generally viewed as a 'dumping ground' for
> code
> > that doesn't fit in elsewhere, and might better be named 'misc' or
> > 'homeless'. The changes were designed to give [util] a chance of a
> release.
> How about moving it to commons rather than leaving it in sandbox?
If it's ready, sure.
> > c) Commons must have the right to make changes to code and manage its
> own
> > releases and components. This should apply whether it is code written
> > specifically for commons, or donated to commons from another jakarta
> > project. If this is not the case then commons is simply a 'dumping
> ground'
> > for other jakarta projects hoping to off-load maintainance, rather than
> a
> > vibrant community in its own right.
> Agreed, but like all code that is to be used and reused, we must consider
> the users of the software.
> <rant>
> I think Gump is the best tool we have for doing this, and we need to be
> nicer citizens.
It's still stealthware to me, but that's my fault for not having found
where on the website it is linked in and checking it regularly.
> Having just been bitten by HttpClient deleting methods that have been
> available for months in CVS, I'm starting to question the current process
> of only deprecating if a method has been available in a 'release' product.
Changing this means that we need a new layer for playing in. Forcing
developers to consider any checked in code to be in a release cycle will
seriously hamper creativity/play.
> I would like deprecation to happen for a time period before deletion, if
> the code was not part of a release, especially in Commons, where the code
> is by design meant to be used by others. And the code base can be stable,
> without a release for a long time.
> </rant>
Why doesn't the user just depend on a tagged date and not HEAD?
> Proposals:
> 1) Util should be moved to commons proper.
-1
> 2) Email should be moved to commons proper.
+0 [assuming it is current and not out of date, and that it is ready
codewise]
> Things to do:
> 1) Fix the ant and maven builds of both components so that they work.
> Having the gump build as the only one available, and the jars unable to be
> built from source is not acceptable.
Will happily fix [util]'s ant and maven.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: GenerateUniqueId.java
Posted by di...@multitask.com.au.
"Stephen Colebourne" <sc...@btopenworld.com> wrote on 17/12/2002
11:35:17 AM:
[snip]
> In broader terms however:
> a) The status of both the [util] and [email] components within
> jakarta-commons-sandbox is that of unreleased code, no matter how
stable.
> Deprecation is not required.
Unfortunate, but true. It's the community part that's missing here.
I'd like to see a move of both of these components to commons.
> b) The [util] component is generally viewed as a 'dumping ground' for
code
> that doesn't fit in elsewhere, and might better be named 'misc' or
> 'homeless'. The changes were designed to give [util] a chance of a
release.
How about moving it to commons rather than leaving it in sandbox?
> c) Commons must have the right to make changes to code and manage its
own
> releases and components. This should apply whether it is code written
> specifically for commons, or donated to commons from another jakarta
> project. If this is not the case then commons is simply a 'dumping
ground'
> for other jakarta projects hoping to off-load maintainance, rather than
a
> vibrant community in its own right.
Agreed, but like all code that is to be used and reused, we must consider
the users of the software.
<rant>
I think Gump is the best tool we have for doing this, and we need to be
nicer citizens.
Having just been bitten by HttpClient deleting methods that have been
available for months in CVS, I'm starting to question the current process
of only deprecating if a method has been available in a 'release' product.
I would like deprecation to happen for a time period before deletion, if
the code was not part of a release, especially in Commons, where the code
is by design meant to be used by others. And the code base can be stable,
without a release for a long time.
</rant>
Proposals:
1) Util should be moved to commons proper.
2) Email should be moved to commons proper.
Things to do:
1) Fix the ant and maven builds of both components so that they work.
Having the gump build as the only one available, and the jars unable to be
built from source is not acceptable.
Comments?
--
dIon Gillard, Multitask Consulting
Blog: http://www.freeroller.net/page/dion/Weblog
Work: http://www.multitask.com.au
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: GenerateUniqueId.java
Posted by Stephen Colebourne <sc...@btopenworld.com>.
I can confirm that I removed the GenerateUniqueId class and replaced it with
the identifier package.
I can also confirm that due to the setup of my mail client, I missed the
ensuing Gump messages. As a result I didn't fix the problem in [email],
which I would have done (although I don't consider myself an [email]
committer). This has now been fixed thanks to dIon Gillard. This was my
mistake, and for this I apologise.
In broader terms however:
a) The status of both the [util] and [email] components within
jakarta-commons-sandbox is that of unreleased code, no matter how stable.
Deprecation is not required.
b) The [util] component is generally viewed as a 'dumping ground' for code
that doesn't fit in elsewhere, and might better be named 'misc' or
'homeless'. The changes were designed to give [util] a chance of a release.
c) Commons must have the right to make changes to code and manage its own
releases and components. This should apply whether it is code written
specifically for commons, or donated to commons from another jakarta
project. If this is not the case then commons is simply a 'dumping ground'
for other jakarta projects hoping to off-load maintainance, rather than a
vibrant community in its own right.
Stephen
From: "Jon Scott Stevens" <jo...@latchkey.com>
>
http://cvs.apache.org/viewcvs.cgi/jakarta-commons-sandbox/util/src/java/org/
> apache/commons/util/identifier/
>
> You removed the GenerateUniqueId.java class and replaced it with some
whole
> subset of code which I'm sure is that much better, but the fact of the
> matter is that there was other code which depended on
GenerateUniqueId.java
> being there and you didn't go and fix it (specifically the code in
> commons-email). You need to learn how to do deprecation properly.
>
> So, either put GenerateUniqueId.java back or fix commons-email and next
time
> please learn how to use deprecation properly.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: GenerateUniqueId.java
Posted by Sam Ruby <ru...@apache.org>.
Henri Yandell wrote:
> With some reflection, another alternative is that when a project becomes
> dependent on a CVS HEAD of an unreleased proejct, or even a HEAD of a
> released project, they make sure that someone documents this in the
> STATUS.html.
I third alternative is people use nag messages as an reminder that they
should actually talk to each other every once in a while.
http://jakarta.apache.org/gump/nagged.html
- Sam Ruby
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: GenerateUniqueId.java
Posted by robert burrell donkin <ro...@blueyonder.co.uk>.
On Monday, December 16, 2002, at 09:45 AM, Henning P. Schmiedehausen wrote:
> Sam Ruby <ru...@apache.org> writes:
>
>> I believe that projects in a perpetual state of alpha are not condusive
>> to a healthy commons.
>
>> Are there plans to address this issue?
>
> The lessons to be learned here is IMHO "release early, release
> often". That's IMHO the main problem with many Jakarta projects.
i think that there are two slight different issues here.
1. components in the commons proper
by my count, there are only three components without (even alpha) releases
and two more which only have alpha and beta releases. that's not a huge
number. are these components (in commons-proper) the projects you were
referring to, sam?
but i agree with henning that the commons proper has got a bit slack with
releases. i think what's needed are more alpha and beta releases. these
allow solid dependencies but don't freeze the API. maybe the charter needs
to be changed to insist that every component creates an alpha release as
soon as it's promoted.
2. sandbox components
IMHO this seems (to me) to be less healthy. it seems to me that there are
conflicts here between the various aims/usages of the sandbox. maybe could
make things clearer by categorizing the components in there.
- robert
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: GenerateUniqueId.java
Posted by "Henning P. Schmiedehausen" <hp...@intermeta.de>.
Sam Ruby <ru...@apache.org> writes:
>I believe that projects in a perpetual state of alpha are not condusive
>to a healthy commons.
>Are there plans to address this issue?
The lessons to be learned here is IMHO "release early, release
often". That's IMHO the main problem with many Jakarta projects.
Regards
Henning
--
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen -- Geschaeftsfuehrer
INTERMETA - Gesellschaft fuer Mehrwertdienste mbH hps@intermeta.de
Am Schwabachgrund 22 Fon.: 09131 / 50654-0 info@intermeta.de
D-91054 Buckenhof Fax.: 09131 / 50654-20
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: GenerateUniqueId.java
Posted by Sam Ruby <ru...@apache.org>.
Henri Yandell wrote:
>
> Given the two very real choices between a code graveyard and a moving
> target, I'd choose the moving target. Yes I'd prefer a perfect project,
> but I like to deal in solutions that work with reality.
http://www.intrepidsoftware.com/fallacy/fd.htm
I believe that projects in a perpetual state of alpha are not condusive
to a healthy commons.
Are there plans to address this issue?
- Sam Ruby
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: GenerateUniqueId.java
Posted by Jon Scott Stevens <jo...@latchkey.com>.
on 2002/12/15 6:26 PM, "Henri Yandell" <ba...@generationjava.com> wrote:
>
>
> On Sun, 15 Dec 2002, Jon Scott Stevens wrote:
>
>> on 2002/12/15 3:58 PM, "Henri Yandell" <ba...@generationjava.com> wrote:
>>
>>> With some reflection, another alternative is that when a project becomes
>>> dependent on a CVS HEAD of an unreleased proejct, or even a HEAD of a
>>> released project, they make sure that someone documents this in the
>>> STATUS.html.
>>>
>>> Hen
>>
>> #1. Years and years ago, this file was originally created by me based on
>> some source from Jserv and put into the Turbine source code. No one bothered
>> to get in touch with me to say that they were going to get rid of it from
>> CVS and replace it with 10 more classes in a different package.
>
> No code ownership. Given Apache's current structure, I can see that
> committers like us should be asking Apache members for permission to do
> such thigns as we don't own the code, but I didn't think Apache subscribed
> to the notion of code ownership.
It is not a matter of code ownership. It is a matter of respect.
> I still disagree. If an unreleased component dies because another
> unreleased component, I see no problem. And if that previous unreleased
> component is only noticed as a change due to gump reporting it, then it
> might be better off dead. If however it notices because the active
> developer working on it notices, then that's all well and good. The code
> hasn't gone anywhere, it's still in CVS etc.
Just because the code hasn't had any changes in a long time doesn't mean it
is dead or not active. It could be functionally complete.
> I believe this is a problem with the Commons charter and beliefs in how
> Commons should work that don't seem workable. Developers should be able to
> focus on creating a component that is as good as possible in its own
> independent state.
EXACTLY! The file there was as good as it needed to be. It was independent
and wasn't changing. Then someone comes in and screws all that up.
> The other solution in which people dump common code
> into a commons project and then forget about it until something goes wrong
> just doesn't seem to work.
That is what is also happening.
> Given the two very real choices between a code graveyard and a moving
> target, I'd choose the moving target. Yes I'd prefer a perfect project,
> but I like to deal in solutions that work with reality.
Now you have gone into ranting about whatever. The fact of the matter is
that someone broke commons-email by removing code instead of deprecating it.
-jon
--
StudioZ.tv /\ Bar/Nightclub/Entertainment
314 11th Street @ Folsom /\ San Francisco
http://studioz.tv/
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: GenerateUniqueId.java
Posted by Henri Yandell <ba...@generationjava.com>.
On Sun, 15 Dec 2002, Jon Scott Stevens wrote:
> on 2002/12/15 3:58 PM, "Henri Yandell" <ba...@generationjava.com> wrote:
>
> > With some reflection, another alternative is that when a project becomes
> > dependent on a CVS HEAD of an unreleased proejct, or even a HEAD of a
> > released project, they make sure that someone documents this in the
> > STATUS.html.
> >
> > Hen
>
> #1. Years and years ago, this file was originally created by me based on
> some source from Jserv and put into the Turbine source code. No one bothered
> to get in touch with me to say that they were going to get rid of it from
> CVS and replace it with 10 more classes in a different package.
No code ownership. Given Apache's current structure, I can see that
committers like us should be asking Apache members for permission to do
such thigns as we don't own the code, but I didn't think Apache subscribed
to the notion of code ownership.
The PMC are welcome to start pushing management if they wish.
> #2. It was moved from Turbine into Jakarta Commons Util on Aug 7 23:23:41
> 2001. Well over a year ago.
>
> Given that it has been in there for that amount of time and commons-email
> has depended on it for probably just as long, I think that overrides any
> sort of released version non-sense. It is simple to deprecate the class
> and/or submit a patch saying that the code is going to go away and be
> replaced with something else.
I still disagree. If an unreleased component dies because another
unreleased component, I see no problem. And if that previous unreleased
component is only noticed as a change due to gump reporting it, then it
might be better off dead. If however it notices because the active
developer working on it notices, then that's all well and good. The code
hasn't gone anywhere, it's still in CVS etc.
> I think the point that Sam and I are both trying to make is that the
> complete lack of disregard for history and communication can't be ignored
> any longer. We need to work together on things.
I believe this is a problem with the Commons charter and beliefs in how
Commons should work that don't seem workable. Developers should be able to
focus on creating a component that is as good as possible in its own
independent state. The other solution in which people dump common code
into a commons project and then forget about it until something goes wrong
just doesn't seem to work.
Given the two very real choices between a code graveyard and a moving
target, I'd choose the moving target. Yes I'd prefer a perfect project,
but I like to deal in solutions that work with reality.
Hen
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: GenerateUniqueId.java
Posted by Jon Scott Stevens <jo...@latchkey.com>.
on 2002/12/15 3:58 PM, "Henri Yandell" <ba...@generationjava.com> wrote:
> With some reflection, another alternative is that when a project becomes
> dependent on a CVS HEAD of an unreleased proejct, or even a HEAD of a
> released project, they make sure that someone documents this in the
> STATUS.html.
>
> Hen
#1. Years and years ago, this file was originally created by me based on
some source from Jserv and put into the Turbine source code. No one bothered
to get in touch with me to say that they were going to get rid of it from
CVS and replace it with 10 more classes in a different package.
#2. It was moved from Turbine into Jakarta Commons Util on Aug 7 23:23:41
2001. Well over a year ago.
Given that it has been in there for that amount of time and commons-email
has depended on it for probably just as long, I think that overrides any
sort of released version non-sense. It is simple to deprecate the class
and/or submit a patch saying that the code is going to go away and be
replaced with something else.
I think the point that Sam and I are both trying to make is that the
complete lack of disregard for history and communication can't be ignored
any longer. We need to work together on things.
-jon
--
StudioZ.tv /\ Bar/Nightclub/Entertainment
314 11th Street @ Folsom /\ San Francisco
http://studioz.tv/
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: GenerateUniqueId.java
Posted by Henri Yandell <ba...@generationjava.com>.
With some reflection, another alternative is that when a project becomes
dependent on a CVS HEAD of an unreleased proejct, or even a HEAD of a
released project, they make sure that someone documents this in the
STATUS.html.
Hen
On Sun, 15 Dec 2002, Henri Yandell wrote:
>
> I disagree. A project which has not been released should not have to care
> about deprecation.
>
> What your basically saying is that if someone adds a feature to CVS then
> it cannot later be removed but must be deprecated, even if not released.
>
> Whoever is the coder on Commons Email should be fixing it when they
> notice that the CVS HEAD they are dependent on has changed. The
> alternative you suggest is impossible beyond the simplest of systems.
>
> Hen
>
>
> On Sun, 15 Dec 2002, Jon Scott Stevens wrote:
>
> > http://cvs.apache.org/viewcvs.cgi/jakarta-commons-sandbox/util/src/java/org/
> > apache/commons/util/identifier/
> >
> > You removed the GenerateUniqueId.java class and replaced it with some whole
> > subset of code which I'm sure is that much better, but the fact of the
> > matter is that there was other code which depended on GenerateUniqueId.java
> > being there and you didn't go and fix it (specifically the code in
> > commons-email). You need to learn how to do deprecation properly.
> >
> > So, either put GenerateUniqueId.java back or fix commons-email and next time
> > please learn how to use deprecation properly.
> >
> > -jon
> >
> > --
> > StudioZ.tv /\ Bar/Nightclub/Entertainment
> > 314 11th Street @ Folsom /\ San Francisco
> > http://studioz.tv/
> >
> >
> > --
> > 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: GenerateUniqueId.java
Posted by Henri Yandell <ba...@generationjava.com>.
I disagree. A project which has not been released should not have to care
about deprecation.
What your basically saying is that if someone adds a feature to CVS then
it cannot later be removed but must be deprecated, even if not released.
Whoever is the coder on Commons Email should be fixing it when they
notice that the CVS HEAD they are dependent on has changed. The
alternative you suggest is impossible beyond the simplest of systems.
Hen
On Sun, 15 Dec 2002, Jon Scott Stevens wrote:
> http://cvs.apache.org/viewcvs.cgi/jakarta-commons-sandbox/util/src/java/org/
> apache/commons/util/identifier/
>
> You removed the GenerateUniqueId.java class and replaced it with some whole
> subset of code which I'm sure is that much better, but the fact of the
> matter is that there was other code which depended on GenerateUniqueId.java
> being there and you didn't go and fix it (specifically the code in
> commons-email). You need to learn how to do deprecation properly.
>
> So, either put GenerateUniqueId.java back or fix commons-email and next time
> please learn how to use deprecation properly.
>
> -jon
>
> --
> StudioZ.tv /\ Bar/Nightclub/Entertainment
> 314 11th Street @ Folsom /\ San Francisco
> http://studioz.tv/
>
>
> --
> 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>