Hi! > ---- Mario Ivankovits <[EMAIL PROTECTED]> 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
