[GRADLE-1399] Incorrect contents generated for org.eclipse.wst.common.component file in Eclipse WTP Utility Module projects Created: 25/Feb/11  Updated: 04/Jan/13  Resolved: 26/Feb/11

Status: Resolved
Project: Gradle
Affects Version/s: 1.0-milestone-1
Fix Version/s: 1.0-milestone-1

Type: Bug
Reporter: Matt Accola Assignee: Peter Niederwieser
Resolution: Fixed Votes: 1

Attachments: Zip Archive test.zip    

 Description   

Background: Issue introduced by fix for http://jira.codehaus.org/browse/GRADLE-1275.

When Eclipse plugin is applied to a WAR project the contents of the org.eclipse.wst.common.component file for each Eclipse project the WAR file depends on is incorrect. The result is that the contents of the JAR file which is deployed within the WAR is incorrect.

Steps to reproduce:
1. Unzip the attached test.zip project structure.
2. Run the following command in the root directory of the project: gradle eclipse

Expected contents of TestModuleA/.settings/org.eclipse.wst.common.component file:

<?xml version="1.0" encoding="UTF-8"?>
<project-modules id="moduleCoreId" project-version="2.0">
	<wb-module deploy-name="TestModuleA">
		<wb-resource deploy-path="/" source-path="src/main/resources"/>
		<wb-resource deploy-path="/" source-path="src/main/java"/>
	</wb-module>
</project-modules>

Actual contents of TestModuleA/.settings/org.eclipse.wst.common.component file:

<?xml version="1.0" encoding="UTF-8"?>
<project-modules id="moduleCoreId" project-version="2.0">
	<wb-module deploy-name="TestModuleA">
		<property name="java-output-path" value="build/classes/main"/>
		<wb-resource deploy-path="/WEB-INF/classes" source-path="src/main/resources"/>
		<wb-resource deploy-path="/WEB-INF/classes" source-path="src/main/java"/>
		<dependent-module deploy-path="/WEB-INF/lib" handle="module:/resource/TestModuleB/TestModuleB">
			<dependency-type>uses</dependency-type>
		</dependent-module>
		<dependent-module deploy-path="/WEB-INF/lib" handle="module:/classpath/lib//home/mraccola/.gradle/cache/commons-lang/commons-lang/jars/commons-lang-2.5.jar">
			<dependency-type>uses</dependency-type>
		</dependent-module>
	</wb-module>
</project-modules>

Expected contents of TestModuleB/.settings/org.eclipse.wst.common.component file:

<?xml version="1.0" encoding="UTF-8"?>
<project-modules id="moduleCoreId" project-version="2.0">
	<wb-module deploy-name="TestModuleB">
		<wb-resource deploy-path="/" source-path="src/main/resources"/>
		<wb-resource deploy-path="/" source-path="src/main/java"/>
	</wb-module>
</project-modules>

Actual contents of TestModuleB/.settings/org.eclipse.wst.common.component file:

<?xml version="1.0" encoding="UTF-8"?>
<project-modules id="moduleCoreId" project-version="2.0">
	<wb-module deploy-name="TestModuleB">
		<property name="java-output-path" value="build/classes/main"/>
		<wb-resource deploy-path="/WEB-INF/classes" source-path="src/main/resources"/>
		<wb-resource deploy-path="/WEB-INF/classes" source-path="src/main/java"/>
		<dependent-module deploy-path="/WEB-INF/lib" handle="module:/classpath/lib//home/mraccola/.gradle/cache/commons-collections/commons-collections/jars/commons-collections-3.2.jar">
			<dependency-type>uses</dependency-type>
		</dependent-module>
	</wb-module>
</project-modules>


 Comments   
Comment by Peter Niederwieser [ 25/Feb/11 ]

Thanks for the analysis. So the component file for the web project is correct, but the component files for the utility projects need to be stripped down as shown? (In our previous discussions, we had even considered to create an empty component file for utility projects. This gave me the impression that its content might not matter all that much.)

Comment by Rob Winch [ 26/Feb/11 ]

In the event that you were curious this appears to be the same issue that I was encountering with the changes in GRADLE-1275. To expand upon the description Matt provided the reason the component file for the utility projects should be this way is that the deploy-path is relative to the utility project which means it is embedded in the jar.

To clarify, by specifying the deploy-path="/WEB-INF/lib" for commons-collection within TestModuleB, commons-collections-3.2.jar is included at TestWeb/WEB-INF/lib/TestModuleB.jar/WEB-INF/lib/commons-collections-3.2.jar. This is because the relative path is within the jar itself. With this in mind commons-collections-3.2.jar should be in the war component file and not in the module component file. By placing it in the war component file and a deploy-path="/WEB-INF/lib" it would be placed at TestWeb/WEB-INF/lib/commons-collections-3.2.jar

A similar problem occurs with the compiled classes and resources of TestModuleB having a deploy-path="/WEB-INF/classes". This makes it so that these resources and classes are included at TestWeb/WEB-INF/lib/TestModuleB.jar/WEB-INF/classes/. With this in mind the deploy path for the compiled classes and resources for modules should be / so that it appears in the root of the jar.

For those that wish, these observations can be seen when deploying the war and navigating to <ECLIPSE_WORKSPACE>/.metadata/.plugins/org.eclipse.wst.server.core/tmp<SERVER_COUNT>/wtpwebapps

Comment by Peter Niederwieser [ 26/Feb/11 ]

> With this in mind commons-collections-3.2.jar should be in the war component file and not in the module component file.

Are you sure that lib dependencies of utility projects need to be referenced in the component file of the dynamic web project? Matt's project doesn't indicate this. The dependencies are marked with <attribute name="org.eclipse.jst.component.dependency" value="../"/> in the utility project's .classpath file though. Just wondering if "../" is always the correct value (it's currently hard-coded).

Comment by Peter Niederwieser [ 26/Feb/11 ]

This comment seems to indicate that we are doing the right thing regarding lib dependencies of utility projects: http://jira.codehaus.org/browse/MECLIPSE-264?focusedCommentId=103194&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_103194

value="../" could mean that the dependency belongs into the same directory as the utility project's Jar. Not sure if the absolute path "/WEB-INF/lib" is an improvement. Searching the web I've seen both of these values but nothing else.

Comment by Matt Accola [ 26/Feb/11 ]

Peter, I do not believe it is necessary to reference all the utility project's lib dependencies in the dynamic web project's component file. As you stated this is the function of the org.eclipse.jsp.component.dependency attribute in the entries of the utility project's .classpath file. For complete details please read this link, http://wiki.eclipse.org/ClasspathEntriesPublishExportSupport.

So I think we should be good. I will do some more testing with the latest fix on Monday.

Things would have been a whole lot easier if Eclipse treated project classpath entries the same as lib classpath entries. There is a reference to a bug that documents this issue at the bottom of that link I posted above. Here is the link for the bug, https://bugs.eclipse.org/bugs/show_bug.cgi?id=184125. Fortunately Peter has already addressed this by recursing through all the depended-upon projects and adding an entry in the dynamic web project's component file for all depended-upon projects. I have verified this was fixed as a part of GRADLE-1275.

Comment by Rob Winch [ 26/Feb/11 ]

As you might have guessed I have been trying to reverse engineer how Eclipse works a bit (I don't have an in depth knowledge of the configuration files). I misspoke when I stated that it was required in the war. While that does work it is not necessary with the dependency attribute in the classpath (something I was unaware of). I verified the changes that have been made fixed the issues I have been having. Thank you both for your efforts.

Generated at Wed Jun 30 11:54:34 CDT 2021 using Jira 8.4.2#804003-sha1:d21414fc212e3af190e92c2d2ac41299b89402cf.