Re: [wtp-dev] Facet's not asking runtime/server about libraries -intenti

[Paul Fullbright <paul.fullbright@xxxxxxxxxx>]

I'm curious as to the purpose of this functionality.  What is the intent?

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.

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?

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