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.
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.
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.
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?
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.
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
