lenya 2.2 or lenya 3 (was Re: Website update)

[Thorsten Scherler <sc...@gmail.com>]

On Thu, 2010-06-03 at 12:29 +0200, Andreas Hartmann wrote:
> Am 03.06.10 11:52, schrieb Michael Wechner:
> > Andreas Hartmann wrote:
> >> Am 03.06.10 00:54, schrieb Richard Frovarp:
> >>> Since 2.2 is dead at the moment,
> >
> > what is the reason that it is dead?
> >
> > Technical or human resource reasons? Or other reasons?
> 
>  From my PoV there are the following reasons:
> 
> * Not enough interest from the community. Which is perfectly 
> understandable given that it is "only" a technology update, not a 
> functional upgrade.
> 
> * Cocoon 2.2 is not state of the art anymore, it has been supplanted by 
> Cocoon 3.
> 
> * IMO Cocoon 2.2 has some advantages over 2.1, but it is not really 
> groundbreaking. It feels like a step in the right direction, but there 
> are some issues which seem to be not quite polished yet. Many new 
> concepts are cool (reloading classloader, servlet-service framework), 
> but they come with some issues which are really annoying (like e.g. 
> class loading conflicts).
> 
> * The migration requires some fundamental changes to the Lenya 
> architecture (dependencies etc.) which would need a lot of work (IIRC I 
> wrote a mail about this).
> 
> * Maven is a whole different beast than Ant. The entry barrier is quite 
> intimidating.
> 
> 
> To summarize: The benefits of upgrading to Cocoon 2.2 don't seem to 
> justify the effort. The Lenya product is very likely to become more 
> complex and complicated. I think there are more important issues we have 
> to address, like making the user experience more pleasant and improve 
> the feature set.
> 
> I still think we should rather try to simplify the back-end by moving to 
> a mature standard repository that takes care of the complicated stuff 
> like concurrency, transactions, versioning etc. and focus on a nice rich 
> GUI. Cocoon is great for document and data processing, but nowadays 
> everything is dynamic and the user doesn't want to wait for the server 
> to assemble the page. Doing complicated things on the server, e.g. in 
> XML pipelines, always comes with an overhead which the user can't influence.
> 
> I'm not implying that we should abandon Cocoon (quite the contrary), but 
> I have the feeling we're doing too much with Cocoon which should rather 
> be done with different technologies (especially client-side ones). And 
> for the things that are a perfect match for XML pipelines (like e.g. 
> i18n and link rewriting), Cocoon 2.1 is IMO sufficient.

I totally agree with Andreas on most parts of his statement. I feel the
need to architectural re-design Lenya to better leverage our resources.
The current product can be labeled stable but limited.

The jcr situation is becoming ridículos and the overhead of self
implemented components rather then standard ones has practically stopped
user contributions. Things like our workflow engine, repository
implementation, etc. can be outsourced. This way we can concentrate on
implementing CMS functionality.

Cocoon3 (c3) is concentrating on the things which made cocoon famous and
since now without competition. For doing the presentational layer and
connect to different datasources to get xml from them. So let us define
the various alternatives to replace our own implementation with standard
components. I personally made very positive experience with Apache
Wicket for forms and there is a wicket integration in c3. 

However I thing we first put the design down on paper/wiki and then we
can distribute the workload under all of us. 

...but the most important thing is that this design is community driven,
meaning do not wait for e.g. me or Andreas to do the first step.

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: lenya 2.2 or lenya 3 (was Re: Website update)

[florent andré <fl...@4sengines.com>]

Hi Thorsten, hi all

+1 for outsourcing and put the design down.

But at the fist step don't we have to decide if we based on C2.1, C2.2 
or C3 ? have to bring a vote ?

After, for the design writing, how we begin ? Lenya is a pretty "big 
app" and many entries points can be used to do the design : process, 
uses-cases, api, user interface,...

You (all of devs) have a design document with the mains points/heading 
to fill down that you can share ?
Such a guideline will help all of us to express I think.

Cheers

On 04/06/2010 10:29, Thorsten Scherler wrote:
> On Thu, 2010-06-03 at 12:29 +0200, Andreas Hartmann wrote:
>> Am 03.06.10 11:52, schrieb Michael Wechner:
>>> Andreas Hartmann wrote:
>>>> Am 03.06.10 00:54, schrieb Richard Frovarp:
>>>>> Since 2.2 is dead at the moment,
>>>
>>> what is the reason that it is dead?
>>>
>>> Technical or human resource reasons? Or other reasons?
>>
>>    From my PoV there are the following reasons:
>>
>> * Not enough interest from the community. Which is perfectly
>> understandable given that it is "only" a technology update, not a
>> functional upgrade.
>>
>> * Cocoon 2.2 is not state of the art anymore, it has been supplanted by
>> Cocoon 3.
>>
>> * IMO Cocoon 2.2 has some advantages over 2.1, but it is not really
>> groundbreaking. It feels like a step in the right direction, but there
>> are some issues which seem to be not quite polished yet. Many new
>> concepts are cool (reloading classloader, servlet-service framework),
>> but they come with some issues which are really annoying (like e.g.
>> class loading conflicts).
>>
>> * The migration requires some fundamental changes to the Lenya
>> architecture (dependencies etc.) which would need a lot of work (IIRC I
>> wrote a mail about this).
>>
>> * Maven is a whole different beast than Ant. The entry barrier is quite
>> intimidating.
>>
>>
>> To summarize: The benefits of upgrading to Cocoon 2.2 don't seem to
>> justify the effort. The Lenya product is very likely to become more
>> complex and complicated. I think there are more important issues we have
>> to address, like making the user experience more pleasant and improve
>> the feature set.
>>
>> I still think we should rather try to simplify the back-end by moving to
>> a mature standard repository that takes care of the complicated stuff
>> like concurrency, transactions, versioning etc. and focus on a nice rich
>> GUI. Cocoon is great for document and data processing, but nowadays
>> everything is dynamic and the user doesn't want to wait for the server
>> to assemble the page. Doing complicated things on the server, e.g. in
>> XML pipelines, always comes with an overhead which the user can't influence.
>>
>> I'm not implying that we should abandon Cocoon (quite the contrary), but
>> I have the feeling we're doing too much with Cocoon which should rather
>> be done with different technologies (especially client-side ones). And
>> for the things that are a perfect match for XML pipelines (like e.g.
>> i18n and link rewriting), Cocoon 2.1 is IMO sufficient.
>
> I totally agree with Andreas on most parts of his statement. I feel the
> need to architectural re-design Lenya to better leverage our resources.
> The current product can be labeled stable but limited.
>
> The jcr situation is becoming ridículos and the overhead of self
> implemented components rather then standard ones has practically stopped
> user contributions. Things like our workflow engine, repository
> implementation, etc. can be outsourced. This way we can concentrate on
> implementing CMS functionality.
>
> Cocoon3 (c3) is concentrating on the things which made cocoon famous and
> since now without competition. For doing the presentational layer and
> connect to different datasources to get xml from them. So let us define
> the various alternatives to replace our own implementation with standard
> components. I personally made very positive experience with Apache
> Wicket for forms and there is a wicket integration in c3.
>
> However I thing we first put the design down on paper/wiki and then we
> can distribute the workload under all of us.
>
> ...but the most important thing is that this design is community driven,
> meaning do not wait for e.g. me or Andreas to do the first step.
>
> salu2

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org