> -----Original Message-----
> From: Leo Simons [mailto:[EMAIL PROTECTED]]
>
> 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-> [EMAIL PROTECTED]>
> For
> additional commands,
> e-mail: <mailto:[EMAIL PROTECTED]>
>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
