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-r568632----geronimo-server-trunk-assemblies-geronimo-framework-pom.xml-td12276842s134.html [5] http://www.nabble.com/Re%3A-micro-G-modules%28configs%29-p6721792s134.htmlMy 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
smime.p7s
Description: S/MIME Cryptographic Signature
