Re: [classlib] logging and lang-management no longer compiling since mx4j move

[Mark Hindess <ma...@googlemail.com>]

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 <49...@gmail.com>, 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 <nd...@apache.org> 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
> >>
> > 
>