Bug 154165 - [j2ee] Provide extension point to allow other plugins to control which jars are published to the WEB-INF/lib folder on publish
Summary: [j2ee] Provide extension point to allow other plugins to control which jars a...
Status: NEW
Alias: None
Product: WTP Java EE Tools
Classification: WebTools
Component: jst.j2ee (show other bugs)
Version: 1.5   Edit
Hardware: PC Windows XP
: P3 enhancement with 5 votes (vote)
Target Milestone: ---   Edit
Assignee: Kaloyan Raev CLA
QA Contact: Chuck Bridgham CLA
URL:
Whiteboard: ProjectStructure
Keywords:
Depends on:
Blocks:
 
Reported: 2006-08-16 17:47 EDT by Robert Elliot CLA
Modified: 2011-02-02 12:20 EST (History)
11 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Robert Elliot CLA 2006-08-16 17:47:01 EDT
At present those modules specified in the "J2EE Module Dependencies" property sheet of a dynamic web project's Project properties, and their dependencies, are the only ones published to the WEB-INF/lib folder on a publish.

Plugins such as the M2Eclipse plugin:
http://m2eclipse.codehaus.org/
which provide alternative means for managing dependencies need a means to take control of which modules are published at this point.

Looking at the latest code in HEAD, the work of defining which items should be published is done by the members() method on an instance of org.eclipse.jst.j2ee.internal.deployables.J2EEFlexProjDeployable

This is instantiated by an instance of org.eclipse.jst.j2ee.internal.deployables.J2EEDeployableFactory

which is provided by extension point org.eclipse.wst.server.core.moduleFactories

It is possible that by extending the two classes I have mentioned and copying most of the logic in J2EEDeployableFactory, and finding a means of superceding the moduleFactories extension (is this possible?) the functionality can be replaced by the M2Eclipse plugin, but it would be better if the design actively expected other plugins to replace its default mechanism for resolving which modules should be published.
Comment 1 Robert Elliot CLA 2006-08-17 04:34:38 EDT
I'm thinking the easiest way would be to create a new extension point for org.eclipse.jst.j2ee and refactor J2EEDeployableFactory to try and retrieve an instance from this extension point, falling back on instantiating an instance of J2EEFlexProjDeployable if it fails to find one.

Is it appropriate for me to work on this solution?  I am not familiar with WTP and where it is currently going.
Comment 2 Chuck Bridgham CLA 2006-08-17 09:49:41 EDT
Hi Rob,

We would be very interested in your help extending the current publishing support to handle Maven build structures.

But before we start creating extension points...   We may want to step back and look at the requirements of the Maven plugin.  We probabaly have most of the metatdata needed to publish/map the folder structures for Maven.

I haven't looked in detail....   Does the plugin help map the eclipse project structure to a backend Maven directory?  and exposes ant build tasks to drive Maven builds?

If so, maybe defining a server adapter for Maven2 would be the easiest extension at this point...  (On top of 1.5.1)

Until we start developing WTP 2.0, we can't add more axtension points, but now is the time to gather requirments....

Thanks again.
Comment 3 Rob Frost CLA 2006-08-17 10:56:47 EDT
We're starting to investigate Maven2/WTP integration and would be interested in participating in any general requirements specification process on that topic; a separate bugzilla to track that process (if one doesn't already exist) would probably be useful (Philip: based on your emails re: a Maven facet, I'm guessing you would be interested as well) - I can go ahead and create one unless I find one or hear that something equivalent already exists.  

Rob: am I right that the issue in this context is deployment of Maven repository dependencies?
Comment 4 Robert Elliot CLA 2006-08-17 11:59:15 EDT
Yes.  The M2Eclipse basically creates another classpath container (I think that's the term) containing all jars referenced in the POM and their dependencies (Maven2 does transitive dependencies).  In physical terms these are located in your local Maven2 repository.

The J2EE publish correctly publishes the contents of the defined webapp folder and sticks the compiled classes into WEB-INF/classes, as you'd expect - but it doesn't know anything about this Maven2 classpath container so it ignores it.  Instead as you know it deals with the modules defined in the .component file.  You can of course add the same modules to the .component file or physically copy them into the WEB-INF/lib folder, but this is a chore, results in duplicate classpath entries and is generally a nasty workaround.

To do this properly you would need to do additional logic on the Maven2 classpath container; the Maven2 POM will define all jars needed in order to compile, including servlet.jar - it marks those that should not be included in the WEB-INF/lib folder as "compile" - and all of them are added to the Maven2 classpath container by the M2Eclipse plugin.  So some work would be needed to work out which should be published by the J2EE plugin and which should not.

I see two possibilities:

1) Explicit support for Maven2 in WTP.  This would mean that WTP was aware of POMs and calculated what to publish direct from the POM.  It would mean duplicating a lot of the work done by the M2Eclipse team (unless the M2Eclipse plugin was incorporated into Eclipse like Ant?  I believe the M2Eclipse team were interested in that at one point...).  It would also mean that if you used the M2Eclipse plugin and WTP at the same time you would get duplicate classpath entries as they both processed the POM and added entries in different places.

2) WTP decoupled from Maven2 but able to be linked together by a 3rd party plugin like M2Eclipse via appropriate extension points.  This is essentially what's going on with the JDT.  This currently works pretty well, since you can set the webapp and src folders to match those in the POM - it only fails on the publishing of Maven2 defined dependencies.
Comment 5 Philip Dodds CLA 2006-08-17 12:07:46 EDT
I have recently been doing extension work on the M2 plugin to allow it to switch from a nature to a facet.  Also as part of this work I implemented a MavenPublisher (generic publisher).

I have been focussing on deploying new facet types to servers rather than fixing up the WTP web support though that might be the next obvious step - I was able to bypass this since a maven based publisher side-steps the WTP ANT based publisher and doesn't need to construct a deployable for ANT to pick up - since Maven can create the WAR (or whatever) itself.

I have been looking next at the classpath container work - in order to try and determine if projects that are deps are already open and reference them etc.

I would certainly be interested in seeing closer interaction between the Maven plugin and the core WTP tooling.
Comment 6 Robert Elliot CLA 2006-08-17 12:17:41 EDT
Cool, sounds like it's on someone's radar anyway, which is primarily what I wanted to check.  Do you have a JIRA open on the changes to the M2Eclipse plugin you are doing?  If there's something an Eclipse novice can help out with I'd happily have a go (I have to confess I don't know the difference between a Nature and a Facet at the moment...).
Comment 7 Philip Dodds CLA 2006-08-17 12:21:14 EDT
I currently don't have a specific JIRA and I'm working with Eugene on the
M2Plugin to get the stuff back into the trunk on that plugin.  Once I get in
there I'll put an update back to this bug entry :)
Comment 8 Kaloyan Raev CLA 2008-09-01 12:01:38 EDT
Assigning to Kaloyan for evaluation