You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lenya.apache.org by Thorsten Scherler <th...@apache.org> on 2008/01/12 02:13:26 UTC
Re: Message on TheServerSide.com: Frustration with competing
apache projects (Lenya vs. JCR)
On Fri, 2008-01-11 at 17:34 +0100, Jörn Nettingsmeier wrote:
...
> but a lesson could be learnt from this nonetheless: we should try to tie
> into apache (and other projects we re-use) more than we currently do,
Can you define tie in?
...
>
> i'm sure JCR will be re-considered (although i would also like to bring
> eXist into the discussion).
Actually a while back we decided to go our own route for jcr like with
some other components such as workflow markup, ac, ... My opinion about
this is, it is total overkill and inefficient. We need to maintain too
much medium quality code that is not even lenya specific to solve common
problems that are already solved by specialized OS products.
See the Jboss workflow engine that is getting used in e.g. Daisy and
Alfresco and compare it with ours. Much more powerful, tools
support, ... Our own JCR implementation is just another bullet point in
a big list.
...and yes we need jcr, now! A CMS without JCR support is doomed.
> but then there's also the move to cocoon
> 2.2, blocks and spring - i wonder which should be handled first.
I am using cocoon 2.2 and spring in current project and have ported the
forrest dispatcher as a cocoon block [1]. Moving to cocoon 2.2
architecture in 2.x of lenya is IMO not a priority since it means a
rethinking of many parts of our current use of cocoon.
> then there's people who feel that lenya should become more independent
> of cocoon (thorsten and andreas, if i have understood them correctly),
Of the underlying Avalon dependencies yes, further cocoon 2.2 tries to
be more standard like and moving it to spring brings a lot more
flexibility. However my point is that I would like to see that I can
interact with lenya fully via an java api or having the possibility to
switch to another interface.
JSF is e.g. IMO the way better interface in comparison with cforms. The
question is to have a clean API to be able to switch technologies. A
small nice java based core and wrapper for cocoon, jsf, tapestry, ...
> and others (well, me) that think that lenya should become more
> cocoon-ish and expose and handle more stuff through sitemaps and
> pipelines than it currently does.
Well, the sitemaps and pipeline handling has slightly changed in cocoon
2.2. e.g. the pass-through attribute does not exist anymore for a mount.
For e.g. forrest that is a big problem since we use a lot of
pass-throughs.
...but what do you mean with: expose and handle more stuff through
sitemaps and pipelines than it currently does. can you give an example?
>
> lots of stuff to do for a small community...
Yes, we need all the help we can, but slimming down our core and
outsource components as dependencies such as JCR and workflow and ...
will reduce the workload.
salu2
[1]
http://svn.apache.org/repos/asf/forrest/trunk/whiteboard/cocoon-2.2-blocks/
>
> Andreas Hartmann wrote:
> > Hi Lenya devs,
> >
> > FYI:
> >
> > http://www.theserverside.com/news/thread.tss?m=c.reply&thread_id=48070#245093
> >
> > <quote>
> > Total frustration with competing apache projects!!! For some unknown
> > reason apache projects always have competing and incompatible projects.
> > The Lenya and Jackrabbit is just an obvious one! If the JSR standard has
> > been approved and apache promotes to be a top domain project then WHY do
> > they not have some say about minimum compatibility!
> >
> > This is beyond me! Any other company or organization will make great
> > efforts to ensure the value of one product can be used by other
> > products! If I download JBoss Portal I feel quite confident that it will
> > work with JBoss AS. Maybe it just me but at some time I would like to
> > see some real up life for organizations and not a major integration,
> > redundant solution approach!!
> >
> > I like the given features of Lenya but also would like my CMS repository
> > to be JSR compliant so I can access with other tools such as BPM engines
> > or WebDav compliant applications.
> >
> > So all that being said… why does Lenya community think that JR
> > integration is not important? And continue to support a proprietary API?
> > And why do they not understand that a CMS system is a central part to
> > most organizations infrastructure!!
> >
> > Do other developers out there feel the same way??
> > </quote>
> >
> > -- Andreas
> >
> >
>
--
Thorsten Scherler thorsten.at.apache.org
Open Source Java consulting, training and solutions
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: Message on TheServerSide.com: Frustration with competing apache
projects (Lenya vs. JCR)
Posted by Andreas Hartmann <an...@apache.org>.
Thorsten Scherler schrieb:
[...]
>> i'm sure JCR will be re-considered (although i would also like to bring
>> eXist into the discussion).
>
> Actually a while back we decided to go our own route for jcr like with
> some other components such as workflow markup, ac, ... My opinion about
> this is, it is total overkill and inefficient. We need to maintain too
> much medium quality code that is not even lenya specific to solve common
> problems that are already solved by specialized OS products.
I share this opinion.
[...]
> ... and yes we need jcr, now! A CMS without JCR support is doomed.
I wouldn't go that far and consider it doomed. That always depends on
the market, and ATM there are not many serious competitors in the open
source market which support JCR. But of course it would be great to be
ahead of the others.
I expect benefits of JCR integration in the following fields (as defined
in our roadmap):
- Community (increased size and diversity due to positive marketing
effects and better visibility)
- Industrial Strength
- Standards Compliance
- Off The Shelf Components
- Feature Set
The following field might suffer from a negative effect:
- Product Maturity
I'm not sure about the following (might be positive or negative or not
affected at all):
- Low Entry Barrier
- Usability
Other areas with positive effect:
- Code Maintenance
>> but then there's also the move to cocoon
>> 2.2, blocks and spring - i wonder which should be handled first.
>
> I am using cocoon 2.2 and spring in current project and have ported the
> forrest dispatcher as a cocoon block [1]. Moving to cocoon 2.2
> architecture in 2.x of lenya is IMO not a priority since it means a
> rethinking of many parts of our current use of cocoon.
I agree that moving to Cocoon 2.2 it is not a priority, but for
different reasons. I consider Cocoon 2.1.x a very good product. But I
don't know the changes between 2.1.x and 2.2. well enough to judge the
necessity of upgrading.
>> then there's people who feel that lenya should become more independent
>> of cocoon (thorsten and andreas, if i have understood them correctly),
As far as I'm concerned, this is partially the case (see below).
> Of the underlying Avalon dependencies yes, further cocoon 2.2 tries to
> be more standard like and moving it to spring brings a lot more
> flexibility. However my point is that I would like to see that I can
> interact with lenya fully via an java api or having the possibility to
> switch to another interface.
I have similar feelings. The rendering/GUI layer should be separated
even stronger from the content management layer. One example is the
Lucene integration. We use cocoon:// calls, pipelines, and a transformer
to do the indexing in the content management layer. This generates
unnecessary complexity and a performance overhead and makes it very hard
to handle errors.
[...]
>> and others (well, me) that think that lenya should become more
>> cocoon-ish and expose and handle more stuff through sitemaps and
>> pipelines than it currently does.
I share this opinion when it comes to the rendering and GUI layers.
[...]
-- Andreas
--
Andreas Hartmann, CTO
BeCompany GmbH
http://www.becompany.ch
Tel.: +41 (0) 43 818 57 01
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: Message on TheServerSide.com: Frustration with competing apache
projects (Lenya vs. JCR)
Posted by Andreas Hartmann <an...@apache.org>.
Thorsten Scherler schrieb:
[...]
>>> These cases could be handled by a transformer:
>>>
>>> 1) <rev:insert-history document="lenya-document:1234-234-asdf"/>
>>>
>>> would be expanded to
>>>
>>> <rev:history document="...">
>>> <rev:revision ...
>>> <rev:revision ...
>>> ...
>>> </rev:history>
>>>
>>> which can be evaluated by a subsequent XSLT.
>> lovely. imho, this is the most natural way of dealing with it.
>> unfortunately, lenya uses this pattern only in some obscure corner
>> cases. we should change that.
>
> Exactly and if we change it, then please let us try to use just a
> wrapper transformer. I mean the transformer will call 2 or three methods
> max of a cocoon independent helper class which is actually doing the
> work. This way I can write a JSF tag attacking the same helper in no
> time.
I totally agree. This is what SoC means. The transformer should only
care about SAX, not about business logic. Take a look at the
AbstractLinkTransformer and its subclasses - they delegate the actual
link rewriting to a LinkRewriter implementation.
http://lenya.apache.org/apidocs/2.0/modules/linking/org/apache/lenya/cms/cocoon/transformation/AbstractLinkTransformer.html
IMO the LuceneIndexTransformer is a good example how it should not be
done. It totally mixes XML and business logic aspects.
-- Andreas
--
Andreas Hartmann, CTO
BeCompany GmbH
http://www.becompany.ch
Tel.: +41 (0) 43 818 57 01
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: Message on TheServerSide.com: Frustration with competing
apache projects (Lenya vs. JCR)
Posted by Thorsten Scherler <th...@apache.org>.
On Mon, 2008-01-14 at 19:36 +0100, Jörn Nettingsmeier wrote:
> Andreas Hartmann wrote:
> > Jörn Nettingsmeier schrieb:
> >> Thorsten Scherler wrote:
> > From my POV, the major benefits of JCR vs. the others are:
> >
> > - You get a Java API and can choose your implementation.
Which is the most important point. You write your code against an API
like other tool developer. Meaning a wide range of tools are available
to explore your content WITHOUT our current web front end.
> > - You get versioning and transactions out of the box.
One thing less that we need to maintain as our own implementation.
...
> > These cases could be handled by a transformer:
> >
> > 1) <rev:insert-history document="lenya-document:1234-234-asdf"/>
> >
> > would be expanded to
> >
> > <rev:history document="...">
> > <rev:revision ...
> > <rev:revision ...
> > ...
> > </rev:history>
> >
> > which can be evaluated by a subsequent XSLT.
>
> lovely. imho, this is the most natural way of dealing with it.
> unfortunately, lenya uses this pattern only in some obscure corner
> cases. we should change that.
Exactly and if we change it, then please let us try to use just a
wrapper transformer. I mean the transformer will call 2 or three methods
max of a cocoon independent helper class which is actually doing the
work. This way I can write a JSF tag attacking the same helper in no
time.
I do not propose to drop cocoon but to make our code more reusable
outside of cocoon.
>
>
> > 2) <ac:insert-user-data user="{$currentUser}"/>
> >
> > would be expanded to
> >
> > <ac:user-data user="john">
> > <ac:email>john@doe.com</ac:email>
> > <ac:name>John</ac:name>
> > ...
> > </ac:user-data>
> >
> >
> > [...]
> >
> >> if we somehow exported an xml view of our repository, i'm sure many
> >> users could think of very clever things to do with their content and
> >> metadata.
> >
> > In principle I agree, though I'd rather provide a well-documented and
> > extensible set of "custom Lenya tags" (see above). AFAIK most CMSs
> > provide such a mechanism, and users are used to it. A big plus of Lenya
> > is that, thanks to Cocoon, we have XML processing pipelines which allow
> > very flexible and powerful tag expansion scenarios.
>
> sounds good. we should bear in mind that users might want to do things
> we haven't anticipated, and expose everything in a generic way.
Yeah, write it once and use it everywhere.
...
> i'd say we should do strict interfaces and encapsulation for writing
> data and doing access control, and be really sloppy when it comes to
> retrieving data.
>
IMO using JSR as data retrieving API is the only way to go. We just do
not have the manpower for an awesome homegrown powerful implementation.
> > (Regarding the workflow engine I have no strong opinion at the moment,
> > only that it would be nice to have workflow-driven usecases instead of
> > the other way round as it is now.)
>
> well said. thorsten, what made you mention workflow explicitly? do you
> see problems with our workflow engine that other engines could solve?
Well our engine is actually an implementation of a concrete usecase (the
publishing process of web content), it is not an easy task to implement
your own custom use case where you may need a higher level of control
over different steps of a process.
Imagine I want to implement:
webcontent is created -> is DOC -> send to user xy for verification ->
xy verifies -> system transforms it to pdf -> send to Designer for
verification -> Designer verifies -> system publish
How much days/week will this cost to implement with our engine? How can
I implement this with our engine?
With e.g. JBoss jBPM that is a quite quick task like the demo may show
http://docs.jboss.com/jbpm/v3/demos/movies/jbpm-overview.htm
I do not want to say that replacing our engine with a custom jbpm
process definition is priority but would definitely say that our
user/devs can benefit a lot from such a move. Imagine the user can
choose different usecase that are provided from the programmer.
...and believe me there a lot programmers that can write you the process
definition as shown in the video with jbpm but only a few that are
capable to implement it in lenya with our current engine.
...anyway the workflow was just an example, AC would be another one, ...
and ...
salu2
--
Thorsten Scherler thorsten.at.apache.org
Open Source Java consulting, training and solutions
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: Message on TheServerSide.com: Frustration with competing apache
projects (Lenya vs. JCR)
Posted by Jörn Nettingsmeier <ne...@apache.org>.
Andreas Hartmann wrote:
> Jörn Nettingsmeier schrieb:
>> Thorsten Scherler wrote:
> From my POV, the major benefits of JCR vs. the others are:
>
> - You get a Java API and can choose your implementation.
> - You get versioning and transactions out of the box.
> - You can do XPath queries, which IMO fits our XML-based approach.
last thing i heard was that xpath support sucked, but that was 1.5 years
ago and things may have improved now.
> - JCR was designed for content management. There are best practises.
all good points.
>> i don't like how we are using a gazillion input modules and passing way
>> too many params to our xslts. i'd prefer to get at lenya-internal data
>> in big xml chunks which i then aggregate with the content and match in
>> xslts.
>
> We had that in 1.2 (page envelope). There are some major performance
> drawbacks:
>
> - You need to compute everyting up front.
true.
> - You have to compute the data for each "parallel" pipeline (e.g., for
> navigation elements and XML chunks which are called using XInclude).
> This generates a lot of XML, and therefore SAX+XSLT processing overhead.
caching should take care of that. and i don't see why they should have
to be computed more than once per request (i know they are now). still,
a valid concern.
> IMO a transformer is (in most cases) the most appropriate technology to
> feed data into the SAX stream:
>
> - It doesn't clutter the sitemaps like input modules.
> - It provides data on demand, only if they are requested by the
> processed XML.
+1
>> for instance, i'd like to be able to say "give me this file's revision
>> history for the last n revs" and "give me a map of user ids vs. their
>> emails", and then i can implement the "last edited by user
>> <fo...@bar.org>" stuff in my xsl, where it's easy to see and understand.
>
> These cases could be handled by a transformer:
>
> 1) <rev:insert-history document="lenya-document:1234-234-asdf"/>
>
> would be expanded to
>
> <rev:history document="...">
> <rev:revision ...
> <rev:revision ...
> ...
> </rev:history>
>
> which can be evaluated by a subsequent XSLT.
lovely. imho, this is the most natural way of dealing with it.
unfortunately, lenya uses this pattern only in some obscure corner
cases. we should change that.
> 2) <ac:insert-user-data user="{$currentUser}"/>
>
> would be expanded to
>
> <ac:user-data user="john">
> <ac:email>john@doe.com</ac:email>
> <ac:name>John</ac:name>
> ...
> </ac:user-data>
>
>
> [...]
>
>> if we somehow exported an xml view of our repository, i'm sure many
>> users could think of very clever things to do with their content and
>> metadata.
>
> In principle I agree, though I'd rather provide a well-documented and
> extensible set of "custom Lenya tags" (see above). AFAIK most CMSs
> provide such a mechanism, and users are used to it. A big plus of Lenya
> is that, thanks to Cocoon, we have XML processing pipelines which allow
> very flexible and powerful tag expansion scenarios.
sounds good. we should bear in mind that users might want to do things
we haven't anticipated, and expose everything in a generic way. i know
that's contrary to the oo philosophy of encapsulation, but oo is not the
holy grail, especially in realms where scripting languages are totally
adequate.
i'd say we should do strict interfaces and encapsulation for writing
data and doing access control, and be really sloppy when it comes to
retrieving data.
> (Regarding the workflow engine I have no strong opinion at the moment,
> only that it would be nice to have workflow-driven usecases instead of
> the other way round as it is now.)
well said. thorsten, what made you mention workflow explicitly? do you
see problems with our workflow engine that other engines could solve? we
should really find a way to get better error messages, but i'm not sure
external code could do that easily.
--
Jörn Nettingsmeier
"One of my most productive days was throwing away 1000 lines of code."
- Ken Thompson.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: Message on TheServerSide.com: Frustration with competing apache
projects (Lenya vs. JCR)
Posted by Andreas Hartmann <an...@apache.org>.
Jörn Nettingsmeier schrieb:
> Thorsten Scherler wrote:
[...]
>> See the Jboss workflow engine that is getting used in e.g. Daisy and
>> Alfresco and compare it with ours. Much more powerful, tools
>> support, ... Our own JCR implementation is just another bullet point in
>> a big list.
>>
>> ...and yes we need jcr, now! A CMS without JCR support is doomed.
>
> hmmm. i don't buy this. i agree that a cms that tries to maintain its
> own repo system is likely doomed, yes.
> but it's not like there aren't any alternatives to JCR.
>
> i'd like to discuss this further, learn about the pros and cons of JCR
> vs. an RDBMS vs. SVN vs. eXist vs. younameit and then arrive at a
> decision and maybe a repo abstraction that makes switching repo engines
> really easy (which might mean to leave some of the cleverness in lenya
> and not use mechanisms that might be available on one backend but not on
> another).
From my POV, the major benefits of JCR vs. the others are:
- You get a Java API and can choose your implementation.
- You get versioning and transactions out of the box.
- You can do XPath queries, which IMO fits our XML-based approach.
- JCR was designed for content management. There are best practises.
>> ...but what do you mean with: expose and handle more stuff through
>> sitemaps and pipelines than it currently does. can you give an example?
[...]
> i don't like how we are using a gazillion input modules and passing way
> too many params to our xslts. i'd prefer to get at lenya-internal data
> in big xml chunks which i then aggregate with the content and match in
> xslts.
We had that in 1.2 (page envelope). There are some major performance
drawbacks:
- You need to compute everyting up front.
- You have to compute the data for each "parallel" pipeline (e.g., for
navigation elements and XML chunks which are called using XInclude).
This generates a lot of XML, and therefore SAX+XSLT processing overhead.
IMO a transformer is (in most cases) the most appropriate technology to
feed data into the SAX stream:
- It doesn't clutter the sitemaps like input modules.
- It provides data on demand, only if they are requested by the
processed XML.
> for instance, i'd like to be able to say "give me this file's revision
> history for the last n revs" and "give me a map of user ids vs. their
> emails", and then i can implement the "last edited by user
> <fo...@bar.org>" stuff in my xsl, where it's easy to see and understand.
These cases could be handled by a transformer:
1) <rev:insert-history document="lenya-document:1234-234-asdf"/>
would be expanded to
<rev:history document="...">
<rev:revision ...
<rev:revision ...
...
</rev:history>
which can be evaluated by a subsequent XSLT.
2) <ac:insert-user-data user="{$currentUser}"/>
would be expanded to
<ac:user-data user="john">
<ac:email>john@doe.com</ac:email>
<ac:name>John</ac:name>
...
</ac:user-data>
[...]
> if we somehow exported an xml view of our repository, i'm sure many
> users could think of very clever things to do with their content and
> metadata.
In principle I agree, though I'd rather provide a well-documented and
extensible set of "custom Lenya tags" (see above). AFAIK most CMSs
provide such a mechanism, and users are used to it. A big plus of Lenya
is that, thanks to Cocoon, we have XML processing pipelines which allow
very flexible and powerful tag expansion scenarios.
[...]
(Regarding the workflow engine I have no strong opinion at the moment,
only that it would be nice to have workflow-driven usecases instead of
the other way round as it is now.)
-- Andreas
--
Andreas Hartmann, CTO
BeCompany GmbH
http://www.becompany.ch
Tel.: +41 (0) 43 818 57 01
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: Message on TheServerSide.com: Frustration with competing apache
projects (Lenya vs. JCR)
Posted by Jörn Nettingsmeier <ne...@apache.org>.
Thorsten Scherler wrote:
> On Fri, 2008-01-11 at 17:34 +0100, Jörn Nettingsmeier wrote:
> ...
>> but a lesson could be learnt from this nonetheless: we should try to tie
>> into apache (and other projects we re-use) more than we currently do,
>
> Can you define tie in?
well, show up at apachecons and cocoon gts, be more visible, join other
asf projects like most of us do with cocoon (i really need to get on
jetty-dev, for example).
> See the Jboss workflow engine that is getting used in e.g. Daisy and
> Alfresco and compare it with ours. Much more powerful, tools
> support, ... Our own JCR implementation is just another bullet point in
> a big list.
>
> ...and yes we need jcr, now! A CMS without JCR support is doomed.
hmmm. i don't buy this. i agree that a cms that tries to maintain its
own repo system is likely doomed, yes.
but it's not like there aren't any alternatives to JCR.
i'd like to discuss this further, learn about the pros and cons of JCR
vs. an RDBMS vs. SVN vs. eXist vs. younameit and then arrive at a
decision and maybe a repo abstraction that makes switching repo engines
really easy (which might mean to leave some of the cleverness in lenya
and not use mechanisms that might be available on one backend but not on
another).
> ...but what do you mean with: expose and handle more stuff through
> sitemaps and pipelines than it currently does. can you give an example?
when i started with lenya, i was quite frustrated how things that should
be really easy (like asking "who published this document last and what
is their email address?") were all but impossible in lenya or required
passing way too many paramters between sitemaps, components and xslts.
with 2.0, most of the clever things i want to do are quite easy. but
that is not because of particularly brilliant design. it's because
andreas has tirelessly answered every tantrum i threw on the list with
yet another input module :)
it would be great if users could peak at lenya-internal information in
way that devs haven't anticipated and provided a hook for.
when a new user starts doing clever things with lenya, the first thing
s/he sees is sitemaps and xslts. this should be our primary api for
getting at data.
i don't like how we are using a gazillion input modules and passing way
too many params to our xslts. i'd prefer to get at lenya-internal data
in big xml chunks which i then aggregate with the content and match in
xslts.
for instance, i'd like to be able to say "give me this file's revision
history for the last n revs" and "give me a map of user ids vs. their
emails", and then i can implement the "last edited by user
<fo...@bar.org>" stuff in my xsl, where it's easy to see and understand.
same for usecases: i think it might make things easier if some of the
more trivial logic (and most of our usecase logic is trivial) was
visible in xslts.
before anyone cries wolf: i'm talking about read-only access at this
point, so there will be no locking issues between the java api and the
xml side.
i must confess that when i ripped out the broken naive caching we had in
the default pub, i had mixed emotions - it clearly could not work, but
it was nice to have such a rather advanced mechanism happen in a
sitemap, using core cocoon components mostly.
if we somehow exported an xml view of our repository, i'm sure many
users could think of very clever things to do with their content and
metadata.
there are coupling issues to think of, and performance, and it might
require a lot of thinking, and the whole idea might turn out to be crap.
but i'd like to re-iterate: the reason i like lenya is the sitemap/xslt
side, not its java api. it's waaaay too crufty in many areas, and avalon
is very limiting nowadays (think of how it prohibits effective
server-side state in cocoon flow, requiring such abysmal constructs like
a UsecaseProxy...)
> Yes, we need all the help we can, but slimming down our core and
> outsource components as dependencies such as JCR and workflow and ...
> will reduce the workload.
agreed. as to workflow, is there a good third-party implementation that
a) allows meaning to be attached to states and transitions and
b) can provide perfectly understandable error messages for every illegal
state transition?
if it can't do that, it's just a dumb state machine that can easily be
implemented in a few lines of code (like the one we have now).
if there is, we should take a look at it.
--
Jörn Nettingsmeier
"One of my most productive days was throwing away 1000 lines of code."
- Ken Thompson.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org