[jira] [Updated] (JCRVLT-289) InstallHooks: Propagate exceptions also for phase INSTALL
[
https://issues.apache.org/jira/browse/JCRVLT-289?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konrad Windszus updated JCRVLT-289:
---
Affects Version/s: 3.1.44
> InstallHooks: Propagate exceptions also for phase INSTALL
> -
>
> Key: JCRVLT-289
> URL: https://issues.apache.org/jira/browse/JCRVLT-289
> Project: Jackrabbit FileVault
> Issue Type: New Feature
> Components: Packaging
>Affects Versions: 3.1.44
>Reporter: Konrad Windszus
>Priority: Major
>
> Currently only exceptions in phase {{PREPARE}} lead to a failure on the
> client side
> (https://github.com/apache/jackrabbit-filevault/blob/a64860257de2450f804b0cdf55a5afc8686b2636/vault-core/src/main/java/org/apache/jackrabbit/vault/packaging/impl/InstallHookProcessorImpl.java#L150).
> But also errors in phase {{lifecyle}} should be propagated to the called,
> otherwise the caller cannot know whether the execution of the hook was
> successful or not.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (JCRVLT-289) InstallHooks: Propagate exceptions also for phase INSTALL
[
https://issues.apache.org/jira/browse/JCRVLT-289?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konrad Windszus updated JCRVLT-289:
---
Component/s: Packaging
> InstallHooks: Propagate exceptions also for phase INSTALL
> -
>
> Key: JCRVLT-289
> URL: https://issues.apache.org/jira/browse/JCRVLT-289
> Project: Jackrabbit FileVault
> Issue Type: New Feature
> Components: Packaging
>Affects Versions: 3.1.44
>Reporter: Konrad Windszus
>Priority: Major
>
> Currently only exceptions in phase {{PREPARE}} lead to a failure on the
> client side
> (https://github.com/apache/jackrabbit-filevault/blob/a64860257de2450f804b0cdf55a5afc8686b2636/vault-core/src/main/java/org/apache/jackrabbit/vault/packaging/impl/InstallHookProcessorImpl.java#L150).
> But also errors in phase {{lifecyle}} should be propagated to the called,
> otherwise the caller cannot know whether the execution of the hook was
> successful or not.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (JCRVLT-289) InstallHooks: Propagate exceptions also for phase INSTALL
[
https://issues.apache.org/jira/browse/JCRVLT-289?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konrad Windszus updated JCRVLT-289:
---
Description:
Currently only exceptions in phase {{PREPARE}} lead to a failure on the client
side
(https://github.com/apache/jackrabbit-filevault/blob/a64860257de2450f804b0cdf55a5afc8686b2636/vault-core/src/main/java/org/apache/jackrabbit/vault/packaging/impl/InstallHookProcessorImpl.java#L150).
But also errors in phase {{lifecyle}} should be propagated to the called,
otherwise the caller cannot know whether the execution of the hook was
successful or not.
Therefore, exceptions in that phase within
InstallHookProcessorImpl.execute(...) should also lead to a return value of
{{false}}. In addition the return value needs to be evaluated in
https://github.com/apache/jackrabbit-filevault/blob/9eb53d36adfb7695a44075c72ca7ff0cedafabcc/vault-core/src/main/java/org/apache/jackrabbit/vault/packaging/impl/ZipVaultPackage.java#L241.
was:Currently only exceptions in phase {{PREPARE}} lead to a failure on the
client side
(https://github.com/apache/jackrabbit-filevault/blob/a64860257de2450f804b0cdf55a5afc8686b2636/vault-core/src/main/java/org/apache/jackrabbit/vault/packaging/impl/InstallHookProcessorImpl.java#L150).
But also errors in phase {{lifecyle}} should be propagated to the called,
otherwise the caller cannot know whether the execution of the hook was
successful or not.
> InstallHooks: Propagate exceptions also for phase INSTALL
> -
>
> Key: JCRVLT-289
> URL: https://issues.apache.org/jira/browse/JCRVLT-289
> Project: Jackrabbit FileVault
> Issue Type: New Feature
> Components: Packaging
>Affects Versions: 3.1.44
>Reporter: Konrad Windszus
>Priority: Major
>
> Currently only exceptions in phase {{PREPARE}} lead to a failure on the
> client side
> (https://github.com/apache/jackrabbit-filevault/blob/a64860257de2450f804b0cdf55a5afc8686b2636/vault-core/src/main/java/org/apache/jackrabbit/vault/packaging/impl/InstallHookProcessorImpl.java#L150).
> But also errors in phase {{lifecyle}} should be propagated to the called,
> otherwise the caller cannot know whether the execution of the hook was
> successful or not.
> Therefore, exceptions in that phase within
> InstallHookProcessorImpl.execute(...) should also lead to a return value of
> {{false}}. In addition the return value needs to be evaluated in
> https://github.com/apache/jackrabbit-filevault/blob/9eb53d36adfb7695a44075c72ca7ff0cedafabcc/vault-core/src/main/java/org/apache/jackrabbit/vault/packaging/impl/ZipVaultPackage.java#L241.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (JCRVLT-289) InstallHooks: Propagate exceptions also for phase INSTALL
[
https://issues.apache.org/jira/browse/JCRVLT-289?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konrad Windszus updated JCRVLT-289:
---
Status: Patch Available (was: Open)
PR: https://github.com/apache/jackrabbit-filevault/pull/26
> InstallHooks: Propagate exceptions also for phase INSTALL
> -
>
> Key: JCRVLT-289
> URL: https://issues.apache.org/jira/browse/JCRVLT-289
> Project: Jackrabbit FileVault
> Issue Type: New Feature
> Components: Packaging
>Affects Versions: 3.1.44
>Reporter: Konrad Windszus
>Priority: Major
>
> Currently only exceptions in phase {{PREPARE}} lead to a failure on the
> client side
> (https://github.com/apache/jackrabbit-filevault/blob/a64860257de2450f804b0cdf55a5afc8686b2636/vault-core/src/main/java/org/apache/jackrabbit/vault/packaging/impl/InstallHookProcessorImpl.java#L150).
> But also errors in phase {{lifecyle}} should be propagated to the called,
> otherwise the caller cannot know whether the execution of the hook was
> successful or not.
> Therefore, exceptions in that phase within
> InstallHookProcessorImpl.execute(...) should also lead to a return value of
> {{false}}. In addition the return value needs to be evaluated in
> https://github.com/apache/jackrabbit-filevault/blob/9eb53d36adfb7695a44075c72ca7ff0cedafabcc/vault-core/src/main/java/org/apache/jackrabbit/vault/packaging/impl/ZipVaultPackage.java#L241.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (JCR-4191) baseline checks fails for jackrabbit-webdav under Java 9
[
https://issues.apache.org/jira/browse/JCR-4191?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16211091#comment-16211091
]
Konrad Windszus commented on JCR-4191:
--
[~julian.resc...@gmx.de] Please consider my comment before. It really totally
makes sense that this behaviour depends on the classpath during the execution
of the baselining. With Java 9 the annotation is there, while with Java 8 it
isn't. Still this should be disregarded by bnd, therefore those annotations
should be just ignored. Please open a bug at bnd.
> baseline checks fails for jackrabbit-webdav under Java 9
>
>
> Key: JCR-4191
> URL: https://issues.apache.org/jira/browse/JCR-4191
> Project: Jackrabbit Content Repository
> Issue Type: Sub-task
> Components: jackrabbit-webdav
>Reporter: Julian Reschke
>Assignee: Julian Reschke
> Fix For: 2.16
>
>
> with:
> {noformat}
> [INFO] * org.apache.jackrabbit.webdav.lock changed1.0.0
> 1.0.0 1.0.1 Version increase required
> [INFO] ~ class org.apache.jackrabbit.webdav.lock.Scope
> [INFO] ~ method hashCode()
> [INFO] - annotated jdk.internal.HotSpotIntrinsicCandidate
> {noformat}
> Note that {{hashCode()}} was indeed added for JCR-4100, but why does have
> adding {{hashCode()}} have this effect, and only when the bunde plugin is
> *run* with Java 9?.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Comment Edited] (JCR-4191) baseline checks fails for jackrabbit-webdav under Java 9
[
https://issues.apache.org/jira/browse/JCR-4191?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1628#comment-1628
]
Konrad Windszus edited comment on JCR-4191 at 10/19/17 2:26 PM:
No, the annotation has only been added with Java 9
(http://bugs.java.com/bugdatabase/view_bug.do?bug_id=8076112). And this is also
reflected by the baselining. Only with Java 9 it sees a difference between the
old version (leveraging the OOTB {{java.lang.Object#hashCode()}} having the
annotation in Java 9) and the new version of jackrabbit-webdav (overwriting the
{{hashCode}} and therefore not having the annotation for intrinsics.
You seem to read the report wrong. Actually baselining is noticing that the
annotation has been removed(!!!) in the new version due to the overwriting of
the otherwise native method.
was (Author: kwin):
No, the annotation has only been added with Java 9
(http://bugs.java.com/bugdatabase/view_bug.do?bug_id=8076112). And this is also
reflected by the baselining. Only with Java 9 it sees a difference between the
old version (leveraging the OOTB {{java.lang.Object#hashCode()}} having the
annotation in Java 9) and the new version of jackrabbit-webdav (overriding the
{{hashCode}} and therefore not having the annotation for intrinsics.
> baseline checks fails for jackrabbit-webdav under Java 9
>
>
> Key: JCR-4191
> URL: https://issues.apache.org/jira/browse/JCR-4191
> Project: Jackrabbit Content Repository
> Issue Type: Sub-task
> Components: jackrabbit-webdav
>Reporter: Julian Reschke
>Assignee: Julian Reschke
> Fix For: 2.16
>
>
> with:
> {noformat}
> [INFO] * org.apache.jackrabbit.webdav.lock changed1.0.0
> 1.0.0 1.0.1 Version increase required
> [INFO] ~ class org.apache.jackrabbit.webdav.lock.Scope
> [INFO] ~ method hashCode()
> [INFO] - annotated jdk.internal.HotSpotIntrinsicCandidate
> {noformat}
> Note that {{hashCode()}} was indeed added for JCR-4100, but why does have
> adding {{hashCode()}} have this effect, and only when the bunde plugin is
> *run* with Java 9?.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (JCR-4191) baseline checks fails for jackrabbit-webdav under Java 9
[
https://issues.apache.org/jira/browse/JCR-4191?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1628#comment-1628
]
Konrad Windszus commented on JCR-4191:
--
No, the annotation has only been added with Java 9
(http://bugs.java.com/bugdatabase/view_bug.do?bug_id=8076112). And this is also
reflected by the baselining. Only with Java 9 it sees a difference between the
old version (leveraging the OOTB {{java.lang.Object#hashCode()}} having the
annotation in Java 9) and the new version of jackrabbit-webdav (overriding the
{{hashCode}} and therefore not having the annotation for intrinsics.
> baseline checks fails for jackrabbit-webdav under Java 9
>
>
> Key: JCR-4191
> URL: https://issues.apache.org/jira/browse/JCR-4191
> Project: Jackrabbit Content Repository
> Issue Type: Sub-task
> Components: jackrabbit-webdav
>Reporter: Julian Reschke
>Assignee: Julian Reschke
> Fix For: 2.16
>
>
> with:
> {noformat}
> [INFO] * org.apache.jackrabbit.webdav.lock changed1.0.0
> 1.0.0 1.0.1 Version increase required
> [INFO] ~ class org.apache.jackrabbit.webdav.lock.Scope
> [INFO] ~ method hashCode()
> [INFO] - annotated jdk.internal.HotSpotIntrinsicCandidate
> {noformat}
> Note that {{hashCode()}} was indeed added for JCR-4100, but why does have
> adding {{hashCode()}} have this effect, and only when the bunde plugin is
> *run* with Java 9?.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Comment Edited] (JCR-4191) baseline checks fails for jackrabbit-webdav under Java 9
[
https://issues.apache.org/jira/browse/JCR-4191?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16210741#comment-16210741
]
Konrad Windszus edited comment on JCR-4191 at 10/19/17 2:08 PM:
I think it is important to clearly understand what happens here and to have a
closer look at the output of bnd's baselining report here:
With the overriding of the hashCode() in JCR-4100 the annotation
{{jdk.internal.HotSpotIntrinsicCandidate}} being set by default on
Object.hashCode() has been removed. This makes totally sense as the custom
hashCode is no longer a candidate for being replaced by an intrinsic function.
This happens only when the baselining is executed with Java9, as only then the
method {{java.lang.Object#hashCode()}} has the annotation
{{jdk.internal.HotSpotIntrinsicCandidate}}. When being executed with Java8 or
below the annotation is not there on {{java.lang.Object#hashCode()}} and
therefore no difference is being detected.
Nevertheless I agree with [~karlpauls] that baselining in bnd should ignore
those special annotations, as those could also come and go if you first compile
with Java9 and then with Java8 (so even without any actual code changes).
was (Author: kwin):
I think it is important to clearly understand what happens here and to have a
closer look at the output of bnd's baselining report here:
With the overriding of the hashCode() in JCR-4100 the annotation
{{jdk.internal.HotSpotIntrinsicCandidate}} being set by default on
Object.hashCode() has been removed. This makes totally sense as the custom
hashCode is no longer a candidate for being replaced by an intrinsic function.
Nevertheless I agree with [~karlpauls] that baselining in bnd should ignore
those special annotations, as those could also come and go if you first compile
with Java9 and then with Java8 (so even without any actual code changes).
> baseline checks fails for jackrabbit-webdav under Java 9
>
>
> Key: JCR-4191
> URL: https://issues.apache.org/jira/browse/JCR-4191
> Project: Jackrabbit Content Repository
> Issue Type: Sub-task
> Components: jackrabbit-webdav
>Reporter: Julian Reschke
>Assignee: Julian Reschke
> Fix For: 2.16
>
>
> with:
> {noformat}
> [INFO] * org.apache.jackrabbit.webdav.lock changed1.0.0
> 1.0.0 1.0.1 Version increase required
> [INFO] ~ class org.apache.jackrabbit.webdav.lock.Scope
> [INFO] ~ method hashCode()
> [INFO] - annotated jdk.internal.HotSpotIntrinsicCandidate
> {noformat}
> Note that {{hashCode()}} was indeed added for JCR-4100, but why does have
> adding {{hashCode()}} have this effect, and only when the bunde plugin is
> *run* with Java 9?.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Comment Edited] (JCR-4191) baseline checks fails for jackrabbit-webdav under Java 9
[
https://issues.apache.org/jira/browse/JCR-4191?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1628#comment-1628
]
Konrad Windszus edited comment on JCR-4191 at 10/19/17 2:27 PM:
No, the annotation has only been added with Java 9
(http://bugs.java.com/bugdatabase/view_bug.do?bug_id=8076112). And this is also
reflected by the baselining. Only with Java 9 it sees a difference between the
old version (leveraging the OOTB {{java.lang.Object#hashCode()}} having the
annotation in Java 9) and the new version of jackrabbit-webdav (overwriting the
{{hashCode}} and therefore not having the annotation for intrinsics.
You seem to read the report wrong. Actually baselining is noticing that the
annotation has been removed(!!!) in the new version due to the overwriting of
the otherwise native method.
Maybe it is a bit confusing that the original hashCode is part of the JRE and
not part of the jackrabbit-webdav module.
was (Author: kwin):
No, the annotation has only been added with Java 9
(http://bugs.java.com/bugdatabase/view_bug.do?bug_id=8076112). And this is also
reflected by the baselining. Only with Java 9 it sees a difference between the
old version (leveraging the OOTB {{java.lang.Object#hashCode()}} having the
annotation in Java 9) and the new version of jackrabbit-webdav (overwriting the
{{hashCode}} and therefore not having the annotation for intrinsics.
You seem to read the report wrong. Actually baselining is noticing that the
annotation has been removed(!!!) in the new version due to the overwriting of
the otherwise native method.
> baseline checks fails for jackrabbit-webdav under Java 9
>
>
> Key: JCR-4191
> URL: https://issues.apache.org/jira/browse/JCR-4191
> Project: Jackrabbit Content Repository
> Issue Type: Sub-task
> Components: jackrabbit-webdav
>Reporter: Julian Reschke
>Assignee: Julian Reschke
> Fix For: 2.16
>
>
> with:
> {noformat}
> [INFO] * org.apache.jackrabbit.webdav.lock changed1.0.0
> 1.0.0 1.0.1 Version increase required
> [INFO] ~ class org.apache.jackrabbit.webdav.lock.Scope
> [INFO] ~ method hashCode()
> [INFO] - annotated jdk.internal.HotSpotIntrinsicCandidate
> {noformat}
> Note that {{hashCode()}} was indeed added for JCR-4100, but why does have
> adding {{hashCode()}} have this effect, and only when the bunde plugin is
> *run* with Java 9?.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (JCRVLT-308) Simple File Aggregate should only update content in repo in case the actual binary has been changed (or some metadata)
Konrad Windszus created JCRVLT-308: -- Summary: Simple File Aggregate should only update content in repo in case the actual binary has been changed (or some metadata) Key: JCRVLT-308 URL: https://issues.apache.org/jira/browse/JCRVLT-308 Project: Jackrabbit FileVault Issue Type: Bug Components: vlt Affects Versions: 3.1.44 Reporter: Konrad Windszus Usually for aggregates the nodes/properties are actually only written if they differ between the To-Be state given in the package and the As-Is state in the repository. That mechanism does not work though for simple file aggregates. Those are always overwritten in the repository (because at least their jcr:lastModification property is touched every time). Instead the simple file aggregate should be compared based on the checksum with the binary from the repository. Only in case they differ or metadata is explicitly written/removed as well the node should actually be touched. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (JCRVLT-255) ImportModes act on file serialization level not on node level
[
https://issues.apache.org/jira/browse/JCRVLT-255?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16301149#comment-16301149
]
Konrad Windszus commented on JCRVLT-255:
[~tripod] Any comments?
> ImportModes act on file serialization level not on node level
> -
>
> Key: JCRVLT-255
> URL: https://issues.apache.org/jira/browse/JCRVLT-255
> Project: Jackrabbit FileVault
> Issue Type: Improvement
>Reporter: Konrad Windszus
>
> When reading the docs at
> http://jackrabbit.apache.org/filevault/importmode.html I would assume that
> for {{ImportMode.MERGE}} the merging happens on node level (i.e. indepent of
> the actual serialization format). Unfortunately this is not the case: If I
> have a serialized docview {{.content.xml}} file covering the current node and
> three levels below the merging is not done if the entry node level does
> already exist in the repository, although not all child nodes are in the
> repository yet.
> This is due to the guard in
> https://github.com/apache/jackrabbit-filevault/blob/8b2fedaf329b3bf4a049e41563c0bc83487406f7/vault-core/src/main/java/org/apache/jackrabbit/vault/fs/impl/io/FileArtifactHandler.java#L226.
> which prevents the DocViewSAXImporter from kicking in, although there are
> indeed subnodes in the {{.content.xml}} which are not yet in the repository.
> Please either fix this behaviour of make the documentation at
> http://jackrabbit.apache.org/filevault/importmode.html clearer because it
> explicitly says there:
> {quote}
> It is important to note, that the import mode always operates on entire nodes
> and subtrees...
> {quote}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (JCRVLT-258) Default compression level incorrectly set to NO_COMPRESSION (0)
[
https://issues.apache.org/jira/browse/JCRVLT-258?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konrad Windszus updated JCRVLT-258:
---
Description:
Default compression level has been changed in this commit from
{{Deflater#DEFAULT_COMPRESSION}} (-1) to {{DEFLATER#NO_COMPRESSION}} (0):
https://github.com/apache/jackrabbit-filevault/commit/9515a785d4e6aa60503969023eadc0832f8c181b#diff-7c56322ea0d87bb499663bdee9c41967R40
The original patch from JCRVLT-163 contained -1 (which was IMHO correct and is
also more in line on how packages have been created prior to JCRVLT-163).
was:
Default compression level has been changed in this commit from -1
(Deflater#DEFAULT_COMPRESSION) to DEFLATER#NO_COMPRESSION (0):
https://github.com/apache/jackrabbit-filevault/commit/9515a785d4e6aa60503969023eadc0832f8c181b#diff-7c56322ea0d87bb499663bdee9c41967R40
The original patch from JCRVLT-163 contained -1 (which was IMHO correct and is
also more in line on how packages have been created prior to JCRVLT-163).
> Default compression level incorrectly set to NO_COMPRESSION (0)
> ---
>
> Key: JCRVLT-258
> URL: https://issues.apache.org/jira/browse/JCRVLT-258
> Project: Jackrabbit FileVault
> Issue Type: Bug
> Components: Packaging
>Affects Versions: 3.1.40
>Reporter: Konrad Windszus
>
> Default compression level has been changed in this commit from
> {{Deflater#DEFAULT_COMPRESSION}} (-1) to {{DEFLATER#NO_COMPRESSION}} (0):
> https://github.com/apache/jackrabbit-filevault/commit/9515a785d4e6aa60503969023eadc0832f8c181b#diff-7c56322ea0d87bb499663bdee9c41967R40
> The original patch from JCRVLT-163 contained -1 (which was IMHO correct and
> is also more in line on how packages have been created prior to JCRVLT-163).
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Comment Edited] (JCRVLT-257) ZipException: invalid code lengths set
[
https://issues.apache.org/jira/browse/JCRVLT-257?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16315875#comment-16315875
]
Konrad Windszus edited comment on JCRVLT-257 at 1/8/18 8:40 AM:
The default being {{NO_COMPRESSION}} (0) is most probably a mistake. This is
tracked in JCRVLT-258.
was (Author: kwin):
The default being `NO_COMPRESSION` is most probably a mistake. This is tracked
in JCRVLT-258.
> ZipException: invalid code lengths set
> --
>
> Key: JCRVLT-257
> URL: https://issues.apache.org/jira/browse/JCRVLT-257
> Project: Jackrabbit FileVault
> Issue Type: Bug
> Components: Packaging
>Affects Versions: 3.1.42
> Environment: Darwin Dirks-MacBook-Pro.local 17.3.0 Darwin Kernel
> Version 17.3.0: Thu Nov 9 18:09:22 PST 2017;
> root:xnu-4570.31.3~1/RELEASE_X86_64 x86_64
> java version "1.8.0_151"
> Java(TM) SE Runtime Environment (build 1.8.0_151-b12)
> Java HotSpot(TM) 64-Bit Server VM (build 25.151-b12, mixed mode)
>Reporter: Dirk Rudolph
>Priority: Critical
> Attachments: distributionpackage.zip
>
>
> I'm running into the following exception:
> {code}
> ...
> Caused by: java.util.zip.ZipException: invalid code lengths set
> at
> java.util.zip.InflaterInputStream.read(InflaterInputStream.java:164)
> at java.util.zip.ZipInputStream.read(ZipInputStream.java:194)
> at
> org.apache.jackrabbit.vault.fs.io.ZipStreamArchive.copyToBuffer(ZipStreamArchive.java:228)
> at
> org.apache.jackrabbit.vault.fs.io.ZipStreamArchive.copy(ZipStreamArchive.java:215)
> at
> org.apache.jackrabbit.vault.fs.io.ZipStreamArchive.open(ZipStreamArchive.java:159)
> at
> org.apache.sling.distribution.serialization.impl.vlt.FileVaultContentSerializer.importFromStream(FileVaultContentSerializer.java:130)
> ... 112 common frames omitted
> {code}
> running Apache Sling Content Distribution on an AEM instance. It looks like
> the Zipfile exported by JarExporter is broken in certain cases - though I
> didn't find a unit test for that so far.
> Anyway I'm quite sure that its caused by JCRVLT-163.
> To workaround the compression of the entire file can to be set to
> NO_COMPRESSION.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (JCRVLT-257) ZipException: invalid code lengths set
[
https://issues.apache.org/jira/browse/JCRVLT-257?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16315875#comment-16315875
]
Konrad Windszus commented on JCRVLT-257:
The default being `NO_COMPRESSION` is most probably a mistake. This is tracked
in JCRVLT-258.
> ZipException: invalid code lengths set
> --
>
> Key: JCRVLT-257
> URL: https://issues.apache.org/jira/browse/JCRVLT-257
> Project: Jackrabbit FileVault
> Issue Type: Bug
> Components: Packaging
>Affects Versions: 3.1.42
> Environment: Darwin Dirks-MacBook-Pro.local 17.3.0 Darwin Kernel
> Version 17.3.0: Thu Nov 9 18:09:22 PST 2017;
> root:xnu-4570.31.3~1/RELEASE_X86_64 x86_64
> java version "1.8.0_151"
> Java(TM) SE Runtime Environment (build 1.8.0_151-b12)
> Java HotSpot(TM) 64-Bit Server VM (build 25.151-b12, mixed mode)
>Reporter: Dirk Rudolph
>Priority: Critical
> Attachments: distributionpackage.zip
>
>
> I'm running into the following exception:
> {code}
> ...
> Caused by: java.util.zip.ZipException: invalid code lengths set
> at
> java.util.zip.InflaterInputStream.read(InflaterInputStream.java:164)
> at java.util.zip.ZipInputStream.read(ZipInputStream.java:194)
> at
> org.apache.jackrabbit.vault.fs.io.ZipStreamArchive.copyToBuffer(ZipStreamArchive.java:228)
> at
> org.apache.jackrabbit.vault.fs.io.ZipStreamArchive.copy(ZipStreamArchive.java:215)
> at
> org.apache.jackrabbit.vault.fs.io.ZipStreamArchive.open(ZipStreamArchive.java:159)
> at
> org.apache.sling.distribution.serialization.impl.vlt.FileVaultContentSerializer.importFromStream(FileVaultContentSerializer.java:130)
> ... 112 common frames omitted
> {code}
> running Apache Sling Content Distribution on an AEM instance. It looks like
> the Zipfile exported by JarExporter is broken in certain cases - though I
> didn't find a unit test for that so far.
> Anyway I'm quite sure that its caused by JCRVLT-163.
> To workaround the compression of the entire file can to be set to
> NO_COMPRESSION.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (JCRVLT-258) Default compression level incorrectly set to NO_COMPRESSION (0)
Konrad Windszus created JCRVLT-258: -- Summary: Default compression level incorrectly set to NO_COMPRESSION (0) Key: JCRVLT-258 URL: https://issues.apache.org/jira/browse/JCRVLT-258 Project: Jackrabbit FileVault Issue Type: Bug Components: Packaging Affects Versions: 3.1.40 Reporter: Konrad Windszus Default compression level has been changed in this commit from -1 (Deflater#DEFAULT_COMPRESSION) to DEFLATER#NO_COMPRESSION (0): https://github.com/apache/jackrabbit-filevault/commit/9515a785d4e6aa60503969023eadc0832f8c181b#diff-7c56322ea0d87bb499663bdee9c41967R40 The original patch from JCRVLT-163 contained -1 (which was IMHO correct and is also more in line on how packages have been created prior to JCRVLT-163). -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Comment Edited] (JCRVLT-257) ZipException: invalid code lengths set
[
https://issues.apache.org/jira/browse/JCRVLT-257?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16316009#comment-16316009
]
Konrad Windszus edited comment on JCRVLT-257 at 1/8/18 10:15 AM:
-
I think this issue has been fixed/worked around in a newer Java versions:
https://bugs.java.com/view_bug.do?bug_id=JDK-8189789. The problem though is
that neither Java 8u162 nor 7u171 nor Java 10 are released yet...
was (Author: kwin):
I think this issue has been fixed/worked around in a newer Java version:
https://bugs.java.com/view_bug.do?bug_id=JDK-8189789.
> ZipException: invalid code lengths set
> --
>
> Key: JCRVLT-257
> URL: https://issues.apache.org/jira/browse/JCRVLT-257
> Project: Jackrabbit FileVault
> Issue Type: Bug
> Components: Packaging
>Affects Versions: 3.1.42
> Environment: uname -a
> Darwin Dirks-MacBook-Pro.local 17.3.0 Darwin Kernel Version 17.3.0: Thu Nov
> 9 18:09:22 PST 2017; root:xnu-4570.31.3~1/RELEASE_X86_64 x86_64
> java -version
> java version "1.8.0_151"
> Java(TM) SE Runtime Environment (build 1.8.0_151-b12)
> Java HotSpot(TM) 64-Bit Server VM (build 25.151-b12, mixed mode)
>Reporter: Dirk Rudolph
>Priority: Critical
> Attachments: distributionpackage.zip
>
>
> I'm running into the following exception:
> {code}
> ...
> Caused by: java.util.zip.ZipException: invalid code lengths set
> at
> java.util.zip.InflaterInputStream.read(InflaterInputStream.java:164)
> at java.util.zip.ZipInputStream.read(ZipInputStream.java:194)
> at
> org.apache.jackrabbit.vault.fs.io.ZipStreamArchive.copyToBuffer(ZipStreamArchive.java:228)
> at
> org.apache.jackrabbit.vault.fs.io.ZipStreamArchive.copy(ZipStreamArchive.java:215)
> at
> org.apache.jackrabbit.vault.fs.io.ZipStreamArchive.open(ZipStreamArchive.java:159)
> at
> org.apache.sling.distribution.serialization.impl.vlt.FileVaultContentSerializer.importFromStream(FileVaultContentSerializer.java:130)
> ... 112 common frames omitted
> {code}
> running Apache Sling Content Distribution on an AEM instance. It looks like
> the Zipfile exported by JarExporter is broken in certain cases - though I
> didn't find a unit test for that so far.
> Anyway I'm quite sure that its caused by JCRVLT-163.
> To workaround the compression of the entire file can to be set to
> NO_COMPRESSION.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (JCRVLT-257) ZipException: invalid code lengths set
[
https://issues.apache.org/jira/browse/JCRVLT-257?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16316009#comment-16316009
]
Konrad Windszus commented on JCRVLT-257:
I think this issue has been fixed/worked around in a newer Java version:
https://bugs.java.com/view_bug.do?bug_id=JDK-8189789.
> ZipException: invalid code lengths set
> --
>
> Key: JCRVLT-257
> URL: https://issues.apache.org/jira/browse/JCRVLT-257
> Project: Jackrabbit FileVault
> Issue Type: Bug
> Components: Packaging
>Affects Versions: 3.1.42
> Environment: uname -a
> Darwin Dirks-MacBook-Pro.local 17.3.0 Darwin Kernel Version 17.3.0: Thu Nov
> 9 18:09:22 PST 2017; root:xnu-4570.31.3~1/RELEASE_X86_64 x86_64
> java -version
> java version "1.8.0_151"
> Java(TM) SE Runtime Environment (build 1.8.0_151-b12)
> Java HotSpot(TM) 64-Bit Server VM (build 25.151-b12, mixed mode)
>Reporter: Dirk Rudolph
>Priority: Critical
> Attachments: distributionpackage.zip
>
>
> I'm running into the following exception:
> {code}
> ...
> Caused by: java.util.zip.ZipException: invalid code lengths set
> at
> java.util.zip.InflaterInputStream.read(InflaterInputStream.java:164)
> at java.util.zip.ZipInputStream.read(ZipInputStream.java:194)
> at
> org.apache.jackrabbit.vault.fs.io.ZipStreamArchive.copyToBuffer(ZipStreamArchive.java:228)
> at
> org.apache.jackrabbit.vault.fs.io.ZipStreamArchive.copy(ZipStreamArchive.java:215)
> at
> org.apache.jackrabbit.vault.fs.io.ZipStreamArchive.open(ZipStreamArchive.java:159)
> at
> org.apache.sling.distribution.serialization.impl.vlt.FileVaultContentSerializer.importFromStream(FileVaultContentSerializer.java:130)
> ... 112 common frames omitted
> {code}
> running Apache Sling Content Distribution on an AEM instance. It looks like
> the Zipfile exported by JarExporter is broken in certain cases - though I
> didn't find a unit test for that so far.
> Anyway I'm quite sure that its caused by JCRVLT-163.
> To workaround the compression of the entire file can to be set to
> NO_COMPRESSION.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Comment Edited] (JCRVLT-257) ZipException: invalid code lengths set
[
https://issues.apache.org/jira/browse/JCRVLT-257?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16316009#comment-16316009
]
Konrad Windszus edited comment on JCRVLT-257 at 1/8/18 10:22 AM:
-
I think this issue has been fixed/worked around in newer Java versions:
https://bugs.java.com/view_bug.do?bug_id=JDK-8189789. The problem though is
that neither Java 8u162 nor 7u171 nor Java 10 are released yet...
was (Author: kwin):
I think this issue has been fixed/worked around in a newer Java versions:
https://bugs.java.com/view_bug.do?bug_id=JDK-8189789. The problem though is
that neither Java 8u162 nor 7u171 nor Java 10 are released yet...
> ZipException: invalid code lengths set
> --
>
> Key: JCRVLT-257
> URL: https://issues.apache.org/jira/browse/JCRVLT-257
> Project: Jackrabbit FileVault
> Issue Type: Bug
> Components: Packaging
>Affects Versions: 3.1.42
> Environment: uname -a
> Darwin Dirks-MacBook-Pro.local 17.3.0 Darwin Kernel Version 17.3.0: Thu Nov
> 9 18:09:22 PST 2017; root:xnu-4570.31.3~1/RELEASE_X86_64 x86_64
> java -version
> java version "1.8.0_151"
> Java(TM) SE Runtime Environment (build 1.8.0_151-b12)
> Java HotSpot(TM) 64-Bit Server VM (build 25.151-b12, mixed mode)
>Reporter: Dirk Rudolph
>Priority: Critical
> Attachments: distributionpackage.zip
>
>
> I'm running into the following exception:
> {code}
> ...
> Caused by: java.util.zip.ZipException: invalid code lengths set
> at
> java.util.zip.InflaterInputStream.read(InflaterInputStream.java:164)
> at java.util.zip.ZipInputStream.read(ZipInputStream.java:194)
> at
> org.apache.jackrabbit.vault.fs.io.ZipStreamArchive.copyToBuffer(ZipStreamArchive.java:228)
> at
> org.apache.jackrabbit.vault.fs.io.ZipStreamArchive.copy(ZipStreamArchive.java:215)
> at
> org.apache.jackrabbit.vault.fs.io.ZipStreamArchive.open(ZipStreamArchive.java:159)
> at
> org.apache.sling.distribution.serialization.impl.vlt.FileVaultContentSerializer.importFromStream(FileVaultContentSerializer.java:130)
> ... 112 common frames omitted
> {code}
> running Apache Sling Content Distribution on an AEM instance. It looks like
> the Zipfile exported by JarExporter is broken in certain cases - though I
> didn't find a unit test for that so far.
> Anyway I'm quite sure that its caused by JCRVLT-163.
> To workaround the compression of the entire file can to be set to
> NO_COMPRESSION.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Comment Edited] (JCRVLT-257) ZipException: invalid code lengths set
[
https://issues.apache.org/jira/browse/JCRVLT-257?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16316080#comment-16316080
]
Konrad Windszus edited comment on JCRVLT-257 at 1/8/18 10:57 AM:
-
The latest build (b03) of 8u162 is from October 2017. The fix though has been
applied in Nov. 2017
(http://cr.openjdk.java.net/~coffeys/webrev.8189789.jdk8u/webrev/ and
http://mail.openjdk.java.net/pipermail/core-libs-dev/2017-November/050118.html)
so we have to wait for a more recent build... 8u162 is supposed to be released
in Jan 2018 (http://openjdk.java.net/projects/jdk8u/releases/8u162.html).
was (Author: kwin):
The latest build (b03) of 8u162 is from October 2017. The fix though has been
applied in Nov. 2017
(http://cr.openjdk.java.net/~coffeys/webrev.8189789.jdk8u/webrev/ and
http://mail.openjdk.java.net/pipermail/core-libs-dev/2017-November/050118.html)
so we have to wait for a more recent build...
> ZipException: invalid code lengths set
> --
>
> Key: JCRVLT-257
> URL: https://issues.apache.org/jira/browse/JCRVLT-257
> Project: Jackrabbit FileVault
> Issue Type: Bug
> Components: Packaging
>Affects Versions: 3.1.42
> Environment: uname -a
> Darwin Dirks-MacBook-Pro.local 17.3.0 Darwin Kernel Version 17.3.0: Thu Nov
> 9 18:09:22 PST 2017; root:xnu-4570.31.3~1/RELEASE_X86_64 x86_64
> java -version
> java version "1.8.0_151"
> Java(TM) SE Runtime Environment (build 1.8.0_151-b12)
> Java HotSpot(TM) 64-Bit Server VM (build 25.151-b12, mixed mode)
>Reporter: Dirk Rudolph
>Priority: Critical
> Attachments: distributionpackage.zip
>
>
> I'm running into the following exception:
> {code}
> ...
> Caused by: java.util.zip.ZipException: invalid code lengths set
> at
> java.util.zip.InflaterInputStream.read(InflaterInputStream.java:164)
> at java.util.zip.ZipInputStream.read(ZipInputStream.java:194)
> at
> org.apache.jackrabbit.vault.fs.io.ZipStreamArchive.copyToBuffer(ZipStreamArchive.java:228)
> at
> org.apache.jackrabbit.vault.fs.io.ZipStreamArchive.copy(ZipStreamArchive.java:215)
> at
> org.apache.jackrabbit.vault.fs.io.ZipStreamArchive.open(ZipStreamArchive.java:159)
> at
> org.apache.sling.distribution.serialization.impl.vlt.FileVaultContentSerializer.importFromStream(FileVaultContentSerializer.java:130)
> ... 112 common frames omitted
> {code}
> running Apache Sling Content Distribution on an AEM instance. It looks like
> the Zipfile exported by JarExporter is broken in certain cases - though I
> didn't find a unit test for that so far.
> Anyway I'm quite sure that its caused by JCRVLT-163.
> To workaround the compression of the entire file can to be set to
> NO_COMPRESSION.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (JCRVLT-258) Default compression level incorrectly set to NO_COMPRESSION (0)
[
https://issues.apache.org/jira/browse/JCRVLT-258?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16316137#comment-16316137
]
Konrad Windszus commented on JCRVLT-258:
Just switching the default to {{DEFAULT_COMPRESSION}} will trigger the issue
observed in JCRVLT-257 (at least on more recent Unix systems, leveraging a more
recent zlib library). So at least a detection for the faulty zlib/java version
must be included.
> Default compression level incorrectly set to NO_COMPRESSION (0)
> ---
>
> Key: JCRVLT-258
> URL: https://issues.apache.org/jira/browse/JCRVLT-258
> Project: Jackrabbit FileVault
> Issue Type: Bug
> Components: Packaging
>Affects Versions: 3.1.40
>Reporter: Konrad Windszus
>
> Default compression level has been changed in this commit from
> {{Deflater#DEFAULT_COMPRESSION}} (-1) to {{DEFLATER#NO_COMPRESSION}} (0):
> https://github.com/apache/jackrabbit-filevault/commit/9515a785d4e6aa60503969023eadc0832f8c181b#diff-7c56322ea0d87bb499663bdee9c41967R40
> The original patch from JCRVLT-163 contained -1 (which was IMHO correct and
> is also more in line on how packages have been created prior to JCRVLT-163).
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (JCRVLT-257) ZipException: invalid code lengths set
[
https://issues.apache.org/jira/browse/JCRVLT-257?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16316080#comment-16316080
]
Konrad Windszus commented on JCRVLT-257:
The latest build (b03) of 8u162 is from October 2017. The fix though has been
applied in Nov. 2017
(http://cr.openjdk.java.net/~coffeys/webrev.8189789.jdk8u/webrev/ and
http://mail.openjdk.java.net/pipermail/core-libs-dev/2017-November/050118.html)
so we have to wait for a more recent build...
> ZipException: invalid code lengths set
> --
>
> Key: JCRVLT-257
> URL: https://issues.apache.org/jira/browse/JCRVLT-257
> Project: Jackrabbit FileVault
> Issue Type: Bug
> Components: Packaging
>Affects Versions: 3.1.42
> Environment: uname -a
> Darwin Dirks-MacBook-Pro.local 17.3.0 Darwin Kernel Version 17.3.0: Thu Nov
> 9 18:09:22 PST 2017; root:xnu-4570.31.3~1/RELEASE_X86_64 x86_64
> java -version
> java version "1.8.0_151"
> Java(TM) SE Runtime Environment (build 1.8.0_151-b12)
> Java HotSpot(TM) 64-Bit Server VM (build 25.151-b12, mixed mode)
>Reporter: Dirk Rudolph
>Priority: Critical
> Attachments: distributionpackage.zip
>
>
> I'm running into the following exception:
> {code}
> ...
> Caused by: java.util.zip.ZipException: invalid code lengths set
> at
> java.util.zip.InflaterInputStream.read(InflaterInputStream.java:164)
> at java.util.zip.ZipInputStream.read(ZipInputStream.java:194)
> at
> org.apache.jackrabbit.vault.fs.io.ZipStreamArchive.copyToBuffer(ZipStreamArchive.java:228)
> at
> org.apache.jackrabbit.vault.fs.io.ZipStreamArchive.copy(ZipStreamArchive.java:215)
> at
> org.apache.jackrabbit.vault.fs.io.ZipStreamArchive.open(ZipStreamArchive.java:159)
> at
> org.apache.sling.distribution.serialization.impl.vlt.FileVaultContentSerializer.importFromStream(FileVaultContentSerializer.java:130)
> ... 112 common frames omitted
> {code}
> running Apache Sling Content Distribution on an AEM instance. It looks like
> the Zipfile exported by JarExporter is broken in certain cases - though I
> didn't find a unit test for that so far.
> Anyway I'm quite sure that its caused by JCRVLT-163.
> To workaround the compression of the entire file can to be set to
> NO_COMPRESSION.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (JCRVLT-257) ZipException: invalid code lengths set
[
https://issues.apache.org/jira/browse/JCRVLT-257?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16316124#comment-16316124
]
Konrad Windszus commented on JCRVLT-257:
The test from [~diru] fails on my machine with Java 8 (1.8.0_151) and 9 (9.0.1)
but works with Java 10 (ea37). So most probably the fix/workaround from Oracle
works.
> ZipException: invalid code lengths set
> --
>
> Key: JCRVLT-257
> URL: https://issues.apache.org/jira/browse/JCRVLT-257
> Project: Jackrabbit FileVault
> Issue Type: Bug
> Components: Packaging
>Affects Versions: 3.1.42
> Environment: Java(TM) SE Runtime Environment (build 1.8.0_151-b12)
> zlib version 1.2.11
>Reporter: Dirk Rudolph
>Priority: Critical
> Attachments: distributionpackage.zip
>
>
> I'm running into the following exception:
> {code}
> ...
> Caused by: java.util.zip.ZipException: invalid code lengths set
> at
> java.util.zip.InflaterInputStream.read(InflaterInputStream.java:164)
> at java.util.zip.ZipInputStream.read(ZipInputStream.java:194)
> at
> org.apache.jackrabbit.vault.fs.io.ZipStreamArchive.copyToBuffer(ZipStreamArchive.java:228)
> at
> org.apache.jackrabbit.vault.fs.io.ZipStreamArchive.copy(ZipStreamArchive.java:215)
> at
> org.apache.jackrabbit.vault.fs.io.ZipStreamArchive.open(ZipStreamArchive.java:159)
> at
> org.apache.sling.distribution.serialization.impl.vlt.FileVaultContentSerializer.importFromStream(FileVaultContentSerializer.java:130)
> ... 112 common frames omitted
> {code}
> running Apache Sling Content Distribution on an AEM instance. It looks like
> the Zipfile exported by JarExporter is broken in certain cases - though I
> didn't find a unit test for that so far.
> Anyway I'm quite sure that its caused by JCRVLT-163.
> To workaround the compression of the entire file can to be set to
> NO_COMPRESSION.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Comment Edited] (JCRVLT-257) ZipException: invalid code lengths set
[
https://issues.apache.org/jira/browse/JCRVLT-257?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16316009#comment-16316009
]
Konrad Windszus edited comment on JCRVLT-257 at 1/8/18 11:30 AM:
-
I think this issue has been fixed/worked around in newer Java versions:
https://bugs.openjdk.java.net/browse/JDK-8189789. The problem though is that
neither Java 8u162 nor 7u171 nor Java 10 are released yet...
was (Author: kwin):
I think this issue has been fixed/worked around in newer Java versions:
https://bugs.java.com/view_bug.do?bug_id=JDK-8189789. The problem though is
that neither Java 8u162 nor 7u171 nor Java 10 are released yet...
> ZipException: invalid code lengths set
> --
>
> Key: JCRVLT-257
> URL: https://issues.apache.org/jira/browse/JCRVLT-257
> Project: Jackrabbit FileVault
> Issue Type: Bug
> Components: Packaging
>Affects Versions: 3.1.42
> Environment: Java(TM) SE Runtime Environment (build 1.8.0_151-b12)
> zlib version 1.2.11
>Reporter: Dirk Rudolph
>Priority: Critical
> Attachments: distributionpackage.zip
>
>
> I'm running into the following exception:
> {code}
> ...
> Caused by: java.util.zip.ZipException: invalid code lengths set
> at
> java.util.zip.InflaterInputStream.read(InflaterInputStream.java:164)
> at java.util.zip.ZipInputStream.read(ZipInputStream.java:194)
> at
> org.apache.jackrabbit.vault.fs.io.ZipStreamArchive.copyToBuffer(ZipStreamArchive.java:228)
> at
> org.apache.jackrabbit.vault.fs.io.ZipStreamArchive.copy(ZipStreamArchive.java:215)
> at
> org.apache.jackrabbit.vault.fs.io.ZipStreamArchive.open(ZipStreamArchive.java:159)
> at
> org.apache.sling.distribution.serialization.impl.vlt.FileVaultContentSerializer.importFromStream(FileVaultContentSerializer.java:130)
> ... 112 common frames omitted
> {code}
> running Apache Sling Content Distribution on an AEM instance. It looks like
> the Zipfile exported by JarExporter is broken in certain cases - though I
> didn't find a unit test for that so far.
> Anyway I'm quite sure that its caused by JCRVLT-163.
> To workaround the compression of the entire file can to be set to
> NO_COMPRESSION.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[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=16330881#comment-16330881 ] Konrad Windszus commented on JCRVLT-262: My proposal is in https://github.com/apache/jackrabbit-filevault-package-maven-plugin/pull/9/files. > 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-258) Default compression level incorrectly set to NO_COMPRESSION (0)
[
https://issues.apache.org/jira/browse/JCRVLT-258?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16332349#comment-16332349
]
Konrad Windszus commented on JCRVLT-258:
Just for the record. Java 8 u162 does not contain the zlib fix from Oracle.
This is now supposed to be fixed with the upcoming u172
(https://bugs.openjdk.java.net/browse/JDK-8189789).
> Default compression level incorrectly set to NO_COMPRESSION (0)
> ---
>
> Key: JCRVLT-258
> URL: https://issues.apache.org/jira/browse/JCRVLT-258
> Project: Jackrabbit FileVault
> Issue Type: Bug
> Components: Packaging
>Affects Versions: 3.1.40
>Reporter: Konrad Windszus
>Assignee: Tobias Bocanegra
>Priority: Major
> Fix For: 3.1.44
>
>
> Default compression level has been changed in this commit from
> {{Deflater#DEFAULT_COMPRESSION}} (-1) to {{DEFLATER#NO_COMPRESSION}} (0):
> https://github.com/apache/jackrabbit-filevault/commit/9515a785d4e6aa60503969023eadc0832f8c181b#diff-7c56322ea0d87bb499663bdee9c41967R40
> The original patch from JCRVLT-163 contained -1 (which was IMHO correct and
> is also more in line on how packages have been created prior to JCRVLT-163).
--
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=16330167#comment-16330167 ] Konrad Windszus commented on JCRVLT-262: There are several issues with upgrading: # all releases since 3.1.38 suffered from pretty serious regressions, namely https://issues.apache.org/jira/browse/JCRVLT-186 in 3.1.40 and https://issues.apache.org/jira/browse/JCRVLT-258 in both 3.1.40 and 3.1.42 # Adobe does not provide an official hotfix in its commercial product AEM containing a newer version Apart from that the workaround does not do any harm (even in newer instances). It just switches from "Simple File Aggregates" for sub packages to "Extended File Aggregates" (http://jackrabbit.apache.org/filevault/vaultfs.html) > 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-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=16350279#comment-16350279
]
Konrad Windszus commented on JCRVLT-266:
The PR in https://github.com/apache/jackrabbit-filevault/pull/22 contains a
proposed fix.
> 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
>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=16330167#comment-16330167 ] Konrad Windszus edited comment on JCRVLT-262 at 2/2/18 5:27 PM: There are several issues with upgrading: # all releases since 3.1.38 suffered from pretty serious regressions, namely https://issues.apache.org/jira/browse/JCRVLT-186 in 3.1.40 and https://issues.apache.org/jira/browse/JCRVLT-258 in both 3.1.40 and 3.1.42 # Adobe does not provide an official hotfix in its commercial product AEM containing a newer version Apart from that the workaround does not do any harm (even in newer instances). It just switches from "Simple File Aggregates" for sub packages to "Extended File Aggregates" (http://jackrabbit.apache.org/filevault/vaultfs.html). Actually the generated package is now closer to what the package manager would generate since the package manager always uses Extended File Aggregates. was (Author: kwin): There are several issues with upgrading: # all releases since 3.1.38 suffered from pretty serious regressions, namely https://issues.apache.org/jira/browse/JCRVLT-186 in 3.1.40 and https://issues.apache.org/jira/browse/JCRVLT-258 in both 3.1.40 and 3.1.42 # Adobe does not provide an official hotfix in its commercial product AEM containing a newer version Apart from that the workaround does not do any harm (even in newer instances). It just switches from "Simple File Aggregates" for sub packages to "Extended File Aggregates" (http://jackrabbit.apache.org/filevault/vaultfs.html) > 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] [Created] (JCRVLT-266) DocViewSaxFormatter does not always emit namespace declaration for "jcr"
Konrad Windszus created JCRVLT-266:
--
Summary: 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
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] [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=16350136#comment-16350136
]
Konrad Windszus commented on JCRVLT-266:
The code in
https://github.com/apache/jackrabbit-filevault/blob/e12e38a69f2ea404f24d965918467dffb4db8e09/vault-core/src/main/java/org/apache/jackrabbit/vault/fs/impl/AggregateImpl.java#L401
must be extended to always return {{jcr}} as prefix.
> 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
>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] [Commented] (JCR-3923) Repository root doesn't respect rep:glob
[
https://issues.apache.org/jira/browse/JCR-3923?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16348902#comment-16348902
]
Konrad Windszus commented on JCR-3923:
--
[~anchela] Thanks a lot for your hints. In our case it seems indeed like we are
using a {{rep:glob}} with a leading "/". Could you reference some documentation
which states how the rep:glob is exactly taken into consideration (which makes
it obvious that the rep:glob should never start with a "/")?
> Repository root doesn't respect rep:glob
>
>
> Key: JCR-3923
> URL: https://issues.apache.org/jira/browse/JCR-3923
> Project: Jackrabbit Content Repository
> Issue Type: Bug
>Reporter: Kamil
>Priority: Major
>
> I have following node structure:
> {noformat}
> /test
> /test/child
> /foo
> {noformat}
> When I set Principal based privileges to some user as:
> {noformat}
> Map restrictions = new HashMap();
> ValueFactory vf = session.getValueFactory();
> restrictions.put("rep:nodePath", vf.createValue("/test", PropertyType.PATH));
> restrictions.put("rep:glob", vf.createValue(""));
>
> jacl.addEntry(principal, privileges, allow, restrictions);
>
> acManager.setPolicy(jacl.getPath(), jacl);
> session.save();
> {noformat}
> where according to this documentation
> http://jackrabbit.apache.org/api/2.2/org/apache/jackrabbit/core/security/authorization/GlobPattern.html
> empty string means "matches /foo only", user can see only:
> {noformat}
> /test
> {noformat}
> without a child, which is correct. But when I set:
> {noformat}
> Map restrictions = new HashMap();
> ValueFactory vf = session.getValueFactory();
> restrictions.put("rep:nodePath", vf.createValue("/", PropertyType.PATH));
> restrictions.put("rep:glob", vf.createValue(""));
>
> jacl.addEntry(principal, privileges, allow, restrictions);
>
> acManager.setPolicy(jacl.getPath(), jacl);
> session.save();
> {noformat}
> then user can see all descendants of root:
> {noformat}
> /test
> /test/child
> /foo
> {noformat}
> which is not correct
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (JCR-3923) Repository root doesn't respect rep:glob
[
https://issues.apache.org/jira/browse/JCR-3923?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16348945#comment-16348945
]
Konrad Windszus commented on JCR-3923:
--
Done in https://issues.apache.org/jira/browse/OAK-7233.
> Repository root doesn't respect rep:glob
>
>
> Key: JCR-3923
> URL: https://issues.apache.org/jira/browse/JCR-3923
> Project: Jackrabbit Content Repository
> Issue Type: Bug
>Reporter: Kamil
>Priority: Major
>
> I have following node structure:
> {noformat}
> /test
> /test/child
> /foo
> {noformat}
> When I set Principal based privileges to some user as:
> {noformat}
> Map restrictions = new HashMap();
> ValueFactory vf = session.getValueFactory();
> restrictions.put("rep:nodePath", vf.createValue("/test", PropertyType.PATH));
> restrictions.put("rep:glob", vf.createValue(""));
>
> jacl.addEntry(principal, privileges, allow, restrictions);
>
> acManager.setPolicy(jacl.getPath(), jacl);
> session.save();
> {noformat}
> where according to this documentation
> http://jackrabbit.apache.org/api/2.2/org/apache/jackrabbit/core/security/authorization/GlobPattern.html
> empty string means "matches /foo only", user can see only:
> {noformat}
> /test
> {noformat}
> without a child, which is correct. But when I set:
> {noformat}
> Map restrictions = new HashMap();
> ValueFactory vf = session.getValueFactory();
> restrictions.put("rep:nodePath", vf.createValue("/", PropertyType.PATH));
> restrictions.put("rep:glob", vf.createValue(""));
>
> jacl.addEntry(principal, privileges, allow, restrictions);
>
> acManager.setPolicy(jacl.getPath(), jacl);
> session.save();
> {noformat}
> then user can see all descendants of root:
> {noformat}
> /test
> /test/child
> /foo
> {noformat}
> which is not correct
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (JCR-3923) Repository root doesn't respect rep:glob
[
https://issues.apache.org/jira/browse/JCR-3923?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16348748#comment-16348748
]
Konrad Windszus commented on JCR-3923:
--
We are running into the same issue with Oak (1.6.2). Is this a known issue?
> Repository root doesn't respect rep:glob
>
>
> Key: JCR-3923
> URL: https://issues.apache.org/jira/browse/JCR-3923
> Project: Jackrabbit Content Repository
> Issue Type: Bug
>Reporter: Kamil
>Priority: Major
>
> I have following node structure:
> {noformat}
> /test
> /test/child
> /foo
> {noformat}
> When I set Principal based privileges to some user as:
> {noformat}
> Map restrictions = new HashMap();
> ValueFactory vf = session.getValueFactory();
> restrictions.put("rep:nodePath", vf.createValue("/test", PropertyType.PATH));
> restrictions.put("rep:glob", vf.createValue(""));
>
> jacl.addEntry(principal, privileges, allow, restrictions);
>
> acManager.setPolicy(jacl.getPath(), jacl);
> session.save();
> {noformat}
> where according to this documentation
> http://jackrabbit.apache.org/api/2.2/org/apache/jackrabbit/core/security/authorization/GlobPattern.html
> empty string means "matches /foo only", user can see only:
> {noformat}
> /test
> {noformat}
> without a child, which is correct. But when I set:
> {noformat}
> Map restrictions = new HashMap();
> ValueFactory vf = session.getValueFactory();
> restrictions.put("rep:nodePath", vf.createValue("/", PropertyType.PATH));
> restrictions.put("rep:glob", vf.createValue(""));
>
> jacl.addEntry(principal, privileges, allow, restrictions);
>
> acManager.setPolicy(jacl.getPath(), jacl);
> session.save();
> {noformat}
> then user can see all descendants of root:
> {noformat}
> /test
> /test/child
> /foo
> {noformat}
> which is not correct
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (JCR-3923) Repository root doesn't respect rep:glob
[
https://issues.apache.org/jira/browse/JCR-3923?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16348902#comment-16348902
]
Konrad Windszus edited comment on JCR-3923 at 2/1/18 5:00 PM:
--
[~anchela] Thanks a lot for your hints. In our case it seems indeed like we are
using a {{rep:glob}} with a leading "/". Could you reference some documentation
which states how the rep:glob is exactly taken into consideration (which makes
it obvious that the rep:glob should never start with a "/")? The examples at
https://jackrabbit.apache.org/oak/docs/security/authorization/restriction.html#Examples
are not clear enough. Maybe that could be extended with an example for the
root node.
was (Author: kwin):
[~anchela] Thanks a lot for your hints. In our case it seems indeed like we are
using a {{rep:glob}} with a leading "/". Could you reference some documentation
which states how the rep:glob is exactly taken into consideration (which makes
it obvious that the rep:glob should never start with a "/")?
> Repository root doesn't respect rep:glob
>
>
> Key: JCR-3923
> URL: https://issues.apache.org/jira/browse/JCR-3923
> Project: Jackrabbit Content Repository
> Issue Type: Bug
>Reporter: Kamil
>Priority: Major
>
> I have following node structure:
> {noformat}
> /test
> /test/child
> /foo
> {noformat}
> When I set Principal based privileges to some user as:
> {noformat}
> Map restrictions = new HashMap();
> ValueFactory vf = session.getValueFactory();
> restrictions.put("rep:nodePath", vf.createValue("/test", PropertyType.PATH));
> restrictions.put("rep:glob", vf.createValue(""));
>
> jacl.addEntry(principal, privileges, allow, restrictions);
>
> acManager.setPolicy(jacl.getPath(), jacl);
> session.save();
> {noformat}
> where according to this documentation
> http://jackrabbit.apache.org/api/2.2/org/apache/jackrabbit/core/security/authorization/GlobPattern.html
> empty string means "matches /foo only", user can see only:
> {noformat}
> /test
> {noformat}
> without a child, which is correct. But when I set:
> {noformat}
> Map restrictions = new HashMap();
> ValueFactory vf = session.getValueFactory();
> restrictions.put("rep:nodePath", vf.createValue("/", PropertyType.PATH));
> restrictions.put("rep:glob", vf.createValue(""));
>
> jacl.addEntry(principal, privileges, allow, restrictions);
>
> acManager.setPolicy(jacl.getPath(), jacl);
> session.save();
> {noformat}
> then user can see all descendants of root:
> {noformat}
> /test
> /test/child
> /foo
> {noformat}
> which is not correct
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (JCRVLT-264) installing a newer version of a "multi-package" might fail with extracted sub-packages.
[ https://issues.apache.org/jira/browse/JCRVLT-264?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16344534#comment-16344534 ] Konrad Windszus commented on JCRVLT-264: I think this is also caused by JCRVLT-177. > installing a newer version of a "multi-package" might fail with extracted > sub-packages. > --- > > Key: JCRVLT-264 > URL: https://issues.apache.org/jira/browse/JCRVLT-264 > Project: Jackrabbit FileVault > Issue Type: Bug > Components: Packaging >Reporter: Tobias Bocanegra >Assignee: Tobias Bocanegra >Priority: Major > > - consider the package: A-1.0, with the sub-package, S-1.0. > - consider the package: A-2.0, with the sub-package, S-1.0. > - A also has content, so it is not a pure container package > perform: > - extract subpackages will add a dependency to A-1.0 on S (because A is not a > pure container package). > - install A and S > now perform the "update": > - extract subpackages will add a dependency to A-2.0 on S (because A is not a > pure container package). > - install A and S, but S will fail, because A is no longer on version 1.0 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[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] [Commented] (JCRVLT-255) ImportModes act on file serialization level not on node level
[
https://issues.apache.org/jira/browse/JCRVLT-255?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16353532#comment-16353532
]
Konrad Windszus commented on JCRVLT-255:
[~tripod] Ping?
> ImportModes act on file serialization level not on node level
> -
>
> Key: JCRVLT-255
> URL: https://issues.apache.org/jira/browse/JCRVLT-255
> Project: Jackrabbit FileVault
> Issue Type: Improvement
>Reporter: Konrad Windszus
>Priority: Major
>
> When reading the docs at
> http://jackrabbit.apache.org/filevault/importmode.html I would assume that
> for {{ImportMode.MERGE}} the merging happens on node level (i.e. indepent of
> the actual serialization format). Unfortunately this is not the case: If I
> have a serialized docview {{.content.xml}} file covering the current node and
> three levels below the merging is not done if the entry node level does
> already exist in the repository, although not all child nodes are in the
> repository yet.
> This is due to the guard in
> https://github.com/apache/jackrabbit-filevault/blob/8b2fedaf329b3bf4a049e41563c0bc83487406f7/vault-core/src/main/java/org/apache/jackrabbit/vault/fs/impl/io/FileArtifactHandler.java#L226.
> which prevents the DocViewSAXImporter from kicking in, although there are
> indeed subnodes in the {{.content.xml}} which are not yet in the repository.
> Please either fix this behaviour of make the documentation at
> http://jackrabbit.apache.org/filevault/importmode.html clearer because it
> explicitly says there:
> {quote}
> It is important to note, that the import mode always operates on entire nodes
> and subtrees...
> {quote}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (JCRVLT-274) Package Maven Plugin: Support multiple types as filter within embedded section
[
https://issues.apache.org/jira/browse/JCRVLT-274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16367490#comment-16367490
]
Konrad Windszus edited comment on JCRVLT-274 at 2/17/18 11:08 AM:
--
To make it more consistent and flexible the same approach should be applied to
{{classifier}}.
was (Author: kwin):
To make it more consistent and flexible the same approach should be applied to
{{scope}} and {{classifier}}.
> Package Maven Plugin: Support multiple types as filter within embedded section
> --
>
> Key: JCRVLT-274
> URL: https://issues.apache.org/jira/browse/JCRVLT-274
> Project: Jackrabbit FileVault
> Issue Type: Improvement
> Components: package maven plugin
>Affects Versions: package-maven-plugin-1.0.1
>Reporter: Konrad Windszus
>Priority: Major
>
> Currently the {{embeddeds}} complex parameter only allows the {{groupId}} or
> {{artifactId}} have complex pattern values. That would be useful as well for
> the {{type}} (which is currently just based on plain string equality) because
> bundles in general may either have type {{jar}} or {{bundle}}. Both make
> sense in this context, therefore it is probably useful to configure both
> types in a generic parent pom.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (JCRVLT-274) Package Maven Plugin: Support multiple types as filter within embedded section
[
https://issues.apache.org/jira/browse/JCRVLT-274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16368188#comment-16368188
]
Konrad Windszus commented on JCRVLT-274:
https://github.com/apache/jackrabbit-filevault-package-maven-plugin/pull/12
> Package Maven Plugin: Support multiple types as filter within embedded section
> --
>
> Key: JCRVLT-274
> URL: https://issues.apache.org/jira/browse/JCRVLT-274
> Project: Jackrabbit FileVault
> Issue Type: Improvement
> Components: package maven plugin
>Affects Versions: package-maven-plugin-1.0.1
>Reporter: Konrad Windszus
>Priority: Major
>
> Currently the {{embeddeds}} complex parameter only allows the {{groupId}} or
> {{artifactId}} have complex pattern values. That would be useful as well for
> the {{type}} (which is currently just based on plain string equality) because
> bundles in general may either have type {{jar}} or {{bundle}}. Both make
> sense in this context, therefore it is probably useful to configure both
> types in a generic parent pom.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (JCRVLT-274) Package Maven Plugin: Support multiple types as filter within embedded section
[
https://issues.apache.org/jira/browse/JCRVLT-274?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konrad Windszus updated JCRVLT-274:
---
Status: Patch Available (was: Open)
> Package Maven Plugin: Support multiple types as filter within embedded section
> --
>
> Key: JCRVLT-274
> URL: https://issues.apache.org/jira/browse/JCRVLT-274
> Project: Jackrabbit FileVault
> Issue Type: Improvement
> Components: package maven plugin
>Affects Versions: package-maven-plugin-1.0.1
>Reporter: Konrad Windszus
>Priority: Major
>
> Currently the {{embeddeds}} complex parameter only allows the {{groupId}} or
> {{artifactId}} have complex pattern values. That would be useful as well for
> the {{type}} (which is currently just based on plain string equality) because
> bundles in general may either have type {{jar}} or {{bundle}}. Both make
> sense in this context, therefore it is probably useful to configure both
> types in a generic parent pom.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (JCR-4260) jackrabbit-filevault-package-maven-plugin can fail with "Access denied" or "...taget/classes"
[
https://issues.apache.org/jira/browse/JCR-4260?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16366890#comment-16366890
]
Konrad Windszus commented on JCR-4260:
--
Please move this issue to https://issues.apache.org/jira/projects/JCRVLT.
> jackrabbit-filevault-package-maven-plugin can fail with "Access denied" or
> "...taget/classes"
> -
>
> Key: JCR-4260
> URL: https://issues.apache.org/jira/browse/JCR-4260
> Project: Jackrabbit Content Repository
> Issue Type: Bug
> Components: maven
>Reporter: Olaf Otto
>Priority: Minor
>
> In a multi-module maven setup, when building without installing the
> artifacts, e.g. running
> {code:java}
> mvn install -DskipTests=true -Dmaven.javadoc.skip=true -B -V{code}
> Followed by
> {code:java}
> mvn test -B{code}
> The following exception arises when the module build has an embedded
> dependency to another module of the same project:
> {code:java}
> [ERROR] Failed to execute goal
> org.apache.jackrabbit:filevault-package-maven-plugin:1.0.1:analyze-classes
> (default-analyze-classes) on ...
> imports: \target\classes (Access is denied) -> [Help 1]
>
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal org.apache.jackrabbit:filevault-package-maven-plugin:1.0.
> o.neba.neba-delivery-aem: Error while analysing imports
>
> --- snipp ---
>
> ... 20 more
>
> Caused by: java.io.FileNotFoundException: \target\classes
> (Access is denied)
> at java.util.zip.ZipFile.open(Native Method)
>
> at java.util.zip.ZipFile.(ZipFile.java:225)
>
> at java.util.zip.ZipFile.(ZipFile.java:155)
>
> at java.util.jar.JarFile.(JarFile.java:166)
>
> at java.util.jar.JarFile.(JarFile.java:130)
>
> at
> org.apache.jackrabbit.filevault.maven.packaging.impl.ImportPackageBuilder$BundleInfo.(ImportPackageBuilder.java:477)
>
> at
> org.apache.jackrabbit.filevault.maven.packaging.impl.ImportPackageBuilder$BundleInfo.(ImportPackageBuilder.java:469)
>
> at
> org.apache.jackrabbit.filevault.maven.packaging.impl.ImportPackageBuilder.scanBundles(ImportPackageBuilder.java:348)
>
> at
> org.apache.jackrabbit.filevault.maven.packaging.impl.ImportPackageBuilder.analyze(ImportPackageBuilder.java:192)
>
> at
> org.apache.jackrabbit.filevault.maven.packaging.AnalyzeClassesMojo.execute(AnalyzeClassesMojo.java:97)
>
> {code}
> This is caused by the Mojo's assumption that artifact dependencies of type
> "jar" are always represented by a jar file, whereas they _may_ be represented
> by directories in case of a dependency to another module within a
> multi-module setup that has no installed artifact yet, as common during
> snapshot development.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (JCRVLT-273) Embeddeds: Make all filter criteria optional
Konrad Windszus created JCRVLT-273:
--
Summary: Embeddeds: Make all filter criteria optional
Key: JCRVLT-273
URL: https://issues.apache.org/jira/browse/JCRVLT-273
Project: Jackrabbit FileVault
Issue Type: Improvement
Components: package maven plugin
Affects Versions: package-maven-plugin-1.0.1
Reporter: Konrad Windszus
Currently the filter criterion {{groupId}} and {{artifactId}} are mandatory
below the {{embeddeds}}. This is contradicting the javadoc and is also no
compatible with {{content-package-maven-plugin}} version 0.5.24 from Adobe
behaved.
Both should be imho optional, so that it is possible e.g. to embed all
dependencies sharing a certain groupId or embed all dependencies with a certain
artifactId irrespective of the groupId.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (JCRVLT-273) Embeddeds: Make all filter criteria optional
[
https://issues.apache.org/jira/browse/JCRVLT-273?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16366955#comment-16366955
]
Konrad Windszus commented on JCRVLT-273:
Actually this should already be the case as {{StringFilterSet.contains()}}
returns {{true}} for empty filters
(https://github.com/apache/jackrabbit-filevault-package-maven-plugin/blob/trunk/src/main/java/org/apache/jackrabbit/filevault/maven/packaging/impl/StringFilterSet.java#L45)
> Embeddeds: Make all filter criteria optional
>
>
> Key: JCRVLT-273
> URL: https://issues.apache.org/jira/browse/JCRVLT-273
> Project: Jackrabbit FileVault
> Issue Type: Improvement
> Components: package maven plugin
>Affects Versions: package-maven-plugin-1.0.1
>Reporter: Konrad Windszus
>Priority: Major
>
> Currently the filter criterion {{groupId}} and {{artifactId}} are mandatory
> below the {{embeddeds}}. This is contradicting the javadoc and is also no
> compatible with {{content-package-maven-plugin}} version 0.5.24 from Adobe
> behaved.
> Both should be imho optional, so that it is possible e.g. to embed all
> dependencies sharing a certain groupId or embed all dependencies with a
> certain artifactId irrespective of the groupId.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (JCRVLT-251) Child nodes mentioned in parent node's docview xml are not cleared correctly during installation
[
https://issues.apache.org/jira/browse/JCRVLT-251?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16365484#comment-16365484
]
Konrad Windszus commented on JCRVLT-251:
[~tripod] IMHO the description for "empty elements" in
https://github.com/apache/jackrabbit-filevault/commit/fed689102dbb2fb50eeb60ef946331bdbd03c303
is not clear enough. It doesn't explicitly state that empty nodes are left
untouched during the import (independent of the merge mode). That is crucial to
know in this context.
> Child nodes mentioned in parent node's docview xml are not cleared correctly
> during installation
>
>
> Key: JCRVLT-251
> URL: https://issues.apache.org/jira/browse/JCRVLT-251
> Project: Jackrabbit FileVault
> Issue Type: Bug
> Components: Packaging
>Affects Versions: 3.1.42
>Reporter: Konrad Windszus
>Priority: Major
> Fix For: 3.1.44
>
>
> If a repository contains the following structure
> {code}
> + testroot [nt:unstructured]
> + testchild [nt:unstructured]
> - property: value (String)
> {code}
> And a package is being installed there containing a {{.content.xml}} file
> below folder {{/testroot}} with the following content only
> {code}
>
> http://sling.apache.org/jcr/sling/1.0;
> xmlns:jcr="http://www.jcp.org/jcr/1.0; xmlns:rep="internal"
> jcr:primaryType="nt:unstructured">
>
>
> {code}
> and a {{filter.xml}} like this
> {code}
>
>
>
>
> {code}
> and apart from that no further files/folders, the repository child node at
> {{/testroot/testchild}} is not correctly cleared, i.e. the property with name
> "property" and value "value" is still there after installation.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (JCRVLT-271) Support a CLI command to format vault xml files
[ https://issues.apache.org/jira/browse/JCRVLT-271?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16365977#comment-16365977 ] Konrad Windszus commented on JCRVLT-271: The only open question is: Is there a reliable way to calculate the same order of the properties as for the case of a push/pull roundtrip with FileVault. I couldn't find any hint in the JCR specs on the order of properties but maybe the order is predictable somehow (at least with Oak). > Support a CLI command to format vault xml files > --- > > Key: JCRVLT-271 > URL: https://issues.apache.org/jira/browse/JCRVLT-271 > Project: Jackrabbit FileVault > Issue Type: New Feature > Components: Misc >Reporter: Dirk Rudolph >Priority: Major > > In our projects we work with vlt IDE integrations (Intellij and Eclpise) to > have an easy and feature rich development process. On the other hand there > are situations where we are writing vlt xml files manually. To not have huge > diffs of formatting changes we tend to commit those vlt xml files formatted > in the way as they are produced by exporting the corresponding nodes from a > remote repository. > Unfortunately the format can not fully be achieved by formatting using the > build in xml formatters of the IDE, nor am I aware of any tooling that would > allow us to check the formatting using lets say a commit hook or maven > plugin. So the common approach we use at the moment is to push and afterwards > pull nodes to or from the remote repository. > To improve that, only formatting the local files with the format the export > uses is much more efficient and can also be automated. > This is a proposal to introduce a _format_ command for the vlt-cli that: > * accepts a list of file patterns that should be processed in the current > directory tree > * formats each file included by the patterns or > * checks if the file is in the right format and fails if not with a list of > all malformed files > This can then be used to: > * automatically format by cli invocation > * validate the format during build or as pre commit hook -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (JCRVLT-246) Generate metadata like filter.xml and properties.xml in dedicated goal
[
https://issues.apache.org/jira/browse/JCRVLT-246?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16365902#comment-16365902
]
Konrad Windszus commented on JCRVLT-246:
The question is what is all considered metadata. E.g. the manifest in the
package is also metadata but it gets data from the the Maven phase
{{process-classes}} for the {{import-packages}} manifest header. So either
# this goal must be bound to a phase {{process-classes}} or later or
# the manifest would still only be generated with the {{package}} goal
> Generate metadata like filter.xml and properties.xml in dedicated goal
> --
>
> Key: JCRVLT-246
> URL: https://issues.apache.org/jira/browse/JCRVLT-246
> Project: Jackrabbit FileVault
> Issue Type: Improvement
> Components: package maven plugin
>Affects Versions: package-maven-plugin-1.0.0
>Reporter: Konrad Windszus
>Priority: Major
>
> To support better IDE integration it would be beneficial if all the metadata
> for content-packages (like filter.xml or properties.xml) would be generated
> in a dedicated goal (by default bound to phase generate-resources). That goal
> should also support m2e integration
> (http://www.eclipse.org/m2e/documentation/m2e-making-maven-plugins-compat.html).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (JCRVLT-275) Docker build and docker image for filevault
[ https://issues.apache.org/jira/browse/JCRVLT-275?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16371498#comment-16371498 ] Konrad Windszus commented on JCRVLT-275: FileVault is a self-contained java based tool which directly runs on every OS. For me using docker to execute it seems to much of an overhead. Why not rather publish the JAR via bintray? > Docker build and docker image for filevault > --- > > Key: JCRVLT-275 > URL: https://issues.apache.org/jira/browse/JCRVLT-275 > Project: Jackrabbit FileVault > Issue Type: Improvement > Components: Packaging, vlt >Affects Versions: 3.1.42 >Reporter: Ioan Eugen Stan >Priority: Major > > I believe it will improve FileVault usage if we make it easier for users to > consume the software. > One way to achieve this is to publlish binary artifacts. > Docker makes this easy to. > I've published patches in a PR on Github > [https://github.com/apache/jackrabbit-filevault/pull/25] . > Docker file contains a multi-stage docker build: > Stage 1: builds FileVault binary using official maven openjdk image > Stage 2: Creates a FileVault image that can be published via automated builds > on docker hub. > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (JCRVLT-276) Switch to timezone designators being understood by ISO8601.parse(...)
[
https://issues.apache.org/jira/browse/JCRVLT-276?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konrad Windszus updated JCRVLT-276:
---
Issue Type: Bug (was: Improvement)
> Switch to timezone designators being understood by ISO8601.parse(...)
> -
>
> Key: JCRVLT-276
> URL: https://issues.apache.org/jira/browse/JCRVLT-276
> Project: Jackrabbit FileVault
> Issue Type: Bug
> Components: package maven plugin
>Affects Versions: package-maven-plugin-1.0.1
>Reporter: Konrad Windszus
>Priority: Major
>
> Currently in
> https://github.com/apache/jackrabbit-filevault-package-maven-plugin/blob/trunk/src/main/java/org/apache/jackrabbit/filevault/maven/packaging/VaultMojo.java#L1038
> an unsupported timezone designator is being used which leads to the fact
> that the creation date cannot be evaluated via
> {{JcrPackageDefinition.getCreated()}} and this always returns {{null}}.
> Supported designators are e.g. {{±hh:mm}}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (JCRVLT-276) Switch to timezone designators being understood by ISO8601.parse(...)
Konrad Windszus created JCRVLT-276:
--
Summary: Switch to timezone designators being understood by
ISO8601.parse(...)
Key: JCRVLT-276
URL: https://issues.apache.org/jira/browse/JCRVLT-276
Project: Jackrabbit FileVault
Issue Type: Improvement
Components: package maven plugin
Affects Versions: package-maven-plugin-1.0.1
Reporter: Konrad Windszus
Currently in
https://github.com/apache/jackrabbit-filevault-package-maven-plugin/blob/trunk/src/main/java/org/apache/jackrabbit/filevault/maven/packaging/VaultMojo.java#L1038
an unsupported timezone designator is being used which leads to the fact that
the creation date cannot be evaluated via {{JcrPackageDefinition.getCreated()}}
and this always returns {{null}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (JCRVLT-276) Switch to timezone designators being understood by ISO8601.parse(...)
[
https://issues.apache.org/jira/browse/JCRVLT-276?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konrad Windszus updated JCRVLT-276:
---
Description:
Currently in
https://github.com/apache/jackrabbit-filevault-package-maven-plugin/blob/trunk/src/main/java/org/apache/jackrabbit/filevault/maven/packaging/VaultMojo.java#L1038
an unsupported timezone designator is being used which leads to the fact that
the creation date cannot be evaluated via {{JcrPackageDefinition.getCreated()}}
and this always returns {{null}}.
Supported designators are e.g. {{±hh:mm}}
was:Currently in
https://github.com/apache/jackrabbit-filevault-package-maven-plugin/blob/trunk/src/main/java/org/apache/jackrabbit/filevault/maven/packaging/VaultMojo.java#L1038
an unsupported timezone designator is being used which leads to the fact that
the creation date cannot be evaluated via {{JcrPackageDefinition.getCreated()}}
and this always returns {{null}}.
> Switch to timezone designators being understood by ISO8601.parse(...)
> -
>
> Key: JCRVLT-276
> URL: https://issues.apache.org/jira/browse/JCRVLT-276
> Project: Jackrabbit FileVault
> Issue Type: Improvement
> Components: package maven plugin
>Affects Versions: package-maven-plugin-1.0.1
>Reporter: Konrad Windszus
>Priority: Major
>
> Currently in
> https://github.com/apache/jackrabbit-filevault-package-maven-plugin/blob/trunk/src/main/java/org/apache/jackrabbit/filevault/maven/packaging/VaultMojo.java#L1038
> an unsupported timezone designator is being used which leads to the fact
> that the creation date cannot be evaluated via
> {{JcrPackageDefinition.getCreated()}} and this always returns {{null}}.
> Supported designators are e.g. {{±hh:mm}}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (JCR-4267) ISO8601.parse should support timezone designators in the form ±hhmm and ±hh
Konrad Windszus created JCR-4267:
Summary: ISO8601.parse should support timezone designators in the
form ±hhmm and ±hh
Key: JCR-4267
URL: https://issues.apache.org/jira/browse/JCR-4267
Project: Jackrabbit Content Repository
Issue Type: Improvement
Components: jackrabbit-jcr-commons
Affects Versions: 2.17.1
Reporter: Konrad Windszus
Currently the ISO8601.parse
(https://github.com/apache/jackrabbit/blob/86e15df24c68c8132361466c80f65862f8709880/jackrabbit-jcr-commons/src/main/java/org/apache/jackrabbit/util/ISO8601.java#L86)
method only supports a subset of time designators being specified by ISO8601.
Namely the ones {{±hhmm}} and {{±hh}} are missing.
This is currently a problem for Jackrabbit Filevault Maven Package, as that is
using these designators in
https://github.com/apache/jackrabbit-filevault-package-maven-plugin/blob/f53c53102e97d0bb000794ee2976cabecf62e5ad/src/main/java/org/apache/jackrabbit/filevault/maven/packaging/VaultMojo.java#L1038.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (JCRVLT-274) Package Maven Plugin: Support multiple types as filter within embedded section
Konrad Windszus created JCRVLT-274:
--
Summary: Package Maven Plugin: Support multiple types as filter
within embedded section
Key: JCRVLT-274
URL: https://issues.apache.org/jira/browse/JCRVLT-274
Project: Jackrabbit FileVault
Issue Type: Improvement
Components: package maven plugin
Affects Versions: package-maven-plugin-1.0.1
Reporter: Konrad Windszus
Currently the {{embeddeds}} complex parameter only allows the {{groupId}} or
{{artifactId}} have complex pattern values. That would be useful as well for
the {{type}} (which is currently just based on plain string equality) because
bundles in general may either have type {{jar}} or {{bundle}}. Both make sense
in this context, therefore it is probably useful to configure both types in a
generic parent pom.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (JCRVLT-274) Package Maven Plugin: Support multiple types as filter within embedded section
[
https://issues.apache.org/jira/browse/JCRVLT-274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16367490#comment-16367490
]
Konrad Windszus commented on JCRVLT-274:
To make it more consistent and flexible the same approach should be applied to
{{scope}} and {{classifier}}.
> Package Maven Plugin: Support multiple types as filter within embedded section
> --
>
> Key: JCRVLT-274
> URL: https://issues.apache.org/jira/browse/JCRVLT-274
> Project: Jackrabbit FileVault
> Issue Type: Improvement
> Components: package maven plugin
>Affects Versions: package-maven-plugin-1.0.1
>Reporter: Konrad Windszus
>Priority: Major
>
> Currently the {{embeddeds}} complex parameter only allows the {{groupId}} or
> {{artifactId}} have complex pattern values. That would be useful as well for
> the {{type}} (which is currently just based on plain string equality) because
> bundles in general may either have type {{jar}} or {{bundle}}. Both make
> sense in this context, therefore it is probably useful to configure both
> types in a generic parent pom.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (JCRVLT-274) Package Maven Plugin: Support multiple types as filter within embedded section
[
https://issues.apache.org/jira/browse/JCRVLT-274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16367487#comment-16367487
]
Konrad Windszus commented on JCRVLT-274:
To achieve this the Class of {{type}} within {{Embedded}} just needs to be
modified from {{String}} to {{StringFilterSet}}.
> Package Maven Plugin: Support multiple types as filter within embedded section
> --
>
> Key: JCRVLT-274
> URL: https://issues.apache.org/jira/browse/JCRVLT-274
> Project: Jackrabbit FileVault
> Issue Type: Improvement
> Components: package maven plugin
>Affects Versions: package-maven-plugin-1.0.1
>Reporter: Konrad Windszus
>Priority: Major
>
> Currently the {{embeddeds}} complex parameter only allows the {{groupId}} or
> {{artifactId}} have complex pattern values. That would be useful as well for
> the {{type}} (which is currently just based on plain string equality) because
> bundles in general may either have type {{jar}} or {{bundle}}. Both make
> sense in this context, therefore it is probably useful to configure both
> types in a generic parent pom.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (JCRVLT-273) Embeddeds: Make all filter criteria optional
[
https://issues.apache.org/jira/browse/JCRVLT-273?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konrad Windszus resolved JCRVLT-273.
Resolution: Invalid
> Embeddeds: Make all filter criteria optional
>
>
> Key: JCRVLT-273
> URL: https://issues.apache.org/jira/browse/JCRVLT-273
> Project: Jackrabbit FileVault
> Issue Type: Improvement
> Components: package maven plugin
>Affects Versions: package-maven-plugin-1.0.1
>Reporter: Konrad Windszus
>Priority: Major
>
> Currently the filter criterion {{groupId}} and {{artifactId}} are mandatory
> below the {{embeddeds}}. This is contradicting the javadoc and is also no
> compatible with {{content-package-maven-plugin}} version 0.5.24 from Adobe
> behaved.
> Both should be imho optional, so that it is possible e.g. to embed all
> dependencies sharing a certain groupId or embed all dependencies with a
> certain artifactId irrespective of the groupId.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (JCRVLT-195) Support OSGi bundle dependencies
[ https://issues.apache.org/jira/browse/JCRVLT-195?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16371724#comment-16371724 ] Konrad Windszus commented on JCRVLT-195: https://issues.apache.org/jira/browse/SLING-3747 needs to be considered in the context as well, as by default the package manager stops all JCR Installer activities while installing a package. That is a problem for packages containing all necessary stuff as subpackages, because in that case the bundles would then only become deployed after the package have been extracted. > Support OSGi bundle dependencies > > > Key: JCRVLT-195 > URL: https://issues.apache.org/jira/browse/JCRVLT-195 > Project: Jackrabbit FileVault > Issue Type: Improvement > Components: Packaging >Reporter: Konrad Windszus >Assignee: Tobias Bocanegra >Priority: Major > > FileVault Packages support both internal and external hooks. Internal hooks > are JARs which are part of the package itself. External hooks are provided > through some classloader (usually through the Bundle Classloader in an OSGi > context, https://issues.apache.org/jira/browse/JCRVLT-116). Installing a > package depending on an external hook class which is not found, leads to an > error. > Therefore it would be beneficial to explicitly add a dependency from the > package referencing an external hook towards the OSGi bundle providing the > hook. Only that way it can be assured, that the installation of this package > is deferred until that bundle providing the hook is finally active. Currently > only package dependencies are supported though, which are not enough, as > there is a delay until the embedded bundle in a package is deployed as well. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (JCRVLT-315) Improve error message in case of embedding invalid sub packages
[
https://issues.apache.org/jira/browse/JCRVLT-315?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konrad Windszus updated JCRVLT-315:
---
Status: Patch Available (was: Open)
> Improve error message in case of embedding invalid sub packages
> ---
>
> Key: JCRVLT-315
> URL: https://issues.apache.org/jira/browse/JCRVLT-315
> Project: Jackrabbit FileVault
> Issue Type: Improvement
> Components: package maven plugin
>Affects Versions: package-maven-plugin-1.0.1
>Reporter: Konrad Windszus
>Priority: Major
> Fix For: package-maven-plugin-1.0.2
>
>
> Currently the error message being emitted for invalid ZIP files referenced as
> sub packages is pretty confusing. It is lacking the original ZIP file name.
> An example error message looks like this
> {code}
> [INFO] --- filevault-package-maven-plugin:1.0.2-SNAPSHOT:generate-metadata
> (default-generate-metadata) @ completepackage ---
> [INFO] Embedding --- Sub Packages:
> groupId=,artifactId=,type=zip,classifier=,filter=true,excludeTransitive=false
> ---
> [INFO]
>
> [INFO] BUILD FAILURE
> [INFO]
>
> [INFO] Total time: 2.061 s
> [INFO] Finished at: 2018-08-10T16:35:09+02:00
> [INFO]
>
> [ERROR] Failed to execute goal
> org.apache.jackrabbit:filevault-package-maven-plugin:1.0.2-SNAPSHOT:generate-metadata
> (default-generate-metadata) on project completepackage:
> java.util.zip.ZipException: zip file is empty -> [Help 1]
> {code}
> It is completely lacking the source file name of the sub package which was
> supposed to be embedded.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (JCRVLT-315) Improve error message in case of embedding invalid sub packages
Konrad Windszus created JCRVLT-315:
--
Summary: Improve error message in case of embedding invalid sub
packages
Key: JCRVLT-315
URL: https://issues.apache.org/jira/browse/JCRVLT-315
Project: Jackrabbit FileVault
Issue Type: Improvement
Components: package maven plugin
Affects Versions: package-maven-plugin-1.0.1
Reporter: Konrad Windszus
Fix For: package-maven-plugin-1.0.2
Currently the error message being emitted for invalid ZIP files referenced as
sub packages is pretty confusing. It is lacking the original ZIP file name.
An example error message looks like this
{code}
[INFO] --- filevault-package-maven-plugin:1.0.2-SNAPSHOT:generate-metadata
(default-generate-metadata) @ completepackage ---
[INFO] Embedding --- Sub Packages:
groupId=,artifactId=,type=zip,classifier=,filter=true,excludeTransitive=false
---
[INFO]
[INFO] BUILD FAILURE
[INFO]
[INFO] Total time: 2.061 s
[INFO] Finished at: 2018-08-10T16:35:09+02:00
[INFO]
[ERROR] Failed to execute goal
org.apache.jackrabbit:filevault-package-maven-plugin:1.0.2-SNAPSHOT:generate-metadata
(default-generate-metadata) on project completepackage:
java.util.zip.ZipException: zip file is empty -> [Help 1]
{code}
It is completely lacking the source file name of the sub package which was
supposed to be embedded.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (JCRVLT-316) Add dedicated parameter to specify subPackageHandling
Konrad Windszus created JCRVLT-316:
--
Summary: Add dedicated parameter to specify subPackageHandling
Key: JCRVLT-316
URL: https://issues.apache.org/jira/browse/JCRVLT-316
Project: Jackrabbit FileVault
Issue Type: Improvement
Components: package maven plugin
Affects Versions: package-maven-plugin-1.0.1
Reporter: Konrad Windszus
Fix For: package-maven-plugin-1.0.2
Currently the {{subPackageHandling}} need to be specified as string value below
the {{properties}} parameter. Similar to the {{accessControlHandling}} there
should be a strongly typed parameter for that.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (JCRVLT-288) Support XML Docview formatting in a dedicated goal
[
https://issues.apache.org/jira/browse/JCRVLT-288?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16576322#comment-16576322
]
Konrad Windszus edited comment on JCRVLT-288 at 8/11/18 10:19 AM:
--
After upgrading the PR
https://github.com/apache/jackrabbit-filevault-package-maven-plugin/pull/15 to
the FileVault 3.2.0 (release version) I get the following failures in some ITs
{code}
[INFO] Running org.apache.jackrabbit.filevault.maven.packaging.it.FilterIT
[ERROR] Tests run: 13, Failures: 2, Errors: 0, Skipped: 0, Time elapsed: 59.063
s <<< FAILURE! - in org.apache.jackrabbit.filevault.maven.packaging.it.FilterIT
[ERROR]
test_merge_inline_filter_with_metainf(org.apache.jackrabbit.filevault.maven.packaging.it.FilterIT)
Time elapsed: 7.496 s <<< FAILURE!
org.junit.ComparisonFailure:
filter.xml is correct expected:<...
{code}
while the actual filter.xml looks with FileVault 3.2.0 like this
{code}
{code}
So the entry from the filter.xml given via {{META-INF/vault/filter.xml}} is
simply missing.
[~tripod] Can you check whether there is a regression in FileVault 3.2.0 with
regards to filter merging? (maybe it is caused by
https://github.com/apache/jackrabbit-filevault/commit/6e6e22518aff2ced79ebbf300cca9dfdb7d6697e)
was (Author: kwin):
After upgrading the PR
https://github.com/apache/jackrabbit-filevault-package-maven-plugin/pull/15 to
the FileVault 3.2.0 (release version) I get the following failures in some ITs
{code}
[INFO] Running org.apache.jackrabbit.filevault.maven.packaging.it.FilterIT
[ERROR] Tests run: 13, Failures: 2, Errors: 0, Skipped: 0, Time elapsed: 59.063
s <<< FAILURE! - in org.apache.jackrabbit.filevault.maven.packaging.it.FilterIT
[ERROR]
test_merge_inline_filter_with_metainf(org.apache.jackrabbit.filevault.maven.packaging.it.FilterIT)
Time elapsed: 7.496 s <<< FAILURE!
org.junit.ComparisonFailure:
filter.xml is correct expected:<...
{code}
while the actual filter.xml looks with FileVault 3.2.0 like this
{code}
{code}
So the entry from the filter.xml given via {{META-INF/vault/filter.xml}} is
simply missing.
[~tripod] Can you check whether there is a regression in FileVault 3.2.0 with
regards to filter merging?
> Support XML Docview formatting in a dedicated goal
> --
>
> Key: JCRVLT-288
> URL: https://issues.apache.org/jira/browse/JCRVLT-288
> Project: Jackrabbit FileVault
> Issue Type: Improvement
> Components: package maven plugin
>Affects Versions: package-maven-plugin-1.0.1
>Reporter: Konrad Windszus
>Priority: Major
> Fix For: package-maven-plugin-1.0.2
>
>
> There should be a dedicated goal which either formats XML files according to
> the Jackrabbit Filevault Docview XML format or only check if files are
> compliant with that format (e.g. for CI servers). The goal should support m2e
> properly (i.e. support emitting error messages or reformatting source files
> in an incremental build)
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (JCRVLT-288) Support XML Docview formatting in a dedicated goal
[
https://issues.apache.org/jira/browse/JCRVLT-288?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16576322#comment-16576322
]
Konrad Windszus edited comment on JCRVLT-288 at 8/11/18 10:15 AM:
--
After upgrading the PR
https://github.com/apache/jackrabbit-filevault-package-maven-plugin/pull/15 to
the FileVault 3.2.0 (release version) I get the following failures in some ITs
{code}
[INFO] Running org.apache.jackrabbit.filevault.maven.packaging.it.FilterIT
[ERROR] Tests run: 13, Failures: 2, Errors: 0, Skipped: 0, Time elapsed: 59.063
s <<< FAILURE! - in org.apache.jackrabbit.filevault.maven.packaging.it.FilterIT
[ERROR]
test_merge_inline_filter_with_metainf(org.apache.jackrabbit.filevault.maven.packaging.it.FilterIT)
Time elapsed: 7.496 s <<< FAILURE!
org.junit.ComparisonFailure:
filter.xml is correct expected:<...
{code}
while the actual filter.xml looks with FileVault 3.2.0 like this
{code}
{code}
So the entry from the filter.xml given via {{META-INF/vault/filter.xml}} is
simply missing.
[~tripod] Can you check whether there is a regression in FileVault 3.2.0 with
regards to filter merging?
was (Author: kwin):
After upgrading the PR
https://github.com/apache/jackrabbit-filevault-package-maven-plugin/pull/15 to
the FileVault 3.2.0 (release version) I get the following failures in some ITs
{code}
[INFO] Running org.apache.jackrabbit.filevault.maven.packaging.it.FilterIT
[ERROR] Tests run: 13, Failures: 2, Errors: 0, Skipped: 0, Time elapsed: 59.063
s <<< FAILURE! - in org.apache.jackrabbit.filevault.maven.packaging.it.FilterIT
[ERROR]
test_merge_inline_filter_with_metainf(org.apache.jackrabbit.filevault.maven.packaging.it.FilterIT)
Time elapsed: 7.496 s <<< FAILURE!
org.junit.ComparisonFailure:
filter.xml is correct expected:<...
https://issues.apache.org/jira/browse/JCRVLT-288
> Project: Jackrabbit FileVault
> Issue Type: Improvement
> Components: package maven plugin
>Affects Versions: package-maven-plugin-1.0.1
>Reporter: Konrad Windszus
>Priority: Major
> Fix For: package-maven-plugin-1.0.2
>
>
> There should be a dedicated goal which either formats XML files according to
> the Jackrabbit Filevault Docview XML format or only check if files are
> compliant with that format (e.g. for CI servers). The goal should support m2e
> properly (i.e. support emitting error messages or reformatting source files
> in an incremental build)
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (JCRVLT-288) Support XML Docview formatting in a dedicated goal
[
https://issues.apache.org/jira/browse/JCRVLT-288?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16577127#comment-16577127
]
Konrad Windszus commented on JCRVLT-288:
Ok, the root cause of this regression is that in the lines where the filter is
being copied:
https://github.com/apache/jackrabbit-filevault-package-maven-plugin/blob/e19e9f904569a0c2c68b1031e26e9aa88021b9ff/src/main/java/org/apache/jackrabbit/filevault/maven/packaging/GenerateMetadataMojo.java#L534
only the {{nodesFilterSet}} and {{propertiesFilterSet}} is filled, but not the
{{referenceFilterSets}}.
> Support XML Docview formatting in a dedicated goal
> --
>
> Key: JCRVLT-288
> URL: https://issues.apache.org/jira/browse/JCRVLT-288
> Project: Jackrabbit FileVault
> Issue Type: Improvement
> Components: package maven plugin
>Affects Versions: package-maven-plugin-1.0.1
>Reporter: Konrad Windszus
>Priority: Major
> Fix For: package-maven-plugin-1.0.2
>
>
> There should be a dedicated goal which either formats XML files according to
> the Jackrabbit Filevault Docview XML format or only check if files are
> compliant with that format (e.g. for CI servers). The goal should support m2e
> properly (i.e. support emitting error messages or reformatting source files
> in an incremental build)
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (JCRVLT-288) Support XML Docview formatting in a dedicated goal
[ https://issues.apache.org/jira/browse/JCRVLT-288?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16577138#comment-16577138 ] Konrad Windszus commented on JCRVLT-288: I provided a fix in the PR in https://github.com/apache/jackrabbit-filevault-package-maven-plugin/pull/15/commits/b2a459c744c4433ced6de93daf954400b8a72caf. Now the ITs are back to green! > Support XML Docview formatting in a dedicated goal > -- > > Key: JCRVLT-288 > URL: https://issues.apache.org/jira/browse/JCRVLT-288 > Project: Jackrabbit FileVault > Issue Type: Improvement > Components: package maven plugin >Affects Versions: package-maven-plugin-1.0.1 >Reporter: Konrad Windszus >Priority: Major > Fix For: package-maven-plugin-1.0.2 > > > There should be a dedicated goal which either formats XML files according to > the Jackrabbit Filevault Docview XML format or only check if files are > compliant with that format (e.g. for CI servers). The goal should support m2e > properly (i.e. support emitting error messages or reformatting source files > in an incremental build) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (JCRVLT-288) Support XML Docview formatting in a dedicated goal
[
https://issues.apache.org/jira/browse/JCRVLT-288?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16576322#comment-16576322
]
Konrad Windszus commented on JCRVLT-288:
After upgrading the PR
https://github.com/apache/jackrabbit-filevault-package-maven-plugin/pull/15 to
the FileVault 3.2.0 (release version) I get the following failures in some ITs
{code}
[INFO] Running org.apache.jackrabbit.filevault.maven.packaging.it.FilterIT
[ERROR] Tests run: 13, Failures: 2, Errors: 0, Skipped: 0, Time elapsed: 59.063
s <<< FAILURE! - in org.apache.jackrabbit.filevault.maven.packaging.it.FilterIT
[ERROR]
test_merge_inline_filter_with_metainf(org.apache.jackrabbit.filevault.maven.packaging.it.FilterIT)
Time elapsed: 7.496 s <<< FAILURE!
org.junit.ComparisonFailure:
filter.xml is correct expected:<...
https://issues.apache.org/jira/browse/JCRVLT-288
> Project: Jackrabbit FileVault
> Issue Type: Improvement
> Components: package maven plugin
>Affects Versions: package-maven-plugin-1.0.1
>Reporter: Konrad Windszus
>Priority: Major
> Fix For: package-maven-plugin-1.0.2
>
>
> There should be a dedicated goal which either formats XML files according to
> the Jackrabbit Filevault Docview XML format or only check if files are
> compliant with that format (e.g. for CI servers). The goal should support m2e
> properly (i.e. support emitting error messages or reformatting source files
> in an incremental build)
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (JCRVLT-268) filevaultMavenPlugin: scanning for oak index does not work on windows systems
[
https://issues.apache.org/jira/browse/JCRVLT-268?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16594733#comment-16594733
]
Konrad Windszus commented on JCRVLT-268:
I provided a PR in
https://github.com/apache/jackrabbit-filevault-package-maven-plugin/pull/17.
[~tripod] Can you quickly cross-check?
> filevaultMavenPlugin: scanning for oak index does not work on windows systems
> -
>
> Key: JCRVLT-268
> URL: https://issues.apache.org/jira/browse/JCRVLT-268
> Project: Jackrabbit FileVault
> Issue Type: Bug
> Components: package maven plugin
>Reporter: Lukas Kummer
>Priority: Minor
> Attachments: screenshot-windows.png
>
>
> on windows systems oak indexes are always added to the filter, and
> allowIndexDefinitions has no effect. The reason for this is a static String
> comparison in class FileValidator ~Line 72:
> {code:java}
> } else if ("META-INF/vault/filter.xml".equals(artifactName) ||
> artifactName.contains("/_oak_index/")) {
> {code}
> See attached screenshot, why comparison fails on Windows:
> !screenshot-windows.png!
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (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:all-tabpanel ] Konrad Windszus resolved JCRVLT-262. Resolution: Won't Fix > 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-316) Add dedicated parameter to specify subPackageHandling
[
https://issues.apache.org/jira/browse/JCRVLT-316?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16592920#comment-16592920
]
Konrad Windszus commented on JCRVLT-316:
This is not as useful as it might sound, as long as
https://issues.apache.org/jira/browse/MPLUGIN-308 is not solved.
> Add dedicated parameter to specify subPackageHandling
> -
>
> Key: JCRVLT-316
> URL: https://issues.apache.org/jira/browse/JCRVLT-316
> Project: Jackrabbit FileVault
> Issue Type: Improvement
> Components: package maven plugin
>Affects Versions: package-maven-plugin-1.0.1
>Reporter: Konrad Windszus
>Priority: Major
>
> Currently the {{subPackageHandling}} need to be specified as string value
> below the {{properties}} parameter. Similar to the {{accessControlHandling}}
> there should be a strongly typed parameter for that.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (JCRVLT-316) Add dedicated parameter to specify subPackageHandling
[
https://issues.apache.org/jira/browse/JCRVLT-316?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konrad Windszus updated JCRVLT-316:
---
Fix Version/s: (was: package-maven-plugin-1.0.2)
> Add dedicated parameter to specify subPackageHandling
> -
>
> Key: JCRVLT-316
> URL: https://issues.apache.org/jira/browse/JCRVLT-316
> Project: Jackrabbit FileVault
> Issue Type: Improvement
> Components: package maven plugin
>Affects Versions: package-maven-plugin-1.0.1
>Reporter: Konrad Windszus
>Priority: Major
>
> Currently the {{subPackageHandling}} need to be specified as string value
> below the {{properties}} parameter. Similar to the {{accessControlHandling}}
> there should be a strongly typed parameter for that.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (JCRVLT-288) Support XML Docview formatting in a dedicated goal
[ https://issues.apache.org/jira/browse/JCRVLT-288?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Konrad Windszus updated JCRVLT-288: --- Issue Type: New Feature (was: Improvement) > Support XML Docview formatting in a dedicated goal > -- > > Key: JCRVLT-288 > URL: https://issues.apache.org/jira/browse/JCRVLT-288 > Project: Jackrabbit FileVault > Issue Type: New Feature > Components: package maven plugin >Affects Versions: package-maven-plugin-1.0.1 >Reporter: Konrad Windszus >Priority: Major > Fix For: package-maven-plugin-1.0.2 > > > There should be a dedicated goal which either formats XML files according to > the Jackrabbit Filevault Docview XML format or only check if files are > compliant with that format (e.g. for CI servers). The goal should support m2e > properly (i.e. support emitting error messages or reformatting source files > in an incremental build) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (JCRVLT-300) vlt-rcp: Support proxy
[
https://issues.apache.org/jira/browse/JCRVLT-300?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konrad Windszus updated JCRVLT-300:
---
Fix Version/s: 3.2
> vlt-rcp: Support proxy
> --
>
> Key: JCRVLT-300
> URL: https://issues.apache.org/jira/browse/JCRVLT-300
> Project: Jackrabbit FileVault
> Issue Type: Bug
> Components: RCP
>Affects Versions: 3.1.44
>Reporter: Konrad Windszus
>Priority: Major
> Fix For: 3.2
>
>
> Currently it is not possible to explicity configure an HTTP proxy (either via
> dedicated parameters or generic system variables). The underlying problem is
> the lack of support in spi2dav tracked in JCR-3211.
> The error message looks like this
> {code}
> 12:52:56 [DEBUG] Opening connection {}->:4502
> 12:52:56 [DEBUG] http-outgoing-0: Shutdown connection
> 12:52:56 [DEBUG] Connection discarded
> 12:52:56 [DEBUG] Connection released: [id: 0][route:
> {}->:4502][total kept alive: 0; route allocated: 0 of 20; total
> allocated: 0 of 20]
> 12:52:56 [DEBUG] Cancelling request execution
> 12:52:56 [ERROR] Error while retrieving src repository
> :4502/crx/server/-/jcr:root/:
> javax.jcr.RepositoryException: java.net.UnknownHostException: :
> System error
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (JCRVLT-300) vlt-rcp: Support proxy
[
https://issues.apache.org/jira/browse/JCRVLT-300?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16542895#comment-16542895
]
Konrad Windszus commented on JCRVLT-300:
Since this has been implemented in Jackrabbit now, the only change to be done
in FileVault would be to increase the dependency of jackrabbit to at least
2.16.3 in
https://github.com/apache/jackrabbit-filevault/blob/6df76ba4a45316a84ec1cd10636296d191a82260/parent/pom.xml#L43.
In addition the feature needs to be enabled via the system property
{{jackrabbit.client.useSystemProperties=true}} (not sure whether rcp should
always set this and then always rely on the java net environment variables or
only on demand).
> vlt-rcp: Support proxy
> --
>
> Key: JCRVLT-300
> URL: https://issues.apache.org/jira/browse/JCRVLT-300
> Project: Jackrabbit FileVault
> Issue Type: Bug
> Components: RCP
>Affects Versions: 3.1.44
>Reporter: Konrad Windszus
>Priority: Major
> Fix For: 3.2
>
>
> Currently it is not possible to explicity configure an HTTP proxy (either via
> dedicated parameters or generic system variables). The underlying problem is
> the lack of support in spi2dav tracked in JCR-3211.
> The error message looks like this
> {code}
> 12:52:56 [DEBUG] Opening connection {}->:4502
> 12:52:56 [DEBUG] http-outgoing-0: Shutdown connection
> 12:52:56 [DEBUG] Connection discarded
> 12:52:56 [DEBUG] Connection released: [id: 0][route:
> {}->:4502][total kept alive: 0; route allocated: 0 of 20; total
> allocated: 0 of 20]
> 12:52:56 [DEBUG] Cancelling request execution
> 12:52:56 [ERROR] Error while retrieving src repository
> :4502/crx/server/-/jcr:root/:
> javax.jcr.RepositoryException: java.net.UnknownHostException: :
> System error
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (JCRVLT-262) Implement workaround for JCRVLT-177 when creating subpackages
Konrad Windszus created JCRVLT-262: -- Summary: 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 Environment: Due to bug JCRVLT-177 all package metadata (like filters or dependencies) of subpackages are not correctly overwritten (when updating a SNAPSHOT version package). 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. Reporter: Konrad Windszus -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (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:all-tabpanel ] Konrad Windszus updated JCRVLT-262: --- Description: Due to bug JCRVLT-177 all package metadata (like filters or dependencies) of subpackages are not correctly overwritten (when updating a SNAPSHOT version package). 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. was: Due to bug JCRVLT-177 all package metadata (like filters or dependencies) of subpackages are not correctly overwritten (when updating a SNAPSHOT version package). 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. > 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). > 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] [Updated] (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:all-tabpanel ] Konrad Windszus updated JCRVLT-262: --- Description: 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. was: 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 < ). 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. > 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] [Updated] (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:all-tabpanel ] Konrad Windszus updated JCRVLT-262: --- Description: 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 < ). 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. was: Due to bug JCRVLT-177 all package metadata (like filters or dependencies) of subpackages are not correctly overwritten (when updating a SNAPSHOT version package). 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. > 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 < ). > 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] [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=16328691#comment-16328691
]
Konrad Windszus edited comment on JCRVLT-262 at 1/17/18 12:46 PM:
--
The proposed workaround would place a {{.content.xml}} in a sibling folder to
the subpackage's zip named {{}} having the following
content
{code}
http://www.jcp.org/jcr/1.0;
jcr:primaryType="nt:file">
{code}
was (Author: kwin):
The proposed workaround would place a {{.content.xml}} in a sibling folder to
the ZIP named {{}} having the following content
{code}
http://www.jcp.org/jcr/1.0;
jcr:primaryType="nt:file">
{code}
> 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] [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=16328691#comment-16328691
]
Konrad Windszus edited comment on JCRVLT-262 at 1/17/18 12:46 PM:
--
The proposed workaround would place a {{.content.xml}} in a sibling folder to
the ZIP named {{}} having the following content
{code}
http://www.jcp.org/jcr/1.0;
jcr:primaryType="nt:file">
{code}
was (Author: kwin):
The proposed workaround would place a {{.content.xml}} in a sibling folder to
the ZIP named {{}} having the following content
{code}
http://www.day.com/jcr/vault/1.0;
xmlns:jcr="http://www.jcp.org/jcr/1.0; xmlns:nt="http://www.jcp.org/jcr/nt/1.0;
jcr:primaryType="nt:file">
{code}
> 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] [Updated] (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:all-tabpanel ] Konrad Windszus updated JCRVLT-262: --- Description: Due to bug JCRVLT-177 all package metadata (like filters or dependencies) of subpackages are not correctly overwritten (when updating a SNAPSHOT version package). 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. > 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). > 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. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (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:all-tabpanel ] Konrad Windszus updated JCRVLT-262: --- Environment: (was: Due to bug JCRVLT-177 all package metadata (like filters or dependencies) of subpackages are not correctly overwritten (when updating a SNAPSHOT version package). 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.) > 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 > -- 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=16328691#comment-16328691
]
Konrad Windszus commented on JCRVLT-262:
The proposed workaround would place a {{.content.xml}} in a sibling folder to
the ZIP named {{}} having the following content
{code}
http://www.day.com/jcr/vault/1.0;
xmlns:jcr="http://www.jcp.org/jcr/1.0; xmlns:nt="http://www.jcp.org/jcr/nt/1.0;
jcr:primaryType="nt:file">
{code}
> 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-281) Packaging a 400mb 0-byte nt:file is not compressed
[ https://issues.apache.org/jira/browse/JCRVLT-281?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16400066#comment-16400066 ] Konrad Windszus commented on JCRVLT-281: Are you sure that this is not JCRVLT-258? > Packaging a 400mb 0-byte nt:file is not compressed > -- > > Key: JCRVLT-281 > URL: https://issues.apache.org/jira/browse/JCRVLT-281 > Project: Jackrabbit FileVault > Issue Type: Improvement > Components: Packaging >Affects Versions: 3.1.40 >Reporter: Tobias Bocanegra >Priority: Major > Fix For: 3.1.44 > > > creating a nt:file with no mimetype and a 400mb 0-byte data, results in a > 400mb package. prior to JCRVLT-163 it was compressed to 400kb. > todo: add test case > /cc [~marett] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (JCRVLT-246) Generate metadata like filter.xml and properties.xml in dedicated goal
[ https://issues.apache.org/jira/browse/JCRVLT-246?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16423987#comment-16423987 ] Konrad Windszus commented on JCRVLT-246: To be able to run some kind of validation in incremental builds it is often crucial to have the metadata of the packages at hand. That is impossible if the metadata is generated in the same goal as the package itself, as e.g. m2e will never execute the phase "package" during incremental builds for performance reasons. For another concrete example just look at https://issues.apache.org/jira/browse/SLING-6344. In the Sling IDE we want to rely on filter files being generated by this plugin. Regarding your comment bq. it really rips the entire logic apart and results in spaghetti code with weird dependencies between the mojos. That depends a bit on the perspective I guess. I would argue that separating the packaging from the metadata generation makes the code in general a bit cleaner. But of course there are some properties which are being used for both goals. Also the file map needs to be passed from one goal to the other, but this is similar to the import packages which are right now also being calculated in a dedicated goal (the only difference is that those are being passed as generated file and not as Maven properties) > Generate metadata like filter.xml and properties.xml in dedicated goal > -- > > Key: JCRVLT-246 > URL: https://issues.apache.org/jira/browse/JCRVLT-246 > Project: Jackrabbit FileVault > Issue Type: Improvement > Components: package maven plugin >Affects Versions: package-maven-plugin-1.0.0 >Reporter: Konrad Windszus >Priority: Major > > To support IDE integration better it would be beneficial if all the metadata > for content-packages (like filter.xml or properties.xml) would be generated > in a dedicated goal (by default bound to phase generate-resources). That goal > should also support m2e integration > (http://www.eclipse.org/m2e/documentation/m2e-making-maven-plugins-compat.html). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (JCRVLT-286) Markup in http://jackrabbit.apache.org/filevault/rcp.html broken
Konrad Windszus created JCRVLT-286: -- Summary: Markup in http://jackrabbit.apache.org/filevault/rcp.html broken Key: JCRVLT-286 URL: https://issues.apache.org/jira/browse/JCRVLT-286 Project: Jackrabbit FileVault Issue Type: Improvement Components: vlt Affects Versions: 3.1.44 Reporter: Konrad Windszus The markup for the table below http://jackrabbit.apache.org/filevault/rcp.html#Create_Task_POST is broken. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (JCRVLT-274) Package Maven Plugin: Support multiple types and classifiers as filter within embedded/subpackage section
[
https://issues.apache.org/jira/browse/JCRVLT-274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16425337#comment-16425337
]
Konrad Windszus commented on JCRVLT-274:
[~tripod] I updated the PR at
https://github.com/apache/jackrabbit-filevault-package-maven-plugin/pull/12
after the merge of JCRVLT-246. Can you have a look?
> Package Maven Plugin: Support multiple types and classifiers as filter within
> embedded/subpackage section
> -
>
> Key: JCRVLT-274
> URL: https://issues.apache.org/jira/browse/JCRVLT-274
> Project: Jackrabbit FileVault
> Issue Type: Improvement
> Components: package maven plugin
>Affects Versions: package-maven-plugin-1.0.1
>Reporter: Konrad Windszus
>Priority: Major
>
> Currently the {{embeddeds}} and {{subpackage}} complex parameter only allows
> the {{groupId}} or {{artifactId}} have complex pattern values. That would be
> useful as well for the {{type}} (which is currently just based on plain
> string equality) because bundles in general may either have type {{jar}} or
> {{bundle}}. Both make sense in this context, therefore it is probably useful
> to configure both types in a generic parent pom.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Issue Comment Deleted] (JCRVLT-274) Package Maven Plugin: Support multiple types and classifiers as filter within embedded/subpackage section
[
https://issues.apache.org/jira/browse/JCRVLT-274?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konrad Windszus updated JCRVLT-274:
---
Comment: was deleted
(was: To achieve this the Class of {{type}} within {{Embedded}} just needs to
be modified from {{String}} to {{StringFilterSet}}.)
> Package Maven Plugin: Support multiple types and classifiers as filter within
> embedded/subpackage section
> -
>
> Key: JCRVLT-274
> URL: https://issues.apache.org/jira/browse/JCRVLT-274
> Project: Jackrabbit FileVault
> Issue Type: Improvement
> Components: package maven plugin
>Affects Versions: package-maven-plugin-1.0.1
>Reporter: Konrad Windszus
>Priority: Major
>
> Currently the {{embeddeds}} and {{subpackage}} complex parameter only allows
> the {{groupId}} or {{artifactId}} have complex pattern values. That would be
> useful as well for the {{type}} (which is currently just based on plain
> string equality) because bundles in general may either have type {{jar}} or
> {{bundle}}. Both make sense in this context, therefore it is probably useful
> to configure both types in a generic parent pom.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (JCRVLT-274) Package Maven Plugin: Support multiple types and classifiers as filter within embedded/subpackage section
[
https://issues.apache.org/jira/browse/JCRVLT-274?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konrad Windszus updated JCRVLT-274:
---
Summary: Package Maven Plugin: Support multiple types and classifiers as
filter within embedded/subpackage section (was: Package Maven Plugin: Support
multiple types as filter within embedded section)
> Package Maven Plugin: Support multiple types and classifiers as filter within
> embedded/subpackage section
> -
>
> Key: JCRVLT-274
> URL: https://issues.apache.org/jira/browse/JCRVLT-274
> Project: Jackrabbit FileVault
> Issue Type: Improvement
> Components: package maven plugin
>Affects Versions: package-maven-plugin-1.0.1
>Reporter: Konrad Windszus
>Priority: Major
>
> Currently the {{embeddeds}} complex parameter only allows the {{groupId}} or
> {{artifactId}} have complex pattern values. That would be useful as well for
> the {{type}} (which is currently just based on plain string equality) because
> bundles in general may either have type {{jar}} or {{bundle}}. Both make
> sense in this context, therefore it is probably useful to configure both
> types in a generic parent pom.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (JCRVLT-274) Package Maven Plugin: Support multiple types and classifiers as filter within embedded/subpackage section
[
https://issues.apache.org/jira/browse/JCRVLT-274?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konrad Windszus updated JCRVLT-274:
---
Description: Currently the {{embeddeds}} and {{subpackage}} complex
parameter only allows the {{groupId}} or {{artifactId}} have complex pattern
values. That would be useful as well for the {{type}} (which is currently just
based on plain string equality) because bundles in general may either have type
{{jar}} or {{bundle}}. Both make sense in this context, therefore it is
probably useful to configure both types in a generic parent pom. (was:
Currently the {{embeddeds}} complex parameter only allows the {{groupId}} or
{{artifactId}} have complex pattern values. That would be useful as well for
the {{type}} (which is currently just based on plain string equality) because
bundles in general may either have type {{jar}} or {{bundle}}. Both make sense
in this context, therefore it is probably useful to configure both types in a
generic parent pom.)
> Package Maven Plugin: Support multiple types and classifiers as filter within
> embedded/subpackage section
> -
>
> Key: JCRVLT-274
> URL: https://issues.apache.org/jira/browse/JCRVLT-274
> Project: Jackrabbit FileVault
> Issue Type: Improvement
> Components: package maven plugin
>Affects Versions: package-maven-plugin-1.0.1
>Reporter: Konrad Windszus
>Priority: Major
>
> Currently the {{embeddeds}} and {{subpackage}} complex parameter only allows
> the {{groupId}} or {{artifactId}} have complex pattern values. That would be
> useful as well for the {{type}} (which is currently just based on plain
> string equality) because bundles in general may either have type {{jar}} or
> {{bundle}}. Both make sense in this context, therefore it is probably useful
> to configure both types in a generic parent pom.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (JCRVLT-276) Switch to timezone designators being understood by ISO8601.parse(...)
[
https://issues.apache.org/jira/browse/JCRVLT-276?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16426522#comment-16426522
]
Konrad Windszus commented on JCRVLT-276:
{{o.a.j.util.ISO8601}}
(https://github.com/apache/jackrabbit/blob/trunk/jackrabbit-jcr-commons/src/main/java/org/apache/jackrabbit/util/ISO8601.java)
supports only a subset(!) of the formats defined by ISO8601, namely the ones
listed in http://www.w3.org/TR/NOTE-datetime (compare with JCR-4267 and the
javadoc). As this class is internally being used for
{{JcrPackageDefinition.getCreated()}} the created date being generated by the
package-maven-plugin must comply to this format.
The problem currently is timezone designator.
* Using {{Z}} for {{SimpleDateFormat}}
(https://docs.oracle.com/javase/7/docs/api/java/text/SimpleDateFormat.html)
does not mean Zulu but rather {{Sign TwoDigitHours Minutes}}, e.g. {{+0200}},
this is not supported by {{o.a.j.util.ISO8601}}
* Using {{X}} for {{SimpleDateFormat}}
(https://docs.oracle.com/javase/7/docs/api/java/text/SimpleDateFormat.html)
means {{Sign TwoDigitHours}} or just {{Z}}, e.g. {{+02}}, , this is not
supported by {{o.a.j.util.ISO8601}}
* Only the format {{XXX}} stands for the supported format {{Sign TwoDigitHours
: TwoDigitMinutes}}, e.g. {{+02:00}}
> Switch to timezone designators being understood by ISO8601.parse(...)
> -
>
> Key: JCRVLT-276
> URL: https://issues.apache.org/jira/browse/JCRVLT-276
> Project: Jackrabbit FileVault
> Issue Type: Bug
> Components: package maven plugin
>Affects Versions: package-maven-plugin-1.0.1
>Reporter: Konrad Windszus
>Priority: Major
> Fix For: package-maven-plugin-1.0.2
>
>
> Currently in
> https://github.com/apache/jackrabbit-filevault-package-maven-plugin/blob/trunk/src/main/java/org/apache/jackrabbit/filevault/maven/packaging/VaultMojo.java#L1038
> an unsupported timezone designator is being used which leads to the fact
> that the creation date cannot be evaluated via
> {{JcrPackageDefinition.getCreated()}} and this always returns {{null}}.
> Supported designators are e.g. {{±hh:mm}}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (JCRVLT-279) Emit warning/error in case embedded file/subpackage is overwritten by jcrRootSourceDirectory
[
https://issues.apache.org/jira/browse/JCRVLT-279?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16425570#comment-16425570
]
Konrad Windszus commented on JCRVLT-279:
Actually the files from {{jcrRootSourceDirectory}} are first added to the ZIP
before the embedded files are being added. The reason why the former take
precedence is the {{ContentPackageArchiver}} s duplicate behaviour. By default
this is {{Archiver.DUPLICATES_SKIP}}
(https://codehaus-plexus.github.io/plexus-archiver/apidocs/org/codehaus/plexus/archiver/Archiver.html#setDuplicateBehavior(java.lang.String))
which means that only the first entry is being considered. Instead we should
switch to {{DUPLICATES_FAIL}} to explicitly throw an exception in that case.
> Emit warning/error in case embedded file/subpackage is overwritten by
> jcrRootSourceDirectory
>
>
> Key: JCRVLT-279
> URL: https://issues.apache.org/jira/browse/JCRVLT-279
> Project: Jackrabbit FileVault
> Issue Type: Bug
> Components: package maven plugin
>Affects Versions: package-maven-plugin-1.0.1
>Reporter: Konrad Windszus
>Priority: Minor
>
> Due to errorneous project setup it may sometimes happen that the
> {{jcrRootSourceDirectory}} inadvertently contains the to be embedded file.
> Since the {{jcrRootSourceDirectory}} is having a higher precedence all files
> in there overwrite previously embedded files. In that case a warning/error
> should be emitted. The same for sub packages.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (JCRVLT-276) Switch to timezone designators being understood by ISO8601.parse(...)
[
https://issues.apache.org/jira/browse/JCRVLT-276?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konrad Windszus updated JCRVLT-276:
---
Fix Version/s: package-maven-plugin-1.0.2
Status: Patch Available (was: Open)
I provided a patch with a test in
https://github.com/apache/jackrabbit-filevault-package-maven-plugin/pull/14.
> Switch to timezone designators being understood by ISO8601.parse(...)
> -
>
> Key: JCRVLT-276
> URL: https://issues.apache.org/jira/browse/JCRVLT-276
> Project: Jackrabbit FileVault
> Issue Type: Bug
> Components: package maven plugin
>Affects Versions: package-maven-plugin-1.0.1
>Reporter: Konrad Windszus
>Priority: Major
> Fix For: package-maven-plugin-1.0.2
>
>
> Currently in
> https://github.com/apache/jackrabbit-filevault-package-maven-plugin/blob/trunk/src/main/java/org/apache/jackrabbit/filevault/maven/packaging/VaultMojo.java#L1038
> an unsupported timezone designator is being used which leads to the fact
> that the creation date cannot be evaluated via
> {{JcrPackageDefinition.getCreated()}} and this always returns {{null}}.
> Supported designators are e.g. {{±hh:mm}}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (JCRVLT-279) Emit warning/error in case embedded file/subpackage is overwritten by jcrRootSourceDirectory
[
https://issues.apache.org/jira/browse/JCRVLT-279?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16425837#comment-16425837
]
Konrad Windszus commented on JCRVLT-279:
I added a (currently failing) test case in
https://github.com/apache/jackrabbit-filevault-package-maven-plugin/pull/13.
The fix is not that easy though, as switching to {{Archiver.DUPLICATES_FAIL}}
leads to a lot of false positives due to the logic in
https://github.com/apache/jackrabbit-filevault-package-maven-plugin/blob/f165aac9c02025650d01d1ee6997448c375796fe/src/main/java/org/apache/jackrabbit/filevault/maven/packaging/VaultMojo.java#L237
which potentially adds overlapping filesets. Also in case of overlapping
filter rules false positives may happen. Therefore another solution has to be
found for this issue.
> Emit warning/error in case embedded file/subpackage is overwritten by
> jcrRootSourceDirectory
>
>
> Key: JCRVLT-279
> URL: https://issues.apache.org/jira/browse/JCRVLT-279
> Project: Jackrabbit FileVault
> Issue Type: Bug
> Components: package maven plugin
>Affects Versions: package-maven-plugin-1.0.1
>Reporter: Konrad Windszus
>Priority: Minor
>
> Due to errorneous project setup it may sometimes happen that the
> {{jcrRootSourceDirectory}} inadvertently contains the to be embedded file.
> Since the {{jcrRootSourceDirectory}} is having a higher precedence all files
> in there overwrite previously embedded files. In that case a warning/error
> should be emitted. The same for sub packages.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (JCRVLT-276) Switch to timezone designators being understood by ISO8601.parse(...)
[
https://issues.apache.org/jira/browse/JCRVLT-276?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16425847#comment-16425847
]
Konrad Windszus commented on JCRVLT-276:
Actually {{-MM-dd'T'HH:mm:ss.SSSX}} will lead to the following designator:
{{±hh}} which is not supported either. IMHO rather the following should be used
{{-MM-dd'T'HH:mm:ss.SSSXXX}}
> Switch to timezone designators being understood by ISO8601.parse(...)
> -
>
> Key: JCRVLT-276
> URL: https://issues.apache.org/jira/browse/JCRVLT-276
> Project: Jackrabbit FileVault
> Issue Type: Bug
> Components: package maven plugin
>Affects Versions: package-maven-plugin-1.0.1
>Reporter: Konrad Windszus
>Priority: Major
>
> Currently in
> https://github.com/apache/jackrabbit-filevault-package-maven-plugin/blob/trunk/src/main/java/org/apache/jackrabbit/filevault/maven/packaging/VaultMojo.java#L1038
> an unsupported timezone designator is being used which leads to the fact
> that the creation date cannot be evaluated via
> {{JcrPackageDefinition.getCreated()}} and this always returns {{null}}.
> Supported designators are e.g. {{±hh:mm}}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (JCRVLT-287) Throw exception in case of ACL Importer failures (instead of just logging)
[
https://issues.apache.org/jira/browse/JCRVLT-287?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konrad Windszus updated JCRVLT-287:
---
Summary: Throw exception in case of ACL Importer failures (instead of just
logging) (was: Throw exception in case of ACL Importing fails)
> Throw exception in case of ACL Importer failures (instead of just logging)
> --
>
> Key: JCRVLT-287
> URL: https://issues.apache.org/jira/browse/JCRVLT-287
> Project: Jackrabbit FileVault
> Issue Type: Improvement
> Components: Packaging
>Affects Versions: 3.1.44
>Reporter: Konrad Windszus
>Priority: Major
>
> Currently the {{JackrabbitACLImporter}} just logs any exception trying to
> apply ACLs but this exception is not being propagated to the caller
> (https://github.com/apache/jackrabbit-filevault/blob/0dcf09d58fa40cbe3bc24dcb6a00281123bd5a1c/vault-core/src/main/java/org/apache/jackrabbit/vault/fs/impl/io/JackrabbitACLImporter.java#L160).
> The exception should basically bubble up till JcrPackage.install/extract
> {code}
> org.apache.jackrabbit.vault.fs.impl.io.DocViewSAXImporter Error while
> applying access control content.
> javax.jcr.AccessDeniedException: Access denied.
> at
> org.apache.jackrabbit.oak.spi.security.authorization.accesscontrol.AbstractAccessControlManager.checkPermissions(AbstractAccessControlManager.java:200)
> at
> org.apache.jackrabbit.oak.spi.security.authorization.accesscontrol.AbstractAccessControlManager.getTree(AbstractAccessControlManager.java:167)
> at
> org.apache.jackrabbit.oak.security.authorization.accesscontrol.AccessControlManagerImpl.setPolicy(AccessControlManagerImpl.java:219)
> at
> org.apache.jackrabbit.oak.security.authorization.composite.CompositeAccessControlManager.setPolicy(CompositeAccessControlManager.java:109)
> at
> org.apache.jackrabbit.oak.jcr.delegate.AccessControlManagerDelegator$8.performVoid(AccessControlManagerDelegator.java:132)
> at
> org.apache.jackrabbit.oak.jcr.delegate.SessionDelegate.performVoid(SessionDelegate.java:274)
> at
> org.apache.jackrabbit.oak.jcr.delegate.AccessControlManagerDelegator.setPolicy(AccessControlManagerDelegator.java:129)
> at
> org.apache.jackrabbit.oak.jcr.delegate.JackrabbitAccessControlManagerDelegator.setPolicy(JackrabbitAccessControlManagerDelegator.java:152)
> at
> org.apache.jackrabbit.vault.fs.impl.io.JackrabbitACLImporter$ImportedAcList.apply(JackrabbitACLImporter.java:318)
> at
> org.apache.jackrabbit.vault.fs.impl.io.JackrabbitACLImporter.close(JackrabbitACLImporter.java:158)
> at
> org.apache.jackrabbit.vault.fs.impl.io.DocViewSAXImporter.endElement(DocViewSAXImporter.java:1153)
> at
> com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.endElement(AbstractSAXParser.java:609)
> at
> com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanEndElement(XMLDocumentFragmentScannerImpl.java:1782)
> at
> com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl$FragmentContentDriver.next(XMLDocumentFragmentScannerImpl.java:2967)
> at
> com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl.next(XMLDocumentScannerImpl.java:602)
> at
> com.sun.org.apache.xerces.internal.impl.XMLNSDocumentScannerImpl.next(XMLNSDocumentScannerImpl.java:112)
> at
> com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanDocument(XMLDocumentFragmentScannerImpl.java:505)
> at
> com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:842)
> at
> com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:771)
> at
> com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(XMLParser.java:141)
> at
> com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.parse(AbstractSAXParser.java:1213)
> at
> com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl$JAXPSAXParser.parse(SAXParserImpl.java:643)
> at
> com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl.parse(SAXParserImpl.java:327)
> at
> org.apache.jackrabbit.vault.fs.impl.io.GenericArtifactHandler.accept(GenericArtifactHandler.java:99)
> at org.apache.jackrabbit.vault.fs.io.Importer.commit(Importer.java:879)
> at org.apache.jackrabbit.vault.fs.io.Importer.commit(Importer.java:784)
> at org.apache.jackrabbit.vault.fs.io.Importer.commit(Importer.java:824)
> at org.apache.jackrabbit.vault.fs.io.Importer.commit(Importer.java:824)
> at org.apache.jackrabbit.vault.fs.io.Importer.commit(Importer.java:824)
> at org.apache.jackrabbit.vault.fs.io.Importer.run(Importer.java:425)
> at
>
[jira] [Created] (JCRVLT-287) Throw exception in case of ACL Importing fails
Konrad Windszus created JCRVLT-287:
--
Summary: Throw exception in case of ACL Importing fails
Key: JCRVLT-287
URL: https://issues.apache.org/jira/browse/JCRVLT-287
Project: Jackrabbit FileVault
Issue Type: Improvement
Components: Packaging
Affects Versions: 3.1.44
Reporter: Konrad Windszus
Currently the {{JackrabbitACLImporter}} just logs any exception trying to apply
ACLs but this exception is not being propagated to the caller
(https://github.com/apache/jackrabbit-filevault/blob/0dcf09d58fa40cbe3bc24dcb6a00281123bd5a1c/vault-core/src/main/java/org/apache/jackrabbit/vault/fs/impl/io/JackrabbitACLImporter.java#L160).
The exception should basically bubble up till JcrPackage.install/extract
{code}
org.apache.jackrabbit.vault.fs.impl.io.DocViewSAXImporter Error while applying
access control content.
javax.jcr.AccessDeniedException: Access denied.
at
org.apache.jackrabbit.oak.spi.security.authorization.accesscontrol.AbstractAccessControlManager.checkPermissions(AbstractAccessControlManager.java:200)
at
org.apache.jackrabbit.oak.spi.security.authorization.accesscontrol.AbstractAccessControlManager.getTree(AbstractAccessControlManager.java:167)
at
org.apache.jackrabbit.oak.security.authorization.accesscontrol.AccessControlManagerImpl.setPolicy(AccessControlManagerImpl.java:219)
at
org.apache.jackrabbit.oak.security.authorization.composite.CompositeAccessControlManager.setPolicy(CompositeAccessControlManager.java:109)
at
org.apache.jackrabbit.oak.jcr.delegate.AccessControlManagerDelegator$8.performVoid(AccessControlManagerDelegator.java:132)
at
org.apache.jackrabbit.oak.jcr.delegate.SessionDelegate.performVoid(SessionDelegate.java:274)
at
org.apache.jackrabbit.oak.jcr.delegate.AccessControlManagerDelegator.setPolicy(AccessControlManagerDelegator.java:129)
at
org.apache.jackrabbit.oak.jcr.delegate.JackrabbitAccessControlManagerDelegator.setPolicy(JackrabbitAccessControlManagerDelegator.java:152)
at
org.apache.jackrabbit.vault.fs.impl.io.JackrabbitACLImporter$ImportedAcList.apply(JackrabbitACLImporter.java:318)
at
org.apache.jackrabbit.vault.fs.impl.io.JackrabbitACLImporter.close(JackrabbitACLImporter.java:158)
at
org.apache.jackrabbit.vault.fs.impl.io.DocViewSAXImporter.endElement(DocViewSAXImporter.java:1153)
at
com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.endElement(AbstractSAXParser.java:609)
at
com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanEndElement(XMLDocumentFragmentScannerImpl.java:1782)
at
com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl$FragmentContentDriver.next(XMLDocumentFragmentScannerImpl.java:2967)
at
com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl.next(XMLDocumentScannerImpl.java:602)
at
com.sun.org.apache.xerces.internal.impl.XMLNSDocumentScannerImpl.next(XMLNSDocumentScannerImpl.java:112)
at
com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanDocument(XMLDocumentFragmentScannerImpl.java:505)
at
com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:842)
at
com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:771)
at
com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(XMLParser.java:141)
at
com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.parse(AbstractSAXParser.java:1213)
at
com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl$JAXPSAXParser.parse(SAXParserImpl.java:643)
at
com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl.parse(SAXParserImpl.java:327)
at
org.apache.jackrabbit.vault.fs.impl.io.GenericArtifactHandler.accept(GenericArtifactHandler.java:99)
at org.apache.jackrabbit.vault.fs.io.Importer.commit(Importer.java:879)
at org.apache.jackrabbit.vault.fs.io.Importer.commit(Importer.java:784)
at org.apache.jackrabbit.vault.fs.io.Importer.commit(Importer.java:824)
at org.apache.jackrabbit.vault.fs.io.Importer.commit(Importer.java:824)
at org.apache.jackrabbit.vault.fs.io.Importer.commit(Importer.java:824)
at org.apache.jackrabbit.vault.fs.io.Importer.run(Importer.java:425)
at
org.apache.jackrabbit.vault.packaging.impl.ZipVaultPackage.extract(ZipVaultPackage.java:233)
at
org.apache.jackrabbit.vault.packaging.impl.JcrPackageImpl.extract(JcrPackageImpl.java:398)
at
org.apache.jackrabbit.vault.packaging.impl.JcrPackageImpl.extract(JcrPackageImpl.java:357)
at
org.apache.jackrabbit.vault.packaging.impl.JcrPackageImpl.extract(JcrPackageImpl.java:343)
{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (JCRVLT-287) Throw exception in case of ACL Importer failures (instead of just logging)
[
https://issues.apache.org/jira/browse/JCRVLT-287?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konrad Windszus updated JCRVLT-287:
---
Description:
Currently the {{JackrabbitACLImporter}} just logs any exception which occurs
while trying to apply ACLs but this exception is not being propagated to the
caller
(https://github.com/apache/jackrabbit-filevault/blob/0dcf09d58fa40cbe3bc24dcb6a00281123bd5a1c/vault-core/src/main/java/org/apache/jackrabbit/vault/fs/impl/io/JackrabbitACLImporter.java#L160).
The exception should basically bubble up till {{JcrPackage.install/extract}}
as {{RepositoryException}}!
{code}
org.apache.jackrabbit.vault.fs.impl.io.DocViewSAXImporter Error while applying
access control content.
javax.jcr.AccessDeniedException: Access denied.
at
org.apache.jackrabbit.oak.spi.security.authorization.accesscontrol.AbstractAccessControlManager.checkPermissions(AbstractAccessControlManager.java:200)
at
org.apache.jackrabbit.oak.spi.security.authorization.accesscontrol.AbstractAccessControlManager.getTree(AbstractAccessControlManager.java:167)
at
org.apache.jackrabbit.oak.security.authorization.accesscontrol.AccessControlManagerImpl.setPolicy(AccessControlManagerImpl.java:219)
at
org.apache.jackrabbit.oak.security.authorization.composite.CompositeAccessControlManager.setPolicy(CompositeAccessControlManager.java:109)
at
org.apache.jackrabbit.oak.jcr.delegate.AccessControlManagerDelegator$8.performVoid(AccessControlManagerDelegator.java:132)
at
org.apache.jackrabbit.oak.jcr.delegate.SessionDelegate.performVoid(SessionDelegate.java:274)
at
org.apache.jackrabbit.oak.jcr.delegate.AccessControlManagerDelegator.setPolicy(AccessControlManagerDelegator.java:129)
at
org.apache.jackrabbit.oak.jcr.delegate.JackrabbitAccessControlManagerDelegator.setPolicy(JackrabbitAccessControlManagerDelegator.java:152)
at
org.apache.jackrabbit.vault.fs.impl.io.JackrabbitACLImporter$ImportedAcList.apply(JackrabbitACLImporter.java:318)
at
org.apache.jackrabbit.vault.fs.impl.io.JackrabbitACLImporter.close(JackrabbitACLImporter.java:158)
at
org.apache.jackrabbit.vault.fs.impl.io.DocViewSAXImporter.endElement(DocViewSAXImporter.java:1153)
at
com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.endElement(AbstractSAXParser.java:609)
at
com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanEndElement(XMLDocumentFragmentScannerImpl.java:1782)
at
com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl$FragmentContentDriver.next(XMLDocumentFragmentScannerImpl.java:2967)
at
com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl.next(XMLDocumentScannerImpl.java:602)
at
com.sun.org.apache.xerces.internal.impl.XMLNSDocumentScannerImpl.next(XMLNSDocumentScannerImpl.java:112)
at
com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanDocument(XMLDocumentFragmentScannerImpl.java:505)
at
com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:842)
at
com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:771)
at
com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(XMLParser.java:141)
at
com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.parse(AbstractSAXParser.java:1213)
at
com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl$JAXPSAXParser.parse(SAXParserImpl.java:643)
at
com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl.parse(SAXParserImpl.java:327)
at
org.apache.jackrabbit.vault.fs.impl.io.GenericArtifactHandler.accept(GenericArtifactHandler.java:99)
at org.apache.jackrabbit.vault.fs.io.Importer.commit(Importer.java:879)
at org.apache.jackrabbit.vault.fs.io.Importer.commit(Importer.java:784)
at org.apache.jackrabbit.vault.fs.io.Importer.commit(Importer.java:824)
at org.apache.jackrabbit.vault.fs.io.Importer.commit(Importer.java:824)
at org.apache.jackrabbit.vault.fs.io.Importer.commit(Importer.java:824)
at org.apache.jackrabbit.vault.fs.io.Importer.run(Importer.java:425)
at
org.apache.jackrabbit.vault.packaging.impl.ZipVaultPackage.extract(ZipVaultPackage.java:233)
at
org.apache.jackrabbit.vault.packaging.impl.JcrPackageImpl.extract(JcrPackageImpl.java:398)
at
org.apache.jackrabbit.vault.packaging.impl.JcrPackageImpl.extract(JcrPackageImpl.java:357)
at
org.apache.jackrabbit.vault.packaging.impl.JcrPackageImpl.extract(JcrPackageImpl.java:343)
{code}
was:
Currently the {{JackrabbitACLImporter}} just logs any exception trying to apply
ACLs but this exception is not being propagated to the caller
[jira] [Created] (JCRVLT-288) Support formatting in a dedicated goal
Konrad Windszus created JCRVLT-288: -- Summary: Support formatting in a dedicated goal Key: JCRVLT-288 URL: https://issues.apache.org/jira/browse/JCRVLT-288 Project: Jackrabbit FileVault Issue Type: Improvement Components: package maven plugin Affects Versions: package-maven-plugin-1.0.1 Reporter: Konrad Windszus There should be a dedicated goal which either formats XML files according to the Jackrabbit Filevault Docview XML format or only check if files are compliant with that format (e.g. for CI servers). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (JCRVLT-288) Support XML Docview formatting in a dedicated goal
[ https://issues.apache.org/jira/browse/JCRVLT-288?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Konrad Windszus updated JCRVLT-288: --- Description: There should be a dedicated goal which either formats XML files according to the Jackrabbit Filevault Docview XML format or only check if files are compliant with that format (e.g. for CI servers). The goal should support m2e properly (i.e. support emitting error messages or reformatting source files in an incremental build) (was: There should be a dedicated goal which either formats XML files according to the Jackrabbit Filevault Docview XML format or only check if files are compliant with that format (e.g. for CI servers).) > Support XML Docview formatting in a dedicated goal > -- > > Key: JCRVLT-288 > URL: https://issues.apache.org/jira/browse/JCRVLT-288 > Project: Jackrabbit FileVault > Issue Type: Improvement > Components: package maven plugin >Affects Versions: package-maven-plugin-1.0.1 >Reporter: Konrad Windszus >Priority: Major > > There should be a dedicated goal which either formats XML files according to > the Jackrabbit Filevault Docview XML format or only check if files are > compliant with that format (e.g. for CI servers). The goal should support m2e > properly (i.e. support emitting error messages or reformatting source files > in an incremental build) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (JCRVLT-288) Support XML Docview formatting in a dedicated goal
[ https://issues.apache.org/jira/browse/JCRVLT-288?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Konrad Windszus updated JCRVLT-288: --- Summary: Support XML Docview formatting in a dedicated goal (was: Support formatting in a dedicated goal) > Support XML Docview formatting in a dedicated goal > -- > > Key: JCRVLT-288 > URL: https://issues.apache.org/jira/browse/JCRVLT-288 > Project: Jackrabbit FileVault > Issue Type: Improvement > Components: package maven plugin >Affects Versions: package-maven-plugin-1.0.1 >Reporter: Konrad Windszus >Priority: Major > > There should be a dedicated goal which either formats XML files according to > the Jackrabbit Filevault Docview XML format or only check if files are > compliant with that format (e.g. for CI servers). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (JCRVLT-246) Generate metadata like filter.xml and properties.xml in dedicated goal
[ https://issues.apache.org/jira/browse/JCRVLT-246?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16418885#comment-16418885 ] Konrad Windszus commented on JCRVLT-246: [~tripod] Can you have a look at the PR? > Generate metadata like filter.xml and properties.xml in dedicated goal > -- > > Key: JCRVLT-246 > URL: https://issues.apache.org/jira/browse/JCRVLT-246 > Project: Jackrabbit FileVault > Issue Type: Improvement > Components: package maven plugin >Affects Versions: package-maven-plugin-1.0.0 >Reporter: Konrad Windszus >Priority: Major > > To support IDE integration better it would be beneficial if all the metadata > for content-packages (like filter.xml or properties.xml) would be generated > in a dedicated goal (by default bound to phase generate-resources). That goal > should also support m2e integration > (http://www.eclipse.org/m2e/documentation/m2e-making-maven-plugins-compat.html). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (JCRVLT-279) Emit warning/error in case embedded file/subpackage is overwritten by jcrRootSourceDirectory
Konrad Windszus created JCRVLT-279:
--
Summary: Emit warning/error in case embedded file/subpackage is
overwritten by jcrRootSourceDirectory
Key: JCRVLT-279
URL: https://issues.apache.org/jira/browse/JCRVLT-279
Project: Jackrabbit FileVault
Issue Type: Bug
Components: package maven plugin
Affects Versions: package-maven-plugin-1.0.1
Reporter: Konrad Windszus
Due to errorneous project setup it may sometimes happen that the
{{jcrRootSourceDirectory}} inadvertently contains the to be embedded file.
Since the {{jcrRootSourceDirectory}} is having a higher precedence all files in
there overwrite previously embedded files. In that case a warning/error should
be emitted. The same for sub packages.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
