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
