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


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


Reply via email to