Re: a new cocoon logo?
Il giorno 02/nov/05, alle ore 23:06, Stefano Mazzocchi ha scritto: +1 to new skin but only with new content. Agree. -1 to the logo, no reason to change a widely recognized one with a new one just for sake of change. Agree as well. Let's keep the current logo, at least until we release Cocoon 3. Ugo -- Ugo Cei Tech Blog: http://agylen.com/ Open Source Zone: http://oszone.org/ Wine Food Blog: http://www.divinocibo.it/
Re: [Vote] Releasing on friday
Il giorno 03/nov/05, alle ore 06:47, Carsten Ziegeler ha scritto: Please cast your votes for releasing 2.1.8 on friday, 4th of November. -0.5. Too many CForms last minute changes, as you wrote in response to Sylvain. Incidentally, I'm +1 on Sylvain's proposed changes to element id generation strategy. Ugo -- Ugo Cei Tech Blog: http://agylen.com/ Open Source Zone: http://oszone.org/ Wine Food Blog: http://www.divinocibo.it/
Re: Problem with XHTMLSerializers
On 11/3/05, Jeroen Reijn [EMAIL PROTECTED] wrote: Helma,We have the same problem with our sites. As far is I know they only workaroundis by putting a space between the script tags like script#160;/script Thanks. I already did that, but it's really not that elegant. BTW I somehow managed to get this fixed but I have no clue what I did different now. Another problem that cropped up with the exhtml serializer is that ' are changed to apos; so all my little _javascript_s suddenly became useless: script src="" select=someparam/');/script turned into script src="" any idea? Bye, Helma
Re: svn commit: r330329 - in /cocoon/blocks/portal/trunk/java/org/apache/cocoon/portal: coplet/ layout/ layout/renderer/aspect/impl/ layout/renderer/impl/ persistence/castor/
Carsten Ziegeler wrote: Ralph Goers wrote: And what about the case that I added support for - full screen with all the navigation still present? Actually, your changes broke the full screen feature if no tab is available. If you look at the current portal demo, full screen does not work anymore in the anonymous section as there is no tab. Ouch. Well I could look into fixing that tomorrow. It needs to work in 2.1 and I presume the changes below are only going in trunk. Or is that what you are calling max-paged (I get realy confused by this since the default 2.1 behavior is min/normal/full-screen-no-nav)? The new possibilities are min/norma/full-screen-no-nav/max-paged where max-paged is a full-screen with static parts (= navigation and important portlets). Frankly, the static layout thing sounds like it could get to be quite a pain. I really don't want to have to add an attribute on every single tab to say it should always be shown. Yes, for sure. We will have default values for each layout object. And the default for a tab will be static=true. So actually you shouldn't have to add an attribute at all. I suggest, just give me some more days to implement this stuff. Then we all can have a look at it and decide if it's a good thing or if it's crap. And then perhaps we see what we really need. But as I said, we have the use case for full-screen (= one single coplet without any navigation) and max-paged. Perhaps max-paged is a wrong or misleading term? Well, JSR-168 (almost) defines NORMAL, MAXIMIZED and MINIMIZED. Unfortunately, both full-screen and max-paged meet the definition of MAXIMIZED so it isn't clear what behavior a portlet should exhibit in that case. In addition, JSR-168 allows us to define other window states. So I would suggest that whatever window states are supported that they be done in such a way that they can eventually be used by JSR-168 portlets as well as coplets. Hmm, I thought if preferences are changing, the coplet instances data are only saved and not the layout? After looking at the code I guess your right - we only write out the coplet instances data. That isn't a problem for me now, but I imagine it will be for some users. But you're right that it's not good to save the whole bunch of data. We should provide the information about what changed to the persistence layer and it's then up to the layer to decide to save the whole profile or just the changed information. As I recall this was partly an artifact of the way that pluto stores preferences. I believe pluto starts the process by calling PortletEntityImpl.store(). So unless we keep track of the parts that have changed ourselves we don't know what has changed and so we write the whole thing. However, I believe it is worse than that because we end up using Castor to generate the XML and it, of course, is going to want to generate the whole document. Ralph
Re: [Vote] Releasing on friday
Ugo Cei wrote: Il giorno 03/nov/05, alle ore 06:47, Carsten Ziegeler ha scritto: Please cast your votes for releasing 2.1.8 on friday, 4th of November. -0.5. Too many CForms last minute changes, as you wrote in response to Sylvain. +1 from me. Let's not delay once more the baby The last minute change is just about replacing -input with :input within two XSLs, to avoid problems later. I could have kept silent on this minor issue, as its probability is rather low, but wanted to avoid any future backwards compatibility issue in the future is it really becomes a problem. This a way also to start some consistent naming practices in stylesheet-generated elements, which will be more and more needed as widgets of increasing complexity will appear. Incidentally, I'm +1 on Sylvain's proposed changes to element id generation strategy. Ok. Sylvain -- Sylvain WallezAnyware Technologies http://people.apache.org/~sylvain http://www.anyware-tech.com Apache Software Foundation Member Research Technology Director
Re: [Vote] Releasing on friday
Sylvain Wallez wrote: Ugo Cei wrote: Il giorno 03/nov/05, alle ore 06:47, Carsten Ziegeler ha scritto: Please cast your votes for releasing 2.1.8 on friday, 4th of November. -0.5. Too many CForms last minute changes, as you wrote in response to Sylvain. +1 from me. Let's not delay once more the baby The last minute change is just about replacing -input with :input within two XSLs, to avoid problems later. I could have kept silent on this minor issue, as its probability is rather low, but wanted to avoid any future backwards compatibility issue in the future is it really becomes a problem. This a way also to start some consistent naming practices in stylesheet-generated elements, which will be more and more needed as widgets of increasing complexity will appear. Incidentally, I'm +1 on Sylvain's proposed changes to element id generation strategy. My question before voting is how have you gone about identifying that a colon is a valid character within ids in all browsers? Regards, Upayavira
Re: [Vote] Releasing on friday
Upayavira wrote: Incidentally, I'm +1 on Sylvain's proposed changes to element id generation strategy. My question before voting is how have you gone about identifying that a colon is a valid character within ids in all browsers? I checked the XML specification: http://www.w3.org/TR/REC-xml/#id Sylvain -- Sylvain WallezAnyware Technologies http://people.apache.org/~sylvain http://www.anyware-tech.com Apache Software Foundation Member Research Technology Director
Re: a new cocoon logo?
hepabolu wrote: Stefano Mazzocchi wrote: +1 to new skin but only with new content. I'd like a more lighter (i.e. in color) skin, much along the lines of the current Maven site. If you want to make new content a prerequisite for a new skin, it won't happen for a long time. The speed of updating/adding content is simply too slow for that. I'd propose an new skin for Cocoon 2.2. I agree. Now, you might think that there's no new documentation in Daisy. I would tend to disagree. There's been a certain 'freshening' of the docs there, which, to my mind, is sufficient to justify a new skin. A new skin would be a part of the 'our documentation has changed/is changing' message, and would be good to have done before 2.2 is released. -1 to the logo, no reason to change a widely recognized one with a new one just for sake of change. There is no reason to stick with the current logo forever. A slight change that modernizes the logo would be ok. And I don't want to start the discussion on what modern is. However, I'm -1 on the initial proposal since there is no relation with the old logo. But +1 to the initiative that Frédéric took. We need more of that. Maybe he can take this as some interesting feedback to his design, and show us what he can come up with next, logo or skin-wise. All good changes come in many small steps. Yup. Upayavira
CForms widget ID naming (was Re: [Vote] Releasing on friday)
(I think this should be discussed in a separate thread) Sylvain Wallez wrote: The last minute change is just about replacing -input with :input within two XSLs, to avoid problems later. Isn't : used as separator for the namespace prefix? I don't know if this applies to IDs too, but perhaps we should double-check before. If it is allowed by the XML spec, it makes me wonder, if we want to prefix the IDs some time in the future to use some kind of namespace here too? Wouldn't this conflict with :input as you then cannot distinguish between the two anymore (namespace prefix vs. :input suffix). Just some random thoughts ... Perhaps it would help to write something up which summarizes all the IDs, names, prefixes, suffixes and namespaces involved in every part of CForms. Andreas.
Re: CForms widget ID naming (was Re: [Vote] Releasing on friday)
Andreas Hochsteger wrote: (I think this should be discussed in a separate thread) Sylvain Wallez wrote: The last minute change is just about replacing -input with :input within two XSLs, to avoid problems later. Isn't : used as separator for the namespace prefix? I don't know if this applies to IDs too, but perhaps we should double-check before. The : is a valid character in element names and ID and IDREF attributes (they are defined using the same grammar rule). Parsers use the : in a special way for element names only, when namespace processing is activated (the default in all modern browsers) If it is allowed by the XML spec, it makes me wonder, if we want to prefix the IDs some time in the future to use some kind of namespace here too. This usage in CForms has already been introduced by the recent library stuff, which associates prefixes to libraries, thus effectively forbidding the use of : in widget ids (otherwise you cannot differenciate between a widget name and a composite name that references a library widget). That is why I chose this character. The / and . are also forbidden (used for lookup paths). The . cannot be used as it is used to combine widget names in the generated IDs, and thus would lead to a similar problem as the current one: - can conflict with siblings, and . can conflict with children. So the choice is between / and :, but / is not allowed in XML names. Hence the result, :... Wouldn't this conflict with :input as you then cannot distinguish between the two anymore (namespace prefix vs. :input suffix). No, because as I said above, using : in widget names is effectively forbidden by the library prefix notation. Another possibility is to prefix the name of generated-ids with : (this is allowed by the XML spec), e.g. :foo-input instead of foo:input. But I prefer to keep the widget ID as the prefix of all that is related to its styling. The rule is then: a styling stylesheed can generate whatever ID its needs for a widget by suffixing the widget's id with : followed by a name. Care should be taken of course that this name doesn't conflict with names produced by other stylesheets. Just some random thoughts ... Perhaps it would help to write something up which summarizes all the IDs, names, prefixes, suffixes and namespaces involved in every part of CForms. Yup. That should be part of the documentation of the various stylings. Sylvain -- Sylvain WallezAnyware Technologies http://people.apache.org/~sylvain http://www.anyware-tech.com Apache Software Foundation Member Research Technology Director
[jira] Closed: (COCOON-1672) Help popup broken in CForms samples
[ http://issues.apache.org/jira/browse/COCOON-1672?page=all ] Sylvain Wallez closed COCOON-1672: -- Resolution: Fixed Fixed by revisions r330513 and r330514 Help popup broken in CForms samples --- Key: COCOON-1672 URL: http://issues.apache.org/jira/browse/COCOON-1672 Project: Cocoon Type: Bug Components: Blocks: Forms, - Samples Versions: 2.1.8-dev (Current SVN) Reporter: Andreas Hochsteger Assignee: Sylvain Wallez If you open the multiform (ajax) sample (http://cocoon.zones.apache.org/demos/21branch/samples/blocks/forms/do-multipage.flow) and click on the help popup for the email addres, it is working. But if you click on next, then it is not working any more. I get the following JavaScript error: Error: helpWinN10010 has no properties It seems to me, that the help window is not referenced correctly after the first submit. Perhaps it's AJAX-related, because it is working for non-ajax samples: http://cocoon.zones.apache.org/demos/21branch/samples/blocks/forms/form1 http://cocoon.zones.apache.org/demos/21branch/samples/blocks/forms/captcha/ Similar problems can be found on the following samples with the help popup and calendar popup, where the images are missing too: http://cocoon.zones.apache.org/demos/21branch/samples/blocks/forms/library/form1.flow http://cocoon.zones.apache.org/demos/21branch/samples/blocks/forms/library/form2.flow http://cocoon.zones.apache.org/demos/21branch/samples/blocks/forms/library/hotel.flow I tested it locally with a fresh svn checkout (r330107) and on cocoon.zones.apache.org with Firefox 1.5beta2 and IE 6 (Win XP Pro, SP2), Sun JDK 1.5.0_04. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: CForms widget ID naming (was Re: [Vote] Releasing on friday)
Sylvain Wallez wrote: This usage in CForms has already been introduced by the recent library stuff, which associates prefixes to libraries, thus effectively forbidding the use of : in widget ids (otherwise you cannot differenciate between a widget name and a composite name that references a library widget). That is why I chose this character. The / and . are also forbidden (used for lookup paths). The . cannot be used as it is used to combine widget names in the generated IDs, and thus would lead to a similar problem as the current one: - can conflict with siblings, and . can conflict with children. Do we already validate a widget id if it does not contain all of these forbidden characters? If not, we really should check this and throw an exception when the model is read. Early failing is better than unpredictable results later on. Carsten -- Carsten Ziegeler - Open Source Group, SN AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
DO NOT REPLY [Bug 36810] - source that declares namespace fails JXPath/Linkrewriter/Input Modules
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=36810. 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=36810 Bug 36810 depends on bug 32360, which changed state. Bug 32360 Summary: [jxpath] Default Namespace not handled correctly http://issues.apache.org/bugzilla/show_bug.cgi?id=32360 What|Old Value |New Value Status|RESOLVED|REOPENED Resolution|FIXED | -- 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: a new cocoon logo?
Upayavira wrote: hepabolu wrote: Stefano Mazzocchi wrote: +1 to new skin but only with new content. I'd like a more lighter (i.e. in color) skin, much along the lines of the current Maven site. If you want to make new content a prerequisite for a new skin, it won't happen for a long time. The speed of updating/adding content is simply too slow for that. I'd propose an new skin for Cocoon 2.2. I agree. Now, you might think that there's no new documentation in Daisy. I would tend to disagree. There's been a certain 'freshening' of the docs there, which, to my mind, is sufficient to justify a new skin. A new skin would be a part of the 'our documentation has changed/is changing' message, and would be good to have done before 2.2 is released. How about choosing a new set of colours, perhaps based on the light-blue of the Cocoon logo: http://wiki.apache.org/cocoon/PoweredByCocoon It is easy to change the colours. Edit this (search in file for colors) ... https://svn.apache.org/repos/asf/cocoon/whiteboard/daisy-to-docs/src/documentation/skinconf.xml and watch the changes show up at: http://forrest.zones.apache.org/ft/build/cocoon-docs/2.1/ -David
Re: CForms widget ID naming (was Re: [Vote] Releasing on friday)
Carsten Ziegeler wrote: Sylvain Wallez wrote: This usage in CForms has already been introduced by the recent library stuff, which associates prefixes to libraries, thus effectively forbidding the use of : in widget ids (otherwise you cannot differenciate between a widget name and a composite name that references a library widget). That is why I chose this character. The / and . are also forbidden (used for lookup paths). The . cannot be used as it is used to combine widget names in the generated IDs, and thus would lead to a similar problem as the current one: - can conflict with siblings, and . can conflict with children. Do we already validate a widget id if it does not contain all of these forbidden characters? If not, we really should check this and throw an exception when the model is read. Early failing is better than unpredictable results later on. Yep. The . and / are already checked in AbstractWidgetDefinition.setCommonProperties(). We just need to add :. BTW, I'm ready to commit the updated stylesheets, which I tested on IE 6, Firefox and Safari. Sylvain -- Sylvain WallezAnyware Technologies http://people.apache.org/~sylvain http://www.anyware-tech.com Apache Software Foundation Member Research Technology Director
[jira] Closed: (COCOON-1594) SQLTransformer swallowing whitespace on substitute-value
[ http://issues.apache.org/jira/browse/COCOON-1594?page=all ] Jeremy Quinn closed COCOON-1594: Resolution: Fixed updated SQLTransformer and TextRecorder to not strip spaces from the SQL Query SQLTransformer swallowing whitespace on substitute-value Key: COCOON-1594 URL: http://issues.apache.org/jira/browse/COCOON-1594 Project: Cocoon Type: Bug Components: Blocks: Databases Versions: 2.1.8-dev (Current SVN) Environment: Operating System: other Platform: Macintosh Reporter: andrew Assignee: Cocoon Developers Team Fix For: 2.1.8-dev (Current SVN) Attachments: example.xmap, param-bug.xml The following code will fail: sql:query SELECT id, name, description from department LIMIT substitute-value sql:name=start/,substitute-value sql:name=count/ /sql:query After the values are substituted, the output is: SELECT id, name, description from department LIMITn,m ... instead of SELECT id, name, description from department LIMIT n,m -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: CForms widget ID naming (was Re: [Vote] Releasing on friday)
Sylvain Wallez wrote: Carsten Ziegeler wrote: Sylvain Wallez wrote: This usage in CForms has already been introduced by the recent library stuff, which associates prefixes to libraries, thus effectively forbidding the use of : in widget ids (otherwise you cannot differenciate between a widget name and a composite name that references a library widget). That is why I chose this character. The / and . are also forbidden (used for lookup paths). The . cannot be used as it is used to combine widget names in the generated IDs, and thus would lead to a similar problem as the current one: - can conflict with siblings, and . can conflict with children. Do we already validate a widget id if it does not contain all of these forbidden characters? If not, we really should check this and throw an exception when the model is read. Early failing is better than unpredictable results later on. Yep. The . and / are already checked in AbstractWidgetDefinition.setCommonProperties(). We just need to add :. BTW, I'm ready to commit the updated stylesheets, which I tested on IE 6, Firefox and Safari. Ok, changes committed. Let's get this baby 2.1.8 out! Sylvain -- Sylvain WallezAnyware Technologies http://people.apache.org/~sylvain http://www.anyware-tech.com Apache Software Foundation Member Research Technology Director
Re: [Vote] Releasing on friday
On 3 Nov 2005, at 05:47, Carsten Ziegeler wrote: Please cast your votes for releasing 2.1.8 on friday, 4th of November. (if we vote to not release on friday, I can do the release on any day in the next week). What about these three issues targeted for 2.1.8 ??? http://issues.apache.org/jira/secure/IssueNavigator.jspa? pid=12310170resolution=-1fixfor=12310601sorter/ field=issuekeysorter/order=DESCtempMax=25reset=true Unfortunately I'm under deadline and have no time to dig into them ATM. Pier smime.p7s Description: S/MIME cryptographic signature
Re: svn commit: r330329 - in /cocoon/blocks/portal/trunk/java/org/apache/cocoon/portal: coplet/ layout/ layout/renderer/aspect/impl/ layout/renderer/impl/ persistence/castor/
Ralph Goers wrote: Ouch. Well I could look into fixing that tomorrow. It needs to work in 2.1 and I presume the changes below are only going in trunk. Yes, all new features are just going to trunk. Well, JSR-168 (almost) defines NORMAL, MAXIMIZED and MINIMIZED. Unfortunately, both full-screen and max-paged meet the definition of MAXIMIZED so it isn't clear what behavior a portlet should exhibit in that case. Yes, I think we can map max-paged to MAXIMIZED and full-screen to something else. In addition, JSR-168 allows us to define other window states. So I would suggest that whatever window states are supported that they be done in such a way that they can eventually be used by JSR-168 portlets as well as coplets. Yes, good idea. But you're right that it's not good to save the whole bunch of data. We should provide the information about what changed to the persistence layer and it's then up to the layer to decide to save the whole profile or just the changed information. As I recall this was partly an artifact of the way that pluto stores preferences. I believe pluto starts the process by calling PortletEntityImpl.store(). So unless we keep track of the parts that have changed ourselves we don't know what has changed and so we write the whole thing. However, I believe it is worse than that because we end up using Castor to generate the XML and it, of course, is going to want to generate the whole document. I think we should keep track of the changed parts. As store() is invoked it shouldn't be that difficult. Carsten -- Carsten Ziegeler - Open Source Group, SN AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
[EMAIL PROTECTED]: Project cocoon (in module cocoon) failed
To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at [EMAIL PROTECTED] Project cocoon has an issue affecting its community integration. This issue affects 57 projects, and has been outstanding for 8 runs. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - cocoon : Java XML Framework - cocoon-block-ajax : Ajax - Utilities and resources for Ajax applications. - cocoon-block-apples : Java XML Framework - cocoon-block-asciiart : Java XML Framework - cocoon-block-authentication-fw : Java XML Framework - cocoon-block-axis : Java XML Framework - cocoon-block-batik : Java XML Framework - cocoon-block-bsf : Java XML Framework - cocoon-block-captcha : Utilites to generate simple CAPTCHAs - cocoon-block-chaperon : Java XML Framework - cocoon-block-core-samples-additional : Additional core samples. - cocoon-block-core-samples-main : Main core samples. - cocoon-block-cron : Java XML Framework - cocoon-block-databases : Java XML Framework - cocoon-block-deli : Java XML Framework - cocoon-block-eventcache : Java XML Framework - cocoon-block-fop : Java XML Framework - cocoon-block-forms : Java XML Framework - cocoon-block-hsqldb : Java XML Framework - cocoon-block-html : Java XML Framework - cocoon-block-itext : Java XML Framework - cocoon-block-javaflow : Java XML Framework - cocoon-block-jcr : A jcr: protocol for Cocoon - cocoon-block-jfor : Java XML Framework - cocoon-block-jms : Java XML Framework - cocoon-block-jsp : Java XML Framework - cocoon-block-linkrewriter : Java XML Framework - cocoon-block-lucene : Java XML Framework - cocoon-block-midi : Java XML Framework - cocoon-block-naming : Java XML Framework - cocoon-block-ojb : Java XML Framework - cocoon-block-paranoid : Java XML Framework - cocoon-block-petstore : Java XML Framework - cocoon-block-portal : Java XML Framework - cocoon-block-portal-sample : Java XML Framework - cocoon-block-profiler : Java XML Framework - cocoon-block-proxy : Java XML Framework - cocoon-block-python : Java XML Framework - cocoon-block-qdox : Java XML Framework - cocoon-block-querybean : Java XML Framework - cocoon-block-repository : Java XML Framework - cocoon-block-serializers : Java XML Framework - cocoon-block-session-fw : Java XML Framework - cocoon-block-slop : Java XML Framework - cocoon-block-spring-app : A demo for Spring and Cocoon - cocoon-block-stx : Java XML Framework - cocoon-block-taglib : Java XML Framework - cocoon-block-template : Java XML Framework - cocoon-block-tour : Java XML Framework - cocoon-block-validation : In-pipeline validation of documents - cocoon-block-velocity : Java XML Framework - cocoon-block-web3 : Java XML Framework - cocoon-block-xmldb : Java XML Framework - cocoon-block-xsp : Java XML Framework - forrest : Apache Forrest is an XML standards-oriented documentation fr... - forrest-test : Apache Forrest is an XML standards-oriented documentation fr... - lenya : Content Management System Full details are available at: http://vmgump.apache.org/gump/public/cocoon/cocoon/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Output [cocoon.jar] identifier set to output basename: [cocoon] -DEBUG- Output [cocoon-testcase.jar] identifier set to output basename: [cocoon-testcase] -DEBUG- Output [cocoon-deprecated.jar] identifier set to output basename: [cocoon-deprecated] -INFO- Made directory [/usr/local/gump/public/workspace/cocoon/build/cocoon-03112005/test] -INFO- Failed with reason build failed -INFO- Project Reports in: /usr/local/gump/public/workspace/cocoon/build/cocoon-03112005/test/output -WARNING- No directory [/usr/local/gump/public/workspace/cocoon/build/cocoon-03112005/test/output] -INFO- Failed to extract fallback artifacts from Gump Repository The following work was performed: http://vmgump.apache.org/gump/public/cocoon/cocoon/gump_work/build_cocoon_cocoon.html Work Name: build_cocoon_cocoon (Type: Build) Work ended in a state of : Failed Elapsed: 17 secs Command Line: java -Djava.awt.headless=true -Xbootclasspath/p:/usr/local/gump/public/workspace/xml-commons/java/external/build/xml-apis.jar:/usr/local/gump/public/workspace/xml-xerces2/java/build/xercesImpl.jar org.apache.tools.ant.Main -Dgump.merge=/x1/gump/public/gump/work/merge.xml -Dbuild.sysclasspath=only -Dlogkit.jar=/usr/local/gump/public/workspace/avalon-trunk/runtime/logkit/target/deliverables/jars/avalon-logkit-03112005.jar
[EMAIL PROTECTED]: Project cocoon (in module cocoon) failed
To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at [EMAIL PROTECTED] Project cocoon has an issue affecting its community integration. This issue affects 57 projects, and has been outstanding for 8 runs. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - cocoon : Java XML Framework - cocoon-block-ajax : Ajax - Utilities and resources for Ajax applications. - cocoon-block-apples : Java XML Framework - cocoon-block-asciiart : Java XML Framework - cocoon-block-authentication-fw : Java XML Framework - cocoon-block-axis : Java XML Framework - cocoon-block-batik : Java XML Framework - cocoon-block-bsf : Java XML Framework - cocoon-block-captcha : Utilites to generate simple CAPTCHAs - cocoon-block-chaperon : Java XML Framework - cocoon-block-core-samples-additional : Additional core samples. - cocoon-block-core-samples-main : Main core samples. - cocoon-block-cron : Java XML Framework - cocoon-block-databases : Java XML Framework - cocoon-block-deli : Java XML Framework - cocoon-block-eventcache : Java XML Framework - cocoon-block-fop : Java XML Framework - cocoon-block-forms : Java XML Framework - cocoon-block-hsqldb : Java XML Framework - cocoon-block-html : Java XML Framework - cocoon-block-itext : Java XML Framework - cocoon-block-javaflow : Java XML Framework - cocoon-block-jcr : A jcr: protocol for Cocoon - cocoon-block-jfor : Java XML Framework - cocoon-block-jms : Java XML Framework - cocoon-block-jsp : Java XML Framework - cocoon-block-linkrewriter : Java XML Framework - cocoon-block-lucene : Java XML Framework - cocoon-block-midi : Java XML Framework - cocoon-block-naming : Java XML Framework - cocoon-block-ojb : Java XML Framework - cocoon-block-paranoid : Java XML Framework - cocoon-block-petstore : Java XML Framework - cocoon-block-portal : Java XML Framework - cocoon-block-portal-sample : Java XML Framework - cocoon-block-profiler : Java XML Framework - cocoon-block-proxy : Java XML Framework - cocoon-block-python : Java XML Framework - cocoon-block-qdox : Java XML Framework - cocoon-block-querybean : Java XML Framework - cocoon-block-repository : Java XML Framework - cocoon-block-serializers : Java XML Framework - cocoon-block-session-fw : Java XML Framework - cocoon-block-slop : Java XML Framework - cocoon-block-spring-app : A demo for Spring and Cocoon - cocoon-block-stx : Java XML Framework - cocoon-block-taglib : Java XML Framework - cocoon-block-template : Java XML Framework - cocoon-block-tour : Java XML Framework - cocoon-block-validation : In-pipeline validation of documents - cocoon-block-velocity : Java XML Framework - cocoon-block-web3 : Java XML Framework - cocoon-block-xmldb : Java XML Framework - cocoon-block-xsp : Java XML Framework - forrest : Apache Forrest is an XML standards-oriented documentation fr... - forrest-test : Apache Forrest is an XML standards-oriented documentation fr... - lenya : Content Management System Full details are available at: http://vmgump.apache.org/gump/public/cocoon/cocoon/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Output [cocoon.jar] identifier set to output basename: [cocoon] -DEBUG- Output [cocoon-testcase.jar] identifier set to output basename: [cocoon-testcase] -DEBUG- Output [cocoon-deprecated.jar] identifier set to output basename: [cocoon-deprecated] -INFO- Made directory [/usr/local/gump/public/workspace/cocoon/build/cocoon-03112005/test] -INFO- Failed with reason build failed -INFO- Project Reports in: /usr/local/gump/public/workspace/cocoon/build/cocoon-03112005/test/output -WARNING- No directory [/usr/local/gump/public/workspace/cocoon/build/cocoon-03112005/test/output] -INFO- Failed to extract fallback artifacts from Gump Repository The following work was performed: http://vmgump.apache.org/gump/public/cocoon/cocoon/gump_work/build_cocoon_cocoon.html Work Name: build_cocoon_cocoon (Type: Build) Work ended in a state of : Failed Elapsed: 17 secs Command Line: java -Djava.awt.headless=true -Xbootclasspath/p:/usr/local/gump/public/workspace/xml-commons/java/external/build/xml-apis.jar:/usr/local/gump/public/workspace/xml-xerces2/java/build/xercesImpl.jar org.apache.tools.ant.Main -Dgump.merge=/x1/gump/public/gump/work/merge.xml -Dbuild.sysclasspath=only -Dlogkit.jar=/usr/local/gump/public/workspace/avalon-trunk/runtime/logkit/target/deliverables/jars/avalon-logkit-03112005.jar
Re: [Vote] Releasing on friday
2005/11/3, Pier Fumagalli [EMAIL PROTECTED]: On 3 Nov 2005, at 05:47, Carsten Ziegeler wrote: Please cast your votes for releasing 2.1.8 on friday, 4th of November. (if we vote to not release on friday, I can do the release on any day in the next week). What about these three issues targeted for 2.1.8 ??? http://issues.apache.org/jira/secure/IssueNavigator.jspa? pid=12310170resolution=-1fixfor=12310601sorter/ field=issuekeysorter/order=DESCtempMax=25reset=true Unfortunately I'm under deadline and have no time to dig into them ATM. I could not access JIRA (Bad Gateway), but I am about to open a JIRA ticket concerning a caching issue which is quite important (a.k.a. release-critical) for the project I am working on. I do not know if it is critical for Cocoon, possibly not, as it is already present in 2.1.7. But it would be nice if a knowledgeable Cocoon developer looked quickly into the issue to check if it is important for Cocoon or not or if I am doing something obviously wrong. (Big thanks!!) The post describing the issue is on the users list, archived on http://marc.theaimsgroup.com/?l=xml-cocoon-usersm=113102299909051w=2 Thank you in advance. -- Antonio
[M10N] new repo layout
Hi all, I've just committed an example of how our repository could be structured to support the ongoing componentization, new (osgi) block structure and M10N. Daniel suggested this flat structure a while ago [0], maven [1] and eclipse [2] use a similar layout. The example is in the whiteboard, under maven2/cocoon-flat-layout. The concept is the following : /trunk pom.xml /cocoon-core /cocoon-forms-block /cocoon-ajax-block /cocoon-asciiart-block /... other blocks /webapp -- pom.xml This is essentially just a multi-module pom which acts as the parent of all module poms. modulecocoon-core/module modulecocoon-ajax-block/module modulecocoon-forms-block/module It allows us to define properties and plugins valid for all modules. Child modules can still override if necessary. -- /cocoon-core This is kept as one maven module for now, we can choose to split this up further. I didn't separate this one into api/impl as I wasn't sure if it made sense, but maven-wise it's very easy to do so. -- /cocoon-forms-block, /cocoon-asciiart-block ... All modules that we choose to host and support ourselves land in the repository root. We can either stick to the existing block naming convention or go for a package based approach like eclipse. -- /webapp This is a special module in the sense that it will be used as a deployment target for blocks during development. The webapp will also get included in various other package and deployment targets. To test the usability from the new structure, go to maven2/cocoon-flat-layout and do mvn -Dmaven.test.skip=true install eclipse:eclipse , it will create an eclipse project for each module, at the end you should see something like [INFO] BUILD SUCCESSFUL [INFO] - [INFO] Total time: 54 seconds [INFO] Finished at: Thu Oct 27 00:36:29 CEST 2005 [INFO] Final Memory: 8M/51M In eclipse, you then do File-Import-Existing Projects Into Workspace and point the root directory to maven2/cocoon-flat-layout. It should detect all available projects, complete with library + inter-project dependencies, source and targetpaths. Note that you'll need to setup the M2_REPO variable to point to your maven2 repo. Alternatively, the eclipse plugin can do this for you [3]. Please have a look and tell me what you think. I'll explain the new block structure in another thread. Regards Jorg [0] http://thread.gmane.org/gmane.text.xml.cocoon.devel/54923 [1] http://svn.apache.org/viewcvs.cgi/maven/components/trunk/ [2] http://dev.eclipse.org/ [3] http://maven.apache.org/maven2/plugins/maven-eclipse-plugin/add-maven-repo-mojo.html
[M10N] new block layout
A standard block layout can look like this : /cocoon-forms-block pom.xml /api pom.xml /impl pom.xml /samples pom.xml -- pom.xml Is a multimodule pom containing modules moduleapi/module moduleimpl/module modulesamples/module /modules as well as the dependencies for the block . dependency groupIdapache-cocoon/groupId artifactIdcocoon-ajax-impl/artifactId version2.2-SNAPSHOT/version /dependency dependency groupIdjakarta-oro/groupId artifactIdjakarta-oro/artifactId version2.0.8/version /dependency . Note: I'm not 100% sure yet about adding all dependencies at this level, this still needs some thought. For now it will do. -- /api Use this if the block has different implementations with a common api. The api pom is a child of the parent block pom so it pulls in all the dependencies. parent groupIdapache-cocoon/groupId artifactIdcocoon-forms-block/artifactId version2.2-SNAPSHOT/version /parent -- /impl The block implementation, it has a default dependency on the api block dependency groupIdapache-cocoon/groupId artifactIdcocoon-forms-api/artifactId version2.2-SNAPSHOT/version /dependency -- /samples Special purpose module to build our sample website together. Basically this is the contents of eg blocks/forms/trunk/samples together with the sample java classes. The samples pom has a dependency on the impl pom as chances are it won't run without ;) dependency groupIdapache-cocoon/groupId artifactIdcocoon-forms-impl/artifactId version2.2-SNAPSHOT/version /dependency The block component itself follows the standard maven directory layout [1], src/main/resources has COB-INF and META-INF. WDYT ? Jorg [1] http://maven.apache.org/maven2/guides/introduction/introduction-to-the-standard-directory-layout.html
Re: [M10N] new repo layout
Jorg Heymans wrote: The concept is the following : /trunk pom.xml /cocoon-core /cocoon-forms-block /cocoon-ajax-block /cocoon-asciiart-block ... Please have a look and tell me what you think. IIRC, we already have separated out blocks out of the core, into svn:/cocoon/blocks/ Where each block is treated as independent project, and has own tags/branches. With Cocoon 2.1.8 out this friday, several blocks will start having own tags. Why do you want to reverse this and combine blocks with cocoon core? Vadim
Re: SQL and CTemplate (was Re: [RT] Rules for adding blocks and functionality?)
Upayavira wrote:
Daniel Fagerstrom wrote:
...
Anyway, for the time beeing I think it is better to focus on making it
as easy as possible to use SQL from flowscripts and present the result
sets in CTemplate. Then if we don't get it easy enough we can start to
think about doing part of ESQL in CTemplate.
Whilst I'm not going to be the person implementing it, having seen the
distinction made between SELECT and UPDATE in ESQL/SQLTransformer, I'd
happily see tags added to CTemplate to allow for SQL querying, without
the ability to update/insert.
Surely the main thing about a template is that it is side-effect free,
and that would be.
Maybe better would be some way to separate the SQL from the template.
Imagine:
esql:select name=my-query idEmployee=#{request.getParameters('id')}/
And queries.sql:
my-query: SELECT * FROM Employee WHERE idEmployee = ${idEmployee}
my-other-query: SELECT * FROM Employers
I guess you'd define your queries.sql file in the map:generators
section of your sitemap.
The worst thing about ESQL/SQLTransformer in my view is the embedded
SQL. Horrible.
That require a small string template language for the queries. While it
wouldn't be such a big deal to implement a such labuage I'm not to happy
with having several different template languages with different properties.
I'd rather have a script action that reuse the flow script mechanisms
except for the web continuation, (as Torsten discussed in another
thread). Then we could have some utility functions for making it easy to
create (lazy) query result sets that are embed in some suitable data
structure that make it easy to iterate over it from JXTG.
The script could look like:
// Query script
myResult = executeSelect(SELECT * FROM Employee WHERE idEmployee = ?,
{request.parameter.id});
myOtherResult = executeSelect(SELECT * FROM Employers);
return {myResult: myResult, myOtherResult: myOtherResult};
The return map from the script is supposed to be used with the ordinary
flow attribute mechanism from JXTG.
The template would do an ordinary for each:
jx:for-each select=#{myOtherResult/row}
tr
td#{name}/td
!-- ... --
/tr
/jx:for-each
Simple and respects SoC, IMO.
/Daniel
Re: [RT] Rules for adding blocks and functionality?
Vadim Gritsenko wrote: Daniel Fagerstrom wrote: Now, I find it rather strange to keep the SQLTransformer and ESQL because some people find them being the best way to do simple reporting at the same time as the community strongly oppose building a modern replacement of them in CTemplate, because they represent bad practice. Anyway, for the time beeing I think it is better to focus on making it as easy as possible to use SQL from flowscripts and present the result sets in CTemplate. Then if we don't get it easy enough we can start to think about doing part of ESQL in CTemplate. SQLTransformer has at least three things going for it: * It is declarative, it is not possible to program using JDBC api or some other api in it. Yes, OTH, it start to get clumsy when you need parameters to your queries. And users learn the hard way why updates in the SQLTransformer can be a bad idea. * You can't access result set or statement or connection, you are abstracted from database access code. Yes. * It is scalable, it does not buffer complete result set in memory. IIRC, Ibatis and maybe other light weight JDBC embedings, provide lazy result sets, so by using such a library you can use a action script and JXTG combo without needing to buffer complete result sets. These all are good things (dunno how things in ESQL - have not looked into it), and better than passing JDBC result set into the CTemplate. Agree. My intesion wasn't to leave users with raw JDBC but to embed it with some utility functions that makes it easy to use. If you are interested in building a modern replacement for it, please go ahead: propose a solution using CTemplate or Flow/CTemplate. I, for one, would like to see a solution which preserves above two points of SQLTransformer and is modern. I'm interested in building a modern replacement, but blocks is higher on my priority list, so don't hold your breath ;) ... Seems to me such solution should have some CTemplate tag (unless it is done in Flow) to query database and return a List type live wrappers around ResultSet with limited functionality which can be iterated over in CTemplate. And regarding pure CTemplate vs Flow+CTemplate: flowless solution has own advantages in pure publishing/reporting environments, and is the closest thing you can have comparing with SQLTransformer. I'd like to see an action script+CTemplate soultiion as scetched in my answer to Upayavira. /Daniel
Re: [M10N] new repo layout
Vadim Gritsenko wrote: IIRC, we already have separated out blocks out of the core, into svn:/cocoon/blocks/ separating meaning to move them to a separate directory ? The flat layout doesn't mean they aren't separated. Where each block is treated as independent project, and has own tags/branches. With Cocoon 2.1.8 out this friday, several blocks will start having own tags. this concept works well with standard maven release management. Why do you want to reverse this and combine blocks with cocoon core? you mean combine them into the same directory ? I'm not sure I'm following you here - can you elaborate a bit ? thanks Jorg
Re: [M10N] new repo layout
Jorg Heymans wrote: Hi all, I've just committed an example of how our repository could be structured to support the ongoing componentization, new (osgi) block structure and M10N. Daniel suggested this flat structure a while ago [0], maven [1] and eclipse [2] use a similar layout. The example is in the whiteboard, under maven2/cocoon-flat-layout. The concept is the following : /trunk pom.xml /cocoon-core /cocoon-forms-block /cocoon-ajax-block /cocoon-asciiart-block /... other blocks /webapp Looks good. -- pom.xml This is essentially just a multi-module pom which acts as the parent of all module poms. modulecocoon-core/module modulecocoon-ajax-block/module modulecocoon-forms-block/module It allows us to define properties and plugins valid for all modules. Child modules can still override if necessary. -- /cocoon-core This is kept as one maven module for now, we can choose to split this up further. I didn't separate this one into api/impl as I wasn't sure if it made sense, but maven-wise it's very easy to do so. -- /cocoon-forms-block, /cocoon-asciiart-block ... All modules that we choose to host and support ourselves land in the repository root. Does the block suffix buy us anything? Everything, core included will be a block. We can either stick to the existing block naming convention or go for a package based approach like eclipse. AFAIU either will do, so we could as well stick with the existing name convention. ... /Daniel
Re: [M10N] new block layout
Jorg Heymans wrote: A standard block layout can look like this : /cocoon-forms-block pom.xml /api pom.xml /impl pom.xml /samples pom.xml -- pom.xml Is a multimodule pom containing modules moduleapi/module moduleimpl/module modulesamples/module /modules as well as the dependencies for the block . dependency groupIdapache-cocoon/groupId artifactIdcocoon-ajax-impl/artifactId version2.2-SNAPSHOT/version /dependency dependency groupIdjakarta-oro/groupId artifactIdjakarta-oro/artifactId version2.0.8/version /dependency . Note: I'm not 100% sure yet about adding all dependencies at this level, this still needs some thought. For now it will do. Would prefer puting API dependencies in the API module and let the impl depend on the api and the samples on the impl. Doesn't the tranistive dependencies work well enough or what is the reasons for having dependencies at parent level? The rest looks good. /Daniel
Re: [M10N] new repo layout
Jorg Heymans wrote: Vadim Gritsenko wrote: IIRC, we already have separated out blocks out of the core, into svn:/cocoon/blocks/ separating meaning to move them to a separate directory ? The flat layout doesn't mean they aren't separated. Separating meaning they are separate projects with independent release cycles, as in: Where each block is treated as independent project, and has own tags/branches. With Cocoon 2.1.8 out this friday, several blocks will start having own tags. this concept works well with standard maven release management. Why do you want to reverse this and combine blocks with cocoon core? you mean combine them into the same directory ? I'm not sure I'm following you here - can you elaborate a bit ? Yes, I mean why do you want to combine multiple projects into single uber project, in your proposed directory structure: /trunk /block-a /block-b Instead of having them as independent projects, as of now: /trunk /core /blocks /a /trunk /b /trunk It seems like a step backward, towards 2.1 situation, where each block is part of single project, instead of moving forward and cutting blocks loose... Vadim
Re: [M10N] new repo layout
Vadim Gritsenko wrote: Jorg Heymans wrote: The concept is the following : /trunk pom.xml /cocoon-core /cocoon-forms-block /cocoon-ajax-block /cocoon-asciiart-block ... Please have a look and tell me what you think. IIRC, we already have separated out blocks out of the core, into svn:/cocoon/blocks/ Where each block is treated as independent project, and has own tags/branches. With Cocoon 2.1.8 out this friday, several blocks will start having own tags. The current structure with trunk/tags/branches under each block will become rather unconvenient as soon as we start to relase and tag things. Right now you can just check out svn:/cocoon/blocks without any problems, but with a number of tags for each blocks you soon get quite a lot to check out, then you either need to check out each blocks/name/trunk separately or we have to provide a directory with externals to each block trunk. But that was extremely slow when we tried that a while ago. Read the links in http://marc.theaimsgroup.com/?l=xml-cocoon-devm=112790057318179w=2 for description of a better way to solve it. Why do you want to reverse this and combine blocks with cocoon core? It doesn't reverese anything, all blocks under /trunk will be independent projects, their interdependencies are completely described in the respective POMs. /Daniel
Update Jtidy
Hello, FYI we had to update jtidy in our project to see an HTML parsing bug fixed. We used this: http://jtidy.sourceforge.net/nightly/jtidy-r8-SNAPSHOT.zip This version was last updated in september 2004. Best regards, -- Jean-Baptiste Quenot Systèmes d'Information ANYWARE TECHNOLOGIES Tel : +33 (0)5 61 00 52 90 Fax : +33 (0)5 61 00 51 46 http://www.anyware-tech.com/
[jira] Created: (COCOON-1677) jx macros output extra whitespace
jx macros output extra whitespace - Key: COCOON-1677 URL: http://issues.apache.org/jira/browse/COCOON-1677 Project: Cocoon Type: Bug Components: Blocks: Forms Versions: 2.1.8-dev (Current SVN) Reporter: Jean-Baptiste Quenot This is the JX template: page xmlns:jx=http://apache.org/cocoon/templates/jx/1.0; jx:import uri=resource://org/apache/cocoon/forms/generation/jx-macros.xml/ ft:form-template (ft:widget id=mywidget/) /ft:form-template /page The ft:widget macro outputs extra whitespace, which is not desirable and a major issue for our picky customers ;) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (COCOON-1677) jx macros output extra whitespace
[ http://issues.apache.org/jira/browse/COCOON-1677?page=comments#action_12356714 ] Mark Lundquist commented on COCOON-1677: cf. Issue 1381 (http://issues.apache.org/jira/browse/COCOON-1381)... this is probably the same thing. BTW, how do you cross-reference issues in JIRA comments? Bugzilla had some magic syntax for that... jx macros output extra whitespace - Key: COCOON-1677 URL: http://issues.apache.org/jira/browse/COCOON-1677 Project: Cocoon Type: Bug Components: Blocks: Forms Versions: 2.1.8-dev (Current SVN) Reporter: Jean-Baptiste Quenot This is the JX template: page xmlns:jx=http://apache.org/cocoon/templates/jx/1.0; jx:import uri=resource://org/apache/cocoon/forms/generation/jx-macros.xml/ ft:form-template (ft:widget id=mywidget/) /ft:form-template /page The ft:widget macro outputs extra whitespace, which is not desirable and a major issue for our picky customers ;) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (COCOON-1629) No default value in forms binding
[
http://issues.apache.org/jira/browse/COCOON-1629?page=comments#action_12356713
]
Jean-Baptiste Quenot commented on COCOON-1629:
--
No, initial-value attribute does not work, neither as child
element.
No default value in forms binding
-
Key: COCOON-1629
URL: http://issues.apache.org/jira/browse/COCOON-1629
Project: Cocoon
Type: Improvement
Components: Blocks: Forms
Versions: 2.1.8-dev (Current SVN)
Environment: Operating System: other
Platform: Other
Reporter: Jean-Baptiste Quenot
Assignee: Cocoon Developers Team
Priority: Minor
When wishing to have a default value for the binding of a form widget, it is
required to make use of a hack like this:
for (var iter = form.form.getChildren() ;
iter.hasNext() ;) {
var child = iter.next();
if
(child.getClass().getName().equals(org.apache.cocoon.forms.formmodel.Field)
child.getDatatype().getTypeClass().getName().equals(java.lang.Long)
child.getValue() == null) {
child.setValue(new java.lang.Long(-1));
}
}
It would be great to add an attribute on fd:datatype, for example:
fd:datatype base=long default=-1 to have a default value that could be
used in the binding.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Closed: (COCOON-1677) jx macros output extra whitespace
[ http://issues.apache.org/jira/browse/COCOON-1677?page=all ] Jean-Baptiste Quenot closed COCOON-1677: Resolution: Duplicate Same as COCOON-1381 jx macros output extra whitespace - Key: COCOON-1677 URL: http://issues.apache.org/jira/browse/COCOON-1677 Project: Cocoon Type: Bug Components: Blocks: Forms Versions: 2.1.8-dev (Current SVN) Reporter: Jean-Baptiste Quenot This is the JX template: page xmlns:jx=http://apache.org/cocoon/templates/jx/1.0; jx:import uri=resource://org/apache/cocoon/forms/generation/jx-macros.xml/ ft:form-template (ft:widget id=mywidget/) /ft:form-template /page The ft:widget macro outputs extra whitespace, which is not desirable and a major issue for our picky customers ;) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [M10N] new block layout
Daniel Fagerstrom wrote: Jorg Heymans wrote: A standard block layout can look like this : /cocoon-forms-block pom.xml /api pom.xml /impl pom.xml /samples pom.xml -- pom.xml Is a multimodule pom containing modules moduleapi/module moduleimpl/module modulesamples/module /modules as well as the dependencies for the block . dependency groupIdapache-cocoon/groupId artifactIdcocoon-ajax-impl/artifactId version2.2-SNAPSHOT/version /dependency dependency groupIdjakarta-oro/groupId artifactIdjakarta-oro/artifactId version2.0.8/version /dependency . Note: I'm not 100% sure yet about adding all dependencies at this level, this still needs some thought. For now it will do. Would prefer puting API dependencies in the API module and let the impl depend on the api and the samples on the impl. Doesn't the tranistive dependencies work well enough or what is the reasons for having dependencies at parent level? If you take everything into account, both API and implementation can have their own dependencies, e.g.: * B (API) depends on A (API) * C (impl of A) depends on A (API) * D (impl of B) depends on B (API) * D (impl of B) depends on C (impl of A) or better readable with a bit of ASCII art: API: [ A ] --- [ B ] ^ ^ | | Impl: [ C ] --- [ D ] But as Daniel already mentioned, it looks good! Andreas
Re: [M10N] new repo layout
Daniel Fagerstrom wrote: The current structure with trunk/tags/branches under each block will become rather unconvenient as soon as we start to relase and tag things. Right now you can just check out svn:/cocoon/blocks without any problems, but with a number of tags for each blocks you soon get quite a lot to check out, then you either need to check out each blocks/name/trunk separately or we have to provide a directory with externals to each block trunk. But that was extremely slow when we tried that a while ago. Read the links in http://marc.theaimsgroup.com/?l=xml-cocoon-devm=112790057318179w=2 for description of a better way to solve it. I agree with your proposal. When I had choose a layout during converting our CVS repository to Subversion I tried hard to find the layout which best fits our needs. The most significant argument was, that if you choose the layout with trunk/tags/branches below every module you have to rename the directory every time you do a checkout (e.g. .../cocoon/trunk has to be checked out as cocoon). You don't have the convention anymore that checked-out directory names are identical with the ones in the repository. If you do it the other way round (.../trunk/cocoon) your life is much easier (simply 'Checkout as Project' works again in Eclipse ;-). Additionally you gain another benefit: If you want to release multiple modules together you can put the tags for multiple modules under .../tags/tagname/modulename. This is not (easily) possible, if every module has it's own trunk/tags/branches directory. Some (badly) written build scripts in other projects even depend on the correct directory name of their submodules... Andreas
commons-lang-2.1
Hi, I have an existing Cocoon 2.1.7-based project in which I would like to upgrade Commons Lang to 2.1, and I'd like to make sure that won't cause any problems for Cocoon. Were any source changes required for Commons Lang 2.1 in BRANCH_2_1_X? Thanks, Mark
[EMAIL PROTECTED]: Project cocoon (in module cocoon) failed
To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at [EMAIL PROTECTED] Project cocoon has an issue affecting its community integration. This issue affects 57 projects. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - cocoon : Java XML Framework - cocoon-block-ajax : Ajax - Utilities and resources for Ajax applications. - cocoon-block-apples : Java XML Framework - cocoon-block-asciiart : Java XML Framework - cocoon-block-authentication-fw : Java XML Framework - cocoon-block-axis : Java XML Framework - cocoon-block-batik : Java XML Framework - cocoon-block-bsf : Java XML Framework - cocoon-block-captcha : Utilites to generate simple CAPTCHAs - cocoon-block-chaperon : Java XML Framework - cocoon-block-core-samples-additional : Additional core samples. - cocoon-block-core-samples-main : Main core samples. - cocoon-block-cron : Java XML Framework - cocoon-block-databases : Java XML Framework - cocoon-block-deli : Java XML Framework - cocoon-block-eventcache : Java XML Framework - cocoon-block-fop : Java XML Framework - cocoon-block-forms : Java XML Framework - cocoon-block-hsqldb : Java XML Framework - cocoon-block-html : Java XML Framework - cocoon-block-itext : Java XML Framework - cocoon-block-javaflow : Java XML Framework - cocoon-block-jcr : A jcr: protocol for Cocoon - cocoon-block-jfor : Java XML Framework - cocoon-block-jms : Java XML Framework - cocoon-block-jsp : Java XML Framework - cocoon-block-linkrewriter : Java XML Framework - cocoon-block-lucene : Java XML Framework - cocoon-block-midi : Java XML Framework - cocoon-block-naming : Java XML Framework - cocoon-block-ojb : Java XML Framework - cocoon-block-paranoid : Java XML Framework - cocoon-block-petstore : Java XML Framework - cocoon-block-portal : Java XML Framework - cocoon-block-portal-sample : Java XML Framework - cocoon-block-profiler : Java XML Framework - cocoon-block-proxy : Java XML Framework - cocoon-block-python : Java XML Framework - cocoon-block-qdox : Java XML Framework - cocoon-block-querybean : Java XML Framework - cocoon-block-repository : Java XML Framework - cocoon-block-serializers : Java XML Framework - cocoon-block-session-fw : Java XML Framework - cocoon-block-slop : Java XML Framework - cocoon-block-spring-app : A demo for Spring and Cocoon - cocoon-block-stx : Java XML Framework - cocoon-block-taglib : Java XML Framework - cocoon-block-template : Java XML Framework - cocoon-block-tour : Java XML Framework - cocoon-block-validation : In-pipeline validation of documents - cocoon-block-velocity : Java XML Framework - cocoon-block-web3 : Java XML Framework - cocoon-block-xmldb : Java XML Framework - cocoon-block-xsp : Java XML Framework - forrest : Apache Forrest is an XML standards-oriented documentation fr... - forrest-test : Apache Forrest is an XML standards-oriented documentation fr... - lenya : Content Management System Full details are available at: http://vmgump.apache.org/gump/public/cocoon/cocoon/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Output [cocoon.jar] identifier set to output basename: [cocoon] -DEBUG- Output [cocoon-testcase.jar] identifier set to output basename: [cocoon-testcase] -DEBUG- Output [cocoon-deprecated.jar] identifier set to output basename: [cocoon-deprecated] -INFO- Made directory [/usr/local/gump/public/workspace/cocoon/build/cocoon-03112005/test] -INFO- Failed with reason build failed -INFO- Project Reports in: /usr/local/gump/public/workspace/cocoon/build/cocoon-03112005/test/output -WARNING- No directory [/usr/local/gump/public/workspace/cocoon/build/cocoon-03112005/test/output] -INFO- Failed to extract fallback artifacts from Gump Repository The following work was performed: http://vmgump.apache.org/gump/public/cocoon/cocoon/gump_work/build_cocoon_cocoon.html Work Name: build_cocoon_cocoon (Type: Build) Work ended in a state of : Failed Elapsed: 17 secs Command Line: java -Djava.awt.headless=true -Xbootclasspath/p:/usr/local/gump/public/workspace/xml-commons/java/external/build/xml-apis.jar:/usr/local/gump/public/workspace/xml-xerces2/java/build/xercesImpl.jar org.apache.tools.ant.Main -Dgump.merge=/x1/gump/public/gump/work/merge.xml -Dbuild.sysclasspath=only -Dlogkit.jar=/usr/local/gump/public/workspace/avalon-trunk/runtime/logkit/target/deliverables/jars/avalon-logkit-03112005.jar -Dbuild=build/cocoon-03112005 gump-core [Working
[EMAIL PROTECTED]: Project cocoon (in module cocoon) failed
To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at [EMAIL PROTECTED] Project cocoon has an issue affecting its community integration. This issue affects 57 projects. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - cocoon : Java XML Framework - cocoon-block-ajax : Ajax - Utilities and resources for Ajax applications. - cocoon-block-apples : Java XML Framework - cocoon-block-asciiart : Java XML Framework - cocoon-block-authentication-fw : Java XML Framework - cocoon-block-axis : Java XML Framework - cocoon-block-batik : Java XML Framework - cocoon-block-bsf : Java XML Framework - cocoon-block-captcha : Utilites to generate simple CAPTCHAs - cocoon-block-chaperon : Java XML Framework - cocoon-block-core-samples-additional : Additional core samples. - cocoon-block-core-samples-main : Main core samples. - cocoon-block-cron : Java XML Framework - cocoon-block-databases : Java XML Framework - cocoon-block-deli : Java XML Framework - cocoon-block-eventcache : Java XML Framework - cocoon-block-fop : Java XML Framework - cocoon-block-forms : Java XML Framework - cocoon-block-hsqldb : Java XML Framework - cocoon-block-html : Java XML Framework - cocoon-block-itext : Java XML Framework - cocoon-block-javaflow : Java XML Framework - cocoon-block-jcr : A jcr: protocol for Cocoon - cocoon-block-jfor : Java XML Framework - cocoon-block-jms : Java XML Framework - cocoon-block-jsp : Java XML Framework - cocoon-block-linkrewriter : Java XML Framework - cocoon-block-lucene : Java XML Framework - cocoon-block-midi : Java XML Framework - cocoon-block-naming : Java XML Framework - cocoon-block-ojb : Java XML Framework - cocoon-block-paranoid : Java XML Framework - cocoon-block-petstore : Java XML Framework - cocoon-block-portal : Java XML Framework - cocoon-block-portal-sample : Java XML Framework - cocoon-block-profiler : Java XML Framework - cocoon-block-proxy : Java XML Framework - cocoon-block-python : Java XML Framework - cocoon-block-qdox : Java XML Framework - cocoon-block-querybean : Java XML Framework - cocoon-block-repository : Java XML Framework - cocoon-block-serializers : Java XML Framework - cocoon-block-session-fw : Java XML Framework - cocoon-block-slop : Java XML Framework - cocoon-block-spring-app : A demo for Spring and Cocoon - cocoon-block-stx : Java XML Framework - cocoon-block-taglib : Java XML Framework - cocoon-block-template : Java XML Framework - cocoon-block-tour : Java XML Framework - cocoon-block-validation : In-pipeline validation of documents - cocoon-block-velocity : Java XML Framework - cocoon-block-web3 : Java XML Framework - cocoon-block-xmldb : Java XML Framework - cocoon-block-xsp : Java XML Framework - forrest : Apache Forrest is an XML standards-oriented documentation fr... - forrest-test : Apache Forrest is an XML standards-oriented documentation fr... - lenya : Content Management System Full details are available at: http://vmgump.apache.org/gump/public/cocoon/cocoon/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Output [cocoon.jar] identifier set to output basename: [cocoon] -DEBUG- Output [cocoon-testcase.jar] identifier set to output basename: [cocoon-testcase] -DEBUG- Output [cocoon-deprecated.jar] identifier set to output basename: [cocoon-deprecated] -INFO- Made directory [/usr/local/gump/public/workspace/cocoon/build/cocoon-03112005/test] -INFO- Failed with reason build failed -INFO- Project Reports in: /usr/local/gump/public/workspace/cocoon/build/cocoon-03112005/test/output -WARNING- No directory [/usr/local/gump/public/workspace/cocoon/build/cocoon-03112005/test/output] -INFO- Failed to extract fallback artifacts from Gump Repository The following work was performed: http://vmgump.apache.org/gump/public/cocoon/cocoon/gump_work/build_cocoon_cocoon.html Work Name: build_cocoon_cocoon (Type: Build) Work ended in a state of : Failed Elapsed: 17 secs Command Line: java -Djava.awt.headless=true -Xbootclasspath/p:/usr/local/gump/public/workspace/xml-commons/java/external/build/xml-apis.jar:/usr/local/gump/public/workspace/xml-xerces2/java/build/xercesImpl.jar org.apache.tools.ant.Main -Dgump.merge=/x1/gump/public/gump/work/merge.xml -Dbuild.sysclasspath=only -Dlogkit.jar=/usr/local/gump/public/workspace/avalon-trunk/runtime/logkit/target/deliverables/jars/avalon-logkit-03112005.jar -Dbuild=build/cocoon-03112005 gump-core [Working
Re: commons-lang-2.1
Mark Lundquist wrote: Hi, I have an existing Cocoon 2.1.7-based project in which I would like to upgrade Commons Lang to 2.1, and I'd like to make sure that won't cause any problems for Cocoon. Were any source changes required for Commons Lang 2.1 in BRANCH_2_1_X? The safest way to know that is to recompile your Cocoon with commons-lang 2.1 and see if any compilation errors pop up. Sylvain -- Sylvain WallezAnyware Technologies http://people.apache.org/~sylvain http://www.anyware-tech.com Apache Software Foundation Member Research Technology Director
Re: [Vote] Releasing on friday
On 03.11.2005 06:47, Carsten Ziegeler wrote: Please cast your votes for releasing 2.1.8 on friday, 4th of November. +0 Too much to do at the moment to test Cocoon. I'm just reading the lists at the moment. And from those I don't have the best feelings about the latest changes. Jörg
Re: [M10N] new repo layout
Vadim Gritsenko wrote: Separating meaning they are separate projects with independent release cycles, as in: Where each block is treated as independent project, and has own tags/branches. With Cocoon 2.1.8 out this friday, several blocks will start having own tags. Perfect, my proposed layout covers this use case. Each block will have its own release cycle, we can even use the maven release plugin to do releases. I will experiment with this in the mini repo and document my findings. Yes, I mean why do you want to combine multiple projects into single uber project, in your proposed directory structure: /trunk /block-a /block-b ... It seems like a step backward, towards 2.1 situation, where each block is part of single project, instead of moving forward and cutting blocks loose... The single root pom has no meaning other than tying the other modules together and giving us the possibility of a) defining common stuff and b) being able to do a full build/release/deploy of all modules with one command. It does not prevent separate release cycles of the individual modules however. Regards, Jorg
Re: [M10N] new repo layout
Daniel Fagerstrom wrote: -- /cocoon-forms-block, /cocoon-asciiart-block ... All modules that we choose to host and support ourselves land in the repository root. Does the block suffix buy us anything? Everything, core included will be a block. if anything the suffix could be something that people switching from 2.1.x can relate to - other than that I don't see any real benefits. I'll drop the suffix if people are ok with this. We can either stick to the existing block naming convention or go for a package based approach like eclipse. AFAIU either will do, so we could as well stick with the existing name convention. ok. Jorg
Re: [M10N] new block layout
Daniel Fagerstrom wrote: Would prefer puting API dependencies in the API module and let the impl depend on the api and the samples on the impl. Doesn't the tranistive dependencies work well enough or what is the reasons for having dependencies at parent level? Well i figured it would buy us a cleaner way of defining dependencies, i now see I was wrong. Looking at Andreas' diagram, it's clear that we have to put API deps in the api pom and let the implementations care about their own dependencies - this way you wouldn't have to exclude unnecessary libs from impl1 in impl2 manually. What if there is no real need for an api block? Do we still add it and define for example the cocoon-core dependency there or do we leave it out alltogether ? Andreas Hochsteger wrote: If you take everything into account, both API and implementation can have their own dependencies, e.g.: * B (API) depends on A (API) wow, multiple APIs in one block ? * C (impl of A) depends on A (API) * D (impl of B) depends on B (API) * D (impl of B) depends on C (impl of A) correct, albeit theoretically. I hope we won't need this level of inheritance for our blocks. or better readable with a bit of ASCII art: API: [ A ] --- [ B ] ^ ^ | | Impl: [ C ] --- [ D ] Nice ! Thanks for your feedback. Jorg
Re: [M10N] new block layout
Jorg Heymans wrote: Andreas Hochsteger wrote: If you take everything into account, both API and implementation can have their own dependencies, e.g.: * B (API) depends on A (API) wow, multiple APIs in one block ? Actually I meant A through D to be blocks, where the blocks A and B just define APIs and blocks C and D just implement those APIs. But of course (theoretically) it could all happen in one block too :-). * C (impl of A) depends on A (API) * D (impl of B) depends on B (API) * D (impl of B) depends on C (impl of A) correct, albeit theoretically. I hope we won't need this level of inheritance for our blocks. I don't think that this is just theoretically but rather common practice (see my clarifications from above). or better readable with a bit of ASCII art: API: [ A ] --- [ B ] ^ ^ | | Impl: [ C ] --- [ D ] Nice ! Thanks for your feedback. Jorg Andreas
Re: [Vote] Releasing on friday
Sylvain Wallez wrote: Upayavira wrote: Incidentally, I'm +1 on Sylvain's proposed changes to element id generation strategy. My question before voting is how have you gone about identifying that a colon is a valid character within ids in all browsers? I checked the XML specification: http://www.w3.org/TR/REC-xml/#id Good point, but it does not answer the Upayavira question. :-) Best Regards, Antonio Gallardo.
Re: CForms widget ID naming (was Re: [Vote] Releasing on friday)
Sylvain Wallez wrote: Carsten Ziegeler wrote: Sylvain Wallez wrote: This usage in CForms has already been introduced by the recent library stuff, which associates prefixes to libraries, thus effectively forbidding the use of : in widget ids (otherwise you cannot differenciate between a widget name and a composite name that references a library widget). That is why I chose this character. The / and . are also forbidden (used for lookup paths). The . cannot be used as it is used to combine widget names in the generated IDs, and thus would lead to a similar problem as the current one: - can conflict with siblings, and . can conflict with children. Do we already validate a widget id if it does not contain all of these forbidden characters? If not, we really should check this and throw an exception when the model is read. Early failing is better than unpredictable results later on. Yep. The . and / are already checked in AbstractWidgetDefinition.setCommonProperties(). We just need to add :. BTW, I'm ready to commit the updated stylesheets, which I tested on IE 6, Firefox and Safari. Why we need to use a symbol at any cost ? Can we use a simple word prefix? As cform-[widgetID]? I was not on GT2005, but I hear a lot about conventions was there. I think this is good. Then let's define a fixed prefix name for cforms names, declare it as a cocoon keyword. KISS rules! ;-) WDYT? Best Regards, Antonio Gallardo.
Re: [M10N] new repo layout
Daniel Fagerstrom wrote: Vadim Gritsenko wrote: IIRC, we already have separated out blocks out of the core, into svn:/cocoon/blocks/ Where each block is treated as independent project, and has own tags/branches. With Cocoon 2.1.8 out this friday, several blocks will start having own tags. The current structure with trunk/tags/branches under each block will become rather unconvenient as soon as we start to relase and tag things. I would say unavoidable rather than inconvenient. Where would you put block's tags if not under the tags, then? Right now you can just check out svn:/cocoon/blocks without any problems, but with a number of tags for each blocks you soon get quite a lot to check out, then you either need to check out each blocks/name/trunk separately or we have to provide a directory with externals to each block trunk. But that was extremely slow when we tried that a while ago. Yes. That was the known issue (iirc i myself brought this up back then), and back then it was recognized that svn:externals is only a temporary measure. Having one external per block is too slow, and having one external for all blocks is not possible, so IMHO best way is to write simple sh/bat file for checking out trunks of all blocks into pre-defined directory structure. Even better if maven somehow can help out here... Either through standard tools or custom plugin... Read the links in http://marc.theaimsgroup.com/?l=xml-cocoon-devm=112790057318179w=2 for description of a better way to solve it. It essentially proposes [1] to move ttb's up one level. something like /trunk /cocoon /blocks /axis /forms /tags /cocoon-2.1.8 /cocoon-axis-1.0 /cocoon-forms-1.0 /branches /cocoon-2.1 ... (note: 'releases' in [1] is 'tags' here) Why do you think that this structure should work better? I would think that it is much easier to use standard ttb layout and let m2 handle each block as separate project, rather than building non standard layout. If I am not mistaken, following should work with m2 right away: /cocoon-core /trunk pom.xml /cocoon-blocks-axis /trunk pom.xml /cocoon-blocks-forms /trunk pom.xml /cocoon-standard /trunk pom.xml (references cocoon-core, cocoon-forms, cocoon-template) /cocoon /trunk pom.xml (references all blocks) So, what do I miss? Why do you want to reverse this and combine blocks with cocoon core? It doesn't reverese anything, all blocks under /trunk will be independent projects, their interdependencies are completely described in the respective POMs. Where tags and brnaches will live? Vadim [1] http://marc.theaimsgroup.com/?l=xml-cocoon-devm=112772867005578
Re: [M10N] new repo layout
Jorg Heymans wrote: Vadim Gritsenko wrote: Where each block is treated as independent project, and has own tags/branches. With Cocoon 2.1.8 out this friday, several blocks will start having own tags. Perfect, my proposed layout covers this use case. Each block will have its own release cycle, we can even use the maven release plugin to do releases. I will experiment with this in the mini repo and document my findings. I must be stupid. I re-read it [1] twice but still don't see where tags and branches live. :-( ... It seems like a step backward, towards 2.1 situation, where each block is part of single project, instead of moving forward and cutting blocks loose... The single root pom has no meaning other than tying the other modules together and giving us the possibility of a) defining common stuff and b) being able to do a full build/release/deploy of all modules with one command. It does not prevent separate release cycles of the individual modules however. See [2], IMHO all this can be handled better by 'cocoon-complete', or 'cocoon-with-all-blocks-included' m2 project. Vadim [1] http://marc.theaimsgroup.com/?l=xml-cocoon-devm=113102793729171 [2] http://marc.theaimsgroup.com/?l=xml-cocoon-devm=113107109911046
Cocooners in Shanghai?
Hi, as I'm currently staying in Shanghai, I was wondering if there are any Cocooners here who are interested in meeting up somewhere? So if you're interested in talking about Cocoon, Open Source and related topics just drop me a line :-) -- * best regards * Jens Maukisch
Re: [M10N] new block layout
Jorg Heymans wrote: What if there is no real need for an api block? Do we still add it and define for example the cocoon-core dependency there or do we leave it out alltogether ? I would lead it out altogether. Leaving it in kind of implies that there should be an api and will probably just confuse people. BTW - I'm +1 on your proposal. Ralph
Re: CForms widget ID naming (was Re: [Vote] Releasing on friday)
On 04.11.2005 02:09, Antonio Gallardo wrote: Yep. The . and / are already checked in AbstractWidgetDefinition.setCommonProperties(). We just need to add :. Why we need to use a symbol at any cost ? Can we use a simple word prefix? As cform-[widgetID]? If you prefix the widget id with a simple word (your proposal) or suffix it with another one (Sylvain's way), with both you have to care about the validness of user-chosen ids. To check them easily you use the unique separator. Jörg
Re: CForms widget ID naming (was Re: [Vote] Releasing on friday)
Joerg Heinicke wrote: On 04.11.2005 02:09, Antonio Gallardo wrote: Yep. The . and / are already checked in AbstractWidgetDefinition.setCommonProperties(). We just need to add :. Why we need to use a symbol at any cost ? Can we use a simple word prefix? As cform-[widgetID]? If you prefix the widget id with a simple word (your proposal) or suffix it with another one (Sylvain's way), with both you have to care about the validness of user-chosen ids. To check them easily you use the unique separator. Agreed. I think checking a prefix is often faster than checking a suffix in a string. On the other side a prefix can rest code readibility. IMHO, the first is better for generated (X)HTML code. The suffix is also ok. The problem was that a -input suffix is too generic and seems to broke some javascript code somewhere. ajax is the main reason for change? If yes, then we can use -cf-input as the suffix or something like that. I am just afraid of adding a : in the name. Maybe does not make sense. Here are some points: 1-It can breaks compatibility somewhere. As sample, all browsers claims to support CSS standards. The point is at wich level and how they interpret the word support. 2-Being in a xpath 1.0 namespace nightmare for months. I am not sure if suddenly somebody will need to give a meaning to the :. I know it is very remote, but... For the records, I don't have any javascript that need to be reviewed if we change this behavior. It is just a technical comment. Best Regards, Antonio Gallardo.
Vote Result: Releasing 2.1.8 today [was: [Vote] Releasing on friday]
To be honest I'm not really happy about this vote: I counted only four votes! I'm still trying to figure out what this result means to us? Anyway, I counted two +1's, one +0.5, one -0.5 and some reservations for releasing today. My decision is to not release today, sorry, but imho there are not enough votes. I'll start another vote on monday for releasing tuesday. Carsten -- Carsten Ziegeler - Open Source Group, SN AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Re: Vote Result: Releasing 2.1.8 today [was: [Vote] Releasing on friday]
On 04.11.2005, at 08:30, Carsten Ziegeler wrote: To be honest I'm not really happy about this vote: I counted only four votes! I'm still trying to figure out what this result means to us? I suspect it means I haven't tested enough to be confident so I don't know. Have all reported issues really been addressed? I'd see them as a +/-0 cheers -- Torsten - who will try to do some testing over the weekend PGP.sig Description: This is a digitally signed message part
