Pong! ;-) Let's focus on "shared" and current release process now. After release is out we start the initiation of the new "commons-jsf" lib and continue the discussion. Ok?
Manfred On 3/10/06, John Fallows <[EMAIL PROTECTED]> wrote: > Ping? > > > On 3/2/06, John Fallows <[EMAIL PROTECTED]> wrote: > > > > On 3/1/06, Manfred Geiler <[EMAIL PROTECTED] > wrote: > > > > > > > > > > > On 3/1/06, John Fallows <[EMAIL PROTECTED]> wrote: > > > > > We need to define the meaning of "with more caution". > > > > Terms for future commons utils and helpers: > > > > * stable API > > > > > > +1. :-) > > > > > > > > > * downward compatibility within major version numbers > > > > > > > > +1. > > > > Backwards compatible at runtime, compile time or both? > > > > > > > > > * separation between API and Impl (to achieve the latter two) > > > > > > > > +1. > > > > Separated by different packages, JARs, or both? > > > > > > > * not MyFaces specific > > > > > > +1. These APIs might become candidates for inclusion in future versions > of the JSF specification. > > > > Would the compilation dependency graph look something like this? > > > > [myfaces-commons-api] --depends-on--> [jsf-api] > > [myfaces-commons-impl] --depends-on--> [myfaces-commons-api, jsf-api] > > [myfaces-tomahawk] --depends-on--> [myfaces-commons-api, jsf-api] > > > > Would the following compilation dependency be avoided? > > > > [myfaces-tomahawk] --depends-on--> [myfaces-commons-impl] > > > > > > > * make sense for all or many JSF component authors and/or app developers > > > > > > > > +1. > > > > > > > More? > > > > > > > > Kind Regards, > > John Fallows. > > -- > > http://apress.com/book/bookDisplay.html?bID=10044 > > Author: Pro JSF and Ajax: Building Rich Internet Components, Apress > > > > -- > http://apress.com/book/bookDisplay.html?bID=10044 > Author: Pro JSF and Ajax: Building Rich Internet Components, Apress
