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 ComponentsI'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?
What about the shared classes. We could release them together with the implementation, I think.
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)
To cover all of these scenarios, we must at least release every part in one single jar. For convenience, we could additionally provide simple all-in-one jars. But keep in mind that the JSR-127 API always must be separated because of the javax.* namespace that is handled specially by container classloaders. For Tomcat JSR-127 API should be in /common/lib for instance.
Thoughts?
Manfred
Martin Cooper schrieb: > On Mon, 14 Mar 2005, Abrams, Howard A wrote: > >> No, I am talking about the way the apache project is structured and >> releases scheduled: >> >> I think it makes sense for the development goals of the components to be >> separate from the development goals of the implementation. After all, >> the components are useful without the MyFaces implementation, and the >> implementation is useful without the components. I would expect that >> once the implementation passes the TCK, there will be only the >> occasional bug fix until work on JSF 1.2 starts. In contrast, I would >> expect that there will be many updates of the components between the TCK >> and JSF 1.2. And once work on JSF 1.2 is in progress, I would expect >> that it will need to release more often than the components until it >> passes the TCK. >> >> If the component and implementation will have such different schedules >> and goals, why tie their releases together? What I am proposing is that >> we split the MyFaces apache project into an implementation subproject >> and a components subproject; each would have their own deliverables. For >> convenience, when we release the components we could also create a >> distribution that packaged the latest implementation along with the >> latest components, and vice-versa. > > > This makes a lot of sense to me. We've done something similar in Struts, > where we separated out the core and have separate subprojects for > taglibs, Tiles, etc. > > I would point out, though, that it's going to be much, much easier to do > this kind of thing once you're using Subversion instead of CVS. ;-) > > -- > Martin Cooper > > >>> -----Original Message----- >>> From: Sean Schofield [mailto:[EMAIL PROTECTED] >>> Sent: Monday, March 14, 2005 10:54 AM >>> To: MyFaces Development >>> Subject: Re: Components subproject (was RE: [VOTE] Two tree controls) >>> >>> Howard, >>> >>> There is already an ant build script that can build and release the >>> JSF implementation separate from the custom components. So it is >>> already possible to use the JSF Implementation without the components. >>> Is this what you are after or are you looking for something more? >>> >>> sean >>> >>> >>> On Mon, 14 Mar 2005 13:50:16 -0500, Abrams, Howard A >>> <[EMAIL PROTECTED]> wrote: >>> >>>> I'm not so worried about 1.0.9, my comment was directed more towards >> >> the >> >>>> release after this one. Since there are many people that will want >> >> to >> >>>> use an Apache licensed certified JSF Implementation, but may not >> >> have >> >>>> the need for the MyFaces components, I thought I'd bring up the idea >> >> of >> >>>> making the components a subproject. >>>> >>>> Anyone have any thoughts? >>>> >>>>> -----Original Message----- >>>>> From: Sean Schofield [mailto:[EMAIL PROTECTED] >>>>> Sent: Monday, March 14, 2005 10:45 AM >>>>> To: MyFaces Development >>>>> Subject: Re: [VOTE] Two tree controls >>>>> >>>>> Howard, >>>>> >>>>> I think we have resolved this issue for now. I agree with you >> >> that >> >>>>> this type of disagreement should not impact the next release. >> >> Since >> >>>>> we can't seem to find a way out of the tree vs tree2 discussion >> >> both >> >>>>> will be included in the next release (and all forseeable future >>>>> releases.) So there will be no scheduling impact on the next >> >> release >> >>>>> now that this has been resolved. >>>>> >>>>> sean >>>>> >>>>> >>>>> On Mon, 14 Mar 2005 12:56:09 -0500, Abrams, Howard A >>>>> <[EMAIL PROTECTED]> wrote: >>>>> >>>>>> +0 >>>>>> >>>>>> I suggest that the MyFaces custom components be moved to a >>>> >>>> subproject. A >>>> >>>>>> debate such as "Tree vs. Tree2" shouldn't hold up a release of >> >> the >> >>>> JSF >>>> >>>>>> implementation and API. >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Sean Schofield [mailto:[EMAIL PROTECTED] >>>>>>> Sent: Monday, March 14, 2005 5:56 AM >>>>>>> To: MyFaces Development >>>>>>> Subject: [VOTE] Two tree controls >>>>>>> >>>>>>> I propose a vote to end the tree vs tree2 controversey. Since >> >> it >> >>>>>>> seems that Oliver and I have reached an impasse (to put it >>>> >>>> mildly), I >>>> >>>>>>> move that we have two tree controls: tree and tree2 and let >> >> the >> >>>> user >>>> >>>>>>> decide which is best for them. >>>>>>> >>>>>>> While I think it is unfortunate that we cannot agree on a >> >> single >> >>>> new >>>> >>>>>>> tree control together this is probably the best course of >> >> action >> >>>> for >>>> >>>>>>> the sake of the team. So I'd like a vote on this so I can >> >> know >> >>>> for >>>> >>>>>>> sure how to go forward. >>>>>>> >>>>>>> I will start the voting ... +1 for me >>>>>>> >>>>>>> ps. I know we don't like voting but I think its important to >> >> have >> >>>>>>> voting for big decisions like this. Oliver and I have both >> >> put a >> >>>> lot >>>> >>>>>>> of time into the respective tree controls so its only fair >> >> that we >> >>>> ask >>>> >>>>>>> the group for direction on how to proceed. >>>>>>> >>>>>> >>>>>> >>>>> >>>> >>>> >>> >> >> >> > >
