Philip, I agree completely. Fixing GRADLE-1014 is ideal. I was under the impression the question was specifically about working in eclipse.
In theory GRADLE-1014 could be somehow implemented provided you sprinkle your builds with some conditional logic. Don't worry, we definitely want to fix 1014 :) Cheers! On Fri, Sep 30, 2011 at 5:36 PM, Philip Crotwell <[email protected]>wrote: > 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 > > > -- Szczepan Faber Principal engineer@gradleware Lead@mockito
