WTP currently does not support mixed deployment paths

Help/Discuss Buildship
21

Ive already pushed my luck with posting stuff. Here’s a snip of the classpath in the EAR project. this is generated from the gradle eclipse command

<classpathentry kind="src" path="/emp-war">
		<attributes>
			<attribute name="org.eclipse.jst.component.nondependency" value=""/>
		</attributes>
	</classpathentry>
	<classpathentry sourcepath="C:/Users/lid4ec9/.gradle/caches/modules-2/files-2.1/org.slf4j/slf4j-log4j12/1.7.21/16b1333786ea93d16bff6fb0f5e3b82716d1b008/slf4j-log4j12-1.7.21-sources.jar" kind="lib" path="C:/Users/lid4ec9/.gradle/caches/modules-2/files-2.1/org.slf4j/slf4j-log4j12/1.7.21/7238b064d1aba20da2ac03217d700d91e02460fa/slf4j-log4j12-1.7.21.jar">
		<attributes>
			<attribute name="org.eclipse.jst.component.dependency" value="/lib"/>
		</attributes>
	</classpathentry>
	<classpathentry sourcepath="C:/Users/lid4ec9/.gradle/caches/modules-2/files-2.1/commons-lang/commons-lang/2.6/67313d715fbf0ea4fd0bdb69217fb77f807a8ce5/commons-lang-2.6-sources.jar" kind="lib" path="C:/Users/lid4ec9/.gradle/caches/modules-2/files-2.1/commons-lang/commons-lang/2.6/ce1edb914c94ebc388f086c6827e8bdeec71ac2/commons-lang-2.6.jar">
		<attributes>
			<attribute name="org.eclipse.jst.component.dependency" value="/lib"/>
		</attributes>
	</classpathentry>
	<classpathentry sourcepath="C:/Users/lid4ec9/.gradle/caches/modules-2/files-2.1/org.slf4j/slf4j-api/1.7.21/f285ac123f201fb4b028bac556928d7cf527ef48/slf4j-api-1.7.21-sources.jar" kind="lib" path="C:/Users/lid4ec9/.gradle/caches/modules-2/files-2.1/org.slf4j/slf4j-api/1.7.21/139535a69a4239db087de9bab0bee568bf8e0b70/slf4j-api-1.7.21.jar">
		<attributes>
			<attribute name="org.eclipse.jst.component.dependency" value="/lib"/>
		</attributes>
	</classpathentry>
	<classpathentry sourcepath="C:/Users/lid4ec9/.gradle/caches/modules-2/files-2.1/log4j/log4j/1.2.17/677abe279b68c5e7490d6d50c6951376238d7d3e/log4j-1.2.17-sources.jar" kind="lib" path="C:/Users/lid4ec9/.gradle/caches/modules-2/files-2.1/log4j/log4j/1.2.17/5af35056b4d257e4b64b9e8069c0746e8b08629f/log4j-1.2.17.jar">
		<attributes>
			<attribute name="org.eclipse.jst.component.dependency" value="/lib"/>
		</attributes>
	</classpathentry>
	<classpathentry kind="lib" path="C:/Apps/Willie/code/TestProjectsConverted/Workspace/EMP/emp-war/libs/was8.5/dev/was_public.jar">
		<attributes>
			<attribute name="org.eclipse.jst.component.dependency" value="/"/>
		</attributes>
	</classpathentry>
	<classpathentry kind="lib" path="C:/Apps/Willie/code/TestProjectsConverted/Workspace/EMP/emp-war/libs/com-2.9.0.jar">
		<attributes>
			<attribute name="org.eclipse.jst.component.dependency" value="/"/>
		</attributes>
	</classpathentry>
	<classpathentry kind="lib" path="C:/Apps/Willie/code/TestProjectsConverted/Workspace/EMP/emp-ear/libs/com-2.9.0.jar">
		<attributes>
			<attribute name="org.eclipse.jst.component.dependency" value="/lib"/>
		</attributes>
	</classpathentry>
22

To me it looks like you made the deploy configuration transitive, which it should not be. The dependencies of the war project are leaking into the root of the ear. Gradle makes deploy non-transitive by default for that reason.

23

With the remarks from scphantm and from you Stefan, I was able to analyze our problem.

We do have an EAR archive with a dependency JAR (called register.jar) added to the top level of the EAR (this is necessary due to a proprietary framework we have to use on our application server.)
This causes a dependency with a path value of / and, like you mentioned, this is the problem for WTP and Buildship.

In our case it was easy to get around this, by excluding the dedicated JAR dependency to register.jar from the Eclipse project, since it is not needed to compile or test the project.

I added a new configuration for that and excluded this configuration in the Eclipse classpath:

apply plugin: 'ear'

configurations {
    seeregister
}

dependencies {
   seeregister see:register:1.0
   deploy see:register:1.0    
}

eclipse.classpath {
    minusConfigurations += [ configurations.seeregister ]
}

Using this, I could use Buildship to import the project into Eclipse and work with it.

This might not be a general solution, but may be some others facing the same problem.

24

Ok, so how did i screw it up? i sent you the entire build file, top to bottom and 90% of it was a copy paste from the gradle documentaiton. how did i screw up?

26

@toex if you let deploy extend from seeregister, you can avoid the duplicate dependency declaration.

27

@scphantm I found the issue: It happens only with local file dependencies like compile files('libs/com-2.9.0.jar'). These leak into the .classpath file despite the fact that deploy is marked as non-transitive.

I’ll look into a fix. In the meantime, can you try the following workaround in the ear project?

eclipse.classpath.minusConfigurations << configurations.deploy

28

well, yea, i can actually. The local is only like that for the time being until our Artifactory server comes online. then those libraries will be deployed there. I just did the local files to let the thing compile for testing.

thats really cool, thanks

29

Good to know you won’t be affected for long. Thanks for walking me through the issue!

I’ve found the offending code and will open a pull request with a fix some time this week, so Gradle 3.3 will no longer have this problem.

30

@scphantm the fix has been merged and will be in Gradle 3.4

1 Like