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