On Tue, 18 Jan 2005, Mark Taylor wrote:
> On Tue, 18 Jan 2005, Peter W. Draper wrote:
>
> > On Tue, 18 Jan 2005, Mark Taylor wrote:
> >
> > > Most of the starjava set now builds, installs and tests using either
> > > Java 1.4(.1) or 1.5(.0) therefore. There is still one problem however.
> > >
> > > The "javadocs" and "test" targets for treeview fail at 1.5, again
> > > because of circular dependencies. In both cases it sits there
> > > for a while and then throws an OutOfMemoryError.
> > > I'm reasonably sure this is because the treeview's installed.classpath
> > > contains both splat.jar and topcat.jar, while the manifests of those
> > > two have class-paths which point to ../treeview/treeview.jar.
> > > The rest of the build is happy with this, but javadocs & test fail.
> > > Peter, can you think of a good way round this? If it's going to be
> > > a pain to do it properly, I could just construct a class path by hand
> > > in treeview's build.xml for use with the javadoc and test targets
> > > which exclude splat & topcat. The right answer of course is to have
> > > treeview split into a library and applications package - it was getting
> > > perilously close to the top of my to-do list before VOGON came along.
> > > If you think it's the only reasonable way to proceed though I could
> > > bite the bullet anyway.
> >
> > Hi Mark,
> >
> > we could work around this kind of problem at the application level by
> > adding optional parts to the CLASSPATH in the startup scripts (this would
> > work for the SPLAT/Treeview problem as the linkage between SPLAT and
> > Treeview is done by reflection, looks like that is also true for TOPCAT),
> > but that wouldn't be much help if the optional parts were needed by the
> > unit tests. For that we'd have to do what you say and add these into just
> > the tests-classpath property and not the full classpath.
>
> The trouble with this is that it means you have to use the startup
> script (or really know what you're doing). I generally advertise
> that the startup script is just a convenience, and you can use the
> jar file directly if you want.
OK, so plan B would be to separate the application jar file classpath from
the classpath needed to compile against a package, i.e. split treeview
into a treeview.jar file that is really empty, but has the current
classpath and treeview-parts.jar (or whatever) that has all the source
code and compile-time classpath. This is what we do for the webstart
stuff!
Peter.
|