On 3/19/08, Thorsten Scherler <[EMAIL PROTECTED]> wrote: > 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 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-children-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/forrest/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
