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 <[EMAIL PROTECTED]>:
>
> 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 <[EMAIL PROTECTED]>
> 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: [EMAIL PROTECTED]
> >> For additional commands, e-mail: [EMAIL PROTECTED]
> >>
> >>
> >
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

Reply via email to