On 2/14/06, Sean Schofield <[EMAIL PROTECTED]> wrote: > Volker, > > Interesting proposal but I don't we have to address this just yet. > But since you brought it up, do you think its possible that ADF and > Tobago could merge into a single project? I don't know enough about > either to say for sure. > > I'm -1 on having saveState in 3 separate projects (tomahawk, tobago > and adf.) Why would it need to be in commons when it could just be in > tomahawk? Is there anything in tobago that *requires* save state? Or > is more accurate to say tobago provides a save state and so does > tomahawk? Again, I'm not too familiar with tobago ATM (but I will > learn!)
100% agreement that it's darn silly to have multiple implementations of any non-rendering "utility"-ish things. Confusing to the users, wasted development effort, etc. etc. One obvious example of that is the file upload filter provided by ADF Faces. That's gotta go - the JSF-specific parts merged into MyFaces core only where they provide new value, and the generic upload implementation chucked for Apache commons. I do think there is some value is thinking about things like saveState as independent of tomahawk, that tomahawk could be considered as a set of rendering functionality, then separately MyFaces has a set of utilities that are entirely independent of any sort of JSF rendering architecture you choose. For the other question of the thread, merging the subprojects, I would think our first goal (once all the incubator, etc., Apache process has cleared) would be merging the non-rendering functionality. For instance, ADF Faces has a custom StateManager - and obviously, we should take the best features of that and merge it down into the core. That's the best way to get the most bang (users benefit) for the buck (developer time). ADF Faces should be very mergeable with Tomahawk with a weak definition of "mergeable": using Tomahawk and ADF Faces in the same page, or making them the same taglib. Doing the merge in a strong sense - making all the components and renderers work off of the same base classes from an internal implementation standpoint, in particular - will be a bigger challenge. Worth taking on, but it'll take time. -- Adam > On 2/14/06, Volker Weber <[EMAIL PROTECTED]> wrote: > > Hi, > > > > +1 for jira split, imho it's needed for different release cycles. > > > > But before doing so we should think about another distributed jar file > > we may want, I think we should have one :-). > > > > I had mentioned before when talking about naming for commons.jar, we > > should have another jar for shared components/classes between tomahawk, > > tobago( and adf?). Non rendering tags like aliasBean, saveState, > > validators and other stuff which could used in both. > > > > I don't like to have impl depends on this, so commons.jar is imho not > > the right place for those. > > > > Regards, > > Volker > > > > Erik Gustavson wrote: > > > It'll also make sense once ADF Faces gets into the mix. > > > > > > +1 for Jira split, esp. when tomahawk and core, etc... start having > > > different release cycles. > > > > > > +1 for the snapshot naming convention > > > > > > +1 for Tomahawk components being listed as Jira components... that would > > > make it very easy to assess the maturity of any given component for an > > > end user. > > > > > > "commons" would make sense as a Jira component of MyFaces. What other > > > Jira components would make sense under MyFaces then? > > > > > > commons > > > (web) site > > > documentation > > > impl > > > build (maven) > > > > -- > > Don't answer to From: address! > > Mail to this account are droped if not recieved via mailinglist. > > To contact me direct create the mail address by > > concatenating my forename to my senders domain. > > >
