[jira] [Created] (OAK-10672) Move internal index version in oak-search
Fabrizio Fortino created OAK-10672: -- Summary: Move internal index version in oak-search Key: OAK-10672 URL: https://issues.apache.org/jira/browse/OAK-10672 Project: Jackrabbit Oak Issue Type: Improvement Components: indexing Reporter: Fabrizio Fortino Assignee: Fabrizio Fortino -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (OAK-10671) [Indexing job] - Improve Mongo regex query: remove condition on non-indexed _path field to speedup traversal
Nuno Santos created OAK-10671:
-
Summary: [Indexing job] - Improve Mongo regex query: remove
condition on non-indexed _path field to speedup traversal
Key: OAK-10671
URL: https://issues.apache.org/jira/browse/OAK-10671
Project: Jackrabbit Oak
Issue Type: Improvement
Components: indexing
Reporter: Nuno Santos
Regex path filtering currently is implemented with a condition like:
{noformat}
_id in [^[0-9]{1,3}:\Q/foo/bar/\E.*$] OR ('_id' in [^[0-9]{1,3}:h.*$}] AND
_path in [^\Q/foo/bar/\E.*$]
{noformat}
The second condition is necessary to deal with long path documents, whose
{{_id}} is an hash instead of the path of the document, and that have an
additional {{_path}} property with the full path of the document. The {{_id}}
field is part of the index used by the query, but {{_path}} is not indexed. So
the performance of this query will be very sensitive to how many time the query
condition can be resolved without having to lookup the value of {{{}_path{}}},
which requires retrieving the full document from the column store. If the
condition can be evaluated only using the {{_id}} value, them if there is no
match the document should not be retrieved from the column store.
Unfortunately, Mongo does not seem to properly optimize this query and is
retrieving the document from the column storage even when {{_id}} does not
match the path /foo/bar and the _id is not in the hash format. This leads to
very poor performance as both the index and the column store have to be fully
read by this query.
We can instead use the following condition:
{noformat}
_id in [^[0-9]{1,3}:\Q/foo/bar/\E.*$ , ^[0-9]{1,3}:h.*$}]
{noformat}
That is, download the document if the _id matches the path or if it is an hash.
This has the disadvantage that it will download all long path documents from
the repository, many of which might not be needed. However, this query
condition only uses the _id field so it is guaranteed to be evaluated fully
using only the data on the index. And the number of long paths documents is
usually very small, some environments don't even have any long path documents,
so downloading them should not take much time. And the indexing job will anyway
reapply the filter on paths locally, to eliminate the long path documents which
are not required by the indexing job.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (OAK-10657) MongoDocumentStore: shrink in-DB documents after updates fail due to 16MB limit
[ https://issues.apache.org/jira/browse/OAK-10657?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Reschke resolved OAK-10657. -- Resolution: Won't Do Will do OAK-10660 instead. > MongoDocumentStore: shrink in-DB documents after updates fail due to 16MB > limit > --- > > Key: OAK-10657 > URL: https://issues.apache.org/jira/browse/OAK-10657 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: documentmk, mongomk >Reporter: Julian Reschke >Assignee: Julian Reschke >Priority: Major > > To address the 16MB/childorder issue, there are many potential approaches: > - make GC more aggressive > - try to change updates to remove "in-between" changes of ":childOrder" > property > - change the data model of ":childOrder" > - try to shrink document in DB once size related exception happens > This ticket is about the last of these options. > Proposal: > - improve exception thrown by document store so that it can be acted upon > - in document store utils add a method that inspects a document and produces > UpdateOps suitable to shrink the document > - DocumentNodeStore commit could catch exception, obtain update ops, apply > them, and retry once (this should be dependant on a feature toggle) -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (OAK-10636) Tar recovery unsuccessful in oak-segment-tar during initialisation of FileStore
[
https://issues.apache.org/jira/browse/OAK-10636?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Miroslav Smiljanic resolved OAK-10636.
--
Fix Version/s: 1.62.0
Resolution: Fixed
> Tar recovery unsuccessful in oak-segment-tar during initialisation of
> FileStore
> ---
>
> Key: OAK-10636
> URL: https://issues.apache.org/jira/browse/OAK-10636
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: segment-tar
>Affects Versions: 1.60.0
>Reporter: Miroslav Smiljanic
>Assignee: Miroslav Smiljanic
>Priority: Major
> Fix For: 1.62.0
>
> Attachments: OAK-10636_test.patch
>
>
> The initialization of FileStore is unsuccessful if tar archive is not closed
> properly and is missing index, graph and binary reference.
> {noformat}
> java.lang.NullPointerException: null
> at
> org.apache.jackrabbit.oak.segment.file.FileStore.readSegment(FileStore.java:517)
> at
> org.apache.jackrabbit.oak.segment.SegmentId.getSegment(SegmentId.java:153)
> at
> org.apache.jackrabbit.oak.segment.RecordId.getSegment(RecordId.java:98)
> at
> org.apache.jackrabbit.oak.segment.SegmentBlob.readLongBlobId(SegmentBlob.java:236)
> at
> org.apache.jackrabbit.oak.segment.SegmentBlob.readBlobId(SegmentBlob.java:174)
> at
> org.apache.jackrabbit.oak.segment.file.AbstractFileStore.lambda$populateTarBinaryReferences$0(AbstractFileStore.java:253)
> at
> org.apache.jackrabbit.oak.segment.Segment.forEachRecord(Segment.java:601)
> at
> org.apache.jackrabbit.oak.segment.file.AbstractFileStore.populateTarBinaryReferences(AbstractFileStore.java:251)
> at
> org.apache.jackrabbit.oak.segment.file.AbstractFileStore.writeSegment(AbstractFileStore.java:237)
> at
> org.apache.jackrabbit.oak.segment.file.AbstractFileStore$1.recoverEntry(AbstractFileStore.java:122)
> at
> org.apache.jackrabbit.oak.segment.file.tar.TarReader.generateTarFile(TarReader.java:183)
> at
> org.apache.jackrabbit.oak.segment.file.tar.TarReader.open(TarReader.java:106)
> at
> org.apache.jackrabbit.oak.segment.file.tar.TarFiles.(TarFiles.java:396)
> at
> org.apache.jackrabbit.oak.segment.file.tar.TarFiles$Builder.build(TarFiles.java:214)
> at
> org.apache.jackrabbit.oak.segment.file.FileStore.(FileStore.java:172)
> at
> org.apache.jackrabbit.oak.segment.file.FileStoreBuilder.build(FileStoreBuilder.java:445)
> at
> org.apache.jackrabbit.oak.segment.file.FileStoreTest.testRecovery_FileStore_withExternalBlobStore(FileStoreTest.java:201)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:566)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:59)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:56)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:54)
> at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
> at
> org.junit.runners.BlockJUnit4ClassRunner$1.evaluate(BlockJUnit4ClassRunner.java:100)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:366)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:103)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:63)
> at org.junit.runners.ParentRunner$4.run(ParentRunner.java:331)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:79)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:329)
> at org.junit.runners.ParentRunner.access$100(ParentRunner.java:66)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:293)
> at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:413)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
> at
> com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:69)
> at
> com.intellij.rt.junit.IdeaTestRunner$Repeater$1.execute(IdeaTestRunner.java:38)
> at
> com.intellij.rt.execution.junit.TestsRepeater.repeat(TestsRepeater.java:11)
> at
>
[jira] [Commented] (OAK-10660) DocumentNodeStore: avoid repeated commits of :childOrder in branch commits
[ https://issues.apache.org/jira/browse/OAK-10660?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17820703#comment-17820703 ] Julian Reschke commented on OAK-10660: -- Actually we have test coverage: in our current test we have ca 50 commits with ever growing :childOrder properties. In each commit, we *try* to remove all, but in practice, all but the last will be removed already. What we may not testing is the case where we map does not exist all all (no :childOder yet), but we can add a low level test for that. > DocumentNodeStore: avoid repeated commits of :childOrder in branch commits > -- > > Key: OAK-10660 > URL: https://issues.apache.org/jira/browse/OAK-10660 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: documentmk >Reporter: Julian Reschke >Assignee: Julian Reschke >Priority: Major > > - While persisting the branch commits, we are persisting large :childOrder > properties repeatedly. In practice, only the last value is needed, so the > previous ones could be cleaned up. > - We currently do not keep information about when (revision) and where (_id) > we have set :childOrder. > - The "clean" approach would be to maintain a map of _id/revision that tells > us in which revision we last set :childOrder. That could be used to pair the > setting of the new value with a removal of the previous one. > - But we may be able to simplify that: just maintain a list of _all_ > revisions that changed :childOrder, and any time we need to set a new value > for :childOrder, nuke the entries for all of these revisions. This would be > harmless because an extra REMOVE_MAP_ENTRY operation is essentially free, > except fo ra small overhead in processing. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (OAK-10654) Build Jackrabbit/jackrabbit-oak-trunk #1363 failed
[ https://issues.apache.org/jira/browse/OAK-10654?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17820671#comment-17820671 ] Hudson commented on OAK-10654: -- Previously failing build now is OK. Passed run: [Jackrabbit/jackrabbit-oak-trunk #1377|https://ci-builds.apache.org/job/Jackrabbit/job/jackrabbit-oak-trunk/1377/] [console log|https://ci-builds.apache.org/job/Jackrabbit/job/jackrabbit-oak-trunk/1377/console] > Build Jackrabbit/jackrabbit-oak-trunk #1363 failed > -- > > Key: OAK-10654 > URL: https://issues.apache.org/jira/browse/OAK-10654 > Project: Jackrabbit Oak > Issue Type: Bug > Components: continuous integration >Reporter: Hudson >Priority: Major > > No description is provided > The build Jackrabbit/jackrabbit-oak-trunk #1363 has failed. > First failed run: [Jackrabbit/jackrabbit-oak-trunk > #1363|https://ci-builds.apache.org/job/Jackrabbit/job/jackrabbit-oak-trunk/1363/] > [console > log|https://ci-builds.apache.org/job/Jackrabbit/job/jackrabbit-oak-trunk/1363/console] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (OAK-10660) DocumentNodeStore: avoid repeated commits of :childOrder in branch commits
[
https://issues.apache.org/jira/browse/OAK-10660?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17820668#comment-17820668
]
Stefan Egli commented on OAK-10660:
---
IIUC then the idea of this ticket is to only look at unmerged branch commits of
the own branch. Based on that, I would indeed only consider the own branch
commit - not any other. So I wouldn't remove just all revisions.
> "just remove the previous one"
I think that would be the optimal - but I fear in {{Commit}} you don't know
which actual previous one it contains. Consider an unmerged branch with 3
branch commits so far. Without actually inspecting the document, how could
{{Commit}} know, which one of those 3 ones were actually adding a ":childOrder"
revisions. It could be the first, the second, any combination of the 3 really.
So, if it is not feasible to have the Document available in
{{Commit.applyToDocumentStore}}, then the only option would actually be to add
{{op.removeMapEntry(":childOrder", rev)}} with all of those 3 previous revs.
This might have to be tested, I'm not sure if the command would fail if you
instruct it to remove a map entry that doesn't exist? (Also wondering, if we'd
add removeMapEntry for all previous branch commits - maybe we want to still
restrict that number if that grows ridiculously large. Eg if you have more than
1000 branch commits, wouldn't it be reasonably sufficient to only remove the
last 1000 (risking that you might still miss some)?
> DocumentNodeStore: avoid repeated commits of :childOrder in branch commits
> --
>
> Key: OAK-10660
> URL: https://issues.apache.org/jira/browse/OAK-10660
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: documentmk
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Major
>
> - While persisting the branch commits, we are persisting large :childOrder
> properties repeatedly. In practice, only the last value is needed, so the
> previous ones could be cleaned up.
> - We currently do not keep information about when (revision) and where (_id)
> we have set :childOrder.
> - The "clean" approach would be to maintain a map of _id/revision that tells
> us in which revision we last set :childOrder. That could be used to pair the
> setting of the new value with a removal of the previous one.
> - But we may be able to simplify that: just maintain a list of _all_
> revisions that changed :childOrder, and any time we need to set a new value
> for :childOrder, nuke the entries for all of these revisions. This would be
> harmless because an extra REMOVE_MAP_ENTRY operation is essentially free,
> except fo ra small overhead in processing.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (OAK-10670) Azure service principal support in oak-upgrade
[ https://issues.apache.org/jira/browse/OAK-10670?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tushar Rana updated OAK-10670: -- Description: Azure Service Principal Support in oak-segment-azure. Goal is to allow Azure authentication via: * clientId - Id of the Service Principal object / App registered with the Active Directory. * clientSecret - Application password. * tenantId - Azure Active Directory Id. > Azure service principal support in oak-upgrade > -- > > Key: OAK-10670 > URL: https://issues.apache.org/jira/browse/OAK-10670 > Project: Jackrabbit Oak > Issue Type: Improvement >Reporter: Tushar Rana >Priority: Major > > Azure Service Principal Support in oak-segment-azure. Goal is to allow Azure > authentication via: > * clientId - Id of the Service Principal object / App registered with the > Active Directory. > * clientSecret - Application password. > * tenantId - Azure Active Directory Id. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (OAK-10670) Azure service principal support in oak-upgrade
Mohit Kataria created OAK-10670: --- Summary: Azure service principal support in oak-upgrade Key: OAK-10670 URL: https://issues.apache.org/jira/browse/OAK-10670 Project: Jackrabbit Oak Issue Type: Improvement Reporter: Tushar Rana -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (OAK-10660) DocumentNodeStore: avoid repeated commits of :childOrder in branch commits
[ https://issues.apache.org/jira/browse/OAK-10660?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17820637#comment-17820637 ] Julian Reschke commented on OAK-10660: -- Good point. Any opinion about whether we need to avoid the "REMOVE *all* previous versions of :childOrder" as opposed to "just remove the previous one"? > DocumentNodeStore: avoid repeated commits of :childOrder in branch commits > -- > > Key: OAK-10660 > URL: https://issues.apache.org/jira/browse/OAK-10660 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: documentmk >Reporter: Julian Reschke >Assignee: Julian Reschke >Priority: Major > > - While persisting the branch commits, we are persisting large :childOrder > properties repeatedly. In practice, only the last value is needed, so the > previous ones could be cleaned up. > - We currently do not keep information about when (revision) and where (_id) > we have set :childOrder. > - The "clean" approach would be to maintain a map of _id/revision that tells > us in which revision we last set :childOrder. That could be used to pair the > setting of the new value with a removal of the previous one. > - But we may be able to simplify that: just maintain a list of _all_ > revisions that changed :childOrder, and any time we need to set a new value > for :childOrder, nuke the entries for all of these revisions. This would be > harmless because an extra REMOVE_MAP_ENTRY operation is essentially free, > except fo ra small overhead in processing. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (OAK-10660) DocumentNodeStore: avoid repeated commits of :childOrder in branch commits
[
https://issues.apache.org/jira/browse/OAK-10660?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17820636#comment-17820636
]
Stefan Egli edited comment on OAK-10660 at 2/26/24 9:17 AM:
In DocumentNodeStore the revisions are actually already tracked in the
{{org.apache.jackrabbit.oak.plugins.document.Branch}} - which is reachable via
the {{org.apache.jackrabbit.oak.plugins.document.UnmergedBranches}} - try
{noformat}
// rev being the branch commit revision vector
dns.getBranches().getBranch(rev);
{noformat}
That contains the unmerged branches of the local instance - which I guess is
what we want (IOW I don't think we need a new revisions set)
was (Author: egli):
In DocumentNodeStore the revisions are actually already tracked in the
{{org.apache.jackrabbit.oak.plugins.document.Branch}} - which is reachable via
the {{org.apache.jackrabbit.oak.plugins.document.UnmergedBranches}} - try
{noformat}
// rev being the branch commit revision vector
dns.getBranches().getBranch(rev);
{noformat}
That contains the unmerged branches of the local instance - which I guess is
what we want.
> DocumentNodeStore: avoid repeated commits of :childOrder in branch commits
> --
>
> Key: OAK-10660
> URL: https://issues.apache.org/jira/browse/OAK-10660
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: documentmk
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Major
>
> - While persisting the branch commits, we are persisting large :childOrder
> properties repeatedly. In practice, only the last value is needed, so the
> previous ones could be cleaned up.
> - We currently do not keep information about when (revision) and where (_id)
> we have set :childOrder.
> - The "clean" approach would be to maintain a map of _id/revision that tells
> us in which revision we last set :childOrder. That could be used to pair the
> setting of the new value with a removal of the previous one.
> - But we may be able to simplify that: just maintain a list of _all_
> revisions that changed :childOrder, and any time we need to set a new value
> for :childOrder, nuke the entries for all of these revisions. This would be
> harmless because an extra REMOVE_MAP_ENTRY operation is essentially free,
> except fo ra small overhead in processing.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (OAK-10660) DocumentNodeStore: avoid repeated commits of :childOrder in branch commits
[
https://issues.apache.org/jira/browse/OAK-10660?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17820636#comment-17820636
]
Stefan Egli commented on OAK-10660:
---
In DocumentNodeStore the revisions are actually already tracked in the
{{org.apache.jackrabbit.oak.plugins.document.Branch}} - which is reachable via
the {{org.apache.jackrabbit.oak.plugins.document.UnmergedBranches}} - try
{noformat}
// rev being the branch commit revision vector
dns.getBranches().getBranch(rev);
{noformat}
That contains the unmerged branches of the local instance - which I guess is
what we want.
> DocumentNodeStore: avoid repeated commits of :childOrder in branch commits
> --
>
> Key: OAK-10660
> URL: https://issues.apache.org/jira/browse/OAK-10660
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: documentmk
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Major
>
> - While persisting the branch commits, we are persisting large :childOrder
> properties repeatedly. In practice, only the last value is needed, so the
> previous ones could be cleaned up.
> - We currently do not keep information about when (revision) and where (_id)
> we have set :childOrder.
> - The "clean" approach would be to maintain a map of _id/revision that tells
> us in which revision we last set :childOrder. That could be used to pair the
> setting of the new value with a removal of the previous one.
> - But we may be able to simplify that: just maintain a list of _all_
> revisions that changed :childOrder, and any time we need to set a new value
> for :childOrder, nuke the entries for all of these revisions. This would be
> harmless because an extra REMOVE_MAP_ENTRY operation is essentially free,
> except fo ra small overhead in processing.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (OAK-10661) oak-search-elastic: remove workaround for elastic/elasticsearch-java/issues/404
[ https://issues.apache.org/jira/browse/OAK-10661?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Fabrizio Fortino resolved OAK-10661. Fix Version/s: 1.62.0 Resolution: Fixed > oak-search-elastic: remove workaround for > elastic/elasticsearch-java/issues/404 > --- > > Key: OAK-10661 > URL: https://issues.apache.org/jira/browse/OAK-10661 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: search, search-elastic >Reporter: Fabrizio Fortino >Assignee: Fabrizio Fortino >Priority: Major > Fix For: 1.62.0 > > > https://github.com/elastic/elasticsearch-java/issues/404 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (OAK-10669) Upgrade maven-versions-plugin to 2.16.2
[ https://issues.apache.org/jira/browse/OAK-10669?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Reschke resolved OAK-10669. -- Fix Version/s: 1.62.0 Resolution: Fixed > Upgrade maven-versions-plugin to 2.16.2 > --- > > Key: OAK-10669 > URL: https://issues.apache.org/jira/browse/OAK-10669 > Project: Jackrabbit Oak > Issue Type: Task > Components: parent >Reporter: Julian Reschke >Assignee: Julian Reschke >Priority: Minor > Fix For: 1.62.0 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (OAK-10669) Upgrade maven-versions-plugin to 2.16.2
[ https://issues.apache.org/jira/browse/OAK-10669?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17820635#comment-17820635 ] Julian Reschke commented on OAK-10669: -- trunk: [559fd9cd15|https://github.com/apache/jackrabbit-oak/commit/559fd9cd15fd150abba17b565a9c12381e2f2304] > Upgrade maven-versions-plugin to 2.16.2 > --- > > Key: OAK-10669 > URL: https://issues.apache.org/jira/browse/OAK-10669 > Project: Jackrabbit Oak > Issue Type: Task > Components: parent >Reporter: Julian Reschke >Assignee: Julian Reschke >Priority: Minor > Labels: candidate_oak_1_22 > Fix For: 1.62.0 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (OAK-10669) Upgrade maven-versions-plugin to 2.16.2
[ https://issues.apache.org/jira/browse/OAK-10669?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Reschke updated OAK-10669: - Labels: candidate_oak_1_22 (was: ) > Upgrade maven-versions-plugin to 2.16.2 > --- > > Key: OAK-10669 > URL: https://issues.apache.org/jira/browse/OAK-10669 > Project: Jackrabbit Oak > Issue Type: Task > Components: parent >Reporter: Julian Reschke >Assignee: Julian Reschke >Priority: Minor > Labels: candidate_oak_1_22 > Fix For: 1.62.0 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
