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

Bug 320729

Summary: Cycle errors detected when import an EAR with JPA and Utility jars as projects.
Product: [WebTools] WTP Java EE Tools Reporter: Jason Sholl <jsholl>
Component: jst.j2eeAssignee: Jason Sholl <jsholl>
Status: RESOLVED FIXED QA Contact: Chuck Bridgham <cbridgha>
Severity: normal    
Priority: P3 CC: ccc, david_williams
Version: 3.2Flags: david_williams: pmc_approved+
jsholl: pmc_approved? (raghunathan.srinivasan)
jsholl: pmc_approved? (naci.dai)
jsholl: pmc_approved? (deboer)
jsholl: pmc_approved? (neil.hauge)
jsholl: pmc_approved? (kaloyan)
cbridgha: review+
Target Milestone: 3.2.1   
Hardware: PC   
OS: Windows Server 2003   
Whiteboard: PMC_approved
Attachments:
Description Flags
ear
none
patch for 3.2.1 none

Description Jason Sholl CLA 2010-07-23 10:49:28 EDT 
This is a regression introduced in WTP 3.2.  Users with workspaces from previous versions of WTP containing EE5 projects may run into this problem.  This can also be reproduced using the following steps:

Steps to reproduce:
a) Import the following ear (IMPORTING ALL THE JARS AS UTILITY PROJECTS )

b)
1.- Create an EAR (5 or 6 ) with module.
2.- Create a JPA and Utility projects (with default values) and add them to the EAR
3.- Export the EAR 
4.- Import the EAR (IMPORTING ALL THE JARS AS UTILITY PROJECTS )

Java build Path Problems are shown regarding to cycles detected between projects. See the image

Note that this is happening only when JPA and Utility are added together.
Comment 1 Jason Sholl CLA 2010-07-23 10:49:51 EDT 
Created attachment 175071 [details]
ear
Comment 2 Jason Sholl CLA 2010-07-23 10:53:14 EDT 
The problem occurs when the component file is setup like this:

<dependent-module archiveName="lib/MyJPA.jar" deploy-path="/" handle="module:/resource/MyJPA/MyJPA">
            <dependency-type>uses</dependency-type>
        </dependent-module>
        <dependent-module archiveName="lib/MyUtility.jar" deploy-path="/" handle="module:/resource/MyUtility/MyUtility">
            <dependency-type>uses</dependency-type>

As opposed to this:

<dependent-module archiveName="MyUtility.jar" deploy-path="/lib" handle="module:/resource/MyUtility/MyUtility">
            <dependency-type>uses</dependency-type>
        </dependent-module>
        <dependent-module archiveName="MyJPA.jar" deploy-path="/lib" handle="module:/resource/MyJPA/MyJPA">
            <dependency-type>uses</dependency-type>
        </dependent-module>

The EAR Libraries classpath container needs to handle the first case when determining whether modules are mapped to the lib folder.  The attached fix does exactly that.
Comment 3 Jason Sholl CLA 2010-07-23 10:54:05 EDT 
Created attachment 175072 [details]
patch for 3.2.1
Comment 4 Chuck Bridgham CLA 2010-07-23 11:07:03 EDT 
approved.
older workspaces (3.1.x) will create the old style - need to handle these cases
Comment 5 Jason Sholl CLA 2010-07-23 11:14:45 EDT 
    * Explain why you believe this is a stop-ship defect. Or, if it is a "hotbug" (requested by an adopter) please document it as such. 

This regression was introduced in WTP 3.2 and will impact users migrating from previous versions of WTP.   This is also reproducible for current 3.2 users importing EAR files

    * Is there a work-around? If so, why do you believe the work-around is insufficient? 

The component file needs to be updated; either by hand, or by using the deployment assembly page.  To update with the deployment assembly page the utilities need to be removed and then readded.

    * How has the fix been tested? Is there a test case attached to the bugzilla record? Has a JUnit Test been added? 

Tested with UI, and JUnits

    * Give a brief technical overview. Who has reviewed this fix? 

Make sure both the runtimePath and the archiveName fields are considered when determining whether this maps to the lib folder.

    * What is the risk associated with this fix? 

none
Comment 6 David Williams CLA 2010-07-23 14:11:48 EDT 
Sounds like a good candidate for improved unit for functional testing?
Comment 7 Carl Anderson CLA 2010-07-23 15:26:54 EDT 
Committed to HEAD for WTP 3.3. (And tentatively WTP 3.2.1, assuming PMC approval)
Comment 8 Jason Sholl CLA 2010-08-04 14:43:12 EDT 
*** Bug 320129 has been marked as a duplicate of this bug. ***