Bug 107039 - [modulecore] We should have a resource mapping tool for flexible projects
Summary: [modulecore] We should have a resource mapping tool for flexible projects
Status: NEW
Alias: None
Product: WTP Java EE Tools
Classification: WebTools
Component: jst.j2ee (show other bugs)
Version: 1.0   Edit
Hardware: PC Windows XP
: P3 enhancement with 7 votes (vote)
Target Milestone: ---   Edit
Assignee: Chuck Bridgham CLA
QA Contact:
URL:
Whiteboard: ProjectStructure
Keywords: helpwanted
Depends on:
Blocks:
 
Reported: 2005-08-15 11:59 EDT by Naci Dai CLA
Modified: 2010-03-19 06:59 EDT (History)
9 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Naci Dai CLA 2005-08-15 11:59:12 EDT
This tools will help us click and choose files or whole folders and map them to
a destination path or file in the deployable structure.

It hsould also work across projects (i.e. map the resources in another dependant
project to a local destination - see the feature request on multiple projects /
module)

Additionally, it would be nice if existing wizards allowed us to override
default choices such as WebContent , ejbModule/META-INF, XXModule/JavaSource
with user defined source locations
Comment 1 Mauro Molinari CLA 2007-06-06 03:53:16 EDT
Hello!
I too miss features like changing the WebContent folder name and/or add multiple folders to the deploy path: I know you can achieve this result by manually editing org.eclipse.wst.common.component in ".settings" folder of your project, but a "clean" and easy way to do this using Eclipse GUI would be *very* appreciated.
Comment 2 Mauro Molinari CLA 2009-04-23 05:49:07 EDT
This can be related to bug #133359.
Comment 3 David Witherspoon CLA 2009-04-23 10:47:03 EDT
I would like to see the same model for web content sourcing as for Java source.  So similar to Project > Build Path > Java Build Path, you would have Project > Build Path > Web Content Build Path.

That dialog would have, at least, a Source tab where you can define which subdirectories contain files that should be processed, and the ability to exclude which subdirectories should not be processed.

Today, I am getting validation errors from files that are in the project, but which I don't want processed.  Having to cover all these cases through the Validation configuration dialog is cumbersome, and doesn't follow the existing model.  Web source should be treated like Java source.
Comment 4 Tom Eugelink CLA 2010-01-13 06:56:55 EST
Apparently (according to Mauro) resolving this issue makes it possible to include a dynamic web project (DWP) in the JEE path of another DWP. 

The reason for this is that a utility DWP with generic servlets and filters, containing configuration files and jsp pages to sort of unit test itself, should be included in an actual application DWP. 
This is not a problem for mere compiling, but the Eclipse Server of the actual application DWP cannot be configured to include the utility DWP project in its JEE path.
Comment 5 Mauro Molinari CLA 2010-03-19 06:59:52 EDT
Well, I just tried WTP 3.2M6 and some of the needs expressed here are now covered:

- you can choose whole folders (not files) within the same project in order to build the deployed structure of your web project; however, you can't define rules as inclusions/exclusions; the actual behaviour now is something you could achieve before by manually editing the org.eclipse.wst.common.component file in .settings folder; to do that now, use the new project property page Deployment Assembly

- rules like inclusions/exclusions can however be set on ANY folder now! If you have a Resource Filter like the following: "[String matcher] exclude *abc.jsp", defined on your WebContent folder, if this contains a file named "myabc.jsp", this file is neither shown in Project Explorer, nor published to the server!

- the WebContent folder name can be changed with right-click, rename; the renaming is reflected in the Deployment Assembly page

- I can't really understand Naci's request for "choicing XXModule/JavaSource with user defined source locations": isn't the default Java buildpath configuration page enough? Are you talking about inter-project source dependencies, so you would like to define a subpart of a project to be included in the JAR deployed to WEB-INF/lib? If so, I think this can't be done yet

- with 3.2M6 you can also choose a Dynamic Web Project as a dependency: if you have DWP A that depends on DWP B, using the Deployment Assembly page you can also choose DWP B on DWP A references; DWP B will be deployed as a WAR in DWP A WEB-INF/lib folder; the old JEE Module Dependency page didn't let you do that; other non-Dynamic Web Projects are still deployed as JAR files in WEB-INF/lib as before

However, the latter mentioned technique regarding inter-project dependencies is about Java build path only. That is:

- in DWP A Deployment Assembly page you can't select a folder contained in project B for web resources deployment, even if project B is a Dynamic Web Project
- even if DWP B is deployed as a WAR in WEB-INF/lib of DWP A, when DWP A is published to your server (I use Tomcat), the server can't serve jsp pages or other static non-Java resources contained in DWP A

In order to map non-Java resources from other projects, however, I think you can use linked files and folders, which are much more powerful now thanks to Eclipse 3.6 enhancements regarding project-specific variables, relative paths in variables, virtual folders and resource filters (see Bug #284148).

So, by creating appropriate virtual folders, links and filters in DWP A to resources in DWP B, then adding the appropriate mappings in the Deployment Assembly page, you can achieve the desired result. I just did a simple test and it works! However I'm still experimenting.

So, to conclude: the only thing I could argue is that a full "Web Content Build Path" feature with inter-project dependency support, as in David's comment #3, would probably be much more simple and user-friendly to use to prepare a complex web application configuration. However, with an only doubt about Naci's request about (inter-project?) Java source locations, I think that the current tools provided by WTP 3.2 and Eclipse 3.6 can let you do all the things requested here.

Thank you very much to the WTP and Eclipse team for the new enhancements!! :-)