Craig, Thanks for your valuable comments. --> inline
Craig McClanahan schrieb:
Inline.
On Tue, 15 Mar 2005 09:58:37 +0100, Manfred Geiler <[EMAIL PROTECTED]> wrote:
Hi all, Thanks for your suggestions and hints about possible project structures. I fully aggree that there will be different development goals for the implementation and component classes. Unfortunately things are more difficult than that. So, I would really appreciate more feedback or hints about this.
The MyFaces main parts are: - MyFaces API in /src/jsfapi (JSR-127 javax.faces.* classes) - MyFaces Share in /src/share (Utilities and common base classes) - MyFaces Impl in /src/myfaces (The implementation) - MyFaces Components in /src/components (Extended and custom components)
The dependencies are:
JSR-127 API (not necessarily the MyFaces API classes) | | MyFaces shared classes | | | | MyFaces Impl MyFaces Components
I'm sure now about the separation of implementation and components. As Martin pointed out they will have different schedules and goals.
But what about the other parts. Should JSR-127 API be also separated? Advantage: We could synchronize release numbers more clearly with the actually implemented Spec version. For instance myfaces-api-1.1.x for Spec 1.1 and myfaces-api-1.2.x for coming Spec 1.2 How do other projects handle this. Ok, there is no JSR Spec for Struts. But what about the Servlet and JSP API in Tomcat? Anyone who can give us valuable hints?
My advice would be to keep all the implementation stuff (the api classes and the MyFaces specific implementation) as a single project, since they are all tied tightly together.
In the Tomcat world, they keep the major version number in sync with the servlet spec version (Tomcat 3.x == Servlet 2.2, Tomcat 4.x == Servlet 2.3, Tomcat 5.x == Servlet 2.4), but reserve minor version numbers for functional enhancements in between. That seems to work pretty well -- even when they did a fairly major refactoring from Tomcat 5.0 to Tomcat 5.5 that still supported the same major version.
For now, I'd go with your idea above (aim MyFaces 1.1 at implementing JSF 1.1, and aim MyFaces 1.2 at implementing JSF 1.2), then decide about switching to 2.x numbering when JSF 2.0 comes out later. That's likely to be a while, so it would not be surprising to see more 1.x minor upgrades in between.
What about the shared classes. We could release them together with the implementation, I think.
Do the components depend on them too? That would tie the components to only working with the MyFaces implementation, which would be bad :-(.
Yes and no. The components depend on the shared classes but they are not tied to the MyFaces implementation because of that (see dependency tree above). The shared classes consist of Utilities and Common base classes that themselves only depend on JSR-127 API. Therefore it is possible to use the MyFaces components with any other JSF impl as long as you package it together with the MyFaces shared classes.
On larger scale projects, you typically see this situation handled as follows:
* Single source code base
* Distributed with *both* projects, in a separate JAR file (probably with its own version number if there are any version incompatibilities).
What about packaging? These are possible scenarios: - api + shared + impl + comp (people who need all out of the box) - shared + impl + comp (people who want to use the RI API for some reason) - shared + comp (people who use the RI API and RI Impl for some reason) - api + shared + impl (people who do not want to use custom components)
A couple of notes on packaging:
* Shipping the API and IMPL classes in two jars, instead of one, will be friendlier to people (like me :-) who have build.xml scripts set up for the JSF RI, which is shipped in two JARs. All I need to do is set both build properties to use MyFaces instead.
* If you ship COMP and SHARED in a single jar, you get the ability to use it with other implementations, which is good -- but you'd get that same benefit from shipping COMP and SHARED in separate jars and just saying you need both of them.
In either case, you're likely to have other dependency jars that are required as well -- treating SHARED as an external dependency jar might be the simplest approach.
Sounds reasonable. So, I have the following proposal:
MyFaces is split into three projects: 1. The "Apache MyFaces" project This is the umbrella for everything related to MyFaces.
2. The "Apache MyFaces Implementation" (sub)-project This is the Main Project consisting of three parts: - MyFaces JSR-127 API - MyFaces Shared classes - MyFaces Implementation
All three parts get released as separate jars, but have the same release number which is in turn in sync with the JSF spec version. So, first official release number we should target at after having passed TCK is 1.1.0
All three parts are released in separate jars called:
myfaces-api-1.1.0.jar
myfaces-shared-1.1.0.jar
myfaces-impl-1.1.0.jar
3. The "Apache MyFaces Components" sub-project
The MyFaces extended and custom components.
The release numbering is independent from "Apache MyFaces Implementation", but should also be in sync with the JSF Spec. So, I suggest 1.x.y for JSF 1.1 compatible components, 2.x.y for JSF 1.2 and so on. The x is incremented on every new component/feature. y is incremented on maintenance.
Since the components depend on the myfaces shared classes from the Implementation, there is of course a relation between impl version and components version of the kind "Apache MyFaces Components 2.3.4" is compatible with "Apache MyFaces Implementation 1.2.7".
We release the components
- as a separate jar called myfaces-components-1.x.y (depending on a specific myfaces-shared-x.x.x.jar)
- as an all-in-one jar called myfaces-full-1.x.y (containing shared, impl and components - but not the API!)
IMHO, there is no need for a components+shared jar as longs as we document the dependency clearly. Quite the contrary, every additional jar would make things worse and confuse people that are too lazy to read docs (like me) and just copy every jar they find into their lib dir. Ok, forget about that. Of course I would never do things like that! ;-)
Thoughts?
Manfred
