You really got me scratching my head and asking around. I hope the answers interspersed below are readable after this email has been distributed to virgo-dev...
On 15 Jul 2010, at 04:03, Dmitry Sklyut wrote:Glad to hear it.
> So after a bit of hiatus I finally got some time to work on maven build for virgo.
That used to be true, but medic is now excluded from the EntryExitTrace joinpoint specification as part of the recent "5x" startup performance improvement. (The aspect build can probably be tidied up in due course.)
> It was mostly a smooth running till I hit medic component.
> Here is what I understand up to this moment:
> 1. *.medic == API bundle
> Code here is woven with EntryExitTrace aspect
This can be deleted in due course as the aspect which used to depend on it was deleted in the performance work. Some other code probably needs changing to remove all references to LoggingInterceptor.
> 2. medic.weaving == Aspect library
I think this is now equivalent to the Logback classic JAR as the weaving is now a no-op.
> 3. org.eclipse.virgo.ch.qos.logback.classic.woven
> As the name says - a woven logback.classic with medic.weaving aspect
That seems to be an oversight. They should be exported with the logback version. If you raise a bug and ideally provide a patch, this can be changed very easily. (I believe no-one is using these exports as they are not imported in the kernel region. In particular these exports are not imported into the user region and so are not available for applications to import.)
> 4. medic.core = implementation of API
> Now the issues that is throwing me off is a manifest generated for medic.core (attached).
> So my questions:
> 1. Why is all of the logback.classic and logback.core packages are exported with medic.core version?
Yes. Medic is designed so that people can write their own Logback appenders which therefore need access to the Logback appender type.
> 2. Should those exports be there?
By design. There is a testcase that implements a Logback appender.
> 3. Is that by design or just because jars got copied to target/classes and bundlor was happy to use them?
> 4. template.mf does not specify Bundle-ClassPath, is it bundlor that adds it when it finds jars? (did not know it can do it).
I believe the original reasoning may have been to place the Logback core and classic classes in a single class loader to address some class loading scenarios, but we do not appear to have taken advantage of that. Another reason may have been to (partially) hide the existence of the woven Logback classic JAR to avoid confusion with a vanilla Logback classic JAR, but that isn't important now that we are no longer weaving Logback classic.
> And just out of curiosity:
> 5. Why do those bundles need to be embedded?
However, I quite like these JARs being embedded in medic core as it avoids unnecessary bundle loading at startup.
The purpose of weaving was to enable in-memory logging, which we no longer provide.
> 6. Why do they need to be weaved (I have not dug too deep into code yet to get it)?
virgo-dev mailing list