Here is the Default Paths and File Names section of the standard
preface, for reference:
http://docsview.sfbay/app/docs/doc/819-3671/6n5si4but?a=view
Note that for just the Sun Java System Application Server, there are
five different possibilities for the installation directory alone. Also
note that in some cases the domain root is under the installation
directory and in other cases it's not. Do we really want to list out
all these possibilities every time we mention the location of a file?
June
June.Parks_at_Sun.COM wrote:
> This could work for many code examples. For the domain.xml file,
> there is already a system property that can be substituted for the
> domain directory, and there may be one for the installation directory
> as well. For deployment descriptors, a build.xml file could be used
> in some cases. But the one thing all these have in common is that the
> true path is not shown directly, but represented by a variable.
>
> However, for path examples, and for deployment descriptor examples
> where the path is being discussed, this doesn't work so well. Most of
> the time it's the part of the path below the installation or domain
> directory that matters. The path of the installation or domain
> directory has so many variations that to show them all becomes quite
> cumbersome. And so far our books have only covered Sun Java System
> Application Server paths. When you consider the GlassFish paths too,
> it's really a mess.
>
> If there are standard environment variables that can be substituted
> for the installation and domain directories, I would be willing to
> change the text entities to use those. But this is ONLY a good idea
> if they are standard. We shouldn't be making things up willy-nilly as
> we've done in the past.
>
> June
>
> Ian Evans wrote:
>> Debbie Carson wrote:
>>> Ian could better answer this than I, but I think he's out of touch
>>> for now. In the Java EE tutorials, there is an
>>> examples\bp\project\build.properties file that the user must edit to
>>> provide the location of their tutorial and GlassFish installations.
>>> This file is used by the build.xml file when the example is built.
>>
>> Right. The user sets a few properties, and these are used by all the
>> common build scripts for the tutorial examples.
>>
>> A more sophisticated build system might make some educated guesses,
>> based on the OS, of the location of GlassFish. If it can't find
>> GlassFish, it would then display an error with instructions for how
>> the user should explicitly set the necessary properties.
>>
>> The point is, engineer the examples so that any OS-specific settings
>> are either figured out automatically, or set once.
>>
>> -ian
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: docs-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: docs-help_at_glassfish.dev.java.net
>