Luta, Raphael (VUN) wrote:
If I understand correctly your concerns, the point is that the "Jetspeed" brand should not get lost in the process. This is good, because, even with its limitations, Jetspeed is getting a brand, and we should not spoil it in the name of something of which we haven't seen anything yet (private SPEC, no code shown in advance, etc.)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."
I have read about having a project called portlet.apache.org, which could have Pluto, Charon, Jetspeed and other initiatives (Cocoon-based, Struts-based, etc.) hanging below it. It looks like this could be a good solution from the political POV, while allowing the obvious technical advantages of having a standard API.
It would also allow that several communities (Cocoon, Struts, Turbine at the very least) to communicate closely around the portal issues each one of them is facing separately now.
+1
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...
Or to have the standard covering XMLized portals, where every portlet is guaranteed to produce valid XML, as cocoon people will need ;-)
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 andI like PSML and templates, although possibly the interface for templating engines and some aspects of the PSML syntax could be revised.
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, bothChoice is always good ;-)
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).
I have customers that still are using products based in Jetspeed 1.3b2+ (some patches). Others are around 1.3b3+ I had to stop tracking changes there because of overload.
One thing that I desperately need is to have a stable branch (even with limited functionality) where we can limit changes to those needed por production bug fixing, etc.
I stopped tracking CVS head because I was under heavy pressure to go into production (this has happened yesterday) for a project, and changes in other modules were driving me crazy.
I have sitting in my local repository a lot of "facade based" security changes. I thought that security in Jetspeed 1.4bX had moved to use the Proxy API in JDK1.4, but I'm not sure. I disagreed with this decision because of security concerns. I still disagree. Do you think these changes are worth committing still?
Jetspeed should be agnostic WRT those issues. Here we have a SAXTemplatingService which handles the whole portal as a SAX event pipeline, being able to pass stream based portlets as CDATA (a hack, i know) or to XMLize them if you have reasonable warranty that they produce XML. We are using Velocity, in fact, for parts of our applications.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]>
-- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
