Hi,
2007/11/29, Manfred Geiler <[EMAIL PROTECTED]>:
> Oh no! Seems like we are going round in circles... :-(
>
> WHAT is the FOCUS of a jsfcommons project?!
>
> Do we really want component like stuff like converters and validators there?
> Didn't we discuss this already?
Yes we had discuss this, but it seems we did not reach agreement.
I think we need a own project for converters/validators/other stuff
for application-development
which should not include renderkid/jsf-impl dependend stuff.
An i think this one was meant by Matthias and Bernd.
If we need jar supporting component-developer we should stop the
repackaging of shared, create a shared.jar and add the dependency
instead to impl and tomahwak.
(Just my thoughts)
Regards,
Volker
> I thought we agreed on not starting yet another jsf component lib.
> What is wrong with having convenient converters and validators in
> tomahawk? Where they are right now!
> Is it because tomahawk has some flaws and maybe have sideeffects on
> other component libs? If yes, we have to FIX tomahawk and not turn
> around and start a new (better?) project.
>
> My original idea of a jsfcommons project is/was:
> - convenient utils, helpers and base classes for component developers
> - convenient backing(!) bean utils and helpers for jsf application
> developers (ie "users")
>
> What jsfcommons should NOT be:
> - a convenient haven for simple components or component like stuff,
> that is put there for "strategic" reasons
>
> A need for a "jsfcommons-faces-config.xml" is a definite sign, that we
> would start off in the wrong direction. We would start yet another jsf
> component lib. That is the main reason I warned of having a
> faces-config.xml in jsfcommons in former discussed. It was not only
> for technical reasons.
>
> --Manfred
>
>
>
> On 11/29/07, Mario Ivankovits <[EMAIL PROTECTED]> wrote:
> > Hi!
> > > I don't think a separation between api and impl jars is useful.
> > >
> > I second that. For the same reasons. It makes things unnecessary
> > complicated ....
> > To ensure api stability community review should be enough - and then
> > there is a maven plugin for that, no?
> >
> > BTW: I thought we agreed on a structure like
> > myfaces-jsfcommons-converters
> > myfaces-jsfcommons-validators
> > ...
> >
> > Also overly complex, but something I can learn to understand ....
> >
> > Lets reiterate: I prefer to start with a simple jsfcommons project where
> > we have no faces-config.xml (at least not in a place where JSF loads it
> > automatically).
> > Providing a jsfcommons-faces-config.xml which the user has to add to the
> > configuration will avoid any side-effect when dropping in our jsfcommons
> > jar. It also allows to selectively active things as the users can change
> > their own configuration as required.
> >
> > Regarding the sandbox: I'd like to suggest to use the tomahawk sandbox
> > for myfaces land at all. Lets promote the tomahawk-sandbox one level
> > higher - thats it.
> >
> > Ciao,
> > Mario
> >
>
