Hi,
Jo Vandermeeren wrote:
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.
Correct.
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.
It's the convention, but not a rule. You can have a module name
that differs from the artifactId of that module.
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.
Yes you can, since modulename!=artifactid. You can have a module a/pom.xml,
and copy that to b/pom.xml, and have the parent declare both a and b
as modules. That's why you get the 'artifact X is duplicated in the reactor'.
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.
Yup, it is. The reactor uniquely identifies projects/modules as
groupId:artifactId.
Anyway, even then, the module names should still need to be unique.
nope ;)
Is this a limitation of Maven?
Maybe. It is definitely worth a discussion but probably not on the users
list.
It's definitely a limitation. Maven assumes it'll only build 1 version of 1
module
in 1 reactor. It shouldn't, but it does. The reason for this is to avoid
recursion,
though when the version would be taken into account (in the unique identifier
for
the module/project), it should be possible to build 2 versions of the same
artifact in
the same reactor build.
Another reason this isn't done is because maven is usually run against some
checkout
of an SCM like svn, and normally there's only 1 version of a project there.
The only reason to build multiple versions of the same artifact in 1 go I can
think of,
is for maven integration testing.
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 :)
Maven reads the pom.xml files pointed to by the module path, and when it's
building
a project, it never looks at the repository for information for that project
itself.
It does however look at a repository for parents (after trying your workspace
first),
and dependencies.
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.
Exactly.
There's one other reason you can get this error though; a bug in maven.
I had a 2 module project, with the parent residing next to the modules (flat
structure).
Running 'mvn -r install' gave me the error that the parent was duplicated.
Is it something like this that's causing it?
-- Kenney
Feel free to comment..
Cheers
Jo
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
