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:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Reply via email to