Carlos Sanchez wrote: > On Nov 28, 2007 8:07 PM, Max Bowsher <[EMAIL PROTECTED]> wrote: >> 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 >> My point is that the repository is currently in a state where artifactId >> *can* be used as a unique id in _most_ circumstances, and tools have >> grown to rely on that (war, assembly plugins etc.), so it's perhaps not >> such a good idea to change the repository so that is no longer true. > > we are NOT changing the repository. We are adding stuff to the > repository, and if everybody lived until now without it, I don't > anticipate a big problem on having it using the *same* layout as the > rest, which is, to compose an id you need both groupId+artifactId > Tools dont rely on just artifactId, maven doesn't, it just happens > that most of the people don't hit that bug, coincidence
How can you say tools don't rely on just artifactId (being unique)? That's exactly what the default functioning of the war-plugin's lib directory creation, the jar-plugin's manifest Class-Path generation, the assembly-plugin's dependencySet function, and presumably others rely on. I agree that we're not suggesting changing anything existing in the repository, but we are discussing adding a large number of artifacts which would weaken the principle of "artifactId is almost always unique" to "artifactId can't really be considered unique at all", changing a concept of the repository as a whole. >> A somewhat tangential idea just occurred to me: If the desired future >> direction _does_ turn out to be that groupId and artifactId be >> considered irrelevant apart from each other, would it make sense for a >> future version of maven to simply have a POM syntax like this:? >> >> <dependency> >> <id>org.eclipse.core.resources</id> >> <version>3.2.1</version> >> </dependency> >> >> Or, to put the question another way, is there any conceptual difference >> between groupId and artifactId that suggests org.eclipse.core.resources >> should map as groupId=org.eclipse.core artifactId=resources, rather than >> groupId=org.eclipse artifactId=core.resources ? > > Maven resolution takes into account groupId+artifactId, whether you > call it id or anything else it's an historical reason I guess. > Groups are supposed to split the repo in the same way as domain names > do. If you own org.eclipse I don't care if you put it in org.eclipse.x > or org.eclipse.y, it's your problem. What we are talking here is about > a way to automatically map osgi bundle ids to group/artifact ids, and > I'm not going to be the one manually choosing what should be the group > and artifact as then we'd never have the eclipse plugins in the repo I understand: OSGi bundle ids *must* be programmatically mappable to groupId/artifactId. I totally agree that tools which rely on artifactId-uniqueness are technically broken, but is it right to choose a programmatic mapping which increases the severity of this breakage? Max.
signature.asc
Description: OpenPGP digital signature
