The last time I looked at the WAR plugin (or last time I checked it in :-)), it would write the extensions to WEB-INF/tuscany/extensions directory of the WAR and the transitive dependencies to WEB-INF/tuscany/repository directory in a Maven repo format. Only the boot libraries and their transitive dependencies are written to WEB-INF/tuscany/boot directory. Nothing is written to the WEB-INF/lib directory.
However, the runtime logic to query these locations and resolve the dependencies is not implemented yet. There is an ArtifactRepository interface and a MavenArtifactRepository implementaion, currently, which would resolve the dependencies if a Maven repo is available at runtime. I think Jeremy is looking into integrating this with the extension loader. I am working on getting this working from a packaged deployed unit (war) without a Maven repo at runtime (if all the dependencies were packaged in during the build using the plugin). Ta Meeraj >> -----Original Message----- >> From: Ken Tam [mailto:[EMAIL PROTECTED] >> Sent: 05 October 2006 12:07 >> To: [email protected] >> Subject: Packaging, usage of, and classloading for >> extensions & their dependencies >> >> 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] >> >> >> This message has been checked for all email viruses by MessageLabs. >> >> ***************************************************** You can find us at www.voca.com ***************************************************** This communication is confidential and intended for the exclusive use of the addressee only. You should not disclose its contents to any other person. If you are not the intended recipient please notify the sender named above immediately. Registered in England, No 1023742, Registered Office: Voca Limited Drake House, Three Rivers Court, Homestead Road, Rickmansworth, Hertfordshire, WD3 1FX This message has been checked for all email viruses by MessageLabs. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
