Kepler

• I updated build-ptolemy.jar so that we now don't include things of little
  use to Kepler. Basically, I looked at ptolemy/adm/gen-5.2/src.ex and the
  makefile in the same directory and added a number of excludes to
  build-ptolemy.jar. This reduces the size from 16.8Mb to 12.3Mb and
  decreases the build time. Further reductions are possible.
  One possibly minor issue is that I had to add the excludes in two places.
  I don't know enough about ant to know if there is a workaround.

• I looked in to the problem I was having with the ptolemy/configs/ptiny/intro.htm
  Part of the problem was the demosPtiny.htm file was not being created properly,
  which I fixed. That file is checked in to CVS, so there is no need for ant to
  try to build it. I fixed a few other missing file problems.

• It turns out that there is a problem with relative URLS and how ant builds
  files. For example, ptolemy/configs/ptiny/intro.htm includes a URL
  ../../../doc/mainVergilPtiny.htm. The problem is that if we
  $PTII/build/classes in the the classpath, then ptolemy/configs/ptiny/intro.htm
  is found in $PTII/build/classes. However, ant puts the docs in
  $PTII/build/doc, so the file we are looking for appears in
  $PTII/build/doc/doc/mainVergilPtiny.htm and is not found relative to intro.htm.
  Fortunately, if we stick with using ptolemy.jar and ptolemy-doc.jar, everything
  works out because the HTML code in Ptolemy is jar URL aware.
  If we could modify the ant configuration so that the doc directory was inside
  classes, then this problem would go away for users that are not using
  ptolemy.jar and ptolemy-doc.jar. However, this would mean modifying how
  ant jars things up, I'm not sure if this is possible.
  Anyway, short answer: use the jar files, the links will work out.

I added a comment to build.xml, but did not modify its functionality.
Before shipping alpha8, we should use ptolemy.jar, not build/classes
so that the URLs in intro.htm work

• At this point, the following links are bad in the configuration.
  ptolemy/configs/doc/docsPtiny.htm
  - The local pdfs are missing. This can be ignored, but when the installer
  is shipped, they should probably be included.
  - "Java Class Documentation" is broken.
  Ptolemy expects to find the javadocs in doc/codeDoc.jar
  build-ptolemy.xml has a jdoc rule that build the Ptolemy javadocs
  and places them in build/docs/codeDoc. This can't be renamed to
  build/doc/codeDoc because there is already a target there. Perhaps
  it could be renamed to build/jdoc/doc/codeDoc and then a jar file
  could be created of build/jdoc so that the javadocs would work out?
  Maybe this is moot with the Kepler doc system, so it is not that important.
  ptolemy/configs/doc/demosPtiny.htm
  - The colt demo does not work because lib/ptcolt.jar is not included.
  Colt is this pretty nifty random number toolkit, see
  http://hoschek.home.cern.ch/hoschek/colt
  I think it probably has real value for Kepler.
  If you want me to include it, I can update the configuration accordingly.
  - The Matlab demo does not work because Matlab is not include.
  Matlab is very useful, but the UI has a C component so it uses JNI so
  it is not very portable. I'm not sure if it is worth Kepler's time
  to include Matlab.
  - None of the GR demos work because ptolemy/domains/gr is excluded.
  GR uses Java3D, and while it is very slick, I think excluding it
  from Kepler is reasonable

So, I think the right solution is for me to create an even smaller configuration
than ptiny that has just the domains and demos that Kepler needs. We
could use the dsp configuration here. I'll think this over.

Anyway, the upshot is that we are in much better shape for alpha8,
especially if we use ptolemy.jar.

I added $PTII/ptolemy/configs/ptinyKepler/intro.htm as the Ptolemy Introduction,
it does not have links to GR, Colt or Matlab.

The current Kepler installers don't use ptolemy.jar. Instead, the build process
under the "run" target builds a "kepler.jar" that contains all of the classes
from ptolemy and the classes from Kepler. We do this specifically so that we
can control the placement of the "exp" files in the resulting jar file (as they
override corresponding classes in ptolemy.jar).

Our initial builds did in fact use ptolemy.jar, but we ran into consistency
problems on different platforms and JVMs when loading the exp classes. So we
switched to the approach of building a consolidated kepler.jar file. But this
file takes quite a while to build, so the "run-dev" target was also created to
run directly from build/classes in order to speed up the edit-compile-test
cycle. This "run-dev" target is only intended to be used by developers, and is
not ultimately how kepler is shipped. So your suggestion to use ptolemy.jar
will not work without some significant changes to our build process.

I would like to eliminate this distinction between the two targets (run and
run-dev). I would also like to go back to using ptolemy.jar. But that requires
resolving our issues with inconsistent classloading for the exp directory. One
approach would be to eliminate the exp directory alltogether, which would also
be good. However, we clearly need a place to experiment with changes to the
ptolemy tree before checking them into ptolemy. I'm not sure the ptolemy group
wants all of the changes that we have made in the exp tree. We should, however,
be better about merging our code in exp regularly into the ptolemy tree. I will
enter a separate bug for this task.

Currently there are not major problems here, so I am moving to post 1.0 release.
(Dan Higgins)

I believe the new build system renders this bug obsolete.

Original Bugzilla ID was 2319