On 12/8/05, Mike Kienenberger <[EMAIL PROTECTED]> wrote: > > I think it makes the most sense to leave it under MyFaces. > All of the tomahawk and sandbox components directly depend upon it, as > does parts of the MyFaces implementation. Moving it into another > project doesn't gain anything, and would make code sychronization more > difficult. As long as it's a separate jar, it doesn't make any > difference to end-users whether it's hosted at MyFaces or another > project.
It may not make a different to MyFaces end users, but, assuming the common code is also used by Shale, which is what I thought we were discussing here, telling JSF RI users that they have to get a component from MyFaces to use Shale with the RI would be a little odd... -- Martin Cooper On 12/8/05, Martin Cooper <[EMAIL PROTECTED]> wrote: > > On 12/8/05, Sean Schofield <[EMAIL PROTECTED]> wrote: > > > > > > I think a jsf-commons project would be nice. Craig's suggestions > > > certainly make for good candidates. There are a few in MyFaces that > > > would definitely be appropriate as well. > > > > > > For MyFaces the plan is to rename the "share" subproject to "commons" > > > and to start releasing it as its own jar. In the shortrun I think we > > > should stick with that stuff in MyFaces but in the long run, I don't > > > see any problem with moving it to jakarta-commons. There are a few > > > issues to consider (such as committer rights and a different set of > > > rules and conventions.) Perhaps Craig could speak to that more > > > specifically. Ultimately we are all in the ASF family so maybe it > > > wouldn't be too big of a change. > > > > > > I don't think this would go to Jakarta Commons. It would, however, be a > good > > candidate for the Silk subproject, assuming that gets off the ground. > (Think > > of Silk as WebApp Commons.) Silk still seems to be pending name > approval, > > but once that gets cleared up, it would be a good place to build > libraries > > that could be shared by Shale, MyFaces, et al. > > > > -- > > Martin Cooper > > > > > > I think we'll need to do a careful analysis of the myfaces commons > > > stuff before moving it into jakarta-commons. I supposed most of it is > > > useful beyond creating a JSF implementation b/c the stuff in there is > > > basically stuff that is used for the MyFaces implementation as well as > > > the Tomahawk components. So certainly custom component builders might > > > be interested. > > > > > > Something to consider but IMO there's no rush on this. We have some > > > major infrastructure changes coming up (Maven, zones) and then there's > > > the 1.2 spec. Plus on the Shale side we're trying to raise the > > > profile of that project and get some releases out the door. > > > Personally I'd rather see a few other things addressed like a "pet > > > shop" type application that would show off MyFaces and Shale working > > > together. I think that would do a lot to help promote the two > > > technologies. > > > > > > sean > > > > > > > > > On 12/8/05, Craig McClanahan <[EMAIL PROTECTED]> wrote: > > > > On 12/8/05, Mike Kienenberger <[EMAIL PROTECTED]> wrote: > > > > > > > > > > This has come up recently on the Myfaces-dev mailing list. We're > > > > > probably going to be splitting off a "jsf commons" package at some > > > > > point. Myfaces/share contains what would probably end up in such > a > > > > > package. > > > > > > > > > > Do a search for thread "[proposal] myfaces-core.jar" on the > > > > > myfaces-dev mailing list, Nov 29th to 30th. > > > > > > > > > > > > For the simple kinds of utilities you're describing, hosting such a > > > commons > > > > at the MyFaces project would make a lot of sense -- all the > developers > > > there > > > > would be JSF savvy and the users of the JSF implementation, and/or > the > > > > components, would both be interested in this kind of stuff. > > > > > > > > On the other hand, if the functionality you are implementing is very > > > > specific to a framework, the utilities ought to stay with that > > > framwork. In > > > > the current Shale code, for example, you could argue that the > > > > LoadBundle.java and Messages.java utilities are sufficiently general > > > purpose > > > > that they might fit into a commons (and it would be fine with me if > the > > > > commons project wanted to copy them) -- but something like > > > > AbstractViewController should stay in Shale because it's fundamental > > > > functionality of the framework. > > > > > > > > AbstractFacesBean.java would be another commons candidate, because > it is > > > not > > > > really framework specific. > > > > > > > > Craig > > > > > > > > On 12/8/05, Alexandre Poitras <[EMAIL PROTECTED]> wrote: > > > > > > I was wondering if it would be a good idea to start a jsf > commons > > > > > > project because every JSF applications seem to use a class Util > with > > > > > > the same methods or some variants of it (set and get some > attributes > > > > > > with binding expressions, passthrought some default attributes > > > during > > > > > > encoding). What do you think? Would the classes under the > package > > > util > > > > > > in Shale be good candidates? I would like to contribute if it > starts > > > > > > but I can't write it all by myself because I am still far from > being > > > a > > > > > > JSF expert. > > > > > > > > > > > > > > > > > -- > > > > > > Alexandre Poitras > > > > > > Québec, Canada > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
