[jira] [Commented] (JCRVLT-266) DocViewSaxFormatter does not always emit namespace declaration for "jcr"
[
https://issues.apache.org/jira/browse/JCRVLT-266?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16352097#comment-16352097
]
Konrad Windszus commented on JCRVLT-266:
Thanks for quick fix. Regarding the usefulness: Even for packages having much
deeper filter roots than “/“ the package will also include docview files for
the root. As those files have been invalid due to the missing namespace
declaration installing such packages lead to weird warnings in the log. This
fix should help to get rid of them.
> DocViewSaxFormatter does not always emit namespace declaration for "jcr"
>
>
> Key: JCRVLT-266
> URL: https://issues.apache.org/jira/browse/JCRVLT-266
> Project: Jackrabbit FileVault
> Issue Type: Bug
> Components: vlt
>Affects Versions: 3.1.42
>Reporter: Konrad Windszus
>Assignee: Tobias Bocanegra
>Priority: Major
> Fix For: 3.1.44
>
>
> Under certain circumstances the {{DocViewSaxFormatter}} does not emit any
> namespace declarations. That is the case for an aggregate not having any
> namespaced properties (e.g. due to lack of read privileges) and not having
> any namespaced child elements. The generated {{.content.xml}} then looks like
> this:
> {code}
>
>
> {code}
> This XML is invalid and leads to exceptions during import.
> The problem is that the namespace for {{jcr}} is always necessary as the root
> element is always named {{jcr:root}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (JCRVLT-266) DocViewSaxFormatter does not always emit namespace declaration for "jcr"
[
https://issues.apache.org/jira/browse/JCRVLT-266?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tobias Bocanegra resolved JCRVLT-266.
-
Resolution: Fixed
Fix Version/s: 3.1.44
fixed slightly different in r1823118.
although I doubt that incomplete serialized packages are particularly useful.
> DocViewSaxFormatter does not always emit namespace declaration for "jcr"
>
>
> Key: JCRVLT-266
> URL: https://issues.apache.org/jira/browse/JCRVLT-266
> Project: Jackrabbit FileVault
> Issue Type: Bug
> Components: vlt
>Affects Versions: 3.1.42
>Reporter: Konrad Windszus
>Assignee: Tobias Bocanegra
>Priority: Major
> Fix For: 3.1.44
>
>
> Under certain circumstances the {{DocViewSaxFormatter}} does not emit any
> namespace declarations. That is the case for an aggregate not having any
> namespaced properties (e.g. due to lack of read privileges) and not having
> any namespaced child elements. The generated {{.content.xml}} then looks like
> this:
> {code}
>
>
> {code}
> This XML is invalid and leads to exceptions during import.
> The problem is that the namespace for {{jcr}} is always necessary as the root
> element is always named {{jcr:root}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (JCRVLT-266) DocViewSaxFormatter does not always emit namespace declaration for "jcr"
[
https://issues.apache.org/jira/browse/JCRVLT-266?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tobias Bocanegra reassigned JCRVLT-266:
---
Assignee: Tobias Bocanegra
> DocViewSaxFormatter does not always emit namespace declaration for "jcr"
>
>
> Key: JCRVLT-266
> URL: https://issues.apache.org/jira/browse/JCRVLT-266
> Project: Jackrabbit FileVault
> Issue Type: Bug
> Components: vlt
>Affects Versions: 3.1.42
>Reporter: Konrad Windszus
>Assignee: Tobias Bocanegra
>Priority: Major
>
> Under certain circumstances the {{DocViewSaxFormatter}} does not emit any
> namespace declarations. That is the case for an aggregate not having any
> namespaced properties (e.g. due to lack of read privileges) and not having
> any namespaced child elements. The generated {{.content.xml}} then looks like
> this:
> {code}
>
>
> {code}
> This XML is invalid and leads to exceptions during import.
> The problem is that the namespace for {{jcr}} is always necessary as the root
> element is always named {{jcr:root}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (JCRVLT-262) Implement workaround for JCRVLT-177 when creating subpackages
[ https://issues.apache.org/jira/browse/JCRVLT-262?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16351918#comment-16351918 ] Tobias Bocanegra edited comment on JCRVLT-262 at 2/5/18 1:50 AM: - [~kwin] the comments regarding the regressions mentioned above are not relevant to this issue. further is the product management of Adobes AEM out of scope of an apache project and should be discussed using the appropriate channels offered by Adobe. bq. Actually the generated package is now closer to what the package manager would generate since the package manager always uses Extended File Aggregates ...which is something I would rather get rid off, and provide the sub-packages outside the jcr content. this is also problematic for setups with changed package root or systems where the packages are not stored in the JCR at all. was (Author: tripod): [~kwin] the comments regarding the regressions mentioned above are not relevant to this issue. further is the product management of Adobes AEM out of scope of an apache project and should be discussed using the appropriate channels offered by Adobe. bq. Actually the generated package is now closer to what the package manager would generate since the package manager always uses Extended File Aggregates ...which is something I would rather get rid off, as well, since some of the information is duplicated in the properties, MANIFEST, filter.xml, etc. I would rather provide a better way to convey the missing meta information differently. however, I see that it might be beneficial to support the population of the definition node properly, since many users want to include this extra information into the package via maven. > Implement workaround for JCRVLT-177 when creating subpackages > - > > Key: JCRVLT-262 > URL: https://issues.apache.org/jira/browse/JCRVLT-262 > Project: Jackrabbit FileVault > Issue Type: Bug > Components: package maven plugin >Affects Versions: package-maven-plugin-1.0.1 >Reporter: Konrad Windszus >Priority: Major > > Due to bug JCRVLT-177 all package metadata (like filters or dependencies) of > subpackages are not correctly overwritten (when updating a SNAPSHOT version > package with Jackrabbit Filevault < 3.1.40). > The workaround to create subpackages not only as one Simple File (the .zip) > but also creating an according .content.xml works around this limitation and > leads to correctly updating the meta data. The Maven plugin should allow to > optionally create the .content.xml along with the subpackage automatically. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (JCRVLT-262) Implement workaround for JCRVLT-177 when creating subpackages
[ https://issues.apache.org/jira/browse/JCRVLT-262?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16351918#comment-16351918 ] Tobias Bocanegra commented on JCRVLT-262: - [~kwin] the comments regarding the regressions mentioned above are not relevant to this issue. further is the product management of Adobes AEM out of scope of an apache project and should be discussed using the appropriate channels offered by Adobe. bq. Actually the generated package is now closer to what the package manager would generate since the package manager always uses Extended File Aggregates ...which is something I would rather get rid off, as well, since some of the information is duplicated in the properties, MANIFEST, filter.xml, etc. I would rather provide a better way to convey the missing meta information differently. however, I see that it might be beneficial to support the population of the definition node properly, since many users want to include this extra information into the package via maven. > Implement workaround for JCRVLT-177 when creating subpackages > - > > Key: JCRVLT-262 > URL: https://issues.apache.org/jira/browse/JCRVLT-262 > Project: Jackrabbit FileVault > Issue Type: Bug > Components: package maven plugin >Affects Versions: package-maven-plugin-1.0.1 >Reporter: Konrad Windszus >Priority: Major > > Due to bug JCRVLT-177 all package metadata (like filters or dependencies) of > subpackages are not correctly overwritten (when updating a SNAPSHOT version > package with Jackrabbit Filevault < 3.1.40). > The workaround to create subpackages not only as one Simple File (the .zip) > but also creating an according .content.xml works around this limitation and > leads to correctly updating the meta data. The Maven plugin should allow to > optionally create the .content.xml along with the subpackage automatically. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
Jackrabbit 2.16.1 Release Plan
Hi, I'd like to cut Jackrabbit 2.16.1 on Tuesday. The list of open issues scheduled for 2.16.1 is empty: https://issues.apache.org/jira/issues/?jql=fixVersion%20%3D%202.16.1%20AND%20project%20%3D%20JCR%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20priority%20DESC The candidate release notes are here: https://svn.apache.org/repos/asf/jackrabbit/branches/2.16/RELEASE-NOTES.txt If there are any objections please let me know. Best regards, Julian
[jira] [Assigned] (JCR-4257) Release Jackrabbit 2.16.1
[ https://issues.apache.org/jira/browse/JCR-4257?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Reschke reassigned JCR-4257: --- Assignee: Julian Reschke > Release Jackrabbit 2.16.1 > - > > Key: JCR-4257 > URL: https://issues.apache.org/jira/browse/JCR-4257 > Project: Jackrabbit Content Repository > Issue Type: Task >Reporter: Julian Reschke >Assignee: Julian Reschke >Priority: Minor > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (JCR-4257) Release Jackrabbit 2.16.1
Julian Reschke created JCR-4257: --- Summary: Release Jackrabbit 2.16.1 Key: JCR-4257 URL: https://issues.apache.org/jira/browse/JCR-4257 Project: Jackrabbit Content Repository Issue Type: Task Reporter: Julian Reschke -- This message was sent by Atlassian JIRA (v7.6.3#76005)
