Home » Language IDEs » ServerTools (WTP) » Managing dependnecies, WTP and Gradle cooperation
Managing dependnecies, WTP and Gradle cooperation [message #1237015] |
Tue, 28 January 2014 16:16 |
Eric Rizzo Messages: 3070 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 |
Larry Isaacs Messages: 1354 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 |
Eric Rizzo Messages: 3070 Registered: July 2009 |
Senior Member |
|
|
Larry Isaacs wrote on Wed, 29 January 2014 09:38On 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 |
Larry Isaacs Messages: 1354 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...
|
|
| |
Goto Forum:
Current Time: Wed Apr 24 23:50:21 GMT 2024
Powered by FUDForum. Page generated in 0.02707 seconds
|