incubator-graffito-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christophe Lombart <christophe.lomb...@gmail.com>
Subject Re: Graffito & Jetspeed 2 dev
Date Thu, 24 Nov 2005 10:25:05 GMT
On 11/23/05, Jason Novotny <novotny@aei.mpg.de> wrote:
>
> Thanks Cristophe,
>
>     I'm having trouble building it-- I don't see any sort of readme or
> install guide yet.

Let me know if something is missing in the following doc :

http://incubator.apache.org/graffito/build.html
http://incubator.apache.org/graffito/deploy.html

We can modify them and add more details.

>How much of the jetspeed stuff will I actually need?

All j2 dependencies  are in the different maven project.xml files. We
should review all subprojects and analyse each dependency.

> Does it makes sense to also add gridsphere=true sort of properties in
> the build.properties and gridsphere deployment targets to the project.xml?
>     The easiest for me would be if you mailed me a portlet WAR possibly
> and I could hand you back the changes I made to get it working in our
> portal.
>
Supporting different portal servers  requires more complexity and abstraction.
Let me resume how Graffito is designed. Than, we can see if it fits to
Gridsphere and see together how we can change the Graffito project
structure, deployment scripts, ... .
If there are too many J2 dependencies,  I'm agree to review them.

1. Grafftito contains some demo portlets but also some components.
Thoses components can be executed in any IOC container (in  theory :-)
). We are currently supporting Spring. If you need another IOC
container, you have to check the differencies in term of component
lifecycle, tx management, ... In the case of J2 integration, the
Graffito components are running inside the portal container and can be
used by other portal services (eg. the portal page manager).
Futhermore, the Graffito scope is not limited to build portlets. It
should be possible to run Graffito components in other kind of
applications. That's why those components are important.

2. The security depends on  the J2 security components which are very
good. Maybe more abstraction is required here. We are using JAAS. Are
you supporting JAAS in Gridsphere ?

3. The demo portlet (browser) depends also on the j2 API and some J2 services.

In my opinion, supporting different portal container is possible but
it will take times.
Personnally, I have no time to do it now but of course I can help you
to modify all subprojects. Let me know if you are interesting to do
it. We can make the following plan :
1. Review the API and commons subproject : see how to drop the J2 dependencies.
2. Review the components subproject wich will be the big job.
3. See if the engine is needed.
3. Review the portlets.


Kind regards,
Christophe

Mime
View raw message