Re: most of *.apache.org do not work for me. Am I the only one?
J Aaron Farr wrote: On 10/24/06, Ralph Goers [EMAIL PROTECTED] wrote: No. It would have been nice to have been notified about a planned outage this long and this massive. Doing any real work without the maven repositories was extremely difficult. Not having any email for 2 days was kind of nice though. Two places of information: 1) http://monitoring.apache.org/status/ Note that links at the top provide lists of scheduled downtime. The downtime this weekend was noted there. 2) http://planetapache.org Henri posted a blog entry over the weekend that explained what was going on. Granted, these aren't necessarily the best channels of communication, but they do exist. Sander sent out a (somewhat late, but definitely in time) email to committers@ that informed folks of the outage. Did you not get it? Upayavira
Re: Cocoon Short Message Service
Omar Adobati wrote: Good morning, I'd like to manage in some way the sms sending using cocoon, but I have not easy clear ideas on how to realize this. Does anyone know the best, or maybe the not worst, way to try to implement this function? Suppose I have an XML file with all the information I need to generate the SMS, and that I could display the SMS contents in HTML or PDF (or anything else too) and also that I can manage the sending of e-mails [just to let you know my background... but I'm still a newbie in cocoon] Yes, I know I need an SMS gateway to send sms, but now I just need to know the way to manage it via cocoon, just a suggestion about it... P.S. I need this for my thesis, no profit reasons :) It really depends upon which provider you plan to use and what interfaces they offer. It could be a custom HTTP one, or perhaps an SMPP one. Do you have a provider in mind? Upayavira
Re: [Vote Result] New committers
Peter Hunsberger wrote: On 7/12/06, David Crossley [EMAIL PROTECTED] wrote: Joerg Heinicke wrote: Upayavira wrote: Jim last recorded a batch on 2006-07-07. Peter this sounds strange. Fax it again. If it is back-to-front or unreadable then nothing that Jim can do. Our Fax machine prints out little images of what was sent with the confirmation so I know it was sent ok unless their fax machine screwed up. I've faxed it off again... I believe GPG signed scans are now accepted by email to [EMAIL PROTECTED] Regards, Upayavira
Re: Cocoon Short Message Service
Omar Adobati wrote: My idea was to connect something like a cellphone (or maybe a real cellphone) and use the AT instruction to send the SMS. Isn't a ggod idea? For low volumes, that can be done. You'd just use a serial port. There are various unix apps IIUC that can send SMSes. I really don't know SMPP, I'm now lloking for info about it on the Internet... I'll tell you if I could use it. Do you suggest me to use it? I use aql.com. they have http and smpp interfaces, and reasonable prices for small scale operations. Upayavira
Re: Cocoon Short Message Service
Omar Adobati wrote: On 7/17/06, Upayavira [EMAIL PROTECTED] wrote: Omar Adobati wrote: My idea was to connect something like a cellphone (or maybe a real cellphone) and use the AT instruction to send the SMS. Isn't a ggod idea? For low volumes, that can be done. You'd just use a serial port. There are various unix apps IIUC that can send SMSes. This is what I need just by now... I'm developing a software for a thesis so at the moment I don't know a great amount of messages... I just need a working prototipe. I really don't know SMPP, I'm now lloking for info about it on the Internet... I'll tell you if I could use it. Do you suggest me to use it? I use aql.com. they have http and smpp interfaces, and reasonable prices for small scale operations. Anyway, I'll take a look to that link :) I think you'll find AQL simpler than hooking up a mobile phone. It is just a simple HTTP post, and you can buy messages in small quantities (100 IIRC). And if they cost £0.10 each, that'd be £10 (~=$20US). Regards, Upayavira
Re: [Vote Result] New committers
Peter Hunsberger wrote: On 6/20/06, Joerg Heinicke [EMAIL PROTECTED] wrote: On 14.06.2006 21:16, Joerg Heinicke wrote: I'd like to introduce some people of our community and invite them for becoming committers of the Cocoon project. Three people do I have in mind: Andreas Hochsteger, Peter Hunsberger and Jason Johnston. Congratulations Andreas, Peter and Jason. You all have been elected with 21 positive and no negative votes to become committers of the Cocoon project. Welcome! Unless you already have an Apache account please let me know your preferred userid (plus an alternative). I will ask for the accounts then. In the meantime you can send the CLA (http://apache.org/foundation/how-it-works.html#committers) to Apache. Joerg, haven't seen anything about apache mail ids being created or such? Is it possible that a direct reply to your e-mail got spam filtered or went missing in someway? Should I resend? The process is you send in your ICLA by fax (or it may be possible to send a scanned email now, not sure of the details tho), the ASF Secretary records the receipt in a file in SVN. When that record is seen, our PMC Chair (Reinhard now?) can request an account for you. That is the point that you choose/get your apache ID. Your name isn't showing in the ICLA file, so sounds like your first task is to ensure that a signed one is received. Regards, Upayavira
Re: [Cocoon Wiki] Update of FrontPage by JohathannRelly
Antonio Gallardo wrote: Simone Gianni escribió: Hi Antonio, something don't work as expected, he did it again. Hi Simone, Thanks for spotting it. Unfortunately, you are right. I've just posted to infra asking why LocalBadContent does not work as advertised. ;-) In the mean time, I discovered we can use (or misuse?, I dunno) our own LocalBadContent in cocoon wiki. I placed there the spammer link and I was able to block his url. The problem is that our local page is open. Hence our pet can erase his keyword before posting. I also alerted infra about this. In short this page should have an ACL (as the page on the general wiki). Add an ACL yourself. Just make sure that there are some users in the relevant group who can edit it. Regards, Upayavira
Re: CocoonTask
Carsten Ziegeler wrote: Upayavira wrote: Do note that the CocoonTask is nothing but a wrapper around the CocoonBean, much as is the CLI (org.apache.cocoon.Main). Were you to get the CocoonBean working without changing its interfaces, the CocoonTask would start working again. Once someone has worked out the CLI, the ant task should be pretty simple. There was an older Ant task in the scratchpad that was a rewrite of the CLI - but I think/hope that was deleted long ago. No, it's still there. Can we delete it? IMO yes. I doubt it works anyway. Upayavira
Re: CocoonTask
Carsten Ziegeler wrote: Reinhard Poetz wrote: I was going through the list of dependencies because I was wondering why we have Ant artifacts in our web applications. I found the cause which is the CocoonTask and the question is, what we want to do with it. As IMO it shouldn't be part of a Cocoon core, I see two options: - create a cocoon-ant module - remove it BTW, is it supposed to work with Cocoon 2.2 at all? I guess it's currently not working anyway. Personally I see no real need in a cocoon ant task, so I would vote for removing it. There is forrest anyway. It likely isn't working, and would need the same attention as the CLI. I don't agree with the 'there is forrest' argument, as Forrest should be using the Ant task rather than calling the CLI. The Cocoon Ant task is really a better way of using the CLI. So by saying there's no need for the Ant task, you're effectively also saying there's no need for the CLI either. (Now that may well be true, wget and all, but that's a different discussion). However, moving it into a separate module makes sense, as both CLI and Ant are definitely not the main use-cases for Cocoon. In the end, if no-one is prepared to update it, then it would be better removed. And I'm not going to be in a position to update it myself. Regards, Upayavira
Re: [QVOTE] Deprecate CocoonTask in 2.1 and remove it in 2.2
Reinhard Poetz wrote: Carsten Ziegeler wrote: Reinhard Poetz wrote: I was going through the list of dependencies because I was wondering why we have Ant artifacts in our web applications. I found the cause which is the CocoonTask and the question is, what we want to do with it. As IMO it shouldn't be part of a Cocoon core, I see two options: - create a cocoon-ant module - remove it BTW, is it supposed to work with Cocoon 2.2 at all? I guess it's currently not working anyway. Personally I see no real need in a cocoon ant task, so I would vote for removing it. There is forrest anyway. Carsten This is a quick vote. Only vote, if you're against it. The vote is open for 48 hours. Are you against deprecating the CocoonTask in 2.1 and removing it in 2.2? -1 Until we've had more discussion. Upayavira
Re: CocoonTask
Reinhard Poetz wrote: Upayavira wrote: Carsten Ziegeler wrote: Reinhard Poetz wrote: I was going through the list of dependencies because I was wondering why we have Ant artifacts in our web applications. I found the cause which is the CocoonTask and the question is, what we want to do with it. As IMO it shouldn't be part of a Cocoon core, I see two options: - create a cocoon-ant module - remove it BTW, is it supposed to work with Cocoon 2.2 at all? I guess it's currently not working anyway. Personally I see no real need in a cocoon ant task, so I would vote for removing it. There is forrest anyway. It likely isn't working, and would need the same attention as the CLI. I don't agree with the 'there is forrest' argument, as Forrest should be using the Ant task rather than calling the CLI. The Cocoon Ant task is really a better way of using the CLI. So by saying there's no need for the Ant task, you're effectively also saying there's no need for the CLI either. (Now that may well be true, wget and all, but that's a different discussion). However, moving it into a separate module makes sense, as both CLI and Ant are definitely not the main use-cases for Cocoon. In the end, if no-one is prepared to update it, then it would be better removed. And I'm not going to be in a position to update it myself. What about creating a cocoon-cli module that also contains the Ant task? I can do the move in our repo but I don't have the knowledge (and time) to test it. I'm quite happy with that. Do note that the CocoonTask is nothing but a wrapper around the CocoonBean, much as is the CLI (org.apache.cocoon.Main). Were you to get the CocoonBean working without changing its interfaces, the CocoonTask would start working again. Once someone has worked out the CLI, the ant task should be pretty simple. There was an older Ant task in the scratchpad that was a rewrite of the CLI - but I think/hope that was deleted long ago. Regards, Upayavira
Re: [QVOTE] Deprecate CocoonTask in 2.1 and remove it in 2.2
Bertrand Delacretaz wrote: On 5/18/06, Carsten Ziegeler [EMAIL PROTECTED] wrote: ...Perhaps we should create an archive directory in our svn and move everything which we won't release in b1 there. So we don't loose the code and can decide later on what to do with it... I like the idea. Yes, sounds reasonable to me. Also helps us to keep the code we are keeping cleaner. Upayavira
Relinquishing moderation role
Hi, Due to pressures of work, I need to relinquish my moderation role on dev/users/cvs/[EMAIL PROTECTED] Are the existing additional moderators happy to continue the job without me, or do we require additional volunteers? Regards, Upayavira
Re: [RT] Resources Accessible Via Subsitemaps To Enable Better Re-Use
Carsten Ziegeler wrote: Adrien Guillon wrote: What is the official design reason for resources not being accessible by child site maps ? I guess originally this has just been forgotten to be implemented. Any suggestions would be greatly appreciated! With 2.2 we will have a different solution, the virtual sitemap components which can be compared to resources and which are inherited to sub sitemaps. Also, bear in mind that if you use the cocoon: protocol, the serialiser will likely be skipped. You could call the sub-pipeline with something that tells it how to use another pipeline as its generator. So there are ways you could achieve what you are after with the current setup. Regards, Upayavira
Re: [RT] Simplifying setup
Ralph Goers wrote: big-snip/ Daniel's proposal was about making this process simpler and this has *nothing* to do with OSGi. Daniel and I believe that OSGi is the way to go but this doesn't necessarily mean that everything we do is OSGi-related. As we had to understand Cocoon internals in greater detail, we started to think more and more about how to simplify things, and believe me, there is room for improvment as the core of Cocoon has grown and got too complicated over the years. Well, I apologize for not knowing enough about trunk to understand that that is how it all works now. However, I'd still like to see an example of how configuring via a servlet filter will make the configuration simpler. Or does it just make the code simpler? Makes the code more 'normative'? Just doing things the same way as has become a convention in more recent times? Which makes the code more accessible to folks that have been exposed to such approaches, which is an increasing number of people. That's how I read it. Regards, Upayavira
Re: [RT] Simplifying setup
Reinhard Poetz wrote: Ralph Goers wrote: I also get paid to do real work. OSGi doesn't fit in those plans. A lot of other stuff in trunk does but I can't have it because a release of trunk isn't going to happen in 2006. My employer won't pay me to work on stuff that they won't see in the next few months. And there is enough stuff in 2.1 that needs fixing to keep me busy for a long time. What exactly is stopping you from working on trunk to make the release happen? People differ in terms of their freedom to work. Some people are fortunate in that they have free time that they can contribute to projects they believe in. Others aren't. I myself have a young family, with another on the way, which pretty effectively fills my non-work time. So, the only way I can get to work on projects is to persuade my boss that it is a good idea, and do it on work time. And of course bosses tend not to favour their employees working on speculative projects that _may_ give results, unless that is directly related to the nature of their business. I personally have had the opportunity to introduce Cocoon into my current workplace, but, due to the additional complexity it would have brought to play, have not been able to justify it. Thus, I have not been in a position to contribute to Cocoon in terms of code for quite some time. Personally, I am grateful that you and Daniel are free to do the work that you are doing. If you get a sense of frustration from Ralph, perhaps you can read that as the frustration that he himself doesn't have the kind of free time to give to it that you do. For Ralph to be able to contribute, he needs to be able to justify it. If you could help him justify it, he may help sooner. Otherwise, he'll just carry on waiting. Either, in the end, is just going to have to be fine. But then, surely all of the above is obvious, no? Regards, Upayavira
Re: [FYI] GSoC 2006 announced!
Bertrand Delacretaz wrote: Most of you have probably seen it already, Google has officially announced Summer Of Code 2006: http://code.google.com/soc/ I'll probably suggest a project to expand the scope of automated testing of our 2.1.x workhorse branch. That would be great, but what we _really_ need is help getting 2.2 (with or without OSGi) out. Are there chunks of work that are both interesting and challenging, but not too challenging, that could be made into Gsoc projects? That's what we really need to help move our project on. Maybe the creation of a sitemap servlet, or a javascript servlet? Or a proposal for a pull pipeline servlet? Or some other block deployer code or something? Thoughts? Regards, Upayavira
Re: [FYI] GSoC 2006 announced!
Upayavira wrote: Bertrand Delacretaz wrote: Most of you have probably seen it already, Google has officially announced Summer Of Code 2006: http://code.google.com/soc/ I'll probably suggest a project to expand the scope of automated testing of our 2.1.x workhorse branch. That would be great, but what we _really_ need is help getting 2.2 (with or without OSGi) out. Are there chunks of work that are both interesting and challenging, but not too challenging, that could be made into Gsoc projects? That's what we really need to help move our project on. Maybe the creation of a sitemap servlet, or a javascript servlet? Or a proposal for a pull pipeline servlet? Or some other block deployer code or something? Thoughts? e.g. reimplementing the CLI based on the new technology. I'd happily mentor that project (something I'd like to do myself but won't have time). Upayavira
Re: Blocked website playboy.com
Gerald Kaplan wrote: I've tried to download the latest version of Cocoon, but the webserver name chosen to host the distributions is indicative of a porn site and is blocked by IBM. Any chance that it will be changed anytime soon? Or, is there another place I can download the source from? Playboy offered to be a mirror site for Apache. Saying no was considered, but it was extremely difficult to identify what boundaries should be placed, and given that nothing that they do or say anything illegal, it was decided to allow them to offer a mirror. If you are unable to access that mirror, the download page should allow you to change the mirror site you are using. Regards, Upayavira
Re: A new CLI (was Re: [RT] The environment abstraction, part II)
Thorsten Scherler wrote: El lun, 03-04-2006 a las 12:34 +0100, Upayavira escribió: Thorsten Scherler wrote: El lun, 03-04-2006 a las 09:00 +0100, Upayavira escribió: David Crossley wrote: Upayavira wrote: Sylvain Wallez wrote: Carsten Ziegeler wrote: Sylvain Wallez wrote: Hmm... the current CLI uses Cocoon's links view to crawl the website. So although the new crawler can be based on servlets, it will assume these servlets to answer to a ?cocoon-view=links :-) Hmm, I think we don't need the links view in this case anymore. A simple HTML crawler should be enough as it will follow all links on the page. The view would only make sense in the case where you don't output html where the usual crawler tools would not work. In the case of Forrest, you're probably right. Now the links view also allows to follow links in pipelines producing something that's not HTML, such as PDF, SVG, WML, etc. We have to decide if we want to loose this feature. I am not sure if we use this in Forrest. If not then we probably should be. In my view, the whole idea of crawling (i.e. gathering links from pages) is suboptimal anyway. For example, some sites don't directly link to all pages (e.g. they are accessed via javascript, or whatever) so you get pages missed. Were I to code a new CLI, whilst I would support crawling I would mainly configure the CLI to get the list of pages to visit by calling one or more URLs. Those URLs would specify the pages to generate. Thus, Forrest would transform its site.xml file into this list of pages, and drive the CLI via that. This is what we do do. We have a property start-uri=linkmap.html http://forrest.zones.apache.org/ft/build/cocoon-docs/linkmap.html (we actually use corresponding xml of course). We define a few extra URIs in the Cocoon cli.xconf There are issues of course. Sometimes we want to include directories of files that are not referenced in site.xml navigation. For my sites i just use a DirectoryGenerator to build an index page which feeds the crawler. Sometime that technique is not sufficent. We also gather links from text files (e.g. CSS) using Chaperon. This works nicely but introduces some overhead. This more or less confirms my suggested approach - allow crawling at the 'end-point' HTML, but more importantly, use a page/URL to identify the pages to be crawled. The interesting thing from what you say is that this page could itself be nothing more than HTML. Well, yes and not really, since e.g. Chaperon is text based and no markup. You need a lex-writer to generate links for the crawler. Yes. You misunderstand me I think. Yes, sorry I did misunderstood you. Even if you use Chaperon etc to parse markup, there'd be no difficulty expressing the links that you found as an HTML page - one intended to be consumed by the CLI, not to be publically viewed. Well in the case of css you want them as well publically viewed but I got your point. ;) In fact, if it were written to disc, forrest would probably delete it afterwards. Forrest actually is *not* aimed for html only support and one can think of the situation that you want your site to be only txt (kind of a book). Here you need to crawler the lex-rewriter outcome and follow the links. Hopefully I've shown that I had understood that already :-) yeah ;) The current limitation of forrest regarding the crawler are IMO not caused by the crawler design but rather by our (as in forrest) usage of it. Yep, fair enough. But if the CLI is going to survive the shift that is happening in Cocoon trunk, something big needs to be done by someone. It cannot survive in its current form as the code it uses is changing almost beyond recognition. Heh, perhaps the Cocoon CLI should just be a Maven plugin. ...or forrest plugin. ;) This would makes it possible that cocoon, lenya and forrest committer can help. Kind of http://svn.apache.org/viewcvs.cgi/lenya/sandbox/doco/ ;) Well, in the end, it is he who implements that decides. Upayavira
Re: A new CLI (was Re: [RT] The environment abstraction, part II)
David Crossley wrote: Upayavira wrote: Sylvain Wallez wrote: Carsten Ziegeler wrote: Sylvain Wallez wrote: Hmm... the current CLI uses Cocoon's links view to crawl the website. So although the new crawler can be based on servlets, it will assume these servlets to answer to a ?cocoon-view=links :-) Hmm, I think we don't need the links view in this case anymore. A simple HTML crawler should be enough as it will follow all links on the page. The view would only make sense in the case where you don't output html where the usual crawler tools would not work. In the case of Forrest, you're probably right. Now the links view also allows to follow links in pipelines producing something that's not HTML, such as PDF, SVG, WML, etc. We have to decide if we want to loose this feature. I am not sure if we use this in Forrest. If not then we probably should be. In my view, the whole idea of crawling (i.e. gathering links from pages) is suboptimal anyway. For example, some sites don't directly link to all pages (e.g. they are accessed via javascript, or whatever) so you get pages missed. Were I to code a new CLI, whilst I would support crawling I would mainly configure the CLI to get the list of pages to visit by calling one or more URLs. Those URLs would specify the pages to generate. Thus, Forrest would transform its site.xml file into this list of pages, and drive the CLI via that. This is what we do do. We have a property start-uri=linkmap.html http://forrest.zones.apache.org/ft/build/cocoon-docs/linkmap.html (we actually use corresponding xml of course). We define a few extra URIs in the Cocoon cli.xconf There are issues of course. Sometimes we want to include directories of files that are not referenced in site.xml navigation. For my sites i just use a DirectoryGenerator to build an index page which feeds the crawler. Sometime that technique is not sufficent. We also gather links from text files (e.g. CSS) using Chaperon. This works nicely but introduces some overhead. This more or less confirms my suggested approach - allow crawling at the 'end-point' HTML, but more importantly, use a page/URL to identify the pages to be crawled. The interesting thing from what you say is that this page could itself be nothing more than HTML. Regards, Upayavira
Re: What's going on with gump?
Reinhard Poetz wrote: Bertrand Delacretaz wrote: Le 3 avr. 06 à 09:08, Gump a écrit : ... -DEBUG- Sole output [chaperon-20040205.jar] identifier set to project name -INFO- Failed with reason missing build outputs -ERROR- Missing Output: /usr/local/gump/public/workspace/cocoon/ lib/optional/chaperon-20040205.jar -ERROR- No such directory (where output is expected) : /usr/local/ gump/public/workspace/cocoon/lib/optional... What's up here? Is gump trying to build the trunk with the old ant build system? I'm not too sure about where to look for details on what exactly gump is trying to do The error above seems to be caused by the missing lib/optional directory as I removed them last week. If somebody wants to reactivate gump again, he should start incrementally and write a gump descriptor for cocoon-core but please make sure that we don't have any svn:externals in trunk; I removed the svn:externals link to gump.xml. Well that is going to break things. That SVN external was to allow Gump people write access to our gump descriptor. How come you removed it? It was placed there in discussion with this list and with the Gump peeps. Regards, Upayavira
Re: What's going on with gump?
Reinhard Poetz wrote: Upayavira wrote: Reinhard Poetz wrote: Bertrand Delacretaz wrote: Le 3 avr. 06 à 09:08, Gump a écrit : ... -DEBUG- Sole output [chaperon-20040205.jar] identifier set to project name -INFO- Failed with reason missing build outputs -ERROR- Missing Output: /usr/local/gump/public/workspace/cocoon/ lib/optional/chaperon-20040205.jar -ERROR- No such directory (where output is expected) : /usr/local/ gump/public/workspace/cocoon/lib/optional... What's up here? Is gump trying to build the trunk with the old ant build system? I'm not too sure about where to look for details on what exactly gump is trying to do The error above seems to be caused by the missing lib/optional directory as I removed them last week. If somebody wants to reactivate gump again, he should start incrementally and write a gump descriptor for cocoon-core but please make sure that we don't have any svn:externals in trunk; I removed the svn:externals link to gump.xml. Well that is going to break things. That SVN external was to allow Gump people write access to our gump descriptor. How come you removed it? It was placed there in discussion with this list and with the Gump peeps. Sorry for not bringing this issue to the list. IIUC I didn't delete the descriptor but only the link to it as gump.xml is located in the gump SVN. We can add the svn:external to our repository for convenience but please don't do it within trunk - /cocoon/gump would be a better idea IMHO. Actually, this is fair enough, as we no longer depend upon Gump for our build process. - o - More generally, we need to decide what we do with it as gump.xml as it is today is totally broken because of the move to Maven 2 (e.g. we are relying on many libraries within the repository; many source directories have changed, etc.). Basically the gump descriptor expresses the same dependencies as the pom.xml and I doubt our community will take care of both. BTW, is anybody taking care of a working Gump descriptor? The best solution would be Gump that can work based on pom.xml descriptors ... I did see some discussion on Gump working with Maven2, but have since unsubscribed from [EMAIL PROTECTED], as I was hardly reading it. So in time, maybe Gump itself will run off pom files where they exist. Regards, Upayavira
Re: What's going on with gump?
Bertrand Delacretaz wrote: Le 3 avr. 06 à 10:51, Reinhard Poetz a écrit : ...More generally, we need to decide what we do with it as gump.xml as it is today is totally broken because of the move to Maven 2... While gump is unable to build our trunk, we could at least have it build the 2.1.x branch? I assume this requires pointing gump to the old 2.1.x descriptor, but I don't know how to do that. The point of having the SVN external was that all Apache committers have commit rights to the Gump area. So, if someone wanted to have Gump build 2.1.x (which makes some sense to me), it would be: a) Check that's okay with the Gump community b) Commit the 2.1.X gump.xml on top of the existing one in the gump SVN c) Create an SVN external in 2.1.X SVN to the gump SVN Upayavira
Re: A new CLI (was Re: [RT] The environment abstraction, part II)
Thorsten Scherler wrote: El lun, 03-04-2006 a las 09:00 +0100, Upayavira escribió: David Crossley wrote: Upayavira wrote: Sylvain Wallez wrote: Carsten Ziegeler wrote: Sylvain Wallez wrote: Hmm... the current CLI uses Cocoon's links view to crawl the website. So although the new crawler can be based on servlets, it will assume these servlets to answer to a ?cocoon-view=links :-) Hmm, I think we don't need the links view in this case anymore. A simple HTML crawler should be enough as it will follow all links on the page. The view would only make sense in the case where you don't output html where the usual crawler tools would not work. In the case of Forrest, you're probably right. Now the links view also allows to follow links in pipelines producing something that's not HTML, such as PDF, SVG, WML, etc. We have to decide if we want to loose this feature. I am not sure if we use this in Forrest. If not then we probably should be. In my view, the whole idea of crawling (i.e. gathering links from pages) is suboptimal anyway. For example, some sites don't directly link to all pages (e.g. they are accessed via javascript, or whatever) so you get pages missed. Were I to code a new CLI, whilst I would support crawling I would mainly configure the CLI to get the list of pages to visit by calling one or more URLs. Those URLs would specify the pages to generate. Thus, Forrest would transform its site.xml file into this list of pages, and drive the CLI via that. This is what we do do. We have a property start-uri=linkmap.html http://forrest.zones.apache.org/ft/build/cocoon-docs/linkmap.html (we actually use corresponding xml of course). We define a few extra URIs in the Cocoon cli.xconf There are issues of course. Sometimes we want to include directories of files that are not referenced in site.xml navigation. For my sites i just use a DirectoryGenerator to build an index page which feeds the crawler. Sometime that technique is not sufficent. We also gather links from text files (e.g. CSS) using Chaperon. This works nicely but introduces some overhead. This more or less confirms my suggested approach - allow crawling at the 'end-point' HTML, but more importantly, use a page/URL to identify the pages to be crawled. The interesting thing from what you say is that this page could itself be nothing more than HTML. Well, yes and not really, since e.g. Chaperon is text based and no markup. You need a lex-writer to generate links for the crawler. Yes. You misunderstand me I think. Even if you use Chaperon etc to parse markup, there'd be no difficulty expressing the links that you found as an HTML page - one intended to be consumed by the CLI, not to be publically viewed. In fact, if it were written to disc, forrest would probably delete it afterwards. Forrest actually is *not* aimed for html only support and one can think of the situation that you want your site to be only txt (kind of a book). Here you need to crawler the lex-rewriter outcome and follow the links. Hopefully I've shown that I had understood that already :-) The current limitation of forrest regarding the crawler are IMO not caused by the crawler design but rather by our (as in forrest) usage of it. Yep, fair enough. But if the CLI is going to survive the shift that is happening in Cocoon trunk, something big needs to be done by someone. It cannot survive in its current form as the code it uses is changing almost beyond recognition. Heh, perhaps the Cocoon CLI should just be a Maven plugin. Upayavira
Re: What's going on with gump?
Ralph Goers wrote: Reinhard Poetz wrote: yes, according to the mails above sometime in the future it will work. - o - If somebody has time to fix gump.xml so that it builds at least cocoon-core it would be a good idea. If not, we should simply ask the Gump folks to remove the descriptor. WDOT? Everytime gump breaks I find myself wondering why anybody cares? Can someone educate me on what is better about gump then us running Continuum? Firstly, I am no expert on Gump. You can see Gump as more of a social thing - it not just related to our own pretty little project - it builds _everything_. It checks out trunk on a huge number of projects and builds them, thus ensuring that all projects continue to work together in their trunk versions. So think of it as one huge Continuum for _all_ Apache software and beyond, not just for Cocoon. As such, it will tell us if, for some reason, Cocoon wouldn't compile on Kaffe, or if one of our dependencies changed its interface and that broke our code. Cocoon is a fantastic project for the Gump people, because we have s many dependencies. If Cocoon builds, that means all of its dependencies, and their dependencies, etc, all built too, which as I understand it doesn't happen that often :-) So, yes, it is a valuable resource, but on a broader scale than just our own project. Regards, Upayavira
Re: A new CLI (was Re: [RT] The environment abstraction, part II)
Sylvain Wallez wrote: Carsten Ziegeler wrote: Sylvain Wallez wrote: Hmm... the current CLI uses Cocoon's links view to crawl the website. So although the new crawler can be based on servlets, it will assume these servlets to answer to a ?cocoon-view=links :-) Hmm, I think we don't need the links view in this case anymore. A simple HTML crawler should be enough as it will follow all links on the page. The view would only make sense in the case where you don't output html where the usual crawler tools would not work. In the case of Forrest, you're probably right. Now the links view also allows to follow links in pipelines producing something that's not HTML, such as PDF, SVG, WML, etc. We have to decide if we want to loose this feature. In my view, the whole idea of crawling (i.e. gathering links from pages) is suboptimal anyway. For example, some sites don't directly link to all pages (e.g. they are accessed via javascript, or whatever) so you get pages missed. Were I to code a new CLI, whilst I would support crawling I would mainly configure the CLI to get the list of pages to visit by calling one or more URLs. Those URLs would specify the pages to generate. Thus, Forrest would transform its site.xml file into this list of pages, and drive the CLI via that. Whilst gathering links from within pipelines is clever, it always struck me as awkward at the same time. Regards, Upayavira
A new CLI (was Re: [RT] The environment abstraction, part II)
Carsten Ziegeler wrote: Upayavira wrote: David Crossley wrote: Carsten Ziegeler wrote: I can't speak for Daniel, but my idea/suggestion was to forget about the different environments and let Cocoon always run in a servlet container. The CLI would then be kind of a http client which starts up jetty and then generates the site using http requests. This would simplify some things in Cocoon, the question is if this would make the life of Forrest too hard? Thanks to you all for the followup. I don't have a ready answer yet. Will make sure that the other Forrest people are aware. In the end, it doesn't really matter that much, and will be up to whoever volunteers to implement the new CLI. It depends a little bit on how we see things. My opinion :) is to remove the environment abstraction completly and simply use the servlet environment while others might think that we should only base our environment abstraction on the servlet api but allow to run Cocoon in a different environment which provides *some* features of the servlet environment but not all. The difference might be subtle, but its not the same. Ah, I wasn't getting that subtle. I was simply saying that I can agree with using the servlet API for _all_ environments. The CLI becomes nothing more than a custom servlet container that uses a servlet to generate its pages. In fact, having said that, it becomes yet another tool that is actually independent of Cocoon - it could be used to crawl pages generated by _any_ servlet, not just the Cocoon one. Regards, Upayavira
Re: [RT] The environment abstraction, part II
David Crossley wrote: Carsten Ziegeler wrote: I can't speak for Daniel, but my idea/suggestion was to forget about the different environments and let Cocoon always run in a servlet container. The CLI would then be kind of a http client which starts up jetty and then generates the site using http requests. This would simplify some things in Cocoon, the question is if this would make the life of Forrest too hard? Thanks to you all for the followup. I don't have a ready answer yet. Will make sure that the other Forrest people are aware. In the end, it doesn't really matter that much, and will be up to whoever volunteers to implement the new CLI. Having said that, I think it makes sense for the CLI to have its own, minimal servlet container. It could just use Jetty, but it would be better/faster if the container didn't serve over http, i.e. require an http client too. Regards, Upayavira
Re: [RT] The environment abstraction, part II
Daniel Fagerstrom wrote: Carsten Ziegeler skrev: David Crossley wrote: Hi Daniel, sorry i cannot understand that last sentence. Would you please re-phrase it. We currently have the three ways: 'forrest run' Starts its packaged Jetty and uses Forrest/Cocoon as a webapp. 'forrest war' Builds a projectName.war ready for deployment in a full Jetty or Tomcat. 'forrest site' Calls the Cocoon CLI to generate a static set of docs. I can't speak for Daniel, but my idea/suggestion was to forget about the different environments and let Cocoon always run in a servlet container. The CLI would then be kind of a http client which starts up jetty and then generates the site using http requests. This would simplify some things in Cocoon, the question is if this would make the life of Forrest too hard? In Cocoon today, the Cocoon object that implements the Processor interface is in some way the top level interface against Cocoon functionality. Then the CocoonServlet and the CLI booth sets up and use the Cocoon object. When creating the blocks fw, Processor didn't work as abstraction as it contains lots of tree processor specifics. So I decided to use the Servlet and javax.servlet.http set of interfaces instead (as discussed on the list a couple of times). This means that the CLI in it current state (working against the Processor interface) doesn't work with the blocks fw. So the CLI needs to be refactored so that it works with a Servlet rather than a Processor. To some extent this is actually an advantage as the CocoonServlet and the CLI has a lot of overlap and the servlet part has been maintained and developed while the CLI part hasn't. By using Servlet as the top level interface of Cocoon the CLI will be much smaller and reuse more of the Servlet work. Back to your question, my incomprehensible sentence was an answer to something like what Carsten propose above. In many cases I agree with Carsten that it makes most sense to run Cocoon in a full servlet container but in some cases, e.g. testing and for a minimal OSGi setup, it makes IMO sense to have a really light weight and minimal servlet container instead. I have built a such one for creating the servlet environment needed for running a servlet within a block and make it possible for it to communicate with other blocks. It is also used for the block protocol (the block correspondence to the Cocoon protocol). We could reuse part of this for the CLI. So the current CLI is a minimal command line Processor container, we could have a minimal command line Servlet container instead. This makes complete sense to me and is exactly how I would have proposed implementing it. Upayavira
Re: Deployment into a monolithic Cocoon web app
Reinhard Poetz wrote: Giacomo Pati wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sat, 25 Mar 2006, Bertrand Delacretaz wrote: Date: Sat, 25 Mar 2006 21:32:13 +0100 From: Bertrand Delacretaz [EMAIL PROTECTED] Reply-To: dev@cocoon.apache.org To: dev@cocoon.apache.org Subject: Re: Deployment into a monolithic Cocoon web app Le 25 mars 06 à 15:37, Reinhard Poetz a écrit : ...What do you have to do to run trunk?... Your instructions worked for me as well, but it took *ages*. IIUC it's because Maven was trying to download stuff, getting timeouts, retrying etc, lines like [INFO] artifact org.apache.maven.plugins:maven-compiler-plugin: checking for updates from mortbay-repo This may be due to snapshot dependencies which Maven2 resolves periodically (depends on configuration). sometimes stay on screen for several minutes without anything apparently happening. It seems that it depends on day or person or connectivity or whatever. I've build trunk so many times with almost always successfully building in one go with none of the issues many have reported. I do really have no clue whether it is the connectivity on the Apache side or on the person side doing the build that causes those issues. I'm (still) a Maven newbie so I might be doing something wrong, but it looks like your deployer works, congratulations! The instructions works here, too. Thanks for the verification. I think the general problem is that you need to have downloaded the artifacts once as Maven have to put them into the local artifacts repository. Indeed, this can take very long if Maven is used for the first them. But then, it should work fine in the future as further downloads are the exception and not the rule. Yes, but here we're talking about downloading stuff needed to build Cocoon aren't we? So we end up downloading _all_ dependencies. I've no problem with that particularly. What I want to see is small, snappy binary distributions. If we still have a large source download, that's fine with me. And, IIUC, what we're doing is in line with that. Regards, Upayavira
Re: Make bugzilla for cocoon read only.
Antonio Gallardo wrote: Dear infra, Is posible to close bugzilla for cocoon? We now use JIRA. Apparently not. It would have been otherwise. Upayavira
Re: Deployment into a monolithic Cocoon web app
Reinhard Poetz wrote: Carsten Ziegeler wrote: Reinhard Poetz wrote: 0. checkout complete trunk and $ mvn clean install -Dmaven.test.skip=true Call this as long as you get BUILD SUCCESSFUL. 1. go to cocoon-webapp $ mvn cocoo:deploy $ mvn jetty6:run 2. point your browser to http://localhost:/ or http://localhost:/apps/cocoon-deployer-plugin-demo/test Please report back if it works for you too. Repeated stage 0 a painful number of times. Then ran mvn cocoo:deploy and mvn cocoon:deploy. Both gave: [INFO] Scanning for projects... [INFO] Reactor build order: [INFO] Apache Cocoon [INFO] Various Maven Archetypes [INFO] Cocoon Core ... [INFO] Validation Block Implementation [INFO] Validation Block Sample [INFO] Core Webapp [INFO] Searching repository for plugin with prefix: 'cocoon'. [INFO] [ERROR] BUILD ERROR [INFO] [INFO] The plugin 'org.apache.maven.plugins:maven-cocoon-plugin' does not exist or no valid version could be found [INFO] [INFO] For more information, run Maven with the -e switch [INFO] [INFO] Total time: 1 second [INFO] Finished at: Mon Mar 27 19:28:09 BST 2006 [INFO] Final Memory: 2M/5M [INFO] Or, for cocoon:deploy it said: [INFO] The plugin 'org.apache.maven.plugins:maven-cocoo-plugin' does not exist or no valid version could be found What's up? Upayavira
Re: [vote result] Niclas Hedhman as a new Cocoon committer
Daniel Fagerstrom wrote: Niclas Hedhman has been elected as a Cocoon committer with 21 1+ and no other votes. Welcome Niclas! He has an account (user name: niclas, I think) since before, so just commit access is needed. Can someone with power take care about that (Upayavira)? Done. Upayavira
Re: Deployment into a monolithic Cocoon web app
Bertrand Delacretaz wrote: Le 27 mars 06 à 20:44, Upayavira a écrit : ...Then ran mvn cocoo:deploy and mvn cocoon:deploy.. AFAIK It's cocoon:deploy, not cocoo:deploy Tried both. No luck with either. Upayavira
Re: Deployment into a monolithic Cocoon web app
Antonio Gallardo wrote: Upayavira escribió: Tried both. No luck with either. Are you using maven 2.0.2? $ mvn -version Maven version: 2.0.2 Upayavira
Re: Deployment into a monolithic Cocoon web app
Reinhard Poetz wrote: Upayavira wrote: [INFO] The plugin 'org.apache.maven.plugins:maven-cocoo-plugin' does not exist or no valid version could be found What's up? You have to run it from cocoon/trunk/cocoon-webapp. Ah, yes. That did it. Now, being stupid, are we supposed to see samples now, or just the webapp itself? I'm not yet entirely sure what I've just done :-) Regards, Upayavira
Re: [vote] Simone Gianni as a new Cocoon committer
Sylvain Wallez wrote: Hi all, It's spring time, new committers are blossoming! I'd like to propose Simone Gianni for Cocoon committership. Simone has contributed interesting additions and bug fixes to CForms that show a very good understanding of this stuff, and is participating more and more to discussions. It's time for him to be able to commit his patches himself! Please cast your votes. +1 Regards, Upayavira
Re: Voting on releases?
Bertrand Delacretaz wrote: Le 21 mars 06 à 18:42, Jean-Baptiste Quenot a écrit : ...Is there a rule requiring new releases to be first approved by a vote?... Maybe not, but we've been doing it this way for about 25 years and it works ;-) Seriously, making sure we agree on release plans (code freeze dates etc.) is a Good Thing - I've seen several projects arguing or disagreeing on releases, so it's certainly good to be a bit careful and to make sure everyone is on the same page. It doesn't cost much and there are at least social benefits. So, +1 for voting on release plans ;-) A release is the primary output of a PMC on behalf of the ASF. You could say that producing releases is what a project exists for. So releases _can not_ be done without a vote, with PMC member's votes being the binding ones. And probably new releases, once done, should be noted to the board in a quarterly board report. There you go. That's the Bureaucracy of it. Regards, Upayavira
Re: [RT] a simple release plan
Andreas Hochsteger wrote: Daniel Fagerstrom wrote: Ralph Goers skrev: Andrew Savory wrote: Hi, Ralph Goers wrote: 1. I'm pretty sure all the blocks have not been mavenized. Is there a list of blocks to mavenise anywhere, with instructions of how to do it? I don't mind helping with this. The easy way to tell I suppose is to check out trunk. There are a bunch of cocoon-whatever directories. Compare that list with what is in src/blocks in 2.1. I believe the instructions are in README.m10n.txt. Actually all the trunk blocks http://svn.apache.org/repos/asf/cocoon/blocks/ was Mavenized once. Then two things happened: 1) We decided to change to change directory structure to something that followed the Maven standard, and that had some other advantages: http://cocoon.zones.apache.org/daisy/documentation/g1/756.html. All blocks with the new structure are moved to the trunk. 2) We changed group id from apache-cocoon to org.apache.cocoon (in trunk). As the later is the recomended structure for M2. Most of the blocks in http://svn.apache.org/repos/asf/cocoon/blocks/ would probably build again just by fixing the group id. It would of course be nice to switch all to the new directory structure, but that can be done one block at the time when someone feel the itch. Is there something that persons without SVN access can help with? The instructions for the m10n of Cocoon Blocks require SVN access for moving directories and files. Nevertheless I'd be glad to help by providing patches via Jira, if somebody could tell me what might be doable for me. I already was able to build the trunk with Maven and run the Welcome page - but without samples so far. The subversion part is the easiest bit. Working out exactly how to make it work is very useful and doesn't require SVN commit rights. Although, if you do move directories, try using svn move, as it will likely make for better svn patch or svn diff output at the end of the process. Personally, I would say go for it. Anything anyone can do would be great, and is much needed right now. Regards, Upayavira
Re: Script for m10n of blocks (was Re: [RT] a simple release plan)
Andreas Hochsteger wrote: I successfully built cocoon-linkrewriter using 'mvn package' with the converted directory structure using the conversion script and 2 new and one adopted pom file. I wanted to attach them, but for some reasons my SMTP server rejected them as SPAM. :-( I used the following conventions for the block poms: * version: 1.0-SNAPSHOT * sample depends only on impl * impl depends on cocoon-core (and other direct dependencies) - based on the existing pom of the old block * parent declares sample and impl as modules Could somebody please have a look at the attached poms? I'll try to extend the script to generate the parent and sample poms automatically and adjust the impl pom (based on the old block pom). Create a jira issue and attach any files relating to this work to that issue. You're doing good work. Regards, Upayavira
Re: [RT] OSGi based blocks
Daniel Fagerstrom wrote: Upayavira skrev: My own reflections on this is whether or not this is still Cocoon. It seems to me that you are creating a framework for managing web applications based upon servlets, OSGi and the URLConnections. This doesn't seem all that specific to Cocoon - it seems more general than that, and potentially more generally useful too. I have had similar reflections. From a technical stand point it could be developed in some other community as it doesn't depend on the rest of Cocoon. But as it is based on years of community work from Cocoon, I think it belongs to Cocoon. Also I think we have some agreement that we should make more parts of Cocoon reusable outside Cocoon and then the same will be the case for them as well. Cocoon's contribution would be its SitemapServlet, and other such elements. So, my question: Is this still cocoon, or is it becoming something more general than that (e.g. that could become a Felix sub-project) - thus gaining a far wider adoption? We should develop it to a point where it works for Cocoon first ;) I'm very interested in suggestions about how we could cooperate with the Felix community about this. As you suggest it could be interesting for some of them and feedback from the OSGi community would be very valuable. Okay. I'm glad we seem to be on the same page with this. It would seem sensible to continue development here in this community - get it working to a point when we can demonstrate it, then we can show it off to others and see who is interested, and where its future home lies. Maybe elsewhere, or maybe the meaning of 'Cocoon' changes. But for now it makes sense to stay precisely here. Regards, Upayavira
Re: [RT] a simple release plan
Reinhard Poetz wrote: Upayavira wrote: Carsten has offered a suggestion that _he_ is prepared to implement. I would like to hear other proposals from people of things that _they_ are prepared to implement. Only that way will we move beyond this impass. There are many documents that explain the roadmap Daniel and I follow ATM. The only thing we are asking for is that we all work on trunk. Everything else is another internal fork (didn't we agree that this was a bad idea?) and we have to make sure again that everything gets synced again and again. That's the reason for the -1 on Carsten's proposal of Daniel and me. So what's the overhead for people that want to work on trunk? They should make sure that the testcases run through and they should run the samples before they commit. Is this such a special requirement? Does somebody have to understand in detail what the testcases cover? If a testcase gets broken *locally* by a developer, the developer should discuss the change on [EMAIL PROTECTED] and then people can decide together how to proceed. That should be the standard procedure in every development project, may it be opensource or commercial. Can we agree on these very basic rules? The overhead for people to work on trunk is that trunk is largely unknown. It is my perception that many people have little confidence that trunk actually works. Fear that it will change frequently, and that they will have to invest a lot of effort (time which they don't have) in order to keep up. That's the concern I'm trying to address. Not whether trunk _actually_ works, but how people in our community _feel_ about it. It may be just 'emotion', but it really is important, as, IMO, emotion (or could I say emotional investment) is the fundamental underpinning of our community. If that fades away, away with it goes our community. I'm looking for ideas of ways and suggestions as to how our community can move on with this more 'fuzzy' stuff - and get more of us developing and innovating again. Upayavira
Re: [RT] a simple release plan
Peter Hunsberger wrote: On 3/16/06, Upayavira [EMAIL PROTECTED] wrote: snip/ Thus, we have 'one way' of doing it, that people don't want to follow, for their own reasons, and because of this, nothing at all happens, and our community gets weaker by the day. Oh, come on. There's no real evidence for this being true. This is my opinion, based upon personal conversations over time, and observations I have heard others make. If it is happening it is only because people start to spread FUD instead of putting some energy into actually trying to work with trunk You can view what I say as FUD if you like, although I clearly don't see it that way. The problem for me is that I don't have the time to invest in dealing with the sorts of issues that people have already mentioned in relation to working with trunk. Yes, it can work, if you give it the effort. But in order to scratch _my_ itch, I currently need to invest in core infrastructure stuff to get trunk working at all, and it may well be the sort of thing that I personally am not suited to doing. We need to have the scope for differences, alternative approaches, conflicts, etc, and then switch to the best when a best clearly shows itself. What we have now is one unimplemented ideal that we are supposedly working towards (I'm talking of the community here, not you yourself). And that ideal is for some psychological reason preventing others from engaging with their own ideas. It is that psychological block that I want to find ways to remove. Really, what the technology is that helps to remove that block, I do not care. I just want to see that block removed so that the creativity of the many can flow again. Once more I ask: what is that you want to do that you can't currently do? I want to see active development of trunk by more than a limited few. Carsten has offered a suggestion that _he_ is prepared to implement. I would like to hear other proposals from people of things that _they_ are prepared to implement. Only that way will we move beyond this impass. Daniel and Bertrand have already given you a reasonable proposal. Yes, I liked Bertrand's idea. Not sure which one of Daniel's you were referring to. What I'm trying to do is encourage people to brin forward proposals that _they_ are prepared to implement, not ones that _others_ might implement. Carsten's proposal sounds reasonable on the surface, but the fact is, that it will actually take a lot of focus away from the current trunk. For years people have been saying they need real blocks, now all of a sudden, there is a need to split a new fork so that a Spring based container can get released? I don't get it: sure it will help some people, so will real blocks. It seems to me that if the same energy was spent getting the current trunk cleaned up that would go into a 2.3 release this discussion) then the job would be done. For years some people have been saying they need real blocks, and others have been wondering what all of the fuss is about. Here's an analogy for you: a man gets engaged to a woman he has loved for many years. A week before the wedding his buddies take him out for a bachelor party and he falls in lust with a young dancer who flirts with him (and happens to take a lot of money from his buddies without him really noticing). Should he break off his engagement with his fiance to start chasing the young dancer? That isn't at all what I am proposing. I want to see 'ordinary' cocoon development happening in parallel with real blocks, rather than ordinary development stalled while waiting for real blocks. Regards, Upayavira
Re: [RT] a simple release plan
Jean-Baptiste Quenot wrote: * Sylvain Wallez: Daniel says that classical Cocoon code doesn't depend on the infrastructure that's being built for real blocks and OSGi. And we seem pretty close to a full M10N. AFAIU, what's needed to finish it is mainly the equivalent of build webapp. Exactly! If the above assumptions are true, splitting the code base and going back to the Ant build seems a huge step backwards, and would relegate OSGi and M10N to scratchpad status. Keeping M10N and providing a « build webapp » script is definitely the way to go. Is that a volunteer? ;-) Regards, Upayavira
Re: [RT] OSGi based blocks
My own reflections on this is whether or not this is still Cocoon. It seems to me that you are creating a framework for managing web applications based upon servlets, OSGi and the URLConnections. This doesn't seem all that specific to Cocoon - it seems more general than that, and potentially more generally useful too. Cocoon's contribution would be its SitemapServlet, and other such elements. So, my question: Is this still cocoon, or is it becoming something more general than that (e.g. that could become a Felix sub-project) - thus gaining a far wider adoption? Regards, Upayavira Daniel Fagerstrom wrote: I have worked on implementing the blocks framework in terms of OSGi for some time. Not everything is working yet, but I think it is time to start discussing the involved ideas. As already discussed I have refactored the blocks fw to reuse as much as possible form the servlet APIs. While studying OSGi R4 and especially the new declarative services (DS), I have seen that much of what we want to accomplish with blocks already is solved in OSGi, although sometimes in a different way. I have experimented with implementing the blocks fw in terms of DS, and am quite happy with the results. The new architecture is less monolithic than the previous one and there is not much code at all, most of it is OSGi based design patterns. --- o0o --- So, now over to the actual design. As before we have a number of different parts (not everything implemented yet): * A dispatcher - where the blocks are mounted with their respective prefixes. * Inter block component management - a block can make its components available to other blocks, and use components from other blocks. * Component manager bridges- the components within a block can be setup by our ECM/Spring container or maybe by some other kind of container. * Inter block communication and polymorphism - a sitemap, and more generally a servlet, can call servlets in other blocks. And there is also inheritance so that one sitemap (or servlet) can extend another one. * Dynamic deployment and configuration - the blocks can be installed, updated, reconfigured and removed dynamically while the rest of the framework is executing. In the rest of the RT we will step through these parts and look at the design. But first a little bit about DS, that is used everywhere in the design and replaces block.xml among other things in the current design. Declarative Services The declarative services simplify service (component) handling in OSGi by making it possible to declare services and their dependencies in an XML file (before service management wasn't configuration file based in OSGi). The DS supports setter injection. Compared to Spring it is rather small and primitive. The cool thing about it is that it support dynamic dependencies. A dynamic dependency can have both a setter and an un-setter. The framework also takes care of stopping and starting non-dynamic components when their dependencies comes and goes. The DS can be used together with a configuration service that can override the default configurations in the DS XML file. The configuration service can take part of the responsibility that the wiring file and deployer takes in the current architecture. There is not much documentation for the DS yet, so the main references are the specification [1] and the documentation of the service binder [2] that was a predecessor of DS. The dispatcher == The role of the dispatcher is that the blocks (servlets) are mounted in it based together with their URI prefixes. The dispatcher then call the blocks based on the incoming URIs. This is already handled by the OSGi HTTP service which provides a service that a servlet can lookup and register it self in. A HTTP service implementation normally contains a HTTP server. But an alternative for embedding OSGi managed servlets in a servlet container is to use a HTTP service that acts as a bridge to the embedding servlet container [3]. It is also inconvenient to require the servlets to lookup the HTTP service. It is better to use the whiteboard pattern [4], and just register the servlets as services and have a component that reacts on the appearance and disappearance of servlet services, and register and unregister them in the HTTP service respectively. Using DS a declaration (which is referred to by the Service-Component property in the manifest file) for a whiteboard adapter can look like [5]: scr:component name=cocoon.activator scr:implementation class=org.apache.cocoon.blocks.osgi.Activator/ scr:reference name=LOG interface=org.osgi.service.log.LogService bind=setLog/ scr:reference name=HTTP interface=org.osgi.service.http.HttpService bind=setHttpService/ scr:reference name
Re: [RT] OSGi based blocks
Ralph Goers wrote: Please Daniel, don't take this personally as it isn't really directed at you. Part of it is directed at myself as I haven't had any significant amount of time to contribute to this work. I guess I'm just wondering if I'm the only one who is feeling this way? If so, I'll stop my whining. I'd like to look at why you don't have time to contribute. I believe it is because this 'Cocoon' that is under development is still in early stages and still quite 'abstract' in the problems it is trying to solve. That's not a bad thing necessarily, but the consequence is that it feels as if there's no space for people to innovate on smaller or more immediate issues because we're all waiting for this 'big thing'. If the OSGi blocks stuff is so orthogonal to Cocoon, why don't we: * break it off into a separate development path, no longer consider it 'trunk', * move 2.1.X into trunk * Start innovating on 2.1.x again * Wrap the OSGi blocks system around this new trunk as and when it is a bit better developed. Personally, the long waiting for this blocks system is having very unfortunate effects on our community. We need to change that. Take the development of blocks off the front stage, and let it happen quietly somewhere until there's something clear for us to see and play with, rather than preventing people from being able to innovate because they can't understand the status of trunk and don't have time/resources to invest in working it out and keeping up. That means that all that are left are those of us that have 'personal spare time'. The rest of us, who do all of our Cocoon work as a part of our livelihoods, can't find time to contribute to Cocoon because we can't justify it - it is just too hard to work out where to contribute. And 'just waiting' is dangerous, as each moment some of our valuable resource wanders away. Upayavira
Re: [RT] OSGi based blocks
Peter Hunsberger wrote: On 3/15/06, Upayavira [EMAIL PROTECTED] wrote: Personally, the long waiting for this blocks system is having very unfortunate effects on our community. We need to change that. Take the development of blocks off the front stage, and let it happen quietly somewhere until there's something clear for us to see and play with, rather than preventing people from being able to innovate because they can't understand the status of trunk and don't have time/resources to invest in working it out and keeping up. That means that all that are left are those of us that have 'personal spare time'. The rest of us, who do all of our Cocoon work as a part of our livelihoods, can't find time to contribute to Cocoon because we can't justify it - it is just too hard to work out where to contribute. And 'just waiting' is dangerous, as each moment some of our valuable resource wanders away. Do that, and nothing other than 2.1 will ever happen. Getting real blocks is a big thing. It looks like a lot of work, everyone has always known that. Now that there is a little bit of momentum in the blocks direction is no time to kill it. I never said 'kill it'. I said 'move it'. I very much value the blocks work, but at the same time I think it is stifling the rest of Cocoon. I would like to see blocks and Cocoon 2.1.X move along in parallel, and as soon as blocks are sufficiently mature and stable, they merge. The current state of affairs with a tiny minority working on blocks (however cool) and nothing else happening is far from healthy. Upayavira
Re: [RT] OSGi based blocks
Bertrand Delacretaz wrote: Le 15 mars 06 à 16:04, Carsten Ziegeler a écrit : ...I personally would love to have the new configuration features of 2.2 in 2.1.x, like the includes for xconf and properties. This alone is a big step forward. Unfortunately this is tight to many other changes like the Spring based container (which I also would like to have *today*). So perhaps your suggestion, starting anew with 2.1.x as trunk is a good way to move on... How about backporting the Spring-based container and the new configuration features to 2.1.x, and make that Cocoon 2.3, without touching the current trunk? The current 2.2 would then stay as is, people could work on it until it stabilizes, and when it's time to release it we can always call it 3.0 or whatever to avoid confusion. And that 2.3 release would be a big improvement already, especially using Spring as its container. Exactly the sort of thing I'm talking about. Both streams keep innovating. Regards, Upayavira
Re: [RT] OSGi based blocks
Peter Hunsberger wrote: On 3/15/06, Upayavira [EMAIL PROTECTED] wrote: Peter Hunsberger wrote: Do that, and nothing other than 2.1 will ever happen. Getting real blocks is a big thing. It looks like a lot of work, everyone has always known that. Now that there is a little bit of momentum in the blocks direction is no time to kill it. I never said 'kill it'. I said 'move it'. If you ask me, that the same thing: if it's ever going to happen lots of people have to focus on it and make it happen... I very much value the blocks work, but at the same time I think it is stifling the rest of Cocoon. I would like to see blocks and Cocoon 2.1.X move along in parallel, and as soon as blocks are sufficiently mature and stable, they merge. The current state of affairs with a tiny minority working on blocks (however cool) and nothing else happening is far from healthy. Perhaps, but from what I understand nothing is really stopping you from working on anything else? 2.1 is a branch - so innovation shouldn't really happen there. Trunk I don't understand, and is too unstable (not a negative, just a fact[1]) for me to find time to understand it. So I don't see quite what I could work on. And I suspect the case is the same for others too. Upayavira [1] Some people have time and resources to give to working with that level of instability. Others need something relatively stable to work on incrementally within their work. I see no problem with either approach, I just want us to bring the latter back into play in our community.
Reviving 2.1 development (was Re: [RT] OSGi based blocks)
Reinhard Poetz wrote: Upayavira wrote: Bertrand Delacretaz wrote: Le 15 mars 06 à 16:04, Carsten Ziegeler a écrit : ...I personally would love to have the new configuration features of 2.2 in 2.1.x, like the includes for xconf and properties. This alone is a big step forward. Unfortunately this is tight to many other changes like the Spring based container (which I also would like to have *today*). So perhaps your suggestion, starting anew with 2.1.x as trunk is a good way to move on... How about backporting the Spring-based container and the new configuration features to 2.1.x, and make that Cocoon 2.3, without touching the current trunk? The current 2.2 would then stay as is, people could work on it until it stabilizes, and when it's time to release it we can always call it 3.0 or whatever to avoid confusion. And that 2.3 release would be a big improvement already, especially using Spring as its container. Exactly the sort of thing I'm talking about. Both streams keep innovating. I have no problem with a backport in general, but why exactly *now* when Daniel writes a mail that he has solved all problems that required a lot of research work and Daniel and I only need some more weeks of implementation work? Consider it nothing more than a build up of frustration. I will only fully believe it when you say now rather than some more weeks. I offer you both/all my greatest encouragement in what you are doing - I really do hope it is a few weeks - I find it very exciting. But at the same time, I want to see something move in the rest of Cocoon too. Regards, Upayavira
Revivingg 2.1 development (was Re: [RT] OSGi based blocks)
Peter Hunsberger wrote: On 3/15/06, Upayavira [EMAIL PROTECTED] wrote: snip/ I would like to see blocks and Cocoon 2.1.X move along in parallel, and as soon as blocks are sufficiently mature and stable, they merge. The current state of affairs with a tiny minority working on blocks (however cool) and nothing else happening is far from healthy. Perhaps, but from what I understand nothing is really stopping you from working on anything else? 2.1 is a branch - so innovation shouldn't really happen there. Trunk I don't understand, and is too unstable (not a negative, just a fact[1]) for me to find time to understand it. So I don't see quite what I could work on. And I suspect the case is the same for others too. Upayavira [1] Some people have time and resources to give to working with that level of instability. Others need something relatively stable to work on incrementally within their work. I see no problem with either approach, I just want us to bring the latter back into play in our community. Sure, I understand. But that's really my point: Cocoon has always taken a bit of learning curve. The fact that trunk is now new, and unusual is a hump for many people, but if Cocoon is every going to really move forward then people should either be willing to wait, or climb the learning curve. I'm talking about people who have already climbed that learning curve. People who have jobs and time constraints and can't justify another climb until there is something concrete to offer their bosses. This is an energy resource we are loosing a lot of right now. Yes, you loose a little bit from the people that don't have the time or energy to climb the curve early in the process. However, IMO you loose even more if there are two main branches of Cocoon to focus on instead. Who _really_ is following the blocks thread anyway other than the core developers? I want someone else for the rest of us to follow. Regards, Upayavira P.S. Note new subject to move away from Daniel's original topic, which is itself good stuff.
Re: Release 2.1.9 (again)
Jason Johnston wrote: On Thu, 2006-03-09 at 08:46 -0800, Ralph Goers wrote: Bruno Dumon wrote: On Thu, 2006-03-09 at 06:35 -0800, Ralph Goers wrote: Hi. Its me again. Seriously, are we there yet? I guess nothing changed since you last asked ;-) Not quite. A few days passed, which is all Sylvain said he needed. AFAIK that is all we are waiting for. It gets mentioned every time someone asks about the 2.1.9 release, so to keep the pattern going: what about the Template block from trunk? IIRC this was discussed and planned for inclusion in 2.1.9. Could you make a patch? That could make it happen. Upayavira
Re: [jira] Commented: (COCOON-1798) Flowscript doc lacks information about isGlobal parameter of cocoon.redirectTo function
Helma van der Linden (JIRA) wrote: [ http://issues.apache.org/jira/browse/COCOON-1798?page=comments#action_12369743 ] Helma van der Linden commented on COCOON-1798: -- I'm not sure what you want to happen. If it's merely an extension to the documentation I'd be happy to add it if you can provide a sensible description of the isGlobal parameter (i.e. something more sensible than global redirect). IIRC a global redirect is one that returns all the way to the browser, even from within internal requests. Regards, Upayavira
Re: Release 2.1.9 (again)
Jason Johnston wrote: On Thu, 2006-03-09 at 21:10 +, Upayavira wrote: Jason Johnston wrote: On Thu, 2006-03-09 at 08:46 -0800, Ralph Goers wrote: Bruno Dumon wrote: On Thu, 2006-03-09 at 06:35 -0800, Ralph Goers wrote: Hi. Its me again. Seriously, are we there yet? I guess nothing changed since you last asked ;-) Not quite. A few days passed, which is all Sylvain said he needed. AFAIK that is all we are waiting for. It gets mentioned every time someone asks about the 2.1.9 release, so to keep the pattern going: what about the Template block from trunk? IIRC this was discussed and planned for inclusion in 2.1.9. Could you make a patch? That could make it happen. I would be glad to. But I would need guidance, since I know nothing about what is required. Is it just adding an svn:external to that block, or are there code changes involved? Try it and see. Then ask questions about where you get stuck. (It likely won't be me answering - I won't know the answers, but the more pointed and precise the questions, the more likely they'll get answered). Regards, Upayavira
Re: JIRA crazy
Jean-Baptiste Quenot wrote: Hello, I'm using JIRA today, and the layout is completely screwed up. Has anybody noticed this as well? I'm using Galeon 1.3.21 (A GNOME browser based on Mozilla). Forward this to [EMAIL PROTECTED] They've been working on this precise problem, and had hoped it had been fixed. Upayavira
Re: [VOTE] Release 2.1.9
Ralph Goers wrote: Carsten Ziegeler wrote: Sylvain Wallez wrote: I believe the alternatives that were mentioned were to either get the OK from legal or not deliver the jcr block as part of the release. If the answer above means you don't feel we have permission than the release should go out without JCR. The API can be redistributed with an implementation, and we do redistribute the implementation. Does this give use the permission to redistribute the API with the implementation? IANAL and I don't know... Ok, so how do we solve this issue? I understand the comment from Roy that we are not allowed to ship the jar right now. I personally would go the easiest way: remove the jcr api from the repo, disable the block by default, add a readme that people have to download the jar and put it into local libs to build the block. My understanding from Roy is that, if we ship Jackrabbit, we don't need the JCR jar, as Jackrabbit provides its own impl. Does it still work if you just remove the JCR jar? Or did I misunderstand something? Upayavira
[Fwd: Cocoon and Felix]
I just received this message from Richard Hall. Seems like Felix just go that bit closer to meeting our needs, which is great. Is there anything else we specifically need in order to use Felix instead of Eclipse? Upayavira Original Message Subject: Cocoon and Felix Date: Sun, 19 Feb 2006 12:58:42 -0500 From: Richard S. Hall [EMAIL PROTECTED] To: [EMAIL PROTECTED], [EMAIL PROTECTED] Hey guys, I wanted to follow up with Cocoon and Felix... I can't remember who said it, but someone mentioned at ApacheCon that Cocoon needed Bundle.getEntry()/getEntryPaths() to start using Felix. I just wanted to let you guys know these methods are now implemented in Felix. It was actually a complicated process because I realized that Felix' module layer abstraction was not really sufficient for implementing the methods. While I could have hacked them in without much difficulty, I decided to refactor and rewrite the module layer abstractions, since it would also help me with some other issues I wanted to solve. Needless to say, after a few weeks worth of work, I am pretty satisfied with the new module layer...it still needs some tweaking, but for the most part it is significantly improved. All of this work is committed and ready for experimentation. Were there other specific show stoppers for Cocoon? We should enter them into JIRA if so, so that we can try to pick them off one by one. - richard
Re: [Fwd: Cocoon and Felix]
Thanks for this Daniel - Richard copied in so he sees your reply. Regards, Upayavira Daniel Fagerstrom wrote: We also need the ability to use unpacked bundles for fast prototyping (available in Equinox). We need the possibility to embed the OSGi framework in a servlet container (http://www.eclipse.org/equinox/incubator/server/embedding_in_a_servlet_container.php). And we need a framework that work together with some declarative services implementation (IIUC the coupling between declarative services and the framework is not standardized). As a first step I think it is more important to get Cocoon working under OSGi at all than supporting our local OSGi provider ;) As soon as we have got to that point I am all for making Cocoon work with all OSGi R4 compliant frameworks, and maybe having Felix as default choice. /Daniel Upayavira skrev: I just received this message from Richard Hall. Seems like Felix just go that bit closer to meeting our needs, which is great. Is there anything else we specifically need in order to use Felix instead of Eclipse? Upayavira Original Message Subject: Cocoon and Felix Date: Sun, 19 Feb 2006 12:58:42 -0500 From: Richard S. Hall [EMAIL PROTECTED] To: [EMAIL PROTECTED], [EMAIL PROTECTED] Hey guys, I wanted to follow up with Cocoon and Felix... I can't remember who said it, but someone mentioned at ApacheCon that Cocoon needed Bundle.getEntry()/getEntryPaths() to start using Felix. I just wanted to let you guys know these methods are now implemented in Felix. It was actually a complicated process because I realized that Felix' module layer abstraction was not really sufficient for implementing the methods. While I could have hacked them in without much difficulty, I decided to refactor and rewrite the module layer abstractions, since it would also help me with some other issues I wanted to solve. Needless to say, after a few weeks worth of work, I am pretty satisfied with the new module layer...it still needs some tweaking, but for the most part it is significantly improved. All of this work is committed and ready for experimentation. Were there other specific show stoppers for Cocoon? We should enter them into JIRA if so, so that we can try to pick them off one by one. - richard
Re: AW: AW: How to use cocoon servlet only for rendering documents?
Peter Neu wrote: Hello Bertrand, I managed to send my xml in a post request to cocoon and retrieve the ouput back in pdf. But one thing I couldn't figure out so far is how to actually read the xml from the post request into my sitemap. Can you please provide a short code snippet? The relevant part looks like this: map:match pattern=pdf map:generate src=data/user.xml/ //still a hard coded resource map:transform src=stylesheets/user.xsl/ map:serialize type=fo2pdf/ /map:match You need the stream generator: map:match pattern=pdf map:generate type=stream/ map:transform src=stylesheets/user.xsl/ map:serialize type=fo2pdf/ /map:match I think that is enough. Try it. Upayavira
Re: AW: AW: How to use cocoon servlet only for rendering documents?
Peter Hunsberger wrote: On 2/15/06, Upayavira [EMAIL PROTECTED] wrote: Peter Neu wrote: Hello Bertrand, I managed to send my xml in a post request to cocoon and retrieve the ouput back in pdf. But one thing I couldn't figure out so far is how to actually read the xml from the post request into my sitemap. Can you please provide a short code snippet? The relevant part looks like this: map:match pattern=pdf map:generate src=data/user.xml/ //still a hard coded resource map:transform src=stylesheets/user.xsl/ map:serialize type=fo2pdf/ /map:match You need the stream generator: map:match pattern=pdf map:generate type=stream/ map:transform src=stylesheets/user.xsl/ map:serialize type=fo2pdf/ /map:match I think that is enough. Try it. Ahh, I get what he's trying to do. Won't the request generator also do the trick at this point? Or will it muck the embedded XML? RequestGenerator will give far too much info (assuming it gives the stream content, which I'm not sure). The StreamGenerator is really easy, although it might need a little configuring. It can either take data sent with PUT, or take a particular form field sent by POST. Upayavira
Re: Logkit (I know, again) was [RT] Using Spring instead of ECM++
Bertrand Delacretaz wrote: Le 13 févr. 06, à 14:50, Carsten Ziegeler a écrit : Giacomo Pati wrote: ...What about also getting rid of logkit and use what we already have in our dependency lists (log4J, commons-logging, ...)? Yes, please :) I would suggest log4j as commons-logging has problems with classloading (afair) and noone is using jdk14 logging +1 for log4j +1 too. Upayavira
Re: Logkit (I know, again) was [RT] Using Spring instead of ECM++
Niklas Therning wrote: Carsten Ziegeler wrote: ... Yes, please :) I would suggest log4j as commons-logging has problems with classloading (afair) and noone is using jdk14 logging. Nowadays there's also slf4j (www.slf4j.org). Like commons-logging it's a facade for other logging frameworks but it doesn't suffer from the classloading problems of commons-logging. It's used by the Apache directory project. I think it's being developed by the guy behind log4j. We have discussed that before. Personally, just using the de-facto standard of Log4J, if it is capable of meeting our requirements, keeps things simple. And simple is something that Cocoon seriously needs to be moving towards. We've been there and done that in relation to lots of dependencies. Regards, Upayavira
Re: Unified directory layout for trunk?
Carsten Ziegeler wrote: I was just looking briefly at the current directory layout of trunk and it seems that we are currently using different layouts for the blocks. Most blocks follow the layout suggested recently while others like the databases or the xmldb do not. Is this supposed to change? My impression is that this is a proposed layout, we're waiting to see how the few converted classes work out before converting any of the rest. How are we getting on with tat evaluation? Are we ready for volunteers to convert the rest? Upayavira
[jira] Commented: (COCOON-1771) cocoon.ajax.Fader runtime error when style uses abreviated form #ccc in IE6.0sp2
[
http://issues.apache.org/jira/browse/COCOON-1771?page=comments#action_12365560
]
Upayavira commented on COCOON-1771:
---
This patch came in as anonymous, therefore we cannot accept it, as its
provenance cannot be proven. Please resubmit it while logged into jira.
cocoon.ajax.Fader runtime error when style uses abreviated form #ccc in
IE6.0sp2
Key: COCOON-1771
URL: http://issues.apache.org/jira/browse/COCOON-1771
Project: Cocoon
Type: Bug
Components: Blocks: Ajax
Versions: 2.1.8
Reporter: Eric Meyer
Assignee: Antonio Gallardo
Attachments: cocoon-ajax.js.patch, cocoon-ajax.js.patch, cocoon-ajax.js.patch
In cocoon.ajax.Fader
this.toColor =
cocoon.ajax.Fader.colorToRgb(cocoon.ajax.Fader.getBgColor(this.element));
getBgColor will return '#fff'
/** Converts a #RRGGBB color as an array of 3 ints */
cocoon.ajax.Fader.colorToRgb = function(hex) {
return [
parseInt(hex.substr(1,2),16),
parseInt(hex.substr(3,2),16),
parseInt(hex.substr(5,2),16) ];
}
Assumes that hex starts with a '#' and has 6 additional hex characters.
The corrected implementation is
/** Converts a #RRGGBB color as an array of 3 ints */
cocoon.ajax.Fader.colorToRgb = function(hex) {
var r = 255; // defaults if no match
var g = 255;
var b = 255;
var i=-1;
var colors = hex.match(/^#(\d{2})(\d{2})(\d{2})$/);
if (colors) {
r = parseInt(colors[++i]);
g = parseInt(colors[++i]);
b = parseInt(colors[++i]);
} else if (colors = hex.match(/^#(\d)(\d)(\d)$/)) {
r = parseInt(colors[++i] + colors[i]);
g = parseInt(colors[++i] + colors[i]);
b = parseInt(colors[++i] + colors[i]);
}
return [r,g,b];
}
Patch attached.
Regards,
Eric Meyer, VP, Quoin, Inc.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
Re: Adding patches to Jira
Reinhard Poetz wrote: Upayavira (JIRA) wrote: [ http://issues.apache.org/jira/browse/COCOON-1771?page=comments#action_12365560 ] Upayavira commented on COCOON-1771: --- This patch came in as anonymous, therefore we cannot accept it, as its provenance cannot be proven. Please resubmit it while logged into jira. How that? Can't we deactivate the possibity to add patches if you're not logged in? Yeah, I wondered about that too. Any jira admin able to look at it? Upayavira
[jira] Commented: (COCOON-1771) cocoon.ajax.Fader runtime error when style uses abreviated form #ccc in IE6.0sp2
[
http://issues.apache.org/jira/browse/COCOON-1771?page=comments#action_12365587
]
Upayavira commented on COCOON-1771:
---
No need. Just make sure that the one you use was uploaded by a known individual
who clicked the grant license button.
cocoon.ajax.Fader runtime error when style uses abreviated form #ccc in
IE6.0sp2
Key: COCOON-1771
URL: http://issues.apache.org/jira/browse/COCOON-1771
Project: Cocoon
Type: Bug
Components: Blocks: Ajax
Versions: 2.1.8
Reporter: Eric Meyer
Assignee: Antonio Gallardo
Attachments: cocoon-ajax.js.patch, cocoon-ajax.js.patch,
cocoon-ajax.js.patch, cocoon-ajax.js.patch
In cocoon.ajax.Fader
this.toColor =
cocoon.ajax.Fader.colorToRgb(cocoon.ajax.Fader.getBgColor(this.element));
getBgColor will return '#fff'
/** Converts a #RRGGBB color as an array of 3 ints */
cocoon.ajax.Fader.colorToRgb = function(hex) {
return [
parseInt(hex.substr(1,2),16),
parseInt(hex.substr(3,2),16),
parseInt(hex.substr(5,2),16) ];
}
Assumes that hex starts with a '#' and has 6 additional hex characters.
The corrected implementation is
/** Converts a #RRGGBB color as an array of 3 ints */
cocoon.ajax.Fader.colorToRgb = function(hex) {
var r = 255; // defaults if no match
var g = 255;
var b = 255;
var i=-1;
var colors = hex.match(/^#(\d{2})(\d{2})(\d{2})$/);
if (colors) {
r = parseInt(colors[++i]);
g = parseInt(colors[++i]);
b = parseInt(colors[++i]);
} else if (colors = hex.match(/^#(\d)(\d)(\d)$/)) {
r = parseInt(colors[++i] + colors[i]);
g = parseInt(colors[++i] + colors[i]);
b = parseInt(colors[++i] + colors[i]);
}
return [r,g,b];
}
Patch attached.
Regards,
Eric Meyer, VP, Quoin, Inc.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
Re: Allow ContinuationsManagerImpl to run in CLI
Jean-Baptiste Quenot wrote: Hello, About http://issues.apache.org/jira/browse/COCOON-1715 What is the best way to deal with this? Add servlet.jar in the Loader's classpath when running the CLI? Or remove the continuations-manager from cocoon.xconf by creating a new optional flow block? Your feedback will be appreciated. Just add servlet.jar to the CLI's classpath. It won't be soon that it gets the attention it needs to make sure it can work without servlet.jar, and it will make life easy for a lot of CLI users. Upayavira
Re: [RT] The environment abstraction, part II
discussion. Regards, Upayavira
Re: Extending the image reader
Tim Williams wrote: I want the image reader to accept a variant name (e.g. thumb, small) and then write the newly created image variant to disk before sending the output. In other words, so that a given image IMG001.jpg might be read with a variant thumb and on disk would now be: IMG001.jpg IMG001.thumb.jpg Obviously, a hefty cost for the first time through on each image but just reading afterwards. I've initially done this by just copying the entire ImageReader into a new PersistentImageReader and inserting the applicable code in setup() and processStream(). Now that it's working how I'd like, I figured I'd just extend the ImageReader and only implement these two methods. The only way I can think to do it is somehow redirect the output into a buffer, write the buffer, then send it out. Is there a better way to extend a reader? Anyone have any clues as to how I might be able to buffer the ImageReader's output? Well, sounds like you're trying to achieve something similar to caching. I wonder if the caching system might be an alternative approach to achieving the same thing. Anyway, to answer your question directly... The AbstractReader class has a setOutputStream method. You could, in your generate() method: * check to see if the resource has already been generated. If it has, set the inputSource to that of your cached version and proceed as normal (calling super.generate()) * Otherwise, take a copy of the existing output stream, set the output stream (using setOutputStream) to your own buffering version. Proceed as normal. At the end of the generate method you write the contents of buffer to disc, then copy contents of buffer to original output stream. I think that would work. And this should work as an extension of the ImageReader class as you suggest. Have I understood your question? Regards, Upayavira
Re: [RT] The environment abstraction, part II
Daniel Fagerstrom wrote: Upayavira wrote: Daniel Fagerstrom wrote: Carsten Ziegeler skrev: ... First, I'm still not sure if this should go into the current 2.2 code base, but apart from that I now think we should even be more radical in this area and remove the whole environment abstraction completly and make Cocoon a web framework. Period. Agree, but as people (you included) had valid reasons for not going that far in 2.2, I suggest something less radical this time, as I want to get rid of the problem of calling servlets from within Cocoon already in 2.2. I am starting to change my mind about this in regard to 2.2. 2.2 is changing as a concept. It was previously just a small step up from 2.1, in which case a significant change in interface would not have been appropriate. However, particularly the maven build, but also a lot of the other stuff that is going on, is leading to some quite substantial improvements. It starts to look like a 3.0 rather than a 2.2 and my personal goal is to implement the whole blocks design including OSGi. OTH I try to not hinder the possibility for a 2.2 release, given that someone is prepared to spearhead it. Question is is there an interim thing that we can release before whole OSGi is implemented? We were talking about an RC when Maven build was done, but we seem to be moving away from that. Gradual steps, release often is good. Making life harder for future exciting developments by releasing too early isn't good. More particularly Daniel's proposals to do with using servlet interfaces for block controllers would make it possible to implement some (or even all) of Sylvain's Cocoon 3.0 ideas within this framework. That is the goal :) Yup, and I like it. If this is the case, then it would seem timely to improve these interfaces now, as 2.2 given the greater flexibility could become _the_ future Cocoon, and we may miss the boat if we don't make this change now. Yes, I feel some urgency. With enough focus and dedication on refactoring Cocoon and finish the blocks Cocoon can be the Rich Server Platform (http://www.infonoia.com/en/content.jsp?d=inf.05.07). And regain its momentum. Focusing on 2.2 seem more like losing valuable time for me. Well, define 2.2 :-) I presume you mean releasing a Maven based Cocoon without a ready blocks system would loose valuable momentum. But that is IMHO, if enough people are prepared to make a 2.2 happen, I will of course join in that work. Again - define what 2.2 is. At the moment, these are just numbers. We should be taking about whether we are going to release feature sets, not numbers. Now, we have currently two other environments: cli and portlets. A portlet is a web application, so there won't be any problem. And for the CLI we can come up with some kind of HttpClient that internally starts Jetty etc. Yes. For CLI an alternative is to have a minimal servlet container as part of the CLI. Maybe its possible to use Jetty in that way without needing to go over a socket? Why a servlet container? Or do you mean simple implementation of the servlet interfaces? That would be what we would need. Something to set up request and response and call the servlet's service() method. I mean a simple implementation of the servlet interfaces as you suggest. I haven't studied the CLI implementation in any detail, what is your opinion about letting it work on the servlet interfaces rather than at the Processor level. What consequences will it have? Wouldn't be too hard. It builds its own Request, Response and Environment, and a Cocoon object to use. Moving it across shouldn't be too hard (although the CLI could do with a _serious_ rewriting, but that's for other reasons). Regards, Upayavira
Re: Extending the image reader
Tim Williams wrote: On 1/30/06, Upayavira [EMAIL PROTECTED] wrote: Tim Williams wrote: I want the image reader to accept a variant name (e.g. thumb, small) and then write the newly created image variant to disk before sending the output. In other words, so that a given image IMG001.jpg might be read with a variant thumb and on disk would now be: IMG001.jpg IMG001.thumb.jpg Obviously, a hefty cost for the first time through on each image but just reading afterwards. I've initially done this by just copying the entire ImageReader into a new PersistentImageReader and inserting the applicable code in setup() and processStream(). Now that it's working how I'd like, I figured I'd just extend the ImageReader and only implement these two methods. The only way I can think to do it is somehow redirect the output into a buffer, write the buffer, then send it out. Is there a better way to extend a reader? Anyone have any clues as to how I might be able to buffer the ImageReader's output? Well, sounds like you're trying to achieve something similar to caching. I wonder if the caching system might be an alternative approach to achieving the same thing. Anyway, to answer your question directly... The AbstractReader class has a setOutputStream method. You could, in your generate() method: * check to see if the resource has already been generated. If it has, set the inputSource to that of your cached version and proceed as normal (calling super.generate()) * Otherwise, take a copy of the existing output stream, set the output stream (using setOutputStream) to your own buffering version. Proceed as normal. At the end of the generate method you write the contents of buffer to disc, then copy contents of buffer to original output stream. I think that would work. And this should work as an extension of the ImageReader class as you suggest. Have I understood your question? Regards, Upayavira Exactly, I'll give these a try and see what I can manage. It is essentially the same as caching but I need something that can work in both webapp and cli modes in forrest. Ah. And currently the cache doesn't survive restarts in the CLI, which it should. So your approach is now more understandable. Regards, Upayavira
Re: Package samples as jars in 2.1
Jean-Baptiste Quenot wrote: * Upayavira: Jean-Baptiste Quenot wrote: Any hint on how to add this location to the loader classpath? The loader source is in tools/src/loader/Loader.java. It seems that the loader doesn't load class directories. However, a brief look at the code suggests to me that it wouldn't be too hard to add. We could hack the Loader. But we could also packages our samples as jars. That would ease to merge the Cocoon build with an existing application. Currently, it is quite difficult to mix Cocoon's WEB-INF/classes with My App's WEB-INF/classes because the latter is often cleaned/regenerated on a regular basis. Yup. Makes sense to me. I often wondered why that stuff wasn't jarred up. Regards, Upayavira
Re: Update to the Servlet API
Sylvain Wallez wrote: Carsten Ziegeler wrote: Sylvain Wallez wrote: So depending on servlet 2.3 shouldn't be that much of a problem. Yes, that's why I said in an earlier response that we can vote on upgrading the requirements to servlet 2.3 officially. Ok, let's vote! Why? What does it give us? It _may_ bring an incompatability for some users, so I'd want to understand what the benefits are. Personally, I think we should go 2.3 or even 2.4 with Cocoon 2.2, but stick as we are in 2.1.x. After all, it is becoming more of a maintenance release, and should have as little substantial change as possible. Regards, Upayavira
Re: Update to the Servlet API
Jean-Baptiste Quenot wrote: * Carsten Ziegeler: Sylvain Wallez schrieb: Jean-Baptiste can elaborate on this, but AFAIU this is because an interesting XSP patch requires a servlet listener, which is something that was added in servlets 2.3. So, he could just add a mock class for the listener to the xsp block, add the listener and we are done with this. Yes, I want to integrate a patch that allows to run an *optional* component on webapp startup to compile XSP. It's only for *compilation* that servlet 2.3 is needed, not for runtime, unless the user explicitly activates in web.xml the optional component (it's a SessionListener). Servlet 2.3 will *not* be required to run Cocoon. A mock sounds like a _much_ better way! Regards, Upayavira
Re: Update to the Servlet API
Sylvain Wallez wrote: Upayavira wrote: Jean-Baptiste Quenot wrote: * Carsten Ziegeler: Sylvain Wallez schrieb: Jean-Baptiste can elaborate on this, but AFAIU this is because an interesting XSP patch requires a servlet listener, which is something that was added in servlets 2.3. So, he could just add a mock class for the listener to the xsp block, add the listener and we are done with this. Yes, I want to integrate a patch that allows to run an *optional* component on webapp startup to compile XSP. It's only for *compilation* that servlet 2.3 is needed, not for runtime, unless the user explicitly activates in web.xml the optional component (it's a SessionListener). Servlet 2.3 will *not* be required to run Cocoon. A mock sounds like a _much_ better way! Mocking a 4-year old specification. This is s dinosaurish in this web 2.0 world... Hmm. If the whole spec is required, I can see where Jean-Baptiste is coming from. We could extend the build process to use servlet 2.3 for compilation, but keep the app running with servlet 2.2. Would that actually cause any backwards compatability issues? Regards, Upayavira
Re: Package samples as jars in 2.1
Jean-Baptiste Quenot wrote: Hello, The Cocoon CLI is broken because when all blocks are compiled in, there are classes in the samples that go to WEB-INF/classes, but the loader does not add this location to the classpath. Any hint on how to add this location to the loader classpath? A simple solution is to package the classes of blocks samples as jars. The loader source is in tools/src/loader/Loader.java. It seems that the loader doesn't load class directories. However, a brief look at the code suggests to me that it wouldn't be too hard to add. Regards, Upayavira
Why pom.xml and block.xml? (was Re: M10N)
Below you explain the role of pom.xml and the role of block.xml. From a technology point of view, I can see why you are going this way. However, if we think of a newcomer to Cocoon, I can see this as being unnecessarily complicated. Why are some things in pom.xml and others in block.xml? Well, er, because Maven doesn't know how to handle the stuff in block.xml. Would it not be possible to put the block.xml data somehow into the pom.xml file, and have it read by the block deployer mojo? Even if it were the same info just embedded into the pom.xml file, this would be substantially more user friendly, IMO. Does this make sense? Regards, Upayavira Reinhard Poetz wrote: Giacomo Pati wrote: On Wed, 18 Jan 2006, Reinhard Poetz wrote: Of course it's possible to edit the wiring.xml but I would (will) recommend Editing wiring.xml? I may now be totally wrong but I've understud that the wiring.xml is a generated file by the deployer (and the deployer-plugin uses the deployer). Please correct me if I'm wrong. yes, the wiring.xml is written by the deployer, but (usually) not directly editid by the developer. using the deployer as it will do validation, auto-wiring, ... Actually I think I'm quite confused about all those descriptors described in our Daisy and what the actual code looks like. pom.xml - for Maven build - used by deployer-plugin to resolve dependencies(?) pom.xml contains the necessary (usual) Java libraries and all blocks that contain Java code. At deployment time pom.xml is only used to get usual Java libraries (not blocks). block.xml - describes a block (components, sitemap, properties) - is used by blocks framework and used by the deployer to read default values for connections and properties block-deploy.xml - defines block dependencies for deployer(-plugin) - supplies additional information (i.e. values for block properties) - is used by deployer-plugin to create the wiring.xml (?) block-deploy.xml describes which blocks you want to install and which implementations you want to use for the requirements. As block.xml already knows the default block, it can support auto-wiring. The result is the wiring.xml. wiring.xml - configures a Cocoon app concerning block relationship, mount point, etc. and is only for internal use Please correct if I'm wrong. I'm not quite sure the difference between block-deploy.xml and wiring.xml. Is it that wiring.xml is the sum of all block-deploy.xml and their connections? The block deployer could support this but not the first release ;-) Can you describe how you see all those descriptors look like for our super-sample-block (collection of all block samples) will look like? deploy block id=ctemplate-samples urn=org.apache.cocoon:cocoon-template-samples:1.0.0/ block id=cforms-samples urn=org.apache.cocoon:cocoon-forms-samples:1.0.0/ [all other sample blocks] /deploy The deployer supports auto-wiring, which means that all required blocks will be automatically deployed and added to wiring.xml. I hope that I can provide a first useable version of the deployer-maven-plugin by the end of the week so that you (and others) can try it out and that we find a balance between what should be configureable and what not, which and how many configuration files we want, what they actually configure and how they relate to each other.
Re: svn commit: r368690 - in /cocoon/branches/BRANCH_2_1_X: src/blocks/xmldb/java/org/apache/cocoon/transformation/XMLDBTransformer.java status.xml
Jean-Baptiste Quenot wrote: BTW, no email was sent for my first commit: The commit in question: http://svn.apache.org/viewcvs.cgi?rev=368641view=rev The cvs archive for my commits: http://marc.theaimsgroup.com/?l=xml-cocoon-cvsw=2r=1s=jbqq=b You need to be subscribed to the cvs@ list via your apache.org email address. Normally a moderator will see your commit and moderate it through, adding you to the 'allow' list so you can do it in future. I believe I did this for your commit mail when I saw the moderation message. The only thing that could have happened is another moderator replied saying no, but I think that unlikely. I'd suggest you try another, this time inconsequential commit (add a space to a file or something) so we can moderate you through properly this time! Regards, Upayavira
Re: Getting response in any particular format required by client
Sumit wrote: Hi All, I have one issue i.e. while developing a dynamic web page i want the response in any particular format required by user, it can be in PDF, TXT, DOC, HTML, XML or WML or any other format whichsoever user chooses, so according to his/her choice the response should be dynamically converted in that particular format and should be visible to user. Can Cocoon and XSP + XSL help in this. I have written some code but not fully successful with that . You should ask this question on the user list. It is a better place for such a question. And the short answer is yes, Cocoon can help with that. Regards, Upayavira
Re: [M10N] releasing our snapshots with continuum
Jorg Heymans wrote: Bertrand Delacretaz wrote: Just a nitpick, I noticed that your howto includes the zone password of the maven user, not sure if this is a good idea. Of course the howto is accessible to ASF committers only, but that's a thousand people...until now we've used su to access the various users on the zone, it might be safer. Actually, Cocoon PMC members have write access, ASF members read access. So 200 people! Alternatively, we can also copy people's ssh keys to ~maven/.ssh to allow them to login. But I don't like having cleartext passwords in SVN. I wasn't too sure about this myself actually, but you're right ofcourse. So I tried changing the password from the maven account but i get -bash-3.00$ whoami maven -bash-3.00$ passwd passwd: Changing password for jheymans Permission denied No idea what's going on there. You need to use: su - maven If you're logging in as yourself first. Then you can try: passwd maven Now when Upayavira first created the maven account i tried putting my ssh key in .ssh/authorized_keys2 but for some reason it doesn't like it during authentication. I have the exact same setup for my user jheymans on the zone and there it works. If someone could take a look at this and make key authentication work that would be great. Dunno about this. Need someone else to help here. Regards, Upayaviria
Re: [VOTE] Stable CForms
Vadim Gritsenko wrote: Sylvain Wallez wrote: Carsten Ziegeler wrote: As soon as forms is really called and *treated* as stable: +1 As I said previously, the number of CForms users is such that any change will have to be backwards compatible. I removed v2 and v3 as the (unnamed) v1 should be the official API, but this breaks the DreamTeam sample that's using v3 We need official vote to mark CForms stable, so let's start it. Please vote to mark CForms as stable, to be included in imminent 2.1.9 release: [ ] +1, Let's do it! [ ] 0, What is CForms? [ ] -1, It's not stable, because... +1 Upayavira
Re: svn commit: r368690 - in /cocoon/branches/BRANCH_2_1_X: src/blocks/xmldb/java/org/apache/cocoon/transformation/XMLDBTransformer.java status.xml
Jean-Baptiste Quenot wrote: * Ralph Goers: I don't see a corresponding email for trunk. Was this also applied there? Not yet. Is it urgently needed in 2.2? No, but if you don't do it now, likely it will be forgotten. Regards, Upayavira
Re: [RT] Simplifying component handling
Reinhard Poetz wrote: --- Carsten Ziegeler [EMAIL PROTECTED] schrieb: Gianugo Rabellino wrote: On 1/2/06, Ralph Goers [EMAIL PROTECTED] wrote: That seems to be a catch-22. How do you move away from Avalon without making these kind of changes? Good question - I think noone is able to answer that one. Honestly, I don't see how anything in the 2.x series could move away from Avalon. Too much refactoring needed, too many issues on the table. Yeah, and I really don't understand this - I (and others) propose small but simple steps to a) improve using Cocoon and b) provide a smooth migration path. But even if these proposals do not include heavy refactoring and do not come with problems, people are blocking it and always point to the we need a rewrite. Then if people are suggestion, let's rewrite, the same people (and others) complain that that is currently not an option. So in the end we are doomed. So I'm coming back to my idea, is anyone against adding constructor injection to ECM++ or at least make it pluggable so I can add it for my own projects? The change adds only a feature while maintaining 100% compatibility. Without having time to understand in depth what you guys are talking about, I'd say that we should not block any features that don't introduce any backwards incompatibilities. If people disagree here, I would be very intersted in their reasons ... So +1 for your enhancements Carsten! Even more - Gianugo makes some valid points about the future. However, at this point, we cannot prove that his opinion is correct. So in my view, we should be taking multiple paths until one shows up to be the clear winner. So, I'd say, Carsten, get on with improving 2.2 to address the issues people have mentioned, and others, get on with prototyping a new implementation of Cocoon. If/when that new implementation comes along, we can see if it can be redone as a refactoring rather than a rewrite. Until then, let's move on on all fronts. We stand a better chance of winning that way. Regards, Upayavira, who's been away for a few days and hasn't read the full thread
Re: JMX integration
Carsten Ziegeler wrote: Giacomo Pati wrote: I now do have a working implementation for JMX with the least impact (by added dependencies) to the core (so far only the javax.management interfaces). The discovery approach is simply looking whether there is a class which has the MBean suffix to the FQCN of the Component target for Management. This means you'll have to write your MBeans by hand (yes there are helper base classes available somewhere else and I will write about this below). The code I've written checks whether there is a MBeanServer available in the JVM and only adds JMX discovery support if there is one (doesn't create an MBeanServer on it's own so far like Commons-Modeler does). Awesome. Sounds great. One of my goals for 2.2 was to add JMX support to Cocoon, but I never really got time for it. I was also asking myself (and now you guys) whether we should depend on Commons-Modeler which has some nice conveniences to add JMX ModelMBean support by xml configuration files and/or subclassing of their BaseModelMBean helper class. Other helper base classes I've found is the org.mortbay.util.jmx.ModelMBeanImpl which make writing MBean classes very easy (I think there is also some generating introstecting method like Commons-Modeler does) and also supports array of managed objects which would come handy for pools of manageable components (which Commons-Modeler base classes doesn't seem to support, only primitive data types). The ModelMBeanImpl base class supports resource properties file which respect the locale of the machine the JVM runs on for the descriptions of the mbean attributes/operations etc. which should be shown in the JMX-Console. A word to components targeted for Management: In 2.1 the support for JMX is quite limitted as we do not control the code of the Component Management parts (it's Excalibur code and I wouldn't take the effort to change it) and thus targets are only components which a ThreadSafe and implement the Component interface (maybe more components could be a traget for management but so far I've only choosen those). In 2.2 the situation is much more comfortable (as we control the component management code). There I'll have support ready for any ThreadSafe components as well as for the NonThreadSafePoolableComponentHandler (for the min/max values of the pools by use of the ModelMBeanImpl base class but this can be changed to Commons-Modeler). Adding management for pools of components will depend on which JMX supporting package we decide to choose. With Commons-Modeler I think it would be a more code to write thanwith the mortbay ModelMBeanImpl base class. The question I'd like to discuss is whether we wan't add a supporting package (Commons-Modeler or jetty/mortbay's ModelMBeanImpl) or should we just stay with the support to add MBeans (how ever those are implemented is up to the user) to a possibly running MBeanServer in the JVM? Hmm actually I don't care that much if we add another dependency. I rewrote the core of Cocoon and added ECM++ for being able to add JMX support somehow. Now, it thing depending on commons-modeler is a little bit easier as it's an Apache project - if there is something wrong for us we can fix it more easily. But apart from that, I think I just trust your decision which of the two is better suited for us. So, big +1 for adding JMX support to 2.2 :) So long as the new dependency isn't one for the core, but can be contained in a block. Upayavira
Re: Roadmap for 2.2 [was Re: [RT] Ditching the environment abstraction]
Jorg Heymans wrote: Carsten Ziegeler wrote: I strongly suggest that we start creating roadmaps. This also would make the development of Cocoon for users much more transparent. Currently I have only two points which I really think have to be finished for 2.2: the build/deployment stuff and making the current blocks available separatly/providing an own versioning for them. So as soon as the m2 integration works, we can polish 2.2 a little bit and then release the core and each blocks as 2.2 and from the on develop the core and the blocks independently and release them independently. Everything else can follow later on. I've been working a bit more behind the scenes lately to get excalibur to behave properly under m2. I am currently switching the flat layout in the whiteboard to the new excalibur poms to see how they behave and do first tests. Once i'm done there i can focus more on the deployment integration again. What about the repository reorganisation I suggested in [1]? Given a more flat and m2 consistent layout, i can *easily* put it under continuum control like i did with excalibur [2]. Note that we wouldn't use continuum's CI features as such, but merely use it as an automated snapshot release tool. It would thus replace my cronned shell script for doing snapshot releases and make it possible to force a snapshot release at the click of a button. The only thing about the repo reorg is that i don't want to stall current development momentum, but frankly i don't really see a way not to - at least for a few days. For me, the absolute most important thing is getting the build working again with the excalibur stuff. I'm here at ApacheCon with Maven chaps around, and the easier it is for me to 'grok' the current Maven setup, the more likely I am to be able to understand and explore with them where we should go next. Also: are we carrying forward all blocks to 2.2 or is this the time where we ditch the obscure, rarely used and blocks that don't really deserve to be a block blocks? I'ld say we choose the 10 most often used and well known blocks and let the users voice their concern about those blocks we aren't taking forward. If enough noise, we can then still decide to support these blocks ourselves again or even offer it to dedicated users to maintain themselves. See separate mail. Upayavira
Dists and Core blocks selection [Re: Roadmap for 2.2 [was Re: [RT] Ditching the environment abstraction]
Jorg Heymans wrote: snip/ Also: are we carrying forward all blocks to 2.2 or is this the time where we ditch the obscure, rarely used and blocks that don't really deserve to be a block blocks? I'ld say we choose the 10 most often used and well known blocks and let the users voice their concern about those blocks we aren't taking forward. If enough noise, we can then still decide to support these blocks ourselves again or even offer it to dedicated users to maintain themselves. IMO we should be aiming to have either two or three releases: bare, small or complete. I would prefer not to have the complete release, because I would like us to have _a lot_ more blocks, as blocks _do_ make sense, they just don't make sense as the core. So if we start making complete releases, that complete release could start to grow into something unmanagable. So, we identify 'core' blocks, if we haven't already. Those get included in the 'small' build, the rest can be downloaded either via Maven or as separate zips. My take on core blocks is: * template * forms * javaflow I would also ask whether we should consider replacing the serializers in core with those in the serializer block. Regards, Upayavira
Re: [RT] Ditching the environment abstraction
Berin Loritsch wrote: Carsten Ziegeler wrote: In general I agree with this - it makes learning Cocoon internal a little bit easier. But I think the current environment api is not our biggest problem. Anyways, our current Request object has more functionality as the servlet request object, e.g. to get the sitemap prefix and sitemap uri and more important the request attribute handling for internal requests. How can we keep this functionality when switching to the servlet api? And for me the most important question :) What is the suggested timeframe/version for this? Do you want to do this for 2.2? Or for a later version? Carsten I would imagine for a leter version. I'd think it would be too soon. We have two implementations of the Cocoon environment abstraction: CLI and WebApp. If we rip out the abstraction now, Forrest would break. I think that alone would push it out a bit. no, it wouldn't. The servlet api is itself an abstraction. So what we have is an abstraction of an abstraction. The suggestion is to scrap this double abstraction. We could easily have our own CLI implementation of javax.servlet.* That is the suggestion. Regards, Upayavira
m2 build broken?
I've just done a fresh build of trunk using m2, which failed somehow because of problems with xml-apis, saying something like: This artifact has been relocated to xml-apis:xml-apis:1.0.b2. And I also found references to it trying to get it from a URL at: http://cvs.apache.org/maven-snapshot-repository that didn't exist. Any ideas? Does it work for other people? Regards, Upayavira
Re: Cocoon F2F at ApacheCon
Matthew Langham wrote: I really think the current discussions on CocoonReloaded could do with some higher bandwidth talks to formulate a first plan. How many Cocoonites will be at ApacheCon and could perhaps get together? I won't be there but Carsten is (for example). I don't think you'll be able to stop us! Discussing the plan via various email-threads doesn't seem to me to be that effective - at this initial stage - and could eventually lead to everyone giving up in frustration. But at the same time we don't want to leave out thase that are not there. Upayavira
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
2.2 vs 3.0, or 2.2 then 3.0?
Gianugo Rabellino wrote: snip type=big/ Mind you, having some strong business interests in terms of existing projects with Cocoon 2, I shouldn't really be this much shouting about moving on in possibly incompatible ways: if I've been repeating from months now that we need a 3.0 (remember AC EU?), this is because I think that without a clear step forward, all we can do are small steps solving our self-induced problems while the world is clearly moving to different solutions and scenarios. The Cocoon community has never been a (late) follower as we risk of being now: if shaking the tree helps regaining momentum, then I'm all for an open discussion about it. I think what Gianugo says here is really important. Yes, I think we do need to be thinking about 3.0 in a radical new way, we do have too many self-imposed problems to solve in our current generation. But at the same time, the majority if not all of us have investments in 2.x based technologies. If someone handed us a complete 3.0 implementation today, it'd surely take us all some time before we'd switch, whether in recoding our apps, or retraining our staff, or whatever. So we need to work out how 2.2 and 3.0 play together. We need to get 2.2 out. I for one need it. But 2.2 is going to make life _much_ easier for people who are _already_ using Cocoon. We need something that is going to bring in significant new blood. So, 2.2 = important, and 3.0 = important. Both. We need to avoid discussions, implications, emotions, etc that suggest otherwise. We need to give the message to our existing users that their code will be supported for a long time, that it is still safe to continue using 2.1/2.2. After all, we will all ourselves have code using it for a long time, much like some of us probably have code running that still uses Cocoon 1.X. Any project will need to be 'revisioned' at times. Take the delightful 'Visual Basic', VB6 is incompatible with VB7. Sometimes it just needs to be done. That didn't stop people using VB6, at least not immediately (unfortunately for them ;-) ). So, no-one is offending anyone else by suggesting 3.0. Anyone shouting about 3.0 also likely needs 2.2 for their businesses to continue to function in the time until someone actually implements 3.0, and probably for some significant time after. Let's get 2.2 out, and let's continue to mull on the nature of 3.0, and thank you to Sylvain for restarting the discussion. Regards, Upayavira
Re: 2.2 vs 3.0, or 2.2 then 3.0?
Berin Loritsch wrote: Upayavira wrote: So, 2.2 = important, and 3.0 = important. Both. We need to avoid discussions, implications, emotions, etc that suggest otherwise. Right. If any of that has gone on, I'm sure its unintentional. If memory serves me correctly, Cocoon 2 was written as a branch, and Maintenance was happening on Cocoon 1 for a while. There did come a time when work stopped on Cocoon 1, but that was after Cocoon 2 was released. Basically, new/exciting stuff should go in Cocoon 3, and touch ups to Cocoon 2 until Cocoon 3 is ready for prime time. Yes, generally I agree. But even that makes it sound that the whole 2.x branch is now in maintenance mode which is far from the case. 2.2 should bring those of us using Cocoon significant advantages, and can continue to be an exciting place to operate for some time to come. 2.2-3.0 is _very_ different to 2.1-2.2. We can expect 2.1 to die relatively quickly, as apps can be ported with a manageable amount of effort. That will likely not be the case for 2.2-3.0, so therefore we can best consider 2.2 and 3.0 to be different products, rather than versions of the same thing. 2.2 will have a life, much like httpd 1.3 lived long after the release of 2.0. 2.2 needs exciting stuff too. At the same time, adding stax processing to it might though be a push too far. On another point - if 3.0 starts as an embedable pipeline engine, surely we can embed that into our existing 2.2 systems? Thus having hybrid systems working until such a point as we have migrated everything across to the new architecture. Regards, Upayavira
Re: 2.2 vs 3.0, or 2.2 then 3.0?
hepabolu wrote: Berin Loritsch wrote: Upayavira wrote: So, 2.2 = important, and 3.0 = important. Both. We need to avoid discussions, implications, emotions, etc that suggest otherwise. Right. If any of that has gone on, I'm sure its unintentional. If memory serves me correctly, Cocoon 2 was written as a branch, and Maintenance was happening on Cocoon 1 for a while. There did come a time when work stopped on Cocoon 1, but that was after Cocoon 2 was released. Basically, new/exciting stuff should go in Cocoon 3, and touch ups to Cocoon 2 until Cocoon 3 is ready for prime time. Fine, but times might be much more hectic now with less people having less time to contribute to either version. There is still the 2.1 branch to maintain as well. So I think that the time of maintaining 2 versions (actually 3) should be as short as possible and that apart from the current Maven and blocks nothing new should be added to 2.2, however exciting that may be. Actually, I tend to disagree. As has been pointed out, this is open source, so an exciting new 3.0 project could easily bring fresh blood, thus not depleting 2.x at all. More important I think is not only defining the vision of Cocoon 3.0 as precisely as possible (so all jumping up and down now, know exactly where to jump in), and coming up with a roadmap, but also to try and define/write conversion tools (however simple) almost from the beginning that can ease the transition from 2.1/2.2 to 3.0. If the tedious 60% can be done automatically, it shows the current user base they are not abandoned. Yup. AND PLEASE TAKE THE DOCUMENTATION INTO ACCOUNT! However rudimentary, write something, give an example and make sure the docs stay up-to-date. And with Daisy in place, this should be much easier. Regards, Upayavira
Re: [ignore] test
Sylvain Wallez wrote: knock knock... Apache Mail servers are struggling at the moment. Folks are working hard to sort it out. Upayavira
Re: [M10N] adding cron entry on the zone
Jorg Heymans wrote: I'ld like to add a cron entry to the zone for user maven to start pushing snapshots to the apache.org snapshot repo. Can someone add maven to /etc/cron.d/cron.allow and do any other necessary foo-magic so i can start cronning ? Alternatively, su to the maven account, and do crontab -e, and edit a cron entry for the maven user. Regards, Upayavira
Contributors (was Re: Planning 2.2)
Antonio Fiol Bonnín wrote:
2005/11/24, Pier Fumagalli [EMAIL PROTECTED]:
On 23 Nov 2005, at 21:34, Joerg Heinicke wrote:
On 23.11.2005 16:33, Antonio Fiol Bonnín wrote:
This can't possibly be what we need, as anyone would have done it
faster than me, but anyway, here it goes.
IIRC the problem was not the pure removal, but the mentioning of
the authors in a contrib file file.
svn blame http://svnbook.red-bean.com/en/1.0/re02.html
So, if I understood correctly, you would like to extract the history
of authors for every file:
#!/bin/bash
for i in $(find . -type f -not -name '*.svn-' | grep -v /\\.svn/)
do
echo $i
svn blame $i | awk '{print $2}' | sort | uniq
echo
done
But I find it hard to do it in a platform-independent way.
Well,
(a) I'm impressed with your little script
(b) it doesn't need to be platform independent - it will only be run
once.
(c) Actually, I wonder if this is something of a redherring. All it
will show us is the committers who have committed to CVS or SVN.
But we know that already. What we want to know is who has
contributed other than committers.
And if someone submits a patch, we can track the contribution in Jira.
I don't understand how this should work.
Well, we can use Jira to note contributions, and then manually copy them
into our contribution records. I imagine that is what Pier means.
Regards, Upayavira
Re: [M10N] adding cron entry on the zone
Jorg Heymans wrote: Upayavira wrote: Alternatively, su to the maven account, and do crontab -e, and edit a cron entry for the maven user. -bash-3.00$ whoami maven -bash-3.00$ crontab -e crontab: you are not authorized to use cron. Sorry. Oh well, another Linux/Solaris difference. Provide me with a crontab line and I'll add it to the root one. Regards, Upayavira
Re: [M10N] adding cron entry on the zone
Bertrand Delacretaz wrote: Le 25 nov. 05, à 17:15, Upayavira a écrit : ...Oh well, another Linux/Solaris difference. Provide me with a crontab line and I'll add it to the root one... Why not allow user maven to use crontab? It's certainly safer than running things as root. I have made the change requested by Jorg: $ cat /etc/cron.d/cron.allow root cdemos daisy maven Ah, that's what you get for not reading properly - I didn't take in the nature of the original request. Sorry for the noise Jorg. Upayavira
