Mailing-List: contact dev-help@geronimo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@geronimo.apache.org
Received-SPF: pass (athena.apache.org: domain of linsun.unc@gmail.com
 designates 209.85.217.17 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:to:subject:in-reply-to:mime-version
         :content-type:content-transfer-encoding:content-disposition
         :references;
        b=IhTQ/x/Bu6T+zafSh2yBWJDLWvI31go2Zm3bSMus7FeAHaACJ8bL52TUw8pzmc9HOm
         RBofZJFpAykRZ3LhP+vI8+RlSICJJJhJ8x4+uo/dcU9fHva9pdoM6OYyCPlFQ2lEVKSN
         PoDGUHnhcCSNKDaGzZx/1tYIaU31ELhEM6Dhg=
Message-ID: <add18bc80808221040u594249c7w1f1450f62ef8f2d9@mail.gmail.com>
Date: Fri, 22 Aug 2008 13:40:47 -0400
From: "Lin Sun" <linsun.unc@gmail.com>
To: dev@geronimo.apache.org
Subject: Re: c-m-p plugin + geronimo plugin with no module-id
In-Reply-To: <7793DC31-709E-46C8-AACB-26549225CACB@yahoo.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <add18bc80808211926m7494fb14m86597d3da0320108@mail.gmail.com>
	 <F643FE2C-750A-4599-82E7-BCAF2B651468@yahoo.com>
	 <48AECE99.4050401@earthlink.net>
	 <7793DC31-709E-46C8-AACB-26549225CACB@yahoo.com>

I think I'd be fine either way but I would need this plugin group
function to enhance the existing custom assembly UI.

1. use no module-id to indicate the geronimo plugin is a plugin group.
  In this case, each assembly we ship will include geronimo plugin
group catalog file to keep track of what plugin groups it has.   When
a user selects to install such a plugin, it would only install the
plugin's dependencies.   So we won't see this type of plugin in the
repository.

2. with module-id but has some properties such as
<PluginGroup>true</PluginGroup> or <module-id pluginGroup="true">.  In
this case, when a user selects to install such a plugin, we'll install
the plugin and its dependencies, except that we won't register the
plugin's configId in server's config.xml.   I imagine this type of
plugin exists in the repository (sort of like an empty geronimo plugin
but with geronimo-plugin.xml in it).

I was learning towards No. 1 because we already have lots of code to
handle the cases where module-id is NULL and it makes sense to me that
we don't leave anything in the repository for this type of plugin
group, but I can go with whatever the community wants to go.

Lin

On Fri, Aug 22, 2008 at 12:15 PM, David Jencks <david_jencks@yahoo.com> wrote:
>
> On Aug 22, 2008, at 7:35 AM, Joe Bohn wrote:
>
>>
>> This is getting a bit tricky.  I agree that we want something like a
>> moduleID for the group of plugins so that it can be named in the catalog.
>
> My main reason for thinking it might be a good idea is that it makes it more
> plausible as a standalone artifact.  Everyone seems to be thinking in terms
> of generating or publishing them with the c-m-p which means I think that
> they will have an associated moduleID from the maven project.
>>
>>
>> It would also be nice if we could persist this knowledge in the server
>> image.
>>
>> So, if you created a server using the Tomcat group, the JMS group, and the
>> Axis2 group you could choose to later remove the Axis2 group rather than
>> being required to "know" that it contained Axis2 & Axis2-deployer.
>>
>> This lack of persistence has also been a problem with plugins. They are
>> install time entities that are not manageable in the server after
>> installation (there's no uninstall for a plugin per se but you could
>> certainly uninstall a car).  We're just seeing the same issue now at a
>> higher level as we discuss groups of plugins.
>
> I've thought about this in the past and decided that this is a nearly
> unsolvable problem and that it is much better to start over and assemble a
> new server containing what you want.
>
> The problems come when you try to figure out what should be in
> config-substitutions and artifact-aliases after removing a plugin that
> changed them.  The plugin might have overwritten some other values.  The
> user might or might not have changed them by hand.  WIthout a complete
> history of each file I don't see how to uninstall a plugin and come up with
> something plausible.  I don't think the utility of beinga able to remove
> plugins is worth the uncertainty and complexity of maintaining this history.
>  So, for now I don't want to support removing plugins.
>
>
> thanks
> david jencks
>
>>
>>
>> I'm not proposing that we have to solve this bigger issue right now.  I
>> think it makes sense to find someway to deal with groups of plugins just at
>> the install level just as Lin is already doing.  This is necessary to make
>> the server assembly more user friendly.  However, at some point (possibly
>> soon) I think we are going to have to start rethinking what the manageable
>> entities are for a Geronimo server and the lifecycle of these entities.
>>
>> BTW, I like the idea of distributing the geronimo-plugin.xml files ... it
>> definitely gives us something to hang-on-to for possible manageability and
>> might be all that we need.
>>
>> Joe
>>
>>
>> David Jencks wrote:
>>>
>>> On Aug 21, 2008, at 7:26 PM, Lin Sun wrote:
>>>>
>>>> Hi,
>>>>
>>>> I have been looking at c-m-p plugin and geronimo plugin with no
>>>> module-id today, as David reminded me in the other thread about this
>>>> function.   I'd like to use this function for the custom server
>>>> assembly stuff I am working on, as it is similar as groups of plugins
>>>> I was initially proposing.
>>>>
>>>> It looks like we do have code to handle module-id = null in plugin
>>>> metadata, but i have not been successful in creating a geronimo plugin
>>>> that doesn't have a module-id using c-m-p.  is this possible w/ the
>>>> current c-m-p?     Anyone has an example on this type of geronimo
>>>> plugin?    Would this type of plugin just contain a META-INF directory
>>>> with geronimo-plugin.xml in the directory?
>>>
>>> I'm not sure how much sense it makes to use the c-m-p to generate a
>>> geronimo-plugin.xml with no moduleId.  IIRC the original idea (from Aaron)
>>> was to just have the entry in the plugin catalog.  Without a moduleId you
>>> can't put it in the maven repo (IMO).  So, maybe we do want a moduleId but
>>> make it so nothing gets into any config.xml???
>>> I've started to wonder if we should distribute the geronimo-plugin.xml
>>> files as attached artifacts with a geronimo-plugin classifier so they are
>>> more readily available as plain files.
>>> still thinking.....
>>> david jencks
>>>>
>>>>
>>>> Thanks,
>>>>
>>>> Lin
>>
>
>