forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thorsten Scherler <>
Subject Re: [jira] Commented: (SOLR-238) [Patch] The tutorial on our website is against trunk which causes confusion by user
Date Mon, 14 May 2007 21:33:02 GMT
On Mon, 2007-05-14 at 11:20 -0700, Hoss Man (JIRA) wrote:
> [
> 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
> 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. -- 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
          depends="dist, example, javadoc">

    <copy todir="${}">
      <fileset dir="site" />

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 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.

Thorsten Scherler                       
Open Source Java                      consulting, training and solutions

View raw message