On 3/19/08, Thorsten Scherler <[EMAIL PROTECTED]> wrote: > On Wed, 2008-03-19 at 05:38 -0400, [EMAIL PROTECTED] wrote: > > On 3/18/08, Andreas Hartmann <[EMAIL PROTECTED]> 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/revolution/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-children-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
