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

[Nathan Beyer <nd...@apache.org>]

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.

-Nathan

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
>

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

[Nathan Beyer <nd...@apache.org>]

On Sun, May 3, 2009 at 1:05 PM, Tim Ellison <t....@gmail.com> 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 <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
>>>
>>
>

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

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

[Tim Ellison <t....@gmail.com>]

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