It tried a quick fix but that didn't work because it turns out the "build" target in build.xml does not depend on "check-depends" as I thought it did. (It turns out there is a "prepare-depends" target in make/build-java.xml which is used instead and there is no depends checking in the build-native tasks. So there is probably a little tidying up to do here.)
It should be fixed now. I still need to figure out why my remove-depends/clean/build cycle didn't see this bug. -Mark. In message <[email protected]>, Tim Ellison writes: > > Nathan Beyer wrote: > > The work around seems to be moving into 'module/jmx' and running > > 'ant', which will extract the mx4j zip file and then navigating back > > up and compiling again. > > It appears to have been caused by r770234 (Moving mx4j dependencies to a > module) which removed the copying of the mx4j JARs into the > bootclasspath before the Harmony code is compiled. > > The same has been done for yoko too, but I guess we don't depend upon > that for a clean compile. > > I'll give Mark a chance to fix it first. I wonder, with the new model > for dealing with some dependencies in pseudo-modules, we need a > poll-modules call to a (new) "pre-compile" target to allow the modules > to do such things? > > It also shows that we need to do more thorough check-in / build testing. > > Regards, > Tim > > > On Sat, May 2, 2009 at 5:59 PM, Nathan Beyer <[email protected]> wrote: > >> Since MX4J was moved into the JMX module, the logging and > >> lang-management modules are no longer compiling. All of the JMX APIs > >> seem to be missing from classpath. > >> > >> I haven't dug into the new dependency changes much, so I'm not > >> familiar with how the classpath is being built now. Any suggestions? > >> > >> -Nathan > >> > > >
