[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [wtp-dev] Facet's not asking runtime/server about libraries -intentional or error ?
|
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*?
When you create a Dynamic Web Project a WTP server/runtime is asked
about what jars it want to provide for the project in context of jst.web
and jdt.java facets.
We (JBoss) until now just returned the web related jars (servlets etc.)
no JPA, no EJB3, no extra frills.
So if you in the dynamic web project than goes and enable JPA the
runtime is never contacted to expand the list of additional jars
(which in our case would be hibernate-* and jpa/ejb3 api jars)
> 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?
At dev time you now are forced to have 50+ jars included in your project
which you might not need OR are duplicating/conflicting with what
JPA/JSF libraries you might want to use.
At deploy time it's not an issue since the classpath container is not
copied into the war.
/max
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
------------------------------------------------------------------------
_______________________________________________
wtp-dev mailing list
wtp-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/wtp-dev
