possibility of more heirarchical repository structure?

2003-09-21 Thread __matthewHawthorne
Has there been any thoughts about making the repository structure more 
heirarchical?

I've commented before about the abundance of commons-* directories in 
the current repository... avalon and excalibur also have quite a few.

The way that I understand it, if a groupId is used, then all of the 
distributions, jars, licenses, and poms for that group go in the same 
directory.  I'm not sure if this would ever cause any conflicts... if 
so, perhaps each group member could still have its own directory for 
these things.

As time goes on, it seems that the repository is going to get larger and 
larger, and it will become more difficult to manage.  Since maven still 
has control over the the logic for downloading jars from the repo, I 
don't think that a migration to a more heirarchical structure would be 
catastropic... maybe the searching mechanism could just be updated.

Any thoughts? Which choice do people prefer?

1. (possible structure)
repo/
jakarta-commons/
commons-beanutils/
commons-lang/
commons-(many more)
jakarta-avalon/
avalon-activation/
avalon-apps/
avalon-(many more)
jakarta-excalibur/
excalibur-altrmi/
excalibur-cli/
excalibur-(many more)

2. (current structure)
repo/
commons-beanutils/
commons-lang/
commons-(many more)
avalon-activation/
avalon-apps/
avalon-(many more)
excalibur-altrmi/
excalibur-cli/
excalibur-(many more)
3. (another possible structure)
repo/
apache.org/
ant/
jakarta/
avalon/
commons/
excalibur/
maven/
		

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


Re: possibility of more heirarchical repository structure?

2003-09-21 Thread Jason van Zyl
On Sun, 2003-09-21 at 14:37, __matthewHawthorne wrote:
 Has there been any thoughts about making the repository structure more 
 heirarchical?

I think Ben jotted some ideas in the wiki when we were chatting about it
but the basic gist would be to use FQDN where the top level would be:

org/
com/
net/

It certainly needs to be reorganized but so many are using it we're not
in a big rush to switch it without a good plan.

 I've commented before about the abundance of commons-* directories in 
 the current repository... avalon and excalibur also have quite a few.
 
 The way that I understand it, if a groupId is used, then all of the 
 distributions, jars, licenses, and poms for that group go in the same 
 directory.  I'm not sure if this would ever cause any conflicts... if 
 so, perhaps each group member could still have its own directory for 
 these things.
 
 As time goes on, it seems that the repository is going to get larger and 
 larger, and it will become more difficult to manage.  Since maven still 
 has control over the the logic for downloading jars from the repo, I 
 don't think that a migration to a more heirarchical structure would be 
 catastropic... maybe the searching mechanism could just be updated.
 
 
 Any thoughts? Which choice do people prefer?
 
 1. (possible structure)
 repo/
   jakarta-commons/
   commons-beanutils/
   commons-lang/
   commons-(many more)
 
   jakarta-avalon/
   avalon-activation/
   avalon-apps/
   avalon-(many more)
 
   jakarta-excalibur/
   excalibur-altrmi/
   excalibur-cli/
   excalibur-(many more)
   
 
 
 2. (current structure)
 repo/
   commons-beanutils/
   commons-lang/
   commons-(many more)
   avalon-activation/
   avalon-apps/
   avalon-(many more)
   excalibur-altrmi/
   excalibur-cli/
   excalibur-(many more)
 
 
 3. (another possible structure)
 repo/
   apache.org/
   ant/
 
   jakarta/
   avalon/
   commons/
   excalibur/
   maven/
 
   
 
 
 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]
-- 
jvz.

Jason van Zyl
[EMAIL PROTECTED]
http://tambora.zenplex.org

In short, man creates for himself a new religion of a rational
and technical order to justify his work and to be justified in it.
  
  -- Jacques Ellul, The Technological Society


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]