You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Leo Simons <le...@apache.org> on 2002/03/30 10:30:17 UTC
shortening package names
import
org.apache.avalon.cornerstone.blocks.masterstore.xml.XMLFilePersistentReposi
tory;
is just one example of many rediculously long
package names. We opted for the completely logical
approach in the past, leaving out only the
'jakarta' in the above, and otherwise building a
slim and long tree, as opposed to a short and wide
one. The problem is that flattening that tree just
takes too much (typing) time.
I propose (well, Pete has in the past, so maybe I should say
"we") we shorten the packages a bit.
option 1
--------
apache.${avalon-sub-project-name}.${component}.*
so
apache.framework.activity.*
apache.excalibur.component.*
apache.cornerstone.blocks.masterstore.* (1)
apache.logkit.util.*
apache.phoenix.components.application.* (2)
apache.db.services.* (3)
option 2
--------
avalon.${avalon-sub-project-name}.${component}.*
so
avalon.framework.activity.*
avalon.excalibur.component.*
avalon.cornerstone.blocks.masterstore.* (1)
avalon.logkit.util.*
avalon.phoenix.components.application.* (2)
avalon.db.services.* (3)
either is fine with me. Turbine follows the first
option, so maybe we should follow their lead.
questions to address
--------------------
(1) - should we keep the blocks and services
separation? As it is, related classes (connection
being one example) are in two different trees.
so you'd get
apache.cornerstone.connection.*
(2) - should the phoenix components and tools
packages be merged with the main tree? so we'd
have
apache.phoenix.configuration.*
(3) - should we have an "apps" package? Obviously,
Avalon cannot claim
apache.demo.* ! Maybe that makes option 2 the
better of the two (as we won't have that
problem).
migration
---------
Phoenix, cornerstone and apps are alpha. We can
change the names of those packages in the next
release.
For the others, I propose a 4.2 and 1.1 release,
for Framework/Excalibur and logkit respectively,
where we deprecate _all_ the current names, along
with a 4.3 and 1.2 release, which is exactly the
same except for the change of package structure.
We should also do an alpha release on cornerstone
and phoenix that work with the 4.2/1.1 and 4.3/1.2
releases of the other projects.
For apps, I suggested we deprecate current
packaging for all packages, but not do a release.
Each app in that repository can then do its first
release once it has moved over to the new
structure.
I'd volunteer to do all the work if I had the time,
but I don't. So others will have to do parts of this,
Especially those better in the regexp and cvs hacks
department ;)
(note there's no call to vote :)
thoughts?
- Leo
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: shortening package names
Posted by Jeff Turner <je...@socialchange.net.au>.
On Sat, Mar 30, 2002 at 10:55:47PM +1100, Peter Donald wrote:
> > ...
> >
> > > option 1
> > > --------
> > > apache.${avalon-sub-project-name}.${component}.*
> >
> > > either is fine with me. Turbine follows the first
> > > option, so maybe we should follow their lead.
> >
> > Do they? Looking in the jakarta-turbine-2 and jakarta-turbine-3
> > modules, all I can see are org.apache.turbine.*
>
> org.apache.torque
> org.apache.mavern
>
> :)
Okay, if that's what was meant by the "first option".
> > Seems like it would be a huge break with convention to drop the
> > 'org.apache' prefix.
>
> Its a huge break in convention that we have a -cvs mailing list.
>
> > Can't we just have an Ant filter expanding
> > @o.a.a.c@ to org.apache.avalon.cornerstone?
>
> That no simpler :/
It saves lots of typing, and that's the issue, right? Any project with
long Avalon imports, just do a filtered <copy> from src/java to
build/java to replace the token, and the problem's solved.
Or we could all make use of our editors' macro facilities. In vim:
:abbr oaac org.apache.avalon.cornerstone
The point is, the brute force solution isn't the only one.
--Jeff
> --
> Cheers,
>
> Pete
>
> *------------------------------------------------------*
> | "Computers are useless. They can only give you |
> | answers." - Pablo Picasso |
> *------------------------------------------------------*
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: shortening package names
Posted by Peter Donald <pe...@apache.org>.
On Sat, 30 Mar 2002 22:48, Jeff Turner wrote:
> On Sat, Mar 30, 2002 at 10:30:17AM +0100, Leo Simons wrote:
> > import
> > org.apache.avalon.cornerstone.blocks.masterstore.xml.XMLFilePersistentRep
> >osi tory;
> >
> > is just one example of many rediculously long
> > package names.
>
> ...
>
> > option 1
> > --------
> > apache.${avalon-sub-project-name}.${component}.*
>
> ...
>
> > option 2
> > --------
> > avalon.${avalon-sub-project-name}.${component}.*
>
> ...
>
> > either is fine with me. Turbine follows the first
> > option, so maybe we should follow their lead.
>
> Do they? Looking in the jakarta-turbine-2 and jakarta-turbine-3
> modules, all I can see are org.apache.turbine.*
org.apache.torque
org.apache.mavern
:)
> Seems like it would be a huge break with convention to drop the
> 'org.apache' prefix.
Its a huge break in convention that we have a -cvs mailing list.
> Can't we just have an Ant filter expanding
> @o.a.a.c@ to org.apache.avalon.cornerstone?
That no simpler :/
--
Cheers,
Pete
*------------------------------------------------------*
| "Computers are useless. They can only give you |
| answers." - Pablo Picasso |
*------------------------------------------------------*
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: shortening package names
Posted by Berin Loritsch <bl...@apache.org>.
> -----Original Message-----
> From: Jeff Turner [mailto:jeff@snow.socialchange.net.au] On
>
> On Sat, Mar 30, 2002 at 10:30:17AM +0100, Leo Simons wrote:
> > import
> >
> org.apache.avalon.cornerstone.blocks.masterstore.xml.XMLFilePersistent
> > Reposi
> > tory;
> >
> > is just one example of many rediculously long
> > package names.
> ...
> > option 1
> > --------
> > apache.${avalon-sub-project-name}.${component}.*
> ...
> > option 2
> > --------
> > avalon.${avalon-sub-project-name}.${component}.*
> ...
> > either is fine with me. Turbine follows the first
> > option, so maybe we should follow their lead.
>
> Do they? Looking in the jakarta-turbine-2 and
> jakarta-turbine-3 modules, all I can see are org.apache.turbine.*
org.apache.turbine
org.apache.maven
org.apache.fulcrum
(those are all turbine packages)
I think Leo meant something like that:
org.apache.excalibur.event.*
org.apache.cornerstone.connectionmanager.*
>
> Seems like it would be a huge break with convention to drop
> the 'org.apache' prefix. Can't we just have an Ant filter
> expanding @o.a.a.c@ to org.apache.avalon.cornerstone?
-1 NO!
We are thinking about our users here. Mandating that the users
not only use ant to build their systems, but that they have to
use non-standard munging if they don't want a class name that is
80 characters long (the example he gave at the beginning of his
message) is not really an option.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: shortening package names
Posted by Jeff Turner <je...@socialchange.net.au>.
On Sat, Mar 30, 2002 at 10:30:17AM +0100, Leo Simons wrote:
> import
> org.apache.avalon.cornerstone.blocks.masterstore.xml.XMLFilePersistentReposi
> tory;
>
> is just one example of many rediculously long
> package names.
...
> option 1
> --------
> apache.${avalon-sub-project-name}.${component}.*
...
> option 2
> --------
> avalon.${avalon-sub-project-name}.${component}.*
...
> either is fine with me. Turbine follows the first
> option, so maybe we should follow their lead.
Do they? Looking in the jakarta-turbine-2 and jakarta-turbine-3
modules, all I can see are org.apache.turbine.*
Seems like it would be a huge break with convention to drop the
'org.apache' prefix. Can't we just have an Ant filter expanding
@o.a.a.c@ to org.apache.avalon.cornerstone?
--Jeff
> thoughts?
>
> - Leo
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: shortening package names
Posted by Peter Donald <pe...@apache.org>.
On Sat, 30 Mar 2002 20:30, Leo Simons wrote:
> apache.framework.activity.*
> apache.excalibur.component.*
> apache.cornerstone.blocks.masterstore.* (1)
> apache.phoenix.components.application.* (2)
> apache.db.services.* (3)
+0.8
> avalon.framework.activity.*
> avalon.excalibur.component.*
> avalon.cornerstone.blocks.masterstore.* (1)
> avalon.logkit.util.*
> avalon.phoenix.components.application.* (2)
> avalon.db.services.* (3)
+1 (not sure if rest of jakarta like this though)
> questions to address
> --------------------
> (1) - should we keep the blocks and services
> separation? As it is, related classes (connection
> being one example) are in two different trees.
> so you'd get
> apache.cornerstone.connection.*
+1
> (2) - should the phoenix components and tools
> packages be merged with the main tree? so we'd
> have
> apache.phoenix.configuration.*
-1
tools are separated out so eventually you are able to distribute separately
and create tools to build/automate/verify phoenix apps outside the server.
> migration
> ---------
How about the following.
* leave logkit where it is as it is stable and doesn't have any massive names
* leave the Phoenix API (ie the part users write against) where it is but
gradually move the rest.
* Move any excallibur scratchpad components to new home gradually
As for the rest; framework/released excalibur components we would need to
change major versions + deprecate before we did it. I propose we delay moving
framework classes until framework5. Maybe we could change the released
components as we move them out of the all/ tree. ie keep the deprecated old
versions in all/src/java/** and the new repackaged ones in the sjhortened
package.
This way we don't hurt any of our current users.
--
Cheers,
Pete
---------------------------------------------------
"It is easy to dodge our responsibilities, but we
cannot dodge the consequences of dodging our
responsibilities." -Josiah Stamp
---------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [vote] RE: shortening package names
Posted by Peter Donald <pe...@apache.org>.
On Mon, 1 Apr 2002 07:48, Leo Simons wrote:
> ------------------------
> So the proposal becomes:
>
> I propose we strip out the "avalon" part in the
> package hierarchy for the next major release of
> the various sub-projects.
>
> So, for:
> avalon framework 5 - org.apache.framework.*
+1
> avalon excalibur 5 - org.apache.excalibur.*
+1
> avalon cornerstone 5 - org.apache.cornerstone.*
+1
> avalon phoenix 5 - org.apache.phoenix.*
+1
> avalon logkit 2 - org.apache.logkit.*
-1
No reason to change it from
org.apache.log
--
Cheers,
Pete
Doubt is not a pleasant condition, but certainty is absurd.
-- Voltaire
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
[vote] RE: shortening package names
Posted by Leo Simons <le...@apache.org>.
(proposals at bottom)
Okay, this last post was not thought through well.
Too much coding does that to a guy :)
I, of course, ment ORG.apache. Avalon, I ment without
the org as that is a gaming something.
Cornerstone - a service can be one block or it can
be multiple blocks. A block can be a service or it
can not be a service.
I've never seen a use case where a block is not
useful as a service, though. So we don't need to
split stuff this way as far as package naming goes.
We could do with a naming convention, though.
Phoenix - no-one really programs to all those
interfaces outside of phoenix anyway. All the
stuff users access is in phoenix.interfaces.*
(or will be).
> Phoenix is near-beta. I would not be averse to making
> it beta now, with the pre-requisite that the management
> interface be built for final release.
Like pete said, it needs some cleaning. I'll leave
further discussion for the phoenix list tho'.
> > For the others, I propose a 4.2 and 1.1 release,
<snip myself>
berin:
> I would have two jars: A ${project}-compat.jar
> to have the old API stuff, and the new official
> jar so that external projects can move at their
> own pace.
yup. The versioning I proposed is not fair as we
are talking about some major changes (the api
becomes completely unusable without a recompile).
------------------------
So the proposal becomes:
I propose we strip out the "avalon" part in the
package hierarchy for the next major release of
the various sub-projects.
So, for:
avalon framework 5 - org.apache.framework.*
avalon excalibur 5 - org.apache.excalibur.*
avalon cornerstone 5 - org.apache.cornerstone.*
avalon phoenix 5 - org.apache.phoenix.*
avalon logkit 2 - org.apache.logkit.*
-------------------
proposal 2 becomes:
I propose we strip out the "blocks" and
"services" part in the package hierarchy before
the alpha release of cornerstone (v4). We will
release a cornerstone-compat.jar as well
that keeps the separation.
cheers,
- Leo
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: shortening package names
Posted by Berin Loritsch <bl...@apache.org>.
> -----Original Message-----
> From: Leo Simons [mailto:leosimons@apache.org]
>
> I propose (well, Pete has in the past, so maybe I should say
> "we") we shorten the packages a bit.
>
> option 1
> --------
> apache.${avalon-sub-project-name}.${component}.*
>
> so
>
> apache.framework.activity.*
> apache.excalibur.component.*
> apache.cornerstone.blocks.masterstore.* (1)
> apache.logkit.util.*
> apache.phoenix.components.application.* (2)
> apache.db.services.* (3)
Um, I would like to keep with the org.apache. prefix.
i.e.:
org.apache.framework.activity.*
org.apache.excalibur.event.*
org.apache.cornerstone.masterstore.* (1)
org.apache.log.util.* (as is done now)
org.apache.phoenix.application.*
org.apache.db.services.*
The org.apache. prefix becomes more important when you
realize that apache.com is a hardware vendor (that also
happens to be Jehova's Witness run [their front page
gives that info away]).
> either is fine with me. Turbine follows the first
> option, so maybe we should follow their lead.
Turbine expands apache.* to org.apache.*
> questions to address
> --------------------
> (1) - should we keep the blocks and services
> separation? As it is, related classes (connection
> being one example) are in two different trees.
> so you'd get
> apache.cornerstone.connection.*
I would be +1 on changing this. Technically, all
interfaces don't need to be grouped with the
implementation, but it helps when trying to understand
the code.
Cocoon does use this approach with their
major components. I.e.:
org.apache.cocoon.generation.Generator;
org.apache.cocoon.transformation.Transformer;
org.apache.cocoon.serialization.Serializer;
etc.
It is essentially what we are doing with excalibur,
so I would like to see it happen in cornerstone as well.
> (2) - should the phoenix components and tools
> packages be merged with the main tree? so we'd
> have
> apache.phoenix.configuration.*
That would be an option that should be discussed at the
project level. I.e. the folks actively maintaining
Phoenix would hash that out.
>
> (3) - should we have an "apps" package? Obviously,
> Avalon cannot claim
> apache.demo.* ! Maybe that makes option 2 the
> better of the two (as we won't have that
> problem).
But who owns avalon.org?
>
> migration
> ---------
> Phoenix, cornerstone and apps are alpha. We can
> change the names of those packages in the next
> release.
Careful though, JAMES depends on Phoenix and Cornerstone.
Phoenix is near-beta. I would not be averse to making
it beta now, with the pre-requisite that the management
interface be built for final release.
The unofficial standard for alpha, beta, final release
levels is:
alpha: niether functionally complete or api stable. No
guarantees, although it might be usable.
beta: The api is stable, but it may be functionally incomplete.
It is safe to start playing with it (unless you really
like the bleeding edge better).
pre-release: Everything is there, we are just shaking out bugs.
It is safe to start developing commercial packages
trying to get the jump on the market when it is
finally released.
final release: We have our stamp of approval on it. It is good for
production quality solutions!
with the exception of the commercial project comment, this is
a fairly common conceptual breakdown.
I would still increment the version number for these three.
> For the others, I propose a 4.2 and 1.1 release,
> for Framework/Excalibur and logkit respectively,
> where we deprecate _all_ the current names, along
> with a 4.3 and 1.2 release, which is exactly the
> same except for the change of package structure.
> We should also do an alpha release on cornerstone
> and phoenix that work with the 4.2/1.1 and 4.3/1.2
> releases of the other projects.
> For apps, I suggested we deprecate current
> packaging for all packages, but not do a release.
> Each app in that repository can then do its first
> release once it has moved over to the new
> structure.
I would have two jars: A ${project}-compat.jar
to have the old API stuff, and the new official
jar so that external projects can move at their
own pace.
>
> I'd volunteer to do all the work if I had the time,
> but I don't. So others will have to do parts of this,
> Especially those better in the regexp and cvs hacks
> department ;) (note there's no call to vote :)
>
> thoughts?
>
> - Leo
>
>
> --
> To unsubscribe, e-mail:
> <mailto:avalon-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>