about the local repo layout some possible solutions we talked about
time ago were
- single layout for the whole local repo configurable in the settings.xml
- layout based on groupIds, maybe in the maven-metadata files?
I think that the first option being simpler could be too simple.
On 5/9/07, Shane Isbell <[EMAIL PROTECTED]> wrote:
Comments below
On 5/9/07, Dan Fabulich <[EMAIL PROTECTED]> wrote:
>
> Hi Shane... I'm slightly confused by your remarks below.
>
> As I understand your email, although previously you had thought that
> creating a new repository layout for .NET was the best strategy, it
> sounds like you have changed your mind since then... specifically, you
> fear that integrating Archiva, the deploy plugin, the release plugin and
> snapshots will be way harder with a new layout. Is that right?
That's correct.
If so, what do you imagine we should do instead? What work exactly
> would take up to two months? The bugs linked there don't go into much
> detail.
Right now the plan is to have the default format on the remote repo. After
NMaven resolves the artifact, it renames it, removing the version info from
the artifact file name. The deploy plugin would be responsible for reversing
the transformation.
It has always been my position that we shouldn't have a special
> *alternative* repository layout just for .NET stuff, but that the
> *default* repository layout for Maven should be changed. Java is
> unusually friendly about allowing arbitrary library names; everything
> else (including .NET but also others) can have much more strict naming
> requirements in their libraries.
>
> If the default repository layout changed, wouldn't that make things a
> lot easier all around? Get everybody on the same page with a repository
> layout that everyone can work with?
By having a remote file-system repo - regardless of the format - we
are exposing the internal schema to the client. Thus, the existing format
has become an implied contract. I think is the core of the problem.
Clearly, the existing default layout is not Java specific, but rather
JSE/JEE specific. In particular, the way that maven handles classifiers is
troubling because it is inadequate for targeting mobile platforms (J2ME,
.NET Compact) applications, which may have a large set of platform
requirements or classifiers: consider a classifier:
mono-1.2.1-framework1.1-linux-FC5-withSharpDevelop2.1-GTK and so on, as you
try to enumerate the platform capabilities within the classifier. This is
one reason I would prefer to move to direct use of DBs (with obvious
front-end layers for the client API), where the build platform just sends it
platform capabilities and the repository sends back the appropriate
artifacts. NMaven handles sophisticated platform capability/requirement
matching, provided that the developer is building the project locally; but
for dependent artifacts that reside remotely, there is nothing other than a
concept of classifier. This is a key area that I would like to address:
applying capability/requirement matching to the discovery of remote
artifacts.
Then the question turns to: is there an adequate default local repository
format that handles general cases? Here is where I would agree with you that
this would be a good thing, as it would lower the entry barrier for new
languages that are incompatible with the existing conventions.
Shane
> -Dan
>
> > -----Original Message-----
> > From: Shane Isbell [mailto: [EMAIL PROTECTED]
> > Sent: Monday, May 07, 2007 6:05 PM
> > To: [email protected]; [EMAIL PROTECTED]
> > Subject: New Remote Repo Layout for .NET Artifacts?
> >
> > Frankly, I don't care how the artifacts are stored on the server. My
> core
> > motivation in the design has been to create the simplest solution that
> > works
> > in a .NET world. Originally I was looking at this issue from a resolve
> > perspective, as it's quite easy to resolve the artifacts with a new
> repo
> > layout, and in fact would require much more work to do a mapping of
> > a standard layout to a .NET layout locally. From what I can determine
> now,
> > including features to support the the .NET layout - such as using
> Archiva,
> > the deploy plugin, the release plugin, snapshots - make it much more
> > complicated to support the total solution with a new layout.
> >
> > http://jira.codehaus.org/browse/NMAVEN-19
> > http://jira.codehaus.org/browse/NMAVEN-43
> > http://jira.codehaus.org/browse/NMAVEN-44
> > http://jira.codehaus.org/browse/NMAVEN-46
> >
> > Getting these feature implemented could take upwards of 2 months,
> which is
> > not a problem if it is the right solution; so I wanted to go ahead and
> > kick
> > off a discussion about the repo format. Does it make sense, as Carlos
> has
> > suggested, to use a database and a web service for the repo? I'm not
> > exactly
> > sure how this would work, so I will let Carlos chime in.
> >
> > Thanks,
> > Shane
>
> Notice: This email message, together with any attachments, may contain
> information of BEA Systems, Inc., its subsidiaries and affiliated
> entities, that may be confidential, proprietary, copyrighted and/or
> legally privileged, and is intended solely for the use of the individual or
> entity named in this message. If you are not the intended recipient, and
> have received this message in error, please immediately return this by email
> and then delete it.
>
--
I could give you my word as a Spaniard.
No good. I've known too many Spaniards.
-- The Princess Bride
