On Wed, 2008-03-19 at 08:23 -0400, [EMAIL PROTECTED] wrote: > On 3/19/08, Thorsten Scherler <[EMAIL PROTECTED]> 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-children-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/forrest/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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
