[jira] [Created] (JCRVLT-673) AggregateImpl: do not collect & sort nodes that will be skipped anyway
Julian Reschke created JCRVLT-673: - Summary: AggregateImpl: do not collect & sort nodes that will be skipped anyway Key: JCRVLT-673 URL: https://issues.apache.org/jira/browse/JCRVLT-673 Project: Jackrabbit FileVault Issue Type: Improvement Components: vlt Reporter: Julian Reschke -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (JCRVLT-673) AggregateImpl: do not collect & sort nodes that will be skipped anyway
[
https://issues.apache.org/jira/browse/JCRVLT-673?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Reschke updated JCRVLT-673:
--
Description:
In {{AggregateImpl.walk()}} we collect all child nodes and sort them by name
(if the collection is unordered).
This happens even for those nodes that will be skipped. This wastes memory and
storage when walking large collections with few included members.
> AggregateImpl: do not collect & sort nodes that will be skipped anyway
> --
>
> Key: JCRVLT-673
> URL: https://issues.apache.org/jira/browse/JCRVLT-673
> Project: Jackrabbit FileVault
> Issue Type: Improvement
> Components: vlt
>Reporter: Julian Reschke
>Priority: Major
>
> In {{AggregateImpl.walk()}} we collect all child nodes and sort them by name
> (if the collection is unordered).
> This happens even for those nodes that will be skipped. This wastes memory
> and storage when walking large collections with few included members.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (JCRVLT-670) Upgrade to commons-collections4
[ https://issues.apache.org/jira/browse/JCRVLT-670?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17647952#comment-17647952 ] Tobias Bocanegra commented on JCRVLT-670: - IIRC, the goal was indeed to reduce the amount of retained memory for the names of the aggregates. for large repos, this was significant. But this was for java 1.4 maybe the string memory handling has improved since then. I think removing the caching is certainly a valid approach. > Upgrade to commons-collections4 > --- > > Key: JCRVLT-670 > URL: https://issues.apache.org/jira/browse/JCRVLT-670 > Project: Jackrabbit FileVault > Issue Type: Task >Reporter: Julian Reschke >Assignee: Julian Reschke >Priority: Minor > > Some code uses the EOLd commons-collections, based on a leaking transitive > dependency from Jackrabbit code. -- This message was sent by Atlassian Jira (v8.20.10#820010)
December 2022 report: draft for review
Hi, The draft for the December 2022 board report is available here: https://jackrabbit.apache.org/jcr/status/board-report-2022-12.html Please review and let me know if something is missing or incorrect. I will submit the report tomorrow. Regards Marcel
[jira] [Commented] (JCRVLT-672) Provide a Version comparison function for "is newer" checks
[ https://issues.apache.org/jira/browse/JCRVLT-672?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17648031#comment-17648031 ] Hans-Peter Stoerr commented on JCRVLT-672: -- [~kwin] : Ouch! It seems I've unknowingly opened a can of worms there. The maven versioning oder specification https://maven.apache.org/pom.html#Version_Order_Specification is amazingly complex when it comes to parsing and comparing the stuff after the first dash. There are also other differences: maven treats 1.0.0 and 1.0 and 1 as the same, Version.compareTo doesn't so far. For a start: maven segments versions differently: in addition to - and . it separates digit sequences from non-digit sequences: 1-1.foo-bar1baz would be split into 1 1 foo bar 1 baz . Moreover the ordering depends on whether the separators are - or . (digit vs. non-digit separation is treated as -). We could change Version.getNormalizedSegments () to also split on digit / non-digit sequences, but it wouldn't be enough to determine the ordering, anyway, and that also would have a risk of breaking something. I guess the only way to be 100% compatible to maven would be to copy e.g. [ComparableVersion.java|https://github.com/apache/maven/blob/maven-3.8.6/maven-artifact/src/main/java/org/apache/maven/artifact/versioning/ComparableVersion.java] as a package private class into org.apache.jackrabbit.vault.packaging and use that for comparisons. That is, obviously, also the easiest way to solve the problem. One problem with this is that the segmentation that is done to compare the versions is not quite compatible with Version.getNormalizedSegments(), which might be confusing at times. Or we could make some kind of compromise that behaves the same for more common things. Do you have any opinions on that which help narrow down the solution space? > Provide a Version comparison function for "is newer" checks > --- > > Key: JCRVLT-672 > URL: https://issues.apache.org/jira/browse/JCRVLT-672 > Project: Jackrabbit FileVault > Issue Type: Improvement >Affects Versions: 3.6.6 >Reporter: Hans-Peter Stoerr >Priority: Minor > > I suggest to add a function to org.apache.jackrabbit.vault.packaging.Version > that provides a sensible partial ordering for checking whether one package is > newer than another. > Background: > [org.apache.jackrabbit.vault.packaging.Version#compareTo|https://github.com/apache/jackrabbit-filevault/blob/jackrabbit-filevault-3.6.6/vault-core/src/main/java/org/apache/jackrabbit/vault/packaging/Version.java#L157] > provides a nice function to sort package versions e.g. for the purpose of > displaying them in a predictable order that is close to the probable > timeline. But sometimes you want an "is newer than" relationship - e.g. for a > sanity check during package installation that you don't install an older over > a newer package. As far as I know, Adobe AEM is actually (ab-)using that > compareTo function for that purpose. That is a problem, because if you deploy > e.g. 1.2.3-SNAPSHOT for a while on a server and then create a release 1.2.3, > it'll refuse automatic installation because it wrongly thinks 1.2.3-SNAPSHOT > is newer than 1.2.3. > Now, obviously you cannot fix that AEM problem here, but you could provide a > function at Version for future use, that would be a nicely useable "is newer > than" relationship for that purpose, and add a comment warning people not to > use Version.compareTo for such a sanity check. That'd be nice for AEM usage, > but also for other package managers, like our [Composum package > manager|https://www.composum.com/home/nodes/pckgmgr.html?pages.locale=de]. > While the ordering of the numerical prefix (which is also implemented by > Version.compareTo) is pretty widely used, there is no widely used ordering > for the suffixes - they could be anything like -SNAPSHOT, -SNAPSHOT-12, -rc1, > -alpha, -testing and whatnot. So it's not possible to give a full order for > that purpose. My suggestion is to provide a partial ordering based on the > numerical prefix, but to ignore the suffix completely. Perhaps provide a > function Version.compareNumericPrefix ? -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (JCRVLT-672) Provide a Version comparison function for "is newer" checks
[ https://issues.apache.org/jira/browse/JCRVLT-672?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17648031#comment-17648031 ] Hans-Peter Stoerr edited comment on JCRVLT-672 at 12/15/22 12:37 PM: - [~kwin] : Ouch! It seems I've unknowingly opened a can of worms there. The maven versioning oder specification [https://maven.apache.org/pom.html#Version_Order_Specification] is amazingly complex when it comes to parsing and comparing the stuff after the first dash. There are also other differences: maven treats 1.0.0 and 1.0 and 1 as the same, Version.compareTo doesn't so far. For a start: maven segments versions differently: in addition to - and . it separates digit sequences from non-digit sequences: 1-1.foo-bar1baz would be split into 1 1 foo bar 1 baz . Moreover the ordering depends on whether the separators are - or . (digit vs. non-digit separation is treated as -). We could change Version.getNormalizedSegments () to also split on digit / non-digit sequences, but it wouldn't be enough to determine the ordering, anyway, and that also would have a risk of breaking something. I guess the only way to be 100% compatible to maven would be to copy e.g. [ComparableVersion.java|https://github.com/apache/maven/blob/maven-3.8.6/maven-artifact/src/main/java/org/apache/maven/artifact/versioning/ComparableVersion.java] as a package private class into org.apache.jackrabbit.vault.packaging and use that for comparisons. That is, obviously, also the easiest way to solve the problem. One problem with this is that the segmentation that is done to compare the versions is not quite compatible with Version.getNormalizedSegments(), which might be confusing at times. Or we could make some kind of compromise that behaves the same for more common things. Do you have any opinions on that which help me narrow down the solution space? was (Author: hanspeterstoerr): [~kwin] : Ouch! It seems I've unknowingly opened a can of worms there. The maven versioning oder specification https://maven.apache.org/pom.html#Version_Order_Specification is amazingly complex when it comes to parsing and comparing the stuff after the first dash. There are also other differences: maven treats 1.0.0 and 1.0 and 1 as the same, Version.compareTo doesn't so far. For a start: maven segments versions differently: in addition to - and . it separates digit sequences from non-digit sequences: 1-1.foo-bar1baz would be split into 1 1 foo bar 1 baz . Moreover the ordering depends on whether the separators are - or . (digit vs. non-digit separation is treated as -). We could change Version.getNormalizedSegments () to also split on digit / non-digit sequences, but it wouldn't be enough to determine the ordering, anyway, and that also would have a risk of breaking something. I guess the only way to be 100% compatible to maven would be to copy e.g. [ComparableVersion.java|https://github.com/apache/maven/blob/maven-3.8.6/maven-artifact/src/main/java/org/apache/maven/artifact/versioning/ComparableVersion.java] as a package private class into org.apache.jackrabbit.vault.packaging and use that for comparisons. That is, obviously, also the easiest way to solve the problem. One problem with this is that the segmentation that is done to compare the versions is not quite compatible with Version.getNormalizedSegments(), which might be confusing at times. Or we could make some kind of compromise that behaves the same for more common things. Do you have any opinions on that which help narrow down the solution space? > Provide a Version comparison function for "is newer" checks > --- > > Key: JCRVLT-672 > URL: https://issues.apache.org/jira/browse/JCRVLT-672 > Project: Jackrabbit FileVault > Issue Type: Improvement >Affects Versions: 3.6.6 >Reporter: Hans-Peter Stoerr >Priority: Minor > > I suggest to add a function to org.apache.jackrabbit.vault.packaging.Version > that provides a sensible partial ordering for checking whether one package is > newer than another. > Background: > [org.apache.jackrabbit.vault.packaging.Version#compareTo|https://github.com/apache/jackrabbit-filevault/blob/jackrabbit-filevault-3.6.6/vault-core/src/main/java/org/apache/jackrabbit/vault/packaging/Version.java#L157] > provides a nice function to sort package versions e.g. for the purpose of > displaying them in a predictable order that is close to the probable > timeline. But sometimes you want an "is newer than" relationship - e.g. for a > sanity check during package installation that you don't install an older over > a newer package. As far as I know, Adobe AEM is actually (ab-)using that > compareTo function for that purpose. That is a problem, because if you deploy > e.g. 1.2.3-SNAPSHOT for
[jira] [Comment Edited] (JCRVLT-672) Provide a Version comparison function for "is newer" checks
[ https://issues.apache.org/jira/browse/JCRVLT-672?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17648031#comment-17648031 ] Hans-Peter Stoerr edited comment on JCRVLT-672 at 12/15/22 12:38 PM: - [~kwin] : Ouch! It seems I've unknowingly opened a can of worms there. The maven versioning oder specification [https://maven.apache.org/pom.html#Version_Order_Specification] is amazingly complex when it comes to parsing and comparing the stuff after the first dash. There are also other differences: maven treats 1.0.0 and 1.0 and 1 as the same, Version.compareTo doesn't so far. For a start: maven segments versions differently: in addition to - and . it separates digit sequences from non-digit sequences: 1-1.foo-bar1baz would be split into 1 1 foo bar 1 baz . Moreover the ordering depends on whether the separators are - or . (digit vs. non-digit separation is treated as -). We could change Version.getNormalizedSegments () to also split on digit / non-digit sequences, but it wouldn't be enough to determine the ordering, anyway, and that also would have a risk of breaking something. I guess the only way to be 100% compatible to maven would be to copy e.g. [ComparableVersion.java|https://github.com/apache/maven/blob/maven-3.8.6/maven-artifact/src/main/java/org/apache/maven/artifact/versioning/ComparableVersion.java] as a package private class into org.apache.jackrabbit.vault.packaging and use that for comparisons. That is, obviously, also the easiest way to solve the problem. One problem with this is that the segmentation that is done to compare the versions is not quite compatible with Version.getNormalizedSegments(), which might be confusing at times. Or we could make some kind of compromise that behaves the same for more common things. Do you have any opinions on that which narrow down the solution space? was (Author: hanspeterstoerr): [~kwin] : Ouch! It seems I've unknowingly opened a can of worms there. The maven versioning oder specification [https://maven.apache.org/pom.html#Version_Order_Specification] is amazingly complex when it comes to parsing and comparing the stuff after the first dash. There are also other differences: maven treats 1.0.0 and 1.0 and 1 as the same, Version.compareTo doesn't so far. For a start: maven segments versions differently: in addition to - and . it separates digit sequences from non-digit sequences: 1-1.foo-bar1baz would be split into 1 1 foo bar 1 baz . Moreover the ordering depends on whether the separators are - or . (digit vs. non-digit separation is treated as -). We could change Version.getNormalizedSegments () to also split on digit / non-digit sequences, but it wouldn't be enough to determine the ordering, anyway, and that also would have a risk of breaking something. I guess the only way to be 100% compatible to maven would be to copy e.g. [ComparableVersion.java|https://github.com/apache/maven/blob/maven-3.8.6/maven-artifact/src/main/java/org/apache/maven/artifact/versioning/ComparableVersion.java] as a package private class into org.apache.jackrabbit.vault.packaging and use that for comparisons. That is, obviously, also the easiest way to solve the problem. One problem with this is that the segmentation that is done to compare the versions is not quite compatible with Version.getNormalizedSegments(), which might be confusing at times. Or we could make some kind of compromise that behaves the same for more common things. Do you have any opinions on that which help me narrow down the solution space? > Provide a Version comparison function for "is newer" checks > --- > > Key: JCRVLT-672 > URL: https://issues.apache.org/jira/browse/JCRVLT-672 > Project: Jackrabbit FileVault > Issue Type: Improvement >Affects Versions: 3.6.6 >Reporter: Hans-Peter Stoerr >Priority: Minor > > I suggest to add a function to org.apache.jackrabbit.vault.packaging.Version > that provides a sensible partial ordering for checking whether one package is > newer than another. > Background: > [org.apache.jackrabbit.vault.packaging.Version#compareTo|https://github.com/apache/jackrabbit-filevault/blob/jackrabbit-filevault-3.6.6/vault-core/src/main/java/org/apache/jackrabbit/vault/packaging/Version.java#L157] > provides a nice function to sort package versions e.g. for the purpose of > displaying them in a predictable order that is close to the probable > timeline. But sometimes you want an "is newer than" relationship - e.g. for a > sanity check during package installation that you don't install an older over > a newer package. As far as I know, Adobe AEM is actually (ab-)using that > compareTo function for that purpose. That is a problem, because if you deploy > e.g. 1.2.3-SNAPSHOT for a w
[jira] [Comment Edited] (JCRVLT-672) Provide a Version comparison function for "is newer" checks
[ https://issues.apache.org/jira/browse/JCRVLT-672?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17648031#comment-17648031 ] Hans-Peter Stoerr edited comment on JCRVLT-672 at 12/15/22 12:40 PM: - [~kwin] : Ouch! It seems I've unknowingly opened a can of worms there. The maven versioning oder specification [https://maven.apache.org/pom.html#Version_Order_Specification] is amazingly complex when it comes to parsing and comparing the stuff after the first dash. There are also other differences: maven treats 1.0.0 and 1.0 and 1 as the same, Version.compareTo doesn't so far. For a start: maven segments versions differently: in addition to - and . it separates digit sequences from non-digit sequences: 1-1.foo-bar1baz would be split into 1 1 foo bar 1 baz . Moreover the ordering depends on whether the separators are - or . (digit vs. non-digit separation is treated as -). We could change Version.getNormalizedSegments() to also split on digit / non-digit sequences, but it wouldn't be enough to determine the ordering, anyway, and that also would have a risk of breaking something. I guess the only way to be 100% compatible to maven would be to copy e.g. [ComparableVersion.java|https://github.com/apache/maven/blob/maven-3.8.6/maven-artifact/src/main/java/org/apache/maven/artifact/versioning/ComparableVersion.java] as a package private class into org.apache.jackrabbit.vault.packaging and use that for comparisons. That is, obviously, also the easiest way to solve the problem. One problem with this is that the segmentation that is done to compare the versions is not quite compatible with Version.getNormalizedSegments(), which might be confusing at times. Or we could make some kind of compromise that behaves the same for more common things. Do you have any opinions on that which narrow down the solution space? was (Author: hanspeterstoerr): [~kwin] : Ouch! It seems I've unknowingly opened a can of worms there. The maven versioning oder specification [https://maven.apache.org/pom.html#Version_Order_Specification] is amazingly complex when it comes to parsing and comparing the stuff after the first dash. There are also other differences: maven treats 1.0.0 and 1.0 and 1 as the same, Version.compareTo doesn't so far. For a start: maven segments versions differently: in addition to - and . it separates digit sequences from non-digit sequences: 1-1.foo-bar1baz would be split into 1 1 foo bar 1 baz . Moreover the ordering depends on whether the separators are - or . (digit vs. non-digit separation is treated as -). We could change Version.getNormalizedSegments() to also split on digit / non-digit sequences, but it wouldn't be enough to determine the ordering, anyway, and that also would have a risk of breaking something. I guess the only way to be 100% compatible to maven would be to copy e.g. [ComparableVersion.java|https://github.com/apache/maven/blob/maven-3.8.6/maven-artifact/src/main/java/org/apache/maven/artifact/versioning/ComparableVersion.java] as a package private class into org.apache.jackrabbit.vault.packaging and use that for comparisons. That is, obviously, also the easiest way to solve the problem. One problem with this is that the segmentation that is done to compare the versions is not quite compatible with Version.getNormalizedSegments(), which might be confusing at times. Or we could make some kind of compromise that behaves the same for more common things. Do you have any opinions on that which narrow down the solution space? > Provide a Version comparison function for "is newer" checks > --- > > Key: JCRVLT-672 > URL: https://issues.apache.org/jira/browse/JCRVLT-672 > Project: Jackrabbit FileVault > Issue Type: Improvement >Affects Versions: 3.6.6 >Reporter: Hans-Peter Stoerr >Priority: Minor > > I suggest to add a function to org.apache.jackrabbit.vault.packaging.Version > that provides a sensible partial ordering for checking whether one package is > newer than another. > Background: > [org.apache.jackrabbit.vault.packaging.Version#compareTo|https://github.com/apache/jackrabbit-filevault/blob/jackrabbit-filevault-3.6.6/vault-core/src/main/java/org/apache/jackrabbit/vault/packaging/Version.java#L157] > provides a nice function to sort package versions e.g. for the purpose of > displaying them in a predictable order that is close to the probable > timeline. But sometimes you want an "is newer than" relationship - e.g. for a > sanity check during package installation that you don't install an older over > a newer package. As far as I know, Adobe AEM is actually (ab-)using that > compareTo function for that purpose. That is a problem, because if you deploy > e.g. 1.2.3-SNAPSHOT for a while on a
[jira] [Comment Edited] (JCRVLT-672) Provide a Version comparison function for "is newer" checks
[ https://issues.apache.org/jira/browse/JCRVLT-672?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17648031#comment-17648031 ] Hans-Peter Stoerr edited comment on JCRVLT-672 at 12/15/22 12:40 PM: - [~kwin] : Ouch! It seems I've unknowingly opened a can of worms there. The maven versioning oder specification [https://maven.apache.org/pom.html#Version_Order_Specification] is amazingly complex when it comes to parsing and comparing the stuff after the first dash. There are also other differences: maven treats 1.0.0 and 1.0 and 1 as the same, Version.compareTo doesn't so far. For a start: maven segments versions differently: in addition to - and . it separates digit sequences from non-digit sequences: 1-1.foo-bar1baz would be split into 1 1 foo bar 1 baz . Moreover the ordering depends on whether the separators are - or . (digit vs. non-digit separation is treated as -). We could change Version.getNormalizedSegments() to also split on digit / non-digit sequences, but it wouldn't be enough to determine the ordering, anyway, and that also would have a risk of breaking something. I guess the only way to be 100% compatible to maven would be to copy e.g. [ComparableVersion.java|https://github.com/apache/maven/blob/maven-3.8.6/maven-artifact/src/main/java/org/apache/maven/artifact/versioning/ComparableVersion.java] as a package private class into org.apache.jackrabbit.vault.packaging and use that for comparisons. That is, obviously, also the easiest way to solve the problem. One problem with this is that the segmentation that is done to compare the versions is not quite compatible with Version.getNormalizedSegments(), which might be confusing at times. Or we could make some kind of compromise that behaves the same for more common things. Do you have any opinions on that which narrow down the solution space? was (Author: hanspeterstoerr): [~kwin] : Ouch! It seems I've unknowingly opened a can of worms there. The maven versioning oder specification [https://maven.apache.org/pom.html#Version_Order_Specification] is amazingly complex when it comes to parsing and comparing the stuff after the first dash. There are also other differences: maven treats 1.0.0 and 1.0 and 1 as the same, Version.compareTo doesn't so far. For a start: maven segments versions differently: in addition to - and . it separates digit sequences from non-digit sequences: 1-1.foo-bar1baz would be split into 1 1 foo bar 1 baz . Moreover the ordering depends on whether the separators are - or . (digit vs. non-digit separation is treated as -). We could change Version.getNormalizedSegments () to also split on digit / non-digit sequences, but it wouldn't be enough to determine the ordering, anyway, and that also would have a risk of breaking something. I guess the only way to be 100% compatible to maven would be to copy e.g. [ComparableVersion.java|https://github.com/apache/maven/blob/maven-3.8.6/maven-artifact/src/main/java/org/apache/maven/artifact/versioning/ComparableVersion.java] as a package private class into org.apache.jackrabbit.vault.packaging and use that for comparisons. That is, obviously, also the easiest way to solve the problem. One problem with this is that the segmentation that is done to compare the versions is not quite compatible with Version.getNormalizedSegments(), which might be confusing at times. Or we could make some kind of compromise that behaves the same for more common things. Do you have any opinions on that which narrow down the solution space? > Provide a Version comparison function for "is newer" checks > --- > > Key: JCRVLT-672 > URL: https://issues.apache.org/jira/browse/JCRVLT-672 > Project: Jackrabbit FileVault > Issue Type: Improvement >Affects Versions: 3.6.6 >Reporter: Hans-Peter Stoerr >Priority: Minor > > I suggest to add a function to org.apache.jackrabbit.vault.packaging.Version > that provides a sensible partial ordering for checking whether one package is > newer than another. > Background: > [org.apache.jackrabbit.vault.packaging.Version#compareTo|https://github.com/apache/jackrabbit-filevault/blob/jackrabbit-filevault-3.6.6/vault-core/src/main/java/org/apache/jackrabbit/vault/packaging/Version.java#L157] > provides a nice function to sort package versions e.g. for the purpose of > displaying them in a predictable order that is close to the probable > timeline. But sometimes you want an "is newer than" relationship - e.g. for a > sanity check during package installation that you don't install an older over > a newer package. As far as I know, Adobe AEM is actually (ab-)using that > compareTo function for that purpose. That is a problem, because if you deploy > e.g. 1.2.3-SNAPSHOT for a while on
[jira] [Comment Edited] (JCRVLT-672) Provide a Version comparison function for "is newer" checks
[
https://issues.apache.org/jira/browse/JCRVLT-672?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17648032#comment-17648032
]
Konrad Windszus edited comment on JCRVLT-672 at 12/15/22 12:43 PM:
---
We already embed {{org.apache.maven:maven-artifact}} in
https://github.com/apache/jackrabbit-filevault/blob/2674a2309731e9a70795b5a96be6df77b03d12ec/vault-core/pom.xml#L248
so no need to copy. It is there in the classpath.
was (Author: kwin):
We already depend on {{org.apache.maven:maven-artifact}} in
https://github.com/apache/jackrabbit-filevault/blob/2674a2309731e9a70795b5a96be6df77b03d12ec/vault-core/pom.xml#L248
so no need to copy. It is there in the classpath.
> Provide a Version comparison function for "is newer" checks
> ---
>
> Key: JCRVLT-672
> URL: https://issues.apache.org/jira/browse/JCRVLT-672
> Project: Jackrabbit FileVault
> Issue Type: Improvement
>Affects Versions: 3.6.6
>Reporter: Hans-Peter Stoerr
>Priority: Minor
>
> I suggest to add a function to org.apache.jackrabbit.vault.packaging.Version
> that provides a sensible partial ordering for checking whether one package is
> newer than another.
> Background:
> [org.apache.jackrabbit.vault.packaging.Version#compareTo|https://github.com/apache/jackrabbit-filevault/blob/jackrabbit-filevault-3.6.6/vault-core/src/main/java/org/apache/jackrabbit/vault/packaging/Version.java#L157]
> provides a nice function to sort package versions e.g. for the purpose of
> displaying them in a predictable order that is close to the probable
> timeline. But sometimes you want an "is newer than" relationship - e.g. for a
> sanity check during package installation that you don't install an older over
> a newer package. As far as I know, Adobe AEM is actually (ab-)using that
> compareTo function for that purpose. That is a problem, because if you deploy
> e.g. 1.2.3-SNAPSHOT for a while on a server and then create a release 1.2.3,
> it'll refuse automatic installation because it wrongly thinks 1.2.3-SNAPSHOT
> is newer than 1.2.3.
> Now, obviously you cannot fix that AEM problem here, but you could provide a
> function at Version for future use, that would be a nicely useable "is newer
> than" relationship for that purpose, and add a comment warning people not to
> use Version.compareTo for such a sanity check. That'd be nice for AEM usage,
> but also for other package managers, like our [Composum package
> manager|https://www.composum.com/home/nodes/pckgmgr.html?pages.locale=de].
> While the ordering of the numerical prefix (which is also implemented by
> Version.compareTo) is pretty widely used, there is no widely used ordering
> for the suffixes - they could be anything like -SNAPSHOT, -SNAPSHOT-12, -rc1,
> -alpha, -testing and whatnot. So it's not possible to give a full order for
> that purpose. My suggestion is to provide a partial ordering based on the
> numerical prefix, but to ignore the suffix completely. Perhaps provide a
> function Version.compareNumericPrefix ?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (JCRVLT-672) Provide a Version comparison function for "is newer" checks
[
https://issues.apache.org/jira/browse/JCRVLT-672?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17648032#comment-17648032
]
Konrad Windszus commented on JCRVLT-672:
We already depend on {{org.apache.maven:maven-artifact}} in
https://github.com/apache/jackrabbit-filevault/blob/2674a2309731e9a70795b5a96be6df77b03d12ec/vault-core/pom.xml#L248
so no need to copy. It is there in the classpath.
> Provide a Version comparison function for "is newer" checks
> ---
>
> Key: JCRVLT-672
> URL: https://issues.apache.org/jira/browse/JCRVLT-672
> Project: Jackrabbit FileVault
> Issue Type: Improvement
>Affects Versions: 3.6.6
>Reporter: Hans-Peter Stoerr
>Priority: Minor
>
> I suggest to add a function to org.apache.jackrabbit.vault.packaging.Version
> that provides a sensible partial ordering for checking whether one package is
> newer than another.
> Background:
> [org.apache.jackrabbit.vault.packaging.Version#compareTo|https://github.com/apache/jackrabbit-filevault/blob/jackrabbit-filevault-3.6.6/vault-core/src/main/java/org/apache/jackrabbit/vault/packaging/Version.java#L157]
> provides a nice function to sort package versions e.g. for the purpose of
> displaying them in a predictable order that is close to the probable
> timeline. But sometimes you want an "is newer than" relationship - e.g. for a
> sanity check during package installation that you don't install an older over
> a newer package. As far as I know, Adobe AEM is actually (ab-)using that
> compareTo function for that purpose. That is a problem, because if you deploy
> e.g. 1.2.3-SNAPSHOT for a while on a server and then create a release 1.2.3,
> it'll refuse automatic installation because it wrongly thinks 1.2.3-SNAPSHOT
> is newer than 1.2.3.
> Now, obviously you cannot fix that AEM problem here, but you could provide a
> function at Version for future use, that would be a nicely useable "is newer
> than" relationship for that purpose, and add a comment warning people not to
> use Version.compareTo for such a sanity check. That'd be nice for AEM usage,
> but also for other package managers, like our [Composum package
> manager|https://www.composum.com/home/nodes/pckgmgr.html?pages.locale=de].
> While the ordering of the numerical prefix (which is also implemented by
> Version.compareTo) is pretty widely used, there is no widely used ordering
> for the suffixes - they could be anything like -SNAPSHOT, -SNAPSHOT-12, -rc1,
> -alpha, -testing and whatnot. So it's not possible to give a full order for
> that purpose. My suggestion is to provide a partial ordering based on the
> numerical prefix, but to ignore the suffix completely. Perhaps provide a
> function Version.compareNumericPrefix ?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (JCRVLT-672) Provide a Version comparison function for "is newer" checks
[
https://issues.apache.org/jira/browse/JCRVLT-672?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17648032#comment-17648032
]
Konrad Windszus edited comment on JCRVLT-672 at 12/15/22 12:44 PM:
---
We already embed {{org.apache.maven:maven-artifact}} in
https://github.com/apache/jackrabbit-filevault/blob/2674a2309731e9a70795b5a96be6df77b03d12ec/vault-core/pom.xml#L248
and
https://github.com/apache/jackrabbit-filevault/blob/2674a2309731e9a70795b5a96be6df77b03d12ec/vault-core/bnd.bnd#L27
so no need for another copy. It is there in the classpath.
was (Author: kwin):
We already embed {{org.apache.maven:maven-artifact}} in
https://github.com/apache/jackrabbit-filevault/blob/2674a2309731e9a70795b5a96be6df77b03d12ec/vault-core/pom.xml#L248
so no need to copy. It is there in the classpath.
> Provide a Version comparison function for "is newer" checks
> ---
>
> Key: JCRVLT-672
> URL: https://issues.apache.org/jira/browse/JCRVLT-672
> Project: Jackrabbit FileVault
> Issue Type: Improvement
>Affects Versions: 3.6.6
>Reporter: Hans-Peter Stoerr
>Priority: Minor
>
> I suggest to add a function to org.apache.jackrabbit.vault.packaging.Version
> that provides a sensible partial ordering for checking whether one package is
> newer than another.
> Background:
> [org.apache.jackrabbit.vault.packaging.Version#compareTo|https://github.com/apache/jackrabbit-filevault/blob/jackrabbit-filevault-3.6.6/vault-core/src/main/java/org/apache/jackrabbit/vault/packaging/Version.java#L157]
> provides a nice function to sort package versions e.g. for the purpose of
> displaying them in a predictable order that is close to the probable
> timeline. But sometimes you want an "is newer than" relationship - e.g. for a
> sanity check during package installation that you don't install an older over
> a newer package. As far as I know, Adobe AEM is actually (ab-)using that
> compareTo function for that purpose. That is a problem, because if you deploy
> e.g. 1.2.3-SNAPSHOT for a while on a server and then create a release 1.2.3,
> it'll refuse automatic installation because it wrongly thinks 1.2.3-SNAPSHOT
> is newer than 1.2.3.
> Now, obviously you cannot fix that AEM problem here, but you could provide a
> function at Version for future use, that would be a nicely useable "is newer
> than" relationship for that purpose, and add a comment warning people not to
> use Version.compareTo for such a sanity check. That'd be nice for AEM usage,
> but also for other package managers, like our [Composum package
> manager|https://www.composum.com/home/nodes/pckgmgr.html?pages.locale=de].
> While the ordering of the numerical prefix (which is also implemented by
> Version.compareTo) is pretty widely used, there is no widely used ordering
> for the suffixes - they could be anything like -SNAPSHOT, -SNAPSHOT-12, -rc1,
> -alpha, -testing and whatnot. So it's not possible to give a full order for
> that purpose. My suggestion is to provide a partial ordering based on the
> numerical prefix, but to ignore the suffix completely. Perhaps provide a
> function Version.compareNumericPrefix ?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [jackrabbit-oak] jelmini commented on a diff in pull request #760: OAK-10006 Prevent writes to Azure storage if lock is not held
jelmini commented on code in PR #760:
URL: https://github.com/apache/jackrabbit-oak/pull/760#discussion_r1049651644
##
oak-segment-tar/src/main/java/org/apache/jackrabbit/oak/segment/file/FileStore.java:
##
@@ -237,6 +237,28 @@ private static GarbageCollectionStrategy
newGarbageCollectionStrategy() {
log.debug("TAR files: {}", tarFiles);
}
+private void onLockStatusChanged(SegmentNodeStorePersistence.LockStatus
lockStatus) {
+switch (lockStatus) {
+case LOST:
+try {
+if (tarFiles != null) {
+tarFiles.close();
Review Comment:
Right. Thanks for spotting this, @ahanikel !
I suppose we should add an `unsafeShutdown()` method to `TarFiles`,
`TarWriter` and `AbstractRemoteSegmentArchiveWriter`, so that we can shut them
down without attempting any finalisation writes to the remote storage, which
would anyway fail or corrupt the data.
What do you think?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: dev-unsubscr...@jackrabbit.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[GitHub] [jackrabbit-filevault] reschke opened a new pull request, #259: JCRVLT-673: AggregateImpl: do not collect & sort nodes that will be s…
reschke opened a new pull request, #259: URL: https://github.com/apache/jackrabbit-filevault/pull/259 …kipped anyway -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@jackrabbit.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [jackrabbit-oak] jelmini commented on a diff in pull request #760: OAK-10006 Prevent writes to Azure storage if lock is not held
jelmini commented on code in PR #760:
URL: https://github.com/apache/jackrabbit-oak/pull/760#discussion_r1049715995
##
oak-segment-azure/src/main/java/org/apache/jackrabbit/oak/segment/azure/AzureRepositoryLock.java:
##
@@ -121,6 +132,21 @@ private void refreshLease() {
}
}
+private void notifyLockStatusChange(LockStatus renewal) {
+try {
+lockStatusChangedCallback.accept(renewal);
+} catch (RuntimeException e) {
+log.warn("Exception in lock status change callback", e);
+}
+}
+
+void doRenewLease() throws StorageException {
+BlobRequestOptions blobRequestOptions = new BlobRequestOptions();
+blobRequestOptions.setMaximumExecutionTimeInMs(Math.max(INTERVAL -
renewalInterval - 1, INTERVAL / 2 - 1));
Review Comment:
Ok, I will add a comment.
In summary, previously `renewLease()` was called with the default
`BlobRequestOptions`. However, those defaults can be set globally for the
client instance and may be not a good fit for calling `renewLease()` as it
could block for too long. As the lease is acquired for 60 seconds and
`renewLease()` is called by default every 30 seconds, I think it should timeout
after at most 29 seconds (giving 1 sec margin), so that we can call
`notifyLockStatusChange(LockStatus.RENEWAL_FAILED)` and suspend writes before
the lease becomes available to be acquired by another instance.
BTW, I have just noticed that values should be in millis and thus multiplied
by 1000...
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: dev-unsubscr...@jackrabbit.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[jira] [Created] (JCRVLT-674) dependency-check issues while building master branch
Konrad Windszus created JCRVLT-674:
--
Summary: dependency-check issues while building master branch
Key: JCRVLT-674
URL: https://issues.apache.org/jira/browse/JCRVLT-674
Project: Jackrabbit FileVault
Issue Type: Bug
Reporter: Konrad Windszus
Assignee: Konrad Windszus
The following issues are emitted by the {{dependeny-check}} plugin
{code}
One or more dependencies were identified with known vulnerabilities in Apache
Jackrabbit FileVault Core Bundle:
commons-codec-1.10.jar (pkg:maven/commons-codec/commons-codec@1.10,
cpe:2.3:a:apache:commons_net:1.10:*:*:*:*:*:*:*) : CVE-2021-37533
commons-collections-3.2.2.jar
(pkg:maven/commons-collections/commons-collections@3.2.2,
cpe:2.3:a:apache:commons_collections:3.2.2:*:*:*:*:*:*:*,
cpe:2.3:a:apache:commons_net:3.2.2:*:*:*:*:*:*:*) : CVE-2021-37533
h2-2.1.212.jar (pkg:maven/com.h2database/h2@2.1.212,
cpe:2.3:a:h2database:h2:2.1.212:*:*:*:*:*:*:*) : CVE-2022-45868
jackrabbit-jcr-commons-2.20.7.jar
(pkg:maven/org.apache.jackrabbit/jackrabbit-jcr-commons@2.20.7,
cpe:2.3:a:apache:commons_net:2.20.7:*:*:*:*:*:*:*,
cpe:2.3:a:apache:jackrabbit:2.20.7:*:*:*:*:*:*:*) : CVE-2021-37533
jcl-over-slf4j-1.7.36.jar (pkg:maven/org.slf4j/jcl-over-slf4j@1.7.36,
cpe:2.3:a:apache:commons_net:1.7.36:*:*:*:*:*:*:*) : CVE-2021-37533
woodstox-core-6.1.1.jar (pkg:maven/com.fasterxml.woodstox/woodstox-core@6.1.1)
: CVE-2022-40152
{code}
(https://ci-builds.apache.org/blue/organizations/jenkins/Jackrabbit%2Ffilevault/detail/master/195/pipeline/53)
Those issues need to be fixed by either whitelist them (if FileVault isn't
affected by the CVE) or the according dependencies should be updated.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (JCRVLT-674) dependency-check issues while building master branch
[
https://issues.apache.org/jira/browse/JCRVLT-674?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konrad Windszus updated JCRVLT-674:
---
Description:
The following issues are emitted by the {{dependeny-check}} plugin for the Core
Module of FileVault
{code}
One or more dependencies were identified with known vulnerabilities in Apache
Jackrabbit FileVault Core Bundle:
commons-codec-1.10.jar (pkg:maven/commons-codec/commons-codec@1.10,
cpe:2.3:a:apache:commons_net:1.10:*:*:*:*:*:*:*) : CVE-2021-37533
commons-collections-3.2.2.jar
(pkg:maven/commons-collections/commons-collections@3.2.2,
cpe:2.3:a:apache:commons_collections:3.2.2:*:*:*:*:*:*:*,
cpe:2.3:a:apache:commons_net:3.2.2:*:*:*:*:*:*:*) : CVE-2021-37533
h2-2.1.212.jar (pkg:maven/com.h2database/h2@2.1.212,
cpe:2.3:a:h2database:h2:2.1.212:*:*:*:*:*:*:*) : CVE-2022-45868
jackrabbit-jcr-commons-2.20.7.jar
(pkg:maven/org.apache.jackrabbit/jackrabbit-jcr-commons@2.20.7,
cpe:2.3:a:apache:commons_net:2.20.7:*:*:*:*:*:*:*,
cpe:2.3:a:apache:jackrabbit:2.20.7:*:*:*:*:*:*:*) : CVE-2021-37533
jcl-over-slf4j-1.7.36.jar (pkg:maven/org.slf4j/jcl-over-slf4j@1.7.36,
cpe:2.3:a:apache:commons_net:1.7.36:*:*:*:*:*:*:*) : CVE-2021-37533
woodstox-core-6.1.1.jar (pkg:maven/com.fasterxml.woodstox/woodstox-core@6.1.1)
: CVE-2022-40152
{code}
(https://ci-builds.apache.org/blue/organizations/jenkins/Jackrabbit%2Ffilevault/detail/master/195/pipeline/53)
Those issues need to be fixed by either whitelist them (if FileVault isn't
affected by the CVE) or the according dependencies should be updated.
was:
The following issues are emitted by the {{dependeny-check}} plugin
{code}
One or more dependencies were identified with known vulnerabilities in Apache
Jackrabbit FileVault Core Bundle:
commons-codec-1.10.jar (pkg:maven/commons-codec/commons-codec@1.10,
cpe:2.3:a:apache:commons_net:1.10:*:*:*:*:*:*:*) : CVE-2021-37533
commons-collections-3.2.2.jar
(pkg:maven/commons-collections/commons-collections@3.2.2,
cpe:2.3:a:apache:commons_collections:3.2.2:*:*:*:*:*:*:*,
cpe:2.3:a:apache:commons_net:3.2.2:*:*:*:*:*:*:*) : CVE-2021-37533
h2-2.1.212.jar (pkg:maven/com.h2database/h2@2.1.212,
cpe:2.3:a:h2database:h2:2.1.212:*:*:*:*:*:*:*) : CVE-2022-45868
jackrabbit-jcr-commons-2.20.7.jar
(pkg:maven/org.apache.jackrabbit/jackrabbit-jcr-commons@2.20.7,
cpe:2.3:a:apache:commons_net:2.20.7:*:*:*:*:*:*:*,
cpe:2.3:a:apache:jackrabbit:2.20.7:*:*:*:*:*:*:*) : CVE-2021-37533
jcl-over-slf4j-1.7.36.jar (pkg:maven/org.slf4j/jcl-over-slf4j@1.7.36,
cpe:2.3:a:apache:commons_net:1.7.36:*:*:*:*:*:*:*) : CVE-2021-37533
woodstox-core-6.1.1.jar (pkg:maven/com.fasterxml.woodstox/woodstox-core@6.1.1)
: CVE-2022-40152
{code}
(https://ci-builds.apache.org/blue/organizations/jenkins/Jackrabbit%2Ffilevault/detail/master/195/pipeline/53)
Those issues need to be fixed by either whitelist them (if FileVault isn't
affected by the CVE) or the according dependencies should be updated.
> dependency-check issues while building master branch
>
>
> Key: JCRVLT-674
> URL: https://issues.apache.org/jira/browse/JCRVLT-674
> Project: Jackrabbit FileVault
> Issue Type: Bug
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
>
> The following issues are emitted by the {{dependeny-check}} plugin for the
> Core Module of FileVault
> {code}
> One or more dependencies were identified with known vulnerabilities in Apache
> Jackrabbit FileVault Core Bundle:
> commons-codec-1.10.jar (pkg:maven/commons-codec/commons-codec@1.10,
> cpe:2.3:a:apache:commons_net:1.10:*:*:*:*:*:*:*) : CVE-2021-37533
> commons-collections-3.2.2.jar
> (pkg:maven/commons-collections/commons-collections@3.2.2,
> cpe:2.3:a:apache:commons_collections:3.2.2:*:*:*:*:*:*:*,
> cpe:2.3:a:apache:commons_net:3.2.2:*:*:*:*:*:*:*) : CVE-2021-37533
> h2-2.1.212.jar (pkg:maven/com.h2database/h2@2.1.212,
> cpe:2.3:a:h2database:h2:2.1.212:*:*:*:*:*:*:*) : CVE-2022-45868
> jackrabbit-jcr-commons-2.20.7.jar
> (pkg:maven/org.apache.jackrabbit/jackrabbit-jcr-commons@2.20.7,
> cpe:2.3:a:apache:commons_net:2.20.7:*:*:*:*:*:*:*,
> cpe:2.3:a:apache:jackrabbit:2.20.7:*:*:*:*:*:*:*) : CVE-2021-37533
> jcl-over-slf4j-1.7.36.jar (pkg:maven/org.slf4j/jcl-over-slf4j@1.7.36,
> cpe:2.3:a:apache:commons_net:1.7.36:*:*:*:*:*:*:*) : CVE-2021-37533
> woodstox-core-6.1.1.jar
> (pkg:maven/com.fasterxml.woodstox/woodstox-core@6.1.1) : CVE-2022-40152
> {code}
> (https://ci-builds.apache.org/blue/organizations/jenkins/Jackrabbit%2Ffilevault/detail/master/195/pipeline/53)
> Those issues need to be fixed by either whitelist them (if FileVault isn't
> affected by the CVE) or the according dependencies should be updated.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [jackrabbit-filevault] stoerr opened a new pull request, #260: JCRVLT-672 use mavens ComparableVersion for package Version compareTo
stoerr opened a new pull request, #260: URL: https://github.com/apache/jackrabbit-filevault/pull/260 Compare https://issues.apache.org/jira/browse/JCRVLT-672 : the advantage is that this properly orders e.g. -SNAPSHOT versions of packages before: previously, 1.2.3 < 1.2.3-SNAPSHOT , but normally you'd create 1.2.3-SNAPSHOT and only later the actual release 1.2.3 . When Version.compareTo is used to check whether a package is "newer" (as e.g. Adobe AEM does), it could refuse installing release 1.2.3 after 1.2.3-SNAPSHOT is installed, which is wrong. This changes the logic of Version.compareTo to use the maven logic https://maven.apache.org/pom.html#Version_Order_Specification . -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@jackrabbit.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [jackrabbit-filevault] stoerr commented on a diff in pull request #260: JCRVLT-672 use mavens ComparableVersion for package Version compareTo
stoerr commented on code in PR #260:
URL:
https://github.com/apache/jackrabbit-filevault/pull/260#discussion_r1049853674
##
vault-core/src/main/java/org/apache/jackrabbit/vault/packaging/Version.java:
##
@@ -135,44 +136,40 @@ public String[] getNormalizedSegments() {
}
/**
- * Compares this version to the given one, segment by segment without any
special
- * "SNAPSHOT" handling.
+ * Compares this version to the given one. The comparison is compatible to
the ordering used by
+ * https://maven.apache.org/";>Apache Maven. It version
consists normally from 3 numbers -
+ * major version, minor version and patch level, and can be followed by a
dash and a qualifier like SNAPSHOT.
+ * Version numbers can also consist of fewer or more numbers.
+ * If the comparison is not resolved by comparing the numbers, the
algorith resorts to the qualifier - see
+ * https://cwiki.apache.org/confluence/display/MAVENOLD/Versioning";>"Versioning"
on Maven Wiki
+ * for details.
*
*
- * Examples:
+ * Some examples:
* "1" < "2"
* "1.0" < "2"
* "2.0.1" < "2.1"
* "2.1" < "2.1.1"
* "2.9" < "2.11"
- * "2.1" < "2.1-SNAPSHOT"
- * "2.1" < "2.1-R1234556"
- * "2.1-R12345" < "2.1-SNAPSHOT"
+ * "2.1-SNAPSHOT" < "2.1"
+ * "2.1-RC1" < "2.1"
+ * "2.1-RC1" < "2.1-SNAPSHOT"
*
*
- * @param o the other version
+ * Please note that this comparison does not use the exact segmentation
presented in {@link #getNormalizedSegments()},
+ * but applies the maven comparison algorithm to the string representation
{@link #toString()}.
+ *
+ * @param o the other version, not null
* @return a negative integer, zero, or a positive integer as this version
* is less than, equal to, or greater than the specified version.
+ *
+ * @see "https://cwiki.apache.org/confluence/display/MAVENOLD/Versioning";
+ * @see "https://semver.org/spec/v1.0.0.html";
*/
-public int compareTo(Version o) {
-String[] oSegs = o.getNormalizedSegments();
-for (int i=0; i< Math.min(segments.length, oSegs.length); i++) {
-String s1 = segments[i];
-String s2 = oSegs[i];
-int strCompare = s1.compareTo(s2);
-if (strCompare == 0) {
-continue;
-}
-try {
-int v1 = Integer.parseInt(segments[i]);
-int v2 = Integer.parseInt(oSegs[i]);
-return v1 - v2;
-} catch (NumberFormatException e) {
-// no numbers, use string compare
-return strCompare;
-}
-}
-return segments.length - oSegs.length;
+public int compareTo(@NotNull Version o) {
+ComparableVersion thisVersion = new ComparableVersion(toString());
+ComparableVersion otherVersion = new ComparableVersion(o.toString());
Review Comment:
Here is a tradeoff: if version comparisons are infrequent, its better to do
it this way. If version comparisons are frequent, it'd be better to create the
ComparableVersion during object construction and keep it as a final field. What
do you think, @kwin ?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: dev-unsubscr...@jackrabbit.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[jira] [Commented] (JCRVLT-672) Provide a Version comparison function for "is newer" checks
[ https://issues.apache.org/jira/browse/JCRVLT-672?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17648153#comment-17648153 ] Hans-Peter Stoerr commented on JCRVLT-672: -- [~kwin] Ah, I never imagined that. That makes it much easier. So, here's a PR [https://github.com/apache/jackrabbit-filevault/pull/260] . What I'm not sure about is whether to create the ComparableVersion as a final field or only temporarily during compareTo - not sure where it hurts least - see [https://github.com/apache/jackrabbit-filevault/pull/260/files#r1049853674] . What do you think? > Provide a Version comparison function for "is newer" checks > --- > > Key: JCRVLT-672 > URL: https://issues.apache.org/jira/browse/JCRVLT-672 > Project: Jackrabbit FileVault > Issue Type: Improvement >Affects Versions: 3.6.6 >Reporter: Hans-Peter Stoerr >Priority: Minor > > I suggest to add a function to org.apache.jackrabbit.vault.packaging.Version > that provides a sensible partial ordering for checking whether one package is > newer than another. > Background: > [org.apache.jackrabbit.vault.packaging.Version#compareTo|https://github.com/apache/jackrabbit-filevault/blob/jackrabbit-filevault-3.6.6/vault-core/src/main/java/org/apache/jackrabbit/vault/packaging/Version.java#L157] > provides a nice function to sort package versions e.g. for the purpose of > displaying them in a predictable order that is close to the probable > timeline. But sometimes you want an "is newer than" relationship - e.g. for a > sanity check during package installation that you don't install an older over > a newer package. As far as I know, Adobe AEM is actually (ab-)using that > compareTo function for that purpose. That is a problem, because if you deploy > e.g. 1.2.3-SNAPSHOT for a while on a server and then create a release 1.2.3, > it'll refuse automatic installation because it wrongly thinks 1.2.3-SNAPSHOT > is newer than 1.2.3. > Now, obviously you cannot fix that AEM problem here, but you could provide a > function at Version for future use, that would be a nicely useable "is newer > than" relationship for that purpose, and add a comment warning people not to > use Version.compareTo for such a sanity check. That'd be nice for AEM usage, > but also for other package managers, like our [Composum package > manager|https://www.composum.com/home/nodes/pckgmgr.html?pages.locale=de]. > While the ordering of the numerical prefix (which is also implemented by > Version.compareTo) is pretty widely used, there is no widely used ordering > for the suffixes - they could be anything like -SNAPSHOT, -SNAPSHOT-12, -rc1, > -alpha, -testing and whatnot. So it's not possible to give a full order for > that purpose. My suggestion is to provide a partial ordering based on the > numerical prefix, but to ignore the suffix completely. Perhaps provide a > function Version.compareNumericPrefix ? -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (JCRVLT-672) Provide a Version comparison function for "is newer" checks
[ https://issues.apache.org/jira/browse/JCRVLT-672?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17648153#comment-17648153 ] Hans-Peter Stoerr edited comment on JCRVLT-672 at 12/15/22 4:38 PM: [~kwin] Ah, I never imagined that. That makes it much easier. So, here's a PR draft [https://github.com/apache/jackrabbit-filevault/pull/260] . What I'm not sure about is whether to create the ComparableVersion as a final field or only temporarily during compareTo - not sure where it hurts least - see [https://github.com/apache/jackrabbit-filevault/pull/260/files#r1049853674] . What do you think? (I see that there are more consequences - now DependencyTest fails because 5.5.0-SNAPSHOT is no more in [5.5.0,) range. I still have to investigate that.) was (Author: hanspeterstoerr): [~kwin] Ah, I never imagined that. That makes it much easier. So, here's a PR [https://github.com/apache/jackrabbit-filevault/pull/260] . What I'm not sure about is whether to create the ComparableVersion as a final field or only temporarily during compareTo - not sure where it hurts least - see [https://github.com/apache/jackrabbit-filevault/pull/260/files#r1049853674] . What do you think? > Provide a Version comparison function for "is newer" checks > --- > > Key: JCRVLT-672 > URL: https://issues.apache.org/jira/browse/JCRVLT-672 > Project: Jackrabbit FileVault > Issue Type: Improvement >Affects Versions: 3.6.6 >Reporter: Hans-Peter Stoerr >Priority: Minor > > I suggest to add a function to org.apache.jackrabbit.vault.packaging.Version > that provides a sensible partial ordering for checking whether one package is > newer than another. > Background: > [org.apache.jackrabbit.vault.packaging.Version#compareTo|https://github.com/apache/jackrabbit-filevault/blob/jackrabbit-filevault-3.6.6/vault-core/src/main/java/org/apache/jackrabbit/vault/packaging/Version.java#L157] > provides a nice function to sort package versions e.g. for the purpose of > displaying them in a predictable order that is close to the probable > timeline. But sometimes you want an "is newer than" relationship - e.g. for a > sanity check during package installation that you don't install an older over > a newer package. As far as I know, Adobe AEM is actually (ab-)using that > compareTo function for that purpose. That is a problem, because if you deploy > e.g. 1.2.3-SNAPSHOT for a while on a server and then create a release 1.2.3, > it'll refuse automatic installation because it wrongly thinks 1.2.3-SNAPSHOT > is newer than 1.2.3. > Now, obviously you cannot fix that AEM problem here, but you could provide a > function at Version for future use, that would be a nicely useable "is newer > than" relationship for that purpose, and add a comment warning people not to > use Version.compareTo for such a sanity check. That'd be nice for AEM usage, > but also for other package managers, like our [Composum package > manager|https://www.composum.com/home/nodes/pckgmgr.html?pages.locale=de]. > While the ordering of the numerical prefix (which is also implemented by > Version.compareTo) is pretty widely used, there is no widely used ordering > for the suffixes - they could be anything like -SNAPSHOT, -SNAPSHOT-12, -rc1, > -alpha, -testing and whatnot. So it's not possible to give a full order for > that purpose. My suggestion is to provide a partial ordering based on the > numerical prefix, but to ignore the suffix completely. Perhaps provide a > function Version.compareNumericPrefix ? -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (JCRVLT-672) Provide a Version comparison function for "is newer" checks
[ https://issues.apache.org/jira/browse/JCRVLT-672?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17648185#comment-17648185 ] Hans-Peter Stoerr commented on JCRVLT-672: -- [~kwin] OK, some more tests need to be changed because e.g. 1.0-SNAPSHOT is indeed not contained in [1.0,2.0) in maven , and now also no more here. Compare this test and the following: [https://github.com/apache/maven/blob/maven-3.8.6/maven-artifact/src/test/java/org/apache/maven/artifact/versioning/VersionRangeTest.java#L657] I adapted the PR to that. From my perspective it's fine now - except if we want to pull up the ComparableVersion into a final field of Version . > Provide a Version comparison function for "is newer" checks > --- > > Key: JCRVLT-672 > URL: https://issues.apache.org/jira/browse/JCRVLT-672 > Project: Jackrabbit FileVault > Issue Type: Improvement >Affects Versions: 3.6.6 >Reporter: Hans-Peter Stoerr >Priority: Minor > > I suggest to add a function to org.apache.jackrabbit.vault.packaging.Version > that provides a sensible partial ordering for checking whether one package is > newer than another. > Background: > [org.apache.jackrabbit.vault.packaging.Version#compareTo|https://github.com/apache/jackrabbit-filevault/blob/jackrabbit-filevault-3.6.6/vault-core/src/main/java/org/apache/jackrabbit/vault/packaging/Version.java#L157] > provides a nice function to sort package versions e.g. for the purpose of > displaying them in a predictable order that is close to the probable > timeline. But sometimes you want an "is newer than" relationship - e.g. for a > sanity check during package installation that you don't install an older over > a newer package. As far as I know, Adobe AEM is actually (ab-)using that > compareTo function for that purpose. That is a problem, because if you deploy > e.g. 1.2.3-SNAPSHOT for a while on a server and then create a release 1.2.3, > it'll refuse automatic installation because it wrongly thinks 1.2.3-SNAPSHOT > is newer than 1.2.3. > Now, obviously you cannot fix that AEM problem here, but you could provide a > function at Version for future use, that would be a nicely useable "is newer > than" relationship for that purpose, and add a comment warning people not to > use Version.compareTo for such a sanity check. That'd be nice for AEM usage, > but also for other package managers, like our [Composum package > manager|https://www.composum.com/home/nodes/pckgmgr.html?pages.locale=de]. > While the ordering of the numerical prefix (which is also implemented by > Version.compareTo) is pretty widely used, there is no widely used ordering > for the suffixes - they could be anything like -SNAPSHOT, -SNAPSHOT-12, -rc1, > -alpha, -testing and whatnot. So it's not possible to give a full order for > that purpose. My suggestion is to provide a partial ordering based on the > numerical prefix, but to ignore the suffix completely. Perhaps provide a > function Version.compareNumericPrefix ? -- This message was sent by Atlassian Jira (v8.20.10#820010)
[GitHub] [jackrabbit-oak] kwin opened a new pull request, #793: OAK-10032 ensure that m-antrun-p execution comes after m-assembly-p
kwin opened a new pull request, #793: URL: https://github.com/apache/jackrabbit-oak/pull/793 Given them separate phases is the safest approach as according to https://issues.apache.org/jira/browse/MNG-5987: "it was documented and chosen that order of execution is not something you cannot count on: phases are ordered, mojos in a phase simply are not" -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@jackrabbit.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Updated] (JCRVLT-672) Provide a Version comparison function for "is newer" checks
[ https://issues.apache.org/jira/browse/JCRVLT-672?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Konrad Windszus updated JCRVLT-672: --- Assignee: Konrad Windszus Status: Patch Available (was: Open) > Provide a Version comparison function for "is newer" checks > --- > > Key: JCRVLT-672 > URL: https://issues.apache.org/jira/browse/JCRVLT-672 > Project: Jackrabbit FileVault > Issue Type: Improvement >Affects Versions: 3.6.6 >Reporter: Hans-Peter Stoerr >Assignee: Konrad Windszus >Priority: Minor > > I suggest to add a function to org.apache.jackrabbit.vault.packaging.Version > that provides a sensible partial ordering for checking whether one package is > newer than another. > Background: > [org.apache.jackrabbit.vault.packaging.Version#compareTo|https://github.com/apache/jackrabbit-filevault/blob/jackrabbit-filevault-3.6.6/vault-core/src/main/java/org/apache/jackrabbit/vault/packaging/Version.java#L157] > provides a nice function to sort package versions e.g. for the purpose of > displaying them in a predictable order that is close to the probable > timeline. But sometimes you want an "is newer than" relationship - e.g. for a > sanity check during package installation that you don't install an older over > a newer package. As far as I know, Adobe AEM is actually (ab-)using that > compareTo function for that purpose. That is a problem, because if you deploy > e.g. 1.2.3-SNAPSHOT for a while on a server and then create a release 1.2.3, > it'll refuse automatic installation because it wrongly thinks 1.2.3-SNAPSHOT > is newer than 1.2.3. > Now, obviously you cannot fix that AEM problem here, but you could provide a > function at Version for future use, that would be a nicely useable "is newer > than" relationship for that purpose, and add a comment warning people not to > use Version.compareTo for such a sanity check. That'd be nice for AEM usage, > but also for other package managers, like our [Composum package > manager|https://www.composum.com/home/nodes/pckgmgr.html?pages.locale=de]. > While the ordering of the numerical prefix (which is also implemented by > Version.compareTo) is pretty widely used, there is no widely used ordering > for the suffixes - they could be anything like -SNAPSHOT, -SNAPSHOT-12, -rc1, > -alpha, -testing and whatnot. So it's not possible to give a full order for > that purpose. My suggestion is to provide a partial ordering based on the > numerical prefix, but to ignore the suffix completely. Perhaps provide a > function Version.compareNumericPrefix ? -- This message was sent by Atlassian Jira (v8.20.10#820010)
[GitHub] [jackrabbit-oak] github-actions[bot] closed pull request #160: OAK-8734 | Sorted query with multiple path restrictions and sorting p…
github-actions[bot] closed pull request #160: OAK-8734 | Sorted query with multiple path restrictions and sorting p… URL: https://github.com/apache/jackrabbit-oak/pull/160 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@jackrabbit.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [jackrabbit-oak] github-actions[bot] closed pull request #157: OAK-8718: LuceneIndexStatsUpdateCallback is slow and synchronous whic…
github-actions[bot] closed pull request #157: OAK-8718: LuceneIndexStatsUpdateCallback is slow and synchronous whic… URL: https://github.com/apache/jackrabbit-oak/pull/157 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@jackrabbit.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [jackrabbit-oak] github-actions[bot] commented on pull request #129: OAK-8328 | Config errors in index defintion causes index update to ge…
github-actions[bot] commented on PR #129: URL: https://github.com/apache/jackrabbit-oak/pull/129#issuecomment-1354067771 This PR is stale because it has been open 24 months with no activity. Remove stale label or comment or this will be closed in 30 days. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@jackrabbit.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [jackrabbit-oak] kwin commented on pull request #793: OAK-10032 ensure that m-antrun-p execution comes after m-assembly-p
kwin commented on PR #793: URL: https://github.com/apache/jackrabbit-oak/pull/793#issuecomment-1354266929 Better approach suggested in https://github.com/apache/jackrabbit-oak/pull/794. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@jackrabbit.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [jackrabbit-oak] kwin commented on pull request #794: OAK-10032 get rid of m-antrun-p to replace the main artifact
kwin commented on PR #794: URL: https://github.com/apache/jackrabbit-oak/pull/794#issuecomment-1354334231 > I continue to believe that we should not make too many changes at once in a single commit, as it makes it harder to to track why something changed, what ticket it is related to do, and makes backports harder. I don't think this is related to the PR, is it? > I'm not a Maven expert. If it works, great. Just try it out. It works good and I would consider my Maven knowledge pretty decent (FYI I am a committer there). Do you dare to approve or not, or should I involve anyone else in the review? -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@jackrabbit.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: [VOTE] Release Apache Jackrabbit FileVault Package Maven Plugin 1.3.2
Here is my +1 Konrad > On 12. Dec 2022, at 18:57, Konrad Windszus wrote: > > Hello, > > A candidate for the Jackrabbit FileVault Package Maven Plugin 1.3.2 release > is available at: > https://dist.apache.org/repos/dist/dev/jackrabbit/filevault-package-maven-plugin/1.3.2/ > > The release candidate is a zip archive of the sources in: > https://github.com/apache/jackrabbit-filevault-package-maven-plugin/tree/filevault-package-maven-plugin-1.3.2/ > > The release notes can be found in JIRA at > https://issues.apache.org/jira/projects/JCRVLT/versions/12351470 > > The command for running automated checks against this release candidate is: > $ sh check-release.sh filevault-plugin 1.3.2 > 377e16ed038cdbb53c9a8cee12dd3ebc8fd44c8f > > A staged Maven repository is available for review at: > https://repository.apache.org/content/repositories/orgapachejackrabbit-1589 > > Please vote on releasing this package as Apache Jackrabbit FileVault Package > Maven Plugin 1.3.2. > The vote is open for a minimum of 72 hours during business days and passes > if a majority of at least three +1 Jackrabbit PMC votes are cast. > The vote fails if not enough votes are cast after 1 week (5 business days). > > [ ] +1 Release this package as Apache Jackrabbit FileVault Package Maven > Plugin 1.3.2 > [ ] -1 Do not release this package because… > > Regards, > Konrad >
[RESULT] [VOTE] Release Apache Jackrabbit FileVault Package Maven Plugin 1.3.2
The vote passed by 3 binding votes from Julian, Woonsan and myself. Thanks for voting. I will push out the release artifacts to Maven Central and ASF Dist. Konrad > On 12. Dec 2022, at 18:57, Konrad Windszus wrote: > > Hello, > > A candidate for the Jackrabbit FileVault Package Maven Plugin 1.3.2 release > is available at: > https://dist.apache.org/repos/dist/dev/jackrabbit/filevault-package-maven-plugin/1.3.2/ > > The release candidate is a zip archive of the sources in: > https://github.com/apache/jackrabbit-filevault-package-maven-plugin/tree/filevault-package-maven-plugin-1.3.2/ > > The release notes can be found in JIRA at > https://issues.apache.org/jira/projects/JCRVLT/versions/12351470 > > The command for running automated checks against this release candidate is: > $ sh check-release.sh filevault-plugin 1.3.2 > 377e16ed038cdbb53c9a8cee12dd3ebc8fd44c8f > > A staged Maven repository is available for review at: > https://repository.apache.org/content/repositories/orgapachejackrabbit-1589 > > Please vote on releasing this package as Apache Jackrabbit FileVault Package > Maven Plugin 1.3.2. > The vote is open for a minimum of 72 hours during business days and passes > if a majority of at least three +1 Jackrabbit PMC votes are cast. > The vote fails if not enough votes are cast after 1 week (5 business days). > > [ ] +1 Release this package as Apache Jackrabbit FileVault Package Maven > Plugin 1.3.2 > [ ] -1 Do not release this package because… > > Regards, > Konrad >
[jira] [Closed] (JCRVLT-651) validate-package: Allow to exclude main artifact
[
https://issues.apache.org/jira/browse/JCRVLT-651?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konrad Windszus closed JCRVLT-651.
--
> validate-package: Allow to exclude main artifact
>
>
> Key: JCRVLT-651
> URL: https://issues.apache.org/jira/browse/JCRVLT-651
> Project: Jackrabbit FileVault
> Issue Type: Bug
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
> Fix For: package-maven-plugin-1.3.2
>
>
> Currently it is stated in
> [https://jackrabbit.apache.org/filevault-package-maven-plugin/validate-package-mojo.html#packageFile]
> that
> {quote}If empty the main artifact will not be validated but only the attached
> artifacts with the given {{classifiers}}
> {quote}
> Due to issue https://issues.apache.org/jira/browse/MNG-6434 it is currently
> impossible to overwrite the default value by the empty or blank value.
> Therefore another parameter needs to be added to allow excluding the main
> artifact from being validated.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (JCRVLT-618) Clarify repositoryStructurePackages parameter
[ https://issues.apache.org/jira/browse/JCRVLT-618?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Konrad Windszus closed JCRVLT-618. -- > Clarify repositoryStructurePackages parameter > - > > Key: JCRVLT-618 > URL: https://issues.apache.org/jira/browse/JCRVLT-618 > Project: Jackrabbit FileVault > Issue Type: Improvement >Reporter: Konrad Windszus >Priority: Major > Fix For: package-maven-plugin-1.3.2 > > > The parameter > [repositoryStructurePackages|https://jackrabbit.apache.org/filevault-package-maven-plugin/validate-files-mojo.html#repositoryStructurePackages] > needs more clarification in its javadoc. It currently only defines > additional [validRoots for validator > jackrabbit-filter|https://jackrabbit.apache.org/filevault/validation.html#standard-validators]. > Particularly it doesn't define any node types for filter roots (compare with > JCRVLT-619) -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (JCRVLT-626) Update to maven-verifier 1.8.0
[
https://issues.apache.org/jira/browse/JCRVLT-626?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konrad Windszus closed JCRVLT-626.
--
> Update to maven-verifier 1.8.0
> --
>
> Key: JCRVLT-626
> URL: https://issues.apache.org/jira/browse/JCRVLT-626
> Project: Jackrabbit FileVault
> Issue Type: Improvement
> Components: package maven plugin
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
> Fix For: package-maven-plugin-1.3.2
>
>
> This allows to run ITs easily from the IDE due to the use of the [embedded
> launcher from
> classpath|https://maven.apache.org/shared/maven-verifier/getting-started.html#class-path-for-embedded-launcher]
> when no explicit {{$maven.home}} variable is set.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (JCRVLT-635) Write validation messages with styles
[ https://issues.apache.org/jira/browse/JCRVLT-635?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Konrad Windszus closed JCRVLT-635. -- > Write validation messages with styles > - > > Key: JCRVLT-635 > URL: https://issues.apache.org/jira/browse/JCRVLT-635 > Project: Jackrabbit FileVault > Issue Type: Improvement >Affects Versions: package-maven-plugin-1.3.0 >Reporter: Konrad Windszus >Priority: Major > Fix For: package-maven-plugin-1.3.2 > > > Leverage > https://maven.apache.org/shared/maven-shared-utils/apidocs/org/apache/maven/shared/utils/logging/MessageBuilder.html > in the ValidationMessagePrinter to support styling of messages. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (JCRVLT-625) Ignore goal "generate-cnd" in Eclipse m2e
[ https://issues.apache.org/jira/browse/JCRVLT-625?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Konrad Windszus closed JCRVLT-625. -- > Ignore goal "generate-cnd" in Eclipse m2e > - > > Key: JCRVLT-625 > URL: https://issues.apache.org/jira/browse/JCRVLT-625 > Project: Jackrabbit FileVault > Issue Type: Improvement >Affects Versions: package-maven-plugin-1.3.0 >Reporter: Konrad Windszus >Priority: Major > Fix For: package-maven-plugin-1.3.2 > > > The plugin execution of goal "generate-cnd" should be ignored for incremental > builds in Eclipse with m2e. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (JCRVLT-642) Drop Plexus components and only rely on JSR 330
[ https://issues.apache.org/jira/browse/JCRVLT-642?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Konrad Windszus closed JCRVLT-642. -- > Drop Plexus components and only rely on JSR 330 > --- > > Key: JCRVLT-642 > URL: https://issues.apache.org/jira/browse/JCRVLT-642 > Project: Jackrabbit FileVault > Issue Type: Improvement > Components: package maven plugin >Affects Versions: package-maven-plugin-1.3.0 >Reporter: Konrad Windszus >Assignee: Konrad Windszus >Priority: Major > Fix For: package-maven-plugin-1.3.2 > > > Currently plexus components are leveraged for the default lifecycle mapping > and the artifact handler for type "content-package". Both should be converted > to a JSR 330 approach to ensure compatibility with future versions of Maven. > Further information available at > https://lists.apache.org/thread/zqz7zvphxst1nb18k32mrxd93vhpzh8y > Also all plugins (except for the filevault one) should have an explicit > version in the mapping to make ITs more stable and in general leverage the > newest version in cases where the pom.xml doesn't define an explicit version > of those without requiring Maven to check the remote repo for the latest > version. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (JCRVLT-621) Set "builtWith" property
[
https://issues.apache.org/jira/browse/JCRVLT-621?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konrad Windszus closed JCRVLT-621.
--
> Set "builtWith" property
>
>
> Key: JCRVLT-621
> URL: https://issues.apache.org/jira/browse/JCRVLT-621
> Project: Jackrabbit FileVault
> Issue Type: Improvement
> Components: package maven plugin
>Reporter: Konrad Windszus
>Priority: Major
> Fix For: package-maven-plugin-1.3.2
>
>
> The Maven plugin should automatically set the "builtWith" property which is
> exposed in the CRX Package Manager. Its value should contain the version
> number and the Maven plugin name. As this property is not part of the
> [official package
> properties|https://jackrabbit.apache.org/filevault/properties.html] it needs
> to be written to a serialized {{vlt:PackageDefinition}} node in
> {{META-INF/vault/definition}}.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (JCRVLT-629) Change default value for failOnUncoveredSourceFiles to true
[
https://issues.apache.org/jira/browse/JCRVLT-629?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konrad Windszus closed JCRVLT-629.
--
> Change default value for failOnUncoveredSourceFiles to true
> ---
>
> Key: JCRVLT-629
> URL: https://issues.apache.org/jira/browse/JCRVLT-629
> Project: Jackrabbit FileVault
> Issue Type: Improvement
> Components: package maven plugin
>Reporter: Konrad Windszus
>Priority: Major
> Fix For: package-maven-plugin-1.3.2
>
>
> As uncovered source files are never included in the package which is almost
> never intended the default value of {{failOnUncoveredSourceFiles}}
> (https://jackrabbit.apache.org/filevault-package-maven-plugin/package-mojo.html#failOnUncoveredSourceFiles)
> should be changed to {{true}}.
> One example where the default behaviour leads to issues is tracked at
> https://github.com/Adobe-Consulting-Services/acs-aem-commons/issues/2826.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (JCRVLT-668) Use FileVault 3.6.6
[ https://issues.apache.org/jira/browse/JCRVLT-668?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Konrad Windszus closed JCRVLT-668. -- > Use FileVault 3.6.6 > --- > > Key: JCRVLT-668 > URL: https://issues.apache.org/jira/browse/JCRVLT-668 > Project: Jackrabbit FileVault > Issue Type: Improvement > Components: package maven plugin >Reporter: Konrad Windszus >Assignee: Konrad Windszus >Priority: Major > Fix For: package-maven-plugin-1.3.2 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (JCRVLT-641) Use plexus-utils instead of Maven Shared Utils
[
https://issues.apache.org/jira/browse/JCRVLT-641?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konrad Windszus closed JCRVLT-641.
--
> Use plexus-utils instead of Maven Shared Utils
> --
>
> Key: JCRVLT-641
> URL: https://issues.apache.org/jira/browse/JCRVLT-641
> Project: Jackrabbit FileVault
> Issue Type: Improvement
> Components: package maven plugin
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
> Fix For: package-maven-plugin-1.3.2
>
>
> Despite what is written in https://maven.apache.org/shared/maven-shared-utils/
> {quote}
> This project aims to be a functional replacement for plexus-utils in Maven.
> It is not a 100% API compatible replacement though but a replacement with
> improvements: lots of methods got cleaned up, generics got added and we
> dropped a lot of unused code.
> Then there are additions, like styled message API.
> {quote}
> the library is not really well maintained and mostly contains deprecated code
> now. Plexus-utils nowadays seems to be the better choice
> (https://lists.apache.org/thread/7dsyg3q1f2qvgzxq3snkcsnfkwltcfwj, and
> https://the-asf.slack.com/archives/C7Q9JB404/p1654722485674189).
> Therefore the changes from JCRVLT-501 should basically be reverted, so that
> we can get rid of maven-shared-utils (and therefore reduce the dependency
> footprint of the plugin, as plexus-utils is transitively required anyways).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (JCRVLT-665) Allow standalone usage of filevault-package:validate-package
[
https://issues.apache.org/jira/browse/JCRVLT-665?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konrad Windszus closed JCRVLT-665.
--
> Allow standalone usage of filevault-package:validate-package
>
>
> Key: JCRVLT-665
> URL: https://issues.apache.org/jira/browse/JCRVLT-665
> Project: Jackrabbit FileVault
> Issue Type: Bug
> Components: package maven plugin
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
> Fix For: package-maven-plugin-1.3.2
>
>
> Currently the goal {{validate-package}} only validates packages attached to
> the build. Alternatively it should be allowed to give a package via path.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (JCRVLT-431) GenerateMetadataMojo.computePackageType does not work correctly for OSGi configurations/bundles
[ https://issues.apache.org/jira/browse/JCRVLT-431?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Konrad Windszus closed JCRVLT-431. -- > GenerateMetadataMojo.computePackageType does not work correctly for OSGi > configurations/bundles > --- > > Key: JCRVLT-431 > URL: https://issues.apache.org/jira/browse/JCRVLT-431 > Project: Jackrabbit FileVault > Issue Type: Bug > Components: package maven plugin >Affects Versions: package-maven-plugin-1.1.2 >Reporter: Konrad Windszus >Assignee: Konrad Windszus >Priority: Minor > Fix For: package-maven-plugin-1.3.2 > > > Currently > https://github.com/apache/jackrabbit-filevault-package-maven-plugin/blob/trunk/src/main/java/org/apache/jackrabbit/filevault/maven/packaging/GenerateMetadataMojo.java#L1134 > will output "application" for packages containing OSGi configurations or > bundles! Instead it must emit "container" or "mixed" according to > https://issues.apache.org/jira/browse/JCRVLT-170. -- This message was sent by Atlassian Jira (v8.20.10#820010)
