I have been going through the dependencies of the various projects and do not see
where there would be any dependency problems created by merging the
pool-instrumented into pool-impl, and thread-instrumented into thread-impl packages.
It looks like the dependency loops were all cleaned up by breaking the component
package up into component, testcase and component-tests.
There is nothing in the dependency trees that I can find that would cause any loops by
merging the Instrumented versions back into their originals. I know that there
used to be so this is a credit to all of your hard work breaking things up.
Here are the dependency paths that currently exist in the packages involved: (They can be skipped if you want. More comments below.)
instrument Direct: none Indirect: none External: framework-api, framework-impl
instrument-spi Direct: instrument Indirect: none External: framework-api, xml-apis
instrument-impl Direct: instrument, instrument-spi Indirect: none External: framework-api, framework-impl, xml-apis
pool-api Direct: none Indirect: none External: framework-api
pool-impl
Direct: pool-api
Indirect: none
External: framework-api, framework-impl, commons-collections, concurrent, junitperf
pool-instrumented
Direct: pool-api, pool-impl, instrument
Indirect: none
External: framework-api, framework-impl, commons-collections, concurrent, junitperf
i18n Direct: none Indirect: none External: none
logger Direct: i18n Indirect: none External: logkit, framework-api, servletapi, log4j, javamail, jms, xml-apis
component
Direct: logger, instrument, instrument-spi, instrument-impl, pool-api, pool-impl, pool-instrumented,
Indirect: i18n
External: logkit, framework-api, framework-impl, commons-collections, concurrent, serletapi, junit
thread-api Direct: none Indirect: none External: framework-api
thread-impl Direct: thread-api, pool-api, pool-impl Indirect: none External: framework-api, framework-impl, commons-collections, concurrent
thread-instrumented
Direct: thread-api, thread-impl, pool-api, pool-impl, instrument, pool-instrumented
Indirect:
External: framework-api, framework-impl, commons-collections, concurrent
By the way, what does the "spi" in instrument-spi stand for? I had originally broken
the instrument-manager into two jars because a connecting altrmi client did not need
to have access to the full api. If I am going to wipe out altrmi, then a lot of this could
probably be further cleaned up and simplified.
Cheers, Leif
Leif Mortenson wrote:
Leo Simons wrote:
Leif Mortenson wrote:
Also it looks like the pool and thread packages have been broken up into
instrumented and uninstrumented copies of the components. Is this really
necessary?
I don't know.
I would like to wait with changing any of this back until we have excalibur building using gump again (right now gump is building the version in cvs). I really don't want to go back to a complex build that continuously breaks.
Excalibur used to be a really big mess dependency-wise, and this is now less of an issue. I'd like to keep it that way.
Agreed. If it is possible to clean up the dependency tree amongst the tests however
then remerging the pool code would be desirable.
maintenance nightmare. If a user does not wish to use instrumentation
then all they need to do is include the instrument jar, which is extremely
small. I think it would be wise to get rid of the uninstrumented versions
and go back to only having one copy of the source. This is akin to creating
a version of the classes which do not do logging... Thoughts?
I fear that the two will quickly diverge and become a
I thought that there were just a few classes in pool with instrumentation, and those were moved out for dependency management reasons.
There are only a few with instrumentation. The problem is that the class
ResourceLimitingPool used to be instrumented. It is widely used in my code.
That class was copied as InstrumentedResourceLimitingPool and the original
had all of its instrumentation removed. This is the naming change that I was
referring to. If possible, I would like to get this worked out before a release.
Once that happens it gets more and more difficult to change back.
[EMAIL PROTECTED] instrumented]$ pwd
/home/lsimons/svn/asf/excalibur/trunk/pool/instrumented
[EMAIL PROTECTED] instrumented]$ find . -name '*.java'
./src/java/org/apache/avalon/excalibur/pool/ValidatedResourceLimitingPool.java
./src/java/org/apache/avalon/excalibur/pool/InstrumentedResourceLimitingPool.java
[EMAIL PROTECTED] instrumented]$ cd ../impl/
<snip>
In summary: Niclas broke things out for a good reason (in order to figure out the dependency chain), I'm okay with changing things again, but only if the dependency graph stays clean and we use gump to verify that.
Ok, I will look into how that can be done.
Cheers, Leif
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Apache Excalibur Project -- URL: http://excalibur.apache.org/
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Apache Excalibur Project -- URL: http://excalibur.apache.org/
