WAR deploy to Eclipse Tomcat server is different from WAR build with Gradle


(Mark Himsley) #1

I have a multi-project app, which eventually builds into a WAR.

In building the WAR I need to copy one ‘special’ file - its in another project for testing, but it needs to be copied to the WAR for the app server.

The following works perfectly, for the WAR, putting the specified file into the folder in the WAR. But it doesn’t do the same when running Tomcat as a server in Eclipse, the file does not get copied to the Tomcat server’s wtpwebapps folder.

apply plugin: 'war'
war {
    from (project(':project').file('src/main/bin/file')) {
        into ('WEB-INF/bin')
    }
}

Am I think wrongly - should I be also be adding the same folder to eclipse.wtp.component… ?


(Donát Csikós) #2

Hi Mark,

This is expected because Buildship has no WTP integration, although we plan to add an initial support in the near future.


(Mark Himsley) #3

Thanks Donát.

Because of all the bugs and limitations in the eclipse.wtp.component functionality, it would be great to have Buildship understand the war plugin configuration and mimic that into Eclipse.


(Stefan Oehme) #4

Buildship will get the information from the eclipse.wtp.component, so any bugs in there would also be in Buildship. Please report them (if you haven’t already), so that everything will work once Buildship reads that information.


(Mark Himsley) #5

Trouble is - I’m finding it really hard to work out what’s reported already and what isn’t - I haven’t got all of the terminology right (in Gradle, Buildship, or Eclipse) so I’m finding it hard to search for reported bugs.

  1. I believe there is a limitation in Eclipse that a project’s Deployment Assembly cannot reference folders/files that are outside of the project. What I mean is, the source-path attribute in <wb-resource> tags in .settings/org.eclipse.wst.common.component is only relative to the project. That appears to be something that will add difficulty to making snippet of code I started this thread with work.

  2. As a workaround I made a Gradle create link in the Eclipse project. That exposed the issue I described here: Eclipse linked folder added with extra '_' after every Gradle refresh - which Donát has already kindly made into a bug report.

  3. And while implementing that workaround I found that the making Gradle make the source-path attribute in <wb-resource> refer to a linked folder did not work. So after searching around I had to implement another work-around in order to make the first work-around work: which is to tinker with the XML using eclipse.wtp.component.file.withXml instead of using the more logical/simple eclipse.wtp.component.resource.

Other people have documented this set of issues, and documented the workarounds - I claim no credit for that.

All in all - using a resource in one project in an Eclipse managed Tomcat of another project is exposing quite a few limitations and bugs - and my build.gradle has is getting close to having more comments saying why each workaround is necessary than actual code :-/

Hopefully this post brings together a group of related limitations and issues into one thread.


(Stefan Oehme) #6

What’s the use case for directly copying a resource from another project? Why not include it as a normal jar dependency and get the resource from the classpath? That would also get rid of the issue that Eclipse can’t handle resources outside the project.


(Mark Himsley) #7

Hi Stefan - thanks for your interest.

In this instance it’s an executable. Its in one project, which is a library wrapper around the executable - not included in the output JAR, for obvious reasons. And it needs to be copied into the WAR - which is always exploded, for similar obvious reasons.
I’m sure you can think of other instances where a file referred to in one library project also needs to be accessible in another project without the file being included in the library project’s JAR. Database files, cache files, the list is long.


(Harinder Singh Bedi) #8

Yes, WTP integration is quit important and many developers love the ease it provides. Not having it might give one reason to some people not moving to gradle.


(Stefan Oehme) #9

WTP support is coming, read more here: [Request for feedback] WTP support coming to Buildship