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
:-(.

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.

Craig

> 
> 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.
>  >>>>>>>
>  >>>>>>
>  >>>>>>
>  >>>>>
>  >>>>
>  >>>>
>  >>>
>  >>
>  >>
>  >>
>  >
>  >
>

Reply via email to