Re: [DISCUSS] Next 2.0 Milestones - Assemblies and Certification - Do we need 8?
On Feb 12, 2007, at 4:11 PM, Dain Sundstrom wrote: For JPA it is easy there is a single string property that chooses the default provider if the user didn't specify one. True - that shouldn't be a big deal. BTW, I'm a very fickle user. OpenJPA is currently working for me, if Cayenne ends up working better, I'll switch. Currently, OpenJPA hangs the debugger on Mac, so when Cayenne is integrated into OpenEJB, I'll be trying it out. I am using the debugger on Mac all the time with Cayenne :-) ... Seriously though, it is hard for us to predict a date when we are 100% compatible, since this is all unpaid volunteer effort, and there is lots of "Cayenne-classic" work going on in parallel, but we are getting there. BTW I should be able to provide hooks to manually register JPA listeners very soon. Andrus
Re: [DISCUSS] Next 2.0 Milestones - Assemblies and Certification - Do we need 8?
On Feb 12, 2007, at 12:51 PM, Andrus Adamchik wrote: I am a Jetty and Cayenne user, so I'd like a "Jetty + ? + Cayenne" combo :-) So while I do not agree with the implication that an informal popularity poll can provide a meaningful selection of a default configuration (as this thread shows it will still be mostly arbitrary), I agree with the approach outlined by Matt - certify a minimal number of combinations (hopefully just 2) that spans all supported individual components. The actual certified combos shouldn't matter, as long as there is an easy way to activate preferred components from the uber tarball. For JPA it is easy there is a single string property that chooses the default provider if the user didn't specify one. BTW, I'm a very fickle user. OpenJPA is currently working for me, if Cayenne ends up working better, I'll switch. Currently, OpenJPA hangs the debugger on Mac, so when Cayenne is integrated into OpenEJB, I'll be trying it out. -dain
Re: [DISCUSS] Next 2.0 Milestones - Assemblies and Certification - Do we need 8?
I am a Jetty and Cayenne user, so I'd like a "Jetty + ? + Cayenne" combo :-) So while I do not agree with the implication that an informal popularity poll can provide a meaningful selection of a default configuration (as this thread shows it will still be mostly arbitrary), I agree with the approach outlined by Matt - certify a minimal number of combinations (hopefully just 2) that spans all supported individual components. The actual certified combos shouldn't matter, as long as there is an easy way to activate preferred components from the uber tarball. Andrus On Feb 11, 2007, at 1:07 PM, Dain Sundstrom wrote: On Feb 11, 2007, at 9:06 AM, Matt Hogstrom wrote: I would love to have a way where people can download the uber tar ball which includes all the bits we have at the time and let the user choose their server type and personality. I believe that a majority of our users are looking more for a server assembly that is a Java EE 5 server with the bits they need to develop Java EE applications (and or deploy them). What seems manageable to me is that we choose a finite set of Java EE 5 assemblies (no more than two based on Jetty and Tomcat given our history, that are certified. Dain made a comment and I've heard similar things that to be certified all modes of operation must be exercised and I think that someone might reasonably apply it to all the pieces of the uber server. Based on feedback I've gotten from users I know that I often hear Tomcat and OpenJPA as a combo they are interested in. As far as the web services piece I haven't really heard a strong preference one way or another. however, since that's not my strong suit that's not a good indication of anything. Do others have feedback in this area? For purposes of this discussion I'll throw out the following combos for discussion: Tomcat, CXF and OpenJPA Jetty, Axis 2 and Cayenne As a Jetty user, I'd like to see CXF and OpenJPA. If tomcat users want Axis2 and Cayenne that is cool with me. -dain
Re: [DISCUSS] Next 2.0 Milestones - Assemblies and Certification - Do we need 8?
A "Geronimo Runtime Configuration Tool" would be cool for those users that want to investigate what "personality" fits better their environment. It would also be cool if once you made your mind you could run some other command that would get rid of all the other components that are not required for that particular configuration. One of the options could be "JEE Certified", then maybe we should try to pick just one flavor for certification. With that we would have 3 distributions, not certified Little-G, JEE certified (just one), and the big brother/pick your own personality. Post release, we could have could have incremental certifications, if at all possible, for the additional "personalities" Having this kind of configuration/export tool would reduce footprint and facilitate porting to other boxes (i.e. faster QA for those custom servers, faster setup for test and prod envs.) Cheers! Hernan Jason Dillon wrote: How big would one assembly be if we include *everything* like jetty, tomcat, axis2, cxf, everything. Not turned on though... then just provide people with a way to switch between personalities from the command line, and make one of them as default, so that if the server starts to boot up with no personality (hehe), then it will apply the default to itself when bootstrapping? Its probably gonna make the assembly zip a wee bit larger, but we'd only have one of em... so build time would be much faster, and if people want to try out different bits they don't have to redownload all that other stuff... but also, everything we need to make a javaee server is already in the assembly zip, so don't have to worry about networking muck to get the right personality up and running. Thoughts? --jason On Feb 9, 2007, at 12:32 PM, Paul McMahan wrote: On 2/8/07, Jason Dillon <[EMAIL PROTECTED]> wrote: I'm definitely *NOT* in-favor of 8 assemblies. Ditto. Even if there was time and manpower to test every possible assembly then I still don't think the end user would be prepared to make an informed choice about which one to download. On Feb 8, 2007, at 6:37 AM, Matt Hogstrom wrote: > If there is a plugin option then I think the TCK discussion becomes > simpler. Anyway, for those more skilled in that art than I what > are the community thoughts on how to address our expanding set of > pluggable components? I think that presenting the user with lots of choices is a good thing if geronimo can : 1.) provide a TCK tested default assembly 2.) help users make informed decisions about changing the defaults 3.) make it easy to enact their decisions 4.) allow them to change their minds later With that in mind, I think the ideal scenario (from a user's perspective) would be to provide one fully tested JEE5 assembly from the download page and then make it easy to swap out components after installation using plugins. Components that have passed the TCK in any assembly can be marked as such in the plugin catalog, along with any other useful information about that component such as which JEE spec it implements, etc. Components that are mutually exclusive like cxf and axis2, jetty and tomcat, etc can provide metadata that will prompt the plugin system to uninstall the component that is being replaced. There are lots of details and what-ifs that would need to be worked out before this approach can be fully realized. But if there's consensus around it then the next release could at least take a step in the right direction. AFAIK most if not all of the necessary functionality and infrastructure are already in place. Best wishes, Paul
Re: [DISCUSS] Next 2.0 Milestones - Assemblies and Certification - Do we need 8?
On Feb 11, 2007, at 9:06 AM, Matt Hogstrom wrote: I would love to have a way where people can download the uber tar ball which includes all the bits we have at the time and let the user choose their server type and personality. I believe that a majority of our users are looking more for a server assembly that is a Java EE 5 server with the bits they need to develop Java EE applications (and or deploy them). What seems manageable to me is that we choose a finite set of Java EE 5 assemblies (no more than two based on Jetty and Tomcat given our history, that are certified. Dain made a comment and I've heard similar things that to be certified all modes of operation must be exercised and I think that someone might reasonably apply it to all the pieces of the uber server. Based on feedback I've gotten from users I know that I often hear Tomcat and OpenJPA as a combo they are interested in. As far as the web services piece I haven't really heard a strong preference one way or another. however, since that's not my strong suit that's not a good indication of anything. Do others have feedback in this area? For purposes of this discussion I'll throw out the following combos for discussion: Tomcat, CXF and OpenJPA Jetty, Axis 2 and Cayenne As a Jetty user, I'd like to see CXF and OpenJPA. If tomcat users want Axis2 and Cayenne that is cool with me. -dain
Re: [DISCUSS] Next 2.0 Milestones - Assemblies and Certification - Do we need 8?
I would love to have a way where people can download the uber tar ball which includes all the bits we have at the time and let the user choose their server type and personality. I believe that a majority of our users are looking more for a server assembly that is a Java EE 5 server with the bits they need to develop Java EE applications (and or deploy them). What seems manageable to me is that we choose a finite set of Java EE 5 assemblies (no more than two based on Jetty and Tomcat given our history, that are certified. Dain made a comment and I've heard similar things that to be certified all modes of operation must be exercised and I think that someone might reasonably apply it to all the pieces of the uber server. Based on feedback I've gotten from users I know that I often hear Tomcat and OpenJPA as a combo they are interested in. As far as the web services piece I haven't really heard a strong preference one way or another. however, since that's not my strong suit that's not a good indication of anything. Do others have feedback in this area? For purposes of this discussion I'll throw out the following combos for discussion: Tomcat, CXF and OpenJPA Jetty, Axis 2 and Cayenne The benefits are that it pretty much does cover all the major technologies in terms of fitting them together. Using DayTrader, we should be able to deploy DT unchanged (app or DDs) on both assemblies. The desire would be that we have a common abstraction point so that if someone wants to use Jetty, CXF and OpenJPA that it should be a simple matter of selecting the appropriate plugins. That said, I'd prefer to not try and provide the universal adapter that can configure everything in the world and lose site of delivering a Java EE 5 container for users to look at in time for Java One (my personal desire I'll admit). I'll defer to the guys actually working on TCK to tell us what they are planning on certifying as they are doing the bulk of the work. What makes sense to me is to have at least one that is certified (more is nice) and that we keep the train moving and offer additional certifications over time as interest and TCKing deliver. To make the proposal concrete our download page would have: *Java EE 5 Certified* Tomcat, CXF, OpenJPA Jetty, Axis2, Cayenne Windows and *nix versions. An uber (you can create your own personality would be awesome. On Feb 11, 2007, at 12:40 AM, Jason Dillon wrote: On Feb 10, 2007, at 9:25 PM, Paul McMahan wrote: I agree that this approach would avoid network dependency but I'm not as convinced that network access presents a problem. Most of the installers I've used lately depend on network access in one way or another. I also suspect that users will customize their server right after downloading it. Many installers I've seen allow for light version which rely on the network to fetch components, and have a complete version which includes all of the components. From an automation perspective it would be best not to add more network dependency, so that once we have a distro zip, we can assume that personality configuration will function with-out unexpected failures due to network issues. Besides a smaller download size, the plugin approach has the advantage that the CLI and admin console are already available for driving the server customization process. Should we invest additional effort in providing the user with another way to achieve effectively the same results? If so then will it be clear to users when to use the plugin installer vs. when to use this alternative mechanism? IMO, the personality bits are simply collections of plugins (perhaps a few non-plugin cars) to be applied to a base installation. I think the concept is complementary with what we have now. One other factor to consider is that the "one big assembly" approach would only deactivate components when they are replaced and not actually uninstall them (at least if I understand your proposal correctly). If the deactivated components were later reactivated from the admin console or from an environmental dependency then the server could enter an unusable state. Sure, that is a danger... though that danger exists today. I was not suggesting any specific implementation, but one solution would be to ship all of the extra components for personalities in a different repository dir, then the personality application tool would install from one repo to another. But, really, we probably need to create some mechanism to classify types of plugins, and then warn the user if they are attempting to enable/install a plugin which collides with another plugin already installed. For example, if there a Jetty plugin already installed, trying to install Tomcat would warn strongly that a duplicate "webcontainer" plugin was already installed (and let them install it if they know better than we do).
Re: [DISCUSS] Next 2.0 Milestones - Assemblies and Certification - Do we need 8?
On Feb 10, 2007, at 9:25 PM, Paul McMahan wrote: I agree that this approach would avoid network dependency but I'm not as convinced that network access presents a problem. Most of the installers I've used lately depend on network access in one way or another. I also suspect that users will customize their server right after downloading it. Many installers I've seen allow for light version which rely on the network to fetch components, and have a complete version which includes all of the components. From an automation perspective it would be best not to add more network dependency, so that once we have a distro zip, we can assume that personality configuration will function with-out unexpected failures due to network issues. Besides a smaller download size, the plugin approach has the advantage that the CLI and admin console are already available for driving the server customization process. Should we invest additional effort in providing the user with another way to achieve effectively the same results? If so then will it be clear to users when to use the plugin installer vs. when to use this alternative mechanism? IMO, the personality bits are simply collections of plugins (perhaps a few non-plugin cars) to be applied to a base installation. I think the concept is complementary with what we have now. One other factor to consider is that the "one big assembly" approach would only deactivate components when they are replaced and not actually uninstall them (at least if I understand your proposal correctly). If the deactivated components were later reactivated from the admin console or from an environmental dependency then the server could enter an unusable state. Sure, that is a danger... though that danger exists today. I was not suggesting any specific implementation, but one solution would be to ship all of the extra components for personalities in a different repository dir, then the personality application tool would install from one repo to another. But, really, we probably need to create some mechanism to classify types of plugins, and then warn the user if they are attempting to enable/install a plugin which collides with another plugin already installed. For example, if there a Jetty plugin already installed, trying to install Tomcat would warn strongly that a duplicate "webcontainer" plugin was already installed (and let them install it if they know better than we do). RPMs do something similar with its 'provides' tag in spec files... so for example, the apache httpd RPM package might provide 'webserver', fnord (another light http server) might also provide 'webserver' and when apache httpd is already installed, attempts to install fnord will barf with a conflict (which can be forced to override). --jason
Re: [DISCUSS] Next 2.0 Milestones - Assemblies and Certification - Do we need 8?
I agree that this approach would avoid network dependency but I'm not as convinced that network access presents a problem. Most of the installers I've used lately depend on network access in one way or another. I also suspect that users will customize their server right after downloading it. Besides a smaller download size, the plugin approach has the advantage that the CLI and admin console are already available for driving the server customization process. Should we invest additional effort in providing the user with another way to achieve effectively the same results? If so then will it be clear to users when to use the plugin installer vs. when to use this alternative mechanism? One other factor to consider is that the "one big assembly" approach would only deactivate components when they are replaced and not actually uninstall them (at least if I understand your proposal correctly). If the deactivated components were later reactivated from the admin console or from an environmental dependency then the server could enter an unusable state. Best wishes, Paul On 2/10/07, Jason Dillon <[EMAIL PROTECTED]> wrote: How big would one assembly be if we include *everything* like jetty, tomcat, axis2, cxf, everything. Not turned on though... then just provide people with a way to switch between personalities from the command line, and make one of them as default, so that if the server starts to boot up with no personality (hehe), then it will apply the default to itself when bootstrapping? Its probably gonna make the assembly zip a wee bit larger, but we'd only have one of em... so build time would be much faster, and if people want to try out different bits they don't have to redownload all that other stuff... but also, everything we need to make a javaee server is already in the assembly zip, so don't have to worry about networking muck to get the right personality up and running. Thoughts? --jason On Feb 9, 2007, at 12:32 PM, Paul McMahan wrote: > On 2/8/07, Jason Dillon <[EMAIL PROTECTED]> wrote: >> I'm definitely *NOT* in-favor of 8 assemblies. > > Ditto. Even if there was time and manpower to test every possible > assembly then I still don't think the end user would be prepared to > make an informed choice about which one to download. > >> On Feb 8, 2007, at 6:37 AM, Matt Hogstrom wrote: >> > If there is a plugin option then I think the TCK discussion becomes >> > simpler. Anyway, for those more skilled in that art than I what >> > are the community thoughts on how to address our expanding set of >> > pluggable components? > > I think that presenting the user with lots of choices is a good thing > if geronimo can : > 1.) provide a TCK tested default assembly > 2.) help users make informed decisions about changing the defaults > 3.) make it easy to enact their decisions > 4.) allow them to change their minds later > > With that in mind, I think the ideal scenario (from a user's > perspective) would be to provide one fully tested JEE5 assembly from > the download page and then make it easy to swap out components after > installation using plugins. Components that have passed the TCK in > any assembly can be marked as such in the plugin catalog, along with > any other useful information about that component such as which JEE > spec it implements, etc. Components that are mutually exclusive like > cxf and axis2, jetty and tomcat, etc can provide metadata that will > prompt the plugin system to uninstall the component that is being > replaced. > > There are lots of details and what-ifs that would need to be worked > out before this approach can be fully realized. But if there's > consensus around it then the next release could at least take a step > in the right direction. AFAIK most if not all of the necessary > functionality and infrastructure are already in place. > > Best wishes, > Paul
Re: [DISCUSS] Next 2.0 Milestones - Assemblies and Certification - Do we need 8?
On Feb 10, 2007, at 7:54 AM, Kevan Miller wrote: On Feb 10, 2007, at 3:55 AM, David Jencks wrote: I think this would be great, especially if we adapted the assembly stuff we have now so you could extract a server that had just what you wanted in it. Then we could supply just one download and let people simplify it themselves if they wanted to. I like it. The size delta would be a minor issue, IMO. I'd be in favor of this as a general approach. A few points: 1. I'd like to maintain two multi-personality distributions -- a minimal and Java EE distribution. Does minimal include a web-container? 2. IMO, the distributions must have a default configuration. Downloading and starting a server must be simple (i.e. no selection/ configuration is required). Yes, the server should check when bootstraping if it has been configured with a personality, if not, it will select the default and continue... so the user does not have to explicitly configure a personality. 3. I would not want this to be the cause of a significant delay in the 2.0 release Ya, hopefully not... else we can leave it for 2.1... I do think this is a good idea. --jason
Re: [DISCUSS] Next 2.0 Milestones - Assemblies and Certification - Do we need 8?
On Feb 10, 2007, at 8:40 PM, Matt Hogstrom wrote: On Feb 10, 2007, at 5:59 PM, Jason Dillon wrote: Aye... on each personality switch I would expect a big warning about "things might not work afterwards", just like any other brain surgery, there are going to be some risks. But if we had a simple way to switch, then we could probably help ensure that each component behaved well with the others. Unlike brain surgery though... hopefully if something does break, switching back to the previous personality would work. It would be pretty nice to be able to switch. I'm wondering how many people would be doing this though. It might be like trying to change your spark plugs while driving down the highway at 75 miles an hour :) I'd imagine that most people would just use it once to configure the personality of the server they wanted/needed. Sure, some would switch back and forth, but they would be in the minority I'd expect. Many would not care at all and would use the default personality which would get applied automatically the first time the server started. Switching between would probably be used mostly by automated tests to help ensure component interop. But... really, the point is to reduce assemblies and distributions which we build, but still allowing folks a choice of what components are actually getting used for their applications. --jason
Re: [DISCUSS] Next 2.0 Milestones - Assemblies and Certification - Do we need 8?
On Feb 10, 2007, at 5:59 PM, Jason Dillon wrote: Aye... on each personality switch I would expect a big warning about "things might not work afterwards", just like any other brain surgery, there are going to be some risks. But if we had a simple way to switch, then we could probably help ensure that each component behaved well with the others. Unlike brain surgery though... hopefully if something does break, switching back to the previous personality would work. It would be pretty nice to be able to switch. I'm wondering how many people would be doing this though. It might be like trying to change your spark plugs while driving down the highway at 75 miles an hour :) --jason
Re: [DISCUSS] Next 2.0 Milestones - Assemblies and Certification - Do we need 8?
Yup, one assembly to build, one download (er 2 I guess zip + tgz)... geronimo--bin.. --jason On Feb 10, 2007, at 12:55 AM, David Jencks wrote: I think this would be great, especially if we adapted the assembly stuff we have now so you could extract a server that had just what you wanted in it. Then we could supply just one download and let people simplify it themselves if they wanted to. thanks david jencks On Feb 9, 2007, at 11:09 PM, Jason Dillon wrote: How big would one assembly be if we include *everything* like jetty, tomcat, axis2, cxf, everything. Not turned on though... then just provide people with a way to switch between personalities from the command line, and make one of them as default, so that if the server starts to boot up with no personality (hehe), then it will apply the default to itself when bootstrapping? Its probably gonna make the assembly zip a wee bit larger, but we'd only have one of em... so build time would be much faster, and if people want to try out different bits they don't have to redownload all that other stuff... but also, everything we need to make a javaee server is already in the assembly zip, so don't have to worry about networking muck to get the right personality up and running. Thoughts? --jason On Feb 9, 2007, at 12:32 PM, Paul McMahan wrote: On 2/8/07, Jason Dillon <[EMAIL PROTECTED]> wrote: I'm definitely *NOT* in-favor of 8 assemblies. Ditto. Even if there was time and manpower to test every possible assembly then I still don't think the end user would be prepared to make an informed choice about which one to download. On Feb 8, 2007, at 6:37 AM, Matt Hogstrom wrote: > If there is a plugin option then I think the TCK discussion becomes > simpler. Anyway, for those more skilled in that art than I what > are the community thoughts on how to address our expanding set of > pluggable components? I think that presenting the user with lots of choices is a good thing if geronimo can : 1.) provide a TCK tested default assembly 2.) help users make informed decisions about changing the defaults 3.) make it easy to enact their decisions 4.) allow them to change their minds later With that in mind, I think the ideal scenario (from a user's perspective) would be to provide one fully tested JEE5 assembly from the download page and then make it easy to swap out components after installation using plugins. Components that have passed the TCK in any assembly can be marked as such in the plugin catalog, along with any other useful information about that component such as which JEE spec it implements, etc. Components that are mutually exclusive like cxf and axis2, jetty and tomcat, etc can provide metadata that will prompt the plugin system to uninstall the component that is being replaced. There are lots of details and what-ifs that would need to be worked out before this approach can be fully realized. But if there's consensus around it then the next release could at least take a step in the right direction. AFAIK most if not all of the necessary functionality and infrastructure are already in place. Best wishes, Paul
Re: [DISCUSS] Next 2.0 Milestones - Assemblies and Certification - Do we need 8?
On Feb 10, 2007, at 11:24 AM, Joe Bohn wrote: I like the idea but I wonder how practical it will be and if users could get themselves in trouble. For example, what would happen if a set of applications was deployed using tomcat & cxf and then the user attempted to switch to jetty & axis? Granted, with the plugin approach they could create similar problems but since it's a little more difficult to install/uninstall a plugin which might provide some more safeguards. Um... well, plugins should not be difficult to install... and neither should it be difficult to switch personalities. Both *should* be ridiculously simple. If something dangerous might happen, then issue a warning and get a confirm prompt from the user. But just because it might mess something up does not mean that we should not provide it as a feature. Hiding or omitting dangerous (or potentially dangerous) features from users is a very bad practice IMO. We can provide some safeguards (ie. confirm prompt), but we need to empower users to make those decisions, and well... if they muck it up, they muck it up. Not like installing a bunk CAR or poorly crafted plugin won't do the same thing now. I guess we could always keep track of the previous state and warn the user if they are attempting to change the configuration on a subsequent restart when applications are deployed that have been configured for the prior configuration. Aye... on each personality switch I would expect a big warning about "things might not work afterwards", just like any other brain surgery, there are going to be some risks. But if we had a simple way to switch, then we could probably help ensure that each component behaved well with the others. Unlike brain surgery though... hopefully if something does break, switching back to the previous personality would work. --jason
Re: [DISCUSS] Next 2.0 Milestones - Assemblies and Certification - Do we need 8?
On Feb 10, 2007, at 3:55 AM, David Jencks wrote: I think this would be great, especially if we adapted the assembly stuff we have now so you could extract a server that had just what you wanted in it. Then we could supply just one download and let people simplify it themselves if they wanted to. I like it. The size delta would be a minor issue, IMO. I'd be in favor of this as a general approach. A few points: 1. I'd like to maintain two multi-personality distributions -- a minimal and Java EE distribution. 2. IMO, the distributions must have a default configuration. Downloading and starting a server must be simple (i.e. no selection/ configuration is required). 3. I would not want this to be the cause of a significant delay in the 2.0 release --kevan
Re: [DISCUSS] Next 2.0 Milestones - Assemblies and Certification - Do we need 8?
Ya, I'm aware of this... but I hope that if I can get vmware instances running on 2 of our big gbuild.org hosts (which might give us 14 - 30) more agents, then we might be able to manage running all those tests in a reasonable amount of time. --jason On Feb 10, 2007, at 8:23 AM, Dain Sundstrom wrote: You would still have to test all combinations of the plugins. The TCJ says something to the effect of "all modes" must be tested and certified. -dain On Feb 9, 2007, at 11:09 PM, Jason Dillon wrote: How big would one assembly be if we include *everything* like jetty, tomcat, axis2, cxf, everything. Not turned on though... then just provide people with a way to switch between personalities from the command line, and make one of them as default, so that if the server starts to boot up with no personality (hehe), then it will apply the default to itself when bootstrapping? Its probably gonna make the assembly zip a wee bit larger, but we'd only have one of em... so build time would be much faster, and if people want to try out different bits they don't have to redownload all that other stuff... but also, everything we need to make a javaee server is already in the assembly zip, so don't have to worry about networking muck to get the right personality up and running. Thoughts? --jason On Feb 9, 2007, at 12:32 PM, Paul McMahan wrote: On 2/8/07, Jason Dillon <[EMAIL PROTECTED]> wrote: I'm definitely *NOT* in-favor of 8 assemblies. Ditto. Even if there was time and manpower to test every possible assembly then I still don't think the end user would be prepared to make an informed choice about which one to download. On Feb 8, 2007, at 6:37 AM, Matt Hogstrom wrote: > If there is a plugin option then I think the TCK discussion becomes > simpler. Anyway, for those more skilled in that art than I what > are the community thoughts on how to address our expanding set of > pluggable components? I think that presenting the user with lots of choices is a good thing if geronimo can : 1.) provide a TCK tested default assembly 2.) help users make informed decisions about changing the defaults 3.) make it easy to enact their decisions 4.) allow them to change their minds later With that in mind, I think the ideal scenario (from a user's perspective) would be to provide one fully tested JEE5 assembly from the download page and then make it easy to swap out components after installation using plugins. Components that have passed the TCK in any assembly can be marked as such in the plugin catalog, along with any other useful information about that component such as which JEE spec it implements, etc. Components that are mutually exclusive like cxf and axis2, jetty and tomcat, etc can provide metadata that will prompt the plugin system to uninstall the component that is being replaced. There are lots of details and what-ifs that would need to be worked out before this approach can be fully realized. But if there's consensus around it then the next release could at least take a step in the right direction. AFAIK most if not all of the necessary functionality and infrastructure are already in place. Best wishes, Paul
Re: [DISCUSS] Next 2.0 Milestones - Assemblies and Certification - Do we need 8?
I like the idea but I wonder how practical it will be and if users could get themselves in trouble. For example, what would happen if a set of applications was deployed using tomcat & cxf and then the user attempted to switch to jetty & axis? Granted, with the plugin approach they could create similar problems but since it's a little more difficult to install/uninstall a plugin which might provide some more safeguards. I guess we could always keep track of the previous state and warn the user if they are attempting to change the configuration on a subsequent restart when applications are deployed that have been configured for the prior configuration. Joe Jason Dillon wrote: How big would one assembly be if we include *everything* like jetty, tomcat, axis2, cxf, everything. Not turned on though... then just provide people with a way to switch between personalities from the command line, and make one of them as default, so that if the server starts to boot up with no personality (hehe), then it will apply the default to itself when bootstrapping? Its probably gonna make the assembly zip a wee bit larger, but we'd only have one of em... so build time would be much faster, and if people want to try out different bits they don't have to redownload all that other stuff... but also, everything we need to make a javaee server is already in the assembly zip, so don't have to worry about networking muck to get the right personality up and running. Thoughts? --jason On Feb 9, 2007, at 12:32 PM, Paul McMahan wrote: On 2/8/07, Jason Dillon <[EMAIL PROTECTED]> wrote: I'm definitely *NOT* in-favor of 8 assemblies. Ditto. Even if there was time and manpower to test every possible assembly then I still don't think the end user would be prepared to make an informed choice about which one to download. On Feb 8, 2007, at 6:37 AM, Matt Hogstrom wrote: > If there is a plugin option then I think the TCK discussion becomes > simpler. Anyway, for those more skilled in that art than I what > are the community thoughts on how to address our expanding set of > pluggable components? I think that presenting the user with lots of choices is a good thing if geronimo can : 1.) provide a TCK tested default assembly 2.) help users make informed decisions about changing the defaults 3.) make it easy to enact their decisions 4.) allow them to change their minds later With that in mind, I think the ideal scenario (from a user's perspective) would be to provide one fully tested JEE5 assembly from the download page and then make it easy to swap out components after installation using plugins. Components that have passed the TCK in any assembly can be marked as such in the plugin catalog, along with any other useful information about that component such as which JEE spec it implements, etc. Components that are mutually exclusive like cxf and axis2, jetty and tomcat, etc can provide metadata that will prompt the plugin system to uninstall the component that is being replaced. There are lots of details and what-ifs that would need to be worked out before this approach can be fully realized. But if there's consensus around it then the next release could at least take a step in the right direction. AFAIK most if not all of the necessary functionality and infrastructure are already in place. Best wishes, Paul
Re: [DISCUSS] Next 2.0 Milestones - Assemblies and Certification - Do we need 8?
You would still have to test all combinations of the plugins. The TCJ says something to the effect of "all modes" must be tested and certified. -dain On Feb 9, 2007, at 11:09 PM, Jason Dillon wrote: How big would one assembly be if we include *everything* like jetty, tomcat, axis2, cxf, everything. Not turned on though... then just provide people with a way to switch between personalities from the command line, and make one of them as default, so that if the server starts to boot up with no personality (hehe), then it will apply the default to itself when bootstrapping? Its probably gonna make the assembly zip a wee bit larger, but we'd only have one of em... so build time would be much faster, and if people want to try out different bits they don't have to redownload all that other stuff... but also, everything we need to make a javaee server is already in the assembly zip, so don't have to worry about networking muck to get the right personality up and running. Thoughts? --jason On Feb 9, 2007, at 12:32 PM, Paul McMahan wrote: On 2/8/07, Jason Dillon <[EMAIL PROTECTED]> wrote: I'm definitely *NOT* in-favor of 8 assemblies. Ditto. Even if there was time and manpower to test every possible assembly then I still don't think the end user would be prepared to make an informed choice about which one to download. On Feb 8, 2007, at 6:37 AM, Matt Hogstrom wrote: > If there is a plugin option then I think the TCK discussion becomes > simpler. Anyway, for those more skilled in that art than I what > are the community thoughts on how to address our expanding set of > pluggable components? I think that presenting the user with lots of choices is a good thing if geronimo can : 1.) provide a TCK tested default assembly 2.) help users make informed decisions about changing the defaults 3.) make it easy to enact their decisions 4.) allow them to change their minds later With that in mind, I think the ideal scenario (from a user's perspective) would be to provide one fully tested JEE5 assembly from the download page and then make it easy to swap out components after installation using plugins. Components that have passed the TCK in any assembly can be marked as such in the plugin catalog, along with any other useful information about that component such as which JEE spec it implements, etc. Components that are mutually exclusive like cxf and axis2, jetty and tomcat, etc can provide metadata that will prompt the plugin system to uninstall the component that is being replaced. There are lots of details and what-ifs that would need to be worked out before this approach can be fully realized. But if there's consensus around it then the next release could at least take a step in the right direction. AFAIK most if not all of the necessary functionality and infrastructure are already in place. Best wishes, Paul
Re: [DISCUSS] Next 2.0 Milestones - Assemblies and Certification - Do we need 8?
I think this would be great, especially if we adapted the assembly stuff we have now so you could extract a server that had just what you wanted in it. Then we could supply just one download and let people simplify it themselves if they wanted to. thanks david jencks On Feb 9, 2007, at 11:09 PM, Jason Dillon wrote: How big would one assembly be if we include *everything* like jetty, tomcat, axis2, cxf, everything. Not turned on though... then just provide people with a way to switch between personalities from the command line, and make one of them as default, so that if the server starts to boot up with no personality (hehe), then it will apply the default to itself when bootstrapping? Its probably gonna make the assembly zip a wee bit larger, but we'd only have one of em... so build time would be much faster, and if people want to try out different bits they don't have to redownload all that other stuff... but also, everything we need to make a javaee server is already in the assembly zip, so don't have to worry about networking muck to get the right personality up and running. Thoughts? --jason On Feb 9, 2007, at 12:32 PM, Paul McMahan wrote: On 2/8/07, Jason Dillon <[EMAIL PROTECTED]> wrote: I'm definitely *NOT* in-favor of 8 assemblies. Ditto. Even if there was time and manpower to test every possible assembly then I still don't think the end user would be prepared to make an informed choice about which one to download. On Feb 8, 2007, at 6:37 AM, Matt Hogstrom wrote: > If there is a plugin option then I think the TCK discussion becomes > simpler. Anyway, for those more skilled in that art than I what > are the community thoughts on how to address our expanding set of > pluggable components? I think that presenting the user with lots of choices is a good thing if geronimo can : 1.) provide a TCK tested default assembly 2.) help users make informed decisions about changing the defaults 3.) make it easy to enact their decisions 4.) allow them to change their minds later With that in mind, I think the ideal scenario (from a user's perspective) would be to provide one fully tested JEE5 assembly from the download page and then make it easy to swap out components after installation using plugins. Components that have passed the TCK in any assembly can be marked as such in the plugin catalog, along with any other useful information about that component such as which JEE spec it implements, etc. Components that are mutually exclusive like cxf and axis2, jetty and tomcat, etc can provide metadata that will prompt the plugin system to uninstall the component that is being replaced. There are lots of details and what-ifs that would need to be worked out before this approach can be fully realized. But if there's consensus around it then the next release could at least take a step in the right direction. AFAIK most if not all of the necessary functionality and infrastructure are already in place. Best wishes, Paul
Re: [DISCUSS] Next 2.0 Milestones - Assemblies and Certification - Do we need 8?
How big would one assembly be if we include *everything* like jetty, tomcat, axis2, cxf, everything. Not turned on though... then just provide people with a way to switch between personalities from the command line, and make one of them as default, so that if the server starts to boot up with no personality (hehe), then it will apply the default to itself when bootstrapping? Its probably gonna make the assembly zip a wee bit larger, but we'd only have one of em... so build time would be much faster, and if people want to try out different bits they don't have to redownload all that other stuff... but also, everything we need to make a javaee server is already in the assembly zip, so don't have to worry about networking muck to get the right personality up and running. Thoughts? --jason On Feb 9, 2007, at 12:32 PM, Paul McMahan wrote: On 2/8/07, Jason Dillon <[EMAIL PROTECTED]> wrote: I'm definitely *NOT* in-favor of 8 assemblies. Ditto. Even if there was time and manpower to test every possible assembly then I still don't think the end user would be prepared to make an informed choice about which one to download. On Feb 8, 2007, at 6:37 AM, Matt Hogstrom wrote: > If there is a plugin option then I think the TCK discussion becomes > simpler. Anyway, for those more skilled in that art than I what > are the community thoughts on how to address our expanding set of > pluggable components? I think that presenting the user with lots of choices is a good thing if geronimo can : 1.) provide a TCK tested default assembly 2.) help users make informed decisions about changing the defaults 3.) make it easy to enact their decisions 4.) allow them to change their minds later With that in mind, I think the ideal scenario (from a user's perspective) would be to provide one fully tested JEE5 assembly from the download page and then make it easy to swap out components after installation using plugins. Components that have passed the TCK in any assembly can be marked as such in the plugin catalog, along with any other useful information about that component such as which JEE spec it implements, etc. Components that are mutually exclusive like cxf and axis2, jetty and tomcat, etc can provide metadata that will prompt the plugin system to uninstall the component that is being replaced. There are lots of details and what-ifs that would need to be worked out before this approach can be fully realized. But if there's consensus around it then the next release could at least take a step in the right direction. AFAIK most if not all of the necessary functionality and infrastructure are already in place. Best wishes, Paul
Re: [DISCUSS] Next 2.0 Milestones - Assemblies and Certification - Do we need 8?
On 2/8/07, Jason Dillon <[EMAIL PROTECTED]> wrote: I'm definitely *NOT* in-favor of 8 assemblies. Ditto. Even if there was time and manpower to test every possible assembly then I still don't think the end user would be prepared to make an informed choice about which one to download. On Feb 8, 2007, at 6:37 AM, Matt Hogstrom wrote: > If there is a plugin option then I think the TCK discussion becomes > simpler. Anyway, for those more skilled in that art than I what > are the community thoughts on how to address our expanding set of > pluggable components? I think that presenting the user with lots of choices is a good thing if geronimo can : 1.) provide a TCK tested default assembly 2.) help users make informed decisions about changing the defaults 3.) make it easy to enact their decisions 4.) allow them to change their minds later With that in mind, I think the ideal scenario (from a user's perspective) would be to provide one fully tested JEE5 assembly from the download page and then make it easy to swap out components after installation using plugins. Components that have passed the TCK in any assembly can be marked as such in the plugin catalog, along with any other useful information about that component such as which JEE spec it implements, etc. Components that are mutually exclusive like cxf and axis2, jetty and tomcat, etc can provide metadata that will prompt the plugin system to uninstall the component that is being replaced. There are lots of details and what-ifs that would need to be worked out before this approach can be fully realized. But if there's consensus around it then the next release could at least take a step in the right direction. AFAIK most if not all of the necessary functionality and infrastructure are already in place. Best wishes, Paul
Re: [DISCUSS] Next 2.0 Milestones - Assemblies and Certification - Do we need 8?
I'm definitely *NOT* in-favor of 8 assemblies. I also believe that we should use the TCK results from our automated builds, not those which happen to pass on certain developer machines. Many issues come up due to varying environments, so tests that pass on your machine, might not pass on mine depending on how things are setup. I've tried to get our harness to remove some of these, but due to the nature of how the TCK works... and how people run them (ie. re-using previously expanded sun dists, which may alter future runs). Also, its hard to say exactly which build of the server or cts server which these users are actually testing against, which is more reason why I would like to leave this matter to the automated system which we know what was used for what build and what was tested, and can re-run tests on the same build to verify that there are no transient/race-condition problems. As for plugins... I'm not sure that really changes things all that much from actually running the tests... though I think its much better from a build perspective. If we did say have one assembly zip, and then some scripts to bootstrap plugins, then from a TCK perspective we'd still have to have N full flights to verify that each permutation passes. So the problem is the same using plugins or pre-built assemblies. The only difference is that with plugins we have to add a pre-test step which will run the proper plugin bootstrap bits to get the right components in the server. If you need more details on the TCK specifics I can give them on the TCK list... --jason On Feb 8, 2007, at 6:37 AM, Matt Hogstrom wrote: I know everyone is working feverishly on 2.0 so I'll make this brief. There are a few things that we need to discuss as the train keeps moving. First, I'm working on DayTrader 2.0 this week to get the beast deployed on 2.0. Basically the initial goal is to deploy what we had working for 1.2-beta and 2.0-M1 which I think will be a fair but not exhaustive test for the converter. Next, regarding assemblies. Right now we've been producing two assemblies which are the traditional Tomcat and Jetty assemblies with CXF as the web-services component and OpenJPA as the EJB persistence option. I think we all agree that certifying 8 different assemblies is not workable as getting two done generally is a herculean task. That said, I think we want to make sure that projects that want to be part of a certified version have the option to make that happen. Since those that are doing the work tend to define what gets in and what ships it seems reasonable to me that the folks doing TCK can choose a configuration that they are interested in testing. There are no limits to the number of people that can TCK a release so the sky is the limit. For the JPA folks and WebServices folks I wanted to get a feel what your thoughts are on this topic. Part of the discussion is how easy is it to include one component versus another and I'll be the first to admit I'm not really well versed with WebServices to have an opinion on integration options. It seems that JPA is fairly simple in terms of plugging in a persistence provider and the user selecting the one they want. Dain had mentioned on an earlier e- mail about having a similar plug point for WS and I don't think there was a lot of discussion at the time. Given where we are at now what are folks thoughts on a plugin option for WebServices? If there is a plugin option then I think the TCK discussion becomes simpler. Anyway, for those more skilled in that art than I what are the community thoughts on how to address our expanding set of pluggable components? I'd like to have the discussion in this thread and if we need to put a vote together to provide a direction we can do that later. Thanks Matt
