On 5/30/07, Stefano Bagnara <[EMAIL PROTECTED]> wrote:
This is not coherent. You say groupId + artifactId + versionId uniquely identify an artifact. So I should be able to manage multiple versions of the same artifact in a single reactor build. What you say should only apply to 2 modules having all 3 values identical... Is this considered a limit of maven?
Stefano, The combination of groupId, artifactId, version (and possibly the classifier of a build output) are indeed used to uniquely identify an artifact in a Maven repository. The module definition is something completely different. For what it's worth.. Here is how I think how module definitions and their resolution work.. A build in Maven starts with a project descriptor (the pom.xml file in the current working directory). This project can be either a single-module project, or a multi-module project. If the project is a single-module project, the reactor sequence is fairly simple. Only this one project is built. If the project contains multiple modules, Maven will take the module names and append them to the current working directory path. The result of this operation is a path to a subdirectory of the current working directory. In this subdirectory, Maven will look for a pom.xml file, which, again, can be either a single-module project or a multi-module project (same logic is applied recursively). Maven will inspect inter-module dependencies and tries to arrange the build sequence in such a way that those module dependencies are built before the module that depends on them. The convention for modules of a pom-packaged project is to use the artifactId as the module name and thus relative directory name. Because of the chosen strategy (module name as part of the relative directory path), you can not define modules with the same artifactId (=module name) in the parent POM. Well, actually it is due to the naming convention of modules, I guess. I haven't had the need to give them another name than their artifactId, so I can't be sure of it. Could be that the entries in the reactor are actually identified by resolving the module's POM details to a full artifact "path" (groupId:artifactId etc..). If so, then my statement is incorrect. Anyway, even then, the module names should still need to be unique. Is this a limitation of Maven? Maybe. It is definitely worth a discussion but probably not on the users list. The least you can say about this decision is that it is faster than a lookup in the repository, and it makes the module definition a lot less complex. And in the end, that's what we all want, isn't it :) So.. You can not build multiple versions of a project in one build. But why on earth would you want to build totally different codebases of a project in a single build? That sounds a bit like smashing together irrelevant parts. The only thing I can think of that remotely matches the context of your question is product development with parallel development of different release versions at the same time. But even then, I would not define them as modules of a master build definition and still build them separately. Feel free to comment.. Cheers Jo
