well, that would be a matter of organizing correctly the groupIds or
doing it at artifact level maybe in some pom config
On 5/9/07, Shane Isbell <[EMAIL PROTECTED]> wrote:
I could see a problem with the second option of basing the layout on group
ids. It could be the case that a developer uses the same group Id for
different languages. In fact, currently, Maven .NET plugins uses the same
group id for a .NET AbstractMojo instance and for the corresponding Java
AbstractMojo binding instance (which is an adapter from Maven to .the NET
Mojo). Still open to the idea though.
Regards,
Shane
On 5/9/07, Carlos Sanchez <[EMAIL PROTECTED]> wrote:
>
> 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
>
--
I could give you my word as a Spaniard.
No good. I've known too many Spaniards.
-- The Princess Bride
