Currently we have to include all *.jar's found in JBoss AS
lib folder because we are never told JPA or JSF is enabled on the
project.
I guess my (uneducated) question is: include *where*? The classpath
container? (Though I've never seen that list of jars whittled down by
anything.) Is this a dev-time problem or deploy-time problem?
Paul Fullbright
Oracle Corp.
Eclipse Dali/Java Persistence Tools Development
paul.fullbright@xxxxxxxxxx
Max Rydahl Andersen wrote:
I'm curious as to the purpose of this
functionality. What is the intent?
that the runtime can provide only the relevant libraries. Currently we
have to include all *.jar's found in JBoss AS lib folder because we are
never told JPA or JSF is enabled on the project.
As to the why, and not understanding fully
the purpose of this request, JPA libraries are in many ways only
loosely connected with the runtime/server libraries. JPA can be
implemented on runtimes that do not support JPA implicitly, and a
separate JPA implementation may be substituted even for runtimes that
do support it. We leave it to the user at the moment to tell us
whether she intends to use the runtime libraries or she intends to
supply her own.
Sure - but you then end up with duplicate jars; the ones provided by
the runtime by default because it cannot know if it should provide it
or not and the users jar.
We did not add JPA support intrinsically to
the runtime definitions mainly because that would limit the runtimes
usable for projects with the JPA facet. Or is this tangential to the
discussion?
This is just about the facet install delegate checking if there is a
runtime associated and ask it for jars (if the user stated he wanted
the server to provide it)
A runtime that doesn't have JPA should/would just ignore the request
(that's at least my understanding on how this is supposed to work ;)
Note: in the current situation I as a user would simply have to just
delete the runtimes provide classpath container since it is doomed to
be wrong in all cases with respect to JSF/JPA ...(wrong in the sense
there can/will be duplicated jar's)
/max
Paul Fullbright
Oracle Corp.
Eclipse Dali/Java Persistence Tools Development
paul.fullbright@xxxxxxxxxx
Max Rydahl Andersen wrote:
fyi:
JSF: https://bugs.eclipse.org/bugs/show_bug.cgi?id=198999
JPA: https://bugs.eclipse.org/bugs/show_bug.cgi?id=199000
/max
My guess as to the "why" question is
that this hasn't been requested by
anyone before. Right now only jst.java and module facets use the
classpath provider facility, but the facility was designed so that any
facet could use it if it makes sense for that facet. I do not know the
design and implementation details of how JSF and JPA facets manage
their
libraries, but I would suggest opening enhancement requests (one for
JSF
and one for JPA) to continue this conversation and to figure out if
this
change makes sense for these facets.
Will do that - but just wondering what the intended behavior is; I
would expect that facet's should be encouraged to do similar things
when it comes to libraries....and the "Server provides libraries"
option for these two would indicate they at least should let the
runtime know about the changes.
In any case: Is there a way for a runtime to know which facet's are
being added to a project that it is connected to ?
e.g. if I move a project from runtime/server A to runtime/server B the
classpath should be updated - but that does not seem to happen. Should
it not ?
/max
- Konstantin
-----Original Message-----
From: wtp-dev-bounces@xxxxxxxxxxx [mailto:wtp-dev-bounces@xxxxxxxxxxx]
On Behalf Of Rob Stryker
Sent: Monday, August 06, 2007 2:57 PM
To: General discussion of project-wide or architectural issues.
Cc: jbosstools-dev@xxxxxxxxxxxxxxx
Subject: Re: [wtp-dev] Facet's not asking runtime/server about
libraries
-intentional or error ?
The type of "alert" not being given by the JSF and JPA facets are
usually called by a line similar to the one below:
ClasspathHelper.addClasspathEntries(project, fv));
The line above alerts the runtime of the facet version's new inclusion
and is borrowed from the WebFacetInstallDelegate.
I echo Max's query. Why don't the other facets such as JSF / JPA do the
same?
Max Rydahl Andersen wrote:
Hi,
I noticed today that when enabling JSF or JPA on projects neither of
them consults the server/runtime about which jars that are relevant for
it.
dynamic web and the java facet does....why not jpa and jsf ?
some runtimes could return an optimized set of jars if this were done
instead of just returning *everything* ....
I'm i missing something obvious ?
what about JPA projects that won't be dynamic web apps ?
/max
_______________________________________________
wtp-dev mailing list
wtp-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/wtp-dev
_______________________________________________
wtp-dev mailing list
wtp-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/wtp-dev
Notice: This email message, together with any attachments, may contain
information of BEA Systems, Inc., its subsidiaries and affiliated
entities, that may be confidential, proprietary, copyrighted and/or
legally privileged, and is intended solely for the use of the
individual or entity named in this message. If you are not the intended
recipient, and have received this message in error, please immediately
return this by email and then delete it.
_______________________________________________
wtp-dev mailing list
wtp-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/wtp-dev
_______________________________________________
wtp-dev mailing list
wtp-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/wtp-dev
_______________________________________________
wtp-dev mailing list
wtp-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/wtp-dev
_______________________________________________
wtp-dev mailing list
wtp-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/wtp-dev
|
