You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@maven.apache.org by Trevor Torrez <ja...@gmail.com> on 2007/01/04 01:18:17 UTC
multi project interdependencies
Is it the suggested / best practice to have a subproject in a multi project
setup to declare it's dependencies on the other subprojects in the
dependency section? This leads to requiring some parts of the multi-project
to be installed to the local repository before other parts can be developed
(using the eclipse:eclipse goal fails if the dependency / subproject is not
installed). Or is there a better way?
Re: multi project interdependencies
Posted by Trevor Torrez <ja...@gmail.com>.
Ok; just checking; so what is the point of having the maven-eclipse-plugin
generate dependencies on subprojects in eclipse (
http://maven.apache.org/plugins/maven-eclipse-plugin/eclipse-mojo.html#useProjectReferences),
since it has to get the artifacts from the repository anyway to successfully
run 'mvn eclipse:eclipse'?
On 1/4/07, Alan D. Salewski <as...@healthmarketscience.com> wrote:
>
> On Wed, Jan 03, 2007 at 07:18:17PM -0500, Trevor Torrez spake thus:
> > Is it the suggested / best practice to have a subproject in a multi
> project
> > setup to declare it's dependencies on the other subprojects in the
> > dependency section?
>
> Yes.
>
>
> > This leads to requiring some parts of the multi-project
> > to be installed to the local repository before other parts can be
> developed
> > (using the eclipse:eclipse goal fails if the dependency / subproject is
> not
> > installed). [...]
>
> That's correct. The reason is that maven-2.x is (by design) repository
> based; when maven needs a dependency, it looks for it in your local
> repos (regardless of whether it's another subproject within the project
> that is building, or something else). That's just how it's supposed to
> work.
>
> -Al
>
> --
> :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: ::
> ::
> Alan D. Salewski
> Software Developer
> Health Market Science, Inc.
> :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: ::
> ::
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
Re: [m2] multi project interdependencies
Posted by mark_in_gr <mc...@xrite.com>.
But then how does Maven know that it needs to re-build the parent artifact?
Based on the changing snapshot id tied to the dependency taken from the
repo?
Alan D. Salewski wrote:
>
> On Wed, Jan 03, 2007 at 07:18:17PM -0500, Trevor Torrez spake thus:
>> Is it the suggested / best practice to have a subproject in a multi
>> project
>> setup to declare it's dependencies on the other subprojects in the
>> dependency section?
>
> Yes.
>
>
>> This leads to requiring some parts of the multi-project
>> to be installed to the local repository before other parts can be
>> developed
>> (using the eclipse:eclipse goal fails if the dependency / subproject is
>> not
>> installed). [...]
>
> That's correct. The reason is that maven-2.x is (by design) repository
> based; when maven needs a dependency, it looks for it in your local
> repos (regardless of whether it's another subproject within the project
> that is building, or something else). That's just how it's supposed to
> work.
>
> -Al
>
> --
> :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: ::
> ::
> Alan D. Salewski
> Software Developer
> Health Market Science, Inc.
> :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: ::
> ::
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
>
--
View this message in context: http://www.nabble.com/multi-project-interdependencies-tf2916882s177.html#a9314490
Sent from the Maven - Users mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: multi project interdependencies
Posted by "Alan D. Salewski" <as...@healthmarketscience.com>.
On Wed, Jan 03, 2007 at 07:18:17PM -0500, Trevor Torrez spake thus:
> Is it the suggested / best practice to have a subproject in a multi project
> setup to declare it's dependencies on the other subprojects in the
> dependency section?
Yes.
> This leads to requiring some parts of the multi-project
> to be installed to the local repository before other parts can be developed
> (using the eclipse:eclipse goal fails if the dependency / subproject is not
> installed). [...]
That's correct. The reason is that maven-2.x is (by design) repository
based; when maven needs a dependency, it looks for it in your local
repos (regardless of whether it's another subproject within the project
that is building, or something else). That's just how it's supposed to
work.
-Al
--
:: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: ::
::
Alan D. Salewski
Software Developer
Health Market Science, Inc.
:: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: :: ::
::
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: [m2] multi project interdependencies
Posted by franz see <fr...@gmail.com>.
Good day to you, M,
Yes, the current solution that I know of is to use mvn clean install. That
is why that continuum uses that as its default build ( to prevent any
adverse effect ).
I am not sure though if the maven developers can find an alternative to
that. On top of my head, I can only think of something like a force.compile
for the maven-compiler-plugin.
Cheers,
Franz
mark_in_gr wrote:
>
> Actually, it looks like what was happening is the error which was being
> caught by the compiler was a result of a private method name mismatch
> being called from the same class. There would really be no way for module
> a level above the module/dependency which has changed to know which
> classes in it's own module would be affected by the dependency change.
> Even Ant based projects which string targets together w/depends statements
> would result in the same behavior I am seeing w/Maven2.
>
> So, I would think a best practice here would be to perform a mvn clean
> install at the top level pom(where the modules are listed in my single
> level module list) every time a dependency module is rebuilt. Do you
> agree?
>
> franz see wrote:
>>
>> Good day to you, M,
>>
>> The steps I mentioned in my previous post still occurred. However, the
>> compiler plugin does not compile if there are no changes in the source
>> code.
>>
>> But in your example, it seems as though that it should have been
>> recompiled. You may want to file a jira issue for that ( see [1] ).
>>
>> Cheers,
>> Franz
>>
>> [1] http://jira.codehaus.org/browse/MCOMPILER
>>
>>
>> mark_in_gr wrote:
>>>
>>> I don't believe this is correct, at least I am not able to get this to
>>> work.
>>>
>>> For example, if I have the following structure:
>>>
>>> Project Parent
>>> ---- Module A
>>> ---- Module B
>>>
>>> where Module B depends on Module A. If I force an issue in some code in
>>> Module A which is used in Module B and should case a compile time error
>>> in a class in Module B, then build(mvn package or mvn install) at the
>>> Project Parent Level, the code in Module A compiles(I see the message "
>>> Compiling 1 source file to . . ."), however, no classes in Module B are
>>> compiled!!(I see "Nothing to compile - all classes are up to date").
>>>
>>> So, how is code in Module B going to be made aware of, say, a method
>>> being changed in a class in Module A??? if I run a mvn clean package or
>>> mvn clean install, everything works correctly seeing that all modules
>>> are completed rebuilt from scratch, but this goes against an incremental
>>> build process and is not an acceptable practice.
>>>
>>> My Project Parent level has a POM only, which Module A and Module B
>>> listed as Modules. In the Module B pom, Module A is listed as a
>>> dependency w/compile scope using the standard conventions(artifactId,
>>> groupId, etc.) and set up to use a snapshot.
>>>
>>>
>>> franz see wrote:
>>>>
>>>> Good day to you, M,
>>>>
>>>> Actually, it's
>>>>
>>>> subproject A - compile
>>>> subproject A - test
>>>> subproject A - jar
>>>> subproject A - install
>>>> subproject A - deploy
>>>> subproject B - compile <- in need of a subproject A jar (searching
>>>> in repostitory)
>>>> subproject B - test <- proceeds only if an OLDER version is found
>>>> subproject B - jar
>>>> subproject B - install
>>>> subproject B - deploy
>>>>
>>>> IRC, maven2 will first group your tasks to segments. And then those
>>>> task segments would be executed one at a time. When one task segment
>>>> finishes, the next will begin.
>>>>
>>>> All non-aggregating goals will be set as one task segment, then every
>>>> aggregating goal will have their own task segment. Aggregating goals
>>>> are those that run only on the project that you invoked it upon, while
>>>> non-aggregating goals are those that run on the project you invoked it
>>>> upon, plus, all modules under it.
>>>>
>>>> The project on which a non-aggregating goal will run on would then be
>>>> ordered according to dependency, making sure that the dependencies are
>>>> built before the dependees.
>>>>
>>>> The task segment for the non-aggregating goals would then be executed
>>>> to each of those projects and according to which build lifecycle phase
>>>> they are bound to.
>>>>
>>>> Thus, with a project project-a, with two modules, module-a and
>>>> module-b, where module-b depends on module-a, if you run mvn deploy on
>>>> project-a, the order of the projects would be
>>>>
>>>> project-a
>>>> module-a
>>>> module-b
>>>>
>>>> And on each project, the goals compiler:compile, surefire:test,
>>>> jar:jar, install:install, deploy:deploy (among others) would be
>>>> executed on each. Thus, it's like having
>>>>
>>>> cd project-a
>>>> mvn compiler:compiler
>>>> mvn surefire:test
>>>> mvn jar:jar
>>>> mvn install:install
>>>> mvn deploy:deploy
>>>> cd module-a
>>>> mvn compiler:compiler
>>>> mvn surefire:test
>>>> mvn jar:jar
>>>> mvn install:install
>>>> mvn deploy:deploy
>>>> cd ..\module-b
>>>> mvn compiler:compiler
>>>> mvn surefire:test
>>>> mvn jar:jar
>>>> mvn install:install
>>>> mvn deploy:deploy
>>>>
>>>> ( more or less ).
>>>>
>>>> Cheers,
>>>> Franz
>>>>
>>>>
>>>> meberts wrote:
>>>>>
>>>>> Hi,
>>>>>
>>>>> you're saying:
>>>>>
>>>>>
>>>>>> If a dependency of your maven project does not exist when you execute
>>>>>> a maven command, then that project will not bulid ( assuming ofcourse
>>>>>> the maven command requires a pom to execute ).
>>>>>>
>>>>> This would be an even bigger problem during install/deploy calls:
>>>>> What would then happen if changed some parts in subproject A and B and
>>>>> try to use parts of A in B? Since A will not be deployed/installed
>>>>> prior to the compilation of B, you might download the wrong version of
>>>>> A from the repository. This would lead to broken builds!?
>>>>> Currently it is like that:
>>>>> subproject A - compile
>>>>> subproject A - test
>>>>> subproject A - jar
>>>>> subproject B - compile <- in need of a subproject A jar (searching
>>>>> in repostitory)
>>>>> subproject B - test <- proceeds only if an OLDER version is found
>>>>> subproject B - jar
>>>>> subproject A - install
>>>>> subproject A - deploy
>>>>> subproject B - install
>>>>> subproject B - deploy
>>>>> Should a project not go through the whole build lifecycle first before
>>>>> switching to the next project???
>>>>>
>>>>> M
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>
--
View this message in context: http://www.nabble.com/multi-project-interdependencies-tf2916882s177.html#a9342521
Sent from the Maven - Users mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: [m2] multi project interdependencies
Posted by mark_in_gr <mc...@xrite.com>.
Actually, it looks like what was happening is the error which was being
caught by the compiler was a result of a private method name mismatch being
called from the same class. There would really be no way for module a level
above the module/dependency which has changed to know which classes in it's
own module would be affected by the dependency change. Even Ant based
projects which string targets together w/depends statements would result in
the same behavior I am seeing w/Maven2.
So, I would think a best practice here would be to perform a mvn clean
install at the top level pom(where the modules are listed in my single level
module list) every time a dependency module is rebuilt. Do you agree?
franz see wrote:
>
> Good day to you, M,
>
> The steps I mentioned in my previous post still occurred. However, the
> compiler plugin does not compile if there are no changes in the source
> code.
>
> But in your example, it seems as though that it should have been
> recompiled. You may want to file a jira issue for that ( see [1] ).
>
> Cheers,
> Franz
>
> [1] http://jira.codehaus.org/browse/MCOMPILER
>
>
> mark_in_gr wrote:
>>
>> I don't believe this is correct, at least I am not able to get this to
>> work.
>>
>> For example, if I have the following structure:
>>
>> Project Parent
>> ---- Module A
>> ---- Module B
>>
>> where Module B depends on Module A. If I force an issue in some code in
>> Module A which is used in Module B and should case a compile time error
>> in a class in Module B, then build(mvn package or mvn install) at the
>> Project Parent Level, the code in Module A compiles(I see the message "
>> Compiling 1 source file to . . ."), however, no classes in Module B are
>> compiled!!(I see "Nothing to compile - all classes are up to date").
>>
>> So, how is code in Module B going to be made aware of, say, a method
>> being changed in a class in Module A??? if I run a mvn clean package or
>> mvn clean install, everything works correctly seeing that all modules are
>> completed rebuilt from scratch, but this goes against an incremental
>> build process and is not an acceptable practice.
>>
>> My Project Parent level has a POM only, which Module A and Module B
>> listed as Modules. In the Module B pom, Module A is listed as a
>> dependency w/compile scope using the standard conventions(artifactId,
>> groupId, etc.) and set up to use a snapshot.
>>
>>
>> franz see wrote:
>>>
>>> Good day to you, M,
>>>
>>> Actually, it's
>>>
>>> subproject A - compile
>>> subproject A - test
>>> subproject A - jar
>>> subproject A - install
>>> subproject A - deploy
>>> subproject B - compile <- in need of a subproject A jar (searching
>>> in repostitory)
>>> subproject B - test <- proceeds only if an OLDER version is found
>>> subproject B - jar
>>> subproject B - install
>>> subproject B - deploy
>>>
>>> IRC, maven2 will first group your tasks to segments. And then those task
>>> segments would be executed one at a time. When one task segment
>>> finishes, the next will begin.
>>>
>>> All non-aggregating goals will be set as one task segment, then every
>>> aggregating goal will have their own task segment. Aggregating goals are
>>> those that run only on the project that you invoked it upon, while
>>> non-aggregating goals are those that run on the project you invoked it
>>> upon, plus, all modules under it.
>>>
>>> The project on which a non-aggregating goal will run on would then be
>>> ordered according to dependency, making sure that the dependencies are
>>> built before the dependees.
>>>
>>> The task segment for the non-aggregating goals would then be executed to
>>> each of those projects and according to which build lifecycle phase they
>>> are bound to.
>>>
>>> Thus, with a project project-a, with two modules, module-a and module-b,
>>> where module-b depends on module-a, if you run mvn deploy on project-a,
>>> the order of the projects would be
>>>
>>> project-a
>>> module-a
>>> module-b
>>>
>>> And on each project, the goals compiler:compile, surefire:test, jar:jar,
>>> install:install, deploy:deploy (among others) would be executed on each.
>>> Thus, it's like having
>>>
>>> cd project-a
>>> mvn compiler:compiler
>>> mvn surefire:test
>>> mvn jar:jar
>>> mvn install:install
>>> mvn deploy:deploy
>>> cd module-a
>>> mvn compiler:compiler
>>> mvn surefire:test
>>> mvn jar:jar
>>> mvn install:install
>>> mvn deploy:deploy
>>> cd ..\module-b
>>> mvn compiler:compiler
>>> mvn surefire:test
>>> mvn jar:jar
>>> mvn install:install
>>> mvn deploy:deploy
>>>
>>> ( more or less ).
>>>
>>> Cheers,
>>> Franz
>>>
>>>
>>> meberts wrote:
>>>>
>>>> Hi,
>>>>
>>>> you're saying:
>>>>
>>>>
>>>>> If a dependency of your maven project does not exist when you execute
>>>>> a maven command, then that project will not bulid ( assuming ofcourse
>>>>> the maven command requires a pom to execute ).
>>>>>
>>>> This would be an even bigger problem during install/deploy calls:
>>>> What would then happen if changed some parts in subproject A and B and
>>>> try to use parts of A in B? Since A will not be deployed/installed
>>>> prior to the compilation of B, you might download the wrong version of
>>>> A from the repository. This would lead to broken builds!?
>>>> Currently it is like that:
>>>> subproject A - compile
>>>> subproject A - test
>>>> subproject A - jar
>>>> subproject B - compile <- in need of a subproject A jar (searching
>>>> in repostitory)
>>>> subproject B - test <- proceeds only if an OLDER version is found
>>>> subproject B - jar
>>>> subproject A - install
>>>> subproject A - deploy
>>>> subproject B - install
>>>> subproject B - deploy
>>>> Should a project not go through the whole build lifecycle first before
>>>> switching to the next project???
>>>>
>>>> M
>>>>
>>>
>>>
>>
>>
>
>
--
View this message in context: http://www.nabble.com/multi-project-interdependencies-tf2916882s177.html#a9332007
Sent from the Maven - Users mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: [m2] multi project interdependencies
Posted by franz see <fr...@gmail.com>.
Good day to you, M,
The steps I mentioned in my previous post still occurred. However, the
compiler plugin does not compile if there are no changes in the source code.
But in your example, it seems as though that it should have been recompiled.
You may want to file a jira issue for that ( see [1] ).
Cheers,
Franz
[1] http://jira.codehaus.org/browse/MCOMPILER
mark_in_gr wrote:
>
> I don't believe this is correct, at least I am not able to get this to
> work.
>
> For example, if I have the following structure:
>
> Project Parent
> ---- Module A
> ---- Module B
>
> where Module B depends on Module A. If I force an issue in some code in
> Module A which is used in Module B and should case a compile time error in
> a class in Module B, then build(mvn package or mvn install) at the Project
> Parent Level, the code in Module A compiles(I see the message " Compiling
> 1 source file to . . ."), however, no classes in Module B are compiled!!(I
> see "Nothing to compile - all classes are up to date").
>
> So, how is code in Module B going to be made aware of, say, a method being
> changed in a class in Module A??? if I run a mvn clean package or mvn
> clean install, everything works correctly seeing that all modules are
> completed rebuilt from scratch, but this goes against an incremental build
> process and is not an acceptable practice.
>
> My Project Parent level has a POM only, which Module A and Module B listed
> as Modules. In the Module B pom, Module A is listed as a dependency
> w/compile scope using the standard conventions(artifactId, groupId, etc.)
> and set up to use a snapshot.
>
>
> franz see wrote:
>>
>> Good day to you, M,
>>
>> Actually, it's
>>
>> subproject A - compile
>> subproject A - test
>> subproject A - jar
>> subproject A - install
>> subproject A - deploy
>> subproject B - compile <- in need of a subproject A jar (searching in
>> repostitory)
>> subproject B - test <- proceeds only if an OLDER version is found
>> subproject B - jar
>> subproject B - install
>> subproject B - deploy
>>
>> IRC, maven2 will first group your tasks to segments. And then those task
>> segments would be executed one at a time. When one task segment finishes,
>> the next will begin.
>>
>> All non-aggregating goals will be set as one task segment, then every
>> aggregating goal will have their own task segment. Aggregating goals are
>> those that run only on the project that you invoked it upon, while
>> non-aggregating goals are those that run on the project you invoked it
>> upon, plus, all modules under it.
>>
>> The project on which a non-aggregating goal will run on would then be
>> ordered according to dependency, making sure that the dependencies are
>> built before the dependees.
>>
>> The task segment for the non-aggregating goals would then be executed to
>> each of those projects and according to which build lifecycle phase they
>> are bound to.
>>
>> Thus, with a project project-a, with two modules, module-a and module-b,
>> where module-b depends on module-a, if you run mvn deploy on project-a,
>> the order of the projects would be
>>
>> project-a
>> module-a
>> module-b
>>
>> And on each project, the goals compiler:compile, surefire:test, jar:jar,
>> install:install, deploy:deploy (among others) would be executed on each.
>> Thus, it's like having
>>
>> cd project-a
>> mvn compiler:compiler
>> mvn surefire:test
>> mvn jar:jar
>> mvn install:install
>> mvn deploy:deploy
>> cd module-a
>> mvn compiler:compiler
>> mvn surefire:test
>> mvn jar:jar
>> mvn install:install
>> mvn deploy:deploy
>> cd ..\module-b
>> mvn compiler:compiler
>> mvn surefire:test
>> mvn jar:jar
>> mvn install:install
>> mvn deploy:deploy
>>
>> ( more or less ).
>>
>> Cheers,
>> Franz
>>
>>
>> meberts wrote:
>>>
>>> Hi,
>>>
>>> you're saying:
>>>
>>>
>>>> If a dependency of your maven project does not exist when you execute a
>>>> maven command, then that project will not bulid ( assuming ofcourse the
>>>> maven command requires a pom to execute ).
>>>>
>>> This would be an even bigger problem during install/deploy calls:
>>> What would then happen if changed some parts in subproject A and B and
>>> try to use parts of A in B? Since A will not be deployed/installed prior
>>> to the compilation of B, you might download the wrong version of A from
>>> the repository. This would lead to broken builds!?
>>> Currently it is like that:
>>> subproject A - compile
>>> subproject A - test
>>> subproject A - jar
>>> subproject B - compile <- in need of a subproject A jar (searching
>>> in repostitory)
>>> subproject B - test <- proceeds only if an OLDER version is found
>>> subproject B - jar
>>> subproject A - install
>>> subproject A - deploy
>>> subproject B - install
>>> subproject B - deploy
>>> Should a project not go through the whole build lifecycle first before
>>> switching to the next project???
>>>
>>> M
>>>
>>
>>
>
>
--
View this message in context: http://www.nabble.com/multi-project-interdependencies-tf2916882s177.html#a9324419
Sent from the Maven - Users mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: [m2] multi project interdependencies
Posted by mark_in_gr <mc...@xrite.com>.
I don't believe this is correct, at least I am not able to get this to work.
For example, if I have the following structure:
Project Parent
---- Module A
---- Module B
where Module B depends on Module A. If I force an issue in some code in
Module A which is used in Module B and should case a compile time error in a
class in Module B, then build(mvn package or mvn install) at the Project
Parent Level, the code in Module A compiles(I see the message " Compiling 1
source file to . . ."), however, no classes in Module B are compiled!!(I see
"Nothing to compile - all classes are up to date").
So, how is code in Module B going to be made aware of, say, a method being
changed in a class in Module A??? if I run a mvn clean package or mvn clean
install, everything works correctly seeing that all modules are completed
rebuilt from scratch, but this goes against an incremental build process and
is not an acceptable practice.
My Project Parent level has a POM only, which Module A and Module B listed
as Modules. In the Module B pom, Module A is listed as a dependency
w/compile scope using the standard conventions(artifactId, groupId, etc.)
and set up to use a snapshot.
franz see wrote:
>
> Good day to you, M,
>
> Actually, it's
>
> subproject A - compile
> subproject A - test
> subproject A - jar
> subproject A - install
> subproject A - deploy
> subproject B - compile <- in need of a subproject A jar (searching in
> repostitory)
> subproject B - test <- proceeds only if an OLDER version is found
> subproject B - jar
> subproject B - install
> subproject B - deploy
>
> IRC, maven2 will first group your tasks to segments. And then those task
> segments would be executed one at a time. When one task segment finishes,
> the next will begin.
>
> All non-aggregating goals will be set as one task segment, then every
> aggregating goal will have their own task segment. Aggregating goals are
> those that run only on the project that you invoked it upon, while
> non-aggregating goals are those that run on the project you invoked it
> upon, plus, all modules under it.
>
> The project on which a non-aggregating goal will run on would then be
> ordered according to dependency, making sure that the dependencies are
> built before the dependees.
>
> The task segment for the non-aggregating goals would then be executed to
> each of those projects and according to which build lifecycle phase they
> are bound to.
>
> Thus, with a project project-a, with two modules, module-a and module-b,
> where module-b depends on module-a, if you run mvn deploy on project-a,
> the order of the projects would be
>
> project-a
> module-a
> module-b
>
> And on each project, the goals compiler:compile, surefire:test, jar:jar,
> install:install, deploy:deploy (among others) would be executed on each.
> Thus, it's like having
>
> cd project-a
> mvn compiler:compiler
> mvn surefire:test
> mvn jar:jar
> mvn install:install
> mvn deploy:deploy
> cd module-a
> mvn compiler:compiler
> mvn surefire:test
> mvn jar:jar
> mvn install:install
> mvn deploy:deploy
> cd ..\module-b
> mvn compiler:compiler
> mvn surefire:test
> mvn jar:jar
> mvn install:install
> mvn deploy:deploy
>
> ( more or less ).
>
> Cheers,
> Franz
>
>
> meberts wrote:
>>
>> Hi,
>>
>> you're saying:
>>
>>
>>> If a dependency of your maven project does not exist when you execute a
>>> maven command, then that project will not bulid ( assuming ofcourse the
>>> maven command requires a pom to execute ).
>>>
>> This would be an even bigger problem during install/deploy calls:
>> What would then happen if changed some parts in subproject A and B and
>> try to use parts of A in B? Since A will not be deployed/installed prior
>> to the compilation of B, you might download the wrong version of A from
>> the repository. This would lead to broken builds!?
>> Currently it is like that:
>> subproject A - compile
>> subproject A - test
>> subproject A - jar
>> subproject B - compile <- in need of a subproject A jar (searching in
>> repostitory)
>> subproject B - test <- proceeds only if an OLDER version is found
>> subproject B - jar
>> subproject A - install
>> subproject A - deploy
>> subproject B - install
>> subproject B - deploy
>> Should a project not go through the whole build lifecycle first before
>> switching to the next project???
>>
>> M
>>
>
>
--
View this message in context: http://www.nabble.com/multi-project-interdependencies-tf2916882s177.html#a9316733
Sent from the Maven - Users mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: multi project interdependencies
Posted by franz see <fr...@gmail.com>.
Good day to you, M,
Actually, it's
subproject A - compile
subproject A - test
subproject A - jar
subproject A - install
subproject A - deploy
subproject B - compile <- in need of a subproject A jar (searching in
repostitory)
subproject B - test <- proceeds only if an OLDER version is found
subproject B - jar
subproject B - install
subproject B - deploy
IRC, maven2 will first group your tasks to segments. And then those task
segments would be executed one at a time. When one task segment finishes,
the next will begin.
All non-aggregating goals will be set as one task segment, then every
aggregating goal will have their own task segment. Aggregating goals are
those that run only on the project that you invoked it upon, while
non-aggregating goals are those that run on the project you invoked it upon,
plus, all modules under it.
The project on which a non-aggregating goal will run on would then be
ordered according to dependency, making sure that the dependencies are built
before the dependees.
The task segment for the non-aggregating goals would then be executed to
each of those projects and according to which build lifecycle phase they are
bound to.
Thus, with a project project-a, with two modules, module-a and module-b,
where module-b depends on module-a, if you run mvn deploy on project-a, the
order of the projects would be
project-a
module-a
module-b
And on each project, the goals compiler:compile, surefire:test, jar:jar,
install:install, deploy:deploy (among others) would be executed on each.
Thus, it's like having
cd project-a
mvn compiler:compiler
mvn surefire:test
mvn jar:jar
mvn install:install
mvn deploy:deploy
cd module-a
mvn compiler:compiler
mvn surefire:test
mvn jar:jar
mvn install:install
mvn deploy:deploy
cd ..\module-b
mvn compiler:compiler
mvn surefire:test
mvn jar:jar
mvn install:install
mvn deploy:deploy
( more or less ).
Cheers,
Franz
meberts wrote:
>
> Hi,
>
> you're saying:
>
>
>> If a dependency of your maven project does not exist when you execute a
>> maven command, then that project will not bulid ( assuming ofcourse the
>> maven command requires a pom to execute ).
>>
> This would be an even bigger problem during install/deploy calls:
> What would then happen if changed some parts in subproject A and B and try
> to use parts of A in B? Since A will not be deployed/installed prior to
> the compilation of B, you might download the wrong version of A from the
> repository. This would lead to broken builds!?
> Currently it is like that:
> subproject A - compile
> subproject A - test
> subproject A - jar
> subproject B - compile <- in need of a subproject A jar (searching in
> repostitory)
> subproject B - test <- proceeds only if an OLDER version is found
> subproject B - jar
> subproject A - install
> subproject A - deploy
> subproject B - install
> subproject B - deploy
> Should a project not go through the whole build lifecycle first before
> switching to the next project???
>
> M
>
--
View this message in context: http://www.nabble.com/multi-project-interdependencies-tf2916882s177.html#a8278008
Sent from the Maven - Users mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: multi project interdependencies
Posted by meberts <ma...@promatis.de>.
Hi,
you're saying:
> If a dependency of your maven project does not exist when you execute a
> maven command, then that project will not bulid ( assuming ofcourse the
> maven command requires a pom to execute ).
>
This would be an even bigger problem during install/deploy calls:
What would then happen if changed some parts in subproject A and B and try
to use parts of A in B? Since A will not be deployed/installed prior to the
compilation of B, you might download the wrong version of A from the
repository. This would lead to broken builds!?
Currently it is like that:
subproject A - compile
subproject A - test
subproject A - jar
subproject B - compile <- in need of a subproject A jar (searching in
repostitory)
subproject B - test <- proceeds only if an OLDER version is found
subproject B - jar
subproject A - install
subproject A - deploy
subproject B - install
subproject B - deploy
Should a project not go through the whole build lifecycle first before
switching to the next project???
M
--
View this message in context: http://www.nabble.com/multi-project-interdependencies-tf2916882s177.html#a8277154
Sent from the Maven - Users mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: multi project interdependencies
Posted by franz see <fr...@gmail.com>.
Good day to you, Trevor,
Let me get this straight, you have a subproject that depends on the other
subprojects? If so, then you don't have to worry about which projects would
be installed first in your local repository. When you execute a maven
command on a project with modules (subprojects), it will automatically
traverse through the subprojects ( and their subprojects, etc ) and arrange
them in order of dependencies. This is to make sure that if A depends on B,
B will be built first.
If a dependency of your maven project does not exist when you execute a
maven command, then that project will not bulid ( assuming ofcourse the
maven command requires a pom to execute ).
So if you want, you create first your dependencies, then their dependees.
Cheers,
Franz
Trevor Torrez wrote:
>
> Is it the suggested / best practice to have a subproject in a multi
> project
> setup to declare it's dependencies on the other subprojects in the
> dependency section? This leads to requiring some parts of the
> multi-project
> to be installed to the local repository before other parts can be
> developed
> (using the eclipse:eclipse goal fails if the dependency / subproject is
> not
> installed). Or is there a better way?
>
>
--
View this message in context: http://www.nabble.com/multi-project-interdependencies-tf2916882s177.html#a8154936
Sent from the Maven - Users mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org