While David is more interested in the philosophy, I'd prefer to know a little bit more about your thoughts on implementation. Specifically what do you imagine would be involved in defining this configuration? Would it be as simple as a definition in config.xml?
On Thu, Oct 16, 2008 at 4:08 AM, Gianny Damour < [EMAIL PROTECTED]> wrote: > Hi David, > > You are correct: the underpinning philosophy of these approaches is to make > it easier to modify pre-canned plugins through extension points. > > This may be a good approach to improve further the packaging model of > dependencies and services. Let's say that an end-user wants to add a > connector to the tomcat6 plugin. Instead of using the admin console or > updating his config.xml, he can simply deploy a cumulative plan. This notion > of cumulative plan is the key differentiator as users can share their > cumulative plans "as-is" - i.e. w/o knowing what the plugin to be modified > looks like. To some extent, providing a plan ready to be deployed instead > of deployment instructions is better for novices. > > I will work on the Groovy builder approach and post back more details as I > go. > > Thanks, > Gianny > > > On 16/10/2008, at 10:59 AM, David Jencks wrote: > > Hi Gianny, >> >> First, I'd like to make sure I understand the philosophy behind your >> proposals. IIUC they both involve the idea of making it easy to modify an >> existing plugin rather than making it easy to replace an existing plugin >> with a similar one. >> >> Why is this a good idea? My idea has been that we should make it easier >> to replace a plugin with a similar one than modify an existing one, and then >> we will have the best of all worlds. >> >> All this being said, I think your ideas are both quite interesting. I'm >> especially interested in the groovy builder approach. >> >> I'll be fairly unavailable until next week but might keep thinking about >> this anyway. >> >> thanks! >> david jencks >> On Oct 15, 2008, at 3:46 AM, Gianny Damour wrote: >> >> On 15/10/2008, at 4:16 AM, David Jencks wrote: >>> >>> That's one of the main missing bits of functionality. Right now the >>>> only way to get the g-p.xml is to use c-m-p or to export the plugin from a >>>> server it's been deployed into, or to do something by hand with jar packing >>>> and unpacking. >>>> >>>> The biggest problem here, in my mind, is that jsr88 only wants you to >>>> have one "plan": to deploy something you get to specify the artifact and >>>> one >>>> "plan". Our deployment system is built around jsr88 so we either have to >>>> condense the g-p.xml and plan into one "plan" or abandon jsr88. >>>> >>>> At the moment I'm thinking that one satisfactory solution might be to >>>> more or less embed the plan into g-p.xml. Perhaps we could avoid >>>> duplicating most of the dependency info by adding the <import> element to >>>> the dependencies in g-p.xml. I guess we'd expect a more or less empty >>>> <environment> element in the plan and fill in the dependencies from the >>>> g-p.xml when deploying. >>>> >>>> I guess another possibility might be to include the info from g-p.xml in >>>> the environment element of the plan. >>>> >>>> I've been thinking about this on and off for a long time and don't have >>>> any solution I'm entirely happy with so discussion and more ideas are more >>>> than welcome :-) >>>> >>> >>> Hi, >>> >>> Another possible solution would be to allow the extension of a given >>> configuration by other configurations. This could work like the web.xml >>> fragment mechanism of the upcoming servlet specs which allows framework >>> libraries to transparently install Web components to the baseline components >>> defined by the web.xml DD. >>> >>> When a configuration starts it looks for complementing configurations >>> whose responsibility is to alter the baseline configuration. The >>> identification of complementing configurations could be based on a simple >>> naming convention scheme, e.g. if the base configuration is org/tomcat6//car >>> then all the configurations matching the pattern >>> org/tomcat6-transform-DiscriminatorName//car are identified as complementing >>> configurations. >>> >>> If there are complementing configurations, then the baseline >>> ConfigurationData could be passed to them for arbitrary transformation, e.g. >>> add, update or remove dependencies. An updated ConfigurationData is passed >>> back and actually loaded by the kernel. >>> >>> The main drawback of this approach is the added configuration complexity. >>> The main benefits is that it provides application server configuration >>> traceability and a mean to perform very simple changes to a baseline >>> configuration w/o having to redefine in its entirety the configuration to be >>> slightly changed. >>> >>> In another thread about scripting language integration, I suggested an >>> even simpler approach whereby a script is executed to perform >>> ConfigurationData transformations. >>> >>> If any of these two options are plausible solutions, then I am happy to >>> move forward with an implementation. >>> >>> Thanks, >>> Gianny >>> >>> >>>> thanks >>>> david jencks >>>> >>>> >> > -- ~Jason Warner
