You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by Donald Woods <dw...@apache.org> on 2008/10/08 05:03:16 UTC
Re: svn commit: r702586 - in /geronimo/server/trunk/plugingroups/console-jetty:
./ pom.xml src/ src/main/ src/main/history/ src/main/history/dependencies.xml
src/main/plan/
Why are we recreating the existing console-jetty and console-tomcat as
yet another plugin?
Also, why are you including optional console plugins like
activemq-console-xxx, which should only be included if the ActiveMQ
plugins are installed? By including it here, you're basically pulling
in the JMS plugins.
I'm starting to reconsider why we need plugingroups, if we're going to
have to recreate dozens of existing plugins just in a slightly different
format just so we can include them in a special view just for custom
server assemblies....
-Donald
linsun@apache.org wrote:
> Author: linsun
> Date: Tue Oct 7 12:09:59 2008
> New Revision: 702586
>
> URL: http://svn.apache.org/viewvc?rev=702586&view=rev
> Log:
> Add the console-jetty plugin group
>
> Added:
> geronimo/server/trunk/plugingroups/console-jetty/
> geronimo/server/trunk/plugingroups/console-jetty/pom.xml (with props)
> geronimo/server/trunk/plugingroups/console-jetty/src/
> geronimo/server/trunk/plugingroups/console-jetty/src/main/
> geronimo/server/trunk/plugingroups/console-jetty/src/main/history/
> geronimo/server/trunk/plugingroups/console-jetty/src/main/history/dependencies.xml (with props)
> geronimo/server/trunk/plugingroups/console-jetty/src/main/plan/
>
> Added: geronimo/server/trunk/plugingroups/console-jetty/pom.xml
> URL: http://svn.apache.org/viewvc/geronimo/server/trunk/plugingroups/console-jetty/pom.xml?rev=702586&view=auto
> ==============================================================================
> --- geronimo/server/trunk/plugingroups/console-jetty/pom.xml (added)
> +++ geronimo/server/trunk/plugingroups/console-jetty/pom.xml Tue Oct 7 12:09:59 2008
> @@ -0,0 +1,98 @@
> +<?xml version="1.0" encoding="ISO-8859-1"?>
> +<!--
> + Licensed to the Apache Software Foundation (ASF) under one
> + or more contributor license agreements. See the NOTICE file
> + distributed with this work for additional information
> + regarding copyright ownership. The ASF licenses this file
> + to you under the Apache License, Version 2.0 (the
> + "License"); you may not use this file except in compliance
> + with the License. You may obtain a copy of the License at
> +
> + http://www.apache.org/licenses/LICENSE-2.0
> +
> + Unless required by applicable law or agreed to in writing,
> + software distributed under the License is distributed on an
> + "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
> + KIND, either express or implied. See the License for the
> + specific language governing permissions and limitations
> + under the License.
> +-->
> +<!-- @version $Rev$ $Date$ -->
> +
> +<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">
> +
> + <modelVersion>4.0.0</modelVersion>
> +
> + <parent>
> + <groupId>org.apache.geronimo.plugingroups</groupId>
> + <artifactId>plugingroups</artifactId>
> + <version>2.2-SNAPSHOT</version>
> + </parent>
> +
> + <artifactId>console-jetty</artifactId>
> + <packaging>car</packaging>
> + <name>Geronimo Plugin Group :: Admin Console Jetty</name>
> +
> + <description>
> + This plugin group provides Admin Console Jetty functionality.
> + </description>
> +
> + <dependencies>
> + <dependency>
> + <groupId>org.apache.geronimo.configs</groupId>
> + <artifactId>ca-helper-jetty</artifactId>
> + <version>${version}</version>
> + <type>car</type>
> + </dependency>
> +
> + <dependency>
> + <groupId>org.apache.geronimo.plugins</groupId>
> + <artifactId>agent</artifactId>
> + <version>${version}</version>
> + <type>car</type>
> + </dependency>
> +
> + <dependency>
> + <groupId>org.apache.geronimo.plugins</groupId>
> + <artifactId>mconsole-jetty</artifactId>
> + <version>${version}</version>
> + <type>car</type>
> + </dependency>
> +
> + <dependency>
> + <groupId>org.apache.geronimo.plugins</groupId>
> + <artifactId>activemq-console-jetty</artifactId>
> + <version>${version}</version>
> + <type>car</type>
> + </dependency>
> +
> + <dependency>
> + <groupId>org.apache.geronimo.plugins</groupId>
> + <artifactId>debugviews-console-jetty</artifactId>
> + <version>${version}</version>
> + <type>car</type>
> + </dependency>
> +
> + <dependency>
> + <groupId>org.apache.geronimo.plugins</groupId>
> + <artifactId>plancreator-console-jetty</artifactId>
> + <version>${version}</version>
> + <type>car</type>
> + </dependency>
> +
> + <dependency>
> + <groupId>org.apache.geronimo.plugins</groupId>
> + <artifactId>plugin-console-jetty</artifactId>
> + <version>${version}</version>
> + <type>car</type>
> + </dependency>
> +
> + <dependency>
> + <groupId>org.apache.geronimo.plugins</groupId>
> + <artifactId>sysdb-console-jetty</artifactId>
> + <version>${version}</version>
> + <type>car</type>
> + </dependency>
> + </dependencies>
> +</project>
> +
>
> Propchange: geronimo/server/trunk/plugingroups/console-jetty/pom.xml
> ------------------------------------------------------------------------------
> svn:eol-style = native
>
> Propchange: geronimo/server/trunk/plugingroups/console-jetty/pom.xml
> ------------------------------------------------------------------------------
> svn:keywords = Date Revision
>
> Propchange: geronimo/server/trunk/plugingroups/console-jetty/pom.xml
> ------------------------------------------------------------------------------
> svn:mime-type = text/xml
>
> Added: geronimo/server/trunk/plugingroups/console-jetty/src/main/history/dependencies.xml
> URL: http://svn.apache.org/viewvc/geronimo/server/trunk/plugingroups/console-jetty/src/main/history/dependencies.xml?rev=702586&view=auto
> ==============================================================================
> --- geronimo/server/trunk/plugingroups/console-jetty/src/main/history/dependencies.xml (added)
> +++ geronimo/server/trunk/plugingroups/console-jetty/src/main/history/dependencies.xml Tue Oct 7 12:09:59 2008
> @@ -0,0 +1,49 @@
> +<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
> +<plugin-artifact xmlns:ns2="http://geronimo.apache.org/xml/ns/attributes-1.2" xmlns="http://geronimo.apache.org/xml/ns/plugins-1.3">
> + <module-id>
> + <groupId>org.apache.geronimo.plugingroups</groupId>
> + <artifactId>console-jetty</artifactId>
> + <version>2.2-SNAPSHOT</version>
> + <type>car</type>
> + </module-id>
> + <dependency>
> + <groupId>org.apache.geronimo.plugins</groupId>
> + <artifactId>plancreator-console-jetty</artifactId>
> + <type>car</type>
> + </dependency>
> + <dependency>
> + <groupId>org.apache.geronimo.plugins</groupId>
> + <artifactId>sysdb-console-jetty</artifactId>
> + <type>car</type>
> + </dependency>
> + <dependency>
> + <groupId>org.apache.geronimo.plugins</groupId>
> + <artifactId>activemq-console-jetty</artifactId>
> + <type>car</type>
> + </dependency>
> + <dependency>
> + <groupId>org.apache.geronimo.plugins</groupId>
> + <artifactId>plugin-console-jetty</artifactId>
> + <type>car</type>
> + </dependency>
> + <dependency>
> + <groupId>org.apache.geronimo.configs</groupId>
> + <artifactId>ca-helper-jetty</artifactId>
> + <type>car</type>
> + </dependency>
> + <dependency>
> + <groupId>org.apache.geronimo.plugins</groupId>
> + <artifactId>debugviews-console-jetty</artifactId>
> + <type>car</type>
> + </dependency>
> + <dependency>
> + <groupId>org.apache.geronimo.plugins</groupId>
> + <artifactId>mconsole-jetty</artifactId>
> + <type>car</type>
> + </dependency>
> + <dependency>
> + <groupId>org.apache.geronimo.plugins</groupId>
> + <artifactId>agent</artifactId>
> + <type>car</type>
> + </dependency>
> +</plugin-artifact>
>
> Propchange: geronimo/server/trunk/plugingroups/console-jetty/src/main/history/dependencies.xml
> ------------------------------------------------------------------------------
> svn:eol-style = native
>
> Propchange: geronimo/server/trunk/plugingroups/console-jetty/src/main/history/dependencies.xml
> ------------------------------------------------------------------------------
> svn:keywords = Date Revision
>
> Propchange: geronimo/server/trunk/plugingroups/console-jetty/src/main/history/dependencies.xml
> ------------------------------------------------------------------------------
> svn:mime-type = text/xml
>
>
>
Re: svn commit: r702586 - in /geronimo/server/trunk/plugingroups/console-jetty: ./ pom.xml src/ src/main/ src/main/history/ src/main/history/dependencies.xml src/main/plan/
Posted by Lin Sun <li...@gmail.com>.
NP - comments are always welcomed! :)
I agree with the difference you mentioned below and I think those are
unresolved and no one is really working on it.
Lin
On Wed, Oct 8, 2008 at 10:19 PM, Joe Bohn <jo...@earthlink.net> wrote:
> Lin Sun wrote:
> Sorry ... it had been a while since I last looked at this. I was
> erroneously thinking that there were still fundamental differences between
> plugins and plugingroups (such as when plugingroups were jars rather than
> cars and as a result weren't included in the plugin catalog) ... but these
> differences have been eliminated. The only significant difference now is
> the lack of a classloader (which is really controlled by the lack of the
> plan rather than the presence of the plugingroup attribute) and potential
> dependency issue when a classloader isn't present.
>
Re: svn commit: r702586 - in /geronimo/server/trunk/plugingroups/console-jetty:
./ pom.xml src/ src/main/ src/main/history/ src/main/history/dependencies.xml
src/main/plan/
Posted by Joe Bohn <jo...@earthlink.net>.
Lin Sun wrote:
> Hi Joe,
>
> I am having trouble to understand the difference between what you
> propose & what has already been done.
>
> Basically, IIUC, you propose to use a plugin for plugin group, with
> the attribute of pluginGroup=true to indicate that is a plugin group.
> This is exactly what has been done today, as we don't differenriate
> plugin group any other way other than the attribute of pluginGroup.
> If I misunderstand you, could you please give a concrete example?
Sorry ... it had been a while since I last looked at this. I was
erroneously thinking that there were still fundamental differences
between plugins and plugingroups (such as when plugingroups were jars
rather than cars and as a result weren't included in the plugin catalog)
... but these differences have been eliminated. The only significant
difference now is the lack of a classloader (which is really controlled
by the lack of the plan rather than the presence of the plugingroup
attribute) and potential dependency issue when a classloader isn't present.
>
> P.S. I think you were shot down by David because of the complexity of
> having plugin groups listed as dependencies on the geronimo specific
> plans.
>
> Lin
>
> On Wed, Oct 8, 2008 at 4:10 PM, Joe Bohn <jo...@earthlink.net> wrote:
>> I agree that groups of plugins are useful and perhaps necessary from a user
>> perspective to help eliminate the clutter. However, there are several ways
>> to provide for those groups.
>>
>> The way that has thus far been pursued has been creating a new module type
>> (is that what you would call it?) of plugingroup.
>>
>> I had proposed earlier that we just use plugins for this purpose. We can
>> create plugins that do nothing more than aggregate other more granular
>> plugins. We could still keep the attribute of plugin-group around as a
>> qualifier to filter out these special "aggregate plugins" from among all of
>> the other plugins when necessary (such as when assembling a server or to
>> present the user with a non-expert view of plugin management). When I
>> proposed this earlier I was shot down because of the classloader creation.
>> However, since David included a change to omit the classloader if there is
>> no plan ... then perhaps there is no real inhibitor to this approach now
>> since a plan is not needed for an aggregate plugin.
>>
>> I originally favored this approach because I felt it was the most intuitive
>> approach, ensured that the groupings of plugins could participate in any
>> scenario that a plugin can participate in today, and had the least
>> code/maintenance impacts. I think those benefits still hold with the
>> possible exception of the classloader change and what that may mean when an
>> aggregate plugin is used as a dependency which might require a little more
>> effort to resolve.
>>
>> Joe
>
Re: svn commit: r702586 - in /geronimo/server/trunk/plugingroups/console-jetty: ./ pom.xml src/ src/main/ src/main/history/ src/main/history/dependencies.xml src/main/plan/
Posted by Lin Sun <li...@gmail.com>.
Hi Joe,
I am having trouble to understand the difference between what you
propose & what has already been done.
Basically, IIUC, you propose to use a plugin for plugin group, with
the attribute of pluginGroup=true to indicate that is a plugin group.
This is exactly what has been done today, as we don't differenriate
plugin group any other way other than the attribute of pluginGroup.
If I misunderstand you, could you please give a concrete example?
P.S. I think you were shot down by David because of the complexity of
having plugin groups listed as dependencies on the geronimo specific
plans.
Lin
On Wed, Oct 8, 2008 at 4:10 PM, Joe Bohn <jo...@earthlink.net> wrote:
> I agree that groups of plugins are useful and perhaps necessary from a user
> perspective to help eliminate the clutter. However, there are several ways
> to provide for those groups.
>
> The way that has thus far been pursued has been creating a new module type
> (is that what you would call it?) of plugingroup.
>
> I had proposed earlier that we just use plugins for this purpose. We can
> create plugins that do nothing more than aggregate other more granular
> plugins. We could still keep the attribute of plugin-group around as a
> qualifier to filter out these special "aggregate plugins" from among all of
> the other plugins when necessary (such as when assembling a server or to
> present the user with a non-expert view of plugin management). When I
> proposed this earlier I was shot down because of the classloader creation.
> However, since David included a change to omit the classloader if there is
> no plan ... then perhaps there is no real inhibitor to this approach now
> since a plan is not needed for an aggregate plugin.
>
> I originally favored this approach because I felt it was the most intuitive
> approach, ensured that the groupings of plugins could participate in any
> scenario that a plugin can participate in today, and had the least
> code/maintenance impacts. I think those benefits still hold with the
> possible exception of the classloader change and what that may mean when an
> aggregate plugin is used as a dependency which might require a little more
> effort to resolve.
>
> Joe
Re: svn commit: r702586 - in /geronimo/server/trunk/plugingroups/console-jetty:
./ pom.xml src/ src/main/ src/main/history/ src/main/history/dependencies.xml
src/main/plan/
Posted by Joe Bohn <jo...@earthlink.net>.
I agree that groups of plugins are useful and perhaps necessary from a
user perspective to help eliminate the clutter. However, there are
several ways to provide for those groups.
The way that has thus far been pursued has been creating a new module
type (is that what you would call it?) of plugingroup.
I had proposed earlier that we just use plugins for this purpose. We
can create plugins that do nothing more than aggregate other more
granular plugins. We could still keep the attribute of plugin-group
around as a qualifier to filter out these special "aggregate plugins"
from among all of the other plugins when necessary (such as when
assembling a server or to present the user with a non-expert view of
plugin management). When I proposed this earlier I was shot down
because of the classloader creation. However, since David included a
change to omit the classloader if there is no plan ... then perhaps
there is no real inhibitor to this approach now since a plan is not
needed for an aggregate plugin.
I originally favored this approach because I felt it was the most
intuitive approach, ensured that the groupings of plugins could
participate in any scenario that a plugin can participate in today, and
had the least code/maintenance impacts. I think those benefits still
hold with the possible exception of the classloader change and what that
may mean when an aggregate plugin is used as a dependency which might
require a little more effort to resolve.
Joe
Lin Sun wrote:
> There is no doubt that framework is useful, but I think most of the
> other plugin groups are useful too (for example web-jetty, web-tomcat,
> or the javaee5-jetty, javaee5-tomcat). It is almost impossible to
> come up those quickly for a new geronimo user.
> With plugin groups, I can see users pick any of the plugin group(s)
> and plus their applications from their existing server to build a new
> working server easily.
>
> Some of the plugin groups may sound very simple and small and there
> doesn't seem to be a need for them, for example the jms or jsf plugin
> group. But for a new user (keep in mind that you guys are geronimo
> experts!!), it is not that obvious to them which modules can get them
> to the jms function. First, they need to understand activemq is the
> JMS impl in geronimo; Second they need to find out all the modules
> that are jms/activemq related and figure out which ones they need.
> By grouping them together, users can get the function with one click
> or command (specify the plugin group as the plugin to be installed via
> admin console or command line). Thus I think they add some
> convenience to the user. I think I am open to remove these type of
> plugin groups if you guys strongly prefer that.
>
> Lin
>
> On Wed, Oct 8, 2008 at 12:42 PM, David Jencks <da...@yahoo.com> wrote:
>> I'm also getting worried that the plugin groups are starting to duplicate
>> the plugins and wondering if the concept is providing significant value
>> beyond the framework plugin group.
>
Re: svn commit: r702586 - in /geronimo/server/trunk/plugingroups/console-jetty: ./ pom.xml src/ src/main/ src/main/history/ src/main/history/dependencies.xml src/main/plan/
Posted by Lin Sun <li...@gmail.com>.
There is no doubt that framework is useful, but I think most of the
other plugin groups are useful too (for example web-jetty, web-tomcat,
or the javaee5-jetty, javaee5-tomcat). It is almost impossible to
come up those quickly for a new geronimo user.
With plugin groups, I can see users pick any of the plugin group(s)
and plus their applications from their existing server to build a new
working server easily.
Some of the plugin groups may sound very simple and small and there
doesn't seem to be a need for them, for example the jms or jsf plugin
group. But for a new user (keep in mind that you guys are geronimo
experts!!), it is not that obvious to them which modules can get them
to the jms function. First, they need to understand activemq is the
JMS impl in geronimo; Second they need to find out all the modules
that are jms/activemq related and figure out which ones they need.
By grouping them together, users can get the function with one click
or command (specify the plugin group as the plugin to be installed via
admin console or command line). Thus I think they add some
convenience to the user. I think I am open to remove these type of
plugin groups if you guys strongly prefer that.
Lin
On Wed, Oct 8, 2008 at 12:42 PM, David Jencks <da...@yahoo.com> wrote:
> I'm also getting worried that the plugin groups are starting to duplicate
> the plugins and wondering if the concept is providing significant value
> beyond the framework plugin group.
Re: svn commit: r702586 - in /geronimo/server/trunk/plugingroups/console-jetty: ./ pom.xml src/ src/main/ src/main/history/ src/main/history/dependencies.xml src/main/plan/
Posted by David Jencks <da...@yahoo.com>.
I'm also getting worried that the plugin groups are starting to
duplicate the plugins and wondering if the concept is providing
significant value beyond the framework plugin group.
Also, I think that the current jms console stuff is unlikely to
survive in anything like its current form for activemq 5. The last
time I talked with the amq developers they indicated pretty strongly
that trying to reconfigure a running broker was not safe and that
editing the broker (xbean-spring) plan and restarting was the desired
approach.
thanks
david jencks
On Oct 8, 2008, at 6:45 AM, Lin Sun wrote:
> These are the console plugin groups, basically it provides the
> required console function for the javaee5 assemblies. I think the
> list suggested the following profiles a while back ago:
> JMS
> EJB
> Web Services
> Admin Console
> ...
>
> Also, I need the console plugin group to construct the javaee5 plugin
> groups/assemblies.
>
> Regarding activemq-console-xxx, my initial thought was to include it
> in the JMS plugin group, but I realize that you are working on the
> optional console and people may not want the JMS console function when
> they want JMS function (for example, there is one user trying to add
> JMS on top of little G). When you have your optional console stuff
> in, you can remove the optional ones from the console plugin group.
>
> Plugin groups are basically groups of plugins for users to easily
> understand and consume them. They can be used in the following ways:
> 1. custom server assemblies
> 2. G server assemblies (framework, javaee5)
> 3. install plugin group as regular plugin. For example, a user should
> be able to install the JMS plugin group in little G to get little G +
> JMS environment.
>
> Lin
>
> On Tue, Oct 7, 2008 at 11:03 PM, Donald Woods <dw...@apache.org>
> wrote:
>> Why are we recreating the existing console-jetty and console-tomcat
>> as yet
>> another plugin?
>>
>> Also, why are you including optional console plugins like
>> activemq-console-xxx, which should only be included if the ActiveMQ
>> plugins
>> are installed? By including it here, you're basically pulling in
>> the JMS
>> plugins.
>>
>> I'm starting to reconsider why we need plugingroups, if we're going
>> to have
>> to recreate dozens of existing plugins just in a slightly different
>> format
>> just so we can include them in a special view just for custom server
>> assemblies....
>>
>>
>>
>> -Donald
>>
>>
>> linsun@apache.org wrote:
>>>
>>> Author: linsun
>>> Date: Tue Oct 7 12:09:59 2008
>>> New Revision: 702586
>>>
>>> URL: http://svn.apache.org/viewvc?rev=702586&view=rev
>>> Log:
>>> Add the console-jetty plugin group
>>>
>>> Added:
>>> geronimo/server/trunk/plugingroups/console-jetty/
>>> geronimo/server/trunk/plugingroups/console-jetty/pom.xml (with
>>> props)
>>> geronimo/server/trunk/plugingroups/console-jetty/src/
>>> geronimo/server/trunk/plugingroups/console-jetty/src/main/
>>> geronimo/server/trunk/plugingroups/console-jetty/src/main/history/
>>>
>>> geronimo/server/trunk/plugingroups/console-jetty/src/main/history/
>>> dependencies.xml
>>> (with props)
>>> geronimo/server/trunk/plugingroups/console-jetty/src/main/plan/
>>>
>>> Added: geronimo/server/trunk/plugingroups/console-jetty/pom.xml
>>> URL:
>>> http://svn.apache.org/viewvc/geronimo/server/trunk/plugingroups/console-jetty/pom.xml?rev=702586&view=auto
>>>
>>> =
>>> =
>>> =
>>> =
>>> =
>>> =
>>> =
>>> =
>>> =
>>> =
>>> ====================================================================
>>> --- geronimo/server/trunk/plugingroups/console-jetty/pom.xml (added)
>>> +++ geronimo/server/trunk/plugingroups/console-jetty/pom.xml Tue
>>> Oct 7
>>> 12:09:59 2008
>>> @@ -0,0 +1,98 @@
>>> +<?xml version="1.0" encoding="ISO-8859-1"?>
>>> +<!--
>>> + Licensed to the Apache Software Foundation (ASF) under one
>>> + or more contributor license agreements. See the NOTICE file
>>> + distributed with this work for additional information
>>> + regarding copyright ownership. The ASF licenses this file
>>> + to you under the Apache License, Version 2.0 (the
>>> + "License"); you may not use this file except in compliance
>>> + with the License. You may obtain a copy of the License at
>>> + + http://www.apache.org/licenses/LICENSE-2.0
>>> + + Unless required by applicable law or agreed to in writing,
>>> + software distributed under the License is distributed on an
>>> + "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
>>> + KIND, either express or implied. See the License for the
>>> + specific language governing permissions and limitations
>>> + under the License.
>>> +-->
>>> +<!-- @version $Rev$ $Date$ -->
>>> +
>>> +<project xmlns="http://maven.apache.org/POM/4.0.0"
>>> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>>> xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
>>> http://maven.apache.org/maven-v4_0_0.xsd">
>>> +
>>> + <modelVersion>4.0.0</modelVersion>
>>> +
>>> + <parent>
>>> + <groupId>org.apache.geronimo.plugingroups</groupId>
>>> + <artifactId>plugingroups</artifactId>
>>> + <version>2.2-SNAPSHOT</version>
>>> + </parent>
>>> +
>>> + <artifactId>console-jetty</artifactId>
>>> + <packaging>car</packaging>
>>> + <name>Geronimo Plugin Group :: Admin Console Jetty</name>
>>> +
>>> + <description>
>>> + This plugin group provides Admin Console Jetty
>>> functionality.
>>> + </description>
>>> +
>>> + <dependencies>
>>> + <dependency>
>>> + <groupId>org.apache.geronimo.configs</groupId>
>>> + <artifactId>ca-helper-jetty</artifactId>
>>> + <version>${version}</version>
>>> + <type>car</type>
>>> + </dependency>
>>> +
>>> + <dependency>
>>> + <groupId>org.apache.geronimo.plugins</groupId>
>>> + <artifactId>agent</artifactId>
>>> + <version>${version}</version>
>>> + <type>car</type>
>>> + </dependency>
>>> +
>>> + <dependency>
>>> + <groupId>org.apache.geronimo.plugins</groupId>
>>> + <artifactId>mconsole-jetty</artifactId>
>>> + <version>${version}</version>
>>> + <type>car</type>
>>> + </dependency>
>>> +
>>> + <dependency>
>>> + <groupId>org.apache.geronimo.plugins</groupId>
>>> + <artifactId>activemq-console-jetty</artifactId>
>>> + <version>${version}</version>
>>> + <type>car</type>
>>> + </dependency>
>>> +
>>> + <dependency>
>>> + <groupId>org.apache.geronimo.plugins</groupId>
>>> + <artifactId>debugviews-console-jetty</artifactId>
>>> + <version>${version}</version>
>>> + <type>car</type>
>>> + </dependency>
>>> +
>>> + <dependency>
>>> + <groupId>org.apache.geronimo.plugins</groupId>
>>> + <artifactId>plancreator-console-jetty</artifactId>
>>> + <version>${version}</version>
>>> + <type>car</type>
>>> + </dependency>
>>> +
>>> + <dependency>
>>> + <groupId>org.apache.geronimo.plugins</groupId>
>>> + <artifactId>plugin-console-jetty</artifactId>
>>> + <version>${version}</version>
>>> + <type>car</type>
>>> + </dependency>
>>> +
>>> + <dependency>
>>> + <groupId>org.apache.geronimo.plugins</groupId>
>>> + <artifactId>sysdb-console-jetty</artifactId>
>>> + <version>${version}</version>
>>> + <type>car</type>
>>> + </dependency>
>>> + </dependencies>
>>> +</project>
>>> +
>>>
>>> Propchange: geronimo/server/trunk/plugingroups/console-jetty/pom.xml
>>>
>>> ------------------------------------------------------------------------------
>>> svn:eol-style = native
>>>
>>> Propchange: geronimo/server/trunk/plugingroups/console-jetty/pom.xml
>>>
>>> ------------------------------------------------------------------------------
>>> svn:keywords = Date Revision
>>>
>>> Propchange: geronimo/server/trunk/plugingroups/console-jetty/pom.xml
>>>
>>> ------------------------------------------------------------------------------
>>> svn:mime-type = text/xml
>>>
>>> Added:
>>> geronimo/server/trunk/plugingroups/console-jetty/src/main/history/
>>> dependencies.xml
>>> URL:
>>> http://svn.apache.org/viewvc/geronimo/server/trunk/plugingroups/console-jetty/src/main/history/dependencies.xml?rev=702586&view=auto
>>>
>>> =
>>> =
>>> =
>>> =
>>> =
>>> =
>>> =
>>> =
>>> =
>>> =
>>> ====================================================================
>>> ---
>>> geronimo/server/trunk/plugingroups/console-jetty/src/main/history/
>>> dependencies.xml
>>> (added)
>>> +++
>>> geronimo/server/trunk/plugingroups/console-jetty/src/main/history/
>>> dependencies.xml
>>> Tue Oct 7 12:09:59 2008
>>> @@ -0,0 +1,49 @@
>>> +<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
>>> +<plugin-artifact
>>> xmlns:ns2="http://geronimo.apache.org/xml/ns/attributes-1.2"
>>> xmlns="http://geronimo.apache.org/xml/ns/plugins-1.3">
>>> + <module-id>
>>> + <groupId>org.apache.geronimo.plugingroups</groupId>
>>> + <artifactId>console-jetty</artifactId>
>>> + <version>2.2-SNAPSHOT</version>
>>> + <type>car</type>
>>> + </module-id>
>>> + <dependency>
>>> + <groupId>org.apache.geronimo.plugins</groupId>
>>> + <artifactId>plancreator-console-jetty</artifactId>
>>> + <type>car</type>
>>> + </dependency>
>>> + <dependency>
>>> + <groupId>org.apache.geronimo.plugins</groupId>
>>> + <artifactId>sysdb-console-jetty</artifactId>
>>> + <type>car</type>
>>> + </dependency>
>>> + <dependency>
>>> + <groupId>org.apache.geronimo.plugins</groupId>
>>> + <artifactId>activemq-console-jetty</artifactId>
>>> + <type>car</type>
>>> + </dependency>
>>> + <dependency>
>>> + <groupId>org.apache.geronimo.plugins</groupId>
>>> + <artifactId>plugin-console-jetty</artifactId>
>>> + <type>car</type>
>>> + </dependency>
>>> + <dependency>
>>> + <groupId>org.apache.geronimo.configs</groupId>
>>> + <artifactId>ca-helper-jetty</artifactId>
>>> + <type>car</type>
>>> + </dependency>
>>> + <dependency>
>>> + <groupId>org.apache.geronimo.plugins</groupId>
>>> + <artifactId>debugviews-console-jetty</artifactId>
>>> + <type>car</type>
>>> + </dependency>
>>> + <dependency>
>>> + <groupId>org.apache.geronimo.plugins</groupId>
>>> + <artifactId>mconsole-jetty</artifactId>
>>> + <type>car</type>
>>> + </dependency>
>>> + <dependency>
>>> + <groupId>org.apache.geronimo.plugins</groupId>
>>> + <artifactId>agent</artifactId>
>>> + <type>car</type>
>>> + </dependency>
>>> +</plugin-artifact>
>>>
>>> Propchange:
>>> geronimo/server/trunk/plugingroups/console-jetty/src/main/history/
>>> dependencies.xml
>>>
>>> ------------------------------------------------------------------------------
>>> svn:eol-style = native
>>>
>>> Propchange:
>>> geronimo/server/trunk/plugingroups/console-jetty/src/main/history/
>>> dependencies.xml
>>>
>>> ------------------------------------------------------------------------------
>>> svn:keywords = Date Revision
>>>
>>> Propchange:
>>> geronimo/server/trunk/plugingroups/console-jetty/src/main/history/
>>> dependencies.xml
>>>
>>> ------------------------------------------------------------------------------
>>> svn:mime-type = text/xml
>>>
>>>
>>>
>>
Re: svn commit: r702586 - in /geronimo/server/trunk/plugingroups/console-jetty: ./ pom.xml src/ src/main/ src/main/history/ src/main/history/dependencies.xml src/main/plan/
Posted by Lin Sun <li...@gmail.com>.
See in line below.
On Wed, Oct 8, 2008 at 6:41 PM, David Jencks <da...@yahoo.com> wrote:
> Here are my current thoughts.... not that they necessarily mean much.
>
> 1. whether plugingroups are in a special svn area (rather than in framework
> and plugins directly) we need the c-m-p functionality for at least the
> framework plugingroup.
I agree. I think it is also agreed (from Donald and me) that besides
framework, web-tomcat, web-jetty and javaee5-tomcat and javaee5-jetty
are very useful.
That leaves us to the few other plugin groups -
clustering-tomcat/jetty
ejb
webservices-axis2/cxf
persistence
client
jms
jsf
console-tomcat/jetty (to be removed when optional console is in place)
And I don't have any intention to create any other plugin groups.
I have trimmed all the irrelevant stuff out and tried to bring stuff
in by transitive dependencies as much as possible. Out of these
plugins, only jms and jsf contain one plugin and I did question
creating them as plugin groups myself when I created them.
>
> 3. I have a suspicion that many of the plugingroups will turn out to only
> have one plugin in them when all the irrelevant stuff is trimmed out and
> stuff brought in by transitive dependencies is not listed explicitly. If
> this turns out to be true then having more than the framework plugingroup
> may not add much usefulness. We'll have to see.
>
> 4. As soon as we have numerous plugin groups, we'll have the same problem we
> do now in that it will be hard to find the plugingroups you want.
I don't plan to add any more plugin groups.
> 5. I think I argued against it in the past but I'm starting to think that
> perhaps including a list of tags with a plugin and having the
> select-a-plugin functionality organized by queries on these tags might be
> worth investigating. You'd pick say "ejb" and see all the ejb related
> plugins -- openejb, openejb-builder, openejb-console-jetty/tomcat, cxf-ejb,
> etc etc.
I think this is similar as what Joe has been proposed, a filter
function to allow you to see a subset of plugins (for example, tag
stuff via categories). I agree this is worthy investigating and I
can see both admin console and command tool benefit this. I'll take
this as a TODO.
> 6. It might be worth displaying plugin dependencies in the select-a-plugin
> functionality.
I think this is already there today in server assembly portlet. If
you select a plugin to see the detail, you will get to see all its
dependencies, along with name, desp, category, license. I use this a
lot to figure out which plugins I can trim in a plugin group. Or
are you suggesting something different?
>
> thanks
> david jencks
Re: svn commit: r702586 - in /geronimo/server/trunk/plugingroups/console-jetty:
./ pom.xml src/ src/main/ src/main/history/ src/main/history/dependencies.xml
src/main/plan/
Posted by Joe Bohn <jo...@earthlink.net>.
David Jencks wrote:
> Here are my current thoughts.... not that they necessarily mean much.
>
> 1. whether plugingroups are in a special svn area (rather than in
> framework and plugins directly) we need the c-m-p functionality for at
> least the framework plugingroup.
>
> 2. IIUC Joe's idea was to make it so a dependency on a classloader-free
> plugin turned into dependencies on all its dependencies. I would like
> to see an extremely convincing and specific use case for this before we
> consider implementing it. I could easily be wrong but fear this would
> introduce hard-to-understand complexity with little gain.
I provided a use case in an earlier thread ... though probably not an
extremely convincing one ;-) (see http://tinyurl.com/3jqfzk ). That
discussion trailed off into a debate over when a plugin should call out
the dependencies it actually needs or when it should call out the
dependencies on specific deployers and let the deployers add in the
dependencies via default environments. I personally think that is a
non-intuitive approach for the user and isn't very general purpose since
not all dependencies will be added via a deployer default environment
... but that may be a discussion for another thread.
However, I think we have to do something given that plugingroups are
really just special purpose plugins. We either need to let them be
treated as plugins when called out as dependencies (and therefore handle
the classloaders correctly) .... OR we need to insert code to prevent
the groups from being added as dependencies (or at least flag them). I
still see a lot of value in allowing the groups wherever plugins can be
used ... now if I can just think of an example that will convince
everyone else :-) .
>
> 3. I have a suspicion that many of the plugingroups will turn out to
> only have one plugin in them when all the irrelevant stuff is trimmed
> out and stuff brought in by transitive dependencies is not listed
> explicitly. If this turns out to be true then having more than the
> framework plugingroup may not add much usefulness. We'll have to see.
Agreed ... if the group includes just one plugin then it is unnecessary.
The other question here is how general purpose do we think plugingroups
will be? Is this primarily just a tool when building our own server
assemblies (and custom versions of them) ... or is it a general purpose
utility such that users can create their own plugingroups and leverage
those when building custom assemblies as well.
I still can imagine scenarios where a user creates several application
utilities that they want to leverage. Each utility is created as an
independent plugin so that various packages can be built. They can then
be bundled as appropriate into plulgingroups and used to build custom
assemblies along with their applications. If we extend the classloaders
as mentioned in #2 the user can also add the plugingroups as
dependencies of their applications rather than adding dependencies on
all the individual utility plugins.
If we support the general purpose use of plugingroups then we shouldn't
eliminate the concept just because we don't generate a lot of them for
our assemble a server scenarios.
>
> 4. As soon as we have numerous plugin groups, we'll have the same
> problem we do now in that it will be hard to find the plugingroups you
> want.
By definition there should always be fewer plugingroups than plugins if
they really aggregate plugins that have some affinity. So, while the
number of plugingroups may also grow it should still be easier to
navigate than the individual plugins.
>
> 5. I think I argued against it in the past but I'm starting to think
> that perhaps including a list of tags with a plugin and having the
> select-a-plugin functionality organized by queries on these tags might
> be worth investigating. You'd pick say "ejb" and see all the ejb
> related plugins -- openejb, openejb-builder,
> openejb-console-jetty/tomcat, cxf-ejb, etc etc.
I think the idea of tagging makes sense independent of the plugingroup
discussion. However, I'm not yet convinced that it can replace the
plugingroup concept completely. It can certainly be used to replace the
attribute of plugingroup that we now have (so "plugingroup" could be
just another tag on a plugin whose only purpose is to aggregate the
content of other plugins). However, I think we will still want the
predictability of plugingroups to define the content rather than letting
a query of tags at a particular point in time and to a particular set of
repositories determine the set of plugins that are installed.
>
> 6. It might be worth displaying plugin dependencies in the
> select-a-plugin functionality.
>
>
> thanks
> david jencks
>
> On Oct 8, 2008, at 2:13 PM, Lin Sun wrote:
>
>> See in-line below...
>>
>> On Wed, Oct 8, 2008 at 4:37 PM, Joe Bohn <jo...@earthlink.net> wrote:
>>
>>>>> Thanks for making the suggestions. It is always good to hear
>>>>> feedback and challenge our thinking! :)
>>>>
>>>> Yep, I wish we had more than 4 people actively looking/discussing
>>>> this :-(
>>>
>>> Ok ... you asked for it ;-) ... Also see my response on the other
>>> branch of
>>> this thread.
>>
>> We had over 4 people in the past... I am sure :)
>>
>>>>> My initial thought of grouping the plugins together was by category,
>>>>> however I think it has the following limitations -
>>>>>
>>>>> 1. A user can specify his module to any category he likes too, thus it
>>>>> could interfere with the resulting tree. For example, a user has a
>>>>> module that is also categorized as console or development tools or
>>>>> administration.
>>>>>
>>>>
>>>> Don't see this as an issue, since we control the default
>>>> repository-list
>>>> and what goes into the geronimo-plugins.xml for the server and
>>>> samples. If
>>>> a user created their own repo (like Liferay) then their plugins
>>>> would be
>>>> listed under the "Liferay Repo" instead of the "Geronimo Server
>>>> Repo" and
>>>> they could use whatever categories they want.
>>
>> The user can grow the repo-list easily by deploying an app onto the
>> local G server. There isn't a geronimo-plugins.xml for the local
>> geronimo server repo, but the server is capable to build one on the
>> fly.
>>>
>>> I see both points here. As Donald mentions, the repository should be in
>>> control of the namespace for the categories. However, that only
>>> works with
>>> an external repository. However, at the moment the assemble a server
>>> functions only work with the local, server repository which can include
>>> plugins from multiple external repositories. To have the assembly
>>> function
>>> with correctly to build up a server it will eventually have to let
>>> the user
>>> choose plugins and plugingroups from multiple external repositories.
>>> That
>>> should be interesting.
>>
>> I agree currently it is local server only, and the prob still exists
>> with local server, as a user can install the plugin onto G server,
>> which will make the user's plugin resides in our local repo.
>>
>>>
>>>>
>>>>
>>>>> 2. group by category doesn't offer any integration into maven. As you
>>>>> know, we are using plugin groups for all of our G assemblies now.
>>>>>
>>>>
>>>> I'm questioning if this "maven integration" is worth the added source
>>>> complexity. I'm starting to lean heavily towards "No" and wondering
>>>> if we
>>>> should remove most of the pluginprofiles for 2.2 and only keep -
>>>> framework,
>>>> minimal and jee5. Once we get user feedback on what groupings "are
>>>> missing"
>>>> then we can consider adding more.
>>
>> I am missing the added source complexity here. We only added very
>> little code to support plugin group as David reminded me the function
>> is already there. In fact, having functions divided by plugin groups
>> allow me to clean up our long list of little G assemblies & javaee5
>> assemblies (there are lots of unnecessary dependencies) and only use
>> what is really needed (others can be pulled via transitive
>> dependencies). I think we should keep most of them as they are today
>> and revise them upon users' request. The only ones I had debating
>> myself if I should create them are jms, jsf and console. jms and jsf
>> plugin groups each contain only one plugin as the other plugins can be
>> pulled via transitive dependencies. However, that doesn't mean users
>> know which ones to pick easily. About console plugin group, I'd be
>> totally ok removing it when we switch to optional console.
>>>
>>> I think this can be worth the effort if we keep things simple. Only
>>> create
>>> plugingroups when they are really necessary and leverage the groups
>>> consistently. I personally like the idea of the groups so that a
>>> user can
>>> incrementally grow function in a new or existing server in logical
>>> chunks
>>> without having to understand all of the detailed plugins that we
>>> generate.
>>
>> Me too.
>>>>
>>>>
>>>>> 3. group by category doesn't help with command line install-plugin
>>>>> command. Currently you can install a plugin group by using "deploy
>>>>> install-plugin <plugingroup id>"
>>>>>
>>>>
>>>> It would have to be enhanced, which it greatly needs IMO.
>>>>> 4. group by category doesn't help with "gshell deploy/assemble"
>>>>> command. A user is unlikely to have some fancy GUI like tree in a
>>>>> command line env.
>>>>
>>>> If a user is trying to assemble from cmdline, then they will suffer and
>>>> should either write a gsh script, use c-m-p or the console.
>>>
>>> Alternatively, part of the enhancement of the command line could be
>>> to allow
>>> the user to filter the list of plugins returned by category.
>>
>> That is possible to enhance, IMO.
>>>>
>>>>>
>>>>> With plugin groups, you can still group plugins by category. In fact,
>>>>> in the install plugin portlet that we allow users to sort plugins by
>>>>> category, name, etc. I disabled the sort function in assemble server
>>>>> portlet as it needs more work but the plugins are sorted by category
>>>>> right now.
>>>>>
>>>>> I think I agree with you that the console-xxx plugin group are not
>>>>> that useful and I think they can be removed after we make most of the
>>>>> console components optional. Currently, all these console components
>>>>> are under application plugins, and I 'm updating their names, desps,
>>>>> and categories to enable users to select them easily. For example,
>>>>> if a user wants little G tomcat + JMS, he can select web-tomcat, JMS
>>>>> plugin group, and Console: JMS from application plugins if he wants
>>>>> console support for JMS.
>>>
>>> I think it would make sense to have several plugingroups (or aggregate
>>> plugins) when dealing with the console extensions. One possible pattern
>>> would be to create a plugingroup for the core function and then another
>>> plugingroup which includes the core function plugingroup and the console
>>> extension. For example (PG indicates a plugingroup, P just a plugin):
>>>
>>> PG - JMS + Console
>>> includes: PG - JMS
>>> P - JMS console
>>>
>>> PG - JMS
>>> includes: P - the JMS and associated plugins that are necessary.
>>>
>>> Here a user could choose to include the plugingroup for JMS + Console or
>>> just the plugingroup for JMS.
>>
>> Joe, I had thought about this too. The other way to do things is
>> pretty straightforward too, either pick
>>
>> PG -JMS + P - Console, JMS (this is only one plugin thus I don't feel
>> we need a group for it).
>>
>> or
>>
>> PG -JMS
>>
>> Lin
>
>
Re: svn commit: r702586 - in /geronimo/server/trunk/plugingroups/console-jetty: ./ pom.xml src/ src/main/ src/main/history/ src/main/history/dependencies.xml src/main/plan/
Posted by David Jencks <da...@yahoo.com>.
Here are my current thoughts.... not that they necessarily mean much.
1. whether plugingroups are in a special svn area (rather than in
framework and plugins directly) we need the c-m-p functionality for at
least the framework plugingroup.
2. IIUC Joe's idea was to make it so a dependency on a classloader-
free plugin turned into dependencies on all its dependencies. I would
like to see an extremely convincing and specific use case for this
before we consider implementing it. I could easily be wrong but fear
this would introduce hard-to-understand complexity with little gain.
3. I have a suspicion that many of the plugingroups will turn out to
only have one plugin in them when all the irrelevant stuff is trimmed
out and stuff brought in by transitive dependencies is not listed
explicitly. If this turns out to be true then having more than the
framework plugingroup may not add much usefulness. We'll have to see.
4. As soon as we have numerous plugin groups, we'll have the same
problem we do now in that it will be hard to find the plugingroups you
want.
5. I think I argued against it in the past but I'm starting to think
that perhaps including a list of tags with a plugin and having the
select-a-plugin functionality organized by queries on these tags might
be worth investigating. You'd pick say "ejb" and see all the ejb
related plugins -- openejb, openejb-builder, openejb-console-jetty/
tomcat, cxf-ejb, etc etc.
6. It might be worth displaying plugin dependencies in the select-a-
plugin functionality.
thanks
david jencks
On Oct 8, 2008, at 2:13 PM, Lin Sun wrote:
> See in-line below...
>
> On Wed, Oct 8, 2008 at 4:37 PM, Joe Bohn <jo...@earthlink.net>
> wrote:
>
>>>> Thanks for making the suggestions. It is always good to hear
>>>> feedback and challenge our thinking! :)
>>>
>>> Yep, I wish we had more than 4 people actively looking/discussing
>>> this :-(
>>
>> Ok ... you asked for it ;-) ... Also see my response on the other
>> branch of
>> this thread.
>
> We had over 4 people in the past... I am sure :)
>
>>>> My initial thought of grouping the plugins together was by
>>>> category,
>>>> however I think it has the following limitations -
>>>>
>>>> 1. A user can specify his module to any category he likes too,
>>>> thus it
>>>> could interfere with the resulting tree. For example, a user has a
>>>> module that is also categorized as console or development tools or
>>>> administration.
>>>>
>>>
>>> Don't see this as an issue, since we control the default
>>> repository-list
>>> and what goes into the geronimo-plugins.xml for the server and
>>> samples. If
>>> a user created their own repo (like Liferay) then their plugins
>>> would be
>>> listed under the "Liferay Repo" instead of the "Geronimo Server
>>> Repo" and
>>> they could use whatever categories they want.
>
> The user can grow the repo-list easily by deploying an app onto the
> local G server. There isn't a geronimo-plugins.xml for the local
> geronimo server repo, but the server is capable to build one on the
> fly.
>>
>> I see both points here. As Donald mentions, the repository should
>> be in
>> control of the namespace for the categories. However, that only
>> works with
>> an external repository. However, at the moment the assemble a server
>> functions only work with the local, server repository which can
>> include
>> plugins from multiple external repositories. To have the assembly
>> function
>> with correctly to build up a server it will eventually have to let
>> the user
>> choose plugins and plugingroups from multiple external
>> repositories. That
>> should be interesting.
>
> I agree currently it is local server only, and the prob still exists
> with local server, as a user can install the plugin onto G server,
> which will make the user's plugin resides in our local repo.
>
>>
>>>
>>>
>>>> 2. group by category doesn't offer any integration into maven.
>>>> As you
>>>> know, we are using plugin groups for all of our G assemblies now.
>>>>
>>>
>>> I'm questioning if this "maven integration" is worth the added
>>> source
>>> complexity. I'm starting to lean heavily towards "No" and
>>> wondering if we
>>> should remove most of the pluginprofiles for 2.2 and only keep -
>>> framework,
>>> minimal and jee5. Once we get user feedback on what groupings
>>> "are missing"
>>> then we can consider adding more.
>
> I am missing the added source complexity here. We only added very
> little code to support plugin group as David reminded me the function
> is already there. In fact, having functions divided by plugin groups
> allow me to clean up our long list of little G assemblies & javaee5
> assemblies (there are lots of unnecessary dependencies) and only use
> what is really needed (others can be pulled via transitive
> dependencies). I think we should keep most of them as they are today
> and revise them upon users' request. The only ones I had debating
> myself if I should create them are jms, jsf and console. jms and jsf
> plugin groups each contain only one plugin as the other plugins can be
> pulled via transitive dependencies. However, that doesn't mean users
> know which ones to pick easily. About console plugin group, I'd be
> totally ok removing it when we switch to optional console.
>>
>> I think this can be worth the effort if we keep things simple.
>> Only create
>> plugingroups when they are really necessary and leverage the groups
>> consistently. I personally like the idea of the groups so that a
>> user can
>> incrementally grow function in a new or existing server in logical
>> chunks
>> without having to understand all of the detailed plugins that we
>> generate.
>
> Me too.
>>>
>>>
>>>> 3. group by category doesn't help with command line install-plugin
>>>> command. Currently you can install a plugin group by using "deploy
>>>> install-plugin <plugingroup id>"
>>>>
>>>
>>> It would have to be enhanced, which it greatly needs IMO.
>>>> 4. group by category doesn't help with "gshell deploy/assemble"
>>>> command. A user is unlikely to have some fancy GUI like tree in a
>>>> command line env.
>>>
>>> If a user is trying to assemble from cmdline, then they will
>>> suffer and
>>> should either write a gsh script, use c-m-p or the console.
>>
>> Alternatively, part of the enhancement of the command line could be
>> to allow
>> the user to filter the list of plugins returned by category.
>
> That is possible to enhance, IMO.
>>>
>>>>
>>>> With plugin groups, you can still group plugins by category. In
>>>> fact,
>>>> in the install plugin portlet that we allow users to sort plugins
>>>> by
>>>> category, name, etc. I disabled the sort function in assemble
>>>> server
>>>> portlet as it needs more work but the plugins are sorted by
>>>> category
>>>> right now.
>>>>
>>>> I think I agree with you that the console-xxx plugin group are not
>>>> that useful and I think they can be removed after we make most of
>>>> the
>>>> console components optional. Currently, all these console
>>>> components
>>>> are under application plugins, and I 'm updating their names,
>>>> desps,
>>>> and categories to enable users to select them easily. For
>>>> example,
>>>> if a user wants little G tomcat + JMS, he can select web-tomcat,
>>>> JMS
>>>> plugin group, and Console: JMS from application plugins if he wants
>>>> console support for JMS.
>>
>> I think it would make sense to have several plugingroups (or
>> aggregate
>> plugins) when dealing with the console extensions. One possible
>> pattern
>> would be to create a plugingroup for the core function and then
>> another
>> plugingroup which includes the core function plugingroup and the
>> console
>> extension. For example (PG indicates a plugingroup, P just a
>> plugin):
>>
>> PG - JMS + Console
>> includes: PG - JMS
>> P - JMS console
>>
>> PG - JMS
>> includes: P - the JMS and associated plugins that are necessary.
>>
>> Here a user could choose to include the plugingroup for JMS +
>> Console or
>> just the plugingroup for JMS.
>
> Joe, I had thought about this too. The other way to do things is
> pretty straightforward too, either pick
>
> PG -JMS + P - Console, JMS (this is only one plugin thus I don't feel
> we need a group for it).
>
> or
>
> PG -JMS
>
> Lin
Re: svn commit: r702586 - in /geronimo/server/trunk/plugingroups/console-jetty: ./ pom.xml src/ src/main/ src/main/history/ src/main/history/dependencies.xml src/main/plan/
Posted by Lin Sun <li...@gmail.com>.
See in-line below...
On Wed, Oct 8, 2008 at 4:37 PM, Joe Bohn <jo...@earthlink.net> wrote:
>>> Thanks for making the suggestions. It is always good to hear
>>> feedback and challenge our thinking! :)
>>
>> Yep, I wish we had more than 4 people actively looking/discussing this :-(
>
> Ok ... you asked for it ;-) ... Also see my response on the other branch of
> this thread.
We had over 4 people in the past... I am sure :)
>>> My initial thought of grouping the plugins together was by category,
>>> however I think it has the following limitations -
>>>
>>> 1. A user can specify his module to any category he likes too, thus it
>>> could interfere with the resulting tree. For example, a user has a
>>> module that is also categorized as console or development tools or
>>> administration.
>>>
>>
>> Don't see this as an issue, since we control the default repository-list
>> and what goes into the geronimo-plugins.xml for the server and samples. If
>> a user created their own repo (like Liferay) then their plugins would be
>> listed under the "Liferay Repo" instead of the "Geronimo Server Repo" and
>> they could use whatever categories they want.
The user can grow the repo-list easily by deploying an app onto the
local G server. There isn't a geronimo-plugins.xml for the local
geronimo server repo, but the server is capable to build one on the
fly.
>
> I see both points here. As Donald mentions, the repository should be in
> control of the namespace for the categories. However, that only works with
> an external repository. However, at the moment the assemble a server
> functions only work with the local, server repository which can include
> plugins from multiple external repositories. To have the assembly function
> with correctly to build up a server it will eventually have to let the user
> choose plugins and plugingroups from multiple external repositories. That
> should be interesting.
I agree currently it is local server only, and the prob still exists
with local server, as a user can install the plugin onto G server,
which will make the user's plugin resides in our local repo.
>
>>
>>
>>> 2. group by category doesn't offer any integration into maven. As you
>>> know, we are using plugin groups for all of our G assemblies now.
>>>
>>
>> I'm questioning if this "maven integration" is worth the added source
>> complexity. I'm starting to lean heavily towards "No" and wondering if we
>> should remove most of the pluginprofiles for 2.2 and only keep - framework,
>> minimal and jee5. Once we get user feedback on what groupings "are missing"
>> then we can consider adding more.
I am missing the added source complexity here. We only added very
little code to support plugin group as David reminded me the function
is already there. In fact, having functions divided by plugin groups
allow me to clean up our long list of little G assemblies & javaee5
assemblies (there are lots of unnecessary dependencies) and only use
what is really needed (others can be pulled via transitive
dependencies). I think we should keep most of them as they are today
and revise them upon users' request. The only ones I had debating
myself if I should create them are jms, jsf and console. jms and jsf
plugin groups each contain only one plugin as the other plugins can be
pulled via transitive dependencies. However, that doesn't mean users
know which ones to pick easily. About console plugin group, I'd be
totally ok removing it when we switch to optional console.
>
> I think this can be worth the effort if we keep things simple. Only create
> plugingroups when they are really necessary and leverage the groups
> consistently. I personally like the idea of the groups so that a user can
> incrementally grow function in a new or existing server in logical chunks
> without having to understand all of the detailed plugins that we generate.
Me too.
>>
>>
>>> 3. group by category doesn't help with command line install-plugin
>>> command. Currently you can install a plugin group by using "deploy
>>> install-plugin <plugingroup id>"
>>>
>>
>> It would have to be enhanced, which it greatly needs IMO.
>>> 4. group by category doesn't help with "gshell deploy/assemble"
>>> command. A user is unlikely to have some fancy GUI like tree in a
>>> command line env.
>>
>> If a user is trying to assemble from cmdline, then they will suffer and
>> should either write a gsh script, use c-m-p or the console.
>
> Alternatively, part of the enhancement of the command line could be to allow
> the user to filter the list of plugins returned by category.
That is possible to enhance, IMO.
>>
>>>
>>> With plugin groups, you can still group plugins by category. In fact,
>>> in the install plugin portlet that we allow users to sort plugins by
>>> category, name, etc. I disabled the sort function in assemble server
>>> portlet as it needs more work but the plugins are sorted by category
>>> right now.
>>>
>>> I think I agree with you that the console-xxx plugin group are not
>>> that useful and I think they can be removed after we make most of the
>>> console components optional. Currently, all these console components
>>> are under application plugins, and I 'm updating their names, desps,
>>> and categories to enable users to select them easily. For example,
>>> if a user wants little G tomcat + JMS, he can select web-tomcat, JMS
>>> plugin group, and Console: JMS from application plugins if he wants
>>> console support for JMS.
>
> I think it would make sense to have several plugingroups (or aggregate
> plugins) when dealing with the console extensions. One possible pattern
> would be to create a plugingroup for the core function and then another
> plugingroup which includes the core function plugingroup and the console
> extension. For example (PG indicates a plugingroup, P just a plugin):
>
> PG - JMS + Console
> includes: PG - JMS
> P - JMS console
>
> PG - JMS
> includes: P - the JMS and associated plugins that are necessary.
>
> Here a user could choose to include the plugingroup for JMS + Console or
> just the plugingroup for JMS.
Joe, I had thought about this too. The other way to do things is
pretty straightforward too, either pick
PG -JMS + P - Console, JMS (this is only one plugin thus I don't feel
we need a group for it).
or
PG -JMS
Lin
Re: svn commit: r702586 - in /geronimo/server/trunk/plugingroups/console-jetty:
./ pom.xml src/ src/main/ src/main/history/ src/main/history/dependencies.xml
src/main/plan/
Posted by Joe Bohn <jo...@earthlink.net>.
Donald Woods wrote:
> In-line.
>
> Lin Sun wrote:
>> Thanks for making the suggestions. It is always good to hear
>> feedback and challenge our thinking! :)
>
> Yep, I wish we had more than 4 people actively looking/discussing this :-(
Ok ... you asked for it ;-) ... Also see my response on the other
branch of this thread.
>
>>
>> My initial thought of grouping the plugins together was by category,
>> however I think it has the following limitations -
>>
>> 1. A user can specify his module to any category he likes too, thus it
>> could interfere with the resulting tree. For example, a user has a
>> module that is also categorized as console or development tools or
>> administration.
>>
>
> Don't see this as an issue, since we control the default repository-list
> and what goes into the geronimo-plugins.xml for the server and samples.
> If a user created their own repo (like Liferay) then their plugins
> would be listed under the "Liferay Repo" instead of the "Geronimo Server
> Repo" and they could use whatever categories they want.
I see both points here. As Donald mentions, the repository should be in
control of the namespace for the categories. However, that only works
with an external repository. However, at the moment the assemble a
server functions only work with the local, server repository which can
include plugins from multiple external repositories. To have the
assembly function with correctly to build up a server it will eventually
have to let the user choose plugins and plugingroups from multiple
external repositories. That should be interesting.
>
>
>> 2. group by category doesn't offer any integration into maven. As you
>> know, we are using plugin groups for all of our G assemblies now.
>>
>
> I'm questioning if this "maven integration" is worth the added source
> complexity. I'm starting to lean heavily towards "No" and wondering if
> we should remove most of the pluginprofiles for 2.2 and only keep -
> framework, minimal and jee5. Once we get user feedback on what
> groupings "are missing" then we can consider adding more.
I think this can be worth the effort if we keep things simple. Only
create plugingroups when they are really necessary and leverage the
groups consistently. I personally like the idea of the groups so that a
user can incrementally grow function in a new or existing server in
logical chunks without having to understand all of the detailed plugins
that we generate.
>
>
>> 3. group by category doesn't help with command line install-plugin
>> command. Currently you can install a plugin group by using "deploy
>> install-plugin <plugingroup id>"
>>
>
> It would have to be enhanced, which it greatly needs IMO.
>
>> 4. group by category doesn't help with "gshell deploy/assemble"
>> command. A user is unlikely to have some fancy GUI like tree in a
>> command line env.
>
> If a user is trying to assemble from cmdline, then they will suffer and
> should either write a gsh script, use c-m-p or the console.
Alternatively, part of the enhancement of the command line could be to
allow the user to filter the list of plugins returned by category.
>
>>
>> With plugin groups, you can still group plugins by category. In fact,
>> in the install plugin portlet that we allow users to sort plugins by
>> category, name, etc. I disabled the sort function in assemble server
>> portlet as it needs more work but the plugins are sorted by category
>> right now.
>>
>> I think I agree with you that the console-xxx plugin group are not
>> that useful and I think they can be removed after we make most of the
>> console components optional. Currently, all these console components
>> are under application plugins, and I 'm updating their names, desps,
>> and categories to enable users to select them easily. For example,
>> if a user wants little G tomcat + JMS, he can select web-tomcat, JMS
>> plugin group, and Console: JMS from application plugins if he wants
>> console support for JMS.
I think it would make sense to have several plugingroups (or aggregate
plugins) when dealing with the console extensions. One possible pattern
would be to create a plugingroup for the core function and then another
plugingroup which includes the core function plugingroup and the console
extension. For example (PG indicates a plugingroup, P just a plugin):
PG - JMS + Console
includes: PG - JMS
P - JMS console
PG - JMS
includes: P - the JMS and associated plugins that are necessary.
Here a user could choose to include the plugingroup for JMS + Console or
just the plugingroup for JMS.
>>
>> Lin
>>
>> On Wed, Oct 8, 2008 at 1:48 PM, Donald Woods <dw...@apache.org> wrote:
>>> It seems that most of the functionality now delivered in the
>>> profilegroups
>>> could have been implemented by just properly setting the plugin category
>>> attribute to a useful "plugin group" name and use the source repo for
>>> the
>>> plugin to denote they are base server plugins vs. Samples vs. a
>>> "Console"
>>> plugin from a third-party.
>>>
>>> For something like the activemq portlets, we'd just set
>>> category=Console.
>>>
>>> Then modifying the plugin installer to build a tree of plugin groups and
>>> allow the user to select one or more "groups" of plugins, like
>>> console, or
>>> choose specific plugins from within a group, like everything under
>>> console
>>> except the activemq portlets. (We would also add some logic to only
>>> select
>>> Tomcat or Jetty plugins based on which is already installed or prompt
>>> the
>>> user to choose.)
>>>
>>> That would allow us to have one set of plugins (the real ones) and
>>> only have
>>> LOGICAL groupings (instead of the physical ones now under plugingroups/)
>>> based on the defined category. The user would then see something like -
>>>
>>> - Apache Geronimo Server repository
>>> |--+ Console
>>> | |- ActiveMQ Console
>>> | |- Dojo
>>> | |- . . .
>>> |
>>> |--+ Web Container
>>> | |- Tomcat6
>>> | |- Jetty6
>>> |
>>> . . .
>>>
>>> There are still some cases where we'd want to use the new c-m-p
>>> support for
>>> not creating a classloader, like using it to generate a "minimal web"
>>> and
>>> "full jee5" grouping/profile/template that users could rely on for
>>> creating
>>> their own custom assemblies with c-m-p without having to create a
>>> complete
>>> assembly build.
>>>
>>>
>>> -Donald
>>>
>>>
>>>
>>> Lin Sun wrote:
>>>> These are the console plugin groups, basically it provides the
>>>> required console function for the javaee5 assemblies. I think the
>>>> list suggested the following profiles a while back ago:
>>>> JMS
>>>> EJB
>>>> Web Services
>>>> Admin Console
>>>> ...
>>>>
>>>> Also, I need the console plugin group to construct the javaee5 plugin
>>>> groups/assemblies.
>>>>
>>>> Regarding activemq-console-xxx, my initial thought was to include it
>>>> in the JMS plugin group, but I realize that you are working on the
>>>> optional console and people may not want the JMS console function when
>>>> they want JMS function (for example, there is one user trying to add
>>>> JMS on top of little G). When you have your optional console stuff
>>>> in, you can remove the optional ones from the console plugin group.
>>>>
>>>> Plugin groups are basically groups of plugins for users to easily
>>>> understand and consume them. They can be used in the following ways:
>>>> 1. custom server assemblies
>>>> 2. G server assemblies (framework, javaee5)
>>>> 3. install plugin group as regular plugin. For example, a user should
>>>> be able to install the JMS plugin group in little G to get little G +
>>>> JMS environment.
>>>>
>>>> Lin
>>>>
>>>> On Tue, Oct 7, 2008 at 11:03 PM, Donald Woods <dw...@apache.org>
>>>> wrote:
>>>>> Why are we recreating the existing console-jetty and console-tomcat as
>>>>> yet
>>>>> another plugin?
>>>>>
>>>>> Also, why are you including optional console plugins like
>>>>> activemq-console-xxx, which should only be included if the ActiveMQ
>>>>> plugins
>>>>> are installed? By including it here, you're basically pulling in
>>>>> the JMS
>>>>> plugins.
>>>>>
>>>>> I'm starting to reconsider why we need plugingroups, if we're going to
>>>>> have
>>>>> to recreate dozens of existing plugins just in a slightly different
>>>>> format
>>>>> just so we can include them in a special view just for custom server
>>>>> assemblies....
>>>>>
>>>>>
>>>>>
>>>>> -Donald
>>>>>
>>>>>
>>>>> linsun@apache.org wrote:
>>>>>> Author: linsun
>>>>>> Date: Tue Oct 7 12:09:59 2008
>>>>>> New Revision: 702586
>>>>>>
>>>>>> URL: http://svn.apache.org/viewvc?rev=702586&view=rev
>>>>>> Log:
>>>>>> Add the console-jetty plugin group
>>>>>>
>>>>>> Added:
>>>>>> geronimo/server/trunk/plugingroups/console-jetty/
>>>>>> geronimo/server/trunk/plugingroups/console-jetty/pom.xml (with
>>>>>> props)
>>>>>> geronimo/server/trunk/plugingroups/console-jetty/src/
>>>>>> geronimo/server/trunk/plugingroups/console-jetty/src/main/
>>>>>> geronimo/server/trunk/plugingroups/console-jetty/src/main/history/
>>>>>>
>>>>>>
>>>>>> geronimo/server/trunk/plugingroups/console-jetty/src/main/history/dependencies.xml
>>>>>>
>>>>>> (with props)
>>>>>> geronimo/server/trunk/plugingroups/console-jetty/src/main/plan/
>>>>>>
>>>>>> Added: geronimo/server/trunk/plugingroups/console-jetty/pom.xml
>>>>>> URL:
>>>>>>
>>>>>> http://svn.apache.org/viewvc/geronimo/server/trunk/plugingroups/console-jetty/pom.xml?rev=702586&view=auto
>>>>>>
>>>>>>
>>>>>>
>>>>>> ==============================================================================
>>>>>>
>>>>>> --- geronimo/server/trunk/plugingroups/console-jetty/pom.xml (added)
>>>>>> +++ geronimo/server/trunk/plugingroups/console-jetty/pom.xml Tue
>>>>>> Oct 7
>>>>>> 12:09:59 2008
>>>>>> @@ -0,0 +1,98 @@
>>>>>> +<?xml version="1.0" encoding="ISO-8859-1"?>
>>>>>> +<!--
>>>>>> + Licensed to the Apache Software Foundation (ASF) under one
>>>>>> + or more contributor license agreements. See the NOTICE file
>>>>>> + distributed with this work for additional information
>>>>>> + regarding copyright ownership. The ASF licenses this file
>>>>>> + to you under the Apache License, Version 2.0 (the
>>>>>> + "License"); you may not use this file except in compliance
>>>>>> + with the License. You may obtain a copy of the License at
>>>>>> + + http://www.apache.org/licenses/LICENSE-2.0
>>>>>> + + Unless required by applicable law or agreed to in writing,
>>>>>> + software distributed under the License is distributed on an
>>>>>> + "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
>>>>>> + KIND, either express or implied. See the License for the
>>>>>> + specific language governing permissions and limitations
>>>>>> + under the License.
>>>>>> +-->
>>>>>> +<!-- @version $Rev$ $Date$ -->
>>>>>> +
>>>>>> +<project xmlns="http://maven.apache.org/POM/4.0.0"
>>>>>> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>>>>>> xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
>>>>>> http://maven.apache.org/maven-v4_0_0.xsd">
>>>>>> +
>>>>>> + <modelVersion>4.0.0</modelVersion>
>>>>>> +
>>>>>> + <parent>
>>>>>> + <groupId>org.apache.geronimo.plugingroups</groupId>
>>>>>> + <artifactId>plugingroups</artifactId>
>>>>>> + <version>2.2-SNAPSHOT</version>
>>>>>> + </parent>
>>>>>> +
>>>>>> + <artifactId>console-jetty</artifactId>
>>>>>> + <packaging>car</packaging>
>>>>>> + <name>Geronimo Plugin Group :: Admin Console Jetty</name>
>>>>>> +
>>>>>> + <description>
>>>>>> + This plugin group provides Admin Console Jetty
>>>>>> functionality.
>>>>>> + </description>
>>>>>> +
>>>>>> + <dependencies>
>>>>>> + <dependency>
>>>>>> + <groupId>org.apache.geronimo.configs</groupId>
>>>>>> + <artifactId>ca-helper-jetty</artifactId>
>>>>>> + <version>${version}</version>
>>>>>> + <type>car</type>
>>>>>> + </dependency>
>>>>>> +
>>>>>> + <dependency>
>>>>>> + <groupId>org.apache.geronimo.plugins</groupId>
>>>>>> + <artifactId>agent</artifactId>
>>>>>> + <version>${version}</version>
>>>>>> + <type>car</type>
>>>>>> + </dependency>
>>>>>> +
>>>>>> + <dependency>
>>>>>> + <groupId>org.apache.geronimo.plugins</groupId>
>>>>>> + <artifactId>mconsole-jetty</artifactId>
>>>>>> + <version>${version}</version>
>>>>>> + <type>car</type>
>>>>>> + </dependency>
>>>>>> +
>>>>>> + <dependency>
>>>>>> + <groupId>org.apache.geronimo.plugins</groupId>
>>>>>> + <artifactId>activemq-console-jetty</artifactId>
>>>>>> + <version>${version}</version>
>>>>>> + <type>car</type>
>>>>>> + </dependency>
>>>>>> +
>>>>>> + <dependency>
>>>>>> + <groupId>org.apache.geronimo.plugins</groupId>
>>>>>> + <artifactId>debugviews-console-jetty</artifactId>
>>>>>> + <version>${version}</version>
>>>>>> + <type>car</type>
>>>>>> + </dependency>
>>>>>> +
>>>>>> + <dependency>
>>>>>> + <groupId>org.apache.geronimo.plugins</groupId>
>>>>>> + <artifactId>plancreator-console-jetty</artifactId>
>>>>>> + <version>${version}</version>
>>>>>> + <type>car</type>
>>>>>> + </dependency>
>>>>>> +
>>>>>> + <dependency>
>>>>>> + <groupId>org.apache.geronimo.plugins</groupId>
>>>>>> + <artifactId>plugin-console-jetty</artifactId>
>>>>>> + <version>${version}</version>
>>>>>> + <type>car</type>
>>>>>> + </dependency>
>>>>>> +
>>>>>> + <dependency>
>>>>>> + <groupId>org.apache.geronimo.plugins</groupId>
>>>>>> + <artifactId>sysdb-console-jetty</artifactId>
>>>>>> + <version>${version}</version>
>>>>>> + <type>car</type>
>>>>>> + </dependency>
>>>>>> + </dependencies>
>>>>>> +</project>
>>>>>> +
>>>>>>
>>>>>> Propchange: geronimo/server/trunk/plugingroups/console-jetty/pom.xml
>>>>>>
>>>>>>
>>>>>> ------------------------------------------------------------------------------
>>>>>>
>>>>>> svn:eol-style = native
>>>>>>
>>>>>> Propchange: geronimo/server/trunk/plugingroups/console-jetty/pom.xml
>>>>>>
>>>>>>
>>>>>> ------------------------------------------------------------------------------
>>>>>>
>>>>>> svn:keywords = Date Revision
>>>>>>
>>>>>> Propchange: geronimo/server/trunk/plugingroups/console-jetty/pom.xml
>>>>>>
>>>>>>
>>>>>> ------------------------------------------------------------------------------
>>>>>>
>>>>>> svn:mime-type = text/xml
>>>>>>
>>>>>> Added:
>>>>>>
>>>>>> geronimo/server/trunk/plugingroups/console-jetty/src/main/history/dependencies.xml
>>>>>>
>>>>>> URL:
>>>>>>
>>>>>> http://svn.apache.org/viewvc/geronimo/server/trunk/plugingroups/console-jetty/src/main/history/dependencies.xml?rev=702586&view=auto
>>>>>>
>>>>>>
>>>>>>
>>>>>> ==============================================================================
>>>>>>
>>>>>> ---
>>>>>>
>>>>>> geronimo/server/trunk/plugingroups/console-jetty/src/main/history/dependencies.xml
>>>>>>
>>>>>> (added)
>>>>>> +++
>>>>>>
>>>>>> geronimo/server/trunk/plugingroups/console-jetty/src/main/history/dependencies.xml
>>>>>>
>>>>>> Tue Oct 7 12:09:59 2008
>>>>>> @@ -0,0 +1,49 @@
>>>>>> +<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
>>>>>> +<plugin-artifact
>>>>>> xmlns:ns2="http://geronimo.apache.org/xml/ns/attributes-1.2"
>>>>>> xmlns="http://geronimo.apache.org/xml/ns/plugins-1.3">
>>>>>> + <module-id>
>>>>>> + <groupId>org.apache.geronimo.plugingroups</groupId>
>>>>>> + <artifactId>console-jetty</artifactId>
>>>>>> + <version>2.2-SNAPSHOT</version>
>>>>>> + <type>car</type>
>>>>>> + </module-id>
>>>>>> + <dependency>
>>>>>> + <groupId>org.apache.geronimo.plugins</groupId>
>>>>>> + <artifactId>plancreator-console-jetty</artifactId>
>>>>>> + <type>car</type>
>>>>>> + </dependency>
>>>>>> + <dependency>
>>>>>> + <groupId>org.apache.geronimo.plugins</groupId>
>>>>>> + <artifactId>sysdb-console-jetty</artifactId>
>>>>>> + <type>car</type>
>>>>>> + </dependency>
>>>>>> + <dependency>
>>>>>> + <groupId>org.apache.geronimo.plugins</groupId>
>>>>>> + <artifactId>activemq-console-jetty</artifactId>
>>>>>> + <type>car</type>
>>>>>> + </dependency>
>>>>>> + <dependency>
>>>>>> + <groupId>org.apache.geronimo.plugins</groupId>
>>>>>> + <artifactId>plugin-console-jetty</artifactId>
>>>>>> + <type>car</type>
>>>>>> + </dependency>
>>>>>> + <dependency>
>>>>>> + <groupId>org.apache.geronimo.configs</groupId>
>>>>>> + <artifactId>ca-helper-jetty</artifactId>
>>>>>> + <type>car</type>
>>>>>> + </dependency>
>>>>>> + <dependency>
>>>>>> + <groupId>org.apache.geronimo.plugins</groupId>
>>>>>> + <artifactId>debugviews-console-jetty</artifactId>
>>>>>> + <type>car</type>
>>>>>> + </dependency>
>>>>>> + <dependency>
>>>>>> + <groupId>org.apache.geronimo.plugins</groupId>
>>>>>> + <artifactId>mconsole-jetty</artifactId>
>>>>>> + <type>car</type>
>>>>>> + </dependency>
>>>>>> + <dependency>
>>>>>> + <groupId>org.apache.geronimo.plugins</groupId>
>>>>>> + <artifactId>agent</artifactId>
>>>>>> + <type>car</type>
>>>>>> + </dependency>
>>>>>> +</plugin-artifact>
>>>>>>
>>>>>> Propchange:
>>>>>>
>>>>>> geronimo/server/trunk/plugingroups/console-jetty/src/main/history/dependencies.xml
>>>>>>
>>>>>>
>>>>>>
>>>>>> ------------------------------------------------------------------------------
>>>>>>
>>>>>> svn:eol-style = native
>>>>>>
>>>>>> Propchange:
>>>>>>
>>>>>> geronimo/server/trunk/plugingroups/console-jetty/src/main/history/dependencies.xml
>>>>>>
>>>>>>
>>>>>>
>>>>>> ------------------------------------------------------------------------------
>>>>>>
>>>>>> svn:keywords = Date Revision
>>>>>>
>>>>>> Propchange:
>>>>>>
>>>>>> geronimo/server/trunk/plugingroups/console-jetty/src/main/history/dependencies.xml
>>>>>>
>>>>>>
>>>>>>
>>>>>> ------------------------------------------------------------------------------
>>>>>>
>>>>>> svn:mime-type = text/xml
>>>>>>
>>>>>>
>>>>>>
>>
>
Re: svn commit: r702586 - in /geronimo/server/trunk/plugingroups/console-jetty:
./ pom.xml src/ src/main/ src/main/history/ src/main/history/dependencies.xml
src/main/plan/
Posted by Donald Woods <dw...@apache.org>.
In-line.
Lin Sun wrote:
> Thanks for making the suggestions. It is always good to hear
> feedback and challenge our thinking! :)
Yep, I wish we had more than 4 people actively looking/discussing this :-(
>
> My initial thought of grouping the plugins together was by category,
> however I think it has the following limitations -
>
> 1. A user can specify his module to any category he likes too, thus it
> could interfere with the resulting tree. For example, a user has a
> module that is also categorized as console or development tools or
> administration.
>
Don't see this as an issue, since we control the default repository-list
and what goes into the geronimo-plugins.xml for the server and samples.
If a user created their own repo (like Liferay) then their plugins
would be listed under the "Liferay Repo" instead of the "Geronimo Server
Repo" and they could use whatever categories they want.
> 2. group by category doesn't offer any integration into maven. As you
> know, we are using plugin groups for all of our G assemblies now.
>
I'm questioning if this "maven integration" is worth the added source
complexity. I'm starting to lean heavily towards "No" and wondering if
we should remove most of the pluginprofiles for 2.2 and only keep -
framework, minimal and jee5. Once we get user feedback on what
groupings "are missing" then we can consider adding more.
> 3. group by category doesn't help with command line install-plugin
> command. Currently you can install a plugin group by using "deploy
> install-plugin <plugingroup id>"
>
It would have to be enhanced, which it greatly needs IMO.
> 4. group by category doesn't help with "gshell deploy/assemble"
> command. A user is unlikely to have some fancy GUI like tree in a
> command line env.
If a user is trying to assemble from cmdline, then they will suffer and
should either write a gsh script, use c-m-p or the console.
>
> With plugin groups, you can still group plugins by category. In fact,
> in the install plugin portlet that we allow users to sort plugins by
> category, name, etc. I disabled the sort function in assemble server
> portlet as it needs more work but the plugins are sorted by category
> right now.
>
> I think I agree with you that the console-xxx plugin group are not
> that useful and I think they can be removed after we make most of the
> console components optional. Currently, all these console components
> are under application plugins, and I 'm updating their names, desps,
> and categories to enable users to select them easily. For example,
> if a user wants little G tomcat + JMS, he can select web-tomcat, JMS
> plugin group, and Console: JMS from application plugins if he wants
> console support for JMS.
>
> Lin
>
> On Wed, Oct 8, 2008 at 1:48 PM, Donald Woods <dw...@apache.org> wrote:
>> It seems that most of the functionality now delivered in the profilegroups
>> could have been implemented by just properly setting the plugin category
>> attribute to a useful "plugin group" name and use the source repo for the
>> plugin to denote they are base server plugins vs. Samples vs. a "Console"
>> plugin from a third-party.
>>
>> For something like the activemq portlets, we'd just set category=Console.
>>
>> Then modifying the plugin installer to build a tree of plugin groups and
>> allow the user to select one or more "groups" of plugins, like console, or
>> choose specific plugins from within a group, like everything under console
>> except the activemq portlets. (We would also add some logic to only select
>> Tomcat or Jetty plugins based on which is already installed or prompt the
>> user to choose.)
>>
>> That would allow us to have one set of plugins (the real ones) and only have
>> LOGICAL groupings (instead of the physical ones now under plugingroups/)
>> based on the defined category. The user would then see something like -
>>
>> - Apache Geronimo Server repository
>> |--+ Console
>> | |- ActiveMQ Console
>> | |- Dojo
>> | |- . . .
>> |
>> |--+ Web Container
>> | |- Tomcat6
>> | |- Jetty6
>> |
>> . . .
>>
>> There are still some cases where we'd want to use the new c-m-p support for
>> not creating a classloader, like using it to generate a "minimal web" and
>> "full jee5" grouping/profile/template that users could rely on for creating
>> their own custom assemblies with c-m-p without having to create a complete
>> assembly build.
>>
>>
>> -Donald
>>
>>
>>
>> Lin Sun wrote:
>>> These are the console plugin groups, basically it provides the
>>> required console function for the javaee5 assemblies. I think the
>>> list suggested the following profiles a while back ago:
>>> JMS
>>> EJB
>>> Web Services
>>> Admin Console
>>> ...
>>>
>>> Also, I need the console plugin group to construct the javaee5 plugin
>>> groups/assemblies.
>>>
>>> Regarding activemq-console-xxx, my initial thought was to include it
>>> in the JMS plugin group, but I realize that you are working on the
>>> optional console and people may not want the JMS console function when
>>> they want JMS function (for example, there is one user trying to add
>>> JMS on top of little G). When you have your optional console stuff
>>> in, you can remove the optional ones from the console plugin group.
>>>
>>> Plugin groups are basically groups of plugins for users to easily
>>> understand and consume them. They can be used in the following ways:
>>> 1. custom server assemblies
>>> 2. G server assemblies (framework, javaee5)
>>> 3. install plugin group as regular plugin. For example, a user should
>>> be able to install the JMS plugin group in little G to get little G +
>>> JMS environment.
>>>
>>> Lin
>>>
>>> On Tue, Oct 7, 2008 at 11:03 PM, Donald Woods <dw...@apache.org> wrote:
>>>> Why are we recreating the existing console-jetty and console-tomcat as
>>>> yet
>>>> another plugin?
>>>>
>>>> Also, why are you including optional console plugins like
>>>> activemq-console-xxx, which should only be included if the ActiveMQ
>>>> plugins
>>>> are installed? By including it here, you're basically pulling in the JMS
>>>> plugins.
>>>>
>>>> I'm starting to reconsider why we need plugingroups, if we're going to
>>>> have
>>>> to recreate dozens of existing plugins just in a slightly different
>>>> format
>>>> just so we can include them in a special view just for custom server
>>>> assemblies....
>>>>
>>>>
>>>>
>>>> -Donald
>>>>
>>>>
>>>> linsun@apache.org wrote:
>>>>> Author: linsun
>>>>> Date: Tue Oct 7 12:09:59 2008
>>>>> New Revision: 702586
>>>>>
>>>>> URL: http://svn.apache.org/viewvc?rev=702586&view=rev
>>>>> Log:
>>>>> Add the console-jetty plugin group
>>>>>
>>>>> Added:
>>>>> geronimo/server/trunk/plugingroups/console-jetty/
>>>>> geronimo/server/trunk/plugingroups/console-jetty/pom.xml (with
>>>>> props)
>>>>> geronimo/server/trunk/plugingroups/console-jetty/src/
>>>>> geronimo/server/trunk/plugingroups/console-jetty/src/main/
>>>>> geronimo/server/trunk/plugingroups/console-jetty/src/main/history/
>>>>>
>>>>>
>>>>> geronimo/server/trunk/plugingroups/console-jetty/src/main/history/dependencies.xml
>>>>> (with props)
>>>>> geronimo/server/trunk/plugingroups/console-jetty/src/main/plan/
>>>>>
>>>>> Added: geronimo/server/trunk/plugingroups/console-jetty/pom.xml
>>>>> URL:
>>>>>
>>>>> http://svn.apache.org/viewvc/geronimo/server/trunk/plugingroups/console-jetty/pom.xml?rev=702586&view=auto
>>>>>
>>>>>
>>>>> ==============================================================================
>>>>> --- geronimo/server/trunk/plugingroups/console-jetty/pom.xml (added)
>>>>> +++ geronimo/server/trunk/plugingroups/console-jetty/pom.xml Tue Oct 7
>>>>> 12:09:59 2008
>>>>> @@ -0,0 +1,98 @@
>>>>> +<?xml version="1.0" encoding="ISO-8859-1"?>
>>>>> +<!--
>>>>> + Licensed to the Apache Software Foundation (ASF) under one
>>>>> + or more contributor license agreements. See the NOTICE file
>>>>> + distributed with this work for additional information
>>>>> + regarding copyright ownership. The ASF licenses this file
>>>>> + to you under the Apache License, Version 2.0 (the
>>>>> + "License"); you may not use this file except in compliance
>>>>> + with the License. You may obtain a copy of the License at
>>>>> + + http://www.apache.org/licenses/LICENSE-2.0
>>>>> + + Unless required by applicable law or agreed to in writing,
>>>>> + software distributed under the License is distributed on an
>>>>> + "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
>>>>> + KIND, either express or implied. See the License for the
>>>>> + specific language governing permissions and limitations
>>>>> + under the License.
>>>>> +-->
>>>>> +<!-- @version $Rev$ $Date$ -->
>>>>> +
>>>>> +<project xmlns="http://maven.apache.org/POM/4.0.0"
>>>>> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>>>>> xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
>>>>> http://maven.apache.org/maven-v4_0_0.xsd">
>>>>> +
>>>>> + <modelVersion>4.0.0</modelVersion>
>>>>> +
>>>>> + <parent>
>>>>> + <groupId>org.apache.geronimo.plugingroups</groupId>
>>>>> + <artifactId>plugingroups</artifactId>
>>>>> + <version>2.2-SNAPSHOT</version>
>>>>> + </parent>
>>>>> +
>>>>> + <artifactId>console-jetty</artifactId>
>>>>> + <packaging>car</packaging>
>>>>> + <name>Geronimo Plugin Group :: Admin Console Jetty</name>
>>>>> +
>>>>> + <description>
>>>>> + This plugin group provides Admin Console Jetty functionality.
>>>>> + </description>
>>>>> +
>>>>> + <dependencies>
>>>>> + <dependency>
>>>>> + <groupId>org.apache.geronimo.configs</groupId>
>>>>> + <artifactId>ca-helper-jetty</artifactId>
>>>>> + <version>${version}</version>
>>>>> + <type>car</type>
>>>>> + </dependency>
>>>>> +
>>>>> + <dependency>
>>>>> + <groupId>org.apache.geronimo.plugins</groupId>
>>>>> + <artifactId>agent</artifactId>
>>>>> + <version>${version}</version>
>>>>> + <type>car</type>
>>>>> + </dependency>
>>>>> +
>>>>> + <dependency>
>>>>> + <groupId>org.apache.geronimo.plugins</groupId>
>>>>> + <artifactId>mconsole-jetty</artifactId>
>>>>> + <version>${version}</version>
>>>>> + <type>car</type>
>>>>> + </dependency>
>>>>> +
>>>>> + <dependency>
>>>>> + <groupId>org.apache.geronimo.plugins</groupId>
>>>>> + <artifactId>activemq-console-jetty</artifactId>
>>>>> + <version>${version}</version>
>>>>> + <type>car</type>
>>>>> + </dependency>
>>>>> +
>>>>> + <dependency>
>>>>> + <groupId>org.apache.geronimo.plugins</groupId>
>>>>> + <artifactId>debugviews-console-jetty</artifactId>
>>>>> + <version>${version}</version>
>>>>> + <type>car</type>
>>>>> + </dependency>
>>>>> +
>>>>> + <dependency>
>>>>> + <groupId>org.apache.geronimo.plugins</groupId>
>>>>> + <artifactId>plancreator-console-jetty</artifactId>
>>>>> + <version>${version}</version>
>>>>> + <type>car</type>
>>>>> + </dependency>
>>>>> +
>>>>> + <dependency>
>>>>> + <groupId>org.apache.geronimo.plugins</groupId>
>>>>> + <artifactId>plugin-console-jetty</artifactId>
>>>>> + <version>${version}</version>
>>>>> + <type>car</type>
>>>>> + </dependency>
>>>>> +
>>>>> + <dependency>
>>>>> + <groupId>org.apache.geronimo.plugins</groupId>
>>>>> + <artifactId>sysdb-console-jetty</artifactId>
>>>>> + <version>${version}</version>
>>>>> + <type>car</type>
>>>>> + </dependency>
>>>>> + </dependencies>
>>>>> +</project>
>>>>> +
>>>>>
>>>>> Propchange: geronimo/server/trunk/plugingroups/console-jetty/pom.xml
>>>>>
>>>>>
>>>>> ------------------------------------------------------------------------------
>>>>> svn:eol-style = native
>>>>>
>>>>> Propchange: geronimo/server/trunk/plugingroups/console-jetty/pom.xml
>>>>>
>>>>>
>>>>> ------------------------------------------------------------------------------
>>>>> svn:keywords = Date Revision
>>>>>
>>>>> Propchange: geronimo/server/trunk/plugingroups/console-jetty/pom.xml
>>>>>
>>>>>
>>>>> ------------------------------------------------------------------------------
>>>>> svn:mime-type = text/xml
>>>>>
>>>>> Added:
>>>>>
>>>>> geronimo/server/trunk/plugingroups/console-jetty/src/main/history/dependencies.xml
>>>>> URL:
>>>>>
>>>>> http://svn.apache.org/viewvc/geronimo/server/trunk/plugingroups/console-jetty/src/main/history/dependencies.xml?rev=702586&view=auto
>>>>>
>>>>>
>>>>> ==============================================================================
>>>>> ---
>>>>>
>>>>> geronimo/server/trunk/plugingroups/console-jetty/src/main/history/dependencies.xml
>>>>> (added)
>>>>> +++
>>>>>
>>>>> geronimo/server/trunk/plugingroups/console-jetty/src/main/history/dependencies.xml
>>>>> Tue Oct 7 12:09:59 2008
>>>>> @@ -0,0 +1,49 @@
>>>>> +<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
>>>>> +<plugin-artifact
>>>>> xmlns:ns2="http://geronimo.apache.org/xml/ns/attributes-1.2"
>>>>> xmlns="http://geronimo.apache.org/xml/ns/plugins-1.3">
>>>>> + <module-id>
>>>>> + <groupId>org.apache.geronimo.plugingroups</groupId>
>>>>> + <artifactId>console-jetty</artifactId>
>>>>> + <version>2.2-SNAPSHOT</version>
>>>>> + <type>car</type>
>>>>> + </module-id>
>>>>> + <dependency>
>>>>> + <groupId>org.apache.geronimo.plugins</groupId>
>>>>> + <artifactId>plancreator-console-jetty</artifactId>
>>>>> + <type>car</type>
>>>>> + </dependency>
>>>>> + <dependency>
>>>>> + <groupId>org.apache.geronimo.plugins</groupId>
>>>>> + <artifactId>sysdb-console-jetty</artifactId>
>>>>> + <type>car</type>
>>>>> + </dependency>
>>>>> + <dependency>
>>>>> + <groupId>org.apache.geronimo.plugins</groupId>
>>>>> + <artifactId>activemq-console-jetty</artifactId>
>>>>> + <type>car</type>
>>>>> + </dependency>
>>>>> + <dependency>
>>>>> + <groupId>org.apache.geronimo.plugins</groupId>
>>>>> + <artifactId>plugin-console-jetty</artifactId>
>>>>> + <type>car</type>
>>>>> + </dependency>
>>>>> + <dependency>
>>>>> + <groupId>org.apache.geronimo.configs</groupId>
>>>>> + <artifactId>ca-helper-jetty</artifactId>
>>>>> + <type>car</type>
>>>>> + </dependency>
>>>>> + <dependency>
>>>>> + <groupId>org.apache.geronimo.plugins</groupId>
>>>>> + <artifactId>debugviews-console-jetty</artifactId>
>>>>> + <type>car</type>
>>>>> + </dependency>
>>>>> + <dependency>
>>>>> + <groupId>org.apache.geronimo.plugins</groupId>
>>>>> + <artifactId>mconsole-jetty</artifactId>
>>>>> + <type>car</type>
>>>>> + </dependency>
>>>>> + <dependency>
>>>>> + <groupId>org.apache.geronimo.plugins</groupId>
>>>>> + <artifactId>agent</artifactId>
>>>>> + <type>car</type>
>>>>> + </dependency>
>>>>> +</plugin-artifact>
>>>>>
>>>>> Propchange:
>>>>>
>>>>> geronimo/server/trunk/plugingroups/console-jetty/src/main/history/dependencies.xml
>>>>>
>>>>>
>>>>> ------------------------------------------------------------------------------
>>>>> svn:eol-style = native
>>>>>
>>>>> Propchange:
>>>>>
>>>>> geronimo/server/trunk/plugingroups/console-jetty/src/main/history/dependencies.xml
>>>>>
>>>>>
>>>>> ------------------------------------------------------------------------------
>>>>> svn:keywords = Date Revision
>>>>>
>>>>> Propchange:
>>>>>
>>>>> geronimo/server/trunk/plugingroups/console-jetty/src/main/history/dependencies.xml
>>>>>
>>>>>
>>>>> ------------------------------------------------------------------------------
>>>>> svn:mime-type = text/xml
>>>>>
>>>>>
>>>>>
>
Re: svn commit: r702586 - in /geronimo/server/trunk/plugingroups/console-jetty: ./ pom.xml src/ src/main/ src/main/history/ src/main/history/dependencies.xml src/main/plan/
Posted by Lin Sun <li...@gmail.com>.
Thanks for making the suggestions. It is always good to hear
feedback and challenge our thinking! :)
My initial thought of grouping the plugins together was by category,
however I think it has the following limitations -
1. A user can specify his module to any category he likes too, thus it
could interfere with the resulting tree. For example, a user has a
module that is also categorized as console or development tools or
administration.
2. group by category doesn't offer any integration into maven. As you
know, we are using plugin groups for all of our G assemblies now.
3. group by category doesn't help with command line install-plugin
command. Currently you can install a plugin group by using "deploy
install-plugin <plugingroup id>"
4. group by category doesn't help with "gshell deploy/assemble"
command. A user is unlikely to have some fancy GUI like tree in a
command line env.
With plugin groups, you can still group plugins by category. In fact,
in the install plugin portlet that we allow users to sort plugins by
category, name, etc. I disabled the sort function in assemble server
portlet as it needs more work but the plugins are sorted by category
right now.
I think I agree with you that the console-xxx plugin group are not
that useful and I think they can be removed after we make most of the
console components optional. Currently, all these console components
are under application plugins, and I 'm updating their names, desps,
and categories to enable users to select them easily. For example,
if a user wants little G tomcat + JMS, he can select web-tomcat, JMS
plugin group, and Console: JMS from application plugins if he wants
console support for JMS.
Lin
On Wed, Oct 8, 2008 at 1:48 PM, Donald Woods <dw...@apache.org> wrote:
> It seems that most of the functionality now delivered in the profilegroups
> could have been implemented by just properly setting the plugin category
> attribute to a useful "plugin group" name and use the source repo for the
> plugin to denote they are base server plugins vs. Samples vs. a "Console"
> plugin from a third-party.
>
> For something like the activemq portlets, we'd just set category=Console.
>
> Then modifying the plugin installer to build a tree of plugin groups and
> allow the user to select one or more "groups" of plugins, like console, or
> choose specific plugins from within a group, like everything under console
> except the activemq portlets. (We would also add some logic to only select
> Tomcat or Jetty plugins based on which is already installed or prompt the
> user to choose.)
>
> That would allow us to have one set of plugins (the real ones) and only have
> LOGICAL groupings (instead of the physical ones now under plugingroups/)
> based on the defined category. The user would then see something like -
>
> - Apache Geronimo Server repository
> |--+ Console
> | |- ActiveMQ Console
> | |- Dojo
> | |- . . .
> |
> |--+ Web Container
> | |- Tomcat6
> | |- Jetty6
> |
> . . .
>
> There are still some cases where we'd want to use the new c-m-p support for
> not creating a classloader, like using it to generate a "minimal web" and
> "full jee5" grouping/profile/template that users could rely on for creating
> their own custom assemblies with c-m-p without having to create a complete
> assembly build.
>
>
> -Donald
>
>
>
> Lin Sun wrote:
>>
>> These are the console plugin groups, basically it provides the
>> required console function for the javaee5 assemblies. I think the
>> list suggested the following profiles a while back ago:
>> JMS
>> EJB
>> Web Services
>> Admin Console
>> ...
>>
>> Also, I need the console plugin group to construct the javaee5 plugin
>> groups/assemblies.
>>
>> Regarding activemq-console-xxx, my initial thought was to include it
>> in the JMS plugin group, but I realize that you are working on the
>> optional console and people may not want the JMS console function when
>> they want JMS function (for example, there is one user trying to add
>> JMS on top of little G). When you have your optional console stuff
>> in, you can remove the optional ones from the console plugin group.
>>
>> Plugin groups are basically groups of plugins for users to easily
>> understand and consume them. They can be used in the following ways:
>> 1. custom server assemblies
>> 2. G server assemblies (framework, javaee5)
>> 3. install plugin group as regular plugin. For example, a user should
>> be able to install the JMS plugin group in little G to get little G +
>> JMS environment.
>>
>> Lin
>>
>> On Tue, Oct 7, 2008 at 11:03 PM, Donald Woods <dw...@apache.org> wrote:
>>>
>>> Why are we recreating the existing console-jetty and console-tomcat as
>>> yet
>>> another plugin?
>>>
>>> Also, why are you including optional console plugins like
>>> activemq-console-xxx, which should only be included if the ActiveMQ
>>> plugins
>>> are installed? By including it here, you're basically pulling in the JMS
>>> plugins.
>>>
>>> I'm starting to reconsider why we need plugingroups, if we're going to
>>> have
>>> to recreate dozens of existing plugins just in a slightly different
>>> format
>>> just so we can include them in a special view just for custom server
>>> assemblies....
>>>
>>>
>>>
>>> -Donald
>>>
>>>
>>> linsun@apache.org wrote:
>>>>
>>>> Author: linsun
>>>> Date: Tue Oct 7 12:09:59 2008
>>>> New Revision: 702586
>>>>
>>>> URL: http://svn.apache.org/viewvc?rev=702586&view=rev
>>>> Log:
>>>> Add the console-jetty plugin group
>>>>
>>>> Added:
>>>> geronimo/server/trunk/plugingroups/console-jetty/
>>>> geronimo/server/trunk/plugingroups/console-jetty/pom.xml (with
>>>> props)
>>>> geronimo/server/trunk/plugingroups/console-jetty/src/
>>>> geronimo/server/trunk/plugingroups/console-jetty/src/main/
>>>> geronimo/server/trunk/plugingroups/console-jetty/src/main/history/
>>>>
>>>>
>>>> geronimo/server/trunk/plugingroups/console-jetty/src/main/history/dependencies.xml
>>>> (with props)
>>>> geronimo/server/trunk/plugingroups/console-jetty/src/main/plan/
>>>>
>>>> Added: geronimo/server/trunk/plugingroups/console-jetty/pom.xml
>>>> URL:
>>>>
>>>> http://svn.apache.org/viewvc/geronimo/server/trunk/plugingroups/console-jetty/pom.xml?rev=702586&view=auto
>>>>
>>>>
>>>> ==============================================================================
>>>> --- geronimo/server/trunk/plugingroups/console-jetty/pom.xml (added)
>>>> +++ geronimo/server/trunk/plugingroups/console-jetty/pom.xml Tue Oct 7
>>>> 12:09:59 2008
>>>> @@ -0,0 +1,98 @@
>>>> +<?xml version="1.0" encoding="ISO-8859-1"?>
>>>> +<!--
>>>> + Licensed to the Apache Software Foundation (ASF) under one
>>>> + or more contributor license agreements. See the NOTICE file
>>>> + distributed with this work for additional information
>>>> + regarding copyright ownership. The ASF licenses this file
>>>> + to you under the Apache License, Version 2.0 (the
>>>> + "License"); you may not use this file except in compliance
>>>> + with the License. You may obtain a copy of the License at
>>>> + + http://www.apache.org/licenses/LICENSE-2.0
>>>> + + Unless required by applicable law or agreed to in writing,
>>>> + software distributed under the License is distributed on an
>>>> + "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
>>>> + KIND, either express or implied. See the License for the
>>>> + specific language governing permissions and limitations
>>>> + under the License.
>>>> +-->
>>>> +<!-- @version $Rev$ $Date$ -->
>>>> +
>>>> +<project xmlns="http://maven.apache.org/POM/4.0.0"
>>>> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>>>> xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
>>>> http://maven.apache.org/maven-v4_0_0.xsd">
>>>> +
>>>> + <modelVersion>4.0.0</modelVersion>
>>>> +
>>>> + <parent>
>>>> + <groupId>org.apache.geronimo.plugingroups</groupId>
>>>> + <artifactId>plugingroups</artifactId>
>>>> + <version>2.2-SNAPSHOT</version>
>>>> + </parent>
>>>> +
>>>> + <artifactId>console-jetty</artifactId>
>>>> + <packaging>car</packaging>
>>>> + <name>Geronimo Plugin Group :: Admin Console Jetty</name>
>>>> +
>>>> + <description>
>>>> + This plugin group provides Admin Console Jetty functionality.
>>>> + </description>
>>>> +
>>>> + <dependencies>
>>>> + <dependency>
>>>> + <groupId>org.apache.geronimo.configs</groupId>
>>>> + <artifactId>ca-helper-jetty</artifactId>
>>>> + <version>${version}</version>
>>>> + <type>car</type>
>>>> + </dependency>
>>>> +
>>>> + <dependency>
>>>> + <groupId>org.apache.geronimo.plugins</groupId>
>>>> + <artifactId>agent</artifactId>
>>>> + <version>${version}</version>
>>>> + <type>car</type>
>>>> + </dependency>
>>>> +
>>>> + <dependency>
>>>> + <groupId>org.apache.geronimo.plugins</groupId>
>>>> + <artifactId>mconsole-jetty</artifactId>
>>>> + <version>${version}</version>
>>>> + <type>car</type>
>>>> + </dependency>
>>>> +
>>>> + <dependency>
>>>> + <groupId>org.apache.geronimo.plugins</groupId>
>>>> + <artifactId>activemq-console-jetty</artifactId>
>>>> + <version>${version}</version>
>>>> + <type>car</type>
>>>> + </dependency>
>>>> +
>>>> + <dependency>
>>>> + <groupId>org.apache.geronimo.plugins</groupId>
>>>> + <artifactId>debugviews-console-jetty</artifactId>
>>>> + <version>${version}</version>
>>>> + <type>car</type>
>>>> + </dependency>
>>>> +
>>>> + <dependency>
>>>> + <groupId>org.apache.geronimo.plugins</groupId>
>>>> + <artifactId>plancreator-console-jetty</artifactId>
>>>> + <version>${version}</version>
>>>> + <type>car</type>
>>>> + </dependency>
>>>> +
>>>> + <dependency>
>>>> + <groupId>org.apache.geronimo.plugins</groupId>
>>>> + <artifactId>plugin-console-jetty</artifactId>
>>>> + <version>${version}</version>
>>>> + <type>car</type>
>>>> + </dependency>
>>>> +
>>>> + <dependency>
>>>> + <groupId>org.apache.geronimo.plugins</groupId>
>>>> + <artifactId>sysdb-console-jetty</artifactId>
>>>> + <version>${version}</version>
>>>> + <type>car</type>
>>>> + </dependency>
>>>> + </dependencies>
>>>> +</project>
>>>> +
>>>>
>>>> Propchange: geronimo/server/trunk/plugingroups/console-jetty/pom.xml
>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>> svn:eol-style = native
>>>>
>>>> Propchange: geronimo/server/trunk/plugingroups/console-jetty/pom.xml
>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>> svn:keywords = Date Revision
>>>>
>>>> Propchange: geronimo/server/trunk/plugingroups/console-jetty/pom.xml
>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>> svn:mime-type = text/xml
>>>>
>>>> Added:
>>>>
>>>> geronimo/server/trunk/plugingroups/console-jetty/src/main/history/dependencies.xml
>>>> URL:
>>>>
>>>> http://svn.apache.org/viewvc/geronimo/server/trunk/plugingroups/console-jetty/src/main/history/dependencies.xml?rev=702586&view=auto
>>>>
>>>>
>>>> ==============================================================================
>>>> ---
>>>>
>>>> geronimo/server/trunk/plugingroups/console-jetty/src/main/history/dependencies.xml
>>>> (added)
>>>> +++
>>>>
>>>> geronimo/server/trunk/plugingroups/console-jetty/src/main/history/dependencies.xml
>>>> Tue Oct 7 12:09:59 2008
>>>> @@ -0,0 +1,49 @@
>>>> +<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
>>>> +<plugin-artifact
>>>> xmlns:ns2="http://geronimo.apache.org/xml/ns/attributes-1.2"
>>>> xmlns="http://geronimo.apache.org/xml/ns/plugins-1.3">
>>>> + <module-id>
>>>> + <groupId>org.apache.geronimo.plugingroups</groupId>
>>>> + <artifactId>console-jetty</artifactId>
>>>> + <version>2.2-SNAPSHOT</version>
>>>> + <type>car</type>
>>>> + </module-id>
>>>> + <dependency>
>>>> + <groupId>org.apache.geronimo.plugins</groupId>
>>>> + <artifactId>plancreator-console-jetty</artifactId>
>>>> + <type>car</type>
>>>> + </dependency>
>>>> + <dependency>
>>>> + <groupId>org.apache.geronimo.plugins</groupId>
>>>> + <artifactId>sysdb-console-jetty</artifactId>
>>>> + <type>car</type>
>>>> + </dependency>
>>>> + <dependency>
>>>> + <groupId>org.apache.geronimo.plugins</groupId>
>>>> + <artifactId>activemq-console-jetty</artifactId>
>>>> + <type>car</type>
>>>> + </dependency>
>>>> + <dependency>
>>>> + <groupId>org.apache.geronimo.plugins</groupId>
>>>> + <artifactId>plugin-console-jetty</artifactId>
>>>> + <type>car</type>
>>>> + </dependency>
>>>> + <dependency>
>>>> + <groupId>org.apache.geronimo.configs</groupId>
>>>> + <artifactId>ca-helper-jetty</artifactId>
>>>> + <type>car</type>
>>>> + </dependency>
>>>> + <dependency>
>>>> + <groupId>org.apache.geronimo.plugins</groupId>
>>>> + <artifactId>debugviews-console-jetty</artifactId>
>>>> + <type>car</type>
>>>> + </dependency>
>>>> + <dependency>
>>>> + <groupId>org.apache.geronimo.plugins</groupId>
>>>> + <artifactId>mconsole-jetty</artifactId>
>>>> + <type>car</type>
>>>> + </dependency>
>>>> + <dependency>
>>>> + <groupId>org.apache.geronimo.plugins</groupId>
>>>> + <artifactId>agent</artifactId>
>>>> + <type>car</type>
>>>> + </dependency>
>>>> +</plugin-artifact>
>>>>
>>>> Propchange:
>>>>
>>>> geronimo/server/trunk/plugingroups/console-jetty/src/main/history/dependencies.xml
>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>> svn:eol-style = native
>>>>
>>>> Propchange:
>>>>
>>>> geronimo/server/trunk/plugingroups/console-jetty/src/main/history/dependencies.xml
>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>> svn:keywords = Date Revision
>>>>
>>>> Propchange:
>>>>
>>>> geronimo/server/trunk/plugingroups/console-jetty/src/main/history/dependencies.xml
>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>> svn:mime-type = text/xml
>>>>
>>>>
>>>>
>>
>
Re: svn commit: r702586 - in /geronimo/server/trunk/plugingroups/console-jetty:
./ pom.xml src/ src/main/ src/main/history/ src/main/history/dependencies.xml
src/main/plan/
Posted by Donald Woods <dw...@apache.org>.
It seems that most of the functionality now delivered in the
profilegroups could have been implemented by just properly setting the
plugin category attribute to a useful "plugin group" name and use the
source repo for the plugin to denote they are base server plugins vs.
Samples vs. a "Console" plugin from a third-party.
For something like the activemq portlets, we'd just set category=Console.
Then modifying the plugin installer to build a tree of plugin groups and
allow the user to select one or more "groups" of plugins, like console,
or choose specific plugins from within a group, like everything under
console except the activemq portlets. (We would also add some logic to
only select Tomcat or Jetty plugins based on which is already installed
or prompt the user to choose.)
That would allow us to have one set of plugins (the real ones) and only
have LOGICAL groupings (instead of the physical ones now under
plugingroups/) based on the defined category. The user would then see
something like -
- Apache Geronimo Server repository
|--+ Console
| |- ActiveMQ Console
| |- Dojo
| |- . . .
|
|--+ Web Container
| |- Tomcat6
| |- Jetty6
|
. . .
There are still some cases where we'd want to use the new c-m-p support
for not creating a classloader, like using it to generate a "minimal
web" and "full jee5" grouping/profile/template that users could rely on
for creating their own custom assemblies with c-m-p without having to
create a complete assembly build.
-Donald
Lin Sun wrote:
> These are the console plugin groups, basically it provides the
> required console function for the javaee5 assemblies. I think the
> list suggested the following profiles a while back ago:
> JMS
> EJB
> Web Services
> Admin Console
> ...
>
> Also, I need the console plugin group to construct the javaee5 plugin
> groups/assemblies.
>
> Regarding activemq-console-xxx, my initial thought was to include it
> in the JMS plugin group, but I realize that you are working on the
> optional console and people may not want the JMS console function when
> they want JMS function (for example, there is one user trying to add
> JMS on top of little G). When you have your optional console stuff
> in, you can remove the optional ones from the console plugin group.
>
> Plugin groups are basically groups of plugins for users to easily
> understand and consume them. They can be used in the following ways:
> 1. custom server assemblies
> 2. G server assemblies (framework, javaee5)
> 3. install plugin group as regular plugin. For example, a user should
> be able to install the JMS plugin group in little G to get little G +
> JMS environment.
>
> Lin
>
> On Tue, Oct 7, 2008 at 11:03 PM, Donald Woods <dw...@apache.org> wrote:
>> Why are we recreating the existing console-jetty and console-tomcat as yet
>> another plugin?
>>
>> Also, why are you including optional console plugins like
>> activemq-console-xxx, which should only be included if the ActiveMQ plugins
>> are installed? By including it here, you're basically pulling in the JMS
>> plugins.
>>
>> I'm starting to reconsider why we need plugingroups, if we're going to have
>> to recreate dozens of existing plugins just in a slightly different format
>> just so we can include them in a special view just for custom server
>> assemblies....
>>
>>
>>
>> -Donald
>>
>>
>> linsun@apache.org wrote:
>>> Author: linsun
>>> Date: Tue Oct 7 12:09:59 2008
>>> New Revision: 702586
>>>
>>> URL: http://svn.apache.org/viewvc?rev=702586&view=rev
>>> Log:
>>> Add the console-jetty plugin group
>>>
>>> Added:
>>> geronimo/server/trunk/plugingroups/console-jetty/
>>> geronimo/server/trunk/plugingroups/console-jetty/pom.xml (with props)
>>> geronimo/server/trunk/plugingroups/console-jetty/src/
>>> geronimo/server/trunk/plugingroups/console-jetty/src/main/
>>> geronimo/server/trunk/plugingroups/console-jetty/src/main/history/
>>>
>>> geronimo/server/trunk/plugingroups/console-jetty/src/main/history/dependencies.xml
>>> (with props)
>>> geronimo/server/trunk/plugingroups/console-jetty/src/main/plan/
>>>
>>> Added: geronimo/server/trunk/plugingroups/console-jetty/pom.xml
>>> URL:
>>> http://svn.apache.org/viewvc/geronimo/server/trunk/plugingroups/console-jetty/pom.xml?rev=702586&view=auto
>>>
>>> ==============================================================================
>>> --- geronimo/server/trunk/plugingroups/console-jetty/pom.xml (added)
>>> +++ geronimo/server/trunk/plugingroups/console-jetty/pom.xml Tue Oct 7
>>> 12:09:59 2008
>>> @@ -0,0 +1,98 @@
>>> +<?xml version="1.0" encoding="ISO-8859-1"?>
>>> +<!--
>>> + Licensed to the Apache Software Foundation (ASF) under one
>>> + or more contributor license agreements. See the NOTICE file
>>> + distributed with this work for additional information
>>> + regarding copyright ownership. The ASF licenses this file
>>> + to you under the Apache License, Version 2.0 (the
>>> + "License"); you may not use this file except in compliance
>>> + with the License. You may obtain a copy of the License at
>>> + + http://www.apache.org/licenses/LICENSE-2.0
>>> + + Unless required by applicable law or agreed to in writing,
>>> + software distributed under the License is distributed on an
>>> + "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
>>> + KIND, either express or implied. See the License for the
>>> + specific language governing permissions and limitations
>>> + under the License.
>>> +-->
>>> +<!-- @version $Rev$ $Date$ -->
>>> +
>>> +<project xmlns="http://maven.apache.org/POM/4.0.0"
>>> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>>> xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
>>> http://maven.apache.org/maven-v4_0_0.xsd">
>>> +
>>> + <modelVersion>4.0.0</modelVersion>
>>> +
>>> + <parent>
>>> + <groupId>org.apache.geronimo.plugingroups</groupId>
>>> + <artifactId>plugingroups</artifactId>
>>> + <version>2.2-SNAPSHOT</version>
>>> + </parent>
>>> +
>>> + <artifactId>console-jetty</artifactId>
>>> + <packaging>car</packaging>
>>> + <name>Geronimo Plugin Group :: Admin Console Jetty</name>
>>> +
>>> + <description>
>>> + This plugin group provides Admin Console Jetty functionality.
>>> + </description>
>>> +
>>> + <dependencies>
>>> + <dependency>
>>> + <groupId>org.apache.geronimo.configs</groupId>
>>> + <artifactId>ca-helper-jetty</artifactId>
>>> + <version>${version}</version>
>>> + <type>car</type>
>>> + </dependency>
>>> +
>>> + <dependency>
>>> + <groupId>org.apache.geronimo.plugins</groupId>
>>> + <artifactId>agent</artifactId>
>>> + <version>${version}</version>
>>> + <type>car</type>
>>> + </dependency>
>>> +
>>> + <dependency>
>>> + <groupId>org.apache.geronimo.plugins</groupId>
>>> + <artifactId>mconsole-jetty</artifactId>
>>> + <version>${version}</version>
>>> + <type>car</type>
>>> + </dependency>
>>> +
>>> + <dependency>
>>> + <groupId>org.apache.geronimo.plugins</groupId>
>>> + <artifactId>activemq-console-jetty</artifactId>
>>> + <version>${version}</version>
>>> + <type>car</type>
>>> + </dependency>
>>> +
>>> + <dependency>
>>> + <groupId>org.apache.geronimo.plugins</groupId>
>>> + <artifactId>debugviews-console-jetty</artifactId>
>>> + <version>${version}</version>
>>> + <type>car</type>
>>> + </dependency>
>>> +
>>> + <dependency>
>>> + <groupId>org.apache.geronimo.plugins</groupId>
>>> + <artifactId>plancreator-console-jetty</artifactId>
>>> + <version>${version}</version>
>>> + <type>car</type>
>>> + </dependency>
>>> +
>>> + <dependency>
>>> + <groupId>org.apache.geronimo.plugins</groupId>
>>> + <artifactId>plugin-console-jetty</artifactId>
>>> + <version>${version}</version>
>>> + <type>car</type>
>>> + </dependency>
>>> +
>>> + <dependency>
>>> + <groupId>org.apache.geronimo.plugins</groupId>
>>> + <artifactId>sysdb-console-jetty</artifactId>
>>> + <version>${version}</version>
>>> + <type>car</type>
>>> + </dependency>
>>> + </dependencies>
>>> +</project>
>>> +
>>>
>>> Propchange: geronimo/server/trunk/plugingroups/console-jetty/pom.xml
>>>
>>> ------------------------------------------------------------------------------
>>> svn:eol-style = native
>>>
>>> Propchange: geronimo/server/trunk/plugingroups/console-jetty/pom.xml
>>>
>>> ------------------------------------------------------------------------------
>>> svn:keywords = Date Revision
>>>
>>> Propchange: geronimo/server/trunk/plugingroups/console-jetty/pom.xml
>>>
>>> ------------------------------------------------------------------------------
>>> svn:mime-type = text/xml
>>>
>>> Added:
>>> geronimo/server/trunk/plugingroups/console-jetty/src/main/history/dependencies.xml
>>> URL:
>>> http://svn.apache.org/viewvc/geronimo/server/trunk/plugingroups/console-jetty/src/main/history/dependencies.xml?rev=702586&view=auto
>>>
>>> ==============================================================================
>>> ---
>>> geronimo/server/trunk/plugingroups/console-jetty/src/main/history/dependencies.xml
>>> (added)
>>> +++
>>> geronimo/server/trunk/plugingroups/console-jetty/src/main/history/dependencies.xml
>>> Tue Oct 7 12:09:59 2008
>>> @@ -0,0 +1,49 @@
>>> +<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
>>> +<plugin-artifact
>>> xmlns:ns2="http://geronimo.apache.org/xml/ns/attributes-1.2"
>>> xmlns="http://geronimo.apache.org/xml/ns/plugins-1.3">
>>> + <module-id>
>>> + <groupId>org.apache.geronimo.plugingroups</groupId>
>>> + <artifactId>console-jetty</artifactId>
>>> + <version>2.2-SNAPSHOT</version>
>>> + <type>car</type>
>>> + </module-id>
>>> + <dependency>
>>> + <groupId>org.apache.geronimo.plugins</groupId>
>>> + <artifactId>plancreator-console-jetty</artifactId>
>>> + <type>car</type>
>>> + </dependency>
>>> + <dependency>
>>> + <groupId>org.apache.geronimo.plugins</groupId>
>>> + <artifactId>sysdb-console-jetty</artifactId>
>>> + <type>car</type>
>>> + </dependency>
>>> + <dependency>
>>> + <groupId>org.apache.geronimo.plugins</groupId>
>>> + <artifactId>activemq-console-jetty</artifactId>
>>> + <type>car</type>
>>> + </dependency>
>>> + <dependency>
>>> + <groupId>org.apache.geronimo.plugins</groupId>
>>> + <artifactId>plugin-console-jetty</artifactId>
>>> + <type>car</type>
>>> + </dependency>
>>> + <dependency>
>>> + <groupId>org.apache.geronimo.configs</groupId>
>>> + <artifactId>ca-helper-jetty</artifactId>
>>> + <type>car</type>
>>> + </dependency>
>>> + <dependency>
>>> + <groupId>org.apache.geronimo.plugins</groupId>
>>> + <artifactId>debugviews-console-jetty</artifactId>
>>> + <type>car</type>
>>> + </dependency>
>>> + <dependency>
>>> + <groupId>org.apache.geronimo.plugins</groupId>
>>> + <artifactId>mconsole-jetty</artifactId>
>>> + <type>car</type>
>>> + </dependency>
>>> + <dependency>
>>> + <groupId>org.apache.geronimo.plugins</groupId>
>>> + <artifactId>agent</artifactId>
>>> + <type>car</type>
>>> + </dependency>
>>> +</plugin-artifact>
>>>
>>> Propchange:
>>> geronimo/server/trunk/plugingroups/console-jetty/src/main/history/dependencies.xml
>>>
>>> ------------------------------------------------------------------------------
>>> svn:eol-style = native
>>>
>>> Propchange:
>>> geronimo/server/trunk/plugingroups/console-jetty/src/main/history/dependencies.xml
>>>
>>> ------------------------------------------------------------------------------
>>> svn:keywords = Date Revision
>>>
>>> Propchange:
>>> geronimo/server/trunk/plugingroups/console-jetty/src/main/history/dependencies.xml
>>>
>>> ------------------------------------------------------------------------------
>>> svn:mime-type = text/xml
>>>
>>>
>>>
>
Re: svn commit: r702586 - in /geronimo/server/trunk/plugingroups/console-jetty: ./ pom.xml src/ src/main/ src/main/history/ src/main/history/dependencies.xml src/main/plan/
Posted by Lin Sun <li...@gmail.com>.
These are the console plugin groups, basically it provides the
required console function for the javaee5 assemblies. I think the
list suggested the following profiles a while back ago:
JMS
EJB
Web Services
Admin Console
...
Also, I need the console plugin group to construct the javaee5 plugin
groups/assemblies.
Regarding activemq-console-xxx, my initial thought was to include it
in the JMS plugin group, but I realize that you are working on the
optional console and people may not want the JMS console function when
they want JMS function (for example, there is one user trying to add
JMS on top of little G). When you have your optional console stuff
in, you can remove the optional ones from the console plugin group.
Plugin groups are basically groups of plugins for users to easily
understand and consume them. They can be used in the following ways:
1. custom server assemblies
2. G server assemblies (framework, javaee5)
3. install plugin group as regular plugin. For example, a user should
be able to install the JMS plugin group in little G to get little G +
JMS environment.
Lin
On Tue, Oct 7, 2008 at 11:03 PM, Donald Woods <dw...@apache.org> wrote:
> Why are we recreating the existing console-jetty and console-tomcat as yet
> another plugin?
>
> Also, why are you including optional console plugins like
> activemq-console-xxx, which should only be included if the ActiveMQ plugins
> are installed? By including it here, you're basically pulling in the JMS
> plugins.
>
> I'm starting to reconsider why we need plugingroups, if we're going to have
> to recreate dozens of existing plugins just in a slightly different format
> just so we can include them in a special view just for custom server
> assemblies....
>
>
>
> -Donald
>
>
> linsun@apache.org wrote:
>>
>> Author: linsun
>> Date: Tue Oct 7 12:09:59 2008
>> New Revision: 702586
>>
>> URL: http://svn.apache.org/viewvc?rev=702586&view=rev
>> Log:
>> Add the console-jetty plugin group
>>
>> Added:
>> geronimo/server/trunk/plugingroups/console-jetty/
>> geronimo/server/trunk/plugingroups/console-jetty/pom.xml (with props)
>> geronimo/server/trunk/plugingroups/console-jetty/src/
>> geronimo/server/trunk/plugingroups/console-jetty/src/main/
>> geronimo/server/trunk/plugingroups/console-jetty/src/main/history/
>>
>> geronimo/server/trunk/plugingroups/console-jetty/src/main/history/dependencies.xml
>> (with props)
>> geronimo/server/trunk/plugingroups/console-jetty/src/main/plan/
>>
>> Added: geronimo/server/trunk/plugingroups/console-jetty/pom.xml
>> URL:
>> http://svn.apache.org/viewvc/geronimo/server/trunk/plugingroups/console-jetty/pom.xml?rev=702586&view=auto
>>
>> ==============================================================================
>> --- geronimo/server/trunk/plugingroups/console-jetty/pom.xml (added)
>> +++ geronimo/server/trunk/plugingroups/console-jetty/pom.xml Tue Oct 7
>> 12:09:59 2008
>> @@ -0,0 +1,98 @@
>> +<?xml version="1.0" encoding="ISO-8859-1"?>
>> +<!--
>> + Licensed to the Apache Software Foundation (ASF) under one
>> + or more contributor license agreements. See the NOTICE file
>> + distributed with this work for additional information
>> + regarding copyright ownership. The ASF licenses this file
>> + to you under the Apache License, Version 2.0 (the
>> + "License"); you may not use this file except in compliance
>> + with the License. You may obtain a copy of the License at
>> + + http://www.apache.org/licenses/LICENSE-2.0
>> + + Unless required by applicable law or agreed to in writing,
>> + software distributed under the License is distributed on an
>> + "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
>> + KIND, either express or implied. See the License for the
>> + specific language governing permissions and limitations
>> + under the License.
>> +-->
>> +<!-- @version $Rev$ $Date$ -->
>> +
>> +<project xmlns="http://maven.apache.org/POM/4.0.0"
>> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>> xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
>> http://maven.apache.org/maven-v4_0_0.xsd">
>> +
>> + <modelVersion>4.0.0</modelVersion>
>> +
>> + <parent>
>> + <groupId>org.apache.geronimo.plugingroups</groupId>
>> + <artifactId>plugingroups</artifactId>
>> + <version>2.2-SNAPSHOT</version>
>> + </parent>
>> +
>> + <artifactId>console-jetty</artifactId>
>> + <packaging>car</packaging>
>> + <name>Geronimo Plugin Group :: Admin Console Jetty</name>
>> +
>> + <description>
>> + This plugin group provides Admin Console Jetty functionality.
>> + </description>
>> +
>> + <dependencies>
>> + <dependency>
>> + <groupId>org.apache.geronimo.configs</groupId>
>> + <artifactId>ca-helper-jetty</artifactId>
>> + <version>${version}</version>
>> + <type>car</type>
>> + </dependency>
>> +
>> + <dependency>
>> + <groupId>org.apache.geronimo.plugins</groupId>
>> + <artifactId>agent</artifactId>
>> + <version>${version}</version>
>> + <type>car</type>
>> + </dependency>
>> +
>> + <dependency>
>> + <groupId>org.apache.geronimo.plugins</groupId>
>> + <artifactId>mconsole-jetty</artifactId>
>> + <version>${version}</version>
>> + <type>car</type>
>> + </dependency>
>> +
>> + <dependency>
>> + <groupId>org.apache.geronimo.plugins</groupId>
>> + <artifactId>activemq-console-jetty</artifactId>
>> + <version>${version}</version>
>> + <type>car</type>
>> + </dependency>
>> +
>> + <dependency>
>> + <groupId>org.apache.geronimo.plugins</groupId>
>> + <artifactId>debugviews-console-jetty</artifactId>
>> + <version>${version}</version>
>> + <type>car</type>
>> + </dependency>
>> +
>> + <dependency>
>> + <groupId>org.apache.geronimo.plugins</groupId>
>> + <artifactId>plancreator-console-jetty</artifactId>
>> + <version>${version}</version>
>> + <type>car</type>
>> + </dependency>
>> +
>> + <dependency>
>> + <groupId>org.apache.geronimo.plugins</groupId>
>> + <artifactId>plugin-console-jetty</artifactId>
>> + <version>${version}</version>
>> + <type>car</type>
>> + </dependency>
>> +
>> + <dependency>
>> + <groupId>org.apache.geronimo.plugins</groupId>
>> + <artifactId>sysdb-console-jetty</artifactId>
>> + <version>${version}</version>
>> + <type>car</type>
>> + </dependency>
>> + </dependencies>
>> +</project>
>> +
>>
>> Propchange: geronimo/server/trunk/plugingroups/console-jetty/pom.xml
>>
>> ------------------------------------------------------------------------------
>> svn:eol-style = native
>>
>> Propchange: geronimo/server/trunk/plugingroups/console-jetty/pom.xml
>>
>> ------------------------------------------------------------------------------
>> svn:keywords = Date Revision
>>
>> Propchange: geronimo/server/trunk/plugingroups/console-jetty/pom.xml
>>
>> ------------------------------------------------------------------------------
>> svn:mime-type = text/xml
>>
>> Added:
>> geronimo/server/trunk/plugingroups/console-jetty/src/main/history/dependencies.xml
>> URL:
>> http://svn.apache.org/viewvc/geronimo/server/trunk/plugingroups/console-jetty/src/main/history/dependencies.xml?rev=702586&view=auto
>>
>> ==============================================================================
>> ---
>> geronimo/server/trunk/plugingroups/console-jetty/src/main/history/dependencies.xml
>> (added)
>> +++
>> geronimo/server/trunk/plugingroups/console-jetty/src/main/history/dependencies.xml
>> Tue Oct 7 12:09:59 2008
>> @@ -0,0 +1,49 @@
>> +<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
>> +<plugin-artifact
>> xmlns:ns2="http://geronimo.apache.org/xml/ns/attributes-1.2"
>> xmlns="http://geronimo.apache.org/xml/ns/plugins-1.3">
>> + <module-id>
>> + <groupId>org.apache.geronimo.plugingroups</groupId>
>> + <artifactId>console-jetty</artifactId>
>> + <version>2.2-SNAPSHOT</version>
>> + <type>car</type>
>> + </module-id>
>> + <dependency>
>> + <groupId>org.apache.geronimo.plugins</groupId>
>> + <artifactId>plancreator-console-jetty</artifactId>
>> + <type>car</type>
>> + </dependency>
>> + <dependency>
>> + <groupId>org.apache.geronimo.plugins</groupId>
>> + <artifactId>sysdb-console-jetty</artifactId>
>> + <type>car</type>
>> + </dependency>
>> + <dependency>
>> + <groupId>org.apache.geronimo.plugins</groupId>
>> + <artifactId>activemq-console-jetty</artifactId>
>> + <type>car</type>
>> + </dependency>
>> + <dependency>
>> + <groupId>org.apache.geronimo.plugins</groupId>
>> + <artifactId>plugin-console-jetty</artifactId>
>> + <type>car</type>
>> + </dependency>
>> + <dependency>
>> + <groupId>org.apache.geronimo.configs</groupId>
>> + <artifactId>ca-helper-jetty</artifactId>
>> + <type>car</type>
>> + </dependency>
>> + <dependency>
>> + <groupId>org.apache.geronimo.plugins</groupId>
>> + <artifactId>debugviews-console-jetty</artifactId>
>> + <type>car</type>
>> + </dependency>
>> + <dependency>
>> + <groupId>org.apache.geronimo.plugins</groupId>
>> + <artifactId>mconsole-jetty</artifactId>
>> + <type>car</type>
>> + </dependency>
>> + <dependency>
>> + <groupId>org.apache.geronimo.plugins</groupId>
>> + <artifactId>agent</artifactId>
>> + <type>car</type>
>> + </dependency>
>> +</plugin-artifact>
>>
>> Propchange:
>> geronimo/server/trunk/plugingroups/console-jetty/src/main/history/dependencies.xml
>>
>> ------------------------------------------------------------------------------
>> svn:eol-style = native
>>
>> Propchange:
>> geronimo/server/trunk/plugingroups/console-jetty/src/main/history/dependencies.xml
>>
>> ------------------------------------------------------------------------------
>> svn:keywords = Date Revision
>>
>> Propchange:
>> geronimo/server/trunk/plugingroups/console-jetty/src/main/history/dependencies.xml
>>
>> ------------------------------------------------------------------------------
>> svn:mime-type = text/xml
>>
>>
>>
>