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: [EMAIL PROTECTED]
Skype: jmitchtx
On Jul 13, 2005, at 5:04 PM, Craig McClanahan wrote:
On 6/15/05, James Holmes <[EMAIL PROTECTED]> 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:[EMAIL PROTECTED]
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: [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]
---------------------------------------------------------------------
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]
