The best way I know of to solve a circular dependency is to float the dependency up one level in the build hierarchy.
Just from what I can see here, you're wanting to depend on a configuration file that lives inside a module in the other modules. If that's not the goal, then ignore the rest of this message. I can't get to github to look at what you're actually doing, but you could extract the config you're wanting to include into a third module or external project, put the config into src/main/resources (or src/test/resources, if that's what you need) and either release it independently (if it's not a module) or have everything else depend on it, maybe as <scope>provided</scope>. It would then be an available resource in the classpath. On Sat, Feb 12, 2011 at 13:33, Stephen Connolly < [email protected]> wrote: > the issue is that you should be depending on the previous released version > of the dependency... > > what plugin needs this as a dependency > ... might be a question of getting a change in that plugin to get your > build > to work right > > - Stephen > > --- > Sent from my Android phone, so random spelling mistakes, random nonsense > words and other nonsense are a direct result of using swype to type on the > screen > On 12 Feb 2011 18:40, "Thiago Moreira (timba)" <[email protected]> > wrote: > > Humm, ok! Is there anything that I can do to change this? Advices in how > > organize the projects? > > How about add a flag to the release-plugin indicating to reactor that it > > can resolve the plugin dependencies if such dependency is generate during > > the build? > > > > On Sat, Feb 12, 2011 at 3:26 PM, Stephen Connolly < > > [email protected]> wrote: > > > >> that is a circular reference... the big is that you are allowed to make > >> such > >> a cycle. > >> > >> the reason why this is not allowed is that maven constructs the build > plan > >> up front, and when a plugin depends on a module from the reactor, then > the > >> build plan could (in theory) be affected based on the result of > building... > >> > >> - Stephen > >> > >> --- > >> Sent from my Android phone, so random spelling mistakes, random nonsense > >> words and other nonsense are a direct result of using swype to type on > the > >> screen > >> On 12 Feb 2011 17:02, "Thiago Moreira (timba)" <[email protected]> > >> wrote: > >> > Hi there, > >> > > >> > I have a multi module project (https://github.com/floggy/parent) that > >> has > >> > two submodules. In the parent project I make reference to one > submodule > >> like > >> > this: > >> > > >> > <plugins> > >> > <plugin> > >> > <groupId>org.apache.maven.plugins</groupId> > >> > <artifactId>maven-checkstyle-plugin</artifactId> > >> > <inherited>true</inherited> > >> > <dependencies> > >> > * <dependency>* > >> > * <groupId>org.floggy</groupId>* > >> > * <artifactId>build-tools</artifactId>* > >> > * <version>0.0.2-SNAPSHOT</version>* > >> > * </dependency>* > >> > </dependencies> > >> > <configuration> > >> > <configLocation>checkstyle-checks-configuration.xml</configLocation> > >> > </configuration> > >> > </plugin> > >> > </plugins> > >> > > >> > When I release the whole project the release plugin does not resolve > the > >> > SNAPSHOT version of my dependency when it is declared as a dependency > of > >> a > >> > plugin. Is there a way to force Maven to do that? Seems that there is > the > >> > same problem with the dependecyManagement section: > >> > http://jira.codehaus.org/browse/MRELEASE-649 > >> > Ideas? Is this a bug? > >> > > >> > Thanks in advance > >> >
