You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Ola Berg <ol...@arkitema.se> on 2002/06/23 22:31:58 UTC
Re: Commons architecture
To me, two things seems reasonable:
1) The low level commons of common components should not be in the same bloated package like util or something (org.apache.commons.everything.* ;-).
2) The packages (io, net, lang, base?, util etc) should be managed within the same subproject, in order to gain speed, momentum and synchronization. For that subproject I propose:
a) name: Commons Core
b) primary reuse assessor and coordinator (because that is what it is all about): Stephen Colebourne
How about that?
/O
(going off for vacation in eight hours to a desolated island outside the east coast of Sweden: just me, my wife, our two kids and my laptop :-)
--------------------
ola.berg@arkitema.se
0733 - 99 99 17
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Commons architecture
Posted by Dmitri Plotnikov <dm...@apache.org>.
I agree that one project is much better than many disparate ones. However,
I would like to suggest that rather than trying to combine many SOLUTIONS
into one project, we collect REQUIREMENTS from all those projects currently
doing the util stuff and try to address them all.
To illustrate the point, JXPath has its own type conversion utilities. The
cause of that is primarily the XPath standard, which has certain
peculiarities about type conversion (for example, you should be able to
convert a Set to a Number). JXPath could be based on a shared type
conversion mechanism only if that mechanism was customizable. That
customization cannot be global either, because different frameworks have
different needs and therefore would require different customized "instances"
of type converters, introspectors etc.
I believe all of that calls for serious research with all interested parties
participating in it. This research might take the form of a specification
or simply a collaboratively written set of documents.
- Dmitri
----- Original Message -----
From: "Steven Caswell" <st...@caswell.name>
To: "'Jakarta Commons Developers List'" <co...@jakarta.apache.org>;
"'Ola Berg'" <ol...@arkitema.se>
Sent: Sunday, June 23, 2002 4:55 PM
Subject: RE: Commons architecture
> I'd like to weigh in as a very interested lurker. I've got bits and
> pieces of things laying around from various places, many of which came
> from different corners of jakarta that I've taken out and abstracted (or
> thought about if I'd had somewhere to put them). The main reason I
> haven't tried to submit these back is that there has not been a good
> place to put them.
>
> IMO one important consideration is that some of the core classes will
> likely depend classes in other core packages. For example, I've found
> some good io stuff in Ant that I'd like to pull into o.a.c.io that will
> probably depend on at least one other class in another area of the core
> (o.a.c.system maybe). I'm guessing that this will be easier to do if
> there is one subproject as Ola suggests.
>
>
> 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: ola.berg@arkitema.se [mailto:ola.berg@arkitema.se]
> > Sent: Sunday, June 23, 2002 3:32 PM
> > To: commons-dev@jakarta.apache.org
> > Subject: Re: Commons architecture
> >
> >
> > To me, two things seems reasonable:
> >
> > 1) The low level commons of common components should not be
> > in the same bloated package like util or something
> > (org.apache.commons.everything.* ;-).
> >
> > 2) The packages (io, net, lang, base?, util etc) should be
> > managed within the same subproject, in order to gain speed,
> > momentum and synchronization. For that subproject I propose:
> >
> > a) name: Commons Core
> > b) primary reuse assessor and coordinator (because that is
> > what it is all about): Stephen Colebourne
> >
> > How about that?
> >
> > /O
> >
> > (going off for vacation in eight hours to a desolated island
> > outside the east coast of Sweden: just me, my wife, our two
> > kids and my laptop :-)
> >
> > --------------------
> > ola.berg@arkitema.se
> > 0733 - 99 99 17
> >
> > --
> > 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: Commons architecture
Posted by "Michael A. Smith" <ma...@apache.org>.
On Sun, 23 Jun 2002, Craig R. McClanahan wrote:
> Collections, although quite coherent, is getting so large that I can't
> always assume a new collection class that I might want to contribute to it
> will become part of a released version of collections (so I can publish a
> dependency on a particular version x.y) in a timely manner; making it more
> likely that I'd just stick it in the "util" subpackage of my own package
> frist.
Please, submit it anyway. While we may not have a release in time for
you to depend on a particular version, if the class is added, you can
remove it from your own package at a later date. And depending on when
you submit, it's possible we can be persuaded into releasing much
sooner. Without people pressuring us to release, it sometimes gets
pushed off.
regards,
michael
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Commons architecture
Posted by "Craig R. McClanahan" <cr...@apache.org>.
On Sun, 23 Jun 2002, Steven Caswell wrote:
> [snip]
> True, but are you saying the same thing about managing the core packages
> with lots of small sub-projects? I'm completely in favor of lots of
> small packages. I'd be a little more concerned (though not to the point
> of losing sleep) with a one-to-one mapping of each small package to a
> sub-project if there were interdependencies between several of those.
> I'm thinking the suggestion of a single, core sub-project with
> well-defined proper boundaries will fill the bill. And of course
> managing the interdependencies.
> >
I've been making the assumption that one package == one release. If
[core] or [lang] or whatever is just combined for ease of project
management, without constraining the release of individual (small)
libraries out of that code base, it'd probably be OK to combine, although
I suspect there will still be tendencies towards longer delivery cycles
and (potentially) more deep dependencies than there otherwise would be if
the small packages were separate.
On the other hand, I haven't observed any fatal penalties to having small
individual packages that are interdependent only on public APIs either.
Even if it's the same, or mostly the same, developers, it is pretty nice
to be able to release a new (say) BeanUtils without worrying about making
sure that Digester code isn't in the middle of a refactoring cycle.
Craig
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Commons architecture
Posted by Steven Caswell <st...@caswell.name>.
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: Craig R. McClanahan [mailto:craigmcc@apache.org]
> Sent: Sunday, June 23, 2002 5:19 PM
> To: Jakarta Commons Developers List; steven@caswell.name
> Cc: 'Ola Berg'
> Subject: RE: Commons architecture
>
>
>
>
> On Sun, 23 Jun 2002, Steven Caswell wrote:
>
> > Date: Sun, 23 Jun 2002 16:55:22 -0400
> > From: Steven Caswell <st...@caswell.name>
> > Reply-To: Jakarta Commons Developers List
> <co...@jakarta.apache.org>,
> > steven@caswell.name
> > To: 'Jakarta Commons Developers List'
> <co...@jakarta.apache.org>,
> > 'Ola Berg' <ol...@arkitema.se>
> > Subject: RE: Commons architecture
> >
> > I'd like to weigh in as a very interested lurker. I've got bits and
> > pieces of things laying around from various places, many of
> which came
> > from different corners of jakarta that I've taken out and
> abstracted
> > (or thought about if I'd had somewhere to put them). The
> main reason I
> > haven't tried to submit these back is that there has not
> been a good
> > place to put them.
> >
> > IMO one important consideration is that some of the core
> classes will
> > likely depend classes in other core packages. For example,
> I've found
> > some good io stuff in Ant that I'd like to pull into o.a.c.io that
> > will probably depend on at least one other class in another area of
> > the core (o.a.c.system maybe). I'm guessing that this will
> be easier
> > to do if there is one subproject as Ola suggests.
> >
>
> Taken to an extreme, this approach would lead to a single
> org.apache.commons.kitchensink package :-).
Agreed. Some common sense (pun wasn't intended but it did make me smile
when I wrote it) will most definitely be required.
>
> To me, the best dividing lines between subpackages in commons
> are based on the following concepts:
>
> * Coherence -- All of the classes in a particular package should
> "obviously" belong together. Either they need each other, or they
> illustrate different ways to implement the same abstractions,
> or they probably shouldn't be together.
>
> * Shallow Interdependencies -- It's fine for Commons projects
> to depend
> on each other, as long as they do so at the "edges" of the public
> API of the other packages. For example, packages dependent on
> commons-logging are encouraged to use LogFactory and Log (and even
> create your own implementations if desired), but deep linking into
> the internals is a sign that maybe your classes should really be in
> the other package instead of separate.
Again agreed. I'm thinking along the lines of where a class in a package
is providing services to the outside world via the public API, and
having that "outside world" include other packages in commons.
>
> * Releasability -- The larger a commons package gets, the slower its
> release cycle must be, due to the added testing and the need to get
> all of the classes to a roughly equivalent quality level (and then
> hold) for long enough to get the release out. Smaller,
> more narrowly
> focused class libraries are easier to release separately.
I'm thinking the core package should be very narrowly defined in order
to achieve this.
>
> All of the commons projects that I've been involved with as a
> developer (primarily beanutils, digester, logging, modeler)
> are relatively small and narrowly focused -- 1-5 key classes
> (with supporting machinery as needed. There are cross-package
> dependencies, but only on public APIs that have stayed quite stable.
>
> Collections, although quite coherent, is getting so large
> that I can't always assume a new collection class that I
> might want to contribute to it will become part of a released
> version of collections (so I can publish a dependency on a
> particular version x.y) in a timely manner; making it more
> likely that I'd just stick it in the "util" subpackage of my
> own package frist.
>
> At the same time, refactoring is a fact of life. For
> example, I'm fine with extracting the
> introspection/reflection stuff out of BeanUtils into either
> one or two finely grained other packages (there is probably
> enough mutual interdependence to be worth combining), and
> making the existing MethodUtils class et. al. a backwards
> compatibility wrapper. I'd even help out in such an effort.
>
> I'm not very keen, however, on making my package dependent on
> some gigantic wad-o-classes that might have a real release
> every couple of years. Totally independent of technical
> quality (assumed to be the same in either case), I simply
> need the flexibility to get faster turnaround on new features
> added to the packages I establish dependencies on -- and
> that's more practical with lots of small packages than fewer
> large ones.
True, but are you saying the same thing about managing the core packages
with lots of small sub-projects? I'm completely in favor of lots of
small packages. I'd be a little more concerned (though not to the point
of losing sleep) with a one-to-one mapping of each small package to a
sub-project if there were interdependencies between several of those.
I'm thinking the suggestion of a single, core sub-project with
well-defined proper boundaries will fill the bill. And of course
managing the interdependencies.
>
> >
> > Steven Caswell
> > steven@caswell.name
> > a.k.a Mungo Knotwise of Michel Delving
> > "One ring to rule them all, one ring to find them..."
> >
>
> Craig McClanahan
>
>
> --
> 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>
RE: Commons architecture
Posted by "Craig R. McClanahan" <cr...@apache.org>.
On Sun, 23 Jun 2002, Steven Caswell wrote:
> Date: Sun, 23 Jun 2002 16:55:22 -0400
> From: Steven Caswell <st...@caswell.name>
> Reply-To: Jakarta Commons Developers List <co...@jakarta.apache.org>,
> steven@caswell.name
> To: 'Jakarta Commons Developers List' <co...@jakarta.apache.org>,
> 'Ola Berg' <ol...@arkitema.se>
> Subject: RE: Commons architecture
>
> I'd like to weigh in as a very interested lurker. I've got bits and
> pieces of things laying around from various places, many of which came
> from different corners of jakarta that I've taken out and abstracted (or
> thought about if I'd had somewhere to put them). The main reason I
> haven't tried to submit these back is that there has not been a good
> place to put them.
>
> IMO one important consideration is that some of the core classes will
> likely depend classes in other core packages. For example, I've found
> some good io stuff in Ant that I'd like to pull into o.a.c.io that will
> probably depend on at least one other class in another area of the core
> (o.a.c.system maybe). I'm guessing that this will be easier to do if
> there is one subproject as Ola suggests.
>
Taken to an extreme, this approach would lead to a single
org.apache.commons.kitchensink package :-).
To me, the best dividing lines between subpackages in commons are based on
the following concepts:
* Coherence -- All of the classes in a particular package should
"obviously" belong together. Either they need each other, or they
illustrate different ways to implement the same abstractions,
or they probably shouldn't be together.
* Shallow Interdependencies -- It's fine for Commons projects to depend
on each other, as long as they do so at the "edges" of the public
API of the other packages. For example, packages dependent on
commons-logging are encouraged to use LogFactory and Log (and even
create your own implementations if desired), but deep linking into
the internals is a sign that maybe your classes should really be in
the other package instead of separate.
* Releasability -- The larger a commons package gets, the slower its
release cycle must be, due to the added testing and the need to get
all of the classes to a roughly equivalent quality level (and then
hold) for long enough to get the release out. Smaller, more narrowly
focused class libraries are easier to release separately.
All of the commons projects that I've been involved with as a developer
(primarily beanutils, digester, logging, modeler) are relatively small and
narrowly focused -- 1-5 key classes (with supporting machinery as needed.
There are cross-package dependencies, but only on public APIs that have
stayed quite stable.
Collections, although quite coherent, is getting so large that I can't
always assume a new collection class that I might want to contribute to it
will become part of a released version of collections (so I can publish a
dependency on a particular version x.y) in a timely manner; making it more
likely that I'd just stick it in the "util" subpackage of my own package
frist.
At the same time, refactoring is a fact of life. For example, I'm fine
with extracting the introspection/reflection stuff out of BeanUtils into
either one or two finely grained other packages (there is probably enough
mutual interdependence to be worth combining), and making the existing
MethodUtils class et. al. a backwards compatibility wrapper. I'd even
help out in such an effort.
I'm not very keen, however, on making my package dependent on some
gigantic wad-o-classes that might have a real release every couple of
years. Totally independent of technical quality (assumed to be the same
in either case), I simply need the flexibility to get faster turnaround on
new features added to the packages I establish dependencies on -- and
that's more practical with lots of small packages than fewer large ones.
>
> Steven Caswell
> steven@caswell.name
> a.k.a Mungo Knotwise of Michel Delving
> "One ring to rule them all, one ring to find them..."
>
Craig McClanahan
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Commons architecture
Posted by Steven Caswell <st...@caswell.name>.
I'd like to weigh in as a very interested lurker. I've got bits and
pieces of things laying around from various places, many of which came
from different corners of jakarta that I've taken out and abstracted (or
thought about if I'd had somewhere to put them). The main reason I
haven't tried to submit these back is that there has not been a good
place to put them.
IMO one important consideration is that some of the core classes will
likely depend classes in other core packages. For example, I've found
some good io stuff in Ant that I'd like to pull into o.a.c.io that will
probably depend on at least one other class in another area of the core
(o.a.c.system maybe). I'm guessing that this will be easier to do if
there is one subproject as Ola suggests.
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: ola.berg@arkitema.se [mailto:ola.berg@arkitema.se]
> Sent: Sunday, June 23, 2002 3:32 PM
> To: commons-dev@jakarta.apache.org
> Subject: Re: Commons architecture
>
>
> To me, two things seems reasonable:
>
> 1) The low level commons of common components should not be
> in the same bloated package like util or something
> (org.apache.commons.everything.* ;-).
>
> 2) The packages (io, net, lang, base?, util etc) should be
> managed within the same subproject, in order to gain speed,
> momentum and synchronization. For that subproject I propose:
>
> a) name: Commons Core
> b) primary reuse assessor and coordinator (because that is
> what it is all about): Stephen Colebourne
>
> How about that?
>
> /O
>
> (going off for vacation in eight hours to a desolated island
> outside the east coast of Sweden: just me, my wife, our two
> kids and my laptop :-)
>
> --------------------
> ola.berg@arkitema.se
> 0733 - 99 99 17
>
> --
> 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>