You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@forrest.apache.org by Clay <we...@mac.com> on 2004/10/27 20:36:06 UTC
forrest.apache.org/build.html
Just updated to the new forrest svn (55720), and noticed I can't cd
forrest/ and then do ./build.sh (as described on the Forrest Build
page[1]) since it's in forrest/forrestcore/. It looks like[1] needs to
be changed to reflect this.
Also, I notice that plugins, whiteboard^H^H^H^H^H^H^Hscratchpad and
tools would not be built in this case. That is probably to be expected,
but I wanted to be sure.
[1]
http://forrest.apache.org/build.html
Web Maestro Clay
--
<we...@mac.com> - <http://homepage.mac.com/webmaestro/>
There are 10 types of people in the world:
Those who understand binary, and those who don't.
Re: parameter entity for globalents.ent
Posted by David Crossley <cr...@apache.org>.
Sean Wheller wrote:
> David Crossley wrote:
> > I reckon that it is a good idea. We used to use
> > entities at various occasions in the past Forrest.
> > When the build was restructured we didn't need that
> > approach anymore. Your suggestion is a good use.
> >
> > Would it be better to use a Public Identifier
> > so that the catalog entity resolver can be used?
>
> Yes it can be part of the catalog. Providing that we specify a URI and not
> just the filename. The later does not work, as far as I know, under the Java
> Resolver.
>
> Where do you think is a good place to put the file and perhaps we should call
> it something, any name suggestions?
Let me experiment with this. I will report back.
> > Would it be better to incorporate this into the
> > document-v* DTDs so that we don't need to declare
> > it in every xml instance.
>
> Yes the DocTypeDecl must declare it. If we use catalog then, we can point to
> it using a ficticious URI. This is a level of abstraction that will enable us
> to move it around in the future.
> The question is, will this feature be "internal" to the project, or will it
> also be a feature across projects?
The catalog would make it universally available.
It is a project-based thing, though perhaps the
forrest core can have one too.
--
David Crossley
Re: parameter entity for globalents.ent (Was: forrest.apache.org/build.html)
Posted by Sean Wheller <se...@inwords.co.za>.
On Thursday 28 October 2004 03:09, David Crossley wrote:
> I reckon that it is a good idea. We used to use
> entities at various occasions in the past Forrest.
> When the build was restructured we didn't need that
> approach anymore. Your suggestion is a good use.
>
> Would it be better to use a Public Identifier
> so that the catalog entity resolver can be used?
Yes it can be part of the catalog. Providing that we specify a URI and not
just the filename. The later does not work, as far as I know, under the Java
Resolver.
Where do you think is a good place to put the file and perhaps we should call
it something, any name suggestions?
>
> Would it be better to incorporate this into the
> document-v* DTDs so that we don't need to declare
> it in every xml instance.
Yes the DocTypeDecl must declare it. If we use catalog then, we can point to
it using a ficticious URI. This is a level of abstraction that will enable us
to move it around in the future.
The question is, will this feature be "internal" to the project, or will it
also be a feature across projects?
--
Sean Wheller
Technical Author
sean@inwords.co.za
http://www.inwords.co.za
parameter entity for globalents.ent (Was:
forrest.apache.org/build.html)
Posted by David Crossley <cr...@apache.org>.
Sean Wheller wrote:
> Dave Brondsema wrote:
>
> Sorry for dropping in like this.
Don't be. We want people to drop in on every topic.
> I would like to make a suggestion. Although changes like this do not happen
> all that often, when they do they generally need fixing in many places.
>
> Something I do to help make light work of the situation is define a central
> database of terms, links etc. that may change and are used frequently
> throughout the documents. These are stored as entities and included in
> documents by entity reference. All documents with a DocTypeDecl specify the
> file as an entity in their subset.
>
> The DocTypeDecl thus looks like this:
> <!DOCTYPE preface PUBLIC "-//OASIS//DTD DocBook XML V4.3//EN"
> "http://www.docbook.org/xml/4.3/docbookx.dtd" [
> <!ENTITY % globalents SYSTEM "global.ent">
> %globalents;
> ]>
>
> The content of "global.ent" looks like this:
> <!ENTITY project-name 'Some Name'>
> <!ENTITY project-url 'http://www.somename.com/'>
> <!ENTITY project-mail-subscribe 'mailto:??.??.??.??'>
> <!ENTITY project-mail-unsubscribe 'mailto:??.??.??.??'>
> <!ENTITY project-mail-post 'mailto:??.??.??.??'>
> <!ENTITY project-mail-archive 'http://??.??.??.??'>
> <!ENTITY project-svn 'svn://??.??.??.??'>
> <!ENTITY project-svn-trunk 'svn://??.??.??.??/'>
> <!ENTITY project-tracker 'http://??.??.??.??'>
> <!ENTITY cc 'http://creativecommons.org/'>
> <!ENTITY cc-attrib '<ulink
> url="http://creativecommons.org/licenses/by-sa/2.0/">Attribution-ShareAlike
> 2.0</ulink>'>
> ...
>
> An entity can be included as follows:
>
> <para>The name of the project is &project-name;. The <ulink
> url="&project-url;">web site</ulink> is built with Forrest. We have a mailing
> list. Send mail to <email>&project-mail-subscribe;</email>.</para>
>
> In this way I only need update the value of an entity in "global.ent" and the
> next time a document that declares and references to it is parsed the new
> value is expanded into the document.
>
> Hope this helps. If you think this is a good idea and need help with
> implimentation, I could help while building the Docbook Plugin.
I reckon that it is a good idea. We used to use
entities at various occasions in the past Forrest.
When the build was restructured we didn't need that
approach anymore. Your suggestion is a good use.
Would it be better to use a Public Identifier
so that the catalog entity resolver can be used?
Would it be better to incorporate this into the
document-v* DTDs so that we don't need to declare
it in every xml instance.
--
David Crossley
Re: forrest.apache.org/build.html
Posted by Sean Wheller <se...@inwords.co.za>.
On Wednesday 27 October 2004 23:00, Dave Brondsema wrote:
> Yes we need to update the building from SVN page. I will do that now.
>
> The 0.6 upgrade documentation is ok because that applies to 0.6, not SVN.
>
> Looking around, there are documents that talk about files like
> "forrest/src/core/context/skins". In cases like this, the SVN version
> starts out "forrestcore" and the release versions start
> "apache-forrest-0.6" (possibly renamed to just "forrest"). I think we
> should have more consistency.
>
> Should we rename forrestcore to forrest?
Sorry for dropping in like this.
I would like to make a suggestion. Although changes like this do not happen
all that often, when they do they generally need fixing in many places.
Something I do to help make light work of the situation is define a central
database of terms, links etc. that may change and are used frequently
throughout the documents. These are stored as entities and included in
documents by entity reference. All documents with a DocTypeDecl specify the
file as an entity in their subset.
The DocTypeDecl thus looks like this:
<!DOCTYPE preface PUBLIC "-//OASIS//DTD DocBook XML V4.3//EN"
"http://www.docbook.org/xml/4.3/docbookx.dtd" [
<!ENTITY % globalents SYSTEM "global.ent">
%globalents;
]>
The content of "global.ent" looks like this:
<!ENTITY project-name 'Some Name'>
<!ENTITY project-url 'http://www.somename.com/'>
<!ENTITY project-mail-subscribe 'mailto:??.??.??.??'>
<!ENTITY project-mail-unsubscribe 'mailto:??.??.??.??'>
<!ENTITY project-mail-post 'mailto:??.??.??.??'>
<!ENTITY project-mail-archive 'http://??.??.??.??'>
<!ENTITY project-svn 'svn://??.??.??.??'>
<!ENTITY project-svn-trunk 'svn://??.??.??.??/'>
<!ENTITY project-tracker 'http://??.??.??.??'>
<!ENTITY cc 'http://creativecommons.org/'>
<!ENTITY cc-attrib '<ulink
url="http://creativecommons.org/licenses/by-sa/2.0/">Attribution-ShareAlike
2.0</ulink>'>
...
An entity can be included as follows:
<para>The name of the project is &project-name;. The <ulink
url="&project-url;">web site</ulink> is built with Forrest. We have a mailing
list. Send mail to <email>&project-mail-subscribe;</email>.</para>
In this way I only need update the value of an entity in "global.ent" and the
next time a document that declares and references to it is parsed the new
value is expanded into the document.
Hope this helps. If you think this is a good idea and need help with
implimentation, I could help while building the Docbook Plugin.
--
Sean Wheller
Technical Author
sean@inwords.co.za
http://www.inwords.co.za
Re: forrest.apache.org/build.html
Posted by Dave Brondsema <da...@brondsema.net>.
Yes we need to update the building from SVN page. I will do that now.
The 0.6 upgrade documentation is ok because that applies to 0.6, not SVN.
Looking around, there are documents that talk about files like
"forrest/src/core/context/skins". In cases like this, the SVN version
starts out "forrestcore" and the release versions start
"apache-forrest-0.6" (possibly renamed to just "forrest"). I think we
should have more consistency.
Should we rename forrestcore to forrest?
Clay Leeds wrote:
> On Oct 27, 2004, at 12:06 PM, Scherler, Thorsten wrote:
>
>> >> Do an "svn up" and rebuild, and update your FORREST_HOME.
>> >
>> > to...?
>>
>> For example from:
>> /home/dpb2/forrest/src/core
>> to:
>> /home/dpb2/forrest/forrestcore/src/core
>
>
> Yes... I know (from reading the Upgrading to 0.6 page). But the Forrest
> Build[1] doesn't say this, as I think it should.
>
> HTH^2
> Web Maestro Clay
>
>> HTH
>> thorsten
>>
>> Clay escribió:
>>
>>> Just updated to the new forrest svn (55720), and noticed I can't cd
>>> forrest/ and then do ./build.sh (as described on the Forrest Build
>>> page[1]) since it's in forrest/forrestcore/. It looks like[1] needs
>>> to be changed to reflect this.
>>> Also, I notice that plugins, whiteboard^H^H^H^H^H^H^Hscratchpad and
>>> tools would not be built in this case. That is probably to be
>>> expected, but I wanted to be sure.
>>> [1]
>>> http://forrest.apache.org/build.html
>>> Web Maestro Clay
>
> Web Maestro Clay
--
Dave Brondsema : dave@brondsema.net
http://www.splike.com : programming
http://csx.calvin.edu : student org
http://www.brondsema.net : personal
Re: forrest.apache.org/build.html
Posted by Clay Leeds <cl...@medata.com>.
On Oct 27, 2004, at 12:06 PM, Scherler, Thorsten wrote:
> >> Do an "svn up" and rebuild, and update your FORREST_HOME.
> >
> > to...?
>
> For example from:
> /home/dpb2/forrest/src/core
> to:
> /home/dpb2/forrest/forrestcore/src/core
Yes... I know (from reading the Upgrading to 0.6 page). But the Forrest
Build[1] doesn't say this, as I think it should.
HTH^2
Web Maestro Clay
> HTH
> thorsten
>
> Clay escribió:
>> Just updated to the new forrest svn (55720), and noticed I can't cd
>> forrest/ and then do ./build.sh (as described on the Forrest Build
>> page[1]) since it's in forrest/forrestcore/. It looks like[1] needs
>> to be changed to reflect this.
>> Also, I notice that plugins, whiteboard^H^H^H^H^H^H^Hscratchpad and
>> tools would not be built in this case. That is probably to be
>> expected, but I wanted to be sure.
>> [1]
>> http://forrest.apache.org/build.html
>> Web Maestro Clay
Web Maestro Clay
--
Clay Leeds - <cl...@medata.com>
Webmaster/Developer - Medata, Inc. - <http://www.medata.com/>
PGP Public Key: <https://mail.medata.com/pgp/cleeds.asc>
Re: forrest.apache.org/build.html
Posted by "Scherler, Thorsten" <th...@apache.org>.
>> Do an "svn up" and rebuild, and update your FORREST_HOME.
>
>
>
> to...?
>
For example from:
/home/dpb2/forrest/src/core
to:
/home/dpb2/forrest/forrestcore/src/core
HTH
thorsten
Clay escribió:
> Just updated to the new forrest svn (55720), and noticed I can't cd
> forrest/ and then do ./build.sh (as described on the Forrest Build
> page[1]) since it's in forrest/forrestcore/. It looks like[1] needs to
> be changed to reflect this.
>
> Also, I notice that plugins, whiteboard^H^H^H^H^H^H^Hscratchpad and
> tools would not be built in this case. That is probably to be expected,
> but I wanted to be sure.
>
> [1]
> http://forrest.apache.org/build.html
>
> Web Maestro Clay