Build problems due to merger of the Instrument projects

[Leif Mortenson <le...@tanukisoftware.com>]

First of all, I need to apologize for missing the thread a few weeks ago 
about merging the instrument,
instrument-manager and instrument-client projects.

But I am currently running into build problems because the 3 projects 
were merged.  They had been
intentionally split up to allow the build to work correctly with inter 
project dependencies.

The instrument project was designed to be completely free of any 
dependencies other than an optional
dependency on framework.  It was done this way so that any project could 
feel free to make use of
instrumentation even if they are not actually registered with an 
Instrument Manager.

The instrument project is then required by a number of other projects 
including component and pool.

The instrument-manager project is a higher level project which is 
dependent on a number of other
projects, including component and pool.

The instrument-client project could actually have been merged with the 
instrument-manager project
for build purposes.  But I chose to break it out as it is really 
designed to be a stand alone application.

The problem now is that it is necessary to build the instrument project 
twice in order for the optional
dependency on component to be satisfied.  This is because of the 
following circular dependency that
was created with the merger of the projects.

now:
instrument -> component,pool -> instrument

before
instrument-manager -> component,pool -> instrument

Unless there are any ideas for how to handle this problem, I am afraid 
that they are going to have
to be moved back the way they were :-/

Cheers,
Leif



--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

[Commit] Merged ICM into ECM was Re: Build problems due to merger of the Instrument projects

[Leif Mortenson <le...@tanukisoftware.com>]

I just got done merging the InstrumentComponentManager code into the 
ExcaliburComponentManager.
The ExcaliburComponentManager should work exactly as it did before 
unless the user code calls
setInstrumentManager().

This change does require that the jakarta-instrument.jar file be 
released with jakarta-component.jar.

I made every effort to maintain the API as is in the internal classes as 
they may have been extended
by user code out there.  Methods have been declared as deprecated where 
appropriate, but they
should all still function the same as they did before.

I ran the standard test suite and ran it against the apps that I am 
using, but it should be tested with
things like cocoon to make sure that nothing broke along the way.

Good news is that with a simple addition of a call to set the instrument 
manager, any app that uses
the ECM will now be able to use the full features of the Instrumentation 
code.  This also cleaned up
a nasty dependency loop in the build.

Cheers,
Leif

Berin Loritsch wrote:

>>From: Leif Mortenson [mailto:leif@tanukisoftware.com] 
>>
>>now:
>>instrument -> component,pool -> instrument
>>    
>>
>
>  
>
>>before
>>instrument-manager -> component,pool -> instrument
>>
>>Unless there are any ideas for how to handle this problem, I 
>>am afraid 
>>that they are going to have
>>to be moved back the way they were :-/
>>    
>>
>
>The best way is to remove the dependency of instrument
>on component/pool.  I.e. move the instrumentable versions
>(or merge the instrumentable versions) of ECM into the
>its project.
>
>They really don't belong as part of instrument anyways.
>
>
>--
>To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
>For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
>  
>

RE: Build problems due to merger of the Instrument projects

[Berin Loritsch <bl...@apache.org>]

> From: Leif Mortenson [mailto:leif@tanukisoftware.com] 
> 
> now:
> instrument -> component,pool -> instrument

> 
> before
> instrument-manager -> component,pool -> instrument
> 
> Unless there are any ideas for how to handle this problem, I 
> am afraid 
> that they are going to have
> to be moved back the way they were :-/

The best way is to remove the dependency of instrument
on component/pool.  I.e. move the instrumentable versions
(or merge the instrumentable versions) of ECM into the
its project.

They really don't belong as part of instrument anyways.


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>