You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@struts.apache.org by James Mitchell <jm...@apache.org> on 2005/07/12 05:04:46 UTC
Tiles
Sorry if I've been out of the loop.
What's going on with Tiles under sandbox/trunk? Last I heard, we were going
to change Tiles (HEAD) to be free of it's dependency on Struts. What is
under the sandbox? It seems like a modification based off of some old
version of Tiles. Am I missing something?
--
James Mitchell
Software Engineer / Open Source Evangelist
Consulting / Mentoring / Freelance
EdgeTech, Inc.
http://www.edgetechservices.net/
678.910.8017
AIM: jmitchtx
MSN: jmitchell@apache.org
Skype: jmitchtx
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Tiles
Posted by David Geary <sa...@earthlink.net>.
Le 05-07-11 à 21:04, James Mitchell a écrit :
> Sorry if I've been out of the loop.
>
> What's going on with Tiles under sandbox/trunk? Last I heard, we
> were going to change Tiles (HEAD) to be free of it's dependency on
> Struts. What is under the sandbox? It seems like a modification
> based off of some old version of Tiles. Am I missing something?
It's a standalone version of Tiles taken from Struts 1.1. When I
originally ripped it out of Struts, it never occurred to me that it
might be folded back into Struts at a later time, so I wasn't
concerned about losing the few Tiles code changes from 1.1 to 1.2.
However, it appears that the strategy now is to unplug the current
version of Tiles from Struts and hook it up to the standalone
version, so those changes (along with CVS history) are suddenly
important.
Neil Pemberton pointed out the stale code and loss of history in a
post to this list shortly after I committed standalone Tiles to the
sandbox and I agreed to fix it. As a matter of fact, I'd appreciate
some feedback on how to do that. AFAICT, I'll have to svn copy from
the current version of Struts and then re-rip Tiles from that tree.
If anyone has a power-SVN solution that would avoid that pain, I'd
like to hear about it.
david
>
>
> --
> James Mitchell
> Software Engineer / Open Source Evangelist
> Consulting / Mentoring / Freelance
> EdgeTech, Inc.
> http://www.edgetechservices.net/
> 678.910.8017
> AIM: jmitchtx
> MSN: jmitchell@apache.org
> Skype: jmitchtx
>
>
>
> ---------------------------------------------------------------------
> 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: Tiles
Posted by Craig McClanahan <cr...@gmail.com>.
On 7/12/05, David Geary <sa...@earthlink.net> wrote:
> Le 05-07-11 à 23:54, Craig McClanahan a écrit :
>
> > On 7/11/05, James Mitchell <jm...@apache.org> 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: 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: Tiles
Posted by David Geary <sa...@earthlink.net>.
Le 05-07-11 à 23:54, Craig McClanahan a écrit :
> On 7/11/05, James Mitchell <jm...@apache.org> 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: 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: Tiles
Posted by Craig McClanahan <cr...@gmail.com>.
On 7/11/05, James Mitchell <jm...@apache.org> wrote:
> I assumed that was the case.
>
> So, what happens now? Does org.apache.tiles continue to grow under the
> sandbox? Can I move tiles/trunk to some legacy location that is not pulled
> into current/, then move sandbox/tiles to where the original was?
>
> 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).
* 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).
* 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.
> James Mitchell
Craig
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Tiles
Posted by James Mitchell <jm...@apache.org>.
I assumed that was the case.
So, what happens now? Does org.apache.tiles continue to grow under the
sandbox? Can I move tiles/trunk to some legacy location that is not pulled
into current/, then move sandbox/tiles to where the original was?
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?
--
James Mitchell
Software Engineer / Open Source Evangelist
Consulting / Mentoring / Freelance
EdgeTech, Inc.
http://www.edgetechservices.net/
678.910.8017
AIM: jmitchtx
MSN: jmitchell@apache.org
Skype: jmitchtx
----- Original Message -----
From: "Craig McClanahan" <cr...@gmail.com>
To: "Struts Developers List" <de...@struts.apache.org>; "Sean Schofield"
<se...@gmail.com>
Sent: Monday, July 11, 2005 11:47 PM
Subject: Re: Tiles
On 7/11/05, Sean Schofield <se...@gmail.com> wrote:
> I believe the version under sandbox is the standalone Tiles that David
> Geary just finished. I haven't been following the discussions as to
> where it should go, but that is what it is. I built it and used with
> Shale. Looks good.
This (sandbox/tiles) is indeed the version that is independent of the
Struts core. Martin pointed out a bunch of TODOs in a previous thread
that still need to be dealt with (including applying some patches that
went in to the 1.2 version of Tiles that is integrated with Struts),
and there are likely some additional issues yet to be discovered, but
this code does indeed work without Struts 1.x in the classpath.
Craig
>
> sean
>
> On 7/11/05, James Mitchell <jm...@apache.org> wrote:
> > Sorry if I've been out of the loop.
> >
> > What's going on with Tiles under sandbox/trunk? Last I heard, we were
> > going
> > to change Tiles (HEAD) to be free of it's dependency on Struts. What is
> > under the sandbox? It seems like a modification based off of some old
> > version of Tiles. Am I missing something?
> >
> >
> > --
> > James Mitchell
> > Software Engineer / Open Source Evangelist
> > Consulting / Mentoring / Freelance
> > EdgeTech, Inc.
> > http://www.edgetechservices.net/
> > 678.910.8017
> > AIM: jmitchtx
> > MSN: jmitchell@apache.org
> > Skype: jmitchtx
> >
> >
> >
> > ---------------------------------------------------------------------
> > 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: Tiles
Posted by Craig McClanahan <cr...@gmail.com>.
On 7/11/05, Sean Schofield <se...@gmail.com> wrote:
> I believe the version under sandbox is the standalone Tiles that David
> Geary just finished. I haven't been following the discussions as to
> where it should go, but that is what it is. I built it and used with
> Shale. Looks good.
This (sandbox/tiles) is indeed the version that is independent of the
Struts core. Martin pointed out a bunch of TODOs in a previous thread
that still need to be dealt with (including applying some patches that
went in to the 1.2 version of Tiles that is integrated with Struts),
and there are likely some additional issues yet to be discovered, but
this code does indeed work without Struts 1.x in the classpath.
Craig
>
> sean
>
> On 7/11/05, James Mitchell <jm...@apache.org> wrote:
> > Sorry if I've been out of the loop.
> >
> > What's going on with Tiles under sandbox/trunk? Last I heard, we were going
> > to change Tiles (HEAD) to be free of it's dependency on Struts. What is
> > under the sandbox? It seems like a modification based off of some old
> > version of Tiles. Am I missing something?
> >
> >
> > --
> > James Mitchell
> > Software Engineer / Open Source Evangelist
> > Consulting / Mentoring / Freelance
> > EdgeTech, Inc.
> > http://www.edgetechservices.net/
> > 678.910.8017
> > AIM: jmitchtx
> > MSN: jmitchell@apache.org
> > Skype: jmitchtx
> >
> >
> >
> > ---------------------------------------------------------------------
> > 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: Tiles
Posted by Sean Schofield <se...@gmail.com>.
I believe the version under sandbox is the standalone Tiles that David
Geary just finished. I haven't been following the discussions as to
where it should go, but that is what it is. I built it and used with
Shale. Looks good.
sean
On 7/11/05, James Mitchell <jm...@apache.org> wrote:
> Sorry if I've been out of the loop.
>
> What's going on with Tiles under sandbox/trunk? Last I heard, we were going
> to change Tiles (HEAD) to be free of it's dependency on Struts. What is
> under the sandbox? It seems like a modification based off of some old
> version of Tiles. Am I missing something?
>
>
> --
> James Mitchell
> Software Engineer / Open Source Evangelist
> Consulting / Mentoring / Freelance
> EdgeTech, Inc.
> http://www.edgetechservices.net/
> 678.910.8017
> AIM: jmitchtx
> MSN: jmitchell@apache.org
> Skype: jmitchtx
>
>
>
> ---------------------------------------------------------------------
> 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