www-repository mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nick Chalko <n...@chalko.com>
Subject Re: subproject URI naming convention
Date Thu, 04 Dec 2003 07:43:03 GMT
Tim Anderson wrote:

>3. Change <product-specifier> so that it is opaque
>
>   repository-uri = access-specifier "/" product-specifier "/"
>                    version-specifier "/" artifact-specifier
>   product-specifier = path_segments
>
>   . recommend that <product-specifier> contains:
>     . reverse FQDN
>     . project name
>     . subproject name(s)
>   . can scale to arbitrary levels of subprojects
>   . tools must parse URIs right to left, in order
>     to separate version-specifier and product-specifier
>   . tools must derive organisation, project, and subproject information
>     from meta-data
>
>  E.g:
>    http://repo.apache.org/org/apache/jakarta/commons/lang
>    http://repo.apache.org/org/apache/xml/batik
>
>I'm beginning to prefer option 3.
>
>  
>
What is the minimum amount of Meta Data we can use to support this.

I can see this as just arbitrary super-projects  and a project is a dir 
that has a dist directory.. or something.

But really what is an organization.  what is a project what is a 
sub-project. 
In the end a "leaf" project is something that has distrabutables, like 
jar's or zip's for source files. 
Everything before that is just an arbitrary amount of grouping of projects
So really it comes down to how many levels of groups to we want 1 or 2 or n.
The fact that commons-lang and commons-io  are both part of the same 
Jakarta Project has no meaning to a repository.  

Because of that I still support having  a specific number of non 
optional project grouping levels. 
I feel grouping at the organization level is enough. but I am not 
against a mandatory second level but I would call it
org/project-group/project



R,
Nick



Mime
View raw message