You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@struts.apache.org by Don Brown <mr...@twdata.org> on 2004/12/24 21:22:33 UTC
Taglibs and Tiles Extraction Issues
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: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Taglibs and Tiles Extraction Issues
Posted by Don Brown <mr...@twdata.org>.
Darn. I suppose we could make an examples subproject, but the original
reason to have subprojects is the ability for them to have a separate
release cycle, which wouldn't really apply to examples. On the other
hand, it wouldn't be good to have code in Core that depends on subprojects.
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 <mr...@twdata.org> 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: dev-unsubscribe@struts.apache.org
>>For additional commands, e-mail: dev-help@struts.apache.org
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Taglibs and Tiles Extraction Issues
Posted by Martin Cooper <mf...@gmail.com>.
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 <mr...@twdata.org> 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: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Taglibs and Tiles Extraction Issues
Posted by Vic <vi...@friendvu.com>.
Don Brown wrote:
> e 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.
>
>
> Don
Can't offer help, but moral support, so thanks AGAIN!
You did a lot of work, and so a deadly embrace is avoided, I think it
best you commit what you have and see what shakes out. (Worst case so of
it gets rolled back )
.V
--
RiA-SoA w/JDNC <http://www.SandraSF.com> forums
- help develop a coomunity
My blog <http://www.sandrasf.com/adminBlog>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Taglibs and Tiles Extraction Issues
Posted by Ted Husted <hu...@apache.org>.
On Fri, 31 Dec 2004 10:17:35 -0800, Martin Cooper wrote:
>>�We might focus on rolling a Core milestone first. Once that is
>>�building, we can bring out a Taglibs milestone which is dependant
>>�on that. Then, Apps milestones that are dependant on Core and
>>�Taglibs. Rinse and repeat. �Core/Taglibs/Extras/Apps. Later,
>>�Core/Taglibs/Extras/BSF/Flow/Apps. And so forth.
>>
>
>�Um, what's 'Extras'? I don't recall one of those, and am not sure
>�what would be in it.
I'm not sure how much we discussed it, but the idea is that it would contain what we now toss into the "Actions" and "Plugins" packages.
Classes that are not essential to the core framework, but that many people fine useful.
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Taglibs and Tiles Extraction Issues
Posted by Martin Cooper <mf...@gmail.com>.
On Wed, 29 Dec 2004 10:26:17 -0500, Ted Husted <hu...@apache.org> wrote:
> On Sat, 25 Dec 2004 00:31:24 -0800, Don Brown wrote:
> > Well, technically, Tiles would be dependent on Struts-taglibs, not
> > Struts core, but I agree, cloning the method is the easiest
> > solution here. I mainly was using it as an opportunity to raise
> > the larger issue of subprojects depending on other subprojects.
>
> Which, as mentioned elsewhere, lacking a dependency on the Core implies that Tiles is not a good candidate for a Struts subproject anymore. A hard dependence on the Core is what keeps us from becoming an umbrella project.
>
> I'd suggest that we continue to follow the "Commons" paradigm. Anything that can be reused should be pushed up into it's own distribution. Everything we distribute under struts.apache.org should be dependant on Core, and Core must not be dependant on anything else we distribute. As we have been doing, anything we can share, that is not dependant on Core, should be pushed down into Commons, or out into its own project (e.g., Tiles).
>
> Anything that Core needs, that is itself dependant on Core, should be part of Core (e.g., TestCase).
>
>
> On Mon, 27 Dec 2004 14:17:27 -0800, Don Brown wrote:
> > Darn. I suppose we could make an examples subproject, but the
> > original reason to have subprojects is the ability for them to have
> > a separate release cycle, which wouldn't really apply to examples.
> > On the other hand, it wouldn't be good to have code in Core that
> > depends on subprojects.
>
> As to "examples", are we not moving the web applications into an Apps subproject?
>
Ah yes, we did say we were going to do this. I might have a go at that
today, since we'll need to pull it out to get 'ant clean dist' in core
to build again.
> I'd suggest getting a Core milestone building first, so that we have a JAR that can be imported by other nascent subprojects, like Taglibs, Extras, and Apps.
>
Yep, that's my immediate goal. If I can rationalise the source tree
structure, I can get the first part of the build process in place as
well.
> I believe we are trying to follow a "divide-and-conquer" strategy. Subprojects should depend on milestone releases of other subprojects. So, we'd want to get a milestone of one thing out first, and then the other.
>
Well, I'd like to get the various pieces building before we start
thinking about milestones, so that we can have a nightly build that
includes the various pieces, as we had before. Right now, the
nightlies are broken.
Also, bear in mind that part of the testing for the taglibs happens
through the exercise-taglibs sample app, so it would be good to have
that working before we start distributing taglibs milestones.
> Obviously, everything is not going to work perfectly together the first time. We'd have to roll Core and Taglibs before making any Apps releases, and the Apps are going to expose oversights in the 1.0.0 milestones of Core and Taglibs. But we can make fixes and bring out new milestones of each until a distribution falls into place.
>
> We might focus on rolling a Core milestone first. Once that is building, we can bring out a Taglibs milestone which is dependant on that. Then, Apps milestones that are dependant on Core and Taglibs. Rinse and repeat. Core/Taglibs/Extras/Apps. Later, Core/Taglibs/Extras/BSF/Flow/Apps. And so forth.
>
Um, what's 'Extras'? I don't recall one of those, and am not sure what
would be in it.
> If we have trouble finding a sequence in which to build the subprojects, then a subproject might not be cohesive, and we might have to rethink the divisions. But, we should follow the code, and let the code tell us what belongs together.
>
Yep. And if what the code tells us doesn't make sense, then it's time
to refactor.
> One thing that would help make this work is a repository system. Either Maven's or our own. The Core JAR should build to a place-certain, and then the other subproject builds should be able to find that JAR and use it in their own builds. For example, each subproject can drop a JAR into a lib folder under the local copy of the Build project.
>
Yep, the new build I have in the wings will take care of that.
> If a new release of Taglibs breaks Apps, so be it. The production release of Apps would still work with the prior production release of Taglibs. Bring out Taglibs, and then fix Apps.
>
As I mentioned above, some of the testing of Taglibs happens though
the use of one of the Apps, so I'd prefer to see at least that app
work before bringing out Taglibs.
> When we have a set of production subproject releases that all play well together, we could roll a new distribution. But, we would not have to roll a new distribution every time a subproject brought out a new release. Only when the pieces fit together.
>
If we make it easy enough for people to grab the pieces they need, we
might not need the bundle eventually. But people will expect it in the
near term, so we should provide it.
> The one thing I don't ever want to get into again is another 1.1 death march, where we are trying to fix several things at once, and have to have everything perfect before we could release anything. Not releasing is very, very bad, since most teams can't use what we don't release. Given our limited resources, and the need to get things "out-there", we have to find a way to do things hand-over-hand.
>
Yep. I expect we'll learn how to do that in the process of breaking
things up, as we are. In fact, I suspect we'll learn things we never
knew about the source code, too. ;-)
--
Martin Cooper
> -Ted.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Taglibs and Tiles Extraction Issues
Posted by Ted Husted <hu...@apache.org>.
On Sat, 25 Dec 2004 00:31:24 -0800, Don Brown wrote:
> Well, technically, Tiles would be dependent on Struts-taglibs, not
> Struts core, but I agree, cloning the method is the easiest
> solution here. I mainly was using it as an opportunity to raise
> the larger issue of subprojects depending on other subprojects.
Which, as mentioned elsewhere, lacking a dependency on the Core implies that Tiles is not a good candidate for a Struts subproject anymore. A hard dependence on the Core is what keeps us from becoming an umbrella project.
I'd suggest that we continue to follow the "Commons" paradigm. Anything that can be reused should be pushed up into it's own distribution. Everything we distribute under struts.apache.org should be dependant on Core, and Core must not be dependant on anything else we distribute. As we have been doing, anything we can share, that is not dependant on Core, should be pushed down into Commons, or out into its own project (e.g., Tiles).
Anything that Core needs, that is itself dependant on Core, should be part of Core (e.g., TestCase).
On Mon, 27 Dec 2004 14:17:27 -0800, Don Brown wrote:
> Darn. I suppose we could make an examples subproject, but the
> original reason to have subprojects is the ability for them to have
> a separate release cycle, which wouldn't really apply to examples.
> On the other hand, it wouldn't be good to have code in Core that
> depends on subprojects.
As to "examples", are we not moving the web applications into an Apps subproject?
I'd suggest getting a Core milestone building first, so that we have a JAR that can be imported by other nascent subprojects, like Taglibs, Extras, and Apps.
I believe we are trying to follow a "divide-and-conquer" strategy. Subprojects should depend on milestone releases of other subprojects. So, we'd want to get a milestone of one thing out first, and then the other.
Obviously, everything is not going to work perfectly together the first time. We'd have to roll Core and Taglibs before making any Apps releases, and the Apps are going to expose oversights in the 1.0.0 milestones of Core and Taglibs. But we can make fixes and bring out new milestones of each until a distribution falls into place.
We might focus on rolling a Core milestone first. Once that is building, we can bring out a Taglibs milestone which is dependant on that. Then, Apps milestones that are dependant on Core and Taglibs. Rinse and repeat. Core/Taglibs/Extras/Apps. Later, Core/Taglibs/Extras/BSF/Flow/Apps. And so forth.
If we have trouble finding a sequence in which to build the subprojects, then a subproject might not be cohesive, and we might have to rethink the divisions. But, we should follow the code, and let the code tell us what belongs together.
One thing that would help make this work is a repository system. Either Maven's or our own. The Core JAR should build to a place-certain, and then the other subproject builds should be able to find that JAR and use it in their own builds. For example, each subproject can drop a JAR into a lib folder under the local copy of the Build project.
If a new release of Taglibs breaks Apps, so be it. The production release of Apps would still work with the prior production release of Taglibs. Bring out Taglibs, and then fix Apps.
When we have a set of production subproject releases that all play well together, we could roll a new distribution. But, we would not have to roll a new distribution every time a subproject brought out a new release. Only when the pieces fit together.
The one thing I don't ever want to get into again is another 1.1 death march, where we are trying to fix several things at once, and have to have everything perfect before we could release anything. Not releasing is very, very bad, since most teams can't use what we don't release. Given our limited resources, and the need to get things "out-there", we have to find a way to do things hand-over-hand.
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Taglibs and Tiles Extraction Issues
Posted by Don Brown <mr...@twdata.org>.
Martin Cooper wrote:
> On Fri, 24 Dec 2004 12:22:33 -0800, Don Brown <mr...@twdata.org> 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.
Well, technically, Tiles would be dependent on Struts-taglibs, not
Struts core, but I agree, cloning the method is the easiest solution
here. I mainly was using it as an opportunity to raise the larger issue
of subprojects depending on other subprojects.
>
> 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?)
Dunno, but I'll look into it.
Don
>
>
>>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: dev-unsubscribe@struts.apache.org
>>For additional commands, e-mail: dev-help@struts.apache.org
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Taglibs and Tiles Extraction Issues
Posted by Joe Germuska <Jo...@Germuska.com>.
At 2:19 PM -0800 12/27/04, Don Brown wrote:
>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:sabreware@earthlink.net]
>>>>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 <mr...@twdata.org>
>>>>>>>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: dev-unsubscribe@struts.apache.org
>>>>>>>>For additional commands, e-mail: dev-help@struts.apache.org
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>--------------------------------------------------------------------
>>>>
>>>>>>>-
>>>>>>>To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>>>>>>>For additional commands, e-mail: dev-help@struts.apache.org
>>>>>>>
>>>>>>
>>>>---------------------------------------------------------------------
>>>>
>>>>>>To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org For
>>>>>>additional commands, e-mail: dev-help@struts.apache.org
>>>>>
>>>>>
>>>>>
>>>>>
>>>>---------------------------------------------------------------------
>>>>
>>>>>To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>>>>>For additional commands, e-mail: dev-help@struts.apache.org
>>>>>
>>>>
>>>>
>>>>---------------------------------------------------------------------
>>>>To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>>>>For additional commands, e-mail: dev-help@struts.apache.org
>>>>
>>>
>>>
>>>---------------------------------------------------------------------
>>>To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>>>For additional commands, e-mail: dev-help@struts.apache.org
>>>
>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>>For additional commands, e-mail: dev-help@struts.apache.org
>>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>For additional commands, e-mail: dev-help@struts.apache.org
--
Joe Germuska
Joe@Germuska.com
http://blog.germuska.com
"Narrow minds are weapons made for mass destruction" -The Ex
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Taglibs and Tiles Extraction Issues
Posted by Don Brown <mr...@twdata.org>.
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.
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:sabreware@earthlink.net]
>>> 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 <mr...@twdata.org>
>>>>>> 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: dev-unsubscribe@struts.apache.org
>>>>>>> For additional commands, e-mail: dev-help@struts.apache.org
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>> --------------------------------------------------------------------
>>>
>>>>>> -
>>>>>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>>>>>> For additional commands, e-mail: dev-help@struts.apache.org
>>>>>>
>>>>>
>>> ---------------------------------------------------------------------
>>>
>>>>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org For
>>>>> additional commands, e-mail: dev-help@struts.apache.org
>>>>
>>>>
>>>>
>>>>
>>> ---------------------------------------------------------------------
>>>
>>>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>>>> For additional commands, e-mail: dev-help@struts.apache.org
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>>> For additional commands, e-mail: dev-help@struts.apache.org
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>> For additional commands, e-mail: dev-help@struts.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Taglibs and Tiles Extraction Issues
Posted by Vic <vi...@friendvu.com>.
Martin Cooper wrote:
>On Wed, 29 Dec 2004 09:46:17 -0700, David Geary <sa...@earthlink.net> wrote:
>
>
>>If Tiles stays with Apache do we have to go
>>through incubation? It'd be nice if we could skip incubation,
>>considering that Tiles has been incubating in Struts for years. 8-)
>>
>>
>
>I think that we should be able to avoid incubation.
>
I think you should take advantage as a top level project, make your own
rules for a sub project. In this case... I think Struts makes a
subproject, DG does tiles, and later guidelines get writen up about how
to become a subproject or a Struts incubator.
.V
--
RiA-SoA w/JDNC <http://www.SandraSF.com> forums
- help develop a community
My blog <http://www.sandrasf.com/adminBlog>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Taglibs and Tiles Extraction Issues
Posted by Martin Cooper <mf...@gmail.com>.
On Wed, 29 Dec 2004 09:46:17 -0700, David Geary <sa...@earthlink.net> wrote:
> Le Dec 29, 2004, à 5:29 AM, Ted Husted a écrit :
>
> > On Sun, 26 Dec 2004 14:40:44 -0700, David Geary wrote:
> >> I'd like to see an open-source standalone version of Tiles. A
> >> toplevel Apache project is one way to do that.
> >
> > I'd support whatever you wanted to do, David.
> >
> > If you, or anyone else, wanted to apply for incubation, I'd help in
> > anyway I can.
>
> Thanks for the offer, Ted. If Tiles stays with Apache do we have to go
> through incubation? It'd be nice if we could skip incubation,
> considering that Tiles has been incubating in Struts for years. 8-)
I think that we should be able to avoid incubation. We simply need to
show that a community exists around Tiles itself. Once there is
activity on the code base, and active discussion of its future on the
lists, we should start to invite participants from places outside of
Struts, and then at some point create separate mailing lists to
support an independent community. (The model I'm thinking of here is
Commons HttpClient.) We can also devote a "sub-site" of the main
Struts site to Tiles to demonstrate our intent to grow Tiles as an
independent entity. Then, when the community thinks it's ready, Tiles
could be proposed as an Apache TLP.
Much of this is similar to going through incubation, except that I
think it will go faster by starting within Struts, because of the
large Struts community, and large number of folks within that
community that already use Tiles. There are already members of our
community here who use Tiles with technologies other than Struts (e.g.
Velocity and JSF / MyFaces), so I don't think that will be a stumbling
block.
--
Martin Cooper
> > Or, if someone made a home for Tiles at SourceForge or Tigris or
> > Codehaus, that would be great too.
>
> java.net is also an option.
>
> > That a community and its codebase lives is more important than where
> > it lives.
>
> Absolutely.
>
>
> david
> >
> > -Ted.
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> > For additional commands, e-mail: dev-help@struts.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: TL Tiles (was Re: Taglibs and Tiles Extraction Issues)
Posted by Martin Cooper <mf...@gmail.com>.
On Thu, 06 Jan 2005 22:43:53 -0600, Vic <vi...@friendvu.com> wrote:
>
> For the slow people: Is Tiles moving as it's own Apache project... not a
> Struts sub-project?
Yah, I'm pretty sure that's what the "TopLevel" means in the name of
the "TilesTopLevel" wiki page. ;-)
> (I do not care, just... I assumed that since Struts was a Top level
> project, it had freedom to do as it pleases)
Up to a point, yes. But I think with Tiles, the idea is that it
shouldn't be tied to any one framework, so it makes more sense for it
to live an independent life, rather than be buried within Struts. That
will give it greater visibility, hopefully leading to more widespread
adoption, and the option of collecting together the Tiles adapters for
multiple frameworks, such as Struts, Velocity and MyFaces, for
starters.
--
Martin Cooper
> .V
>
> --
> RiA-SoA w/JDNC <http://www.SandraSF.com> forums
> - help develop a community
> My blog <http://www.sandrasf.com/adminBlog>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: TL Tiles (was Re: Taglibs and Tiles Extraction Issues)
Posted by Vic <vi...@friendvu.com>.
For the slow people: Is Tiles moving as it's own Apache project... not a
Struts sub-project?
(I do not care, just... I assumed that since Struts was a Top level
project, it had freedom to do as it pleases)
.V
--
RiA-SoA w/JDNC <http://www.SandraSF.com> forums
- help develop a community
My blog <http://www.sandrasf.com/adminBlog>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: TL Tiles (was Re: Taglibs and Tiles Extraction Issues)
Posted by Martin Cooper <mf...@gmail.com>.
On Thu, 6 Jan 2005 20:24:45 -0500, Ted Husted <hu...@apache.org> wrote:
> OK, there's a draft proposal up at [http://wiki.apache.org/struts/TilesTopLevel].
I noticed that the proposal mentions Jira. Without getting into a big
flap about which one is better, I just wanted to point out that it
would be much simpler to reallocate bugs in the Struts bug database to
Tiles if Tiles uses Bugzilla.
--
Martin Cooper
> [Tell you what, after working in Confluence all day, Moin Moin feels like a jalopy :)]
>
> On Wed, 29 Dec 2004 19:10:45 -0700, David Geary wrote:
> > Le Dec 29, 2004, à 4:44 PM, Ted Husted a écrit :
> >
> >> Since there seems to be interest, why don't I setup the usual
> >> proposal on the incubator wiki, and we can see who signs up.
> >>
> >> Even if we were able to dodge "incubation" per se, we would still
> >> need to bring a resolution to the board, and do all the same
> >> infrastructure things.
> >>
> >
> > Excellent. I'm really excited about this. Let's do it.
> >
> >> David, if you wanted to contribute the package you extracted to
> >> Struts, as Martin indicated, it would make it easier to frame the
> >> proposal.
> >>
> >
> > Sure, I'd be happy to do that.
> >
> >> Then, we could just remove it from the Core, rather than extract
> >> it, and when the time comes, just move it from one Apache
> >> instance to another.
> >>
> >
> > Okay.
> >
> >> As mentioned, we can restore your karma upon request. (Merit
> >> never expires.) All you would need to do is file a CLA
> >> [http://apache.org/licenses/icla.txt] and ask us to update your
> >> status.
> >>
> >
> > I'll do that also.
> >
> >
> > david
> >
> >>
> >> -Ted.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: TL Tiles (was Re: Taglibs and Tiles Extraction Issues)
Posted by David Geary <sa...@earthlink.net>.
This is great news. Thanks, Ted.
david
Le Jan 6, 2005, à 8:24 PM, Ted Husted a écrit :
> OK, there's a draft proposal up at
> [http://wiki.apache.org/struts/TilesTopLevel].
>
> [Tell you what, after working in Confluence all day, Moin Moin feels
> like a jalopy :)]
>
> On Wed, 29 Dec 2004 19:10:45 -0700, David Geary wrote:
>> Le Dec 29, 2004, à 4:44 PM, Ted Husted a écrit :
>>
>>> Since there seems to be interest, why don't I setup the usual
>>> proposal on the incubator wiki, and we can see who signs up.
>>>
>>> Even if we were able to dodge "incubation" per se, we would still
>>> need to bring a resolution to the board, and do all the same
>>> infrastructure things.
>>>
>>
>> Excellent. I'm really excited about this. Let's do it.
>>
>>> David, if you wanted to contribute the package you extracted to
>>> Struts, as Martin indicated, it would make it easier to frame the
>>> proposal.
>>>
>>
>> Sure, I'd be happy to do that.
>>
>>> Then, we could just remove it from the Core, rather than extract
>>> it, and when the time comes, just move it from one Apache
>>> instance to another.
>>>
>>
>> Okay.
>>
>>> As mentioned, we can restore your karma upon request. (Merit
>>> never expires.) All you would need to do is file a CLA
>>> [http://apache.org/licenses/icla.txt] and ask us to update your
>>> status.
>>>
>>
>> I'll do that also.
>>
>>
>> david
>>
>>>
>>> -Ted.
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: TL Tiles (was Re: Taglibs and Tiles Extraction Issues)
Posted by Levieux Cedric <ce...@europatrust.com>.
Hi,
+1 too cause it save a lot of work for any jsp pages struts or not and it's
a really mature project.
By the way it really need to be extended.
Regards,
Cedric Levieux
----- Original Message -----
From: "Cedric Dumoulin" <ce...@lifl.fr>
To: "Struts Developers List" <de...@struts.apache.org>
Sent: Friday, January 07, 2005 5:53 PM
Subject: Re: TL Tiles (was Re: Taglibs and Tiles Extraction Issues)
>
> Hello everybody,
>
> I'am +1 in Tiles becoming a top level project, or at least to be
> extracted from the Struts core.
> You can add me in the set of initial committersin the draft proposal,
> if you agree.
>
> Cedric
>
>
> Ted Husted wrote:
>
> >OK, there's a draft proposal up at
[http://wiki.apache.org/struts/TilesTopLevel].
> >
> >[Tell you what, after working in Confluence all day, Moin Moin feels like
a jalopy :)]
> >
> >
> >
> >
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: TL Tiles (was Re: Taglibs and Tiles Extraction Issues)
Posted by Ted Husted <hu...@apache.org>.
It's a wiki, Cedric :) -- Feel free to add your own name, as well as any other likely changes. :)
-Ted.
On Fri, 07 Jan 2005 17:53:07 +0100, Cedric Dumoulin wrote:
>
> Hello everybody,
>
> I'am +1 in Tiles becoming a top level project, or at least to be
> extracted from the Struts core.
> You can add me in the set of initial committersin the draft
> proposal, if you agree.
>
> Cedric
>
>
> Ted Husted wrote:
>
>> OK, there's a draft proposal up at
>> [http://wiki.apache.org/struts/TilesTopLevel].
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: TL Tiles (was Re: Taglibs and Tiles Extraction Issues)
Posted by Cedric Dumoulin <ce...@lifl.fr>.
Hello everybody,
I'am +1 in Tiles becoming a top level project, or at least to be
extracted from the Struts core.
You can add me in the set of initial committersin the draft proposal,
if you agree.
Cedric
Ted Husted wrote:
>OK, there's a draft proposal up at [http://wiki.apache.org/struts/TilesTopLevel].
>
>[Tell you what, after working in Confluence all day, Moin Moin feels like a jalopy :)]
>
>
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: TL Tiles (was Re: Taglibs and Tiles Extraction Issues)
Posted by Ted Husted <hu...@apache.org>.
OK, there's a draft proposal up at [http://wiki.apache.org/struts/TilesTopLevel].
[Tell you what, after working in Confluence all day, Moin Moin feels like a jalopy :)]
On Wed, 29 Dec 2004 19:10:45 -0700, David Geary wrote:
> Le Dec 29, 2004, à 4:44 PM, Ted Husted a écrit :
>
>> Since there seems to be interest, why don't I setup the usual
>> proposal on the incubator wiki, and we can see who signs up.
>>
>> Even if we were able to dodge "incubation" per se, we would still
>> need to bring a resolution to the board, and do all the same
>> infrastructure things.
>>
>
> Excellent. I'm really excited about this. Let's do it.
>
>> David, if you wanted to contribute the package you extracted to
>> Struts, as Martin indicated, it would make it easier to frame the
>> proposal.
>>
>
> Sure, I'd be happy to do that.
>
>> Then, we could just remove it from the Core, rather than extract
>> it, and when the time comes, just move it from one Apache
>> instance to another.
>>
>
> Okay.
>
>> As mentioned, we can restore your karma upon request. (Merit
>> never expires.) All you would need to do is file a CLA
>> [http://apache.org/licenses/icla.txt] and ask us to update your
>> status.
>>
>
> I'll do that also.
>
>
> david
>
>>
>> -Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: TL Tiles (was Re: Taglibs and Tiles Extraction Issues)
Posted by David Geary <sa...@earthlink.net>.
Le Dec 29, 2004, à 4:44 PM, Ted Husted a écrit :
> Since there seems to be interest, why don't I setup the usual proposal
> on the incubator wiki, and we can see who signs up.
>
> Even if we were able to dodge "incubation" per se, we would still need
> to bring a resolution to the board, and do all the same infrastructure
> things.
Excellent. I'm really excited about this. Let's do it.
> David, if you wanted to contribute the package you extracted to
> Struts, as Martin indicated, it would make it easier to frame the
> proposal.
Sure, I'd be happy to do that.
> Then, we could just remove it from the Core, rather than extract it,
> and when the time comes, just move it from one Apache instance to
> another.
Okay.
> As mentioned, we can restore your karma upon request. (Merit never
> expires.) All you would need to do is file a CLA
> [http://apache.org/licenses/icla.txt] and ask us to update your
> status.
I'll do that also.
david
>
> -Ted.
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
TL Tiles (was Re: Taglibs and Tiles Extraction Issues)
Posted by Ted Husted <hu...@apache.org>.
On Wed, 22 Dec 2004 12:19:25 -0800, Nathan Bubna wrote:
> You can indeed use Velocity+Tiles:
>
> http://jakarta.apache.org/velocity/tools/javadoc/org/apache/velocity/t
> ools/struts/TilesTool.html
On Fri, 24 Dec 2004 15:41:38 -0700, 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?
On Wed, 29 Dec 2004 21:20:37 +0100, Matthias Wessendorf wrote:
> We have some extra components in MyFaces. Custom validators based
> on Commons Validator. Now I am about to include a RenderKit for
> WML. Also support for Tiles see:
> http://www.apache.org/~matzew/myfaces-tiles-example.war Perhaps we
> could bring the MyFaces' TilesViewHandler to David's coming Tiles
> project.
> BTW. I would like to see this project inside of Apache ...
On Wed, 29 Dec 2004 13:51:38 -0500, Ted Husted wrote:
> Incubation doesn't have to be a lengthy process.
>
> * Float a proposal on general@incubator
> * Setup the usual resources (lists, issues, repository, website,
> status file) * Tick off the boxes on the incubator check list *
> Apply to exit
>
> If the Contributor License Agreements are already on file,
> conceivably, it could all be done the same week.
>
> All you really need is a Member to advocate the proposal.
>
> I could do it, but I already have two projects in incubation, so if
> there were another volunteer, that would be better.
Since there seems to be interest, why don't I setup the usual proposal on the incubator wiki, and we can see who signs up.
Even if we were able to dodge "incubation" per se, we would still need to bring a resolution to the board, and do all the same infrastructure things.
David, if you wanted to contribute the package you extracted to Struts, as Martin indicated, it would make it easier to frame the proposal. Then, we could just remove it from the Core, rather than extract it, and when the time comes, just move it from one Apache instance to another. As mentioned, we can restore your karma upon request. (Merit never expires.) All you would need to do is file a CLA [http://apache.org/licenses/icla.txt] and ask us to update your status.
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Taglibs and Tiles Extraction Issues
Posted by Ted Husted <hu...@apache.org>.
The incubation process is where we setup the project infrastructure now, so, yes.
The code and community were created here, and so that part is already done.
Incubation doesn't have to be a lengthy process.
* Float a proposal on general@incubator
* Setup the usual resources (lists, issues, repository, website, status file)
* Tick off the boxes on the incubator check list
* Apply to exit
If the Contributor License Agreements are already on file, conceivably, it could all be done the same week.
All you really need is a Member to advocate the proposal.
I could do it, but I already have two projects in incubation, so if there were another volunteer, that would be better.
-Ted.
On Wed, 29 Dec 2004 09:46:17 -0700, David Geary wrote:
> Le Dec 29, 2004, à 5:29 AM, Ted Husted a écrit :
>
>> On Sun, 26 Dec 2004 14:40:44 -0700, David Geary wrote:
>>
>>> I'd like to see an open-source standalone version of Tiles. A
>>> toplevel Apache project is one way to do that.
>>>
>>
>> I'd support whatever you wanted to do, David.
>>
>> If you, or anyone else, wanted to apply for incubation, I'd help
>> in anyway I can.
>>
>
> Thanks for the offer, Ted. If Tiles stays with Apache do we have to
> go through incubation? It'd be nice if we could skip incubation,
> considering that Tiles has been incubating in Struts for years. 8-)
>
>> Or, if someone made a home for Tiles at SourceForge or Tigris or
>> Codehaus, that would be great too.
>>
>
> java.net is also an option.
>
>> That a community and its codebase lives is more important than
>> where it lives.
>>
>
> Absolutely.
>
>
> david
>
>> -Ted.
>>
>>
>> ------------------------------------------------------------------
>> --- To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org For
>> additional commands, e-mail: dev-help@struts.apache.org
>>
>
> --------------------------------------------------------------------
> - To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org For
> additional commands, e-mail: dev-help@struts.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Taglibs and Tiles Extraction Issues
Posted by David Geary <sa...@earthlink.net>.
Le Dec 29, 2004, à 5:29 AM, Ted Husted a écrit :
> On Sun, 26 Dec 2004 14:40:44 -0700, David Geary wrote:
>> I'd like to see an open-source standalone version of Tiles. A
>> toplevel Apache project is one way to do that.
>
> I'd support whatever you wanted to do, David.
>
> If you, or anyone else, wanted to apply for incubation, I'd help in
> anyway I can.
Thanks for the offer, Ted. If Tiles stays with Apache do we have to go
through incubation? It'd be nice if we could skip incubation,
considering that Tiles has been incubating in Struts for years. 8-)
> Or, if someone made a home for Tiles at SourceForge or Tigris or
> Codehaus, that would be great too.
java.net is also an option.
> That a community and its codebase lives is more important than where
> it lives.
Absolutely.
david
>
> -Ted.
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
RE: Taglibs and Tiles Extraction Issues
Posted by Matthias Wessendorf <ma...@matthias-wessendorf.de>.
> That a community and its codebase lives is more important
> than where it lives.
Yes, that's it! And also it is important, to have one place
where it lives! Not much different. So I would be happy to
move the JSF TilesViewHandler from MyFaces to that (new) repository.
> -Ted.
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Taglibs and Tiles Extraction Issues
Posted by Ted Husted <hu...@apache.org>.
On Sun, 26 Dec 2004 14:40:44 -0700, David Geary wrote:
> I'd like to see an open-source standalone version of Tiles. A
> toplevel Apache project is one way to do that.
I'd support whatever you wanted to do, David.
If you, or anyone else, wanted to apply for incubation, I'd help in anyway I can.
Or, if someone made a home for Tiles at SourceForge or Tigris or Codehaus, that would be great too.
That a community and its codebase lives is more important than where it lives.
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Taglibs and Tiles Extraction Issues
Posted by David Geary <sa...@earthlink.net>.
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:sabreware@earthlink.net]
>> 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 <mr...@twdata.org>
>>>>> 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: dev-unsubscribe@struts.apache.org
>>>>>> For additional commands, e-mail: dev-help@struts.apache.org
>>>>>>
>>>>>>
>>>>>
>>>>>
>> --------------------------------------------------------------------
>>>>> -
>>>>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>>>>> For additional commands, e-mail: dev-help@struts.apache.org
>>>>>
>>>>
>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org For
>>>> additional commands, e-mail: dev-help@struts.apache.org
>>>
>>>
>>>
>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>>> For additional commands, e-mail: dev-help@struts.apache.org
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>> For additional commands, e-mail: dev-help@struts.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
RE: Taglibs and Tiles Extraction Issues
Posted by Matthias Wessendorf <ma...@matthias-wessendorf.de>.
David,
are you thinking about bringing Tiles up to
incubator ? To be a *toplevel* apache project
like Struts itself?
And yes... Merry Christmas ;-)
Matthias
> -----Original Message-----
> From: David Geary [mailto:sabreware@earthlink.net]
> 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 <mr...@twdata.org>
> >>> 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: dev-unsubscribe@struts.apache.org
> >>>> For additional commands, e-mail: dev-help@struts.apache.org
> >>>>
> >>>>
> >>>
> >>>
> --------------------------------------------------------------------
> >>> -
> >>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> >>> For additional commands, e-mail: dev-help@struts.apache.org
> >>>
> >>
> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org For
> >> additional commands, e-mail: dev-help@struts.apache.org
> >
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> > For additional commands, e-mail: dev-help@struts.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Taglibs and Tiles Extraction Issues
Posted by David Geary <sa...@earthlink.net>.
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 <mr...@twdata.org>
>>> 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: dev-unsubscribe@struts.apache.org
>>>> For additional commands, e-mail: dev-help@struts.apache.org
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>>> For additional commands, e-mail: dev-help@struts.apache.org
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>> For additional commands, e-mail: dev-help@struts.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Taglibs and Tiles Extraction Issues
Posted by Don Brown <mr...@twdata.org>.
I don't know about the other Struts folks, but I think this is would be
a great addition to Tiles. 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.
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 <mr...@twdata.org> 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: dev-unsubscribe@struts.apache.org
>>> For additional commands, e-mail: dev-help@struts.apache.org
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>> For additional commands, e-mail: dev-help@struts.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
RE: Taglibs and Tiles Extraction Issues
Posted by Matthias Wessendorf <ma...@matthias-wessendorf.de>.
> 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.
that sounds nice!
Using Tiles *standalone* is fine!
Btw. have you looked at MyFaces' ViewHandler
for JSF?
> 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.
I guess it is worth to have *core* tiles + *adapters* for
Velocity, Tapestry, JSF, Struts, yet another framework
> 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?
As I said (my personal thoughts):
a *core* Tiles version (or call it standalone) is fine.
So why not having adapters for other frameworks.
In MyFaces we include struts.jar for be able to build
our ViewHandler. But this JAR contains *more* than we
realy want :-)
so I am +1 having tiles *core* as standalone...
Regards,
Matthias
> david
>
> Le Dec 24, 2004, à 3:30 PM, Martin Cooper a écrit :
>
> > On Fri, 24 Dec 2004 12:22:33 -0800, Don Brown <mr...@twdata.org>
> > 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: dev-unsubscribe@struts.apache.org For
> >> additional commands, e-mail: dev-help@struts.apache.org
> >>
> >>
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> > For additional commands, e-mail: dev-help@struts.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Taglibs and Tiles Extraction Issues
Posted by David Geary <sa...@earthlink.net>.
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 <mr...@twdata.org> 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: dev-unsubscribe@struts.apache.org
>> For additional commands, e-mail: dev-help@struts.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Taglibs and Tiles Extraction Issues
Posted by Martin Cooper <mf...@gmail.com>.
On Fri, 31 Dec 2004 12:16:10 -0600, Joe Germuska <Jo...@germuska.com> wrote:
> At 10:03 AM -0800 12/31/04, Martin Cooper wrote:
> > > Probably, the same thing should be done for Jakarta Commons.
> >There are way too many Commons-This and Commons-That.
> >>
> >
> >Agreed. The Maven <dependency> elements support this for obtaining the
> >dependencies, but I don't know what changes we'd need to make to the
> >project.xml files to get the deploy to deal with that. Hopefully
> >someone on the Commons list will know.
>
> I'm not sure if I understand the question. If it's simply "how to
> construct project.xml so that a JAR is deployed correctly with maven
> jar:deploy", then the answer is also simple. The EL project.xml is
> set up correctly:
Cool. Thanks, Joe, that was exactly the question. I looked at a few
Commons components, and didn't see anything like that specified, so
didn't see how this worked. As I've said before, I'm not much of a
Maven maven. ;-)
--
Martin Cooper
>
> <project>
> ...
> <id>struts-el</id>
> <groupId>struts</groupId>
> ....
> </project>
>
> Joe
>
> --
> Joe Germuska
> Joe@Germuska.com
> http://blog.germuska.com
> "Narrow minds are weapons made for mass destruction" -The Ex
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Taglibs and Tiles Extraction Issues
Posted by Joe Germuska <Jo...@Germuska.com>.
At 10:03 AM -0800 12/31/04, Martin Cooper wrote:
> > Probably, the same thing should be done for Jakarta Commons.
>There are way too many Commons-This and Commons-That.
>>
>
>Agreed. The Maven <dependency> elements support this for obtaining the
>dependencies, but I don't know what changes we'd need to make to the
>project.xml files to get the deploy to deal with that. Hopefully
>someone on the Commons list will know.
I'm not sure if I understand the question. If it's simply "how to
construct project.xml so that a JAR is deployed correctly with maven
jar:deploy", then the answer is also simple. The EL project.xml is
set up correctly:
<project>
...
<id>struts-el</id>
<groupId>struts</groupId>
....
</project>
Joe
--
Joe Germuska
Joe@Germuska.com
http://blog.germuska.com
"Narrow minds are weapons made for mass destruction" -The Ex
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Taglibs and Tiles Extraction Issues
Posted by Martin Cooper <mf...@gmail.com>.
On Wed, 29 Dec 2004 07:29:46 -0500, Ted Husted <hu...@apache.org> wrote:
>
> On Fri, 24 Dec 2004 14:30:24 -0800, Martin Cooper wrote:
> > Struts as a group and Struts subprojects as artifacts within that
> > group (using Maven terminology here ;).
>
> +1
>
> The big difference here being that there would only be one top-level Struts entry in a Maven repository, and the various Struts JARs would be nested under that.
>
Yes, that's what we get by using a 'struts' group and then artifacts within it.
> Probably, the same thing should be done for Jakarta Commons. There are way too many Commons-This and Commons-That.
>
Agreed. The Maven <dependency> elements support this for obtaining the
dependencies, but I don't know what changes we'd need to make to the
project.xml files to get the deploy to deal with that. Hopefully
someone on the Commons list will know.
> > 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).
>
> Thanks for all you hard work on this, Martin. Working on build systems drives me batty :)
>
> And I do hope you and yours have a happy Hogmanay!
Thanks! And a Happy Hogmanay to you too!
--
Martin Cooper
> -Ted.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Taglibs and Tiles Extraction Issues
Posted by Ted Husted <hu...@apache.org>.
On Fri, 24 Dec 2004 14:30:24 -0800, Martin Cooper wrote:
>�Struts as a group and Struts subprojects as artifacts within that
>�group (using Maven terminology here ;).
+1
The big difference here being that there would only be one top-level Struts entry in a Maven repository, and the various Struts JARs would be nested under that.
Probably, the same thing should be done for Jakarta Commons. There are way too many Commons-This and Commons-That.
>�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).
Thanks for all you hard work on this, Martin. Working on build systems drives me batty :)
And I do hope you and yours have a happy Hogmanay!
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Taglibs and Tiles Extraction Issues
Posted by Martin Cooper <mf...@gmail.com>.
On Fri, 24 Dec 2004 12:22:33 -0800, Don Brown <mr...@twdata.org> 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: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org