You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by Jason Dillon <ja...@planet57.com> on 2007/03/03 07:52:29 UTC
Upgrade Pluto to 1.1? (was Re: What are we using Castor for?)
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
Re: Upgrade Pluto to 1.1? (was Re: What are we using Castor for?)
Posted by Jason Dillon <ja...@planet57.com>.
Actually, what I'd really like to see is our console allow app
developers to plugin their own portlets for custom administration of
their applications which are running in Geronimo...
--jason
On Mar 2, 2007, at 11:27 PM, Jason Dillon wrote:
> Or... what about Jetspeed 2? Again I know jack about all things
> portal so I have no idea... but I would like to have the console
> get to be more pluggable and dynamic to install plugin bits at
> runtime.
>
> --jason
>
>
> On Mar 2, 2007, at 10:52 PM, Jason Dillon 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
>>
>>
>>
>
Re: Upgrade Pluto to 1.1? (was Re: What are we using Castor for?)
Posted by Jason Dillon <ja...@planet57.com>.
Or... what about Jetspeed 2? Again I know jack about all things
portal so I have no idea... but I would like to have the console get
to be more pluggable and dynamic to install plugin bits at runtime.
--jason
On Mar 2, 2007, at 10:52 PM, Jason Dillon 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
>
>
>
Re: Upgrade Pluto to 1.1? (was Re: What are we using Castor for?)
Posted by Jason Dillon <ja...@planet57.com>.
On Mar 3, 2007, at 4:41 PM, Joe Bohn wrote:
> 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.
Wouldn't using a more a more full-featured portal framework, like
Jetspeed2 solve this... or really move the problem from us having to
invent a solution to us being able to implement a solution based on
another's framework?
>> 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.
Sure... but how much _heavier_ is Jetspeed2 vs. Pluto? If its not
that much bigger, and provides things like the modularity/deploy
functionality already... then it might end up being less overall code
for us to maintain, and would move the impl of the modularity to
being specific to that vendors portal framework and not specific to
Geronimo.
> 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.
Right. There is Geronimo admin, and then there is app-admin, and
then there is the app itself it is portal-based. My main focus would
be on G admin and app-admin, but if the same portal could be used to
handle everything (and isn't a massive dog) then... well... why not?
> 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.
Again... how much _heavier_ is Jetspeed2 vs. Pluto? I'd imagine J2
is bigger... but does anyone know how much bigger? And how much more
overhead is our custom framework for modularity (and admin/
customization of those modules) going to add... in terms of resident
footprint, lines of code and complexity?
IMO... if using a more full-featured portal that fits our licensing
needs... that does not add a huge bloat to the assembly/footprint,
and provides some solutions to the framework needs we have (and/or
adding more useful features)... then seems like that makes more sense.
I'm not pushing for one or the other... just trying to gather some
real details from folks who know about this better than I do. But so
far, I've only heard that one is more lightweight... nothing specific
at all :-(
So, does anyone know? Does using J2 bloat the distro by like 10mb or
something? Or eat up 25m in heap when running, etc...
I'm all for light... but if a bit of extra fat adds support OOTB for
modularity features, reduces G-specific portal infrastructure, and
provides folks with a usable portal system for their own custom
administration or simple application, then I'd be happy with a little
extra grease on my bacon with my morning eggs. But if its more like
adding a tub of butter on my toast... I might not like that so much
(as good as it might taste) ;-)
--jason
Re: Upgrade Pluto to 1.1? (was Re: What are we using Castor for?)
Posted by Joe Bohn <jo...@earthlink.net>.
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 <am...@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 <ja...@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
>>> >
>>> >
>>> >
>>> >
>>> >
>>>
>
>
Re: Upgrade Pluto to 1.1? (was Re: What are we using Castor for?)
Posted by David Jencks <da...@yahoo.com>.
On Mar 3, 2007, at 6:39 PM, 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).
modular == good
>
> How much _heavier_ is Jetspeed2 vs. Pluto?
A really lot heavier. A reasonable j2 integration will also be a
significant effort since its going to involve a big security
integration, probably a new jacc provider (or using triplesec), and a
lot of other stuff. An unreasonably incomplete integration wouldn't
need all of this.... but j2 has a lot of stuff for laying out apps,
administering everything, etc etc etc.
> I know that J2 now uses Pluto (though not sure what version,
> hopefully its 1.1).
I think they're still on 1.0.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'm not sure that j2 would really make it a lot easier to add in
admin plugins. I think its definitely worth investigating how far
pluto 1.1 will get us.
thanks
david jencks
>
> --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 <am...@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 <ja...@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
>>> >
>>> >
>>> >
>>> >
>>> >
>>>
>
Re: Upgrade Pluto to 1.1? (was Re: What are we using Castor for?)
Posted by Jason Dillon <ja...@planet57.com>.
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).
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.
--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 <am...@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 <ja...@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
>> >
>> >
>> >
>> >
>> >
>>
Re: Upgrade Pluto to 1.1? (was Re: What are we using Castor for?)
Posted by Jason Dillon <ja...@planet57.com>.
I actually pinged the pluto dev list yesterday:
http://www.nabble.com/Pluto-1.0.x-to-1.1-upgrade-guide-%28Apache-
Geronimo-Console%29-tf3337657.html
If someone who knows more about the details could chime in (Paul?
Aaron?) it might help.
--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 <am...@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 <ja...@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
>> >
>> >
>> >
>> >
>> >
>>
Re: Upgrade Pluto to 1.1? (was Re: What are we using Castor for?)
Posted by Paul McMahan <pa...@gmail.com>.
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 <am...@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 <ja...@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
> >
> >
> >
> >
> >
>
Re: Upgrade Pluto to 1.1? (was Re: What are we using Castor for?)
Posted by Aaron Mulder <am...@alumni.princeton.edu>.
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 <ja...@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
>
>
>
>
>