Mailing-List: contact dev-help@harmony.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@harmony.apache.org
Received-SPF: neutral (nike.apache.org: 195.212.29.153 is neither permitted
 nor denied by domain of mark.hindess@googlemail.com)
Message-Id: <200905050919.n459Jv5p019800@d12av03.megacenter.de.ibm.com>
In-reply-to: <49FDDCEF.3050603@gmail.com> 
References: <3b3f27c60905021559n15d969aeja1b98e0c0e4dd1ed@mail.gmail.com>
 <3b3f27c60905021603m7724c347mad3f8e92734cd058@mail.gmail.com>
 <49FDDCEF.3050603@gmail.com>
Comments: In-reply-to Tim Ellison <t.p.ellison@gmail.com>
   message dated "Sun, 03 May 2009 19:05:35 +0100."
From: Mark Hindess <mark.hindess@googlemail.com>
To: dev@harmony.apache.org
Subject: Re: [classlib] logging and lang-management no longer compiling since
 mx4j move 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Tue, 05 May 2009 10:19:57 +0100


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 <49FDDCEF.3050603@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 <ndbeyer@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
> >>
> > 
>