On Nov 25, 2006, at 9:32 AM, Ted Husted wrote:
Could we also document the alternative of moving the org.apache.tiles packages *into* the struts2-plugin? The proposal cites three problems: 1 Can't release 2 Not visible 3 Not permanent As part of the Struts2 Plugin, problems 1 and 2 will be solved.
The problem I'm most concerned about with this proposal is problem 1. Our main goal here is to find a point where we stop adding revolutionary features and start moving towards a GA release. To me the most urgent "visibility" problem is that people can't download an actual Tiles release. They have to download a snapshot build. So the Struts 2 plugin and the Shale view handler have to depend on a snapshot release. Other projects, like MyFaces, just depend on Tiles 1.x. My initial goal is to give people a Tiles 2.0.0 that is an Alpha-quality release and I think the other Tiles developers are on the same page.
If all we want to do is separate Tiles from the core, then mission accomplished, put the packages back into the plugin.
I disagree. If we do that Tiles is not standalone anymore and the mission is no longer accomplished. Tiles 2 currently has no dependencies on Struts and contains no integration code with any other framework. Integration with another framework is provided by the other framework. That's the whole idea of making it "standalone". If we put the packages into the plugin it now has an integration layer with Struts 2. When we decide where it will ultimately live we will have to separate the plugin from the core Tiles framework. That means separating codebase, test cases, doc, build files, etc.
I want to keep Tiles standalone, graduate so we can release an alpha, then put our focus into knocking out the rest of the issues and deciding where the permanent project will live.
Realistically, making Tiles a subproject is not going to suddenly create community interest in the codebase. That didn't happen for the other subprojects, that we later merged back into Struts 1, it really didn't happen for Shale either, and it's unlikely to happen to Tiles. To create community, a codebase needs to stand on its own or be part of a larger umbrella project, like the Commons or the ASF itself.
I agree. I don't see this move as building community. It's just a stepping stone on the path to independence.
As part of the Struts 2 plugin, other projects, like Shale, and Spring, and WebWork, would be able to make use of Tiles, which is the primary goal. We can make the Tiles plugin as visible as we want it to be, and it will be just as easy to promote Tiles to TLP later, should other developers materialize (or remateralize).
Yes, but then the plugin would be part of Tiles. I personally don't want that and I think that goes against the original reason for creating the standalone Tiles project.
I'm OK with listing Jakarta Commons as a home for Tiles, as well as a new Jakarta Subproject or even TLP for Web Components. I'm also OK with listing the s2 plugin as an option, even though it's not an option I'm in favor of. But our focus here is not trying to find the permanent home for Tiles. We are intentionally leaving that question open for the time being and trying to move Tiles to a place where it will stabilize.
The reason the subproject appeals to me is that we can simply copy the tiles sandbox svn tree out of the sandbox and cut an alpha release. Then we can start trying to answer the bigger questions. Any other path either 1) takes us backwards with regard to independence (struts2-plugin) or 2) requires a whole lot more community-building and red tape before we can move any further (jakarta, TLP, etc.).
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
