On 12/14/06, Greg Reddin <[EMAIL PROTECTED]> wrote:
On Dec 13, 2006, at 5:47 PM, Craig McClanahan wrote:
<snip>
> One thing that might affect Greg's enthusiasm :-) I'd like to see > us do is > try to position for a GA release of everything except shale-tiles, > either by > marking it with a separate release grade when we ultimately vote, > or by > making it available separately as its own release. I think we can > be ready > to have API stability on everything else in just a short while. I agree. I don't think the tiles piece should hold up the whole project from going GA. I want to have a way to promote components to GA as they are ready. I think I prefer the approach of marking separate release grades over creating separate releases. It seems like there's too much to do to roll out a release for each component to have its own cycle. We already distribute everything as separate packages, right? It doesn't seem like it would be too hard to apply a quality label to each package individually.
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. That would resolve the potentially confusing issue of having different pieces with different quality labels? On the topic of separate releases it seems that you have two scenarios in Shale - components which have inter-dependencies (usually core) and those that don't (not including a "test" dependency on shale-test). In the first case as well as being practical from a release management POV to release together - it also makes it easier to understand for users if the version number of these is the same and they don't have to work out which versions are compatible. In the second case where there are no inter-dependencies then there would seem to be more value in allowing for the possibility of separate release cycles. A couple of points about Shale's inter-dependencies: 1) shale-tiles and shale-spring have a dependency on shale-core in their pom.xml but I can't see any actual need for this? 2) shale-application's only dependency on shale-core seems to be the Messages class and the actual messages which are in the core's bundle (is that a mistake?). Since the Messages class is only used for logging/exception messages with the default Locale and only one instance uses a replacement argument - most of the value of using this convenience class over a ResourceBundle directly seems to be not utilized. IMO it would be worth removing this so that shale-application could be used on its own. ...anyway back to the point, from what I can see "core", "clay", "designtime", "tiger", "validator" and "view" are inter-dependant whereas "application" (with slight change), "dialog/dialog-basic/dialog-scxml", "spring", "test" and "tiles" could be used standalone with any JSF app? 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. Whether that's a practical approach release/maven wise is another thing and I'm sure other people are better qualified to say. Just my 2cents. Niall
