I agree its not clear how all this is supposed to work, Venkat and I have also both just being struggling with it.
To be complete, adding to your (a) and (b) in (3) there's also a (c) where both the extension and application logic may share a dependency. Examples of this are js.jar for the JavaScript extension, or AXIOM if an application is using OMElements and the Axis2 WS binding. Could you give an example for what you mean by "simplifying it by being more explicit"? ...ant On 10/5/06, Ken Tam <[EMAIL PROTECTED]> wrote:
While working with Andy on fixing some of the Spring samples, and taking a look at the way the war plugin has replaced the web distro, I ran into a number of issues relating to extensions and their dependencies. 1) It's not obvious how someone building a webapp sample expresses their requirement for a particular extension. Given the maven focus of our current infrastructure, the current way it seems this is done is to just include the extension artifact as a <dependency> entry. Does anyone have a better proposal? I think some metadata might help here -- see the next point. 2) The war plugin doesn't understand extensions. Right now, anything that's a <dependency> by default gets put into WEB-INF/lib, and it might get moved into WEB-INF/tuscany/boot if the plugin determines it only be a transitive dep of the webapp-host. This is totally disconnected from the webapp extension loading mechanism, which requires something to be present in WEB-INF/tuscany/extensions. So it seems the war plugin could benefit from understanding what dependencies are actually extensions, so it could populate it in the right place. I would expect the standalone case to be similar (ie, the sample build would also need to figure out to put it in the extension directory where the DirScanExtender looks). I'm thinking about adding metadata to the POM for extensions so that they can be identified as such, but haven't thought about how to do this yet.. 3) Extensions are loaded into a classloader that isolates them from the application logic (the exact code in deployExtension() has FIXMEs suggesting that while the exact classloader to be used is in flux, the principal of isolation is true). Extensions often have their own dependencies, which I believe fall into 2 categories: a) deps which need to be surfaced to application logic, and thus shouldn't be in the same isolating classloader as the extension itself. b) deps that ought to be hidden from application logic, and can be in the same isolating classloader. Taking the Spring extension as an example, the Spring framework jars themselves would be type A deps. Right now, there is no clear way to manage this -- for example, via maven the dep between the Spring extension and the Spring framework jars is "just another dependency" and so get treated just like any other jars. I'm starting to think that it may actually be counter-productive in the short term to attempt automation of all this -- dependency management in general tends to be a hard problem to automate anyways (look how long it's taken maven to attack, and it's still nowhere near perfect). The war plugin attempts to automagically figure out where all jars need to go, but as I think I've shown, there's a lot of missing metadata needed to do that right. What do folks think about simplifying it by being more explicit, and then slowly moving back to a more automatic model? --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
