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]
