You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@forrest.apache.org by Rob Exley <ro...@equifax.com> on 2004/03/30 13:56:03 UTC
upgrading an existing forrest installation
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
What is the recommended approach for upgrading an existing forrest
installation ?
I am in the process of using forrest for an internal documentation site and
having just updated my forrest build directory from SVN it now complains
about illegal attributes within the skinconf.xml file on the toc element.
I can see the changes so I have no problem fixing this, my question is what
have people found to be the best way to handle changes such as this in an
existing installation ? I don't want to have to re-seed a new directory and
copy over all my documentation every time, especially as I now have it all
under version control.
Is it just a case of trying 'forrest run' and seeing what breaks ?
- --
Rob Exley <ro...@equifax.com>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
iD8DBQFAaWBWIQSbu4H8vOQRAh2tAJ4kX67LUnlRrkU/2Ewy3m05/fo3twCgsTsw
EHA+Qb4pnsHVW3ZWuhC83iI=
=SdMT
-----END PGP SIGNATURE-----
Re: upgrading an existing forrest installation
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Rob Exley wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> What is the recommended approach for upgrading an existing forrest
> installation ?
>
> I am in the process of using forrest for an internal documentation site and
> having just updated my forrest build directory from SVN it now complains
> about illegal attributes within the skinconf.xml file on the toc element.
>
> I can see the changes so I have no problem fixing this, my question is what
> have people found to be the best way to handle changes such as this in an
> existing installation ? I don't want to have to re-seed a new directory and
> copy over all my documentation every time, especially as I now have it all
> under version control.
>
> Is it just a case of trying 'forrest run' and seeing what breaks ?
Unfortunately skinconf.xml files don't have versioning nor upgrade
systems, so it's always a matter of comparing the most recent template
with the existing one.
As for other features... it's mainly left to users that test and report
eventual problems here. We try to keep Forrest backward compatible, but
skinconf in particular has bitten us sometimes.
In any case, we should IMNSHO stop *requiring* attributes and elements,
as currently the skinconf file is always augmented before being read, so
we can cater for missing elements there, filling it in with defaults.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: upgrading an existing forrest installation
Posted by Juan Jose Pablos <ch...@che-che.com>.
Dave Brondsema escribió:
>
>
> We need an external, versioned DTD for skinconf for many reasons. :-)
>
>
Even if we loose the ability of off-line validation?
What are our options on this issue?
Cheers,
Cheche
Re: upgrading an existing forrest installation
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Juan Jose Pablos wrote:
> Nicola,
>
>
> Nicola Ken Barozzi escribió:
>
>>
>>
>> We don't necessarily need to break it.
>>
>
> <snip resources.xmap code>
>
>> This means that every time skinconf is used, the xsl in
>> {forrest:home}context/skins/common/skinconf.xsl is *always* applied.
>>
>> So if we mark all the elements as not required and put default values
>> in the above xsl, along with transformations for name changes, we will
>> not break compatibility.
>>
>
> Instead of doing that transformation for nearly EVERY request,
Cocoon caches the output, there is no performance hit.
> What
> about using xslt ant task?
> http://ant.apache.org/manual/CoreTasks/style.html
>
> We could run it on a build target.
> Replace Jing task to validate skinconf with something on the lines:
>
> <xslt in="skinconf.xml" out="{build.project}/skinconf.xml"
> style="{forrest:home}context/skins/common/skinconf.xsl">
> <xmlcatalog refid="mycatalog"/>
> </xslt>
>
> WDYT?
The less we make the build script complex, the better.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: upgrading an existing forrest installation
Posted by Juan Jose Pablos <ch...@che-che.com>.
Nicola,
Nicola Ken Barozzi escribió:
>
>
> We don't necessarily need to break it.
>
<snip resources.xmap code>
> This means that every time skinconf is used, the xsl in
> {forrest:home}context/skins/common/skinconf.xsl is *always* applied.
>
> So if we mark all the elements as not required and put default values in
> the above xsl, along with transformations for name changes, we will not
> break compatibility.
>
Instead of doing that transformation for nearly EVERY request, What
about using xslt ant task?
http://ant.apache.org/manual/CoreTasks/style.html
We could run it on a build target.
Replace Jing task to validate skinconf with something on the lines:
<xslt in="skinconf.xml" out="{build.project}/skinconf.xml"
style="{forrest:home}context/skins/common/skinconf.xsl">
<xmlcatalog refid="mycatalog"/>
</xslt>
WDYT?
Cheers,
Cheche
Re: upgrading an existing forrest installation
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Dave Brondsema wrote:
> On Tue, 30 Mar 2004, Juan Jose Pablos wrote:
...
>>It complains about @level on the TOC element. It has been replace
>>@max-depth. Now he have 2 options here:
>>
>>1)allow the level attribute even it will not be used.
>>
>>2) create a xsl file that convert old skin @level to be converted to
>>@max-depth
>
> I don't have a problem with breaking backwards compatibility here because
> the fix is so easy. We just have to make sure we document it on an
> "upgrading to 0.6" page.
We don't necessarily need to break it.
Look here:
http://cvs.apache.org/viewcvs.cgi/xml/forrest/trunk/src/core/context/resources.xmap?rev=9585&root=Apache-SVN&view=markup
In particular this:
<map:pipeline internal-only="false">
<map:match pattern="**skin/skinconf.xml">
<map:generate src="{project:skinconf}" />
<map:select type="exists">
<map:when
test="{project:skins-dir}{forrest:skin}/skinconf.xsl">
<map:transform
src="{project:skins-dir}{forrest:skin}/skinconf.xsl"/>
</map:when>
</map:select>
<map:select type="exists">
<map:when
test="{forrest:home}context/skins/{forrest:skin}/skinconf.xsl">
<map:transform
src="{forrest:home}context/skins/{forrest:skin}/skinconf.xsl"/>
</map:when>
</map:select>
<map:transform
src="{forrest:home}context/skins/common/skinconf.xsl"/>
<map:transform type="skinconf"/>
<map:serialize type="xml" />
</map:match>
</map:pipeline>
This means that every time skinconf is used, the xsl in
{forrest:home}context/skins/common/skinconf.xsl is *always* applied.
So if we mark all the elements as not required and put default values in
the above xsl, along with transformations for name changes, we will not
break compatibility.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: upgrading an existing forrest installation
Posted by Dave Brondsema <da...@brondsema.net>.
On Tue, 30 Mar 2004, Juan Jose Pablos wrote:
> Rob,
>
> > What is the recommended approach for upgrading an existing forrest
> > installation ?
>
> For people that use the SVN version, just remember to change your
> FORREST_HOME value.
>
> > I am in the process of using forrest for an internal documentation site and
> > having just updated my forrest build directory from SVN it now complains
> > about illegal attributes within the skinconf.xml file on the toc element.
>
> It complains about @level on the TOC element. It has been replace
> @max-depth. Now he have 2 options here:
>
> 1)allow the level attribute even it will not be used.
>
> 2) create a xsl file that convert old skin @level to be converted to
> @max-depth
>
I don't have a problem with breaking backwards compatibility here because
the fix is so easy. We just have to make sure we document it on an
"upgrading to 0.6" page.
>
> for 2, we need to have a @version on the skinconf.
>
We need an external, versioned DTD for skinconf for many reasons. :-)
> WDYT?
>
--
Dave Brondsema : dave@brondsema.net
http://www.brondsema.net : personal
http://www.splike.com : programming
http://csx.calvin.edu : student org
Re: upgrading an existing forrest installation
Posted by Juan Jose Pablos <ch...@che-che.com>.
Rob,
> What is the recommended approach for upgrading an existing forrest
> installation ?
For people that use the SVN version, just remember to change your
FORREST_HOME value.
> I am in the process of using forrest for an internal documentation site and
> having just updated my forrest build directory from SVN it now complains
> about illegal attributes within the skinconf.xml file on the toc element.
It complains about @level on the TOC element. It has been replace
@max-depth. Now he have 2 options here:
1)allow the level attribute even it will not be used.
2) create a xsl file that convert old skin @level to be converted to
@max-depth
for 2, we need to have a @version on the skinconf.
WDYT?