Re: Merry Christmas
Simone Tripodi wrote: Dear Cocoon community, Merry Christmas and best wishes for a happy and prosperous New Year. All the best!!! the same to you :-) Cheers Michael Simone Tripodi
Re: Interest in link rewriting transformer?
Thorsten Scherler schrieb: On Wed, 2009-08-26 at 14:17 +0200, Andreas Hartmann wrote: Hi Cocoon devs, Lenya contains an AbstractLinkTransformer for link rewriting purposes. I'm using it for other Cocoon projects too. +1 to move it here. +1 Michael salu2
devs for hire
Dear All Wyona is looking for developers for hire (either as salaried employee or contract) for its Swiss office in Zurich. Some more information can be found at http://www.wyona.com/jobs.html Wyona is dedicated to Open Source and still believes in making ends meet :-). Zurich/Switzerland is a great place for mountain biking (and other out/indoor activities) and in December you will be invited by Wyona to watch the new James Bond movie :-) Please contact [EMAIL PROTECTED] or myself off this list. Cheers Michael -- Michael Wechner Wyona - Open Source Content Management - Yanel, Yulup http://www.wyona.com [EMAIL PROTECTED], [EMAIL PROTECTED] +41 44 272 91 61
Re: Micro-Cocoon ... Corona
Peter Hunsberger wrote: On Thu, Mar 13, 2008 at 10:40 AM, Reinhard Poetz [EMAIL PROTECTED] wrote: Reinhard Poetz wrote: sniplots of cool stuff/snip So far Corona has been developed mostly by Steven (~ 90 % by him, 10 % by me) behind closed doors but we would like to change that, if this community is interested in adopting it in this or that way. Is there any interest and if yes, how should we proceed? Very interested. I'd second throwing it into the white board if you're willing? +1 Michael -- Michael Wechner Wyona - Open Source Content Management - Yanel, Yulup http://www.wyona.com [EMAIL PROTECTED], [EMAIL PROTECTED] +41 44 272 91 61
Re: [PROPOSAL] Micro-Cocoon
Sylvain Wallez wrote: Jeroen Reijn wrote: Reinhard, sounds like a good thing. I guess not only Indoqa will get a benefit out of this. Put it in the whiteboard, so if needed and possible other people can help out and perhaps join the discussion? +1 ! +1 Michael Sylvain -- Michael Wechner Wyona - Open Source Content Management - Yanel, Yulup http://www.wyona.com [EMAIL PROTECTED], [EMAIL PROTECTED] +41 44 272 91 61
Re: lenya 2.0 release preparation - cocoon version dependency (2.1.11?)
Antonio Gallardo wrote: Bertrand Delacretaz escribió: Agree with Ralph, there's no need to close anything, if people want to fix bugs on older versions that's one of the beauties of open source: no one forces you to upgrade, as long as you're ready to fix what you're using if needed. +1 +1 Cheers Michael Best Regards, Antonio Gallardo. -- Michael Wechner Wyona - Open Source Content Management - Yanel, Yulup http://www.wyona.com [EMAIL PROTECTED], [EMAIL PROTECTED] +41 44 272 91 61
Re: Ideas for student projects
Reinhard Poetz wrote: Michael Wechner wrote: Reinhard Poetz wrote: Google announced the 3rd summer of code and this year. The Austrian Computer society launched a similar project, the OSS Contest Austria 2007. We as Cocoon project can make proposals about possible student projects. If you have ideas for such projects, add them to http://wiki.apache.org/cocoon/StudentProjectIdeas2007. The more ideas we have, the better for us! the link http://osscontest.ocg.at/ doesn't seem to work. And idea what might be wrong? works for me :-/ Does a DNS lookup on osscontest.ocg.at work for you? no, but www.ocg.at works fine Cheers Michael -- Michael Wechner Wyona - Open Source Content Management -Apache Lenya http://www.wyona.com http://lenya.apache.org [EMAIL PROTECTED][EMAIL PROTECTED] +41 44 272 91 61
Re: Ideas for student projects
Reinhard Poetz wrote: Google announced the 3rd summer of code and this year. The Austrian Computer society launched a similar project, the OSS Contest Austria 2007. We as Cocoon project can make proposals about possible student projects. If you have ideas for such projects, add them to http://wiki.apache.org/cocoon/StudentProjectIdeas2007. The more ideas we have, the better for us! the link http://osscontest.ocg.at/ doesn't seem to work. And idea what might be wrong? Cheers Michi If you are Cocoon committer and interested in mentoring a project, add yourself to the mentoring section of the document. Adding yourself now only means that you are generally interested. Of course it's on you to finally accept a student application or not. -- Michael Wechner Wyona - Open Source Content Management -Apache Lenya http://www.wyona.com http://lenya.apache.org [EMAIL PROTECTED][EMAIL PROTECTED] +41 44 272 91 61
Re: Add mime-type application/xhtml+xml to StreamGenerator
Carsten Ziegeler wrote: Michael Wechner wrote: Hi It seems to me that the mime-type application/xhtml+xml was missing from the StreamGenerator, so I have added it. Please let me know if this is causing any inconvenience. Can you please add this change to trunk as well? Thanks done core/cocoon-core/src/main/java/org/apache/cocoon/generation/StreamGenerator.java whereas I receive the following error when building with mvn -Dmaven.test.skip=true install the recent revision 424536 [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Error building POM (may not be this project's POM). Project ID: batik:batik-script Reason: Error getting POM for 'batik:batik-script' from the repository: Error transferring file batik:batik-script:pom:1.6 from the specified remote repositories: central (http://ibiblio.org/maven2), apache.snapshots (http://svn.apache.org/maven-snapshot-repository), apache.snapshot (http://svn.apache.org/maven-snapshot-repository), apache-cvs (http://svn.apache.org/repository) Are others experiencing the same problem? Thanks Michi Carsten -- Michael Wechner Wyona - Open Source Content Management -Apache Lenya http://www.wyona.com http://lenya.apache.org [EMAIL PROTECTED][EMAIL PROTECTED] +41 44 272 91 61
Add mime-type application/xhtml+xml to StreamGenerator
Hi It seems to me that the mime-type application/xhtml+xml was missing from the StreamGenerator, so I have added it. Please let me know if this is causing any inconvenience. Thanks Michi -- Michael Wechner Wyona - Open Source Content Management -Apache Lenya http://www.wyona.com http://lenya.apache.org [EMAIL PROTECTED][EMAIL PROTECTED] +41 44 272 91 61
[2.1.x] Patching enable-uploads during build
Hi I have modified build.properties src/webapp/WEB-INF/web.xml in order that one can actually patch the enable-uploads. Before my change one had always true for this no matter if one declared within (local.)build.properties: config.enable-uploads=false, because web.xml was set to true by default and xpatch with if-prop won't patch if the prop is set to false. So it works now, BUT I think the default setting within build.properties should be false and not true for security reasons, but I left the default behaviour as it was, because I don't know what was agreed on. Also I think one should enhance the xpatch such one can patch several times, because the way it works now is that if you patch it with true, then one cannot patch it to false anymore. It's basically a one way value patch. Thanks Michi -- Michael Wechner Wyona - Open Source Content Management -Apache Lenya http://www.wyona.com http://lenya.apache.org [EMAIL PROTECTED][EMAIL PROTECTED]
Re: [M10N] cocoon-jcr
David Nuescheler wrote: hi sylvain, does this help? http://www.day.com/maven/jsr170/licenses/day-spec-license.htm if i can do anything else to help, please let me know. it clearly is our intention that everybody should be able to redistribute the jcr-1.0.jar well, I will use your statement in front of a court (maybe in the future) to argue why we redistributed jcr-1.0.jar ;-) Although I am not sure if the word intention is enough versus the end of the second para: No license is granted hereunder for any other purpose (including, for example, modifying the Specification, other than to the extent of your fair use rights, or distributing the Specification to third parties) or am I misunderstanding something? Or what is the context of distributing the Specification to third parties? Thanks Michi regards, david -- Michael Wechner Wyona - Open Source Content Management -Apache Lenya http://www.wyona.com http://lenya.apache.org [EMAIL PROTECTED][EMAIL PROTECTED]
Re: W3C XML Processing working group
Gianugo Rabellino wrote: On 12/30/05, Sylvain Wallez [EMAIL PROTECTED] wrote: Hi all, The W3C recently set up an XML Processing working group[1] whose primary goal is to define an XML processing language (i.e. pipelines). Wow, innovation at work! :-) AFAIU the group's direction is not to reinvent something new, but to standardize what already exists, taking as inputs two pipeline languages that were submitted as W3C notes, namely Norman Walsh's[2] and XPL from Orbeon[3] (that BTW they claim to be the pipeline language that has in fact been used the most[4]. My impression is that what this WG will end up defining yet another programming language in XML, and that this language will either be very limited in the processing types it allows in order to be implemented on a wide range of platforms (including browsers), or allow a lot of extensibility, thus actually limiting its portability. WDYT, should we join the party? I think it would make sense to at least talk to them, or has this been done already? I'm not that much interested into yet another DSL expressed in XML, and I don't feel alone at all. Actually I'd much rather drift towards a programmatic pipeline API. what do you mean by a programmatic pipeline API? Thanks Michi Anyone has the guts to start a JSR on that? :) -- Gianugo Rabellino Pro-netics s.r.l. - http://www.pro-netics.com Orixo, the XML business alliance: http://www.orixo.com (blogging at http://www.rabellino.it/blog/) -- Michael Wechner Wyona - Open Source Content Management -Apache Lenya http://www.wyona.com http://lenya.apache.org [EMAIL PROTECTED][EMAIL PROTECTED]
Re: [RT][long] Cocoon 3.0: the necessary mutation
Sylvain Wallez wrote: All this to say that if we want Cocoon to have a bright future, it must go through a mutation. agreed Tell me your thoughts. Am I completely off-track, I cannot judge the technical implications you wrote about above, but I think I have the same feeling and I don't think at all that you are off the track. I also think that Cocoon would have the capability of representing the good side of both worlds (rapid prototyping as is possible with Ruby and on the other hand what J2EE land has to offer). Michi -- Michael Wechner Wyona - Open Source Content Management -Apache Lenya http://www.wyona.com http://lenya.apache.org [EMAIL PROTECTED][EMAIL PROTECTED]
Re: [vote] Ross Gardler as a new Cocoon committer
Ralph Goers wrote: Daniel Fagerstrom wrote: Hi all! I'd like to propose Ross Gardler as a Cocoon committer. He is one of the driving forces in the Forrest project, he has been quite active in our documentation efforts and in integrating Forrest, Lenya and Cocoon. Becoming a Cocoon committer will simplify his work and bring our communities closer. Please cast you votes. /Daniel +1 +1 Michi -- Michael Wechner Wyona - Open Source Content Management -Apache Lenya http://www.wyona.com http://lenya.apache.org [EMAIL PROTECTED][EMAIL PROTECTED]
including Zip Source within Cocoon
Hi It seems like the ZipSource has been removed from Cocoon, whereas it was part of Cocoon-2.1.6 within the scratchpad block. The ZipSource is very useful to open OpenDocument(s) and in combination with WebDAV allows editing with OpenOffice for instance. The pipeline to extract looks as follows: !-- Content of OpenDocument -- map:pipeline map:match pattern=**.odt map:generate src=zip://[EMAIL PROTECTED]/ map:serialize type=xml/ /map:match /map:pipeline I would like to suggest that we put these two classes (ZipSource and ZipSourceFactory) back into Cocoon (2.1.X branch) because I guess many people would be happy to easily render OpenDocument(s) and edith them with OpenOffice through WebDAV. WDYT? Thanks Michi -- Michael Wechner Wyona - Open Source Content Management -Apache Lenya http://www.wyona.com http://lenya.apache.org [EMAIL PROTECTED][EMAIL PROTECTED]
Re: [JCR Block] Viewing content of properties and last modified
Andreas Hartmann wrote: Michael Wechner wrote: what I meant was that I want to use the Source to get the content of the property, e.g. map:generate src=jcr://committers/andreas/email/ if email is a property then one should receive something like property name=email [EMAIL PROTECTED] /property whereas I am not sure if the above is correct JCR path syntax OK, now I see what you mean. That would be really useful, for instance to access Lenya meta data in presentation pipelines. I'll try to change the JCR block re properties. Any objections? Thanks Michi -- Michael Wechner Wyona - Open Source Content Management -Apache Lenya http://www.wyona.com http://lenya.apache.org [EMAIL PROTECTED][EMAIL PROTECTED]
Re: [JCR Block] Viewing content of properties and last modified
Andreas Hartmann wrote:
Michael Wechner wrote:
Sylvain Wallez wrote:
Michael Wechner wrote:
Hi
I have two questions re the JCR Block
1) How can one actually access the content of properties?
You cannot access them directly with the JCRNodeSource, which is
meant to represent file-like abstractions which are mapped to nodes.
wouldn't it make sense to actually implement this for JCR source?
I mean extend it to JCR properties.
In my sandbox, I implemented InspectableSource in JCRNodeSource
(I already posted a message some time ago).
can you send that to me that I can give it a try
How do you imagine providing access to the properties?
Property getProperty(...) {
return getNode().getProperty(...);
}
doesn't add much value ...
what do you mean by doesn't add much value?
Now such a source, you can get the corresponding Node and then do
whatever you want with it.
yes, I can list all nodes by using the TraversableGenerator, but I
think it
would make sense it the the JCR Source in combination with the
FileGenerator
would allow to get the content of a JCR property, e.g.
property name= value=
/property
That could probably be implemented using an
InspectableTraversableGenerator
or something like that ...
Well, I think it would make sense to stick to the source and map nodes
onto collections and properties onto resources.
But yes, as an alternative we could write a specific JCR Generator.
But one of the main questions probably is, can we (Cocoon community)
agree on something. At the moment it seems to me that only Sylvain's
company and
the Lenya community is using the JCR source, but want to use it in different
ways, right?
No offense, but it seems to me that the current JCR Source isn't very
useful,
beside being able to list all the nodes, or am I missing something?
Thanks
Michi
-- Andreas
--
Michael Wechner
Wyona - Open Source Content Management -Apache Lenya
http://www.wyona.com http://lenya.apache.org
[EMAIL PROTECTED][EMAIL PROTECTED]
Re: [JCR Block] Viewing content of properties and last modified
Andreas Hartmann wrote:
Michael Wechner wrote:
[...]
In my sandbox, I implemented InspectableSource in JCRNodeSource
(I already posted a message some time ago).
can you send that to me that I can give it a try
I attached the additional methods below.
To compile it, you have to add the dependency from the JCR
block to the repository block in gump.xml and enable the blocks
in local.blocks.properties.
thanks
How do you imagine providing access to the properties?
Property getProperty(...) {
return getNode().getProperty(...);
}
doesn't add much value ...
what do you mean by doesn't add much value?
Because getNode() can be called by the client code as well:
((JCRNodeSource) source).getNode().getProperty()
instead of
((JCRNodeSource) source).getProperty()
what I meant was that I want to use the Source to get the content of the
property, e.g.
map:generate src=jcr://committers/andreas/email/
if email is a property then one should receive something like
property name=email
[EMAIL PROTECTED]
/property
whereas I am not sure if the above is correct JCR path syntax
Now such a source, you can get the corresponding Node and then do
whatever you want with it.
yes, I can list all nodes by using the TraversableGenerator, but I
think it
would make sense it the the JCR Source in combination with the
FileGenerator
would allow to get the content of a JCR property, e.g.
property name= value=
/property
That could probably be implemented using an
InspectableTraversableGenerator
or something like that ...
Well, I think it would make sense to stick to the source and map nodes
onto collections and properties onto resources.
Do you mean something like that?
node - directory
property - file
That would certainly make sense, because it allows to resemble arbitrary
JCR repos using a file system.
yes, whereas in the terminology of TraversableGenerator it would be
node - collection
property - resource
Michi
--
Michael Wechner
Wyona - Open Source Content Management -Apache Lenya
http://www.wyona.com http://lenya.apache.org
[EMAIL PROTECTED][EMAIL PROTECTED]
Re: [JCR Block] Viewing content of properties and last modified
Sylvain Wallez wrote: Michael Wechner wrote: Hi I have two questions re the JCR Block 1) How can one actually access the content of properties? You cannot access them directly with the JCRNodeSource, which is meant to represent file-like abstractions which are mapped to nodes. wouldn't it make sense to actually implement this for JCR source? I mean extend it to JCR properties. Now such a source, you can get the corresponding Node and then do whatever you want with it. yes, I can list all nodes by using the TraversableGenerator, but I think it would make sense it the the JCR Source in combination with the FileGenerator would allow to get the content of a JCR property, e.g. property name= value= /property 2) I don't fully understand how lastModified is being handled. From looking at the implementation it seems to me that only content nodes can have a lastModified, but I probably misunderstand something, right? The idea here is that the node holding the content also holds the property that gives the last modification. The distinction between file node and content node is more a point of view, and a given node should be able to have both roles. nodes which don't have the content role, but maybe are just a collection should also have a last modified, because they might received a new child, right. It seems to me otherwise for instance the TraversableGenerator won't reread the node show the new children, or am I confusing something. Thanks Michi -- Michael Wechner Wyona - Open Source Content Management -Apache Lenya http://www.wyona.com http://lenya.apache.org [EMAIL PROTECTED][EMAIL PROTECTED]
[JCR Block] Viewing content of properties and last modified
Hi I have two questions re the JCR Block 1) How can one actually access the content of properties? 2) I don't fully understand how lastModified is being handled. From looking at the implementation it seems to me that only content nodes can have a lastModified, but I probably misunderstand something, right? Thanks Michi -- Michael Wechner Wyona - Open Source Content Management -Apache Lenya http://www.wyona.com http://lenya.apache.org [EMAIL PROTECTED][EMAIL PROTECTED]
Re: Finally creating Doco
Ross Gardler wrote: I seem to recall a conversation with Gregor in which he was explaining that Lenya can integrate with SVN via the WebDav support, is this correct? in worst case we can always use/call the command line of SVN. I have written once some Java classes to this for CVS and we could reuse this very easily NOTE I'm thinking of proposing a talk on this for ApacheCon now that the deadline has been extended, however, I don't wnat to propose it if Lenya is not able to use SVN as a repository as without that I don't think I could implement it in time. if needed I can provide the CVS/Java classes to you and you would just have to replace the cvs by the svn command. I think it would be great if you could submit a talk on this Michi Ross - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Michael Wechner Wyona - Open Source Content Management -Apache Lenya http://www.wyona.com http://lenya.apache.org [EMAIL PROTECTED][EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jcr] Scope of JCRNodeSource
Cédric Damioli wrote: Andreas Hartmann a écrit : Cédric Damioli wrote: Hi Andreas, This block is really in an very early stage of development. In the actually committed version, it does not work as expected. Sylvain first wrote this JCRNodeSource for my own needs (I am one of his coworkers) and I've applied many many patches to it without contributing them back to Cocoon. BTW - are you planning to provide your work to the project? I'm just asking because I want to avoid doing work which has already been done :) -- Andreas Yes, it is in our TODO list... We have to fix some bugs and so on, and we will contribute our changes. But I'm afraid we won't have much time in the next few days to play with the JCR stuff... you might want to attach the fixes to Bugzilla and someone else will contribute them ;-) Michi BTW the JCRNodeSource in itself does not do much : it is only Traversable and Modifiable. IMHO, one of its most interesting method is getNode(), which provide access to JCR Node :-) Regards, Cédric -- Michael Wechner Wyona - Open Source Content Management -Apache Lenya http://www.wyona.com http://lenya.apache.org [EMAIL PROTECTED][EMAIL PROTECTED]
Re: [jcr] Scope of JCRNodeSource
Cédric Damioli wrote: Sylvain and I have actually had different ideas about what a JCRSource must be. I personally thought about an entry point to every JCR Item in the Repository (it appears it is what you want too) Sylvain thought more about a TraversableSource with directories and files (actually nt:directory and nt:file Nodes). I would be interested to known your usecases. I think both ;-) In the case of Lenya one probably is more nt:directory and nt:file oriented, but for less document oriented applications this doesn't necessarily makes sense. Michi Regards, Cédric -- Michael Wechner Wyona - Open Source Content Management -Apache Lenya http://www.wyona.com http://lenya.apache.org [EMAIL PROTECTED][EMAIL PROTECTED]
Re: Moving TraversableGenerator into Cocoon core
Sylvain Wallez wrote: Nope. And while you're at it (/me is lazy), would you mind moving also CSVGenerator? sure (if nobody else minds). So I will move TraversableGenerator XPathTraversableGenerator CVSGenerator I will try to do this by Wednesday or Thursday, because I will be offline for the next 2 days. This gives also some more time for other people to think about it. Michi There's been a number of people asking for this and didn't noticed we already had it! Sylvain -- Michael Wechner Wyona - Open Source Content Management -Apache Lenya http://www.wyona.com http://lenya.apache.org [EMAIL PROTECTED][EMAIL PROTECTED]
Re: Moving TraversableGenerator into Cocoon core
Gregor J. Rothfuss wrote: ideally, the two would be merged, and the traversable generator would emit the directory xml format for file sources for compatibility agreed, but I think for backwards compatibility reasons we cannot do this. But we might want to deprecate the DirectoryGenerator and add an optional parameter to the TraversableGenerator to enable the output in directory generator syntax. Makes sense? Michi (with a clear note to change the stylesheets) and then eventually rip out the directory xml. -- Michael Wechner Wyona - Open Source Content Management -Apache Lenya http://www.wyona.com http://lenya.apache.org [EMAIL PROTECTED][EMAIL PROTECTED]
Re: Moving TraversableGenerator into Cocoon core
Sylvain Wallez wrote: Michael Wechner wrote: Nope. And while you're at it (/me is lazy), would you mind moving also CSVGenerator? I just noticed that joerg has already moved the Traversables on Sat 23 ;-) Michi -- Michael Wechner Wyona - Open Source Content Management -Apache Lenya http://www.wyona.com http://lenya.apache.org [EMAIL PROTECTED][EMAIL PROTECTED]
Moving TraversableGenerator into Cocoon core
Hi I would like to suggest that we move the TraversableGenerator into Cocoon core. It seems to me that the TraversableGenerator is very useful, because it supports the excalibur Source in general and not just the FileSource like the DirectoryGenerator. Otherwise people have to enable the repository block which has some dependencies which are not that obvious (e.g. JMS) WDYT? If most people are positive on this, does something like this require a vote? Thanks Michi -- Michael Wechner Wyona - Open Source Content Management -Apache Lenya http://www.wyona.com http://lenya.apache.org [EMAIL PROTECTED][EMAIL PROTECTED]
Re: DirectoryGenerator using abstract Source
Joerg Heinicke wrote: On 14.07.2005 10:59, Gianugo Rabellino wrote: 1. move TraversableGenerator to src/core, +1 +1 deprecate DirectoryGenerator leaving it untouched Read below. 2. insert some log.xxx(DG is now deprecated, please use TG instead), where xxx is promoted from debug to error in a few release cycles 3. optionally start introducing XMLGenerator the same way (though the only path I can foresee is via cp) In any case, avoid extends like the plague. If anything, the hassle we're going to have because of that bunch of generators extending DG should prove how extends can be harmful. Actually, it might be worth thinking about refactoring the whole stuff using composition. Yeah, I know: prefer composition over inheritance. And it might improve the DGs we have. But when we make DG extending TG just for a naming issue I see no advantage in composition and adding so many delegating methods. And why do you want to leave DG untouched at all? Couldn't TG do the same? what implementing the DG XML syntax into TG if the Source is a FileSource? Regarding 3.: +1 for doing it the same way - what ever we will decide. I think the name XMLGenerator is not very clear, although I have to admit as was pointed out that ResourceGenerator is also not very clear. But I think it would make sense to generalize it somehow anyway. btw, I made a note within the javadoc of DirectoryGenerator pointing to the TraversableGenerator Michi Joerg -- Michael Wechner Wyona - Open Source Content Management -Apache Lenya http://www.wyona.com http://lenya.apache.org [EMAIL PROTECTED][EMAIL PROTECTED]
JCR samples added
Hi I have added a JCR samples within BRANCH_2_1_X (src/blocks/jcr/samples/). Beside that I have upgraded to JCR-1.0 and Jackrabbit-1.0-dev and implemented the loading of jaas.config. Any feedback is very welcome. Thanks Michi -- Michael Wechner Wyona - Open Source Content Management -Apache Lenya http://www.wyona.com http://lenya.apache.org [EMAIL PROTECTED][EMAIL PROTECTED]
Re: JCR samples added
Carsten Ziegeler wrote: Michael Wechner wrote: Hi I have added a JCR samples within BRANCH_2_1_X (src/blocks/jcr/samples/). Beside that I have upgraded to JCR-1.0 and Jackrabbit-1.0-dev and implemented the loading of jaas.config. Can you please keep the trunk (2.2) in sync? sure, but I am bit confused about the trunk, because I am not sure why X src/blocks/jcr within the BRANCH_2_1_X is treated as external (pointing to the trunk) or am I cofusing something else here? Any help on this is appreciated Michi Carsten -- Michael Wechner Wyona - Open Source Content Management -Apache Lenya http://www.wyona.com http://lenya.apache.org [EMAIL PROTECTED][EMAIL PROTECTED]
Re: JCR samples added
Leo Leonid wrote: On Jul 15, 2005, at 6:04 PM, Carsten Ziegeler wrote: Michael Wechner wrote: Carsten Ziegeler wrote: Michael Wechner wrote: Hi I have added a JCR samples within BRANCH_2_1_X (src/blocks/jcr/ samples/). Beside that I have upgraded to JCR-1.0 and Jackrabbit-1.0-dev and implemented the loading of jaas.config. Can you please keep the trunk (2.2) in sync? sure, but I am bit confused about the trunk, because I am not sure why X src/blocks/jcr within the BRANCH_2_1_X is treated as external (pointing to the trunk) or am I cofusing something else here? D'oh, you're right of course. So you just have to sync everything which is not directly inside the blocks/jcr directory, like jars, gump.xml?, status etc. Carsten With current build I still get an Initialization Problem when accessing to the server: java.io.FileNotFoundException: /home/leo/BRANCH_2_1_X/build/webapp/ samples/repository.xml (No such file or directory) org.apache.avalon.framework.configuration.ConfigurationException: Cannot access configuration information at file:/home/leo/ BRANCH_2_1_X/build/webapp/WEB-INF/cocoon.xconf:2076:106 at org.apache.cocoon.jcr.JackrabbitRepository.configure (JackrabbitRepository.java:93) at org.apache.avalon.framework.container.ContainerUtil.configure (ContainerUtil.java:240) So, the sync isn't all done already, or is it? no, this is something else. When one enables the jcr block within blocks.properties or local.blocks.properties then one needs to copy the src/blocks/jcr/samples into build/webapp/ such that the compenent can find the repository.xml file. But I just realize that blocks.properties has jcr block enabled by default, but the samples won't be copied automatically. Sorry for this. I will do a quick fix by disabling the block by default. I am not sure if this was the reason that Sylvain didn't put in the xconf of the component. Is there a possibility that if the jcr block is enabled, that also the samples are being copied? Michi /Leo -- Michael Wechner Wyona - Open Source Content Management -Apache Lenya http://www.wyona.com http://lenya.apache.org [EMAIL PROTECTED][EMAIL PROTECTED]
Re: JCR samples added
Michael Wechner wrote: Is there a possibility that if the jcr block is enabled, that also the samples are being copied? Please ignore my last message. I was totally confused, because I used a local.build.properties where the samples were disabled and copied the samples of jcr by hand. I have fixed the paths within src/blocks/jcr/conf/jcr-component.xconf and it should work now (please update your local workspace and clean/build Cocoon again). Please apologize for any inconvenience Michi Michi /Leo -- Michael Wechner Wyona - Open Source Content Management -Apache Lenya http://www.wyona.com http://lenya.apache.org [EMAIL PROTECTED][EMAIL PROTECTED]
Re: JCR samples added
Carsten Ziegeler wrote: X src/blocks/jcr within the BRANCH_2_1_X is treated as external (pointing to the trunk) or am I cofusing something else here? D'oh, you're right of course. So you just have to sync everything which is not directly inside the blocks/jcr directory, like jars, gump.xml?, status etc. ok, will do that. Michi Carsten -- Michael Wechner Wyona - Open Source Content Management -Apache Lenya http://www.wyona.com http://lenya.apache.org [EMAIL PROTECTED][EMAIL PROTECTED]
Re: DirectoryGenerator using abstract Source
Joerg Heinicke wrote: On 13.07.2005 23:38, Gianugo Rabellino wrote: DirectoryGenerator extends TraversableGenerator We've been through this before: http://marc.theaimsgroup.com/?t=10578281593r=1w=2 In a word: backward compatibility. Wow, 2 years ago! And what about starting a real migration now by starting with the unclean way (DirectoryG extends TraversableG with old namespace and directory/file metaphore as you wrote it), deprecating it at the same time and making the TraversableG the officially supported one? just one note re such a migration. Wouldn't it make sense to actually rename the TraversableGenerator to CollectionGenerator and introduce something like ResourceGenerator (or does that exist already?) and do DirectoryGenerator extends CollectionGenerator FileGenerator extends ResourceGenerator such that the terminology is consistent? Michi Joerg -- Michael Wechner Wyona - Open Source Content Management -Apache Lenya http://www.wyona.com http://lenya.apache.org [EMAIL PROTECTED][EMAIL PROTECTED]
Re: DirectoryGenerator using abstract Source
Joerg Heinicke wrote: On 13.07.2005 00:28, Michael Wechner wrote: It seems to me that the directory generator is not really based on the abstract methods of an excalibur Source, but rather takes the source and maps it onto a java.io.File. Is that intended or just not implemented for the lack of time? I would like to make this more generic with regard to other sources, e.g. JCR or whatever. If this makes sense then I would patch the DirectoryGenerator, but otherwise I would write a DirectoryGenerator from scratch, e.g CollectionGenerator which is making use the TraversableSource interface. You don't have to: $COCOON_HOME/src/blocks/repository/java/org/apache/cocoon/generation/TraversableGenerator.java thanks very much for the pointer. I think it would make sense to make a note within the DirectoryGenerator that the TraversableGenerator exists and is more generic. Michi Joerg -- Michael Wechner Wyona - Open Source Content Management -Apache Lenya http://www.wyona.com http://lenya.apache.org [EMAIL PROTECTED][EMAIL PROTECTED]
Re: DirectoryGenerator using abstract Source
Unico Hommes wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Michael Wechner wrote I think it would make sense to make a note within the DirectoryGenerator that the TraversableGenerator exists and is more generic. In fact IMHO, it should be deprecated in favor of TraversableGenerator... I didn't dare to suggest that ;-), but on the other hand I have to say, that DirectoryGenerator sounds more familiar than TraversableGenerator, but maybe one just wants to subclass it: DirectoryGenerator extends TraversableGenerator WDYT? Michi - -- Unico -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (Darwin) iD8DBQFC1UORcuec8tVNKAwRAiA4AJ94XDoBh0ACS2iTFW+uqTDcIBJ6lQCg34Fr xYZdDb1pyefSC/Wlf2FAyjw= =y0i0 -END PGP SIGNATURE- -- Michael Wechner Wyona - Open Source Content Management -Apache Lenya http://www.wyona.com http://lenya.apache.org [EMAIL PROTECTED][EMAIL PROTECTED]
Re: DirectoryGenerator using abstract Source
Gianugo Rabellino wrote: On 7/13/05, Michael Wechner [EMAIL PROTECTED] wrote: Unico Hommes wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Michael Wechner wrote I think it would make sense to make a note within the DirectoryGenerator that the TraversableGenerator exists and is more generic. In fact IMHO, it should be deprecated in favor of TraversableGenerator... I didn't dare to suggest that ;-), but on the other hand I have to say, that DirectoryGenerator sounds more familiar than TraversableGenerator, but maybe one just wants to subclass it: DirectoryGenerator extends TraversableGenerator We've been through this before: http://marc.theaimsgroup.com/?t=10578281593r=1w=2 ok, you were there 2 years ago where I am now ;-) In a word: backward compatibility. you mean re XML output? But we could at least deprecate it and point to the TraversableGenerator. Michi Ciao, -- Michael Wechner Wyona - Open Source Content Management -Apache Lenya http://www.wyona.com http://lenya.apache.org [EMAIL PROTECTED][EMAIL PROTECTED]
DirectoryGenerator using abstract Source
Hi It seems to me that the directory generator is not really based on the abstract methods of an excalibur Source, but rather takes the source and maps it onto a java.io.File. Is that intended or just not implemented for the lack of time? I would like to make this more generic with regard to other sources, e.g. JCR or whatever. If this makes sense then I would patch the DirectoryGenerator, but otherwise I would write a DirectoryGenerator from scratch, e.g CollectionGenerator which is making use the TraversableSource interface. WDYT? Michi -- Michael Wechner Wyona - Open Source Content Management -Apache Lenya http://www.wyona.com http://lenya.apache.org [EMAIL PROTECTED][EMAIL PROTECTED]
Getting started with JCR block
Hi I am trying to get started with the JCR block, but I am bit confused where to specify the repository.xml (and jaas.config). I have added source-factories component-instance name=jcr class=org.apache.cocoon.jcr.source.JCRSourceFactory ... /component-instance to cocoon.xconf and receive the following exception: org.apache.avalon.framework.CascadingRuntimeException: Cannot lookup repository at org.apache.cocoon.jcr.source.JCRSourceFactory.lazyInit(JCRSourceFactory.java:214) at org.apache.cocoon.jcr.source.JCRSourceFactory.getSource(JCRSourceFactory.java:226) at org.apache.excalibur.source.impl.SourceResolverImpl.resolveURI(SourceResolverImpl.java:208) btw, there seems to be a small typo within the Javadoc of JCRSourceFactory. I guess it should read component-instance instead just component. Thanks Michi -- Michael Wechner Wyona - Open Source Content Management -Apache Lenya http://www.wyona.com http://lenya.apache.org [EMAIL PROTECTED][EMAIL PROTECTED]
Re: [VOTE] Document Editors, and a new Committer
Upayavira wrote: Thank you Upayavira. Even if I'm not convinced yet it's the best possible solution to make Cocoon doc more alive, I'm really interested in trying it. So what's the next step ? Register on the site (cocoon.zones.apache.org/daisy), I think it should read /daisy/ otherwise an exception is being thrown. Maybe somebody wants add a redirect. just my 2 cents Michi -- Michael Wechner Wyona Inc. - Open Source Content Management - Apache Lenya http://www.wyona.com http://lenya.apache.org [EMAIL PROTECTED][EMAIL PROTECTED]
Re: [VOTE] Document Editors, and a new Committer
Tim Larson wrote: On Thu, Jun 09, 2005 at 02:14:44PM +0200, Bertrand Delacretaz wrote: Le 9 juin 05, ? 11:52, Upayavira a ?crit : ...As granting committership requires a vote, please cast your votes now: [ ] Helma Van Der Linden as a Cocoon committer +1 Welcome! +1 Also, I'd like to invite both Mark Leicester and Glen Ezkovich to be editors... +1 +1 Although this doesn't require a vote IIUC: +1, for Sebastien as well. +1 +1 Michi -- Michael Wechner Wyona Inc. - Open Source Content Management - Apache Lenya http://www.wyona.com http://lenya.apache.org [EMAIL PROTECTED][EMAIL PROTECTED]
Re: New JCR block
Sylvain Wallez wrote: Your feedback and opinions about this initial implementation and its future evolutions are more than welcome! very cool. I will check how it will fit together with the Lenya specific stuff http://svn.apache.org/repos/asf/lenya/sandbox/jcrsitetree/ Re the JCR library lib/optional/jcr-0.16.4.jar, is it really allowed to re-distribute this? Re the Jackrabbit library lib/optional/jackrabbit-20050422T153417.jar, I think it would make sense to use the LCR (Last Changed Revision) number instead the date within the filename. Thanks Michi Enjoy, Sylvain -- Michael Wechner Wyona Inc. - Open Source Content Management - Apache Lenya http://www.wyona.com http://lenya.apache.org [EMAIL PROTECTED][EMAIL PROTECTED]
Re: New JCR block
Sylvain Wallez wrote: Michael Wechner wrote: Sylvain Wallez wrote: Your feedback and opinions about this initial implementation and its future evolutions are more than welcome! very cool. I will check how it will fit together with the Lenya specific stuff http://svn.apache.org/repos/asf/lenya/sandbox/jcrsitetree/ Re the JCR library lib/optional/jcr-0.16.4.jar, is it really allowed to re-distribute this? Re the Jackrabbit library lib/optional/jackrabbit-20050422T153417.jar, I think it would make sense to use the LCR (Last Changed Revision) number instead the date within the filename. I'm no subversion expert, hence my hesitation to use it. How does this LCR behave when the last commit was done somewhere deep in the hierarchy and not on the checkout root? LCR is global in the sense that it is valid for all subdirectories. Give it a try by running svn info within your jackrabbit/trunk directory ;-) As Torsten is poiting out, it would make sense for all Subversion based libraries which don't have a release version (whereas a release could actually be mapped onto a LCR) Michi -- Michael Wechner Wyona Inc. - Open Source Content Management - Apache Lenya http://www.wyona.com http://lenya.apache.org [EMAIL PROTECTED][EMAIL PROTECTED]
[JOB] Project Manager at Wyona
Hi Wyona is looking for a Project Manager for its Boston/Cambridge (USA) office. The requirements are: - 3+ years project management experience in a distributed development environment - Experience with managing Java related projects - Enthusiasm for working in an Open Source environment - Preferably experience with Lenya and Cocoon or other Apache projects - Enthusiasm for interacting with software developers and customers Please contact me off the list if you are interested ([EMAIL PROTECTED]) Thanks Michi -- Michael Wechner Wyona Inc. - Open Source Content Management - Apache Lenya http://www.wyona.com http://lenya.apache.org [EMAIL PROTECTED][EMAIL PROTECTED]
Re: Bug in XInclude transformer?
Joachim Breitsprecher wrote: Hi all, I think I found a bug in Cocoon's XInclude transformer. Try this pipeline: map:match pattern=test map:generate src=test.xml / map:transform type=xinclude / map:serialize type=xml / /map:match whith test.xml containing: ?xml version=1.0 encoding=utf-8 ? root xmlns:xi=http://www.w3.org/2001/XInclude; xi:include href=this_file_does_not_exist.xml xi:fallback elementThis should be here if the file was not found/element /xi:fallback /xi:include /root With all cocoon versions I tested (2.1.4, 2.1.5.1, 2.1.6, SVN head) this pipeline gives me an unbalanced output if this_file_does_not_exist.xml doesn't exist. what do you mean by unbalanced output? I have prepared a patch against the current SVN version and am ready to file a bug if no-one objects :-) Have you filed this patch yet? Michi Regards, Joachim -- Michael Wechner Wyona Inc. - Open Source Content Management - Apache Lenya http://www.wyona.com http://lenya.apache.org [EMAIL PROTECTED][EMAIL PROTECTED]
Re: Experimental per-sitemap reloadable classloader
Sylvain Wallez wrote: The funny thing is that *all* sitemap resources how are relative to the trunk... maybe something to do with symlinks? Hmmm... could this be a problem with File.getPath() or File.getCanonicalPath() on symlinks? getAbsolutePath() and getCanonicalPath() in combination can definitely create conflicts ;-) Just my two cents Michi -- Michael Wechner Wyona Inc. - Open Source Content Management - Apache Lenya http://www.wyona.com http://lenya.apache.org [EMAIL PROTECTED][EMAIL PROTECTED]
Re: Any JCR (JSR-170) scratchpad code for Cocoon yet?
Sylvain Wallez wrote: Stefano Mazzocchi wrote: Sylvain Wallez wrote: Will the scheme be named jcr? Yes, but the scheme can be anything you want, especially as you may use several repositories within the same webapp, and therefore use jcr1, jcr2, etc. ah! Please, do jcr://repo/* instead! I thought about that, but I'm not sure it is the best as: - most apps will use a single repo - I'd like to provide pure JCR repos using JNDI and pure Jackrabbit where the component config is or points to the Jackrabbit config, and these will be different implementations of SourceFactory what about specifying the repo as parameter, e.g. map:generate src=jcr://... map:parameter name=repo value=.../ /map:generate whereas if not parameter is being specified a default repo is being used? Michi -- Michael Wechner Wyona Inc. - Open Source Content Management - Apache Lenya http://www.wyona.com http://lenya.apache.org [EMAIL PROTECTED][EMAIL PROTECTED]
Re: Any JCR (JSR-170) scratchpad code for Cocoon yet?
Sylvain Wallez wrote: Torsten Schlabach wrote: Sylvain, I'm currently writing such a source ;-) Will it show up in a separate block in 2.2-dev soon? Yes. Maybe even 2.1, as I needed for a 2.1 project. cool. I would be happy to help and testdrive when you will check in your stuff Michi -- Michael Wechner Wyona Inc. - Open Source Content Management - Apache Lenya http://www.wyona.com http://lenya.apache.org [EMAIL PROTECTED][EMAIL PROTECTED]
Re: Any JCR (JSR-170) scratchpad code for Cocoon yet?
Upayavira wrote: Michael Wechner wrote: what about specifying the repo as parameter, e.g. map:generate src=jcr://... map:parameter name=repo value=.../ /map:generate Because this is a source, not a generator. The parameter would be a parameter to the generator. ok. Well, I thought the generator could pass it on to the source, but I guess I don't fully understand how it should work. Will try to figure it out. But on the other hand I don't fully understand why Sylvan would like to use jcrX://... instead of jcr://X/... as Stefano suggested, which seems to make more sense. Michi Regards, Upayavira -- Michael Wechner Wyona Inc. - Open Source Content Management - Apache Lenya http://www.wyona.com http://lenya.apache.org [EMAIL PROTECTED][EMAIL PROTECTED]
Re: Guidelines for linked projects from our site
Antonio Gallardo wrote: Hi: Yesterday, on the user list was a post for a link of a project that use a Collaborative License. This kind of license is not OSI aproved. I read about this license and for my eyes is a closed source license. We currently have this page: http://cocoon.apache.org/link/projects.html The question is: we can allow software using non-OSI license to be linked from our site? To me the asnwer is a clear NO. I think every project which the Cocoon community thinks it's worth linking to should be linked to no matter if open or closed. It might make sense to mention the license, because many projects don't make it very clear, which can be misleading sometimes. Michi But I want to ping community to be sure that this is the correct decision. ;-) WDYT? Best Regards, Antonio Gallardo. -- Michael Wechner Wyona Inc. - Open Source Content Management - Apache Lenya http://www.wyona.com http://lenya.apache.org [EMAIL PROTECTED][EMAIL PROTECTED]
Re: cocoon-reload bug
Stefano Mazzocchi wrote: latest checkout from 2.2, turn allow-reload true in web.xml and when I hit a page with 'cocoon-reload=true' I get an IllegalStateException: The cocoon-ehcache-4 Cache is not alive. which goes away as soon as I reload it. we experience similar problems with Lenya and Cocoon-2.1.6 whereas these problems do not occur with Cocoon-2.1.5 So far none of us has found a solution, except by suggesting to replace the ehcache by something else Michi I can't be the only one hitting this how do you guys develop on cocoon without reloading? -- Michael Wechner Wyona Inc. - Open Source Content Management - Apache Lenya http://www.wyona.com http://lenya.apache.org [EMAIL PROTECTED][EMAIL PROTECTED]
Re: cocoon-showtime
Carsten Ziegeler wrote: WDYT? Yepp, it's not that much but anyway it can be saved. I just applied a patch. thanks very much Sorry for bothering once more, but re my question, wouldn't it make sense to have a more standardized log message, e.g. IPNUMBER - - [DATE] GET /lenya/default/live/css/page.css PROTOCOL - Processed by Cocoon-X in milliseconds ? I am aware that one could configure the servlet container accordingly, but if someone turns on logging resp. the log level INFO it would certainly help re debugging. Thanks Michi Thanks Carsten -- Michael Wechner Wyona Inc. - Open Source Content Management - Apache Lenya http://www.wyona.com http://lenya.apache.org [EMAIL PROTECTED][EMAIL PROTECTED]
Re: Adding the sitemap path to Cocoon's Request object
Gianugo Rabellino wrote: the best place being o.a.c.environment.Request (which will provide immediate user access through the RequestInputModule). I am very bad in naming stuff, but I would say that something like getSitemapPath() could do the trick. +1 for having such a method, but shouldn't it rather belong to the sitemap, which is being passed or am I misunderstand something? Michi -- Michael Wechner Wyona Inc. - Open Source Content Management - Apache Lenya http://www.wyona.com http://lenya.apache.org [EMAIL PROTECTED][EMAIL PROTECTED]
logging requests by CocoonServlet
I just played around a bit with the CocoonServlet and thought it might
make sense to log the requests similar to Apache httpd does, e.g.
getLogger().info(request.getRemoteAddr() + - - [ + new
java.text.SimpleDateFormat().format(new java.util.Date(end)) + ] \ +
request.getMethod() + + uri + + request.getProtocol() + \ -
+ timeString);
Would it make sense to replace the current
getLogger().info(' + uri + ' + timeString);
by the above? WDYT?
Michi
--
Michael Wechner
Wyona Inc. - Open Source Content Management - Apache Lenya
http://www.wyona.com http://lenya.apache.org
[EMAIL PROTECTED][EMAIL PROTECTED]
cocoon-showtime
I just learned that if one adds
htttp://../cocoon/html?cocoon-showtime=true (or whatever)
then the Cocoon Servlet is adding the following line to the very end of the
HTML, e.g.
pProcessed by Apache Cocoon 2.1.6 in 30 milliseconds./p
It seems to me that the method calculating this string should only be called if
actually needed:
if (getLogger().isInfoEnabled()) {
processTime(end - start)
and
if (show)
processTime(end - start)
because it saves some time within production envs, maybe just very little,
but still...
WDYT?
Michi
--
Michael Wechner
Wyona Inc. - Open Source Content Management - Apache Lenya
http://www.wyona.com http://lenya.apache.org
[EMAIL PROTECTED][EMAIL PROTECTED]
HttpRequest handling docu up to date?
Is the HttpRequest Handling docu still up to date? http://cocoon.apache.org/2.1/developing/httprequest.html#HttpRequest+handling If necessary, the Manager asks the Handler to regenerate its sitemap class. (FIXME: As of today, 2000-11-08, I'm not sure if the if necessary check is working). Regeneration exists in: The Handler gets the program-generator Component from its Comp... Thanks Michi -- Michael Wechner Wyona Inc. - Open Source Content Management - Apache Lenya http://www.wyona.com http://lenya.apache.org [EMAIL PROTECTED][EMAIL PROTECTED]
Re: DOMStreamer / Cocoon Initialization error patch to 2.1.7
Ken Wasetis wrote: Hello, I saw a recent post regarding the DOMStreamer patch and related Cocoon Initialization Error after a full Cocoon rebuild (though with a status of 'successful'.) I don't think these are related, but it's rather that I just noted there is another problem and Vadim hinted that he or somebody else might be able to look into it I'm also interested in this fix. Is this something that will take a day or two (so I can wait)? Or, should I use a previous branch? I would suggest to use the Cocoon-2.1.7-dev resp. branches/BRANCH_2_1_X branch where the DOMStreamer has been fixed (or use Cocoon-2.1.6 and apply the patch provided within Lenya) HTH Michi Not trying to be impatient. I just need to demo something in the coming days. Thanks, Ken -- Michael Wechner Wyona Inc. - Open Source Content Management - Apache Lenya http://www.wyona.com http://lenya.apache.org [EMAIL PROTECTED][EMAIL PROTECTED]
DOMStreamer patched: default namespace and non-empty prefix of attributes
Within Lenya we have encountered a problem with the
o.a.c.xml.dom.DOMStreamer re default namespace and non-empty prefix for
attributes. Thanks to Josias Thoeny the bug has been fixed and I have
checked it into Cocoon-2.1.7-dev (BRANCH_2_1_X)
--- src/java/org/apache/cocoon/xml/dom/DOMStreamer.java (revision 151344)
+++ src/java/org/apache/cocoon/xml/dom/DOMStreamer.java (working copy)
@@ -396,7 +396,7 @@
// if the prefix is null, or the prefix
has not been declared, or conflicts with an in-scope binding
if (declaredUri == null ||
!declaredUri.equals(attrNsURI)) {
String availablePrefix =
currentElementInfo.findPrefix(attrNsURI);
-if (availablePrefix != null)
+if (availablePrefix != null
!availablePrefix.equals())
assignedAttrPrefix =
availablePrefix;
else {
Please let us know if there might be a regression.
Thanks
Michi
--
Michael Wechner
Wyona Inc. - Open Source Content Management - Apache Lenya
http://www.wyona.com http://lenya.apache.org
[EMAIL PROTECTED][EMAIL PROTECTED]
Re: DOMStreamer patched: default namespace and non-empty prefix of attributes
Vadim Gritsenko wrote: Michael Wechner wrote: Within Lenya we have encountered a problem with the o.a.c.xml.dom.DOMStreamer re default namespace and non-empty prefix for attributes. Thanks to Josias Thoeny the bug has been fixed and I have checked it into Cocoon-2.1.7-dev (BRANCH_2_1_X) What about trunk? I didn't patch it within the trunk Is it already there, or you are waiting on something? waiting, to get some feedback ;-) Just don't want it to get out of sink, ok, shall I also patch it within the trunk? Michi Regards, Vadim -- Michael Wechner Wyona Inc. - Open Source Content Management - Apache Lenya http://www.wyona.com http://lenya.apache.org [EMAIL PROTECTED][EMAIL PROTECTED]
Re: DOMStreamer patched: default namespace and non-empty prefix of attributes
Ugo Cei wrote: Il giorno 04/feb/05, alle 15:30, Vadim Gritsenko ha scritto: What about trunk? Is it already there, or you are waiting on something? Just don't want it to get out of sink, ok, patched it within the trunk, whereas I noticed that trunk and BRANCH_2_1_X are not in sync re static. btw, the trunk builds successfully but doesn't seem to work java.lang.IllegalStateException: ConnectionFactoryAvalonDataSource is already initialized Michi -- Michael Wechner Wyona Inc. - Open Source Content Management - Apache Lenya http://www.wyona.com http://lenya.apache.org [EMAIL PROTECTED][EMAIL PROTECTED]
Re: DOMStreamer patched: default namespace and non-empty prefix of attributes
Vadim Gritsenko wrote: btw, the trunk builds successfully but doesn't seem to work java.lang.IllegalStateException: ConnectionFactoryAvalonDataSource is already initialized I guess it is either my fault or problem with the new core... I can take a look at it but not sooner then mon/tue... no problem have a nice weekend Michi -- Michael Wechner Wyona Inc. - Open Source Content Management - Apache Lenya http://www.wyona.com http://lenya.apache.org [EMAIL PROTECTED][EMAIL PROTECTED]
Re: Lenya link
Antonio Gallardo wrote: Michael Wechner dijo: It seems that Lenya's website is ready at http://lenya.apache.org Hence I think it would make sense to replace the Lenya link on the Cocoon site by Related and create a new page where Lenya, Forrest and other projects based on Cocoon (e.g. Daisy, ...) could be linked from. WDYT? I think the solution is better as there is in the xml.apache.org: Moved projects: http://xml.apache.org/ WDYT? ;-) I think Related Projects is better than Moved Projects because it's timeless. Michi Best Regards, Antonio Gallardo -- Michael Wechner Wyona Inc. - Open Source Content Management - Apache Lenya http://www.wyona.com http://cocoon.apache.org/lenya/ [EMAIL PROTECTED][EMAIL PROTECTED]
Lenya link
It seems that Lenya's website is ready at http://lenya.apache.org Hence I think it would make sense to replace the Lenya link on the Cocoon site by Related and create a new page where Lenya, Forrest and other projects based on Cocoon (e.g. Daisy, ...) could be linked from. WDYT? Michi -- Michael Wechner Wyona Inc. - Open Source Content Management - Apache Lenya http://www.wyona.com http://cocoon.apache.org/lenya/ [EMAIL PROTECTED][EMAIL PROTECTED]
Publications Blog and Default within 1.4-dev are broken
The Blog and Default Publication are broken within 1.4-dev. After a
clean checkout and using build.sh I receive the following errors
Blog Publication
The prefix i18n for element i18n:text is not bound.
Default Publication
Cannot get variable 'document-type' in expression
'cocoon:/lenyabody-view/{page-envelope:publication-id}/{page-envelope:area}/{page-envelope:document-type}{page-envelope:document-url}'
Any clues?
Michi
--
Michael Wechner
Wyona Inc. - Open Source Content Management - Apache Lenya
http://www.wyona.com http://cocoon.apache.org/lenya/
[EMAIL PROTECTED][EMAIL PROTECTED]
Re: A web-based front-end for the JSR 170 reference implementation
Sylvain Wallez wrote: Hi all, David Nueschler, the JSR170 (content repository API) spec lead, has set up a cool demo web site for the reference implementation of the JSR, so that people can quickly get their hands on it and get a feeling of what this long-awaited API can bring to them. You can play with it at http://jsr170tools.day.com/ As David explicitely told me when I asked if I could inform you all about it, this demo is in its early phases and should not be considered - yet - as rock solid. So use with care ;-) cool btw, David submitted a proposal for a JSR-170 presentation at OSCOM 4 http://www.oscom.org/events/oscom4/rfp so I guess one will be able to hear more about it there as well (if the organization committee accepts the proposal ;-) Michi There's also a related mailing list at http://groups.yahoo.com/group/jcr-crx/ David, thanks a lot for this and don't hesitate to jump in to give more info if needed. Enjoy, Sylvain -- Michael Wechner Wyona Inc. - Open Source Content Management - Apache Lenya http://www.wyona.com http://cocoon.apache.org/lenya/ [EMAIL PROTECTED][EMAIL PROTECTED]
Re: [Summary ]Re: [TEST+VOTE] Lenya 1.2 Release
Leo Simons wrote: Michael Wechner wrote: Leo Simons wrote: In this case, Noel has raised some perfectly valid concerns about files living on http://www.apache.org/dist/ without a PMC putting them there (which is a *big thing*, for legal and other reasons). If I were lenya, I wouldn't complain about constraints, but just address those concerns. well, IIRC then concerns have been addressed promptly. No, they have not been addressed promptly. There exists content on http://www.apache.org/dist/cocoon/lenya/ which is not supposed to be there. I renamed them to dev after Steven approached me (btw, I didn't put them there in the first place) I'll quote Noel: Thinking on it, we should probably delete those files, which were never approved by either the Incubator or Cocoon PMCs. Baring commentary to the contrary, I will do so within the next day or so (leaving time for legitimate contrary views). do you like us to delete them for good? C'mon guys, a mistake or two have been made, which is fine! That's why we have an incubation process in the first place :-D. Live and learn. Go fix things. that's my intention duly noted, and lenya-dev added back to CC list. thanks Michi Guys, you may have missed some useful bits of info. Please go read recent [EMAIL PROTECTED] archives to make sure you haven't. - Leo - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Michael Wechner Wyona Inc. - Open Source Content Management - Apache Lenya http://www.wyona.com http://cocoon.apache.org/lenya/ [EMAIL PROTECTED][EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
typo in build-cocoon-targets.xml
there seems to be a typo within build-cocoon-targets.xml of http://wiki.apache.org/cocoon/YourCocoonBasedProjectAnt16 target name=-cocoon:check depends=-cocoon:test unless=cocoon.ok failNo cocoon available. Run 'ant cocoon.get' first./fail /target I think it should say cocoon:get instead cocoon.get Michi -- Michael Wechner Wyona Inc. - Open Source Content Management - Apache Lenya http://www.wyona.com http://cocoon.apache.org/lenya/ [EMAIL PROTECTED][EMAIL PROTECTED]
Re: Response to workflow
Johan Stuyts wrote: Good idea, I have made a start: http://wiki.cocoondev.org/Wiki.jsp?page=WorkflowImplementationComparison. cool Michael, could you add the information about Lenya workflow? yes, I will try to do so I won't be able to respond to messages the next two weeks fortunately. I will be on holiday in (hopefully) sunny Turkey. I'll be back April 5. enjoy your vacation :-) Makes sense? Michi +1 to start with Lenya workflow. Guido (How long until Andreas returns from vacation? :-) Michi -- Michael Wechner Wyona Inc. - Open Source Content Management - Apache Lenya http://www.wyona.com http://cocoon.apache.org/lenya/ [EMAIL PROTECTED][EMAIL PROTECTED]
Re: Response to workflow
Guido Casper wrote: Community-wise the Lenya workflow package is certainly the best bet. We should just try to keep the interfaces neutral so that others might be integrated. sure, it's very important that other people start using it and hence help improving and refactoring +1 to start with Lenya workflow. Guido (How long until Andreas returns from vacation? :-) about two more weeks (beginning of April). Andreas would certainly be of great help, but I think we should try to start anyway Michi Michi -- Michael Wechner Wyona Inc. - Open Source Content Management - Apache Lenya http://www.wyona.com http://cocoon.apache.org/lenya/ [EMAIL PROTECTED][EMAIL PROTECTED]
Re: Response to workflow
Johan Stuyts wrote: I view choosing for Lenya workflow as choosing to build/use a Cocoon-independent solution (with an adapter to make it accessible in Cocoon) instead of building a solution using Cocoon-specific technology. There are a number of existing implementations which can be used as a starting point for a Cocoon-independent solution. I feel other implementations are more mature than Lenya workflow and will be a better choice to use as a starting point. I think OSWorkflow is a good option, but jBpm looks very promising (I suggest to give the demo a try). Both these technologies are license-compatible with Cocoon. yes, from a license point of view the choice seems to come down to jBpm OSWorkflow Lenya Maybe we should try to characterize the differences and similarities within the Wiki in order to get a better picture (at least I need to do this for myself ;-) Makes sense? Michi +1 to start with Lenya workflow. Guido (How long until Andreas returns from vacation? :-) Michi -- Michael Wechner Wyona Inc. - Open Source Content Management - Apache Lenya http://www.wyona.com http://cocoon.apache.org/lenya/ [EMAIL PROTECTED][EMAIL PROTECTED]
Re: Response to workflow
Guido Casper wrote: Michael Wechner wrote: Johan Stuyts wrote: Conclusion -- IMHO there should be more consensus about what is needed and what is feasible in a relatively short time, e.g. half a year to a year. I think building a generalized workflow based on a standard is too ambitious. Leaving out some more complex constructs decreases usability. It might be an option to choose a (proper) subset of a standard with which a large percentage (definitely more than 80%. Having to resort to another solution in one of four situations is not acceptable) of use cases can be implemented. I would suggest to start on an existing code base, e.g. Lenya or whatever, make an appropriate Cocoon block out of it (there had been a list of requirements to meet) and start from there. If that goes along with some documentation :-) and an isolated sample I'm +1 agreed. In case we agree on the Lenya workflow as initial workflow bloc, then we should probably work down the list provided by Carsten: http://article.gmane.org/gmane.comp.cms.lenya.devel/2902 Michi Guido Else I guess discussions just keep going forever ;-) The existing code base might not satisfy everybody, but at least it's something concrete to start with, even if it will be totally modified resp. refactored in the end. Michi -- Michael Wechner Wyona Inc. - Open Source Content Management - Apache Lenya http://www.wyona.com http://cocoon.apache.org/lenya/ [EMAIL PROTECTED][EMAIL PROTECTED]
Re: Response to workflow
Stefano Mazzocchi wrote: The existing code base might not satisfy everybody, but at least it's something concrete to start with, even if it will be totally modified resp. refactored in the end. 100% agreement. Doing design without a codebase takes forever on a open community because it's much easier to disagree with email than with code ;-) it's a do-ocracy after all, then we polish from there. what do others think (beside Guido and Stefano)? I don't know if there are any other existing code-bases beside the ones listed at http://wiki.cocoondev.org/Wiki.jsp?page=Workflow whereas the type of license reduces the choice even more Michi -- Michael Wechner Wyona Inc. - Open Source Content Management - Apache Lenya http://www.wyona.com http://cocoon.apache.org/lenya/ [EMAIL PROTECTED][EMAIL PROTECTED]
Re: Lenya J2EE 1.3
Joe Lozina wrote: Hi Is there a version of lenay that is J2EE 1.3 compatible? no, only 1.4.x Michi Regards Joe -- Michael Wechner Wyona Inc. - Open Source Content Management - Apache Lenya http://www.wyona.com http://cocoon.apache.org/lenya/ [EMAIL PROTECTED][EMAIL PROTECTED]
cocoon-upload.jar
Is there a particular reason that cocoon-upload.jar from http://wiki.cocoondev.org/Wiki.jsp?page=FileUploadsWithFlow is not part of Cocoon-2.1 ? Thanks Michi -- Michael Wechner Wyona Inc. - Open Source Content Management - Apache Lenya http://www.wyona.com http://cocoon.apache.org/lenya/ [EMAIL PROTECTED][EMAIL PROTECTED]
Re: workflow block commited
Carsten Ziegeler wrote: I think these issues have to be address before the next release, together with a minimum docs and a sample. agreed I expect another release of Cocoon in two or three weeks! Without the above changes, this block doesn't really fit into Cocoon. In fact nothing Cocoon specific is used, so have you considered to move the block to a more common place, e.h. jakarta-commons or something like that? why don't we move it into the Lenya module and work there on the list which was suggested by Carsten? Cocoon committers also have access to the Lenya module and it seems to me that Cocoon committers know by now that this block exists ;-) As soon as we have addressed the issues we can try moving it back into the Cocoon module. WDYT? Michi Carsten - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: workflow block commited
Michael Wechner wrote: why don't we move it into the Lenya module and work there on the list which was suggested by Carsten? By me? :) sorry, for my bad english, but I meant the list with the issues to be addressed, or did somebody else suggest this list? Maybe I am confusing things ;-) Big +10 it seems to me that most Cocooners would like to move this block back to Lenya, at least for the moment. So I would suggest that we move it. Michi Carsten
Re: cvs commit: cocoon-2.1/src/blocks/workflow/java/org/apache/lenya/xml DocumentHelper.java
Carsten Ziegeler wrote: As far as I know (from my weak memory :) ) there hasn't been a vote at Cocoon about accepting this block. yes, not that I know So, can you please enlighten us (or only me?) about the use of this block for Cocoon and why you want to move it here? Well, I actually thought that we would maintain the block within Lenya first and then move it to the Cocoon module. But I guess Gregor's intention was meant to be good in order to facilitate the developement also for Cocoon developers only from the very beginning. I'm really worried that everyone starts a new block whenever he thinks it's right to do without asking anyone (This is not targetted at you Gregor.). I did this myself, yes. But I think we should sometime really start to discuss new blocks, otherwise we get burried under too many blocks noone maintains. agreed In fact a block is a new subproject that perhaps should go through incubation etc. Well, Lenya definitely is going to use this block, but as I said it doesn't have to be maintained within the Cocoon module. I would suggest that we discuss it right now and depending on the general interest we either let it stay or move it into the Lenya module. Makes sense? btw, in case people would be agreeing on adding it to Cocoon, then I guess the Java package should be renamed. Michi Carsten -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Sunday, February 29, 2004 6:35 PM Log: new workflow block from lenya. see http://nagoya.apache.org/eyebrowse/BrowseList?listName=lenya-d [EMAIL PROTECTED]by=threadfrom=653774 for a discussion and vote on this. the block is marked unstable. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
resource-exists selector: test path relative to sitemap
I would like to propose to change the default behaviour of the resource-exists selector re testing the path relative to the sitemap from it's being called. Let me give an example: Let's say we have a sitemap and from there another sub-sitemap mounted within some directory, context (e.g. cocoon) | +-- sitemap.xmap | +-- foo | +-- sub-sitemap.xmap | +-- bar | +-- file1.xml | +-- file2.xml Currently to test files from within the *sub-sitemap* requires the following sitemap snippet map:select type=resource-exists map:when test=foo/bar/file1.xml but wouldn't it make more sense to have map:select type=resource-exists map:when test=bar/file1.xml which means the path is relative to the actual sitemap? Or am I overlooking something? WDYT? Michi -- Michael Wechner Wyona Inc. - Open Source Content Management - Apache Lenya http://www.wyona.com http://cocoon.apache.org/lenya/ [EMAIL PROTECTED][EMAIL PROTECTED]
Re: resource-exists selector: test path relative to sitemap
Nicola Ken Barozzi wrote: map:select type=resource-exists map:when test=bar/file1.xml which means the path is relative to the actual sitemap? Or am I overlooking something? Sub-sitemaps can be anywhere you mean referenced by absolute paths? and not necessarily work with a sub-dir scenario in mind. Forrest is a good example of this, as we use several subsitemaps, all in the same dir. i need to check that What IMHO would make more sense, instead, is something like: map:select type=resource-exists base=foo/ map:when test=bar/file1.xml and base as optional attribute? -- Michael Wechner Wyona Inc. - Open Source Content Management - Apache Lenya http://www.wyona.com http://cocoon.apache.org/lenya/ [EMAIL PROTECTED][EMAIL PROTECTED]
Re: StreamGenerator doesn't accept text/html
Joerg Heinicke wrote: On 14.12.2003 18:12, Michael Wechner wrote: Mmmh, but Epoz sends wellformed xhtml. The point is Epoz sends text/html as content-type, which is not handled by StreamGenerator(, yet). I don't want to tidy anything, at the mom. My question is: Why does the StreamGenerator not support text/html?? I guess this was the simplest way to enforce well-formedness. But the test on a specific content type is no that good IMO. Why not simply let the parser complain about well-formedness errors? Good point. Look at the fact that it accepts text/plain :) so why not text/html or what ever? it seems to me that two fixes should be made: Epoz should send text/xhtml Not text/xhtml, but similar: http://www.w3.org/TR/xhtml-media-types/#summary right http://www.xml.com/pub/a/2003/03/19/dive-into-xml.html http://www.web-graphics.com/mtarchive/000861.php but still ... ;-) Michi and the generic StreamGenerator should be able to check well-formedness instead just checking the mime-type, maybe by default, but which could be configured to be turned off because of possible performance issues. Simply trying parsing and rethrowing a parsing error ... what it has to do in any case. Joerg
Re: StreamGenerator doesn't accept text/html
Rolf Kulemann wrote: Hello List, I'm currently integrating the Epoz editor into Lenya. This editor sends text/html as content-type in a PUT request when the document is being saved. I thought it is a good idea to use the StreamGenerator to generate my XML within a xmap. The StreamGenerator complains about a not supported content-type. quote Do you think it makes sense that the StreamGenerator should accept text/html since html is a subset of xml ? /quote I already made a tiny change to StreamGenerator to support text/html and it works fine, but I dunno, if this is a misuse. If so, can anybody give me a hint how to generate XML out of Epoz's PUT request? Daniel's remarks might also be of interest http://article.gmane.org/gmane.comp.cms.lenya.devel/2071 Michi (I use Cocoon 2.1.2) Thanks. -- Michael Wechner Wyona Inc. - Open Source Content Management - Apache Lenya http://www.wyona.com http://cocoon.apache.org/lenya/ [EMAIL PROTECTED][EMAIL PROTECTED]
Re: [RT] Converging the repository concept in cocoon
Stefano Mazzocchi wrote: On 5 Dec 2003, at 02:17, Andreas Hartmann wrote: Stefano Mazzocchi wrote: I looked into the repository block and I find a *lot* of things (locking, permissions, properties) that look very much like a duplication of effort. The Slide project spent years optimizing and polishing issues like transactionality and locking, do you really want to implement a layer to emulate those things in case the given source is not capable of handling it itself? I have a basic question: When you talk about a repository, does this imply that operations on ressources are transactional, or is this an optional feature? That's up to us to define what level of transactionality we want/need/able-to-implement-shortly. For me, now, transactionality is not that important, but it would be a good thing to have (for example, making the saving of one document that contains images an atomic thing) I think for Lenya it is quite important. As soon as we enter a multi-user environment where several documents are being modified within a single transaction, things can become very tricky without the actual support of transactions. I hope I will find more time to really join this thread. On the other hand I think things are heading into the right direction. I am currently preparing some thoughts about introspection and workflow instances, but I need some more time to write it down. But it should be ready before X'Mas. Anyway, I am going to fix the rest of these michis now within Lenya. Michi -- Stefano. -- Michael Wechner Wyona Inc. - Open Source Content Management - Apache Lenya http://www.wyona.com http://cocoon.apache.org/lenya/ [EMAIL PROTECTED][EMAIL PROTECTED]
Re: About cocoon.apache-korea.org
Min Kye Seon wrote: I'm keyseon, Min and a Korean. I am a korean undergraduate and I am running , managing, and translating cocoon.apache-korea.org with korean. The cocoon.apache-korea.org is translation site with korean. Since I have sutdied Cocoon, I thought it is good Cocoon is activated and I hope to help some korean developers or user use Cocoon easily. So I established the cocoon.apache-korea.org in october, 2003 and Translating Cocoon documentation with korean began at november. The cocoon.apache-korea.org is began from apache-kore.org. apache-kore.org is the translating project of a number of apache projects. Now, http://jakarta.apache-korea.org, http://ant.apache-korea.org, http://cocoon.apache-korea.org, http://xml.apache-korea.org is active. would it make sense to host these pages under the actual apache domain, e.g. http://cocoon.apache.org/index_ko.html ? Michi I am translating cocoon.apache.org. Moreover, I am developing some Cocoon tools for cocooners. The C-tracer following the idea Mr. Arje Cahn is distributed in http://cocoon.apache-korea.org/application/c-tracer.html Also, I am developing Cocoon Sitemap Editor as struts-config.xml editor of Struts and making progress 80%. Thanks. ps. I'd like to express my heartfelt thanks to Arje Cahn who provides the idea of a C-Tracer. _ Àü¼¼°èÀÎÀÌ ÇÔ²²ÇÏ´Â À¥ ¸ÞÀÏ ¼ºñ½ºÀÎ MSN HotmailÀ» ¸¸³ª º¸¼¼¿ä. http://loginnet.passport.com/login.srf?id=2svc=mailcbid=24325msppjph=1lc=1042 -- Michael Wechner Wyona Inc. - Open Source Content Management - Apache Lenya http://www.wyona.com http://cocoon.apache.org/lenya/ [EMAIL PROTECTED][EMAIL PROTECTED]
Re: Doco needs landing (Was: cvs commit: cocoon-2.1 features.xml)
Nicola Ken Barozzi wrote: Stefano Mazzocchi wrote: On 28 Nov 2003, at 03:46, David Crossley wrote: What I don't really understand is that he is not using a public Apache repository, like the Cocoon scratchpad, to do it. it's not CVS or SVN yet, but AFAIK Stefano updated recently http://wiki.cocoondev.org/Wiki.jsp?page=Doco HTH Michi At least we could have watched it grow, and he would have not been slowed with community as he now likes to say ;-) In any case, he's free to do so if he wishes, and we will see what to do when this thing will land here. -- Michael Wechner Wyona Inc. - Open Source Content Management - Apache Lenya http://www.wyona.com http://cocoon.apache.org/lenya/ [EMAIL PROTECTED][EMAIL PROTECTED]
Re: RELAX NG Validation with Jing
David Crossley wrote: Michael Wechner wrote: jing-20030619.jar Yes, please. I would but i am going soon to the Aussie bush for the w/end. ok, I have updated it within 2.1 and 2.2 Michi --David -- Michael Wechner Wyona Inc. - Open Source Content Management - Apache Lenya http://www.wyona.com http://cocoon.apache.org/lenya/ [EMAIL PROTECTED][EMAIL PROTECTED]
RELAX NG Validation with Jing
Is there a library within Cocoon which is capable of doing RELAX NG validation, or do I need to include jing.jar from James Clark? Thanks Michi -- Michael Wechner Wyona Inc. - Open Source Content Management - Apache Lenya http://www.wyona.com http://cocoon.apache.org/lenya/ [EMAIL PROTECTED][EMAIL PROTECTED]
Re: Cron block: Interest in adding job persistence?
Andreas Hartmann wrote: Hi Cocoon developers, the Lenya community is considering to use the Cron block as the basis to improve the Lenya scheduler. At the moment, there is no job persistence functionality (ie, when Cocoon is restarted, the scheduled jobs get lost). Is anyone besides me interested in implementing this feature or supporting me? yes,I am, but not this week ;-) Michi Thanks! -- Andreas -- Michael Wechner Wyona Inc. - Open Source Content Management - Apache Lenya http://www.wyona.com http://cocoon.apache.org/lenya/ [EMAIL PROTECTED][EMAIL PROTECTED]
Re: Cannot easily set http status
Unico Hommes wrote:
Working on davmap I noticed that the way I was setting the status code
in the Serializer wasn't working. This is what I do:
map:match pattern=status/*
map:generate src=status.xml /
map:serialize type=xml status-code={1} /
/map:match
But it seems that the status-code attribute is not being resolved. I
propose we change this.
Within Lenya I use the status-code attribute as follows
(src/webapp/lenya/pubs/blog/webdav.xmap)
map:serialize type=xml status-code=204/
which works, but maybe the problem is the {1}
HTH
Michi
Then I thought I may be able to set it on fom response object in the
flow. But this too seems not to be possible. However, changing this
seems to be a little more straightforward since setStatus is not a
method on the environment Response interface but on the HttpResponse
implementation instead. I propose we add this method to the fom and make
it a nop in case we are dealing with a different Response implementation
than HttpResponse.
Thoughts?
-- Unico
--
Michael Wechner
Wyona Inc. - Open Source Content Management - Apache Lenya
http://www.wyona.com http://cocoon.apache.org/lenya/
[EMAIL PROTECTED][EMAIL PROTECTED]
Re: [proposal] Doco
In order to get myself into the Doco discussion I have created a Wiki page at (I was busy moderating emails for lenya-dev ...) http://wiki.cocoondev.org/Wiki.jsp?page=Doco where I have compiled Stefano's original proposal and added issues from the various email threads. Would be nice if people could compile ideas into this page in order to find consensus. Hope this helps to get an overview and development started. Thanks Michi -- Michael Wechner Wyona Inc. - Open Source Content Management - Apache Lenya http://www.wyona.com http://cocoon.apache.org/lenya/ [EMAIL PROTECTED][EMAIL PROTECTED]
Re: [RT] FirstFriday - monthly virtual Hackathon
Carsten Ziegeler wrote: snip / Does anyone know of an IRC client that's not blocked by a firewall? Or is it possible to use irc via my apache account? you could tunnel through ssh (I guess ssh gets through your firwall) HTH Michael Carsten -- Michael Wechner Wyona Ltd. - Open Source Content Management - Apache Lenya http://www.wyona.com http://cocoon.apache.org/lenya/ [EMAIL PROTECTED][EMAIL PROTECTED]
Re: [GT2003] Thank you
Bertrand Delacretaz wrote: Unfortunately the GT is over now :( Unfortunately...but thanks to everybody who helped make this a great event! yeah, it was a very nice experience. Thanks very much for the great hospitality Michael -- Michael Wechner Wyona Ltd. - Open Source Content Management - Apache Lenya http://www.wyona.com http://cocoon.apache.org/lenya/ [EMAIL PROTECTED][EMAIL PROTECTED]
Re: Cocoon GetTogether 2003 website opened
Is anyone interested to share an appartment or hotel room? Maybe we could rent an appartment (with kitchen) for two or three nights, where a couple of people could stay. Thanks Michael Steven Noels wrote: Dear all, we've been frantically preparing the information and registration website for the upcoming Cocoon GetTogether 2003 on October 7th in Ghent, Belgium, and we are very pleased to say that we are open for business now. Please check out http://www.orixo.com/events/gt2003/ On this site, you'll find the program, speakers and all necessary travel and lodging info, which will be updated as the event date approaches. Last year, we had more than 100 people registering for this unique opportunity to meet and intermingle with fellow Cocoonies, and we hope to double that number this year. Mind you that this is *not* a developers-only event, and that many sessions are really mini-tutorials which will give you a jumpstart while exploring the Cocoon framework. On the Wiki, you'll also find some relevant pages: - http://wiki.cocoondev.org/Wiki.jsp?page=GetTogetherAttending in case you want to know who's coming as well - http://wiki.cocoondev.org/Wiki.jsp?page=GT2003Hackathon for developers that want to participate with the Hackathon on the 6th We have been careful in making this event as low-cost as possible, while moving to a larger and better accessible venue, and we are fully committed to provide you with many bangs for your bucks. On behalf of Orixo, I'd like to cordially invite you to participate with this year's edition, and I really look forward to see you in Ghent on October 7th. Cheers, /Steven - GT 2003 co-organizing puppet -- Michael Wechner Wyona Ltd. - Open Source Content Management - Apache Lenya http://www.wyona.com http://cocoon.apache.org/lenya/ [EMAIL PROTECTED][EMAIL PROTECTED]
OSCOM @ Seybold SF
Seybold organizers just told me that they want to cancel the OSCOM hackathon/sprint @ Seybold if there aren't enough participants which have signed up until tomorrow Friday (western times). The reason seems to be that room and internet connection are too expensive for hosting just a few people. So far 3 people have signed up, but they are expecting around 20 people. I think it's a great opportunity to meet in person and do some coding on Atom and WebDAV related stuff So, please subscribe NOW if you want to participate for real. Participation is for FREE and you can sign up here: http://www.seybold365.com/common/index.php?s=hackathon more info can be found here http://www.oscom.org/Conferences/Sprints/San%20Francisco%20September%202003.html Thanks Michael
Re: 'Production' build for Cocoon?
Roger I Martin PhD wrote: Hi Antonio, At the moment I'm checking out Lenya by CVS so I can understand it's impact on the use of Cocoon and webapp design. Then I'll get back to you on what Cocoon's INSTALL.txt needs added. with regard to your recent emails better don't look at the Lenya INSTALL.txt ;-) it's basically a white sheet ... ... but any help on improving them is very welcome (especially generating them out of some XML) Michael Right now INSTALL.txt needs some things cut out of it: snip Let me guess: you don't like to read verbose docs, right? Great, this file is for you. /snip snip your mileage may vary depending on your shell, but you know how to setup environments, right? /snip snip That's it! Now, you have two choices: a) close this file and try to hack something out by yourself b) keep reading Go ahead and choose option a), but don't complain if you can't figure out how to use the cocoon build system for your needs. Still here? good. You won't regret it. /snip snip All right, that's it for now. Happy hacking with Cocoon. /snip Would you rather a CVS patch that removes these? Typos and English troubles are not a problem. A good editor can solve those quickly. It's coyness, obnoxious playing with people new to Cocoon in the first documents they read that lowers first impressions. The overview on http://cocoon.apache.org/ gives a good first impression. Where is the person who wrote it? br, Roger BTW, it is fine for email between developers to have typos, English problems and self expression :-) One thing I do note is many take snips out of other people's email to express themselves about said snippet and lose the context like a bunch of quibbling Biblical scholars:-) Perhaps someday instead of using email lists we can use a Content Management System where we can link to reference a particular piece of writing we're wanting to discuss. - Original Message - From: Antonio Gallardo [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Saturday, August 23, 2003 12:32 PM Subject: Re: 'Production' build for Cocoon? Hi Roger: Can you write the intro as you suggested? Please don't take this question in the bad sense. I think all of us can help to make a better Cocoon. We are a community with a common interest called Cocoon framework. I meet Cocoon a year ago (I still consider my self a newbie in Cocoon). From my point of view, there has been an amazing improvement in the Cocoon documentation: Currently, we have 3 printed books released in less than a year, a nice (still growing) wiki site with many info and helps docs to read and at the end but not the last important a better official cocoon documentation. A year ago there was nothing like that, just some docs in the official cocoon site and a handfull articles somewhere in the vast Internet. It is really amazing how long the project growed in the last year. I saw that. Well, as usual, nothing is perfect and because of that we are still working to improve Cocoon framework every day. I encourage you to join us an helps in this wonderful project. From my own experience in the project I learned that: Critics are always welcomed, because helps to improve the framework. But solutions are better welcomed. By solutions I mean a patch that address a particular problem someone see. Remember that this is a multi cultural community that try to use a unique language (english). The skill of written english that members use is very diferent. From totally beginners to people with great skill to write english. This is a fact. Take my own example: To write this mail I need more than 30 mins. I need to review what I wrote to make sure if my message carries what I mean and I know still there are many errors and sometimes after my own review my message is not carried in the lines. But is is not because I am a stupid, this is because simply my mother language is not english. For there reasons, I think we need people with better skill of written english to help us to write and improve the docs. And if this is your case I encourage you to helps us to write your requested INSTALL.txt :) As usual, when there is nothing, the first draft or the first block of the construction is hard to put, after that when we have something then improve it is easier! Please try to write the first draft. :) At the end I want to write a phrase from a song from Pink Floyd: Together we stand, divided we fall :) Best Regards, Antonio Gallardo P.S: I dont want to fight with nobody here and I am not trying to attack nobody. Please take my message in the most good sense. Really we need to work together :) -- Michael Wechner Wyona Ltd. - Open Source Content Management - Apache Lenya http://www.wyona.com http://cocoon.apache.org/lenya/ [EMAIL PROTECTED][EMAIL PROTECTED]
Re: [RT] The perfect repository might be just under your eyes
Hunsberger, Peter wrote: Stefano Mazzocchi [EMAIL PROTECTED] writes: This morning I found this http://www.namesys.com/v4/pseudo.html and I was *litterarely* blown away. Been monitoring Slashdot perhaps? Apparently (from the XML-dev list) it's reference was to http://cda.mrs.umn.edu/~mine0057/fs.pdf but that in turn points to the above... btw, there is another recent thread on the perfect repository ;-) (I guess there are many more if one starts looking ...) http://article.gmane.org/gmane.comp.cms.lenya.devel/757 thanks Michael
