Re: Custom Assembly, Micro-G, Flexible Server, choose your favorite name
Still not sold on #4 (server toolkit), given all the plugins should be published to the maven snapshot or release repos. I could see providing the framework assembly from our distribution website with docs and samples of how to use it or c-m-p to create custom server or application centric assemblies. If we created a repository assembly, then I could see that as being a separate download that could be used for local builds, but using the hosted maven repos would still be the preferred solution. I think we need to decide in the next couple weeks how much of this we want to achieve for 2.2, given B,E,F will require restructuring the source tree and fixing some interdependencies, like - 1) framework assembly can be built from plugins and not have to include a separate boilerplate jarfile as today. The Framework assembly should be able to start and provide a cmdline for installing other plugins to create a web or full jee5 runtime from the maven repos (or a local dir if supplied) 2) restructuring depends under the current minimal-assembly to not include all of the JEE5 specs and yoko files. The specs should only be installed by the plugins that need them and yoko should only be pulled in when needed. 3) can we decouple openejb and axis/cxf support so you can have one w/o the other? believe we have some deployer/builder cross depends in this area today. -Donald Joe Bohn wrote: We've had a lot of discussions about user capabilities to build custom assemblies in the past (see the links at [1], [2], [3] and [4] below) and it seems we're launching into another one again. This most recent discussion started when Lin was considering ways to improve the assemble a server portlet. This discussion has now moved beyond just the console to bigger ideas (as it must since the portlet is exposing some core feature we want in Geronimo). I thought it might make sense to pause and reflect on ideas expressed in the past to see if they have some bearing on where we go next. To that end, I've included links to the old discussions as a way to help bridge the gaps, explain how we got to where we are, and communicate where we thought we wanted to end up. We obviously haven't gotten to the end game yet, but I think we're getting closer. Plugins are beginning to be more appreciated by our users and the vision is starting to catch on ... so perhaps we're at a point where we can finally achieve some of the more lofty goals (or make new ones). Some of the original discussions were perhaps best summarized by Matt in [5] which was part of thread [2]. Matt has a great summary of the types of users and their goals in that note. references: [1] http://www.nabble.com/Micro-G-td6490485s134.html#a6490485 [2] http://www.nabble.com/micro-G-modules(configs)-td6669533s134.html [3] http://www.nabble.com/-DISCUSS--to-plugin-or-not-to-plugin%2C-that-is-the-question-td12410749s134.html [4] http://www.nabble.com/Re%3A-svn-commit%3A-r568632geronimo-server-trunk-assemblies-geronimo-framework-pom.xml-td12276842s134.html [5] http://www.nabble.com/Re%3A-micro-G-modules%28configs%29-p6721792s134.html My take on all of this: For Geronimo I think this translates into these goals: 1) Provide users with the ability to generate assemblies that include only what they want (including user created plugins). The process should be repeatable across future Geronimo releases with consistent results. 2) Continue to provide users with assemblies that match what we certify for completeness. 3) Provide some "out of the box" definitions of features that can be leveraged as complete solutions or modified to create new solutions. Such "features" might include the function currently represented in little-G and therefore could eliminate the need to ship little-G assemblies. 4) Provide an easy to use toolkit to make all of this possible. 5) If possible, reduce the number of assemblies that we currently provide. To accomplish these goals I think we need the following functions in Geronimo: A) The capability to generate any assembly starting from a default core assembly. B) A core framework assembly that can act as the foundation for building any more complex assembly. C) A plugin catalog where the actual plugins to be used in the assembly process will reside. This could be either shipped with an installation kit or made available via remote repositories. It would not be the only collection of plugins but would minimally contain all of the plugins used to make our certified assemblies. D) A mechanism to group sets of plugins together into logical functions that make sense at a user level. E) A mechanism to further group these logical functions together into possible assemblies. F) A command line or batch mechanism to consume definitions of plugins, groupings of plugins, and possible assemblies to produce the actual assembly. If thi
Custom Assembly, Micro-G, Flexible Server, choose your favorite name
We've had a lot of discussions about user capabilities to build custom assemblies in the past (see the links at [1], [2], [3] and [4] below) and it seems we're launching into another one again. This most recent discussion started when Lin was considering ways to improve the assemble a server portlet. This discussion has now moved beyond just the console to bigger ideas (as it must since the portlet is exposing some core feature we want in Geronimo). I thought it might make sense to pause and reflect on ideas expressed in the past to see if they have some bearing on where we go next. To that end, I've included links to the old discussions as a way to help bridge the gaps, explain how we got to where we are, and communicate where we thought we wanted to end up. We obviously haven't gotten to the end game yet, but I think we're getting closer. Plugins are beginning to be more appreciated by our users and the vision is starting to catch on ... so perhaps we're at a point where we can finally achieve some of the more lofty goals (or make new ones). Some of the original discussions were perhaps best summarized by Matt in [5] which was part of thread [2]. Matt has a great summary of the types of users and their goals in that note. references: [1] http://www.nabble.com/Micro-G-td6490485s134.html#a6490485 [2] http://www.nabble.com/micro-G-modules(configs)-td6669533s134.html [3] http://www.nabble.com/-DISCUSS--to-plugin-or-not-to-plugin%2C-that-is-the-question-td12410749s134.html [4] http://www.nabble.com/Re%3A-svn-commit%3A-r568632geronimo-server-trunk-assemblies-geronimo-framework-pom.xml-td12276842s134.html [5] http://www.nabble.com/Re%3A-micro-G-modules%28configs%29-p6721792s134.html My take on all of this: For Geronimo I think this translates into these goals: 1) Provide users with the ability to generate assemblies that include only what they want (including user created plugins). The process should be repeatable across future Geronimo releases with consistent results. 2) Continue to provide users with assemblies that match what we certify for completeness. 3) Provide some "out of the box" definitions of features that can be leveraged as complete solutions or modified to create new solutions. Such "features" might include the function currently represented in little-G and therefore could eliminate the need to ship little-G assemblies. 4) Provide an easy to use toolkit to make all of this possible. 5) If possible, reduce the number of assemblies that we currently provide. To accomplish these goals I think we need the following functions in Geronimo: A) The capability to generate any assembly starting from a default core assembly. B) A core framework assembly that can act as the foundation for building any more complex assembly. C) A plugin catalog where the actual plugins to be used in the assembly process will reside. This could be either shipped with an installation kit or made available via remote repositories. It would not be the only collection of plugins but would minimally contain all of the plugins used to make our certified assemblies. D) A mechanism to group sets of plugins together into logical functions that make sense at a user level. E) A mechanism to further group these logical functions together into possible assemblies. F) A command line or batch mechanism to consume definitions of plugins, groupings of plugins, and possible assemblies to produce the actual assembly. If this capability remains integrated with the server it should be possible to run this from our smallest server assembly, framework. Given that our administration console is our primary admin vehicle in the full javaee5 assembly we should provide equivalent (and hopefully more user friendly) function there. Items B-F would most likely compose a server assembly kit that could be one possible deliverable from Geronimo. So, we might end up delivering just the certified javaee5 assemblies and the server assembly toolkit to cover all other cases. Joe
Re: micro-g vs. geronimo framework
I'd say call it minimal and just leave "little-g" as a nickname, since I think folks like to call it little-g, but technically it is minimal, or lite really :-P --jason On Mar 6, 2008, at 5:27 AM, Hernan Cunico wrote: Agreed, the only thing is that we've been calling it Little-G for quite some time now. Would it be too bad to call the assembly that way? Lets face it, Little-G sounds a lot cooler that geronimo-minimal. Another thing in favor of keeping Little-G name is that "minimal" would not be as representative anymore since the Geronimo framework would actually the "new" minimal. Cheers! Hernan Joe Bohn wrote: Hernan Cunico wrote: I saw several times the term micro-g as well as geronimo framework (or just framework) used indifferently as synonymous. I'm trying to standardize the term in the docs and would help a lot if we agree to call it the same way. If no one oppose I'll propose we stick to "Geronimo framework" as it also matches the assembly name. Cheers! Hernan If we're going to do that (I think it's probably a good idea) ... then should we also consider using the term "minimal" consistently instead of little-G? Joe
Re: micro-g vs. geronimo framework
Agreed, the only thing is that we've been calling it Little-G for quite some time now. Would it be too bad to call the assembly that way? Lets face it, Little-G sounds a lot cooler that geronimo-minimal. Another thing in favor of keeping Little-G name is that "minimal" would not be as representative anymore since the Geronimo framework would actually the "new" minimal. Cheers! Hernan Joe Bohn wrote: Hernan Cunico wrote: I saw several times the term micro-g as well as geronimo framework (or just framework) used indifferently as synonymous. I'm trying to standardize the term in the docs and would help a lot if we agree to call it the same way. If no one oppose I'll propose we stick to "Geronimo framework" as it also matches the assembly name. Cheers! Hernan If we're going to do that (I think it's probably a good idea) ... then should we also consider using the term "minimal" consistently instead of little-G? Joe
Re: micro-g vs. geronimo framework
Hernan Cunico wrote: I saw several times the term micro-g as well as geronimo framework (or just framework) used indifferently as synonymous. I'm trying to standardize the term in the docs and would help a lot if we agree to call it the same way. If no one oppose I'll propose we stick to "Geronimo framework" as it also matches the assembly name. Cheers! Hernan If we're going to do that (I think it's probably a good idea) ... then should we also consider using the term "minimal" consistently instead of little-G? Joe
micro-g vs. geronimo framework
I saw several times the term micro-g as well as geronimo framework (or just framework) used indifferently as synonymous. I'm trying to standardize the term in the docs and would help a lot if we agree to call it the same way. If no one oppose I'll propose we stick to "Geronimo framework" as it also matches the assembly name. Cheers! Hernan
Re: micro-G modules(configs)
On 10/9/06, Matt Hogstrom <[EMAIL PROTECTED]> wrote: Anyway, should I put these ideas on the cwiki for discussion / clarification? It sounds that this is the general direction we're headed in and is rather unique. If we agree in concept it would be good to get our web page updated to reflect these goals (vision) of the project so people can see where we're going and get involved if they're interested. Sure. Why not!? It's been a while since I marked the thread to read when the time permits and I must admit I like the concept of templating. I'm not sure how it's different from config.xml where you declare your deps, but it's worth to give it a thought again and sort it out. Or wait, do you want the templating tool to download (from a local or remote repo) necessary modules and create an assembly? Isn't it what car-maven-plugin and maven-assembly-plugin together are doing now? It's definitely worth to put the idea on the wiki. Even if it dies at some time (which I doubt) we can move to it later or wipe it out. Jacek -- Jacek Laskowski http://www.laskowski.net.pl
Re: micro-G modules(configs)
On Oct 9, 2006, at 12:55 PM, Aaron Mulder wrote: On 10/5/06, David Jencks <[EMAIL PROTECTED]> wrote: Online-deployer is empty just like the rest of the configs that are servers. It relies on manifest classpath and the configuration it contains. IIRC online-deployer.car is the same file as deployer.jar. I guess you're right that a little more might be good. I was figuring that being able to add plugins might be enough. What connects to the plugin installer? Ah, OK. We need the command-line deploy tool (which I gather means online-deployer as well as j2ee-security, and perhaps per Joe's comment j2ee-deployer). The actual plugin installer is located in the system module which I think is in rmi-naming, and IIRC the deploy tool just uses the remote Kernel proxy thingy to talk to the plugin installer, but I'd have to look to be sure. It may be that j2ee-deployer is not required in order to use the search-plugins and install-plugins commands but would be required in order to use the other commands. But it may also be that JSR-88 isn't in the class path without e.g. j2ee-deployer and therefore the classes used by the deploy tool couldn't be located and it would die. If that's the case, we may just be able to shift some of the JAR dependencies around to avoid needing the full j2ee-deployer... We _really_ shouldn't need to start j2ee-deployer in order to do any of this. If there really are problems and the solutions aren't obvious please start opening jiras for them. thanks david jencks Thanks, Aaron
Re: micro-G modules(configs)
On 10/5/06, David Jencks <[EMAIL PROTECTED]> wrote: Online-deployer is empty just like the rest of the configs that are servers. It relies on manifest classpath and the configuration it contains. IIRC online-deployer.car is the same file as deployer.jar. I guess you're right that a little more might be good. I was figuring that being able to add plugins might be enough. What connects to the plugin installer? Ah, OK. We need the command-line deploy tool (which I gather means online-deployer as well as j2ee-security, and perhaps per Joe's comment j2ee-deployer). The actual plugin installer is located in the system module which I think is in rmi-naming, and IIRC the deploy tool just uses the remote Kernel proxy thingy to talk to the plugin installer, but I'd have to look to be sure. It may be that j2ee-deployer is not required in order to use the search-plugins and install-plugins commands but would be required in order to use the other commands. But it may also be that JSR-88 isn't in the class path without e.g. j2ee-deployer and therefore the classes used by the deploy tool couldn't be located and it would die. If that's the case, we may just be able to shift some of the JAR dependencies around to avoid needing the full j2ee-deployer... Thanks, Aaron
Re: micro-G modules(configs)
On Oct 6, 2006, at 10:37 AM, Joe Bohn wrote: I couldn't quite decide what to call it either which is why I'm using the term "geronimo-framework" for the assembly. But I'm certainly open to other opinions. I don't envision this being something that the casual user would pick up directly. I image that we would still ship the full j2ee assembly and possibly even the minimal assembly. Micro-G would be available for more sophisticated users that wanted to build a custom image and for vendors who might pick up Micro-G, build their own custom image, and then add their own software for redistribution/sale. Framework makes sense as I think that is where people wanted to go with Geronimo based on my recollection from many e-mails and conversations. I'll pop in my 2c here given Joe's comments above. What makes sense in my twisted mind is that Micro-G provides the core wiring framework to build a server (as joe indicated). From that we install plugins to assemble a server. The question then becomes how would a user consume this? and perhaps we need to define the groups of users that Geronimo would appeal to. Here is my quick hit list: J2EE developers - these folks are interested in a server that they can use to develop and deploy J2EE applications. They are not really concerned about the plumbing of the server but are more interested in consuming ready made things like Eclipse, Geronimo, etc. to build an application. Application Developer - May not want all the gizmos of J2EE / JEE but is definitely interested in things like Servlets and Spring. They would like a server that is sized for their needs and includes the components they need for their applications to run. People that use Tomcat + other stuff fall into this category. System Developers - these folks are more in tune with the server and its various pieces. They might be interested in the Geronimo Tx Manager or other piece parts of the server. They are willing to write GBeans and other Geronimo specific artifacts to accomplish their goals. They probably want the ability to create custom server configurations. ISV's - Pretty much the same as System Developers but might have targetted deployment environments like Kiosks or embedded devices. They want to build and distribute Applications and will use Geronimo as their core runtime infrastructure. They are probably more interested in stability than innovation as their distributing applications. There are probably lots more user types but I think the above covers the spectrum pretty broadly. With that said, how do we meet their needs? If I were in their shoes I would like to be able download either pre- built server configurations (J2EE certified) or build a custom assembly. In order to allow both I wonder if it makes sense to introduce the concept of server templates. Here is what I mean: Since every assembly we make now is hand turned we could make the configuration simpler so a user could express their intended server configuration through an XML file and we provide a generic assembler that would read this template, resolve dependencies and spit out a binary server config that could be distributed (downloaded as a server). The template would allow for command line building of the server such that a user would not need to interactively build it (GShell ?) This means that there would be a distribution of Geronimo that included micro-G along with all the gorp we normally build. The gorp would be in a repository format (like plugins or the same) so that a user could use templates to build a server without being network connected if they so chose). So we would make the following available for distribution: Geronimo J(2)EE certified (1.4 / 5.0, etc.) Tomcat / Jetty Minimal Tomcat / Jetty Micro-G (all components to build yur own custom server). So in effect, the J(2)EE and Minimal servers would simply be templates that happen to build server assemblies. Of these, the Geronimo team certifies the J2EE one. Anyway, should I put these ideas on the cwiki for discussion / clarification? It sounds that this is the general direction we're headed in and is rather unique. If we agree in concept it would be good to get our web page updated to reflect these goals (vision) of the project so people can see where we're going and get involved if they're interested. thoughts? The thinking above is really a comglomeration of lots of discussion on the list. Matt Hogstrom [EMAIL PROTECTED]
Re: micro-G modules(configs)
Jacek Laskowski wrote: On 10/5/06, Joe Bohn <[EMAIL PROTECTED]> wrote: The following modules are currently included in micro-G. What of these should we attempt to remove yet from micro-G? Where are we heading with Micro-G? Do we want to strip off all modules, but those that let us download plugins and enhance the server? That's my goal. Just enough of the Geronimo framework to be able to deploy plugins. It's not a kernel and neither is it a server. Should we call it a container? A plugin container? Will it end up as a OSGi-like container that understand GBean-based bundles? Some more help required or my brain will melt down. I couldn't quite decide what to call it either which is why I'm using the term "geronimo-framework" for the assembly. But I'm certainly open to other opinions. I don't envision this being something that the casual user would pick up directly. I image that we would still ship the full j2ee assembly and possibly even the minimal assembly. Micro-G would be available for more sophisticated users that wanted to build a custom image and for vendors who might pick up Micro-G, build their own custom image, and then add their own software for redistribution/sale. Jacek
Re: micro-G modules(configs)
On 10/5/06, Joe Bohn <[EMAIL PROTECTED]> wrote: The following modules are currently included in micro-G. What of these should we attempt to remove yet from micro-G? Where are we heading with Micro-G? Do we want to strip off all modules, but those that let us download plugins and enhance the server? It's not a kernel and neither is it a server. Should we call it a container? A plugin container? Will it end up as a OSGi-like container that understand GBean-based bundles? Some more help required or my brain will melt down. Jacek -- Jacek Laskowski http://www.laskowski.net.pl
Re: micro-G modules(configs)
Yes, we need to keep enough to be able to run the command line deployer. When I pulled j2ee-deployer I was unable to run the command line deploy. more comments/questions below David Jencks wrote: On Oct 5, 2006, at 3:52 PM, Aaron Mulder wrote: I think we need to keep enough in there that the command-line deploy tool still works. It looks like online-deployer is empty (or else I would have said to keep that), but I think j2ee-security is required for the JMX remoting used by the deploy tool. Without this, I think you'll have to mangle the repository contents and config.xml by hand in order to ever have more than "Micro G" (ick). Anyway, I would also be in favor of separating the specs from RMI naming. So let me see if I understand the idea here. I can pull the spec dependencies from RMI naming and create a new config with just those dependencies. I suspect that I will need to make rmi-naming dependent on the new spec config but then I think that limits the ability to easily switch between 1.4 and 1.5 specs. Are the specs not really required for rmi-naming and currently included just as a way to get the specs in the image? Thanks, Aaron P.S. Maybe we should whack the online-deployer module and rename "j2ee-security" to just "security" or something. Online-deployer is empty just like the rest of the configs that are servers. It relies on manifest classpath and the configuration it contains. IIRC online-deployer.car is the same file as deployer.jar. I was under the impression that this was required for the command line deploy as well but I'll pull it and see what happens. I guess you're right that a little more might be good. I was figuring that being able to add plugins might be enough. What connects to the plugin installer? thanks david jencks On 10/5/06, David Jencks <[EMAIL PROTECTED]> wrote: I marked the ones to remove IMO with an X I seem to have a more extreme view of "micro" than you :-) I'm all for getting micro-G as small as possible so long as we can grow it easily. I guess if the dependencies are all correct (which is not the case right now) then installing the higher level plugins should pull everything else along for the ride. I'd also prefer to pull the specs out of rmi-naming into a separate config so we can swap in the jee5 ones more easily. thanks david jencks On Oct 5, 2006, at 2:59 PM, Joe Bohn wrote: > > The following modules are currently included in micro-G. > What of these should we attempt to remove yet from micro-G? > > X connector-deployer OK, I'll attempt to pull this one. > geronimo-gbean-deployer > X hot-deployer I'll pull this one too. > X j2ee-deployer So I assume that we really need to keep this for plugin deployment unless we rework that code some more. > X j2ee-security If this isn't really j2ee specific then I can rename it but based upon Aaron's comments it looks like this is still required in micro-G. > X j2ee-server Is it true j2ee-server can be removed? I was under the impress that this was necessary for some of the management capabilities. > j2ee-system > X online-deployer Is this not necessary for command-line deployement as well? > rmi-naming > X sharedlib Isn't sharelib of value even without the web containers? I didn't think there was a lot of value in removing this but it's an easy one to pull. > shutdown > X transaction I can look at removing this as well but I was under the impression that the transaction capability was general purpose and not tied directly to j2ee. > X unavailable-client-deployer > X unavailable-ejb-deployer > X unavailable-webservices-deployer I think these three unavailable* configs are necessary so long as we keep the j2ee-deployer. > > I'd like to be able to remove the unavailable* deployers but at the > moment I think they are pretty tightly tied to the j2ee-deployer > which IIUC we need to keep since it is really not just for j2ee > deployments. IIRC I attempted to remove j2ee-deployer earlier and > discovered that I needed this to be able to deploy plugins into > micro-G. I think the other j2ee* modules are likewise required for > more than just j2ee content. Is this true? > > I think we might be able to remove hot-deployer ... any thoughts? > My only concern is that if we get too fine grained then it gets > difficult to build up the image to be equivalent for little-G or > higher. Right now to get from micro-G to little-G you need to > deploy both the tomcat or jetty plugin and the corresponding > deployer. Removing hot-deployer will add another item to the > list. Thoughts? > > Joe > >
Re: micro-G modules(configs)
On Oct 5, 2006, at 3:52 PM, Aaron Mulder wrote: I think we need to keep enough in there that the command-line deploy tool still works. It looks like online-deployer is empty (or else I would have said to keep that), but I think j2ee-security is required for the JMX remoting used by the deploy tool. Without this, I think you'll have to mangle the repository contents and config.xml by hand in order to ever have more than "Micro G" (ick). Anyway, I would also be in favor of separating the specs from RMI naming. Thanks, Aaron P.S. Maybe we should whack the online-deployer module and rename "j2ee-security" to just "security" or something. Online-deployer is empty just like the rest of the configs that are servers. It relies on manifest classpath and the configuration it contains. IIRC online-deployer.car is the same file as deployer.jar. I guess you're right that a little more might be good. I was figuring that being able to add plugins might be enough. What connects to the plugin installer? thanks david jencks On 10/5/06, David Jencks <[EMAIL PROTECTED]> wrote: I marked the ones to remove IMO with an X I seem to have a more extreme view of "micro" than you :-) I'd also prefer to pull the specs out of rmi-naming into a separate config so we can swap in the jee5 ones more easily. thanks david jencks On Oct 5, 2006, at 2:59 PM, Joe Bohn wrote: > > The following modules are currently included in micro-G. > What of these should we attempt to remove yet from micro-G? > > X connector-deployer > geronimo-gbean-deployer > X hot-deployer > X j2ee-deployer > X j2ee-security > X j2ee-server > j2ee-system > X online-deployer > rmi-naming > X sharedlib > shutdown > X transaction > X unavailable-client-deployer > X unavailable-ejb-deployer > X unavailable-webservices-deployer > > I'd like to be able to remove the unavailable* deployers but at the > moment I think they are pretty tightly tied to the j2ee-deployer > which IIUC we need to keep since it is really not just for j2ee > deployments. IIRC I attempted to remove j2ee-deployer earlier and > discovered that I needed this to be able to deploy plugins into > micro-G. I think the other j2ee* modules are likewise required for > more than just j2ee content. Is this true? > > I think we might be able to remove hot-deployer ... any thoughts? > My only concern is that if we get too fine grained then it gets > difficult to build up the image to be equivalent for little-G or > higher. Right now to get from micro-G to little-G you need to > deploy both the tomcat or jetty plugin and the corresponding > deployer. Removing hot-deployer will add another item to the > list. Thoughts? > > Joe > >
Re: micro-G modules(configs)
I think we need to keep enough in there that the command-line deploy tool still works. It looks like online-deployer is empty (or else I would have said to keep that), but I think j2ee-security is required for the JMX remoting used by the deploy tool. Without this, I think you'll have to mangle the repository contents and config.xml by hand in order to ever have more than "Micro G" (ick). Anyway, I would also be in favor of separating the specs from RMI naming. Thanks, Aaron P.S. Maybe we should whack the online-deployer module and rename "j2ee-security" to just "security" or something. On 10/5/06, David Jencks <[EMAIL PROTECTED]> wrote: I marked the ones to remove IMO with an X I seem to have a more extreme view of "micro" than you :-) I'd also prefer to pull the specs out of rmi-naming into a separate config so we can swap in the jee5 ones more easily. thanks david jencks On Oct 5, 2006, at 2:59 PM, Joe Bohn wrote: > > The following modules are currently included in micro-G. > What of these should we attempt to remove yet from micro-G? > > X connector-deployer > geronimo-gbean-deployer > X hot-deployer > X j2ee-deployer > X j2ee-security > X j2ee-server > j2ee-system > X online-deployer > rmi-naming > X sharedlib > shutdown > X transaction > X unavailable-client-deployer > X unavailable-ejb-deployer > X unavailable-webservices-deployer > > I'd like to be able to remove the unavailable* deployers but at the > moment I think they are pretty tightly tied to the j2ee-deployer > which IIUC we need to keep since it is really not just for j2ee > deployments. IIRC I attempted to remove j2ee-deployer earlier and > discovered that I needed this to be able to deploy plugins into > micro-G. I think the other j2ee* modules are likewise required for > more than just j2ee content. Is this true? > > I think we might be able to remove hot-deployer ... any thoughts? > My only concern is that if we get too fine grained then it gets > difficult to build up the image to be equivalent for little-G or > higher. Right now to get from micro-G to little-G you need to > deploy both the tomcat or jetty plugin and the corresponding > deployer. Removing hot-deployer will add another item to the > list. Thoughts? > > Joe > >
Re: micro-G modules(configs)
I marked the ones to remove IMO with an X I seem to have a more extreme view of "micro" than you :-) I'd also prefer to pull the specs out of rmi-naming into a separate config so we can swap in the jee5 ones more easily. thanks david jencks On Oct 5, 2006, at 2:59 PM, Joe Bohn wrote: The following modules are currently included in micro-G. What of these should we attempt to remove yet from micro-G? X connector-deployer geronimo-gbean-deployer X hot-deployer X j2ee-deployer X j2ee-security X j2ee-server j2ee-system X online-deployer rmi-naming X sharedlib shutdown X transaction X unavailable-client-deployer X unavailable-ejb-deployer X unavailable-webservices-deployer I'd like to be able to remove the unavailable* deployers but at the moment I think they are pretty tightly tied to the j2ee-deployer which IIUC we need to keep since it is really not just for j2ee deployments. IIRC I attempted to remove j2ee-deployer earlier and discovered that I needed this to be able to deploy plugins into micro-G. I think the other j2ee* modules are likewise required for more than just j2ee content. Is this true? I think we might be able to remove hot-deployer ... any thoughts? My only concern is that if we get too fine grained then it gets difficult to build up the image to be equivalent for little-G or higher. Right now to get from micro-G to little-G you need to deploy both the tomcat or jetty plugin and the corresponding deployer. Removing hot-deployer will add another item to the list. Thoughts? Joe
micro-G modules(configs)
The following modules are currently included in micro-G. What of these should we attempt to remove yet from micro-G? connector-deployer geronimo-gbean-deployer hot-deployer j2ee-deployer j2ee-security j2ee-server j2ee-system online-deployer rmi-naming sharedlib shutdown transaction unavailable-client-deployer unavailable-ejb-deployer unavailable-webservices-deployer I'd like to be able to remove the unavailable* deployers but at the moment I think they are pretty tightly tied to the j2ee-deployer which IIUC we need to keep since it is really not just for j2ee deployments. IIRC I attempted to remove j2ee-deployer earlier and discovered that I needed this to be able to deploy plugins into micro-G. I think the other j2ee* modules are likewise required for more than just j2ee content. Is this true? I think we might be able to remove hot-deployer ... any thoughts? My only concern is that if we get too fine grained then it gets difficult to build up the image to be equivalent for little-G or higher. Right now to get from micro-G to little-G you need to deploy both the tomcat or jetty plugin and the corresponding deployer. Removing hot-deployer will add another item to the list. Thoughts? Joe
Re: Micro-G
You're absolutely right Jacek. Actually, I think the name is one of the things still open for debate. However, once it is settled we need to use it consistently. I've been using micro-G as a nickname just as we used little-G to refer to the geronimo-jetty/tomcat-minimal assemblies. But I think that it's really not necessary to have a nickname and even confusing to our users. Thanks, Joe Jacek Laskowski wrote: On 9/26/06, Joe Bohn <[EMAIL PROTECTED]> wrote: The initial commit is out there with rev. 449892. Thanks Joe for your work. The only thing I'm not happy with is that we call it - Micro-G - whereas it's geronimo-framework in repository. I think that it may confuse our users and confused they won't be so willing to play with it. Therefore, we need to be more consistent how we call the latest newborn and call it geronimo-framework as it is named in the repository or rename geronimo-framework to geronimo-micro. Even though the names could not be the final ones - we'd be better off calling it in a uniform way, even temporarily. Jacek
Re: Micro-G
On 9/26/06, Joe Bohn <[EMAIL PROTECTED]> wrote: The initial commit is out there with rev. 449892. Thanks Joe for your work. The only thing I'm not happy with is that we call it - Micro-G - whereas it's geronimo-framework in repository. I think that it may confuse our users and confused they won't be so willing to play with it. Therefore, we need to be more consistent how we call the latest newborn and call it geronimo-framework as it is named in the repository or rename geronimo-framework to geronimo-micro. Even though the names could not be the final ones - we'd be better off calling it in a uniform way, even temporarily. Jacek -- Jacek Laskowski http://www.laskowski.net.pl
Re: Micro-G
The initial commit is out there with rev. 449892. I can deploy the updated tomcat car and then subsequently the tomcat-deployer car produced with these changes. I can then subsequently deploy a simple web application on tomcat. I have also done the same with jetty, jetty-deploy, and again a simple web application. However, to this I have to cheat a little at the moment. I manually copy the 1.2-SNAPSHOT jars necessary for tomcat, tomcat-deployer, jetty, jetty-deployer, and most recently geronimo-clustering (due to the dependency from jetty to geronimo-clustering) into the assemblies repository. This is necessary for the time being because these jars don't exist in any public repository. I also have to cheat and copy the jetty schemas into the schema location (the framework assembly build already includes the tomcat schemas for now). Aaron pointed me to some info on how to get these schemas included in the plugin and copied at deploy time which I will look at next. Finally, for Jetty I also have to modify var\config\config.xml WebBuilder default namespace to reference jetty instead of tomcat so there's still some more work necessary there. There are also some more items that should probably be removed from this framework assembly ... but this is a start. Initial commit to trunk on 09/25/06: Adding assemblies\geronimo-framework Adding assemblies\geronimo-framework\LICENSE.txt Adding assemblies\geronimo-framework\NOTICE.txt Adding assemblies\geronimo-framework\pom.xml Adding assemblies\geronimo-framework\src Adding assemblies\geronimo-framework\src\main Adding assemblies\geronimo-framework\src\main\assembly Adding assemblies\geronimo-framework\src\main\assembly\bin.xml Adding assemblies\geronimo-framework\src\main\var Adding assemblies\geronimo-framework\src\main\var\config Adding assemblies\geronimo-framework\src\main\var\config\config.xml Adding assemblies\geronimo-framework\src\main\var\config\offline-deployer-list Sendingassemblies\pom.xml Sendingconfigs\jetty\pom.xml Adding configs\jetty\src\main Adding configs\jetty\src\main\resources Adding configs\jetty\src\main\resources\META-INF Adding configs\jetty\src\main\resources\META-INF\geronimo-plugin.xml Sendingconfigs\jetty\src\plan\plan.xml Sendingconfigs\jetty-deployer\pom.xml Adding configs\jetty-deployer\src\main Adding configs\jetty-deployer\src\main\resources Adding configs\jetty-deployer\src\main\resources\META-INF Adding configs\jetty-deployer\src\main\resources\META-INF\geronimo-plugin.xml Sendingconfigs\pom.xml Sendingconfigs\tomcat\pom.xml Adding configs\tomcat\src\main Adding configs\tomcat\src\main\resources Adding configs\tomcat\src\main\resources\META-INF Adding configs\tomcat\src\main\resources\META-INF\geronimo-plugin.xml Sendingconfigs\tomcat\src\plan\plan.xml Sendingconfigs\tomcat-deployer\pom.xml Adding configs\tomcat-deployer\src\main Adding configs\tomcat-deployer\src\main\resources Adding configs\tomcat-deployer\src\main\resources\META-INF Adding configs\tomcat-deployer\src\main\resources\META-INF\geronimo-plugin.xml Transmitting file data .. Committed revision 449892. Joe Bohn wrote: I've done some work on a new assembly that I've nicknamed "Micro-G" (I know .. not very creative). The name that I'm using under geronimo/assemblies is "geronimo-framework". This is intended to be a new foundational assembly from which any customized Geronimo assembly could be built by installing plugins we would provide (starting with tomcat and jetty plugins). Hopefully this could help us eliminate the need to provide so many canned configurations with each release. I'm pretty sure we would probably still want to provide at least one full j2ee server configuration that we certified against, but we could potentially drop the little-G assemblies and hopefully avoid additional future assemblies based upon different combinations of components in the works. So far, I've been doing this on my local image. I would like to get this code (incomplete as it currently is) checked into trunk to better manage the changes and to share the effort. Is this considered a "controversial change"? Should I first provide a patch as it currently stands so that folks can comment on it prior to a commit(ala RTC)? I'm inclined to just commit the code since it is relatively self contained at the moment, safe, and can be easily reverted. I think the only controversial change thus far might be that I updated the default port selections on the tomcat configuration so that if you install a tomcat plugin on this framework assembly you will end up with the same port co
Re: Micro-G
What I have now is dependent upon geronimo-boilerplate-minimal (same as the minimal tomcat assembly which I cloned and used as a starting point). Joe Jason Dillon wrote: How is this new assembly going to work with the boilerplates? --jason On Sep 25, 2006, at 1:20 PM, Joe Bohn wrote: I didn't create a branch earlier because I didn't have experience doing that and thought I'd just start to play with my local build (I know, not a good excuse but it's the truth). I was just getting to the point where I figured I should either create a branch or provide a patch for RTC when we made the switch to CTR last week. Since it appears that there are no strong objections I'll go ahead and commit what I have later today. Thanks, Joe Jacek Laskowski wrote: On 9/25/06, Joe Bohn <[EMAIL PROTECTED]> wrote: So far, I've been doing this on my local image. I would like to get this code (incomplete as it currently is) checked into trunk to better manage the changes and to share the effort. Is this considered a "controversial change"? Should I first provide a patch as it currently stands so that folks can comment on it prior to a commit(ala RTC)? I wonder why you haven't been doing your experiments in a branch or the sandbox? You would surely avoid dealing with these troubles. Should I go ahead and commit this new assembly and config updates? +0 Jacek
Re: Micro-G
How is this new assembly going to work with the boilerplates? --jason On Sep 25, 2006, at 1:20 PM, Joe Bohn wrote: I didn't create a branch earlier because I didn't have experience doing that and thought I'd just start to play with my local build (I know, not a good excuse but it's the truth). I was just getting to the point where I figured I should either create a branch or provide a patch for RTC when we made the switch to CTR last week. Since it appears that there are no strong objections I'll go ahead and commit what I have later today. Thanks, Joe Jacek Laskowski wrote: On 9/25/06, Joe Bohn <[EMAIL PROTECTED]> wrote: So far, I've been doing this on my local image. I would like to get this code (incomplete as it currently is) checked into trunk to better manage the changes and to share the effort. Is this considered a "controversial change"? Should I first provide a patch as it currently stands so that folks can comment on it prior to a commit(ala RTC)? I wonder why you haven't been doing your experiments in a branch or the sandbox? You would surely avoid dealing with these troubles. Should I go ahead and commit this new assembly and config updates? +0 Jacek
Re: Micro-G
+1. Go for it. -- dims On 9/25/06, Joe Bohn <[EMAIL PROTECTED]> wrote: I didn't create a branch earlier because I didn't have experience doing that and thought I'd just start to play with my local build (I know, not a good excuse but it's the truth). I was just getting to the point where I figured I should either create a branch or provide a patch for RTC when we made the switch to CTR last week. Since it appears that there are no strong objections I'll go ahead and commit what I have later today. Thanks, Joe Jacek Laskowski wrote: > On 9/25/06, Joe Bohn <[EMAIL PROTECTED]> wrote: > > >> So far, I've been doing this on my local image. I would like to get >> this code (incomplete as it currently is) checked into trunk to better >> manage the changes and to share the effort. Is this considered a >> "controversial change"? Should I first provide a patch as it currently >> stands so that folks can comment on it prior to a commit(ala RTC)? > > > I wonder why you haven't been doing your experiments in a branch or > the sandbox? You would surely avoid dealing with these troubles. > >> Should I go ahead and commit this new assembly and config updates? > > > +0 > > Jacek > -- Davanum Srinivas : http://www.wso2.net (Oxygen for Web Service Developers)
Re: Micro-G
I didn't create a branch earlier because I didn't have experience doing that and thought I'd just start to play with my local build (I know, not a good excuse but it's the truth). I was just getting to the point where I figured I should either create a branch or provide a patch for RTC when we made the switch to CTR last week. Since it appears that there are no strong objections I'll go ahead and commit what I have later today. Thanks, Joe Jacek Laskowski wrote: On 9/25/06, Joe Bohn <[EMAIL PROTECTED]> wrote: So far, I've been doing this on my local image. I would like to get this code (incomplete as it currently is) checked into trunk to better manage the changes and to share the effort. Is this considered a "controversial change"? Should I first provide a patch as it currently stands so that folks can comment on it prior to a commit(ala RTC)? I wonder why you haven't been doing your experiments in a branch or the sandbox? You would surely avoid dealing with these troubles. Should I go ahead and commit this new assembly and config updates? +0 Jacek
Re: Micro-G
Sweeet... we need a new logo Since its new I'm happy to look at it after you commit it. Matt Hogstrom [EMAIL PROTECTED]
Re: Micro-G
On 9/25/06, Joe Bohn <[EMAIL PROTECTED]> wrote: So far, I've been doing this on my local image. I would like to get this code (incomplete as it currently is) checked into trunk to better manage the changes and to share the effort. Is this considered a "controversial change"? Should I first provide a patch as it currently stands so that folks can comment on it prior to a commit(ala RTC)? I wonder why you haven't been doing your experiments in a branch or the sandbox? You would surely avoid dealing with these troubles. Should I go ahead and commit this new assembly and config updates? +0 Jacek -- Jacek Laskowski http://www.laskowski.net.pl
Re: Micro-G
I'd like to see the changes. I think CTR is fine. Tomcat config update seems like the right thing, anyway. --kevan
Re: Micro-G
--- Joe Bohn <[EMAIL PROTECTED]> wrote: > > I've done some work on a new assembly that I've nicknamed "Micro-G" > (I > know .. not very creative). The name that I'm using under > geronimo/assemblies is "geronimo-framework". This is intended to be > a > new foundational assembly from which any customized Geronimo assembly > > could be built by installing plugins we would provide (starting with > tomcat and jetty plugins). > > Hopefully this could help us eliminate the need to provide so many > canned configurations with each release. I'm pretty sure we would > probably still want to provide at least one full j2ee server > configuration that we certified against, but we could potentially > drop > the little-G assemblies and hopefully avoid additional future > assemblies > based upon different combinations of components in the works. > > So far, I've been doing this on my local image. I would like to get > this code (incomplete as it currently is) checked into trunk to > better > manage the changes and to share the effort. Yes, please go ahead.. and let me know if and how I can share the effort. thanks Anita Is this considered a > "controversial change"? Should I first provide a patch as it > currently > stands so that folks can comment on it prior to a commit(ala RTC)? > > I'm inclined to just commit the code since it is relatively self > contained at the moment, safe, and can be easily reverted. I think > the > only controversial change thus far might be that I updated the > default > port selections on the tomcat configuration so that if you install a > tomcat plugin on this framework assembly you will end up with the > same > port configurations currently available on our existing tomcat > distributions. Of course, this means that the default ports are no > longer conducive to running two web servers in the same > configuration. > > Should I go ahead and commit this new assembly and config updates? > > Joe > > __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: Micro-G
On Sep 25, 2006, at 9:49 AM, Joe Bohn wrote: I've done some work on a new assembly that I've nicknamed "Micro- G" (I know .. not very creative). The name that I'm using under geronimo/assemblies is "geronimo-framework". This is intended to be a new foundational assembly from which any customized Geronimo assembly could be built by installing plugins we would provide (starting with tomcat and jetty plugins). Hopefully this could help us eliminate the need to provide so many canned configurations with each release. I'm pretty sure we would probably still want to provide at least one full j2ee server configuration that we certified against, but we could potentially drop the little-G assemblies and hopefully avoid additional future assemblies based upon different combinations of components in the works. So far, I've been doing this on my local image. I would like to get this code (incomplete as it currently is) checked into trunk to better manage the changes and to share the effort. Is this considered a "controversial change"? Should I first provide a patch as it currently stands so that folks can comment on it prior to a commit(ala RTC)? I'm inclined to just commit the code since it is relatively self contained at the moment, safe, and can be easily reverted. I think the only controversial change thus far might be that I updated the default port selections on the tomcat configuration so that if you install a tomcat plugin on this framework assembly you will end up with the same port configurations currently available on our existing tomcat distributions. Of course, this means that the default ports are no longer conducive to running two web servers in the same configuration. Should I go ahead and commit this new assembly and config updates? yes, please do. Updating the tomcat config ports to the "normal" expected values is a really good idea anyway. Anyone crazy enough (that would be me) to want to run 2 web servers in the same g instance can deal with setting the ports in the config.xml thanks david jencks Joe
Re: Micro-G
Yes...commit it...this is a great foundation for SOA and ESBs (no web container needed). Joe Bohn wrote: > > I've done some work on a new assembly that I've nicknamed "Micro-G" (I > know .. not very creative). The name that I'm using under > geronimo/assemblies is "geronimo-framework". This is intended to be a > new foundational assembly from which any customized Geronimo assembly > could be built by installing plugins we would provide (starting with > tomcat and jetty plugins). > > Hopefully this could help us eliminate the need to provide so many > canned configurations with each release. I'm pretty sure we would > probably still want to provide at least one full j2ee server > configuration that we certified against, but we could potentially drop > the little-G assemblies and hopefully avoid additional future assemblies > based upon different combinations of components in the works. > > So far, I've been doing this on my local image. I would like to get > this code (incomplete as it currently is) checked into trunk to better > manage the changes and to share the effort. Is this considered a > "controversial change"? Should I first provide a patch as it currently > stands so that folks can comment on it prior to a commit(ala RTC)? > > I'm inclined to just commit the code since it is relatively self > contained at the moment, safe, and can be easily reverted. I think the > only controversial change thus far might be that I updated the default > port selections on the tomcat configuration so that if you install a > tomcat plugin on this framework assembly you will end up with the same > port configurations currently available on our existing tomcat > distributions. Of course, this means that the default ports are no > longer conducive to running two web servers in the same configuration. > > Should I go ahead and commit this new assembly and config updates? > > Joe
Micro-G
I've done some work on a new assembly that I've nicknamed "Micro-G" (I know .. not very creative). The name that I'm using under geronimo/assemblies is "geronimo-framework". This is intended to be a new foundational assembly from which any customized Geronimo assembly could be built by installing plugins we would provide (starting with tomcat and jetty plugins). Hopefully this could help us eliminate the need to provide so many canned configurations with each release. I'm pretty sure we would probably still want to provide at least one full j2ee server configuration that we certified against, but we could potentially drop the little-G assemblies and hopefully avoid additional future assemblies based upon different combinations of components in the works. So far, I've been doing this on my local image. I would like to get this code (incomplete as it currently is) checked into trunk to better manage the changes and to share the effort. Is this considered a "controversial change"? Should I first provide a patch as it currently stands so that folks can comment on it prior to a commit(ala RTC)? I'm inclined to just commit the code since it is relatively self contained at the moment, safe, and can be easily reverted. I think the only controversial change thus far might be that I updated the default port selections on the tomcat configuration so that if you install a tomcat plugin on this framework assembly you will end up with the same port configurations currently available on our existing tomcat distributions. Of course, this means that the default ports are no longer conducive to running two web servers in the same configuration. Should I go ahead and commit this new assembly and config updates? Joe
