On 7/12/05, David Geary <[EMAIL PROTECTED]> wrote:
> 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.
Agreed that we should move quickly on convergence.
>
> >> 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?
>
That would certainly be a goal for having Tiles standalone in the
first place -- it would need to be something we (Struts project) can
vote on and release as a separate artifact. That same artifcat could
then be incorporated into an overall Struts 1.x release, or
incorporated in non-Struts-1.x projects as well.
> >
> > * 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.
>
Seems so ... but I was just reiterating the original thinking.
> > * 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
Craig
> >
> >
> >> 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]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
