Re: [result][vote] start up the MyFaces Commons project

[Andrew Robinson <an...@gmail.com>]

To lessen confusion, would someone want to start a wiki page with a
summary of what the commons would look like. That way the emails
should be (hopefully) easier to read. Then this thread can be used to
refine and discuss the wiki contents.

-Andrew

On Nov 30, 2007 12:34 AM, Mario Ivankovits <ma...@ops.co.at> wrote:
> Hi!
> > ---- Mario Ivankovits <ma...@ops.co.at> schrieb:
> >
> >> I don't see any reason why we shoulnd't being able to provide a stable
> >> api even for shared.
> >>
> >
> > I have to strongly disagree here.
> >
> I know what all this means, but, this statement, and what Manfred wrote
> means, that MyFaces is not allowed to depend on jsfcommons and is not
> allowed to use all the nice utility methods in there.
>
> I still think it should be possible to provide a library with a stable
> api over time, new methods can be added without breaking backward
> compatibility. See commons-lang.
> IF JSF changes in a way that makes this no longer possible, we could
> create a new package structure for the new API.
> Something like org.apache.myfaces.jsfcommons ->
> org.apache.myfaces.jsfcommons2 etc.
>
> Dropping such a jar into the J2EE Container does not necessarily break
> anything.
>
> BTW: I think all this J2EE stuff with providing implementations is
> broken, at least, it shows a major caveat in Java where a library is not
> able to define on which other library-version it depends on. A shame
> that this has not been fixed for a long time ... Something like this is
> planned in Java 1.7 I think, no?
>
>
> In any case, I think having a subject-separated project structure in
> jsfcommons is better than the api/impl way. However, if we split
> tomahawk into pieces and providing a jsfcommons for just the utils thing
> I am fine too. Yep, maybe this is the way how tomahawk should evolve and
> it frees jsfcommons from the discussion if converters/validators should
> be put in there - the answer then is simply "NO, put it into
> tomahawk-converters". In the sense of "equality" we should find an all
> new name for this project which has nothing to do with commons,
> tomahawk, trinidad etc.
>
> Ciao,
> Mario
>
>

Re: [result][vote] start up the MyFaces Commons project

[Matthias Wessendorf <ma...@apache.org>]

let me try to get the wiki page done tomorrow.
(at least the starting point)

On Dec 3, 2007 8:48 PM, Andrew Robinson <an...@gmail.com> wrote:
> To lessen confusion, would someone want to start a wiki page with a
> summary of what the commons would look like. That way the emails
> should be (hopefully) easier to read. Then this thread can be used to
> refine and discuss the wiki contents.
>
> -Andrew
>
>
> On Nov 30, 2007 12:34 AM, Mario Ivankovits <ma...@ops.co.at> wrote:
> > Hi!
> > > ---- Mario Ivankovits <ma...@ops.co.at> schrieb:
> > >
> > >> I don't see any reason why we shoulnd't being able to provide a stable
> > >> api even for shared.
> > >>
> > >
> > > I have to strongly disagree here.
> > >
> > I know what all this means, but, this statement, and what Manfred wrote
> > means, that MyFaces is not allowed to depend on jsfcommons and is not
> > allowed to use all the nice utility methods in there.
> >
> > I still think it should be possible to provide a library with a stable
> > api over time, new methods can be added without breaking backward
> > compatibility. See commons-lang.
> > IF JSF changes in a way that makes this no longer possible, we could
> > create a new package structure for the new API.
> > Something like org.apache.myfaces.jsfcommons ->
> > org.apache.myfaces.jsfcommons2 etc.
> >
> > Dropping such a jar into the J2EE Container does not necessarily break
> > anything.
> >
> > BTW: I think all this J2EE stuff with providing implementations is
> > broken, at least, it shows a major caveat in Java where a library is not
> > able to define on which other library-version it depends on. A shame
> > that this has not been fixed for a long time ... Something like this is
> > planned in Java 1.7 I think, no?
> >
> >
> > In any case, I think having a subject-separated project structure in
> > jsfcommons is better than the api/impl way. However, if we split
> > tomahawk into pieces and providing a jsfcommons for just the utils thing
> > I am fine too. Yep, maybe this is the way how tomahawk should evolve and
> > it frees jsfcommons from the discussion if converters/validators should
> > be put in there - the answer then is simply "NO, put it into
> > tomahawk-converters". In the sense of "equality" we should find an all
> > new name for this project which has nothing to do with commons,
> > tomahawk, trinidad etc.
> >
> > Ciao,
> > Mario
> >
> >
>



-- 
Matthias Wessendorf

further stuff:
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
mail: matzew-at-apache-dot-org