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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
