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

Bug 300425

Summary: Move J2EE participants out of jst.j2ee
Product: [WebTools] WTP Java EE Tools Reporter: Tim deBoer <deboer>
Component: jst.j2eeAssignee: Jason Peterson <jasonpet>
Status: CLOSED FIXED QA Contact: Chuck Bridgham <cbridgha>
Severity: normal    
Priority: P3 CC: ccc, stryker
Version: unspecified   
Target Milestone: 3.2   
Hardware: PC   
OS: Windows XP   
Whiteboard:

Description Tim deBoer CLA 2010-01-21 14:18:53 EST 
Most of the existing J2EE flatten participants, e.g.:
  o.e.j.j2ee.internal.common.exportmodel.AddClasspathReferencesParticipant
  o.e.j.j2ee.internal.common.exportmodel.AddMappedOutputFoldersParticipant
  o.e.j.j2ee.internal.common.exportmodel.IgnoreJavaInSourceFolderParticipant
  o.e.j.j2ee.internal.common.exportmodel.ReplaceManifestExportParticipant
  o.e.j.j2ee.internal.common.exportmodel.SingleRootExportParticipant

(but maybe not
o.e.j.j2ee.internal.common.exportmodel.JEEHeirarchyExportParticipant)

aren't really JEE related at all. They should be useful and reusable for any WTP-based flexible project structure. Can they be moved to (e.g.) jst.common so that they can be reused without a direct dependency on J2EE tools?
Comment 1 Carl Anderson CLA 2010-01-21 16:28:38 EST 
Assigning to Jason Peterson for initial investigation.
Comment 2 Rob Stryker CLA 2010-01-22 00:18:58 EST 
Currently, replacing the manifest *does* require J2EE as it needs to check the references for acceptable j2ee references to include in the new manifest. So that one shouldn't be moved.

And currently, the single root participant also depends on the manifest participant, because even in the case of single root, for legacy purposes and for the way that j2ee sets up their projects, the manifest.mf files remain empty during development and need to be updated. So single root participant is also j2ee specific.
Comment 3 Tim deBoer CLA 2010-01-22 14:24:54 EST 
I'm guessing there's probably reusable bits here too, since anyone using the flexible project support could have the same/similar references page and update the manifest too... but one step at a time. Moving the clearly non-jee classes would be a great start.
Comment 4 Rob Stryker CLA 2010-02-05 05:34:18 EST 
I have moved the following participants out into jst.common.frameworks:
  o.e.j.j2ee.internal.common.exportmodel.AddMappedOutputFoldersParticipant
  o.e.j.j2ee.internal.common.exportmodel.IgnoreJavaInSourceFolderParticipant
  o.e.j.j2ee.internal.common.exportmodel.SingleRootExportParticipant

The following two still remain because of the significant cost associated with moving them:
  o.e.j.j2ee.internal.common.exportmodel.ReplaceManifestExportParticipant
  o.e.j.j2ee.internal.common.exportmodel.AddClasspathReferencesParticipant

ReplaceManifestExportParticipant requires significant amounts of code to be moved lower, and some are API and would require keeping the classes around extending the new version. 

AddClasspathReferencesParticipant is an extremely problematic one as the string property on the classpath references is, in fact, jee specific. It could still be possible to move it but I'd need significant feedback from those with more experience in the matter.

Closing this bug as resolved and will open a new one for each of the two, currently untargeted. 

https://bugs.eclipse.org/bugs/show_bug.cgi?id=301938
https://bugs.eclipse.org/bugs/show_bug.cgi?id=301939
Comment 5 Tim deBoer CLA 2010-02-25 23:45:28 EST 
Verified changes. Thanks!