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 >> >
