On Sun, May 3, 2009 at 1:05 PM, Tim Ellison <[email protected]> wrote: > 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.
I was thinking about this and I was wondering if we should consider adding a "full-clean" or some sort of "reset" that does a clean that mimics a wholly new checkout. I only ran into this because of a fresh check out that required a new download and extract. -Nathan > > 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 >>> >> >
