Fast development with Gradle in Eclipse. Is it possible?

I’m not aware of any plans at Gradle to mimic Eclipse’s way of building projects.
The one thing that will come in the future is composite builds, i.e. building across disjunct projects.

Just to emphasize a last thing: I didn’t suggest anywhere that the point of this topic started by me was to find a way for Gradle to mimic Eclipse’s way of building projects. I wouldn’t be so naive. If so, what about IntelliJ, Netbeans, etc? This meaning can’t be assigned to my topic.

What I suggested was a way that, to save development time, independent of any IDE, while someone is working in development stage (maybe that only in Java SE applications, I don’t know), was not necessary to Gradle generate the jar file(s). The developer could be working in this mode, let’s call it this way, until he thinks it is the time to package and deploy its artifacts. That would save a lot of time in development (as we have today using IDEs in Java SE applications).

Thank you for listing.

Hi Marcos,
i had a similar challenge migrating legacy projects to be built by gradle, without having too much impact on the development workflow.
What finally worked for me, was using this kind of hack to adjust the generated eclipse classpath to have a reference to the class folder of the library project, compiled by the eclipse compiler.
This way, launching the project A from eclipse would pick up the latest changes done in sources of library B without any gradling.
From what i can tell, this binary reference is the only thing you are missing to achieve what you want.
Since my main project was a web project, this is how the generated CP entry had to look like:

<classpathentry kind="lib" path="/library-b/bin" exported="null" sourcepath="/library-b">
	<attributes>
		<attribute name="org.eclipse.jst.component.dependency" value="/WEB-INF/classes"/>
	</attributes>
</classpathentry>

Whether or not you are willing to go this hacky road is up to you ;-]

Thank you. I’ll test this next week and report if it solves the problem.

I also have utility projects and clients of them, that are built and published separately.
But where I want to do fast and seamless development on them at the same time in eclipse.

My solution has been a flag in the client project build file.
When set, the normal dependency to the utility project is disabled, and the eclipse-plugin is used to add an eclipse project reference to the utility project.

Works a charm.

i can post an example, when I’m at work on Monday if you like.

Yes, I really would like to see your solution.

It would be nice if there was a stardard way in Gradle to configure it to be .class oriented when we want instead of only .jar oriented. Then this discussion would be needless.

Who generates it? Eclipse itself or gradle build runned by you in command line? I think eclipse alone cannot do this. If you create build files from your post and run gradle eclipse it will generate .classpath file (maybe some other files needed for raw eclipse build without gradle). Then you can use your eclipse installation as usual without gradle. And no jar files will be generated until you run gradle build or something similar. So you achieve really what you want - fast development in eclise without gradle. But with possibility of building your projects from command line and deploy when you want.

Maybe I am wrong? I really doesn’t understand what problem you experience. Maybe I not understand your workflow process?

The script below uses an external prebuilt dependency (dk.jyskebank.tooling.infra:infra-base) when useWorkspaceBase is false.

When true, it rewrites Eclipse’s .classpath file to reference the project (jb.jbit.im.tools.base.java) directly in the workspace (not its .classpath folder - the project).

I hope it makes sense.

Cheers,
Jesper

apply plugin: "eclipse"

ext {
  useWorkspaceBase = false
}

dependencies {
  if (!useWorkspaceBase) {
    compile "dk.jyskebank.tooling.infra:infra-base:1.0.0"
  }
}

eclipse {
  classpath {
    if (useWorkspaceBase) {
      file {
        withXml {
          def node = it.asNode()
          node.appendNode('classpathentry', [kind: 'src', path: '/jb.jbit.im.tools.base.java', exported: true])
        }
      }
    }
  }
}

I decided to abandon Gradle for Java SE development. I will only use it in Java EE development where artifacts like .jar, .war and .ear really need to be generated for the server in order to run the application.

Gradle is a nice tool, no doubt about that, but it is certainly not tailored for the use case of this topic. Eclipse does a better job alone.

Thanks to Jasper and conf for the help. The hacks didn’t work for me and unfortunately I don’t have the time to delay my work anymore to try to find out why.

Again, only my suggestion: I think that Gradle should consider an easier way to achieve this in the future. I’m not the only one that wants this feature.

This is going to be fixed by the composite build feature we plan to release with Buildship 1.1

This is really what I call very good news. I’ll certainly give it a try. With this feature Gradle is becoming even more complete and sophisticated. Thank you for implementing this.