myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Matthias Wessendorf" <mat...@apache.org>
Subject Re: [result][vote] start up the MyFaces Commons project
Date Mon, 03 Dec 2007 21:14:11 GMT
let me try to get the wiki page done tomorrow.
(at least the starting point)

On Dec 3, 2007 8:48 PM, Andrew Robinson <andrew.rw.robinson@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 <mario@ops.co.at> wrote:
> > Hi!
> > > ---- Mario Ivankovits <mario@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

Mime
View raw message