Mailing-List: contact dev-help@geronimo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@geronimo.apache.org
Received-SPF: pass (herse.apache.org: local policy)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
  s=dk20050327; d=earthlink.net;
  b=QsXKa8zTy918CIa4zvf0T0l/6UtZZDWcFOssujN/Zh2J/xHNSkKxM4L1Sa0itPfg;
  h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP;
Message-ID: <45EA15B3.8030509@earthlink.net>
Date: Sat, 03 Mar 2007 19:41:23 -0500
From: Joe Bohn <joe.bohn@earthlink.net>
User-Agent: Thunderbird 1.5.0.10 (Macintosh/20070221)
MIME-Version: 1.0
To: dev@geronimo.apache.org
Subject: Re: Upgrade Pluto to 1.1? (was Re: What are we using Castor for?)
References: <55C60C42-1F22-43EF-8FD6-681E68F3FC02@planet57.com>
 <9EF83EC8-DA0C-430C-9729-F1F8C1F39EFB@yahoo.com>
 <BF9A0C01-5985-4737-9CA0-A66AA5AAA0B8@planet57.com>
 <74e15baa0703030810m51c4370ev483a0a7154f41d63@mail.gmail.com>
 <21df75940703030904k51be597ct67c50dd429bfee36@mail.gmail.com>
 <AC3C0D3E-703A-4261-929A-92EF1A60699B@planet57.com>
In-Reply-To: <AC3C0D3E-703A-4261-929A-92EF1A60699B@planet57.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit


Jason Dillon wrote:
> How modular is the existing console code?  I'm thinking that some work 
> is probably needed to make it more modular, so that the existing 
> functionality could be split up into smaller domain-specific modules and 
> then deployed into the console app.  Right now it looks like a big app, 
> would like to see each of the major bits as a separate module... to help 
> keep things orderly and prevent spaghetti code (which I've already 
> started to notice when I looked at some Derby and AMQ-related console 
> bits last).

What is there isn't very modular.  We've discussed this before.  We need 
to make the console architecture a bit more modular so that the console 
management components could added as functions that they manage are 
added.  For example, adding an EJB management portlet with EJB functions 
to a minimal Geronimo assembly.  The down-side is that there are no 
standards here, so it would be Geronimo specific.

> 
> How much _heavier_ is Jetspeed2 vs. Pluto?  I know that J2 now uses 
> Pluto (though not sure what version, hopefully its 1.1).  I'm all for 
> lightweight... but I'm also okay with a little bit of extra pounds if it 
> makes the console application easier for app developers/sysadmins to 
> plugin/customize their own administration bits.

I think that we need to keep things light-weight for the web console. 
We're already catching grief for the footprint.

The other aspect here is that users would like portal capability to 
exploit for their purposes and not just for Geronimo administration. 
There was some discussion on this in the past too.

For customer use something like Jetspeed2 or Liferay may make more 
sense.  For an embedded administration console for Geronimo use Pluto 
provides the necessary functions with a smaller footprint.

IMO the ideal solution would be:
- Improve the modularity of the console components such that management 
could be installed with a function.  This is really an orthogonal 
discussion but was raised here because Pluto 1.1 provides some necessary 
features to make this a reality.
- Continue to ship Geronimo using Pluto (1.1) as the default portal for 
our administration console.
- Provide the capability to install/run the console on other Portal 
solutions such as JetSpeed2 or Liferay if deployed on Geronimo.  I guess 
in these situations we could support running two portals (one for 
Geronimo and a user Portal) but that eliminates any possible integration 
between user portlets and Geronimo admin portlets.

Joe


> 
> --jason
> 
> 
> On Mar 3, 2007, at 9:04 AM, Paul McMahan wrote:
> 
>> I agree with Aaron that Pluto 1.1 would provide a much better baseline
>> for making the admin console more pluggable.  Jetspeed and Liferay are
>> excellent portals as well but since they are application frameworks in
>> their own right I think they provide a lot of functionality beyond
>> what is needed for the admin console.
>>
>> David DeWolf from the Pluto team contacted us offering his assistance
>> in upgrading the admin console to pluto 1.1, and that sparked a very
>> interesting conversation.  He specifically said that pluto 1.1
>> supports dynamic addition of portlets, which is key for making the
>> admin console pluggable.  See:
>>   http://tinyurl.com/3cdmj3
>> That was in 12/2005 (!) but maybe we can rekindle that conversation
>> while we put the finishing touches on G 2.0.
>>
>> Best wishes,
>> Paul
>>
>>
>> On 3/3/07, Aaron Mulder <ammulder@alumni.princeton.edu> wrote:
>>> Pluto 1.1 integration would be great, and would allow much more
>>> reasonable dynamic additions of screens to the console.  Someone just
>>> needs to do the work.  :)
>>>
>>> I expect Jetspeed 2 would do the same, but I think Pluto would be much
>>> more lightweight, so I would think it would be preferable for the
>>> console, whereas Jetspeed and Liferay would be preferable for people
>>> developing portal applications.
>>>
>>> I believe David J did some initial work along these lines a while back.
>>>
>>> Thanks,
>>>       Aaron
>>>
>>> On 3/3/07, Jason Dillon <jason@planet57.com> wrote:
>>> > On Feb 13, 2007, at 5:49 PM, David Jencks wrote:
>>> > > It's used by pluto for the admin console.  No idea if more recent
>>> > > would work.
>>> > >
>>> > > We could upgrade pluto too if anyone has some time to investigate
>>> >
>>> > I wonder if anyone from the Pluto team would want to help with
>>> > that... looks like 1.1 is not compatible with 1.0.1... but also looks
>>> > like that might not be a bad thing:
>>> >
>>> > <snip>
>>> > Pluto 1.1 introduces a new container architecture. If you are
>>> > embedding Pluto in your portal, realize that 1.1 is not binarily
>>> > compatible with Pluto 1.0.x.
>>> >
>>> > Pluto 1.1 aims to simplify the architecture in order to make it more
>>> > user and developer friendly. You should find Pluto 1.1 easier to get
>>> > started with, easier to understand, and easier to embed with your
>>> > portal. Your feedback regarding how far we've come is always welcome
>>> > on the user and developer mailing lists!
>>> >
>>> > </snip>
>>> >
>>> > I don't know much abort portal muck, so I can't really show how much
>>> > better 1.1 might be... but I know that there have been some issues
>>> > with the console asis now to get stuff like plugin porlets installed
>>> > dynamically... perhaps 1.1 can help solve some of these issues?
>>> >
>>> > Anyone know?
>>> >
>>> > --jason
>>> >
>>> >
>>> >
>>> >
>>> >
>>>
> 
>