Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » Web Tools Project (WTP) » Managing dependnecies, WTP and Gradle cooperation
Managing dependnecies, WTP and Gradle cooperation [message #1237015] Tue, 28 January 2014 16:16 Go to next message
Eric Rizzo is currently offline Eric Rizzo
Messages: 2245
Registered: July 2009
Senior Member
I'm working on a project that is using Gradle to do builds and manage dependencies. We're using the Gradle plugin in Eclipse that creates a Gradle-specific classpath container on the project, and that works well for "plain" Java projects. However, we want to use WTP on this project, which uses different classpath containers to manage dependencies and deployment, etc. Gradle has "eclipse" and "eclipseWtp" tasks that generate Eclipse project configuration files, but it does a less-than-stellar job of doing so. One of the more painful parts is that it generates links to absolute paths of Gradle-managed dependencies in the org.eclipse.wst.common.component file, like this:
<dependent-module deploy-path="/WEB-INF/lib" handle="module:/classpath/lib/C:/Users/erizzo/.gradle/caches/modules-2/files-2.1/org.springframework.hateoas/spring-hateoas/0.8.0.RELEASE/819c25e1ff12b7fca483d76b4e7d20221f621fcd/spring-hateoas-0.8.0.RELEASE.jar">

I'd like to be able to have all Eclipse project config files checked in so that we can easily check out the project directly into Eclipse and have it automatically configured without any additional steps. But obviously these absolute paths are a problem.
My question is, is there a way to specify the handle attribute of a <dependent-module> in some other way that isn't absolute and user-specific? Perhaps some way to reference the Gradle classpath container?
Or, are there any other options/ideas for getting this project completely checked in as I'm trying to achieve?

Thanks,
Eric
Re: Managing dependnecies, WTP and Gradle cooperation [message #1237371 is a reply to message #1237015] Wed, 29 January 2014 14:38 Go to previous messageGo to next message
Larry Isaacs is currently offline Larry Isaacs
Messages: 1305
Registered: July 2009
Senior Member
On 1/28/2014 11:16 AM, Eric Rizzo wrote:
> I'm working on a project that is using Gradle to do builds and manage
> dependencies. We're using the Gradle plugin in Eclipse that creates a
> Gradle-specific classpath container on the project, and that works well
> for "plain" Java projects. However, we want to use WTP on this project,
> which uses different classpath containers to manage dependencies and
> deployment, etc. Gradle has "eclipse" and "eclipseWtp" tasks that
> generate Eclipse project configuration files, but it does a
> less-than-stellar job of doing so. One of the more painful parts is that
> it generates links to absolute paths of Gradle-managed dependencies in
> the org.eclipse.wst.common.component file, like this:<dependent-module
> deploy-path="/WEB-INF/lib"
> handle="module:/classpath/lib/C:/Users/erizzo/.gradle/caches/modules-2/files-2.1/org.springframework.hateoas/spring-hateoas/0.8.0.RELEASE/819c25e1ff12b7fca483d76b4e7d20221f621fcd/spring-hateoas-0.8.0.RELEASE.jar">
>
> I'd like to be able to have all Eclipse project config files checked in
> so that we can easily check out the project directly into Eclipse and
> have it automatically configured without any additional steps. But
> obviously these absolute paths are a problem.
> My question is, is there a way to specify the handle attribute of a
> <dependent-module> in some other way that isn't absolute and
> user-specific? Perhaps some way to reference the Gradle classpath
> container?
> Or, are there any other options/ideas for getting this project
> completely checked in as I'm trying to achieve?
>
> Thanks,
> Eric
>

I have done a minimal amount of work with Gradle based Dynamic Web
Projects. In a simple example, I have one that doesn't yet include any
jar dependencies. However, I do find in the project properties Java
Build Path Libraries tab, there is a Gradle Dependencies classpath
container. Under it is a "Publish/export dependency: /WEB-INF/lib"
entry. This means any jar in the Gradle Dependencies classpath
container will be copied to the WEB-INF/lib folder of the exported or
published project. If I examine the project properties Deployment
Assembly page, I see Gradle Dependencies listed with a deploy path of
WEB-INF/lib. This entry is not editable here because it is being
declared in the .classpath file. It's just visible here.

Given the above, and assuming your project is a Dynamic Web project and
not an EAR project, I don't know why Gradle would be creating direct jar
dependencies in the org.eclipse.wst.common.component file instead of
relying on the Gradle Dependencies classpath container. Is your project
also showing the Gradle Dependencies classpath container. And if so,
does it contain duplicates of the jars you find listed in the
org.eclipse.wst.common.component file? I would think that any
duplicates could be removed from the org.eclipse.wst.common.component file.

Cheers,
Larry
Re: Managing dependnecies, WTP and Gradle cooperation [message #1237425 is a reply to message #1237371] Wed, 29 January 2014 17:39 Go to previous messageGo to next message
Eric Rizzo is currently offline Eric Rizzo
Messages: 2245
Registered: July 2009
Senior Member
Larry Isaacs wrote on Wed, 29 January 2014 09:38
On 1/28/2014 11:16 AM, I have done a minimal amount of work with Gradle based Dynamic Web
Projects. In a simple example, I have one that doesn't yet include any
jar dependencies. However, I do find in the project properties Java
Build Path Libraries tab, there is a Gradle Dependencies classpath
container. Under it is a "Publish/export dependency: /WEB-INF/lib"
entry. This means any jar in the Gradle Dependencies classpath
container will be copied to the WEB-INF/lib folder of the exported or
published project. If I examine the project properties Deployment
Assembly page, I see Gradle Dependencies listed with a deploy path of
WEB-INF/lib. This entry is not editable here because it is being
declared in the .classpath file. It's just visible here.

Given the above, and assuming your project is a Dynamic Web project and
not an EAR project, I don't know why Gradle would be creating direct jar
dependencies in the org.eclipse.wst.common.component file instead of
relying on the Gradle Dependencies classpath container. Is your project
also showing the Gradle Dependencies classpath container. And if so,
does it contain duplicates of the jars you find listed in the
org.eclipse.wst.common.component file? I would think that any
duplicates could be removed from the org.eclipse.wst.common.component file.

Cheers,
Larry


Larry,
After some more experimenting yesterday with the Gradle eclipseWtp task, examining all the changes it made when I ran it on a manually configured Dynamic Web project, I was able to surmise that the magic to make them work together is the small addition to .classpath, the Gradle container including this attribute as you said:
<attributes>
	<attribute name="org.eclipse.jst.component.dependency" value="/WEB-INF/lib"/>
</attributes>
I do wonder why there's no way to configure that in the UI.

When I include that, then there is no need for the individual <dependent-module> entries (with their hard-coded absolute paths) in the org.eclipse.wst.common.component file. I'm pretty sure this needs to be raised as a bug with Gradle, but I don't have the energy to do that right now. I really should, though...
Re: Managing dependnecies, WTP and Gradle cooperation [message #1237465 is a reply to message #1237425] Wed, 29 January 2014 19:50 Go to previous messageGo to next message
Larry Isaacs is currently offline Larry Isaacs
Messages: 1305
Registered: July 2009
Senior Member
On 1/29/2014 12:39 PM, Eric Rizzo wrote:
>
> Larry,
> After some more experimenting yesterday with the Gradle eclipseWtp task,
> examining all the changes it made when I ran it on a manually configured
> Dynamic Web project, I was able to surmise that the magic to make them
> work together is the small addition to .classpath, the Gradle container
> including this attribute as you said:
> <attributes>
> <attribute name="org.eclipse.jst.component.dependency"
> value="/WEB-INF/lib"/>
> </attributes>
> I do wonder why there's no way to configure that in the UI.

Actually there is some UI for this, though I would have expected the
Gradle plug-in to have handled this for you. If you go to the
Deployment Assembly page and click Add, one of your choices is "Java
Build Path Entries". Choose that one and you would get a chance to
select the Gradle Dependencies classpath container to be added as a
"Publish/export dependency". My statement about is not being editable
was probably misleading. The Edit button is disabled, but you can still
remove the entry or edit the deploy path (though there's no reason you
would want to do that).

There is another way as well, which is to look in the Markers view for a
warning under "Classpath Dependency Validator Message". Right-click on
the child item and select Quick Fix. Here you get a choice of including
the classpath container content in WEB-INF/lib, or explicitly excluding
it. If you happen to exclude one, the way to un-exclude it is to go to
the Java Build Path page and remove the "Excluded from publish/export
structure" item under the classpath container.

Cheers,
Larry

>
> When I include that, then there is no need for the individual
> <dependent-module> entries (with their hard-coded absolute paths) in the
> org.eclipse.wst.common.component file. I'm pretty sure this needs to be
> raised as a bug with Gradle, but I don't have the energy to do that
> right now. I really should, though...
Re: Managing dependnecies, WTP and Gradle cooperation [message #1237539 is a reply to message #1237465] Thu, 30 January 2014 00:11 Go to previous message
Eric Rizzo is currently offline Eric Rizzo
Messages: 2245
Registered: July 2009
Senior Member
Well, Gradle's eclipseWtp task is basically broken (or at least not very smart); it does add the Gradle classpath container as a "Publish/export dependency," but it then also adds hard-coded absolute path <dependent-module> entries on top of that. Redundant, plus it makes the project totally workspace-specific and thus blocks the ability to check in project config files. Yuck.
Previous Topic:(Solved)The solution for the conflict when Config Glassfish 4 with the Kepler on MAC OS X 10.9.1
Next Topic:How Do I Extend the CSS Editor?
Goto Forum:
  


Current Time: Wed Sep 17 19:37:38 GMT 2014

Powered by FUDForum. Page generated in 0.06686 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software