On 12/14/06, Greg Reddin <[EMAIL PROTECTED]> wrote:
On Dec 14, 2006, at 8:53 AM, Niall Pemberton wrote: > As the shale-tiles module has no dependency on the rest of shale and > can be used in a vanilla JSF environment wouldn't it make more sense > to move this to the proposed Tiles project? I think the argument for > having JSF support in Tiles is different to the one of including > support for Struts or any other framework in the Tiles project since > JSF is a standard. I've thought about that myself. Shale-Tiles is *just* a ViewHandler. I fear that importing it into the Tiles project might be a mistake for at least a couple of reasons: 1) It sets a bad (IMO) precedent of Tiles providing integration with parent frameworks instead of the frameworks providing integration with Tiles.
Doesn't it being a java "standard" make it different from other frameworks? Commons components like Chain and SCXML provide "servlet", "portlet" and "JSF" integration as standards and I think most users would recognise that providing integration with a standard is different from a non-standard framework.
2) It may send the message that JSF is a "preferred" framework for Tiles, and people will start to ask questions about why Tiles doesn't provide Struts integration, etc.
Conversly you may get people thinking that you have to have Shale to use Tiles with JSF. Either way the message you send is easily resolved with reasonable docs/website.
I'm more comfortable with Shale-TIles staying here or even moving to MyFaces as an extension than becoming part of the core Tiles framework.
The other argument I would say is where are the shale-tiles dependencies? In "project" terms its not Shale or MyFaces - the only project it depends on is Tiles plus a standard (JSF). So doesn't it make more sense to release from that project - rather than getting tied into/bound by MyFaces or Shale release cycles when theres no actual need to do so?
> That would resolve the potentially confusing issue > of having different pieces with different quality labels? It would solve the most immediate problem, but I don't think it addresses the root cause. Shale is made up of a bunch of loosely- coupled components - so much so that, as you pointed out, most of them could live completely independently of one another. But if each one was required to go through the whole release process separately, none of them would ever be released :-) Plus, you also pointed out the issue of compatibility. How can I know if shale-remoting-1.0.4 can live happily alongside shale-dialog-1.0.6?
Well as "remoting" and "dialog" are independant of each other and the rest of shale is there any reason why they wouldn't live happily together? I think the independent pieces of shale (i.e. those that don't depend of other shale pieces) should be clearly marked. That way if I use for example shale-dialog I know it doesn't matter what the version number of other pieces of shale are.
If we could cut a release that includes only selected components we might have this: shale-1.0.4 includes: - shale-core-1.0.4 - shale-remoting-1.0.4 - shale-clay-1.0.4 Then Clay goes into unstable development while dialog-basic stabilizes so we release: shale-1.0.5 includes - shale-core-1.0.5 - shale-remoting-1.0.5 - shale-dialog-basic-1.0.5 But what if I need shale-1.0.5 and I'm using Clay? Which Clay do I use? Is clay-1.0.4 compatible with core-1.0.5? Maybe there's a way for shale-1.0.5 to include shale-clay-1.0.4 with a label of shale- clay-1.0.5. That sounds pretty screwy, but the advantage is that users can know that components with the same version number are compatible.
I don't think I expressed myself very well since this was what I was trying to say - I agree that the shale pieces that have inter-dependencies (e.g. clay on core) would be better to be released together with the same version number to avoid user confusion over compatibility. Niall
> Having an "all" distro is a > good plan IMO - but also making the independent components also > available as separate downloads would help communicate that there are > pieces available to use on their own and having independent version > numbers for them and not precluding the possibility of separate > release in the future would seem like a good idea IMO. For projects using maven, of course, this is already possible. I don't know when the last time was I actually downloaded a release package. I just get it by adding a reference in my Maven POM to specific components. To me, this approach is much easier when all the components have the same version number. Greg
