Ok, no worries :-) I will prod through the Maven source.  I think
Chris's post has got all I need.

Ta
Meeraj

-----Original Message-----
From: Jeremy Boynes [mailto:[EMAIL PROTECTED] 
Sent: 06 September 2006 19:28
To: [email protected]
Subject: Re: Tuscany war plugin

On Sep 6, 2006, at 10:57 AM, Meeraj Kunnumpurath wrote:

> Jeremy,
>
> 1 & 4 are done. I am scratching my head around understanding the usage

> of ArtifactResolver.resolveTransitively() from the Maven artifact API.
> Do you have any idea?

Sorry, not really.

> Also any pointers to the  required servlet context listener, filter 
> and servlet (if they exist) will be highly appreciated.

Best I have is Chris's post here:
http://mail-archives.apache.org/mod_mbox/ws-tuscany-dev/200609.mbox/%
[EMAIL PROTECTED]

> Ta
> Meeraj
>
> -----Original Message-----
> From: Meeraj Kunnumpurath [mailto:[EMAIL PROTECTED]
> Sent: 06 September 2006 05:43
> To: [email protected]
> Subject: Re: Tuscany war plugin
>
> Jeremy/Chris,
>
> Following the thread between you two, these are the changes I plan to 
> make,
>
> 1. Support exploded deployment
> 2. Support transitive dependencies for boot libs (do we do the same 
> for
> extensions?)
> 3. Enrich the web xml with the context listener, filter and servlet 4.
> Use web-app-host as the default for bootLibs
>
> Have I missed anything (it is still early morning, I need to have my 
> coffee
> :-))
>
>> I like the idea of reusing all of this function from Maven (given the

>> number of easily available artifacts plus its support for intranet
>> configurations) but we need to chat to the Maven folks to see how   
>> easy
>
>> it would be to extract that function. Any help here would be
> appreciated.
>
> If we decide to use Maven for resolving the extension dependencies, 
> wouldn't this work the same way as that for bootLibs (Most of the 
> stuff in the plugin is factored out from the Maven dependency plugin)
>
> Ta
> Meeraj
>
>
>> From: Jeremy Boynes <[EMAIL PROTECTED]>
>> Reply-To: [email protected]
>> To: [email protected]
>> Subject: Re: Tuscany war plugin
>> Date: Tue, 5 Sep 2006 19:41:13 -0700
>>
>> On Sep 5, 2006, at 6:03 PM, Chris Wall wrote:
>>
>>> Some more questions.... :-)
>>>
>>> 1.) I suppose I don't understand extensions.  If an application uses

>>> implementation.spring and binding.ws, should the Spring container  
>>> and
>
>>> Celtix binding jars be bootLibs or extensions?  Both extend the 
>>> core,
>>> so  my initial guess was that they both were extensions.   
>>> Configuring
>>> them as such  each produce MissingResourceException during Tuscany 
>>> bootstrapping.  As bootLibs both resources are found.
>>
>> They should be extensions but the extension mechanism is not working 
>> yet for webapps (WIP).
>>
>>> 2.) Maybe this is WIP, but transitive dependencies are not pulled 
>>> into the webapp.  For example, the Celtix binding requires many 
>>> additional  jars, but are not included in the WAR -
>>> NoClassDefFoundError:
>>> javax/wsdl/WSDLException.
>>
>> They are not - I hope Meeraj is working on support for that for
> bootLibs.
>>
>> For extension, we need to do a couple of things:
>> 1) find out what the dependencies for an extension are - this was the

>> discussion Jim and I had a while ago about using OSGi dependencies  
>> vs.
>> using Maven meta-data either read from the jar or by using 
>> <dependency> elements in the scdl.
>> 2) use the ArtifactRepository to resolve those dependencies (e.g.   
>> from
>
>> a local maven repo)
>>
>> I like the idea of reusing all of this function from Maven (given the

>> number of easily available artifacts plus its support for intranet
>> configurations) but we need to chat to the Maven folks to see how   
>> easy
>
>> it would be to extract that function. Any help here would be
> appreciated.
>>
>> As a work around, you can always use Class-Path entries in the
> extensions'
>> manifests to include the dependencies.
>>
>>>
>>> 3.) How does the plugin and bootstrap handle the scenario where a 
>>> bootLib and/or extension lib share a dependency with the 
>>> application?
>
>>> Will  the plugin and bootstrap mechanism default to
> WEB-INF/lib/<shared-jar>?
>>
>> The host's classloader (for a webapp this is the TCCL) is a parent 
>> classloader for all the runtime classloaders. So extensions are 
>> children of the runtime boot loader which is a child of the webapp 
>> loader. Putting things in WEB-INF/lib should make them available to 
>> everything. Having said that I am not convinced we are following this

>> structure everywhere and I am in the process of going back through  
>> and
>
>> checking how we set them all up.
>>
>> --
>> Jeremy
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> For additional commands, e-mail: [EMAIL PROTECTED]
>>
>
> _________________________________________________________________
> Be the first to hear what's new at MSN - sign up to our free 
> newsletters!
> http://www.msn.co.uk/newsletters
>
>
> ---------------------------------------------------------------------
> 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]
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


This message has been checked for all email viruses by MessageLabs.



This message has been checked for all email viruses by MessageLabs.

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to