WTP currently does not support mixed deployment paths

Help/Discuss Buildship
1 
project('myear') {
    apply plugin: "com.orctom.was"
    apply plugin: 'ear'
    apply plugin: 'eclipse-wtp'

    dependencies{
        deploy project(':emp-jar')
        deploy project(':emp-war')

        earlib files('libs/com-2.9.0.jar')
        earlib group: 'org.slf4j', name: 'slf4j-log4j12', version: '1.7.21'
        earlib group: 'commons-lang', name: 'commons-lang', version: '2.6'
    }
}

is my project snip. I get this error:

Synchronize Gradle projects with workspace failed due to an unsupported configuration in the referenced Gradle build.
WTP currently does not support mixed deployment paths.
org.eclipse.buildship.core.UnsupportedConfigurationException: WTP currently does not support mixed deployment paths.
	at org.eclipse.buildship.core.workspace.internal.WtpClasspathUpdater.getDeploymentPath(WtpClasspathUpdater.java:62)
	at org.eclipse.buildship.core.workspace.internal.WtpClasspathUpdater.update(WtpClasspathUpdater.java:46)
	at org.eclipse.buildship.core.workspace.internal.SynchronizeGradleBuildOperation.synchronizeOpenJavaProject(SynchronizeGradleBuildOperation.java:229)
	at org.eclipse.buildship.core.workspace.internal.SynchronizeGradleBuildOperation.synchronizeOpenWorkspaceProject(SynchronizeGradleBuildOperation.java:215)
	at org.eclipse.buildship.core.workspace.internal.SynchronizeGradleBuildOperation.addNewEclipseProjectToWorkspace(SynchronizeGradleBuildOperation.java:268)
	at org.eclipse.buildship.core.workspace.internal.SynchronizeGradleBuildOperation.synchronizeNonWorkspaceProject(SynchronizeGradleBuildOperation.java:245)
	at org.eclipse.buildship.core.workspace.internal.SynchronizeGradleBuildOperation.synchronizeGradleProjectWithWorkspaceProject(SynchronizeGradleBuildOperation.java:181)
	at org.eclipse.buildship.core.workspace.internal.SynchronizeGradleBuildOperation.runInWorkspace(SynchronizeGradleBuildOperation.java:142)
	at org.eclipse.buildship.core.workspace.internal.SynchronizeGradleBuildOperation.access$000(SynchronizeGradleBuildOperation.java:105)
	at org.eclipse.buildship.core.workspace.internal.SynchronizeGradleBuildOperation$1.run(SynchronizeGradleBuildOperation.java:123)
	at org.eclipse.jdt.internal.core.BatchOperation.executeOperation(BatchOperation.java:39)
	at org.eclipse.jdt.internal.core.JavaModelOperation.run(JavaModelOperation.java:729)
	at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:2241)
	at org.eclipse.jdt.core.JavaCore.run(JavaCore.java:5409)
	at org.eclipse.jdt.core.JavaCore.run(JavaCore.java:5366)
	at org.eclipse.buildship.core.workspace.internal.SynchronizeGradleBuildOperation.run(SynchronizeGradleBuildOperation.java:119)
	at org.eclipse.buildship.core.workspace.internal.SynchronizeGradleBuildsJob.synchronizeBuild(SynchronizeGradleBuildsJob.java:77)
	at org.eclipse.buildship.core.workspace.internal.SynchronizeGradleBuildsJob.runToolingApiJob(SynchronizeGradleBuildsJob.java:68)
	at org.eclipse.buildship.core.util.progress.ToolingApiJob$1.run(ToolingApiJob.java:73)
	at org.eclipse.buildship.core.util.progress.ToolingApiInvoker.invoke(ToolingApiInvoker.java:62)
	at org.eclipse.buildship.core.util.progress.ToolingApiJob.run(ToolingApiJob.java:70)
	at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55)

using milestone 2. Now i get that gradle is about 5 years ahead of the piece of junk known as eclipse, but, concessions have to be made. I realize that doing it the right way is a bad thing with eclipse. i get that. But can we have buildship treat this as a warning instead of blowing up the import? With gradle, eclipse is largely used as a glorified text editor anyways so this error is largely irrelevant for most people, due to the fact we aren’t building with eclipse, we are building with gradle.

Can this be switched from an error to a warning?

And on a side note, i have big problems with the imports always giving errors. I don’t live in a perfect world and lots of times, im trying to import projects in order to fix them, but both the eclipse and intellij plugins keep blowing up so i typically end up having to fix the problems in notepad anyways. makes me long for the days of edit.

2

The problem is that this leads to not being able to use Eclipse’s deploy to sever feature. Just ignoring it would be confusing (people don’t look at warnings in the log). That’s why we decided to make it an error. What we should probably do (not just for this case) is add error markers to the project instead of failing the import.

The other thing you mentioned could be solved with a “dumb” mode which ignores a broken model and just imports the root project as a plain project.

Would you be interested in contributing these features?

3

I would put a switch in the model so we can choose. I can think of a few projects for each situation.

funny you should ask about contributing. Me and my CTO are meeting with the legal department next week on that very question. My company has one of those all code is ours and proprietary rules. If my CTO and i can get that overturned, then sure. but lawyers are involved, so it will be a while.

4

No switches please :slight_smile: It is always an error, but that error should not block you from working. An error marker on the build file would be the right way to go. We could provide a preference page where the user can configure how to treat each of these Eclipse-specific errors (error/warning/ignore).

5

i didn’t mean to switch on and off whether or not its an error, its always an error until they update WPT, which should be sometime in the next 2-300 years (it is an IBM project after all). what im saying is when the error happens, switch between importing it as a broken ear project or a perfectly fine java project.

6

It will work perfectly fine, you just can’t deploy it from Eclipse. All we need to do is not throw an error and just add a visual error marker instead. We should do that for almost all errors in fact.

7

do you think there is any way to salvage the deployability? i have 1000 developers and 900 of them are addicted to debuggers, which require eclipse deployers. i was going to rip apart the gradle EAR plugin to see if there’s something there i can rewrite or reimplement to do it, but its a stretch. Short of forcing IBM to support IntelliJ, do you see any way to salvage this?

8

The problem is that the WTP plugin uses the raw classpath instead of the resolved classpath. This means that all dependencies in the Gradle dependency container get the same deployment path, even though each entry could actually have a different one. If you want that fixed, you’d have to contribute a patch to Eclipse WTP.

There was a long discussion in BugZilla where the Maven folks tried to explain this exact problem, but the WTP contributor did not understand the use case.

9

If you could give me a small example on GitHub, I can also look whether there is something we could do on the Buildship side, since the chances of changing WTP are slim. In the snippet you showed above I only see a single deploy path, which would be fine.

10

yea, ive been reading the WTP code, it take me a year to get started, its huge. I may have a touch of luck with IBM. We just volunteered to test 2 of their new server products, maybe they will do us a favor for it. Ill open a PMR on monday and see if it goes anywhere. But that thing is so outdated it 2016 and it doesn’t even have the concept of test source dirs so im not going to hold my breath.

Have to wait till i get back in the office monday but yea, i can send you the whole build file. These eclipse builders and deployers have been nothing but a nightmare for us over the years, but for the guys/gals that like debuggers, its the only way. Thats why for 15 years now, applications were built one way on the dev’s desktop and a completely different way on the server before deployment. then to combat the inevitable class issues, they solved things by just dumping 150 megs (on average) worth of libraries in each application hoping they got them all.

Ive told my tooling guys that i have no problem eliminating debuggers all together because i personally believe you develop the invaluable ability to read code without them, but i was physically thrown out of the room. so i gotta figure it out.

11

Note that WTP is developed by RedHat, not IBM.

I think we can work something out to fix this. A self-contained example that shows the failure would be great.

12

In our company we are also struggeling with the limitations in Eclipse WTP. This makes it currently impossible to import out projects into Eclipse using Builship and newer versions of Gradle.
Please continue with the idea to not throw an exception but set an error marker instead.

We are not using the Eclipse deployment methods so the WTP stuff is not of importance. We just want to be able to import the whole Gradle project to work with the code.

13

@toex can you please provide an example project that fails? The only reason it should fail is if the same project has both the war and ear plugin applied at the same time. Anything else might be a bug in Gradle/Buildship.

14

Here’s my full build file. this project is setup as a single file build. i had to annonymize a bit but the jvm plugin also includes java.

buildscript {
    repositories {
        mavenCentral()
        mavenLocal()
        jcenter()
        maven {
            url "https://plugins.gradle.org/m2/"
        }
    }

    dependencies { 
        classpath 'com.mycompany.pluginsuite:jvm:+' 
        classpath "gradle.plugin.com.orctom.gradle.was:was-gradle-plugin:1.1"
        files('libs/com.ibm.ws.runtime.jar')
    }
}

apply plugin: 'jvm'

allprojects{
    repositories {
        mavenCentral()
        mavenLocal()
    }
}

subprojects {
	apply plugin: 'eclipse-wtp'
}

project('emp-ear') {
    apply plugin: "com.orctom.was"
    apply plugin: 'ear'

    dependencies{
       deploy project(':emp-jar')
       deploy project(':emp-war')

       earlib files('libs/com-2.9.0.jar')
       earlib group: 'org.slf4j', name: 'slf4j-log4j12', version: '1.7.21'
   	   earlib group: 'commons-lang', name: 'commons-lang', version: '2.6'
    }
}

project('emp-jar') {
    dependencies{
        compile group: 'org.slf4j', name: 'slf4j-log4j12', version: '1.7.21'
    }
}

project('emp-war') {
    apply plugin: 'war'
    dependencies{
        compile project(':emp-jar')

        compile files('libs/was8.5/dev/was_public.jar')

        compile files('libs/com-2.9.0.jar')
        compile group: 'org.slf4j', name: 'slf4j-log4j12', version: '1.7.21'
        compile group: 'commons-lang', name: 'commons-lang', version: '2.6'
    }
}
15

I need some time for an example, since I cannot publish our build here.
I try to find a minimal example.

16

@scphantm I copied your build script and generated the classpath. There were no mixed deployment paths. Everything in emp-ear is deployed to /lib, everything in emp-war is deployed to /WEB-INF/lib as expected.

Can you run gradle eclipse on your project and check the values of the org.eclipse.jst.component.dependency attributes? Buildship will throw the exception if different values are mixed within a single classpath.

17

ok, i tried it both ways. If you gradle eclipse on the master and all subprojects, it can be opened with eclipse with typical problems, wrong jvm, and such, which im working on. and all the deployments are screwed up, but again, i think thats more configs working with the websphere plugin. But, if you gradle cleaneclipse and delete the .metadata folder, etc, and then do file, import, and import as a gradle project, thats when you get the error above.

18

I was specifically interested if there is any .classpath file containing different values for org.eclipse.jst.component.dependency? Have you checked?

19

when it bombs out on import, only the base and the ear have a classpath file and neither have an entry for that

when you run gradle eclipse, the ear has different values (’/’ and ‘/lib’), one entry for each of the files listed in the dependencies and the war has one for each of the files in the dependencies, all pointing to ‘web-inf/lib’

am i correct in that the eclipse plugin doesn’t care that its an illegal setting and writes it out, but buildship is validating it?

20

It’s not illegal, it’s just not supported when inside a container.

I don’t get different paths for the exact same setup you pasted. So I can only assume that your jvm plugin is changing something in how the war or ear plugins work. Or the example is not showing the full picture.

More specifically, there should be no dependencies with path ‘/’.

Can you please provide a fully self contained example repo?