Graffito status followup

[Jukka Zitting]

Hi,

The ASF board asked us to report again this month on the outcome of
the project status discussion we had recently. It seems that there's
marked interest in the project, but as of now not much is happening.
I'd like to resume the discussion and hopefully arrive in a conclusion
that we could include in the next Incubator report.

There was talk about better componentization of the project. What
could this mean in practice? My view is that currently Graffito is
more designed as a full framework rather than a set of independent
components. Would it make sense to revisit this design decision, and
what would be the amount of required vs. available effort for doing
something like that? And more fundamentally, what would be the
requirements and use cases for more independent components?

Alternatively, assuming we keep the current architecture, what could
be done to encourage and enable a more active community? Are there
technical obstacles for trying out and adopting Graffito, do we need
more documentation, or would some other measures help?

I personally have some issues (discussed last autumn) with the current
design which makes Graffito less appealing for some webapp projects
I've been thinking of. I also found it a bit hard to grasp the
underlying idea of Graffito, there is no clear metafor or a similar
explanation of what Graffito is really about. It might be just me, but
if similar views are more common, that might explain the low level of
adoption we are still seeing.

BR,

Jukka Zitting

[Christophe Lombart]

Hi Jukka,

Let's start to grasp the underlying idea of Graffito. I agree with you to
clarify this point. Maybe this is not yet defined.
When we will be agree on the Graffito goals, we can try to review together
the architecture and see later if we have to split the project or review
some parts to be more attractive.

I would like to see Graffito as a series of components/services to build ECM
applications. that's all :-)
In my point of view, we need the following layers :

a. "Graffito Core" : all necessary low-level services to define, store,
manage, audit, request and search content. If needed, it can give an access
to different heterogenous content servers (JCR and propriatary servers).
Graffito core have to be extensible. For example, a workflow service could
be added into "Graffito Core".

b. "Graffito Runtime" : it should be possible to deploy the "Graffito Core"
anywhere and customize the components to use. Generally, the "Graffito core"
is matching to a content server or a cluster of content server.

c. "Graffito Applications" : a series of applications which access to
"Graffito Core"  to manage a specific kind of content application. Some
basic applications can be a simple document management, a forum or a wiki
application. Advanced web content management can be also a good example. I
think Graffito applications are also components/service based.

d. "Graffito portlets"  : a series of portlets used to integrate "Graffito
applications" into portal like Jetspeed.


Is it make sense ? Do you see some point to improve ?

If we are agree on the underlying ideas, let's start the technical details.
Just one word in point of view of architecture, I'm not the SOA expert but
I'm wondering if we can go into this direction.


br,
Christophe

[stibrian]

-----Original Message-----
From: Christophe Lombart [mailto:christophe.lombart@...]
Sent: Monday, February 05, 2007 6:06 AM
To: graffito-dev@...
Subject: Re: Graffito status followup

Hi Jukka,

Let's start to grasp the underlying idea of Graffito. I agree with you to
clarify this point. Maybe this is not yet defined.
When we will be agree on the Graffito goals, we can try to review together
the architecture and see later if we have to split the project or review
some parts to be more attractive.

I would like to see Graffito as a series of components/services to build ECM
applications. that's all :-)
In my point of view, we need the following layers :

a. "Graffito Core" : all necessary low-level services to define, store,
manage, audit, request and search content. If needed, it can give an access
to different heterogenous content servers (JCR and propriatary servers).
Graffito core have to be extensible. For example, a workflow service could
be added into "Graffito Core".

b. "Graffito Runtime" : it should be possible to deploy the "Graffito Core"
anywhere and customize the components to use. Generally, the "Graffito core"
is matching to a content server or a cluster of content server.

c. "Graffito Applications" : a series of applications which access to
"Graffito Core"  to manage a specific kind of content application. Some
basic applications can be a simple document management, a forum or a wiki
application. Advanced web content management can be also a good example. I
think Graffito applications are also components/service based.

d. "Graffito portlets"  : a series of portlets used to integrate "Graffito
applications" into portal like Jetspeed.


Is it make sense ? Do you see some point to improve ?

If we are agree on the underlying ideas, let's start the technical details.
Just one word in point of view of architecture, I'm not the SOA expert but
I'm wondering if we can go into this direction.


br,
Christophe

Good morning,

I've been lurking on this list for a while, trying to better grok where the
Graffito project is and where it's going.  I was working on my own Object<->
JCR mapping project, so Graffito is of great interest to me.  So here's my
$.02.

I agree that the underlying idea of Graffito and consensus on this is
essential.

On point a I mostly agree - with the exception of the workflow comment.  Via
listeners etc I think there are ample places to hook workflow into JCR in
general, and there are a number of workflow engines out there.  As such,
tying anything other than the most bare workflow notions into Graffito
limits its use, or at least has users ignoring a bunch of the work in the
core.  Yes, the core has to be extensible, but spending too much time on
extensibility prior to an actual release just pushes the release farther and
farther out.

On point c - couldn't agree more.  This gets you to, essentially, a series
of clients that each manages a particular domain model and a series of use
cases.  This is where extensibility is key, as folks will always want "one
more property" that you haven't thought of.  In this arena there is
something of an interesting need too related to extensibility, and that is a
common node definition lang.  Several other jcr backed applications have a
node def lang (ie: CND for Jackrabbit, whatever-it-is for alfresco, etc),
and a wonderful extension point for Graffito to allow and promote domain
specific node defs etc would be a more common way to express the
node/property structure.  This could be similar to how Hibernate uses the
notion of dialects to generate RDMS specific DDL for db creation from its
standard mappings.

On point d - I've liked the notion of portlets for a long time, but I think
the too tightly coupling the notion/power of Graffito (general Object<->JCR
mapping tool) to portals has stalled its appeal to a larger audience of
developers.  This goes along with the sentiment that Graffito could/should
be more properly aligned beneath Jackrabbit than the portals project.
Portals and portal content are a specific domain that JCR is good at
managing, but not the core reason the spec was defined.  If the focus is
narrow - Object<->JCR, then building applications on top of that to address
specific domains should be much easier.

So, I've certainly dumped my opinions - I apologize if I've offended or
stepped out of bounds.

Thanks,
Brian  

--
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.5.432 / Virus Database: 268.17.25/669 - Release Date: 2/4/2007
9:58 PM
 

[Christophe Lombart]

Hi all,

Is it possible to continue this discussion ?

Following my previous mail, I would like to know if it is ok for
everybody. As you can see, the scope is very high and I would like to
start more details on the first point : "Graffito Core". Specially, I
would like to review together our component-oriented architecture
(goals, use cases, list of components, API, ....). In my opinion, we
can review later the point b, c, d

Let me know if it makes sense for you !

br,
Christophe

On 2/5/07, Christophe Lombart <christophe.lombart@...> wrote:

> Hi Jukka,
>
> Let's start to grasp the underlying idea of Graffito. I agree with you to
> clarify this point. Maybe this is not yet defined.
> When we will be agree on the Graffito goals, we can try to review together
> the architecture and see later if we have to split the project or review
> some parts to be more attractive.
>
> I would like to see Graffito as a series of components/services to build ECM
> applications. that's all :-)
> In my point of view, we need the following layers :
>
> a. "Graffito Core" : all necessary low-level services to define, store,
> manage, audit, request and search content. If needed, it can give an access
> to different heterogenous content servers (JCR and propriatary servers).
> Graffito core have to be extensible. For example, a workflow service could
> be added into "Graffito Core".
>
> b. "Graffito Runtime" : it should be possible to deploy the "Graffito Core"
> anywhere and customize the components to use. Generally, the "Graffito core"
> is matching to a content server or a cluster of content server.
>
> c. "Graffito Applications" : a series of applications which access to
> "Graffito Core"  to manage a specific kind of content application. Some
> basic applications can be a simple document management, a forum or a wiki
> application. Advanced web content management can be also a good example. I
> think Graffito applications are also components/service based.
>
> d. "Graffito portlets"  : a series of portlets used to integrate "Graffito
> applications" into portal like Jetspeed.
>
>
> Is it make sense ? Do you see some point to improve ?
>
> If we are agree on the underlying ideas, let's start the technical details.
> Just one word in point of view of architecture, I'm not the SOA expert but
> I'm wondering if we can go into this direction.
>
>
> br,
> Christophe
>
>
>
>
>

[Jukka Zitting]

Hi,

On 2/13/07, Christophe Lombart <christophe.lombart@...> wrote:
> Following my previous mail, I would like to know if it is ok for
> everybody. As you can see, the scope is very high and I would like to
> start more details on the first point : "Graffito Core".

Sounds good to me.

> a. "Graffito Core" : all necessary low-level services to define, store,
> manage, audit, request and search content. If needed, it can give an access
> to different heterogenous content servers (JCR and propriatary servers).
> Graffito core have to be extensible. For example, a workflow service could
> be added into "Graffito Core".

Personally I'm most interested in a pure JCR solution, but a pluggable
storage layer is also fine.

What I'm most interested in at this level is the content model.
Currently Graffito has a predefined set of Document and other content
types, but also uses generic bean persistence. Should the "Graffito
Content Model" be fixed by better specifying the core content
interfaces, or should the Graffito Core support arbitrary content
objects?

BR,

Jukka Zitting

[Christophe Lombart]

Hi,

On 2/14/07, Jukka Zitting <jukka.zitting@...> wrote:

> > a. "Graffito Core" : all necessary low-level services to define, store,
> > manage, audit, request and search content. If needed, it can give an access
> > to different heterogenous content servers (JCR and propriatary servers).
> > Graffito core have to be extensible. For example, a workflow service could
> > be added into "Graffito Core".
>
> Personally I'm most interested in a pure JCR solution, but a pluggable
> storage layer is also fine.

Me too. I just want to maximize the abstraction between application layers.
Using the JCR backend +  our OCM tools will be more extensible than a
DB + OJB or Hibernate. If everybody are agree, I'm ok to drop the OJB
support. We can have a persistence later which access to several JCR
content repos.

> What I'm most interested in at this level is the content model.
> Currently Graffito has a predefined set of Document and other content
> types, but also uses generic bean persistence. Should the "Graffito
> Content Model" be fixed by better specifying the core content
> interfaces, or should the Graffito Core support arbitrary content
> objects?
>

Good question. So, this is certainly the first tech aspect to review.
Our persistence layer should not force the developer to use a specific
content model. He should have the freedom to define its own interfaces
and classes. The current CmsObject has be also optional. JCR and our
OCM tools gives us this kind of flexibility. So, it should be possible
to have similar think in the core Graffito components. At least try to
have it with a prototype.

and you ? How do you see our content model ?


br,
Christophe

[Jukka Zitting]

Hi,

On 2/14/07, Christophe Lombart <christophe.lombart@...> wrote:

> On 2/14/07, Jukka Zitting <jukka.zitting@...> wrote:
> > What I'm most interested in at this level is the content model.
> > Currently Graffito has a predefined set of Document and other content
> > types, but also uses generic bean persistence. Should the "Graffito
> > Content Model" be fixed by better specifying the core content
> > interfaces, or should the Graffito Core support arbitrary content
> > objects?
>
> Good question. So, this is certainly the first tech aspect to review.
> Our persistence layer should not force the developer to use a specific
> content model. He should have the freedom to define its own interfaces
> and classes. The current CmsObject has be also optional. JCR and our
> OCM tools gives us this kind of flexibility. So, it should be possible
> to have similar think in the core Graffito components. At least try to
> have it with a prototype.

Agreed. Having a fixed content model would effectively make Graffito
just another content management system instead of a framework for such
systems. However, having a flexible content model poses a number of
open questions like how to handle typing or how to enforce specific
relationships between documents or objects. JCR handles this quite
nicely with the node type system. This is actually one of the main
reasons why I'd rather make Graffito just JCR-based, as otherwise
we'll need to come up with a similar typing mechanism that covers also
other backend systems.

BR,

Jukka Zitting

[Christophe Lombart]

Ok,  it sounds great !
Before starting the refactoring, I would like to be sure that
everybody is agreed.
Can we summarize like this :

Main goals
---------------
* Review the project to be more attractive and increase the community size.

* Refactoring the Graffito project in order to be more a content
management framework instead of a complete CMS product. As an
alternative to many cms products, Graffito wants to provide a more
modular approach.


Refactoring the project :
-----------------------------------
* Framework means a series of components/services that can be running
alone (or integrated into specific applications). The framework offers
also an integration with other existing frameworks/components. One
good example is an integration with existing workflow engines like
JBPM, OsWorkflow, ....
* We have to define the component lists (in the first time, only for
the "Graffito core" layer).  * The first component to review is the
current PersistenceManager. This one aims to access to different JCR
content repositories which can contain any kind of content. Other
backend systems will not be supported because it will add more
complexities (eg. node type management, ...).
* Each component has its own set of artifacts (jar, config file,
dependencies...).
* The code repository has to be reviewed in order to match to this new
goal.

The Content Model :
------------------------------
* Our content model has to be extensible without imposing specific
content types.
* The persistence layer  will use the OCM tools to map java classes
into a JCR repo.
* A tools is required to register a new class definition into a JCR
repo. When registring a new java class, this tools will create the
corresponfing node types. Register a new content java class has to be
as simple as register a new jcr node type.


Let me know if it makes sense for you.


br,
Christophe

On 2/14/07, Jukka Zitting <jukka.zitting@...> wrote:

> Hi,
>
> On 2/14/07, Christophe Lombart <christophe.lombart@...> wrote:
> > On 2/14/07, Jukka Zitting <jukka.zitting@...> wrote:
> > > What I'm most interested in at this level is the content model.
> > > Currently Graffito has a predefined set of Document and other content
> > > types, but also uses generic bean persistence. Should the "Graffito
> > > Content Model" be fixed by better specifying the core content
> > > interfaces, or should the Graffito Core support arbitrary content
> > > objects?
> >
> > Good question. So, this is certainly the first tech aspect to review.
> > Our persistence layer should not force the developer to use a specific
> > content model. He should have the freedom to define its own interfaces
> > and classes. The current CmsObject has be also optional. JCR and our
> > OCM tools gives us this kind of flexibility. So, it should be possible
> > to have similar think in the core Graffito components. At least try to
> > have it with a prototype.
>
> Agreed. Having a fixed content model would effectively make Graffito
> just another content management system instead of a framework for such
> systems. However, having a flexible content model poses a number of
> open questions like how to handle typing or how to enforce specific
> relationships between documents or objects. JCR handles this quite
> nicely with the node type system. This is actually one of the main
> reasons why I'd rather make Graffito just JCR-based, as otherwise
> we'll need to come up with a similar typing mechanism that covers also
> other backend systems.
>
> BR,
>
> Jukka Zitting
>

[Jukka Zitting]

Hi,

On 2/14/07, Christophe Lombart <christophe.lombart@...> wrote:
> Before starting the refactoring, I would like to be sure that
> everybody is agreed. Can we summarize like this :

+1, sounds good to me.

> * Framework means a series of components/services that can be running
> alone (or integrated into specific applications). The framework offers
> also an integration with other existing frameworks/components.

We might want to consider applying the OSGi component model in
Graffito to help integration with other tools.

> * The persistence layer  will use the OCM tools to map java classes
> into a JCR repo.
> * A tools is required to register a new class definition into a JCR
> repo. When registring a new java class, this tools will create the
> corresponfing node types. Register a new content java class has to be
> as simple as register a new jcr node type.

There's a jcr-classloader component in Jackrabbit contribs that might
come in handy.

I'd also be interested in investigating options for content-to-object
mappings as opposed to object-to-content mappings. I.e. could we
automatically expose JCR content as Java objects (instead or in
addition to JCR Nodes) to enable effortless integration with various
JavaBean tools.

BR,

Jukka Zitting

[Christophe Lombart]

On 2/14/07, Jukka Zitting <jukka.zitting@...> wrote:

> Hi,
>
> On 2/14/07, Christophe Lombart <christophe.lombart@...> wrote:
> > Before starting the refactoring, I would like to be sure that
> > everybody is agreed. Can we summarize like this :
>
> +1, sounds good to me.
>
> > * Framework means a series of components/services that can be running
> > alone (or integrated into specific applications). The framework offers
> > also an integration with other existing frameworks/components.
>
> We might want to consider applying the OSGi component model in
> Graffito to help integration with other tools.
>

+1 . Let's talk later on that topic.

> There's a jcr-classloader component in Jackrabbit contribs that might
> come in handy.

ok I will review it.

>
> I'd also be interested in investigating options for content-to-object
> mappings as opposed to object-to-content mappings. I.e. could we
> automatically expose JCR content as Java objects (instead or in
> addition to JCR Nodes) to enable effortless integration with various
> JavaBean tools.

What do you mean by content-to-object mapping. Can give some use cases ?
The OCM tools is supporting both mapping I think no ?

[Jukka Zitting]

Hi,

On 2/14/07, Christophe Lombart <christophe.lombart@...> wrote:
> What do you mean by content-to-object mapping. Can give some use cases ?
> The OCM tools is supporting both mapping I think no ?

The current OCM tool is based on the premise that the Java class being
mapped already exists. What I'm thinking about is a system for
automatically mapping JCR content to objects without any preconfigured
classes being available. Such a mapping would make it easy to for
example use a standard JavaBean browser/editor widget for manipulating
the content of a given JCR node.

BR,

Jukka Zitting

[Jukka Zitting]

Hi,

On 2/2/07, Jukka Zitting <jukka.zitting@...> wrote:
> The ASF board asked us to report again this month on the outcome of
> the project status discussion we had recently. It seems that there's
> marked interest in the project, but as of now not much is happening.
> I'd like to resume the discussion and hopefully arrive in a conclusion
> that we could include in the next Incubator report.

I've written the following report for Graffito this month. Please
comment by the end of today if there's something you'd like to change
in the report.

----

Graffito

(This is the extra followup report requested by the board last month.)

Graffito is a framework for content-based applications, especially in
portlet environments. Graffito entered incubation on September 20,
2004.

The recent discussion on the status of the Graffito project has
concluded with some concrete action items (see
http://mail-archives.apache.org/mod_mbox/incubator-graffito-dev/200702.mbox/%3c3b728ee90702140445i5d21bd22j95fb5b67c58abc70@...%3e).
The plan is to realign Graffito to be more a content management
framework instead of a complete CMS product and to better leverage the
features of JCR content repositories.

The effect of these plans on commit activity remains to be seen, but
as of now the general feeling around the project is positive.
Hopefully we'll have some concrete results to show by the time of the
next report.

----

BR,

Jukka Zitting

[Christophe Lombart]

No comment. Thanks for this report.

Christophe


On 2/14/07, Jukka Zitting <jukka.zitting@...> wrote:

> Hi,
>
> On 2/2/07, Jukka Zitting <jukka.zitting@...> wrote:
> > The ASF board asked us to report again this month on the outcome of
> > the project status discussion we had recently. It seems that there's
> > marked interest in the project, but as of now not much is happening.
> > I'd like to resume the discussion and hopefully arrive in a conclusion
> > that we could include in the next Incubator report.
>
> I've written the following report for Graffito this month. Please
> comment by the end of today if there's something you'd like to change
> in the report.
>
> ----
>
> Graffito
>
> (This is the extra followup report requested by the board last month.)
>
> Graffito is a framework for content-based applications, especially in
> portlet environments. Graffito entered incubation on September 20,
> 2004.
>
> The recent discussion on the status of the Graffito project has
> concluded with some concrete action items (see
> http://mail-archives.apache.org/mod_mbox/incubator-graffito-dev/200702.mbox/%3c3b728ee90702140445i5d21bd22j95fb5b67c58abc70@...%3e).
> The plan is to realign Graffito to be more a content management
> framework instead of a complete CMS product and to better leverage the
> features of JCR content repositories.
>
> The effect of these plans on commit activity remains to be seen, but
> as of now the general feeling around the project is positive.
> Hopefully we'll have some concrete results to show by the time of the
> next report.
>
> ----
>
> BR,
>
> Jukka Zitting
>

[Christophe Lombart]

Ah yes, just one comment : How to organise/split the work ? Who is
volonteer to work on a specific part ?

1/ There is the first release for the JCR Mapping tools ( see
http://mail-archives.apache.org/mod_mbox/incubator-graffito-dev/200702.mbox/%3c510143ac0702020331k43ebb422ob091f8aa0b37cdbe@...%3e)
2/ The refactoring of the persistence manager.
3/ and maybe the documentations, exemples, review the site, ...


I'm volonteer to work one the persistence manager refactorin if
someone wants to work on the OCM tools.

Christophe



On 2/14/07, Jukka Zitting <jukka.zitting@...> wrote:

> Hi,
>
> On 2/2/07, Jukka Zitting <jukka.zitting@...> wrote:
> > The ASF board asked us to report again this month on the outcome of
> > the project status discussion we had recently. It seems that there's
> > marked interest in the project, but as of now not much is happening.
> > I'd like to resume the discussion and hopefully arrive in a conclusion
> > that we could include in the next Incubator report.
>
> I've written the following report for Graffito this month. Please
> comment by the end of today if there's something you'd like to change
> in the report.
>
> ----
>
> Graffito
>
> (This is the extra followup report requested by the board last month.)
>
> Graffito is a framework for content-based applications, especially in
> portlet environments. Graffito entered incubation on September 20,
> 2004.
>
> The recent discussion on the status of the Graffito project has
> concluded with some concrete action items (see
> http://mail-archives.apache.org/mod_mbox/incubator-graffito-dev/200702.mbox/%3c3b728ee90702140445i5d21bd22j95fb5b67c58abc70@...%3e).
> The plan is to realign Graffito to be more a content management
> framework instead of a complete CMS product and to better leverage the
> features of JCR content repositories.
>
> The effect of these plans on commit activity remains to be seen, but
> as of now the general feeling around the project is positive.
> Hopefully we'll have some concrete results to show by the time of the
> next report.
>
> ----
>
> BR,
>
> Jukka Zitting
>

[Jukka Zitting]

Hi,

On 2/14/07, Christophe Lombart <christophe.lombart@...> wrote:
> 1/ There is the first release for the JCR Mapping tools

I can bite the bullet here. :-)

BR,

Jukka Zitting

[Christophe Lombart]

On 2/15/07, Jukka Zitting <jukka.zitting@...> wrote:
> Hi,
>
> On 2/14/07, Christophe Lombart <christophe.lombart@...> wrote:
> > 1/ There is the first release for the JCR Mapping tools
>
> I can bite the bullet here. :-)

Of course, you are welcome :-)
I'm going to finalize the name property support. It is is a part of
the issue GRFT-40 (see issue :
http://issues.apache.org/jira/browse/GRFT-40). Maybe we can split this
issue into small ones.

Christophe

>
> BR,
>
> Jukka Zitting
>