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