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] > >