I agree with this, so long as the circular dependencies for compile time are not used. I also agree with many of tue others, the MyFaces API should be available at compile time and be BINARY compatible with the RI, and even though the impl only need be present at runtime, I don't think anyone expects to be able to run, say, a mojarra impl with a MyFaces API.
On Feb 11, 2011, at 11:48 AM, Mark Struberg <strub...@yahoo.de> wrote: > Imo myfaces-api is pretty much bound to myfaces-impl. Like el-api is bound to > the el-impl most of the times. (sadly) > > LieGrue, > strub > > --- On Fri, 2/11/11, David Jencks <david_jen...@yahoo.com> wrote: > >> From: David Jencks <david_jen...@yahoo.com> >> Subject: Re: Issue 2995 - Leo please read >> To: "MyFaces Development" <dev@myfaces.apache.org>, "Leonardo Uribe" >> <lu4...@gmail.com> >> Date: Friday, February 11, 2011, 6:23 PM >> >> On Feb 10, 2011, at 9:39 PM, Leonardo Uribe wrote: >> >>> Hi David >>> >>> There are some points to take into consideration for >> myfaces-api jar >>> >>> 1. It is preferred that myfaces-api have the less >> amount of "compile" or "runtime" dependencies to work. Right >> now, myfaces 2.0.x api and impl only require: >>> >>> commons-beanutils-1.8.3.jar >>> commons-codec-1.4.jar >>> commons-collections-3.2.1.jar >>> commons-digester-1.8.jar >>> commons-logging-1.1.1.jar (transitive from commons >> packages) >>> jstl-1.2.jar >>> >>> The idea is simple: few dependencies means few things >> to think about when someone configures its custom webapp. >>> >>> The patch provided adds a new dependency, so >> additionally with "myfaces-api" and "myfaces-impl" it is >> required to include "myfaces-api-spi" in every webapp that >> uses future versions myfaces. Of course,a new module is >> required because the code cannot be on myfaces-impl >> (circular dependency). >> >> I would think that anyone who is concerned with how many >> myfaces jars they use would use the osgi bundle which is >> only one artifact rather than 2 (current) or 3 (proposed). >> >>> >>> 2. In some situations, a myfaces-api jar is used to >> only provide classes under javax.faces package, but it is >> not wanted to include classes under org.apache.myfaces >> package in that jar, to prevent users to import >> org.apache.myfaces packages and classes when they don't >> want. >>> >>> 3. It is wanted to keep "coherence" with the javadoc >> provided by the spec. That means, myfaces default behavior >> should do what the spec javadoc says, but it is not wanted >> web applications that runs only with myfaces and not with >> other jsf implementations, because after all that is the >> intention of take a lot of time and effort to do a >> specification. >>> >>> The patch proposed could be seen as an "unofficial" >> extension for FactoryFinder. I'm not saying we can't do >> that, just we need to take our time before do some change. >> >> IMO the jsf spec and reference implementation make the >> assumption that there is one classloader per war, probably >> because all existing containers do that, despite the >> explicit statememts in the ee spec that this is not >> required. So to me this is a spec defect. I >> don't think there's any chance of fixing this in the spec >> but it is possible to fix it with this extension. >> >>> >>> Now, let's review the previous response: >>> >>> DJ>> This is NOT for osgi. The ee >> classloading model does not require a separate >>> DJ>> classloader for each war in an ear, whereas >> currently the myfaces api implementation >>> DJ>> assumes that web apps can be distinguished >> by the thread context classloader. >>> >>> But this new feature is for geronimo, right? It is >> true the ee classloading model does not require a separate >> classloader ( well, is questionable, because only if >> something is not explicit mentioned does not means the >> opposite is true ) , but the truth is "almost" every >> ee container uses a different classloader for each war in an >> ear (maybe all). If that so, why bother us to put this stuff >> on myfaces api if this will be used by geronimo? if other >> container in the future wants to use this feature, I think >> it is a good bet they surely will use myfaces osgi bundle. >> >> This is not an osgi specific feature. Are you >> suggesting that geronimo provide its own FacesFactory >> implementation and pack up our own myfaces osgi bundle >> including this code? IMO if myfaces includes this code >> at all it should not be in a specifically osgi related >> form. >>> >>> Other option i can imagine is do something using java >> reflection api. In this way, the code could live in >> myfaces-impl (where all our spi interfaces are), but I have >> not dedicated too much time about it. >> >> I can write this so the spi-api is optional and is only >> used if the spi-api interface is available, but this would >> be significantly more complicated which is why I didn't >> suggest it at first. Let me know if you'd like to see >> this. >> I also think that putting it in myfaces impl is not a good >> idea because theoretically myfaces-api can be used with >> another jsf implementation. >> >> thanks >> david jencks >> >>> >>> regards, >>> >>> Leonardo Uribe >> >> > > >
