DO NOT REPLY [Bug 31546] - [PATCH] Serializers: bug in pop(...) of namespaces stack
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=31546. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=31546 [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|CLOSED -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
Re: CForms: a Tree widget
Upayavira wrote: Just tried on Firefox/Linux, and got 'could not find element with id files'. Is this something obvious? Got it: I forgot to commit some changes made to the BrowserUpdateTransformer. That should work now! Sylvain -- Sylvain WallezAnyware Technologies http://apache.org/~sylvainhttp://anyware-tech.com Apache Software Foundation Member Research Technology Director
Re: [PATCH][Gump] your definitions break Gump builds
Stefano Mazzocchi wrote: Stefan Bodewig wrote: On Thu, 16 Jun 2005, Stefano Mazzocchi [EMAIL PROTECTED] wrote: it's not a matter of being annoyed enough (we are already!), it's the fact that cocoon needs that file at build time. Hmm, so why don't you realize that you have a typo in it for many days? Like when you rename a jar but forget to update the descriptor? because cocoon doesn't use *all* of that data, only parts. Truth be told, cocoon could have two files, one for gump and one for its own build system, but they would contain the same information. Now, I would be totally in favor of granting the gump committers commit access to the cocoon project. Should be quite trivial to add a rule to asf-authorization that grants rw to @gump for just that file, at least I think it allows file-granularity. Even better. Can we do it or is it something that infra@ has to do? PMC chairs can do it. -David
Re: [PATCH][Gump] your definitions break Gump builds
On 16-06-2005 17:00, Stefan Bodewig [EMAIL PROTECTED] wrote: On Thu, 16 Jun 2005, Stefano Mazzocchi [EMAIL PROTECTED] wrote: Now, I would be totally in favor of granting the gump committers commit access to the cocoon project. Should be quite trivial to add a rule to asf-authorization that grants rw to @gump for just that file, at least I think it allows file-granularity. Yes please. We'll add an svn:externals to gump svn if possible and all this sending patches around can go away (ooh another reason to move everything to svn!) :-) - Leo
Re: [PATCH][Gump] your definitions break Gump builds
Stefano Mazzocchi wrote: Now, I would be totally in favor of granting the gump committers commit access to the cocoon project. Should be quite trivial to add a rule to asf-authorization that grants rw to @gump for just that file, at least I think it allows file-granularity. Even better. Can we do it or is it something that infra@ has to do? Does the svn authorization file accept wildcards? That would allow for [**/gump.xml] @gump=rw Otherwise, each PMC is responsible for managing its own authorizations and chairs have write access to asf-authorization. Sylvain -- Sylvain WallezAnyware Technologies http://apache.org/~sylvainhttp://anyware-tech.com Apache Software Foundation Member Research Technology Director
Re: [PATCH][Gump] your definitions break Gump builds
Sylvain Wallez wrote: Stefano Mazzocchi wrote: Now, I would be totally in favor of granting the gump committers commit access to the cocoon project. Should be quite trivial to add a rule to asf-authorization that grants rw to @gump for just that file, at least I think it allows file-granularity. Even better. Can we do it or is it something that infra@ has to do? Does the svn authorization file accept wildcards? That would allow for [**/gump.xml] @gump=rw Otherwise, each PMC is responsible for managing its own authorizations and chairs have write access to asf-authorization. From my local tests, no, wildcards don't work. So each PMC would have to add this line themselves. Upayavira
Re: [PATCH][Gump] your definitions break Gump builds
Stefano Mazzocchi wrote: Stefan Bodewig wrote: On Thu, 16 Jun 2005, Stefano Mazzocchi [EMAIL PROTECTED] wrote: it's not a matter of being annoyed enough (we are already!), it's the fact that cocoon needs that file at build time. Hmm, so why don't you realize that you have a typo in it for many days? Like when you rename a jar but forget to update the descriptor? because cocoon doesn't use *all* of that data, only parts. Truth be told, cocoon could have two files, one for gump and one for its own build system, but they would contain the same information. Now, I would be totally in favor of granting the gump committers commit access to the cocoon project. Should be quite trivial to add a rule to asf-authorization that grants rw to @gump for just that file, at least I think it allows file-granularity. Even better. Can we do it or is it something that infra@ has to do? I've just tried it on a local installation of SVN, and it seems to work just fine. I believe we can just do it ourselves, although it would be polite to mention it on infra as it isn't something I've seen done before, so does establish something of a new policy. Here's the patch that would be required. It's pretty simple: Index: asf-authorization === --- asf-authorization (revision 191108) +++ asf-authorization (working copy) @@ -339,6 +339,9 @@ @cocoon = rw @lenya = rw +[/cocoon/trunk/gump.xml] [EMAIL PROTECTED] = rw + [/forrest] @forrest = rw @cocoon = rw So, we all want this? Regards, Upayavira
RE: [Cforms] Java Selection List
Hi Bruno, Your last suggestion resembles how I basically have overwritten the setSelectionListBox(SelectionList) method in the Field.java source. However, I have to admit that for my problem, your first solution would have been a lot easier! Thanx, Ron -Original Message- From: Bruno Dumon [mailto:[EMAIL PROTECTED] Sent: Thursday, June 16, 2005 8:33 PM To: dev@cocoon.apache.org Subject: Re: [Cforms] Java Selection List On Thu, 2005-06-16 at 11:05 -0400, Vadim Gritsenko wrote: Bruno Dumon wrote: On Thu, 2005-06-16 at 10:51 +0200, Ron van de Ven wrote: I have to set a selection list on a field, based on success or failure of a validation. When I use the following fragment: TntCformsJavaSelectionList mySelectionList = new TntCformsJavaSelectionList(true); mySelectionList.setDatatype(new StringType()); myField.setSelectionList(mySelectionList); I get an error: Tried to assign a SelectionList that is not associated with this widget's datatype. then why not do: mySelectionList.setDatatype(myField.getDatatype()); ? I think I had similar situation, with this answer to the question above: you may want to share potentially large selection list(s) between multiple widgets, here widgets might be on the same form, or even on multiple forms for multiple users. It could be quite substantial memory savings... In this scenario, you need either multiple widgets have same instance of datatype on multiple widgets (is it even possible?), or use equals() instead of '==' as was suggested. I see. But is it feasible to implement equals? Testing the equality of a datatype includes testing the equality of its contained convertor, which could be configurable in all sorts of ways. Another possibility would be to change the contract of the SelectionList, letting the field pass its datatype (or even just its convertor) to the SelectionList.generateSaxFragment method. To check the type-compatibility, a SelectionList.getTypeClass() method could be added (cfr. Datatype.getTypeClass()). -- Bruno Dumon http://outerthought.org/ Outerthought - Open Source, Java XML Competence Support Center [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: [PATCH][Gump] your definitions break Gump builds
On 17-06-2005 05:24, Stefano Mazzocchi [EMAIL PROTECTED] wrote: Should be quite trivial to add a rule to asf-authorization that grants rw to @gump for just that file, at least I think it allows file-granularity. Even better. Can we do it or is it something that infra@ has to do? All pmc chairs have the ability to edit the svn-authorization file in infra SVN. Other people do too (e.g. The infrastructre team). But really the request should be from the cocoon PMC to the infra@ mailing list. I'll probably end up making the changes :) LSD
Re: [PATCH][Gump] your definitions break Gump builds
On Thu, 16 Jun 2005, Stefano Mazzocchi [EMAIL PROTECTED] wrote: Stefan Bodewig wrote: On Thu, 16 Jun 2005, Stefano Mazzocchi [EMAIL PROTECTED] wrote: it's not a matter of being annoyed enough (we are already!), it's the fact that cocoon needs that file at build time. Hmm, so why don't you realize that you have a typo in it for many days? Like when you rename a jar but forget to update the descriptor? because cocoon doesn't use *all* of that data, only parts. Unfortunately Gump gets into trouble because of the parts Cocoon doesn't use. If you don't use any of the projects you define for jars in your repo, maybe you better shouldn't define those projects at all? Instead nag the Gump crew to turn them into installed packages. Now, I would be totally in favor of granting the gump committers commit access to the cocoon project. Should be quite trivial to add a rule to asf-authorization that grants rw to @gump for just that file, at least I think it allows file-granularity. Even better. Can we do it or is it something that infra@ has to do? Sylvain can, or I could, but I'd certainly prefer if the Coccon PMC made the change. Stefan
[vote] gump-related stuff
We should try to make it easier for gump to work with us. Our build system is a little hacky in that regard since it uses partial gump information to build cocoon. Gump strongly suggests people to move their gump descriptors over to the gump repository, so that all apache committers have access to it, not just cocoon committers. This increases the ability for others to fix the problems that we might introduce. At the same time, this is not possible, since our build depends on that *and* we can't svn:externalize it because the gump metadata is not (yet!) in SVN (we could get it from viewcvs, though, but it sounds hacky) So, the easiest thing is to allow gump committers to modify our 'gump.xml' files. So, issue #1: would you like to allow this? - o - There is another issue: cocoon has unique packages that we only depend on and we place them in our gump.xml file, problem is that later on other projects might start using those and collisions might happen. Gump is not really happy when naming collisions happen (its datamodel is not namespaced, yet) so one way to do it better is to ask the gump folks to package the things we depend on directly. Means that its a little slower turnover. So, issue #2, would you like to ask the gump people to move our library dependencies currently in gump.xml over in the gump metadata repository instead? -- Stefano.
Re: [PATCH][Gump] your definitions break Gump builds
Stefan Bodewig wrote: On Thu, 16 Jun 2005, Stefano Mazzocchi [EMAIL PROTECTED] wrote: Stefan Bodewig wrote: On Thu, 16 Jun 2005, Stefano Mazzocchi [EMAIL PROTECTED] wrote: it's not a matter of being annoyed enough (we are already!), it's the fact that cocoon needs that file at build time. Hmm, so why don't you realize that you have a typo in it for many days? Like when you rename a jar but forget to update the descriptor? because cocoon doesn't use *all* of that data, only parts. Unfortunately Gump gets into trouble because of the parts Cocoon doesn't use. I know. If you don't use any of the projects you define for jars in your repo, maybe you better shouldn't define those projects at all? Instead nag the Gump crew to turn them into installed packages. I personally wouldn't be against such a thing. Now, I would be totally in favor of granting the gump committers commit access to the cocoon project. Should be quite trivial to add a rule to asf-authorization that grants rw to @gump for just that file, at least I think it allows file-granularity. Even better. Can we do it or is it something that infra@ has to do? Sylvain can, or I could, but I'd certainly prefer if the Coccon PMC made the change. ok, I'll start a vote. -- Stefano.
Re: [docs] old docs import done
On Fri, 2005-06-17 at 12:40 +0200, Bruno Dumon wrote: Hi all, The import is done, see here: http://cocoon.zones.apache.org/daisy/legacydocs All the imported docs belong to a collection called legacydocs. If a document belongs to this collection, a warning is put on top. Later this afternoon, I will start moving some docs to the new documentation (I'll probably start with the forms docs). I suggest that we create a collection/site documentation for this purpose. Done: http://cocoon.zones.apache.org/daisy/documentation Now we can start working on content ;-) -- Bruno Dumon http://outerthought.org/ Outerthought - Open Source, Java XML Competence Support Center [EMAIL PROTECTED] [EMAIL PROTECTED]
FW: svn commit: r191131 - /cocoon/branches/BRANCH_2_1_X/src/blocks/mail/java/org/apache/cocoon/mail/transformation/SendMailTransformer.java
Twice static final int MODE_xxx = 8 looks like copy-waste error? Cheers, Alfred. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Freitag, 17. Juni 2005 13:46 To: cvs@cocoon.apache.org Subject: svn commit: r191131 - /cocoon/branches/BRANCH_2_1_X/src/blocks/mail/java/org/apache/cocoon/mai l/transformation/SendMailTransformer.java Author: unico Date: Fri Jun 17 04:46:08 2005 New Revision: 191131 URL: http://svn.apache.org/viewcvs?rev=191131view=rev Log: Make smtp port configurable Modified: cocoon/branches/BRANCH_2_1_X/src/blocks/mail/java/org/apache/cocoon/mail/transformation/SendMailTransformer.java Modified: cocoon/branches/BRANCH_2_1_X/src/blocks/mail/java/org/apache/cocoon/mail/transformation/SendMailTransformer.java URL: http://svn.apache.org/viewcvs/cocoon/branches/BRANCH_2_1_X/src/blocks/mail/java/org/apache/cocoon/mail/transformation/SendMailTransformer.java?rev=191131r1=191130r2=191131view=diff == --- cocoon/branches/BRANCH_2_1_X/src/blocks/mail/java/org/apache/cocoon/mail/transformation/SendMailTransformer.java (original) +++ cocoon/branches/BRANCH_2_1_X/src/blocks/mail/java/org/apache/cocoon/mail/transformation/SendMailTransformer.java Fri Jun 17 04:46:08 2005 @@ -188,6 +188,7 @@ public static final String NAMESPACE = http://apache.org/cocoon/transformation/sendmail;; public static final String ELEMENT_SENDMAIL = sendmail; public static final String ELEMENT_SMTPHOST = smtphost; +public static final String ELEMENT_SMTPPORT = smtpport; public static final String ELEMENT_MAILFROM = from; public static final String ELEMENT_MAILTO = to; public static final String ELEMENT_REPLYTO= reply-to; @@ -215,11 +216,13 @@ protected static final int MODE_ATTACHMENT = 6; protected static final int MODE_ATTACHMENT_CONTENT = 7; protected static final int MODE_REPLY_TO = 8; +protected static final int MODE_SMTPPORT = 8; ^ This message is for the named person's use only. It may contain confidential, proprietary or legally privileged information. No confidentiality or privilege is waived or lost by any mistransmission. If you receive this message in error, please notify the sender urgently and then immediately delete the message and any copies of it from your system. Please also immediately destroy any hardcopies of the message. You must not, directly or indirectly, use, disclose, distribute, print, or copy any part of this message if you are not the intended recipient. The senders company reserves the right to monitor all e-mail communications through their networks. Any views expressed in this message are those of the individual sender, except where the message states otherwise and the sender is authorised to state them to be the views of the senders company.
Re: [vote] gump-related stuff
Stefano Mazzocchi wrote: We should try to make it easier for gump to work with us. Our build system is a little hacky in that regard since it uses partial gump information to build cocoon. Gump strongly suggests people to move their gump descriptors over to the gump repository, so that all apache committers have access to it, not just cocoon committers. This increases the ability for others to fix the problems that we might introduce. At the same time, this is not possible, since our build depends on that *and* we can't svn:externalize it because the gump metadata is not (yet!) in SVN (we could get it from viewcvs, though, but it sounds hacky) So, the easiest thing is to allow gump committers to modify our 'gump.xml' files. So, issue #1: would you like to allow this? +1. Let's knowledged gumpers fix the descriptor when then find errors rather than having to send patches. - o - There is another issue: cocoon has unique packages that we only depend on and we place them in our gump.xml file, problem is that later on other projects might start using those and collisions might happen. Gump is not really happy when naming collisions happen (its datamodel is not namespaced, yet) so one way to do it better is to ask the gump folks to package the things we depend on directly. Means that its a little slower turnover. What does this mean concretely? That the libs we depend on will be managed at Gump? So, issue #2, would you like to ask the gump people to move our library dependencies currently in gump.xml over in the gump metadata repository instead? Don't know yet... Sylvain -- Sylvain WallezAnyware Technologies http://apache.org/~sylvainhttp://anyware-tech.com Apache Software Foundation Member Research Technology Director
Re: [docs] old docs import done
Bruno Dumon wrote: On Fri, 2005-06-17 at 12:40 +0200, Bruno Dumon wrote: Hi all, The import is done, see here: http://cocoon.zones.apache.org/daisy/legacydocs All the imported docs belong to a collection called legacydocs. If a document belongs to this collection, a warning is put on top. Later this afternoon, I will start moving some docs to the new documentation (I'll probably start with the forms docs). I suggest that we create a collection/site documentation for this purpose. Done: http://cocoon.zones.apache.org/daisy/documentation Now we can start working on content ;-) Great! Thanks Bruno! Sylvain -- Sylvain WallezAnyware Technologies http://apache.org/~sylvainhttp://anyware-tech.com Apache Software Foundation Member Research Technology Director
Re: FW: svn commit: r191131 - /cocoon/branches/BRANCH_2_1_X/src/blocks/mail/java/org/apache/cocoon/mail/transformation/SendMailTransformer.java
It does. Thanks, I'll fix it. -- Unico Nathaniel Alfred wrote: Twice static final int MODE_xxx = 8 looks like copy-waste error? Cheers, Alfred. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Freitag, 17. Juni 2005 13:46 To: cvs@cocoon.apache.org Subject: svn commit: r191131 - /cocoon/branches/BRANCH_2_1_X/src/blocks/mail/java/org/apache/cocoon/mai l/transformation/SendMailTransformer.java Author: unico Date: Fri Jun 17 04:46:08 2005 New Revision: 191131 URL: http://svn.apache.org/viewcvs?rev=191131view=rev Log: Make smtp port configurable Modified: cocoon/branches/BRANCH_2_1_X/src/blocks/mail/java/org/apache/cocoon/mail/transformation/SendMailTransformer.java Modified: cocoon/branches/BRANCH_2_1_X/src/blocks/mail/java/org/apache/cocoon/mail/transformation/SendMailTransformer.java URL: http://svn.apache.org/viewcvs/cocoon/branches/BRANCH_2_1_X/src/blocks/mail/java/org/apache/cocoon/mail/transformation/SendMailTransformer.java?rev=191131r1=191130r2=191131view=diff == --- cocoon/branches/BRANCH_2_1_X/src/blocks/mail/java/org/apache/cocoon/mail/transformation/SendMailTransformer.java (original) +++ cocoon/branches/BRANCH_2_1_X/src/blocks/mail/java/org/apache/cocoon/mail/transformation/SendMailTransformer.java Fri Jun 17 04:46:08 2005 @@ -188,6 +188,7 @@ public static final String NAMESPACE = http://apache.org/cocoon/transformation/sendmail;; public static final String ELEMENT_SENDMAIL = sendmail; public static final String ELEMENT_SMTPHOST = smtphost; +public static final String ELEMENT_SMTPPORT = smtpport; public static final String ELEMENT_MAILFROM = from; public static final String ELEMENT_MAILTO = to; public static final String ELEMENT_REPLYTO= reply-to; @@ -215,11 +216,13 @@ protected static final int MODE_ATTACHMENT = 6; protected static final int MODE_ATTACHMENT_CONTENT = 7; protected static final int MODE_REPLY_TO = 8; +protected static final int MODE_SMTPPORT = 8; ^ This message is for the named person's use only. It may contain confidential, proprietary or legally privileged information. No confidentiality or privilege is waived or lost by any mistransmission. If you receive this message in error, please notify the sender urgently and then immediately delete the message and any copies of it from your system. Please also immediately destroy any hardcopies of the message. You must not, directly or indirectly, use, disclose, distribute, print, or copy any part of this message if you are not the intended recipient. The senders company reserves the right to monitor all e-mail communications through their networks. Any views expressed in this message are those of the individual sender, except where the message states otherwise and the sender is authorised to state them to be the views of the senders company.
[GT2005] News, vote and more news
Howdy fellow Cocoonies, lots of GetTogether news, and a call for advise. The Cocoon GetTogether will be travelling this year, in a bold and unprecedented move to check the quality of ribs across the globe. Our first stop will be in xxx Amsterdam xxx, during the first week of October. OK, that's hardly a adventurous distance from Ghent, but it'll do for our first edition abroad, won't it? Adding to this bold move, we're also adding an extra day to the Hackathon, providing us with two long days to hack on our beloved project, and be tempted to go and visit Amsterdam. Or not. Whatever. :-) Arj Cahn (from Hippo) and I went location scouting a few weeks ago, and we've found two really cool places to put our Cocoon tents up. Pending logistical arrangements, we'll be geeking out in either (or both, rather) the Felix Meritis (http://www.felix.meritis.nl/) and the Nemo (http://www.e-nemo.nl/). The Felix Meritis is an elegant historical building along the Amsterdam Grachten - the canals - and the Nemo is a Science museum (!), located in the water. Both in easy reach of public transportation, and close to the heart of Amsterdam - I'm sure Amsterdam will be a worthy competitor of Ghent location-wise. ;) I've put up some pictures of the buildings + rooms in the Flickr group pool: http://www.flickr.com/groups/cocoongt2005/pool/ Arj has volunteered to be our local host this year - of course with plenty of assistance from me, and I hope also from some other volunteers as well. I'm thrilled to see the GetTogether going places! Now, about the vote: we have rooms reserved for the entire first week of October, but need to decide on the first or last part of the week. So please indicate your preference (and reply to the dev list for easier counting): Yes, I'm thinking of attending the Cocoon GetTogether 2005 in Amsterdam, preferably on [ ] 3/4/5 October (Mon-Wed) [ ] 5/6/7 October (Wed-Fri) That's all for now, expect more to hear from Arj or me in the future! Cheers, /Steven -- Steven Noelshttp://outerthought.org/ Outerthought Open Source Java XML stevenn at outerthought.orgstevenn at apache.org
Re: svn commit: r191129 - /cocoon/trunk/blocks.properties
[EMAIL PROTECTED] wrote:
Author: unico
Date: Fri Jun 17 04:24:24 2005
New Revision: 191129
URL: http://svn.apache.org/viewcvs?rev=191129view=rev
Log:
jms dependencies changed
Modified:
cocoon/trunk/blocks.properties
Maybe I've overlooked your commit of gump.xml, if not, blocks.properties is
generated using some Ant task out of gump.xml.
--
Reinhard Ptz Independent Consultant, Trainer (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
Re: [docs] old docs import done
Hi Bruno, Great! I've done a fair amount of work on the Cocoon In Action section. Should we look at merging the two, or do they have sufficiently distinct purposes to keep them separated? Helma, what do you think? Mark On 17 Jun 2005, at 14:11, Bruno Dumon wrote: On Fri, 2005-06-17 at 12:40 +0200, Bruno Dumon wrote: Hi all, The import is done, see here: http://cocoon.zones.apache.org/daisy/legacydocs All the imported docs belong to a collection called legacydocs. If a document belongs to this collection, a warning is put on top. Later this afternoon, I will start moving some docs to the new documentation (I'll probably start with the forms docs). I suggest that we create a collection/site documentation for this purpose. Done: http://cocoon.zones.apache.org/daisy/documentation Now we can start working on content ;-) -- Bruno Dumon http://outerthought.org/ Outerthought - Open Source, Java XML Competence Support Center [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: [docs] old docs import done
Mark Leicester wrote: Hi Bruno, Great! I've done a fair amount of work on the Cocoon In Action section. Should we look at merging the two, or do they have sufficiently distinct purposes to keep them separated? Helma, what do you think? Personally, what I want to see is two sections: one for reference docs and one for tutorials, etc. But within the same documentation. Regards, Upayavira On 17 Jun 2005, at 14:11, Bruno Dumon wrote: On Fri, 2005-06-17 at 12:40 +0200, Bruno Dumon wrote: Hi all, The import is done, see here: http://cocoon.zones.apache.org/daisy/legacydocs All the imported docs belong to a collection called legacydocs. If a document belongs to this collection, a warning is put on top. Later this afternoon, I will start moving some docs to the new documentation (I'll probably start with the forms docs). I suggest that we create a collection/site documentation for this purpose. Done: http://cocoon.zones.apache.org/daisy/documentation Now we can start working on content ;-) -- Bruno Dumon http://outerthought.org/ Outerthought - Open Source, Java XML Competence Support Center [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: [docs] old docs import done
On 17 Jun 2005, at 16:53, Upayavira wrote: Mark Leicester wrote: Hi Bruno, Great! I've done a fair amount of work on the Cocoon In Action section. Should we look at merging the two, or do they have sufficiently distinct purposes to keep them separated? Helma, what do you think? Personally, what I want to see is two sections sites or sections: content can be repurposed in several places at the same time. Using this new environment, we'll hopefully be able to create smaller, more reusable pieces of content. /Steven -- Steven Noelshttp://outerthought.org/ Outerthought Open Source Java XML stevenn at outerthought.orgstevenn at apache.org
Re: [docs] old docs import done
Steven Noels wrote: On 17 Jun 2005, at 16:53, Upayavira wrote: Mark Leicester wrote: Hi Bruno, Great! I've done a fair amount of work on the Cocoon In Action section. Should we look at merging the two, or do they have sufficiently distinct purposes to keep them separated? Helma, what do you think? Personally, what I want to see is two sections sites or sections: content can be repurposed in several places at the same time. Using this new environment, we'll hopefully be able to create smaller, more reusable pieces of content. I want to see two sections. i.e. one navigation that covers both reference and tutorials. Yes documents can be reused, but a document detailing how the HTMLGenerator works, with all of its options, wouldn't be that useful in other parts of the documentation (other than as a link), IMO. Upayavira
Re: [GT2005] News, vote and more news
Il giorno 17/giu/05, alle 16:41, Steven Noels ha scritto: The Cocoon GetTogether will be travelling this year, in a bold and unprecedented move to check the quality of ribs across the globe. Our first stop will be in xxx Amsterdam xxx, during the first week of October. OK, that's hardly a adventurous distance from Ghent, but it'll do for our first edition abroad, won't it? Great news! I always wanted to visit Amsterdam, even though I loved Ghent. Yes, I'm thinking of attending the Cocoon GetTogether 2005 in Amsterdam, preferably on [+0.5] 3/4/5 October (Mon-Wed) [+0.5] 5/6/7 October (Wed-Fri) I.e. it makes no difference to me. Ugo -- Ugo Cei Tech Blog: http://agylen.com/ Open Source Zone: http://oszone.org/ Wine Food Blog: http://www.divinocibo.it/ smime.p7s Description: S/MIME cryptographic signature
Re: [docs] old docs import done
Le 17 juin 05, 17:08, Upayavira a crit : ...a document detailing how the HTMLGenerator works, with all of its options, wouldn't be that useful in other parts of the documentation (other than as a link), IMO. IMHO such reference documents should have permanent and predictable short URLs, say reference/components/HTMLGenerator in this case. That's hoping these will be generated automatically of course, at some point. -Bertrand smime.p7s Description: S/MIME cryptographic signature
Re: [docs] old docs import done
On Fri, 2005-06-17 at 17:15 +0200, Bertrand Delacretaz wrote: Le 17 juin 05, 17:08, Upayavira a crit : ...a document detailing how the HTMLGenerator works, with all of its options, wouldn't be that useful in other parts of the documentation (other than as a link), IMO. IMHO such reference documents should have permanent and predictable short URLs, say reference/components/HTMLGenerator in this case. That's hoping these will be generated automatically of course, at some point. Depends a bit on what is part of the automatically-generated docs. IMHO documentation that provides usage notes on components (thus, which is not really javadoc) should better not be maintained as javadoc. For example, take the I18nTransformer. There's a very very long javadoc there which is essentially user documentation and is very hard to read/maintain in the form of javadoc. I am +1 though on merging technical information on the component (such a it is cacheable, is it poolable, ...) automatically from the sources. -- Bruno Dumon http://outerthought.org/ Outerthought - Open Source, Java XML Competence Support Center [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: [GT2005] News, vote and more news
Hi, On 17 Jun 2005, at 15:41, Steven Noels wrote: Now, about the vote: we have rooms reserved for the entire first week of October, but need to decide on the first or last part of the week. So please indicate your preference (and reply to the dev list for easier counting): Yes, I'm thinking of attending the Cocoon GetTogether 2005 in Amsterdam, preferably on [+1] 3/4/5 October (Mon-Wed) [ ] 5/6/7 October (Wed-Fri) It would help in deciding if we had an indication of start / end times and social events, etc. In previous years, there's been a great chance to grab beers with people the night before, which effectively means arriving on a Sunday or a Tuesday. If that's the case this year too, then I'm in favour of 3/4/5 ... Presumably you're aiming for hackathon on days 12, with day 3 for the main presentations? Also, is it worth trying to do a deal with one of the larger hotels in Amsterdam, so as many of us as possible are all in one place, possibly securing a reduction in price? Hurry up October, I can't wait! Andrew. -- Andrew Savory, Managing Director, Luminas Limited Tel: +44 (0)870 741 6658 Fax: +44 (0)700 598 1135 Web: http://www.luminas.co.uk/ Orixo alliance: http://www.orixo.com/
Re: [GT2005] News, vote and more news
Ugo Cei wrote: Great news! I always wanted to visit Amsterdam, even though I loved Ghent. Yes, I'm thinking of attending the Cocoon GetTogether 2005 in Amsterdam, preferably on [+0.5] 3/4/5 October (Mon-Wed) [+0.5] 5/6/7 October (Wed-Fri) I.e. it makes no difference to me. Same here, mostly because I *want* to go, and there's an extremely small chance I can actually make it this year. Tony
Re: svn commit: r191129 - /cocoon/trunk/blocks.properties
Reinhard Poetz wrote: [EMAIL PROTECTED] wrote: Author: unico Date: Fri Jun 17 04:24:24 2005 New Revision: 191129 URL: http://svn.apache.org/viewcvs?rev=191129view=rev Log: jms dependencies changed Modified: cocoon/trunk/blocks.properties Maybe I've overlooked your commit of gump.xml, if not, blocks.properties is generated using some Ant task out of gump.xml. I guess you did overlook it, my version of gump.xml is up to date and I used it to generate the blocks.properties. -- Unico
RE: [GT2005] News, vote and more news
Presumably you're aiming for hackathon on days 12, with day 3 for the main presentations? Yes. The presentations will be on either wednesday the 5th, or friday the 7th. Also, is it worth trying to do a deal with one of the larger hotels in Amsterdam, so as many of us as possible are all in one place, possibly securing a reduction in price? Mmmm. Yes; could do that! Hurry up October, I can't wait! I can imagine - have 4 (!) nights of grabbing beers should sound attractive to you ;) Arj
Re: [docs] old docs import done
On Fri, 2005-06-17 at 12:40 +0200, Bruno Dumon wrote: Hi all, The import is done, see here: http://cocoon.zones.apache.org/daisy/legacydocs All the imported docs belong to a collection called legacydocs. If a document belongs to this collection, a warning is put on top. Forgot to mention, if anyone wants to change the warning message content or styling, this can be done by editing this XSL: /home/daisy/daisy/daisywiki/webapp/daisy/resources/document-styling/default/html/Document.xsl (on the zone) -- Bruno Dumon http://outerthought.org/ Outerthought - Open Source, Java XML Competence Support Center [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: [docs] old docs import done
On Fri, 2005-06-17 at 14:54 +0100, Mark Leicester wrote: Hi Bruno, Great! I've done a fair amount of work on the Cocoon In Action section. Should we look at merging the two, or do they have sufficiently distinct purposes to keep them separated? This is just IMHO... The parts of Cocoon In Action that talk about the build system and getting the code from SVN certainly belong in the documentation. The rest... I'm undecided yet. I have some preference to keep tutorials separate. -- Bruno Dumon http://outerthought.org/ Outerthought - Open Source, Java XML Competence Support Center [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: [GT2005] News, vote and more news
Well, I've already spoken to my boss and have tentatively worked something out with him. Mon - Wed would probably be better for me as I plan to stay a few extra days as I've never been to Europe at all, so I'll do a little sight seeing afterwards. I'd appreciate any advice regarding car rentals and places to see that are close by to wherever we are. Ralph Steven Noels wrote: Yes, I'm thinking of attending the Cocoon GetTogether 2005 in Amsterdam, preferably on [ ] 3/4/5 October (Mon-Wed) [ ] 5/6/7 October (Wed-Fri) That's all for now, expect more to hear from Arj or me in the future! Cheers, /Steven
RE: [SUMMARY] [VOTE] Document Editors, and a new Committer
I would have thought the husband and two boys were the fulltime job! Obviously, Helma has at least two full time jobs. It can be argued that she has 4 full time jobs. From personal experience having a spouse is a full time job and most certainly raising a child is a full time job. Helma has a day job, a husband and two children. Therefore, Helma has 4 full time jobs. Trust me for taking the difficult path. ;-) Congratulations Helma. Don't work any more then 40 hours a week at each job. If you do you won't be working agile. ;-) Oops, that leaves 8 hours of sleep per week. That's wy too much. ;-) Bye, Helma
RE: [GT2005] News, vote and more news
Yes, I'm thinking of attending the Cocoon GetTogether 2005 in Amsterdam, preferably on [ ] 3/4/5 October (Mon-Wed) [X] 5/6/7 October (Wed-Fri) Bye, Helma
Re: [GT2005] News, vote and more news
Yes, I'm thinking of attending the Cocoon GetTogether 2005 in Amsterdam, preferably on [x] 3/4/5 October (Mon-Wed) [x] 5/6/7 October (Wed-Fri) ...a weekend in amsterdam afterwards or beforehand is still a weekend in amsterdam ;) Both options are just fine! :-D cheers -- Torsten signature.asc Description: OpenPGP digital signature
RE: [docs] old docs import done
Guys, When the navigation is a matter of creating a query and/or a hand-picked outline, I really don't think it is THAT important to decide now. When writing the tutorial I found it practical to keep the various steps/documents together so I could better focus on what to write and what was done. But the ultimate form will probably be different. I myself like documentation based on a growing example with background information woven into it, but once I get the idea I like an extensive index for quick access to the various details. Maybe, we can ultimately decide that there are various sites, all handling the same documentation, but with different navigational setups. That way each can choose his/her own preferred way of diving into the matter. AFAIU Daisy is capable of doing this, so let's focus on content first with a preliminary navigation. Bye, Helma -Original Message- From: Bruno Dumon [mailto:[EMAIL PROTECTED] Sent: Friday, 17 June 2005 17:46 To: dev@cocoon.apache.org Subject: Re: [docs] old docs import done On Fri, 2005-06-17 at 14:54 +0100, Mark Leicester wrote: Hi Bruno, Great! I've done a fair amount of work on the Cocoon In Action section. Should we look at merging the two, or do they have sufficiently distinct purposes to keep them separated? This is just IMHO... The parts of Cocoon In Action that talk about the build system and getting the code from SVN certainly belong in the documentation. The rest... I'm undecided yet. I have some preference to keep tutorials separate. -- Bruno Dumon http://outerthought.org/ Outerthought - Open Source, Java XML Competence Support Center [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: [docs] old docs import done
Le 17 juin 05, 17:56, Bruno Dumon a crit : ...Depends a bit on what is part of the automatically-generated docs. IMHO documentation that provides usage notes on components (thus, which is not really javadoc) should better not be maintained as javadoc... The idea, based on the summer of code cocoon-refdoc project [1], is to mostly use what already exists to build the reference docs / manpages: sitemap snippets, example input files, parameters information extracted from code comments, and some short narrative which can be entered either inside the code or in separate files (html or wiki formats). But it's all vaporware for now ;-) We'll know more if the cocoon-refdoc project actually happens. -Bertrand [1] http://wiki.apache.org/cocoon/CocoonRefDocProject smime.p7s Description: S/MIME cryptographic signature
Re: [GT2005] News, vote and more news
Le 17 juin 05, 16:41, Steven Noels a crit : ...Yes, I'm thinking of attending the Cocoon GetTogether 2005 in Amsterdam, preferably on [+1 ] 3/4/5 October (Mon-Wed) [ +0.5] 5/6/7 October (Wed-Fri) Thanks Steven and Arj! -Bertrand smime.p7s Description: S/MIME cryptographic signature
iCal
Has anyone thought about integrating iCal with Cocoon?
