De : Weaver, Scott [mailto:[EMAIL PROTECTED]]
>
>
> I'm not on general, but I did read the archived stuff on the
> recent Pluto discussion. I have to admit I am somewhat confused.
>
OK, I'll try to explain what I understood of the situation (however
I'm not on the JSR so I may be wrong on some specifics).
> I had a strong feeling that the RI for JSR 168 was going to
> be Apaches's baby. However, I would like a clearer view on
> how Jetspeed fit's into this. I have spent a lot of time
> building our company's portal offering around Jetspeed and
> would hate to see it become the red headed step child, as I
> think all of us would, that gets a thorough beating from
> "standards" based portals. I am also starting to get
> questions from management about using Websphere portlets in
> our offering (Jetpeed), I keep saying "wait until JSR-168."
>
The idea of Pluto is to be the RI of the Portlet API defined
in JSR 168. However, if you look at the current proposed IBM
portlet API sitting in Jetspeed CVS, this API does not specify
many required aspects of a fully functional portal, most critical
missing parts are:
- how aggregation is performed and/or customized
- how security is implemented
- how portlets are added to a page (esp. do you use a taxonomony,
search, etc...)
- i10n, multi mime-type support, type transcoding, etc...
- back-end tools available (CMS, DB, etc...)
That leaves ampls rooms for several portal implementations to
build on top of the RI (or to reimplement a different container
to achieve specific goals).
The main advantage of such a container is that it clearly
separates the portlet writer concerns (coding against the standard)
from the portal integrator (customizing the portal features).
Current, Jetspeed mixes these two constraints and forces everybody
to tie into Turbine if they want to write portlets. IMO, this is a
*bad* thing, people should be free to use Struts to write complex
portlets if that is what they want...
So the way I see the whole projects come together is something
like this:
+---------------+ +----------------+
| Pluto |<-- Pluto---+--| Jetspeed |
| | API | | |
+---------------+ +--|--+----------------+
^ | |
| | |
Portlet API | +--+----------------+
| | | | Struts/Tiles |
+---------------+ +--|--| Portal |
| Compliant | | | +----------------+
| Portlet |<-Portlet+ |
+---------------+ API | +--+----------------+
| | Cocoon |
+-----| Portal |
+----------------+
With the different portals differentiated by their
aggregation model, URL space model, back-end and extensibility
features, but still able to share common portlets functional
blocks.
(Of course, speaking of blocks... for me Pluto is a project
that screams to be Avalonized as soon as possible with special
care going to carefully define and abstract the exposed Puto
service API. I strongly doubt that the donated code from
IBM will be that well abstracted ;) )
Additionnally, such an organization, can start bridging the
different existing "portals" within ASF (Jetspeed, Tiles and
Cocoon Portal components) to maybe steal some ideas from
each other or cross-implement features across different
frameworks.
"Competitive collaboration" is a good thing. :)
Concerning migration paths for current Jetspeed users, I would
see the following happening, depending on the technical limitations
imposed by the Portlet API and Pluto API:
- as soon as the API and the Pluto code is available, develop a
JSRPortlet in Jetspeed (somewhat similar to the VelocityPortlet)
that would act as a proxy to a pluto-hosted portlet.
That way current Jetspeed users, can start developping and using
JSR-compliant portlets ASAP but still keep their current
Jetspeed config (PSML, registry, templates, custom actions, etc...)
- around the same time, review the global Jetspeed architecture to finally
start that much-delayed Jetspeed 2. This project would not have
the requirement to be completely backward compatible and would be
designed from sratch to work around the new API.
As such it can probably integrate much more closely with Pluto.
Depending on the design choices, made at this stage Jetspeed 2 may
or may not support the current Jetspeed portal-related config
(PSML, templates, etc...) but will probably try to support the
current Jetspeed portlet through a JSR compliant proxy.
That way we can have in mid-term 2 main branches of Jetspeed, both
supporting the new JSR and maintain the 2 branches concurrently for
some time. New functional components can be developped for both
through the use of JSR compliant portlets, so it should not fork
the community but give more options and possibly bring more people
in the community.
However, I fully anticipate that over time there'll be a gradual
migration of users from JS 1 to JS 2, given that we'll address in
JS 2 the structural issues of JS 1 and that JS 1 will be slowly
put in maintenance mode (like Cocoon 1 vs Cocoon 2)
Another option might be that some developers definitely want to
stick with JS 1 and that the 2 would grow in parallel (a la
Tomcat 3 vs Tomcat 4).
> As for Jetspeed becoming the RI, I can already see issues
> with struts/tiles users not wanting to play with the
> turbine-driven MVC model that is the current basis for
> Jetspeed. I don't blame them. Struts is a powerful MVC
> framework and there should be no need to learn another one
> just to use the portal RI. I have already seen this issue pop
> up in jetspeed-user. This leads to the usage of jsp's within
> turbine, which never was a real priority in the past.
> However, I do have to admit that Mark Orciuch has really done
> an excellent job of making Jetspeed play nicely with jsp's
> which I think has helped retain/gain additional Jetspeed
> users as it appears more and more of the questions on
> jetspeed-user have a JSP focus.
>
+1 to that
> Finally, what is Charon, besides Pluto's solitary moon ;).
> Is it a project? Is there an existing code-base?
>
Don't know.
--
Rapha�l Luta - [EMAIL PROTECTED]
Jakarta Jetspeed - Enterprise Portal in Java
http://jakarta.apache.org/jetspeed/
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
