HI This addresses the issue of eclipse using the dependency project source instead of the downloaded dependency jar, but if you used gradle itself to compile, wouldn't it still use the dependency jar and not do a recompile of the other project? Seems confusing to get different results if you compile in eclipse versus compiling in gradle.
As in GRADLE-1014, it would be really nice if there was a way to declare a dependency that would do the right thing, ie us a multiproject style "go compile that project first" if the project exists locally, but download that jar if you can't gradle can't find the other project. thanks Philip On Fri, Sep 30, 2011 at 10:42 AM, Szczepan Faber <[email protected]> wrote: > Hey, > It should be doable with the current eclipse configuration DSL, though it > may not be pretty :) > Don't worry about the DSL changes - just follow the documentation > corresponding to the version of gradle you use and you'll be good. When > upgrading to newer gradle deprecation warnings should lead you. > Here's what you can try (it's latest gradle, for milestone-3 it's going to > look slightly different): > eclipse.classpath.file.beforeMerged { Classpath c -> > //remove the jar dependencies from the classpath entries: > def toBeRemoved = c.entries.findAll { it instanceof Library && ((Library) > it).library.path.contains('somProjectFoo') } > //configure the project dependencies: > def toBeAdded = [ new ProjectDependency('/someProjectFoo', null)] > > c.entries -= toBeRemoved > c.entries += toBeAdded > } > I haven't tested above so it's just coding from memory / looking at the code > :) The docs for that are here (again, it's latest gradle snapshot): > http://gradle.org/releases/latest/docs/dsl/org.gradle.plugins.ide.eclipse.model.EclipseClasspath.html > and: > http://gradle.org/releases/latest/docs/groovydoc/org/gradle/plugins/ide/eclipse/model/package-summary.html > Hope that helps! > Let me know how did it go. > Cheers! > On Fri, Sep 30, 2011 at 3:22 PM, Philip Crotwell <[email protected]> > wrote: >> >> THis issue is more or less the same as what you want I think: >> http://issues.gradle.org/browse/GRADLE-1014 >> >> PHilip >> >> On Fri, Sep 30, 2011 at 6:21 AM, matthias <[email protected]> wrote: >> > Hey everyone, >> > >> > in our project, we have a few upstream dependencies that we develop >> > ourselves (in Eclipse), and I was wondering if there is a way to turn an >> > ordinary Gradle dependency into an Eclipse workspace project dependency >> > when >> > generating the Eclipse classpath? >> > >> > i.e. let's say we have a dependency to "artifact" in our app (both app >> > and >> > artifact are developed in Eclipse): >> > >> > dependencies { >> > compile "org.company:artifact:1.0-SNAPSHOT" >> > } >> > >> > we want the build server to pull that JAR file from the snapshot >> > repository. >> > However, when developing, we want to see changes to artifact in our app >> > immediately, by having Eclipse compile the dependency in straight away. >> > Right now what we have to do is create a new snapshot build, and run >> > some >> > Gradle task for the app just to have Gradle re-download the new snapshot >> > JAR, just to make it visible to the app project in Eclipse (by itself it >> > won't detect the change). That's a bit annoying. >> > >> > Instead, what we want is have "gradle eclipseClasspath" turn the >> > dependency >> > to artifact into a workspace project dependency, rather than a >> > dependency to >> > a JAR in Gradle's artifact cache. It should still reference all >> > transitive >> > dependencies as JARs, however. >> > >> > Is that something that can be achieved with the Eclipse DSL, or would we >> > have to code that ourselves? >> > >> > Thanks >> > Matthias >> > >> > PS: I'm getting confused over which version of the Eclipse DSL is the >> > current one. For instance, in order to configure the classpath in >> > build.gradle, would I use eclipse { classpath { ... } } or >> > eclipseClasspath? >> > I understand there have been changes to how the Eclipse DSL works in >> > Gradle >> > 1.0, but I lost track. >> > >> > -- >> > View this message in context: >> > http://gradle.1045684.n5.nabble.com/Gradle-s-Eclipse-DSL-and-resolving-dependencies-to-workspace-projects-tp4856525p4856525.html >> > Sent from the gradle-user mailing list archive at Nabble.com. >> > >> > --------------------------------------------------------------------- >> > To unsubscribe from this list, please visit: >> > >> > http://xircles.codehaus.org/manage_email >> > >> > >> > >> >> --------------------------------------------------------------------- >> 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
