Should we start 3.0?

Hi all,

like sounded in the thread around Cocoon 2.2 FOP NG update
we need to
look into updating to cocoon 2.2. Further our famous 1.3
branch that
brings some nice ideas should merge with the 2.0.x branch.

Maybe we can take the chance to merge both branch in an
upcoming 3.0.
Would it make sense to have a clean cut? 

I meaning starting first with a requirements/architecture
document and
ten develop the code around it (using as much good as we
have right
now). Do you think it would be possible?

salu2
-- 
Thorsten Scherler                                
thorsten.at.apache.org
Open Source Java                      consulting, training
and solutions


------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribelenya.apache.org
For additional commands, e-mail: dev-helplenya.apache.org

On 3/14/08, Thorsten Scherler <thorsten.scherler.extjuntadeandalucia.es> wrote:
>  we need to
>  look into updating to cocoon 2.2. Further our famous
1.3 branch that
>  brings some nice ideas should merge with the 2.0.x
branch.
>
>  Maybe we can take the chance to merge both branch in
an upcoming 3.0.
>  Would it make sense to have a clean cut?
>
>  I meaning starting first with a
requirements/architecture document and
>  then develop the code around it (using as much good as
we have right
>  now). Do you think it would be possible?
>  Thorsten Scherler                                
thorsten.at.apache.org

That was how I developed 1.3 -- I started with what I wanted
Lenya to
do.  The first step was to change Usecases to use the Area
part of the
URL as a patch for 1.2.  That evolved into 1.3's Module
system.  Then
the repository became flat, with a migration-from-1.2 module
and a new
protocol.  The rest is recreating the functions of 1.2 to
work with
the new repository using the module system.

Lenya 1.3 is still not functionally complete.  I am
currently working
on the structure editor ("relate" Module).  I hope
to finish soon, but
other obligations may delay it for 2 weeks.  Security is the
next task
-- another couple of weeks.  Then the editor needs work.
Navigation
between administration screens is missing -- 1.3 does not
yet have the
comprehensive environment of 1.2 or 2.x because many of the
components
have not been created.  The ToDo list and other
documentation is in
the "13*.txt" files at:
http://svn.apache.org/viewvc/lenya/branches/revolut
ion/1.3.x/

1.3 is completely backwards-compatible with 1.2.  Once 1.3
is usable,
tested, and all major enhancements implemented, 1.3 becomes
the
migration path from 1.2.  The version after 1.3 should
remove 1.2
compatibility (and probably half the code for a very clean
system.)

Merging with 2.x would be interesting.  Both 1.3 and 2.x add
similar
functions with very different implementations.  Paraphrasing
"What's
New in Lenya 2.0":
- Modularization: Same description, different
implementation.  1.3
Modules are very simple and cannot contain Java.  The
module.xml
contains important information; most other constraints are
due to
interaction with other Modules.  (The "home"
Module inherits the
"xhtml" Module overriding only
"page2xhtml.xsl".)
- Improved Repository Access: Allows for new repositories by
extending
the Resource Interfaces (Java).
- UNIDs for Resources: Documents are typically assigned
UUIDs, but
UNIDs allow named resources -- useful for web-editable
design
documents (CSS, XSL, XMAP, etc.)
- Link rewriting is still on the ToDo List.
- Everything is Treated as Resources: No distinctions.
- Improved Access Control - Still on ToDo List.
- Configurable Meta Data - Meta Data (and everything else)
is defined
in Resource Modules so anything is possible.
- Module Inheritance rather than Publication Templating: All
files are
inherited from multiple parent Modules.  Parent Modules may
be global
or belong to another Publication.  New Modules only need to
contain
overwritten files.
- Usecase Framework is replaced by Module system.  1.2's
Usecases
still work, but should become Modules.
- No notifications (yet), mail or otherwise.

Other improvements (IMO):
- Areas are gone.  Resources save all versions (of a
specific
translation) to one directory.  The "live" version
is controlled by a
setting (in translation.xml).  The Area portion of the URL
is used for
the Module name.
- Only two protocols are used.  The content: protocol
retrieves all
Resources.  The module: protocol retrieves all functional
files.
Other protocols are available, but rarely needed.  (see
13HELP.txt)
- Editor is Xinha -- extendible and eliminates temporary
files (and
desperately needs extending to work with images and links.)

The ultimate goal is for the lenya directory to contain just
/modules
and /pubs, and for
publications to contain:
- publication.xml (1.2's /config/publication.xconf)
- /modules (only needed for overriding a few files, e.g.
page2xhtml,
and adding new functions.)
- /content (1.3's /content/resources, but could be
external)
- /security (1.2's /ac/passwd, but could be external)

Hopefully this post and the documentation in svn explain
1.3, but
please ask about any concerns.

solprovider

------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribelenya.apache.org
For additional commands, e-mail: dev-helplenya.apache.org

Thorsten Scherler wrote:

>
>I meaning starting first with a
requirements/architecture document
>

+1 for working on requirements and architecture first

Cheers

Michael

> and
>ten develop the code around it (using as much good as we
have right
>now). Do you think it would be possible?
>
>salu2
>  
>


-- 
Michael Wechner
Wyona      -   Open Source Content Management - Yanel,
Yulup
http://www.wyona.com
michael.wechnerwyona.com, michiapache.org
+41 44 272 91 61


------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribelenya.apache.org
For additional commands, e-mail: dev-helplenya.apache.org

Thorsten Scherler wrote:
> Hi all,
> 
> like sounded in the thread around Cocoon 2.2 FOP NG
update we need to
> look into updating to cocoon 2.2. Further our famous
1.3 branch that
> brings some nice ideas should merge with the 2.0.x
branch.
> 
> Maybe we can take the chance to merge both branch in an
upcoming 3.0.
> Would it make sense to have a clean cut? 
> 
> I meaning starting first with a
requirements/architecture document and
> ten develop the code around it (using as much good as
we have right
> now). Do you think it would be possible?
> 
> salu2

disclaimer: i've just started a new job and won't be
spending all that
much time on lenya in the next month or so, so ignore me


i think moving along with cocoon 2.2 is a very good idea.
but there are also a number of other things on the agenda:
* get rid of areas
* revisit content repository
* generic editor handlers
* 21st century css for the authoring interface
* even more ajax.

i wonder: should we really be starting a 3.0 at this point?
it seems
weird to spread our (already small) developer base even
thinner...
i think we owe it to our users to invest some more time into
the 2.0
branch (with easy upgradeability - let's not fool ourselves:
a
transition from cocoon 2.1 to 2.2 will *not* be seamless
except for the
most trivial of deployments).




-- 
Jörn Nettingsmeier

"One of my most productive days was throwing away 1000
lines of code."
  - Ken Thompson.

------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribelenya.apache.org
For additional commands, e-mail: dev-helplenya.apache.org

Jörn Nettingsmeier wrote:
> Thorsten Scherler wrote:
>   
>> Hi all,
>>
>> like sounded in the thread around Cocoon 2.2 FOP NG
update we need to
>> look into updating to cocoon 2.2. Further our
famous 1.3 branch that
>> brings some nice ideas should merge with the 2.0.x
branch.
>>
>> Maybe we can take the chance to merge both branch
in an upcoming 3.0.
>> Would it make sense to have a clean cut? 
>>
>> I meaning starting first with a
requirements/architecture document and
>> ten develop the code around it (using as much good
as we have right
>> now). Do you think it would be possible?
>>
>> salu2
>>     
>
>
>
> i wonder: should we really be starting a 3.0 at this
point? it seems
> weird to spread our (already small) developer base even
thinner...
> i think we owe it to our users to invest some more time
into the 2.0
> branch (with easy upgradeability - let's not fool
ourselves: a
> transition from cocoon 2.1 to 2.2 will *not* be
seamless except for the
> most trivial of deployments).
>
>   
I agree. I think with our small developer base we should
hold off on 
starting 3.0. A roadmap for 3.0 and 2.0 should be generated.
Release 
early and release often. I think we're probably close to a
2.0.2 
release, given several performance updates that happened
just after 
2.0.1, plus some of the bug fixes.

------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribelenya.apache.org
For additional commands, e-mail: dev-helplenya.apache.org

ON SAT, 2008-03-15 AT 15:21 -0500, RICHARD FROVARP WROTE:
> JöRN NETTINGSMEIER WROTE:
> > THORSTEN SCHERLER WROTE:
> >   
> >> HI ALL,
...
> >> I MEANING STARTING FIRST WITH A
REQUIREMENTS/ARCHITECTURE DOCUMENT AND
> >> TEN DEVELOP THE CODE AROUND IT (USING AS MUCH
GOOD AS WE HAVE RIGHT
> >> NOW). 
...
> > I WONDER: SHOULD WE REALLY BE STARTING A 3.0 AT
THIS POINT? IT SEEMS
> > WEIRD TO SPREAD OUR (ALREADY SMALL) DEVELOPER BASE
EVEN THINNER...
> > I THINK WE OWE IT TO OUR USERS TO INVEST SOME MORE
TIME INTO THE 2.0
> > BRANCH (WITH EASY UPGRADEABILITY - LET'S NOT FOOL
OURSELVES: A
> > TRANSITION FROM COCOON 2.1 TO 2.2 WILL *NOT* BE
SEAMLESS EXCEPT FOR THE
> > MOST TRIVIAL OF DEPLOYMENTS).

I AGREE THAT IS WHY I WROTE ABOVE TO START WITH
DOCUMENTATION FIRST.
THIS WILL HELP US IN MANY WAYS. 

- FIRST WE WILL ALL KNOW WHAT WE HAVE TO DO AND EVERYBODY
MAY PICK A
TASK AND IMPLEMENT IT.
- SECOND WE WILL ALL KNOW AND HAVE IT DOCUMENTED HOW THE
ARCHITECTURE OF
3.0 WILL LOOK LIKE.
- THIRD WE HAVE A DRAFT TO ASK ON COCOON WHETHER 2.2 WILL
SUPPORT IT AND
WHICH POSSIBLE PITFALLS ARE.

> >
> >   
> I AGREE. I THINK WITH OUR SMALL DEVELOPER BASE WE
SHOULD HOLD OFF ON 
> STARTING 3.0. A ROADMAP FOR 3.0 AND 2.0 SHOULD BE
GENERATED. 

I DO NOT WANT THAT WE START CODING AT ALL ON 3.0 TILL WE
HAVE ABOVE
MENTIONED DOCUMENTS. 2.0 IS OUR STABLE VERSION - REPLACING
1.2 IN THIS
SENSE - AND WE NEED TO KEEP ON DEVELOPING ON IT.

> RELEASE 
> EARLY AND RELEASE OFTEN. I THINK WE'RE PROBABLY CLOSE
TO A 2.0.2 
> RELEASE, GIVEN SEVERAL PERFORMANCE UPDATES THAT
HAPPENED JUST AFTER 
> 2.0.1, PLUS SOME OF THE BUG FIXES.

I TOTALLY AGREE THAT THIS RELEASE HAVE PREFERENCE OVER 3.0,
HOWEVER WE
NEED TO START THINKING ABOUT THE FUTURE. 

IF WE MANAGE TO DEVELOP THE DOCUMENTATION FOR 3.0 BEFORE
WRITING ONE
LINE OF CODE THEN WE CAN GAIN A NEVER KNOWN MOMENTUM.  

SALU2
-- 
THORSTEN SCHERLER                                
THORSTEN.AT.APACHE.ORG
OPEN SOURCE JAVA                      CONSULTING, TRAINING
AND SOLUTIONS


------------------------------------------------------------
---------
TO UNSUBSCRIBE, E-MAIL: DEV-UNSUBSCRIBELENYA.APACHE.ORG
FOR ADDITIONAL COMMANDS, E-MAIL: DEV-HELPLENYA.APACHE.ORG

Thorsten Scherler wrote:
> On Sat, 2008-03-15 at 15:21 -0500, Richard Frovarp
wrote:
>   
>> Jörn Nettingsmeier wrote:
>>     
>>> Thorsten Scherler wrote:
>>>   
>>>       
>>>> Hi all,
>>>>         
> ...
>   
>>>> I meaning starting first with a
requirements/architecture document and
>>>> ten develop the code around it (using as
much good as we have right
>>>> now). 
>>>>         
> ...
>   
>>> i wonder: should we really be starting a 3.0 at
this point? it seems
>>> weird to spread our (already small) developer
base even thinner...
>>> i think we owe it to our users to invest some
more time into the 2.0
>>> branch (with easy upgradeability - let's not
fool ourselves: a
>>> transition from cocoon 2.1 to 2.2 will *not* be
seamless except for the
>>> most trivial of deployments).
>>>       
>
> I agree that is why I wrote above to start with
documentation first.
> This will help us in many ways. 
>
> - First we will all know what we have to do and
everybody may pick a
> task and implement it.
> - Second we will all know and have it documented how
the architecture of
> 3.0 will look like.
> - Third we have a draft to ask on cocoon whether 2.2
will support it and
> which possible pitfalls are.
>
>   
>>>   
>>>       
>> I agree. I think with our small developer base we
should hold off on 
>> starting 3.0. A roadmap for 3.0 and 2.0 should be
generated. 
>>     
>
> I do not want that we start coding at all on 3.0 till
we have above
> mentioned documents. 2.0 is our stable version -
replacing 1.2 in this
> sense - and we need to keep on developing on it.
>
>   
>> Release 
>> early and release often. I think we're probably
close to a 2.0.2 
>> release, given several performance updates that
happened just after 
>> 2.0.1, plus some of the bug fixes.
>>     
>
> I totally agree that this release have preference over
3.0, however we
> need to start thinking about the future. 
>
> If we manage to develop the documentation for 3.0
before writing one
> line of code then we can gain a never known momentum. 

>
> salu2
>   
+1 That all makes sense to me and sounds good.

------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribelenya.apache.org
For additional commands, e-mail: dev-helplenya.apache.org

Andreas Hartmann wrote:

> Jörn Nettingsmeier schrieb:
>
>> * generic editor handlers
>
>
> Unfortunately it looks like the future of this issue is
not too 
> bright. Unless we get Christian Stocker (BXE), Thomas
Comiotto, and 
> maybe the HTML editor folks (TinyMCE, FCKEditor etc.)
to talk to each 
> other, I'm afraid the situation won't change much.

me neither

> Neutron is certainly a nice idea, but it won't succeed
if other editor 
> vendors don't participate in the specification
process.


I think the only way to do this is putting our hands on
these editors

Cheers

Michael

>
>
> -- Andreas
>
>


-- 
Michael Wechner
Wyona      -   Open Source Content Management - Yanel,
Yulup
http://www.wyona.com
michael.wechnerwyona.com, michiapache.org
+41 44 272 91 61


------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribelenya.apache.org
For additional commands, e-mail: dev-helplenya.apache.org

On 3/18/08, Andreas Hartmann <andreasapache.org> wrote:
> Jörn Nettingsmeier schrieb:
> > Thorsten Scherler wrote:
>  >> like sounded in the thread around Cocoon 2.2
FOP NG update we need to
>  >> look into updating to cocoon 2.2. Further our
famous 1.3 branch that
>  >> brings some nice ideas should merge with the
2.0.x branch.
>  >>
>  >> Maybe we can take the chance to merge both
branch in an upcoming 3.0.
>  >> Would it make sense to have a clean cut?
>  >>
>  >> I meaning starting first with a
requirements/architecture document and
>  >> ten develop the code around it (using as much
good as we have right
>  >> now). Do you think it would be possible?

Everybody seems to agree that starting with a specification
is good.
Please tell me about any desired functions that are not in
Lenya-1.3
or on its ToDo list.

> Yes, the closer we stay to Cocoon, the better.
>  IMO we don't emphasize the connection to Cocoon
enough:
>  - "Based on Cocoon" is very good marketing.
>  - Cocoon users are potential Lenya users.
>  - If your customer uses Lenya, you can sell
Cocoon-based add-ons.
>  - Staying up-to-date with Cocoon allows to use their
latest goodies.

I agree that capturing the Cocoon market would be good.  I
am not
certain about moving to Cocoon-2.2 or later. Cocoon-2.2
expects Maven.
 This is good for developing with ever-changing
dependencies.  This is
not good when trying to maintain stable business
applications.  The
Cocoon devs seem excited about losing functionality.  One
faction
wants to migrate to Spring, which cannot handle much of the
dynamic
decisions Lenya uses everywhere.  Another faction is
creating a
mini-Cocoon that removes most of the good functions Lenya
uses.  A
near-future release of Cocoon may require a completely
rewritten and
more complex Lenya because backwards-compatibility does not
seem to be
a priority.  More important, the Cocoon market will likely
shrink when
current users realize their current applications will not
work on the
future releases.

After Lenya-1.3, I might work on Cocoon-2.1.  My top three
improvements are:
- Aggregators using Generators so <map:part
type="x"> would work
without creating extra pipelines.  (This one is so obvious
that I
cannot believe the first Aggregator was not implemented this
way.)
- Selectors work inside Generators, Transformers, and
Seriaizers to
reduce code duplication.  (This may have been lost when the
two-phase
processing was implemented.)
- MatchSelector and RegexpSelector could replace most
current Matchers
and Selectors, increasing functionality while decreasing
learning
time.  (General functions are always better than specific
functions.
Cocoon-2.1.11 includes a specialized RegexpSelectors for
request
parameters and headers without including the easier general
case.)
These three patches could eliminate half the code developed
for Cocoon.
.
A Lenya based on a easier-to-learn-and-use and
easy-for-upgrades
Cocoon-2.1 might capture the audience of people frustrated
by the
Cocoon project's current direction.

>  > but there are also a number of other things on
the agenda:
>  > * get rid of areas
> That would be nice, especially since it could simplify
the codebase, but
>  from my POV the other issues have a higher priority.

Areas were removed from Lenya-1.3.  The first code written
was a
simple patch to 1.2 to use the Area portion of the URL for
Modules as
standardized Usecases without the querystring syntax.  When
Lenya-1.3
became a real goal, I discovered this Module system removed
the need
for XMAPs in the publication directory.  Adding file-based
inheritance
made most Modules extremely simple since the Resource root
types (xml,
file, link, text) contain most of the code needed by most
Modules.
This also allows function-based (rather than file-type) file
organization (e.g. homepage/page2xhtml.xsl rather than
xslt/page2xhtml-homepage.xsl, and no file if inheriting from
a parent
Module rather than a file containing only an import
statement.)

>  > * revisit content repository
>  Very important point. People keep asking why we don't
support JCR.
>  Jackrabbit has arrived at release 1.4, I have the
feeling that the
>  integration would now be much more painless than two
years ago. Of
>  course we should also consider other options, but I
have the feeling
>  that JCR support would give us a big marketing
advantage.

Lenya-1.3 prefers a flat datastore.  Lenya-1.2's
hierarchical
datastore still works in Lenya1.3, but mostly uses code from
Lenya-1.2.  The Content interface is used by both
datastores.  A JCR
implementation should be easy, but is very low on my
priority list;
maybe next year's SOC project?

>  > * generic editor handlers
>  Unfortunately it looks like the future of this issue
is not too bright.
>  Unless we get Christian Stocker (BXE), Thomas
Comiotto, and maybe the
>  HTML editor folks (TinyMCE, FCKEditor etc.) to talk to
each other, I'm
>  afraid the situation won't change much. Neutron is
certainly a nice
>  idea, but it won't succeed if other editor vendors
don't participate in
>  the specification process.

Lenya-1.3 does not use the FCKEditor (which I used for a
project last
year) because FCKEditor wants to send the entire XHTML page.
 My
specification for Lenya-1.3's editor was it had to play nice
with
other fields and be able to run multiple instances on one
page.
FCKEditor does not meet those specifications.

(I thought we had licensing issues with FCKEditor.  I lost a
day
trying to compile Cocoon because jcr-1.0.jar and many other
libraries
are missing.  If some code does not fit the Apache license,
do not use
it.  Everything should work out-of-the-box, including the
source
version.)

I was amazed at the amount of code needed to integrate Kupu
into
Lenya-1.2.  Kupu requires storing part of a document being
edited on
the server.  I tried using Kupu with Lenya-1.3 by creating
Virtual
resources (the Virtual classes are still in svn), but really
disliked
the algorithm. (When should the server discard abandoned
continuations? after one hour? tomorrow? next week?)

Lenya-1.3 is currenly using Xinha (derived from HTMLArea
that I used
many years ago) because multiple rich-text areas could be
edited on
one page with no temporary data on the server, and because
the code
and configuration looked easy to understand.  I already
fixed some
bugs and integrated for basic XHTML editing.  Full
integration with
choosing links, images, and other Resources is my third
priority
(after the Relations Structure Editor and security).

TinyMCE looks similar to Xinha.  We can create a Lenya-1.3
Module for
it.  Only 6 lines of code in the "xml" Module
enable Xinha so changing
the editor to something similar should be easy.  Should the
editor be
configurable in the publication?  Probably start with a
querystring
parameter to keep it simple.

Any editor for Lenya should allow multiple rich-text fields
to coexist
with other fields.  That allows Lenya to be used for most
business
applications.  Without that specification, Lenya is just a
complicated
datastore with some security.

solprovider

solproviderapache.org wrote:

>On 3/18/08, Andreas Hartmann <andreasapache.org> wrote:
>  
>
>>Jörn Nettingsmeier schrieb:
>>    
>>
>>>Thorsten Scherler wrote:
>>>      
>>>
>> >> like sounded in the thread around Cocoon
2.2 FOP NG update we need to
>> >> look into updating to cocoon 2.2. Further
our famous 1.3 branch that
>> >> brings some nice ideas should merge with
the 2.0.x branch.
>> >>
>> >> Maybe we can take the chance to merge both
branch in an upcoming 3.0.
>> >> Would it make sense to have a clean cut?
>> >>
>> >> I meaning starting first with a
requirements/architecture document and
>> >> ten develop the code around it (using as
much good as we have right
>> >> now). Do you think it would be possible?
>>    
>>
>
>Everybody seems to agree that starting with a
specification is good.
>Please tell me about any desired functions that are not
in Lenya-1.3
>or on its ToDo list.
>  
>

I think it would be good to have some documentation on lenya
1.3 in 
order to compare more easily.
Also is the todo list for Lenya 1.3 publicly available?

Cheers

Michael


-- 
Michael Wechner
Wyona      -   Open Source Content Management - Yanel,
Yulup
http://www.wyona.com
michael.wechnerwyona.com, michiapache.org
+41 44 272 91 61


------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribelenya.apache.org
For additional commands, e-mail: dev-helplenya.apache.org