Anywhere near concensus?

[Tim Anderson <tm...@netspace.net.au>]

Is there any concensus out there that the
repository URI proposals are the right/wrong way to go?

The only sticking point I'm aware of at the moment, is
the product-specifier part of the URI, i.e,
    repository-uri = access-specifier "/" product-specifier "/"
                     version-specifier "/" artifact-specifier

1.  product-specifier = organisation "/" project
    organisation = pchar+
    project = pchar+

    OR

2.  product-specifier = path_segments

So far, form [1] seems to be preferred as it supports URI parsing.
I prefer [2] as it allows better representation of project
heirarchies.
I'm attaching a sample repository structure for [1].
A sample for [2] can be found here:

http://nagoya.apache.org/eyebrowse/ReadMsg?listName=repository@apache.org&ms
gNo=490

If someone with a public webspace can extract them both (Adam?),
that would be great.

Thanks,

Tim

Re: Anywhere near concensus?

["Adam R. B. Jack" <aj...@trysybase.com>]

> > Done:    http://cvs.apache.org/~ajack/repository/proposals/
>
> I think of the group, I like repositoryFQDN/ best.

For me, it is between that and group (oh yeah, I asked for that one. ;-)
'cos they are both of deterministic directory depth/layout.

[BTW: If things get 'overloaded' we can do the traditional /fred ->
/f/r/fred w/o changing deterministic depth/layout.]

That said, to me 'group' and FQDN don't need to be any different --- one is
just saying 'for Java projects (or those w/ DN-like packages) the likely
group name is the FQDN of the root package'.

regards,

Adam

RE: Anywhere near concensus?

["Noel J. Bergman" <no...@devtech.com>]

> Done:    http://cvs.apache.org/~ajack/repository/proposals/

I think of the group, I like repositoryFQDN/ best.

	--- Noel

Re: Anywhere near concensus?

["Adam R. B. Jack" <aj...@trysybase.com>]

> If someone with a public webspace can extract them both (Adam?),
> that would be great.

Done:    http://cvs.apache.org/~ajack/repository/proposals/

regards

Adam

RE: Anywhere near concensus?

[Tim Anderson <tm...@netspace.net.au>]

> From: Adam R. B. Jack [mailto:ajack@trysybase.com]
> 
> > Is there any consensus out there that the
> > repository URI proposals are the right/wrong way to go?
> 
> I have to believe it is close. I think folks need to add any issues they
> have here to TODOs
> 
> http://nagoya.apache.org/wiki/apachewiki.cgi?ASFRepository/ToDo
> 
> If we can't agree on some we need to vote, I guess. We need to set a
> deadline, get agreement (or what we can all live with) and move on.
> 
> Q: I missed a conclusion, did 'binaries'/'binary' get decided?
> 

Not yet. 

-Tim

Re: Anywhere near concensus?

["Adam R. B. Jack" <aj...@trysybase.com>]

> IIRC, the repository structure used by Maven
(http://www.ibiblio.org/maven/)
> has generated much discussion in the past, with the
> general concensus being that the flat structure:
> . didn't help artifact categorisation
> . made it difficult to navigate and locate artifacts

Folk have resolved those issues with type and version sub-directories. What
we have now isn't flat.

> It was an excellent first step, but I think it can be done
> better.

Yes, me too, but we need a tight set of useful categorizations, and I'm not
sure that 'sub-project' is one. Artefact id (plus the others) covers that. I
think that things like 'sub-project' are just too fluid and too subjective
to fix into the URI. [Gump has a different view of a project than Maven than
...]

regards

Adam

RE: Anywhere near concensus?

[Tim Anderson <tm...@netspace.net.au>]

> From: Adam R. B. Jack [mailto:ajack@trysybase.com]
>
>
> > The third form leads to a flat repository structure, similar to
> > that in use by maven (http://www.ibiblio.org/maven)
> > >From a browsing perspective, this doesn't scale to large numbers
> > of groups (aka products).
>
> That could be said about anything, at any level. Luckily Apache (this
> repository) isn't SourceForge, our product groups/artefacts are within
> scale. I think one could argue about almost any arbitrary hierarchy, with
> pros and cons. I don't think we should start there phase one. I
> say we keep
> it simple, and fix it only if we find it broken.
>

IIRC, the repository structure used by Maven (http://www.ibiblio.org/maven/)
has generated much discussion in the past, with the
general concensus being that the flat structure:
. didn't help artifact categorisation
. made it difficult to navigate and locate artifacts

It was an excellent first step, but I think it can be done
better.

I haven't looked at Wagon yet - does it use the existing ibiblio
structure?

-Tim

Re: Anywhere near concensus?

["Adam R. B. Jack" <aj...@trysybase.com>]

> The third form leads to a flat repository structure, similar to
> that in use by maven (http://www.ibiblio.org/maven)
> >From a browsing perspective, this doesn't scale to large numbers
> of groups (aka products).

That could be said about anything, at any level. Luckily Apache (this
repository) isn't SourceForge, our product groups/artefacts are within
scale. I think one could argue about almost any arbitrary hierarchy, with
pros and cons. I don't think we should start there phase one. I say we keep
it simple, and fix it only if we find it broken.

regards

Adam

RE: Anywhere near concensus?

[Tim Anderson <tm...@netspace.net.au>]

> From: Adam R. B. Jack [mailto:ajack@trysybase.com]
> 
> > Is there any consensus out there that the
> > repository URI proposals are the right/wrong way to go?
> 

[snip]
> 
> I would like to change the name of product-specified (back?) to
> 'group-specifier'. I think that concepts like 'sub-project' are totally
> orthogonal to a artefacts repository, and how folks structure things like
> that is not something we ought attempt to replicate. There are other
> groupings we aren't allowing in, so why allow this one? I think 
> that 'group'
> becomes a namespace, and that products within that group (e.g. 
> sub-projects)
> can't uniquely name their artefacts with the group. That is all we need.
> Anything else is distraction/overkill.
> 
> As such, I'd say group-specifier=pchar* (i.e. no '/' in there, so it is
> parsable.)
> 

OK, there are now three alternatives:

1.  repository-uri = access-specifier "/" product-specifier "/"
                     version-specifier "/" artifact-specifier
    product-specifier = organisation "/" project
    organisation = pchar+
    project = pchar+

2.  repository-uri = access-specifier "/" product-specifier "/"
                     version-specifier "/" artifact-specifier
    product-specifier = organisation "/" project
    product-specifier = path_segments

3.  repository-uri = access-specifier "/" group-specifier "/"
                     version-specifier "/" artifact-specifier
    group-specifier = pchar+

The third form leads to a flat repository structure, similar to 
that in use by maven (http://www.ibiblio.org/maven)
>From a browsing perspective, this doesn't scale to large numbers
of groups (aka products).

Example attached.

Regards,

Tim

Re: Anywhere near concensus?

["Adam R. B. Jack" <aj...@trysybase.com>]

> Is there any consensus out there that the
> repository URI proposals are the right/wrong way to go?

I have to believe it is close. I think folks need to add any issues they
have here to TODOs

http://nagoya.apache.org/wiki/apachewiki.cgi?ASFRepository/ToDo

If we can't agree on some we need to vote, I guess. We need to set a
deadline, get agreement (or what we can all live with) and move on.

Q: I missed a conclusion, did 'binaries'/'binary' get decided?

> The only sticking point I'm aware of at the moment, is
> the product-specifier part of the URI, i.e,

I hate to set this backwards, I know folks have been trying to whittle
things down to a conclusion, but I think that has failed so far.

I would like to change the name of product-specified (back?) to
'group-specifier'. I think that concepts like 'sub-project' are totally
orthogonal to a artefacts repository, and how folks structure things like
that is not something we ought attempt to replicate. There are other
groupings we aren't allowing in, so why allow this one? I think that 'group'
becomes a namespace, and that products within that group (e.g. sub-projects)
can't uniquely name their artefacts with the group. That is all we need.
Anything else is distraction/overkill.

As such, I'd say group-specifier=pchar* (i.e. no '/' in there, so it is
parsable.)

> I'm attaching a sample repository structure for [1].
> A sample for [2] can be found here:
>
>
http://nagoya.apache.org/eyebrowse/ReadMsg?listName=repository@apache.org&ms
> gNo=490
>
> If someone with a public webspace can extract them both (Adam?),
> that would be great.

I'll read & try to find time today.

regards,

Adam