You're right. What I meant was that it will help mitigating your problem :)
Cheers! On Mon, Jul 11, 2011 at 6:59 PM, David Gileadi <[email protected]> wrote: > On 7/11/11 9:22 AM, Szczepan Faber wrote: >> That will aslo solve David's initial problem. > > Unfortunately I don't believe it will. The problem is that Eclipse resolves > things in a different way than Gradle. For example if you have project A > with a dependency on servlet-api:2.3 and project B with a dependency on > project A and on servlet-api:2.5, then from what I understand Gradle will > use servlet-api:2.5 regardless of dependency order. However Eclipse will > use the first jar that it comes across. If project A is in project B's > dependency list before servlet-api:2.5 then Eclipse will look in all of > project A's exported dependencies, find the jar for servlet-api:2.3 and use > it. > > My reasoning for suggesting that the Eclipse plugin put project dependencies > after jar dependencies was to help mitigate this, under the assumption that > dependencies that the project itself declares are more likely to be correct > than those brought in by depended-on projects. But I certainly agree that > it's not optimal. I just can't yet imagine what an optimal solution would > be. > >> Thanks Adam for your insights! >> >>> 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. >> >> That will aslo solve David's initial problem. The classpath order that >> Gradle uses, for example, to run tests uses library dependencies >> before project dependencies. There's a ticket for making eclipse >> classpath order consistent with Gradle: >> http://issues.gradle.org/browse/GRADLE-1614 >> >> IMHO fixing GRADLE-1614 must be coupled with providing a way to >> reorder the eclipse classpath entries because of compatibility >> reasons. I may throw it to my background tasks and hopefully solve at >> some point. >> >> Cheers! >> Szczepan >> >> On Tue, Jun 28, 2011 at 1:44 AM, Adam Murdoch >> <[email protected]> wrote: >>> >>> 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 >>> >>> >> >> >> > > > > --------------------------------------------------------------------- > 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
