You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Max Bowsher <ma...@ukf.net> on 2007/11/27 12:40:59 UTC
groupId/artifactId mapping for Eclipse jars (was Re: in repo1 it
is available)
Carlos Sanchez wrote:
> I'm uploading right now a good number of jars to
> http://repo1.maven.org/eclipse-staging/
> If it looks good I will sync to central
>
> Note that the location for the one you want should be
> http://repo1.maven.org/eclipse-staging/org/eclipse/core/resources/3.2.1/
I wonder if this groupId:artifactId mapping is a bad idea?
Most jars in the repository have an artifactId which is, whilst not
necessarily globally unique, good enough to give you a pretty good idea
what they are. This is a good thing, since there are several use cases
where a collection of jars is bundled into a single directory, and those
jars are named {artifactId}-{version}.jar (e.g, war file WEB-INF/lib/,
common usage of assembly plugin).
The suggested mapping of just taking the last component of the name as
the artifactId will lead to many artifacts with non-descriptive and
clashing names like "common", "core", "ui", etc. At best case, this
will merely be horrendously confusing for humans attempting to
understand and debug these generated collections of jars. At worst case,
some of the artifacts will not only have the same artifactId, but same
version too, and will overwrite each other.
So, I think the current mapping fits poorly with existing Maven
use-cases and plugin design, and needs further consideration.
Max.
Re: groupId/artifactId mapping for Eclipse jars (was Re: in repo1
it is available)
Posted by Richard van Nieuwenhoven <ni...@cfc.at>.
ok, just changed my mind. after reading all comments and looking into my
needs now. I can work with with the mapping, specially because i need
only one at the moment.
It is MUCH more important there is a consistent mapping! Than it is that
somebody like me likes it or not.
Just see a lot of work coming .... and hole bunches of backward
compatibility stuff.
One of the troubles i see coming for example in the maven-eclipse-plugin
is convincing eclipse that a file reference to a jar in the local
repository called "resources.jar" should be handled as if it is called
"org.eclipse.core.resources.jar". In some cases i know it is possible in
others ....
Could somebody (hint-> "Carlos Sanchez") write a page on the maven site
about this discussion: about the naming of artifact's and the proper
handling in bundling plugin's. So next time somebody (like me) asks a
question that breaks lose a discussion, we can point the page for
the arguments. It can also be used as a reference for jira tasks in the
various bundling plugins so that all have the same handling, share the
same (activation) parameter names and share the same backward
compatibility handling.
Then with version 2.x.x of maven the default can be switched to the
"correct" handling.
Ritchie
Carlos Sanchez wrote:
> 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 <ca...@apache.org> 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 <ni...@gmail.com> 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 <ca...@apache.org>:
>>>> On Nov 28, 2007 7:09 PM, nicolas de loof <ni...@gmail.com> wrote:
>>>>> 2007/11/28, Carlos Sanchez <ca...@apache.org>:
>>>>>> 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: dev-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>
>>>>
>>
>>
>> --
>>
>> I could give you my word as a Spaniard.
>> No good. I've known too many Spaniards.
>> -- The Princess Bride
>>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: groupId/artifactId mapping for Eclipse jars (was Re: in repo1 it is available)
Posted by nicolas de loof <ni...@gmail.com>.
>
> > > 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
You're right : "IF" you create... but nobody did AFAIK. Only eclipse
artifacts like "*.*.resources.jar" does
> oh, and btw the war plugin already uses the groupId when in conflict :)
> http://jira.codehaus.org/browse/MWAR-19<http://jira.codehaus.org/browse/MWAR-19>
I was not aware of this feature.
Re: groupId/artifactId mapping for Eclipse jars (was Re: in repo1 it is available)
Posted by Carlos Sanchez <ca...@apache.org>.
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 <ca...@apache.org> 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 <ni...@gmail.com> 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 <ca...@apache.org>:
> > >
> > > On Nov 28, 2007 7:09 PM, nicolas de loof <ni...@gmail.com> wrote:
> > > > 2007/11/28, Carlos Sanchez <ca...@apache.org>:
> > > > > 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: dev-unsubscribe@maven.apache.org
> > > For additional commands, e-mail: dev-help@maven.apache.org
> > >
> > >
> >
>
>
>
> --
>
> 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: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: groupId/artifactId mapping for Eclipse jars (was Re: in repo1 it is available)
Posted by Carlos Sanchez <ca...@apache.org>.
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 <ni...@gmail.com> 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 <ca...@apache.org>:
> >
> > On Nov 28, 2007 7:09 PM, nicolas de loof <ni...@gmail.com> wrote:
> > > 2007/11/28, Carlos Sanchez <ca...@apache.org>:
> > > > 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: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
> >
>
--
I could give you my word as a Spaniard.
No good. I've known too many Spaniards.
-- The Princess Bride
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: groupId/artifactId mapping for Eclipse jars (was Re: in repo1 it is available)
Posted by nicolas de loof <ni...@gmail.com>.
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 <ca...@apache.org>:
>
> On Nov 28, 2007 7:09 PM, nicolas de loof <ni...@gmail.com> wrote:
> > 2007/11/28, Carlos Sanchez <ca...@apache.org>:
> > > 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: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: groupId/artifactId mapping for Eclipse jars (was Re: in repo1 it is available)
Posted by Carlos Sanchez <ca...@apache.org>.
On Nov 28, 2007 7:09 PM, nicolas de loof <ni...@gmail.com> wrote:
> 2007/11/28, Carlos Sanchez <ca...@apache.org>:
> > 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: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: groupId/artifactId mapping for Eclipse jars (was Re: in repo1 it is available)
Posted by nicolas de loof <ni...@gmail.com>.
2007/11/28, Carlos Sanchez <ca...@apache.org>:
>
> On Nov 28, 2007 6:40 PM, Richard van Nieuwenhoven <ni...@cfc.at> wrote:
> > The reason for me is that eclipse is the source of the jars and eclipse
> > does repeat the group name in the jar name.
> >
> > It looks very strange to have 10 different jars in the classpath all
> > called "resource.jar". And what would happen when you need to package
> > the jars together in a directory (ear, war, standalone tool). What would
> > the resulting MANIFEST.MF look like.
>
> 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...
Re: groupId/artifactId mapping for Eclipse jars (was Re: in repo1
it is available)
Posted by Richard van Nieuwenhoven <ni...@cfc.at>.
i do not think anybody want to change the repository:
id=groupId+artifactId
Just that the artifactId may include a part of the groupId
id=org.eclipse.core.org-eclipse-core-resources
I know now that that me have the osgi-id problem, but we have also the
grown average use factor to consider. I think we can live with long
names. In this case i see no problem stripping the "org" from the
artifactId so the id is:
id=org.eclipse.core.eclipse-core-resources
This way we can survive till the moment where there is only an id left
and no more groupId or artifactId. Relocations can then be used for a
smooth transition.
So can we find a way to suit both sides?
- keep the tools we have running
and
- move to a unique id
Ritchie
Carlos Sanchez wrote:
> As I said before it's easier to add the new bundles using
> id=groupId+artifactId than to change the whole repo so artifactId can
> be used as id
>
> You have to consider that the repository is not only for Maven users
>
>
> On Nov 28, 2007 7:51 PM, Max Bowsher <ma...@ukf.net> wrote:
>> Carlos Sanchez wrote:
>>> On Nov 28, 2007 6:40 PM, Richard van Nieuwenhoven <ni...@cfc.at> wrote:
>>>> The reason for me is that eclipse is the source of the jars and eclipse
>>>> does repeat the group name in the jar name.
>>>>
>>>> It looks very strange to have 10 different jars in the classpath all
>>>> called "resource.jar". And what would happen when you need to package
>>>> the jars together in a directory (ear, war, standalone tool). What would
>>>> the resulting MANIFEST.MF look like.
>>> 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
>> That might make a lot of sense for the future, but it really isn't the
>> current state of plugins and people's general expectations.
>>
>> For that reason, I submit that it would be a mistake to add a large
>> collection of jars to the central repository in a way highly likely to
>> cause confusion and name clashes.
>>
>>
>>
>> I have to say that there's a certain pleasant simplicity to using plain
>> artifactId names - it's certainly vastly easier to look at a lib
>> directory and quickly understand what's in there. In the vast majority
>> of projects there will be no clash at all, given the current tendencies
>> of choosing artifactIds.
>>
>> I'd even go so far to suggest that a sort of ad-hoc standard has grown
>> up of choosing an artifactId of what the originating project would
>> reasonably call the jar in the absence of Maven (subject to
>> conventionally allowed characters), and then prepending a suitable
>> groupId to ensure global uniqueness. If those rules are followed then
>> org.eclipse.core.resources_3.3.0.whatever.jar does quite reasonably map
>> to artifactId=org-eclipse-core-resources, groupId=org.eclipse.core.
>>
>> Max.
>>
>>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: groupId/artifactId mapping for Eclipse jars (was Re: in repo1
it is available)
Posted by Max Bowsher <ma...@ukf.net>.
Carlos Sanchez wrote:
> On Nov 28, 2007 8:07 PM, Max Bowsher <ma...@ukf.net> wrote:
>> Carlos Sanchez wrote:
>>> As I said before it's easier to add the new bundles using
>>> id=groupId+artifactId than to change the whole repo so artifactId can
>>> be used as id
>>>
>>> You have to consider that the repository is not only for Maven users
>> My point is that the repository is currently in a state where artifactId
>> *can* be used as a unique id in _most_ circumstances, and tools have
>> grown to rely on that (war, assembly plugins etc.), so it's perhaps not
>> such a good idea to change the repository so that is no longer true.
>
> we are NOT changing the repository. We are adding stuff to the
> repository, and if everybody lived until now without it, I don't
> anticipate a big problem on having it using the *same* layout as the
> rest, which is, to compose an id you need both groupId+artifactId
> Tools dont rely on just artifactId, maven doesn't, it just happens
> that most of the people don't hit that bug, coincidence
How can you say tools don't rely on just artifactId (being unique)?
That's exactly what the default functioning of the war-plugin's lib
directory creation, the jar-plugin's manifest Class-Path generation, the
assembly-plugin's dependencySet function, and presumably others rely on.
I agree that we're not suggesting changing anything existing in the
repository, but we are discussing adding a large number of artifacts
which would weaken the principle of "artifactId is almost always unique"
to "artifactId can't really be considered unique at all", changing a
concept of the repository as a whole.
>> A somewhat tangential idea just occurred to me: If the desired future
>> direction _does_ turn out to be that groupId and artifactId be
>> considered irrelevant apart from each other, would it make sense for a
>> future version of maven to simply have a POM syntax like this:?
>>
>> <dependency>
>> <id>org.eclipse.core.resources</id>
>> <version>3.2.1</version>
>> </dependency>
>>
>> Or, to put the question another way, is there any conceptual difference
>> between groupId and artifactId that suggests org.eclipse.core.resources
>> should map as groupId=org.eclipse.core artifactId=resources, rather than
>> groupId=org.eclipse artifactId=core.resources ?
>
> Maven resolution takes into account groupId+artifactId, whether you
> call it id or anything else it's an historical reason I guess.
> Groups are supposed to split the repo in the same way as domain names
> do. If you own org.eclipse I don't care if you put it in org.eclipse.x
> or org.eclipse.y, it's your problem. What we are talking here is about
> a way to automatically map osgi bundle ids to group/artifact ids, and
> I'm not going to be the one manually choosing what should be the group
> and artifact as then we'd never have the eclipse plugins in the repo
I understand: OSGi bundle ids *must* be programmatically mappable to
groupId/artifactId.
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?
Max.
Re: groupId/artifactId mapping for Eclipse jars (was Re: in repo1 it is available)
Posted by Carlos Sanchez <ca...@apache.org>.
On Nov 28, 2007 8:07 PM, Max Bowsher <ma...@ukf.net> wrote:
> Carlos Sanchez wrote:
> > As I said before it's easier to add the new bundles using
> > id=groupId+artifactId than to change the whole repo so artifactId can
> > be used as id
> >
> > You have to consider that the repository is not only for Maven users
>
> My point is that the repository is currently in a state where artifactId
> *can* be used as a unique id in _most_ circumstances, and tools have
> grown to rely on that (war, assembly plugins etc.), so it's perhaps not
> such a good idea to change the repository so that is no longer true.
we are NOT changing the repository. We are adding stuff to the
repository, and if everybody lived until now without it, I don't
anticipate a big problem on having it using the *same* layout as the
rest, which is, to compose an id you need both groupId+artifactId
Tools dont rely on just artifactId, maven doesn't, it just happens
that most of the people don't hit that bug, coincidence
>
>
>
> A somewhat tangential idea just occurred to me: If the desired future
> direction _does_ turn out to be that groupId and artifactId be
> considered irrelevant apart from each other, would it make sense for a
> future version of maven to simply have a POM syntax like this:?
>
> <dependency>
> <id>org.eclipse.core.resources</id>
> <version>3.2.1</version>
> </dependency>
>
> Or, to put the question another way, is there any conceptual difference
> between groupId and artifactId that suggests org.eclipse.core.resources
> should map as groupId=org.eclipse.core artifactId=resources, rather than
> groupId=org.eclipse artifactId=core.resources ?
Maven resolution takes into account groupId+artifactId, whether you
call it id or anything else it's an historical reason I guess.
Groups are supposed to split the repo in the same way as domain names
do. If you own org.eclipse I don't care if you put it in org.eclipse.x
or org.eclipse.y, it's your problem. What we are talking here is about
a way to automatically map osgi bundle ids to group/artifact ids, and
I'm not going to be the one manually choosing what should be the group
and artifact as then we'd never have the eclipse plugins in the repo
>
>
> Max.
>
>
>
--
I could give you my word as a Spaniard.
No good. I've known too many Spaniards.
-- The Princess Bride
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: groupId/artifactId mapping for Eclipse jars (was Re: in repo1
it is available)
Posted by Max Bowsher <ma...@ukf.net>.
Carlos Sanchez wrote:
> As I said before it's easier to add the new bundles using
> id=groupId+artifactId than to change the whole repo so artifactId can
> be used as id
>
> You have to consider that the repository is not only for Maven users
My point is that the repository is currently in a state where artifactId
*can* be used as a unique id in _most_ circumstances, and tools have
grown to rely on that (war, assembly plugins etc.), so it's perhaps not
such a good idea to change the repository so that is no longer true.
A somewhat tangential idea just occurred to me: If the desired future
direction _does_ turn out to be that groupId and artifactId be
considered irrelevant apart from each other, would it make sense for a
future version of maven to simply have a POM syntax like this:?
<dependency>
<id>org.eclipse.core.resources</id>
<version>3.2.1</version>
</dependency>
Or, to put the question another way, is there any conceptual difference
between groupId and artifactId that suggests org.eclipse.core.resources
should map as groupId=org.eclipse.core artifactId=resources, rather than
groupId=org.eclipse artifactId=core.resources ?
Max.
Re: groupId/artifactId mapping for Eclipse jars (was Re: in repo1 it is available)
Posted by Carlos Sanchez <ca...@apache.org>.
As I said before it's easier to add the new bundles using
id=groupId+artifactId than to change the whole repo so artifactId can
be used as id
You have to consider that the repository is not only for Maven users
On Nov 28, 2007 7:51 PM, Max Bowsher <ma...@ukf.net> wrote:
> Carlos Sanchez wrote:
> > On Nov 28, 2007 6:40 PM, Richard van Nieuwenhoven <ni...@cfc.at> wrote:
> >> The reason for me is that eclipse is the source of the jars and eclipse
> >> does repeat the group name in the jar name.
> >>
> >> It looks very strange to have 10 different jars in the classpath all
> >> called "resource.jar". And what would happen when you need to package
> >> the jars together in a directory (ear, war, standalone tool). What would
> >> the resulting MANIFEST.MF look like.
> >
> > 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
>
> That might make a lot of sense for the future, but it really isn't the
> current state of plugins and people's general expectations.
>
> For that reason, I submit that it would be a mistake to add a large
> collection of jars to the central repository in a way highly likely to
> cause confusion and name clashes.
>
>
>
> I have to say that there's a certain pleasant simplicity to using plain
> artifactId names - it's certainly vastly easier to look at a lib
> directory and quickly understand what's in there. In the vast majority
> of projects there will be no clash at all, given the current tendencies
> of choosing artifactIds.
>
> I'd even go so far to suggest that a sort of ad-hoc standard has grown
> up of choosing an artifactId of what the originating project would
> reasonably call the jar in the absence of Maven (subject to
> conventionally allowed characters), and then prepending a suitable
> groupId to ensure global uniqueness. If those rules are followed then
> org.eclipse.core.resources_3.3.0.whatever.jar does quite reasonably map
> to artifactId=org-eclipse-core-resources, groupId=org.eclipse.core.
>
> Max.
>
>
--
I could give you my word as a Spaniard.
No good. I've known too many Spaniards.
-- The Princess Bride
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: groupId/artifactId mapping for Eclipse jars (was Re: in repo1
it is available)
Posted by Max Bowsher <ma...@ukf.net>.
Carlos Sanchez wrote:
> On Nov 28, 2007 6:40 PM, Richard van Nieuwenhoven <ni...@cfc.at> wrote:
>> The reason for me is that eclipse is the source of the jars and eclipse
>> does repeat the group name in the jar name.
>>
>> It looks very strange to have 10 different jars in the classpath all
>> called "resource.jar". And what would happen when you need to package
>> the jars together in a directory (ear, war, standalone tool). What would
>> the resulting MANIFEST.MF look like.
>
> 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
That might make a lot of sense for the future, but it really isn't the
current state of plugins and people's general expectations.
For that reason, I submit that it would be a mistake to add a large
collection of jars to the central repository in a way highly likely to
cause confusion and name clashes.
I have to say that there's a certain pleasant simplicity to using plain
artifactId names - it's certainly vastly easier to look at a lib
directory and quickly understand what's in there. In the vast majority
of projects there will be no clash at all, given the current tendencies
of choosing artifactIds.
I'd even go so far to suggest that a sort of ad-hoc standard has grown
up of choosing an artifactId of what the originating project would
reasonably call the jar in the absence of Maven (subject to
conventionally allowed characters), and then prepending a suitable
groupId to ensure global uniqueness. If those rules are followed then
org.eclipse.core.resources_3.3.0.whatever.jar does quite reasonably map
to artifactId=org-eclipse-core-resources, groupId=org.eclipse.core.
Max.
Re: groupId/artifactId mapping for Eclipse jars (was Re: in repo1
it is available)
Posted by Richard van Nieuwenhoven <ni...@cfc.at>.
Hi,
Such changes will not happen easy! think about the consequences in all
existing MANIFEST.MF files with classpaths .....
Most users will use the group id as a organizational help but still use
"almost" unique artifactId's as identifications. -> When i see the name
of the jar i know what it is.
Ritchie
Carlos Sanchez wrote:
> On Nov 28, 2007 6:40 PM, Richard van Nieuwenhoven <ni...@cfc.at> wrote:
>> The reason for me is that eclipse is the source of the jars and eclipse
>> does repeat the group name in the jar name.
>>
>> It looks very strange to have 10 different jars in the classpath all
>> called "resource.jar". And what would happen when you need to package
>> the jars together in a directory (ear, war, standalone tool). What would
>> the resulting MANIFEST.MF look like.
>
> 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
>
>> Sorry to reopen this discussion, but i think a jar's name should be as
>> near as possible to the original jar name.
>>
>> It is done all the time, example:
>> "maven-eclipse-plugin" is not called "eclipse" because the groupId
>> contains "maven" and "plugin".
>
> but i think if groupid is org.apache.maven.plugins then the artifact
> should be just eclipse. Doesnt happen now, but it probably should
>
>> Ritchie
>>
>>
>>
>>
>> Carlos Sanchez wrote:
>>> why would we use groupIds and artifactIds if we were going to repeat
>>> the same information in both fields?
>>>
>>> this was already brought before and the way the jars are stored
>>> doesn't imply the way they are used
>>>
>>> On Nov 27, 2007 8:12 PM, Richard van Nieuwenhoven <ri...@gmx.at> wrote:
>>>> I think it is important that {artifactId}-{version}.jar results in a
>>>> name as similar as possible the the name as they are in the plugin
>>>> directory of eclipse.
>>>>
>>>> And the eclipse project name should represent the group id of the plugin
>>>> as on http://www.eclipse.org/projects/ , whereas i do not care if only
>>>> top-level-projects are used as group-id's. Or (to keep it simple) just
>>>> use the first three words as a groupId....
>>>>
>>>> this way the jar should be:
>>>>
>>>> <groupId>org.eclipse.platform</groupId>
>>>> <artefactId>org-eclipse-core-resources</artefactId>
>>>> <version>3.2.1</version>
>>>>
>>>> or
>>>>
>>>> <groupId>org.eclipse.platform.core</groupId>
>>>> <artefactId>org-eclipse-core-resources</artefactId>
>>>> <version>3.2.1</version>
>>>>
>>>> or
>>>>
>>>> <groupId>org.eclipse.core</groupId>
>>>> <artefactId>org-eclipse-core-resources</artefactId>
>>>> <version>3.2.1</version>
>>>>
>>>> any other idea's...
>>>>
>>>> Ritchie
>>>>
>>>>
>>>> Max Bowsher wrote:
>>>>> Carlos Sanchez wrote:
>>>>>> I'm uploading right now a good number of jars to
>>>>>> http://repo1.maven.org/eclipse-staging/
>>>>>> If it looks good I will sync to central
>>>>>>
>>>>>> Note that the location for the one you want should be
>>>>>> http://repo1.maven.org/eclipse-staging/org/eclipse/core/resources/3.2.1/
>>>>> I wonder if this groupId:artifactId mapping is a bad idea?
>>>>>
>>>>> Most jars in the repository have an artifactId which is, whilst not
>>>>> necessarily globally unique, good enough to give you a pretty good idea
>>>>> what they are. This is a good thing, since there are several use cases
>>>>> where a collection of jars is bundled into a single directory, and those
>>>>> jars are named {artifactId}-{version}.jar (e.g, war file WEB-INF/lib/,
>>>>> common usage of assembly plugin).
>>>>>
>>>>> The suggested mapping of just taking the last component of the name as
>>>>> the artifactId will lead to many artifacts with non-descriptive and
>>>>> clashing names like "common", "core", "ui", etc. At best case, this
>>>>> will merely be horrendously confusing for humans attempting to
>>>>> understand and debug these generated collections of jars. At worst case,
>>>>> some of the artifacts will not only have the same artifactId, but same
>>>>> version too, and will overwrite each other.
>>>>>
>>>>> So, I think the current mapping fits poorly with existing Maven
>>>>> use-cases and plugin design, and needs further consideration.
>>>>>
>>>>> Max.
>>>>>
>>>>>
>>>>>
>>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>
>>>>
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: groupId/artifactId mapping for Eclipse jars (was Re: in repo1 it is available)
Posted by Carlos Sanchez <ca...@apache.org>.
On Nov 28, 2007 6:40 PM, Richard van Nieuwenhoven <ni...@cfc.at> wrote:
> The reason for me is that eclipse is the source of the jars and eclipse
> does repeat the group name in the jar name.
>
> It looks very strange to have 10 different jars in the classpath all
> called "resource.jar". And what would happen when you need to package
> the jars together in a directory (ear, war, standalone tool). What would
> the resulting MANIFEST.MF look like.
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
>
> Sorry to reopen this discussion, but i think a jar's name should be as
> near as possible to the original jar name.
>
> It is done all the time, example:
> "maven-eclipse-plugin" is not called "eclipse" because the groupId
> contains "maven" and "plugin".
but i think if groupid is org.apache.maven.plugins then the artifact
should be just eclipse. Doesnt happen now, but it probably should
>
> Ritchie
>
>
>
>
> Carlos Sanchez wrote:
> > why would we use groupIds and artifactIds if we were going to repeat
> > the same information in both fields?
> >
> > this was already brought before and the way the jars are stored
> > doesn't imply the way they are used
> >
> > On Nov 27, 2007 8:12 PM, Richard van Nieuwenhoven <ri...@gmx.at> wrote:
> >> I think it is important that {artifactId}-{version}.jar results in a
> >> name as similar as possible the the name as they are in the plugin
> >> directory of eclipse.
> >>
> >> And the eclipse project name should represent the group id of the plugin
> >> as on http://www.eclipse.org/projects/ , whereas i do not care if only
> >> top-level-projects are used as group-id's. Or (to keep it simple) just
> >> use the first three words as a groupId....
> >>
> >> this way the jar should be:
> >>
> >> <groupId>org.eclipse.platform</groupId>
> >> <artefactId>org-eclipse-core-resources</artefactId>
> >> <version>3.2.1</version>
> >>
> >> or
> >>
> >> <groupId>org.eclipse.platform.core</groupId>
> >> <artefactId>org-eclipse-core-resources</artefactId>
> >> <version>3.2.1</version>
> >>
> >> or
> >>
> >> <groupId>org.eclipse.core</groupId>
> >> <artefactId>org-eclipse-core-resources</artefactId>
> >> <version>3.2.1</version>
> >>
> >> any other idea's...
> >>
> >> Ritchie
> >>
> >>
> >> Max Bowsher wrote:
> >>> Carlos Sanchez wrote:
> >>>> I'm uploading right now a good number of jars to
> >>>> http://repo1.maven.org/eclipse-staging/
> >>>> If it looks good I will sync to central
> >>>>
> >>>> Note that the location for the one you want should be
> >>>> http://repo1.maven.org/eclipse-staging/org/eclipse/core/resources/3.2.1/
> >>> I wonder if this groupId:artifactId mapping is a bad idea?
> >>>
> >>> Most jars in the repository have an artifactId which is, whilst not
> >>> necessarily globally unique, good enough to give you a pretty good idea
> >>> what they are. This is a good thing, since there are several use cases
> >>> where a collection of jars is bundled into a single directory, and those
> >>> jars are named {artifactId}-{version}.jar (e.g, war file WEB-INF/lib/,
> >>> common usage of assembly plugin).
> >>>
> >>> The suggested mapping of just taking the last component of the name as
> >>> the artifactId will lead to many artifacts with non-descriptive and
> >>> clashing names like "common", "core", "ui", etc. At best case, this
> >>> will merely be horrendously confusing for humans attempting to
> >>> understand and debug these generated collections of jars. At worst case,
> >>> some of the artifacts will not only have the same artifactId, but same
> >>> version too, and will overwrite each other.
> >>>
> >>> So, I think the current mapping fits poorly with existing Maven
> >>> use-cases and plugin design, and needs further consideration.
> >>>
> >>> Max.
> >>>
> >>>
> >>>
> >>>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >> For additional commands, e-mail: dev-help@maven.apache.org
> >>
> >>
> >
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
--
I could give you my word as a Spaniard.
No good. I've known too many Spaniards.
-- The Princess Bride
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: groupId/artifactId mapping for Eclipse jars (was Re: in repo1 it is available)
Posted by nicolas de loof <ni...@gmail.com>.
AFAIK we could argue for the same about maven-side artifacts :
why is plexus-utils not simply "utils.jar", as it allready has groupId
"plexus" ?
Nico.
2007/11/28, Richard van Nieuwenhoven <ni...@cfc.at>:
>
> The reason for me is that eclipse is the source of the jars and eclipse
> does repeat the group name in the jar name.
>
> It looks very strange to have 10 different jars in the classpath all
> called "resource.jar". And what would happen when you need to package
> the jars together in a directory (ear, war, standalone tool). What would
> the resulting MANIFEST.MF look like.
>
> Sorry to reopen this discussion, but i think a jar's name should be as
> near as possible to the original jar name.
>
> It is done all the time, example:
> "maven-eclipse-plugin" is not called "eclipse" because the groupId
> contains "maven" and "plugin".
>
> Ritchie
>
>
>
> Carlos Sanchez wrote:
> > why would we use groupIds and artifactIds if we were going to repeat
> > the same information in both fields?
> >
> > this was already brought before and the way the jars are stored
> > doesn't imply the way they are used
> >
> > On Nov 27, 2007 8:12 PM, Richard van Nieuwenhoven <ri...@gmx.at>
> wrote:
> >> I think it is important that {artifactId}-{version}.jar results in a
> >> name as similar as possible the the name as they are in the plugin
> >> directory of eclipse.
> >>
> >> And the eclipse project name should represent the group id of the
> plugin
> >> as on http://www.eclipse.org/projects/ , whereas i do not care if only
> >> top-level-projects are used as group-id's. Or (to keep it simple) just
> >> use the first three words as a groupId....
> >>
> >> this way the jar should be:
> >>
> >> <groupId>org.eclipse.platform</groupId>
> >> <artefactId>org-eclipse-core-resources</artefactId>
> >> <version>3.2.1</version>
> >>
> >> or
> >>
> >> <groupId>org.eclipse.platform.core</groupId>
> >> <artefactId>org-eclipse-core-resources</artefactId>
> >> <version>3.2.1</version>
> >>
> >> or
> >>
> >> <groupId>org.eclipse.core</groupId>
> >> <artefactId>org-eclipse-core-resources</artefactId>
> >> <version>3.2.1</version>
> >>
> >> any other idea's...
> >>
> >> Ritchie
> >>
> >>
> >> Max Bowsher wrote:
> >>> Carlos Sanchez wrote:
> >>>> I'm uploading right now a good number of jars to
> >>>> http://repo1.maven.org/eclipse-staging/
> >>>> If it looks good I will sync to central
> >>>>
> >>>> Note that the location for the one you want should be
> >>>>
> http://repo1.maven.org/eclipse-staging/org/eclipse/core/resources/3.2.1/
> >>> I wonder if this groupId:artifactId mapping is a bad idea?
> >>>
> >>> Most jars in the repository have an artifactId which is, whilst not
> >>> necessarily globally unique, good enough to give you a pretty good
> idea
> >>> what they are. This is a good thing, since there are several use cases
> >>> where a collection of jars is bundled into a single directory, and
> those
> >>> jars are named {artifactId}-{version}.jar (e.g, war file WEB-INF/lib/,
> >>> common usage of assembly plugin).
> >>>
> >>> The suggested mapping of just taking the last component of the name as
> >>> the artifactId will lead to many artifacts with non-descriptive and
> >>> clashing names like "common", "core", "ui", etc. At best case, this
> >>> will merely be horrendously confusing for humans attempting to
> >>> understand and debug these generated collections of jars. At worst
> case,
> >>> some of the artifacts will not only have the same artifactId, but
> same
> >>> version too, and will overwrite each other.
> >>>
> >>> So, I think the current mapping fits poorly with existing Maven
> >>> use-cases and plugin design, and needs further consideration.
> >>>
> >>> Max.
> >>>
> >>>
> >>>
> >>>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >> For additional commands, e-mail: dev-help@maven.apache.org
> >>
> >>
> >
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: groupId/artifactId mapping for Eclipse jars (was Re: in repo1
it is available)
Posted by Richard van Nieuwenhoven <ni...@cfc.at>.
The reason for me is that eclipse is the source of the jars and eclipse
does repeat the group name in the jar name.
It looks very strange to have 10 different jars in the classpath all
called "resource.jar". And what would happen when you need to package
the jars together in a directory (ear, war, standalone tool). What would
the resulting MANIFEST.MF look like.
Sorry to reopen this discussion, but i think a jar's name should be as
near as possible to the original jar name.
It is done all the time, example:
"maven-eclipse-plugin" is not called "eclipse" because the groupId
contains "maven" and "plugin".
Ritchie
Carlos Sanchez wrote:
> why would we use groupIds and artifactIds if we were going to repeat
> the same information in both fields?
>
> this was already brought before and the way the jars are stored
> doesn't imply the way they are used
>
> On Nov 27, 2007 8:12 PM, Richard van Nieuwenhoven <ri...@gmx.at> wrote:
>> I think it is important that {artifactId}-{version}.jar results in a
>> name as similar as possible the the name as they are in the plugin
>> directory of eclipse.
>>
>> And the eclipse project name should represent the group id of the plugin
>> as on http://www.eclipse.org/projects/ , whereas i do not care if only
>> top-level-projects are used as group-id's. Or (to keep it simple) just
>> use the first three words as a groupId....
>>
>> this way the jar should be:
>>
>> <groupId>org.eclipse.platform</groupId>
>> <artefactId>org-eclipse-core-resources</artefactId>
>> <version>3.2.1</version>
>>
>> or
>>
>> <groupId>org.eclipse.platform.core</groupId>
>> <artefactId>org-eclipse-core-resources</artefactId>
>> <version>3.2.1</version>
>>
>> or
>>
>> <groupId>org.eclipse.core</groupId>
>> <artefactId>org-eclipse-core-resources</artefactId>
>> <version>3.2.1</version>
>>
>> any other idea's...
>>
>> Ritchie
>>
>>
>> Max Bowsher wrote:
>>> Carlos Sanchez wrote:
>>>> I'm uploading right now a good number of jars to
>>>> http://repo1.maven.org/eclipse-staging/
>>>> If it looks good I will sync to central
>>>>
>>>> Note that the location for the one you want should be
>>>> http://repo1.maven.org/eclipse-staging/org/eclipse/core/resources/3.2.1/
>>> I wonder if this groupId:artifactId mapping is a bad idea?
>>>
>>> Most jars in the repository have an artifactId which is, whilst not
>>> necessarily globally unique, good enough to give you a pretty good idea
>>> what they are. This is a good thing, since there are several use cases
>>> where a collection of jars is bundled into a single directory, and those
>>> jars are named {artifactId}-{version}.jar (e.g, war file WEB-INF/lib/,
>>> common usage of assembly plugin).
>>>
>>> The suggested mapping of just taking the last component of the name as
>>> the artifactId will lead to many artifacts with non-descriptive and
>>> clashing names like "common", "core", "ui", etc. At best case, this
>>> will merely be horrendously confusing for humans attempting to
>>> understand and debug these generated collections of jars. At worst case,
>>> some of the artifacts will not only have the same artifactId, but same
>>> version too, and will overwrite each other.
>>>
>>> So, I think the current mapping fits poorly with existing Maven
>>> use-cases and plugin design, and needs further consideration.
>>>
>>> Max.
>>>
>>>
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: groupId/artifactId mapping for Eclipse jars (was Re: in repo1 it is available)
Posted by Carlos Sanchez <ca...@apache.org>.
why would we use groupIds and artifactIds if we were going to repeat
the same information in both fields?
this was already brought before and the way the jars are stored
doesn't imply the way they are used
On Nov 27, 2007 8:12 PM, Richard van Nieuwenhoven <ri...@gmx.at> wrote:
> I think it is important that {artifactId}-{version}.jar results in a
> name as similar as possible the the name as they are in the plugin
> directory of eclipse.
>
> And the eclipse project name should represent the group id of the plugin
> as on http://www.eclipse.org/projects/ , whereas i do not care if only
> top-level-projects are used as group-id's. Or (to keep it simple) just
> use the first three words as a groupId....
>
> this way the jar should be:
>
> <groupId>org.eclipse.platform</groupId>
> <artefactId>org-eclipse-core-resources</artefactId>
> <version>3.2.1</version>
>
> or
>
> <groupId>org.eclipse.platform.core</groupId>
> <artefactId>org-eclipse-core-resources</artefactId>
> <version>3.2.1</version>
>
> or
>
> <groupId>org.eclipse.core</groupId>
> <artefactId>org-eclipse-core-resources</artefactId>
> <version>3.2.1</version>
>
> any other idea's...
>
> Ritchie
>
>
> Max Bowsher wrote:
> > Carlos Sanchez wrote:
> >> I'm uploading right now a good number of jars to
> >> http://repo1.maven.org/eclipse-staging/
> >> If it looks good I will sync to central
> >>
> >> Note that the location for the one you want should be
> >> http://repo1.maven.org/eclipse-staging/org/eclipse/core/resources/3.2.1/
> >
> > I wonder if this groupId:artifactId mapping is a bad idea?
> >
> > Most jars in the repository have an artifactId which is, whilst not
> > necessarily globally unique, good enough to give you a pretty good idea
> > what they are. This is a good thing, since there are several use cases
> > where a collection of jars is bundled into a single directory, and those
> > jars are named {artifactId}-{version}.jar (e.g, war file WEB-INF/lib/,
> > common usage of assembly plugin).
> >
> > The suggested mapping of just taking the last component of the name as
> > the artifactId will lead to many artifacts with non-descriptive and
> > clashing names like "common", "core", "ui", etc. At best case, this
> > will merely be horrendously confusing for humans attempting to
> > understand and debug these generated collections of jars. At worst case,
> > some of the artifacts will not only have the same artifactId, but same
> > version too, and will overwrite each other.
> >
> > So, I think the current mapping fits poorly with existing Maven
> > use-cases and plugin design, and needs further consideration.
> >
> > Max.
> >
> >
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
--
I could give you my word as a Spaniard.
No good. I've known too many Spaniards.
-- The Princess Bride
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: groupId/artifactId mapping for Eclipse jars (was Re: in repo1
it is available)
Posted by Richard van Nieuwenhoven <ri...@gmx.at>.
I think it is important that {artifactId}-{version}.jar results in a
name as similar as possible the the name as they are in the plugin
directory of eclipse.
And the eclipse project name should represent the group id of the plugin
as on http://www.eclipse.org/projects/ , whereas i do not care if only
top-level-projects are used as group-id's. Or (to keep it simple) just
use the first three words as a groupId....
this way the jar should be:
<groupId>org.eclipse.platform</groupId>
<artefactId>org-eclipse-core-resources</artefactId>
<version>3.2.1</version>
or
<groupId>org.eclipse.platform.core</groupId>
<artefactId>org-eclipse-core-resources</artefactId>
<version>3.2.1</version>
or
<groupId>org.eclipse.core</groupId>
<artefactId>org-eclipse-core-resources</artefactId>
<version>3.2.1</version>
any other idea's...
Ritchie
Max Bowsher wrote:
> Carlos Sanchez wrote:
>> I'm uploading right now a good number of jars to
>> http://repo1.maven.org/eclipse-staging/
>> If it looks good I will sync to central
>>
>> Note that the location for the one you want should be
>> http://repo1.maven.org/eclipse-staging/org/eclipse/core/resources/3.2.1/
>
> I wonder if this groupId:artifactId mapping is a bad idea?
>
> Most jars in the repository have an artifactId which is, whilst not
> necessarily globally unique, good enough to give you a pretty good idea
> what they are. This is a good thing, since there are several use cases
> where a collection of jars is bundled into a single directory, and those
> jars are named {artifactId}-{version}.jar (e.g, war file WEB-INF/lib/,
> common usage of assembly plugin).
>
> The suggested mapping of just taking the last component of the name as
> the artifactId will lead to many artifacts with non-descriptive and
> clashing names like "common", "core", "ui", etc. At best case, this
> will merely be horrendously confusing for humans attempting to
> understand and debug these generated collections of jars. At worst case,
> some of the artifacts will not only have the same artifactId, but same
> version too, and will overwrite each other.
>
> So, I think the current mapping fits poorly with existing Maven
> use-cases and plugin design, and needs further consideration.
>
> Max.
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org