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

Bug 312176

Summary:

Ear Module Assembly overrides/prevents custom file extensions of utility projects

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, jasonpet, neil.hauge

Version:

unspecified

Flags:

stryker: pmc_approved? (david_williams)
stryker: pmc_approved? (raghunathan.srinivasan)
stryker: pmc_approved? (naci.dai)
stryker: pmc_approved? (deboer)
neil.hauge: pmc_approved+
stryker: pmc_approved? (kaloyan)
cbridgha: review+

Target Milestone:

3.2 RC1

Hardware:

OS:

Windows Vista

Whiteboard:

PMC_approved

Attachments:

Description	Flags
Test projects	none
Adds the uri map	none

Description Fred Bricon

2010-05-09 05:18:30 EDT

Build Identifier: 20100506-2000

Hi, 

A little piece of background first : I'm trying to handle non standard Java (EE) projects with m2eclipse, starting with JBoss SAR projects (https://issues.sonatype.org/browse/MNGECLIPSE-1984). A SAR project is basically a utility project with a sar extension, and can embed jars in a lib folder.
Since it didn't work the first time and it's JBoss related, I opened a bug in JBoss Tools (https://jira.jboss.org/jira/browse/JBIDE-5691) : variable based dependencies were not exported to lib. 
Turns out that was due to a WTP bug : https://bugs.eclipse.org/bugs/show_bug.cgi?id=298735, which was solved by Rob Stryker before Helios M7.

The test project I provided for JBIDE-5691 actually works as is : the sar project is now correctly exported with its dependencies in lib.

Here comes the bug (at last): when manually changing the deployed name of the sarproject in the Ear Module Assembly page, the .sar extension is changed to .jar. I assume there's a strict sanity check in that page that prevents the use of custom extensions (.har, .par, .wsr, ...)  
Worst thing is, after the extension has been changed to .jar, dependencies are no longer exported to lib
 
So, could you 
- turn off the check for jar extension in the Ear Module Assembly page
- explain why utility projects export behave differently whether their extension is jar or something else.
 

Reproducible: Always

Comment 1 Fred Bricon

2010-05-09 05:30:46 EDT

Created attachment 167620 [details]
Test projects

1- Import the attached test projects to your workspace. The sarproject depends on the JUNIT_HOME\junit.jar which is supposed to be exported to lib.
2 - Export earproject, open earproject.ear, it contains sarproject.sar which in turn contains /lib/junit.jar as expected
3 - in the ear module assembly page, rename sarproject.sar to sar.sar and close the window
4 - reopen that same page to see the module's name is now sarproject.jar (no warning popped up to tell you there was something wrong)

Comment 2 Fred Bricon

2010-05-09 05:32:43 EDT

> Worst thing is, after the extension has been changed to .jar, dependencies are
> no longer exported to lib
Scratch that, I double checked and the jar contains the expected /lib with its jar

Comment 3 Carl Anderson

2010-05-10 09:23:03 EDT

Assigning to Rob for initial investigation.

Comment 4 Rob Stryker

2010-05-11 21:04:32 EDT

Created attachment 168068 [details]
Adds the uri map 

Reproducible: patch is to fix the new ear-specific reference operation which was missing one line.

Comment 5 Rob Stryker

2010-05-11 21:05:18 EDT

seeking approvals.

Comment 6 Chuck Bridgham

2010-05-12 10:45:17 EDT

approved

Comment 7 Rob Stryker

2010-05-12 11:18:44 EDT

Needs PMC

Comment 8 Rob Stryker

2010-05-12 12:10:04 EDT

Forgot whiteboard flag

Comment 9 Neil Hauge

2010-05-12 12:41:26 EDT

Approved assuming this is as low risk as it appears.

Comment 10 Rob Stryker

2010-05-12 12:44:13 EDT

Committed to RC1