Re: Splitting up the server into a few more chunks
On Aug 29, 2007, at 10:12 AM, Prasad Kashyap wrote: Scenario 1: server/support/trunk server/framework/trunk server/plugins/trunk/ <--- jee5, non-jee5, samples etc are all here together. I'm not really convinced we need to have this intermediate "server" tree right now. IMO this is a bit over structured for a structure we haven't really gotten a good idea for what it looks like. I'd defer organizing the chunks we split off into smaller groups as an exercise for once we've actually gotten then chunks pulled off. Its easy enough to change later... --jason
Re: Splitting up the server into a few more chunks
On Aug 6, 2007, at 8:03 PM, David Blevins wrote: On Aug 6, 2007, at 8:12 AM, David Jencks wrote: I certainly agree with your goal but am less sure about your proposed naming and organization. Also from looking at your list it took me a couple minutes to figure out what is removed from "server" I've been thinking that we could proceed by turning bits of the server into plugins. For instance I was planning to turn the directory bits I commented out recently into a plugin this week. I think we could fairly easiiy turn jetty, tomcat, and openejb into plugins. I wonder if, after turning the "easy stuff" into plugins what we will think about reorganizing the remaining stuff. So then the question might be how to organize the plugins? Haven't read the rest of the thread yet, but I'd like to backup the idea of pulling things out one at a time, like we did with connector and transaction, making them plugins if possible. It would be really great if people do things like upgrade OpenEJB when a new release came out -- which we're hoping is often. Do you know of any other bits which we can pull out nowish (or with a wee bit of work)? I'd really like to get the kernel and muck sucked out, but I've got a feeling that is a hugeish taskotron. --jason
Re: Splitting up the server into a few more chunks
On Aug 6, 2007, at 11:12 AM, Donald Woods wrote: Another thought (now that I had some lunch) What if we create a "builders/deployers" grouping, which contained the modules and configs needed for each builder, like - deployers myfaces modules geronimo-myfaces geronimo-myfaces-builder configs myfaces myfaces-deployers tomcat . . . jetty . . . Anything that didn't fit into a deployer/builder category, could go into a system grouping or the existing components group. I forget what I said about this before... but just in case I didn't say it... I'm really *not* fond of grouping things under a "deployer (s)" name. I think we have a core/framework, a set of reusable components (non-plugins, ie. tx manager, jndi provider or whatever), a set of plugins which provide additional functionality (could be deployment, could be daemon processes, whatever), a set of standard applications (like the web console), and a set of assemblies (which glue it all together). So, based on that I think that: framework|core/trunk components//trunk plugins//trunk apps//trunk server//trunk (where server is javaee/minimal/crackpipe/ etc) uberserver/trunk (uses svn:externals to make a workspace with all the bits to compile for those who like to watch paint dry as the beast builds) For now I'd like to see the components, plugins and apps trees contain separate sub-projects for each chunk of functionality, versioned and released independently. I'm guessing that these projects might contain anywhere from 2-10 modules or so, probably averaging at 4, maybe 3. Ya, I know its more moving parts to manage, but IMO, I think this will simplify many aspects of delivering a rock solid application server (and framework) to the world. And if we do it right we should be able to quickly adapt and fix bugs for faster turn around. And well, it will also make some of our lives a lot simpler since with *most* of the server being in separate smaller sub- projects which are released, there is a heck of a lot less code to build. Well, anyways... no matter how we slice it... we need to do something. And we should really get some yays and nays in the next week or so about the _general_ plan... and then start to stage the move... because it will affect developers, there will be oh-so-fun merges to be done, and someone is not going to be happy I'm sure... but we need to do it. And, well with my code slinging cowbow hat on I'd say lets just go balls out and do it. Once we have a general plan, implementing will take a week maybe (to get it all sorted and back to happy happy again), assuming there are no super-evil coupling points. /me will shutup now --jason
Re: Splitting up the server into a few more chunks
On Aug 6, 2007, at 9:59 AM, Donald Woods wrote: Anything more than 6 to 8 groupings could cause chaos (just like at our current release process which takes weeks to get everything voted and released...) After cleanup of server to move the samples to /samples and ApacheDS to /plugins, we should consider the more drastic changes, like moving the base Admin Console support (via Pluto 1.2) out to / plugins and start moving the Portlets into the actual modules/ configs that they administer Some other "grouping" that may make sense are - - core - renamed /server/modules directory promoted to a top-level grouping and only contains server modules - configs - current configs, which can be installed as plugins I'd really like to see the grouping of just configuration modules go away. I firmly believe that configuration modules should live right next to the code modules for which they are configuration for. - assemblies - current assemblies, which require the configs as input I'd like to see the main assembly configuration split off from the server/core/whatever stuff. Actually, I'd like to see the core/ framework as a sub-project, then have the server sub-project server only to configure the plugins to be pulled in and the assembly configurations for the javaee server distributions. --jason
Re: Splitting up the server into a few more chunks
On Aug 29, 2007, at 1:12 PM, Prasad Kashyap wrote: 2. We have to split the current build tree into support, framework, and plugins sub-trees. Other than support and framework, everything else should be plugins. This includes jee5, non-jee5, samples etc. which could go in their own subtrees or be together. I like your ideas. Taking a step back are we in agreement on the "everything else as plugins" approach? We have been hinting at this for some time and doing various interesting things with plugins but I don't see enough of the big picture yet to provide much useful feedback on your proposal. Maybe the time is right to start a big picture discussion about plugins. I'll cook something up and maybe that thread will help us answer some of your questions. Best wishes, Paul
Re: Splitting up the server into a few more chunks
I think we don't really need svn, lets just mail around patches we make to the list and get rid of this scm crapo... too much work for too little benifit lol :-P --jason On Aug 29, 2007, at 10:12 AM, Prasad Kashyap wrote: I'm trying to understand what we have discussed/decided so far. Please let me know if my summary is on track and help me correct course. We haven't discussed the actual maven groupIds/artifactIds/directory names yet. So all names used in this summary are just as examples. Summary: --- 1. Our basic objective is to deliver a framework and a large set of components with which our users can build their own Geronimo server. The primary goal of our build restructuring exercise should be to help us meet this objective. The next goal should be to help us build smoothly and release efficiently. 2. We have to split the current build tree into support, framework, and plugins sub-trees. Other than support and framework, everything else should be plugins. This includes jee5, non-jee5, samples etc. which could go in their own subtrees or be together. Scenario 1: server/support/trunk server/framework/trunk server/plugins/trunk/ <--- jee5, non-jee5, samples etc are all here together. Scenario 2: server/support/trunk server/framework/trunk server/plugins/trunk/ jee5/ opt/ samples/ Scenario 3: server/support/trunk server/framework/trunk server/plugins/trunk<-- jee5 plugins server/opt/trunk <-- opt plugins server/samples/trunk <-- samples plugins Can we please pick a scenario here and move on ? 3. We have to restructure the build tree to make it feature-oriented rather than type-oriented like present. To take Jencks example, jetty runtime, jetty deployer and jetty admin should be kept together (as a plugin group) instead of keeping module jars and config cars separate. server/plugins/trunk/ geronimo-jetty/ jetty-runtime(1) jetty-deployer (2) jetty-admin (3) "I think you should be able to install (1), (1 and 3) (1 and 2) or (1, 2 and 3)." - Jencks. Further discussion: Currently the plugins tree is structured as plugins//trunk. IMO, this is not feasible in the long run, esp. when we want to convert most of everything we have into plugins, b'coz - 1. svn checkout of a complete Geronimo server (framework + all plugins) for a given version now becomes a nightmare. 2. building all plugins for a given version becomes difficult. 3. inheritance from a common parent becomes difficult. Many things will be duplicated across all the poms for all the plugins. Longer poms causes larger maintenance issues. 4. Even maven plugins whom we want to emulate for their independent release cycles are not structured this way. Trunk, branches, tags form the top tier. http://svn.apache.org/viewvc/maven/plugins/ Cheers Prasad On 8/8/07, Jason Dillon <[EMAIL PROTECTED]> wrote: On Aug 6, 2007, at 8:03 PM, David Blevins wrote: On Aug 6, 2007, at 8:12 AM, David Jencks wrote: I certainly agree with your goal but am less sure about your proposed naming and organization. Also from looking at your list it took me a couple minutes to figure out what is removed from "server" I've been thinking that we could proceed by turning bits of the server into plugins. For instance I was planning to turn the directory bits I commented out recently into a plugin this week. I think we could fairly easiiy turn jetty, tomcat, and openejb into plugins. I wonder if, after turning the "easy stuff" into plugins what we will think about reorganizing the remaining stuff. So then the question might be how to organize the plugins? Haven't read the rest of the thread yet, but I'd like to backup the idea of pulling things out one at a time, like we did with connector and transaction, making them plugins if possible. It would be really great if people do things like upgrade OpenEJB when a new release came out -- which we're hoping is often. I'd still like to see the plugin mangement in the console work something like the Confluence Plugin Repository Client ( http:// confluence.atlassian.com/display/CONFEXT/Confluence+Repository +Client ) Which has a sex UI to show whats installed (version, urls, notes, etc), whats not (with simple buttons to install) and when stuff is out of date (with simple buttons to upgrade). This would be *hugely* powerful for administrators managing a Geronimo instance. :-)
Re: Splitting up the server into a few more chunks
I'm trying to understand what we have discussed/decided so far. Please let me know if my summary is on track and help me correct course. We haven't discussed the actual maven groupIds/artifactIds/directory names yet. So all names used in this summary are just as examples. Summary: --- 1. Our basic objective is to deliver a framework and a large set of components with which our users can build their own Geronimo server. The primary goal of our build restructuring exercise should be to help us meet this objective. The next goal should be to help us build smoothly and release efficiently. 2. We have to split the current build tree into support, framework, and plugins sub-trees. Other than support and framework, everything else should be plugins. This includes jee5, non-jee5, samples etc. which could go in their own subtrees or be together. Scenario 1: server/support/trunk server/framework/trunk server/plugins/trunk/ <--- jee5, non-jee5, samples etc are all here together. Scenario 2: server/support/trunk server/framework/trunk server/plugins/trunk/ jee5/ opt/ samples/ Scenario 3: server/support/trunk server/framework/trunk server/plugins/trunk<-- jee5 plugins server/opt/trunk <-- opt plugins server/samples/trunk <-- samples plugins Can we please pick a scenario here and move on ? 3. We have to restructure the build tree to make it feature-oriented rather than type-oriented like present. To take Jencks example, jetty runtime, jetty deployer and jetty admin should be kept together (as a plugin group) instead of keeping module jars and config cars separate. server/plugins/trunk/ geronimo-jetty/ jetty-runtime(1) jetty-deployer (2) jetty-admin (3) "I think you should be able to install (1), (1 and 3) (1 and 2) or (1, 2 and 3)." - Jencks. Further discussion: Currently the plugins tree is structured as plugins//trunk. IMO, this is not feasible in the long run, esp. when we want to convert most of everything we have into plugins, b'coz - 1. svn checkout of a complete Geronimo server (framework + all plugins) for a given version now becomes a nightmare. 2. building all plugins for a given version becomes difficult. 3. inheritance from a common parent becomes difficult. Many things will be duplicated across all the poms for all the plugins. Longer poms causes larger maintenance issues. 4. Even maven plugins whom we want to emulate for their independent release cycles are not structured this way. Trunk, branches, tags form the top tier. http://svn.apache.org/viewvc/maven/plugins/ Cheers Prasad On 8/8/07, Jason Dillon <[EMAIL PROTECTED]> wrote: > On Aug 6, 2007, at 8:03 PM, David Blevins wrote: > > On Aug 6, 2007, at 8:12 AM, David Jencks wrote: > > > >> I certainly agree with your goal but am less sure about your > >> proposed naming and organization. Also from looking at your list > >> it took me a couple minutes to figure out what is removed from > >> "server" > >> > >> I've been thinking that we could proceed by turning bits of the > >> server into plugins. For instance I was planning to turn the > >> directory bits I commented out recently into a plugin this week. > >> I think we could fairly easiiy turn jetty, tomcat, and openejb > >> into plugins. I wonder if, after turning the "easy stuff" into > >> plugins what we will think about reorganizing the remaining stuff. > >> > >> So then the question might be how to organize the plugins? > > > > Haven't read the rest of the thread yet, but I'd like to backup the > > idea of pulling things out one at a time, like we did with > > connector and transaction, making them plugins if possible. It > > would be really great if people do things like upgrade OpenEJB when > > a new release came out -- which we're hoping is often. > > I'd still like to see the plugin mangement in the console work > something like the Confluence Plugin Repository Client ( http:// > confluence.atlassian.com/display/CONFEXT/Confluence+Repository+Client ) > > Which has a sex UI to show whats installed (version, urls, notes, > etc), whats not (with simple buttons to install) and when stuff is > out of date (with simple buttons to upgrade). This would be *hugely* > powerful for administrators managing a Geronimo instance. > > :-) > > >
Re: Splitting up the server into a few more chunks
On Aug 6, 2007, at 8:03 PM, David Blevins wrote: On Aug 6, 2007, at 8:12 AM, David Jencks wrote: I certainly agree with your goal but am less sure about your proposed naming and organization. Also from looking at your list it took me a couple minutes to figure out what is removed from "server" I've been thinking that we could proceed by turning bits of the server into plugins. For instance I was planning to turn the directory bits I commented out recently into a plugin this week. I think we could fairly easiiy turn jetty, tomcat, and openejb into plugins. I wonder if, after turning the "easy stuff" into plugins what we will think about reorganizing the remaining stuff. So then the question might be how to organize the plugins? Haven't read the rest of the thread yet, but I'd like to backup the idea of pulling things out one at a time, like we did with connector and transaction, making them plugins if possible. It would be really great if people do things like upgrade OpenEJB when a new release came out -- which we're hoping is often. I'd still like to see the plugin mangement in the console work something like the Confluence Plugin Repository Client ( http:// confluence.atlassian.com/display/CONFEXT/Confluence+Repository+Client ) Which has a sex UI to show whats installed (version, urls, notes, etc), whats not (with simple buttons to install) and when stuff is out of date (with simple buttons to upgrade). This would be *hugely* powerful for administrators managing a Geronimo instance. :-)
Re: Splitting up the server into a few more chunks
On Aug 6, 2007, at 12:43 PM, Paul McMahan wrote: On Aug 6, 2007, at 12:59 PM, Donald Woods wrote: we should consider the more drastic changes, like moving the base Admin Console support (via Pluto 1.2) out to /plugins I really like that idea for a couple of reasons - - it allows us to keep the admin console that's currently at server/trunk/applications/console in place until the new extensible admin console is ready and can scale up from minimal to full JEE5 functionality plus debug views, etc. - I like the idea of streamlining server/trunk for JEE5 stuff and moving the optional stuff elsewhere My only reservation (and its no biggie) is that using the location / plugins for optional stuff is misleading since there will be stuff in server/trunk that's required for JEE5 (i.e. not optional) but implemented as plugins like tomcat, jetty, amq, openejb, etc. Calling something a plugin is a statement about its packaging and deployment mechanism, and not whether it is required or optional. So maybe "/opt" or some such would be a better place to put the extensible admin console, tuscany (eventually), directory server, samples, roller, etc... Personally, I don't consider the bits in /plugins as _optional_... simply a home for the plug-able components and features that can be dropped into the base server to make Geronimo do something useful. After thinking about this more, I think that probably _most_ of the stuff under server/trunk can get converted into a plugin and moved to its own plugins//trunk, released and managed independently of the core server framework. If we need to update the plugin bits to make this work for more stuff, then we should do that, though I'm not sure that is needed atm. Then we'd end up with relatively smaller projects per feature/ component, a medium-sized project for the core server, and then a project for the assemblies which we deliver (ie, the javaee bits, which aggregate the javaee components, the server framework and the configuration required to make it all work out of the box). The only thing we have to be careful of is to not end up with a massive set of versions to manage, so perhaps components need to have some detail that indicates which version of the server they are compatible with or something like that. I dunno... anyways, its going to take some more discussion and planning before we can get to making this a reality, but I really trully do believe that we *must* do this to scale the management and development of Geronimo. and start moving the Portlets into the actual modules/configs that they administer I like this idea from a conceptual point of view since it keeps things neat and well organized. But I am not sure how to implement it since the main geronimo components are typically packaged in JARs, and the admin portlets for a component have to be packaged in a WAR (that's just the way that pluto works). i.e. a JAR can't contain a WAR. Some options I can think of: - use EAR as the packaging format for all geronimo components and package the admin WARs inside them - maintain geronimo components and their admin WARs separately. bind them at deployment time via the plugin installer's dependency resolution or by some enhancement to the maven car plugin - package the geronimo components as WARs so the admin portlets can be merged with them. (seems like the tail wagging the dog) - follow some organizational structure like in your previous email where each geronimo component has a module, config, and (now) WAR subdirectory Just brainstorming here... Um, I dunno... maybe some of the new magical console stuff that is going on can help. But my guess is we might have to implement a dynamic portlet, which can be given an artifact from the repository, and then load the real impl from that artifact and display it. Then the portlet bits per component can be bundled into a jar and tossed into the repo, and then the console can be configured with a list of artifacts to load into portlets. Seems like that might work out well, if the dynamic portlet impl simply handles the bridge to the portlet impl in the artifact and once loaded, basically proxies everything over to it. 'm just brainstorming too... and having *never* written a portlet in my life... maybe it will work, maybe it won't... Though, this is one area where I think a full portal impl like jetspeed2 might be of help since its already got all the juice to do this kinda dynamic portlet muck... or at least I'm hoping it does. I'm just generalizing my experience with php portals like phpnuke and postnuke which have this kinda plugabiliity built in. I really do think though that this is really positive direction... as right now the console is a horrible coupling point with all of the bits inside of the server... and if we are going to start pulling things apart into sm
Re: Splitting up the server into a few more chunks
On Aug 6, 2007, at 8:12 AM, David Jencks wrote: I certainly agree with your goal but am less sure about your proposed naming and organization. Also from looking at your list it took me a couple minutes to figure out what is removed from "server" I've been thinking that we could proceed by turning bits of the server into plugins. For instance I was planning to turn the directory bits I commented out recently into a plugin this week. I think we could fairly easiiy turn jetty, tomcat, and openejb into plugins. I wonder if, after turning the "easy stuff" into plugins what we will think about reorganizing the remaining stuff. So then the question might be how to organize the plugins? Haven't read the rest of the thread yet, but I'd like to backup the idea of pulling things out one at a time, like we did with connector and transaction, making them plugins if possible. It would be really great if people do things like upgrade OpenEJB when a new release came out -- which we're hoping is often. -David thanks david jencks On Aug 6, 2007, at 1:48 AM, Jason Dillon wrote: Hiya, I've mentioned this before... and now that we have a 2.0 branch and trunk has moved on to 2.1 work, I think its time we really make a decision on this and implement it. Before, I had been thinking of keeping all of the modules in the server/trunk tree just in better locations organized by functionality and feature not by artifact type. But, now I'm thinking we should really do one step more than that, and split up the server/trunk project into several smaller and more manageable chunks of modules. I still think that the basic grouping that we kinda talked about before should work fine, but instead of having them share a project namespace we give them their own. So, for example... server-support/trunk testsupport buildsupport server-framework/trunk geronimo-activation geronimo-client geronimo-client-builder geronimo-clustering geronimo-common geronimo-connector geronimo-connector-builder geronimo-core geronimo-deploy-config geronimo-deploy-jsr88 geronimo-deploy-jsr88-bootstrapper geronimo-deploy-tool geronimo-deployment geronimo-gbean-deployer geronimo-interceptor geronimo-j2ee geronimo-j2ee-builder geronimo-j2ee-schema geronimo-jmx-remoting geronimo-kernel geronimo-management geronimo-naming geronimo-naming-builder geronimo-security geronimo-security-builder geronimo-service-builder geronimo-system geronimo-test-ddbean geronimo-timer geronimo-transaction geronimo-transaction-jta11 geronimo-transformer geronimo-util geronimo-web-2.5-builder And then we can group some of the related components up into shared projects, or just go out and give each component its own project, and/or think about maybe using the same style that the maven/plugins/trunk tree uses, a shared project, but each component is related individually... still not sure I like that, kinda messy. I don't want to end up with a ton of projects either, and I certainly don't want to get up using SNAPSHOT versions of these puppies if we can help it. So, maybe to start out we could do these: server-support server-framework server-components server-assembly BTW, I'm using "dash" here so that the names don't collide with what is there now, but really we could user server/support/trunk, server/framework/trunk, etc (which is better IMO for the longer run). And in the process of making this split up, we can re-arrange modules by feature and function instead of by type... and actually we have to do that to make the components bits work. * * * I really believe this will help improve the support and maintainability of the server's code-base and it will help the project scale better as new components are added too. For developers that are only interested in working on a specific component, it reduces the amount of other sources they need to check out and reduces the time to build too, so that they can build a clean server assembly faster and developer their features sooner and hopefully have less hair-pulling and more relaxed beer drinking as they pat themselves on the back for doing such a speedy job. I really, really... really, really, really ( :-P ) think that we *must* move along these lines for the longer term health of the project... Comments? Suggestions? --jason
Re: Splitting up the server into a few more chunks
On Aug 6, 2007, at 12:43 PM, Paul McMahan wrote: On Aug 6, 2007, at 12:59 PM, Donald Woods wrote: we should consider the more drastic changes, like moving the base Admin Console support (via Pluto 1.2) out to /plugins I really like that idea for a couple of reasons - - it allows us to keep the admin console that's currently at server/trunk/applications/console in place until the new extensible admin console is ready and can scale up from minimal to full JEE5 functionality plus debug views, etc. - I like the idea of streamlining server/trunk for JEE5 stuff and moving the optional stuff elsewhere My only reservation (and its no biggie) is that using the location / plugins for optional stuff is misleading since there will be stuff in server/trunk that's required for JEE5 (i.e. not optional) but implemented as plugins like tomcat, jetty, amq, openejb, etc. Calling something a plugin is a statement about its packaging and deployment mechanism, and not whether it is required or optional. So maybe "/opt" or some such would be a better place to put the extensible admin console, tuscany (eventually), directory server, samples, roller, etc... and start moving the Portlets into the actual modules/configs that they administer I like this idea from a conceptual point of view since it keeps things neat and well organized. But I am not sure how to implement it since the main geronimo components are typically packaged in JARs, and the admin portlets for a component have to be packaged in a WAR (that's just the way that pluto works). i.e. a JAR can't contain a WAR. Some options I can think of: - use EAR as the packaging format for all geronimo components and package the admin WARs inside them - maintain geronimo components and their admin WARs separately. bind them at deployment time via the plugin installer's dependency resolution or by some enhancement to the maven car plugin - package the geronimo components as WARs so the admin portlets can be merged with them. (seems like the tail wagging the dog) - follow some organizational structure like in your previous email where each geronimo component has a module, config, and (now) WAR subdirectory Just brainstorming here... I think we want to use "plugin groups" which IIRC is already implemented in some way. So I see a typical feature (say jetty support) as having 3 plugins: - runtime jetty (geronimo-jetty6 module + jetty car) - deploy time jetty (geronimo-jetty6-builder + jetty-deployer car) - admin jetty (war with jetty admin portlets) To keep it simple I'm purposefully forgetting about wadi clustering support. I think you should be able to install (1), (1 and 3) (1 and 2) or (1 2 and 3). thanks david jencks Best wishes, Paul
Re: Splitting up the server into a few more chunks
On Aug 6, 2007, at 12:59 PM, Donald Woods wrote: we should consider the more drastic changes, like moving the base Admin Console support (via Pluto 1.2) out to /plugins I really like that idea for a couple of reasons - - it allows us to keep the admin console that's currently at server/ trunk/applications/console in place until the new extensible admin console is ready and can scale up from minimal to full JEE5 functionality plus debug views, etc. - I like the idea of streamlining server/trunk for JEE5 stuff and moving the optional stuff elsewhere My only reservation (and its no biggie) is that using the location / plugins for optional stuff is misleading since there will be stuff in server/trunk that's required for JEE5 (i.e. not optional) but implemented as plugins like tomcat, jetty, amq, openejb, etc. Calling something a plugin is a statement about its packaging and deployment mechanism, and not whether it is required or optional. So maybe "/opt" or some such would be a better place to put the extensible admin console, tuscany (eventually), directory server, samples, roller, etc... and start moving the Portlets into the actual modules/configs that they administer I like this idea from a conceptual point of view since it keeps things neat and well organized. But I am not sure how to implement it since the main geronimo components are typically packaged in JARs, and the admin portlets for a component have to be packaged in a WAR (that's just the way that pluto works). i.e. a JAR can't contain a WAR. Some options I can think of: - use EAR as the packaging format for all geronimo components and package the admin WARs inside them - maintain geronimo components and their admin WARs separately. bind them at deployment time via the plugin installer's dependency resolution or by some enhancement to the maven car plugin - package the geronimo components as WARs so the admin portlets can be merged with them. (seems like the tail wagging the dog) - follow some organizational structure like in your previous email where each geronimo component has a module, config, and (now) WAR subdirectory Just brainstorming here... Best wishes, Paul
Re: Splitting up the server into a few more chunks
I'd rather not have another level to simply separate code jars from config jars... I think they should all live together, and if needed we suffix the config bits with "-config", so you'd have: activemq-broker activemq-broker-config activemq-ra activemq-ra-config IMO, no need for another level of nested directories. But regaurdless, my drive here is to help make it easier for folks to develop G and develop G plugins w/o having to build the entire server, which as well all know can be problematic from time to time. --jason On Aug 6, 2007, at 11:12 AM, Donald Woods wrote: Another thought (now that I had some lunch) What if we create a "builders/deployers" grouping, which contained the modules and configs needed for each builder, like - deployers myfaces modules geronimo-myfaces geronimo-myfaces-builder configs myfaces myfaces-deployers tomcat . . . jetty . . . Anything that didn't fit into a deployer/builder category, could go into a system grouping or the existing components group. Then again, maybe we need to step back from the current source code structure and think more along the lines of Lego blocks or OSGi bundles in a server, agree to what that "framework" would look like and then slice and dice our current .m2 structure into those new buckets. -Donald Donald Woods wrote: Anything more than 6 to 8 groupings could cause chaos (just like at our current release process which takes weeks to get everything voted and released...) We already have 5 groupings created - - devtools (Eclipse, Netbeans, J2G) - plugins (non-JEE5 required server add-ons) - samples (should contain all samples from current server and the wiki) - components (shared/used by other projects) - server (current catch-all) After cleanup of server to move the samples to /samples and ApacheDS to /plugins, we should consider the more drastic changes, like moving the base Admin Console support (via Pluto 1.2) out to / plugins and start moving the Portlets into the actual modules/ configs that they administer Some other "grouping" that may make sense are - - core - renamed /server/modules directory promoted to a top-level grouping and only contains server modules - configs - current configs, which can be installed as plugins - assemblies - current assemblies, which require the configs as input -Donald Jason Dillon wrote: Um, I just took a blind stab in the dark... But, what I was thinking was that we have the core modules which are the bare minimum to boot up a functional Geronimo server w/o any JavaEE muck, then slice up the other components into plugins, though they don't really need to be G plugins, they just need to hold groups of modules to provide a components functionality and configuration. I also split up the support bits, as those should be common across the core framework bits and components/plugins... I'm certainly open to ideas and discussion on this. I think we really need to move in this direction. --jason On Aug 6, 2007, at 8:12 AM, David Jencks wrote: I certainly agree with your goal but am less sure about your proposed naming and organization. Also from looking at your list it took me a couple minutes to figure out what is removed from "server" I've been thinking that we could proceed by turning bits of the server into plugins. For instance I was planning to turn the directory bits I commented out recently into a plugin this week. I think we could fairly easiiy turn jetty, tomcat, and openejb into plugins. I wonder if, after turning the "easy stuff" into plugins what we will think about reorganizing the remaining stuff. So then the question might be how to organize the plugins? thanks david jencks On Aug 6, 2007, at 1:48 AM, Jason Dillon wrote: Hiya, I've mentioned this before... and now that we have a 2.0 branch and trunk has moved on to 2.1 work, I think its time we really make a decision on this and implement it. Before, I had been thinking of keeping all of the modules in the server/trunk tree just in better locations organized by functionality and feature not by artifact type. But, now I'm thinking we should really do one step more than that, and split up the server/trunk project into several smaller and more manageable chunks of modules. I still think that the basic grouping that we kinda talked about before should work fine, but instead of having them share a project namespace we give them their own. So, for example... server-support/trunk testsupport buildsupport server-framework/trunk geronimo-activation geronimo-client geronimo-client-builder geronimo-clust
Re: Splitting up the server into a few more chunks
On Aug 6, 2007, at 9:59 AM, Donald Woods wrote: Anything more than 6 to 8 groupings could cause chaos (just like at our current release process which takes weeks to get everything voted and released...) Yes, it has to be done very carefully, though if you look a Maven, Plexus and the related bits, they tend to release smaller groups of modules together and for the most part it does work. We already have 5 groupings created - - devtools (Eclipse, Netbeans, J2G) - plugins (non-JEE5 required server add-ons) - samples (should contain all samples from current server and the wiki) - components (shared/used by other projects) - server (current catch-all) After cleanup of server to move the samples to /samples and ApacheDS to /plugins, we should consider the more drastic changes, like moving the base Admin Console support (via Pluto 1.2) out to / plugins and start moving the Portlets into the actual modules/ configs that they administer Some other "grouping" that may make sense are - - core - renamed /server/modules directory promoted to a top-level grouping and only contains server modules - configs - current configs, which can be installed as plugins One key thing that *must* change IMO, is we need to group code jars with config jars (cars), the current split of modules/* configs/* is very artificial and doesn't really help make things easy for developers to update a specific component with out a lot of cd; mvn; junk or custom scripts. --jason
Re: Splitting up the server into a few more chunks
Another thought (now that I had some lunch) What if we create a "builders/deployers" grouping, which contained the modules and configs needed for each builder, like - deployers myfaces modules geronimo-myfaces geronimo-myfaces-builder configs myfaces myfaces-deployers tomcat . . . jetty . . . Anything that didn't fit into a deployer/builder category, could go into a system grouping or the existing components group. Then again, maybe we need to step back from the current source code structure and think more along the lines of Lego blocks or OSGi bundles in a server, agree to what that "framework" would look like and then slice and dice our current .m2 structure into those new buckets. -Donald Donald Woods wrote: Anything more than 6 to 8 groupings could cause chaos (just like at our current release process which takes weeks to get everything voted and released...) We already have 5 groupings created - - devtools (Eclipse, Netbeans, J2G) - plugins (non-JEE5 required server add-ons) - samples (should contain all samples from current server and the wiki) - components (shared/used by other projects) - server (current catch-all) After cleanup of server to move the samples to /samples and ApacheDS to /plugins, we should consider the more drastic changes, like moving the base Admin Console support (via Pluto 1.2) out to /plugins and start moving the Portlets into the actual modules/configs that they administer Some other "grouping" that may make sense are - - core - renamed /server/modules directory promoted to a top-level grouping and only contains server modules - configs - current configs, which can be installed as plugins - assemblies - current assemblies, which require the configs as input -Donald Jason Dillon wrote: Um, I just took a blind stab in the dark... But, what I was thinking was that we have the core modules which are the bare minimum to boot up a functional Geronimo server w/o any JavaEE muck, then slice up the other components into plugins, though they don't really need to be G plugins, they just need to hold groups of modules to provide a components functionality and configuration. I also split up the support bits, as those should be common across the core framework bits and components/plugins... I'm certainly open to ideas and discussion on this. I think we really need to move in this direction. --jason On Aug 6, 2007, at 8:12 AM, David Jencks wrote: I certainly agree with your goal but am less sure about your proposed naming and organization. Also from looking at your list it took me a couple minutes to figure out what is removed from "server" I've been thinking that we could proceed by turning bits of the server into plugins. For instance I was planning to turn the directory bits I commented out recently into a plugin this week. I think we could fairly easiiy turn jetty, tomcat, and openejb into plugins. I wonder if, after turning the "easy stuff" into plugins what we will think about reorganizing the remaining stuff. So then the question might be how to organize the plugins? thanks david jencks On Aug 6, 2007, at 1:48 AM, Jason Dillon wrote: Hiya, I've mentioned this before... and now that we have a 2.0 branch and trunk has moved on to 2.1 work, I think its time we really make a decision on this and implement it. Before, I had been thinking of keeping all of the modules in the server/trunk tree just in better locations organized by functionality and feature not by artifact type. But, now I'm thinking we should really do one step more than that, and split up the server/trunk project into several smaller and more manageable chunks of modules. I still think that the basic grouping that we kinda talked about before should work fine, but instead of having them share a project namespace we give them their own. So, for example... server-support/trunk testsupport buildsupport server-framework/trunk geronimo-activation geronimo-client geronimo-client-builder geronimo-clustering geronimo-common geronimo-connector geronimo-connector-builder geronimo-core geronimo-deploy-config geronimo-deploy-jsr88 geronimo-deploy-jsr88-bootstrapper geronimo-deploy-tool geronimo-deployment geronimo-gbean-deployer geronimo-interceptor geronimo-j2ee geronimo-j2ee-builder geronimo-j2ee-schema geronimo-jmx-remoting geronimo-kernel geronimo-management geronimo-naming geronimo-naming-builder geronimo-security geronimo-security-builder geronimo-service-builder geronimo-system geronimo-test-ddbean geronimo-timer geronimo-transactio
Re: Splitting up the server into a few more chunks
Anything more than 6 to 8 groupings could cause chaos (just like at our current release process which takes weeks to get everything voted and released...) We already have 5 groupings created - - devtools (Eclipse, Netbeans, J2G) - plugins (non-JEE5 required server add-ons) - samples (should contain all samples from current server and the wiki) - components (shared/used by other projects) - server (current catch-all) After cleanup of server to move the samples to /samples and ApacheDS to /plugins, we should consider the more drastic changes, like moving the base Admin Console support (via Pluto 1.2) out to /plugins and start moving the Portlets into the actual modules/configs that they administer Some other "grouping" that may make sense are - - core - renamed /server/modules directory promoted to a top-level grouping and only contains server modules - configs - current configs, which can be installed as plugins - assemblies - current assemblies, which require the configs as input -Donald Jason Dillon wrote: Um, I just took a blind stab in the dark... But, what I was thinking was that we have the core modules which are the bare minimum to boot up a functional Geronimo server w/o any JavaEE muck, then slice up the other components into plugins, though they don't really need to be G plugins, they just need to hold groups of modules to provide a components functionality and configuration. I also split up the support bits, as those should be common across the core framework bits and components/plugins... I'm certainly open to ideas and discussion on this. I think we really need to move in this direction. --jason On Aug 6, 2007, at 8:12 AM, David Jencks wrote: I certainly agree with your goal but am less sure about your proposed naming and organization. Also from looking at your list it took me a couple minutes to figure out what is removed from "server" I've been thinking that we could proceed by turning bits of the server into plugins. For instance I was planning to turn the directory bits I commented out recently into a plugin this week. I think we could fairly easiiy turn jetty, tomcat, and openejb into plugins. I wonder if, after turning the "easy stuff" into plugins what we will think about reorganizing the remaining stuff. So then the question might be how to organize the plugins? thanks david jencks On Aug 6, 2007, at 1:48 AM, Jason Dillon wrote: Hiya, I've mentioned this before... and now that we have a 2.0 branch and trunk has moved on to 2.1 work, I think its time we really make a decision on this and implement it. Before, I had been thinking of keeping all of the modules in the server/trunk tree just in better locations organized by functionality and feature not by artifact type. But, now I'm thinking we should really do one step more than that, and split up the server/trunk project into several smaller and more manageable chunks of modules. I still think that the basic grouping that we kinda talked about before should work fine, but instead of having them share a project namespace we give them their own. So, for example... server-support/trunk testsupport buildsupport server-framework/trunk geronimo-activation geronimo-client geronimo-client-builder geronimo-clustering geronimo-common geronimo-connector geronimo-connector-builder geronimo-core geronimo-deploy-config geronimo-deploy-jsr88 geronimo-deploy-jsr88-bootstrapper geronimo-deploy-tool geronimo-deployment geronimo-gbean-deployer geronimo-interceptor geronimo-j2ee geronimo-j2ee-builder geronimo-j2ee-schema geronimo-jmx-remoting geronimo-kernel geronimo-management geronimo-naming geronimo-naming-builder geronimo-security geronimo-security-builder geronimo-service-builder geronimo-system geronimo-test-ddbean geronimo-timer geronimo-transaction geronimo-transaction-jta11 geronimo-transformer geronimo-util geronimo-web-2.5-builder And then we can group some of the related components up into shared projects, or just go out and give each component its own project, and/or think about maybe using the same style that the maven/plugins/trunk tree uses, a shared project, but each component is related individually... still not sure I like that, kinda messy. I don't want to end up with a ton of projects either, and I certainly don't want to get up using SNAPSHOT versions of these puppies if we can help it. So, maybe to start out we could do these: server-support server-framework server-components server-assembly BTW, I'm using "dash" here so that the names don't collide with what is there now, but really we could user server/support/trunk, server/framework/trunk, etc (which is better IMO for the longer run). And in the process of making this split up, we can re-arrange modules by feature and function instead of
Re: Splitting up the server into a few more chunks
Um, I just took a blind stab in the dark... But, what I was thinking was that we have the core modules which are the bare minimum to boot up a functional Geronimo server w/o any JavaEE muck, then slice up the other components into plugins, though they don't really need to be G plugins, they just need to hold groups of modules to provide a components functionality and configuration. I also split up the support bits, as those should be common across the core framework bits and components/plugins... I'm certainly open to ideas and discussion on this. I think we really need to move in this direction. --jason On Aug 6, 2007, at 8:12 AM, David Jencks wrote: I certainly agree with your goal but am less sure about your proposed naming and organization. Also from looking at your list it took me a couple minutes to figure out what is removed from "server" I've been thinking that we could proceed by turning bits of the server into plugins. For instance I was planning to turn the directory bits I commented out recently into a plugin this week. I think we could fairly easiiy turn jetty, tomcat, and openejb into plugins. I wonder if, after turning the "easy stuff" into plugins what we will think about reorganizing the remaining stuff. So then the question might be how to organize the plugins? thanks david jencks On Aug 6, 2007, at 1:48 AM, Jason Dillon wrote: Hiya, I've mentioned this before... and now that we have a 2.0 branch and trunk has moved on to 2.1 work, I think its time we really make a decision on this and implement it. Before, I had been thinking of keeping all of the modules in the server/trunk tree just in better locations organized by functionality and feature not by artifact type. But, now I'm thinking we should really do one step more than that, and split up the server/trunk project into several smaller and more manageable chunks of modules. I still think that the basic grouping that we kinda talked about before should work fine, but instead of having them share a project namespace we give them their own. So, for example... server-support/trunk testsupport buildsupport server-framework/trunk geronimo-activation geronimo-client geronimo-client-builder geronimo-clustering geronimo-common geronimo-connector geronimo-connector-builder geronimo-core geronimo-deploy-config geronimo-deploy-jsr88 geronimo-deploy-jsr88-bootstrapper geronimo-deploy-tool geronimo-deployment geronimo-gbean-deployer geronimo-interceptor geronimo-j2ee geronimo-j2ee-builder geronimo-j2ee-schema geronimo-jmx-remoting geronimo-kernel geronimo-management geronimo-naming geronimo-naming-builder geronimo-security geronimo-security-builder geronimo-service-builder geronimo-system geronimo-test-ddbean geronimo-timer geronimo-transaction geronimo-transaction-jta11 geronimo-transformer geronimo-util geronimo-web-2.5-builder And then we can group some of the related components up into shared projects, or just go out and give each component its own project, and/or think about maybe using the same style that the maven/plugins/trunk tree uses, a shared project, but each component is related individually... still not sure I like that, kinda messy. I don't want to end up with a ton of projects either, and I certainly don't want to get up using SNAPSHOT versions of these puppies if we can help it. So, maybe to start out we could do these: server-support server-framework server-components server-assembly BTW, I'm using "dash" here so that the names don't collide with what is there now, but really we could user server/support/trunk, server/framework/trunk, etc (which is better IMO for the longer run). And in the process of making this split up, we can re-arrange modules by feature and function instead of by type... and actually we have to do that to make the components bits work. * * * I really believe this will help improve the support and maintainability of the server's code-base and it will help the project scale better as new components are added too. For developers that are only interested in working on a specific component, it reduces the amount of other sources they need to check out and reduces the time to build too, so that they can build a clean server assembly faster and developer their features sooner and hopefully have less hair-pulling and more relaxed beer drinking as they pat themselves on the back for doing such a speedy job. I really, really... really, really, really ( :-P ) think that we *must* move along these lines for the longer term health of the project... Comments? Suggestions? --jason
Re: Splitting up the server into a few more chunks
I certainly agree with your goal but am less sure about your proposed naming and organization. Also from looking at your list it took me a couple minutes to figure out what is removed from "server" I've been thinking that we could proceed by turning bits of the server into plugins. For instance I was planning to turn the directory bits I commented out recently into a plugin this week. I think we could fairly easiiy turn jetty, tomcat, and openejb into plugins. I wonder if, after turning the "easy stuff" into plugins what we will think about reorganizing the remaining stuff. So then the question might be how to organize the plugins? thanks david jencks On Aug 6, 2007, at 1:48 AM, Jason Dillon wrote: Hiya, I've mentioned this before... and now that we have a 2.0 branch and trunk has moved on to 2.1 work, I think its time we really make a decision on this and implement it. Before, I had been thinking of keeping all of the modules in the server/trunk tree just in better locations organized by functionality and feature not by artifact type. But, now I'm thinking we should really do one step more than that, and split up the server/trunk project into several smaller and more manageable chunks of modules. I still think that the basic grouping that we kinda talked about before should work fine, but instead of having them share a project namespace we give them their own. So, for example... server-support/trunk testsupport buildsupport server-framework/trunk geronimo-activation geronimo-client geronimo-client-builder geronimo-clustering geronimo-common geronimo-connector geronimo-connector-builder geronimo-core geronimo-deploy-config geronimo-deploy-jsr88 geronimo-deploy-jsr88-bootstrapper geronimo-deploy-tool geronimo-deployment geronimo-gbean-deployer geronimo-interceptor geronimo-j2ee geronimo-j2ee-builder geronimo-j2ee-schema geronimo-jmx-remoting geronimo-kernel geronimo-management geronimo-naming geronimo-naming-builder geronimo-security geronimo-security-builder geronimo-service-builder geronimo-system geronimo-test-ddbean geronimo-timer geronimo-transaction geronimo-transaction-jta11 geronimo-transformer geronimo-util geronimo-web-2.5-builder And then we can group some of the related components up into shared projects, or just go out and give each component its own project, and/or think about maybe using the same style that the maven/ plugins/trunk tree uses, a shared project, but each component is related individually... still not sure I like that, kinda messy. I don't want to end up with a ton of projects either, and I certainly don't want to get up using SNAPSHOT versions of these puppies if we can help it. So, maybe to start out we could do these: server-support server-framework server-components server-assembly BTW, I'm using "dash" here so that the names don't collide with what is there now, but really we could user server/support/trunk, server/framework/trunk, etc (which is better IMO for the longer run). And in the process of making this split up, we can re-arrange modules by feature and function instead of by type... and actually we have to do that to make the components bits work. * * * I really believe this will help improve the support and maintainability of the server's code-base and it will help the project scale better as new components are added too. For developers that are only interested in working on a specific component, it reduces the amount of other sources they need to check out and reduces the time to build too, so that they can build a clean server assembly faster and developer their features sooner and hopefully have less hair-pulling and more relaxed beer drinking as they pat themselves on the back for doing such a speedy job. I really, really... really, really, really ( :-P ) think that we *must* move along these lines for the longer term health of the project... Comments? Suggestions? --jason
