Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 354346

Summary:

SingleRootExportParticipant ignoring situation where reference is not ignored, also not a child

Product:

[WebTools] WTP Java EE Tools

Reporter:

Fred Bricon <fbricon>

Component:

jst.j2ee

Assignee:

Rob Stryker <stryker>

Status:

RESOLVED FIXED

QA Contact:

Chuck Bridgham <cbridgha>

Severity:

normal

Priority:

CC:

ccc, shr31223, stryker

Version:

3.3

Flags:

cbridgha: review+

Target Milestone:

3.3.2

Hardware:

OS:

Linux

Whiteboard:

Attachments:

Description	Flags
Sample projects to reproduce the issue	none
Patch to ensure such jars are included	none
Test case for attached project	none

Description Fred Bricon

2011-08-10 05:08:39 EDT

Build Identifier:  I20110613-1736

Hi,

I'm trying to hack in support for mavenized JBoss SAR projects in JBoss Tools (https://issues.jboss.org/browse/JBIDE-9127)

So far I've been adding the Utility Facet to such projects, so they can be deployed in EARs.
A SAR project can embed dependencies in a lib folder, inside the archive.
A loooong time ago, when I tried it on a POC, the fix for https://bugs.eclipse.org/bugs/show_bug.cgi?id=298735 made it possible to work.

In this use case, I have 2 sample maven-less projects :
-sarproject : has a dependency to JUNIT_HOME\junit.jar in the module assembly page. The resulting org.eclipse.wst.common.component contains :

<project-modules id="moduleCoreId" project-version="1.5.0">
    <wb-module deploy-name="sarproject">
        <wb-resource deploy-path="/" source-path="/src"/>
        <dependent-module archiveName="junit.jar" deploy-path="/lib" handle="module:/classpath/var/JUNIT_HOME/junit.jar">
            <dependency-type>uses</dependency-type>
        </dependent-module>
    </wb-module>
</project-modules>

-earproject : needed so sarproject can be a Module project. I've manually tweaked org.eclipse.wst.common.component so sarproject will have the .sar extension when deployed. Here is the end result :

<project-modules id="moduleCoreId" project-version="1.5.0">
    <wb-module deploy-name="earproject">
        <wb-resource deploy-path="/" source-path="/EarContent"/>
        <dependent-module archiveName="sarproject.sar" deploy-path="/" handle="module:/resource/sarproject/sarproject">
            <dependency-type>uses</dependency-type>
        </dependent-module>
    </wb-module>
</project-modules>

Unfortunately, it seems a regression has crept in, because using these projects, the embedded jar (junit.jar) is no longer present inside the sarproject.sar, when earproject is deployed on (any) JBoss AS (https://issues.jboss.org/browse/JBIDE-9496).

I know that, since it's a hack, you might be tempted to not fix it but, if you export the ear project, everything works fine. So you have an inconsistent behaviour between export and deployment AHAAAAH!!! And, I might have other use cases where this whole Utility facet + embedded jars might be useful, so I think it should be fixed :-)

Reproducible: Always

Comment 1 Fred Bricon

2011-08-10 05:10:16 EDT

Created attachment 201220 [details]
Sample projects to reproduce the issue

Comment 2 Fred Bricon

2011-08-10 05:13:53 EDT

Quoting Rob Stryker from https://issues.jboss.org/browse/JBIDE-9496 : 

"The utility project is being identified as a "single root" project. There seems to be a bug in the single root handler (an efficient handler for specific cases) where it ignores references that are not child modules.

Workaround is to make your project NOT single root. Steps to do that include:
1) Adding a new folder to your project called "garbage" or some other irrelevant name
2) Adding a folder mapping from "garbage" to "/" via the module assembly page.

At this point your project is no longer single root and this bug is worked around."

Comment 3 Rob Stryker

2011-08-12 03:09:39 EDT

*** Bug 354469 has been marked as a duplicate of this bug. ***

Comment 4 Rob Stryker

2011-08-12 03:10:34 EDT

Created attachment 201370 [details]
Patch to ensure such jars are included

Bringing patch over from 354469

Comment 5 Carl Anderson

2011-08-25 16:32:32 EDT

Rob, you removed yourself as the owner here, but attached a patch.  That confuses me.

I am assigning this to Roberto, and targeting it to WTP 3.4.0... if that is incorrect, please modify this as appropriate.

Comment 6 Rob Stryker

2011-09-13 08:10:53 EDT

Hey Chuck: Seeking a review for 3.3.2.  I assume I do not need a review for 3.4.0 yet?

Comment 7 Chuck Bridgham

2011-09-14 19:44:07 EDT

Rob - will get to this soon...   but because this is targeted to 3.3.2, it may be next week

Comment 8 Rob Stryker

2011-10-13 06:58:18 EDT

Hey Chuck:

Gotta ping on this pal

Comment 9 Chuck Bridgham

2011-10-17 10:26:38 EDT

I have tested this change, and it looks reasonable.. Can you add a new junit with your sample?  Need to fill in these holes.  - Let me know if you need some help setting up

Comment 10 Roberto Sanchez Herrera

2011-10-17 10:55:19 EDT

Just for curiosity, was the array of delegates in this class (SingleRootExportParticipant) reviewed to see if one of them should consider this reference as a child module, or maybe add a new delegate? I think that this patch is bypassing completely the verification made by the delegates, so I wonder if that is what we want (but it is just a comment, I'm fine with the patch)

Comment 11 Rob Stryker

2011-10-21 03:57:54 EDT

> was the array of delegates in this class (SingleRootExportParticipant) reviewed to see if one of them should consider this reference as a child module

Yes, they are still checked ;)   addChildModules still calls isChildModule, which iterates through the delegates to find out.

Comment 12 Rob Stryker

2012-01-17 03:54:32 EST

Created attachment 209605 [details]
Test case for attached project

Comment 13 Rob Stryker

2012-01-17 04:09:31 EST

Um... the changes to AllTests  were just to speed up my testing. Those obviously don't need to be in the patch.

Comment 14 Rob Stryker

2012-01-18 02:34:04 EST

Committed and released to 3.3.2 and head with test