Re: Adding 2 webapp jars to binary distro
Jim, See comments inline. Simon Jim Marino wrote: On Nov 10, 2006, at 10:44 AM, Simon Nash wrote: As far as I know these are the only things (apart from the core Tuscany runtime and application artifacts) that always need to be physically packaged within the war. Other things would either not always be required, or could be downloaded as an alternative to being physically packaged. There will be others, such as resource host implementations, data source providers, etc. We would do well to create a solution that will work now and in the future. I believe the approach of having an Ant task will do this. This discussion is not about whether there should be an Ant task. We have both said that there should be. We are debating whether having a convenience download packaging would be helpful for some users and some use cases. So now for Ant users we require them to use the runtime resolution mechanism? We've basically punted the problem to the runtime. For me, we need to address the problem of transitive dependencies when building the archive. As an Ant user, the latter strike me as more inline with that build mechanism. As I said, we should support both build-time and runtime resolution of extension dependencies for both maven and ant builds. We should not require ant users to use runtime resolution, but we should support this as an option. The choice of build tool should not dictate whether build-time or runtime resolution is used. Good so we are on the same page. An Ant task will need to be provided that can download transitive extension dependencies. Yes, we are agreed about this. The problem is if we require everything locally, as you are suggesting, we are going to wind up with a kitchen sink distro. Again, I would suggest we provide an Ant task that can provisioning any required dependency from a remote repo and assemble a runtime for any host from the core distribution. Bootstrappers would be provisioned when the war was created. Note that this does not include placing boostrap code related to running in a web app into core, which is inappropriate. It also makes the two use cases you mentioned below dead-simple as well as reduces the complexity of the Ant script that would be required to build the archive. I am not suggesting that we should require everything locally. The discussion is around the bootstrapping code, specifically bootstrapping for webapps. I am not saying that this code is part of core, but that it should be made available locally as part of our binary distro for use in common cases embodied in our samples, just as we make other non- core code available locally via the contrib directory. And we will have bootstrapping code for OSGi containers, potentially a Geronimo GBean, IntelliJ plugin, Eclipse plugin, etc. This will mean we have to bundle all of this into the core distro which really breaks modularity. I wouldn't mind having separate distros for each of these. Otherwise, the same Ant Task that is required above could be repurposed for this. I have not proposed bundling all of these things into a single binary distro. What is bundled should depend on use cases and how commonly the various artifacts will be used. We are currently doing a modest amount of bundling by putting certain extensions into the contrib directory. So I am not suggesting a new approach here, but extending the existing approach to include one more very common use case. All the examples of downloadable binary distros that I looked at were from open source projects, not commercial software. There is value in making something available that is in line with common open source practice and is familiar to a large category of users, as this will help to get a broader community engaged with Tuscany. Some of our users will be familiar with maven and will want to do their builds in the manner that you describe with remote downloading of everything from the maven repos, while others will prefer a package that contains at least the artifacts needed in order to build simple samples. We should be willing to accommodate the preferences of both kinds of users. I agree that's why I was proposing an Ant task. That would be dead- simple, avoid a bloated distro with a lot of irrelevant modules, and would fit into how people do Ant builds without introducing anti- patterns such as manually copying files from place to place. As I said, we agree on having an ant task that supports remote downloading. The debate is about whether very simple cases whould require remote downloading, which introduces complexities such as the need for network connectivity and availability of the repositories. Some users prefer this approach, and others prefer the simplicity of having things available locally in locations that they can control. In order to appeal to all types of users, we should accommodate both styles rather than insist on one
Re: Adding 2 webapp jars to binary distro
Jim, See comments inline. Simon Jim Marino wrote: I agree that Tuscany webapps will normally receive or make remote invocations, and these will require Tuscany extensions and their dependencies. These extensions and dependencies can be bundled physically within the war file, or the dependencies can be downloaded at runtime from an external maven repo. Currently the extensions can't be downloaded at runtime, but this is something that we could (and IMO should) support in the future. The 2 webapp jars are in a different category. They always need to be physically packaged inside the webapp and can never be downloaded at runtime. There are ways around this but there is a broader issue that I mentioned previously, namely these are not the only things that need to be provisioned for Ant users who want to have things statically packaged in the war. . As far as I know these are the only things (apart from the core Tuscany runtime and application artifacts) that always need to be physically packaged within the war. Other things would either not always be required, or could be downloaded as an alternative to being physically packaged. This is why they are in a different category than extensions and dependencies, and should be considered for different treatment as far as packaging is concerned. The helloworldws sample (one of those for which I provided an ant build script) is an example of the use case I have in mind. It receives remote invocations over Web services using the Axis2 binding and the SDO data binding. These Tuscany extensions are packaged inside the war file, but not their dependencies (either local or transitive). The Tuscany runtime loads these dependencies from an external maven repo. So now for Ant users we require them to use the runtime resolution mechanism? We've basically punted the problem to the runtime. For me, we need to address the problem of transitive dependencies when building the archive. As an Ant user, the latter strike me as more inline with that build mechanism. As I said, we should support both build-time and runtime resolution of extension dependencies for both maven and ant builds. We should not require ant users to use runtime resolution, but we should support this as an option. The choice of build tool should not dictate whether build-time or runtime resolution is used. To build the helloworldws war file in this form, my ant script takes the Tuscany runtime from the atandalone/binary distro, and the Axis2 binding and SDO data binding Tuscany extensions from the contrib directory of the distro. The only things it currently cannot obtain from the locally installed distro are the 2 webapp jars. Forcing a remote download for these two jars, when everything else can be found locally, makes this common use case considerably more complex for a first-time or inexperienced user. The problem is if we require everything locally, as you are suggesting, we are going to wind up with a kitchen sink distro. Again, I would suggest we provide an Ant task that can provisioning any required dependency from a remote repo and assemble a runtime for any host from the core distribution. Bootstrappers would be provisioned when the war was created. Note that this does not include placing boostrap code related to running in a web app into core, which is inappropriate. It also makes the two use cases you mentioned below dead-simple as well as reduces the complexity of the Ant script that would be required to build the archive. I am not suggesting that we should require everything locally. The discussion is around the bootstrapping code, specifically bootstrapping for webapps. I am not saying that this code is part of core, but that it should be made available locally as part of our binary distro for use in common cases embodied in our samples, just as we make other non-core code available locally via the contrib directory. In summary, the ant support for building war files must cover the following cases: 1. build war files with all required Tuscany extensions and their dependencies packaged within the war file 2. build war files with all required Tuscany extensions packaged within the war file, and their dependencies downloaded at runtime Packaging the 2 webapp jars within the downloadable distro simplifies the logistics of case 2 for webapps using extensions that we deliver as part of the distro, which is a common scenario. What I would recommend doing to help Ant users is to create a utility that can be invoked from an Ant Task, programmatically, or from the command line which downloads transitive dependencies from a Maven repository. As an implementation strategy, the first place I would look at is just wrapping Maven (or Wagon, the part that actually does the downloading). I would also keep in mind that reusing Maven will avoid the trouble of having to write code that parses and
Re: Adding 2 webapp jars to binary distro
On Nov 10, 2006, at 10:44 AM, Simon Nash wrote: As far as I know these are the only things (apart from the core Tuscany runtime and application artifacts) that always need to be physically packaged within the war. Other things would either not always be required, or could be downloaded as an alternative to being physically packaged. There will be others, such as resource host implementations, data source providers, etc. We would do well to create a solution that will work now and in the future. I believe the approach of having an Ant task will do this. So now for Ant users we require them to use the runtime resolution mechanism? We've basically punted the problem to the runtime. For me, we need to address the problem of transitive dependencies when building the archive. As an Ant user, the latter strike me as more inline with that build mechanism. As I said, we should support both build-time and runtime resolution of extension dependencies for both maven and ant builds. We should not require ant users to use runtime resolution, but we should support this as an option. The choice of build tool should not dictate whether build-time or runtime resolution is used. Good so we are on the same page. An Ant task will need to be provided that can download transitive extension dependencies. The problem is if we require everything locally, as you are suggesting, we are going to wind up with a kitchen sink distro. Again, I would suggest we provide an Ant task that can provisioning any required dependency from a remote repo and assemble a runtime for any host from the core distribution. Bootstrappers would be provisioned when the war was created. Note that this does not include placing boostrap code related to running in a web app into core, which is inappropriate. It also makes the two use cases you mentioned below dead-simple as well as reduces the complexity of the Ant script that would be required to build the archive. I am not suggesting that we should require everything locally. The discussion is around the bootstrapping code, specifically bootstrapping for webapps. I am not saying that this code is part of core, but that it should be made available locally as part of our binary distro for use in common cases embodied in our samples, just as we make other non- core code available locally via the contrib directory. And we will have bootstrapping code for OSGi containers, potentially a Geronimo GBean, IntelliJ plugin, Eclipse plugin, etc. This will mean we have to bundle all of this into the core distro which really breaks modularity. I wouldn't mind having separate distros for each of these. Otherwise, the same Ant Task that is required above could be repurposed for this. All the examples of downloadable binary distros that I looked at were from open source projects, not commercial software. There is value in making something available that is in line with common open source practice and is familiar to a large category of users, as this will help to get a broader community engaged with Tuscany. Some of our users will be familiar with maven and will want to do their builds in the manner that you describe with remote downloading of everything from the maven repos, while others will prefer a package that contains at least the artifacts needed in order to build simple samples. We should be willing to accommodate the preferences of both kinds of users. I agree that's why I was proposing an Ant task. That would be dead- simple, avoid a bloated distro with a lot of irrelevant modules, and would fit into how people do Ant builds without introducing anti- patterns such as manually copying files from place to place. Jim - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Adding 2 webapp jars to binary distro
On Nov 8, 2006, at 11:01 PM, Jim Marino wrote: What I would recommend doing to help Ant users is to create a utility that can be invoked from an Ant Task, programmatically, or from the command line which downloads transitive dependencies from a Maven repository. As an implementation strategy, the first place I would look at is just wrapping Maven (or Wagon, the part that actually does the downloading). I would also keep in mind that reusing Maven will avoid the trouble of having to write code that parses and understands Maven POMs. I would also look to see what can be shared with the Maven War plugin we currently have to avoid duplicated effort and code. I've not used it but there is an extension for Maven that supports this: http://maven.apache.org/ant-tasks.html YMMV -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Adding 2 webapp jars to binary distro
Jim, See my comments inline. Simon Jim Marino wrote: On Nov 8, 2006, at 8:40 AM, Simon Nash wrote: Jim, See my comments inline. Simon It seems that if you go down this route you will wind up re- inventing Maven. Maven seems simple enough to me. I had not intended to reinvent maven. Not yet, but you will (see below) ;-) I was thinking more in terms of something that enables ant scripts to find dependencies in maven repos and package these in the embedded repo within the war file. I'm looking at various options for how best to do this in a way that is most convenient from the perspective of ant users. In order for this to work, you are going to need to handle transitive dependencies in all but the simplest use case. Namely an application that cannot receive or make remote invocations. I don't see any way around this. For example, all of the web services binding extensions and container extensions have dependencies. Bundling the two jar files mentioned previously will only allow someone to create a web application that invokes a local service from a servlet or JSP. No services exposed over remote bindings. No references with remote bindings. That type of application doesn't strike me as very compelling for Tuscany. In fact, I would tell people not to use Tuscany for this and to use something more appropriate such as PicoContainer. If someone was doing this to understand how to write Java services, I would tell them to use the standalone client since deploying to a web container for this sort of thing is superfluous. What benefit would they gain except the rigamarole of having to create a war (or an exploded directory) and wait for a server whose capabilities they are not using to restart for every change they make? Running the kernel inside an IDE takes milliseconds and does not require a deployment. I agree that Tuscany webapps will normally receive or make remote invocations, and these will require Tuscany extensions and their dependencies. These extensions and dependencies can be bundled physically within the war file, or the dependencies can be downloaded at runtime from an external maven repo. Currently the extensions can't be downloaded at runtime, but this is something that we could (and IMO should) support in the future. The 2 webapp jars are in a different category. They always need to be physically packaged inside the webapp and can never be downloaded at runtime. This is why they are in a different category than extensions and dependencies, and should be considered for different treatment as far as packaging is concerned. The helloworldws sample (one of those for which I provided an ant build script) is an example of the use case I have in mind. It receives remote invocations over Web services using the Axis2 binding and the SDO data binding. These Tuscany extensions are packaged inside the war file, but not their dependencies (either local or transitive). The Tuscany runtime loads these dependencies from an external maven repo. To build the helloworldws war file in this form, my ant script takes the Tuscany runtime from the atandalone/binary distro, and the Axis2 binding and SDO data binding Tuscany extensions from the contrib directory of the distro. The only things it currently cannot obtain from the locally installed distro are the 2 webapp jars. Forcing a remote download for these two jars, when everything else can be found locally, makes this common use case considerably more complex for a first-time or inexperienced user. In summary, the ant support for building war files must cover the following cases: 1. build war files with all required Tuscany extensions and their dependencies packaged within the war file 2. build war files with all required Tuscany extensions packaged within the war file, and their dependencies downloaded at runtime Packaging the 2 webapp jars within the downloadable distro simplifies the logistics of case 2 for webapps using extensions that we deliver as part of the distro, which is a common scenario. What I would recommend doing to help Ant users is to create a utility that can be invoked from an Ant Task, programmatically, or from the command line which downloads transitive dependencies from a Maven repository. As an implementation strategy, the first place I would look at is just wrapping Maven (or Wagon, the part that actually does the downloading). I would also keep in mind that reusing Maven will avoid the trouble of having to write code that parses and understands Maven POMs. I would also look to see what can be shared with the Maven War plugin we currently have to avoid duplicated effort and code. Yes, I was planning to do something very much along these lines. There is a further issue that statically cramming things into the distribution is not going to solve. Namely, moving forward, these jars are not going to be the only things required to run
Re: Adding 2 webapp jars to binary distro
Jim Marino wrote: On Nov 8, 2006, at 8:38 AM, Simon Nash wrote: Raymond Feng wrote: 1) It seems that you're looking for a collection of tuscany runtime/extension jars which provides you the artifacts to build the web application offline using ant or manually. I don't think it's appropriate to add them to the standalone distro though because it serves as the runtime for standalone applications instead of a traditional binary distro. I'm not sure why you are making a strong distinction between these two uses. A traditional binary distro will have a bin directory containing a command to launch its runtime and possibly other commands as well. Supporting dependencies that are needed to provide core functionality are in a lib directory. For example, the binary distros for tomcat and ant follow this pattern. So if we were releasing a binary runtime distro for core Tuscany functionality (i.e., functionality that is not part of some extension), I think its contents would be quite similar to what we have today in the standalone distro. There is nothing core about the web app launcher. Many deployments of Tuscany will not be to Servlet containers. My use of that core word was a bit unfortunate :-) What I meant was that these files will be widely used and are not part of a Tuscany extension. Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Adding 2 webapp jars to binary distro
I agree that Tuscany webapps will normally receive or make remote invocations, and these will require Tuscany extensions and their dependencies. These extensions and dependencies can be bundled physically within the war file, or the dependencies can be downloaded at runtime from an external maven repo. Currently the extensions can't be downloaded at runtime, but this is something that we could (and IMO should) support in the future. The 2 webapp jars are in a different category. They always need to be physically packaged inside the webapp and can never be downloaded at runtime. There are ways around this but there is a broader issue that I mentioned previously, namely these are not the only things that need to be provisioned for Ant users who want to have things statically packaged in the war. . This is why they are in a different category than extensions and dependencies, and should be considered for different treatment as far as packaging is concerned. The helloworldws sample (one of those for which I provided an ant build script) is an example of the use case I have in mind. It receives remote invocations over Web services using the Axis2 binding and the SDO data binding. These Tuscany extensions are packaged inside the war file, but not their dependencies (either local or transitive). The Tuscany runtime loads these dependencies from an external maven repo. So now for Ant users we require them to use the runtime resolution mechanism? We've basically punted the problem to the runtime. For me, we need to address the problem of transitive dependencies when building the archive. As an Ant user, the latter strike me as more inline with that build mechanism. To build the helloworldws war file in this form, my ant script takes the Tuscany runtime from the atandalone/binary distro, and the Axis2 binding and SDO data binding Tuscany extensions from the contrib directory of the distro. The only things it currently cannot obtain from the locally installed distro are the 2 webapp jars. Forcing a remote download for these two jars, when everything else can be found locally, makes this common use case considerably more complex for a first-time or inexperienced user. The problem is if we require everything locally, as you are suggesting, we are going to wind up with a kitchen sink distro. Again, I would suggest we provide an Ant task that can provisioning any required dependency from a remote repo and assemble a runtime for any host from the core distribution. Bootstrappers would be provisioned when the war was created. Note that this does not include placing boostrap code related to running in a web app into core, which is inappropriate. It also makes the two use cases you mentioned below dead-simple as well as reduces the complexity of the Ant script that would be required to build the archive. In summary, the ant support for building war files must cover the following cases: 1. build war files with all required Tuscany extensions and their dependencies packaged within the war file 2. build war files with all required Tuscany extensions packaged within the war file, and their dependencies downloaded at runtime Packaging the 2 webapp jars within the downloadable distro simplifies the logistics of case 2 for webapps using extensions that we deliver as part of the distro, which is a common scenario. What I would recommend doing to help Ant users is to create a utility that can be invoked from an Ant Task, programmatically, or from the command line which downloads transitive dependencies from a Maven repository. As an implementation strategy, the first place I would look at is just wrapping Maven (or Wagon, the part that actually does the downloading). I would also keep in mind that reusing Maven will avoid the trouble of having to write code that parses and understands Maven POMs. I would also look to see what can be shared with the Maven War plugin we currently have to avoid duplicated effort and code. Yes, I was planning to do something very much along these lines. Great I'd like to make clear that I understand the value of modularity and I strongly support it. We need to have modularity in terms of both architecture and implementation. But when choosing how we package our distros, we need to give some consideration to convenience for our users, especially those who are accustomed to a conventional dwonloadable binary distribution. I'm not arguing for the kitchen sink, but for careful consideration of user scenarios and how our distribution can support common cases in a convenient manner. I agree we need to carefully consider the end-user. However, we are not shipping conventional binary distributions typically done in many commercial software releases. I actually think an Ant script that automates the assembly of the runtime modules as I mentioned is actually easier and less complex for end users
Re: Adding 2 webapp jars to binary distro
Raymond, Thanks for these comments. My responses are inline. Simon Raymond Feng wrote: Hi, Simon. A few comments: 1) It seems that you're looking for a collection of tuscany runtime/extension jars which provides you the artifacts to build the web application offline using ant or manually. I don't think it's appropriate to add them to the standalone distro though because it serves as the runtime for standalone applications instead of a traditional binary distro. I'm not sure why you are making a strong distinction between these two uses. A traditional binary distro will have a bin directory containing a command to launch its runtime and possibly other commands as well. Supporting dependencies that are needed to provide core functionality are in a lib directory. For example, the binary distros for tomcat and ant follow this pattern. So if we were releasing a binary runtime distro for core Tuscany functionality (i.e., functionality that is not part of some extension), I think its contents would be quite similar to what we have today in the standalone distro. Also, what we have today seems to be something of a hybrid between a standalone distro and a binary distro. The extensions in the contrib directory are not needed by the standalone launcher, but are packaged in the same bundle (binary distro) for user convenience. By suggesting adding the 2 webapp jars, I was trying to take this approach of user convenience just a tiny bit further. 2) There may be another scenario that a distro is desired for web applications. In that case, the tuscany runtime/extension jars will be shared by the Tomcat server level (I remember we did a similar thing before by leveraging common/lib and server/lib?). This configuration is not supported today. I'm not sure it should be considered. I had not intended to support this scenario. If we decide we want to revive support for it, then we would have some work to do on both the runtime and build time aspects. 3) I also feel a bit scary by looking at the ant script which packages the WAR file. A prebuilt ant script can help one sample application, but won't the end-users be scared as well imaging they have to write such a script to deal with other web applications? Can we defer it to M3 so that we can have a better picture instead of rushing to M2 which is very close to the release? My hope in providing some sample scripts would be to show people what is needed in order to build and run Tuscany applications, at a more explicit level than just run maven. In effect this would serve as documentation for how they could do this themselves, using whatever tool they find most comfortable. I agree that the current webapp script comes across as quite scary, which is why I asked for suggestions to improve it. 4) As for the ant script itself, I suggest that you use the nested elements (such as lib, classes, webinf and metinfo) for war task instaed of a bunch of copy tasks as documented @ http://ant.apache.org/manual/CoreTasks/war.html. Thanks for this very helpful feedback. I will work on this today and post an updated version of the script later. I hope this will go some way to addressing your previous comment. Thanks, Raymond - Original Message - From: Simon Nash [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Tuesday, November 07, 2006 2:28 PM Subject: Re: Adding 2 webapp jars to binary distro Rick wrote: Jeremy Boynes wrote: I think this highlights one of the challenges with Ant-based build environments. Although Ant provides the mechanisms for executing the build scripts it does not provide a method for locating the dependencies needed at build-time - for example, to compile or repackage; often they are simply checked in alongside the user's source. This was one of the key issues that the Maven project originally set out to solve and which led to the establishment of the repo systems. I have not had a chance to see how your scripts address locating these dependencies. I realize that some, like SDO, are (undesirably) located in the standalone distro; others like spring, jaxb, json, js are not (or at least I hope they are not). It would help (in my currently disconnected state) if you could describe how your environment handles these. We will be making all the dependencies (including these) available through the maven repository system. As I explained in an earlier mail, the release vote would include not just the binary and other archives but also /all/ of the artifacts we release through the repo; this addresses Ant's concern about IPMC approval. At a fundamental level, I would question whether using the standalone runtime distribution as the basis of a build environment is the way to be going. Would we be better served producing a library Wouldn't if we added javadoc, SDOgen, Java2WSDL, WSDL2Java, War Plugin commandline to this be essentially a Tuscany SDK? Yes, it would, and for M3 it would be good
Re: Adding 2 webapp jars to binary distro
Jim, See my comments inline. Simon Jim Marino wrote: On Nov 7, 2006, at 10:43 AM, Simon Nash wrote: Jeremy, Thanks for the quick response. I am trying to be pragmatic here and deal with simple use cases. I haven't yet worked out the best way to deal with external or transitive dependencies from an ant build environment (though I do have some thoughts), but having a complete story for this is not needed to build a simple webapp. It seems that if you go down this route you will wind up re-inventing Maven. Maven seems simple enough to me. I had not intended to reinvent maven. I was thinking more in terms of something that enables ant scripts to find dependencies in maven repos and package these in the embedded repo within the war file. I'm looking at various options for how best to do this in a way that is most convenient from the perspective of ant users. Adding these 2 jars would be a simple change that would make the first use encounter with Tuscany quite a bit easier for ant users. Both Jeremy and Raymond pointed out the issue about working from a standalone distribution. Please see my comment to Raymond on this. I'd like to explore why it wouldn't be appropriate to have a binary distro that could be used for both purposes. There is a further issue that statically cramming things into the distribution is not going to solve. Namely, moving forward, these jars are not going to be the only things required to run in a web app in many of the common usage scenarios. For example, there will also be pure-Tuscany things like a JNDI-based implementation of ResourceHost to support the @Resource tag and service discovery. In addition, people may want to use other optional extensions such as Celtix instead of Axis or JAXB instead of SDO. The best way to solve this other than using Maven (and potentially embedding it as part of the distribution) is to use the artifact repository at runtime or, as you mentioned, a custom Ant task that replicated its functionality at deployment time (it could even embed Maven :-) ). The Ant task would download the jars and place them in the Ant project folder as determined by the user. I am not debating the extensions issue. We need a robust and convenient way for ant users (and users of other build tools) to obtain optional Tuscany extensions that aren't included in the tuscany-sca binary distro. I'm only focusing on the small set of binary artifacts that are basic components of Tuscany and aren't packaged as Tuscany extensions. I don't really see any distinction between these artifacts and the contrib Tuscany extensions that we are including in the M2 distro. In both cases, these could be downloaded separately, but bundling them into a downloadable distribution is a valuable convenience to users. What would be a less than ideal solution is to adopt the kitchen sink approach. Even if today it is two jars, this will quickly break down as the complexity of the runtime configuration increases. Putting this in as a temporary stopgap also does not seem like a good move given the issues it presents moving forward and the fact that we would have to remove it in the next release. Agreed that we don't want to do something now that we would reverse later. I don't see why this would be necessary. Even if we had a very sophisticated remote loading approach, there would still be a few basic things that it would make sense to find locally. Perhaps a custom Ant task which replicates the functionality in Maven is something you could look into? If you embedded Maven, I don't think it would be that much work. I'm certainly going to look into this and I think it's the right way to locate and load optional external dependencies. One of the approaches I am investigating is embedding maven. But I would draw a distinction between solving the general problem of artifact discovery and downloading, and how we provide basic elements of the Tuscany runtime. Jim - 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: Adding 2 webapp jars to binary distro
On Nov 8, 2006, at 8:40 AM, Simon Nash wrote: Jim, See my comments inline. Simon It seems that if you go down this route you will wind up re- inventing Maven. Maven seems simple enough to me. I had not intended to reinvent maven. Not yet, but you will (see below) ;-) I was thinking more in terms of something that enables ant scripts to find dependencies in maven repos and package these in the embedded repo within the war file. I'm looking at various options for how best to do this in a way that is most convenient from the perspective of ant users. In order for this to work, you are going to need to handle transitive dependencies in all but the simplest use case. Namely an application that cannot receive or make remote invocations. I don't see any way around this. For example, all of the web services binding extensions and container extensions have dependencies. Bundling the two jar files mentioned previously will only allow someone to create a web application that invokes a local service from a servlet or JSP. No services exposed over remote bindings. No references with remote bindings. That type of application doesn't strike me as very compelling for Tuscany. In fact, I would tell people not to use Tuscany for this and to use something more appropriate such as PicoContainer. If someone was doing this to understand how to write Java services, I would tell them to use the standalone client since deploying to a web container for this sort of thing is superfluous. What benefit would they gain except the rigamarole of having to create a war (or an exploded directory) and wait for a server whose capabilities they are not using to restart for every change they make? Running the kernel inside an IDE takes milliseconds and does not require a deployment. What I would recommend doing to help Ant users is to create a utility that can be invoked from an Ant Task, programmatically, or from the command line which downloads transitive dependencies from a Maven repository. As an implementation strategy, the first place I would look at is just wrapping Maven (or Wagon, the part that actually does the downloading). I would also keep in mind that reusing Maven will avoid the trouble of having to write code that parses and understands Maven POMs. I would also look to see what can be shared with the Maven War plugin we currently have to avoid duplicated effort and code. There is a further issue that statically cramming things into the distribution is not going to solve. Namely, moving forward, these jars are not going to be the only things required to run in a web app in many of the common usage scenarios. For example, there will also be pure-Tuscany things like a JNDI-based implementation of ResourceHost to support the @Resource tag and service discovery. In addition, people may want to use other optional extensions such as Celtix instead of Axis or JAXB instead of SDO. The best way to solve this other than using Maven (and potentially embedding it as part of the distribution) is to use the artifact repository at runtime or, as you mentioned, a custom Ant task that replicated its functionality at deployment time (it could even embed Maven :-) ). The Ant task would download the jars and place them in the Ant project folder as determined by the user. I am not debating the extensions issue. We need a robust and convenient way for ant users (and users of other build tools) to obtain optional Tuscany extensions that aren't included in the tuscany-sca binary distro. I'm only focusing on the small set of binary artifacts that are basic components of Tuscany and aren't packaged as Tuscany extensions. I don't really see any distinction between these artifacts and the contrib Tuscany extensions that we are including in the M2 distro. In both cases, these could be downloaded separately, but bundling them into a downloadable distribution is a valuable convenience to users. What capabilities would this distribution have (please see my comments above)? I think not much. What would be a less than ideal solution is to adopt the kitchen sink approach. Even if today it is two jars, this will quickly break down as the complexity of the runtime configuration increases. Putting this in as a temporary stopgap also does not seem like a good move given the issues it presents moving forward and the fact that we would have to remove it in the next release. Agreed that we don't want to do something now that we would reverse later. I don't see why this would be necessary. Even if we had a very sophisticated remote loading approach, there would still be a few basic things that it would make sense to find locally. I just don't get this. If I have to remotely download extensions anyway, why would we complicate things by cramming web app-related libraries into a standalone distribution? Perhaps a custom
Re: Adding 2 webapp jars to binary distro
On Nov 8, 2006, at 8:38 AM, Simon Nash wrote: Raymond Feng wrote: 1) It seems that you're looking for a collection of tuscany runtime/extension jars which provides you the artifacts to build the web application offline using ant or manually. I don't think it's appropriate to add them to the standalone distro though because it serves as the runtime for standalone applications instead of a traditional binary distro. I'm not sure why you are making a strong distinction between these two uses. A traditional binary distro will have a bin directory containing a command to launch its runtime and possibly other commands as well. Supporting dependencies that are needed to provide core functionality are in a lib directory. For example, the binary distros for tomcat and ant follow this pattern. So if we were releasing a binary runtime distro for core Tuscany functionality (i.e., functionality that is not part of some extension), I think its contents would be quite similar to what we have today in the standalone distro. There is nothing core about the web app launcher. Many deployments of Tuscany will not be to Servlet containers. Jim - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Adding 2 webapp jars to binary distro
On 11/7/06, Simon Nash [EMAIL PROTECTED] wrote: webapp-1.0-incubator-M2-SNAPSHOT.jar webapp-host-1.0-incubator-M2-SNAPSHOT.jar are not present in the standalone launcher (the rest are). In order to avoid the need for ant users to download these jars from a maven repo, I'd like to propose adding them to the binary distro. For example, they could go in a new webapp directory. They are not large and they would not impact use of the binary distro as a standalone Tuscany launcher. I think the issue here is what is our binary distro in M2, is it just the standalone distro or something more? Some previous discussion have been sounding like the binary distro is just the standalone distro, i'm not convinced thats true or a good idea. The current name is ...-bin not ...-standalone and it already includes the servlet jar and things like SDO. If we don't include the two tuscany webapp jars in the bin distro we release then how do we get them released officially with an ipmc vote? Being pragmatic the easiest way to fix this particular problem probably is to just also include the two tuscany webapp jars as well. And if we're going down that route why not also add the javadoc and prebuilt samples as well so we have a really easy to use binary M2 release :) ...ant PS. Whats going to happen when trying to build bigbank with ant and the DAS jars are required?
Re: Adding 2 webapp jars to binary distro
On Nov 7, 2006, at 6:13 AM, ant elder wrote: On 11/7/06, Simon Nash [EMAIL PROTECTED] wrote: webapp-1.0-incubator-M2-SNAPSHOT.jar webapp-host-1.0-incubator-M2-SNAPSHOT.jar are not present in the standalone launcher (the rest are). In order to avoid the need for ant users to download these jars from a maven repo, I'd like to propose adding them to the binary distro. For example, they could go in a new webapp directory. They are not large and they would not impact use of the binary distro as a standalone Tuscany launcher. I think the issue here is what is our binary distro in M2, is it just the standalone distro or something more? Some previous discussion have been sounding like the binary distro is just the standalone distro, i'm not convinced thats true or a good idea. The current name is ...-bin not ...-standalone and it already includes the servlet jar and things like SDO. They contain SDO because of a hack and should not, specifically the jars need to be crammed on the system classpath because we have not yet implemented multi-parent classloading. Once this is in place, they can be removed. As for servlet jar, that is required by the Kernel for ServletHost. We could factor that out as well moving forward. If we don't include the two tuscany webapp jars in the bin distro we release then how do we get them released officially with an ipmc vote? Being pragmatic the easiest way to fix this particular problem probably is to just also include the two tuscany webapp jars as well. And if we're going down that route why not also add the javadoc and prebuilt samples as well so we have a really easy to use binary M2 release :) And then the problem we have is we wind up with the monolith we tried to avoid based on all of the modularity discussions. As you mentioned below, when we include BigBank, we drag in DAS. In the future, when we have additional samples such as a BigBank that uses JPA, we will need to included those as well. Multiply that with JAXB, other web services stacks, JMS, etc. The kitchen sink approach ultimately is not going to work with the type of extensible runtime that we have. Instead of creating a monolith, this can be solved (better IMO) by having the runtime dynamically provision extensions based on the Maven Artifact repository service that Meeraj and Jeremy worked on. Jeremy had very strong opinions on how this should be done; as our release manager for M2, before making any significant changes to the branch we should clear it with him. He mentioned he will be back online Thursday. Jim ...ant PS. Whats going to happen when trying to build bigbank with ant and the DAS jars are required? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Adding 2 webapp jars to binary distro
I understand why the jars are there Jim, actually the servlet one is due to the current design of the axis binding not the kernel ServletHost, and I think we all understand that ultimately a kitchen sink distro isn't going to work, but thats _ultimately_, right now today in M2 we don't have JAXB and JPA and JMS and all the other things you mention, and we also don't have the things to help that you mention completed yet such as the maven artifact repository stuff or multi-parent classloader support. Given that, for this M2 release it may be easiest to just include the webapp jars as we have already done with the other ones. What is an alternative solution that you're suggesting? ...ant On 11/7/06, Jim Marino [EMAIL PROTECTED] wrote: On Nov 7, 2006, at 6:13 AM, ant elder wrote: On 11/7/06, Simon Nash [EMAIL PROTECTED] wrote: webapp-1.0-incubator-M2-SNAPSHOT.jar webapp-host-1.0-incubator-M2-SNAPSHOT.jar are not present in the standalone launcher (the rest are). In order to avoid the need for ant users to download these jars from a maven repo, I'd like to propose adding them to the binary distro. For example, they could go in a new webapp directory. They are not large and they would not impact use of the binary distro as a standalone Tuscany launcher. I think the issue here is what is our binary distro in M2, is it just the standalone distro or something more? Some previous discussion have been sounding like the binary distro is just the standalone distro, i'm not convinced thats true or a good idea. The current name is ...-bin not ...-standalone and it already includes the servlet jar and things like SDO. They contain SDO because of a hack and should not, specifically the jars need to be crammed on the system classpath because we have not yet implemented multi-parent classloading. Once this is in place, they can be removed. As for servlet jar, that is required by the Kernel for ServletHost. We could factor that out as well moving forward. If we don't include the two tuscany webapp jars in the bin distro we release then how do we get them released officially with an ipmc vote? Being pragmatic the easiest way to fix this particular problem probably is to just also include the two tuscany webapp jars as well. And if we're going down that route why not also add the javadoc and prebuilt samples as well so we have a really easy to use binary M2 release :) And then the problem we have is we wind up with the monolith we tried to avoid based on all of the modularity discussions. As you mentioned below, when we include BigBank, we drag in DAS. In the future, when we have additional samples such as a BigBank that uses JPA, we will need to included those as well. Multiply that with JAXB, other web services stacks, JMS, etc. The kitchen sink approach ultimately is not going to work with the type of extensible runtime that we have. Instead of creating a monolith, this can be solved (better IMO) by having the runtime dynamically provision extensions based on the Maven Artifact repository service that Meeraj and Jeremy worked on. Jeremy had very strong opinions on how this should be done; as our release manager for M2, before making any significant changes to the branch we should clear it with him. He mentioned he will be back online Thursday. Jim ...ant PS. Whats going to happen when trying to build bigbank with ant and the DAS jars are required? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Adding 2 webapp jars to binary distro
On Nov 7, 2006, at 8:03 AM, ant elder wrote: I understand why the jars are there Jim, actually the servlet one is due to the current design of the axis binding not the kernel ServletHost, ServletHost is also referenced by other extensions as it is assumed to be part of the host spi so it's not just Axis. and I think we all understand that ultimately a kitchen sink distro isn't going to work, but thats _ultimately_, right now today in M2 we don't have JAXB and JPA and JMS and all the other things you mention, and we also don't have the things to help that you mention completed yet such as the maven artifact repository stuff or multi-parent classloader support. That's not the point. One of the primary goals of this release was modularity. This breaks that. Given that, for this M2 release it may be easiest to just include the webapp jars as we have already done with the other ones. What is an alternative solution that you're suggesting? Use Maven or the artifact repository Meraaj and Jeremy worked on. Jim ...ant On 11/7/06, Jim Marino [EMAIL PROTECTED] wrote: On Nov 7, 2006, at 6:13 AM, ant elder wrote: On 11/7/06, Simon Nash [EMAIL PROTECTED] wrote: webapp-1.0-incubator-M2-SNAPSHOT.jar webapp-host-1.0-incubator-M2-SNAPSHOT.jar are not present in the standalone launcher (the rest are). In order to avoid the need for ant users to download these jars from a maven repo, I'd like to propose adding them to the binary distro. For example, they could go in a new webapp directory. They are not large and they would not impact use of the binary distro as a standalone Tuscany launcher. I think the issue here is what is our binary distro in M2, is it just the standalone distro or something more? Some previous discussion have been sounding like the binary distro is just the standalone distro, i'm not convinced thats true or a good idea. The current name is ...- bin not ...-standalone and it already includes the servlet jar and things like SDO. They contain SDO because of a hack and should not, specifically the jars need to be crammed on the system classpath because we have not yet implemented multi-parent classloading. Once this is in place, they can be removed. As for servlet jar, that is required by the Kernel for ServletHost. We could factor that out as well moving forward. If we don't include the two tuscany webapp jars in the bin distro we release then how do we get them released officially with an ipmc vote? Being pragmatic the easiest way to fix this particular problem probably is to just also include the two tuscany webapp jars as well. And if we're going down that route why not also add the javadoc and prebuilt samples as well so we have a really easy to use binary M2 release :) And then the problem we have is we wind up with the monolith we tried to avoid based on all of the modularity discussions. As you mentioned below, when we include BigBank, we drag in DAS. In the future, when we have additional samples such as a BigBank that uses JPA, we will need to included those as well. Multiply that with JAXB, other web services stacks, JMS, etc. The kitchen sink approach ultimately is not going to work with the type of extensible runtime that we have. Instead of creating a monolith, this can be solved (better IMO) by having the runtime dynamically provision extensions based on the Maven Artifact repository service that Meeraj and Jeremy worked on. Jeremy had very strong opinions on how this should be done; as our release manager for M2, before making any significant changes to the branch we should clear it with him. He mentioned he will be back online Thursday. Jim ...ant PS. Whats going to happen when trying to build bigbank with ant and the DAS jars are required? - 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: Adding 2 webapp jars to binary distro
I was not suggesting a kitchen sink approach, only the inclusion in the binary distro of 2 small extra runtime jar files that all our users who create webapps will need. I understand that our strategy for loading extension dependencies is to use the runtime support for accessing a remote or embedded Maven artifact repository that Meeraj and Jeremy worked on. I'm not proposing that we change this strategy. The challenge I'm facing in adding some support for building Tuscany applications with ant is not a runtime issue but a build-time one. For simple Tuscany webapps, I am very close to being able to build these webapps from the binary distro and a simple ant script using only built-in tasks. It is only the lack of these 2 webapp jar files in the binary distro that is preventing this, since without them in the binary distro, the ant script would need to download them from a remote maven repo. This requires the use of a custom Ant task as well as the need for live internet connectivity. This makes the ant build process and the user's getting started experience a lot more complex. By adding these 2 jars to the binary distro, we enable ant users to build simple Tuscany webapps without needing to deal with custom Ant tasks, dependency management, or remote maven repos. For more complex webapps with external dependencies that we are not delivering in our binary distro, we also need a way to build these using ant. When I have completed the simple case without dependencies, I will start work on this case. I have begun to investigate possible options, which will necessarily be more complex than the simple case where there are no dependencies. I'd like to give our users a simple experience for doing simple things, and reserve the more complex experience for doing more complex things. I hope this explains why it would be very helpful from a user perspective to have these 2 jars in the binary distro. This is a separate issue from adding the other things that Ant mentioned. Simon Jim Marino wrote: On Nov 7, 2006, at 6:13 AM, ant elder wrote: On 11/7/06, Simon Nash [EMAIL PROTECTED] wrote: webapp-1.0-incubator-M2-SNAPSHOT.jar webapp-host-1.0-incubator-M2-SNAPSHOT.jar are not present in the standalone launcher (the rest are). In order to avoid the need for ant users to download these jars from a maven repo, I'd like to propose adding them to the binary distro. For example, they could go in a new webapp directory. They are not large and they would not impact use of the binary distro as a standalone Tuscany launcher. I think the issue here is what is our binary distro in M2, is it just the standalone distro or something more? Some previous discussion have been sounding like the binary distro is just the standalone distro, i'm not convinced thats true or a good idea. The current name is ...-bin not ...-standalone and it already includes the servlet jar and things like SDO. They contain SDO because of a hack and should not, specifically the jars need to be crammed on the system classpath because we have not yet implemented multi-parent classloading. Once this is in place, they can be removed. As for servlet jar, that is required by the Kernel for ServletHost. We could factor that out as well moving forward. If we don't include the two tuscany webapp jars in the bin distro we release then how do we get them released officially with an ipmc vote? Being pragmatic the easiest way to fix this particular problem probably is to just also include the two tuscany webapp jars as well. And if we're going down that route why not also add the javadoc and prebuilt samples as well so we have a really easy to use binary M2 release :) And then the problem we have is we wind up with the monolith we tried to avoid based on all of the modularity discussions. As you mentioned below, when we include BigBank, we drag in DAS. In the future, when we have additional samples such as a BigBank that uses JPA, we will need to included those as well. Multiply that with JAXB, other web services stacks, JMS, etc. The kitchen sink approach ultimately is not going to work with the type of extensible runtime that we have. Instead of creating a monolith, this can be solved (better IMO) by having the runtime dynamically provision extensions based on the Maven Artifact repository service that Meeraj and Jeremy worked on. Jeremy had very strong opinions on how this should be done; as our release manager for M2, before making any significant changes to the branch we should clear it with him. He mentioned he will be back online Thursday. Jim ...ant PS. Whats going to happen when trying to build bigbank with ant and the DAS jars are required? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Simon C Nash IBM Distinguished Engineer
Re: Adding 2 webapp jars to binary distro
I think this highlights one of the challenges with Ant-based build environments. Although Ant provides the mechanisms for executing the build scripts it does not provide a method for locating the dependencies needed at build-time - for example, to compile or repackage; often they are simply checked in alongside the user's source. This was one of the key issues that the Maven project originally set out to solve and which led to the establishment of the repo systems. I have not had a chance to see how your scripts address locating these dependencies. I realize that some, like SDO, are (undesirably) located in the standalone distro; others like spring, jaxb, json, js are not (or at least I hope they are not). It would help (in my currently disconnected state) if you could describe how your environment handles these. We will be making all the dependencies (including these) available through the maven repository system. As I explained in an earlier mail, the release vote would include not just the binary and other archives but also /all/ of the artifacts we release through the repo; this addresses Ant's concern about IPMC approval. At a fundamental level, I would question whether using the standalone runtime distribution as the basis of a build environment is the way to be going. Would we be better served producing a library distribution, and if so, should it include /alll/ the transitive dependencies or not? Perhaps we should take this further and produce distributions pre-packaged for consumption in IDE environments (an IDEA or Eclipse distribution for example)? After all, if I'm building a WAR file, why would I need the standalone distro at all? Or perhaps using Ant is actually more complex perhaps we should just ship Maven builds. -- Jeremy On 11/7/06, Simon Nash [EMAIL PROTECTED] wrote: I was not suggesting a kitchen sink approach, only the inclusion in the binary distro of 2 small extra runtime jar files that all our users who create webapps will need. I understand that our strategy for loading extension dependencies is to use the runtime support for accessing a remote or embedded Maven artifact repository that Meeraj and Jeremy worked on. I'm not proposing that we change this strategy. The challenge I'm facing in adding some support for building Tuscany applications with ant is not a runtime issue but a build-time one. For simple Tuscany webapps, I am very close to being able to build these webapps from the binary distro and a simple ant script using only built-in tasks. It is only the lack of these 2 webapp jar files in the binary distro that is preventing this, since without them in the binary distro, the ant script would need to download them from a remote maven repo. This requires the use of a custom Ant task as well as the need for live internet connectivity. This makes the ant build process and the user's getting started experience a lot more complex. By adding these 2 jars to the binary distro, we enable ant users to build simple Tuscany webapps without needing to deal with custom Ant tasks, dependency management, or remote maven repos. For more complex webapps with external dependencies that we are not delivering in our binary distro, we also need a way to build these using ant. When I have completed the simple case without dependencies, I will start work on this case. I have begun to investigate possible options, which will necessarily be more complex than the simple case where there are no dependencies. I'd like to give our users a simple experience for doing simple things, and reserve the more complex experience for doing more complex things. I hope this explains why it would be very helpful from a user perspective to have these 2 jars in the binary distro. This is a separate issue from adding the other things that Ant mentioned. Simon Jim Marino wrote: On Nov 7, 2006, at 6:13 AM, ant elder wrote: On 11/7/06, Simon Nash [EMAIL PROTECTED] wrote: webapp-1.0-incubator-M2-SNAPSHOT.jar webapp-host-1.0-incubator-M2-SNAPSHOT.jar are not present in the standalone launcher (the rest are). In order to avoid the need for ant users to download these jars from a maven repo, I'd like to propose adding them to the binary distro. For example, they could go in a new webapp directory. They are not large and they would not impact use of the binary distro as a standalone Tuscany launcher. I think the issue here is what is our binary distro in M2, is it just the standalone distro or something more? Some previous discussion have been sounding like the binary distro is just the standalone distro, i'm not convinced thats true or a good idea. The current name is ...-bin not ...-standalone and it already includes the servlet jar and things like SDO. They contain SDO because of a hack and should not, specifically the jars need to be crammed on the system classpath because we have not yet implemented multi-parent classloading. Once this is in place, they
Re: Adding 2 webapp jars to binary distro
Jeremy Boynes wrote: I think this highlights one of the challenges with Ant-based build environments. Although Ant provides the mechanisms for executing the build scripts it does not provide a method for locating the dependencies needed at build-time - for example, to compile or repackage; often they are simply checked in alongside the user's source. This was one of the key issues that the Maven project originally set out to solve and which led to the establishment of the repo systems. I have not had a chance to see how your scripts address locating these dependencies. I realize that some, like SDO, are (undesirably) located in the standalone distro; others like spring, jaxb, json, js are not (or at least I hope they are not). It would help (in my currently disconnected state) if you could describe how your environment handles these. We will be making all the dependencies (including these) available through the maven repository system. As I explained in an earlier mail, the release vote would include not just the binary and other archives but also /all/ of the artifacts we release through the repo; this addresses Ant's concern about IPMC approval. At a fundamental level, I would question whether using the standalone runtime distribution as the basis of a build environment is the way to be going. Would we be better served producing a library Wouldn't if we added javadoc, SDOgen, Java2WSDL, WSDL2Java, War Plugin commandline to this be essentially a Tuscany SDK? distribution, and if so, should it include /alll/ the transitive dependencies or not? Perhaps we should take this further and produce distributions pre-packaged for consumption in IDE environments (an IDEA or Eclipse distribution for example)? After all, if I'm building a WAR file, why would I need the standalone distro at all? Or perhaps using Ant is actually more complex perhaps we should just ship Maven builds. -- Jeremy On 11/7/06, Simon Nash [EMAIL PROTECTED] wrote: I was not suggesting a kitchen sink approach, only the inclusion in the binary distro of 2 small extra runtime jar files that all our users who create webapps will need. I understand that our strategy for loading extension dependencies is to use the runtime support for accessing a remote or embedded Maven artifact repository that Meeraj and Jeremy worked on. I'm not proposing that we change this strategy. The challenge I'm facing in adding some support for building Tuscany applications with ant is not a runtime issue but a build-time one. For simple Tuscany webapps, I am very close to being able to build these webapps from the binary distro and a simple ant script using only built-in tasks. It is only the lack of these 2 webapp jar files in the binary distro that is preventing this, since without them in the binary distro, the ant script would need to download them from a remote maven repo. This requires the use of a custom Ant task as well as the need for live internet connectivity. This makes the ant build process and the user's getting started experience a lot more complex. By adding these 2 jars to the binary distro, we enable ant users to build simple Tuscany webapps without needing to deal with custom Ant tasks, dependency management, or remote maven repos. For more complex webapps with external dependencies that we are not delivering in our binary distro, we also need a way to build these using ant. When I have completed the simple case without dependencies, I will start work on this case. I have begun to investigate possible options, which will necessarily be more complex than the simple case where there are no dependencies. I'd like to give our users a simple experience for doing simple things, and reserve the more complex experience for doing more complex things. I hope this explains why it would be very helpful from a user perspective to have these 2 jars in the binary distro. This is a separate issue from adding the other things that Ant mentioned. Simon Jim Marino wrote: On Nov 7, 2006, at 6:13 AM, ant elder wrote: On 11/7/06, Simon Nash [EMAIL PROTECTED] wrote: webapp-1.0-incubator-M2-SNAPSHOT.jar webapp-host-1.0-incubator-M2-SNAPSHOT.jar are not present in the standalone launcher (the rest are). In order to avoid the need for ant users to download these jars from a maven repo, I'd like to propose adding them to the binary distro. For example, they could go in a new webapp directory. They are not large and they would not impact use of the binary distro as a standalone Tuscany launcher. I think the issue here is what is our binary distro in M2, is it just the standalone distro or something more? Some previous discussion have been sounding like the binary distro is just the standalone distro, i'm not convinced thats true or a good idea. The current name is ...-bin not ...-standalone and it already includes the servlet jar and things like SDO. They contain SDO because of a hack and should not,
Re: Adding 2 webapp jars to binary distro
Jeremy, Thanks for the quick response. I am trying to be pragmatic here and deal with simple use cases. I haven't yet worked out the best way to deal with external or transitive dependencies from an ant build environment (though I do have some thoughts), but having a complete story for this is not needed to build a simple webapp. Adding these 2 jars would be a simple change that would make the first use encounter with Tuscany quite a bit easier for ant users. I am not proposing a library with extension dependencies like the ones you mentioned (either direct or transitive). I think there are a lot of issues with this, mainly because these dependencies are not part of Tuscany but are part of other projects. The 2 webapp jars are part of Tuscany and would be included in the Tuscany binary distro as a convenience to Tuscany users. IDE-specific packages are something we might get to in the future. I am not trying to be anything like that ambitious at the moment. Yes, we could insist that all Tuscany application developers build with maven. I don't think that would be a wise approach if we want to build a broad-based community. At least there should be some level of support for other build environments, or enough indication of what is going on under the maven covers that people can create other build setups themselves if they want to. Simple ant scripts can serve as this kind of documentation. You're right that a war doesn't need the standalone distribution to be present in order to run. Having a way to use our binary distribution in library mode, at least for the Tuscany artifacts that it contains, seems attractive to me if the cost is only adding 2 small jars. I'm quite a newbie with ant so I don't think my war building script in its current form provides the slickest possible approach. I'd be happy to make it available so that people can look at it and perhaps suggest improvements. It currently takes quite a literal approach to recreating the exact same directory and file structure as the maven build produces. I'll create a JIRA and attach the 2 scripts I have created so far (standalone and war). Simon Jeremy Boynes wrote: I think this highlights one of the challenges with Ant-based build environments. Although Ant provides the mechanisms for executing the build scripts it does not provide a method for locating the dependencies needed at build-time - for example, to compile or repackage; often they are simply checked in alongside the user's source. This was one of the key issues that the Maven project originally set out to solve and which led to the establishment of the repo systems. I have not had a chance to see how your scripts address locating these dependencies. I realize that some, like SDO, are (undesirably) located in the standalone distro; others like spring, jaxb, json, js are not (or at least I hope they are not). It would help (in my currently disconnected state) if you could describe how your environment handles these. We will be making all the dependencies (including these) available through the maven repository system. As I explained in an earlier mail, the release vote would include not just the binary and other archives but also /all/ of the artifacts we release through the repo; this addresses Ant's concern about IPMC approval. At a fundamental level, I would question whether using the standalone runtime distribution as the basis of a build environment is the way to be going. Would we be better served producing a library distribution, and if so, should it include /alll/ the transitive dependencies or not? Perhaps we should take this further and produce distributions pre-packaged for consumption in IDE environments (an IDEA or Eclipse distribution for example)? After all, if I'm building a WAR file, why would I need the standalone distro at all? Or perhaps using Ant is actually more complex perhaps we should just ship Maven builds. -- Jeremy On 11/7/06, Simon Nash [EMAIL PROTECTED] wrote: I was not suggesting a kitchen sink approach, only the inclusion in the binary distro of 2 small extra runtime jar files that all our users who create webapps will need. I understand that our strategy for loading extension dependencies is to use the runtime support for accessing a remote or embedded Maven artifact repository that Meeraj and Jeremy worked on. I'm not proposing that we change this strategy. The challenge I'm facing in adding some support for building Tuscany applications with ant is not a runtime issue but a build-time one. For simple Tuscany webapps, I am very close to being able to build these webapps from the binary distro and a simple ant script using only built-in tasks. It is only the lack of these 2 webapp jar files in the binary distro that is preventing this, since without them in the binary distro, the ant script would need to download them from a remote maven repo. This requires the use of a custom Ant task as well as the need for live internet
Re: Adding 2 webapp jars to binary distro
Rick wrote: Jeremy Boynes wrote: I think this highlights one of the challenges with Ant-based build environments. Although Ant provides the mechanisms for executing the build scripts it does not provide a method for locating the dependencies needed at build-time - for example, to compile or repackage; often they are simply checked in alongside the user's source. This was one of the key issues that the Maven project originally set out to solve and which led to the establishment of the repo systems. I have not had a chance to see how your scripts address locating these dependencies. I realize that some, like SDO, are (undesirably) located in the standalone distro; others like spring, jaxb, json, js are not (or at least I hope they are not). It would help (in my currently disconnected state) if you could describe how your environment handles these. We will be making all the dependencies (including these) available through the maven repository system. As I explained in an earlier mail, the release vote would include not just the binary and other archives but also /all/ of the artifacts we release through the repo; this addresses Ant's concern about IPMC approval. At a fundamental level, I would question whether using the standalone runtime distribution as the basis of a build environment is the way to be going. Would we be better served producing a library Wouldn't if we added javadoc, SDOgen, Java2WSDL, WSDL2Java, War Plugin commandline to this be essentially a Tuscany SDK? Yes, it would, and for M3 it would be good to talk about whether this is a useful thing to provide. At the moment I am focused on the minimum needed to solve the specific problem of building simple webapps using ant scripts that don't require custom tasks. I have attached the 2 ant scripts that I have completed so far to TUSCANY-906. I'd appreciate suggestions for improvement, especially to the webapp one. In their current state, they can't handle extension dependencies. I'm going to look into creating a custom ant task that will support this in a similar manner to the Tuscany maven war plugin. Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
