On Sun, Oct 14, 2001 at 11:33:12AM +0100, Paul Hammant wrote:
> Jeff,
>
> >1.18 +1 -1 jakarta-avalon-cornerstone/apps/demo/build.xml
> >
> > - <pathelement location="xerces.jar2"/>
> > + <pathelement
> > location="../../../jakarta-avalon/tools/lib/xerces.jar"/>
> >
> >
> This used to the be the case and you've undone something that was
> deliberate here.
Feh.. that's what happens when you muck with build systems ;) Cornerstone was
not building from a clean CVS checkout, which forced the issue for me.
Let me trace the history of this... back in 1.5, it worked like this:
<property name="xerces.jar2" value="../../${tools.dir}/lib/xerces.jar"/>
<javac ...
<classpath>
<pathelement path="${xerces.jar2}" />
</classpath>
</javac>
That is also how jesktop currently works. All looks fine to me (tools.dir is
project root-relative).
Then in 1.6, as part of a large commit, a certain 'donaldp' changed it to:
<path id="project.class.path">
..
<pathelement location="xerces.jar2"/>
</path>
<javac ...
<classpath refid="project.class.path" />
</javac>
It looks to me like Peter simply forgot the <property> declaration and ${..}
when creating the separate path.
How could it be otherwise, since "xerces.jar2" doesn't exist in apps/demo/?
apps/bay/build.xml has the same problem. It doesn't show it, because it doesn't
use any org.xml.* classes. But try importing something in xerces.jar in a bay
class, and you'll see what I mean:
[EMAIL PROTECTED]:~/apache/jakarta/jakarta-avalon-cornerstone$ ./build.sh bay
main
..
Compiling 12 source files to
/home/jeff/apache/jakarta/jakarta-avalon-cornerstone/apps/bay/build/classes
/home/jeff/apache/jakarta/jakarta-avalon-cornerstone/apps/bay/src/java/org/apache/avalon/bay/blocks/BayImpl.java:29:
cannot resolve symbol
symbol : class Attributes
location: package sax
import org.xml.sax.Attributes;
^
Assuming all the above is correct, it unearths an interesting fact: for the
last month, nobody has done a 'build.sh' in cornerstone with a clean classpath.
As suggested in a previous email, I think this illustrates the brokenness of
the current system, because developers simply bypass 'build.sh'.
> Question : Are you trying to run ant in the apps/demo
> directory? Or the root for cornerstone and use the "build demo xxxx"
> target where xxx is the target in the build.xml file of demo?
It works if you invoke 'ant' from apps/demo, because your $ANT_HOME/lib
contains the correct classes. If you use build.sh with a clean classpath, it
will fail.
> Assertion : Ant has problems with paths if you intend to to invoke
> building of the same project from multiple directories in a hierarchy.
Indeed.. especially because 'build.sh' constructs a classpath with relative
paths. Currently, any ref to ${java.class.path} in apps/*/build.xml has no
effect.
> I think it needs to be changed back.
Will do so if I'm wrong. Will fix bay if I'm right ;)
--Jeff
> Regards,
>
> - Paul H
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
