False Alarm - was: Build failure on missing tuscany-war-plugin
Blowing away my maven repo and starting from afresh cured this. On 21/12/06, kelvin goodson [EMAIL PROTECTED] wrote: I'm getting lots of build failures on doing a mvn clean at the java root level because of a missing plugin groupId=org.apache.tuscany.sca.runtime.webappartifactId=tuscany-war-plugin Is everyone else seeing this? Regards, Kelvin.
[jira] Closed: (TUSCANY-738) tuscany war plugin and default runtime location of extensions seem to be out of sync
[ http://issues.apache.org/jira/browse/TUSCANY-738?page=all ] Rick Rineholt closed TUSCANY-738. - Resolution: Fixed this has been addressed. tuscany war plugin and default runtime location of extensions seem to be out of sync Key: TUSCANY-738 URL: http://issues.apache.org/jira/browse/TUSCANY-738 Project: Tuscany Issue Type: Bug Components: Java SCA Tomcat Integration, Maven Plugins Affects Versions: Java-M2 Reporter: Rick Rineholt Assigned To: Jeremy Boynes Priority: Critical Fix For: Java-M2 By default the tuscany war plugin is put extensions in WEB-INF/tuscany/extensions while by default the runtime is searching for it here: -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-738) tuscany war plugin and default runtime location of extensions seem to be out of sync
tuscany war plugin and default runtime location of extensions seem to be out of sync Key: TUSCANY-738 URL: http://issues.apache.org/jira/browse/TUSCANY-738 Project: Tuscany Issue Type: Bug Components: Java SCA Tomcat Integration, Maven Plugins Affects Versions: Java-M2 Reporter: Rick Rineholt Priority: Critical Fix For: Java-M2 By default the tuscany war plugin is put extensions in WEB-INF/tuscany/extensions while by default the runtime is searching for it here: -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Assigned: (TUSCANY-738) tuscany war plugin and default runtime location of extensions seem to be out of sync
[ http://issues.apache.org/jira/browse/TUSCANY-738?page=all ] Jeremy Boynes reassigned TUSCANY-738: - Assignee: Jeremy Boynes tuscany war plugin and default runtime location of extensions seem to be out of sync Key: TUSCANY-738 URL: http://issues.apache.org/jira/browse/TUSCANY-738 Project: Tuscany Issue Type: Bug Components: Java SCA Tomcat Integration, Maven Plugins Affects Versions: Java-M2 Reporter: Rick Rineholt Assigned To: Jeremy Boynes Priority: Critical Fix For: Java-M2 By default the tuscany war plugin is put extensions in WEB-INF/tuscany/extensions while by default the runtime is searching for it here: -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Tuscany war plugin
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? Also any pointers to the required servlet context listener, filter and servlet (if they exist) will be highly appreciated. Ta Meeraj -Original Message- From: Meeraj Kunnumpurath [mailto:[EMAIL PROTECTED] Sent: 06 September 2006 05:43 To: tuscany-dev@ws.apache.org 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: tuscany-dev@ws.apache.org To: tuscany-dev@ws.apache.org 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
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: tuscany-dev@ws.apache.org 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: tuscany-dev@ws.apache.org To: tuscany-dev@ws.apache.org 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
RE: Tuscany war plugin
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: tuscany-dev@ws.apache.org 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: tuscany-dev@ws.apache.org 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: tuscany-dev@ws.apache.org To: tuscany-dev@ws.apache.org 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
RE: Tuscany war plugin
I will add the code to pull in the bootLibs dependencies transitively. I do apologize my ignorance, could you pls explain what you mean by webapp-host as the default for bootLibs. Also, do you want me to leave the extensions as optional? I guess, even without any extensions, someone should be able to use Tuscany with the Java container and SCA bindings. Thanks for your comments :-) Ta Meeraj -Original Message- From: Jeremy Boynes [mailto:[EMAIL PROTECTED] Sent: 04 September 2006 17:46 To: tuscany-dev@ws.apache.org Subject: Re: Tuscany war plugin I added a sample that uses this plugin to generate the war. The webapp does not actually use SCA at this point and I am going to work on adding that but I wanted to give a couple of comments first. * I think bootLibs dependencies should also pull in transitive ones (but not ones already on the webapp classpath e.g. that are in WEB- INF/lib) * I think the default bootLibs set is just webapp-host (with the rest pulled in transitively) * extensions seems to be a required element - not sure if this was intended and it seems reasonable as an application is likely to need some unless we can come up with a reasonable set of defaults Having this definitely makes setting up the webapp easier though - thanks Meeraj. -- Jeremy On Sep 4, 2006, at 6:14 AM, Meeraj Kunnumpurath wrote: Jeremy, I have posted the plugin on the JIRA (688). We should also support all the features of the normal war plugin - I assume we can get that just by subclassing it. The plugin executes after the Maven WAR plugin and takes the WAR file as the input and adds the boot and extension libraries specified as artifacts. I was not very sure whether Qdox would work on sub-classing the Maven WAR MoJo without access to the source files. I also thought, it was cleaner to build from where the Maven WAR plugin finished, to accept the WAR and enrich it with the Tuscany dependencies. I still haven't done anything about adding the context listener, it shouldn't take much effort. Please let me know if anything needs changing. Ta Meeraj -Original Message- From: Jeremy Boynes [mailto:[EMAIL PROTECTED] Sent: 31 August 2006 15:12 To: tuscany-dev@ws.apache.org Subject: Re: Tuscany war plugin Great - thanks. I think there are three categories: WEB-INF/lib: webapp and its dependencies (host-api) - I think these can just be project dependencies WEB-INF/tuscany/boot: webapp-host and its dependencies - bootLibs configuration element WEB-INF/tuscany/extensions: extensions configuration element All of these should have defaults that can be overridden in the plugin section of the pom, something like: plugin groupdIdorg.apache.tuscany.plugin/groupId artifactIdtuscany-war-plugin/artifactId configuration bootLibs dependency groupIdorg.apache.tuscany/groupId artifactIdcore/artifactId /dependency /bootLibs extensions dependency groupIdorg.apache.tuscany/groupId artifactIdaxis2/artifactId /dependency /extensions /configuration /plugin We should also support all the features of the normal war plugin - I assume we can get that just by subclassing it. Hope that's enough to get started :-) -- Jeremy On Aug 31, 2006, at 5:09 AM, Meeraj Kunnumpurath wrote: Jeremy, I am starting on the war plugin. Could you pls point me to the runtime artefacts (tuscany boot libraries etc) that need to be included in the war? Ta Meeraj -Original Message- From: Jeremy Boynes [mailto:[EMAIL PROTECTED] Sent: 29 August 2006 16:21 To: tuscany-dev@ws.apache.org Subject: Re: Tuscany war plugin Basically set up jars for the runtime rather than using war dependencies to put them in WEB-INF/lib. This would include: * Copy the webapp host jars to WEB-INF/lib * Copy the core runtime to e.g. WEB-INF/tuscany/boot * Take a set of extensions (as artifact references) and add them to e.g. WEB-INF/tuscany/extension * Copy extension dependencies to somewhere an ArtifactRepository can find them It could also check web.xml for the presence of the Tuscany listeners etc. and potentially add them. -- Jeremy On Aug 29, 2006, at 7:20 AM, Bert Lamb wrote: Is there more information on what specifically this plugin would need to do? -Bert On 8/28/06, Jeremy Boynes [EMAIL PROTECTED] wrote: Jim had said that as a prereq to a release then we should have a maven plugin that will set up the webapp runtime in a war. I think that having such a beast would make building the samples easier and so would suggest we get to work on it - is anyone interested in helping? -- Jeremy --- - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e
Re: Tuscany war plugin
+1 - this bit me as well trying to debug stuff. On Sep 5, 2006, at 2:42 PM, Chris Wall wrote: I haven't gotten too deep into the plugin yet, but I have a request. Can we create the target webapp directory (target/[webapp]) with the tuscany boot structure and contents first, and then jar up this directory to create the archived version? This way both the directory and archived WAR match up, and we can also deploy the exploded version of webapp. Thanks. -Chris - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tuscany war plugin
A few questions not necessarily related to the plugin, but to Tuscany webapps in general: 1.) The plugin doesn't define an application scdl location. I think the default is WEB-INF/default.scdl and applicationScdlPath allows for flexibility. But, what is recommended in the context of Tuscany structure (WEB-INF/tuscany)? Or is this structure strictly is for runtime stuff only? Should the plugin create a META-INF/tuscany structure? Could the plugin be application scdl aware and move the scdl to a common location? 2.) Along the lines of #1, where should extension scdls be placed? And how should the main webapp scdl reference these extension scdls. I've been hacking webapp.system.scdl with include.../ references. Obviously this isn't friendly and invasive to Tuscany's core. Could Tuscany append scdls located in a specific location (WEB-INF/tuscany/extensions/scdl) or query the classpath or? 3.) What exactly does Tuscany need in a web.xml - context-params, listeners, filters, etc? I've seen as little as the TuscanyContextListener and systemScdlPath and applicationScdlPath and as much as the following: context-param param-namesystemScdlPath/param-name param-value/META-INF/sca/webapp.system.scdl/param-value /context-param context-param param-nameapplicationScdlPath/param-name param-value/META-INF/sca/default.scdl/param-value /context-param filter filter-nameTuscanyFilter/filter-name filter-classorg.apache.tuscany.runtime.webapp.TuscanyFilter /filter-class /filter filter-mapping filter-nameTuscanyFilter/filter-name url-pattern/*/url-pattern /filter-mapping listenerlistener-class org.apache.tuscany.runtime.webapp.TuscanyContextListener/listener-class /listener listener listener-class org.apache.tuscany.runtime.webapp.TuscanySessionListener/listener-class /listener servlet servlet-nameTuscanyServlet/servlet-name display-nameTuscany Servlet/display-name servlet-classorg.apache.tuscany.runtime.webapp.TuscanyServlet /servlet-class /servlet servlet-mapping servlet-nameTuscanyServlet/servlet-name url-pattern/services/*/url-pattern /servlet-mapping Thanks. -Chris
Re: Tuscany war plugin
On Sep 5, 2006, at 3:20 PM, Chris Wall wrote: A few questions not necessarily related to the plugin, but to Tuscany webapps in general: 1.) The plugin doesn't define an application scdl location. I think the default is WEB-INF/default.scdl and applicationScdlPath allows for flexibility. But, what is recommended in the context of Tuscany structure (WEB-INF/tuscany)? Or is this structure strictly is for runtime stuff only? Should the plugin create a META-INF/ tuscany structure? Could the plugin be application scdl aware and move the scdl to a common location? I think this raises a fairly fundamental question about what the default composite is. The Java CI spec says that there is such a composite but does not say where the SCDL is define nor where its implementations are loaded from. Personally, I think that having a default composite is a problem but I haven't managed to get the spec people to buy into that. If we assume that all the code has to be on the webapp classpath then all we need to know is the location of the scdl for that default composite and in that case isn't WEB-INF/default.scdl a reasonable location? 2.) Along the lines of #1, where should extension scdls be placed? And how should the main webapp scdl reference these extension scdls. I've been hacking webapp.system.scdl with include.../ references. Obviously this isn't friendly and invasive to Tuscany's core. Could Tuscany append scdls located in a specific location (WEB-INF/tuscany/extensions/scdl) or query the classpath or? I was envisioning extension scdls would be packaged in the extension's jar (making it a composite jar) and that jar would be placed in WEB-INF/tuscany/extension by the plugin. There would be an extender in the webapp-host system scdl that would scan that webapp resource (like the DirectoryScanExtender but using ServletContext.getResourcePaths() instead of File.listFiles()). The extension directory could also contain bare XML files (with any code being located through dependency elements in the XML). 3.) What exactly does Tuscany need in a web.xml - context-params, listeners, filters, etc? I've seen as little as the TuscanyContextListener and systemScdlPath and applicationScdlPath and as much as the following: I think we may need all of this (now snipped but you get the idea): * the context listener to start the runtime * the filter to bind the default context to the thread * the servlet to dispatch inbound service requests I also think the number of things is confusing and would like it if the plugin added them :-) -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tuscany war plugin
On 9/5/06, Jeremy Boynes [EMAIL PROTECTED] wrote: On Sep 5, 2006, at 3:20 PM, Chris Wall wrote: A few questions not necessarily related to the plugin, but to Tuscany webapps in general: 1.) The plugin doesn't define an application scdl location. I think the default is WEB-INF/default.scdl and applicationScdlPath allows for flexibility. But, what is recommended in the context of Tuscany structure (WEB-INF/tuscany)? Or is this structure strictly is for runtime stuff only? Should the plugin create a META-INF/ tuscany structure? Could the plugin be application scdl aware and move the scdl to a common location? I think this raises a fairly fundamental question about what the default composite is. The Java CI spec says that there is such a composite but does not say where the SCDL is define nor where its implementations are loaded from. Personally, I think that having a default composite is a problem but I haven't managed to get the spec people to buy into that. If we assume that all the code has to be on the webapp classpath then all we need to know is the location of the scdl for that default composite and in that case isn't WEB-INF/default.scdl a reasonable location? Sure is. I suppose the question was driven by my desire for better webapp organization. Typically the root WEB-INF directory is littered with various configuration files, so I liked the structure the plugin creates. 2.) Along the lines of #1, where should extension scdls be placed? And how should the main webapp scdl reference these extension scdls. I've been hacking webapp.system.scdl with include.../ references. Obviously this isn't friendly and invasive to Tuscany's core. Could Tuscany append scdls located in a specific location (WEB-INF/tuscany/extensions/scdl) or query the classpath or? I was envisioning extension scdls would be packaged in the extension's jar (making it a composite jar) and that jar would be placed in WEB-INF/tuscany/extension by the plugin. There would be an extender in the webapp-host system scdl that would scan that webapp resource (like the DirectoryScanExtender but using ServletContext.getResourcePaths() instead of File.listFiles()). The extension directory could also contain bare XML files (with any code being located through dependency elements in the XML). I like. As far as assembly goes, could we feed the plugin a list of XML files? 3.) What exactly does Tuscany need in a web.xml - context-params, listeners, filters, etc? I've seen as little as the TuscanyContextListener and systemScdlPath and applicationScdlPath and as much as the following: I think we may need all of this (now snipped but you get the idea): * the context listener to start the runtime * the filter to bind the default context to the thread * the servlet to dispatch inbound service requests I also think the number of things is confusing and would like it if the plugin added them :-) Gotcha. -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tuscany war plugin
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. 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. 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? Thanks! -Chris
Re: Tuscany war plugin
On Sep 5, 2006, at 5:26 PM, Chris Wall wrote: snip... 2.) Along the lines of #1, where should extension scdls be placed? And how should the main webapp scdl reference these extension scdls. I've been hacking webapp.system.scdl with include.../ references. Obviously this isn't friendly and invasive to Tuscany's core. Could Tuscany append scdls located in a specific location (WEB-INF/tuscany/extensions/scdl) or query the classpath or? I was envisioning extension scdls would be packaged in the extension's jar (making it a composite jar) and that jar would be placed in WEB-INF/tuscany/extension by the plugin. There would be an extender in the webapp-host system scdl that would scan that webapp resource (like the DirectoryScanExtender but using ServletContext.getResourcePaths() instead of File.listFiles()). The extension directory could also contain bare XML files (with any code being located through dependency elements in the XML). I like. As far as assembly goes, could we feed the plugin a list of XML files? The plugin works off a list of maven dependencies; these default to being jars but can actually have any type including XML: .. plugin configuration extensions dependency !-- com.example/ext1-1.0.jar -- groupIdcom.example/groupId artifactIdext1/artifactId version1.0/version typecomposite/type /dependency dependency !-- com.example/ext2-1.0.xml -- groupIdcom.example/groupId artifactIdext2/artifactId version1.0/version typexml/type /dependency And, of course, an extension (as a jar or as xml) can include other composites or can contain a component implemented by another composite. Either of these techniques could be used to include multiple extensions. -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tuscany war plugin
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]
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: tuscany-dev@ws.apache.org To: tuscany-dev@ws.apache.org 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]
Re: Tuscany war plugin
On Sep 5, 2006, at 9:42 PM, Meeraj Kunnumpurath wrote: 2. Support transitive dependencies for boot libs (do we do the same for extensions?) If we have transitive support in the ArtifactRepositiory then we don't need to support it here as it will be handled at runtime by the repo impl. However, we do need to make sure the artifacts are available. If we are using the local maven repo then I think it would ok just to download the artifacts to there at runtime. However, people may also want to have everything in the war. One way to do that would be to copy from a local maven repo into the war file itself e.g. to /WEB-INF/tuscany/repository and then have a WebappMavenRepository impl of ArtifactRepository that looked there. Just one way it might work :-) -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Tuscany war plugin
Jeremy, I have posted the plugin on the JIRA (688). We should also support all the features of the normal war plugin - I assume we can get that just by subclassing it. The plugin executes after the Maven WAR plugin and takes the WAR file as the input and adds the boot and extension libraries specified as artifacts. I was not very sure whether Qdox would work on sub-classing the Maven WAR MoJo without access to the source files. I also thought, it was cleaner to build from where the Maven WAR plugin finished, to accept the WAR and enrich it with the Tuscany dependencies. I still haven't done anything about adding the context listener, it shouldn't take much effort. Please let me know if anything needs changing. Ta Meeraj -Original Message- From: Jeremy Boynes [mailto:[EMAIL PROTECTED] Sent: 31 August 2006 15:12 To: tuscany-dev@ws.apache.org Subject: Re: Tuscany war plugin Great - thanks. I think there are three categories: WEB-INF/lib: webapp and its dependencies (host-api) - I think these can just be project dependencies WEB-INF/tuscany/boot: webapp-host and its dependencies - bootLibs configuration element WEB-INF/tuscany/extensions: extensions configuration element All of these should have defaults that can be overridden in the plugin section of the pom, something like: plugin groupdIdorg.apache.tuscany.plugin/groupId artifactIdtuscany-war-plugin/artifactId configuration bootLibs dependency groupIdorg.apache.tuscany/groupId artifactIdcore/artifactId /dependency /bootLibs extensions dependency groupIdorg.apache.tuscany/groupId artifactIdaxis2/artifactId /dependency /extensions /configuration /plugin We should also support all the features of the normal war plugin - I assume we can get that just by subclassing it. Hope that's enough to get started :-) -- Jeremy On Aug 31, 2006, at 5:09 AM, Meeraj Kunnumpurath wrote: Jeremy, I am starting on the war plugin. Could you pls point me to the runtime artefacts (tuscany boot libraries etc) that need to be included in the war? Ta Meeraj -Original Message- From: Jeremy Boynes [mailto:[EMAIL PROTECTED] Sent: 29 August 2006 16:21 To: tuscany-dev@ws.apache.org Subject: Re: Tuscany war plugin Basically set up jars for the runtime rather than using war dependencies to put them in WEB-INF/lib. This would include: * Copy the webapp host jars to WEB-INF/lib * Copy the core runtime to e.g. WEB-INF/tuscany/boot * Take a set of extensions (as artifact references) and add them to e.g. WEB-INF/tuscany/extension * Copy extension dependencies to somewhere an ArtifactRepository can find them It could also check web.xml for the presence of the Tuscany listeners etc. and potentially add them. -- Jeremy On Aug 29, 2006, at 7:20 AM, Bert Lamb wrote: Is there more information on what specifically this plugin would need to do? -Bert On 8/28/06, Jeremy Boynes [EMAIL PROTECTED] wrote: Jim had said that as a prereq to a release then we should have a maven plugin that will set up the webapp runtime in a war. I think that having such a beast would make building the samples easier and so would suggest we get to work on it - is anyone interested in helping? -- Jeremy - 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] - 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
Re: Tuscany war plugin
Thanks Meeraj - I'll take a look this morning (its a long weekend in the US) -- Jeremy On Sep 4, 2006, at 6:14 AM, Meeraj Kunnumpurath wrote: Jeremy, I have posted the plugin on the JIRA (688). We should also support all the features of the normal war plugin - I assume we can get that just by subclassing it. The plugin executes after the Maven WAR plugin and takes the WAR file as the input and adds the boot and extension libraries specified as artifacts. I was not very sure whether Qdox would work on sub-classing the Maven WAR MoJo without access to the source files. I also thought, it was cleaner to build from where the Maven WAR plugin finished, to accept the WAR and enrich it with the Tuscany dependencies. I still haven't done anything about adding the context listener, it shouldn't take much effort. Please let me know if anything needs changing. Ta Meeraj -Original Message- From: Jeremy Boynes [mailto:[EMAIL PROTECTED] Sent: 31 August 2006 15:12 To: tuscany-dev@ws.apache.org Subject: Re: Tuscany war plugin Great - thanks. I think there are three categories: WEB-INF/lib: webapp and its dependencies (host-api) - I think these can just be project dependencies WEB-INF/tuscany/boot: webapp-host and its dependencies - bootLibs configuration element WEB-INF/tuscany/extensions: extensions configuration element All of these should have defaults that can be overridden in the plugin section of the pom, something like: plugin groupdIdorg.apache.tuscany.plugin/groupId artifactIdtuscany-war-plugin/artifactId configuration bootLibs dependency groupIdorg.apache.tuscany/groupId artifactIdcore/artifactId /dependency /bootLibs extensions dependency groupIdorg.apache.tuscany/groupId artifactIdaxis2/artifactId /dependency /extensions /configuration /plugin We should also support all the features of the normal war plugin - I assume we can get that just by subclassing it. Hope that's enough to get started :-) -- Jeremy On Aug 31, 2006, at 5:09 AM, Meeraj Kunnumpurath wrote: Jeremy, I am starting on the war plugin. Could you pls point me to the runtime artefacts (tuscany boot libraries etc) that need to be included in the war? Ta Meeraj -Original Message- From: Jeremy Boynes [mailto:[EMAIL PROTECTED] Sent: 29 August 2006 16:21 To: tuscany-dev@ws.apache.org Subject: Re: Tuscany war plugin Basically set up jars for the runtime rather than using war dependencies to put them in WEB-INF/lib. This would include: * Copy the webapp host jars to WEB-INF/lib * Copy the core runtime to e.g. WEB-INF/tuscany/boot * Take a set of extensions (as artifact references) and add them to e.g. WEB-INF/tuscany/extension * Copy extension dependencies to somewhere an ArtifactRepository can find them It could also check web.xml for the presence of the Tuscany listeners etc. and potentially add them. -- Jeremy On Aug 29, 2006, at 7:20 AM, Bert Lamb wrote: Is there more information on what specifically this plugin would need to do? -Bert On 8/28/06, Jeremy Boynes [EMAIL PROTECTED] wrote: Jim had said that as a prereq to a release then we should have a maven plugin that will set up the webapp runtime in a war. I think that having such a beast would make building the samples easier and so would suggest we get to work on it - is anyone interested in helping? -- Jeremy --- - - 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] - 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
Re: Tuscany war plugin
I added a sample that uses this plugin to generate the war. The webapp does not actually use SCA at this point and I am going to work on adding that but I wanted to give a couple of comments first. * I think bootLibs dependencies should also pull in transitive ones (but not ones already on the webapp classpath e.g. that are in WEB- INF/lib) * I think the default bootLibs set is just webapp-host (with the rest pulled in transitively) * extensions seems to be a required element - not sure if this was intended and it seems reasonable as an application is likely to need some unless we can come up with a reasonable set of defaults Having this definitely makes setting up the webapp easier though - thanks Meeraj. -- Jeremy On Sep 4, 2006, at 6:14 AM, Meeraj Kunnumpurath wrote: Jeremy, I have posted the plugin on the JIRA (688). We should also support all the features of the normal war plugin - I assume we can get that just by subclassing it. The plugin executes after the Maven WAR plugin and takes the WAR file as the input and adds the boot and extension libraries specified as artifacts. I was not very sure whether Qdox would work on sub-classing the Maven WAR MoJo without access to the source files. I also thought, it was cleaner to build from where the Maven WAR plugin finished, to accept the WAR and enrich it with the Tuscany dependencies. I still haven't done anything about adding the context listener, it shouldn't take much effort. Please let me know if anything needs changing. Ta Meeraj -Original Message- From: Jeremy Boynes [mailto:[EMAIL PROTECTED] Sent: 31 August 2006 15:12 To: tuscany-dev@ws.apache.org Subject: Re: Tuscany war plugin Great - thanks. I think there are three categories: WEB-INF/lib: webapp and its dependencies (host-api) - I think these can just be project dependencies WEB-INF/tuscany/boot: webapp-host and its dependencies - bootLibs configuration element WEB-INF/tuscany/extensions: extensions configuration element All of these should have defaults that can be overridden in the plugin section of the pom, something like: plugin groupdIdorg.apache.tuscany.plugin/groupId artifactIdtuscany-war-plugin/artifactId configuration bootLibs dependency groupIdorg.apache.tuscany/groupId artifactIdcore/artifactId /dependency /bootLibs extensions dependency groupIdorg.apache.tuscany/groupId artifactIdaxis2/artifactId /dependency /extensions /configuration /plugin We should also support all the features of the normal war plugin - I assume we can get that just by subclassing it. Hope that's enough to get started :-) -- Jeremy On Aug 31, 2006, at 5:09 AM, Meeraj Kunnumpurath wrote: Jeremy, I am starting on the war plugin. Could you pls point me to the runtime artefacts (tuscany boot libraries etc) that need to be included in the war? Ta Meeraj -Original Message- From: Jeremy Boynes [mailto:[EMAIL PROTECTED] Sent: 29 August 2006 16:21 To: tuscany-dev@ws.apache.org Subject: Re: Tuscany war plugin Basically set up jars for the runtime rather than using war dependencies to put them in WEB-INF/lib. This would include: * Copy the webapp host jars to WEB-INF/lib * Copy the core runtime to e.g. WEB-INF/tuscany/boot * Take a set of extensions (as artifact references) and add them to e.g. WEB-INF/tuscany/extension * Copy extension dependencies to somewhere an ArtifactRepository can find them It could also check web.xml for the presence of the Tuscany listeners etc. and potentially add them. -- Jeremy On Aug 29, 2006, at 7:20 AM, Bert Lamb wrote: Is there more information on what specifically this plugin would need to do? -Bert On 8/28/06, Jeremy Boynes [EMAIL PROTECTED] wrote: Jim had said that as a prereq to a release then we should have a maven plugin that will set up the webapp runtime in a war. I think that having such a beast would make building the samples easier and so would suggest we get to work on it - is anyone interested in helping? -- Jeremy --- - - 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] - 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
RE: Tuscany war plugin
Jeremy, I am starting on the war plugin. Could you pls point me to the runtime artefacts (tuscany boot libraries etc) that need to be included in the war? Ta Meeraj -Original Message- From: Jeremy Boynes [mailto:[EMAIL PROTECTED] Sent: 29 August 2006 16:21 To: tuscany-dev@ws.apache.org Subject: Re: Tuscany war plugin Basically set up jars for the runtime rather than using war dependencies to put them in WEB-INF/lib. This would include: * Copy the webapp host jars to WEB-INF/lib * Copy the core runtime to e.g. WEB-INF/tuscany/boot * Take a set of extensions (as artifact references) and add them to e.g. WEB-INF/tuscany/extension * Copy extension dependencies to somewhere an ArtifactRepository can find them It could also check web.xml for the presence of the Tuscany listeners etc. and potentially add them. -- Jeremy On Aug 29, 2006, at 7:20 AM, Bert Lamb wrote: Is there more information on what specifically this plugin would need to do? -Bert On 8/28/06, Jeremy Boynes [EMAIL PROTECTED] wrote: Jim had said that as a prereq to a release then we should have a maven plugin that will set up the webapp runtime in a war. I think that having such a beast would make building the samples easier and so would suggest we get to work on it - is anyone interested in helping? -- Jeremy - 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] - 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]
Re: Tuscany war plugin
Great - thanks. I think there are three categories: WEB-INF/lib: webapp and its dependencies (host-api) - I think these can just be project dependencies WEB-INF/tuscany/boot: webapp-host and its dependencies - bootLibs configuration element WEB-INF/tuscany/extensions: extensions configuration element All of these should have defaults that can be overridden in the plugin section of the pom, something like: plugin groupdIdorg.apache.tuscany.plugin/groupId artifactIdtuscany-war-plugin/artifactId configuration bootLibs dependency groupIdorg.apache.tuscany/groupId artifactIdcore/artifactId /dependency /bootLibs extensions dependency groupIdorg.apache.tuscany/groupId artifactIdaxis2/artifactId /dependency /extensions /configuration /plugin We should also support all the features of the normal war plugin - I assume we can get that just by subclassing it. Hope that's enough to get started :-) -- Jeremy On Aug 31, 2006, at 5:09 AM, Meeraj Kunnumpurath wrote: Jeremy, I am starting on the war plugin. Could you pls point me to the runtime artefacts (tuscany boot libraries etc) that need to be included in the war? Ta Meeraj -Original Message- From: Jeremy Boynes [mailto:[EMAIL PROTECTED] Sent: 29 August 2006 16:21 To: tuscany-dev@ws.apache.org Subject: Re: Tuscany war plugin Basically set up jars for the runtime rather than using war dependencies to put them in WEB-INF/lib. This would include: * Copy the webapp host jars to WEB-INF/lib * Copy the core runtime to e.g. WEB-INF/tuscany/boot * Take a set of extensions (as artifact references) and add them to e.g. WEB-INF/tuscany/extension * Copy extension dependencies to somewhere an ArtifactRepository can find them It could also check web.xml for the presence of the Tuscany listeners etc. and potentially add them. -- Jeremy On Aug 29, 2006, at 7:20 AM, Bert Lamb wrote: Is there more information on what specifically this plugin would need to do? -Bert On 8/28/06, Jeremy Boynes [EMAIL PROTECTED] wrote: Jim had said that as a prereq to a release then we should have a maven plugin that will set up the webapp runtime in a war. I think that having such a beast would make building the samples easier and so would suggest we get to work on it - is anyone interested in helping? -- Jeremy - 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] - 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]
RE: Tuscany war plugin
I can help out, if no one else has volunteered yet. -Original Message- From: Jim Marino [mailto:[EMAIL PROTECTED] Sent: 28 August 2006 22:23 To: tuscany-dev@ws.apache.org Subject: Re: Tuscany war plugin Hopefully it won't be a beast ;-) On Aug 28, 2006, at 1:40 PM, Jeremy Boynes wrote: Jim had said that as a prereq to a release then we should have a maven plugin that will set up the webapp runtime in a war. I think that having such a beast would make building the samples easier and so would suggest we get to work on it - is anyone interested in helping? -- Jeremy - 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. * 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]
Re: Tuscany war plugin
Basically set up jars for the runtime rather than using war dependencies to put them in WEB-INF/lib. This would include: * Copy the webapp host jars to WEB-INF/lib * Copy the core runtime to e.g. WEB-INF/tuscany/boot * Take a set of extensions (as artifact references) and add them to e.g. WEB-INF/tuscany/extension * Copy extension dependencies to somewhere an ArtifactRepository can find them It could also check web.xml for the presence of the Tuscany listeners etc. and potentially add them. -- Jeremy On Aug 29, 2006, at 7:20 AM, Bert Lamb wrote: Is there more information on what specifically this plugin would need to do? -Bert On 8/28/06, Jeremy Boynes [EMAIL PROTECTED] wrote: Jim had said that as a prereq to a release then we should have a maven plugin that will set up the webapp runtime in a war. I think that having such a beast would make building the samples easier and so would suggest we get to work on it - is anyone interested in helping? -- Jeremy - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tuscany war plugin
Darn good idea. Meeraj et al., let me know if you need help. I can help out w/ development or simply being a guniea pig. -Chris
Re: Tuscany war plugin
Hopefully it won't be a beast ;-) On Aug 28, 2006, at 1:40 PM, Jeremy Boynes wrote: Jim had said that as a prereq to a release then we should have a maven plugin that will set up the webapp runtime in a war. I think that having such a beast would make building the samples easier and so would suggest we get to work on it - is anyone interested in helping? -- Jeremy - 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]
