import-bot (20211) [Avatar] Offline
#1
[Originally posted by jtharp]

I found your book to be very informative, thank you.

I am developing a build process for a project that has broken the source into
several different reusable components. Each of these components can be built
separately and are pulled into several different projects. My solution to
having massive build.xml files that are copied for each component was to use
your library build file concept. Unfortunately, this is where my problem
begins...

Using your example, I started with a library build file for javadoc. In that
build file I need to reference a classpath. I would like to use the reference
"compile.classpath" if it was defined in the calling project, but have a
default value otherwise. Unfortunately, it appears that path references are
not immutable like properties are. Even if I call the javadoc library build
file with inheritrefs="true" my default definition in the library build file
overrides the one defined in the calling project.

Have I missed some basic concept here? Is there a way to test for the
existence of a path reference definition (since referring to it before it is
defined causes a fatal error)?

Thanks,

Josh
import-bot (20211) [Avatar] Offline
#2
Re: Testing for a path reference
[Originally posted by steve_l]

The only way I've got to get paths around reliably is to convert them to a
property using <property refid>, which effectively calls toString() on the
referenced item.

You can then turn it back into a path at the far end. Ugly but workable.