On 28/06/2011, at 2:01 AM, David Gileadi wrote: > The ultimate, of course, would be to get Eclipse to use exactly the same > dependencies as Gradle does when it builds. While this may not be possible > I've considered an option for making the Eclipse plugin make everything be > non-exported from projects and instead gathering all the transitive > dependencies from depended-upon projects, applying conflict resolution to > them and put them all directly in the dependant project. I don't know whether > this would work, but I'm considering trying it out.
This approach will give you a more accurate result, but at the cost of polluting each project with its transitive dependencies, which is probably not worth the improvement in accuracy. Another option is to have the eclipse plugin generate a synthetic project which contains the transitive dependencies of a project once exclusions and conflict management have been applied. > > In any case I'm glad you like the idea of putting project entries after > library entries; I'll probably submit a pull request for it at some point. I'm not convinced it's a good solution. It's certainly not a general solution, so I suspect we're just introducing other issues by doing this. Instead, I think I'd prefer a solution where classpath entries are generated in the same order they are used by Gradle when it builds stuff, along with some easy way for you to reorder entries. This we could combine with dependency management changes to get rid of the need for you to use exclusions. > > On 6/27/11 8:35 AM, Szczepan Faber wrote: >>> Changing the Eclipse plugin to put library classpath entries before project >>> classpath entries would make it so that Eclipse looks in declared library >> >> It makes sense to me. It also somewhat shows that it would be nice if >> eclipse plugin had better support for configuring the resulting order >> of dependencies. >> >> Cheers! >> >> On Thu, Jun 23, 2011 at 12:38 AM, David Gileadi<[email protected]> wrote: >>> This message is to ask if there's any reason why we shouldn't change the >>> Eclipse plugin to put project classpath entries after library classpath >>> entries. Here's some background: >>> >>> I'm trying to use the Eclipse plugin for a rather complex multi-project >>> build. I've found that Eclipse resolves things in the order they appear in >>> the .classpath file, and that the Eclipse plugin puts projects first in that >>> file. So for instance if Project A depends on some-library-1.0.jar (notice >>> the 1.0) and Project B depends on both Project A and some-library-2.0.jar >>> (notice the 2.0) then the Java files in Project B will be compiling against >>> some-library-1.0.jar (the 1.0 version). >>> >>> This is really because Eclipse doesn't support exclusions in project >>> dependencies the way Maven and Gradle do. That is, in Gradle for Project B >>> you can specify: >>> >>> dependencies { >>> compile project(':projectA') { exclude module: 'some-library' } >>> } >>> >>> However I believe that in Eclipse there's no equivalent construct--importing >>> a project imports all its exported classpath entries too. >>> >>> Changing the Eclipse plugin to put library classpath entries before project >>> classpath entries would make it so that Eclipse looks in declared library >>> dependencies before it looks in library dependencies of imported projects, >>> which I think helps mitigate the lack of excludes for project imports. I've >>> made the change locally and it seems to work. What do you think--is there a >>> reason that making this change is a bad idea? > > > --------------------------------------------------------------------- > To unsubscribe from this list, please visit: > > http://xircles.codehaus.org/manage_email > > -- Adam Murdoch Gradle Co-founder http://www.gradle.org VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting http://www.gradleware.com
