On Tue, 17 Dec 2002 [EMAIL PROTECTED] wrote:
> Henri Yandell <[EMAIL PROTECTED]> wrote on 17/12/2002 03:26:08 PM: > > On Tue, 17 Dec 2002 [EMAIL PROTECTED] wrote: > > > > > Henri Yandell <[EMAIL PROTECTED]> 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: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
