Hi, my +1 to Bernds suggestion of having separated commons packages.
And to move the discussion back to this thread: If we want to include converters/validators and components into the new "common", than we need to have new TLDs with new prefixes here. Regards, Volker 2006/11/25, Bernd Bohmann <[EMAIL PROTECTED]>:
Hello, I like the proprosal of a commons package. But I would prefer more separated packages(artifacts) org.apache.myfaces.commons.util org.apache.myfaces.commons.fileupload org.apache.myfaces.commons.security org.apache.myfaces.commons.security.tiger org.apache.myfaces.commons.validator org.apache.myfaces.commons.convert org.apache.myfaces.commons.component . . I don't like commons-jsf. In my opinion myfaces is jsf we don't need a jsf in the name. We should discuss the version scheme of the commons artifacts, too. Maybe we need a Minor.major.fixpack.point scheme and the Minor.major version is equivalent to the jsf version Regards Bernd Cagatay Civici wrote: > Yes, having separate commons packages sounds good. > > Cagatay > > On 11/24/06, Martin Marinschek <[EMAIL PROTECTED]> wrote: >> >> +1 for starting off with commons >> >> +1 for your first naming suggestion >> >> regards, >> >> Martin >> >> On 11/24/06, Manfred Geiler <[EMAIL PROTECTED]> wrote: >> > Important hint, thanks! >> > My feeling is, we should have only one jsf-commons project and resolve >> > version issues in the way springframework does support both >> > hibernate2.1 and hibernate3. They have separate packages and only >> > optional maven dependencies. >> > >> > So we could start like this: >> > >> > org.apache.myfaces.commons-jsf >> > org.apache.myfaces.commons-jsf-1-1 >> > org.apache.myfaces.commons-jsf-1-2 >> > >> > and have >> > org.apache.myfaces.commons-jsf-2-0 >> > and so on >> > later. >> > >> > Or alternatively: >> > org.apache.myfaces.commons-jsf >> > org.apache.myfaces.commons-jsf.jsf-1-1 >> > org.apache.myfaces.commons-jsf.jsf-1-2 >> > >> > Or: >> > org.apache.myfaces.commons-jsf.webapp >> > org.apache.myfaces.commons-jsf.webapp.jsf-1-1 >> > org.apache.myfaces.commons-jsf.webapp.jsf-1-2 >> > org.apache.myfaces.commons-jsf.render.html >> > org.apache.myfaces.commons-jsf.render.html.jsf-1-1 >> > org.apache.myfaces.commons-jsf.render.html.jsf-1-2 >> > >> > WDYT? >> > >> > Manfred >> > >> > >> > >> > >> > On 11/24/06, Bruno Aranda <[EMAIL PROTECTED]> wrote: >> > > It seems a good idea to me. But should this commons lib be jsf >> version >> > > independent (I mean, same jar to be used in jsf 1.1 and jsf 1.2 or >> > > not). There are classes, like UIComponentTagUtils, which would have a >> > > different implementation for jsf 1.1 and 1.2, but there are other >> > > (many) classes that can work for 1.1 and 1.2 out of the box. I would >> > > say it would be better to have a unique implementation of >> > > myfaces-commons and it should be jsf version independent... >> > > >> > > Cheers, >> > > >> > > Bruno >> > > >> > > On 24/11/06, Manfred Geiler <[EMAIL PROTECTED]> wrote: >> > > > Hi *, >> > > > Anyone remembering the old idea of having a separate "commons jsf >> > > > utils" project? >> > > > >> > > > Mission: >> > > > - provide utilities for JSF component developers as well as JSF >> > > > application developers >> > > > - provide a stable API >> > > > - must not depend on a certain JSF implementation >> > > > - own release schedule independent of core and tomahawk. Maybe >> > > > propelled by a sister project of course... ;-) >> > > > >> > > > One perfect example of a jsf-commons class I just stumbled >> across is >> > > > UIComponentTagUtils. It's the class where all those boring >> > > > set*Property methods are implemented, that do the "if value-binding >> > > > then... else..." things. >> > > > >> > > > Proposal: >> > > > - Initiate a new MyFaces sub-project called "commons-jsf" >> > > > (Yes! There did exist a "commons" in ancient times. It was the >> > > > forerunner for our current "shared" project and the reason we >> renamed >> > > > "commons" to "shared" was, that we planned to create a REAL commons >> > > > project later. Remember?) >> > > > - We start with those obvious common jsf utils (like >> UIComponentTagUtils) >> > > > - Each (new) util class must be carefully designed to be able to >> > > > provide a robust API >> > > > >> > > > Thoughts? >> > > > >> > > > >> > > > Manfred >> > > > >> > > >> > >> >> >> -- >> >> http://www.irian.at >> >> Your JSF powerhouse - >> JSF Consulting, Development and >> Courses in English and German >> >> Professional Support for Apache MyFaces >> >
