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

Bug 324111

Summary: Need better enablement behavior for WTP library providers
Product: [WebTools] WTP Java EE Tools Reporter: Paul Fullbright <paul.fullbright>
Component: jst.j2eeAssignee: Konstantin Komissarchik <konstantin>
Status: RESOLVED FIXED QA Contact: Chuck Bridgham <cbridgha>
Severity: enhancement    
Priority: P3 CC: konstantin
Version: 3.2   
Target Milestone: 3.3 M3   
Hardware: PC   
OS: Windows Vista   
Whiteboard:
Bug Depends on:    
Bug Blocks: 326960    
Attachments:
Description Flags
proposed patch
none
updated patch konstantin: iplog+

Description Paul Fullbright CLA 2010-08-31 13:15:33 EDT 
WTP library providers currently extend the base library providers by adding the "Include libraries with this application" checkbox (and the management of associated classpath attributes).

There is a use case that a facet may or may not be associated with a module facet (JPA) and thus may or may not be associated with an "application".  Thus there is the use case that a facet library provider may *conditionally* want to take advantage of this functionality.

It is desirable, in order not to duplicate code unnecessarily, that the existing implementation allow the possibility of having this setting or of not having this setting, depending on the "application-ness" of the project, that is, whether or not there is a module facet present.

In addition, it is desirable that these implementations can handle a change in the "application-ness" of the project.
Comment 1 Paul Fullbright CLA 2010-08-31 13:26:19 EDT 
Created attachment 177867 [details]
proposed patch

This patch adds enablement to the "Include libraries with this application" setting.  If the project has a module facet, the setting is enabled, and if not, it is not.  Additionally, if the project adds or removes a module facet, the setting is updated accordingly.  It should behave exactly as before if the project always has a module.

It also tweaks the metadata storage a little bit in that it distinguishes in between module dependency, non-dependency, and "does not apply".  If the setting is enabled, then the library is marked as a dependency or non-dependency, then the appropriate classpath attribute is used, but if the setting is not enabled, then all such attributes are removed from the classpath entry.

This patch also includes a fix for bug 323870.
Comment 2 Paul Fullbright CLA 2010-08-31 13:38:16 EDT 
Created attachment 177869 [details]
updated patch

Noticed small (but significant) error in WtpOsgiBundlesLibraryProviderInstallPanel
Comment 3 Paul Fullbright CLA 2010-08-31 13:52:47 EDT 
One thing I could add but did not in the patch is validation.  It's possible that an existing library provider has the "true" setting (i.e. a project previously created but with erroneous metadata), but the setting is not actually enabled for the library provider.  I'm not sure this would be a real problem in any case.
Comment 4 Konstantin Komissarchik CLA 2010-08-31 16:35:26 EDT 
I will take a look.
Comment 5 Konstantin Komissarchik CLA 2010-09-01 20:29:41 EDT 
*** Bug 323870 has been marked as a duplicate of this bug. ***
Comment 6 Konstantin Komissarchik CLA 2010-10-20 20:14:15 EDT 
Committed patch largely as is. Thanks for the contribution. The biggest change the need to remove project listener on dispose. The rest was adding contribution notes to headers, fixing unrelated warnings in these files and other cleanup.

I have not released the changes as there are other unreleased changes in these plugins.
Comment 7 Konstantin Komissarchik CLA 2010-10-21 12:14:03 EDT 
Changes have been released and should be in this week's I-build.