On 5/26/05, Martin Marinschek <[EMAIL PROTECTED]> wrote: > Well, we could probably just ask Craig for a copy, but it doesn't play > well to have two copies of the same code in the ASF codebase.
You mean "ask for a copy of code that's already in an ASF repository?" You don't have to -- the license terms already allow for that sort of cut-n-paste reuse. But, of course, you're welcome to it from my *personal* perspective. Of course, your other point about duplication is relevant. See below for a couple of more thoughts. > > Is Craig listening to that? Wdythink? > >From my perspective, the MyFaces "movement" was started with the sole focus of creating a compatible implementation of the JavaServer Faces Specification (which is a good thing :-) -- and which is not done yet :-(). The idea that someone might be interested in a set of JSF components produced by an overlapping group of the same people was, well, serendipity at work. If the original scope of the MyFaces incubator proposal had said "we want to produce a compatible JSF implementation *and* a bunch of stuff on top of JSF", I'd be a lot more interested in directly participating. But it didn't say that, and I had to prod the developers into doing things as obvious (sorry ... this is probably a cheap shot, but ...) as splitting the components out into a separate JAR, and making some efforts to ensure that those components would actually run on non-MyFaces implementations as well. That's the point of a common standard, right? Happily, that seems to be the direction that the component folks are going. Where life gets more interesting (as the Chinese would say :-) is when you do value added stuff on top of "JSF as an application framework baseline" instead of just "JSF as a basis for portable user interface components". I personally view Shale as a logical successor to Struts 1.x, and it would not have been fair for me to host it anywhere other than the Struts community, if they were willing to accept it (which they were). The other committers haven't bought in to the "logical successor" part of this yet, but give 'em time :-). In the interim and even if my view ultimately prevails, I do *not* see Shale as a place where lots of generic JSF components live. Indeed, the only components that *must* live there should be ones that rely on Shale infrastructure. Generic JSF libraries can be happily integrated with Shale courtesy of the JSF standards; we don't need to invent any of those, or pretend that there is such a thing as a "Shale tree control" or whatnot. That being said, it doesn't seem unlikely to me that there will be technologies (such as Commons Validator) that make sense to have integrations directly with a webapp framework, and a looser integration with generic JSF. That's fine -- and it makes sense to have both approaches supported because the use cases and the audiences are different. (Indeed, this is why I'm going to work on a Spring Web Flow -- JSF integration library, if I'd ever get to stop working insane hours :-), separate from what's already in Shale; different folks have different needs and different levels of technical sophistication.) Don't assume that the optimum number of implementations of any particular idea is *one*. That's too simplistic to cover the needs of all the developers out there. Don't assume that the existence of support for technology X in Shale means that I would oppose an implementation of the same technology purely based on JSF. Indeed, if you ask, I'll be happy to give you the benefit of our experiences. But, in the long run, I'll bet the background I have in web app frameworks gives me a head start in understanding what people might want of a web app framework that presumes JSF exists :-). Craig > regards, > > Martin > > On 5/26/05, IdRatherBeSailing <[EMAIL PROTECTED]> wrote: > > > > --- Sean Schofield <[EMAIL PROTECTED]> wrote: > > > Shale and MyFaces are two entirely different > > projects > > > started by two entirely different groups of people. > > > The only thing they have in common in JSF. > > > > Agreed completely. And MyFaces Extensions is a set of > > extensions to core JSF that should work on any JSF > > according to its description. > > > > > If you like the commons validator stuff for JSF then > > > you are going to have to end up using Shale. > > > > That's a non-starter. While JSF and Struts are > > already accepted by the market, customers and mgmt, > > Shale is still too new (near zero market share, still > > under early development not release...). While I'd > > love to start playing with Shale, it's not going to > > make into my or my customers' deployed apps anytime > > soon, while JSF and common JSF extension tags (like > > MyFaces Extensions) could. > > > > > One thing I can say for 100% sure is that there is > > > no point in MyFaces adding something that is > > > already available in Shale. > > > > Completely disagree with you on that one. Adding > > something shale-specific to MyFaces makes no sense. > > Adding a JSF tag(s) that would be of use to all users > > of any JSF (since JSF validators ootb leave a bit to > > be desired) across all JSF implementations (JSF is > > supposed to be a standard, so apps you build with JSF > > should run on all JSF impls where possible) to MyFaces > > Extensions (not MyFaces core) makes complete sense. > > > > If Shale had an extension library that had useful JSF > > tags that could be used across all JSF > > implementations, then I could see your point. But > > Shale is a new framework that's not yet done and it > > has now embedded these useful-across-the-JSF-board > > tags within the Shale Core such that you couldn't use > > them without including the Shale core in your app. > > > > Struts didn't include commons-validator within Struts > > core, it's a separate subproject so that it could be > > used across other projects that had similar needs. > > > > > Shale is new techonology but then again so is > > > MyFaces and JSF for that matter. > > > > JSF is shipping in several commercial IDEs already, > > and thus has market and mindshare. Shale, while cool > > and interesting does not yet have that luxury. I > > hope that it does at some point, but I would still > > like to see generally useful JSF tags included in the > > JSF project extensions not in a superset framework > > project. > > > > Thanks, and I know these questions are more oriented > > toward Craig and David than you and the MyFaces PMC, > > but I was hoping someone on the MyFaces Extensions > > contributor team would offer to add this functionality > > to the MyFaces extensions (at which point Craig and > > David could decide whether to keep their own copy in > > the Shale "core" or to depend on the MyFaces > > extensions like other JSF apps and JSF supersets > > could). > > > > > > > > __________________________________________________ > > Do You Yahoo!? > > Tired of spam? Yahoo! Mail has the best spam protection around > > http://mail.yahoo.com > > >
