[GRADLE-2362] eclipse-wtp should be supported on non-EAR/WAR projects Created: 25/Jun/12  Updated: 07/Dec/14  Resolved: 05/Dec/14

Status: Resolved
Project: Gradle
Affects Version/s: 1.0
Fix Version/s: 2.3-rc-1

Type: Improvement
Reporter: Andrew Oberstar Assignee: Radim Kubacki
Resolution: Fixed Votes: 0

Issue Links:
Duplicate
Duplicates GRADLE-2221 Cannot manually configure a facet for... Resolved
Duplicates GRADLE-2186 Faceted eclipse wtp projects without ... Resolved

 Description   

Issue:

The eclipse-wtp plugin currently requires either the EAR or WAR plugin to be applied for any real functionality to be applied, except in very specific cases.

Currently the plugin will wire up the tasks and model for any EAR/WAR projects that have eclipse-wtp applied and also for any project dependencies in the EAR/WAR's runtime configuration.

This inhibits use in cases where the EAR project does not also have the java plugin applied (no runtime conf) or for any standalone project that requires facets but is not part of an EAR/WAR.

What I want is to be able to apply eclipse-wtp to any plugin and add facets, without needing to wire up the tasks and the eclipse model.

Specific Use Case:

We have our own internal plugin for EJB projects. These require a specific facet to be added to work properly in Eclipse. Given the current behavior of the eclipse-wtp plugin, I need to manually create the WTP Facet task as well as wire the facet model into the WTP model.

The reason the existing runtime-following logic doesn't work is that the EJB is added as a deploy dependency to the EAR. Since we make a practice of not adding the java plugin to our EARs (we add JavaBasePlugin only, since there is no code being compiled), we don't have a runtime configuration.

Possible Implementations:

My preferred option would be to have the eclipse-wtp plugin wire up all of the tasks regardless of what other plugins are applied. Any project with eclipse-wtp should have the ability to add facets. I don't know if the component makes as much sense independently, so maybe I really just need the facets task/model.

 Comments   
Comment by Andrew Oberstar [ 10/May/13 ]

I think this is the same as GRADLE-2186.

Comment by Andreas Schmid [ 04/Nov/14 ]

Hi Andrew Oberstar,
I am currently planning to fix GRADLE-2186 and found this issue. How important is it to be able to adjust the eclipse.wtp... configuration event if the "java" plugin or at least "java-base" plugin is not applied? IMHO this does not really makes sense or do you have a use case for that as well?

And would it also work for you if the "eclipse-wtp" plugin is only applied if at least the "java" plugin is applied (as the "java-base" already does a lot of configurations, you can easily also apply the java plugin instead).

Comment by Andrew Oberstar [ 04/Nov/14 ]

My memory is a little fuzzy on this. We've had a workaround in place since I opened the issue, so I haven't thought much about it since.

Primarily, I wanted to support the EJB and utility JAR use cases mentioned in the other issue. As a general point, I'd like that it doesn't force any additional dependencies that aren't technically required. If the necessary configuration can be done without knowledge of the java or java-base plugins then the dependency shouldn't be there. It can open up more flexibility for people who end up with different use cases.

Comment by Andreas Schmid [ 16/Nov/14 ]

Hi Andrew Oberstar,

what defaults would you expect for the properties on http://www.gradle.org/docs/current/dsl/org.gradle.plugins.ide.eclipse.model.EclipseWtpComponent.html#N125B5?

With my fixes for GRADLE-2186 and GRADLE-2221, this would already work but with no certain defaults besides 

deployName = project.eclipse.project.name

. The other defaults come directly from 

org.gradle.plugins.ide.eclipse.model.EclipseWtpComponent

.

Cheers,
Andreas

Comment by Andrew Oberstar [ 17/Nov/14 ]

From what I can see in our code, I wouldn't be expecting any additional defaults to be set.

Comment by Andreas Schmid [ 17/Nov/14 ]

Nice, so this should be fixed with https://github.com/gradle/gradle/pull/353
Even though, I am planning to provide some proper defaults with a further pull request.

Comment by Andrew Oberstar [ 17/Nov/14 ]

Thanks! I like the behavior in that pull request much better than the current.

Comment by Andreas Schmid [ 17/Nov/14 ]

Welcome, maybe you add a comment with this, for having more positive feedback on this

Comment by Radim Kubacki [ 05/Dec/14 ]

Fix provided by Andreas Schmid.

Generated at Wed Jun 30 12:19:51 CDT 2021 using Jira 8.4.2#804003-sha1:d21414fc212e3af190e92c2d2ac41299b89402cf.