Eclipse Plugin improvement suggestions

Old Forum Archive
1

I’ve been using eclipse in conjunction with gradle and gradle’s eclipse and eclipse-wtp plugins, and I’ve been happy with it for the most part, but there are some areas that I think could use some improvements.

  1. cleanEclipse should also remove files compiled with eclipse. This is similar to how “gradle clean” works with removing the “build” dir. If not this, then a separate task at least to remove these files would be beneficial. I’ve created a task called cleanEclipseBin that does this.

  2. cleanEclipse should remove the .settings dir. Right now it seems to rely on gradle’s task auto-cleaning functionality but often leaves a lot of files that the eclipse IDE may have generated itself. If not this, then a separate task at least to remove these files would be beneficial. I’ve created a task called cleanEclipseSettings that does this.

  3. Add (and probably make default) a way to separate src/main and src/test sourceSets. By default, these sources are compiled into the same directory which can mess up testing and especially deployment. In my projects, I’ve applied a fix that modifies eclipse.classpath, looking for entries starting with “src/test/” and setting their output to “bin/test”, and it changes the defaultOutputDir to “bin/main”. This works but its behavior is a bit quirky, requiring me to clear the classpath entries before doing this step.

  4. (eclipse-wtp) Please increase the default version of eclipse.wtp.facet ‘jst.web’ and perhaps add an easier way to change this. Default version 2.4 is quite old, and while the code to change this isn’t too bad, it currently needs to be done to each of my projects and is less concise than a JstWebFacetVersion property or something.

  5. (eclipse-wtp) Make sure the eclipse.classpath entry ‘org.eclipse.jst.j2ee.internal.web.container’ is listed last. In eclipse, this is reflected as Web App Libraries being the last libraries entry. Eclipse doesn’t properly resolve libraries otherwise.

I think this would help remove a lot of the required tweaks that many projects may need to make so that gradle can properly generate eclipse project files.

I currently have a separate plugin that I run which applies these and other fixes so that project-specific configurations can remain small.

Does this sound useful?

1 Like
2

Thanks for the ideas. There are some that I like and some that sound controversial. Let me comment on that:

cleanEclipse

task should clean what was created by

eclipse

task. Content in bin folder (or any other folder used as compile destination) is managed by Eclipse. Also there can be other outputs from Eclipse build that the plugin will ignore so this would be half-baked solution.

  1. Similar to the point above: I am not sure what else can be stored in this directory and am afraid this will break customization that should be completely independent from Gradle.

  2. Perhaps. IMO the root problem here is https://bugs.eclipse.org/bugs/show_bug.cgi?id=105372 Doing what you suggest will not help us much unless there are launch configurations giving you ability to use only

bin/main

or both

bin/main:bin/test

.

  1. http://issues.gradle.org/browse/GRADLE-1377 seems to suggest a solution. Can you take a look to see if that would be acceptable?

  2. http://issues.gradle.org/browse/GRADLE-1974 - again your comments are welcomed there.

I think eclipse-wtp deserves some changes and I have it on my TODO list (not at the top to be honest). Your input can help to shape its future functionality. And I would love to see some real world examples how people use this in their projects.

3

Thanks for the feedback, very informative.

Regarding 1 & 2, if that’s more to the spirit of the plugin, I’ll stick with the custom tasks I have now. That’s fine.

4: That solution works, yes. That’s basically what I do. I just wanted to avoid lower-level groovy scripting in every project that uses WTP if possible. Currently I have a custom plugin that I run after eclipse or eclipse-wtp which applies these tweaks.

5: Thanks for the issue link. I’ll add that it would be beneficial to put the web container last in the classpath.

3 is the most serious problem.

I’m currently working on a multi project build that generates some war artifacts, so I’m coming from that perspective and may have missed use cases of standard java projects that are run from eclipse by calling the respective main method.

My specific problem is that, when using eclipse’s WTP server deployment, files in src/test/java and src/test/resources end up in the deployed application. I can see that in .setttings/org.eclipse.wst.common.component, the test files are added as elements. If I build a war from within gradle, the test resources are properly excluded, so I can tell this is just an eclipse deployment issue.

If I make the change I mentioned, separating the outputs of the test and main sources, the test files are no longer entries in the wtp component file, and the files are excluded from deployment. So I’m not sure that having different launch configurations for these sources is necessary, because those launch configurations aren’t useful for a deployed application anyway.

I know I haven’t had this issue in m2eclipse. Do you happen to know how they might’ve solved this? Hopefully it’s not within their custom project builder. I could see that they separated test and main sources, so I figured that solution would work here, too.

4

  1. I’ll have to do more experiments to understand how WTP works with various sources and dependencies before there will be any changes.

  2. I have a patch that can better infer the version based on project dependencies but more complete solution will be implemented later when the whole dependency resolution process is improved.