Re: Further Jetspeed-2 development plans - jetspeed light

[Elliot Metsger <em...@jhu.edu>]

 

Ate Douma wrote:
> 
> - Jetspeed "light" (no need for database persistence and much simplified
> page/site management)
> 

I think jetspeed (of) light is a good idea.  I don't have many thoughts but
I would like to offer some datapoints.

1. The 1.1.4 (release candidate, please vote) with a bundled Tomcat starts
in 3.9 ms on my laptop (Macbook Pro 2.33 MHz Intel Core 2 Duo).

2.  The following statement (obviously) is anecdotal: Everyone I know uses
Pluto Portal to develop portlets.  There is certainly some non-zero usage of
Pluto Portal as a "real" portal (based on pluto list traffic), but
absolutely every person that I know who develops JSR 168 portlets is using
the Pluto Portal as their development environment.  After they have
developed their portlet, they drop it into whatever their enterprise portal
is.

So if Pluto Portal becomes Jetspeed Light (however that happens) my concern
is that it remains as easy to use (this area can definitely use some
improvment), fast, and lightweight as possible for portlet developers.

3.  Organizationally for Apache Portals I think this is a good thing.  Pluto
Portal is used because it fills a real need (#2), and I believe that it
deserves to be given cycles by Pluto developers (as their "itch" directs
them).  If Pluto Portal goes away in favor of Jetspeed Light, then the
internal conflict/tension/duality of the Pluto Container and Pluto Portal is
resolved, and hopefully any external tension between Pluto and the Jetspeed
projects is dissolved.

I'm not at all familiar with Jetspeed's internals.  But perhaps one idea for
pursing the refactoring Ate has proposed is to actually build a Jetspeed
Light, an exercise which would identify and result in loosely coupled
components.  JS Light becomes "enterprise" by plugging in additional
components.  Reading that sentence back I think I repeated what Ate has
already said :).

My .02,
Elliot


-- 
View this message in context: http://www.nabble.com/Further-Jetspeed-2-development-plans-tf4087420.html#a11723756
Sent from the Jetspeed - Dev mailing list archive at Nabble.com.


---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-dev-help@portals.apache.org

Re: Further Jetspeed-2 development plans - jetspeed light

[Ate Douma <at...@douma.nu>]

Elliot Metsger wrote:
>  
> 
> Ate Douma wrote:
>> - Jetspeed "light" (no need for database persistence and much simplified
>> page/site management)
>>
> 
> I think jetspeed (of) light is a good idea.  I don't have many thoughts but
> I would like to offer some datapoints.
> 
> 1. The 1.1.4 (release candidate, please vote) with a bundled Tomcat starts
> in 3.9 ms on my laptop (Macbook Pro 2.33 MHz Intel Core 2 Duo).
> 
> 2.  The following statement (obviously) is anecdotal: Everyone I know uses
> Pluto Portal to develop portlets.  There is certainly some non-zero usage of
> Pluto Portal as a "real" portal (based on pluto list traffic), but
> absolutely every person that I know who develops JSR 168 portlets is using
> the Pluto Portal as their development environment.  After they have
> developed their portlet, they drop it into whatever their enterprise portal
> is.
Cool, I can (mostly) say the same using Jetspeed-2 here (which of course is pluto based).

> 
> So if Pluto Portal becomes Jetspeed Light (however that happens) my concern
> is that it remains as easy to use (this area can definitely use some
> improvment), fast, and lightweight as possible for portlet developers.
Definitely, +1

> 
> 3.  Organizationally for Apache Portals I think this is a good thing.  Pluto
> Portal is used because it fills a real need (#2), and I believe that it
> deserves to be given cycles by Pluto developers (as their "itch" directs
> them).  If Pluto Portal goes away in favor of Jetspeed Light, then the
> internal conflict/tension/duality of the Pluto Container and Pluto Portal is
> resolved, and hopefully any external tension between Pluto and the Jetspeed
> projects is dissolved.
That would be one of my goals yes.
But not just that: I really would like to see us join forces to work on one main Apache Portal code base.
The Pluto and Jetspeed development teams are both rather small, and I think we will gain a lot of synergy and boost of productivity when we can discuss and work 
together as one team. I'd love to see that happen.

> 
> I'm not at all familiar with Jetspeed's internals.  But perhaps one idea for
> pursing the refactoring Ate has proposed is to actually build a Jetspeed
> Light, an exercise which would identify and result in loosely coupled
> components.  JS Light becomes "enterprise" by plugging in additional
> components.  Reading that sentence back I think I repeated what Ate has
> already said :).
Yeah, thanks for repeating though :)

Ate
> 
> My .02,
> Elliot
> 
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-dev-help@portals.apache.org

Re: Further Jetspeed-2 development plans - jetspeed light

[David Sean Taylor <da...@bluesunrise.com>]

On Jul 21, 2007, at 9:45 AM, Elliot Metsger wrote:

>
>
>
> Ate Douma wrote:
>>
>> - Jetspeed "light" (no need for database persistence and much  
>> simplified
>> page/site management)
>>
>
> I think jetspeed (of) light is a good idea.  I don't have many  
> thoughts but
> I would like to offer some datapoints.
>
> 1. The 1.1.4 (release candidate, please vote) with a bundled Tomcat  
> starts
> in 3.9 ms on my laptop (Macbook Pro 2.33 MHz Intel Core 2 Duo).

3.9 ms, awesome dude!!! You guys rock!!!

I just tested Pluto 1.1.3 on my Macbook Pro 2.33 Mhz Intel Core 2  
Duo, and it started up in about 3 or 4 seconds
Some serious improvements in 1.1.4, you shaved Tomcat startup down to  
almost nothing!

With Jetspeed basic build (only j2-admin webapp) it starts in about 8  
seconds on the same machine
I guess adding webapps, depending on the size and number of classes,  
will be a constant for all portals as they
still all need to go through the Java class loader and pay the same  
price

>
> 2.  The following statement (obviously) is anecdotal: Everyone I  
> know uses
> Pluto Portal to develop portlets.  There is certainly some non-zero  
> usage of
> Pluto Portal as a "real" portal (based on pluto list traffic), but
> absolutely every person that I know who develops JSR 168 portlets  
> is using
> the Pluto Portal as their development environment.  After they have
> developed their portlet, they drop it into whatever their  
> enterprise portal
> is.
>
Cool, nice of you to say that.
We use the Pluto container for portal development as well, embedded  
in Jetspeed.

> So if Pluto Portal becomes Jetspeed Light (however that happens) my  
> concern
> is that it remains as easy to use (this area can definitely use some
> improvment), fast, and lightweight as possible for portlet developers.
>

Yes, that is my goal as well. Look forward to working with you




---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-dev-help@portals.apache.org