Eliminating startcmd

[p-b-west]

Following my difficulties with the build of DITA-OT (see #1285) I have considered changes to the build files to make the process less arcane and obscure.

I propose modifying build.properties to include default values for the required elements of the class path, xercesImpl.jar, resolver.jar, etc. The defaults would be defined relative to ${lib.dir}, i.e. src/main/lib. In over for this to work best, buildxml would be altered to define src.dir and lib.dir BEFORE reading build.properties, so that the build.xml definitions would take precedence.

The required CLASSPATH for processes invoked by ant could then be set within the various build file components. Users of standard and minimal distributions would modify the build.properties file to indicate their preferred locations.

The other part of startcmd is the setting of ANT_OPTS to the required memory for the java process. This is only required for the full-easy-install, which should be a hands-free install and run.

There are two alternatives.

1. As the full-easy includes an ant distribution which it expects full-easy users to take advantage of, simply modify the ant script to set ANT_OPTS to the appropriate values.
2. provide an ant.conf file to install in $HOME/.ant/. The build can check for the presence of this file. If present, keep going. If not, copy ant.conf to $HOME/.ant, issue a message explaining what has happened, and get the user to start again.

The great disadvantage of 2 is that the ant.conf file will be referenced for all ant builds. However, as this is part of full-easy, such users are unlikely to be using ant for other purposes.

Option 1 seems to me to be the cleanest. The ant distribution in tools will only be referenced by users of DITA-OT, so the ANT_OPTS can be specific to the OT.

I will prepare diffs for the relevant files and post them to this issue.

[jelovirt]

Instead of posting diffs here, please fork the dita-ot repository and send a pull request.

[p-b-west]

Ok. I'll get back to you for details when I have tested the changes.

Peter West

"Are not all these who are speaking Galileans?"

On 01/06/2012, at 3:51 PM, Jarno Elovirta wrote:

Instead of posting diffs here, please fork the dita-ot repository and send a pull request.

---

Reply to this email directly or view it on GitHub:
#1287 (comment)

[jelovirt]

I experimented with this. If we currently have (some libraries omitted):

lib/
  org.dita.dost.platform/
    plugin.properties
  saxon/
    saxon9.jar
    saxon9-dom.jar
  CatalogManager.properties
  configuration.properties
  resolver.jar
  xercesImpl.jar
  xml-apis.jar
tools/
  ant/
    lib/

In the full easy install distribution package, we can just move everything to Ant's lib:

tools/
  ant/
    lib/
      org.dita.dost.platform/
        plugin.properties
      saxon/
        saxon9.jar
        saxon9-dom.jar
      CatalogManager.properties
      configuration.properties
      resolver.jar
      xercesImpl.jar
      xml-apis.jar

Based on a quick test, this works for JARs, but not for the property files.

If you use -lib tools/ant/lib argument when calling Ant, the lib directory is used.

[p-b-west]

What I've been looking at is, among other things, the integration of the building and the running of the distribution. That happens within the build anyway, because the documentation is generated by the constructed dost.jar and the other components.

There is already provision for a local.properties file. I would use that, but access it only through an import of a new local.properties.ant file. See attached.

The import of the local.properties.xml file gives access to the dita.dir, no matter whether it is included from the distribution build or from the top level of the distribution.

I have only been able to give this imtermittent attention, but I will plug away at it.

Peter

Peter West

"Are not all these who are speaking Galileans?"

On 05/06/2012, at 7:12 PM, Jarno Elovirta wrote:

I experimented with this. If we currently have (some libraries omitted):

lib/
 org.dita.dost.platform/
   plugin.properties
 saxon/
   saxon9.jar
   saxon9-dom.jar
 CatalogManager.properties
 configuration.properties
 resolver.jar
 xercesImpl.jar
 xml-apis.jar
tools/
 ant/
   lib/

In the full easy install distribution package, we can just move everything to Ant's lib:

tools/
 ant/
   lib/
     org.dita.dost.platform/
       plugin.properties
     saxon/
       saxon9.jar
       saxon9-dom.jar
     CatalogManager.properties
     configuration.properties
     resolver.jar
     xercesImpl.jar
     xml-apis.jar

Based on a quick test, this works for JARs, but not for the property files.

---

Reply to this email directly or view it on GitHub:
#1287 (comment)

[p-b-west]

Jarno,

I have been driven stark raving mad trying to follow is going on inside this build system. I have it working to a certain point, but I am now completely lost, and have made no progress for a week, on and off.

The crash happens on in update-doc, and seems to have something to do with the catalog resolver.
Can you have a look at this?

If I try to run build_demo.xml all separately, I get the same failure.

And, what does "send a pull request" mean?

Note that I have placed extra jars in the lib folder, and I am running without those elements in the CLASSPATH.

Attached is the output from the build of 'dist'. You may see something obvious straight away.

Peter West

"Unless I see...I will not believe."

On 01/06/2012, at 3:51 PM, Jarno Elovirta wrote:

Instead of posting diffs here, please fork the dita-ot repository and send a pull request.

---

Reply to this email directly or view it on GitHub:
#1287 (comment)

Log at https://gist.github.com/3075734

[p-b-west]

I have a set of changes to the build files that implement this, and also fix #1332. I have committed them to my local repository. What do I do now?

Peter West

"Is not this the carpenter, the son of Mary...?"

On 01/06/2012, at 3:51 PM, Jarno Elovirta wrote:

Instead of posting diffs here, please fork the dita-ot repository and send a pull request.

---

Reply to this email directly or view it on GitHub:
#1287 (comment)

[jelovirt]

Send a pull request.

[p-b-west]

See pull request at #1333 for the results of this.

[jelovirt]

Closing as the command line tool handles the use case.