Another idea would be to refactor the examples such that we create one big example, that can be built from core and subprojects. Cocoon does this for its "blocks" concept, which is somewhat similar to subprojects. Each "block" defines its own example files, then a build.xml script crawls all block directories looking for example files, to aggregate them into one large example. This would help consolidate our many examples and make the example build process not dependent on any subprojects, yet include them naturally for the end user.
Don
Martin Cooper wrote:
Don,
I just realised that there's another, rather large, issue that you'll come across, if you haven't already. All of the examples use the taglibs. That means we'll need to pull the examples out of core at the same time, probably into an 'examples' subproject.
I ran into this while working on the build, since I was looking at the overall structure of what we have. There's a lot of inconsistency, and I'd like to clean that up. But I'm going to put the new build on hold for a bit, until we get the major restructuring out of the way. That means that I'll have some cycles this coming week, which I was going to spend on the build. So if you'd like some help with the restructuring you're working on, let me know.
-- Martin Cooper
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?
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
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.
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]
