I think it's probably a "you" issue. You refer to the top-level POM as the "parent", and it may well be so, but as such it has nothing to do with the structure of the project or the relationship between the children (aside from dependencyManagement). As far as the multi-module nature is concerned, the more significant role of that POM is as an *aggregator*. As such, it is merely a convenient container for the following *independent* components (I added the SNAPSHOT part, assuming it is correct):
a 1.2-SNAPSHOT b 1.3-SNAPSHOT -> a 1.1 c 1.1-SNAPSHOT -> b 1.2 I call them independent because they are completely discrete sets of versions. I think you should pay close attention to what is happening when you start your code for debugging ... I would suspect you are starting an object method that lives in the 'c' project, which probably means that it is using the older jars at runtime; the development code you are writing for the 'b' and 'a' SNAPSHOT versions is probably not getting used at all. The fact that later versions of 'a' and 'b' exist is irrelevant to the project ('c') that you are working with. 'c' depends on 'b 1.2', and that is the version of code that your IDE finds for you. As for the release step, you seem to want to be developing based on the latest version of the dependencies, but still allow yourself the option of releasing updates that are dependent on the older versions. How did you plan to manage this? Think about how the code will be used after deployment, not just how you are using it during development. Zac On Wed, Jul 29, 2009 at 10:29 PM, Mark Derricutt<m...@talios.com> wrote: ... > We have a multi-module project, and when single stepping through code, > or clicking through stack traces IDEA insists on sending the editor to > .java files inside -sources.jars rather than the versions currently in > the project. From what I can tell, the problem lines in that our poms > currently look like: > > - parent > - module a v 1.2 > - module b v 1.3 > - depends on a v 1.1 > - module c v 1.1 > - depends on b v 1.2 ... > Initially I changed our parent pom to include a <dependencyManagement> > section, pinning all the versions of each module which worked for > debugging/strack-trace clicking, as the project only knows about b:1.3 > - however, this means we can no longer do a maven release of b, if the > parent pom currently refers to a SNAPSHOT of a or c, and we end up > putting <version> elements back in our module poms. ... --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org