[util] Dependency on lang

[Stephen Colebourne <sc...@btopenworld.com>]

I would like to propose that [util] becomes dependent on [lang].

- [util] is conceptually at a higher level.
- Its not in wide use, so adding a dependency shouldn't affect too many
people.
- This would enable the identifier generating code currently in [pattern] to
move to [util] (a much better location for it), thus enabling [pattern] to
close entirely

This will have to be voted on to pass, this mail is to gain views first.

Stephen


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: [util] Dependency on lang

[Henri Yandell <ba...@generationjava.com>]

On Fri, 22 Nov 2002, Ola Berg wrote:

> But given the closeness between them, isn't it already now justified
> to manage both the o.a.c.lang and the o.a.c.util package in the
> thought of basic commons component named [core]? They are both small
> and very very very basic. Handling them as two
> jars/subprojects/downloads seems to be so much work for so little
> achieved.
>
> I say: let's marry them together. What do you think?

I'm not sure. Shouldn't util get to being a releasable component on its
own legs before we talk of a Core?

Util's current structure [ignoring current suggestions of things to add to
Util]:

empty http, exception and compare directories.
an lru package which has an LRUStore in, which I'm assuming is not desired
in Collections, but ought to go in there. [I don't get if there's a major
difference between LRUStore and LRUMap, haven't really looked].  [btw, No
apache license on these]

Then there are a handful of classes lying around:

BitField		Seems to have justification for being here.
GenerateUniqueId	Will fold into the Pattens code being migrated in.
Interpolator		Came out of StringUtils.
       			Not worth its existence at the moment.
WordWrapper		Came out of StringUtils. Not stable and
			effectively needs heavy unit testing.
XmlUtils		Probably shouldn't be at Jakarta. Quietly die.
StopWatch		Needs unit testing.

[new]

Ola's Hash stuff.
Patterns' Sequencer stuff.

...

These two new components both feel like good Util things, and hopefully
they can fill the Util project out a bit. We need to clean Util again,
then let things gestate a little with new ideas before releasing it,
either as util or into lang or into core.

Hen




--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: [util] Dependency on lang

[Jeff Varszegi <jv...@yahoo.com>]

You're absolutely right.

--- Ola Berg <ol...@ports.se> wrote:
> A commons core component has been discussed before. Seems like lang, util, collection, io and
> some more are justified there, since they cover broad aspects of java programming. This is
> something that we (according to the discussions) seems to see in the future.
> 
> But given the closeness between them, isn't it already now justified to manage both the
> o.a.c.lang and the o.a.c.util package in the thought of basic commons component named [core]?
> They are both small and very very very basic. Handling them as two jars/subprojects/downloads
> seems to be so much work for so little achieved.  
> 
> I say: let's marry them together. What do you think?
> 
> /O
> 
> 
> 
> 
> --
> To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
> 


__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus � Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: [util] Dependency on lang

[Ola Berg <ol...@ports.se>]

A commons core component has been discussed before. Seems like lang, util, collection, io and some more are justified there, since they cover broad aspects of java programming. This is something that we (according to the discussions) seems to see in the future.

But given the closeness between them, isn't it already now justified to manage both the o.a.c.lang and the o.a.c.util package in the thought of basic commons component named [core]? They are both small and very very very basic. Handling them as two jars/subprojects/downloads seems to be so much work for so little achieved.  

I say: let's marry them together. What do you think?

/O




--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: [util] Dependency on lang

[Henri Yandell <ba...@generationjava.com>]

+1

On Fri, 22 Nov 2002, Stephen Colebourne wrote:

> Doh. Its no good trying to think straight at midnight.
>
> I will move the id stuff into [util] from [pattern] unless anyone objects.
>
> Stephen
>
> ----- Original Message -----
> From: "Henri Yandell" <ba...@generationjava.com>
> To: "Jakarta Commons Developers List" <co...@jakarta.apache.org>
> Sent: Thursday, November 21, 2002 11:45 PM
> Subject: Re: [util] Dependency on lang
>
>
> >
> > It is dependant on lang :)
> >
> > SNAPSHOT version at the moment.
> >
> > Hen
> >
> > On Thu, 21 Nov 2002, Stephen Colebourne wrote:
> >
> > > I would like to propose that [util] becomes dependent on [lang].
> > >
> > > - [util] is conceptually at a higher level.
> > > - Its not in wide use, so adding a dependency shouldn't affect too many
> > > people.
> > > - This would enable the identifier generating code currently in
> [pattern] to
> > > move to [util] (a much better location for it), thus enabling [pattern]
> to
> > > close entirely
> > >
> > > This will have to be voted on to pass, this mail is to gain views first.
> > >
> > > Stephen
> > >
> > >
> > > --
> > > 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>
>
>


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: [util] Dependency on lang

[Stephen Colebourne <sc...@btopenworld.com>]

Doh. Its no good trying to think straight at midnight.

I will move the id stuff into [util] from [pattern] unless anyone objects.

Stephen

----- Original Message -----
From: "Henri Yandell" <ba...@generationjava.com>
To: "Jakarta Commons Developers List" <co...@jakarta.apache.org>
Sent: Thursday, November 21, 2002 11:45 PM
Subject: Re: [util] Dependency on lang


>
> It is dependant on lang :)
>
> SNAPSHOT version at the moment.
>
> Hen
>
> On Thu, 21 Nov 2002, Stephen Colebourne wrote:
>
> > I would like to propose that [util] becomes dependent on [lang].
> >
> > - [util] is conceptually at a higher level.
> > - Its not in wide use, so adding a dependency shouldn't affect too many
> > people.
> > - This would enable the identifier generating code currently in
[pattern] to
> > move to [util] (a much better location for it), thus enabling [pattern]
to
> > close entirely
> >
> > This will have to be voted on to pass, this mail is to gain views first.
> >
> > Stephen
> >
> >
> > --
> > 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: [util] Dependency on lang

[Henri Yandell <ba...@generationjava.com>]

It is dependant on lang :)

SNAPSHOT version at the moment.

Hen

On Thu, 21 Nov 2002, Stephen Colebourne wrote:

> I would like to propose that [util] becomes dependent on [lang].
>
> - [util] is conceptually at a higher level.
> - Its not in wide use, so adding a dependency shouldn't affect too many
> people.
> - This would enable the identifier generating code currently in [pattern] to
> move to [util] (a much better location for it), thus enabling [pattern] to
> close entirely
>
> This will have to be voted on to pass, this mail is to gain views first.
>
> Stephen
>
>
> --
> 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>