On 15 May 07, at 9:57 AM 15 May 07, Shane Isbell wrote:
Just to clarify, the implementation is now as follows: NMaven uses the
default repo format remotely and then transforms locally; this is
the most
pragmatic approach, and I don't have any immediate concerns. The
problem,
however, is that we are exposing the internal schema to the client;
this
creates a fair amount of confusion as people look for a general
schema that
satisfies the various languages, as opposed to a general API, say
through
REST or SOAP. Although HTTP GET with a URL may qualify as an API,
I don't think it does. If you're referring to how an actual artifact
is retrieve then it should only be via a set of parameters like
artifactId, groupId, version, type (optional classifier) and the
provider should deal with fetching the said artifact and giving it
back to the client. Using an URL as the only way to retrieve an
artifact is problematic.
So specify the set of parameters you can get an artifact from a Gem
repository, CPAN, a Maven repository, or anything else provided you
delegated to appropriate provider to deal with repository specifics.
The call for a artifact for assemblies or JARs would look the same
once you have a reference to the provider. So you would have
something like Maven Artifact eventually I would imagine.
under its
current form its really implementation (file-system) specific. I
would be
surprised if this issue doesn't keep coming up, as people become
interested
in using Maven for other languages.
Shane
On 5/15/07, Jason van Zyl [EMAIL PROTECTED] wrote:
On 6 May 07, at 9:13 PM 6 May 07, Carlos Sanchez wrote:
I didn't have a chance to talk about this with Shane but the
idea in
the end is to make the repository agnostic on how things are stored
and how the client uses them.
Right now is a simple directory, but could be a database with a web
front end or anything like that.
It shouldn't matter how NMaven artifacts are stored, as long as the
client handles them correctly. A solution we talked about time
ago was
to put them as any other artifacts and either developers could
choose
what format their local repo is in or the pom could say how they
should be stored
It all boils down to packaging that's important. It doesn't matter
how they are stored. What matters is how they are transformed and I'm
sure someone can find a work around for having the name in the
assembly manifest being burned in and breaking the linker when the
file name and manifest entry doesn't match.
The repository can theoretically be stored in anything Wagon supports
but it's unlikely we'll stray very far from file-system based
mechanisms.
But this is a total different discussion
On 5/6/07, Daniel Kulp [EMAIL PROTECTED] wrote:
Shane,
Honestly, it sounds like the NMaven stuff will need a complete new
set of
repositories for NMaven artifacts. There isn't any way, IMO,
that the
repo layout can change for the normal maven 1 and maven 2
repositories.
Incubator or repo1.maven.org is relatively irrelevant in that
regards.
The layout is pretty much set in stone. There are too many
plugins
(deploy, etc...) that rely on it, there are too many other apps
(several
different proxy applications, etc...) that rely on it, etc...
If the current layout is inadequate for NMaven, the NMaven team
should
figure out an appropriate place for a new repository. My
personal
suggestion is to work with the Maven team and create a new area at
repo1.maven.org/nmaven or similar. But that's me. In either
case, I
think that discussion is separate from where the m2 artifacts
go. It
make make sense to put the nmaven stuff in dist/incubator for a
while
until the layout is finalized, then move to central.
However, the
layouts for m1/m2 are finalized. Thus, they can/should go to
central.
(IMO)
That said, I don't know the NMaven details. But my #1 concern
is your
line:
I
would expect that an incubator release repo would be more
amendable to
such changes.
No chance, IMO. Once an artifact is released, it's SET IN
STONE. That
includes the layout of the repository it's sitting in. Once
theres the
possibility that another project is relying on a particular
artifact to
be living at a particular location, it needs to stay there. The
incubator m2 release repository is no different from central in
that
regard.
Dan
On Sunday 06 May 2007 14:11, Shane Isbell wrote:
[ ] use standard repositories
[ x ] relocate repositories under /www.apache.org/dist/incubator
My reasons are as follows: First, NMaven does not follow the
standard
repo layout; second, the repository layout structure is still
in a
state of flux, meaning that there is a need for potentially
changing
the layout for .NET artifacts, while still doing releases.
Getting more into some more specifics, with NMaven, there is no
version information contained
