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 <[EMAIL PROTECTED]> wrote: >> Carlos Sanchez wrote: >>> On Nov 28, 2007 6:40 PM, Richard van Nieuwenhoven <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
