Le 05-07-11 à 23:54, Craig McClanahan a écrit :
On 7/11/05, James Mitchell <[EMAIL PROTECTED]> wrote:
I assumed that was the case.
So, what happens now? Does org.apache.tiles continue to grow
under the
sandbox?
We should try to minimize growth until we align it with the current
version of Struts Tiles because it seems as though we're going to
have to replace files (see my other reply to this thread's original
email). I'm keeping track of changes I see here, but things could get
out of hand if we were to diverge significantly before updating what
we currently have.
Can I move tiles/trunk to some legacy location that is not pulled
into current/, then move sandbox/tiles to where the original was?
Eventually we want to do something like that, but we need to align
with the current Struts Tiles first.
I'm not sure I understand what the plan is here, surely we are not
going to
maintain 2 sets of Tiles code...are we?
We definitely don't want to maintain two sets of code. As David Geary
likes to acronym-ize :-), DRY ("don't repeat yourself").
IIRC correcty, the original plan was along the lines of:
* Establish a stand alone releasable artifact for Tiles, not
dependent on the Struts 1.x core. (This involves both
technology and community; so it makes sense to start
within the Struts community and just adapt the technology).
I take it this means there will be someplace in Apache where you can
download the tiles-core.jar. Is that correct?
* Once the standalone Tiles is mature and functional,
migrate Struts to support it (while maintaining backwards
compatibility for the original mechanisms, even if deprecated,
for a reasonable amount of time).
Standalone Tiles is mature and functional now, isn't it? I think the
issues are that it's out of synch with the current Struts Tiles.
* Encourage other frameworks that have wanted a reusable
templating architecture to adopt standalone Tlles.
* If/when it makes sense, launch Tiles as a separate Jakarta
subproject or Apache top level project.
We're on the way towards the first goal ... the immmediate next steps
are to ensure that the standalone Tiles has *all* the functionality of
the current integrated version (and none of the bugs, of course :-).
Then, it's up to the developers focused on Struts 1.x to define a
migration strategy (possibly through re-implementing the
Struts-dependent org.apache.struts.tiles classes as wrappers around
the corresponding org.apache.tiles classes, or by supporting both the
new and old, and deprecating the old).
But we're only at the beginning of this path. Martin gave us a great
TODO list as a starting point in an earlier thread; I'm going to focus
some attention on addressing those issues.
I'm glad to hear that. 8-)
david
James Mitchell
Craig
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
