Comment 1 Paul Fullbright 2009-05-16 18:38:08 EDT

Created attachment 136108 [details]
proposed patch

Added jar resolution for generic and eclipselink.
Added validation warning.
Added UI for aiding user in configuring proper jar file path for generic and eclipselink.

Comment 2 Paul Fullbright 2009-05-18 10:22:27 EDT

To sum up our current support:

- Only for web projects are jars typically provided as project resources *and*
we know the correct deployment path for them.  Java EE projects typically use
libraries provided by the EAR project, and SE projects' build structure are not
typically known.

- Furthermore, different JPA platforms resolve jars in slightly different ways.
 So determining the correct deployment path for a generic JPA project is more
inexact than for an eclipselink JPA project.

- So, for web projects, we can somewhat determine the correct deployment path
to a project resource jar and we do so.  For eclipselink, we know the correct
path.  For generic, we know it's one of two different paths.  (Note that this
does not eliminate the case that a web project may use an EAR library instead.)
 If the jar doesn't resolve via this "best guess" we fall through to the next
method.  (see below)  

- For other cases, we simply guess.  That is, we match up the jar file name
with a jar with the same file name within the project.  We trust the user to
verify the correct deployment path for her application.

- We provide a validation warning for all jar file references to tell the user
that we can't be sure of the proper deployment path for the jar file, and that
it is up to her to make sure it's proper for her environment.

- We attempt to help the user in the UI by providing that disclaimer again (we
can't be sure what the correct path is), by providing our best guess as to the
deployment path to the jar, and by allowing the user to change this path when
adding the jar.

Comment 3 Paul Fullbright 2009-05-18 17:26:37 EDT

Created attachment 136233 [details]
amended patch

amended to take into account patches applied underneath

Comment 4 Paul Fullbright 2009-05-18 17:38:56 EDT

Created attachment 136234 [details]
amended path (now without bugzilla "improvements"!!!)

bugzilla blerged last patch

Comment 5 Neil Hauge 2009-05-18 18:45:57 EDT

* Explain why you believe this is a stop-ship defect. Or, if it is a
"hotbug" (requested by an adopter) please document it as such. 
This is a major issue in our new JAR file support in that JAR file 
references are not resolved in all cases.  After some investigation
it was determined that some minor UI changes were necessary to do 
this right.

* Is there a work-around? If so, why do you believe the work-around is
insufficient? 
There is no workaround for the cases fixed in this patch.  

* How has the fix been tested? Is there a test case attached to the
bugzilla record? Has a JUnit Test been added? 
Manual testing has been performed by Paul and myself.

* Give a brief technical overview. Who has reviewed this fix? 
See comment #2. I have reviewed the fix.

* What is the risk associated with this fix? 
This change is low risk due to the isolated nature of the changes.

Comment 6 Karen Butzke 2009-05-18 20:46:23 EDT

checked this fix in to HEAD for Paul