On 12/8/05, Martin Cooper <[EMAIL PROTECTED]> wrote: > > 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...
Well, only sort of ... the tomahawk components will certainly work very nicely with Shale, and they are from MyFaces too. Craig -- > 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] > > > > > >
