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.
signature.asc
Description: OpenPGP digital signature
