Should we start 3.0?

ON WED, 2008-03-19 AT 05:38 -0400, 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.

HMM, LIKE I STATED IN THE FIRST MAIL, 3.0 SHOULD MERGE BOTH
WORLDS. THE
DOCUMENTATION SHOULD BE INDEPENDENT FROM EITHER VERSION. THE
DOCUMENT
SHOULD CONTAIN ALL DESIRED FUNCTIONS IT SHOULD NOT MATTER
WHICH VERSION
OF LENYA IS INCORPORATING IT ALREADY OR NOT.

FURTHER FOR ME THAT HAVE NEVER WORKED WITH 1.3 IT IS HARD TO
EVALUATE
THE FUNCTIONALITY. LIKE MICHI STATED WE WOULD NEED SOME
DOCUMENTATION
ABOUT IT TO EVALUATE IT.

> 
> > 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.

WELL, NO. TO BUILD COCOON FROM SCRATCH IT HELPS TO HAVE
MAVEN, BUT THERE
IS TALK TO HAVE AN ANT BUILD VERSION AS WELL. FURTHER IN THE
FUTURE WE
SHOULD USE THE BUILDED COCOON JARS AND DROP THE SVN:EXTERNAL
TO COCOON.

>  THIS IS GOOD FOR DEVELOPING WITH EVER-CHANGING
DEPENDENCIES.  THIS IS
> NOT GOOD WHEN TRYING TO MAINTAIN STABLE BUSINESS
APPLICATIONS.  

HMM, THE USAGE OF MAVEN SHOULD NOT BE OF ANY CONCERN IN THIS
COMMUNITY.

> 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.  

HMM, CAN YOU GIVE AN EXAMPLE? SPRING REPLACES AVALON AS
UNDERLYING IOC
CONTAINER BUT THAT HAS LITTLE INFLUENCE ON FUNCTIONALITY OF
COCOON.

> 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.

HMM, THAT IS NOT TRUE! THERE ARE SOME FUNCTIONS (PASS-TROUGH
MOUNTS OF
SITEMAP -> RARELY USED) THAT ARE NOT ANYMORE BUT EXPECT
THAT 99% OF ALL
COCOON 2.1. APPS WILL WORK IN 2.2!

> 
> 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.

HMM, I AM NOT REALLY SURE WHETHER YOUR ONE MAN SHOW APPROACH
IS
BENEFICENTLY NEITHER FOR YOURSELF NOR FOR COCOON/LENYA. THE
ABOVE
CHANGES HAVE BEEN REJECTED FROM THE COCOON COMMUNITY AND
THEY EXPLAINED
YOU WHY THEY ARE NOT PRACTICAL (MAINLY BECAUSE THEY VIOLATE
EXISTING
CONTRACTS).

> .
> 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.

DO YOU REALLY THINK A ONE-MAN-LENYA/COCOON IMPLEMENTATION
WILL CAPTURE
ANY AUDIENCE? THE MOST IMPORTANT THINK HERE ON APACHE ARE
THE
COMMUNITIES NOT THE CODE!

FURTHER I AM NOT SURE WHETHER IT IS NOT YOU THAT IS
FRUSTRATED BY THE
COCOON DIRECTION. AT LEAST THAT IS THE IMPRESSION I GOT
READING YOUR
MAIL ON THE COCOON MAILING LISTS.

DO NOT GET ME WRONG, I DO NOT WANT TO STEP ON YOUR TOES. YOU
NEED TO
UNDERSTAND THAT YOU ARE PART OF A COMMUNITY AND THE
COMMUNITY MAKES
DECISION THAT ARE BINDING FOR THEM. DOING FORKS OF CODE IS
NOT HELPING
TO BUILD A COMMUNITY WHICH TRIES TO SOLVE A COMMON PROBLEM,
IT DOES THE
OPPOSITE.

THAT REMINDS ME ON AN OLD MAIL FOOTER OF MINE:
"TOGETHER WE STAND,
DIVIDED WE FALL. - PINK FLOYD"

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/19/08, Michael Wechner <michael.wechnerwyona.com> wrote:
> 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

See the files starting with "13" at:
http://svn.apache.org/viewvc/lenya/branches/revolut
ion/1.3.x/

Hint: The Todo list is named 13TODO.txt.  You might start
with
13ABOUT.txt and 13HELP.txt.

solprovider

On 3/19/08, Thorsten Scherler <thorsten.scherler.extjuntadeandalucia.es> wrote:
> On Wed, 2008-03-19 at 05:38 -0400, 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.
> Hmm, like I stated in the first mail, 3.0 should merge
both worlds. The
>  documentation should be INDEPENDENT from either
version. The document
>  should contain all desired functions it should not
matter which version
>  of lenya is incorporating it already or not.

My suggestions for 3.0 are obvious -- they look like
Lenya-1.3.  I was
asking what I missed that is important to other devs (e.g.
categories
in navigation menus is something I had not planned. I added
at least
six ToDo entries while responding to other posts this
evening.)  We
are discussing specifications, not deciding which codebase
should be
used or whether we should start from scratch.

>  Further for me that have never worked with 1.3 it is
hard to evaluate
>  the functionality. Like Michi stated we would need
some documentation
>  about it to evaluate it.

http://svn.apache.org/viewvc/lenya/branches/revolut
ion/1.3.x/

>  > > 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.
> Well, no. To build cocoon from scratch it helps to have
maven, but there
>  is talk to have an ant build version as well. Further
in the future we
>  should use the builded cocoon jars and drop the
svn:external to cocoon.

Sounds good.

>  >  This is good for developing with ever-changing
dependencies.  This is
>  > not good when trying to maintain stable business
applications.
> Hmm, the usage of maven should not be of any concern in
this community.

Good.

>  > 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.
> Hmm, can you give an example? Spring replaces Avalon as
underlying IoC
>  container but that has little influence on
functionality of cocoon.

http://www.nabble.com/PipelineEvents-eat-childr
en-td15580888.html
I have not used Spring yet.  The first response states:
"Spring does not provide any conditionals in their
configuration
files. Instead they provide dynamic evaluation of property
placeholders though - just like our input modules."

This suggests the replacement for InputModules would handle
dynamic
decisions.  If true, that would move many branches from
easily
accessible XMAPs to Java programmed-and-compiled whatevers. 
Please
tell me this is not true.

>  > 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.
> Hmm, that is not true! There are some functions
(pass-through mounts of
>  sitemap -> rarely used) that are not anymore but
expect that 99% of all
>  cocoon 2.1 apps will work in 2.2!

Lenya-1.3 Modules use map:mount everywhere.  I think all
XMAPs have a
default match so pass-through might not be an issue.

>  > 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.
> Hmm, I am not really sure whether your one man show
approach is
>  beneficently neither for yourself nor for
cocoon/lenya. The above
>  changes have been rejected from the cocoon community
and they explained
>  you why they are not practical (mainly because they
violate existing
>  contracts).

The "one man show approach" developed from the
responses to my
suggestions.  My original suggestions here were ignored. 
When I
started implementing my ideas (to test of my mental
abilities after a
car accident) and mentioned solutions based on the
experience gained,
we created the Lenya-1.3 branch that nobody has seen.  My
suggestions
on the Cocoon MLs are being actively rejected, which would
be nice if
I had a personality type able to appreciate negative
attention.

None of those suggestions for Cocoon-2.1 would violate
existing contracts.
- Aggregation would default to the current behavior.  New
functionality is only gained if the "type"
attribute is used.  No
current code should be using a useless attribute.
- Same with Selectors working inside PipelineEvents.  No
current XMAPs
should be using a structure that does not work.
- Two new Selectors affect nothing as they could not have
been
configured since they do not exist.

I did not accept membership in this community because I
wanted to
develop software alone.  I have other projects where I am
the sole
authority.  Few of my suggestions here have been used.  The
Search
function was integrated before I became a Committer. 
Improving
lenya.sh for all versions was my other triumph.  I committed
what I
thought were two minor changes to Cocoon after the JIRA were
ignored
for 6 months.  One went unnoticed.  The other got me
chastised, was
reverted, and was finally implemented by Carsten (with
incredibly
concise code that solved several other issues!)  Am I doing
something
wrong?  What am I missing?

>  > 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.
> Do you really think a one-man-lenya/cocoon
implementation will capture
>  any audience? The most important think here on apache
are the
>  communities NOT the code!

No, I do not expect solo versions to capture any audience. 
Lenya-1.3
is a priority because a client needs to upgrade from
Lenya-1.2; I
doubt anybody has checked it out.  The Cocoon-2.1
improvements might
be allowed into the branch once the devs are focused on
Cocoon-2.2+.
The important part (for me) is making development easier for
the
community.  Does a Cocoon developer exist that did not try
<map:part
type="x">?

>  Further I am not sure whether it is not you that is
frustrated by the
>  cocoon direction. At least that is the impression I
got reading your
>  mail on the cocoon mailing lists.
Frustrated by their responses to my suggestions: no
discussion, just
rejection.  Not frustrated by their direction.  Not affected
by their
direction until a client wants to use a future release, and
then I
will learn it like any new program.  Still helping others on
several
ASF MLs, including Cocoon's.

>  Do not get me wrong, I do not want to step on your
toes. You need to
>  understand that you are part of a community and the
community makes
>  decision that are binding for them. Doing forks of
code is not helping
>  to build a community which tries to solve a common
problem, it does the
>  opposite.

The fork branch was not my idea.  The community demanded the
code.  I
still commit changes with the hope that demonstrating my
suggestions
might influence our project.

>  That reminds me on an old mail footer of mine:
"Together we stand,
>  divided we fall. - Pink Floyd"
>  salu2
>  Thorsten Scherler                                
thorsten.at.apache.org

So where should I stand?
solprovider

On Wed, 2008-03-19 at 08:23 -0400, solproviderapache.org wrote:
> On 3/19/08, Thorsten Scherler
<thorsten.scherler.extjuntadeandalucia.es>
wrote:
...
> > Hmm, like I stated in the first mail, 3.0 should
merge both worlds. The
> >  documentation should be INDEPENDENT from either
version. The document
> >  should contain all desired functions it should
not matter which version
> >  of lenya is incorporating it already or not.
> 
> My suggestions for 3.0 are obvious -- they look like
Lenya-1.3.  

That sounds a wee bit like 1.3 is the best there is. What
would you say
if some other dev says: hey look into 2.0 and see what there
is
missing. 

> I was
> asking what I missed that is important to other devs
(e.g. categories
> in navigation menus is something I had not planned. I
added at least
> six ToDo entries while responding to other posts this
evening.)  We
> are discussing specifications, not deciding which
codebase should be
> used or whether we should start from scratch.

You correctly point out that we should discuss
specifications and not
feature list. That I why I do not like to point to a certain
branch as
discussion basic.
...
> >  > 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.
> > Hmm, can you give an example? Spring replaces
Avalon as underlying IoC
> >  container but that has little influence on
functionality of cocoon.
> 
> http://www.nabble.com/PipelineEvents-eat-childr
en-td15580888.html

The link is a thread where you discuss to introduce a new
concept of
configuring  pipeline. It is not Spring specific.

> I have not used Spring yet.  The first response
states:
> "Spring does not provide any conditionals in their
configuration
> files. Instead they provide dynamic evaluation of
property
> placeholders though - just like our input
modules."
> 
> This suggests the replacement for InputModules would
handle dynamic
> decisions.  If true, that would move many branches from
easily
> accessible XMAPs to Java programmed-and-compiled
whatevers.  Please
> tell me this is not true.

Actually that have been discussed on cocoon dev. Jörg,
Carsten and
others had been trying to explain it to you why the
suggestion has some
flaws. I do not think we need to discuss it here.

...
> > Hmm, that is not true! There are some functions
(pass-through mounts of
> >  sitemap -> rarely used) that are not anymore
but expect that 99% of all
> >  cocoon 2.1 apps will work in 2.2!
> 
> Lenya-1.3 Modules use map:mount everywhere. 

map mount is no problem. See
http://svn.apache.org/viewvc/forr
est/trunk/main/webapp/sitemap.xmap?view=markup
and search for pass-through="true".
...
> > Hmm, I am not really sure whether your one man
show approach is
> >  beneficently neither for yourself nor for
cocoon/lenya. The above
> >  changes have been rejected from the cocoon
community and they explained
> >  you why they are not practical (mainly because
they violate existing
> >  contracts).
> 
> The "one man show approach" developed from
the responses to my
> suggestions.  My original suggestions here were
ignored.  When I
> started implementing my ideas (to test of my mental
abilities after a
> car accident) and mentioned solutions based on the
experience gained,
> we created the Lenya-1.3 branch that nobody has seen. 
My suggestions
> on the Cocoon MLs are being actively rejected, which
would be nice if
> I had a personality type able to appreciate negative
attention.

Or maybe you sometimes do not want to listen to others?
Sometimes it
takes time and work to convince the community about new
ideas. To reach
consensus about this suggestion is the important factor.
Sometimes one
has to swallow its ego to reach a consensus for the benefit
of the
community.

...and believe me it is a challenge for me as well, since I
tend to have
a strong personality.

> 
> None of those suggestions for Cocoon-2.1 would violate
existing contracts.
> ...

See the thread you linked above.

> I did not accept membership in this community because I
wanted to
> develop software alone.  I have other projects where I
am the sole
> authority.  Few of my suggestions here have been used. 
The Search
> function was integrated before I became a Committer. 
Improving
> lenya.sh for all versions was my other triumph.  I
committed what I
> thought were two minor changes to Cocoon after the JIRA
were ignored
> for 6 months.  One went unnoticed.  The other got me
chastised, was
> reverted, and was finally implemented by Carsten (with
incredibly
> concise code that solved several other issues!)  Am I
doing something
> wrong?  What am I missing?

AFAIR that have been the ant copy target where filtering
needs to be
turned of for some resources. Most of the time the
experience of people
like Carsten are more general then a specific use case.
Sometimes a
special use case needs to solved differently for the wider
good of the
broader usage of the code.

> 
> >  > 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.
> > Do you really think a one-man-lenya/cocoon
implementation will capture
> >  any audience? The most important think here on
apache are the
> >  communities NOT the code!
> 
> No, I do not expect solo versions to capture any
audience.  Lenya-1.3
> is a priority because a client needs to upgrade from
Lenya-1.2; I
> doubt anybody has checked it out.  The Cocoon-2.1
improvements might
> be allowed into the branch once the devs are focused on
Cocoon-2.2+.
> The important part (for me) is making development
easier for the
> community.  

That is very good but you need to become part of the
community otherwise
it always will be your special use case.

> Does a Cocoon developer exist that did not try
<map:part
> type="x">?

I do not know what you are referring to with the type but
no I have not
tried because there never have been the need for it.

> 
> >  Further I am not sure whether it is not you that
is frustrated by the
> >  cocoon direction. At least that is the impression
I got reading your
> >  mail on the cocoon mailing lists.
> Frustrated by their responses to my suggestions: no
discussion, just
> rejection.  

Well that is not really true they had been trying to explain
they
rejection.

> Not frustrated by their direction.  Not affected by
their
> direction until a client wants to use a future release,
and then I
> will learn it like any new program.  Still helping
others on several
> ASF MLs, including Cocoon's.

I know and that is fantastic. I wish in terms of development
it would be
the same.

> 
> >  Do not get me wrong, I do not want to step on
your toes. You need to
> >  understand that you are part of a community and
the community makes
> >  decision that are binding for them. Doing forks
of code is not helping
> >  to build a community which tries to solve a
common problem, it does the
> >  opposite.
> 
> The fork branch was not my idea.  The community
demanded the code.  I
> still commit changes with the hope that demonstrating
my suggestions
> might influence our project.

I know and I am glad you donated this code. I only try to
get your good
ideas into a new version which is supported by the community
as whole.

> 
> >  That reminds me on an old mail footer of mine:
"Together we stand,
> >  divided we fall. - Pink Floyd"
> >  salu2
> >  Thorsten Scherler                                
thorsten.at.apache.org
> 
> So where should I stand?

hehe, with us. ;)

No seriously, I wish that you could help us and cooperate
more on the
main stream version. 

Thanks Paul for your work and patience, let us try to get
the goodies
from 1.3 into a wider use range.

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/19/08, Thorsten Scherler <thorstenapache.org> wrote:
> On Wed, 2008-03-19 at 08:23 -0400, solproviderapache.org wrote:
>  > On 3/19/08, Thorsten Scherler
<thorsten.scherler.extjuntadeandalucia.es>
wrote:
> > > Hmm, like I stated in the first mail, 3.0
should merge both worlds. The
>  > >  documentation should be INDEPENDENT from
either version. The document
>  > >  should contain all desired functions it
should not matter which version
>  > >  of Lenya is incorporating it already or
not.
>  > My suggestions for 3.0 are obvious -- they look
like Lenya-1.3.
> That sounds a wee bit like 1.3 is the best there is.
What would you say
>  if some other dev says: hey look into 2.0 and see what
there is
>  missing.

I have read the docs about 2.0 and posted a feature
comparison in
another thread.  A completed Lenya-1.3 may be best for some
people;
the goal of this thread is to design a Lenya that is best
for
everybody.

>  > I was
>  > asking what I missed that is important to other
devs (e.g. categories
>  > in navigation menus is something I had not
planned. I added at least
>  > six ToDo entries while responding to other posts
this evening.)  We
>  > are discussing specifications, not deciding which
codebase should be
>  > used or whether we should start from scratch.
> You correctly point out that we should discuss
specifications and not
>  feature list. That I why I do not like to point to a
certain branch as
>  discussion basic.

My suggestions are documented in the text files that happen
to be
stored in that branch. Nobody needs to run or download the
code to
read the suggestions; they are available on the Web.  Almost
all of
the suggestions have been mentioned on the MLs; the others
are likely
to be specific to the implementation of Lenya-1.3.

>  > http://www.nabble.com/PipelineEvents-eat-childr
en-td15580888.html
> The link is a thread where you discuss to introduce a
new concept of
>  configuring pipeline. It is not Spring specific.
Sorry.  That post created my impression of Spring.

>  > This suggests the replacement for InputModules
would handle dynamic
>  > decisions.  If true, that would move many
branches from easily
>  > accessible XMAPs to Java programmed-and-compiled
whatevers.  Please
>  > tell me this is not true.
> Actually that have been discussed on cocoon dev. Jörg,
Carsten and
>  others had been trying to explain it to you why the
suggestion has some
>  flaws. I do not think we need to discuss it here.
>  > Frustrated by [Cocoon devs'] responses to my
suggestions: no discussion, just
>  > rejection.
> Well that is not really true they had been trying to
explain the
> rejection.
Did I miss the discussion of the benefits?  The reasons
given were,
"This is how it has been for 8 years" and
"Changing might be
difficult."  Nobody discussed the benefits of the
suggestion. We agree
this topic does not belong on this ML.

> map mount is no problem. See
>  http://svn.apache.org/viewvc/forr
est/trunk/main/webapp/sitemap.xmap?view=markup
>  and search for pass-through="true".
Good.

> > > Hmm, I am not really sure whether your one
man show approach is
>  > >  beneficently neither for yourself nor for
cocoon/lenya. The above
>  > >  changes have been rejected from the cocoon
community and they explained
>  > >  you why they are not practical (mainly
because they violate existing
>  > >  contracts).
>  > The "one man show approach" developed
from the responses to my
>  > suggestions.  My original suggestions here were
ignored.  When I
>  > started implementing my ideas (to test of my
mental abilities after a
>  > car accident) and mentioned solutions based on
the experience gained,
>  > we created the Lenya-1.3 branch that nobody has
seen.  My suggestions
>  > on the Cocoon MLs are being actively rejected,
which would be nice if
>  > I had a personality type able to appreciate
negative attention.
> Or maybe you sometimes do not want to listen to others?
Sometimes it
>  takes time and work to convince the community about
new ideas. To reach
>  consensus about this suggestion is the important
factor. Sometimes one
>  has to swallow its ego to reach a consensus for the
benefit of the
>  community.
>  ...and believe me it is a challenge for me as well,
since I tend to have
>  a strong personality.
I usually collaborate.  One of my programmers complained
that I always
spoke last and we almost always used my ideas so why didn't
I speak
first?  My answer was "my" ideas combined the best
of everybody's
suggestions and did not exist until everybody contributed. 
One
developer was shy; a complaint was that I always asked him
to speak.
This happened immediately after a meeting where the shy
developer
explained a major problem with our plans that would have
required
months of rework to solve if not caught then.

I have read every post on both Lenya MLs for years.  The
specifications for Lenya-1.3 were developed by combining the
thoughts
of the community.  Others first presented many of the good
ideas; my
contribution was to collect them and implement a solution. 
Even
recent threads added entries to the ToDo list; the diff
after my next
commit will contain several entries easily recognizable as
having
originated here.

>  > I do not expect solo versions to capture any
audience.  Lenya-1.3
>  > is a priority because a client needs to upgrade
from Lenya-1.2; I
>  > doubt anybody has checked it out.  The Cocoon-2.1
improvements might
>  > be allowed into the branch once the devs are
focused on Cocoon-2.2+.
>  > The important part (for me) is making development
easier for the
>  > community.
> That is very good but you need to become part of the
community otherwise
>  it always will be your special use case.
That is what this thread is about.

>  > Does a Cocoon developer exist that did not try
<map:part
>  > type="x">?
> I do not know what you are referring to with the type but
no I have not
>  tried because there never have been the need for it.
Lenya-1.2 includes the workaround for <map:part
type="serverpages"> in
scheduler.xmap and usecase-kupu.xmap.  blog/sitemap.xmap
contains the
pattern, but would also need the Selectors-in-PipelineEvents
to fix.
admin.xmap would look very different if developed with these
abilities
available.

>  > Still helping others on several ASF MLs,
including Cocoon's.
> I know and that is fantastic. I wish in terms of
development it would be
>  the same.
I believe some of my development suggestions were recently
implemented
by other devs.  At least the discussions were about
technical merits.

>  > The fork branch was not my idea.  The community
demanded the code.  I
>  > still commit changes with the hope that
demonstrating my suggestions
>  > might influence our project.
> I know and I am glad you donated this code. I only try
to get your good
>  ideas into a new version that is supported by the
community as whole.

So let's get this thread back to discussing specifications.

>  > >  That reminds me on an old mail footer of
mine: "Together we stand,
>  > >  divided we fall. - Pink Floyd"
>  > So where should I stand?
> hehe, with us. ;)
>
>  No seriously, I wish that you could help us and
cooperate more on the
>  mainstream version.

My current setup includes a checkout of trunk (although I
have yet to
attempt compilation.)  Lenya-1.3 uses 2.x's UUID
implementation
(reformatted to 11 LOC in Globals.)  I read all ML posts
concerning
2.x and knew the code existed.  I could assist with trunk if
I knew
what problems needed to be solved.  Most of the dev
discussions are
about issues that others are already handling.

>  Thanks Paul for your work and patience, let us try to
get the goodies
>  from 1.3 into a wider use range.
>  Thorsten Scherler                                
thorsten.at.apache.org

I had not expected to remain the only developer of Lenya-1.3
after the
original code was committed to svn.  The ToDo list is
updated
frequently so others would understand where to contribute.

Someone recently commented that removing Areas was
difficult.  I found
a hidden 8-page section from early 2006 on my website
describing how
and why to implement this as a patch for Lenya-1.2.  The
pages were
not published to prevent forking the project. Then the
Lenya-1.3
branch was created, and the code was easier to retrieve from
svn.
Lenya-1.3's Module system is used by all publications so the
benefits
have been available without migrating from Lenya-1.2's
hierarchical
content.  I always test 1.2 functionality before committing
so
unmigrated Lenya-1.2 publications always work.

I want to show the Structure Editor to everybody because I
think it is
cool.  Should be committed tonight.  Could be modified to
edit
Sitetrees in any version of Lenya.  Suggestions for
implementing an
easy interface distinguishing between Move and Copy actions
would be
very welcome.

Can the devs consider 1.3 less as a fork and more as a
demonstration
of possibilities?

solprovider

>
>> * 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.
>

Maybe we can improve Lenya first by introducing a clean API
for web  
based remote i/o and then see if editor vendors are willing
to  
implement that? I guess they will. That's probably better
that to  
wait for some independent group to come up with a generic
API that  
might fit our needs.

I'd be willing to join such an effort.

Thomas


> -- Andreas
>
>
> -- 
> Andreas Hartmann, CTO
> BeCompany GmbH
> http://www.becompany.ch
> Tel.: +41 (0) 43 818 57 01
>
>
>
------------------------------------------------------------
---------
> To unsubscribe, e-mail: dev-unsubscribelenya.apache.org
> For additional commands, e-mail: dev-helplenya.apache.org
>

------------------------------------------------------------
------------ 
-----
                         Thomas Comiotto              
thomas.comiottoid.uzh.ch

                         Universitaet Zuerich
                         Informatikdienste               
Tel: +41 44  
63 54541
                         Winterthurerstrasse 190            
  +41 44  
63 43333
                         CH-8057 Zuerich                 
Fax: +41 44  
63 54505





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