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. 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
