You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lenya.apache.org by Andreas Hartmann <an...@apache.org> on 2005/08/17 09:59:24 UTC
[Vote] [1.4] JCR-only vs. Repository Abstraction Layer
Hi Lenya devs,
we have to come to a decision about the repository question.
People stated their opinions, it looks like there are two
general directions.
If you think it's too early for a vote, please request cancelling.
Vote:
(a) Lenya should focus on JCR only. It is OK to implement core
functionality which absolutely relies on JCR features.
+1
----
(b) Lenya should support other repository implementations as well,
without implementing custom JCR content repositories.
This means we need a Lenya-specific repository abstraction layer.
----
(c) That should be deferred, let's release 1.4 with the current
repository implementation. I'm aware that this could imply
bigger migration efforts from 1.4 to 1.6.
Some advantages of (a):
- We can leverage the full power of JCR.
- We don't have to care about designing another repo layer (which is quite
complex).
- We don't have to care about compliance between several repo implementations.
- We don't have to mimic JCR functionality in other repo implementations.
- Testing efforts are reduced. (we don't have automated tests yet, that's
not good but it is the truth and we have to face it)
- Overall: faster, cleaner, simpler.
Some advantages of (b):
- Assuming that the Lenya repo API is not as complex as JCR, it is
easier to implement back-ends (content repositories, e.g. SVN-backed).
- We don't rely on external code.
- Overall: more flexible, more independent.
----
A note about doco etc.:
There will always be the need for other repositories.
But IMO we should differentiate between
- using a repo as a Lenya repository and
- allowing to export / import content to / from a repo
In the case of doco, IIUC there's no need for using the SVN versioning
for CMS versioning, is there? Maybe an (automated) export to an SVN
repository would be sufficient.
-- Andreas
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: [Vote] [1.4] JCR-only vs. Repository Abstraction Layer
Posted by Andreas Hartmann <an...@apache.org>.
Jann Forrer wrote:
[...]
> I could imagine that the migration 1.2 -> 1.4 (NO JCR) might be easier.
> You mainly have to extract the the meta-data and put it into a .xml.meta
> and start testing.
> How is the migration path with jcr-only?
> 1.2 -> extract meta-data from content -> import into a jcr repo ?
Yes, that would be the case.
The second step is already implemented for the current JCR integration
(see wiki page "JCRConfiguration")
> It probably might be more difficult to track down problems with that
> approach or am i wrong?
I think it will be quite straightforward.
And we can add a verification step (generate a test XML including
meta data from both FS and JCR and compare them).
-- Andreas
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: [Vote] [1.4] JCR-only vs. Repository Abstraction Layer
Posted by Jann Forrer <ja...@id.unizh.ch>.
On Thu, 18 Aug 2005, Antonio Gallardo wrote:
> Andreas Hartmann wrote:
>
> > Vote:
> >
> > (a) Lenya should focus on JCR only. It is OK to implement core
> > functionality which absolutely relies on JCR features.
>
> +1
+1 (however ...., see below)
>
> How will be the migration from 1.2 to 1.4? Will be great to provide at
> least an automated repository migration for current users. Is that OK?
>
+1 (i was thinking about the migration just yesterday)
I could imagine that the migration 1.2 -> 1.4 (NO JCR) might be easier.
You mainly have to extract the the meta-data and put it into a .xml.meta
and start testing.
How is the migration path with jcr-only?
1.2 -> extract meta-data from content -> import into a jcr repo ?
It probably might be more difficult to track down problems with that
approach or am i wrong?
Jann
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: [Vote] [1.4] JCR-only vs. Repository Abstraction Layer
Posted by Antonio Gallardo <ag...@agssa.net>.
Andreas Hartmann wrote:
> Vote:
>
> (a) Lenya should focus on JCR only. It is OK to implement core
> functionality which absolutely relies on JCR features.
+1
How will be the migration from 1.2 to 1.4? Will be great to provide at
least an automated repository migration for current users. Is that OK?
Best Regards,
Antonio Gallardo.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: [Summary] [RFO] [1.4] JCR-only vs. Repository Abstraction Layer
Posted by "J. Wolfgang Kaltz" <ka...@interactivesystems.info>.
Andreas Hartmann schrieb:
>>> (...)
>>> - Is Jackrabbit stable enough to act as the default Lenya
>>> repository implementation?
>>
>>
>>
>> I agree that's a valid concern. I guess, from the community
>> perspective, we have to try :) An alternative scenario is to base
>> Lenya's content handling on the JCR API anyway (meaning, a Lenya node
>> becomes a JCR node etc.) and for storage have our content mapped
>> one-to-one onto files, as it is now.
>
>
> Does this mean that we provide our own stripped-down JCR implementation?
Yes. What I am wondering is if it would be possible to turn the current
Lenya repository implementation inside-out. Lenya internals would only
use JCR classes (instead of e.g. Lenya's Node class). The current
repository implementation becomes Lenya's stripped-down JCR
implementation, which would be registered using the same mechanism as
any other JCR implementation. I'm not sure that makes sense, but if it
does, it should make for a smoother transition.
--
Wolfgang
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: [Summary] [RFO] [1.4] JCR-only vs. Repository Abstraction Layer
Posted by Andreas Hartmann <an...@apache.org>.
J. Wolfgang Kaltz wrote:
> Andreas Hartmann schrieb:
>
>> (...)
>>
>>> (a) Lenya should focus on JCR only. It is OK to implement core
>>> functionality which absolutely relies on JCR features.
>>
>>
>> (...)
>> - Is this sufficient? Can we require people to implement JCR
>> to access custom repositories?
>
>
> What is meant here with access to custom repositories ? If it's
> integrating external sources, that IMO has no effect on Lenya/JCR: if
> you want the CMS to manage that source, it's no longer external and it
> would instead need to be imported.
I share this opinion. But, to quote Michi:
>> But - do we really want to allow editing a Forrest site?
> sure. No offense, but if Lenya isn't able to do this, then Lenya is
> pretty useless. If Lenya doesn't allow building a Forrest publication,
> then I think we have totally missed the goal of providing a Content Management
> Framework
IIUC he means that Lenya should be able to edit external content directly.
Please correct me if I got this wrong.
> If instead you want data managed
> elsewhere to be displayed within a publication, this also wouldn't be
> affected by Lenya switching to JCR
> So IMO this question is not applicable
>
>>
>> - Is Jackrabbit stable enough to act as the default Lenya
>> repository implementation?
>
>
> I agree that's a valid concern. I guess, from the community perspective,
> we have to try :) An alternative scenario is to base Lenya's content
> handling on the JCR API anyway (meaning, a Lenya node becomes a JCR node
> etc.) and for storage have our content mapped one-to-one onto files, as
> it is now.
Does this mean that we provide our own stripped-down JCR implementation?
>> If these concerns are not considered weighty, we should start to
>> re-design the Lenya repository layer. IMO it makes sense to use
>> a Wiki page to collect random thoughts and to refine them gradually.
>>
>> Of course a meeting (brainstorming day) would be great. Maybe all
>> involved people want to visit Zurich? :)
>
>
> I'd be interested in that. I'm coming to Zurich anyway on a personal
> matter Sept. 24-25, so let me be the first to propose a date ;)
> How about monday, Sept. 26th ?
+1, if my boss agrees :)
-- Andreas
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: [Summary] [RFO] [1.4] JCR-only vs. Repository Abstraction Layer
Posted by "J. Wolfgang Kaltz" <ka...@interactivesystems.info>.
Andreas Hartmann schrieb:
> (...)
>> (a) Lenya should focus on JCR only. It is OK to implement core
>> functionality which absolutely relies on JCR features.
>
> (...)
> - Is this sufficient? Can we require people to implement JCR
> to access custom repositories?
What is meant here with access to custom repositories ? If it's
integrating external sources, that IMO has no effect on Lenya/JCR: if
you want the CMS to manage that source, it's no longer external and it
would instead need to be imported. If instead you want data managed
elsewhere to be displayed within a publication, this also wouldn't be
affected by Lenya switching to JCR
So IMO this question is not applicable
>
> - Is Jackrabbit stable enough to act as the default Lenya
> repository implementation?
I agree that's a valid concern. I guess, from the community perspective,
we have to try :) An alternative scenario is to base Lenya's content
handling on the JCR API anyway (meaning, a Lenya node becomes a JCR node
etc.) and for storage have our content mapped one-to-one onto files, as
it is now.
>
>
> If these concerns are not considered weighty, we should start to
> re-design the Lenya repository layer. IMO it makes sense to use
> a Wiki page to collect random thoughts and to refine them gradually.
>
> Of course a meeting (brainstorming day) would be great. Maybe all
> involved people want to visit Zurich? :)
I'd be interested in that. I'm coming to Zurich anyway on a personal
matter Sept. 24-25, so let me be the first to propose a date ;)
How about monday, Sept. 26th ?
--
Wolfgang
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: [Summary] [RFO] [1.4] JCR-only vs. Repository Abstraction Layer
Posted by Andreas Hartmann <an...@apache.org>.
Torsten Schlabach wrote:
> > Of course a meeting (brainstorming day) would be great. Maybe all
> > involved people want to visit Zurich? :)
>
> Good idea, but depends on schedule. Would this be on a working day or
> rather in the weekend? Will one day do?
Michi started a thread ("Lenya Hackathon Proposal").
-- Andreas
>
> Regards,
> Torsten
>
> Andreas Hartmann schrieb:
>
>> Andreas Hartmann wrote:
>>
>>> Hi Lenya devs,
>>>
>>> we have to come to a decision about the repository question.
>>> People stated their opinions, it looks like there are two
>>> general directions.
>>
>>
>>
>>> (a) Lenya should focus on JCR only. It is OK to implement core
>>> functionality which absolutely relies on JCR features.
>>
>>
>>
>> It looks like the general opinion of the community is to go
>> for a JCR-based approach.
>>
>> Some concerns that were brought up:
>>
>> - Is this sufficient? Can we require people to implement JCR
>> to access custom repositories?
>>
>> - Is Jackrabbit stable enough to act as the default Lenya
>> repository implementation?
>>
>>
>> If these concerns are not considered weighty, we should start to
>> re-design the Lenya repository layer. IMO it makes sense to use
>> a Wiki page to collect random thoughts and to refine them gradually.
>>
>> Of course a meeting (brainstorming day) would be great. Maybe all
>> involved people want to visit Zurich? :)
>>
>> -- Andreas
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
>> For additional commands, e-mail: dev-help@lenya.apache.org
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: [Summary] [RFO] [1.4] JCR-only vs. Repository Abstraction Layer
Posted by Torsten Schlabach <ts...@apache.org>.
> Of course a meeting (brainstorming day) would be great. Maybe all
> involved people want to visit Zurich? :)
Good idea, but depends on schedule. Would this be on a working day or
rather in the weekend? Will one day do?
Regards,
Torsten
Andreas Hartmann schrieb:
> Andreas Hartmann wrote:
>
>> Hi Lenya devs,
>>
>> we have to come to a decision about the repository question.
>> People stated their opinions, it looks like there are two
>> general directions.
>
>
>> (a) Lenya should focus on JCR only. It is OK to implement core
>> functionality which absolutely relies on JCR features.
>
>
> It looks like the general opinion of the community is to go
> for a JCR-based approach.
>
> Some concerns that were brought up:
>
> - Is this sufficient? Can we require people to implement JCR
> to access custom repositories?
>
> - Is Jackrabbit stable enough to act as the default Lenya
> repository implementation?
>
>
> If these concerns are not considered weighty, we should start to
> re-design the Lenya repository layer. IMO it makes sense to use
> a Wiki page to collect random thoughts and to refine them gradually.
>
> Of course a meeting (brainstorming day) would be great. Maybe all
> involved people want to visit Zurich? :)
>
> -- Andreas
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
> For additional commands, e-mail: dev-help@lenya.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
[Summary] [RFO] [1.4] JCR-only vs. Repository Abstraction Layer
Posted by Andreas Hartmann <an...@apache.org>.
Andreas Hartmann wrote:
> Hi Lenya devs,
>
> we have to come to a decision about the repository question.
> People stated their opinions, it looks like there are two
> general directions.
> (a) Lenya should focus on JCR only. It is OK to implement core
> functionality which absolutely relies on JCR features.
It looks like the general opinion of the community is to go
for a JCR-based approach.
Some concerns that were brought up:
- Is this sufficient? Can we require people to implement JCR
to access custom repositories?
- Is Jackrabbit stable enough to act as the default Lenya
repository implementation?
If these concerns are not considered weighty, we should start to
re-design the Lenya repository layer. IMO it makes sense to use
a Wiki page to collect random thoughts and to refine them gradually.
Of course a meeting (brainstorming day) would be great. Maybe all
involved people want to visit Zurich? :)
-- Andreas
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: [RFO] [1.4] JCR-only vs. Repository Abstraction Layer
Posted by Torsten Schlabach <ts...@apache.org>.
+1 for (a)
Regards,
Torsten
Andreas Hartmann schrieb:
> Hi Lenya devs,
>
> we have to come to a decision about the repository question.
> People stated their opinions, it looks like there are two
> general directions.
>
> If you think it's too early for a vote, please request cancelling.
>
> Vote:
>
> (a) Lenya should focus on JCR only. It is OK to implement core
> functionality which absolutely relies on JCR features.
>
> +1
>
> ----
>
> (b) Lenya should support other repository implementations as well,
> without implementing custom JCR content repositories.
> This means we need a Lenya-specific repository abstraction layer.
>
> ----
>
> (c) That should be deferred, let's release 1.4 with the current
> repository implementation. I'm aware that this could imply
> bigger migration efforts from 1.4 to 1.6.
>
>
> Some advantages of (a):
>
> - We can leverage the full power of JCR.
>
> - We don't have to care about designing another repo layer (which is quite
> complex).
>
> - We don't have to care about compliance between several repo
> implementations.
>
> - We don't have to mimic JCR functionality in other repo implementations.
>
> - Testing efforts are reduced. (we don't have automated tests yet, that's
> not good but it is the truth and we have to face it)
>
> - Overall: faster, cleaner, simpler.
>
>
> Some advantages of (b):
>
> - Assuming that the Lenya repo API is not as complex as JCR, it is
> easier to implement back-ends (content repositories, e.g. SVN-backed).
>
> - We don't rely on external code.
>
> - Overall: more flexible, more independent.
>
>
> ----
>
> A note about doco etc.:
>
> There will always be the need for other repositories.
> But IMO we should differentiate between
>
> - using a repo as a Lenya repository and
> - allowing to export / import content to / from a repo
>
> In the case of doco, IIUC there's no need for using the SVN versioning
> for CMS versioning, is there? Maybe an (automated) export to an SVN
> repository would be sufficient.
>
> -- Andreas
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
> For additional commands, e-mail: dev-help@lenya.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: [RFO] [1.4] JCR-only vs. Repository Abstraction Layer
Posted by Torsten Schlabach <ts...@apache.org>.
Wolfgang,
> BTW: Jackrabbit's default storage -is- the filesystem. Question to
> those
> who have experimented with it thus far: how does it do this, e.g. one
> big file, or one file per "item", or one per "node" and one per
> "property", ... ? I suppose we probably should not rely on that anyway
> (e.g. for automated svn functionality), but I am still curious :)
The good news is: It is not one big file. I wouldn't actually consider
this "filesystem" then but rather "binary". This would be probably what
you get when using the BerkeleyDB backend that I thought I read
something about.
You cannot tell exactly if this is one file per node and one file per
property, but what I can tell for sure:
In the workspaces/data folder of a filesystem repository you will find a
lot of folders with names in hex values that contain other folders with
names in hex values which at some point contain XML files with properties.
In other words: Folders and filenames are entirely unrelated to the
outside view of the repository, which in my opinion renders them useless
for any other purpose but reading and writing the content through
Jackrabbit. (I guess that was the question behind your question.)
Don't forget the basic idea of UUID in JCR. JCR is *not primarily* a
tree structure with folders and files. You can model it that way if you
want, but you can also build entirely different systems of reference. I
think (haven't tried) you can even have parallel systems of referencing
the same content.
Hope this helps.
Regards,
Torsten
J. Wolfgang Kaltz schrieb:
>> Andreas Hartmann wrote:
>>
>>> Hi Lenya devs,
>>>
>>> we have to come to a decision about the repository question.
>>> People stated their opinions, it looks like there are two
>>> general directions.
>>>
>>> If you think it's too early for a vote, please request cancelling.
>>>
>>> Vote:
>>>
>>> (a) Lenya should focus on JCR only. It is OK to implement core
>>> functionality which absolutely relies on JCR features.
>>>
>>> +1
>
>
> Assuming this decision is neutral regarding the question "will Lenya be
> used for Apache doco", I'm also
> +1
>
> BTW: Jackrabbit's default storage -is- the filesystem. Question to those
> who have experimented with it thus far: how does it do this, e.g. one
> big file, or one file per "item", or one per "node" and one per
> "property", ... ? I suppose we probably should not rely on that anyway
> (e.g. for automated svn functionality), but I am still curious :)
>
>
> --
> Wolfgang
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
> For additional commands, e-mail: dev-help@lenya.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: [RFO] [1.4] JCR-only vs. Repository Abstraction Layer
Posted by "J. Wolfgang Kaltz" <ka...@interactivesystems.info>.
> Andreas Hartmann wrote:
>
>> Hi Lenya devs,
>>
>> we have to come to a decision about the repository question.
>> People stated their opinions, it looks like there are two
>> general directions.
>>
>> If you think it's too early for a vote, please request cancelling.
>>
>> Vote:
>>
>> (a) Lenya should focus on JCR only. It is OK to implement core
>> functionality which absolutely relies on JCR features.
>>
>> +1
Assuming this decision is neutral regarding the question "will Lenya be
used for Apache doco", I'm also
+1
BTW: Jackrabbit's default storage -is- the filesystem. Question to those
who have experimented with it thus far: how does it do this, e.g. one
big file, or one file per "item", or one per "node" and one per
"property", ... ? I suppose we probably should not rely on that anyway
(e.g. for automated svn functionality), but I am still curious :)
--
Wolfgang
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: [RFO] [1.4] JCR-only vs. Repository Abstraction Layer
Posted by Felix Röthenbacher <fe...@wyona.com>.
I strongly agree with Andreas to focus on JCR only!
Andreas mentioned many good reasons for focusing on
JCR only. One point I want to stress once more is
that focusing on JCR will disburden the Lenya community
from maintaining a repository on its own. Additionally,
versioning, locking, transaction, etc. is also
mostly covered and taken care of by JCR.
BR,
Felix
Andreas Hartmann wrote:
> Hi Lenya devs,
>
> we have to come to a decision about the repository question.
> People stated their opinions, it looks like there are two
> general directions.
>
> If you think it's too early for a vote, please request cancelling.
>
> Vote:
>
> (a) Lenya should focus on JCR only. It is OK to implement core
> functionality which absolutely relies on JCR features.
>
> +1
>
> ----
>
> (b) Lenya should support other repository implementations as well,
> without implementing custom JCR content repositories.
> This means we need a Lenya-specific repository abstraction layer.
>
> ----
>
> (c) That should be deferred, let's release 1.4 with the current
> repository implementation. I'm aware that this could imply
> bigger migration efforts from 1.4 to 1.6.
>
>
> Some advantages of (a):
>
> - We can leverage the full power of JCR.
>
> - We don't have to care about designing another repo layer (which is quite
> complex).
>
> - We don't have to care about compliance between several repo
> implementations.
>
> - We don't have to mimic JCR functionality in other repo implementations.
>
> - Testing efforts are reduced. (we don't have automated tests yet, that's
> not good but it is the truth and we have to face it)
>
> - Overall: faster, cleaner, simpler.
>
>
> Some advantages of (b):
>
> - Assuming that the Lenya repo API is not as complex as JCR, it is
> easier to implement back-ends (content repositories, e.g. SVN-backed).
>
> - We don't rely on external code.
>
> - Overall: more flexible, more independent.
>
>
> ----
>
> A note about doco etc.:
>
> There will always be the need for other repositories.
> But IMO we should differentiate between
>
> - using a repo as a Lenya repository and
> - allowing to export / import content to / from a repo
>
> In the case of doco, IIUC there's no need for using the SVN versioning
> for CMS versioning, is there? Maybe an (automated) export to an SVN
> repository would be sufficient.
>
> -- Andreas
>
>
--
Felix Röthenbacher felix.roethenbacher@wyona.com
Wyona Inc. - Open Source Content Management - Apache Lenya
http://www.wyona.com http://lenya.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: [Vote] [1.4] JCR-only vs. Repository Abstraction Layer
Posted by "Gregor J. Rothfuss" <gr...@apache.org>.
Andreas Hartmann wrote:
> (a) Lenya should focus on JCR only. It is OK to implement core
> functionality which absolutely relies on JCR features.
+1 given that we can implement svn as an export. we would indeed only
store published versions in svn, and maintain an internal revision history.
> In the case of doco, IIUC there's no need for using the SVN versioning
> for CMS versioning, is there? Maybe an (automated) export to an SVN
> repository would be sufficient.
right
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
JCR and roadmap aspects (was: Re: [Vote] [1.4] JCR-only vs. Repository
Abstraction Layer)
Posted by Andreas Hartmann <an...@apache.org>.
My feelings how a JCR-only approach is related to the roadmap aspects
(note: this doesn't imply conformance to the roadmap itself):
( - o + )
Community o
Low Entry Barrier + (less complexity, existing JCR docs)
Product Maturity + (clean architecture)
Industrial Strength o (identic implications of JCR-optional & JCR-only)
Off-the-Shelf-Components + (we don't do our own repo)
Feature Set + (implementation of features using
queries etc. is possible)
Standards Compliance + (each Lenya repo can be accessed via JCR)
Usability o
-- Andreas
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org