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

Bug 301601

Summary: SingleRoot participant needs to filter files
Product: [WebTools] WTP Common Tools Reporter: Jason Peterson <jasonpet>
Component: wst.commonAssignee: Rob Stryker <stryker>
Status: RESOLVED FIXED QA Contact: Konstantin Komissarchik <konstantin>
Severity: normal    
Priority: P3 CC: stryker
Version: unspecified   
Target Milestone: ---   
Hardware: PC   
OS: Windows XP   
Whiteboard:
Attachments:
Description Flags
Preliminary patch, moves to jst.common.frameworks none

Description Jason Peterson CLA 2010-02-02 16:33:22 EST 
The export operations currently give users the ability to determine if source files are included or not.  For Java EE projects, this means .java files, but may mean different things for non Java EE projects.  In the near future users will have more control of files/directories to exclude.  Currently, the FlatVirtualComponent allows users to filter files by creating a participant that overrides shouldAddExportableFile().  One called FilterResourceParticipant already exists for this exact purpose.  The problem is that this filter is ignored when SingleRootExportParticipant is used.  This breaks the export operation and always includes source (.java files) whenever the outputcontainer is set to the Java source container.  

Either the singleroot participant needs to honor other participants that override shouldAddExportableFile() or have some other means to filter the files.  Maybe have a constructor that takes a list of file suffix's as a pararmeter that could be used to filter based on.
Comment 1 Rob Stryker CLA 2010-02-03 04:01:40 EST 
I'm not going to lie, but I find this single root participant scenerio more and more odd ;) 

You want to be able to say "only draw from the files HERE, and do it very efficiently!" but then you also want to go through and hand-massage the results, replace the manifest, filter some results, etc, for the most part completely undoing the benefits of your single-root optimizations. 

I don't even imagine export can benefit much from using the single-root. From my understanding, single-root tends to benefit the server adapters primarily so that they can manually load things directly from an output folder where classes are already compiled and everything is already in its proper structure before you have to do anything. The server adapter then can reach directly into that output folder of classes, jars, etc, and just understand everything immediately. 

It seems that in export, this wouldn't even be a concern as you're exporting directly to one zipped file. Single-root or not, you're exporting, and the server adapter will not see your output folder full of classes and jars, but rather it would see one zipped file somewhere.
Comment 2 Rob Stryker CLA 2010-02-03 04:02:02 EST 
I'm also struggling mightily to code this in a way that doesn't make the entire code base ridiculous
Comment 3 Rob Stryker CLA 2010-02-03 04:38:48 EST 
Created attachment 158014 [details]
Preliminary patch, moves to jst.common.frameworks

This is a preliminary patch that attempts to do all of the stuff that needs to be done. It both moves the code lower into jst.common.frameworks, allows for a filter, removes a dependency on manifest participant while still allowing some way to provide the same via a callback handler, etc etc etc. 

Ugh... tough work ;)
Comment 4 Rob Stryker CLA 2010-02-05 06:23:29 EST 
SingleRootExportParticipant can now take a SingleRootParticipantCallback which can provide a list of delegates which must also take effect. 

In this case, the participant callback that jee should use is the JavaEESingleRootCallback.  This JavaEESingleRootCallback constructor allows you to pass in an array of Strings with suffixes to filter. 

Committed to m6