> 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.
Ok, cool. The only issue is backwards compatibility. Let's say we change the default order. What might happen is that for some people after "gradle eclipse" their projects may suffer unexpected runtime errors after upgrading gradle. Also, I'm wondering if eclipse plugin maintains the order of classpath entries when merging gradle info with existing .classpath file. On Mon, Jun 27, 2011 at 6:01 PM, David Gileadi <[email protected]> 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. > > 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. > > 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 > > > -- Szczepan Faber Principal engineer@gradleware Lead@mockito --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
