geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Lin Sun" <linsun....@gmail.com>
Subject Re: [DISCUSS] plugingroups - another idea
Date Sat, 13 Sep 2008 02:54:19 GMT
For option 1, I guess I don't understand why we need the classLoader
attribute.   I think for plugin groups, we should not add the plugin
group itself to the classloader, but we should add the dependencies to
the classloader.   For instance, if we support Joe's scenario, when a
user specifies a plugin group as a dependency in his deployment plan,
it would just add the dependencies that the plugin group depends on to
the project's classloader.   This is similar as the plugin installer,
which would skip the installation of the plugin group itself but
installs its dependencies.

For option 2, users might want to create functional plugin groups
themselves.  If we hardcode values like
groupId=org.apache.geronimo.profiles, we won't allow users to build
custom servers out of the plugin groups they created.  Also, I don't
think we always want to create a classloader.  Last time, when I tried
to have my plugin group as car format, which created a classloader,
server started the plugin group and my server stopped function after
one or two deploy commands.

Lin

On Fri, Sep 12, 2008 at 11:53 AM, Donald Woods <dwoods@apache.org> wrote:
> OK, two options come to mind.
>
> 1) Use 2 plugin attributes:
> - pluginGroup to denote this plugin is only for server assembly views
> - classLoader to allow us to disable classloader creation for any plugin
>
> 2) Go back to what we had and keep the pluginpgroups grouped together:
> - always create a classLoader (still not sure why we wanted to aviod this
> for some cases)
> - drop the pluginGroup attribute
> - change the server assembly UI code to treat only plugins with
> groupId=org.apache.geronimo.profiles (or something similar) as plugins to
> display for the function/profile assembly path
>
>
> -Donald
>
>
>
> Joe Bohn wrote:
>>
>> Donald Woods wrote:
>>>
>>> Becoming clearer now...
>>>
>>> For #1, maybe we should replace <pluginGroup> with a <createClassloader>
>>> attribute, which would be true by default.  If set to false, then we
>>> wouldn't add to config.xml or create a classloader.
>>
>> I think there are 3 different goals being tossed around here:
>> A. Differentiating plugins that are intended to be large enough building
>> blocks for most users vs. those that are more granular and intended really
>> only for expert users.
>> B. Using plugingroups wherever plugins are used today so the user is
>> dealing with consistent concepts (this may just be my personal goal).
>> C. Elimination of classloaders if they are not needed for architectural
>> purity.
>>
>> I was proposing using the pluginGroup attribute as just a categorization
>> to achieve A.  I was proposing making everything a regular plugin (with a
>> classloader) to achieve B.  And ... I was hoping to eliminate C to
>> facilitate B.
>>
>>
>>>
>>> After making the above change, the creation of special plugin groups
>>> which are jar files would go away and everything would be a CAR again, which
>>> would allow any plugin (whether it creates a classloader or not) to be
>>> installed through all of the existing methods (plugin installer, server
>>> assembler or at application deployment.)
>>
>> I think if we must have the no-classloader option then we will have to add
>> some special logic in place to address dependencies that a user might place
>> on these special plugins that do not contain classloaders. I assume that
>> logic would be to flag an error and prevent users from deploying a plugin
>> that has a dependency on a plugingroup with noclassloader.  I think we also
>> need to make this clear in the doc.  I don't think that the no-classloader
>> option replaces the plugingroup option because I think we still need that
>> categorization for A.
>>
>> My head is spinning a bit, but I think this may be a good compromise.  I
>> think it make the plugingroups more general purpose, gives the user just one
>> primary set of objects to deal with for all 3 cases where plugins are
>> primarily used today, and addresses the architectural purity concerns in the
>> case where a particular plugingroup has no possible value as a dependency of
>> another plugin.
>>
>> Joe
>>
>>
>>>
>>>
>>> -Donald
>>>
>>>
>>> Jarek Gawor wrote:
>>>>
>>>> Joe,
>>>>
>>>> I think I understand what you are saying. First, there are two key
>>>> issues about plugin groups as of right now:
>>>>
>>>> 1) The geronimo-plugin.xml for plugin groups have
>>>> <pluginGroup>true</pluginGroup> element set to indicate the plugin
is
>>>> a plugin group.
>>>> 2) The plugin groups are packaged as jars.
>>>>
>>>> About #2:
>>>>
>>>> Since the plugin groups are packaged as jars (and if I understand
>>>> things correctly), the plugin group does not show up in the
>>>> config.xml, there is no classloader associated with the plugin group,
>>>> and plugin group will not show up in the
>>>> ~/.m2/repository/geronimo-plugin.xml file. Since the global
>>>> geronimo-plugin.xml is not updated, it basically means you won't be
>>>> able to see any plugin groups under console->install plugins no matter
>>>> which remote or local repo you point to. The plugin groups will only
>>>> show up under the console->assemble server (which will only show you
>>>> already installed plugin groups).
>>>>
>>>> So yes, plugin groups right now are very "assemble a server" specific.
>>>> If we turn the plugin groups into cars we would get a lot more
>>>> flexibility: classloaders, remote install of plugin groups, etc.
>>>>
>>>> About #1:
>>>>
>>>> I think the "pluginGroup" element in geronimo-plugin.xml is really
>>>> only used for classification purposes. That is, so that the plugin
>>>> appears under the right menu in the console or the CLI tool. And if
>>>> so, we could probably make this a bit more generic and introduce some
>>>> sort of tagging to geronimo-plugin.xml. For example, we could allow a
>>>> zero or more arbitrary tags to be associated with the given plugin.
>>>> The console or the CLI tools would then present a list of tag names to
>>>> the user. The user could choose one or more tags which would resolve
>>>> to multiple plugins.
>>>> This could also be an alternative solution to plugin groups where
>>>> multiple plugins tagged with the same tag would constitute a plugin
>>>> group (so there would be no need for a separate maven module for each
>>>> plugin group).
>>>>
>>>> Jarek
>>>>
>>>> On Thu, Sep 11, 2008 at 5:26 PM, Joe Bohn <joe.bohn@earthlink.net>
>>>> wrote:
>>>>>
>>>>> I've been thinking about plugingroups and I'm wondering why we need to
>>>>> make
>>>>> them very much different than regular plugins.
>>>>>
>>>>> We've been primarily focused on plugingroups as a way of simplifying
>>>>> the
>>>>> creation of a custom server assembly.  That's a good use of
>>>>> plugingroups.
>>>>>  However, perhaps it isn't the only use.   Because we've been primarily
>>>>> thinking of them as server assembly bits we've been looking to remove
>>>>> some
>>>>> of the regular plugin functions from them ... like the classloaders
>>>>> they
>>>>> create and their entries in config.xml.
>>>>>
>>>>> So the question is; can plugingroups be used in other ways and would
>>>>> the
>>>>> classloaders, etc... be useful in those other scenarios?
>>>>>
>>>>> Perhaps a user or solution provider has a need to create a core set of
>>>>> plugins and then "bundle" them together into higher function
>>>>> plugingroups
>>>>> (just as we want to do with the server bits).  Their customers could
>>>>> then
>>>>> create their own applications and include dependencies on these
>>>>> plugingroups.  These plugingroups might also be of value for a user to
>>>>> install on a server independently.  I think our users could also
>>>>> benefit
>>>>> from this by creating dependencies on our plugingroups rather than
>>>>> individual plugins.  A user could create an application that requires
>>>>> tomcat, web services with cxf, and jms.  It would be nice if they could
>>>>> reference the plugingroups as dependencies when building a plugin via
>>>>> maven
>>>>> rather than having to reference the individual plugins.
>>>>>
>>>>> IIUC, our current direction is that a user would deal with one set of
>>>>> components (plugingroups) when building a server ... but a different
>>>>> set of
>>>>> components (plugins) when creating their own application plugin (at
>>>>> least I
>>>>> think that would be the case).  Also, I suspect we would have to
>>>>> include
>>>>> additional capabilities in Geronimo to protect against a user
>>>>> attempting to
>>>>> add a dependency on a plugingroup.  I'm concerned that making the
>>>>> plugingroups too specialized results in more work for us and less
>>>>> capability
>>>>> for the end user.
>>>>>
>>>>> If we just let the regular processing occur for plugins that aggregate
>>>>> other
>>>>> plugins (plugingroups), then I think the user could leverage the plugin
>>>>> groups in many different ways and we'd have fewer issues.
>>>>>
>>>>> How we actually work the internal details to construct classloaders
>>>>> could
>>>>> still be enhanced to eventually "skip" the aggregate objects and drill
>>>>> to
>>>>> the next level for plugingroups ... but I think that's really an
>>>>> independent
>>>>> issue and an optimization.
>>>>>
>>>>> So, the proposal I was thinking of was simply this:
>>>>> 1) Create plugin groups as any other plugin and let our current
>>>>> processing
>>>>> deal with them as any other plugin.  The classloader that is created
>>>>> might
>>>>> actually be useful.  The config.xml entry probably is not, but is it
>>>>> really
>>>>> causing any problems?
>>>>> 2) Use the plugin group attribute more as a way of classification
>>>>> rather
>>>>> than function enhancement (at least for now).  We can always decide to
>>>>> leverage this knowledge more completely to optimize classloader
>>>>> construction
>>>>> or for other purposes such as organization.
>>>>> 3) Leave the assembly construction GUI/commandline and plugin install
>>>>> GUI/commandline to work with plugins only ... no differentiation with
>>>>> plugingroups.
>>>>> 4) To help clear the clutter from those GUIs/commandlines (one of the
>>>>> primary motivations in the recent effort) we could create different
>>>>> plugin
>>>>> catalogs.   The default catalog could primarily include the
>>>>> plugingroups and
>>>>> perhaps a few specific plugins that don't merit further aggregation.
>>>>>  An
>>>>> expert catalog would be the complete catalog with all plugins included.
>>>>>  These same catalogs would be used when installing plugins and
>>>>> constructing
>>>>> server assemblies so there would be some consistency for the user.
>>>>> 5) The same set of plugins and plugingroups would be available as
>>>>> dependencies when a user builds their own plugin via maven.
>>>>>
>>>>> I think this would broaden the usefulness of plugin groups.
>>>>>
>>>>> thoughts?
>>>>>
>>>>>
>>>>> BTW, why are the current plugingroups jars rather than cars ... and why
>>>>> don't they appear in the geronimo-plugins.xml?
>>>>>
>>>>> Joe
>>>>>
>>>>
>>>
>>
>>
>

Mime
View raw message