oh, and btw the war plugin already uses the groupId when in conflict :)
http://jira.codehaus.org/browse/MWAR-19
On Nov 29, 2007 10:44 AM, Carlos Sanchez <[EMAIL PROTECTED]> wrote:
> answering several mails here:
>
> > id=org.eclipse.core.eclipse-core-resources
>
> how can I programatically map this back to the OSGi id ?
> you must be able to map osgi<->maven
>
>
> > I totally agree that tools which rely on artifactId-uniqueness are
> > technically broken, but is it right to choose a programmatic mapping
> > which increases the severity of this breakage?
>
> it doesnt increase anything, you were not using eclipse artifacts
> before, because they were not in the repo
> it's most likely that you will use the eclipse bundles for osgi
> development than for webapp, so it's worse to accommodate the broken
> war plugin than break the osgi plugins
>
> > Eclipse is the first project that introduces this artifactId conflict issue,
>
> not really, if i create an artifact with a very commons artifactId
> like "util" i'm in the same trouble
>
>
>
> On Nov 28, 2007 9:14 PM, nicolas de loof <[EMAIL PROTECTED]> wrote:
> > Your right : the packaging plugins may provide a optional workaround to
> > conflicting artifacts names.
> > I've created MWAR-132 for this.
> >
> > Eclipse is the first project that introduces this artifactId conflict issue,
> > but many other could appear in future, so the plugins must be upgraded asap
> > to provide a workaround.
> >
> > Nico.
> >
> >
> > 2007/11/28, Carlos Sanchez <[EMAIL PROTECTED]>:
> > >
> > > On Nov 28, 2007 7:09 PM, nicolas de loof <[EMAIL PROTECTED]> wrote:
> > > > 2007/11/28, Carlos Sanchez <[EMAIL PROTECTED]>:
> > > > > plugins (war, ear,...) should support and even make it the default, to
> > > > > package the jars using the full group+arifact id, because using just
> > > > > the artifactId has limitations. What happens now if you have 2 jars
> > > > > with same artifactId and version in a war? they overwrite each other
> > > > >
> > > > >
> > > > This would be great in an ideal world.
> > > > Lets consider the required changes :
> > > >
> > > > - war plugin to create required WEB-INF/lib
> > > > - jar/ear/ejb plugin to create the correct MANIFEST entries
> > > > - assembly plugin to bundle dependencies
> > > >
> > > > Adn now, consider how many builds could be broken by such changes...
> > >
> > > for those plugins it can be an option, doesnt need to be the default
> > > right away. What i'm saying is that it's the path forward and new
> > > stuff like the eclipse bundles need to be aware of it. The OSGi tools,
> > > like felix bundle plugin already compose the bundle symbolic name with
> > > group+artifact.
> > >
> > > in any case those plugins are already broken if there are two
> > > artifacts with same artifactid and version (eg util-1.0.jar)
> > >
> > > Now imagine that the eclipse plugins get the name from the artifactId
> > > only, what about the thousands of artifacts that are already in the
> > > repo? org.apache.commons-logging/commons-logging should be
> > > commons-logging in an osgi bundle or org.apache.commons-logging???
> > >
> > >
> > >
> > > >
> > >
> > >
> > >
> > > --
> > > I could give you my word as a Spaniard.
> > > No good. I've known too many Spaniards.
> > > -- The Princess Bride
> > >
> >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > For additional commands, e-mail: [EMAIL PROTECTED]
> > >
> > >
> >
>
>
>
> --
>
> 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
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
