| Summary: | Utility jars in EAR50/lib or EAR/ not listed in in EAR Java EE Module Dependencies | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | [WebTools] WTP Java EE Tools | Reporter: | Diego Sahagun <diegosr> | ||||||
| Component: | jst.j2ee | Assignee: | Diego Sahagun <diegosr> | ||||||
| Status: | RESOLVED FIXED | QA Contact: | Chuck Bridgham <cbridgha> | ||||||
| Severity: | normal | ||||||||
| Priority: | P3 | CC: | ccc, shr31223 | ||||||
| Version: | 3.0.5 | Flags: | cbridgha:
review+
ccc: review+ |
||||||
| Target Milestone: | 3.0.5 P | ||||||||
| Hardware: | PC | ||||||||
| OS: | Windows XP | ||||||||
| Whiteboard: | |||||||||
| Attachments: |
|
||||||||
|
Description
Diego Sahagun
Note that in WTP 3.1, the Java EE Module Dependencies was replaced by the Deployment Assembly properties page. An adopter has reported this problem in WTP 305. The code to display these entries was introduced as part of bug 241335, but it looks like this code did not take into account the case where the EAR content directory is the EAR project itself (i.e. when the content directory field of the new EAR project is empty) Logic while showing Utility jars when the ear has no Content directory specified (root directory of the ear is the content dir) is not considered, also the logic to show whether if the Jar is in lib dir or not doesn't consider this case. Created attachment 198435 [details]
Fix for Util Jar population and in-lib-dir checkbox in Java EE Module Dependencies page
Diego - there were some problems with this initial patch... let me know when you have resubmitted. Created attachment 202029 [details]
Second patch proposal with a few improvements
I reviewed the code - and it looks ok, but when I tested I have more questions..... I see the jar's show up in the Ear's property page... but in the case of a lib directory set to root "", the Ear Libraries java container isn't working... maybe this is a different problem. ok my tests went ok.... I'm approving this Code committed and released to R3_0_5_patches Resolving because the code was already committed. |