On Mon, 2007-05-14 at 11:20 -0700, Hoss Man (JIRA) wrote:
> [
> https://issues.apache.org/jira/browse/SOLR-238?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12495706
> ]
>
> Hoss Man commented on SOLR-238:
> -------------------------------
>
> Thorsten ... thanks for the prod on this issue. One thing that makes this
> tricky is that the tutorial (and the entire website) are bundled with every
> release ... that's why we keep the site up to date with the trunk, so that
> people can review the docs as time goes on, but when a release is cut people
> using that release should refer to the docs that come with it.
>
> I'm not very knowledgeable in forest, do you (or anyone else watching this
> issue) know if there is an easy way to do variable substitution into the
> generated docs when they are build using property files (or something like it)
>
> Then the docs could always contain the current Solr spec version number when
> the tutorial is regenerated (for official releases, the spec version number
> looks like 1.1, 1.2, etc... for nightly builds it looks like
> 1.1.2007.05.11.10.10.53 -- the last official version number followed by the
> current datetime)
Well the quickest way certainly is changing the skinconf.xml by hand.
However that will not be possible in the use-cases you describe (for
nightly builds).
For this case you would need something more sophisticated.
To understand it right you would like to build the site with forrest and
in the build appears the version number and the name of the dis (ant
property ${fullnamever}) of the tutorial.
In the solr build.xml we define:
<!-- make a distribution -->
<target name="package"
description="Packages the Solr Distribution files and
Documentation."
depends="dist, example, javadoc">
<copy todir="${build.docs}">
<fileset dir="site" />
</copy>
...
</target>
One idea was for me to use a filter with the copy task that e.g.
@fullnamever@ will be substitute with ${fullnamever}. The problem is
that would not be substituted then on the live website.
One could replace http://wiki.apache.org/solr/Website_Update_HOWTO step
2 of "Website update steps" with a target that is doing the filtering
for you. Then in "forrest run" you would find @fullnamever@ but after
building the site and using the copy target with filtering true you have
the variable substituted. The problem is that the nightly builds would
need to build as well the documentation with forrest. Letting forrest do
the substitution and import forrest targets into the solr build.xml is a
similar approach but then you have an even bigger dependency on forrest.
I need to think about it but maybe meanwhile somebody on forrest-dev
(which I cc) has an idea.
salu2
--
Thorsten Scherler thorsten.at.apache.org
Open Source Java consulting, training and solutions
