You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@struts.apache.org by Niall Pemberton <ni...@blueyonder.co.uk> on 2005/06/15 04:08:24 UTC
Initial checkin of standalone Tiles
I have a few concerns/questions about the initial checkin of standalone
Tiles into the sandbox, which David indicates in the SVN log is extracted
from Struts 1.1:
1) I'm wondering why this is based on Struts 1.1, rather than the current
version of tiles code? I did a quick scan (for starters) of the tiles taglib
and while there hasn't been a large amount of activity since Struts 1.1
there have been some bug fixes and some other minor changes and it seems a
shame to have to redo these changes rather than copying the current
versions.
2) IMO it would be better to use SVN copy to create the initial code base -
seems a shame to loose all the subversion history by adding these as new
artefacts. Since we have Struts 1.1 versions tagged they could be copied
either from the current versions or the Struts 1.1 versions.
3) The taglib package has been renamed to "org.apache.taglib.tiles" - I'm
wondering if this will create a confusion with the Jakarta Taglibs project
which uses "org.apache.taglibs.???" package name? Would this not be better
and more consistent as "org.apache.tiles.taglib"?
4) Similar question about the message resources which are being duplicated
from Struts - are we OK to use the "org.apache.util" package name for these
classes rather than "org.apache.tiles.util"? Also, its probably another
discussion, but maybe these need to be replaced with something else (commons
resources?) rather than duplicating from struts.
Niall
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Initial checkin of standalone Tiles
Posted by David Geary <sa...@earthlink.net>.
Le Jun 14, 2005 à 8:08 PM, Niall Pemberton a écrit :
> I have a few concerns/questions about the initial checkin of
> standalone
> Tiles into the sandbox, which David indicates in the SVN log is
> extracted
> from Struts 1.1:
>
> 1) I'm wondering why this is based on Struts 1.1, rather than the
> current
> version of tiles code? I did a quick scan (for starters) of the
> tiles taglib
> and while there hasn't been a large amount of activity since Struts
> 1.1
> there have been some bug fixes and some other minor changes and it
> seems a
> shame to have to redo these changes rather than copying the current
> versions.
>
> 2) IMO it would be better to use SVN copy to create the initial
> code base -
> seems a shame to loose all the subversion history by adding these
> as new
> artefacts. Since we have Struts 1.1 versions tagged they could be
> copied
> either from the current versions or the Struts 1.1 versions.
>
> 3) The taglib package has been renamed to "org.apache.taglib.tiles"
> - I'm
> wondering if this will create a confusion with the Jakarta Taglibs
> project
> which uses "org.apache.taglibs.???" package name? Would this not be
> better
> and more consistent as "org.apache.tiles.taglib"?
>
> 4) Similar question about the message resources which are being
> duplicated
> from Struts - are we OK to use the "org.apache.util" package name
> for these
> classes rather than "org.apache.tiles.util"? Also, its probably
> another
> discussion, but maybe these need to be replaced with something else
> (commons
> resources?) rather than duplicating from struts.
Thanks for the comments, Niall. All of your concerns are valid.
Looking through the code, it seems feasible to update the 1.1 code
with code from the latest Struts build. We should also be able to
rename packages.
I won't have time to work on this until after JavaOne, but I agree
that we should make these changes.
We should also start thinking about plugging Struts into the
standalone version of Tiles. I don't think we want to support two
versions of Tiles.
david
>
> Niall
>
>
>
>
>
>
> ---------------------------------------------------------------------
> 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: Initial checkin of standalone Tiles
Posted by Levieux Cedric <ce...@europatrust.com>.
Sounds fine for me.
Cedric
----- Original Message -----
From: "James Mitchell" <jm...@apache.org>
To: "Struts Developers List" <de...@struts.apache.org>
Sent: Thursday, July 14, 2005 6:06 AM
Subject: Re: Initial checkin of standalone Tiles
> That sounds great. Given the commit activity as of late, I doubt
> there will be anyone putting their tiles updates on hold while this
> happens ;)
>
>
> --
> James Mitchell
> Software Engineer / Open Source Evangelist
> Consulting / Mentoring / Freelance
> EdgeTech, Inc.
> http://www.edgetechservices.net/
> 678.910.8017
> AIM: jmitchtx
> Yahoo: jmitchtx
> MSN: jmitchell@apache.org
> Skype: jmitchtx
>
>
>
> On Jul 13, 2005, at 5:04 PM, Craig McClanahan wrote:
>
> > On 6/15/05, James Holmes <ja...@jamesholmes.com> wrote:
> >
> >> I'm with Martin and Niall.
> >>
> >
> > Having looked at this some more, I agree as well, and I'm willing to
> > do the work. The proposed plan is to:
> >
> > * "svn mv" the current contents of "sandbox/tiles" to someplace
> > archival
> > until the remaining steps are complete.
> >
> > * "svn copy" to establish the initial code base for "sandbox/tiles"
> > from the
> > trunk version of "tiles" (i.e. the latest and greatest version
> > that is used
> > in development releases of Struts).
> >
> > * Refactor the package names, taking into account the feedback above.
> > In particular:
> > - Base package name will be "org.apache.tiles".
> > - Tag library classes will be "org.apache.tiles.taglib"
> > - Any utility classes that are needed from Struts
> > will be "svn copy"d into "org.apache.tiles.util".
> >
> > * Add in appropriate versions of the old DTDs so that validating
> > the definitions
> > file does not attempt to access the Internet.
> >
> > * Establish a new (version 1.2) DTD so that standalone Tiles can
> > diverge
> > in the future if it needs to, without messing up the DTDs used
> > for 1.0 and 1.1
> > based applications.
> >
> > * When all is well, get rid of the previously archived version
> > of "sandbox/tiles".
> >
> > Does this sound like a reasonable plan?
> >
> > Craig
> >
> >
> >
> >>
> >> James
> >>
> >> -----Original Message-----
> >> From: Martin Cooper [mailto:martinc@apache.org]
> >> Sent: Wednesday, June 15, 2005 11:36 AM
> >> To: Struts Developers List
> >> Subject: Re: Initial checkin of standalone Tiles
> >>
> >> I agree with all of Niall's points below. I'm especially concerned
> >> at the
> >> loss of history mentioned in #2, since history can be so important.
> >>
> >> --
> >> Martin Cooper
> >>
> >>
> >> On Wed, 15 Jun 2005, Niall Pemberton wrote:
> >>
> >>
> >>> I have a few concerns/questions about the initial checkin of
> >>> standalone
> >>> Tiles into the sandbox, which David indicates in the SVN log is
> >>> extracted
> >>> from Struts 1.1:
> >>>
> >>> 1) I'm wondering why this is based on Struts 1.1, rather than the
> >>> current
> >>> version of tiles code? I did a quick scan (for starters) of the
> >>> tiles
> >>>
> >> taglib
> >>
> >>> and while there hasn't been a large amount of activity since
> >>> Struts 1.1
> >>> there have been some bug fixes and some other minor changes and
> >>> it seems a
> >>> shame to have to redo these changes rather than copying the current
> >>> versions.
> >>>
> >>> 2) IMO it would be better to use SVN copy to create the initial
> >>> code base
> >>>
> >> -
> >>
> >>> seems a shame to loose all the subversion history by adding these
> >>> as new
> >>> artefacts. Since we have Struts 1.1 versions tagged they could
> >>> be copied
> >>> either from the current versions or the Struts 1.1 versions.
> >>>
> >>> 3) The taglib package has been renamed to
> >>> "org.apache.taglib.tiles" - I'm
> >>> wondering if this will create a confusion with the Jakarta
> >>> Taglibs project
> >>> which uses "org.apache.taglibs.???" package name? Would this not
> >>> be better
> >>> and more consistent as "org.apache.tiles.taglib"?
> >>>
> >>> 4) Similar question about the message resources which are being
> >>> duplicated
> >>> from Struts - are we OK to use the "org.apache.util" package name
> >>> for
> >>>
> >> these
> >>
> >>> classes rather than "org.apache.tiles.util"? Also, its probably
> >>> another
> >>> discussion, but maybe these need to be replaced with something else
> >>>
> >> (commons
> >>
> >>> resources?) rather than duplicating from struts.
> >>>
> >>> Niall
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> --------------------------------------------------------------------
> >>> -
> >>> 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
>
>
>
>
> --
> No virus found in this incoming message.
> Checked by AVG Anti-Virus.
> Version: 7.0.323 / Virus Database: 267.8.14/48 - Release Date: 13/07/2005
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Initial checkin of standalone Tiles
Posted by James Mitchell <jm...@apache.org>.
That sounds great. Given the commit activity as of late, I doubt
there will be anyone putting their tiles updates on hold while this
happens ;)
--
James Mitchell
Software Engineer / Open Source Evangelist
Consulting / Mentoring / Freelance
EdgeTech, Inc.
http://www.edgetechservices.net/
678.910.8017
AIM: jmitchtx
Yahoo: jmitchtx
MSN: jmitchell@apache.org
Skype: jmitchtx
On Jul 13, 2005, at 5:04 PM, Craig McClanahan wrote:
> On 6/15/05, James Holmes <ja...@jamesholmes.com> wrote:
>
>> I'm with Martin and Niall.
>>
>
> Having looked at this some more, I agree as well, and I'm willing to
> do the work. The proposed plan is to:
>
> * "svn mv" the current contents of "sandbox/tiles" to someplace
> archival
> until the remaining steps are complete.
>
> * "svn copy" to establish the initial code base for "sandbox/tiles"
> from the
> trunk version of "tiles" (i.e. the latest and greatest version
> that is used
> in development releases of Struts).
>
> * Refactor the package names, taking into account the feedback above.
> In particular:
> - Base package name will be "org.apache.tiles".
> - Tag library classes will be "org.apache.tiles.taglib"
> - Any utility classes that are needed from Struts
> will be "svn copy"d into "org.apache.tiles.util".
>
> * Add in appropriate versions of the old DTDs so that validating
> the definitions
> file does not attempt to access the Internet.
>
> * Establish a new (version 1.2) DTD so that standalone Tiles can
> diverge
> in the future if it needs to, without messing up the DTDs used
> for 1.0 and 1.1
> based applications.
>
> * When all is well, get rid of the previously archived version
> of "sandbox/tiles".
>
> Does this sound like a reasonable plan?
>
> Craig
>
>
>
>>
>> James
>>
>> -----Original Message-----
>> From: Martin Cooper [mailto:martinc@apache.org]
>> Sent: Wednesday, June 15, 2005 11:36 AM
>> To: Struts Developers List
>> Subject: Re: Initial checkin of standalone Tiles
>>
>> I agree with all of Niall's points below. I'm especially concerned
>> at the
>> loss of history mentioned in #2, since history can be so important.
>>
>> --
>> Martin Cooper
>>
>>
>> On Wed, 15 Jun 2005, Niall Pemberton wrote:
>>
>>
>>> I have a few concerns/questions about the initial checkin of
>>> standalone
>>> Tiles into the sandbox, which David indicates in the SVN log is
>>> extracted
>>> from Struts 1.1:
>>>
>>> 1) I'm wondering why this is based on Struts 1.1, rather than the
>>> current
>>> version of tiles code? I did a quick scan (for starters) of the
>>> tiles
>>>
>> taglib
>>
>>> and while there hasn't been a large amount of activity since
>>> Struts 1.1
>>> there have been some bug fixes and some other minor changes and
>>> it seems a
>>> shame to have to redo these changes rather than copying the current
>>> versions.
>>>
>>> 2) IMO it would be better to use SVN copy to create the initial
>>> code base
>>>
>> -
>>
>>> seems a shame to loose all the subversion history by adding these
>>> as new
>>> artefacts. Since we have Struts 1.1 versions tagged they could
>>> be copied
>>> either from the current versions or the Struts 1.1 versions.
>>>
>>> 3) The taglib package has been renamed to
>>> "org.apache.taglib.tiles" - I'm
>>> wondering if this will create a confusion with the Jakarta
>>> Taglibs project
>>> which uses "org.apache.taglibs.???" package name? Would this not
>>> be better
>>> and more consistent as "org.apache.tiles.taglib"?
>>>
>>> 4) Similar question about the message resources which are being
>>> duplicated
>>> from Struts - are we OK to use the "org.apache.util" package name
>>> for
>>>
>> these
>>
>>> classes rather than "org.apache.tiles.util"? Also, its probably
>>> another
>>> discussion, but maybe these need to be replaced with something else
>>>
>> (commons
>>
>>> resources?) rather than duplicating from struts.
>>>
>>> Niall
>>>
>>>
>>>
>>>
>>>
>>>
>>> --------------------------------------------------------------------
>>> -
>>> 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: Initial checkin of standalone Tiles
Posted by James Holmes <ja...@jamesholmes.com>.
+1
-----Original Message-----
From: Craig McClanahan [mailto:craigmcc@gmail.com]
Sent: Wednesday, July 13, 2005 4:04 PM
To: Struts Developers List
Subject: Re: Initial checkin of standalone Tiles
On 6/15/05, James Holmes <ja...@jamesholmes.com> wrote:
> I'm with Martin and Niall.
Having looked at this some more, I agree as well, and I'm willing to
do the work. The proposed plan is to:
* "svn mv" the current contents of "sandbox/tiles" to someplace archival
until the remaining steps are complete.
* "svn copy" to establish the initial code base for "sandbox/tiles" from the
trunk version of "tiles" (i.e. the latest and greatest version that is
used
in development releases of Struts).
* Refactor the package names, taking into account the feedback above.
In particular:
- Base package name will be "org.apache.tiles".
- Tag library classes will be "org.apache.tiles.taglib"
- Any utility classes that are needed from Struts
will be "svn copy"d into "org.apache.tiles.util".
* Add in appropriate versions of the old DTDs so that validating the
definitions
file does not attempt to access the Internet.
* Establish a new (version 1.2) DTD so that standalone Tiles can diverge
in the future if it needs to, without messing up the DTDs used for 1.0 and
1.1
based applications.
* When all is well, get rid of the previously archived version
of "sandbox/tiles".
Does this sound like a reasonable plan?
Craig
>
> James
>
> -----Original Message-----
> From: Martin Cooper [mailto:martinc@apache.org]
> Sent: Wednesday, June 15, 2005 11:36 AM
> To: Struts Developers List
> Subject: Re: Initial checkin of standalone Tiles
>
> I agree with all of Niall's points below. I'm especially concerned at the
> loss of history mentioned in #2, since history can be so important.
>
> --
> Martin Cooper
>
>
> On Wed, 15 Jun 2005, Niall Pemberton wrote:
>
> > I have a few concerns/questions about the initial checkin of standalone
> > Tiles into the sandbox, which David indicates in the SVN log is
extracted
> > from Struts 1.1:
> >
> > 1) I'm wondering why this is based on Struts 1.1, rather than the
current
> > version of tiles code? I did a quick scan (for starters) of the tiles
> taglib
> > and while there hasn't been a large amount of activity since Struts 1.1
> > there have been some bug fixes and some other minor changes and it seems
a
> > shame to have to redo these changes rather than copying the current
> > versions.
> >
> > 2) IMO it would be better to use SVN copy to create the initial code
base
> -
> > seems a shame to loose all the subversion history by adding these as new
> > artefacts. Since we have Struts 1.1 versions tagged they could be
copied
> > either from the current versions or the Struts 1.1 versions.
> >
> > 3) The taglib package has been renamed to "org.apache.taglib.tiles" -
I'm
> > wondering if this will create a confusion with the Jakarta Taglibs
project
> > which uses "org.apache.taglibs.???" package name? Would this not be
better
> > and more consistent as "org.apache.tiles.taglib"?
> >
> > 4) Similar question about the message resources which are being
duplicated
> > from Struts - are we OK to use the "org.apache.util" package name for
> these
> > classes rather than "org.apache.tiles.util"? Also, its probably another
> > discussion, but maybe these need to be replaced with something else
> (commons
> > resources?) rather than duplicating from struts.
> >
> > Niall
> >
> >
> >
> >
> >
> >
> > ---------------------------------------------------------------------
> > 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: Initial checkin of standalone Tiles
Posted by Craig McClanahan <cr...@gmail.com>.
On 6/15/05, James Holmes <ja...@jamesholmes.com> wrote:
> I'm with Martin and Niall.
Having looked at this some more, I agree as well, and I'm willing to
do the work. The proposed plan is to:
* "svn mv" the current contents of "sandbox/tiles" to someplace archival
until the remaining steps are complete.
* "svn copy" to establish the initial code base for "sandbox/tiles" from the
trunk version of "tiles" (i.e. the latest and greatest version that is used
in development releases of Struts).
* Refactor the package names, taking into account the feedback above.
In particular:
- Base package name will be "org.apache.tiles".
- Tag library classes will be "org.apache.tiles.taglib"
- Any utility classes that are needed from Struts
will be "svn copy"d into "org.apache.tiles.util".
* Add in appropriate versions of the old DTDs so that validating the definitions
file does not attempt to access the Internet.
* Establish a new (version 1.2) DTD so that standalone Tiles can diverge
in the future if it needs to, without messing up the DTDs used for 1.0 and 1.1
based applications.
* When all is well, get rid of the previously archived version
of "sandbox/tiles".
Does this sound like a reasonable plan?
Craig
>
> James
>
> -----Original Message-----
> From: Martin Cooper [mailto:martinc@apache.org]
> Sent: Wednesday, June 15, 2005 11:36 AM
> To: Struts Developers List
> Subject: Re: Initial checkin of standalone Tiles
>
> I agree with all of Niall's points below. I'm especially concerned at the
> loss of history mentioned in #2, since history can be so important.
>
> --
> Martin Cooper
>
>
> On Wed, 15 Jun 2005, Niall Pemberton wrote:
>
> > I have a few concerns/questions about the initial checkin of standalone
> > Tiles into the sandbox, which David indicates in the SVN log is extracted
> > from Struts 1.1:
> >
> > 1) I'm wondering why this is based on Struts 1.1, rather than the current
> > version of tiles code? I did a quick scan (for starters) of the tiles
> taglib
> > and while there hasn't been a large amount of activity since Struts 1.1
> > there have been some bug fixes and some other minor changes and it seems a
> > shame to have to redo these changes rather than copying the current
> > versions.
> >
> > 2) IMO it would be better to use SVN copy to create the initial code base
> -
> > seems a shame to loose all the subversion history by adding these as new
> > artefacts. Since we have Struts 1.1 versions tagged they could be copied
> > either from the current versions or the Struts 1.1 versions.
> >
> > 3) The taglib package has been renamed to "org.apache.taglib.tiles" - I'm
> > wondering if this will create a confusion with the Jakarta Taglibs project
> > which uses "org.apache.taglibs.???" package name? Would this not be better
> > and more consistent as "org.apache.tiles.taglib"?
> >
> > 4) Similar question about the message resources which are being duplicated
> > from Struts - are we OK to use the "org.apache.util" package name for
> these
> > classes rather than "org.apache.tiles.util"? Also, its probably another
> > discussion, but maybe these need to be replaced with something else
> (commons
> > resources?) rather than duplicating from struts.
> >
> > Niall
> >
> >
> >
> >
> >
> >
> > ---------------------------------------------------------------------
> > 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: Initial checkin of standalone Tiles
Posted by James Holmes <ja...@jamesholmes.com>.
I'm with Martin and Niall.
James
-----Original Message-----
From: Martin Cooper [mailto:martinc@apache.org]
Sent: Wednesday, June 15, 2005 11:36 AM
To: Struts Developers List
Subject: Re: Initial checkin of standalone Tiles
I agree with all of Niall's points below. I'm especially concerned at the
loss of history mentioned in #2, since history can be so important.
--
Martin Cooper
On Wed, 15 Jun 2005, Niall Pemberton wrote:
> I have a few concerns/questions about the initial checkin of standalone
> Tiles into the sandbox, which David indicates in the SVN log is extracted
> from Struts 1.1:
>
> 1) I'm wondering why this is based on Struts 1.1, rather than the current
> version of tiles code? I did a quick scan (for starters) of the tiles
taglib
> and while there hasn't been a large amount of activity since Struts 1.1
> there have been some bug fixes and some other minor changes and it seems a
> shame to have to redo these changes rather than copying the current
> versions.
>
> 2) IMO it would be better to use SVN copy to create the initial code base
-
> seems a shame to loose all the subversion history by adding these as new
> artefacts. Since we have Struts 1.1 versions tagged they could be copied
> either from the current versions or the Struts 1.1 versions.
>
> 3) The taglib package has been renamed to "org.apache.taglib.tiles" - I'm
> wondering if this will create a confusion with the Jakarta Taglibs project
> which uses "org.apache.taglibs.???" package name? Would this not be better
> and more consistent as "org.apache.tiles.taglib"?
>
> 4) Similar question about the message resources which are being duplicated
> from Struts - are we OK to use the "org.apache.util" package name for
these
> classes rather than "org.apache.tiles.util"? Also, its probably another
> discussion, but maybe these need to be replaced with something else
(commons
> resources?) rather than duplicating from struts.
>
> Niall
>
>
>
>
>
>
> ---------------------------------------------------------------------
> 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: Initial checkin of standalone Tiles
Posted by Martin Cooper <ma...@apache.org>.
I agree with all of Niall's points below. I'm especially concerned at the
loss of history mentioned in #2, since history can be so important.
--
Martin Cooper
On Wed, 15 Jun 2005, Niall Pemberton wrote:
> I have a few concerns/questions about the initial checkin of standalone
> Tiles into the sandbox, which David indicates in the SVN log is extracted
> from Struts 1.1:
>
> 1) I'm wondering why this is based on Struts 1.1, rather than the current
> version of tiles code? I did a quick scan (for starters) of the tiles taglib
> and while there hasn't been a large amount of activity since Struts 1.1
> there have been some bug fixes and some other minor changes and it seems a
> shame to have to redo these changes rather than copying the current
> versions.
>
> 2) IMO it would be better to use SVN copy to create the initial code base -
> seems a shame to loose all the subversion history by adding these as new
> artefacts. Since we have Struts 1.1 versions tagged they could be copied
> either from the current versions or the Struts 1.1 versions.
>
> 3) The taglib package has been renamed to "org.apache.taglib.tiles" - I'm
> wondering if this will create a confusion with the Jakarta Taglibs project
> which uses "org.apache.taglibs.???" package name? Would this not be better
> and more consistent as "org.apache.tiles.taglib"?
>
> 4) Similar question about the message resources which are being duplicated
> from Struts - are we OK to use the "org.apache.util" package name for these
> classes rather than "org.apache.tiles.util"? Also, its probably another
> discussion, but maybe these need to be replaced with something else (commons
> resources?) rather than duplicating from struts.
>
> Niall
>
>
>
>
>
>
> ---------------------------------------------------------------------
> 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