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