I don't think anyone would mind Tiles splitting off to be its own project, but the question is rather the existence of developers and a community to take it over. I suggest its own Struts subproject for now until a development community can form around Tiles to support its departure.
This sounds like a good approach. I'm all for letting Tiles leave the nest, for the reasons David cited. On the other hand, I'm not sure I'd worry about pushing it out of the nest, even if the tiles subproject had a lot of external dependencies. I think we can manage all of that.
Joe
Don
David Geary wrote:Le Dec 26, 2004, à 3:50 AM, Matthias Wessendorf a écrit :
David,
are you thinking about bringing Tiles up to incubator ? To be a *toplevel* apache project like Struts itself?
I'd like to see an open-source standalone version of Tiles. A toplevel Apache project is one way to do that.
david
And yes... Merry Christmas ;-) Matthias
-----Original Message----- From: David Geary [mailto:[EMAIL PROTECTED] Sent: Saturday, December 25, 2004 6:39 PM To: Struts Developers List Subject: Re: Taglibs and Tiles Extraction Issues
Merry Christmas, btw!
Le Dec 25, 2004, à 1:35 AM, Don Brown a écrit :
I don't know about the other Struts folks, but I think this is would be a great addition to Tiles.
This is not an addition to Tiles, this *is* Tiles. Perhaps I wasn't clear. I have extracted the Tiles code from Struts 1.1, including the taglibs. I have taken that code and added a few enhancements, including a Tiles servlet, a JSF view handler and some demos. I have a standalone version of Tiles that works without Struts.
Initially, the Struts Tiles subproject could host Tiles,
but as more
adapters get added, and perhaps the Tiles community
enlarges, there
would be enough interest in hosting the Tiles project somewhere outside of Struts.
It seems to me that now is the time for Tiles to be it's own project. Tiles has nothing to do with Struts, other than the fact that it provides Struts integration. With my version of Tiles, I'd like to provide integration for other display technologies as well. I'm also interested in exploring integration with SiteMesh, which is a neat technology (for page decoration) that compliments Tiles (for page composition) nicely. None of those goals for Tiles has anything to do with Struts.
I also think that Tiles would get more attention if it were it's own project instead of a Struts subproject. IMO, Tiles has stagnated and is due for a facelift.
david
As for adapters, the Tiles build could follow the pattern commons-chain uses to optionally build adapters as jars are
available.
Let me get the Tiles subproject setup, then we can start
working on
integrating this code.
Don
David Geary wrote:
I have extracted a standalone version of Tiles from Struts
1.1. I've
implemented a TilesServlet for using Tiles outside of
Struts and a
JSF view handler that forwards to a tile instead of a JSP page. I also have some cool examples. I was on the verge of starting an open source project for
standalone
Tiles that would focus on integration with other presentation technologies besides Struts, such as JSF, Velocity,
Tapestry, etc. I
want a Tiles version that I can use with JSP only, or with the framework of my choice. And I want Tiles to be integrated
as smoothly
as possible with my framework. I don't want to have to
drag Struts
around to do that. So, I'm not sure what to do with my code. Do my goals for a standalone Tiles align with the goals for the Tiles
subproject within
Struts? david Le Dec 24, 2004, à 3:30 PM, Martin Cooper a écrit :
On Fri, 24 Dec 2004 12:22:33 -0800, Don Brown <[EMAIL PROTECTED]> wrote:
I've made further progress in extracting tiles and taglibs, and have run into several issues I'd like to get some feedback on.
1. Tiles depends on TagUtils in taglibs. Tiles' version of TagUtils has a link to taglib's TagUtils.getScope(). I could copy
this method
over (it is a whole 5 lines), but this raises a larger question of subproject dependencies and distribution. Will each subproject have its own ibiblio entries? Ted suggested, and I agree, that
subprojects will
be bundled with Struts releases ala Linux distributions,
but how do we
communicate intra-subproject dependencies?
The method is short, but it relies on a map that is set up in a static initialiser... If we want to make Tiles usable in the absence of Struts, as some people do, I think we'd have to clone the
code within
Tiles.
With respect to ibiblio, I think it would make sense to consider Struts as a group and Struts subprojects as artifacts within that group (using Maven terminology here ;).
I think you're asking about inter-subproject dependencies, right? This is one of the pieces of the build system I haven't yet found a solution for that I'm happy with. But I'm not sure if
you're asking
about that, or about communicating the information to users.
2. Mock objects. Currently, Struts contains mocks for
the servlet,
but these classes would be useful for subprojects as well.
I suggest we
adopt StrutsTestCase, or another test package, as a
subproject or
dependency
I still haven't taken the time to look at StrutsTestCase.
If we used
that for our own testing, I assume, from what you say,
that we could
then ditch the mock objects we have today? (What does
StrutsTestCase
use for its own unit tests?)
3. Cactus. I admit, I never got this working, and now
with taglibs
and tiles unit tests requiring Cactus, I'm not sure how to
migrate that
build process over, especially as we await the Ant
reorganization
Martin is working on. I'm leaning to committing all my changes
once I got
all the code compiling and let someone more knowledgable
setup cactus
for these two subprojects.
It looks like EL "solved" this by copying the build files. Obviously, this is, um, less than optimal, but until the
new build
is ready, perhaps we should do the same thing. On the
other hand, I
don't think we want to put a lot of effort to making this
all work
when the build system is changing (hopefully next week).
-- Martin Cooper
Thanks for the help,
Don
-------------------------------------------------------------------
- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------
- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
-- Joe Germuska [EMAIL PROTECTED] http://blog.germuska.com "Narrow minds are weapons made for mass destruction" -The Ex
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
