On 2/21/06, John Fallows <[EMAIL PROTECTED]> wrote: > Folks, > > There seems to be increasing discussion lately regarding MyFaces Commons and > how it relates to both MyFaces Core and MyFaces Tomahawk. > > Adding Tobago and ADF Faces to the discussion makes it even more critical > that we come up with a useful way to share reusable code between the various > projects. So, I thought it might be helpful to the current discussion if I > shared my thoughts about this for the future. > > Right now, we tend to think of MyFaces Commons as a dumping ground for > common utility code that is reused between the Core and Tomahawk, and AFAIK, > none of this code has been vetted for its suitability as a consistently > backwards-compatible public API. > > In future, we'll need to provide common code to all component libraries > developed as part of the MyFaces effort (and outside MyFaces too), and due > to the independent upgrade requirements for individual component libraries, > that common codebase will need to provide a guarantee of backwards > compatiblilty. > > One example of such shared code for the future might be a common strategy > for the FileUpload feature. It would be a real shame if all of the internal > implementation code for this FileUpload feature became part of a public API > just because it was added to Commons. So, I propose a split in Commons > between public API and private implementation. In fact, I think it > shouldn't be called Commons either. :-) > > [groupId = org.apache.myfaces] > myfaces-api-x.y.z.jar > myfaces-impl-x.y.z.jar
My definite -1 on naming anything other than the current MyFaces JSF API and Impl as "myfaces-api-*" or "myfaces-impl-*" Not only this would totally confuse our users, having equally named artifacts in Maven that not only differ in version and/or features/bugs but totally differ in their contents sounds more than unreasonable to me. > Dependent projects should be free to create compile-time dependencies > against myfaces-api, but not myfaces-impl. > > The code currently in Commons will need an overhaul to prepare it for such > backwards compatibility strictness. We should take a hard look at the > codebase in there and decide how best to trim it to a managable size that > can realisticly be kept compatible across releases. > > Now, this raises the point about the naming for the current API and > implementation for the specification. How about the following? > > [groupId = org.apache.myfaces] > jsf-api-a.b.c.jar > jsf-impl-a.b.c.jar -1 on naming any of our libs identical to any other publicly available lib. Ok, they would differ in Maven groupId, but AFAICT most of our end users will not use Maven at all. Anyway, having equally named libs from different sources sounds very dangerous to me. -0.9 on renaming our current api and impl libs at all > I think this makes two things very clear. > > MyFaces spec api and impl do not contain any non-spec related code (i.e. no > non-portable "extensions" to the spec) > > MyFaces spec api and impl are equivalents of the reference api and impl from > Sun > In addition, we might need to break the dependency between > jsf-impl-x.y.z.jar and myfaces-api-x.y.z.jar/my-faces-impl.x.y.z.jar above. > This may still involve "inlining" commons into the jsf-impl JAR to avoid > potential problems with JavaEE containers vs. webapp ClassLoaders. +1 on "inlining" commons into the jsf-impl JAR for the above reasons I will do some additional experiments on this today. Stay tuned... > It certainly feels better to have a directed dependency from the MyFaces API > / Impl -> standard JSF API / Impl rather than the reverse. :-) Don't know what you mean by that. > Btw, do JavaEE containers, e.g. Tomcat, properly isolate the Webapp > ClassLoader from the container's own ClassLoader, preventing visibility of > jsf-impl and only exposing jsf-api to the Webapp ClassLoader? This should > be perfectly possible using appropriate ClassLoader parentage, but I'm not > certain if it is commonly done or mentioned in the JavaEE specification. > > For Tomahawk, Tobago and ADF Faces, we can have the following. > > [groupId = org.apache.myfaces] > tomahawk-api-d.e.f.jar > tomahawk-impl-d.e.f.jar > > tobago-api-g.h.i.jar > tobago-impl-g.h.i.jar > > adf-faces-api-j.k.l.jar* > adf-faces-impl-j.k.l.jar* > > where each has a compile time dependeny on both jsf-api and myfaces-api but > only a runtime dependency on the internal implementation details of jsf-impl > and myfaces-impl. > > *adf-faces to be renamed during incubation. > > When any of these projects need to be upgraded, and it depends on a newer > version of myfaces-api / myfaces-impl, the upgrade can proceed with > confidence because the newer version guarantees backwards compatibilty at > compile-time for myfaces-api and at runtime for myfaces-impl. > > Thoughts? I have the feeling of a slight overkill here. Splitting everything into api and impl makes things unnecessarily complicated. Making it clear in javadoc what is subject to change and what api people can rely on shoud be enough IMHO. What I could do secondary to the planned refactoring of commons classes (package move from o.a.myfaces .* --> o.a.myfaces.commons.*) is to try splitting commons classes into "MyFaces specific helpers" and "Reasonable public interest goodies". The former would be those classes that are subject to change on most releases and could be moved into their own package "o.a.myfaces.commons.private.*" or better, but perhaps confusing "o.a.myfaces.commons.impl.*". The latter would be those "API like" utils and base classes that people may rely on in their own custom components. WDYT? Manfred