Re: Distribution zips and what they contain, was: SCA runtimes
On Tue, Jun 10, 2008 at 10:59 PM, Mike Edwards < [EMAIL PROTECTED]> wrote: > Good debate here, but let's be clear about the big picture before the > details swamp the debate. > Big +1 to that, i really hope we can some consensus on what the distributions and runtimes should look like before we decide what registries etc we need to use to implement them. ...ant
Re: Distribution zips and what they contain, was: SCA runtimes
Mike Edwards wrote: ... Are people interested in exploring these ideas? Jean-Sebastien, I'll start with the last question first: YES. But I'd next like to step back from what I can see is developing into a somewhat "active" debate (to use a neutral euphemism) :) and investigate the big picture here. Let me try to understand the motivations (yes, plural, I think) for multiple binary distro zips of Tuscany. My initial reaction to seeing a list like the one above is "hmm - complexity - for the end user" - they now have to understand which of those packages they need and install each of them separately. The more packages, the more complexity. Now, this is only looking at one side of things - why is splitting things into packages like that a good idea? Well, I suppose there is the question of download size and size on disk. More packages = each package can be smaller. You get what you ask for. The other side is smaller runtime size - no unnecessary things get loaded. For the download size, I see the merits of bacon slicing into sets of independent packages. For the runtime size, other methods (eg lazy loading) might be an alternative. I can see the argument to use an install system like Eclipse, but on the other hand, as a user of Eclipse, I have to say that this aspect is one of the less satisfactory parts of Eclipse, and it can be frustratingly hard to know that you've got the right set of stuff installed. Part of this is about the number of packages and the set of valid combinations. If it's a small number then OK, perhaps not a problem. Once the number grows, I think it does become a problem for the end user. I'm aiming for a small number of packages, similar to the Eclipse distributions that people build (a Java developer distro, a Web developer distro, an Enterprise distro, a Mobile device distro etc) to not have to worry about the bits and pieces. We already had that discussion in January and IIRC I had also brought up the similarity with Eclipse distros then :) The question of the approach to OSGi is perhaps different. I think it does make sense to create a bundle-per-module. It does make sense to have clean interfaces for each module with crisp lists of imports and exports. (and yes, I know that we are a long way from that today!) Yes, but I'm not sure we're a long way from that today, except for the few cases where people have gone around SPIs. OSGi imports/exports will help prevent that, as going around exported SPIs will break the build. But I don't expect that OSGi bundles should be directly reflected into the bigger scale packaging. In other words, the bigger scale packaging is aimed at satisfying the user's needs and a big package could have 10 or 100 module-sized bundles in it, as necessary. That depends on overall function, not on details of the modules used to provide that function. Exactly! - 1 bundle per module - n bundles per 'bigger packaging' distro Good debate here, but let's be clear about the big picture before the details swamp the debate. :) -- Jean-Sebastien
Re: Distribution zips and what they contain, was: SCA runtimes
Jean-Sebastien Delfino wrote: Jean-Sebastien Delfino wrote: I'd like to discuss the following: "What distro Zips are we building and what do they contain?" I think we could improve our distro scheme to provide: - smaller packages - easier for people to find what they need I was thinking about the following binary distro zips: - tuscany-core.zip - The base that everybody needs. core assembly model and runtime Java APIs, Java components - tuscany-web.zip - For WS and Web developers WS binding, Web 2.0 bindings, Scripting components, Widget components - tuscany-jee.zip - For JEE app integration EJB, RMI and JMS bindings, Spring components - tuscany-process.zip - For process development BPEL and XQuery components - tuscany-all.zip - all of the above Note that I'm not trying to tackle release cycles and the potential for releasing the above zips independently in this discussion and I'm assuming that we release all of the above together. I'm also assuming that the relevant samples are included in each zip. This email was from 1/22/08, generated a lot of discussion for about 3 weeks, lots of opinions, no conclusion, no commits :) I still think the same as what I had posted then, plus additional ideas: - Use OSGi exports/imports to export clean SPIs, hide internals, and refine the contents of the distros and their dependencies. Disclaimer - Please don't get me wrong I'm not saying that one distro == one OSGi bundle, as I've already said several times on the list that the big-OSGi-bundle approach didn't make sense to me :) I just think that declaring and enforcing clean dependencies using OSGi will help us refine the contents of each distro. - Instead of a tuscany-manifest JAR or tuscany-all JAR, use an extension registry mechanism (what we have now in Tuscany or better a combination of what we have now and the Eclipse Equinox registry for example) to detect which pieces are installed and activate their capabilities. Are people interested in exploring these ideas? Jean-Sebastien, I'll start with the last question first: YES. But I'd next like to step back from what I can see is developing into a somewhat "active" debate (to use a neutral euphemism) and investigate the big picture here. Let me try to understand the motivations (yes, plural, I think) for multiple binary distro zips of Tuscany. My initial reaction to seeing a list like the one above is "hmm - complexity - for the end user" - they now have to understand which of those packages they need and install each of them separately. The more packages, the more complexity. Now, this is only looking at one side of things - why is splitting things into packages like that a good idea? Well, I suppose there is the question of download size and size on disk. More packages = each package can be smaller. You get what you ask for. The other side is smaller runtime size - no unnecessary things get loaded. For the download size, I see the merits of bacon slicing into sets of independent packages. For the runtime size, other methods (eg lazy loading) might be an alternative. I can see the argument to use an install system like Eclipse, but on the other hand, as a user of Eclipse, I have to say that this aspect is one of the less satisfactory parts of Eclipse, and it can be frustratingly hard to know that you've got the right set of stuff installed. Part of this is about the number of packages and the set of valid combinations. If it's a small number then OK, perhaps not a problem. Once the number grows, I think it does become a problem for the end user. The question of the approach to OSGi is perhaps different. I think it does make sense to create a bundle-per-module. It does make sense to have clean interfaces for each module with crisp lists of imports and exports. (and yes, I know that we are a long way from that today!) But I don't expect that OSGi bundles should be directly reflected into the bigger scale packaging. In other words, the bigger scale packaging is aimed at satisfying the user's needs and a big package could have 10 or 100 module-sized bundles in it, as necessary. That depends on overall function, not on details of the modules used to provide that function. Good debate here, but let's be clear about the big picture before the details swamp the debate. Yours, Mike.
Re: Distribution zips and what they contain, was: SCA runtimes
ant elder wrote: On Tue, Jun 10, 2008 at 3:02 AM, Jean-Sebastien Delfino < [EMAIL PROTECTED]> wrote: Jean-Sebastien Delfino wrote: I'd like to discuss the following: "What distro Zips are we building and what do they contain?" I think we could improve our distro scheme to provide: - smaller packages - easier for people to find what they need I was thinking about the following binary distro zips: - tuscany-core.zip - The base that everybody needs. core assembly model and runtime Java APIs, Java components - tuscany-web.zip - For WS and Web developers WS binding, Web 2.0 bindings, Scripting components, Widget components - tuscany-jee.zip - For JEE app integration EJB, RMI and JMS bindings, Spring components - tuscany-process.zip - For process development BPEL and XQuery components - tuscany-all.zip - all of the above Note that I'm not trying to tackle release cycles and the potential for releasing the above zips independently in this discussion and I'm assuming that we release all of the above together. I'm also assuming that the relevant samples are included in each zip. This email was from 1/22/08, generated a lot of discussion for about 3 weeks, lots of opinions, no conclusion, no commits :) No commits as we haven't found much consensus yet. I still think the same as what I had posted then, plus additional ideas: - Use OSGi exports/imports to export clean SPIs, hide internals, and refine the contents of the distros and their dependencies. Disclaimer - Please don't get me wrong I'm not saying that one distro == one OSGi bundle, as I've already said several times on the list that the big-OSGi-bundle approach didn't make sense to me :) I just think that declaring and enforcing clean dependencies using OSGi will help us refine the contents of each distro. The term "enforcing" seems to suggest that there might be an OSGi dependency for the Tuscany runtime. I don't know if this was intended. I think the right approach is to have a Tuscany+OSGi runtime (as we are building in itest\osgi-tuscany) which would actually do enforcement, and a non-OSGi Tuscany runtime in which the exports/imports are present in the jars but not enforced. What would be the granularity of these OSGi bundles? If the bundles are the current maven modules, I think we will find a number of classes that need to be exported even though these classes are not considered part of the SPI or API that the module provides. To resolve this I see the following options: a) Export more than we really believe is correct. This leaves us in the current unsatisfactory position of exposing unwanted implementation internals. b) Combine multiple maven modules with a close implementation affinity into a single OSGi bundle, and only expose true APIs or SPIs from these bundles. c) Refactor the code to remove dependencies on internals of other modules, and create new SPIs or APIs when this isn't possible. I believe a combination of b) and c) is the best approach. - Instead of a tuscany-manifest JAR or tuscany-all JAR, use an extension registry mechanism (what we have now in Tuscany or better a combination of what we have now and the Eclipse Equinox registry for example) to detect which pieces are installed and activate their capabilities. Can you say a bit more about what an "extension registry mechanism" would look like? What the tuscany-all/manifest jar are trying to do is to have users not need to know about the internal makeup of Tuscany. So they can simply use tuscany-all and avoid needing to know about all the dozens of different Tuscany modules and their dependencies, and that should keep working over many Tuscany releases whereas as we keep adding/deleting/changing the modules we keep breaking user builds for each Tuscany release if they refer to the individual modules. Maybe the granularity isn't quite right yet and we need something in between the all jar and all the individual modules. Is there much agreement that avoiding users needing to know about the internal Tuscany modules is a Good Thing? Yes, I think this is important. Ideally the Tuscany core runtime would figure out which pieces are needed for the domain configuration and load these pieces automatically. Simon ...ant
Re: Distribution zips and what they contain, was: SCA runtimes
On Tue, Jun 10, 2008 at 3:02 AM, Jean-Sebastien Delfino < [EMAIL PROTECTED]> wrote: > Jean-Sebastien Delfino wrote: >> >> I'd like to discuss the following: "What distro Zips are we building and >> what do they contain?" >> >> I think we could improve our distro scheme to provide: >> - smaller packages >> - easier for people to find what they need >> >> I was thinking about the following binary distro zips: >> >> - tuscany-core.zip - The base that everybody needs. >> core assembly model and runtime >> Java APIs, Java components >> >> - tuscany-web.zip - For WS and Web developers >> WS binding, Web 2.0 bindings, Scripting components, Widget components >> >> - tuscany-jee.zip - For JEE app integration >> EJB, RMI and JMS bindings, Spring components >> >> - tuscany-process.zip - For process development >> BPEL and XQuery components >> >> - tuscany-all.zip - all of the above >> >> Note that I'm not trying to tackle release cycles and the potential for >> releasing the above zips independently in this discussion and I'm assuming >> that we release all of the above together. >> >> I'm also assuming that the relevant samples are included in each zip. >> > > This email was from 1/22/08, generated a lot of discussion for about 3 > weeks, lots of opinions, no conclusion, no commits :) > No commits as we haven't found much consensus yet. > I still think the same as what I had posted then, plus additional ideas: > > - Use OSGi exports/imports to export clean SPIs, hide internals, and refine > the contents of the distros and their dependencies. > > Disclaimer - Please don't get me wrong I'm not saying that one distro == one > OSGi bundle, as I've already said several times on the list that the > big-OSGi-bundle approach didn't make sense to me :) I just think that > declaring and enforcing clean dependencies using OSGi will help us refine > the contents of each distro. > > - Instead of a tuscany-manifest JAR or tuscany-all JAR, use an extension > registry mechanism (what we have now in Tuscany or better a combination of > what we have now and the Eclipse Equinox registry for example) to detect > which pieces are installed and activate their capabilities. > Can you say a bit more about what an "extension registry mechanism" would look like? What the tuscany-all/manifest jar are trying to do is to have users not need to know about the internal makeup of Tuscany. So they can simply use tuscany-all and avoid needing to know about all the dozens of different Tuscany modules and their dependencies, and that should keep working over many Tuscany releases whereas as we keep adding/deleting/changing the modules we keep breaking user builds for each Tuscany release if they refer to the individual modules. Maybe the granularity isn't quite right yet and we need something in between the all jar and all the individual modules. Is there much agreement that avoiding users needing to know about the internal Tuscany modules is a Good Thing? ...ant
Re: Distribution zips and what they contain, was: SCA runtimes
Jean-Sebastien Delfino wrote: I'd like to discuss the following: "What distro Zips are we building and what do they contain?" I think we could improve our distro scheme to provide: - smaller packages - easier for people to find what they need I was thinking about the following binary distro zips: - tuscany-core.zip - The base that everybody needs. core assembly model and runtime Java APIs, Java components - tuscany-web.zip - For WS and Web developers WS binding, Web 2.0 bindings, Scripting components, Widget components - tuscany-jee.zip - For JEE app integration EJB, RMI and JMS bindings, Spring components - tuscany-process.zip - For process development BPEL and XQuery components - tuscany-all.zip - all of the above Note that I'm not trying to tackle release cycles and the potential for releasing the above zips independently in this discussion and I'm assuming that we release all of the above together. I'm also assuming that the relevant samples are included in each zip. This email was from 1/22/08, generated a lot of discussion for about 3 weeks, lots of opinions, no conclusion, no commits :) I still think the same as what I had posted then, plus additional ideas: - Use OSGi exports/imports to export clean SPIs, hide internals, and refine the contents of the distros and their dependencies. Disclaimer - Please don't get me wrong I'm not saying that one distro == one OSGi bundle, as I've already said several times on the list that the big-OSGi-bundle approach didn't make sense to me :) I just think that declaring and enforcing clean dependencies using OSGi will help us refine the contents of each distro. - Instead of a tuscany-manifest JAR or tuscany-all JAR, use an extension registry mechanism (what we have now in Tuscany or better a combination of what we have now and the Eclipse Equinox registry for example) to detect which pieces are installed and activate their capabilities. Are people interested in exploring these ideas? -- Jean-Sebastien
Re: Distribution zips and what they contain, was: SCA runtimes
Sorry for the delay in responding. I have been out sick for a few days and I am just getting back to my Tuscany mail. Comments inline. Simon Jean-Sebastien Delfino wrote: Comments inline. Simon Nash wrote: Well, I think the smart installer approach will be a nightmare. We had a similar approach in M2 and people didn't like it. The M2 approach was very different from what I was proposing. M2 downloaded everything on demand at runtime. A smart installer would set things up ahead of time with the necessary features for the desired runtime configuration. This is much more manageable if there are any problems with the downloads. OK, you scared me :) If you're talking about analyzing the features required by a composite at deployment time, calculating the set of JARs providing these features, and making them available for installation, then you get my +1. The work I've started with the Maven Ant generator plugin is a step in that direction. If you hook it with a composite model analyzer and remove the Ant specifics you get what I just described, allowing you to tailor a minimal runtime for a particular SCA application. Yes, the tailored runtime could be based on the needs of a single composite or on a predefined user-selected list of features. You're right that the Eclipse feature install approach is a little like that. IMHO it has been a nightmare and probably one of the reasons why their download page [1] now shows targeted distros :) - for Java developers - for Java EE developers - for Plugin developers - for C++ developers - for Web developers (on a separate page). - and the classic IDE mix Very similar to the approach I was proposing... I'm just seeing Spring and Eclipse, two extensible and successful projects adopt similar approaches, and thought they'd be good examples to follow :) I think these are good examples to follow. Tuscany is rather similar in that it contains a base framework and many optional extensions, and there is probably no user who wants to use all the optional features. +1 But that's OK, if people don't like that split I can also live with a single big runtime distro. Over time, we will add more and more optional features and this will become more and more of a problem. IMO, it's bad enough now that we need to do something. I agree with you, but there is no consensus on this. I see several options: a) a vote to pick a common direction now b) have people develop their different visions to get user feedback c) continue with the current distro scheme Like I said I could live with (c). However, I would prefer (a) or (b). I could live with c) only if we start doing baby steps towards better modularity within a single distro as I proposed here. So I'd like to try to understand others' views on this baby step towards better modularity before I take a firm position on a), b) or c). I'd like to suggest a first baby step towards partitioning the contents of the distro. In this first step, there's still a single binary distro with all the dependencies. The difference is that the modules and lib directories are broken down into subdirectories along the lines that Sebastien and others have suggested. Based on earlier discussions, the subdirectories could be: core - The base that everybody needs core assembly model and runtime Java APIs, Java components, SCA binding, Web Service binding web - For Web developers Web 2.0 bindings, Scripting components, Widget components JEE - For JEE app integration EJB, RMI and JMS bindings, Spring components process - For process development BPEL and XQuery components Each of these could be built and tested separately. Dependencies between them would only use documented SPIs. There would no longer be a single catch-all tuscany-manifest jar or a single tuscany-all jar. If this first step is successful, we could think about what further steps we could take to improve modularity. I don't see what that baby step buys us. If we think that partitioning is the right approach, why not just simply do it cleanly and partition the distro? Please take a look at my other email on this thread responding to Ant. I think the main piece of work needed is to create a runtime that's truly modular, and this baby step is a first move towards that. Once we have that, almost any configuration or reconfiguration will be possible. Doing a zip repackaging without solving the modularity isssues might just move us from one inflexible packaging to a different packaging that's equally inflexible. For me, having the internal flexibility enabled is the first step that provides the key to many different scenarios under headings a) and b) above. Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Distribution zips and what they contain, was: SCA runtimes
Comments inline. Simon Nash wrote: Well, I think the smart installer approach will be a nightmare. We had a similar approach in M2 and people didn't like it. The M2 approach was very different from what I was proposing. M2 downloaded everything on demand at runtime. A smart installer would set things up ahead of time with the necessary features for the desired runtime configuration. This is much more manageable if there are any problems with the downloads. OK, you scared me :) If you're talking about analyzing the features required by a composite at deployment time, calculating the set of JARs providing these features, and making them available for installation, then you get my +1. The work I've started with the Maven Ant generator plugin is a step in that direction. If you hook it with a composite model analyzer and remove the Ant specifics you get what I just described, allowing you to tailor a minimal runtime for a particular SCA application. You're right that the Eclipse feature install approach is a little like that. IMHO it has been a nightmare and probably one of the reasons why their download page [1] now shows targeted distros :) - for Java developers - for Java EE developers - for Plugin developers - for C++ developers - for Web developers (on a separate page). - and the classic IDE mix Very similar to the approach I was proposing... I'm just seeing Spring and Eclipse, two extensible and successful projects adopt similar approaches, and thought they'd be good examples to follow :) I think these are good examples to follow. Tuscany is rather similar in that it contains a base framework and many optional extensions, and there is probably no user who wants to use all the optional features. +1 But that's OK, if people don't like that split I can also live with a single big runtime distro. Over time, we will add more and more optional features and this will become more and more of a problem. IMO, it's bad enough now that we need to do something. I agree with you, but there is no consensus on this. I see several options: a) a vote to pick a common direction now b) have people develop their different visions to get user feedback c) continue with the current distro scheme Like I said I could live with (c). However, I would prefer (a) or (b). I'd like to suggest a first baby step towards partitioning the contents of the distro. In this first step, there's still a single binary distro with all the dependencies. The difference is that the modules and lib directories are broken down into subdirectories along the lines that Sebastien and others have suggested. Based on earlier discussions, the subdirectories could be: core - The base that everybody needs core assembly model and runtime Java APIs, Java components, SCA binding, Web Service binding web - For Web developers Web 2.0 bindings, Scripting components, Widget components JEE - For JEE app integration EJB, RMI and JMS bindings, Spring components process - For process development BPEL and XQuery components Each of these could be built and tested separately. Dependencies between them would only use documented SPIs. There would no longer be a single catch-all tuscany-manifest jar or a single tuscany-all jar. If this first step is successful, we could think about what further steps we could take to improve modularity. I don't see what that baby step buys us. If we think that partitioning is the right approach, why not just simply do it cleanly and partition the distro? -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Distribution zips and what they contain, was: SCA runtimes
ant elder wrote: On Feb 10, 2008 10:06 PM, Simon Nash <[EMAIL PROTECTED]> wrote: But that's OK, if people don't like that split I can also live with a single big runtime distro. Over time, we will add more and more optional features and this will become more and more of a problem. IMO, it's bad enough now that we need to do something. We don't seem to be reaching much consensus on this and i wonder if its because we don't understand what each of our priorities are. There was an attempt to find that out over at http://apache.markmail.org/message/4wldk6zdjxaxz4kf but now here on this thread I'm a bit lost after the many weeks of discussion so could you say more about which aspect is "bad enough" now and maybe summarise the important aspects you'd like the distribution(s) to have? ...ant From a user perspective, if the user is doing personal development, I suppose most users these days can put up with a 60MB download and a 60MB runtime. Where this becomes an issue is for people building applications or services that depend on the Tuscany runtime and need to be deployed into various environments. Examples are packaging the Tuscany runtime packaged inside a webapp, placing it in a shared library on a JEE appserver, placing it on the classpath in a J2SE environment, and maybe others. In all these cases, it's desirable for the deployed runtime to contain only what's needed to run the deployed applications. This is particularly important for Tuscany's external library dependencies, partly because of the number and diversity of these (read: risk), and partly because the versions of these libraries that we ship could potentially conflict with other things within the runtime environment. I also have a number of concerns from the Tuscany architecture, design and implementation perspective. As a Tuscany developer, I think the present situation is bad for the following reasons. 1. We claim to have a "modular architecture" but all evidence suggests that this isn't the case. For Tuscany SCA Java, we have to build it as one unit, test it as one unit, package it as one unit, and deliver it as one unit. Where is the modularity? What are the modules? 2. We know that there are dependency issues with some parts of the current codebase, with various parts of the runtime dragging dependencies that they shouldn't (either other parts of Tuscany or external libraries). How much of the Tuscany runtime, and how many external libraries, are needed to run a simple "Hello World"? How many of these things are we comfortable with having as dependencies, and how many do we think are a problem that should be eliminated? The present structure provides no answers to these questions. 3. We know that some of the maven modules are directly using implementation code within other maven modules rather than going through SPIs, but we don't know exactly what these non-SPI couplings are. Our claim to have a stable and well-defined SPI is a little shaky until we get a handle on these exception cases and address them. 4. To make Tuscany successful, we need a modular architecture and implementation that addresses all the above issues. This is because Tuscany needs to run in many different environments with many different configurations. Without modularity, we won't be able to do this. This doesn't necessarily mean that we need to split the distribution right now, but I think it does mean that we need to work on improving modularity in the code, in at least some of the ways listed above. This would give us and our users some flexibility to build and deploy different combinations of capability to meet their needs. Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Distribution zips and what they contain, was: SCA runtimes
On Feb 10, 2008 10:06 PM, Simon Nash <[EMAIL PROTECTED]> wrote: > But that's OK, if people don't like that split I can also live with a > > single big runtime distro. > > > Over time, we will add more and more optional features and this will > become more and more of a problem. IMO, it's bad enough now that we > need to do something. > We don't seem to be reaching much consensus on this and i wonder if its because we don't understand what each of our priorities are. There was an attempt to find that out over at http://apache.markmail.org/message/4wldk6zdjxaxz4kf but now here on this thread I'm a bit lost after the many weeks of discussion so could you say more about which aspect is "bad enough" now and maybe summarise the important aspects you'd like the distribution(s) to have? ...ant
Re: Distribution zips and what they contain, was: SCA runtimes
Comments inline. Simon Jean-Sebastien Delfino wrote: Mike Edwards wrote: Jean-Sebastien, Let's chat some more about objectives, to see why we're seeming to look at this differently: [snip] Jean-Sebastien Delfino wrote: I was thinking about the following binary distro zips: - tuscany-core.zip - The base that everybody needs. core assembly model and runtime Java APIs, Java components - tuscany-web.zip - For WS and Web developers WS binding, Web 2.0 bindings, Scripting components, Widget components - tuscany-jee.zip - For JEE app integration EJB, RMI and JMS bindings, Spring components - tuscany-process.zip - For process development BPEL and XQuery components - tuscany-all.zip - all of the above Mike Edwards wrote: I'm not convinced that this is a particularly useful split. Sorry to disagree, but it is worth debating this before folk do a lot of work. From the perspective of an end-user, their main goal in life is to get their applications working on their runtime. I view this as something like: - give me a Tuscany package (containing the Tuscany runtime materials) and a way of installing that with my runtime. Then tell me how and where I put my application stuff so that it will run. - splitting up the Tuscany package into several packages does not seem to help me very much. Now I have to go read and understand what each package does and what I need to do with it. - let's envisage a series of potential runtimes which I could be using: a) standalone Tuscany b) Tomcat c) Geronimo d) WebSphere e) a. n. other runtime What I think I'd really like is to be told 1) go get this (one) download package containing the runtime 2) have an install script of some kind that knows how to take content from the download package and put it "in the right place(s)" for it to be usable with my runtime (may be one script per runtime type) - the partitioning which Jean-Sebastien describes above is actually more appropriately done by the install script. It will either KNOW that only certain pieces are appropriate for a given runtime (eg no point in installing JEE related stuff on a non-JEE runtime), or it will be able to ask some simple questions about whether I will need some of the less common pieces - am I asking for too much here, or is this the best approach for the end users? Jean-Sebastien Delfino wrote: Sorry, I'm not convinced: - The packages I've proposed are relevant to all the runtimes you've listed (including the JEE one). - If I'm an application developer or a system administrator and I'm not able to say if I'm going to use Web 2.0, JEE integration or business processes, I won't be able to answer the install script questions either. I find the organization of the Spring framework download page [1] clear and useful and I was envisioning a similar download page organization for Tuscany. Do people find it confusing and can they say why? [1] http://www.springframework.org/download Mike edwards wrote: The problem I have with the Spring download page, which I think is the same as the reason I'm not keen on the split you've suggested above, is that I first have to get to grips with what each download is about. So, if I'm a newbie to Spring, I first have to learn about "Web Flow", "Security", "Web Services" and so on, in order to know whether I need them or not. For someone already familiar with Spring, this split might be OK. I was thinking about two categories of users: A) The user who knows what he wants to achieve: - I am a Web app developer and want to compose a Web app - I want to compose Web Services - I want to integrate existing EJBs from my JEE app server - I want to develop business processes These packages would help him get the distro he needs. B) The lurker who wants to try out Tuscany. The different packages on the download page would give him an overview of the high-level features. He'd pick one path and start to explore it, instead of drowning in a sea of features and JARs that he doesn't need to start experimenting. For a newbie, it isn't. Let's go back to the reason to want to split things up. We've previously discussed: - splitting to make the download smaller - making it easier for people to find what they need I've said before that I think making things easier for people should be the more important of the goals. The trouble is that these requirements are actually in conflict. The simplest package is a single package that I download and then run as an installer - and I get everything I want. No more searching. No sudden discovery that something does not work because I don't have some needed dependency. I agree that package size is important, but it is less important to me than making things easy. Even 100Mb ain't too big a deal these days with Broadband a general commodity. (Microsoft certainly seem to think so when you look at some of their update bundles !!). I note Simon
Re: Distribution zips and what they contain, was: SCA runtimes
On Feb 3, 2008 7:49 PM, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote: > One thing looking at those Spring downloads is that i think they're more > > comaprable to out SCA, SDO, and DAS downloads. > > I don't understand why you're saying that. I was following a scheme > similar to Spring in my proposal. > > - tuscany-core - Spring core framework > - tuscany-web - Spring web flow / Spring Web services > - tuscany-process - Spring integration > What I was trying to say is that I don't think the Spring Framework does map to only our tuscany-core as the Spring Framework also includes support for all those other things i listed out before (ws, scripting,...), so following the Spring model the tuscany-core, web, and process would be included in the one distribution. The other Spring downloads are for completely separate projects with separate release cycles just as our SDO and DAS projects are, for example, Spring Web services is a complete WS stack comparable to Axis2 or CXF. ...ant
Re: Distribution zips and what they contain, was: SCA runtimes
Mike Edwards wrote: Jean-Sebastien, Let's chat some more about objectives, to see why we're seeming to look at this differently: [snip] Jean-Sebastien Delfino wrote: I was thinking about the following binary distro zips: - tuscany-core.zip - The base that everybody needs. core assembly model and runtime Java APIs, Java components - tuscany-web.zip - For WS and Web developers WS binding, Web 2.0 bindings, Scripting components, Widget components - tuscany-jee.zip - For JEE app integration EJB, RMI and JMS bindings, Spring components - tuscany-process.zip - For process development BPEL and XQuery components - tuscany-all.zip - all of the above Mike Edwards wrote: I'm not convinced that this is a particularly useful split. Sorry to disagree, but it is worth debating this before folk do a lot of work. From the perspective of an end-user, their main goal in life is to get their applications working on their runtime. I view this as something like: - give me a Tuscany package (containing the Tuscany runtime materials) and a way of installing that with my runtime. Then tell me how and where I put my application stuff so that it will run. - splitting up the Tuscany package into several packages does not seem to help me very much. Now I have to go read and understand what each package does and what I need to do with it. - let's envisage a series of potential runtimes which I could be using: a) standalone Tuscany b) Tomcat c) Geronimo d) WebSphere e) a. n. other runtime What I think I'd really like is to be told 1) go get this (one) download package containing the runtime 2) have an install script of some kind that knows how to take content from the download package and put it "in the right place(s)" for it to be usable with my runtime (may be one script per runtime type) - the partitioning which Jean-Sebastien describes above is actually more appropriately done by the install script. It will either KNOW that only certain pieces are appropriate for a given runtime (eg no point in installing JEE related stuff on a non-JEE runtime), or it will be able to ask some simple questions about whether I will need some of the less common pieces - am I asking for too much here, or is this the best approach for the end users? Jean-Sebastien Delfino wrote: Sorry, I'm not convinced: - The packages I've proposed are relevant to all the runtimes you've listed (including the JEE one). - If I'm an application developer or a system administrator and I'm not able to say if I'm going to use Web 2.0, JEE integration or business processes, I won't be able to answer the install script questions either. I find the organization of the Spring framework download page [1] clear and useful and I was envisioning a similar download page organization for Tuscany. Do people find it confusing and can they say why? [1] http://www.springframework.org/download Mike edwards wrote: The problem I have with the Spring download page, which I think is the same as the reason I'm not keen on the split you've suggested above, is that I first have to get to grips with what each download is about. So, if I'm a newbie to Spring, I first have to learn about "Web Flow", "Security", "Web Services" and so on, in order to know whether I need them or not. For someone already familiar with Spring, this split might be OK. I was thinking about two categories of users: A) The user who knows what he wants to achieve: - I am a Web app developer and want to compose a Web app - I want to compose Web Services - I want to integrate existing EJBs from my JEE app server - I want to develop business processes These packages would help him get the distro he needs. B) The lurker who wants to try out Tuscany. The different packages on the download page would give him an overview of the high-level features. He'd pick one path and start to explore it, instead of drowning in a sea of features and JARs that he doesn't need to start experimenting. For a newbie, it isn't. Let's go back to the reason to want to split things up. We've previously discussed: - splitting to make the download smaller - making it easier for people to find what they need I've said before that I think making things easier for people should be the more important of the goals. The trouble is that these requirements are actually in conflict. The simplest package is a single package that I download and then run as an installer - and I get everything I want. No more searching. No sudden discovery that something does not work because I don't have some needed dependency. I agree that package size is important, but it is less important to me than making things easy. Even 100Mb ain't too big a deal these days with Broadband a general commodity. (Microsoft certainly seem to think so when you look at some of their update bundles !!). I note Simon Nash's comment about the potential of a small download packa
Re: Distribution zips and what they contain, was: SCA runtimes
Jean-Sebastien, Let's chat some more about objectives, to see why we're seeming to look at this differently: Jean-Sebastien Delfino wrote: Mike Edwards wrote: [snip] >> Jean-Sebastien Delfino wrote: I think we could improve our distro scheme to provide: - smaller packages - easier for people to find what they need I agree with the objectives. The second of the two is more important from my perspective. I was thinking about the following binary distro zips: - tuscany-core.zip - The base that everybody needs. core assembly model and runtime Java APIs, Java components - tuscany-web.zip - For WS and Web developers WS binding, Web 2.0 bindings, Scripting components, Widget components - tuscany-jee.zip - For JEE app integration EJB, RMI and JMS bindings, Spring components - tuscany-process.zip - For process development BPEL and XQuery components - tuscany-all.zip - all of the above I'm not convinced that this is a particularly useful split. Sorry to disagree, but it is worth debating this before folk do a lot of work. From the perspective of an end-user, their main goal in life is to get their applications working on their runtime. I view this as something like: - give me a Tuscany package (containing the Tuscany runtime materials) and a way of installing that with my runtime. Then tell me how and where I put my application stuff so that it will run. - splitting up the Tuscany package into several packages does not seem to help me very much. Now I have to go read and understand what each package does and what I need to do with it. - let's envisage a series of potential runtimes which I could be using: a) standalone Tuscany b) Tomcat c) Geronimo d) WebSphere e) a. n. other runtime What I think I'd really like is to be told 1) go get this (one) download package containing the runtime 2) have an install script of some kind that knows how to take content from the download package and put it "in the right place(s)" for it to be usable with my runtime (may be one script per runtime type) - the partitioning which Jean-Sebastien describes above is actually more appropriately done by the install script. It will either KNOW that only certain pieces are appropriate for a given runtime (eg no point in installing JEE related stuff on a non-JEE runtime), or it will be able to ask some simple questions about whether I will need some of the less common pieces - am I asking for too much here, or is this the best approach for the end users? Sorry, I'm not convinced: - The packages I've proposed are relevant to all the runtimes you've listed (including the JEE one). - If I'm an application developer or a system administrator and I'm not able to say if I'm going to use Web 2.0, JEE integration or business processes, I won't be able to answer the install script questions either. I find the organization of the Spring framework download page [1] clear and useful and I was envisioning a similar download page organization for Tuscany. Do people find it confusing and can they say why? [1] http://www.springframework.org/download The problem I have with the Spring download page, which I think is the same as the reason I'm not keen on the split you've suggested above, is that I first have to get to grips with what each download is about. So, if I'm a newbie to Spring, I first have to learn about "Web Flow", "Security", "Web Services" and so on, in order to know whether I need them or not. For someone already familiar with Spring, this split might be OK. For a newbie, it isn't. Let's go back to the reason to want to split things up. We've previously discussed: - splitting to make the download smaller - making it easier for people to find what they need I've said before that I think making things easier for people should be the more important of the goals. The trouble is that these requirements are actually in conflict. The simplest package is a single package that I download and then run as an installer - and I get everything I want. No more searching. No sudden discovery that something does not work because I don't have some needed dependency. I agree that package size is important, but it is less important to me than making things easy. Even 100Mb ain't too big a deal these days with Broadband a general commodity. (Microsoft certainly seem to think so when you look at some of their update bundles !!). I note Simon Nash's comment about the potential of a small download package that has some installer that then goes and fetches the rest. This is a bit like the Eclipse approach. I could live with that - as long as it's also possible to get a big bundle that I can download for any offline work. If we don't think that folk can answer questions - and you may be right on that - then best to assume they need everything and avoid problems that way. Hope this helps, Yours, Mike. PS I definitely agree with the idea of h
Re: Distribution zips and what they contain, was: SCA runtimes
ant elder wrote: [snip] I'm leaning more towards what Mike is suggesting. OK it doesn't look like we're reaching a consensus as at least two people don't seem to like the scheme I proposed. I take it back then, forget about my proposal, but I still think that a single download containing all kinds of extensions that I don't need most of the times is overkill. One thing looking at those Spring downloads is that i think they're more comaprable to out SCA, SDO, and DAS downloads. I don't understand why you're saying that. I was following a scheme similar to Spring in my proposal. - tuscany-core - Spring core framework - tuscany-web - Spring web flow / Spring Web services - tuscany-process - Spring integration -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Distribution zips and what they contain, was: SCA runtimes
On Feb 2, 2008 3:23 AM, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote: > Mike Edwards wrote: > [snip] > >> Jean-Sebastien Delfino wrote: > >> I think we could improve our distro scheme to provide: > >> - smaller packages > >> - easier for people to find what they need > >> > > > > I agree with the objectives. The second of the two is more important > > from my perspective. > > > >> I was thinking about the following binary distro zips: > >> > >> - tuscany-core.zip - The base that everybody needs. > >> core assembly model and runtime > >> Java APIs, Java components > >> > >> - tuscany-web.zip - For WS and Web developers > >> WS binding, Web 2.0 bindings, Scripting components, Widget components > >> > >> - tuscany-jee.zip - For JEE app integration > >> EJB, RMI and JMS bindings, Spring components > >> > >> - tuscany-process.zip - For process development > >> BPEL and XQuery components > >> > >> - tuscany-all.zip - all of the above > >> > > > > I'm not convinced that this is a particularly useful split. Sorry to > > disagree, but it is worth debating this before folk do a lot of work. > > > > From the perspective of an end-user, their main goal in life is to get > > their applications working on their runtime. > > > > I view this as something like: > > > > - give me a Tuscany package (containing the Tuscany runtime materials) > > and a way of installing that with my runtime. Then tell me how and > > where I put my application stuff so that it will run. > > > > - splitting up the Tuscany package into several packages does not seem > > to help me very much. Now I have to go read and understand what each > > package does and what I need to do with it. > > > > - let's envisage a series of potential runtimes which I could be using: > > a) standalone Tuscany > > b) Tomcat > > c) Geronimo > > d) WebSphere > > e) a. n. other runtime > > What I think I'd really like is to be told > > 1) go get this (one) download package containing the runtime > > 2) have an install script of some kind that knows how to take content > > from the download package and put it "in the right place(s)" for it to > > be usable with my runtime (may be one script per runtime type) > > > > - the partitioning which Jean-Sebastien describes above is actually more > > appropriately done by the install script. It will either KNOW that only > > certain pieces are appropriate for a given runtime (eg no point in > > installing JEE related stuff on a non-JEE runtime), or it will be able > > to ask some simple questions about whether I will need some of the less > > common pieces > > > > - am I asking for too much here, or is this the best approach for the > > end users? > > > > Sorry, I'm not convinced: > > - The packages I've proposed are relevant to all the runtimes you've > listed (including the JEE one). > > - If I'm an application developer or a system administrator and I'm not > able to say if I'm going to use Web 2.0, JEE integration or business > processes, I won't be able to answer the install script questions either. > > I find the organization of the Spring framework download page [1] clear > and useful and I was envisioning a similar download page organization > for Tuscany. Do people find it confusing and can they say why? > > [1] http://www.springframework.org/download > -- > Jean-Sebastien > > I'm leaning more towards what Mike is suggesting. One thing looking at those Spring downloads is that i think they're more comaprable to out SCA, SDO, and DAS downloads. If you look within the main Spring Framework distribution its actually very similar to our SCA one and, as we do, it includes code for all sorts of stuff and their dependencies - aop, beans, caching, context, core, dao, ejb, glassfixh, oc4j, tomcat, weblogic, websphere, jca, jdbc, jms, jmx, jndi, mail, orm, hibernate, ibatis, jdo, jpa, toplink, remoting with caucho, jaxrpc, jaxws, rmi and soap, scheduling and quartz, scripting with bsh, groovy and jruby, transactions and jta, and ui stuff with freemaker, jasper and velocity, jsf, portlets, servlets, tiles, struts ...ant
Re: Distribution zips and what they contain, was: SCA runtimes
On 02/02/2008, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote: > Mike Edwards wrote: > [snip] > >> Jean-Sebastien Delfino wrote: > >> I think we could improve our distro scheme to provide: > >> - smaller packages > >> - easier for people to find what they need > >> > > > > I agree with the objectives. The second of the two is more important > > from my perspective. > > > >> I was thinking about the following binary distro zips: > >> > >> - tuscany-core.zip - The base that everybody needs. > >> core assembly model and runtime > >> Java APIs, Java components > >> > >> - tuscany-web.zip - For WS and Web developers > >> WS binding, Web 2.0 bindings, Scripting components, Widget components > >> > >> - tuscany-jee.zip - For JEE app integration > >> EJB, RMI and JMS bindings, Spring components > >> > >> - tuscany-process.zip - For process development > >> BPEL and XQuery components > >> > >> - tuscany-all.zip - all of the above > >> > > > > I'm not convinced that this is a particularly useful split. Sorry to > > disagree, but it is worth debating this before folk do a lot of work. > > > > From the perspective of an end-user, their main goal in life is to get > > their applications working on their runtime. > > > > I view this as something like: > > > > - give me a Tuscany package (containing the Tuscany runtime materials) > > and a way of installing that with my runtime. Then tell me how and > > where I put my application stuff so that it will run. > > > > - splitting up the Tuscany package into several packages does not seem > > to help me very much. Now I have to go read and understand what each > > package does and what I need to do with it. > > > > - let's envisage a series of potential runtimes which I could be using: > > a) standalone Tuscany > > b) Tomcat > > c) Geronimo > > d) WebSphere > > e) a. n. other runtime > > What I think I'd really like is to be told > > 1) go get this (one) download package containing the runtime > > 2) have an install script of some kind that knows how to take content > > from the download package and put it "in the right place(s)" for it to > > be usable with my runtime (may be one script per runtime type) > > > > - the partitioning which Jean-Sebastien describes above is actually more > > appropriately done by the install script. It will either KNOW that only > > certain pieces are appropriate for a given runtime (eg no point in > > installing JEE related stuff on a non-JEE runtime), or it will be able > > to ask some simple questions about whether I will need some of the less > > common pieces > > > > - am I asking for too much here, or is this the best approach for the > > end users? > > > > Sorry, I'm not convinced: > > - The packages I've proposed are relevant to all the runtimes you've > listed (including the JEE one). > > - If I'm an application developer or a system administrator and I'm not > able to say if I'm going to use Web 2.0, JEE integration or business > processes, I won't be able to answer the install script questions either. > > I find the organization of the Spring framework download page [1] clear > and useful and I was envisioning a similar download page organization > for Tuscany. Do people find it confusing and can they say why? > I know nothing about Spring or Tuscany, so take these comments as you wish. It's not clear to me if Webflow is a part of Framework or independent - does one have to download both? Similarly for the other products/addons on the page. There is a long list of Homepages at the bottom - why do only some of them have download sections on this page? I find the packaging of the Framework a bit annoying. Suppose I downloaded the binary only, and then decide I need the documentation - I've got to download the binary as well. Likewise if I just want the documentation. Why not just provide the documentation separately? BTW, the heading "For More Information Access Spring Project Homepages" could be clearer, e.g. For more information on Spring projects, please visit their homepages > [1] http://www.springframework.org/download > -- > Jean-Sebastien > > - > 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: Distribution zips and what they contain, was: SCA runtimes
Mike Edwards wrote: [snip] >> Jean-Sebastien Delfino wrote: I think we could improve our distro scheme to provide: - smaller packages - easier for people to find what they need I agree with the objectives. The second of the two is more important from my perspective. I was thinking about the following binary distro zips: - tuscany-core.zip - The base that everybody needs. core assembly model and runtime Java APIs, Java components - tuscany-web.zip - For WS and Web developers WS binding, Web 2.0 bindings, Scripting components, Widget components - tuscany-jee.zip - For JEE app integration EJB, RMI and JMS bindings, Spring components - tuscany-process.zip - For process development BPEL and XQuery components - tuscany-all.zip - all of the above I'm not convinced that this is a particularly useful split. Sorry to disagree, but it is worth debating this before folk do a lot of work. From the perspective of an end-user, their main goal in life is to get their applications working on their runtime. I view this as something like: - give me a Tuscany package (containing the Tuscany runtime materials) and a way of installing that with my runtime. Then tell me how and where I put my application stuff so that it will run. - splitting up the Tuscany package into several packages does not seem to help me very much. Now I have to go read and understand what each package does and what I need to do with it. - let's envisage a series of potential runtimes which I could be using: a) standalone Tuscany b) Tomcat c) Geronimo d) WebSphere e) a. n. other runtime What I think I'd really like is to be told 1) go get this (one) download package containing the runtime 2) have an install script of some kind that knows how to take content from the download package and put it "in the right place(s)" for it to be usable with my runtime (may be one script per runtime type) - the partitioning which Jean-Sebastien describes above is actually more appropriately done by the install script. It will either KNOW that only certain pieces are appropriate for a given runtime (eg no point in installing JEE related stuff on a non-JEE runtime), or it will be able to ask some simple questions about whether I will need some of the less common pieces - am I asking for too much here, or is this the best approach for the end users? Sorry, I'm not convinced: - The packages I've proposed are relevant to all the runtimes you've listed (including the JEE one). - If I'm an application developer or a system administrator and I'm not able to say if I'm going to use Web 2.0, JEE integration or business processes, I won't be able to answer the install script questions either. I find the organization of the Spring framework download page [1] clear and useful and I was envisioning a similar download page organization for Tuscany. Do people find it confusing and can they say why? [1] http://www.springframework.org/download -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Distribution zips and what they contain, was: SCA runtimes
On 31/01/2008, Simon Nash <[EMAIL PROTECTED]> wrote: > Comments inline. > >Simon > > Mike Edwards wrote: > > > Folks, > > > > As with Simon Nash - sorry for my slow reply but the SCA spec work has > > been a hard master over the past 2 weeks ;-) > > > > Jean-Sebastien Delfino wrote: > > > >> Simon Nash wrote: > >> >> Jean-Sebastien Delfino wrote: > >> > - What distro Zips are we building and what do they contain? just > the runtime? samples or not? dependencies or not? are we building > specialized distros for different use cases? > >> > >> [snip] > >> > >>> With a big topic like this, dividing it into separate threads makes it > >>> easier for people to follow and participate in the discussions. The > >>> split you are suggesting looks good to me. > >> > >> [snip] > >> > >> I'd like to discuss the following: "What distro Zips are we building > >> and what do they contain?" > >> > >> I think we could improve our distro scheme to provide: > >> - smaller packages > >> - easier for people to find what they need > >> > > > > I agree with the objectives. The second of the two is more important > > from my perspective. > > > >> I was thinking about the following binary distro zips: > >> > >> - tuscany-core.zip - The base that everybody needs. > >> core assembly model and runtime > >> Java APIs, Java components > >> > >> - tuscany-web.zip - For WS and Web developers > >> WS binding, Web 2.0 bindings, Scripting components, Widget components > >> > >> - tuscany-jee.zip - For JEE app integration > >> EJB, RMI and JMS bindings, Spring components > >> > >> - tuscany-process.zip - For process development > >> BPEL and XQuery components > >> > >> - tuscany-all.zip - all of the above > >> > > > > I'm not convinced that this is a particularly useful split. Sorry to > > disagree, but it is worth debating this before folk do a lot of work. > > > > From the perspective of an end-user, their main goal in life is to get > > their applications working on their runtime. > > > > I view this as something like: > > > > - give me a Tuscany package (containing the Tuscany runtime materials) > > and a way of installing that with my runtime. Then tell me how and > > where I put my application stuff so that it will run. > > > > - splitting up the Tuscany package into several packages does not seem > > to help me very much. Now I have to go read and understand what each > > package does and what I need to do with it. > > > > - let's envisage a series of potential runtimes which I could be using: > > a) standalone Tuscany > > b) Tomcat > > c) Geronimo > > d) WebSphere > > e) a. n. other runtime > > What I think I'd really like is to be told > > 1) go get this (one) download package containing the runtime > > > I'd like to focus on "...containing the runtime". This is the heart > of this discussion. What is "the runtime"? If it's about 2 megs of > Tuscany jars, this is a good approach. If it includes about 50 megs > of dependent jars, plus samples/demos/etc., this suffers from all the > problems that we have today. > > > 2) have an install script of some kind that knows how to take content > > from the download package and put it "in the right place(s)" for it to > > be usable with my runtime (may be one script per runtime type) > > > If this script can also pull down the dependencies needed, I am ++1 > with doing this. It can't be too hard, surely, to find the repos > where they all live and pull them down. It shouldn't take any more > time to do this than having them downloaded as part of the Tuscany > distro. Actually, it should take less time because the script could > be more intelligent about only pulling down what's needed and not > already present in the user's environment. > +1 Just need to be careful with downloading jars that are not released under AL 2.0 that the user is made aware of the license requirements. This might mean having to agree to a prompt. > > - the partitioning which Jean-Sebastien describes above is actually more > > appropriately done by the install script. It will either KNOW that only > > certain pieces are appropriate for a given runtime (eg no point in > > installing JEE related stuff on a non-JEE runtime), or it will be able > > to ask some simple questions about whether I will need some of the less > > common pieces > > > > > - am I asking for too much here, or is this the best approach for the > > end users? > > > For many end users, it would be a good approach. However, it doesn't > (on its own) solve the issue about making it easier for users to find > what they need, as the scope of Tuscany gets broader and more diverse > over time. I'd like to see some progress on that as well. > >Simon > > >> Note that I'm not trying to tackle release cycles and the potential > >> for releasing the above zips independently in this discussion and I'm > >> assuming that we release all of the above together. > >> > >> I'm also assuming that the relevant samples a
Re: Distribution zips and what they contain, was: SCA runtimes
Comments inline. Simon Mike Edwards wrote: Folks, As with Simon Nash - sorry for my slow reply but the SCA spec work has been a hard master over the past 2 weeks ;-) Jean-Sebastien Delfino wrote: Simon Nash wrote: >> Jean-Sebastien Delfino wrote: - What distro Zips are we building and what do they contain? just the runtime? samples or not? dependencies or not? are we building specialized distros for different use cases? [snip] With a big topic like this, dividing it into separate threads makes it easier for people to follow and participate in the discussions. The split you are suggesting looks good to me. [snip] I'd like to discuss the following: "What distro Zips are we building and what do they contain?" I think we could improve our distro scheme to provide: - smaller packages - easier for people to find what they need I agree with the objectives. The second of the two is more important from my perspective. I was thinking about the following binary distro zips: - tuscany-core.zip - The base that everybody needs. core assembly model and runtime Java APIs, Java components - tuscany-web.zip - For WS and Web developers WS binding, Web 2.0 bindings, Scripting components, Widget components - tuscany-jee.zip - For JEE app integration EJB, RMI and JMS bindings, Spring components - tuscany-process.zip - For process development BPEL and XQuery components - tuscany-all.zip - all of the above I'm not convinced that this is a particularly useful split. Sorry to disagree, but it is worth debating this before folk do a lot of work. From the perspective of an end-user, their main goal in life is to get their applications working on their runtime. I view this as something like: - give me a Tuscany package (containing the Tuscany runtime materials) and a way of installing that with my runtime. Then tell me how and where I put my application stuff so that it will run. - splitting up the Tuscany package into several packages does not seem to help me very much. Now I have to go read and understand what each package does and what I need to do with it. - let's envisage a series of potential runtimes which I could be using: a) standalone Tuscany b) Tomcat c) Geronimo d) WebSphere e) a. n. other runtime What I think I'd really like is to be told 1) go get this (one) download package containing the runtime > I'd like to focus on "...containing the runtime". This is the heart of this discussion. What is "the runtime"? If it's about 2 megs of Tuscany jars, this is a good approach. If it includes about 50 megs of dependent jars, plus samples/demos/etc., this suffers from all the problems that we have today. 2) have an install script of some kind that knows how to take content from the download package and put it "in the right place(s)" for it to be usable with my runtime (may be one script per runtime type) If this script can also pull down the dependencies needed, I am ++1 with doing this. It can't be too hard, surely, to find the repos where they all live and pull them down. It shouldn't take any more time to do this than having them downloaded as part of the Tuscany distro. Actually, it should take less time because the script could be more intelligent about only pulling down what's needed and not already present in the user's environment. - the partitioning which Jean-Sebastien describes above is actually more appropriately done by the install script. It will either KNOW that only certain pieces are appropriate for a given runtime (eg no point in installing JEE related stuff on a non-JEE runtime), or it will be able to ask some simple questions about whether I will need some of the less common pieces - am I asking for too much here, or is this the best approach for the end users? For many end users, it would be a good approach. However, it doesn't (on its own) solve the issue about making it easier for users to find what they need, as the scope of Tuscany gets broader and more diverse over time. I'd like to see some progress on that as well. Simon Note that I'm not trying to tackle release cycles and the potential for releasing the above zips independently in this discussion and I'm assuming that we release all of the above together. I'm also assuming that the relevant samples are included in each zip. Thoughts? - 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: Distribution zips and what they contain, was: SCA runtimes
Folks, As with Simon Nash - sorry for my slow reply but the SCA spec work has been a hard master over the past 2 weeks ;-) Jean-Sebastien Delfino wrote: Simon Nash wrote: >> Jean-Sebastien Delfino wrote: - What distro Zips are we building and what do they contain? just the runtime? samples or not? dependencies or not? are we building specialized distros for different use cases? [snip] With a big topic like this, dividing it into separate threads makes it easier for people to follow and participate in the discussions. The split you are suggesting looks good to me. [snip] I'd like to discuss the following: "What distro Zips are we building and what do they contain?" I think we could improve our distro scheme to provide: - smaller packages - easier for people to find what they need I agree with the objectives. The second of the two is more important from my perspective. I was thinking about the following binary distro zips: - tuscany-core.zip - The base that everybody needs. core assembly model and runtime Java APIs, Java components - tuscany-web.zip - For WS and Web developers WS binding, Web 2.0 bindings, Scripting components, Widget components - tuscany-jee.zip - For JEE app integration EJB, RMI and JMS bindings, Spring components - tuscany-process.zip - For process development BPEL and XQuery components - tuscany-all.zip - all of the above I'm not convinced that this is a particularly useful split. Sorry to disagree, but it is worth debating this before folk do a lot of work. From the perspective of an end-user, their main goal in life is to get their applications working on their runtime. I view this as something like: - give me a Tuscany package (containing the Tuscany runtime materials) and a way of installing that with my runtime. Then tell me how and where I put my application stuff so that it will run. - splitting up the Tuscany package into several packages does not seem to help me very much. Now I have to go read and understand what each package does and what I need to do with it. - let's envisage a series of potential runtimes which I could be using: a) standalone Tuscany b) Tomcat c) Geronimo d) WebSphere e) a. n. other runtime What I think I'd really like is to be told 1) go get this (one) download package containing the runtime 2) have an install script of some kind that knows how to take content from the download package and put it "in the right place(s)" for it to be usable with my runtime (may be one script per runtime type) - the partitioning which Jean-Sebastien describes above is actually more appropriately done by the install script. It will either KNOW that only certain pieces are appropriate for a given runtime (eg no point in installing JEE related stuff on a non-JEE runtime), or it will be able to ask some simple questions about whether I will need some of the less common pieces - am I asking for too much here, or is this the best approach for the end users? Note that I'm not trying to tackle release cycles and the potential for releasing the above zips independently in this discussion and I'm assuming that we release all of the above together. I'm also assuming that the relevant samples are included in each zip. Thoughts? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Distribution zips and what they contain, was: SCA runtimes
On Jan 29, 2008 3:09 PM, Simon Nash <[EMAIL PROTECTED]> wrote: > Sorry for the late response. I have been travelling and in OASIS > meetings, and I'm just catching up with the ML now. > > See comments inline. > > Simon > > Jean-Sebastien Delfino wrote: > > > Simon Nash wrote: > > >> Jean-Sebastien Delfino wrote: > > > >>> - What distro Zips are we building and what do they contain? just the > >>> runtime? samples or not? dependencies or not? are we building > >>> specialized distros for different use cases? > > > > [snip] > > > >> With a big topic like this, dividing it into separate threads makes it > >> easier for people to follow and participate in the discussions. The > >> split you are suggesting looks good to me. > > > > [snip] > > > > I'd like to discuss the following: "What distro Zips are we building and > > what do they contain?" > > > > I think we could improve our distro scheme to provide: > > - smaller packages > > - easier for people to find what they need > > > +1 to both of these. It would also help modularity by eliminating > some undesired dependencies, and it would give people a better > understanding of the true size of Tuscany. > > > I was thinking about the following binary distro zips: > > > > - tuscany-core.zip - The base that everybody needs. > > core assembly model and runtime > > Java APIs, Java components > > > I think it would make sense to have binding.ws in here. If we are > including binding.sca (as auggested by Sebastien), this implies a > need for binding.ws to handle remote endpoints. > I agree with that. Not sure i agree all the other distro's will really help the goal of making things "easier for people to find what they need" but if we do have a core distro then i think it should include WS support. ...ant
Re: Distribution zips and what they contain, was: SCA runtimes
Sorry for the late response. I have been travelling and in OASIS meetings, and I'm just catching up with the ML now. See comments inline. Simon Jean-Sebastien Delfino wrote: Simon Nash wrote: >> Jean-Sebastien Delfino wrote: - What distro Zips are we building and what do they contain? just the runtime? samples or not? dependencies or not? are we building specialized distros for different use cases? [snip] With a big topic like this, dividing it into separate threads makes it easier for people to follow and participate in the discussions. The split you are suggesting looks good to me. [snip] I'd like to discuss the following: "What distro Zips are we building and what do they contain?" I think we could improve our distro scheme to provide: - smaller packages - easier for people to find what they need +1 to both of these. It would also help modularity by eliminating some undesired dependencies, and it would give people a better understanding of the true size of Tuscany. I was thinking about the following binary distro zips: - tuscany-core.zip - The base that everybody needs. core assembly model and runtime Java APIs, Java components I think it would make sense to have binding.ws in here. If we are including binding.sca (as auggested by Sebastien), this implies a need for binding.ws to handle remote endpoints. - tuscany-web.zip - For WS and Web developers WS binding, Web 2.0 bindings, Scripting components, Widget components +1 (see comment above). - tuscany-jee.zip - For JEE app integration EJB, RMI and JMS bindings, Spring components +1 - tuscany-process.zip - For process development BPEL and XQuery components +1 - tuscany-all.zip - all of the above If this is exactly equal to the sum of all of the above, then we just need a zipzip file that contains the other zips, with a script to unzip them all into the same set of directories. Note that I'm not trying to tackle release cycles and the potential for releasing the above zips independently in this discussion and I'm assuming that we release all of the above together. +1 for taking this as a first step. I'm also assuming that the relevant samples are included in each zip. +1 Simon Thoughts? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Distribution zips and what they contain, was: SCA runtimes
Thank you, Sebastien. Graham or I will provide the changes once the new distribution poms are ready. Thank you... Regards, Rajini On 1/24/08, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote: > > Rajini Sivaram wrote: > > Would it be possible to add an OSGi manifest header into these zip files > so > > that the zips can be directly installed into an OSGi runtime? The > entries > > will not have any impact when used without OSGi. > > +1 > > The only issue would be the > > creation of these entries. We have two options - 1)generate them > > automatically during the build process using the maven-bundle-plugin, > > +1 or another automated process > > or 2) > > hand-code a manifest file. It would be easiest to go with option 2) to > start > > with to avoid any build issues. If it becomes difficult to maintain the > > hand-coded manifest file, we can move to option 1). > > I'd suggest to write it by hand once to define the target to automate, > then automate its generation right away. > > > The manifest entries will contain bundle names, versions, imported > packages, > > exported packages and a bundle classpath(which lists jars contained > inside > > the zip). > > Can you post an example or put it in SVN? Thanks. > > -- > Jean-Sebastien > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
Re: Distribution zips and what they contain, was: SCA runtimes
I just want to throw my 0.02 cents here... I haven't made up my mind if these multiple distros are going to really help or not, but once we implement this, we will need very clear user documentation, to avoid confusion. We should also state very clear the limitations, otherwise people will start to download distribution A and will start to ask how to add binding X, etc... Also, we should double check all modules that have derby db in SVN and make that created by the build process. This would also help on reducing the size of distributions. On Jan 24, 2008 9:59 AM, Raymond Feng <[EMAIL PROTECTED]> wrote: > There are two tools in Apache felix can probably help: > > 1) mangen - OSGi Bundle Manifest generator > http://cwiki.apache.org/confluence/display/FELIX/Bundle+Manifest+Generator+%28mangen%29 > > We could use it to create OSGi bundles out of the existing jars. > > 2) Maven Bundle Plugin 1.2.0 > > We could use it to automate the generating OSGi manifests as part of the > maven build. > > Thanks, > Raymond > > - Original Message - > From: "Jean-Sebastien Delfino" <[EMAIL PROTECTED]> > To: > > Sent: Thursday, January 24, 2008 9:46 AM > Subject: Re: Distribution zips and what they contain, was: SCA runtimes > > > > Rajini Sivaram wrote: > >> Would it be possible to add an OSGi manifest header into these zip files > >> so > >> that the zips can be directly installed into an OSGi runtime? The entries > >> will not have any impact when used without OSGi. > > > > +1 > > > > The only issue would be the > >> creation of these entries. We have two options - 1)generate them > >> automatically during the build process using the maven-bundle-plugin, > > > > +1 or another automated process > > > > or 2) > >> hand-code a manifest file. It would be easiest to go with option 2) to > >> start > >> with to avoid any build issues. If it becomes difficult to maintain the > >> hand-coded manifest file, we can move to option 1). > > > > I'd suggest to write it by hand once to define the target to automate, > > then automate its generation right away. > > > >> The manifest entries will contain bundle names, versions, imported > >> packages, > >> exported packages and a bundle classpath(which lists jars contained > >> inside > >> the zip). > > > > Can you post an example or put it in SVN? Thanks. > > > > -- > > Jean-Sebastien > > > > - > > 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] > > -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Distribution zips and what they contain, was: SCA runtimes
There are two tools in Apache felix can probably help: 1) mangen - OSGi Bundle Manifest generator http://cwiki.apache.org/confluence/display/FELIX/Bundle+Manifest+Generator+%28mangen%29 We could use it to create OSGi bundles out of the existing jars. 2) Maven Bundle Plugin 1.2.0 We could use it to automate the generating OSGi manifests as part of the maven build. Thanks, Raymond - Original Message - From: "Jean-Sebastien Delfino" <[EMAIL PROTECTED]> To: Sent: Thursday, January 24, 2008 9:46 AM Subject: Re: Distribution zips and what they contain, was: SCA runtimes Rajini Sivaram wrote: Would it be possible to add an OSGi manifest header into these zip files so that the zips can be directly installed into an OSGi runtime? The entries will not have any impact when used without OSGi. +1 The only issue would be the creation of these entries. We have two options - 1)generate them automatically during the build process using the maven-bundle-plugin, +1 or another automated process or 2) hand-code a manifest file. It would be easiest to go with option 2) to start with to avoid any build issues. If it becomes difficult to maintain the hand-coded manifest file, we can move to option 1). I'd suggest to write it by hand once to define the target to automate, then automate its generation right away. The manifest entries will contain bundle names, versions, imported packages, exported packages and a bundle classpath(which lists jars contained inside the zip). Can you post an example or put it in SVN? Thanks. -- Jean-Sebastien - 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: Distribution zips and what they contain, was: SCA runtimes
On Jan 24, 2008 5:36 PM, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote: > ant elder wrote: > > On Jan 23, 2008 5:53 PM, Jean-Sebastien Delfino <[EMAIL PROTECTED]> > > wrote: > > > > > > > >> If this is mainly about reducing the size of the download > >> [snip] > >> > >> No > > > > > > I'm puzzled by this. One of the two goals at the start of this thread > was > > "smaller packages". > > I'm puzzled that you find that puzzling :) > > I had spelled two goals: > - smaller packages > - easier for people to find what they need > > You asked "Is this *mainly* about reducing the size...", I replied "No", > i.e. this is not *mainly* about smaller packages, it's about: > (A) smaller packages > (B) easier for people to find what they need > and (B) is more important to me. > > If size really isn't an issue then whats the problem > > with the distro including unneeded clutter - it can just be ignored? > > > > I would like to try have this reorg exercise get to a smaller download > size > > if possible - am I the only one that would like this? > > > > Me too, one of my two goals was: (A) smaller packages. > > -- > Jean-Sebastien > > Thanks for clarifying :-) I shall go and try to prioritize the goals over on that other thread and ask others to do the same, that way maybe we'll all understand better what everyone would like to achieve. ...ant
Re: Distribution zips and what they contain, was: SCA runtimes
Rajini Sivaram wrote: Would it be possible to add an OSGi manifest header into these zip files so that the zips can be directly installed into an OSGi runtime? The entries will not have any impact when used without OSGi. +1 The only issue would be the creation of these entries. We have two options - 1)generate them automatically during the build process using the maven-bundle-plugin, +1 or another automated process or 2) hand-code a manifest file. It would be easiest to go with option 2) to start with to avoid any build issues. If it becomes difficult to maintain the hand-coded manifest file, we can move to option 1). I'd suggest to write it by hand once to define the target to automate, then automate its generation right away. The manifest entries will contain bundle names, versions, imported packages, exported packages and a bundle classpath(which lists jars contained inside the zip). Can you post an example or put it in SVN? Thanks. -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Distribution zips and what they contain, was: SCA runtimes
ant elder wrote: On Jan 23, 2008 5:53 PM, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote: If this is mainly about reducing the size of the download [snip] No I'm puzzled by this. One of the two goals at the start of this thread was "smaller packages". I'm puzzled that you find that puzzling :) I had spelled two goals: - smaller packages - easier for people to find what they need You asked "Is this *mainly* about reducing the size...", I replied "No", i.e. this is not *mainly* about smaller packages, it's about: (A) smaller packages (B) easier for people to find what they need and (B) is more important to me. If size really isn't an issue then whats the problem with the distro including unneeded clutter - it can just be ignored? I would like to try have this reorg exercise get to a smaller download size if possible - am I the only one that would like this? Me too, one of my two goals was: (A) smaller packages. -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Distribution zips and what they contain, was: SCA runtimes
On Jan 23, 2008 5:53 PM, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote: > If this is mainly about reducing the size of the download > [snip] > > No I'm puzzled by this. One of the two goals at the start of this thread was "smaller packages". If size really isn't an issue then whats the problem with the distro including unneeded clutter - it can just be ignored? I would like to try have this reorg exercise get to a smaller download size if possible - am I the only one that would like this? ...ant
Re: Distribution zips and what they contain, was: SCA runtimes
Would it be possible to add an OSGi manifest header into these zip files so that the zips can be directly installed into an OSGi runtime? The entries will not have any impact when used without OSGi. The only issue would be the creation of these entries. We have two options - 1)generate them automatically during the build process using the maven-bundle-plugin, or 2) hand-code a manifest file. It would be easiest to go with option 2) to start with to avoid any build issues. If it becomes difficult to maintain the hand-coded manifest file, we can move to option 1). The manifest entries will contain bundle names, versions, imported packages, exported packages and a bundle classpath(which lists jars contained inside the zip). Thoughts? Thank you... Regards, Rajini On 1/23/08, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote: > > ant elder wrote: > [snip] > > Would each distro include everthing it needs or is tuscany-core.zip a > > prereq? > > tuscany-core is a prereq. That's what I meant with "tuscany-core - The > base that everybody needs." > > > Where do all the different data bindings go? > > Some in tuscany-core, some in tuscany-web, some (saxon for example) in > tuscany-process or tuscany-all. > > > Doesn't one of the SCA specs say an SCA runtime MUST support binding.ws? > > Yes in the assembly spec. Is that an issue? > > > Is interface.wsdl supported in the others or only with tuscany-web? > > I view interface.wsdl as part of tuscany-core. > > > Is the core distro really so useful with nothing except > > implementation.javaand no bindings > > The SCA binding should be in tuscany-core. > > > Do all those distro's include everything to support both tomcat and > Jetty > > standalone and webapps...and all the runtimes being discussed like > Geronimo > > and Tomcat deep integration? > > I'd rather stick to a small number of runtimes. I must admit I'm > confused by the growing list of runtimes and their different capabilities. > > My naive view is: > - Webapp support in tuscany-web > - Geronimo support in tuscany-jee (as I'll want to use Geronimo to > integrate JEE artifacts) > - or Geronimo support in its own tuscany-geronimo package? > > What do others think? > > > Would any/all of those work with all the new domain/node stuff? And i > think > > right now that requires things like the WS and JSON support? > > IMO the new domain/node stuff drags too much of Tuscany at the moment > and needs more work to simplify it. > > We could put the domain management application in a separate package, as > people won't install it on all their nodes. Thoughts? > > > Where would all the demo's get included? > > > > In the most relevant package, alert-aggregator in the tuscany-web > package, xml-bigbank in tuscany-process, some in tuscany-all. > > > If this is mainly about reducing the size of the download > [snip] > > No, I want to provide people with packages that fit their scenarios, not > cluttered with other things they don't need. > > -- > Jean-Sebastien > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
Re: Distribution zips and what they contain, was: SCA runtimes
ant elder wrote: [snip] Would each distro include everthing it needs or is tuscany-core.zip a prereq? tuscany-core is a prereq. That's what I meant with "tuscany-core - The base that everybody needs." Where do all the different data bindings go? Some in tuscany-core, some in tuscany-web, some (saxon for example) in tuscany-process or tuscany-all. Doesn't one of the SCA specs say an SCA runtime MUST support binding.ws? Yes in the assembly spec. Is that an issue? Is interface.wsdl supported in the others or only with tuscany-web? I view interface.wsdl as part of tuscany-core. Is the core distro really so useful with nothing except implementation.javaand no bindings The SCA binding should be in tuscany-core. Do all those distro's include everything to support both tomcat and Jetty standalone and webapps...and all the runtimes being discussed like Geronimo and Tomcat deep integration? I'd rather stick to a small number of runtimes. I must admit I'm confused by the growing list of runtimes and their different capabilities. My naive view is: - Webapp support in tuscany-web - Geronimo support in tuscany-jee (as I'll want to use Geronimo to integrate JEE artifacts) - or Geronimo support in its own tuscany-geronimo package? What do others think? Would any/all of those work with all the new domain/node stuff? And i think right now that requires things like the WS and JSON support? IMO the new domain/node stuff drags too much of Tuscany at the moment and needs more work to simplify it. We could put the domain management application in a separate package, as people won't install it on all their nodes. Thoughts? Where would all the demo's get included? In the most relevant package, alert-aggregator in the tuscany-web package, xml-bigbank in tuscany-process, some in tuscany-all. If this is mainly about reducing the size of the download [snip] No, I want to provide people with packages that fit their scenarios, not cluttered with other things they don't need. -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Distribution zips and what they contain, was: SCA runtimes
Raymond Feng wrote: [snip] - tuscany-jee.zip - For JEE app integration EJB, RMI and JMS bindings, Spring components I think we should have WS binding in tuscany-jee.zip as WS is part of JEE. (Maybe -jee should be a superset of -web). JEE like other platforms supports Web Services but I didn't think that WS was "part of jee". The idea of tuscany-jee is to package the software I need to integrate JEE artifacts (EJBs etc.) in an SCA based solution. These packages are not exclusive. If I need to integrate JEE artifacts and WS in a solution I'll install both tuscany-jee and tuscany-web. - tuscany-process.zip - For process development BPEL and XQuery components - tuscany-all.zip - all of the above Are the BPEL/XQuery mature enough to have a separate tuscany-process.zip? Maybe the users could download tuscany-all.zip for now if they want to work with BEPL and XQuery. [snip] +1 -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Distribution zips and what they contain, was: SCA runtimes
On Jan 22, 2008 5:36 PM, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote: > Simon Nash wrote: > >> Jean-Sebastien Delfino wrote: > >> - What distro Zips are we building and what do they contain? just the > >> runtime? samples or not? dependencies or not? are we building > >> specialized distros for different use cases? > [snip] > > With a big topic like this, dividing it into separate threads makes it > > easier for people to follow and participate in the discussions. The > > split you are suggesting looks good to me. > [snip] > > I'd like to discuss the following: "What distro Zips are we building and > what do they contain?" > > I think we could improve our distro scheme to provide: > - smaller packages > - easier for people to find what they need > We do need to do something about the distribution but having multiple distro's doesn't actually make it easier to find what you need does it? It actually makes it harder as right now we have a single distro so its pretty easy to know where to look :) > I was thinking about the following binary distro zips: > > - tuscany-core.zip - The base that everybody needs. > core assembly model and runtime > Java APIs, Java components > > - tuscany-web.zip - For WS and Web developers > WS binding, Web 2.0 bindings, Scripting components, Widget components > > - tuscany-jee.zip - For JEE app integration > EJB, RMI and JMS bindings, Spring components > > - tuscany-process.zip - For process development > BPEL and XQuery components > > - tuscany-all.zip - all of the above > Would each distro include everthing it needs or is tuscany-core.zip a prereq? Where do all the different data bindings go? Doesn't one of the SCA specs say an SCA runtime MUST support binding.ws? Is interface.wsdl supported in the others or only with tuscany-web? Is the core distro really so useful with nothing except implementation.javaand no bindings Do all those distro's include everything to support both tomcat and Jetty standalone and webapps...and all the runtimes being discussed like Geronimo and Tomcat deep integration? Would any/all of those work with all the new domain/node stuff? And i think right now that requires things like the WS and JSON support? Where would all the demo's get included? If this is mainly about reducing the size of the download then as an alternative way of splitting things - what sort of size would be "ok" and using that number could we then add the most useful extensions until we get to that size and make the others optional downloads? ...ant
Re: Distribution zips and what they contain, was: SCA runtimes
Please see my comments inline. Thanks, Raymond - Original Message - From: "Jean-Sebastien Delfino" <[EMAIL PROTECTED]> To: Sent: Tuesday, January 22, 2008 9:36 AM Subject: Distribution zips and what they contain, was: SCA runtimes Simon Nash wrote: >> Jean-Sebastien Delfino wrote: - What distro Zips are we building and what do they contain? just the runtime? samples or not? dependencies or not? are we building specialized distros for different use cases? [snip] With a big topic like this, dividing it into separate threads makes it easier for people to follow and participate in the discussions. The split you are suggesting looks good to me. [snip] I'd like to discuss the following: "What distro Zips are we building and what do they contain?" I think we could improve our distro scheme to provide: - smaller packages - easier for people to find what they need I was thinking about the following binary distro zips: - tuscany-core.zip - The base that everybody needs. core assembly model and runtime Java APIs, Java components +1. - tuscany-web.zip - For WS and Web developers WS binding, Web 2.0 bindings, Scripting components, Widget components +1. - tuscany-jee.zip - For JEE app integration EJB, RMI and JMS bindings, Spring components I think we should have WS binding in tuscany-jee.zip as WS is part of JEE. (Maybe -jee should be a superset of -web). - tuscany-process.zip - For process development BPEL and XQuery components - tuscany-all.zip - all of the above Are the BPEL/XQuery mature enough to have a separate tuscany-process.zip? Maybe the users could download tuscany-all.zip for now if they want to work with BEPL and XQuery. Note that I'm not trying to tackle release cycles and the potential for releasing the above zips independently in this discussion and I'm assuming that we release all of the above together. +1 to keep the zips at the same level. I'm also assuming that the relevant samples are included in each zip. Thoughts? -- Jean-Sebastien - 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]
