[jira] Updated: (COCOON-2133) Addition of allow-enlarge parameter to ImageOp resize operation
[ https://issues.apache.org/jira/browse/COCOON-2133?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robin Wyles updated COCOON-2133: Attachment: RevisedResizeOperationPatch.txt Revised patch that fixes a bug with the previous patch where scaling with allowEnlarge property would be ignored when only one dimension needs to be reduced in size. Addition of allow-enlarge parameter to ImageOp resize operation - Key: COCOON-2133 URL: https://issues.apache.org/jira/browse/COCOON-2133 Project: Cocoon Issue Type: Improvement Components: Blocks: ImageOp Affects Versions: 2.1.11, 2.2-dev (Current SVN) Reporter: Robin Wyles Priority: Minor Attachments: ResizeOperation.patch, RevisedResizeOperationPatch.txt The addition of an allow-enlarge parameter to the resize operation allows the user to control whether an image should be enlarged by the operation. This new parameter is declared in the sitemap like so: map:read type=imageop src=image.jpg map:parameter name=prefix-preserve-ratio value=true/ map:parameter name=prefix-allow-enlarge value=false/ map:parameter name=prefix-width value=320/ map:parameter name=prefix-height value=240/ /map:read -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COCOON-2133) Addition of allow-enlarge parameter to ImageOp resize operation
[ https://issues.apache.org/jira/browse/COCOON-2133?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12555291#action_12555291 ] Robin Wyles commented on COCOON-2133: - I'd be happy to provide a test-case but I can't see how to set one up to test a Reader. Looking at SitemapComponentTestCase I don't see a corresponding read method and I can't find any test-cases for other readers in any other blocks. If you can let me know how I might implement this test-case then I'll write it. In the meantime I attach a revised patch that fixes a bug with the previous patch where scaling with allowEnlarge property would be ignored when only one dimension needs to be reduced in size. Addition of allow-enlarge parameter to ImageOp resize operation - Key: COCOON-2133 URL: https://issues.apache.org/jira/browse/COCOON-2133 Project: Cocoon Issue Type: Improvement Components: Blocks: ImageOp Affects Versions: 2.1.11, 2.2-dev (Current SVN) Reporter: Robin Wyles Priority: Minor Attachments: ResizeOperation.patch, RevisedResizeOperationPatch.txt The addition of an allow-enlarge parameter to the resize operation allows the user to control whether an image should be enlarged by the operation. This new parameter is declared in the sitemap like so: map:read type=imageop src=image.jpg map:parameter name=prefix-preserve-ratio value=true/ map:parameter name=prefix-allow-enlarge value=false/ map:parameter name=prefix-width value=320/ map:parameter name=prefix-height value=240/ /map:read -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (COCOON-2052) Allow Ajax submission of forms with empty upload field
[ https://issues.apache.org/jira/browse/COCOON-2052?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robin Wyles updated COCOON-2052: Attachment: C2.2-AjaxForm-upload-patch.txt Patch for 2.2-dev Allow Ajax submission of forms with empty upload field -- Key: COCOON-2052 URL: https://issues.apache.org/jira/browse/COCOON-2052 Project: Cocoon Issue Type: Improvement Components: Blocks: Forms Affects Versions: 2.1.11 Reporter: Robin Wyles Priority: Minor Fix For: 2.1.11 Attachments: AjaxForm-upload-patch.txt, C2.2-AjaxForm-upload-patch.txt Currently AjaxForm.js disables Ajax if the form contains an active upload field regardless of whether it contains a value or not. This simple patch only disables Ajax if the upload field is active and has a value. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (COCOON-2052) Allow Ajax submission of forms with empty upload field
[ https://issues.apache.org/jira/browse/COCOON-2052?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robin Wyles updated COCOON-2052: Fix Version/s: 2.2-dev (Current SVN) Affects Version/s: 2.2-dev (Current SVN) Allow Ajax submission of forms with empty upload field -- Key: COCOON-2052 URL: https://issues.apache.org/jira/browse/COCOON-2052 Project: Cocoon Issue Type: Improvement Components: Blocks: Forms Affects Versions: 2.1.11, 2.2-dev (Current SVN) Reporter: Robin Wyles Priority: Minor Fix For: 2.1.11, 2.2-dev (Current SVN) Attachments: AjaxForm-upload-patch.txt, C2.2-AjaxForm-upload-patch.txt Currently AjaxForm.js disables Ajax if the form contains an active upload field regardless of whether it contains a value or not. This simple patch only disables Ajax if the upload field is active and has a value. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Repository block and C2.2
Hi, I would like to use the Repository block with C2.2, but I see from the Cocoon site that it is not yet ready for release. I'd be happy to have a go at updating this block for use with C2.2 if someone could tell me the following... 1. Is this welcome/necessary? 2. What do I need to do to get this block ready for release? 3. Any documentation on upgrading blocks to C2.2? Thanks, Robin smime.p7s Description: S/MIME cryptographic signature
Re: Repository block and C2.2
Robin Wyles pisze: Hi, Hi Robin, I would like to use the Repository block with C2.2, but I see from the Cocoon site that it is not yet ready for release. I'd be happy to have a go at updating this block for use with C2.2 if someone could tell me the following... Although I haven't used repository myself but I will try to help you a bit. 1. Is this welcome/necessary? Of course it is welcomed. 2. What do I need to do to get this block ready for release? Main requirement for any release is to have no dependencies on a snapshot versions on artifacts. I don't know much about repository block so you might check it. For a first milestone release I don't think expectations should be set high so I think it's enough to set up some minimal docs and have some code working. :) For final I would like to see some samples (repository block lacks any) and at least minimal coverage by tests. 3. Any documentation on upgrading blocks to C2.2? I fear there is nothing like that but this is caused mainly because trunk has been changing many times until it stabilized now. Moreover, it is quite hard to provide general enough documentation of a process that itself is rather non-trivial. I don't want you to get an impression that you are aiming at a dead-complicated task... Ok, enough of excuse. I just have taken a quick look at repository block and it seems that there are only few issues: a) there are no configuration files of sitemap components provided by repository block. In a C2.2 advised method is to configure them *outside* the sitemap. See this[1] file to get an idea how it should look like. b) there is old file containing configuration of caching source. This source has been refactored and moved to the core so this configuration is not needed anymore. I think that the best strategy would be to create configuration of sitemap components in order to get them running then try to run rest of components. I guess it's not that much work left in order to prepare first milestone release of repository block but having even few samples would be highly appreciated. [1] http://svn.apache.org/repos/asf/cocoon/trunk/core/cocoon-core/src/main/resources/META-INF/cocoon/avalon/cocoon-core-sitemapcomponents.xconf -- Grzegorz Kossakowski
Re: Repository block and C2.2
Hi Grzegorz, On 2 Jan 2008, at 15:15, Grzegorz Kossakowski wrote: Robin Wyles pisze: Hi, Hi Robin, I would like to use the Repository block with C2.2, but I see from the Cocoon site that it is not yet ready for release. I'd be happy to have a go at updating this block for use with C2.2 if someone could tell me the following... Although I haven't used repository myself but I will try to help you a bit. Neither have I yet, so I'm sure this will get me well acquainted with it! 1. Is this welcome/necessary? Of course it is welcomed. 2. What do I need to do to get this block ready for release? Main requirement for any release is to have no dependencies on a snapshot versions on artifacts. I don't know much about repository block so you might check it. Looking at the pom I don't see any version numbers, but the dependencies seem to be: cocoon-core cocoon-eventcache-impl excalibur-datasource servlet-api For a first milestone release I don't think expectations should be set high so I think it's enough to set up some minimal docs and have some code working. :) No problem. For final I would like to see some samples (repository block lacks any) and at least minimal coverage by tests. Me too, after going through your points below my plan is to write initial tests for SourceRepository to test all repository operations using a local file:// based repository. Ultimately I would like to see this block springified (sprung?) too - I envisage us creating our own Repository implementations and would much prefer to do this using Spring. 3. Any documentation on upgrading blocks to C2.2? I fear there is nothing like that but this is caused mainly because trunk has been changing many times until it stabilized now. Moreover, it is quite hard to provide general enough documentation of a process that itself is rather non-trivial. I don't want you to get an impression that you are aiming at a dead- complicated task... No problem, as I said before we expect to be making use of this block, it will all be useful... Ok, enough of excuse. I just have taken a quick look at repository block and it seems that there are only few issues: a) there are no configuration files of sitemap components provided by repository block. In a C2.2 advised method is to configure them *outside* the sitemap. See this [1] file to get an idea how it should look like. No problem. b) there is old file containing configuration of caching source. This source has been refactored and moved to the core so this configuration is not needed anymore. No problem. I think that the best strategy would be to create configuration of sitemap components in order to get them running then try to run rest of components. Will do this and set up some tests for these components - I'm still figuring out how some of the other components in this block are used and so how they can be tested. I guess it's not that much work left in order to prepare first milestone release of repository block but having even few samples would be highly appreciated. I'll report back after I've taken a look at the above and will hopefully have an idea of what the samples could contain. Thanks, Robin [1] http://svn.apache.org/repos/asf/cocoon/trunk/core/cocoon-core/src/ main/resources/META-INF/cocoon/avalon/cocoon-core- sitemapcomponents.xconf -- Grzegorz Kossakowski smime.p7s Description: S/MIME cryptographic signature
[jira] Subscription: COCOON-open-with-patch
Issue Subscription Filter: COCOON-open-with-patch (108 issues) Subscriber: cocoon Key Summary COCOON-2149 Patch to IncludeTransformer to add root-element stripping (cf CIncludeTransformer) https://issues.apache.org/jira/browse/COCOON-2149 COCOON-2137 XSD Schemas for CForms Development https://issues.apache.org/jira/browse/COCOON-2137 COCOON-2133 Addition of allow-enlarge parameter to ImageOp resize operation https://issues.apache.org/jira/browse/COCOON-2133 COCOON-2114 fix sorting in TraversableGenerator https://issues.apache.org/jira/browse/COCOON-2114 COCOON-2109 Incorrent cleanup of expired continuations https://issues.apache.org/jira/browse/COCOON-2109 COCOON-2108 xmodule:flow-attr Does not accept document objects https://issues.apache.org/jira/browse/COCOON-2108 COCOON-2104 [PATCH] Add base URI fixup support to XIncludeTransformer https://issues.apache.org/jira/browse/COCOON-2104 COCOON-2100 Retrieving mimeType returned by pipeline executed from Flow https://issues.apache.org/jira/browse/COCOON-2100 COCOON-2071 Option to turn off pooling for components (probably faster on new JVMs and simpler debugging) https://issues.apache.org/jira/browse/COCOON-2071 COCOON-2065 huge performance increase of LuceneIndexTransformer on large Lucene indexes https://issues.apache.org/jira/browse/COCOON-2065 COCOON-2063 NekoHTMLTransformer needs to set the default-encoding of the current system to work properly with UTF-8 https://issues.apache.org/jira/browse/COCOON-2063 COCOON-2052 Allow Ajax submission of forms with empty upload field https://issues.apache.org/jira/browse/COCOON-2052 COCOON-2041 WebDAV Returns improper status on PUT https://issues.apache.org/jira/browse/COCOON-2041 COCOON-2040 Union widget does not work with booleanfield set as case widget https://issues.apache.org/jira/browse/COCOON-2040 COCOON-2037 New DynamicGroup widget https://issues.apache.org/jira/browse/COCOON-2037 COCOON-2035 NPE in the sorter of the EnhancedRepeater https://issues.apache.org/jira/browse/COCOON-2035 COCOON-2032 [PATCH] Sort order in paginated repeater https://issues.apache.org/jira/browse/COCOON-2032 COCOON-2030 submit-on-change doesn't work for a multivaluefield with list-type=checkbox https://issues.apache.org/jira/browse/COCOON-2030 COCOON-2018 Use thread context class loader to load custom binding classes https://issues.apache.org/jira/browse/COCOON-2018 COCOON-2017 More output beautification options for serializers https://issues.apache.org/jira/browse/COCOON-2017 COCOON-2015 Doctype added twice because root element (html) is inlined https://issues.apache.org/jira/browse/COCOON-2015 COCOON-2002 HTML transformer only works with latin-1 characters https://issues.apache.org/jira/browse/COCOON-2002 COCOON-1985 AbstractCachingProcessingPipeline locking with IncludeTransformer may hang pipeline https://issues.apache.org/jira/browse/COCOON-1985 COCOON-1974 Donating ContextAttributeInputModule https://issues.apache.org/jira/browse/COCOON-1974 COCOON-1973 CaptchaValidator: allow case-insensitive matching https://issues.apache.org/jira/browse/COCOON-1973 COCOON-1964 Redirects inside a block called via the blocks protocol fail https://issues.apache.org/jira/browse/COCOON-1964 COCOON-1963 Add a redirect action to the browser update handler https://issues.apache.org/jira/browse/COCOON-1963 COCOON-1960 Pipeline errors for generator/reader already set should provide more information https://issues.apache.org/jira/browse/COCOON-1960 COCOON-1949 [PATCH] load flowscript from file into specified Rhino context object https://issues.apache.org/jira/browse/COCOON-1949 COCOON-1946 [PATCH] - Javaflow Sample errors trying to enhance Javaflow classes and showing cform templates https://issues.apache.org/jira/browse/COCOON-1946 COCOON-1943 [Patch] Parameters in blocks-protocol URIs get decoded too early https://issues.apache.org/jira/browse/COCOON-1943 COCOON-1932 [PATCH] correct styling of disabled suggestion lists https://issues.apache.org/jira/browse/COCOON-1932 COCOON-1929 [PATCH] Reloading classloader in Cocoon 2.2 https://issues.apache.org/jira/browse/COCOON-1929 COCOON-1917 Request Encoding problem: multipart/form vs. url encoded https://issues.apache.org/jira/browse/COCOON-1917 COCOON-1915 Nullable value with additional String or XMLizable in JavaSelectionList https://issues.apache.org/jira/browse/COCOON-1915 COCOON-1914 Text as XMLizable in EmptySelectionList https://issues.apache.org/jira/browse/COCOON-1914 COCOON-1899 [PATCH] Cocoon XML:DB Implementation should not depend on Xindice
[jira] Updated: (COCOON-2133) Addition of allow-enlarge parameter to ImageOp resize operation
[ https://issues.apache.org/jira/browse/COCOON-2133?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Grzegorz Kossakowski updated COCOON-2133: - Attachment: cocoon-core-SitemapComponentTestCase-read-method.patch Having some spare time while waiting for a bus I opened my laptop and created this patch. It adds missing read() method to be used for testing Readers. Addition of allow-enlarge parameter to ImageOp resize operation - Key: COCOON-2133 URL: https://issues.apache.org/jira/browse/COCOON-2133 Project: Cocoon Issue Type: Improvement Components: Blocks: ImageOp Affects Versions: 2.1.11, 2.2-dev (Current SVN) Reporter: Robin Wyles Priority: Minor Attachments: cocoon-core-SitemapComponentTestCase-read-method.patch, ResizeOperation.patch, RevisedResizeOperationPatch.txt The addition of an allow-enlarge parameter to the resize operation allows the user to control whether an image should be enlarged by the operation. This new parameter is declared in the sitemap like so: map:read type=imageop src=image.jpg map:parameter name=prefix-preserve-ratio value=true/ map:parameter name=prefix-allow-enlarge value=false/ map:parameter name=prefix-width value=320/ map:parameter name=prefix-height value=240/ /map:read -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (COCOON-2133) Addition of allow-enlarge parameter to ImageOp resize operation
[ https://issues.apache.org/jira/browse/COCOON-2133?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Grzegorz Kossakowski updated COCOON-2133: - Attachment: cocoon-imageop-impl-no-effects-test.patch Here comes a patch adding very simple test for ImageOp reader. I have not given both patches too much testing but I hope you will find it helpful. Addition of allow-enlarge parameter to ImageOp resize operation - Key: COCOON-2133 URL: https://issues.apache.org/jira/browse/COCOON-2133 Project: Cocoon Issue Type: Improvement Components: Blocks: ImageOp Affects Versions: 2.1.11, 2.2-dev (Current SVN) Reporter: Robin Wyles Priority: Minor Attachments: cocoon-core-SitemapComponentTestCase-read-method.patch, cocoon-imageop-impl-no-effects-test.patch, ResizeOperation.patch, RevisedResizeOperationPatch.txt The addition of an allow-enlarge parameter to the resize operation allows the user to control whether an image should be enlarged by the operation. This new parameter is declared in the sitemap like so: map:read type=imageop src=image.jpg map:parameter name=prefix-preserve-ratio value=true/ map:parameter name=prefix-allow-enlarge value=false/ map:parameter name=prefix-width value=320/ map:parameter name=prefix-height value=240/ /map:read -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [Vote] Cocoon Release 2.1.11
On 12/31/07, Carsten Ziegeler [EMAIL PROTECTED] wrote: I've put up the 2.1.11 release at: http://people.apache.org/~cziegeler/releases/cocoon/ Please check, verify and cast your votes. Thanks Carsten Ziegeler In cocoon-2.1.11-src.zip, the EOLs are Unix format for tools\bin\*.bat and every *.txt file in any directory. The EOLs are MS-DOS format for build.bat and cocoon.bat. Build.bat is not usable because it calls the wrongly-formatted incomprehensible batch files in tools\bin. ant.bat, antRun.bat, appendcp.bat, and lcp.bat should be formatted with MS-DOS line breaks. This issue may not be considered a blocker since the the formatting has been wrong in every release of Cocoon that I have seen. I did not check the tar.gz. Anybody understanding tar.gz files is also likely to know the dos2unix command. solprovider
[jira] Commented: (COCOON-2155) Failing test cases due to additional attributes from namespace declarations in a DOM from parser, but not from serializer
[ https://issues.apache.org/jira/browse/COCOON-2155?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12555463#action_12555463 ] Jörg Heinicke commented on COCOON-2155: --- I'm don't like these superfluous declarations either but my opinion is that test-cases should always reflect in every detail behaviour of components they test. Current behaviour of tested components is to leave superfluous namespace declarations and this must be reflected in tests. My point was that it is no error if the component's behavior changes in this regard. But I really don't have a strong opinion on this and I am absolutely ok with the way you did it. Failing test cases due to additional attributes from namespace declarations in a DOM from parser, but not from serializer - Key: COCOON-2155 URL: https://issues.apache.org/jira/browse/COCOON-2155 Project: Cocoon Issue Type: Bug Components: * Cocoon Core Affects Versions: 2.2-dev (Current SVN) Reporter: Grzegorz Kossakowski Attachments: COCOON-2155-cocoon-core.patch, COCOON-2155-cocoon-forms-impl.patch, COCOON-2155-cocoon-template-impl.patch, COCOON-2155-parent-pom.patch Quoting Joerg: Just an explanation: A namespace declaration is not an attribute (even if it looks so) and that's why it should not end as such. The DOM produced by Cocoon is absolutely correct, the one by parsing expected document in the test case is not since it has both the namespace declaration AND an attribute xmlns:fi - which broke our test. (http://article.gmane.org/gmane.text.xml.cocoon.devel/75975) Also see this: http://article.gmane.org/gmane.text.xml.cocoon.devel/75974 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (COCOON-2052) Allow Ajax submission of forms with empty upload field
[ https://issues.apache.org/jira/browse/COCOON-2052?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jörg Heinicke closed COCOON-2052. - Resolution: Fixed Affects version (Component): Parent values: Blocks: Forms(10167). Level 1 values: 1.0.0-RC1(10321). Fix version (Component): Parent values: Blocks: Forms(10239). Applied to 2.2 as well. Allow Ajax submission of forms with empty upload field -- Key: COCOON-2052 URL: https://issues.apache.org/jira/browse/COCOON-2052 Project: Cocoon Issue Type: Improvement Components: Blocks: Forms Affects Versions: 2.1.11, 2.2-dev (Current SVN) Reporter: Robin Wyles Priority: Minor Fix For: 2.1.11, 2.2-dev (Current SVN) Attachments: AjaxForm-upload-patch.txt, C2.2-AjaxForm-upload-patch.txt Currently AjaxForm.js disables Ajax if the form contains an active upload field regardless of whether it contains a value or not. This simple patch only disables Ajax if the upload field is active and has a value. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [jira] Closed: (COCOON-2052) Allow Ajax submission of forms with empty upload field
On 02.01.2008 20:48 Uhr, Jörg Heinicke (JIRA) wrote: [ https://issues.apache.org/jira/browse/COCOON-2052?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jörg Heinicke closed COCOON-2052. - Resolution: Fixed Affects version (Component): Parent values: Blocks: Forms(10167). Level 1 values: 1.0.0-RC1(10321). Fix version (Component): Parent values: Blocks: Forms(10239). Where can these values be administered? There is no 1.0-dev or 1.0.0 or whatever for Forms block. Joerg
[jira] Updated: (COCOON-2149) Patch to IncludeTransformer to add root-element stripping (cf CIncludeTransformer)
[ https://issues.apache.org/jira/browse/COCOON-2149?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jörg Heinicke updated COCOON-2149: -- Affects version (Component): Parent values: Cocoon Core(10151). Level 1 values: 2.2.0-RC2(10309). (was: Parent values: Cocoon Core(10151). ) Fix Version/s: 2.2-dev (Current SVN) 2.1.12-dev (Current SVN) Patch applied to 2.2. 2.1 is frozen at the moment, will be applied as soon as 2.1.11 is released. Patch to IncludeTransformer to add root-element stripping (cf CIncludeTransformer) -- Key: COCOON-2149 URL: https://issues.apache.org/jira/browse/COCOON-2149 Project: Cocoon Issue Type: Improvement Components: * Cocoon Core Affects Versions: 2.1.11, 2.2-dev (Current SVN) Reporter: Ellis Pritchard Assignee: Grzegorz Kossakowski Priority: Minor Fix For: 2.1.12-dev (Current SVN), 2.2-dev (Current SVN) Attachments: IncludeTransformer.java.2.2.patch, IncludeTransformer.java.patch The CIncludeTransformer offers the useful ability to strip the root element of included content; this patch adds this functionality to the IncludeTransformer. Example: i:include xmlns:i=http://apache.org/cocoon/include/1.0; src=cocoon://path/to/include strip-root=true/ -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (COCOON-2104) [PATCH] Add base URI fixup support to XIncludeTransformer
[ https://issues.apache.org/jira/browse/COCOON-2104?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jörg Heinicke reassigned COCOON-2104: - Assignee: Jörg Heinicke [PATCH] Add base URI fixup support to XIncludeTransformer - Key: COCOON-2104 URL: https://issues.apache.org/jira/browse/COCOON-2104 Project: Cocoon Issue Type: Bug Components: * Cocoon Core Affects Versions: 2.1.11, 2.2-dev (Current SVN) Reporter: Andrew Cave Assignee: Jörg Heinicke Priority: Minor Attachments: baseFixup-2.1-r561455.diff, baseFixup-2.2-r561499.diff As discussed at [1], the XIncludeTransformer fails to perform the base URI fixup specified in the W3C's XInclude spec [2]. The spec says that the base URIs of elements do not change when passed through a conformant XInclude processor. Meaning, xml:base attributes must be added to the result set. The reason being that relative URIs in the included document should not break; this provides a mechanism to resolve them properly. This patch results in the XIncludeTransformer adding xml:base attributes to top-level included elements. It does this only when the the base URI of the included element differs from the base URI of the parent element (meaning: for almost every case except where the included document is the current document). The XIncludeTransformer's JUnit test is also updated by this patch to reflect the fact that the resulting XML file (xinclude-result-1.xml) has an xml:base attribute added. [1] http://www.mail-archive.com/dev@cocoon.apache.org/msg52803.html [2] http://www.w3.org/TR/xinclude/#base - The Base URI Fixup section of the W3C's XInclude specification -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [Vote] Cocoon Release 2.1.11
Carsten Ziegeler wrote: Hi, i've put up the 2.1.11 release at: http://people.apache.org/~cziegeler/releases/cocoon/ please check, verify and cast your votes. I used the tar.gz and verified the md5sum and pgp signature, and investigated some other things. md5: f103d7c90fcd1e0f027f88f7fd0a44a0 +1 from me. p.s. We have the wrong name for the Apache License in the README.txt and some of the stuff that is in CREDITS.txt should instead be in NOTICE.txt, but i reckon that can pass this time. -David
