Herve, I'm looking at trying to add this functionality to maven-dependency-tree but I want to start with a unit test showing the failure. But there doesn't seem to be any unit tests for the DependencyGraphBuilder (for any environment).
What's the best way to create a unit test that sets up the environment so that I can explicitly test the Maven3DependencyGraphBuilder and Maven31DependencyGraphBuilder? William On Thu, Mar 20, 2014 at 5:36 PM, Hervé BOUTEMY <herve.bout...@free.fr>wrote: > I don't really know: that's a precise feature that I didn't sudy > dependency-tree is used in Maven plugins in contexts where components are > already installed: so there is not much difference between reactor > resolution > and local repository resolution > > you're probably right: if reactor resolution is not done, it should be > added, > since that can be something generally expected from the component > > Regards, > > Hervé > > Le jeudi 20 mars 2014 17:30:38 William Ferguson a écrit : > > Herve, > > > > I didn't think I was asking for any extra flexibility out of > > dependency-tree that it didn't already give. Are you saying that it > doesn't > > support resolution of projects in the current reactor? > > > > William > > > > On Thu, Mar 20, 2014 at 5:16 PM, Hervé BOUTEMY <herve.bout...@free.fr > >wrote: > > > maven-dependency-tree offers a really simple API: that's its objective. > > > The drawback is that it is not very flexible > > > The value is that it hides Maven 2, Maven 3.0.x and Maven 3.1.x+ > > > implementations, which are completely different (initial Maven 2 is > made > > > of > > > listeners, Maven 3 uses Aether and Maven provider, with package changes > > > from > > > Maven 3.0 and 3.1) > > > > > > If you need more features, I think you'd better use Aether with Maven > > > Provider: you can look both at maven-dependency-tree source to start > and > > > Aether examples to better understand Aether API, which is a lot more > > > flexible<- > > > > > > >rich<->complex > > > > > > Notice that your initial code will use latest Aether, then your plugin > > > will > > > require Maven 3.1.x minimum. If you want compatibility with Maven 3.0.x > > > and > > > 3.1.x+, you'll have to add some reflection magic which might add > > > complexity (it > > > was not so easy to do it in maven-dependency-tree) > > > If you want Maven 2 compatibility, I would personnally not really > think it > > > is > > > reasonably feasible > > > > > > Regards, > > > > > > Hervé > > > > > > Le jeudi 20 mars 2014 09:55:31 William Ferguson a écrit : > > > > Hi, > > > > > > > > I have a plugin that uses the maven-dependency-tree component to > resolve > > > > project dependencies in a LifeCycleParticipant. (We need early > access to > > > > deps because we need to modify the compile classpath). > > > > > > > > But I'm finding that with a clean repository, in a multi-module > project > > > > with modules X and Y-depends-on-X that the DependencyGraphBuilder is > > > > throwing a DependencyGraphBuilderException when trying to resolve > > > > Y-depends-on-X. It says that it cannot find X. > > > > > > > > So it appears that the maven-dependency-tree is only using > information > > > > > > from > > > > > > > the repository and not the reactor. > > > > > > > > Is that expected? > > > > Is there anyway that I can get MDT to resolve from the reactor? > > > > Is there another approach that I should be taking to ensure that > > > > > > resolution > > > > > > > looks in the reactor? > > > > > > > > NB I need to support both maven 3.0 and 3.1 which is why we are using > > > > MDT > > > > to provide a level of abstraction above the 2 differing Aether > > > > implementations. > > > > > > > > William > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > > > For additional commands, e-mail: users-h...@maven.apache.org > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > >