Re: [RT] The next shiny thing?
Il giorno 06/dic/05, alle ore 01:24, David Crossley ha scritto: I started to draft here what the next-generation Cocoon should be. I dubbed it Racoon (with Andrew's permission) as I really think that from a marketing point of view, a new name should be used so that people don't see it as a publication engine, as too many people still see Cocoon. Please don't. Cocoon is the name. I agree that we must keep the Cocoon name, but even if we decide to change it in the end, please not Racoon. From a marketing standpoint, it will always be interpreted as meaning almost like Rails, but not the real thing. Ugo -- Ugo Cei Tech Blog: http://agylen.com/ Open Source Zone: http://oszone.org/ Wine Food Blog: http://www.divinocibo.it/
Re: [RT] The next shiny thing?
Ugo Cei wrote: Il giorno 06/dic/05, alle ore 01:24, David Crossley ha scritto: I started to draft here what the next-generation Cocoon should be. I dubbed it Racoon (with Andrew's permission) as I really think that from a marketing point of view, a new name should be used so that people don't see it as a publication engine, as too many people still see Cocoon. Please don't. Cocoon is the name. I agree that we must keep the Cocoon name, but even if we decide to change it in the end, please not Racoon. From a marketing standpoint, it will always be interpreted as meaning almost like Rails, but not the real thing. Il like this friendly animal and the rhyme with Cocoon. Now there's also Baboon :-) Have a look at http://www.rhymezone.com/r/rhyme.cgi?Word=cocoontypeofrhyme=perfectorg1=sylorg2=l Sylvain -- Sylvain WallezAnyware Technologies http://bluxte.net http://www.anyware-tech.com Apache Software Foundation Member Research Technology Director
Re: [RT] The next shiny thing?
Il giorno 06/dic/05, alle ore 10:01, Sylvain Wallez ha scritto: Il like this friendly animal and the rhyme with Cocoon. Now there's also Baboon :-) Have a look at http://www.rhymezone.com/r/rhyme.cgi? Word=cocoontypeofrhyme=perfectorg1=sylorg2=l I also see Too soon on that list, which might be descriptive of the feelings of some people on this list ;). Sorry, couldn't resist. Ugo -- Ugo Cei Tech Blog: http://agylen.com/ Open Source Zone: http://oszone.org/ Wine Food Blog: http://www.divinocibo.it/
Re: [RT] The next shiny thing?
Le 6 déc. 05, à 10:12, Ugo Cei a écrit : ...I also see Too soon on that list, which might be descriptive of the feelings of some people on this list ;). It might be too soon to choose a name for something which doesn't exist yet...but choosing a code name helps clarifying what we're talking about. So Racoon (or whatever name) could be the code name, it doesn't mean this would ever by shipped under that name. -Bertrand smime.p7s Description: S/MIME cryptographic signature
RE: [RT] The next shiny thing?
No, the brand is not strong. Look around among people that have *not* used Cocoon and ask them what it is. Most of them will tell you it's a publishing engine, or even it's a tool to perform XSL transformations. What we have now and what we're building is much more than that, and IMO we won't be able to deliver this message with a name that has been associated for 6 years to just a publication engine, even if that just is already a lot. Struts has Shale which is a complete rewrite that learns from the past and looks into the future. I really think we should to the same. We're talking a new start, aiming at building a simple, clean and consistent platform. That deserves more than in a major revision number of a name that denotes something else in most people's mind. I strongly disagree with this. And while I agree to most of the points being discussed, I can't help but feel that is is a step too far. And I also think the current discussion is missing something significant (when compared to the first Cocoon steps). While only being able to quickly read through all the discussions - if the best way is really for a clean start: Where is the vision? Matthew
Re: [RT] The next shiny thing?
To me: * throwing away the collected work of the community * building something rather different * throwing away a strong brand * leave all the users who has put a trust in us behind seem like a rather strange way of saving Cocoon. I will continue to be proud of our brand, our product and our community. And I will continue the work on *Cocoon* towards the future in an evolutionary way, so that those who have put their trust in us have a reasonable migration path to follow. IMO the most important step towards getting an uppwards spiral again is by regaining our and our communities faith in Cocoon, by keeping our promisses and do a 2.2 release. Instead of running like lemmlings towards the next shiny thing. We should focus on our core offerning and getting the parts of it reusable outside Cocoon and of high quality, following the path outlined by Marc. For you attention seekers out there, OSGi based blocks will draw a lot of attention towards Cocoon, and it is innovation, not immitation. /Daniel Ugo Cei wrote: Il giorno 06/dic/05, alle ore 01:24, David Crossley ha scritto: I started to draft here what the next-generation Cocoon should be. I dubbed it Racoon (with Andrew's permission) as I really think that from a marketing point of view, a new name should be used so that people don't see it as a publication engine, as too many people still see Cocoon. Please don't. Cocoon is the name. I agree that we must keep the Cocoon name, but even if we decide to change it in the end, please not Racoon. From a marketing standpoint, it will always be interpreted as meaning almost like Rails, but not the real thing.
Re: [RT] The next shiny thing?
Matthew Langham wrote: No, the brand is not strong. Look around among people that have *not* used Cocoon and ask them what it is. Most of them will tell you it's a publishing engine, or even it's a tool to perform XSL transformations. What we have now and what we're building is much more than that, and IMO we won't be able to deliver this message with a name that has been associated for 6 years to just a publication engine, even if that just is already a lot. Struts has Shale which is a complete rewrite that learns from the past and looks into the future. I really think we should to the same. We're talking a new start, aiming at building a simple, clean and consistent platform. That deserves more than in a major revision number of a name that denotes something else in most people's mind. I strongly disagree with this. And while I agree to most of the points being discussed, I can't help but feel that is is a step too far. And I also think the current discussion is missing something significant (when compared to the first Cocoon steps). While only being able to quickly read through all the discussions - if the best way is really for a clean start: Where is the vision? It's being built in this thread, and I started aggregating it on Daisy[1]. Still very embryonic, but I will spend time on it. Now you're right: let's forget this naming issue, even if I really consider it as being important, and concentrate on what it we want to build. Sylvain [1] http://cocoon.zones.apache.org/daisy/test/g1/792.html -- Sylvain WallezAnyware Technologies http://bluxte.net http://www.anyware-tech.com Apache Software Foundation Member Research Technology Director
Re: [RT] The next shiny thing?
Le 6 déc. 05, à 10:17, Matthew Langham a écrit : Where is the vision? Delivering some of the unique things that are inside Cocoon in much smaller independent packages, to make them useful to people who don't need all of Cocoon. Dunno if this qualifies as a vision, but it's how I see it ;-) -Bertrand smime.p7s Description: S/MIME cryptographic signature
Re: [RT] The next shiny thing?
Ugo Cei wrote: Il giorno 06/dic/05, alle ore 10:01, Sylvain Wallez ha scritto: Il like this friendly animal and the rhyme with Cocoon. Now there's also Baboon :-) Have a look at http://www.rhymezone.com/r/rhyme.cgi?Word=cocoontypeofrhyme=perfectorg1=sylorg2=l I also see Too soon on that list, which might be descriptive of the feelings of some people on this list ;). Sorry, couldn't resist. LOL :-D Sylvain -- Sylvain WallezAnyware Technologies http://bluxte.net http://www.anyware-tech.com Apache Software Foundation Member Research Technology Director
Re: [RT] The next shiny thing?
On 06 Dec 2005, at 09:59, Sylvain Wallez wrote: Struts has Shale Meeep. Bu. Wrong. Struts has Craig. It's a telltale of Cocoon's problem that we're off discussing marketing techniques and branding again, without having any design, code, nor dedication to boot with. A busy thread just in time for ACon. Currently, I see more community than project in Cocoon. I'm game for any sort of progress, as long as: * there's a core set of functionality which is documented through maintained API (or conventions) and scripture * there's a mechanism which enables us to separate the unmaintained one-off's aka blocks into separate release and deprecation cycles * there's more than one actual coder who actually lives through this until the end Maybe this might show people something. This is the reality of someone building an application (Daisy) with a UI using Cocoon: #include.block.batik=false #include.block.fop=false #include.block.ajax=false #include.block.apples=false #include.block.forms=false #include.block.serializers=false , with ajax currently only being included since forms apparently depend on it. And Batik is just there to render images in FOP. That's all. Furthermore, in http://svn.cocoondev.org/viewsvn/trunk/daisy/applications/daisywiki/ frontend/src/cocoon/webapp/daisy/sitemap.xmap: org.outerj.daisy.frontend.QueryGenerator org.outerj.daisy.frontend.ErrorGenerator org.outerj.daisy.frontend.DaisyLinkTransformer org.outerj.daisy.frontend.FopImageSrcTransformer org.outerj.daisy.frontend.TableHelperTransformer org.outerj.daisy.frontend.IncludePreparedDocumentsTransformer org.outerj.daisy.frontend.ExternalIncludeTransformer org.outerj.daisy.frontend.PublisherTransformer org.outerj.daisy.frontend.IDAbsolutizerTransformer org.outerj.daisy.frontend.SerializeTransformer org.outerj.daisy.frontend.CrossRefParserTransformer org.outerj.daisy.repository.DocumentReadDeniedException org.outerj.daisy.repository.DocumentNotFoundException org.outerj.daisy.repository.DocumentVariantNotFoundException org.outerj.daisy.frontend.util.HttpMethodNotAllowedException org.outerj.daisy.frontend.SetRequestAttributeAction org.outerj.daisy.frontend.LocaleAction org.outerj.daisy.frontend.MountPointAction org.outerj.daisy.frontend.InitSkinAction org.outerj.daisy.frontend.SkinsDirAction org.outerj.daisy.frontend.HandleSiteAction org.outerj.daisy.frontend.PartReader org.outerj.daisy.frontend.components.reading.CachingReader Looking at that sitemap and the tiny list of used blocks, I see a number of things: * there's a need for solid programming interfaces in Cocoon * there's lots of stuff we don't use Maybe, when we start from scratch, building solid interfaces, throwing away undermaintained legacy, this is a good time to reinvent Cocoon into a workable environment again. But IMNSHO, we'll never get there with the current approach, effort and dedication. It's the amount of community and legacy tax that is putting innovation efforts into starvation. /Steven -- Steven Noelshttp://outerthought.org/ Outerthought Open Source Java XML stevenn at outerthought.orgstevenn at apache.org
RepeaterJXPathBinding
Hi All, Up until recently I was able to have a repeater binding like this... fb:repeater id=repeater parent-path=. row-path=collection fb:identity fb:value path=id id=id / /fb:identity fb:on-bind [...] /fb:on-bind fb:on-delete-row fb:delete-node / /fb:on-delete-row /fb:repeater This would handle the loading, updating and deleting of rows in the repeater, but ignore newly added rows. This was neat because it meant I could use a second custom binding to handle the binding for newly added rows thus allowing me to bind collections containing objects of different classes. However after revision 349806 of RepeaterJXPathBinding.java this usage results in... org.apache.commons.jxpath.JXPathException: Cannot create a relative context for a non-existent node: /collection[8] at org.apache.commons.jxpath.ri.JXPathContextReferenceImpl.getRelativeConte xt(JXPathContextReferenceImpl.java:581) at org.apache.cocoon.forms.binding.RepeaterJXPathBinding.doSave(RepeaterJXP athBinding.java:253) [...] Comparing this revision with the previous one I can see why the error is occurring - in the previous revision the new row context is not created if the insert binding does not exist, this is not the case in the latest revision. I've patched my copy which continues to work as expected for normal repeater bindings and my binding as outlined above. However I don't know enough about the binding framework to know if this change between the last revision was for a specific reason and whether my patch to revert the behaviour will break other things. Can someone take a look? Thanks, Robin
Re: [RT] The next shiny thing?
Steven Noels wrote: On 06 Dec 2005, at 09:59, Sylvain Wallez wrote: Struts has Shale Meeep. Bu. Wrong. Struts has Craig. And Tapestry has Howard and Spring has Rod. What do you mean? That Cocoon misses someone that can fully dedicate to it and plays the benevolent dictator? Sylvain -- Sylvain WallezAnyware Technologies http://bluxte.net http://www.anyware-tech.com Apache Software Foundation Member Research Technology Director
AJAX and upload field
Hi All, I noticed that if a form contains a file field then AJAX is completely disabled for that form. I've patched my cforms.js so that it disables AJAX only if the file field contains a value. Is this valid? On a more general note would it not be possible to check only the fields which are to be refreshed on that browser update before deciding whether a full page update is needed, or am I misunderstanding something? Thanks, Robin
Re: AJAX and upload field
Robin Wyles wrote: Hi All, I noticed that if a form contains a file field then AJAX is completely disabled for that form. I've patched my cforms.js so that it disables AJAX only if the file field contains a value. Is this valid? Yes, definitely. On a more general note would it not be possible to check only the fields which are to be refreshed on that browser update before deciding whether a full page update is needed, or am I misunderstanding something? Full page reload only occurs when we exit form.showForm(). Other than that, only partial updates are sent back to the browser. Sylvain -- Sylvain WallezAnyware Technologies http://bluxte.net http://www.anyware-tech.com Apache Software Foundation Member Research Technology Director
Re: AJAX and upload field
Sylvain, On 6 Dec 2005, at 12:20, Sylvain Wallez wrote: Robin Wyles wrote: Hi All, I noticed that if a form contains a file field then AJAX is completely disabled for that form. I've patched my cforms.js so that it disables AJAX only if the file field contains a value. Is this valid? Yes, definitely. Shall I put the patch on JIRA? It's very small - I attached it to this mail. On a more general note would it not be possible to check only the fields which are to be refreshed on that browser update before deciding whether a full page update is needed, or am I misunderstanding something? Full page reload only occurs when we exit form.showForm(). Other than that, only partial updates are sent back to the browser. I understand, I think, but in my form it doesn't seem to work that way (this is with a file field). I have something like... fd:group id=group1 fd:widgets fd:upload id=upload/ [...] /fd:widgets /fd:group fd:booleanfield id=boolean fd:on-value-changed fd:javascript // toggle group2 visibility /fd:javascript /fd:on-value-changed /fd:booleanfield fd:group id=group2 fd:widgets fd:field id=field1/ [...] fd:field id=field10/ /fd:widgets /fd:group Using the boolean field to toggle group2 works fine with my patch as long as the upload field doesn't have a value. However when it does have a value the whole page is refreshed even though only group1 contains the upload field and it is group2 that is the subject of the browser update. Also after toggling the area again after a full page refresh I notice that the value is removed from my file field. Is there something I missed? Thanks, Robin
Re: AJAX and upload field
Forgot the patch... cforms-upload.patch Description: Binary data On 6 Dec 2005, at 12:51, Robin Wyles wrote: Sylvain, On 6 Dec 2005, at 12:20, Sylvain Wallez wrote: Robin Wyles wrote: Hi All, I noticed that if a form contains a file field then AJAX is completely disabled for that form. I've patched my cforms.js so that it disables AJAX only if the file field contains a value. Is this valid? Yes, definitely. Shall I put the patch on JIRA? It's very small - I attached it to this mail. On a more general note would it not be possible to check only the fields which are to be refreshed on that browser update before deciding whether a full page update is needed, or am I misunderstanding something? Full page reload only occurs when we exit form.showForm(). Other than that, only partial updates are sent back to the browser. I understand, I think, but in my form it doesn't seem to work that way (this is with a file field). I have something like... fd:group id=group1 fd:widgets fd:upload id=upload/ [...] /fd:widgets /fd:group fd:booleanfield id=boolean fd:on-value-changed fd:javascript // toggle group2 visibility /fd:javascript /fd:on-value-changed /fd:booleanfield fd:group id=group2 fd:widgets fd:field id=field1/ [...] fd:field id=field10/ /fd:widgets /fd:group Using the boolean field to toggle group2 works fine with my patch as long as the upload field doesn't have a value. However when it does have a value the whole page is refreshed even though only group1 contains the upload field and it is group2 that is the subject of the browser update. Also after toggling the area again after a full page refresh I notice that the value is removed from my file field. Is there something I missed? Thanks, Robin
Re: [RT] The next shiny thing?
On 06 Dec 2005, at 12:04, Sylvain Wallez wrote: Steven Noels wrote: On 06 Dec 2005, at 09:59, Sylvain Wallez wrote: Struts has Shale Meeep. Bu. Wrong. Struts has Craig. And Tapestry has Howard and Spring has Rod. What do you mean? I meant to say that Struts is a bad example since it has a benevolent, dedicated person that is cheered upon by a league of grateful groupies, who will follow him anywhere (up to their own imagination's limits). Ditto with Tapestry and Spring and RoR. With Cocoon, there's as much direction as there's developers, and users even: it's big and bloated and lacks direction. And I honestly believe it's the community and consensus tax which make it virtually impossible to create such a unified direction. So so far, I believe we're about to say the same thing, except that I'm pessimistic (as usual). But you sniped away what I really meant to say, actually. That blocks and interfaces, however they come to into existence, are needed - not only for technical but mostly for community reasons: to provide non-community-shepherded code with its own release and life cycle. To provide users with something they can rely upon. Not the next cool thing down the road, or an experimentation platform for non-enduring geeks. Or a code graveyard for a bunch of consultants. I fail to see how giving something fancy names will change that model. So consequentially, maybe it's the community that needs to change. I'm surprised to finally see evidence of an anti-OSGI camp in Cocoon. Not that this surprises me, but it's just sad that this hasn't been clarified much earlier. That damned community tax again, I guess. Waste of time and energy for everyone. /Steven -- Steven Noelshttp://outerthought.org/ Outerthought Open Source Java XML stevenn at outerthought.orgstevenn at apache.org
Re: [RT][long] Cocoon 3.0: the necessary mutation
Luca Morandini wrote: Stefano Mazzocchi wrote: Luca Morandini wrote: Nevertheless, it is easier to build a tool around a declarative language expressed as XML, than a procedural language expressed as... a procedural programming language. I'm sorry, Luca, but I think that's BS. cut/ For example, do you think that if the java classes were expressed as XML statements that *declarative* describe their methods and variables and inner classes it would be easier to write a tool like Eclipse? That I don't know, I've never seen the inner workings of Eclipse. Let's just say that when something is written in XML (say, an UML model expressed as XMI) I can fire up Xalan and beat the beast into submission easily, if the same mopel was expressed as a set of Java classes... hmmm... time for man yacc ? Maybe it's just that I've worked with XML for too long, but I still like the easy production/validation/transformation of vocabularies that comes with it, and I'm scared a bit by the other approach. Which is fair, but this is due to your experience and knowledge. It's fair and nice that you say that it's easier for *you* to write some code using XML technologies instead of using javacc or yacc or bison or whatever else, but using this is an absolute argument is utterly misleading and one of the sins that, myself included, we, as a community made over the years. -- Stefano.
Problem with loc namespace
Hi, I'm using eXist XQueryGenerator in a simple pipeline. It works correctly when i call it directly from my browser with correct parameters. Now this pipeline is called from o.a.c.w.a.c.PipelineAuthenticator.authenticate(PipelineAuthenticator.java:145) during a flow flogin and i've got an exception org.exist.xquery.XPathException: No namespace defined for prefix loc Any idea ?
Re: [RT] The next shiny thing?
Steven Noels wrote: On 06 Dec 2005, at 12:04, Sylvain Wallez wrote: Steven Noels wrote: On 06 Dec 2005, at 09:59, Sylvain Wallez wrote: Struts has Shale Meeep. Bu. Wrong. Struts has Craig. And Tapestry has Howard and Spring has Rod. What do you mean? I meant to say that Struts is a bad example since it has a benevolent, dedicated person that is cheered upon by a league of grateful groupies, who will follow him anywhere (up to their own imagination's limits). Ditto with Tapestry and Spring and RoR. With Cocoon, there's as much direction as there's developers, and users even: it's big and bloated and lacks direction. And I honestly believe it's the community and consensus tax which make it virtually impossible to create such a unified direction. So so far, I believe we're about to say the same thing, except that I'm pessimistic (as usual). Ok. Got it. Also, after hitting send, I realized that I should have added and Daisy has Bruno. But you sniped away what I really meant to say, actually. That blocks and interfaces, however they come to into existence, are needed - not only for technical but mostly for community reasons: to provide non-community-shepherded code with its own release and life cycle. To provide users with something they can rely upon. Not the next cool thing down the road, or an experimentation platform for non-enduring geeks. Or a code graveyard for a bunch of consultants. I wholeheartedly agree. The purpose of layering Cocoon is about ensuring strength of contracts. Someone that knows a piece of software inside out doesn't need contracts. But others do. This is the well-known architecture of participation ([1] -- funny to see who's quoted) that says that successful communities keep a center cathedral around which the bazaar can develop. Lately, Cocoon has failed to maintain this cathedral which has been slowly invaded by the bazaar. Defining contracts in separate modules, and defending them fiercely through human oversight and automated tools is a way to help the very decentralized Cocoon community to preserve the central cathedral. The document I added to Daisy has a chapter dedicated do development rules, which is new here. I fail to see how giving something fancy names will change that model. Fancy names are meant to show that something different is going on. Technically different, but also more importantly culturally different. And that last point is certainly a more difficult change. Some will like it, others won't. So consequentially, maybe it's the community that needs to change. It a least must change the way it handles what it produces and how it behaves. I'm surprised to finally see evidence of an anti-OSGI camp in Cocoon. Not that this surprises me, but it's just sad that this hasn't been clarified much earlier. It's not an anti-OSGi camp, but a are blocks really the solution? camp. OSGi was brought to the picture because no one could agree on the kernel/container to use. So we fetched a great ready-made container outside. That damned community tax again, I guess. Waste of time and energy for everyone. Maybe. But that community also has been able to produce many great things. Let's try to build this cathedral so that the community bazaar can builds even greater things around it. Sylvain [1] http://weblogs.oreilly.com/lpt/wlg/3017 -- Sylvain WallezAnyware Technologies http://bluxte.net http://www.anyware-tech.com Apache Software Foundation Member Research Technology Director
Re: [RT] The next shiny thing?
Bertrand Delacretaz wrote: Le 6 déc. 05, à 10:12, Ugo Cei a écrit : ...I also see Too soon on that list, which might be descriptive of the feelings of some people on this list ;). It might be too soon to choose a name for something which doesn't exist yet...but choosing a code name helps clarifying what we're talking about. So Racoon (or whatever name) could be the code name, it doesn't mean this would ever by shipped under that name. BTW the animal's name is raccoon (2 c's). I agree that now is not the time for a new name and there's always the way of Debian and Ubuntu to provide names to releases while the overall name stays the same. Bye, Helma
Re: [RT] The next shiny thing?
Daniel Fagerstrom wrote: To me: * throwing away the collected work of the community * building something rather different * throwing away a strong brand * leave all the users who has put a trust in us behind seem like a rather strange way of saving Cocoon. It seemed like a rather strange way of saving Apple as well, but look what happened. Now I agree about the point on throwing away a strong brand, because the focus of any revolution here is to clarify and crystalize how to use Cocoon efficiently. Now, the point of leave all the users who has put a trust in us behind is a bit of hyperbole IMO. This community successfully made that transition once before. I will continue to be proud of our brand, our product and our community. And I will continue the work on *Cocoon* towards the future in an evolutionary way, so that those who have put their trust in us have a reasonable migration path to follow. I've put a souple years into Cocoon, and I'm proud of the work that I've done. I like the *concepts* behind Cocoon. The problem is that I lack the patience to wait for evolution to take place--how long has it been that real blocks are not a reality in Cocoon? I could understand if it were just six months and you have to have some time to make it happen. I take this painfully slow evolutionary pace to mean that we are unable to adapt quickly enough. That's a real problem. Esp. when I don't have a clear picture of how blocks is even going to help me. My friends, the comment of Ruby on Rails and simplicity has hit our ecosystem. Prepare for an ice age, adapt or die. Slow adaptation isn't going to cut it. Users have different expectations of their frameworks now. IMO the most important step towards getting an uppwards spiral again is by regaining our and our communities faith in Cocoon, by keeping our promisses and do a 2.2 release. Instead of running like lemmlings towards the next shiny thing. We should focus on our core offerning and getting the parts of it reusable outside Cocoon and of high quality, following the path outlined by Marc. Enjoy that process. There is a lot of pain involved with doing restructurings of Cocoon. As much as I like Cocoon, I honestly believe that the effort to bring order out of chaos is going to be much higher than the effort to build a new system. That's my two cents. For you attention seekers out there, OSGi based blocks will draw a lot of attention towards Cocoon, and it is innovation, not immitation. /Daniel :) Honestly, too little, too late. Just how much attention has OSGi received over the years? It's been around at least as long as Avalon, but Avalon received much more attention (albeit negative attention). It has been living quietly behind the scenes now for a long time.
Re: where is the box?
What I write here is just one vote, but maybe others think the same. For all of our enterprise projects we have done in Cocoon, if it hadn't been Java, we wouldn't have been allowed to use it. Our customers understand Java and it is currently equated with enterprise. Now, it is difficult enough to get enterprise customers to even allow Cocoon as it is something they haven't heard of. To me, adding in the fact that it isn't written in Java only makes this worse. I realize at one point in time Java suffered from this as well, as do all new programming languages. Just wanted to throw this out there. It certainly doesn't mean Ruby, or Python, or whatever won't be the next Java. I can say that when connecting to other enterprise messaging systems, EAI, etc, there are lots of mature Java solutions we have made use of from within cocoon. With our applications in cocoon, having the components in Java allowed us to write custom transformers that used these third party apis. For me, it was Java that is the strength of cocoon, not its weakness. IrvOn 12/6/05, Tim Larson [EMAIL PROTECTED] wrote: I have been sitting back listening to the cocoon evolution/revolutiondiscussion, while happily coding with something else...The development of open source is dominated by emergent properties,which like their counterparts in chemistry and physics are not greatly affected by many types of environmental changes and aredifficult or impossible to predict from base causes.The trick isto recognize that you are dealing with emergent properties and nota set of well-behaved laws, and then to deal with the patterns that present themselves.Where is the recent bottleneck in Cocoon?Is it the number oflanguages, the complexity of the core, the multi-step developmentprocess, the inability to use a common debugger across it all, the lack of a full test suit, incomplete or out of date documentation..or is there something more basic that is strongly contributingto all of these issues?Since we are taking a moment to think outside the box, perhaps we should pause to figure out where the box is and of what it ismade.When Cocoon was started there were not many viable choicesfor cross-platform programming languages, so Java had much goingin its favor.Now the situation has changed.Cross-platform scripting languages have become common.Java is a fairly staticand verbose language compared with these new offerings...and muchof the work in Cocoon lately seems to be in trying to work aroundthis.Java has become the box. People moving to Rails hardly seem to notice the language changethat comes with it.Is that because of the Rails hype (whichwears off quickly) or because the language stays out of the way?Tutorials teach you the framework first, and let you pick up the language along the way because it is so easy.With Cocoon we are already dealing with a variety of languages,Java, _javascript_, numerous XML dialects, and a sprinkling ofScheme to name a few.Perhaps Cocoon is ready to spawn a new breed with a Ruby core, where the language is succinct and morefriendly to more dynamic code.Domain languages become possiblewithout sacrificing a common syntax, debugger, and test suit.Pause and think about how the choice of a base language affects the development of a project...the more words and steps it takesto write code, the harder it gets to write, modify, document,and decipher the project.There are many ways to work around averbose and predominately static language to make it seem more concise and dynamic, but each step taken in this effort divergesyou further from common knowledge of the base language andcomplicates the core of the project...every line of code reflectsthe design decisions of the language used, until the project implodes.Let's find a new box, that is bigger and will fit all of ourtoys (we want to bring them with us, right?)There are a lotof great ideas in Cocoon, but I have come to the conclusionthat Java has become to constricting to effectively develop them much further in a timely manner.I suggest we seriouslyconsider Ruby as that larger, less constricting box.--Tim Larson
RE: [RT] The next shiny thing?
Sorry, I read spots of this list and somebody could have written the same: I think the cocoon package is too big. I would prefer a core and a lot of plugins, not in the same distribution. I think the cocoon package is great but confusing. With plugins you have not to care that anything must have the same maturity level. And if I need a plugin I have only to download that, just as I do that with eclipse. bye romano -Original Message- From: Berin Loritsch [mailto:[EMAIL PROTECTED] Sent: martedì 6 dicembre 2005 14.44 To: dev@cocoon.apache.org Subject: Re: [RT] The next shiny thing? Daniel Fagerstrom wrote: To me: * throwing away the collected work of the community * building something rather different * throwing away a strong brand * leave all the users who has put a trust in us behind seem like a rather strange way of saving Cocoon. It seemed like a rather strange way of saving Apple as well, but look what happened. Now I agree about the point on throwing away a strong brand, because the focus of any revolution here is to clarify and crystalize how to use Cocoon efficiently. Now, the point of leave all the users who has put a trust in us behind is a bit of hyperbole IMO. This community successfully made that transition once before. I will continue to be proud of our brand, our product and our community. And I will continue the work on *Cocoon* towards the future in an evolutionary way, so that those who have put their trust in us have a reasonable migration path to follow. I've put a souple years into Cocoon, and I'm proud of the work that I've done. I like the *concepts* behind Cocoon. The problem is that I lack the patience to wait for evolution to take place--how long has it been that real blocks are not a reality in Cocoon? I could understand if it were just six months and you have to have some time to make it happen. I take this painfully slow evolutionary pace to mean that we are unable to adapt quickly enough. That's a real problem. Esp. when I don't have a clear picture of how blocks is even going to help me. My friends, the comment of Ruby on Rails and simplicity has hit our ecosystem. Prepare for an ice age, adapt or die. Slow adaptation isn't going to cut it. Users have different expectations of their frameworks now. IMO the most important step towards getting an uppwards spiral again is by regaining our and our communities faith in Cocoon, by keeping our promisses and do a 2.2 release. Instead of running like lemmlings towards the next shiny thing. We should focus on our core offerning and getting the parts of it reusable outside Cocoon and of high quality, following the path outlined by Marc. Enjoy that process. There is a lot of pain involved with doing restructurings of Cocoon. As much as I like Cocoon, I honestly believe that the effort to bring order out of chaos is going to be much higher than the effort to build a new system. That's my two cents. For you attention seekers out there, OSGi based blocks will draw a lot of attention towards Cocoon, and it is innovation, not immitation. /Daniel :) Honestly, too little, too late. Just how much attention has OSGi received over the years? It's been around at least as long as Avalon, but Avalon received much more attention (albeit negative attention). It has been living quietly behind the scenes now for a long time.
Re: [RT] The next shiny thing?
Romano Trampus wrote: Sorry, I read spots of this list and somebody could have written the same: I think the cocoon package is too big. I would prefer a core and a lot of plugins, not in the same distribution. I think the cocoon package is great but confusing. With plugins you have not to care that anything must have the same maturity level. And if I need a plugin I have only to download that, just as I do that with eclipse. That exactly is the point with the block architecture, that will be part of 2.2. In the next step the blocks will be OSGi bundles exactly as the Eclipse pluggins, and they will be deployable within Eclipse as any other pluggin, this will make a whole new level of tool support for Cocoon possible. /Daniel
Re: [RT] The next shiny thing?
Berin Loritsch wrote: Daniel Fagerstrom wrote: To me: * throwing away the collected work of the community * building something rather different * throwing away a strong brand * leave all the users who has put a trust in us behind seem like a rather strange way of saving Cocoon. It seemed like a rather strange way of saving Apple as well, but look what happened. Now I agree about the point on throwing away a strong brand, because the focus of any revolution here is to clarify and crystalize how to use Cocoon efficiently. Now, the point of leave all the users who has put a trust in us behind is a bit of hyperbole IMO. This community successfully made that transition once before. And failed a number of times since then. Anyway, we have rules for revolutionaries and so on, go ahead if you like it. I will continue the evolutionary path and it seem like others will as well. I will continue to be proud of our brand, our product and our community. And I will continue the work on *Cocoon* towards the future in an evolutionary way, so that those who have put their trust in us have a reasonable migration path to follow. I've put a souple years into Cocoon, and I'm proud of the work that I've done. I like the *concepts* behind Cocoon. The problem is that I lack the patience to wait for evolution to take place--how long has it been that real blocks are not a reality in Cocoon? I could understand if it were just six months and you have to have some time to make it happen. You know Berin, we have blocks. Go and read http://marc.theaimsgroup.com/?l=xml-cocoon-devm=113335919919804w=2. It says something interesting about this community that no one have responded to that message yet. While a thread about marketing and branding absorbs all the community energy (again). Is Cocoon all about talk and hype? Is design and programming, and god forbid refactoring and testing, something old fashioned that we better stop worrying about? I take this painfully slow evolutionary pace to mean that we are unable to adapt quickly enough. That's a real problem. Esp. when I don't have a clear picture of how blocks is even going to help me. My friends, the comment of Ruby on Rails and simplicity has hit our ecosystem. Prepare for an ice age, adapt or die. Slow adaptation isn't going to cut it. Users have different expectations of their frameworks now. Wow! isn't marketing talk fun. Still I fail to see a common coherent vision for this revolution besides that current Cocoon is messy. Sure I have seen that Sylvain have collected some ideas that we have discussed on the list for a while. Much of it that great stuff, but is it something that can't be achieved by refactoring Cocoon? And are they so great so that we should spread ourselves even thinner instead of focus on getting 2.2 out of the door? IMO the most important step towards getting an uppwards spiral again is by regaining our and our communities faith in Cocoon, by keeping our promisses and do a 2.2 release. Instead of running like lemmlings towards the next shiny thing. We should focus on our core offerning and getting the parts of it reusable outside Cocoon and of high quality, following the path outlined by Marc. Enjoy that process. There is a lot of pain involved with doing restructurings of Cocoon. As much as I like Cocoon, I honestly believe that the effort to bring order out of chaos is going to be much higher than the effort to build a new system. That's my two cents. I know about the pain of restructuring Cocoon as I'm have worked with core related stuff for along time. And getting some proof of concept code working might not be that hard. But I think that you severly underestimate the amount of work it will take to get a production quality system shipping. Not to talk about getting the trust in the new product when we anounce: trust us, this time is different, this time we will behave responsible For you attention seekers out there, OSGi based blocks will draw a lot of attention towards Cocoon, and it is innovation, not immitation. /Daniel :) Honestly, too little, too late. Just how much attention has OSGi received over the years? It's been around at least as long as Avalon, but Avalon received much more attention (albeit negative attention). It has been living quietly behind the scenes now for a long time. OSGi draw enough attention to attract Eclipse. And as it takes a niche that many projects find really important it starting to get a lot of attention. Having a pluggin system seem to be the best known mean to handle great complexity. And because of that many projects have build own plugin system. Inspired by Eclipse many of them are now starting to look at OSGi. The Felix project have taken off lately. Eclipse have restarted its Equinox project that is entirely dedicated to OSGi and seem to be rather active. Eclipse 3.2 have OSGi bundle development
Re: [RT] The next shiny thing?
Daniel Fagerstrom wrote: Berin Loritsch wrote: I will continue to be proud of our brand, our product and our community. And I will continue the work on *Cocoon* towards the future in an evolutionary way, so that those who have put their trust in us have a reasonable migration path to follow. I've put a souple years into Cocoon, and I'm proud of the work that I've done. I like the *concepts* behind Cocoon. The problem is that I lack the patience to wait for evolution to take place--how long has it been that real blocks are not a reality in Cocoon? I could understand if it were just six months and you have to have some time to make it happen. You know Berin, we have blocks. Go and read http://marc.theaimsgroup.com/?l=xml-cocoon-devm=113335919919804w=2. It says something interesting about this community that no one have responded to that message yet. While a thread about marketing and branding absorbs all the community energy (again). :) Yes I know we have a certain implimentation of blocks that require compiling against the core. Is Cocoon all about talk and hype? Is design and programming, and god forbid refactoring and testing, something old fashioned that we better stop worrying about? Oh I agree that design, programming, refactoring, and testing are all extremely important. Any attempt to do a redesign *must* have these things working if it is to have any hope to succeed. I just believe that we have gotten to a point where retrofitting these things is going to take more time and energy than it will to establish them at the inception of any new efforts. My friends, the comment of Ruby on Rails and simplicity has hit our ecosystem. Prepare for an ice age, adapt or die. Slow adaptation isn't going to cut it. Users have different expectations of their frameworks now. I take this painfully slow evolutionary pace to mean that we are unable to adapt quickly enough. That's a real problem. Esp. when I don't have a clear picture of how blocks is even going to help me. Wow! isn't marketing talk fun. Yes it is. But don't forget to see the substance behind it. The reality is that the world around us has changed, and ignoring that fact is just as unhealthy as doing a complete redesign every release. Still I fail to see a common coherent vision for this revolution besides that current Cocoon is messy. Sure I have seen that Sylvain have collected some ideas that we have discussed on the list for a while. Much of it that great stuff, but is it something that can't be achieved by refactoring Cocoon? And are they so great so that we should spread ourselves even thinner instead of focus on getting 2.2 out of the door? Right, and we do need to solidify the vision. I think the point where we are is still trying to see if there is enough community support to do a redesign. Nevertheless, we do need a common vision for Cocoon, whether that is 2.2, 2.3, 3.0, or X. That way we can be sure that we are evolving the right direction. We should focus on our core offerning and getting the parts of it reusable outside Cocoon and of high quality, following the path outlined by Marc. Enjoy that process. There is a lot of pain involved with doing restructurings of Cocoon. As much as I like Cocoon, I honestly believe that the effort to bring order out of chaos is going to be much higher than the effort to build a new system. That's my two cents. IMO the most important step towards getting an uppwards spiral again is by regaining our and our communities faith in Cocoon, by keeping our promisses and do a 2.2 release. Instead of running like lemmlings towards the next shiny thing. I don't think anyone has suggested that we abandon 2.2. Yes, we need to finish 2.2. We need to manage the TODO list for 2.2. I know about the pain of restructuring Cocoon as I'm have worked with core related stuff for along time. And getting some proof of concept code working might not be that hard. But I think that you severly underestimate the amount of work it will take to get a production quality system shipping. Not to talk about getting the trust in the new product when we anounce: trust us, this time is different, this time we will behave responsible That's why I have always advocated the release early and often mantra. I think we should institute a monthly early access release, so that we can get the feedback we need at each stage. I would advocate that whether the community goes evolutionary, revolutionary, or some hybrid.
[Vision] Knowing When We are Done
In all the talks of redesign or not, there has been a recurring question as to the vision. Sylvain has outlined some things that he would like to see, but they really don't constitute a vision. They are a nice list of improvements, but they aren't a vision. In my experience the best visions really don't have to do with features and improvements, but with what we expect to be able to do with Cocoon. We need to be able to put our vision statement in one or two paragraphs, and it needs to convey a little more than technology. Visions contain emotional content as well. There are two kinds of visions. One is the kind that you use to attract users, Oh, that's what I need and they approach things the way I expect. That's the kind that ends up on the front page. Then there's the kind of vision that explains how you think something should be done. Kind of like a how-to that describes what _should_ be instead of what is the case. It has to be something exciting, something that people can get behind. Now, whether we are talking about evolutionary change or revolutionary change, we need to have a common vision. How else will we ensure the transition goes as smoothly as possible? Good foundational principles of modern software development are just side issues. Let's take a look at what we want Cocoon to be. Below is my vision, which I hope starts discussion. We can start consolditing the common points once people post their visions. Let's gather the information, and then see if we can look at some commonalities and think a little outside the box to make as many of us happy as is practical. Berin's Vision I envision a Cocoon which takes its principle strengths in separation of concerns to make developing web applications easier. Modern web applications provide machine-to-machine communications via web services and email as well as various views into the data. I envision a Cocoon that makes Java look attractive again, proving that it is suited for the rapidly changing web environment. I envision a Cocoon which avoids configuration where it is unnecessary, and instead employs easy to understand conventions. I envision a Cocon that is able to be extended using standard Java mechanisms such as the JAR services approach. I envision a Cocoon where I only have to learn Java and XML to be affective. I see a Cocoon where testing is embraced, encouraged, and made easy. I see a Cocoon where any errors/exceptions tell me exactly where the problem lies, down to the source code line--even if that source is not Java code. I see a Cocoon where the Sitemap is not the preferred way to map URLs to generating content. I see a cocoon where convention dictates the pipeline. A note about blocks: while they *can* be helpful, they are not central to my vision. I am open to them, and if they are a part of Cocoon's future then the following applies: I see a cocoon where communities can share solutions packaged up in blocks to be reused in other applications. I'm thinking solutions like user authentication, portal support, or other generic solutions. - That's my vision. What's yours? How much overlap is there? Let's start this discussion, I think we will be pleasantly surprised how close many of us are with where we want Cocoon to go.
Re: Cocoon 2.2 - Build and deployment with Maven2
Jorg Heymans wrote:
Reinhard Poetz wrote:
What do you think about moving block dependecy handling from
block.xml to pom.xml? It means reduced flexibilty as block
dependencies becomes
IIUC, the dependency handling discussed here is the deploy-time
dependency handling, thus only relevant for the deployer?
In that case if we have something like
dependency
artifactIdmyBlock/artifactId
groupIdorg.apache.cocoon.blocks/groupId
version1.2alpha/version
/dependency
then the deployer could check for all declared dependencies with groupId
org.apache.cocoon.blocks and treat them as block dependencies. There
are other ways to distinguish between dependencies in maven, but this
would be the easiest initially i think.
dependencies we can add it later. There would be a need to give the
dependencies POM unique ids that can be used in the block protocol and
not sure on how to best solve this, i'll give it some thought.
Today, Jorg and I had a long chat about this. In short, we failed to find a
solution that works with Maven 2 as it is today. The problem is that Cocoon
block requirements have a different purpose than Maven 2 dependencies. Cocoon
block requirements desribe what a block needs to run while Maven 2 dependencies
describe what a project needs to compile. Additionally we want to describe our
dependencies as contracts and not as direct dependencies to a JAR.
In our opinion there are two possible options:
A) We talk with the Maven guys whether there is some way to add our Cocoon
specific information to a dependency description.
B) We use block.xml.
I'm in favour of B) as
- we don't bend Maven to something which it wasn't created for
- we shouldn't force everybody to use Maven just as we are so
exited about it
- it doesn't tie Cocoon unnecessarily to Maven
Of course we can provide a Maven goal that checks if block.xml and pom.xml
describe the same dependencies.
Maybe some of you guys find some time to talk about this with the Maven folks at
the ApacheCon. Maybe they see a simple solution for our problem.
--
Reinhard Pötz Independent Consultant, Trainer (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
Re: Cocoon 2.2 - Build and deployment with Maven2
Reinhard Poetz wrote: Jorg Heymans wrote: Reinhard Poetz wrote: What do you think about moving block dependecy handling from block.xml to pom.xml? It means reduced flexibilty as block dependencies becomes IIUC, the dependency handling discussed here is the deploy-time dependency handling, thus only relevant for the deployer? In that case if we have something like dependency artifactIdmyBlock/artifactId groupIdorg.apache.cocoon.blocks/groupId version1.2alpha/version /dependency then the deployer could check for all declared dependencies with groupId org.apache.cocoon.blocks and treat them as block dependencies. There are other ways to distinguish between dependencies in maven, but this would be the easiest initially i think. dependencies we can add it later. There would be a need to give the dependencies POM unique ids that can be used in the block protocol and not sure on how to best solve this, i'll give it some thought. Today, Jorg and I had a long chat about this. In short, we failed to find a solution that works with Maven 2 as it is today. The problem is that Cocoon block requirements have a different purpose than Maven 2 dependencies. Cocoon block requirements desribe what a block needs to run while Maven 2 dependencies describe what a project needs to compile. Can't you use scoperuntime/scope? Additionally we want to describe our dependencies as contracts and not as direct dependencies to a JAR. Yes and no ;) My idea was to start simple with only jar dependencies which solves our current needs and is simple. Then we could add indirect dependencies later when we need it. In our opinion there are two possible options: A) We talk with the Maven guys whether there is some way to add our Cocoon specific information to a dependency description. B) We use block.xml. I'm in favour of B) as - we don't bend Maven to something which it wasn't created for - we shouldn't force everybody to use Maven just as we are so exited about it - it doesn't tie Cocoon unnecessarily to Maven Simplicity vs flexibillity ;) Anyway, the important thing is to get something that works ASAP, and the block code is designed for B) and you seem to think that it is easier with M2, so go ahead with B). We can impove usabillity with various conventions at a later stage. Of course we can provide a Maven goal that checks if block.xml and pom.xml describe the same dependencies. Maybe some of you guys find some time to talk about this with the Maven folks at the ApacheCon. Maybe they see a simple solution for our problem. There have been a long discussion on Felix-dev about how to use M2 (which is jar based) with OSGi (which is contract based, although at the package level) in the best way. Both people from Maven and Eclipse have been involved. We can use what they come up with later, and I will try to discuss the problem with them at ApacheCon. /Daniel
Re: Cocoon 2.2 - Build and deployment with Maven2
Daniel Fagerstrom wrote:
Simplicity vs flexibillity ;)
Anyway, the important thing is to get something that works ASAP, and the
block code is designed for B) and you seem to think that it is easier
with M2, so go ahead with B). We can impove usabillity with various
conventions at a later stage.
yes, for now I think it is simpler (and more flexible) with B)
thanks for your feedback!
--
Reinhard Pötz Independent Consultant, Trainer (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
Re: Cocoon 2.2 - Build and deployment with Maven2
BURGHARD Éric wrote: Daniel Fagerstrom wrote: What do you think about moving block dependecy handling from block.xml to pom.xml? It means reduced flexibilty as block dependencies becomes direct instead of indirect as in the current schema. OTH it reduce complexity and fullfills our current use cases. If we need indirect dependencies we can add it later. There would be a need to give the dependencies POM unique ids that can be used in the block protocol and we also need a way to be able to mark a dependency as extension, any idea if this would be possible? Hmm, while that would be nice at some point I think that it currently would be enough to have a block aware variant of the war pluggin. That fetch and install all needed blocks in the webapp one i developing. Maybe wiring.xml could even be expressed as a POM for this pluggin? 2 wonderfull ideas ! Before you wrote that, daniel, i was very frightened by the new 'hot' block framework because of * the new kind of descriptor, The current design involves a pom.xml and a block.xml (and a Manifest.mf whith OSGi) for each block and a wiring.xml globally. This is certainly to much, some merging of configuration files is needed on the block level. How to do this is an open question. With Jorg's and Reinhard's ongoing work and the block mechanism in place we hopefully will be able to real blockify a number of blocks in trunk RSN. Then hopefully the community can take some interst in such mundane questions as configuration file formats ;) * all the new jar introduced (osgi, knopflerfish: even if don't know if there are really related to this, it's part of the cocoon new face) They will be removed from the 2.2 releases and only be part of 3.0. And it is not as bad as it might seem, framework, log and http which together is less than 350kB is needed for actually running serving webpages with Cocoon in OSGi mode. The rest (rather small as well) are for the Knopflerfish OSGi runtime console. * the fact that blocks are not regular jar (even if i don't know what it means it's frightening for a java developer :-) Bundles are regular jars that happen to include some extra fields in the manifest. Blocks will be as well. After 2 years using cocoon i just can't explain clearly how to build an application over cocoon-core and a few blocks staticaly. You should do something with block management for sure, but IMHO hot deployment should not be a priority. It just seems like adding an unecessary new layer of complexity (i know that you think this is simpler :-). No I don't think complete hot deployment is simple. Block that are leaves in the dependency chain and that not are connected to complicated external things like DBs, is not that complicated to get hot deployable. And having hot deployable user blocks will make wonders for development. Think about having your Cocoon (which will be a couple of bundles) deployed within Eclipse while you develop your own block with the pluggin development mode in Eclipse. But as you suggest hot deployment is far from the main priority. First we need to get everything working statically and even without OSGi. ... So please (poor user request) define first a clean static build process with well defined dependencies (concern 99% of users) before thinking of hot deployment stuff. This build process could be defined for cocoon 2.1.9 without redefining the block management nor the jar stucture. It would give new users the possibility to fire a new cocoon project in 30s (how lucky ! it took me several month just to know how to build a minimal cocoon webapp). Hmm ... might there be simpler things we could do than redefining ourself completely, to attract users? Could a first step be as easy as reducing the startup phase of Cocoon from 3 months to ... say 1 month ;) Or maybe to a few minutes. The ongoing M2 and blocks work will get us there. /Daniel
Re: Cocoon 2.2 - Build and deployment with Maven2
Daniel Fagerstrom wrote: There have been a long discussion on Felix-dev about how to use M2 (which is jar based) with OSGi (which is contract based, although at the package level) in the best way. Both people from Maven and Eclipse have been involved. We can use what they come up with later, and I will try to discuss the problem with them at ApacheCon. Yes, Jason Vanzyl asked me if we could find some time during ApacheCon to discuss the cocoon maven integration issues. Unfortunately i won't be attending, so it would be great if you and anyone else remotely interested in maven (Jason's own words!) could get in touch with him there for a chat. Regards Jorg
Re: Cocoon 2.2 - Build and deployment with Maven2
Jorg Heymans wrote: Daniel Fagerstrom wrote: There have been a long discussion on Felix-dev about how to use M2 (which is jar based) with OSGi (which is contract based, although at the package level) in the best way. Both people from Maven and Eclipse have been involved. We can use what they come up with later, and I will try to discuss the problem with them at ApacheCon. Yes, Jason Vanzyl asked me if we could find some time during ApacheCon to discuss the cocoon maven integration issues. Unfortunately i won't be attending, so it would be great if you and anyone else remotely interested in maven (Jason's own words!) could get in touch with him there for a chat. I'm far over the stage of remote interest, I can't wait until we have switched completely to M2. And Carsten might be interested in discussing Maven as well ;) /Daniel
An entirely new beast
I've been thinking more about Sylvain's proposal and ideas. And would like to suggest a way to look at it and see how it fits into the context of what we already have. Sylvain is proposing something different, something that is likely to be almost entirely incompatible with the existing Cocoon. If it is almost entirely incompatible, how can we think of it as in some way being a _continuation_ of what we already have? This, it is _not_ Cocoon 3.0. It is something else. Thus, I agree with Sylvain that it should have a new name, but think that Raccoon is a bad one, as it is a play on Cocoon and could never really be the project's real name. Imagine it, powered by Apache Cocoon Raccoon. Hmm. So, what I'd propose is we choose another name, and consider it to be a new subproject of Cocoon. A new, exciting web development framework from the people that brought you Apache Cocoon. And, the existing Cocoon carries on as long as people want and need it. Maybe 3.0 could still be the OSGi version. It may well still bring huge benefits to those using the current generation of Cocoon. Thoughts? (Other than oh no, not another naming discussion!) Regards, Upayavira (P.S. If people do agree, I'd say please refrain from providing possible names at the moment. We can discuss that later. For now, let's see if people agree with what I am suggesting).
Re: Cocoon 2.2 - Build and deployment with Maven2
Daniel Fagerstrom wrote: Jorg Heymans wrote: Daniel Fagerstrom wrote: There have been a long discussion on Felix-dev about how to use M2 (which is jar based) with OSGi (which is contract based, although at the package level) in the best way. Both people from Maven and Eclipse have been involved. We can use what they come up with later, and I will try to discuss the problem with them at ApacheCon. Yes, Jason Vanzyl asked me if we could find some time during ApacheCon to discuss the cocoon maven integration issues. Unfortunately i won't be attending, so it would be great if you and anyone else remotely interested in maven (Jason's own words!) could get in touch with him there for a chat. I'm far over the stage of remote interest, I can't wait until we have switched completely to M2. And Carsten might be interested in discussing Maven as well ;) I plan to be in on it too. Upayavira
Re: An entirely new beast
On Dec 6, 2005, at 2:31 PM, Upayavira wrote: This, it is _not_ Cocoon 3.0. It is something else. Thus, I agree with Sylvain that it should have a new name, but think that Raccoon is a bad one, as it is a play on Cocoon and could never really be the project's real name. Imagine it, powered by Apache Cocoon Raccoon. Hmm. So, what I'd propose is we choose another name, and consider it to be a new subproject of Cocoon. A new, exciting web development framework from the people that brought you Apache Cocoon. And, the existing Cocoon carries on as long as people want and need it. Maybe 3.0 could still be the OSGi version. It may well still bring huge benefits to those using the current generation of Cocoon. Thoughts? If it is truly something else, then I agree, it should have a new name. If, as someone has suggested, it should turn out no longer to be Java-based, then it would definitely be something else, of course. If it's still Java, then I can't tell yet (but maybe others can). If it's like the difference between Cocoon 1 and Cocoon 2, then I think it should still be Cocoon. my $.02... :-) —ml—
Re: An entirely new beast
Upayavira wrote: I've been thinking more about Sylvain's proposal and ideas. And would like to suggest a way to look at it and see how it fits into the context of what we already have. Sylvain is proposing something different, something that is likely to be almost entirely incompatible with the existing Cocoon. If it is almost entirely incompatible, how can we think of it as in some way being a _continuation_ of what we already have? This, it is _not_ Cocoon 3.0. It is something else. Thus, I agree with Sylvain that it should have a new name, but think that Raccoon is a bad one, as it is a play on Cocoon and could never really be the project's real name. Imagine it, powered by Apache Cocoon Raccoon. Hmm. Well, let's at least get on the same page with what the vision should be. I'd rather have that discussion first.
help please!
good morning , or better good night
I don't know English very well , and for this this email is orrible.
i have a problem , please help me!
i must to create a sitemap with the html generator and an xslt
generator, but don't work or
better or work the xslt without the html generator or the html genetare.
my site map is the follow:
?xml version=1.0?
map:sitemap xmlns:map=http://apache.org/cocoon/sitemap/1.0;
map:pipelines
map:pipeline
map:match pattern=*
map:generate src=web-site/{1} type=html/
map:transform src=XSLT/add.xsl/
map:serialize type=xhtml/
/map:match
/map:pipeline
/map:pipelines
/map:sitemap
please tell me why?
ths
lordsh
Re: dealing with log messages from ehcache
Cocoon 2.2 uses running modes for resolving properties. In the WEB-INF/properties directory, you'll find two modesprod and dev. By default, 2.2 is running in dev mode which overrides all log levels defined in the logkit config and sets them to DEBUG. You can either set the running mode to prod by setting the system property -Dorg.apache.cocoon.mode=prod on startup, or you can remove the org.apache.cocoon.override.loglevel=DEBUG from the core.properties file in the dev directory. Note, that dev and prod are not predefined. So you can create a forrest-dev directory underneath the properties directory and set the running mode to forrest-dev etc. HTH Carsten David Crossley wrote: Can anyone explain the following difference ... Doing 'cocoon.sh' with 2.2 trunk at my local working copy, with all default blocks. The logfile is filling up with EHCache debug messages into the logfile at build/webapp/WEB-INF/logs/cocoon.log At cocoon.zones.apache.org i cannot find any mention of ehcache in the logs of the trunk demo. Why is it so? -David David Crossley wrote: As you know, at Apache Forrest we use Cocoon 2.2 trunk. A few months ago we upgraded our packaged Cocoon. Now we get messages from EHCache coming to stdout when we use our Jetty demo webapp. Of course tweaking WEB-INF/logkit.xconf has no effect because they are coming to the console. However, when going to Cocoon trunk and using './cocoon.sh servlet' the ehcache messages are properly handled by logkit.xconf So what is the difference? Are we missing some configuration? Another issue is that in both Cocoon trunk and at Forrest, the loglevel for these cache messages are at DEBUG, so the logs fill up rapidly. How can we set its loglevel to something else? -David -- Carsten Ziegeler - Open Source Group, SN AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Re: Cocoon 2.2 - Build and deployment with Maven2
I'm far over the stage of remote interest, I can't wait until we have switched completely to M2. And Carsten might be interested in discussing Maven as well ;) Yupp, definitly :) Carsten -- Carsten Ziegeler - Open Source Group, SN AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
ajax cform and forms_onsubmitHandlers issues
Hello, We've run into a problem where javascript event handlers do not work after any ajax form widget fires. For example, before changing a selection box that triggers an ajax event, the forms_onsubmitHandlers has a number of objects in it. After an ajax request, the forms_onsubmitHandlers array is empty (0 length). We're using on-value-changed/javascript on the server-side. It appears that various page-level javascript variables are being reset when the ajax action runs. Any ideas what's going on and where to look? Has anyone else seen this? Thanks in advance, Eric Meyer
Re: ajax cform and forms_onsubmitHandlers issues
I believe that the source of the problem is cforms.js
cocoon.forms.submitForm = function(element, name) {
...
forms_onsubmitHandlers = new Array();
Removing the above line seems to solve the problem. Any reason why
that line should be there? Can it be removed?
Regards,
Eric Meyer
Re: ajax cform and forms_onsubmitHandlers issues
It is also necessary to change forms_onsubmit in forms-lib.js to
remove setting the forms_onsubmithandlers to null.
Any suggestions about this? It seems that it's import to know when the
form is finally submitted vs when it is being ajax submitted. Is this
correct?
function forms_onsubmit() {
if (forms_onsubmitHandlers == null) {
// Form already submited, but the new page is not yet loaded.
This can happen when
// the focus is in an input with an onchange and the user
clicks on a submit button.
return false;
}
...
// clear it
//forms_onsubmitHandlers = null; // commented this out
Re: dealing with log messages from ehcache
Carsten Ziegeler wrote: Cocoon 2.2 uses running modes for resolving properties. In the WEB-INF/properties directory, you'll find two modesprod and dev. By default, 2.2 is running in dev mode which overrides all log levels defined in the logkit config and sets them to DEBUG. You can either set the running mode to prod by setting the system property -Dorg.apache.cocoon.mode=prod on startup, or you can remove the org.apache.cocoon.override.loglevel=DEBUG from the core.properties file in the dev directory. Note, that dev and prod are not predefined. So you can create a forrest-dev directory underneath the properties directory and set the running mode to forrest-dev etc. HTH Carsten That certainly does help to explain the difference in log-levels. Thanks Carsten. Someone should document that :-) The original problem still remains. How does Cocoon manage to get logkit to handle the ehcache messages, whereas with Forrest they come to the console? -David David Crossley wrote: Can anyone explain the following difference ... Doing 'cocoon.sh' with 2.2 trunk at my local working copy, with all default blocks. The logfile is filling up with EHCache debug messages into the logfile at build/webapp/WEB-INF/logs/cocoon.log At cocoon.zones.apache.org i cannot find any mention of ehcache in the logs of the trunk demo. Why is it so? -David David Crossley wrote: As you know, at Apache Forrest we use Cocoon 2.2 trunk. A few months ago we upgraded our packaged Cocoon. Now we get messages from EHCache coming to stdout when we use our Jetty demo webapp. Of course tweaking WEB-INF/logkit.xconf has no effect because they are coming to the console. However, when going to Cocoon trunk and using './cocoon.sh servlet' the ehcache messages are properly handled by logkit.xconf So what is the difference? Are we missing some configuration? Another issue is that in both Cocoon trunk and at Forrest, the loglevel for these cache messages are at DEBUG, so the logs fill up rapidly. How can we set its loglevel to something else? -David
Re: An entirely new beast
Upayavira wrote:
I've been thinking more about Sylvain's proposal and ideas. And would
like to suggest a way to look at it and see how it fits into the context
of what we already have.
Sylvain is proposing something different, something that is likely to be
almost entirely incompatible with the existing Cocoon. If it is almost
entirely incompatible, how can we think of it as in some way being a
_continuation_ of what we already have?
This, it is _not_ Cocoon 3.0. It is something else.
Thus, I agree with Sylvain that it should have a new name, but think
that Raccoon is a bad one, as it is a play on Cocoon and could never
really be the project's real name. Imagine it, powered by Apache Cocoon
Raccoon. Hmm.
So, what I'd propose is we choose another name, and consider it to be a
new subproject of Cocoon. A new, exciting web development framework
from the people that brought you Apache Cocoon.
And, the existing Cocoon carries on as long as people want and need it.
Maybe 3.0 could still be the OSGi version. It may well still bring huge
benefits to those using the current generation of Cocoon.
Thoughts? (Other than oh no, not another naming discussion!)
Regards, Upayavira
(P.S. If people do agree, I'd say please refrain from providing possible
names at the moment. We can discuss that later. For now, let's see if
people agree with what I am suggesting).
Thanks!
Could we please stop to throw around version numbers? We don't even have a
*common* vision. We don't know anything about compatibility, about the base
technologogy, etc.
When we know what we have created, then there is time enough for finding a name
and a version number.
--
Reinhard Pötz Independent Consultant, Trainer (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
Re: [Vision] Knowing When We are Done
Berin Loritsch wrote: In all the talks of redesign or not, there has been a recurring question as to the vision. Sylvain has outlined some things that he would like to see, but they really don't constitute a vision. They are a nice list of improvements, but they aren't a vision. In my experience the best visions really don't have to do with features and improvements, but with what we expect to be able to do with Cocoon. We need to be able to put our vision statement in one or two paragraphs, and it needs to convey a little more than technology. Visions contain emotional content as well. There are two kinds of visions. One is the kind that you use to attract users, Oh, that's what I need and they approach things the way I expect. That's the kind that ends up on the front page. Then there's the kind of vision that explains how you think something should be done. Kind of like a how-to that describes what _should_ be instead of what is the case. It has to be something exciting, something that people can get behind. Now, whether we are talking about evolutionary change or revolutionary change, we need to have a common vision. How else will we ensure the transition goes as smoothly as possible? Good foundational principles of modern software development are just side issues. Let's take a look at what we want Cocoon to be. Below is my vision, which I hope starts discussion. We can start consolditing the common points once people post their visions. Let's gather the information, and then see if we can look at some commonalities and think a little outside the box to make as many of us happy as is practical. Berin's Vision I envision a Cocoon which takes its principle strengths in separation of concerns to make developing web applications easier. Modern web applications provide machine-to-machine communications via web services and email as well as various views into the data. I envision a Cocoon that makes Java look attractive again, proving that it is suited for the rapidly changing web environment. I envision a Cocoon which avoids configuration where it is unnecessary, and instead employs easy to understand conventions. I envision a Cocon that is able to be extended using standard Java mechanisms such as the JAR services approach. I envision a Cocoon where I only have to learn Java and XML to be affective. I see a Cocoon where testing is embraced, encouraged, and made easy. I see a Cocoon where any errors/exceptions tell me exactly where the problem lies, down to the source code line--even if that source is not Java code. I see a Cocoon where the Sitemap is not the preferred way to map URLs to generating content. I see a cocoon where convention dictates the pipeline. A note about blocks: while they *can* be helpful, they are not central to my vision. I am open to them, and if they are a part of Cocoon's future then the following applies: I see a cocoon where communities can share solutions packaged up in blocks to be reused in other applications. I'm thinking solutions like user authentication, portal support, or other generic solutions. - That's my vision. What's yours? How much overlap is there? Let's start this discussion, I think we will be pleasantly surprised how close many of us are with where we want Cocoon to go. Oh yes, we are close. To all the above, add the following: I envision a Cocoon where I can use the power of the pipeline engine in almost every environment where there is some XML data to be processed. I envision a Cocoon where people can use a single unified scripting language for both the client and the server. I envision a Cocoon where the expression used to access a given data is the same everywhere. I envision a Cocoon where any change to a source file, even Java, is instantly reflected in my application. Sylvain -- Sylvain WallezAnyware Technologies http://bluxte.net http://www.anyware-tech.com Apache Software Foundation Member Research Technology Director
