Re: Maven Error -" is duplicated in the reactor "

[Kenney Westerhof <ke...@apache.org>]

Hi,


Jo Vandermeeren wrote:
> On 5/30/07, Stefano Bagnara <ap...@bago.org> 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: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

Re: Maven Error -" is duplicated in the reactor "

[Jo Vandermeeren <Jo...@ordina.be>]

Thanks for your interesting comments Kenney!

On 6/16/07, Kenney Westerhof <ke...@apache.org> wrote:
>
> Hi,
>
>
> Jo Vandermeeren wrote:
> > On 5/30/07, Stefano Bagnara <ap...@bago.org> 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: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>