[jira] [Comment Edited] (JCRVLT-757) Optionally apply Enhanced DocView XML escaping to filtered values
[
https://issues.apache.org/jira/browse/JCRVLT-757?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17854507#comment-17854507
]
Konrad Windszus edited comment on JCRVLT-757 at 6/12/24 6:24 PM:
-
This can be implemented as
{{org.codehaus.plexus.interpolation.InterpolationPostProcessor}} being added to
the {{FilterWrapper}} s interpolator. Additional FilterWrappers can be added
via the {{MavenResourcesExecution}}. All wrappers are applied in a nested
fashion (with the default ones being applied last).
was (Author: kwin):
This can be implemented as
{{org.codehaus.plexus.interpolation.InterpolationPostProcessor}} being added to
the {{FilterWrapper}} s interpolator.
> Optionally apply Enhanced DocView XML escaping to filtered values
> -
>
> Key: JCRVLT-757
> URL: https://issues.apache.org/jira/browse/JCRVLT-757
> Project: Jackrabbit FileVault
> Issue Type: Improvement
> Components: package maven plugin
>Affects Versions: package-maven-plugin-1.3.6
>Reporter: Konrad Windszus
>Priority: Major
>
> The filtering option outlined in
> https://jackrabbit.apache.org/filevault-package-maven-plugin/filtering.html
> currently only supports as-is replacements, i.e. the values are taken
> unprocessed. In order to use the same variable values for different contexts
> it would be nice to optionally apply [FileVault DocView XML
> Escaping|https://jackrabbit.apache.org/filevault/docview.html#Escaping]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (JCRVLT-757) Optionally apply Enhanced DocView XML escaping to filtered values
[ https://issues.apache.org/jira/browse/JCRVLT-757?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17854507#comment-17854507 ] Konrad Windszus commented on JCRVLT-757: This can be implemented as `org.codehaus.plexus.interpolation.InterpolationPostProcessor` being added to the `FilterWrapper`s interpolator. > Optionally apply Enhanced DocView XML escaping to filtered values > - > > Key: JCRVLT-757 > URL: https://issues.apache.org/jira/browse/JCRVLT-757 > Project: Jackrabbit FileVault > Issue Type: Improvement > Components: package maven plugin >Affects Versions: package-maven-plugin-1.3.6 >Reporter: Konrad Windszus >Priority: Major > > The filtering option outlined in > https://jackrabbit.apache.org/filevault-package-maven-plugin/filtering.html > currently only supports as-is replacements, i.e. the values are taken > unprocessed. In order to use the same variable values for different contexts > it would be nice to optionally apply [FileVault DocView XML > Escaping|https://jackrabbit.apache.org/filevault/docview.html#Escaping] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (JCRVLT-757) Optionally apply Enhanced DocView XML escaping to filtered values
[
https://issues.apache.org/jira/browse/JCRVLT-757?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17854507#comment-17854507
]
Konrad Windszus edited comment on JCRVLT-757 at 6/12/24 5:57 PM:
-
This can be implemented as
{{org.codehaus.plexus.interpolation.InterpolationPostProcessor}} being added to
the {{FilterWrapper}} s interpolator.
was (Author: kwin):
This can be implemented as
`org.codehaus.plexus.interpolation.InterpolationPostProcessor` being added to
the `FilterWrapper`s interpolator.
> Optionally apply Enhanced DocView XML escaping to filtered values
> -
>
> Key: JCRVLT-757
> URL: https://issues.apache.org/jira/browse/JCRVLT-757
> Project: Jackrabbit FileVault
> Issue Type: Improvement
> Components: package maven plugin
>Affects Versions: package-maven-plugin-1.3.6
>Reporter: Konrad Windszus
>Priority: Major
>
> The filtering option outlined in
> https://jackrabbit.apache.org/filevault-package-maven-plugin/filtering.html
> currently only supports as-is replacements, i.e. the values are taken
> unprocessed. In order to use the same variable values for different contexts
> it would be nice to optionally apply [FileVault DocView XML
> Escaping|https://jackrabbit.apache.org/filevault/docview.html#Escaping]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (JCRVLT-757) Optionally apply Enhanced DocView XML escaping to filtered values
[ https://issues.apache.org/jira/browse/JCRVLT-757?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Konrad Windszus updated JCRVLT-757: --- Description: The filtering option outlined in https://jackrabbit.apache.org/filevault-package-maven-plugin/filtering.html currently only supports as-is replacements, i.e. the values are taken unprocessed. In order to use the same variable values for different contexts it would be nice to optionally apply [FileVault DocView XML Escaping|https://jackrabbit.apache.org/filevault/docview.html#Escaping] (was: The filtering option outlined in https://jackrabbit.apache.org/filevault-package-maven-plugin/filtering.html currently only supports as-is replacements, i.e. the values are taken unprocessed. In order to use the same property values for different context it would be nice to optionally apply [FileVault DocView XML Escaping|https://jackrabbit.apache.org/filevault/docview.html#Escaping]) > Optionally apply Enhanced DocView XML escaping to filtered values > - > > Key: JCRVLT-757 > URL: https://issues.apache.org/jira/browse/JCRVLT-757 > Project: Jackrabbit FileVault > Issue Type: Improvement > Components: package maven plugin >Affects Versions: package-maven-plugin-1.3.6 >Reporter: Konrad Windszus >Priority: Major > > The filtering option outlined in > https://jackrabbit.apache.org/filevault-package-maven-plugin/filtering.html > currently only supports as-is replacements, i.e. the values are taken > unprocessed. In order to use the same variable values for different contexts > it would be nice to optionally apply [FileVault DocView XML > Escaping|https://jackrabbit.apache.org/filevault/docview.html#Escaping] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (JCRVLT-757) Optionally apply Enhanced DocView XML escaping to filtered values
[ https://issues.apache.org/jira/browse/JCRVLT-757?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Konrad Windszus updated JCRVLT-757: --- Description: The filtering option outlined in https://jackrabbit.apache.org/filevault-package-maven-plugin/filtering.html currently only supports as-is replacements, i.e. the values are taken unprocessed. In order to use the same property values for different context it would be nice to optionally apply [FileVault DocView XML Escaping|https://jackrabbit.apache.org/filevault/docview.html#Escaping] (was: The filtering option outlined in https://jackrabbit.apache.org/filevault-package-maven-plugin/filtering.html currently only supports as-is replacements, i.e. the values are taken unprocessed. In order to use the same values for different context it would be nice to optionally apply [FileVault DocView XML Escaping|https://jackrabbit.apache.org/filevault/docview.html#Escaping]) > Optionally apply Enhanced DocView XML escaping to filtered values > - > > Key: JCRVLT-757 > URL: https://issues.apache.org/jira/browse/JCRVLT-757 > Project: Jackrabbit FileVault > Issue Type: Improvement > Components: package maven plugin >Affects Versions: package-maven-plugin-1.3.6 >Reporter: Konrad Windszus >Priority: Major > > The filtering option outlined in > https://jackrabbit.apache.org/filevault-package-maven-plugin/filtering.html > currently only supports as-is replacements, i.e. the values are taken > unprocessed. In order to use the same property values for different context > it would be nice to optionally apply [FileVault DocView XML > Escaping|https://jackrabbit.apache.org/filevault/docview.html#Escaping] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (JCRVLT-757) Optionally apply Enhanced DocView XML escaping to filtered values
Konrad Windszus created JCRVLT-757: -- Summary: Optionally apply Enhanced DocView XML escaping to filtered values Key: JCRVLT-757 URL: https://issues.apache.org/jira/browse/JCRVLT-757 Project: Jackrabbit FileVault Issue Type: Improvement Components: package maven plugin Affects Versions: package-maven-plugin-1.3.6 Reporter: Konrad Windszus The filtering option outlined in https://jackrabbit.apache.org/filevault-package-maven-plugin/filtering.html currently only supports as-is replacements, i.e. the values are taken unprocessed. In order to use the same values for different context it would be nice to optionally apply [FileVault DocView XML Escaping|https://jackrabbit.apache.org/filevault/docview.html#Escaping] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (JCRVLT-755) All contents are deleted when a content package created from a folder is applied
[ https://issues.apache.org/jira/browse/JCRVLT-755?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17853661#comment-17853661 ] Konrad Windszus commented on JCRVLT-755: bq. In that case I'd expect it to be replaced by an empty node. Konrad Windszus - would you agree? No, as outlined in https://jackrabbit.apache.org/filevault/docview.html#Empty_Elements. > All contents are deleted when a content package created from a folder is > applied > > > Key: JCRVLT-755 > URL: https://issues.apache.org/jira/browse/JCRVLT-755 > Project: Jackrabbit FileVault > Issue Type: Bug > Components: vlt >Reporter: Christian Schneider >Priority: Critical > Attachments: deleted.zip, working.zip > > > We have a strange issue where replication of a folder deletes all contents of > the folder on destination system. > We create a filevault package from the folder and apply the package using > filevault on the destination system. > It seems the behaviour is different depending if the folder or parent folder > has a jcr:content sub node. > I attached two content packages: > * working.zip : Export of /content/experience-fragements/test2 when > experience-fragements has jcr:content subnode. In this case an existing > experience fragement at /content/experience-fragements/test2/test4 is not > deleted > * deleted.zip : Export of /content/experience-fragements/test2 when > experience-fragements does not have jcr:content subnode. In this case prio > existing test4 content fragment was deletedon apply. > The content packages look different. In the case with jcr:content > experience-fragments and test2 are folders in the zip. > In case without jcr:content inside experience-fragments there are no folders > like above. Instead the sub nodes are inside a single content.xml -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (JCRVLT-756) Sub packages contained in "all" package no longer installed
[ https://issues.apache.org/jira/browse/JCRVLT-756?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Konrad Windszus resolved JCRVLT-756. Resolution: Invalid > Sub packages contained in "all" package no longer installed > --- > > Key: JCRVLT-756 > URL: https://issues.apache.org/jira/browse/JCRVLT-756 > Project: Jackrabbit FileVault > Issue Type: Bug > Components: vlt >Affects Versions: 3.7.4 >Reporter: Stefan Seifert >Priority: Minor > Attachments: > vault_installer_2024.5.16461.20240524T172309Z-240500.log, > vault_installer_2024.5.16544.20240530T165853Z-240500.log > > > i noticed that with latest vlt 3.7.3-SNAPSHOT it's not longer possible to > install a package that includes sub packages - the sub packages are > extracted, but not installed themselves properly. > it seems the functionality broke with one of the recent commits: > * it works fine with 3.7.3-T20240308111857-81fa88f1 > * but does no longer work with 3.7.3-T20240514105118-694f6aea > * differences between those two revs: > [https://github.com/apache/jackrabbit-filevault/compare/81fa88f1d7af07e77871e2c0bb03515107f18d74...694f6aeac27d9b6656647e968636fd9f5bc99238] > i tested with AEMaaCS SDK in two different versions - steps to reproduce the > problem: > * setup a local AEMaaCS SDK instance > * upload package > [https://github.com/adobe/aem-guides-wknd/releases/download/aem-guides-wknd-3.2.0/aem-guides-wknd.all-3.2.0.zip] > * install this package > * expected behavior: the package included the 5 subpackages should be > extracted in packaged manager and all of them should be installed > this works with AEMaaCS SDK 2024.5.16461.20240524T172309Z-240500 which > includes 3.7.3-T20240308111857-81fa88f1 > it does no longer work with AEMaaCS SDK 2024.5.16544.20240530T165853Z-240500 > which includes 3.7.3-T20240514105118-694f6aea > i've attached log files with the package install procedure with both those > versions. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (JCRVLT-756) Sub packages contained in "all" package no longer installed
[ https://issues.apache.org/jira/browse/JCRVLT-756?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17852838#comment-17852838 ] Konrad Windszus commented on JCRVLT-756: This points more to a problem in AEM than a general one in FileVault then. I would recommend involving Adobe support. > Sub packages contained in "all" package no longer installed > --- > > Key: JCRVLT-756 > URL: https://issues.apache.org/jira/browse/JCRVLT-756 > Project: Jackrabbit FileVault > Issue Type: Bug > Components: vlt >Affects Versions: 3.7.4 >Reporter: Stefan Seifert >Priority: Critical > Attachments: > vault_installer_2024.5.16461.20240524T172309Z-240500.log, > vault_installer_2024.5.16544.20240530T165853Z-240500.log > > > i noticed that with latest vlt 3.7.3-SNAPSHOT it's not longer possible to > install a package that includes sub packages - the sub packages are > extracted, but not installed themselves properly. > it seems the functionality broke with one of the recent commits: > * it works fine with 3.7.3-T20240308111857-81fa88f1 > * but does no longer work with 3.7.3-T20240514105118-694f6aea > * differences between those two revs: > [https://github.com/apache/jackrabbit-filevault/compare/81fa88f1d7af07e77871e2c0bb03515107f18d74...694f6aeac27d9b6656647e968636fd9f5bc99238] > i tested with AEMaaCS SDK in two different versions - steps to reproduce the > problem: > * setup a local AEMaaCS SDK instance > * upload package > [https://github.com/adobe/aem-guides-wknd/releases/download/aem-guides-wknd-3.2.0/aem-guides-wknd.all-3.2.0.zip] > * install this package > * expected behavior: the package included the 5 subpackages should be > extracted in packaged manager and all of them should be installed > this works with AEMaaCS SDK 2024.5.16461.20240524T172309Z-240500 which > includes 3.7.3-T20240308111857-81fa88f1 > it does no longer work with AEMaaCS SDK 2024.5.16544.20240530T165853Z-240500 > which includes 3.7.3-T20240514105118-694f6aea > i've attached log files with the package install procedure with both those > versions. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (JCRVLT-756) Sub packages contained in "all" package no longer installed
[ https://issues.apache.org/jira/browse/JCRVLT-756?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17852772#comment-17852772 ] Konrad Windszus commented on JCRVLT-756: [~sseifert] Any chance you can come up with a failing IT? > Sub packages contained in "all" package no longer installed > --- > > Key: JCRVLT-756 > URL: https://issues.apache.org/jira/browse/JCRVLT-756 > Project: Jackrabbit FileVault > Issue Type: Bug > Components: vlt >Affects Versions: 3.7.4 >Reporter: Stefan Seifert >Priority: Critical > Attachments: > vault_installer_2024.5.16461.20240524T172309Z-240500.log, > vault_installer_2024.5.16544.20240530T165853Z-240500.log > > > i noticed that with latest vlt 3.7.3-SNAPSHOT it's not longer possible to > install a package that includes sub packages - the sub packages are > extracted, but not installed themselves properly. > it seems the functionality broke with one of the recent commits: > * it works fine with 3.7.3-T20240308111857-81fa88f1 > * but does no longer work with 3.7.3-T20240514105118-694f6aea > * differences between those two revs: > [https://github.com/apache/jackrabbit-filevault/compare/81fa88f1d7af07e77871e2c0bb03515107f18d74...694f6aeac27d9b6656647e968636fd9f5bc99238] > i tested with AEMaaCS SDK in two different versions - steps to reproduce the > problem: > * setup a local AEMaaCS SDK instance > * upload package > [https://github.com/adobe/aem-guides-wknd/releases/download/aem-guides-wknd-3.2.0/aem-guides-wknd.all-3.2.0.zip] > * install this package > * expected behavior: the package included the 5 subpackages should be > extracted in packaged manager and all of them should be installed > this works with AEMaaCS SDK 2024.5.16461.20240524T172309Z-240500 which > includes 3.7.3-T20240308111857-81fa88f1 > it does no longer work with AEMaaCS SDK 2024.5.16544.20240530T165853Z-240500 > which includes 3.7.3-T20240514105118-694f6aea > i've attached log files with the package install procedure with both those > versions. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (SLING-12350) Make the HTL Compiler build work on more recent JDKs
[ https://issues.apache.org/jira/browse/SLING-12350?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Konrad Windszus resolved SLING-12350. - Assignee: Konrad Windszus Resolution: Fixed PR is applied in https://github.com/apache/sling-org-apache-sling-scripting-sightly-compiler/commit/69de23f3eb41c02fb5d2bd47e869617c3c34ee57. [~Csaba Varga] Thanks a lot for the contribution. > Make the HTL Compiler build work on more recent JDKs > > > Key: SLING-12350 > URL: https://issues.apache.org/jira/browse/SLING-12350 > Project: Sling > Issue Type: Improvement > Components: HTL >Affects Versions: Scripting HTL Compiler 1.2.14-1.4.0 >Reporter: Csaba Varga >Assignee: Konrad Windszus >Priority: Minor > Fix For: Scripting HTL Compiler 1.2.16-1.4.0 > > > The current build of the HTL compiler artifact fails on JDK 17 and later > because it tries to access standard library internals via reflection. It > should be updated so that it can be built on recent JDKs. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MNG-8135) Profile activation based on OS properties is no longer case insensitive
[
https://issues.apache.org/jira/browse/MNG-8135?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konrad Windszus updated MNG-8135:
-
Description:
This BUG is introduced by MNG-5726. Prior that change the os name, arch and
version comparison was always case-insensitive. Afterwards it needs to match
the lower-case variants.
When OS name, arch or version has capital letters, it won't activate the
profile.
For example:
{code:java}
Mac OS X
aarch64
{code}
was:
This BUG is introduced by MNG-5726. Prior that change the os name, arch and
version comparison was always case-insensitive. Afterwards it needs to match
the lower-case variants.
When OS name has capital letters, it can not activate the profile.
For example:
{code:java}
Mac OS X
aarch64
{code}
> Profile activation based on OS properties is no longer case insensitive
> ---
>
> Key: MNG-8135
> URL: https://issues.apache.org/jira/browse/MNG-8135
> Project: Maven
> Issue Type: Bug
> Components: Profiles
>Affects Versions: 3.9.7
>Reporter: Lijia Liu
>Priority: Major
> Fix For: 4.0.0, 3.9.8, 4.0.0-beta-4
>
>
> This BUG is introduced by MNG-5726. Prior that change the os name, arch and
> version comparison was always case-insensitive. Afterwards it needs to match
> the lower-case variants.
> When OS name, arch or version has capital letters, it won't activate the
> profile.
> For example:
> {code:java}
>
>
> Mac OS X
> aarch64
>
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MNG-8135) Profile activation based on OS properties is no longer case insensitive
[
https://issues.apache.org/jira/browse/MNG-8135?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konrad Windszus updated MNG-8135:
-
Summary: Profile activation based on OS properties is no longer case
insensitive (was: Activate profile by capital OS name fail)
> Profile activation based on OS properties is no longer case insensitive
> ---
>
> Key: MNG-8135
> URL: https://issues.apache.org/jira/browse/MNG-8135
> Project: Maven
> Issue Type: Bug
> Components: Profiles
>Affects Versions: 3.9.7
>Reporter: Lijia Liu
>Priority: Major
> Fix For: 4.0.0, 3.9.8, 4.0.0-beta-4
>
>
> This BUG is introduced by MNG-5726. Prior that change the os name, arch and
> version comparison was always case-insensitive. Afterwards it needs to match
> the lower-case variants.
> When OS name has capital letters, it can not activate the profile.
> For example:
> {code:java}
>
>
> Mac OS X
> aarch64
>
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MNG-8135) Activate profile by capital OS name fail
[
https://issues.apache.org/jira/browse/MNG-8135?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konrad Windszus updated MNG-8135:
-
Description:
This BUG is introduced by MNG-5726. Prior that change the os name, arch and
version comparison was always case-insensitive. Afterwards it needs to match
the lower-case variants.
When OS name has capital letters, it can not activate the profile.
For example:
{code:java}
Mac OS X
aarch64
{code}
was:
This BUG is introduced by MNG-5726.
When OS name has capital letters, it can not activate the profile.
For example:
{code:java}
Mac OS X
aarch64
{code}
> Activate profile by capital OS name fail
>
>
> Key: MNG-8135
> URL: https://issues.apache.org/jira/browse/MNG-8135
> Project: Maven
> Issue Type: Bug
> Components: Profiles
>Affects Versions: 3.9.7
>Reporter: Lijia Liu
>Priority: Major
>
> This BUG is introduced by MNG-5726. Prior that change the os name, arch and
> version comparison was always case-insensitive. Afterwards it needs to match
> the lower-case variants.
> When OS name has capital letters, it can not activate the profile.
> For example:
> {code:java}
>
>
> Mac OS X
> aarch64
>
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MENFORCER-505) Wrong documentation for new requireMatchingCoordinates rules
[ https://issues.apache.org/jira/browse/MENFORCER-505?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Konrad Windszus updated MENFORCER-505: -- Labels: (was: up-for-grabs) > Wrong documentation for new requireMatchingCoordinates rules > > > Key: MENFORCER-505 > URL: https://issues.apache.org/jira/browse/MENFORCER-505 > Project: Maven Enforcer Plugin > Issue Type: Bug >Reporter: Michael Keppler >Assignee: Konrad Windszus >Priority: Minor > Fix For: next-release > > > There is a copy-paste error in > [https://github.com/apache/maven-enforcer/blob/f8430efe20020071273bab883cffb3a2e0f00107/enforcer-rules/src/site/apt/requireMatchingCoordinates.apt.vm#L65,] > where the closing tag does not match the opening tag. > See > [https://maven.apache.org/enforcer/enforcer-rules/requireMatchingCoordinates.html] > line 19 for the result. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (MENFORCER-505) Wrong documentation for new requireMatchingCoordinates rules
[ https://issues.apache.org/jira/browse/MENFORCER-505?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Konrad Windszus resolved MENFORCER-505. --- Fix Version/s: next-release Resolution: Fixed > Wrong documentation for new requireMatchingCoordinates rules > > > Key: MENFORCER-505 > URL: https://issues.apache.org/jira/browse/MENFORCER-505 > Project: Maven Enforcer Plugin > Issue Type: Bug >Reporter: Michael Keppler >Assignee: Konrad Windszus >Priority: Minor > Labels: up-for-grabs > Fix For: next-release > > > There is a copy-paste error in > [https://github.com/apache/maven-enforcer/blob/f8430efe20020071273bab883cffb3a2e0f00107/enforcer-rules/src/site/apt/requireMatchingCoordinates.apt.vm#L65,] > where the closing tag does not match the opening tag. > See > [https://maven.apache.org/enforcer/enforcer-rules/requireMatchingCoordinates.html] > line 19 for the result. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (MENFORCER-505) Wrong documentation for new requireMatchingCoordinates rules
[ https://issues.apache.org/jira/browse/MENFORCER-505?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Konrad Windszus reassigned MENFORCER-505: - Assignee: Konrad Windszus > Wrong documentation for new requireMatchingCoordinates rules > > > Key: MENFORCER-505 > URL: https://issues.apache.org/jira/browse/MENFORCER-505 > Project: Maven Enforcer Plugin > Issue Type: Bug >Reporter: Michael Keppler >Assignee: Konrad Windszus >Priority: Minor > Labels: up-for-grabs > > There is a copy-paste error in > [https://github.com/apache/maven-enforcer/blob/f8430efe20020071273bab883cffb3a2e0f00107/enforcer-rules/src/site/apt/requireMatchingCoordinates.apt.vm#L65,] > where the closing tag does not match the opening tag. > See > [https://maven.apache.org/enforcer/enforcer-rules/requireMatchingCoordinates.html] > line 19 for the result. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (SLING-12331) Update sling maven plugins to maven 3.8.x
[
https://issues.apache.org/jira/browse/SLING-12331?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17850329#comment-17850329
]
Konrad Windszus commented on SLING-12331:
-
The proper fix is to change the Maven dependencies provided by the Maven
distribution to scope {{provided}}. That way they are no longer downloaded (for
no reason). Compare with https://issues.apache.org/jira/browse/MPLUGIN-370.
> Update sling maven plugins to maven 3.8.x
> -
>
> Key: SLING-12331
> URL: https://issues.apache.org/jira/browse/SLING-12331
> Project: Sling
> Issue Type: Improvement
> Components: Maven Plugins and Archetypes
>Reporter: Dirk Rudolph
>Priority: Major
>
> We recently got some security vulnerability reported related to maven-core,
> which is a transitive dependency used in many / some of the sling maven
> plugins.
> While maven-core is always take from the maven installation in the current
> version, the vulnerable jars are downloaded when using the plugins, and hence
> found and reported by security scanners.
> We should update our maven plugins to use the 3.8.x version of maven at least.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MNG-5726) Update OS Activation To Allow Wildcards In OS Version
[
https://issues.apache.org/jira/browse/MNG-5726?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17849549#comment-17849549
]
Konrad Windszus commented on MNG-5726:
--
[~sjaranowski] I did that already. What exactly are you missing?
> Update OS Activation To Allow Wildcards In OS Version
> -
>
> Key: MNG-5726
> URL: https://issues.apache.org/jira/browse/MNG-5726
> Project: Maven
> Issue Type: New Feature
> Components: Profiles
>Affects Versions: 3.1.1, 3.2.3
> Environment: RHEL/CentOs
>Reporter: Andy Lehane
>Assignee: Konrad Windszus
>Priority: Minor
> Fix For: 3.9.7, 4.0.0-alpha-13, 4.0.0
>
> Attachments: maven-os-version-patch-3.2.3.zip
>
>
> I'm attempting to use maven to build a legacy project that requires different
> dependecies based on the operating system version, i.e:
> - version 1.0 of "a platform specific library" for Red Hat Linux 5
> - version 1.1 of "a platform specific library" for Red Hat Linux 6
> - version 1.4a of "a platform specific library" for Windows and
> - version 1.3b of (a platform specific library" for Solaris.
> I can configure my pom file to get activate specific profiles for RHEL, Win
> and Solaris but cannot distinguish between Red Hat 5 and 6 unless I use the
> full version string, which is of the form "2.6.32-504.1.3.el6.x86_64".
> As this Linux version will change whenever patch updates are installed, this
> will make maintaining the pom/project akward.
> To solve this, it would be good to be able to specify wildcard's in the os
> version tag. I have taken a look at the range checking (for example, as
> applied to the JdkVersion), but don't think this method would be sufficient,
> as the specific part of the Red Hat version number we require is buried over
> half way into the version string (i.e. "el6" of the version
> "2.6.32-504.1.3.el6.x86_64").
> It would be nice to be able to have something like:
> {code}
>
> linux-rhel5
>
> false
>
> unix
> Linux
> *el5*
>
>
>
> .
> {code}
> I've taken a look at the OperatingSystemProfileActivator code and have
> created a patch that will use ^ to signify that the text is a regular
> expression, for example:
> {code}
> ^.*(el5).*
> {code}
> I've also kept the ! notation, so the following can also be used:
> {code}
> !^.*(el5).*
> {code}
> The patch added contains a unit test for the OperatingSystemProfileActivator
> in the maven-model-builder project (warning: it's a nasty test but I couldn't
> find a nicer way of being able to reliably manuplate the OS Version).
> I've also patch the OperatingSystemProfileActivator class in the maven-compat
> project but have not been able to write a unit test for that class.
> Can this updated be considered for implementation/inclusion please?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (SLING-12322) Stream Reader should Return SC_OK if content length is less than specified range
[
https://issues.apache.org/jira/browse/SLING-12322?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17848818#comment-17848818
]
Konrad Windszus commented on SLING-12322:
-
I don’t think this is compliant with
https://datatracker.ietf.org/doc/html/rfc7233#section-4.1. What actual issue
are you trying to solve?
> Stream Reader should Return SC_OK if content length is less than specified
> range
>
>
> Key: SLING-12322
> URL: https://issues.apache.org/jira/browse/SLING-12322
> Project: Sling
> Issue Type: Bug
> Components: Servlets
>Affects Versions: Servlets Get 2.2.0
>Reporter: Abhishek Garg
>Priority: Major
>
> if the Request contains following header :
> {code:java}
> Range: bytes=0-8388607 {code}
> and file length is less than this, then we should return SC_OK(200) instead
> of
> SC_PARTIAL_CONTENT(206).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MNG-8097) Validate that each dependency->type is a type registered in an artifact handler
[
https://issues.apache.org/jira/browse/MNG-8097?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konrad Windszus updated MNG-8097:
-
Description:
Currently often the dependency's type is being set to the extension and the
resolution is lenient, i.e. if there is no artifact handler defining the value
given in {{dependency->type}} resolution transparently uses the type as
extension.
That can potentially lead to two issues:
1. Resolution might fail with surprising error messages like
{code}
Could not resolve dependencies for project : The following artifacts could
not be resolved: : Could not transfer artifact
::: from/to ...
{code}
This is an issue for all types not defined by Maven Core itself, e.g. for
https://jackrabbit.apache.org/filevault-package-maven-plugin/index.html which
registers an artifact handler for type {{content-package}} with extension
{{zip}}.
2. The information {{addedToClasspath}}, {{includesDependencies}} and
{{classifier}} from the artifact handler is not evaluated
Compare with
https://maven.apache.org/repositories/artifacts.html#but-where-do-i-set-artifact-extension
was:
Currently often the dependency's type is being set to the extension and the
resolution is lenient, i.e. if there is no artifact handler defining the value
given in {{dependency->type}} resolution transparently uses the type as
extension.
That can potentially lead to two issues:
1. Resolution might fail with surprising error messages like
{code}
Could not resolve dependencies for project : The following artifacts could
not be resolved: : Could not transfer artifact
::: from/to ...
{code}
This is an issue for all types not defined by Maven Core itself, e.g. for
https://jackrabbit.apache.org/filevault-package-maven-plugin/index.html which
registers an artifact handler for type {{content-package}} with extension
{{zip}}.
2. The information {{addedToClasspath}}, {{includesDependencies}} and
{{classifier}} from the artifact handler is not evaluated
> Validate that each dependency->type is a type registered in an artifact
> handler
> ---
>
> Key: MNG-8097
> URL: https://issues.apache.org/jira/browse/MNG-8097
> Project: Maven
> Issue Type: New Feature
>Reporter: Konrad Windszus
>Priority: Major
>
> Currently often the dependency's type is being set to the extension and the
> resolution is lenient, i.e. if there is no artifact handler defining the
> value given in {{dependency->type}} resolution transparently uses the type as
> extension.
> That can potentially lead to two issues:
> 1. Resolution might fail with surprising error messages like
> {code}
> Could not resolve dependencies for project : The following artifacts
> could not be resolved: : Could not transfer artifact
> ::: from/to ...
> {code}
> This is an issue for all types not defined by Maven Core itself, e.g. for
> https://jackrabbit.apache.org/filevault-package-maven-plugin/index.html which
> registers an artifact handler for type {{content-package}} with extension
> {{zip}}.
> 2. The information {{addedToClasspath}}, {{includesDependencies}} and
> {{classifier}} from the artifact handler is not evaluated
> Compare with
> https://maven.apache.org/repositories/artifacts.html#but-where-do-i-set-artifact-extension
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (MNG-8050) Same repositories IDs in settings.xml and POM are not detected
[
https://issues.apache.org/jira/browse/MNG-8050?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konrad Windszus closed MNG-8050.
> Same repositories IDs in settings.xml and POM are not detected
> --
>
> Key: MNG-8050
> URL: https://issues.apache.org/jira/browse/MNG-8050
> Project: Maven
> Issue Type: Improvement
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
> Fix For: 4.0.0, 4.0.0-beta-3
>
>
> When the same repository ID is used in repositories defined in
> # {{settings.xml}} and
> # POM
> the one from the POM is just silently ignored and no ERROR is emitted.
> OTOH when defining repositories with the same ID in POM the following error
> is emitted:
> {code}
> [ERROR] Some problems were encountered while processing the POMs:
> [ERROR] 'repositories.repository.id' must be unique
> {code}
> A similar error should be emitted for repository ID clashes in
> {{settings.xml}} (both local and global) and POM
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (MNG-8050) Same repositories IDs in settings.xml and POM are not detected
[
https://issues.apache.org/jira/browse/MNG-8050?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konrad Windszus resolved MNG-8050.
--
Fix Version/s: 4.0.0
4.0.0-beta-3
Resolution: Fixed
Fixed in
https://github.com/apache/maven/commit/ac80eeabc4cf28199cf65cb58b27eae590b3d16a.
> Same repositories IDs in settings.xml and POM are not detected
> --
>
> Key: MNG-8050
> URL: https://issues.apache.org/jira/browse/MNG-8050
> Project: Maven
> Issue Type: Improvement
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
> Fix For: 4.0.0, 4.0.0-beta-3
>
>
> When the same repository ID is used in repositories defined in
> # {{settings.xml}} and
> # POM
> the one from the POM is just silently ignored and no ERROR is emitted.
> OTOH when defining repositories with the same ID in POM the following error
> is emitted:
> {code}
> [ERROR] Some problems were encountered while processing the POMs:
> [ERROR] 'repositories.repository.id' must be unique
> {code}
> A similar error should be emitted for repository ID clashes in
> {{settings.xml}} (both local and global) and POM
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (SLING-12319) JcrResourceListener should expose the JCR Event's getIdentifier()
[ https://issues.apache.org/jira/browse/SLING-12319?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Konrad Windszus reassigned SLING-12319: --- Assignee: (was: Konrad Windszus) > JcrResourceListener should expose the JCR Event's getIdentifier() > - > > Key: SLING-12319 > URL: https://issues.apache.org/jira/browse/SLING-12319 > Project: Sling > Issue Type: Improvement > Components: JCR >Reporter: Mark Adamcin >Priority: Major > > The JcrResourceChange > ([https://github.com/apache/sling-org-apache-sling-jcr-resource/blob/daa4777ba63264b940e6b9b64df24189828ccd17/src/main/java/org/apache/sling/jcr/resource/api/JcrResourceChange.java#L31] > ) should expose the value of the JCR Event's getIdentifier() method, which > is otherwise read in case it contains a path, but ultimately discarded: > [https://github.com/apache/sling-org-apache-sling-jcr-resource/blob/daa4777ba63264b940e6b9b64df24189828ccd17/src/main/java/org/apache/sling/jcr/resource/internal/JcrResourceListener.java#L116] > > The use case for this is primarily to expose the jcr:uuid of deleted > mix:referenceable nodes to listeners, because once the node is deleted, the > jcr:uuid property can no longer be accessed by the event path. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (JCRVLT-754) check-release does not work for filevault anymore
[ https://issues.apache.org/jira/browse/JCRVLT-754?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17846855#comment-17846855 ] Konrad Windszus commented on JCRVLT-754: bq. no sha1 is generated anymore; however, this is what is put into the generated vote template. The SHA1 is generated, but no longer persisted. It is used in the email template: https://github.com/apache/jackrabbit-filevault/pull/331/files#diff-9c5fb3d1b7e3b0f54bc5c4182965c4fe1f9023d449017cece3005d3f90e8e4d8R300 > check-release does not work for filevault anymore > - > > Key: JCRVLT-754 > URL: https://issues.apache.org/jira/browse/JCRVLT-754 > Project: Jackrabbit FileVault > Issue Type: Task >Reporter: Julian Reschke >Assignee: Konrad Windszus >Priority: Major > Fix For: 3.7.4 > > > Since https://issues.apache.org/jira/browse/JCRVLT-742, no sha1 is generated > anymore; however, this is what is put into the generated vote template. > The proper fix likely would be to put the SHA512 checksum into the vote > template. > Furthermore, the basename of the source artefact changed from"src" to > "source-release". This needs to be adjusted in the check script. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (JCRVLT-742) Stop generating MD5, SHA1 and SHA512 with Ant
[ https://issues.apache.org/jira/browse/JCRVLT-742?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17846854#comment-17846854 ] Konrad Windszus commented on JCRVLT-742: FTR: The SHA1 is still generated and used in the email template being generated, but no longer persisted as file: https://github.com/apache/jackrabbit-filevault/pull/331/files#diff-9c5fb3d1b7e3b0f54bc5c4182965c4fe1f9023d449017cece3005d3f90e8e4d8R300 > Stop generating MD5, SHA1 and SHA512 with Ant > - > > Key: JCRVLT-742 > URL: https://issues.apache.org/jira/browse/JCRVLT-742 > Project: Jackrabbit FileVault > Issue Type: Improvement > Components: package maven plugin >Reporter: Konrad Windszus >Assignee: Konrad Windszus >Priority: Major > Fix For: 3.7.4, package-maven-plugin-1.3.8 > > > Currently there is still manual generation of MD5, SHA1 and SHA512 checksum > via Ant in > https://github.com/apache/jackrabbit-filevault/blob/3c9f668fc608c815db154b2569bf16c71f668428/pom.xml#L325-L340 > and > https://github.com/apache/jackrabbit-filevault-package-maven-plugin/blob/c0433155e825130d1c9a435f5fb837af8e9c46d4/pom.xml#L744-L759. > MD5 and SHA1 should no longer be provided according to > https://infra.apache.org/release-distribution.html#sigs-and-sums and SHA512 > is automatically created through the ASF parent pom > (https://maven.apache.org/pom/asf/#the-apache-release-profile). > In https://jackrabbit.apache.org/jcr/downloads.html#vlt we only link the > SHA512 anyways. > Note: This is only about ASF dist not about the checksums used in Maven > repositories which are transparently created by Maven Resolver. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (JCRVLT-754) check-release does not work for filevault anymore
[ https://issues.apache.org/jira/browse/JCRVLT-754?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Konrad Windszus reassigned JCRVLT-754: -- Assignee: Konrad Windszus > check-release does not work for filevault anymore > - > > Key: JCRVLT-754 > URL: https://issues.apache.org/jira/browse/JCRVLT-754 > Project: Jackrabbit FileVault > Issue Type: Task >Reporter: Julian Reschke >Assignee: Konrad Windszus >Priority: Major > Fix For: 3.7.4 > > > Since https://issues.apache.org/jira/browse/JCRVLT-742, no sha1 is generated > anymore; however, this is what is put into the generated vote template. > The proper fix likely would be to put the SHA512 checksum into the vote > template. > Furthermore, the basename of the source artefact changed from"src" to > "source-release". This needs to be adjusted in the check script. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (JCRVLT-753) FORCE_REMOVE_CONFLICTING_ID Strategy Causing Constraint Violation Exception in AEM Replication
[
https://issues.apache.org/jira/browse/JCRVLT-753?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17846849#comment-17846849
]
Konrad Windszus commented on JCRVLT-753:
We should at least clarify the javadoc of
https://jackrabbit.apache.org/filevault/apidocs/org/apache/jackrabbit/vault/fs/api/IdConflictPolicy.html
to make it clear that {{FORCE_REMOVE_CONFLICTING_ID}} may lead to exceptions
as well.
> FORCE_REMOVE_CONFLICTING_ID Strategy Causing Constraint Violation Exception
> in AEM Replication
> --
>
> Key: JCRVLT-753
> URL: https://issues.apache.org/jira/browse/JCRVLT-753
> Project: Jackrabbit FileVault
> Issue Type: Bug
> Components: vlt
>Reporter: Danilo Banjac
>Assignee: Konrad Windszus
>Priority: Major
> Labels: vault
>
> {*}Issue Description{*}:
> Recent updates to the replication conflict resolution strategy in Adobe
> Experience Manager (AEM) using JCR Filevault have led to failures when
> attempting to replicate content packages. Specifically, the shift from the
> *LEGACY* to the *FORCE_REMOVE_CONFLICTING_ID* strategy causes
> *javax.jcr.nodetype.ConstraintViolationException: OakConstraint0026* due to
> the attempted deletion of mandatory child nodes during the replication
> process.
> {*}Steps to Reproduce{*}:
> 1. Create a content package with a primary node of type *nt:file* and a
> mandatory child node {*}jcr:content{*}.
> 2. Update the version of the content package, ensuring the *jcr:uuid* of the
> *jcr:content* node remains unchanged.
> 3. Replicate the updated content package.
> {*}Observed Behavior{*}:
> - The replication framework attempts to remove the conflicting *jcr:content*
> node due to the identical {*}jcr:uuid{*}.
> - The deletion operation fails because the parent *nt:file* node requires the
> *jcr:content* child node, resulting in a {*}ConstraintViolationException{*}:
> "{*}Mandatory child node jcr:content cannot be removed.{*}"
> {*}Root Cause{*}:
> The *FORCE_REMOVE_CONFLICTING_ID* conflict resolution strategy does not
> account for the constraints of mandatory child nodes in the JCR repository,
> leading to violations when trying to remove these nodes.
> {*}Impact{*}:
> This issue prevents successful replication of updated content packages in
> AEM, disrupting content management workflows and generating errors in the log.
> *Nodes Used for Testing*
> {noformat}
> {
> "jcr:primaryType": "nt:file",
> "jcr:createdBy": "sling-distribution-importer",
> "jcr:created": "Tue May 14 2024 10:13:41 GMT+",
> "jcr:content": {
> "jcr:primaryType": "nt:resource",
> "jcr:mixinTypes": [
> "vlt:Package"
> ],
> "jcr:lastModifiedBy": "admin",
> "jcr:mimeType": "application/zip",
> "jcr:lastModified": "Tue May 14 2024 10:13:32 GMT+",
> ":jcr:data": 35146,
> "jcr:uuid": "cef51ff7-f3fc-4a41-b765-ca4ceb4246ce",
> "vlt:definition": {
> "jcr:primaryType": "vlt:PackageDefinition",
> "testedWith": "",
> "lastUnpacked": "Tue May 14 2024 10:13:41 GMT+",
> "lastUnpackedBy": "sling-distribution-importer",
> "requiresRestart": false,
> "requiresRoot": false,
> "lastWrapped": "Fri Apr 26 2024 12:27:44 GMT+",
> "buildCount": "17",
> "providerLink": "",
> "providerName": "",
> "jcr:created": "Fri Apr 26 2024 12:27:44 GMT+",
> "name": "global-truststore",
> "group": "admin-tasks",
> "version": "15.0",
> "dependencies": [],
> "fixedBugs": "",
> "jcr:lastModified": "Fri Apr 26 2024 12:27:44 GMT+",
> "lastUnwrapped": "Tue May 14 2024 10:13:32 GMT+",
> "providerUrl": "",
> "screenshots": {
> "jcr:primaryType": "nt:unstructured"
> },
> "filter": {
> "jcr:primaryType": "nt:unstructured",
> "f0": {
> "jcr:primaryType": "nt:unstructured",
> "propertyRules": [],
> "mode": "replace",
> "root": "/etc/truststore",
> "rules": []
> }
> }
> }
> }
> }{noformat}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (MNG-7375) Potential NPE in o.a.m.artifact.repository.metadata.Metadata.merge(...) with invalid/incomplete plugin metadata
[
https://issues.apache.org/jira/browse/MNG-7375?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17846728#comment-17846728
]
Konrad Windszus edited comment on MNG-7375 at 5/15/24 6:15 PM:
---
Although true, this is due to a limitation in modello:
https://github.com/codehaus-plexus/modello/blob/8467ab87f95557c8c6409f5ebe613caf240836b3/modello-plugins/modello-plugin-xsd/src/main/java/org/codehaus/modello/plugin/xsd/XsdGenerator.java#L245-L247
Compare with
https://github.com/apache/maven/blob/maven-3.9.x/maven-plugin-api/src/main/mdo/plugin.mdo#L75-L80
was (Author: kwin):
Although true, this is due to a limitation in modello:
https://github.com/codehaus-plexus/modello/blob/8467ab87f95557c8c6409f5ebe613caf240836b3/modello-plugins/modello-plugin-xsd/src/main/java/org/codehaus/modello/plugin/xsd/XsdGenerator.java#L245-L247
> Potential NPE in o.a.m.artifact.repository.metadata.Metadata.merge(...) with
> invalid/incomplete plugin metadata
> ---
>
> Key: MNG-7375
> URL: https://issues.apache.org/jira/browse/MNG-7375
> Project: Maven
> Issue Type: Improvement
> Components: Artifacts and Repositories
>Affects Versions: 3.8.4
>Reporter: Konrad Windszus
>Priority: Major
> Attachments: NEXUS-30749 - Broken groupId metadata and follow-up NPE
> during
> org.sonatype.nexus.maven.staging.deploy.strategy.AbstractDeployStrategy.deployUp
> - Sonatype JIRA.pdf
>
>
> Currently the metadata at
> https://repository.apache.org/service/local/repositories/snapshots/content/org/apache/jackrabbit/maven-metadata.xml
> contains an invalid entry without a prefix:
> {code:xml}
>
>
>
> Apache Jackrabbit FileVault - Package Maven Plugin
> filevault-package
> filevault-package-maven-plugin
>
>
> filevault-package-maven-plugin
> filevault-package-maven-plugin
>
>
>
> {code}
> This leads to an NPE when trying to deploy a new version with
> {{org.apache.maven.artifact.deployer.DefaultArtifactDeployer.deploy(...)}}:
> {noformat}
> Caused by: java.lang.NullPointerException
> at org.apache.maven.artifact.repository.metadata.Metadata.merge
> (Metadata.java:276)
> at
> org.apache.maven.artifact.repository.metadata.AbstractRepositoryMetadata.updateRepositoryMetadata
> (AbstractRepositoryMetadata.java:121)
> at
> org.apache.maven.artifact.repository.metadata.AbstractRepositoryMetadata.storeInLocalRepository
> (AbstractRepositoryMetadata.java:67)
> at org.apache.maven.artifact.repository.metadata.MetadataBridge.merge
> (MetadataBridge.java:65)
> at org.eclipse.aether.internal.impl.DefaultDeployer.upload
> (DefaultDeployer.java:433)
> at org.eclipse.aether.internal.impl.DefaultDeployer.deploy
> (DefaultDeployer.java:321)
> at org.eclipse.aether.internal.impl.DefaultDeployer.deploy
> (DefaultDeployer.java:213)
> at org.eclipse.aether.internal.impl.DefaultRepositorySystem.deploy
> (DefaultRepositorySystem.java:386)
> at org.apache.maven.artifact.deployer.DefaultArtifactDeployer.deploy
> (DefaultArtifactDeployer.java:142)
> {noformat}
> Although this happened in the context of using
> "[org.sonatype.plugins:nexus-staging-maven-plugin|https://github.com/sonatype/nexus-maven-plugins]:1.6.8;
> (issue https://issues.sonatype.org/browse/NEXUS-30749 opened, exported to
> [^NEXUS-30749 - Broken groupId metadata and follow-up NPE during
> org.sonatype.nexus.maven.staging.deploy.strategy.AbstractDeployStrategy.deployUp
> - Sonatype JIRA.pdf] ), the affected code is in Maven.
> The metadata is probably invalid but the Metadata class should be more robust
> when trying to do the merge in
> https://github.com/apache/maven/blob/951b5ee95f40147abbc2bb9d928e408b85d5aef3/maven-repository-metadata/src/main/mdo/metadata.mdo#L100
> and just ignore all plugin entries without all mandatory elements.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MNG-7375) Potential NPE in o.a.m.artifact.repository.metadata.Metadata.merge(...) with invalid/incomplete plugin metadata
[
https://issues.apache.org/jira/browse/MNG-7375?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17846728#comment-17846728
]
Konrad Windszus commented on MNG-7375:
--
Although true, this is due to a limitation in modello:
https://github.com/codehaus-plexus/modello/blob/8467ab87f95557c8c6409f5ebe613caf240836b3/modello-plugins/modello-plugin-xsd/src/main/java/org/codehaus/modello/plugin/xsd/XsdGenerator.java#L245-L247
> Potential NPE in o.a.m.artifact.repository.metadata.Metadata.merge(...) with
> invalid/incomplete plugin metadata
> ---
>
> Key: MNG-7375
> URL: https://issues.apache.org/jira/browse/MNG-7375
> Project: Maven
> Issue Type: Improvement
> Components: Artifacts and Repositories
>Affects Versions: 3.8.4
>Reporter: Konrad Windszus
>Priority: Major
> Attachments: NEXUS-30749 - Broken groupId metadata and follow-up NPE
> during
> org.sonatype.nexus.maven.staging.deploy.strategy.AbstractDeployStrategy.deployUp
> - Sonatype JIRA.pdf
>
>
> Currently the metadata at
> https://repository.apache.org/service/local/repositories/snapshots/content/org/apache/jackrabbit/maven-metadata.xml
> contains an invalid entry without a prefix:
> {code:xml}
>
>
>
> Apache Jackrabbit FileVault - Package Maven Plugin
> filevault-package
> filevault-package-maven-plugin
>
>
> filevault-package-maven-plugin
> filevault-package-maven-plugin
>
>
>
> {code}
> This leads to an NPE when trying to deploy a new version with
> {{org.apache.maven.artifact.deployer.DefaultArtifactDeployer.deploy(...)}}:
> {noformat}
> Caused by: java.lang.NullPointerException
> at org.apache.maven.artifact.repository.metadata.Metadata.merge
> (Metadata.java:276)
> at
> org.apache.maven.artifact.repository.metadata.AbstractRepositoryMetadata.updateRepositoryMetadata
> (AbstractRepositoryMetadata.java:121)
> at
> org.apache.maven.artifact.repository.metadata.AbstractRepositoryMetadata.storeInLocalRepository
> (AbstractRepositoryMetadata.java:67)
> at org.apache.maven.artifact.repository.metadata.MetadataBridge.merge
> (MetadataBridge.java:65)
> at org.eclipse.aether.internal.impl.DefaultDeployer.upload
> (DefaultDeployer.java:433)
> at org.eclipse.aether.internal.impl.DefaultDeployer.deploy
> (DefaultDeployer.java:321)
> at org.eclipse.aether.internal.impl.DefaultDeployer.deploy
> (DefaultDeployer.java:213)
> at org.eclipse.aether.internal.impl.DefaultRepositorySystem.deploy
> (DefaultRepositorySystem.java:386)
> at org.apache.maven.artifact.deployer.DefaultArtifactDeployer.deploy
> (DefaultArtifactDeployer.java:142)
> {noformat}
> Although this happened in the context of using
> "[org.sonatype.plugins:nexus-staging-maven-plugin|https://github.com/sonatype/nexus-maven-plugins]:1.6.8;
> (issue https://issues.sonatype.org/browse/NEXUS-30749 opened, exported to
> [^NEXUS-30749 - Broken groupId metadata and follow-up NPE during
> org.sonatype.nexus.maven.staging.deploy.strategy.AbstractDeployStrategy.deployUp
> - Sonatype JIRA.pdf] ), the affected code is in Maven.
> The metadata is probably invalid but the Metadata class should be more robust
> when trying to do the merge in
> https://github.com/apache/maven/blob/951b5ee95f40147abbc2bb9d928e408b85d5aef3/maven-repository-metadata/src/main/mdo/metadata.mdo#L100
> and just ignore all plugin entries without all mandatory elements.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (JCRVLT-753) FORCE_REMOVE_CONFLICTING_ID Strategy Causing Constraint Violation Exception in AEM Replication
[
https://issues.apache.org/jira/browse/JCRVLT-753?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17846704#comment-17846704
]
Konrad Windszus commented on JCRVLT-753:
[~dbanjac] Can you provide a failing IT in a PR?
However I don't have a clever idea how to solve this edge case as all options
outlined above by [~reschke] seem quite unexpected to the user either so any
other suggestions would be much appreciated.
> FORCE_REMOVE_CONFLICTING_ID Strategy Causing Constraint Violation Exception
> in AEM Replication
> --
>
> Key: JCRVLT-753
> URL: https://issues.apache.org/jira/browse/JCRVLT-753
> Project: Jackrabbit FileVault
> Issue Type: Bug
> Components: vlt
>Reporter: Danilo Banjac
>Assignee: Konrad Windszus
>Priority: Major
> Labels: vault
>
> {*}Issue Description{*}:
> Recent updates to the replication conflict resolution strategy in Adobe
> Experience Manager (AEM) using JCR Filevault have led to failures when
> attempting to replicate content packages. Specifically, the shift from the
> *LEGACY* to the *FORCE_REMOVE_CONFLICTING_ID* strategy causes
> *javax.jcr.nodetype.ConstraintViolationException: OakConstraint0026* due to
> the attempted deletion of mandatory child nodes during the replication
> process.
> {*}Steps to Reproduce{*}:
> 1. Create a content package with a primary node of type *nt:file* and a
> mandatory child node {*}jcr:content{*}.
> 2. Update the version of the content package, ensuring the *jcr:uuid* of the
> *jcr:content* node remains unchanged.
> 3. Replicate the updated content package.
> {*}Observed Behavior{*}:
> - The replication framework attempts to remove the conflicting *jcr:content*
> node due to the identical {*}jcr:uuid{*}.
> - The deletion operation fails because the parent *nt:file* node requires the
> *jcr:content* child node, resulting in a {*}ConstraintViolationException{*}:
> "{*}Mandatory child node jcr:content cannot be removed.{*}"
> {*}Root Cause{*}:
> The *FORCE_REMOVE_CONFLICTING_ID* conflict resolution strategy does not
> account for the constraints of mandatory child nodes in the JCR repository,
> leading to violations when trying to remove these nodes.
> {*}Impact{*}:
> This issue prevents successful replication of updated content packages in
> AEM, disrupting content management workflows and generating errors in the log.
> *Nodes Used for Testing*
> {noformat}
> {
> "jcr:primaryType": "nt:file",
> "jcr:createdBy": "sling-distribution-importer",
> "jcr:created": "Tue May 14 2024 10:13:41 GMT+",
> "jcr:content": {
> "jcr:primaryType": "nt:resource",
> "jcr:mixinTypes": [
> "vlt:Package"
> ],
> "jcr:lastModifiedBy": "admin",
> "jcr:mimeType": "application/zip",
> "jcr:lastModified": "Tue May 14 2024 10:13:32 GMT+",
> ":jcr:data": 35146,
> "jcr:uuid": "cef51ff7-f3fc-4a41-b765-ca4ceb4246ce",
> "vlt:definition": {
> "jcr:primaryType": "vlt:PackageDefinition",
> "testedWith": "",
> "lastUnpacked": "Tue May 14 2024 10:13:41 GMT+",
> "lastUnpackedBy": "sling-distribution-importer",
> "requiresRestart": false,
> "requiresRoot": false,
> "lastWrapped": "Fri Apr 26 2024 12:27:44 GMT+",
> "buildCount": "17",
> "providerLink": "",
> "providerName": "",
> "jcr:created": "Fri Apr 26 2024 12:27:44 GMT+",
> "name": "global-truststore",
> "group": "admin-tasks",
> "version": "15.0",
> "dependencies": [],
> "fixedBugs": "",
> "jcr:lastModified": "Fri Apr 26 2024 12:27:44 GMT+",
> "lastUnwrapped": "Tue May 14 2024 10:13:32 GMT+",
> "providerUrl": "",
> "screenshots": {
> "jcr:primaryType": "nt:unstructured"
> },
> "filter": {
> "jcr:primaryType": "nt:unstructured",
> "f0": {
> "jcr:primaryType": "nt:unstructured",
> "propertyRules": [],
> "mode": "replace",
> "root": "/etc/truststore",
> "rules": []
> }
> }
> }
> }
> }{noformat}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (JCRVLT-751) ExportOptions.rootPath not properly converted to platform name format
[ https://issues.apache.org/jira/browse/JCRVLT-751?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Konrad Windszus updated JCRVLT-751: --- Resolution: Fixed Status: Resolved (was: Patch Available) Fixed in https://github.com/apache/jackrabbit-filevault/commit/33b23e126e7e7260582dd43d4b9f4c93958da674. > ExportOptions.rootPath not properly converted to platform name format > - > > Key: JCRVLT-751 > URL: https://issues.apache.org/jira/browse/JCRVLT-751 > Project: Jackrabbit FileVault > Issue Type: Bug > Components: vlt >Affects Versions: 3.7.2 >Reporter: Timothée Maret >Assignee: Konrad Windszus >Priority: Major > Labels: vault > Fix For: 3.7.4 > > > AEM has a user synchronisation capability in the publish tier. The > synchronisation mechanism relies on FileVault to export and import content. > Users stored in the repository under a path that starts with a _ and that > contain another _ can be exported but fail to be re-imported. For instance, > the user stored under the path /home/users/test/_6k_test-user-a won't be > imported. > Debugging this issue, it seems that FileVault treats the _6k_ pattern as a > namespace and thus skip the resource upon import because the paths don't > match. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (FELIX-6704) Improve error logging for exceptions thrown from Configuration Plugins in ConfigurationManager
Konrad Windszus created FELIX-6704:
--
Summary: Improve error logging for exceptions thrown from
Configuration Plugins in ConfigurationManager
Key: FELIX-6704
URL: https://issues.apache.org/jira/browse/FELIX-6704
Project: Felix
Issue Type: Improvement
Components: Configuration Admin
Affects Versions: configadmin-1.9.24
Reporter: Konrad Windszus
Currently all throwables are caught in
https://github.com/apache/felix-dev/blob/517f9a0c89cad1866f315255568b40c568f5239d/configadmin/src/main/java/org/apache/felix/cm/impl/ConfigurationManager.java#L932
and logged.
The important factory or configuration PID is not emitted in the log message
though.
Example:
{code}
07.05.2024 20:41:33.820 *ERROR* [FelixLogListener]
LogService.org.apache.felix.configadmin Service
[org.apache.felix.cm.ConfigurationAdmin,47,
[org.osgi.service.cm.ConfigurationAdmin]] Unexpected problem calling
configuration plugin [org.osgi.service.cm.ConfigurationPlugin, id=41,
bundle=38/slinginstall:org.apache.felix.configadmin.plugin.interpolation-1.2.6.jar]
(org.apache.felix.log.LogException:
org.osgi.util.converter.ConversionException: Cannot convert TO BE PROVIDED to
class java.lang.Integer)
org.apache.felix.log.LogException: org.osgi.util.converter.ConversionException:
Cannot convert TO BE PROVIDED to class java.lang.Integer
at org.osgi.util.converter.ConvertingImpl.to(ConvertingImpl.java:243)
at
org.osgi.util.converter.CustomConverterImpl$ConvertingWrapper.to(CustomConverterImpl.java:183)
at
org.osgi.util.converter.CustomConverterImpl$ConvertingWrapper.to(CustomConverterImpl.java:151)
at
org.osgi.util.converter.CustomConverterImpl$ConvertingWrapper.to(CustomConverterImpl.java:141)
at
org.apache.felix.configadmin.plugin.interpolation.InterpolationConfigurationPlugin.convertType(InterpolationConfigurationPlugin.java:308)
at
org.apache.felix.configadmin.plugin.interpolation.InterpolationConfigurationPlugin.lambda$replace$0(InterpolationConfigurationPlugin.java:197)
at
org.apache.felix.configadmin.plugin.interpolation.Interpolator.replace(Interpolator.java:149)
at
org.apache.felix.configadmin.plugin.interpolation.InterpolationConfigurationPlugin.replace(InterpolationConfigurationPlugin.java:179)
at
org.apache.felix.configadmin.plugin.interpolation.InterpolationConfigurationPlugin.getNewValue(InterpolationConfigurationPlugin.java:171)
at
org.apache.felix.configadmin.plugin.interpolation.InterpolationConfigurationPlugin.modifyConfiguration(InterpolationConfigurationPlugin.java:133)
at
org.apache.felix.cm.impl.ConfigurationManager.callPlugins(ConfigurationManager.java:928)
[org.apache.felix.configadmin:1.9.24]
at
org.apache.felix.cm.impl.ConfigurationAdapter.getProcessedProperties(ConfigurationAdapter.java:293)
[org.apache.felix.configadmin:1.9.24]
at
org.apache.felix.scr.impl.manager.RegionConfigurationSupport.getConfigurationInfo(RegionConfigurationSupport.java:532)
[org.apache.felix.scr:2.2.4]
at
org.apache.felix.scr.impl.manager.RegionConfigurationSupport.configurationEvent(RegionConfigurationSupport.java:333)
[org.apache.felix.scr:2.2.4]
at
org.apache.felix.scr.impl.manager.RegionConfigurationSupport$2.configurationEvent(RegionConfigurationSupport.java:115)
[org.apache.felix.scr:2.2.4]
at
org.apache.felix.cm.impl.ConfigurationManager$FireConfigurationEvent.sendEvent(ConfigurationManager.java:1721)
[org.apache.felix.configadmin:1.9.24]
at
org.apache.felix.cm.impl.ConfigurationManager$FireConfigurationEvent.run(ConfigurationManager.java:1662)
[org.apache.felix.configadmin:1.9.24]
at org.apache.felix.cm.impl.UpdateThread.run0(UpdateThread.java:122)
[org.apache.felix.configadmin:1.9.24]
at org.apache.felix.cm.impl.UpdateThread.run(UpdateThread.java:84)
[org.apache.felix.configadmin:1.9.24]
at java.base/java.lang.Thread.run(Thread.java:829)
{code}
For debugging purposes the configuration PID is the most crucial bit of
information and this is missing from this log message.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (MPLUGIN-522) The auto prerequisites are way to aggressive
[ https://issues.apache.org/jira/browse/MPLUGIN-522?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17844188#comment-17844188 ] Konrad Windszus edited comment on MPLUGIN-522 at 5/7/24 8:18 AM: - bq. why it gets "highest class version present on classpath"? Why not compiler target instead? ... Because in general it is fair to assume that every class being embedded in the plugin is supposed to be executed. That requires a Java version capable of digesting the class version. Not every class being shipped with the plugin is necessarily compiled in the same build. bq. Similarly, if I have one class that is Java 22, the plugin prerequisite is NOT Java 22. It the class is in the plugin classpath I would assume that this is necessary for plugin execution (not necessarily for each mojo). If the class isn't being called then it shouldn't be there in the first place... bq. if I compile against 3.9.6 Maven APIs, that – due backward compatibility – does NOT mean plugin "has a prerequisite of 3.9.6". As we all know, they are happily working even with 3.6.3 or even 3.2.x. What you describe is not backwards-compatibility but forwards-compatibility. Each minor Maven version may add new methods/classes to Maven API in a backwards-compatible way. Therefore it is fair to assume that the Maven API you compile against is the minimally required Maven version. What you are running into are edge cases which IMHO justify that you override the automatically created values (i.e. one class with bytecode for Java22 not being executed by the Mojo for some reason, compiling against a newer Maven version than you require). I don't want plugins to not state prerequisites at all just because plugin developers are too lazy, because that is very frustrating for users not complying with those (unexplicit) prerequisites. was (Author: kwin): bq. why it gets "highest class version present on classpath"? Why not compiler target instead? Because in general it is fair to assume that every class being embedded in the plugin is supposed to be executed. That requires a Java version capable of digesting the class version. Not every class being shipped with the plugin is necessarily compiled in the same build. bq. if I compile against 3.9.6 Maven APIs, that – due backward compatibility – does NOT mean plugin "has a prerequisite of 3.9.6". As we all know, they are happily working even with 3.6.3 or even 3.2.x. What you describe is not backwards-compatibility but forwards-compatibility. Each minor Maven version may add new methods/classes to Maven API in a backwards-compatible way. Therefore it is fair to assume that the Maven API you compile against is the minimally required Maven version. What you are running into are edge cases which IMHO justify that you override the automatically created values (i.e. one class with bytecode for Java22 not being executed by the Mojo for some reason, compiling against a newer Maven version than you require). I don't want plugins to not state prerequisites at all just because plugin developers are too lazy, because that is very frustrating for users not complying with those (unexplicit) prerequisites. > The auto prerequisites are way to aggressive > > > Key: MPLUGIN-522 > URL: https://issues.apache.org/jira/browse/MPLUGIN-522 > Project: Maven Plugin Tools > Issue Type: Bug > Components: Plugin Plugin >Reporter: Tamas Cservenak >Priority: Major > > IMHO the implementation done in MPLUGIN-425 and MPLUGIN-424 are wrong. > They are way too aggresive and violate backward compatibility: if new feature > is not explicitly set by user, code should not "come up" with some automatic > value. By having the value not set simply means user does not want to use it. > This is especially true for (maven or java) prerequisite, as it creates HARD > BREAKAGE if not met. Use of prerequisite is opt-in, but now it is FORCED onto > user. > [~kwin] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (MPLUGIN-522) The auto prerequisites are way to aggressive
[ https://issues.apache.org/jira/browse/MPLUGIN-522?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17844188#comment-17844188 ] Konrad Windszus edited comment on MPLUGIN-522 at 5/7/24 8:10 AM: - bq. why it gets "highest class version present on classpath"? Why not compiler target instead? Because in general it is fair to assume that every class being embedded in the plugin is supposed to be executed. That requires a Java version capable of digesting the class version. Not every class being shipped with the plugin is necessarily compiled in the same build. bq. if I compile against 3.9.6 Maven APIs, that – due backward compatibility – does NOT mean plugin "has a prerequisite of 3.9.6". As we all know, they are happily working even with 3.6.3 or even 3.2.x. What you describe is not backwards-compatibility but forwards-compatibility. Each minor Maven version may add new methods/classes to Maven API in a backwards-compatible way. Therefore it is fair to assume that the Maven API you compile against is the minimally required Maven version. What you are running into are edge cases which IMHO justify that you override the automatically created values (i.e. one class with bytecode for Java22 not being executed by the Mojo for some reason, compiling against a newer Maven version than you require). I don't want plugins to not state prerequisites at all just because plugin developers are too lazy, because that is very frustrating for users not complying with those (unexplicit) prerequisites. was (Author: kwin): bq. why it gets "highest class version present on classpath"? Why not compiler target instead? Because in general it is fair to assume that every class being embedded in the plugin is supposed to be executed. That requires a Java version capable of digesting the class version. Not every class being shipped with the plugin is necessarily compiled in the same build. bq. if I compile against 3.9.6 Maven APIs, that – due backward compatibility – does NOT mean plugin "has a prerequisite of 3.9.6". As we all know, they are happily working even with 3.6.3 or even 3.2.x. What you describe is not backwards-compatibility but forwards-compatibility. Each minor Maven version may add new methods/classes to Maven API in a backwards-compatible way. Therefore it is fair to assume that the Maven API you compile against is the minimally required Maven version. What you are running into are edge cases which IMHO justify that you override the automatically created values (i.e. one class with bytecode for Java22 not being executed by the Mojo for some reason, compiling against a newer Maven version than you require). I don't want plugins to not state prerequisites at all just because plugin developers are too lazy. > The auto prerequisites are way to aggressive > > > Key: MPLUGIN-522 > URL: https://issues.apache.org/jira/browse/MPLUGIN-522 > Project: Maven Plugin Tools > Issue Type: Bug > Components: Plugin Plugin >Reporter: Tamas Cservenak >Priority: Major > > IMHO the implementation done in MPLUGIN-425 and MPLUGIN-424 are wrong. > They are way too aggresive and violate backward compatibility: if new feature > is not explicitly set by user, code should not "come up" with some automatic > value. By having the value not set simply means user does not want to use it. > This is especially true for (maven or java) prerequisite, as it creates HARD > BREAKAGE if not met. Use of prerequisite is opt-in, but now it is FORCED onto > user. > [~kwin] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MPLUGIN-522) The auto prerequisites are way to aggressive
[ https://issues.apache.org/jira/browse/MPLUGIN-522?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17844188#comment-17844188 ] Konrad Windszus commented on MPLUGIN-522: - > why it gets "highest class version present on classpath"? Why not compiler > target instead? Because in general it is fair to assume that every class being embedded in the plugin is supposed to be executed. That requires a Java version capable of digesting the class version. Not every class being shipped with the plugin is necessarily compiled in the same build. > if I compile against 3.9.6 Maven APIs, that – due backward compatibility – > does NOT mean plugin "has a prerequisite of 3.9.6". As we all know, they are > happily working even with 3.6.3 or even 3.2.x. What you describe is not backwards-compatibility but forwards-compatibility. Each minor Maven version may add new methods/classes to Maven API in a backwards-compatible way. Therefore it is fair to assume that the Maven API you compile against is the minimally required Maven version. What you are running into are edge cases which IMHO justify that you override the automatically created values (i.e. one class with bytecode for Java22 not being executed by the Mojo for some reason, compiling against a newer Maven version than you require). I don't want plugins to not state prerequisites at all just because plugin developers are too lazy. > The auto prerequisites are way to aggressive > > > Key: MPLUGIN-522 > URL: https://issues.apache.org/jira/browse/MPLUGIN-522 > Project: Maven Plugin Tools > Issue Type: Bug > Components: Plugin Plugin >Reporter: Tamas Cservenak >Priority: Major > > IMHO the implementation done in MPLUGIN-425 and MPLUGIN-424 are wrong. > They are way too aggresive and violate backward compatibility: if new feature > is not explicitly set by user, code should not "come up" with some automatic > value. By having the value not set simply means user does not want to use it. > This is especially true for (maven or java) prerequisite, as it creates HARD > BREAKAGE if not met. Use of prerequisite is opt-in, but now it is FORCED onto > user. > [~kwin] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (MPLUGIN-522) The auto prerequisites are way to aggressive
[ https://issues.apache.org/jira/browse/MPLUGIN-522?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17844188#comment-17844188 ] Konrad Windszus edited comment on MPLUGIN-522 at 5/7/24 8:08 AM: - bq. why it gets "highest class version present on classpath"? Why not compiler target instead? Because in general it is fair to assume that every class being embedded in the plugin is supposed to be executed. That requires a Java version capable of digesting the class version. Not every class being shipped with the plugin is necessarily compiled in the same build. bq. if I compile against 3.9.6 Maven APIs, that – due backward compatibility – does NOT mean plugin "has a prerequisite of 3.9.6". As we all know, they are happily working even with 3.6.3 or even 3.2.x. What you describe is not backwards-compatibility but forwards-compatibility. Each minor Maven version may add new methods/classes to Maven API in a backwards-compatible way. Therefore it is fair to assume that the Maven API you compile against is the minimally required Maven version. What you are running into are edge cases which IMHO justify that you override the automatically created values (i.e. one class with bytecode for Java22 not being executed by the Mojo for some reason, compiling against a newer Maven version than you require). I don't want plugins to not state prerequisites at all just because plugin developers are too lazy. was (Author: kwin): > why it gets "highest class version present on classpath"? Why not compiler > target instead? Because in general it is fair to assume that every class being embedded in the plugin is supposed to be executed. That requires a Java version capable of digesting the class version. Not every class being shipped with the plugin is necessarily compiled in the same build. > if I compile against 3.9.6 Maven APIs, that – due backward compatibility – > does NOT mean plugin "has a prerequisite of 3.9.6". As we all know, they are > happily working even with 3.6.3 or even 3.2.x. What you describe is not backwards-compatibility but forwards-compatibility. Each minor Maven version may add new methods/classes to Maven API in a backwards-compatible way. Therefore it is fair to assume that the Maven API you compile against is the minimally required Maven version. What you are running into are edge cases which IMHO justify that you override the automatically created values (i.e. one class with bytecode for Java22 not being executed by the Mojo for some reason, compiling against a newer Maven version than you require). I don't want plugins to not state prerequisites at all just because plugin developers are too lazy. > The auto prerequisites are way to aggressive > > > Key: MPLUGIN-522 > URL: https://issues.apache.org/jira/browse/MPLUGIN-522 > Project: Maven Plugin Tools > Issue Type: Bug > Components: Plugin Plugin >Reporter: Tamas Cservenak >Priority: Major > > IMHO the implementation done in MPLUGIN-425 and MPLUGIN-424 are wrong. > They are way too aggresive and violate backward compatibility: if new feature > is not explicitly set by user, code should not "come up" with some automatic > value. By having the value not set simply means user does not want to use it. > This is especially true for (maven or java) prerequisite, as it creates HARD > BREAKAGE if not met. Use of prerequisite is opt-in, but now it is FORCED onto > user. > [~kwin] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (JCR-5051) ISO9075.encodePath/encode should preserve wildcard
[
https://issues.apache.org/jira/browse/JCR-5051?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konrad Windszus updated JCR-5051:
-
Description:
Currently the wildcard {{"*"}} is escaped as well to {{"_x002a_"}}.
This is not intended as in the context of XPath the wildcard is an allowed
character in the grammar
(https://www.w3.org/TR/xpath20/#prod-xpath-ElementNameOrWildcard).
Not sure if ISO9075 is used for other purposes so it might be better to
explicitly add another method to keep the wildcard in place.
was:
Currently the wildcard {{"*"}} is escaped as well to {{"_x002a_"}}.
This is not intended as in the context of XPath the wildcard is an allowed
character in the grammar
(https://www.w3.org/TR/xpath20/#prod-xpath-ElementNameOrWildcard).
Not sure if ISO9075 is used for other purposes so it might be better to
explicitly add another method to keep the wildcard in place.
> ISO9075.encodePath/encode should preserve wildcard
> --
>
> Key: JCR-5051
> URL: https://issues.apache.org/jira/browse/JCR-5051
> Project: Jackrabbit Content Repository
> Issue Type: New Feature
> Components: jackrabbit-jcr-commons
>Reporter: Konrad Windszus
>Priority: Major
>
> Currently the wildcard {{"*"}} is escaped as well to {{"_x002a_"}}.
> This is not intended as in the context of XPath the wildcard is an allowed
> character in the grammar
> (https://www.w3.org/TR/xpath20/#prod-xpath-ElementNameOrWildcard).
> Not sure if ISO9075 is used for other purposes so it might be better to
> explicitly add another method to keep the wildcard in place.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (JCR-5051) ISO9075.encodePath/encode should preserve wildcard
[
https://issues.apache.org/jira/browse/JCR-5051?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konrad Windszus updated JCR-5051:
-
Description:
Currently the wildcard {{"*"}} is escaped as well to {{"_x002a_"}}.
This is not intended as in the context of XPath the wildcard is an allowed
character in the grammar
(https://www.w3.org/TR/xpath20/#prod-xpath-ElementNameOrWildcard).
Not sure if ISO9075 is used for other purposes so it might be better to
explicitly add another method to keep the wildcard in place.
was:
Currently the wildcard {{*}} is escaped as well to {{_x002a_}}.
This is not intended as in the context of XPath the wildcard is an allowed
character in the grammar
(https://www.w3.org/TR/xpath20/#prod-xpath-ElementNameOrWildcard).
Not sure if ISO9075 is used for other purposes so it might be better to
explicitly add another method to keep the wildcard in place.
> ISO9075.encodePath/encode should preserve wildcard
> --
>
> Key: JCR-5051
> URL: https://issues.apache.org/jira/browse/JCR-5051
> Project: Jackrabbit Content Repository
> Issue Type: New Feature
> Components: jackrabbit-jcr-commons
>Reporter: Konrad Windszus
>Priority: Major
>
> Currently the wildcard {{"*"}} is escaped as well to {{"_x002a_"}}.
> This is not intended as in the context of XPath the wildcard is an allowed
> character in the grammar
> (https://www.w3.org/TR/xpath20/#prod-xpath-ElementNameOrWildcard).
> Not sure if ISO9075 is used for other purposes so it might be better to
> explicitly add another method to keep the wildcard in place.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (JCR-5051) ISO9075.encodePath/encode should preserve wildcard
Konrad Windszus created JCR-5051:
Summary: ISO9075.encodePath/encode should preserve wildcard
Key: JCR-5051
URL: https://issues.apache.org/jira/browse/JCR-5051
Project: Jackrabbit Content Repository
Issue Type: New Feature
Components: jackrabbit-jcr-commons
Reporter: Konrad Windszus
Currently the wildcard {{*}} is escaped as well to {{_x002a_}}.
This is not intended as in the context of XPath the wildcard is an allowed
character in the grammar
(https://www.w3.org/TR/xpath20/#prod-xpath-ElementNameOrWildcard).
Not sure if ISO9075 is used for other purposes so it might be better to
explicitly add another method to keep the wildcard in place.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (JCRVLT-751) ExportOptions.rootPath not properly converted to platform name format
[ https://issues.apache.org/jira/browse/JCRVLT-751?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Konrad Windszus updated JCRVLT-751: --- Fix Version/s: 3.7.4 > ExportOptions.rootPath not properly converted to platform name format > - > > Key: JCRVLT-751 > URL: https://issues.apache.org/jira/browse/JCRVLT-751 > Project: Jackrabbit FileVault > Issue Type: Bug > Components: vlt >Affects Versions: 3.7.2 >Reporter: Timothée Maret >Assignee: Konrad Windszus >Priority: Major > Labels: vault > Fix For: 3.7.4 > > > AEM has a user synchronisation capability in the publish tier. The > synchronisation mechanism relies on FileVault to export and import content. > Users stored in the repository under a path that starts with a _ and that > contain another _ can be exported but fail to be re-imported. For instance, > the user stored under the path /home/users/test/_6k_test-user-a won't be > imported. > Debugging this issue, it seems that FileVault treats the _6k_ pattern as a > namespace and thus skip the resource upon import because the paths don't > match. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (JCRVLT-751) ExportOptions.rootPath not properly converted to platform name format
[ https://issues.apache.org/jira/browse/JCRVLT-751?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Konrad Windszus updated JCRVLT-751: --- Summary: ExportOptions.rootPath not properly converted to platform name format (was: ExportOptions.rootPath not properly unescaped during filter rule mapping) > ExportOptions.rootPath not properly converted to platform name format > - > > Key: JCRVLT-751 > URL: https://issues.apache.org/jira/browse/JCRVLT-751 > Project: Jackrabbit FileVault > Issue Type: Bug > Components: vlt >Affects Versions: 3.7.2 >Reporter: Timothée Maret >Priority: Major > Labels: vault > > AEM has a user synchronisation capability in the publish tier. The > synchronisation mechanism relies on FileVault to export and import content. > Users stored in the repository under a path that starts with a _ and that > contain another _ can be exported but fail to be re-imported. For instance, > the user stored under the path /home/users/test/_6k_test-user-a won't be > imported. > Debugging this issue, it seems that FileVault treats the _6k_ pattern as a > namespace and thus skip the resource upon import because the paths don't > match. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (JCRVLT-751) ExportOptions.rootPath not properly converted to platform name format
[ https://issues.apache.org/jira/browse/JCRVLT-751?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Konrad Windszus updated JCRVLT-751: --- Assignee: Konrad Windszus Status: Patch Available (was: Open) > ExportOptions.rootPath not properly converted to platform name format > - > > Key: JCRVLT-751 > URL: https://issues.apache.org/jira/browse/JCRVLT-751 > Project: Jackrabbit FileVault > Issue Type: Bug > Components: vlt >Affects Versions: 3.7.2 >Reporter: Timothée Maret >Assignee: Konrad Windszus >Priority: Major > Labels: vault > > AEM has a user synchronisation capability in the publish tier. The > synchronisation mechanism relies on FileVault to export and import content. > Users stored in the repository under a path that starts with a _ and that > contain another _ can be exported but fail to be re-imported. For instance, > the user stored under the path /home/users/test/_6k_test-user-a won't be > imported. > Debugging this issue, it seems that FileVault treats the _6k_ pattern as a > namespace and thus skip the resource upon import because the paths don't > match. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (JCRVLT-751) ExportOptions.rootPath not properly unescaped during filter rule mapping
[ https://issues.apache.org/jira/browse/JCRVLT-751?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Konrad Windszus updated JCRVLT-751: --- Summary: ExportOptions.rootPath not properly unescaped during filter rule mapping (was: Can't import a user with parent folder that starts with _ and includes another _ ) > ExportOptions.rootPath not properly unescaped during filter rule mapping > > > Key: JCRVLT-751 > URL: https://issues.apache.org/jira/browse/JCRVLT-751 > Project: Jackrabbit FileVault > Issue Type: Bug > Components: vlt >Affects Versions: 3.7.2 >Reporter: Timothée Maret >Priority: Major > Labels: vault > > AEM has a user synchronisation capability in the publish tier. The > synchronisation mechanism relies on FileVault to export and import content. > Users stored in the repository under a path that starts with a _ and that > contain another _ can be exported but fail to be re-imported. For instance, > the user stored under the path /home/users/test/_6k_test-user-a won't be > imported. > Debugging this issue, it seems that FileVault treats the _6k_ pattern as a > namespace and thus skip the resource upon import because the paths don't > match. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MSKINS-245) Maven Site 4 will break code highlight of site generated by Markdown
[ https://issues.apache.org/jira/browse/MSKINS-245?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Konrad Windszus updated MSKINS-245: --- Component/s: Fluido Skin > Maven Site 4 will break code highlight of site generated by Markdown > > > Key: MSKINS-245 > URL: https://issues.apache.org/jira/browse/MSKINS-245 > Project: Maven Skins > Issue Type: Bug > Components: Fluido Skin >Reporter: Xavi Lee >Assignee: Konrad Windszus >Priority: Major > Attachments: maven-site-3.png, maven-site-4.png, test-v3.html, > test-v4.html > > > repro repo https://github.com/awxiaoxian2020/code-render-bug > master branch is Maven Site 3 with Fluido skin 1 > v4 branch is Maven Site 4 with Fluido skin 2. > Open their respective `target/site/test.html` files in local to see the > rendered result. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MSKINS-245) Maven Site 4 will break code highlight of site generated by Markdown
[ https://issues.apache.org/jira/browse/MSKINS-245?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Konrad Windszus updated MSKINS-245: --- Fix Version/s: fluido-2.0.0-M9 fluido-2.0.0 > Maven Site 4 will break code highlight of site generated by Markdown > > > Key: MSKINS-245 > URL: https://issues.apache.org/jira/browse/MSKINS-245 > Project: Maven Skins > Issue Type: Bug > Components: Fluido Skin >Reporter: Xavi Lee >Assignee: Konrad Windszus >Priority: Major > Fix For: fluido-2.0.0-M9, fluido-2.0.0 > > Attachments: maven-site-3.png, maven-site-4.png, test-v3.html, > test-v4.html > > > repro repo https://github.com/awxiaoxian2020/code-render-bug > master branch is Maven Site 3 with Fluido skin 1 > v4 branch is Maven Site 4 with Fluido skin 2. > Open their respective `target/site/test.html` files in local to see the > rendered result. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (JCRVLT-751) Can't import a user with parent folder that starts with _ and includes another _
[
https://issues.apache.org/jira/browse/JCRVLT-751?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17840140#comment-17840140
]
Konrad Windszus edited comment on JCRVLT-751 at 4/23/24 3:32 PM:
-
In my tests the node path
{code}
/home/users/test/_6k_test-user-a
{code} is exported as ZIP path
{code}
/home/users/test/__6k_test-user-a
{code}
(which is correct according to
https://jackrabbit.apache.org/filevault/vaultfs.html#filename-escaping) and
correctly unescaped to node path {{/home/users/test/_6k_test-user-a}} during
import.
was (Author: kwin):
In my tests the node path {{/home/users/test/_6k_test-user-a}} is exported as
ZIP path {{/home/users/test/__6k_test-user-a}} (which is correct according to
https://jackrabbit.apache.org/filevault/vaultfs.html#filename-escaping) and
correctly unescaped to node path {{/home/users/test/_6k_test-user-a}} during
import.
> Can't import a user with parent folder that starts with _ and includes
> another _
> -
>
> Key: JCRVLT-751
> URL: https://issues.apache.org/jira/browse/JCRVLT-751
> Project: Jackrabbit FileVault
> Issue Type: Bug
> Components: vlt
>Affects Versions: 3.7.2
>Reporter: Timothée Maret
>Priority: Major
> Labels: vault
>
> AEM has a user synchronisation capability in the publish tier. The
> synchronisation mechanism relies on FileVault to export and import content.
> Users stored in the repository under a path that starts with a _ and that
> contain another _ can be exported but fail to be re-imported. For instance,
> the user stored under the path /home/users/test/_6k_test-user-a won't be
> imported.
> Debugging this issue, it seems that FileVault treats the _6k_ pattern as a
> namespace and thus skip the resource upon import because the paths don't
> match.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (JCRVLT-751) Can't import a user with parent folder that starts with _ and includes another _
[ https://issues.apache.org/jira/browse/JCRVLT-751?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17840140#comment-17840140 ] Konrad Windszus commented on JCRVLT-751: In my tests the node path `/home/users/test/_6k_test-user-a` is exported as ZIP path `/home/users/test/__6k_test-user-a` (which is correct according to https://jackrabbit.apache.org/filevault/vaultfs.html#filename-escaping) and correctly unescaped to node path `/home/users/test/_6k_test-user-a` during import. > Can't import a user with parent folder that starts with _ and includes > another _ > - > > Key: JCRVLT-751 > URL: https://issues.apache.org/jira/browse/JCRVLT-751 > Project: Jackrabbit FileVault > Issue Type: Bug > Components: vlt >Affects Versions: 3.7.2 >Reporter: Timothée Maret >Priority: Major > Labels: vault > > AEM has a user synchronisation capability in the publish tier. The > synchronisation mechanism relies on FileVault to export and import content. > Users stored in the repository under a path that starts with a _ and that > contain another _ can be exported but fail to be re-imported. For instance, > the user stored under the path /home/users/test/_6k_test-user-a won't be > imported. > Debugging this issue, it seems that FileVault treats the _6k_ pattern as a > namespace and thus skip the resource upon import because the paths don't > match. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (JCRVLT-751) Can't import a user with parent folder that starts with _ and includes another _
[
https://issues.apache.org/jira/browse/JCRVLT-751?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17840140#comment-17840140
]
Konrad Windszus edited comment on JCRVLT-751 at 4/23/24 3:31 PM:
-
In my tests the node path {{/home/users/test/_6k_test-user-a}} is exported as
ZIP path {{/home/users/test/__6k_test-user-a}} (which is correct according to
https://jackrabbit.apache.org/filevault/vaultfs.html#filename-escaping) and
correctly unescaped to node path {{/home/users/test/_6k_test-user-a}} during
import.
was (Author: kwin):
In my tests the node path `/home/users/test/_6k_test-user-a` is exported as ZIP
path `/home/users/test/__6k_test-user-a` (which is correct according to
https://jackrabbit.apache.org/filevault/vaultfs.html#filename-escaping) and
correctly unescaped to node path `/home/users/test/_6k_test-user-a` during
import.
> Can't import a user with parent folder that starts with _ and includes
> another _
> -
>
> Key: JCRVLT-751
> URL: https://issues.apache.org/jira/browse/JCRVLT-751
> Project: Jackrabbit FileVault
> Issue Type: Bug
> Components: vlt
>Affects Versions: 3.7.2
>Reporter: Timothée Maret
>Priority: Major
> Labels: vault
>
> AEM has a user synchronisation capability in the publish tier. The
> synchronisation mechanism relies on FileVault to export and import content.
> Users stored in the repository under a path that starts with a _ and that
> contain another _ can be exported but fail to be re-imported. For instance,
> the user stored under the path /home/users/test/_6k_test-user-a won't be
> imported.
> Debugging this issue, it seems that FileVault treats the _6k_ pattern as a
> namespace and thus skip the resource upon import because the paths don't
> match.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (DOXIASITETOOLS-324) Allow configuration of parser per markup
[ https://issues.apache.org/jira/browse/DOXIASITETOOLS-324?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Konrad Windszus resolved DOXIASITETOOLS-324. Fix Version/s: 2.0.0 2.0.0-M18 Resolution: Fixed > Allow configuration of parser per markup > > > Key: DOXIASITETOOLS-324 > URL: https://issues.apache.org/jira/browse/DOXIASITETOOLS-324 > Project: Maven Doxia Sitetools > Issue Type: New Feature > Components: Site renderer >Reporter: Konrad Windszus >Assignee: Konrad Windszus >Priority: Major > Fix For: 2.0.0, 2.0.0-M18 > > > Currently the Doxia parsers being used for the Doxia markup sources have a > fix configuration > (https://github.com/apache/maven-doxia-sitetools/blob/dacaa552c1b8e89eed84db0f43b6b0a72be91d0c/doxia-site-renderer/src/main/java/org/apache/maven/doxia/siterenderer/DefaultSiteRenderer.java#L324). > It would be beneficial to allow to dynamically configure the parsers (based > on a matching markup source path pattern) -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MNG-7388) Support Java prerequisites for Maven plugins
[
https://issues.apache.org/jira/browse/MNG-7388?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17838247#comment-17838247
]
Konrad Windszus commented on MNG-7388:
--
[~jnord_cbs] Indeed, thanks for noticing.
> Support Java prerequisites for Maven plugins
>
>
> Key: MNG-7388
> URL: https://issues.apache.org/jira/browse/MNG-7388
> Project: Maven
> Issue Type: Improvement
>Reporter: Konrad Windszus
>Priority: Major
>
> Currently only the minimum Maven version can be explicitly required for a
> Maven plugin via {{prerequisites->maven}}. The same should be possible for
> the Java version, as Maven plugins compiled for Java 11 won't run on Java 8
> and currently only emit the nasty "UnsupportedClassVersion" errors.
> The plugin reporting plugin uses some heuristics in
> https://github.com/apache/maven-plugin-tools/blob/c6d0808b92423b969f8d2aac500b7263399d0373/maven-plugin-plugin/src/main/java/org/apache/maven/plugin/plugin/PluginReport.java#L739,
> but this is only considered for the plugin documentation but never at run
> time. This metadata should be evaluated similar to prerequisites.maven at
> https://github.com/apache/maven/blob/0080e845884922814d26914d0ae9f59b084bee35/maven-core/src/main/java/org/apache/maven/lifecycle/internal/MojoExecutor.java#L173
> This requires a Maven model change though, and therefore can only end up in
> Maven 5.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (MNG-7388) Support Java prerequisites for Maven plugins
[
https://issues.apache.org/jira/browse/MNG-7388?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konrad Windszus resolved MNG-7388.
--
Resolution: Duplicate
> Support Java prerequisites for Maven plugins
>
>
> Key: MNG-7388
> URL: https://issues.apache.org/jira/browse/MNG-7388
> Project: Maven
> Issue Type: Improvement
>Reporter: Konrad Windszus
>Priority: Major
>
> Currently only the minimum Maven version can be explicitly required for a
> Maven plugin via {{prerequisites->maven}}. The same should be possible for
> the Java version, as Maven plugins compiled for Java 11 won't run on Java 8
> and currently only emit the nasty "UnsupportedClassVersion" errors.
> The plugin reporting plugin uses some heuristics in
> https://github.com/apache/maven-plugin-tools/blob/c6d0808b92423b969f8d2aac500b7263399d0373/maven-plugin-plugin/src/main/java/org/apache/maven/plugin/plugin/PluginReport.java#L739,
> but this is only considered for the plugin documentation but never at run
> time. This metadata should be evaluated similar to prerequisites.maven at
> https://github.com/apache/maven/blob/0080e845884922814d26914d0ae9f59b084bee35/maven-core/src/main/java/org/apache/maven/lifecycle/internal/MojoExecutor.java#L173
> This requires a Maven model change though, and therefore can only end up in
> Maven 5.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MSITE-1006) MSITE-723 causes duplicate document rendering and log output
[
https://issues.apache.org/jira/browse/MSITE-1006?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17838109#comment-17838109
]
Konrad Windszus commented on MSITE-1006:
I would expect that those documents which are based on doxia source files
(editable) take precedence over same-named (generated) reports (not the other
way around). But there should be a WARNING emitted in case a report would emit
to a clashing path.
> MSITE-723 causes duplicate document rendering and log output
>
>
> Key: MSITE-1006
> URL: https://issues.apache.org/jira/browse/MSITE-1006
> Project: Maven Site Plugin
> Issue Type: Bug
> Components: doxia integration
>Affects Versions: 4.0.0-M13
>Reporter: Michael Osipov
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 4.0.0, 4.0.0-M14
>
>
> Consider the following output:
> {noformat}
> ...
> [INFO] --- maven-site-plugin:3.12.1:site (default-site) @ doxia-skin-model ---
> [INFO] configuring report plugin
> org.apache.maven.plugins:maven-project-info-reports-plugin:3.4.5
> [INFO] 15 reports configured for maven-project-info-reports-plugin:3.4.5:
> index, summary, dependency-info, modules, team, scm, issue-management,
> mailing-lists, dependency-management, dependencies, dependency-convergence,
> ci-management, plugin-management, plugins, distribution-management
> [INFO] Rendering site with default locale English (en)
> [INFO] Relativizing decoration links with respect to localized project URL:
> https://maven.apache.org/doxia/doxia-sitetools/doxia-skin-model/
> [INFO] Rendering content with
> org.apache.maven.skins:maven-fluido-skin:jar:1.11.2 skin.
> [INFO] Skipped "About" report
> (maven-project-info-reports-plugin:3.4.5:index), file "index.html" already
> exists.
> [INFO] Rendering 2 Doxia documents: 1 apt, 1 xdoc
> [INFO] Generating "Summary" report ---
> maven-project-info-reports-plugin:3.4.5:summary
> [INFO] Generating "Dependency Information" report ---
> maven-project-info-reports-plugin:3.4.5:dependency-info
> [INFO] Generating "Team" report ---
> maven-project-info-reports-plugin:3.4.5:team
> [INFO] Generating "Source Code Management" report ---
> maven-project-info-reports-plugin:3.4.5:scm
> [INFO] Generating "Issue Management" report ---
> maven-project-info-reports-plugin:3.4.5:issue-management
> [INFO] Generating "Mailing Lists" report---
> maven-project-info-reports-plugin:3.4.5:mailing-lists
> [INFO] Generating "Dependency Management" report ---
> maven-project-info-reports-plugin:3.4.5:dependency-management
> [INFO] Generating "Dependencies" report ---
> maven-project-info-reports-plugin:3.4.5:dependencies
> [INFO] Generating "Dependency Convergence" report ---
> maven-project-info-reports-plugin:3.4.5:dependency-convergence
> [INFO] Generating "CI Management" report---
> maven-project-info-reports-plugin:3.4.5:ci-management
> [INFO] Generating "Plugin Management" report---
> maven-project-info-reports-plugin:3.4.5:plugin-management
> [INFO] Generating "Plugins" report ---
> maven-project-info-reports-plugin:3.4.5:plugins
> [INFO] Generating "Distribution Management" report ---
> maven-project-info-reports-plugin:3.4.5:distribution-management
> [INFO] Rendering 1 generated Doxia document: 1 xdoc
> ...
> {noformat}
> Let's locate these two handwritten documents:
> {noformat}
> ~/var/Projekte/maven-doxia-sitetools (master =)
> $ tree doxia-skin-model/src/site/
> doxia-skin-model/src/site/
> ├── apt
> │ └── index.apt
> └── site.xml
> 2 directories, 2 files
> {noformat}
> There aren't. This is caused by MSITE-723 which add generated documents for
> the first round of rendering (non-editable ones), then does the rendering,
> does reports and then allows generated documents to overwrite report output
> by running generated rendering again.
> This is suboptimal since it causes:
> * Duplicate rendering
> * Deceiving log output
> * Maven Fluido Skin generates an "Edit Button" for such content sind the
> editable flag is set to true:
> view-source:https://maven.apache.org/doxia/doxia-sitetools-archives/doxia-sitetools-2.0.0-M16/doxia-skin-model/skin.html
> The solution to the problem is to flag the document renderer for such output
> with Sitetools to allow unconditional overwrite. We need to fix Doxia
> Sitetools first and then we can fix in this plugin.
> Block in question:
> https://github.com/apache/maven-site-plugin/blob/036997f9a70b7394d9a9771ede04a686aca834e1/src/main/java/org/apache/maven/plugins/site/render/SiteMojo.java#L123-L167
> This needs to be {{true}}:
> https://maven.apache.org/doxia/doxia-sitetools/doxia-site-renderer/xref/org/apache/maven/doxia/siterenderer/DoxiaDocumentRenderer.html#L61
--
This message
[jira] [Updated] (MNG-8097) Validate that each dependency->type is a type registered in an artifact handler
[
https://issues.apache.org/jira/browse/MNG-8097?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konrad Windszus updated MNG-8097:
-
Description:
Currently often the dependency's type is being set to the extension and the
resolution is lenient, i.e. if there is no artifact handler defining the value
given in {{dependency->type}} resolution transparently uses the type as
extension.
That can potentially lead to two issues:
1. Resolution might fail with surprising error messages like
{code}
Could not resolve dependencies for project : The following artifacts could
not be resolved: : Could not transfer artifact
::: from/to ...
{code}
This is an issue for all types not defined by Maven Core itself, e.g. for
https://jackrabbit.apache.org/filevault-package-maven-plugin/index.html which
registers an artifact handler for type {{content-package}} with extension
{{zip}}.
2. The information {{addedToClasspath}}, {{includesDependencies}} and
{{classifier}} from the artifact handler is not evaluated
was:
Currently often the dependency's type is being set to the extension and the
resolution is lenient, i.e. if there is no artifact handler defining the value
given in {{dependency->type}} resolution transparently uses the type as
extension.
That can potentially lead to two issues:
1. Resolution might fail with surprising error messages like
{code}
Could not resolve dependencies for project : The following artifacts could
not be resolved: : Could not transfer artifact
::: from/to ...
{code}
This is an issue for all types not defined by Maven Core itself, e.g. for
https://jackrabbit.apache.org/filevault-package-maven-plugin/index.html which
registers an artifact handler for type {{content-package}} with extension
{{zip}}.
2. The information {{addedToClasspath}} and {{includesDependencies}} from the
artifact handler is not evaluated
> Validate that each dependency->type is a type registered in an artifact
> handler
> ---
>
> Key: MNG-8097
> URL: https://issues.apache.org/jira/browse/MNG-8097
> Project: Maven
> Issue Type: New Feature
>Reporter: Konrad Windszus
>Priority: Major
>
> Currently often the dependency's type is being set to the extension and the
> resolution is lenient, i.e. if there is no artifact handler defining the
> value given in {{dependency->type}} resolution transparently uses the type as
> extension.
> That can potentially lead to two issues:
> 1. Resolution might fail with surprising error messages like
> {code}
> Could not resolve dependencies for project : The following artifacts
> could not be resolved: : Could not transfer artifact
> ::: from/to ...
> {code}
> This is an issue for all types not defined by Maven Core itself, e.g. for
> https://jackrabbit.apache.org/filevault-package-maven-plugin/index.html which
> registers an artifact handler for type {{content-package}} with extension
> {{zip}}.
> 2. The information {{addedToClasspath}}, {{includesDependencies}} and
> {{classifier}} from the artifact handler is not evaluated
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MNG-8097) Validate that each dependency->type is a type registered in an artifact handler
[
https://issues.apache.org/jira/browse/MNG-8097?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17837673#comment-17837673
]
Konrad Windszus commented on MNG-8097:
--
bq. But no, there is no "each dependency type is registered" type of thing, nor
it makes sense.
For me it would make a lot of sense to enforce this, because otherwise the
lenient handling of Maven being able to deal with both type and extension for
dependencies leads to a lot of confusion and confusing follow-up errors as
stated in the description.
> Validate that each dependency->type is a type registered in an artifact
> handler
> ---
>
> Key: MNG-8097
> URL: https://issues.apache.org/jira/browse/MNG-8097
> Project: Maven
> Issue Type: New Feature
>Reporter: Konrad Windszus
>Priority: Major
>
> Currently often the dependency's type is being set to the extension and the
> resolution is lenient, i.e. if there is no artifact handler defining the
> value given in {{dependency->type}} resolution transparently uses the type as
> extension.
> That can potentially lead to two issues:
> 1. Resolution might fail with surprising error messages like
> {code}
> Could not resolve dependencies for project : The following artifacts
> could not be resolved: : Could not transfer artifact
> ::: from/to ...
> {code}
> This is an issue for all types not defined by Maven Core itself, e.g. for
> https://jackrabbit.apache.org/filevault-package-maven-plugin/index.html which
> registers an artifact handler for type {{content-package}} with extension
> {{zip}}.
> 2. The information {{addedToClasspath}} and {{includesDependencies}} from the
> artifact handler is not evaluated
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (MNG-8097) Validate that each dependency->type is a type registered in an artifact handler
[
https://issues.apache.org/jira/browse/MNG-8097?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17837665#comment-17837665
]
Konrad Windszus edited comment on MNG-8097 at 4/16/24 10:56 AM:
bq. when consuming just declare the dependency type of "zip" and be done with
it.
No, as then the addedToClasspath, includesDependency and default classifier
settings from the artifact handler are not considered!
was (Author: kwin):
> when consuming just declare the dependency type of "zip" and be done with it.
No, as then the addedToClasspath, includesDependency and default classifier
settings from the artifact handler are not considered!
> Validate that each dependency->type is a type registered in an artifact
> handler
> ---
>
> Key: MNG-8097
> URL: https://issues.apache.org/jira/browse/MNG-8097
> Project: Maven
> Issue Type: New Feature
>Reporter: Konrad Windszus
>Priority: Major
>
> Currently often the dependency's type is being set to the extension and the
> resolution is lenient, i.e. if there is no artifact handler defining the
> value given in {{dependency->type}} resolution transparently uses the type as
> extension.
> That can potentially lead to two issues:
> 1. Resolution might fail with surprising error messages like
> {code}
> Could not resolve dependencies for project : The following artifacts
> could not be resolved: : Could not transfer artifact
> ::: from/to ...
> {code}
> This is an issue for all types not defined by Maven Core itself, e.g. for
> https://jackrabbit.apache.org/filevault-package-maven-plugin/index.html which
> registers an artifact handler for type {{content-package}} with extension
> {{zip}}.
> 2. The information {{addedToClasspath}} and {{includesDependencies}} from the
> artifact handler is not evaluated
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MNG-8097) Validate that each dependency->type is a type registered in an artifact handler
[
https://issues.apache.org/jira/browse/MNG-8097?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17837665#comment-17837665
]
Konrad Windszus commented on MNG-8097:
--
> when consuming just declare the dependency type of "zip" and be done with it.
No, as then the addedToClasspath, includesDependency and default classifier
settings from the artifact handler are not considered!
> Validate that each dependency->type is a type registered in an artifact
> handler
> ---
>
> Key: MNG-8097
> URL: https://issues.apache.org/jira/browse/MNG-8097
> Project: Maven
> Issue Type: New Feature
>Reporter: Konrad Windszus
>Priority: Major
>
> Currently often the dependency's type is being set to the extension and the
> resolution is lenient, i.e. if there is no artifact handler defining the
> value given in {{dependency->type}} resolution transparently uses the type as
> extension.
> That can potentially lead to two issues:
> 1. Resolution might fail with surprising error messages like
> {code}
> Could not resolve dependencies for project : The following artifacts
> could not be resolved: : Could not transfer artifact
> ::: from/to ...
> {code}
> This is an issue for all types not defined by Maven Core itself, e.g. for
> https://jackrabbit.apache.org/filevault-package-maven-plugin/index.html which
> registers an artifact handler for type {{content-package}} with extension
> {{zip}}.
> 2. The information {{addedToClasspath}} and {{includesDependencies}} from the
> artifact handler is not evaluated
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MNG-8097) Validate that each dependency->type is a type registered in an artifact handler
[
https://issues.apache.org/jira/browse/MNG-8097?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17837663#comment-17837663
]
Konrad Windszus commented on MNG-8097:
--
By validate I mean "warn with a message on unknown dependency types".
Which artifact handler has "zip" as extension? I would assume something like
this is provided by https://maven.apache.org/plugins/maven-assembly-plugin/...
> Validate that each dependency->type is a type registered in an artifact
> handler
> ---
>
> Key: MNG-8097
> URL: https://issues.apache.org/jira/browse/MNG-8097
> Project: Maven
> Issue Type: New Feature
>Reporter: Konrad Windszus
>Priority: Major
>
> Currently often the dependency's type is being set to the extension and the
> resolution is lenient, i.e. if there is no artifact handler defining the
> value given in {{dependency->type}} resolution transparently uses the type as
> extension.
> That can potentially lead to two issues:
> 1. Resolution might fail with surprising error messages like
> {code}
> Could not resolve dependencies for project : The following artifacts
> could not be resolved: : Could not transfer artifact
> ::: from/to ...
> {code}
> This is an issue for all types not defined by Maven Core itself, e.g. for
> https://jackrabbit.apache.org/filevault-package-maven-plugin/index.html which
> registers an artifact handler for type {{content-package}} with extension
> {{zip}}.
> 2. The information {{addedToClasspath}} and {{includesDependencies}} from the
> artifact handler is not evaluated
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (DOXIASITETOOLS-329) Expose lastModification date in addition to publishDate in Velocity Context
[ https://issues.apache.org/jira/browse/DOXIASITETOOLS-329?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17837181#comment-17837181 ] Konrad Windszus commented on DOXIASITETOOLS-329: The simple modification date does not work well with SCMs (as each clone/checkout has a different modification date). Rather one needs to leverage the common modification date coming from the SCM. This requires https://issues.apache.org/jira/browse/SCM-914 and leveraging that library to populate the context variable. As this calculation might lead to some overhead, there should be an explicit opt-in flag to populate the variable. > Expose lastModification date in addition to publishDate in Velocity Context > --- > > Key: DOXIASITETOOLS-329 > URL: https://issues.apache.org/jira/browse/DOXIASITETOOLS-329 > Project: Maven Doxia Sitetools > Issue Type: Improvement > Components: Site renderer >Reporter: Konrad Windszus >Assignee: Konrad Windszus >Priority: Major > > Currently only the published date (the same for the whole site) is available > in the Velocity context > (https://github.com/apache/maven-doxia-sitetools/blob/5fe4a4c5359e6a23b78f385e15f77767cadaee99/doxia-site-renderer/src/main/java/org/apache/maven/doxia/siterenderer/DefaultSiteRenderer.java#L495). > It would be useful to also populate the lastModification date of the doxia > source file (if available). > That way one could expose a more useful date for end-users (as the publish > date rarely is equal to the date when a page was last touched). Obviously for > Sinks/Documents not based on Doxia source files this is not available. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MNG-8097) Validate that each dependency->type is a type registered in an artifact handler
[
https://issues.apache.org/jira/browse/MNG-8097?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17837178#comment-17837178
]
Konrad Windszus commented on MNG-8097:
--
[~hboutemy] WDYT?
> Validate that each dependency->type is a type registered in an artifact
> handler
> ---
>
> Key: MNG-8097
> URL: https://issues.apache.org/jira/browse/MNG-8097
> Project: Maven
> Issue Type: New Feature
>Reporter: Konrad Windszus
>Priority: Major
>
> Currently often the dependency's type is being set to the extension and the
> resolution is lenient, i.e. if there is no artifact handler defining the
> value given in {{dependency->type}} resolution transparently uses the type as
> extension.
> That can potentially lead to two issues:
> 1. Resolution might fail with surprising error messages like
> {code}
> Could not resolve dependencies for project : The following artifacts
> could not be resolved: : Could not transfer artifact
> ::: from/to ...
> {code}
> This is an issue for all types not defined by Maven Core itself, e.g. for
> https://jackrabbit.apache.org/filevault-package-maven-plugin/index.html which
> registers an artifact handler for type {{content-package}} with extension
> {{zip}}.
> 2. The information {{addedToClasspath}} and {{includesDependencies}} from the
> artifact handler is not evaluated
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (MNG-8097) Validate that each dependency->type is a type registered in an artifact handler
Konrad Windszus created MNG-8097:
Summary: Validate that each dependency->type is a type registered
in an artifact handler
Key: MNG-8097
URL: https://issues.apache.org/jira/browse/MNG-8097
Project: Maven
Issue Type: New Feature
Reporter: Konrad Windszus
Currently often the dependency's type is being set to the extension and the
resolution is lenient, i.e. if there is no artifact handler defining the value
given in {{dependency->type}} resolution transparently uses the type as
extension.
That can potentially lead to two issues:
1. Resolution might fail with surprising error messages like
{code}
Could not resolve dependencies for project : The following artifacts could
not be resolved: : Could not transfer artifact
::: from/to ...
{code}
This is an issue for all types not defined by Maven Core itself, e.g. for
https://jackrabbit.apache.org/filevault-package-maven-plugin/index.html which
registers an artifact handler for type {{content-package}} with extension
{{zip}}.
2. The information {{addedToClasspath}} and {{includesDependencies}} from the
artifact handler is not evaluated
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (MENFORCER-502) ResolverUtil.resolveTransitiveDependencies() does not consider transitive dependencies
[
https://issues.apache.org/jira/browse/MENFORCER-502?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17835827#comment-17835827
]
Konrad Windszus edited comment on MENFORCER-502 at 4/10/24 5:09 PM:
Actually it works fine. I was wrongly assuming this does not work because the
affected dependency uses maven-shade-plugin which creates a dependency-reduced
POM (leaving no compile time dependencies in place).
was (Author: kwin):
Actually it works fine. I was wrongly assuming this does not work because the
affected modules uses maven-shade-plugin which creates a dependency-reduced POM
(leaving no compile time dependencies in place).
> ResolverUtil.resolveTransitiveDependencies() does not consider transitive
> dependencies
> ---
>
> Key: MENFORCER-502
> URL: https://issues.apache.org/jira/browse/MENFORCER-502
> Project: Maven Enforcer Plugin
> Issue Type: Bug
> Components: bannedDependencies
>Affects Versions: 3.4.1
>Reporter: Konrad Windszus
>Priority: Major
>
> Despite its name
> https://github.com/apache/maven-enforcer/blob/80ee78e5f7473dafc8ca8e68d8f2af7895290303/enforcer-rules/src/main/java/org/apache/maven/enforcer/rules/dependency/ResolverUtil.java#L113
> does no longer resolve transitive dependencies.
> Only the direct ones are resolved in the returned {{DependencyNode}}. I.e.
> the rootNode has direct children, but the children itself never have any
> children (despite the fact that there are transitive dependencies on that
> level).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (MENFORCER-502) ResolverUtil.resolveTransitiveDependencies() does not consider transitive dependencies
[
https://issues.apache.org/jira/browse/MENFORCER-502?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17835827#comment-17835827
]
Konrad Windszus edited comment on MENFORCER-502 at 4/10/24 5:09 PM:
Actually it works fine. I was wrongly assuming this does not work because the
affected dependency uses maven-shade-plugin which creates a dependency-reduced
POM (leaving no transitive compile time dependencies in place).
was (Author: kwin):
Actually it works fine. I was wrongly assuming this does not work because the
affected dependency uses maven-shade-plugin which creates a dependency-reduced
POM (leaving no compile time dependencies in place).
> ResolverUtil.resolveTransitiveDependencies() does not consider transitive
> dependencies
> ---
>
> Key: MENFORCER-502
> URL: https://issues.apache.org/jira/browse/MENFORCER-502
> Project: Maven Enforcer Plugin
> Issue Type: Bug
> Components: bannedDependencies
>Affects Versions: 3.4.1
>Reporter: Konrad Windszus
>Priority: Major
>
> Despite its name
> https://github.com/apache/maven-enforcer/blob/80ee78e5f7473dafc8ca8e68d8f2af7895290303/enforcer-rules/src/main/java/org/apache/maven/enforcer/rules/dependency/ResolverUtil.java#L113
> does no longer resolve transitive dependencies.
> Only the direct ones are resolved in the returned {{DependencyNode}}. I.e.
> the rootNode has direct children, but the children itself never have any
> children (despite the fact that there are transitive dependencies on that
> level).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (MENFORCER-502) ResolverUtil.resolveTransitiveDependencies() does not consider transitive dependencies
[
https://issues.apache.org/jira/browse/MENFORCER-502?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konrad Windszus resolved MENFORCER-502.
---
Resolution: Invalid
Actually it works fine. I was wrongly assuming this does not work because the
affected modules uses maven-shade-plugin which creates a dependency-reduced POM
(leaving no compile time dependencies in place).
> ResolverUtil.resolveTransitiveDependencies() does not consider transitive
> dependencies
> ---
>
> Key: MENFORCER-502
> URL: https://issues.apache.org/jira/browse/MENFORCER-502
> Project: Maven Enforcer Plugin
> Issue Type: Bug
> Components: bannedDependencies
>Affects Versions: 3.4.1
>Reporter: Konrad Windszus
>Priority: Major
>
> Despite its name
> https://github.com/apache/maven-enforcer/blob/80ee78e5f7473dafc8ca8e68d8f2af7895290303/enforcer-rules/src/main/java/org/apache/maven/enforcer/rules/dependency/ResolverUtil.java#L113
> does no longer resolve transitive dependencies.
> Only the direct ones are resolved in the returned {{DependencyNode}}. I.e.
> the rootNode has direct children, but the children itself never have any
> children (despite the fact that there are transitive dependencies on that
> level).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (MRESOLVER-526) Import Eclipse Aether wiki content to Maven Site
[
https://issues.apache.org/jira/browse/MRESOLVER-526?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konrad Windszus reassigned MRESOLVER-526:
-
Assignee: (was: Konrad Windszus)
> Import Eclipse Aether wiki content to Maven Site
>
>
> Key: MRESOLVER-526
> URL: https://issues.apache.org/jira/browse/MRESOLVER-526
> Project: Maven Resolver
> Issue Type: Task
>Reporter: Konrad Windszus
>Priority: Major
> Attachments: EclipseAetherWikiExportAsMD.zip,
> Eclipsepedia-20240410130147.xml
>
>
> As the Eclipse wiki is gonna be shutdown soon the content currently only
> available on https://wiki.eclipse.org/Aether (and other pages with category
> {{Aether}}) should be migrated to the resolver site.
> The steps for exporting and converting to Markdown are outlined at
> https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-Move-FAQ.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (MRESOLVER-526) Import Eclipse Aether wiki content to Maven Site
[
https://issues.apache.org/jira/browse/MRESOLVER-526?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17835726#comment-17835726
]
Konrad Windszus edited comment on MRESOLVER-526 at 4/10/24 1:16 PM:
I attached both the original Mediawiki export:
[^Eclipsepedia-20240410130147.xml] as well as the converted MD pages in
[^EclipseAetherWikiExportAsMD.zip] (created according to this manual:
[https://github.com/msohn/EclipseWikiCrawler/blob/main/README.md).|https://github.com/msohn/EclipseWikiCrawler/blob/main/README.md]
was (Author: kwin):
I attached both the original Mediawiki export:
[^Eclipsepedia-20240410130147.xml] as well as the
[^EclipseAetherWikiExportAsMD.zip] created according to this manual:
https://github.com/msohn/EclipseWikiCrawler/blob/main/README.md
> Import Eclipse Aether wiki content to Maven Site
>
>
> Key: MRESOLVER-526
> URL: https://issues.apache.org/jira/browse/MRESOLVER-526
> Project: Maven Resolver
> Issue Type: Task
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
> Attachments: EclipseAetherWikiExportAsMD.zip,
> Eclipsepedia-20240410130147.xml
>
>
> As the Eclipse wiki is gonna be shutdown soon the content currently only
> available on https://wiki.eclipse.org/Aether (and other pages with category
> {{Aether}}) should be migrated to the resolver site.
> The steps for exporting and converting to Markdown are outlined at
> https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-Move-FAQ.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MRESOLVER-526) Import Eclipse Aether wiki content to Maven Site
[
https://issues.apache.org/jira/browse/MRESOLVER-526?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17835726#comment-17835726
]
Konrad Windszus commented on MRESOLVER-526:
---
I attached both the original Mediawiki export:
[^Eclipsepedia-20240410130147.xml] as well as the
[^EclipseAetherWikiExportAsMD.zip] created according to this manual:
https://github.com/msohn/EclipseWikiCrawler/blob/main/README.md
> Import Eclipse Aether wiki content to Maven Site
>
>
> Key: MRESOLVER-526
> URL: https://issues.apache.org/jira/browse/MRESOLVER-526
> Project: Maven Resolver
> Issue Type: Task
>Reporter: Konrad Windszus
>Priority: Major
> Attachments: EclipseAetherWikiExportAsMD.zip,
> Eclipsepedia-20240410130147.xml
>
>
> As the Eclipse wiki is gonna be shutdown soon the content currently only
> available on https://wiki.eclipse.org/Aether (and other pages with category
> {{Aether}}) should be migrated to the resolver site.
> The steps for exporting and converting to Markdown are outlined at
> https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-Move-FAQ.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (MRESOLVER-526) Import Eclipse Aether wiki content to Maven Site
[
https://issues.apache.org/jira/browse/MRESOLVER-526?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konrad Windszus reassigned MRESOLVER-526:
-
Assignee: Konrad Windszus
> Import Eclipse Aether wiki content to Maven Site
>
>
> Key: MRESOLVER-526
> URL: https://issues.apache.org/jira/browse/MRESOLVER-526
> Project: Maven Resolver
> Issue Type: Task
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
> Attachments: EclipseAetherWikiExportAsMD.zip,
> Eclipsepedia-20240410130147.xml
>
>
> As the Eclipse wiki is gonna be shutdown soon the content currently only
> available on https://wiki.eclipse.org/Aether (and other pages with category
> {{Aether}}) should be migrated to the resolver site.
> The steps for exporting and converting to Markdown are outlined at
> https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-Move-FAQ.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MRESOLVER-526) Import Eclipse Aether wiki content to Maven Site
[
https://issues.apache.org/jira/browse/MRESOLVER-526?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konrad Windszus updated MRESOLVER-526:
--
Attachment: EclipseAetherWikiExportAsMD.zip
> Import Eclipse Aether wiki content to Maven Site
>
>
> Key: MRESOLVER-526
> URL: https://issues.apache.org/jira/browse/MRESOLVER-526
> Project: Maven Resolver
> Issue Type: Task
>Reporter: Konrad Windszus
>Priority: Major
> Attachments: EclipseAetherWikiExportAsMD.zip,
> Eclipsepedia-20240410130147.xml
>
>
> As the Eclipse wiki is gonna be shutdown soon the content currently only
> available on https://wiki.eclipse.org/Aether (and other pages with category
> {{Aether}}) should be migrated to the resolver site.
> The steps for exporting and converting to Markdown are outlined at
> https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-Move-FAQ.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (MRESOLVER-526) Import Eclipse Aether wiki content to Maven Site
Konrad Windszus created MRESOLVER-526:
-
Summary: Import Eclipse Aether wiki content to Maven Site
Key: MRESOLVER-526
URL: https://issues.apache.org/jira/browse/MRESOLVER-526
Project: Maven Resolver
Issue Type: Task
Reporter: Konrad Windszus
Attachments: Eclipsepedia-20240410130147.xml
As the Eclipse wiki is gonna be shutdown soon the content currently only
available on https://wiki.eclipse.org/Aether (and other pages with category
{{Aether}}) should be migrated to the resolver site.
The steps for exporting and converting to Markdown are outlined at
https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-Move-FAQ.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MRESOLVER-526) Import Eclipse Aether wiki content to Maven Site
[
https://issues.apache.org/jira/browse/MRESOLVER-526?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konrad Windszus updated MRESOLVER-526:
--
Attachment: Eclipsepedia-20240410130147.xml
> Import Eclipse Aether wiki content to Maven Site
>
>
> Key: MRESOLVER-526
> URL: https://issues.apache.org/jira/browse/MRESOLVER-526
> Project: Maven Resolver
> Issue Type: Task
>Reporter: Konrad Windszus
>Priority: Major
> Attachments: Eclipsepedia-20240410130147.xml
>
>
> As the Eclipse wiki is gonna be shutdown soon the content currently only
> available on https://wiki.eclipse.org/Aether (and other pages with category
> {{Aether}}) should be migrated to the resolver site.
> The steps for exporting and converting to Markdown are outlined at
> https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-Move-FAQ.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MENFORCER-502) ResolverUtil.resolveTransitiveDependencies() does not consider transitive dependencies
[
https://issues.apache.org/jira/browse/MENFORCER-502?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konrad Windszus updated MENFORCER-502:
--
Affects Version/s: 3.4.1
> ResolverUtil.resolveTransitiveDependencies() does not consider transitive
> dependencies
> ---
>
> Key: MENFORCER-502
> URL: https://issues.apache.org/jira/browse/MENFORCER-502
> Project: Maven Enforcer Plugin
> Issue Type: Bug
> Components: bannedDependencies
>Affects Versions: 3.4.1
>Reporter: Konrad Windszus
>Priority: Major
>
> Despite its name
> https://github.com/apache/maven-enforcer/blob/80ee78e5f7473dafc8ca8e68d8f2af7895290303/enforcer-rules/src/main/java/org/apache/maven/enforcer/rules/dependency/ResolverUtil.java#L113
> does no longer resolve transitive dependencies.
> Only the direct ones are resolved in the returned {{DependencyNode}}. I.e.
> the rootNode has direct children, but the children itself never have any
> children (despite the fact that there are transitive dependencies on that
> level).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MENFORCER-502) ResolverUtil.resolveTransitiveDependencies() does not consider transitive dependencies
[
https://issues.apache.org/jira/browse/MENFORCER-502?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17835658#comment-17835658
]
Konrad Windszus commented on MENFORCER-502:
---
[~cstamas] or [~sjaranowski] Any idea what is wrong here? Wrong usage of
Resolver API?
> ResolverUtil.resolveTransitiveDependencies() does not consider transitive
> dependencies
> ---
>
> Key: MENFORCER-502
> URL: https://issues.apache.org/jira/browse/MENFORCER-502
> Project: Maven Enforcer Plugin
> Issue Type: Bug
> Components: bannedDependencies
>Reporter: Konrad Windszus
>Priority: Major
>
> Despite its name
> https://github.com/apache/maven-enforcer/blob/80ee78e5f7473dafc8ca8e68d8f2af7895290303/enforcer-rules/src/main/java/org/apache/maven/enforcer/rules/dependency/ResolverUtil.java#L113
> does no longer resolve transitive dependencies.
> Only the direct ones are resolved in the returned {{DependencyNode}}. I.e.
> the rootNode has direct children, but the children itself never have any
> children (despite the fact that there are transitive dependencies on that
> level).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MENFORCER-502) ResolverUtil.resolveTransitiveDependencies() does not consider transitive dependencies
[
https://issues.apache.org/jira/browse/MENFORCER-502?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konrad Windszus updated MENFORCER-502:
--
Description:
Despite its name
https://github.com/apache/maven-enforcer/blob/80ee78e5f7473dafc8ca8e68d8f2af7895290303/enforcer-rules/src/main/java/org/apache/maven/enforcer/rules/dependency/ResolverUtil.java#L113
does no longer resolve transitive dependencies.
Only the direct ones are resolved in the returned {{DependencyNode}}. I.e. the
rootNode has direct children, but the children itself never have any children
(despite the fact that there are transitive dependencies on that level).
was:
Despite its name
https://github.com/apache/maven-enforcer/blob/80ee78e5f7473dafc8ca8e68d8f2af7895290303/enforcer-rules/src/main/java/org/apache/maven/enforcer/rules/dependency/ResolverUtil.java#L113
does no longer resolve transitive dependencies.
Only the direct ones are resolved in the returned {{DependencyNode}}. I.e. the
rootNode has direct children, but the children itself never have any children.
> ResolverUtil.resolveTransitiveDependencies() does not consider transitive
> dependencies
> ---
>
> Key: MENFORCER-502
> URL: https://issues.apache.org/jira/browse/MENFORCER-502
> Project: Maven Enforcer Plugin
> Issue Type: Bug
> Components: bannedDependencies
>Reporter: Konrad Windszus
>Priority: Major
>
> Despite its name
> https://github.com/apache/maven-enforcer/blob/80ee78e5f7473dafc8ca8e68d8f2af7895290303/enforcer-rules/src/main/java/org/apache/maven/enforcer/rules/dependency/ResolverUtil.java#L113
> does no longer resolve transitive dependencies.
> Only the direct ones are resolved in the returned {{DependencyNode}}. I.e.
> the rootNode has direct children, but the children itself never have any
> children (despite the fact that there are transitive dependencies on that
> level).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (MENFORCER-502) ResolverUtil.resolveTransitiveDependencies() does not consider transitive dependencies
Konrad Windszus created MENFORCER-502:
-
Summary: ResolverUtil.resolveTransitiveDependencies() does not
consider transitive dependencies
Key: MENFORCER-502
URL: https://issues.apache.org/jira/browse/MENFORCER-502
Project: Maven Enforcer Plugin
Issue Type: Bug
Components: bannedDependencies
Reporter: Konrad Windszus
Despite its name
https://github.com/apache/maven-enforcer/blob/80ee78e5f7473dafc8ca8e68d8f2af7895290303/enforcer-rules/src/main/java/org/apache/maven/enforcer/rules/dependency/ResolverUtil.java#L113
does no longer resolve transitive dependencies.
Only the direct ones are resolved in the returned {{DependencyNode}}. I.e. the
rootNode has direct children, but the children itself never have any children.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (SLING-10506) Document inappropriate Sonar rules
[
https://issues.apache.org/jira/browse/SLING-10506?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17835176#comment-17835176
]
Konrad Windszus commented on SLING-10506:
-
I would like to add https://rules.sonarsource.com/java/RSPEC-1948/ to the list
because AFAIK none of the OSGi runtimes ever serialize something to disk
(except if explicitly forced via API call). This particularly affects
HttpServletRequest derived classes...
[~olli] Any chance of following up on this?
> Document inappropriate Sonar rules
> --
>
> Key: SLING-10506
> URL: https://issues.apache.org/jira/browse/SLING-10506
> Project: Sling
> Issue Type: Task
> Components: Build and Source Control, CI
>Reporter: Oliver Lietz
>Assignee: Oliver Lietz
>Priority: Major
>
> * {{java:S100}} (https://rules.sonarsource.com/java/RSPEC-100)
> * {{java:S112}} (https://rules.sonarsource.com/java/RSPEC-112)
> * {{java:S1117}} (https://rules.sonarsource.com/java/RSPEC-1117)
> * {{java:S1149}} (https://rules.sonarsource.com/java/RSPEC-1149)
> * {{java:S1989}} (https://rules.sonarsource.com/java/RSPEC-1989)
> * {{java:S2226}} (https://rules.sonarsource.com/java/RSPEC-2226)
> * {{java:S3077}} (https://rules.sonarsource.com/java/RSPEC-3077)
> * {{java:S6212}} (https://rules.sonarsource.com/java/RSPEC-6212)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (SCM-914) InfoItem.lastChangedDate is leaky abstraction
[ https://issues.apache.org/jira/browse/SCM-914?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17834831#comment-17834831 ] Konrad Windszus commented on SCM-914: - Fixed in https://github.com/apache/maven-scm/commit/a297237e98b405ba4a323247137eaffcf8e20593. > InfoItem.lastChangedDate is leaky abstraction > - > > Key: SCM-914 > URL: https://issues.apache.org/jira/browse/SCM-914 > Project: Maven SCM > Issue Type: Bug > Components: maven-scm-api >Reporter: Tobias Gruetzmacher >Assignee: Konrad Windszus >Priority: Minor > Fix For: 2.1.0 > > > I was looking into implementing > [https://github.com/mojohaus/buildnumber-maven-plugin/pull/16] in a sane way, > but had to conclude that InfoItem.lastChangedDate is unfortunately just a > string and not a Data, so will leak the console output of different providers > to the user. > Does anybody see a sane way to fix this API and create a sane abstraction for > different SCMs? If yes, I would try to go ahead with the following tasks: > # Fix InfoItem, so that lastChangedDate is a Date > # Fix the current providers filling this field (svnexe and svnjava AFAICS - > aside: why is svnjava not part of the maven-scm repository?) > # Implement this feature for at least gitexe (and maybe jgit) so I can use > it for my usecase > Ideas, comments? -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (SCM-914) InfoItem.lastChangedDate is leaky abstraction
[ https://issues.apache.org/jira/browse/SCM-914?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Konrad Windszus resolved SCM-914. - Fix Version/s: 2.1.0 Resolution: Fixed > InfoItem.lastChangedDate is leaky abstraction > - > > Key: SCM-914 > URL: https://issues.apache.org/jira/browse/SCM-914 > Project: Maven SCM > Issue Type: Bug > Components: maven-scm-api >Reporter: Tobias Gruetzmacher >Assignee: Konrad Windszus >Priority: Minor > Fix For: 2.1.0 > > > I was looking into implementing > [https://github.com/mojohaus/buildnumber-maven-plugin/pull/16] in a sane way, > but had to conclude that InfoItem.lastChangedDate is unfortunately just a > string and not a Data, so will leak the console output of different providers > to the user. > Does anybody see a sane way to fix this API and create a sane abstraction for > different SCMs? If yes, I would try to go ahead with the following tasks: > # Fix InfoItem, so that lastChangedDate is a Date > # Fix the current providers filling this field (svnexe and svnjava AFAICS - > aside: why is svnjava not part of the maven-scm repository?) > # Implement this feature for at least gitexe (and maybe jgit) so I can use > it for my usecase > Ideas, comments? -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (JCRVLT-750) startup error around unclosed archives
[
https://issues.apache.org/jira/browse/JCRVLT-750?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17834337#comment-17834337
]
Konrad Windszus commented on JCRVLT-750:
[~ankitaagar] You referenced a patch file from a private JIRA instance. Please
rather attach the patch here.
> startup error around unclosed archives
> --
>
> Key: JCRVLT-750
> URL: https://issues.apache.org/jira/browse/JCRVLT-750
> Project: Jackrabbit FileVault
> Issue Type: Bug
> Components: vlt
>Affects Versions: 3.7.2
>Reporter: Ankita Agarwal
>Priority: Major
>
> {code:java}
> 11.03.2024 13:33:10.690 *ERROR* [OsgiInstallerImpl]
> org.apache.jackrabbit.vault.fs.io.AbstractArchive Detected unclosed archive.
> To figure out where it has been opened set the Java System property
> 'vault.enableStackTraces' to 'true'11.03.2024 13:33:10.690 *ERROR*
> [OsgiInstallerImpl] org.apache.jackrabbit.vault.fs.io.AbstractArchive
> Detected unclosed archive. To figure out where it has been opened set the
> Java System property 'vault.enableStackTraces' to 'true'11.03.2024
> 13:33:10.690 *ERROR* [OsgiInstallerImpl]
> org.apache.jackrabbit.vault.fs.io.AbstractArchive Detected unclosed archive.
> To figure out where it has been opened set the Java System property
> 'vault.enableStackTraces' to 'true'
> Full stacktrace of above unclosed archive is (it can be seen in logs using
> the switch {{{}-Dvault.enableStackTraces=true{}}}):
> {code}
> {code:xml}
> java.lang.Exception: Open Stack Trace
> at org.h2.util.CloseWatcher.register(CloseWatcher.java:85)
> at
> org.apache.jackrabbit.vault.fs.io.ZipArchive.open(ZipArchive.java:156)
> at
> org.apache.jackrabbit.vault.packaging.impl.ZipVaultPackage.getArchive(ZipVaultPackage.java:107)
> at
> org.apache.jackrabbit.vault.packaging.impl.ZipVaultPackage.getMetaInf(ZipVaultPackage.java:145)
> at
> org.apache.jackrabbit.vault.packaging.impl.ZipVaultPackage.getPropertiesMap(ZipVaultPackage.java:323)
> at
> org.apache.jackrabbit.vault.packaging.impl.PackagePropertiesImpl.getProperty(PackagePropertiesImpl.java:265)
> at
> org.apache.jackrabbit.vault.packaging.impl.PackagePropertiesImpl.getId(PackagePropertiesImpl.java:62)
> at
> org.apache.jackrabbit.vault.packaging.impl.JcrPackageDefinitionImpl.unwrap(JcrPackageDefinitionImpl.java:219)
> at
> org.apache.jackrabbit.vault.packaging.impl.JcrPackageImpl.tryUnwrap(JcrPackageImpl.java:258)
> at
> org.apache.jackrabbit.vault.packaging.impl.JcrPackageImpl.extract(JcrPackageImpl.java:414)
> at
> org.apache.jackrabbit.vault.packaging.impl.JcrPackageImpl.extract(JcrPackageImpl.java:356)
> at
> org.apache.jackrabbit.vault.packaging.impl.JcrPackageImpl.install(JcrPackageImpl.java:350)
> at
> com.adobe.granite.installer.factory.packages.impl.PackageTransformer$InstallPackageTask.execute(PackageTransformer.java:348)
> at
> org.apache.sling.installer.core.impl.OsgiInstallerImpl.doExecuteTasks(OsgiInstallerImpl.java:918)
> at
> org.apache.sling.installer.core.impl.OsgiInstallerImpl.executeTasks(OsgiInstallerImpl.java:755)
> at
> org.apache.sling.installer.core.impl.OsgiInstallerImpl.run(OsgiInstallerImpl.java:304)
> at java.base/java.lang.Thread.run(Thread.java:833)
> {code}
> It seems that, in case of sub packages, filevault opens the archive but only
> processes (and close) them in case of non-recursive import option is set to
> false [0]. Packages are deployed non-recursively in this case and filevault
> is not closing the archives when subpacks are not empty.
> This seems to be happening for the we-retail packages, as in case of
> we-retail the created archive is of type ZipArchive [1] (and we are adding a
> close watcher for it [3]), for other cases in which subpacks are there,
> archive is of type MemoryArchive [2]
> I believe this
> [filevault.patch{^}!https://jira.corp.adobe.com/images/icons/link_attachment_7.gif|width=7,height=7!{^}|https://jira.corp.adobe.com/secure/attachment/11792561/11792561_filevault.patch]
> should fix the problem,
> [0]:
> [https://github.com/apache/jackrabbit-filevault/blob/master/vault-core/src/main/java/org/apache/jackrabbit/vault/packaging/impl/JcrPackageImpl.java#L484]
> [1]:
> [https://github.com/apache/jackrabbit-filevault/blob/master/vault-core/src/main/java/org/apache/jackrabbit/vault/packaging/impl/JcrPackageImpl.java#L323-L333]
> [2]:
> [https://github.com/apache/jackrabbit-filevault/blob/master/vault-core/src/main/java/org/apache/jackrabbit/vault/packaging/impl/JcrPackageImpl.java#L306-L323]
> [3]:
> [https://github.com/apache/jackrabbit-filevault/blob/master/vault-core/src/main/java/org/apache/jackrabbit/vault/fs/io/ZipArchive.java#L156]
>
[jira] [Created] (MNG-8093) Support profile id alias(es)
Konrad Windszus created MNG-8093: Summary: Support profile id alias(es) Key: MNG-8093 URL: https://issues.apache.org/jira/browse/MNG-8093 Project: Maven Issue Type: Improvement Components: Profiles Reporter: Konrad Windszus Currently each profile may only have exactly one id which is used to enable/disable it on CLI (https://maven.apache.org/pom.html#Profiles). For certain edge cases it would be useful to define aliases (similar to https://maven.apache.org/ref/3.9.6/maven-plugin-api/plugin.html#parameter). So that multiple different ids can be used to activate the same profile. This requires a new POM schema version though. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (JCRVLT-749) IAE in generate-metadata during incremental builds
[
https://issues.apache.org/jira/browse/JCRVLT-749?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konrad Windszus updated JCRVLT-749:
---
Description:
The following error can be seen with goal {{generate-metadata}} when being
executed with m2e
{code}
Failed to execute mojo
org.apache.jackrabbit:filevault-package-maven-plugin:1.3.6:generate-metadata
{execution: default-generate-metadata}
(org.apache.jackrabbit:filevault-package-maven-plugin:1.3.6:generate-metadata:default-generate-metadata:generate-test-sources)
org.eclipse.core.runtime.CoreException: Failed to execute mojo
org.apache.jackrabbit:filevault-package-maven-plugin:1.3.6:generate-metadata
{execution: default-generate-metadata}
at
org.eclipse.m2e.core.internal.embedder.MavenExecutionContext.executeMojo(MavenExecutionContext.java:340)
at
org.eclipse.m2e.core.internal.embedder.MavenExecutionContext.lambda$0(MavenExecutionContext.java:291)
at
org.eclipse.m2e.core.internal.embedder.MavenExecutionContext.executeBare(MavenExecutionContext.java:394)
at
org.eclipse.m2e.core.internal.embedder.MavenExecutionContext.execute(MavenExecutionContext.java:275)
at
org.eclipse.m2e.core.internal.embedder.MavenExecutionContext.execute(MavenExecutionContext.java:290)
at
org.eclipse.m2e.core.project.configurator.MojoExecutionBuildParticipant.build(MojoExecutionBuildParticipant.java:57)
at
org.eclipse.m2e.core.internal.builder.MavenBuilderImpl.lambda$2(MavenBuilderImpl.java:153)
at java.base/java.util.LinkedHashMap.forEach(LinkedHashMap.java:986)
at
org.eclipse.m2e.core.internal.builder.MavenBuilderImpl.build(MavenBuilderImpl.java:133)
at
org.eclipse.m2e.core.internal.builder.MavenBuilder$1.method(MavenBuilder.java:164)
at
org.eclipse.m2e.core.internal.builder.MavenBuilder$1.method(MavenBuilder.java:1)
at
org.eclipse.m2e.core.internal.builder.MavenBuilder$BuildMethod.lambda$1(MavenBuilder.java:109)
at
org.eclipse.m2e.core.internal.embedder.MavenExecutionContext.executeBare(MavenExecutionContext.java:394)
at
org.eclipse.m2e.core.internal.embedder.MavenExecutionContext.execute(MavenExecutionContext.java:228)
at
org.eclipse.m2e.core.internal.builder.MavenBuilder$BuildMethod.lambda$0(MavenBuilder.java:100)
at
org.eclipse.m2e.core.internal.embedder.MavenExecutionContext.executeBare(MavenExecutionContext.java:394)
at
org.eclipse.m2e.core.internal.embedder.MavenExecutionContext.execute(MavenExecutionContext.java:275)
at
org.eclipse.m2e.core.internal.embedder.MavenExecutionContext.execute(MavenExecutionContext.java:214)
at
org.eclipse.m2e.core.internal.builder.MavenBuilder$BuildMethod.execute(MavenBuilder.java:83)
at
org.eclipse.m2e.core.internal.builder.MavenBuilder.build(MavenBuilder.java:192)
at
org.eclipse.core.internal.events.BuildManager$2.run(BuildManager.java:1079)
at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:45)
at
org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:296)
at
org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:352)
at
org.eclipse.core.internal.events.BuildManager$1.run(BuildManager.java:441)
at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:45)
at
org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:444)
at
org.eclipse.core.internal.events.BuildManager.basicBuildLoop(BuildManager.java:555)
at
org.eclipse.core.internal.events.BuildManager.basicBuildLoop(BuildManager.java:503)
at
org.eclipse.core.internal.events.BuildManager.build(BuildManager.java:585)
at
org.eclipse.core.internal.events.AutoBuildJob.doBuild(AutoBuildJob.java:207)
at
org.eclipse.core.internal.events.AutoBuildJob.run(AutoBuildJob.java:300)
at org.eclipse.core.internal.jobs.Worker.run(Worker.java:63)
Caused by: org.apache.maven.plugin.PluginExecutionException: Execution
default-generate-metadata of goal
org.apache.jackrabbit:filevault-package-maven-plugin:1.3.6:generate-metadata
failed: Could not figure out version part in filename 'pom.xml'. For this
artifact you cannot use 'isAllVersionsFilter=true'
at
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:133)
at
org.eclipse.m2e.core.internal.embedder.MavenExecutionContext.executeMojo(MavenExecutionContext.java:338)
... 32 more
Caused by: java.lang.IllegalArgumentException: Could not figure out version
part in filename 'pom.xml'. For this artifact you cannot use
'isAllVersionsFilter=true'
at
org.apache.jackrabbit.filevault.maven.packaging.mojo.GenerateMetadataMojo.getPathFilterSetForEmbeddedFile(GenerateMetadataMojo.java:1234)
at
[jira] [Comment Edited] (JCRVLT-749) IAE in generate-metadata during incremental builds
[
https://issues.apache.org/jira/browse/JCRVLT-749?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17834037#comment-17834037
]
Konrad Windszus edited comment on JCRVLT-749 at 4/4/24 9:06 PM:
This is an issue with m2e which returns sometimes
* the path to the pom.xml for dependencies (type != pom) which are Eclipse
projects and sometimes
* the path to the classes folder for dependencies which are Eclipse projects
Not sure yet under which circumstances what is returned.
was (Author: kwin):
This is an issue with m2e which returns sometimes
* The path to the pom.xml for dependencies which are Eclipse projects and
sometimes
* The path to the classes folder for dependencies which are Eclipse projects
Not sure yet under which circumstances what is returned.
> IAE in generate-metadata during incremental builds
> --
>
> Key: JCRVLT-749
> URL: https://issues.apache.org/jira/browse/JCRVLT-749
> Project: Jackrabbit FileVault
> Issue Type: Improvement
>Affects Versions: package-maven-plugin-1.3.6
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
>
> The following error can be seen with goal {{generate-metadata}} when being
> executed with m2e
> {code}
> Failed to execute mojo
> org.apache.jackrabbit:filevault-package-maven-plugin:1.3.6:generate-metadata
> {execution: default-generate-metadata}
> (org.apache.jackrabbit:filevault-package-maven-plugin:1.3.6:generate-metadata:default-generate-metadata:generate-test-sources)
> org.eclipse.core.runtime.CoreException: Failed to execute mojo
> org.apache.jackrabbit:filevault-package-maven-plugin:1.3.6:generate-metadata
> {execution: default-generate-metadata}
> at
> org.eclipse.m2e.core.internal.embedder.MavenExecutionContext.executeMojo(MavenExecutionContext.java:340)
> at
> org.eclipse.m2e.core.internal.embedder.MavenExecutionContext.lambda$0(MavenExecutionContext.java:291)
> at
> org.eclipse.m2e.core.internal.embedder.MavenExecutionContext.executeBare(MavenExecutionContext.java:394)
> at
> org.eclipse.m2e.core.internal.embedder.MavenExecutionContext.execute(MavenExecutionContext.java:275)
> at
> org.eclipse.m2e.core.internal.embedder.MavenExecutionContext.execute(MavenExecutionContext.java:290)
> at
> org.eclipse.m2e.core.project.configurator.MojoExecutionBuildParticipant.build(MojoExecutionBuildParticipant.java:57)
> at
> org.eclipse.m2e.core.internal.builder.MavenBuilderImpl.lambda$2(MavenBuilderImpl.java:153)
> at java.base/java.util.LinkedHashMap.forEach(LinkedHashMap.java:986)
> at
> org.eclipse.m2e.core.internal.builder.MavenBuilderImpl.build(MavenBuilderImpl.java:133)
> at
> org.eclipse.m2e.core.internal.builder.MavenBuilder$1.method(MavenBuilder.java:164)
> at
> org.eclipse.m2e.core.internal.builder.MavenBuilder$1.method(MavenBuilder.java:1)
> at
> org.eclipse.m2e.core.internal.builder.MavenBuilder$BuildMethod.lambda$1(MavenBuilder.java:109)
> at
> org.eclipse.m2e.core.internal.embedder.MavenExecutionContext.executeBare(MavenExecutionContext.java:394)
> at
> org.eclipse.m2e.core.internal.embedder.MavenExecutionContext.execute(MavenExecutionContext.java:228)
> at
> org.eclipse.m2e.core.internal.builder.MavenBuilder$BuildMethod.lambda$0(MavenBuilder.java:100)
> at
> org.eclipse.m2e.core.internal.embedder.MavenExecutionContext.executeBare(MavenExecutionContext.java:394)
> at
> org.eclipse.m2e.core.internal.embedder.MavenExecutionContext.execute(MavenExecutionContext.java:275)
> at
> org.eclipse.m2e.core.internal.embedder.MavenExecutionContext.execute(MavenExecutionContext.java:214)
> at
> org.eclipse.m2e.core.internal.builder.MavenBuilder$BuildMethod.execute(MavenBuilder.java:83)
> at
> org.eclipse.m2e.core.internal.builder.MavenBuilder.build(MavenBuilder.java:192)
> at
> org.eclipse.core.internal.events.BuildManager$2.run(BuildManager.java:1079)
> at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:45)
> at
> org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:296)
> at
> org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:352)
> at
> org.eclipse.core.internal.events.BuildManager$1.run(BuildManager.java:441)
> at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:45)
> at
> org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:444)
> at
> org.eclipse.core.internal.events.BuildManager.basicBuildLoop(BuildManager.java:555)
> at
> org.eclipse.core.internal.events.BuildManager.basicBuildLoop(BuildManager.java:503)
> at
> org.eclipse.core.internal.events.BuildManager.build(BuildManager.java:585)
> at
>
[jira] [Resolved] (MENFORCER-500) New rule: Maven coordinates must match pattern
[
https://issues.apache.org/jira/browse/MENFORCER-500?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konrad Windszus resolved MENFORCER-500.
---
Fix Version/s: next-release
Resolution: Fixed
Fixed in
https://github.com/apache/maven-enforcer/commit/80ee78e5f7473dafc8ca8e68d8f2af7895290303.
> New rule: Maven coordinates must match pattern
> --
>
> Key: MENFORCER-500
> URL: https://issues.apache.org/jira/browse/MENFORCER-500
> Project: Maven Enforcer Plugin
> Issue Type: Improvement
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
> Fix For: next-release
>
>
> Sometimes it is crucial that the {{groupId}} and/or the {{artifactId}} match
> a certain pattern (e.g. because it is reserved namespace prefix for deploying
> to Maven Central). It would be beneficial to enforce that with a standard
> rule.
> The pattern should be a configurable regex pattern (independently for
> {{artifactId}} and {{groupId}})
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (JCRVLT-749) IAE in generate-metadata during incremental builds
[
https://issues.apache.org/jira/browse/JCRVLT-749?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17834037#comment-17834037
]
Konrad Windszus commented on JCRVLT-749:
This is an issue with m2e which returns sometimes
* The path to the pom.xml for dependencies which are Eclipse projects and
sometimes
* The path to the classes folder for dependencies which are Eclipse projects
Not sure yet under which circumstances what is returned.
> IAE in generate-metadata during incremental builds
> --
>
> Key: JCRVLT-749
> URL: https://issues.apache.org/jira/browse/JCRVLT-749
> Project: Jackrabbit FileVault
> Issue Type: Improvement
>Affects Versions: package-maven-plugin-1.3.6
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
>
> The following error can be seen with goal {{generate-metadata}} when being
> executed with m2e
> {code}
> Failed to execute mojo
> org.apache.jackrabbit:filevault-package-maven-plugin:1.3.6:generate-metadata
> {execution: default-generate-metadata}
> (org.apache.jackrabbit:filevault-package-maven-plugin:1.3.6:generate-metadata:default-generate-metadata:generate-test-sources)
> org.eclipse.core.runtime.CoreException: Failed to execute mojo
> org.apache.jackrabbit:filevault-package-maven-plugin:1.3.6:generate-metadata
> {execution: default-generate-metadata}
> at
> org.eclipse.m2e.core.internal.embedder.MavenExecutionContext.executeMojo(MavenExecutionContext.java:340)
> at
> org.eclipse.m2e.core.internal.embedder.MavenExecutionContext.lambda$0(MavenExecutionContext.java:291)
> at
> org.eclipse.m2e.core.internal.embedder.MavenExecutionContext.executeBare(MavenExecutionContext.java:394)
> at
> org.eclipse.m2e.core.internal.embedder.MavenExecutionContext.execute(MavenExecutionContext.java:275)
> at
> org.eclipse.m2e.core.internal.embedder.MavenExecutionContext.execute(MavenExecutionContext.java:290)
> at
> org.eclipse.m2e.core.project.configurator.MojoExecutionBuildParticipant.build(MojoExecutionBuildParticipant.java:57)
> at
> org.eclipse.m2e.core.internal.builder.MavenBuilderImpl.lambda$2(MavenBuilderImpl.java:153)
> at java.base/java.util.LinkedHashMap.forEach(LinkedHashMap.java:986)
> at
> org.eclipse.m2e.core.internal.builder.MavenBuilderImpl.build(MavenBuilderImpl.java:133)
> at
> org.eclipse.m2e.core.internal.builder.MavenBuilder$1.method(MavenBuilder.java:164)
> at
> org.eclipse.m2e.core.internal.builder.MavenBuilder$1.method(MavenBuilder.java:1)
> at
> org.eclipse.m2e.core.internal.builder.MavenBuilder$BuildMethod.lambda$1(MavenBuilder.java:109)
> at
> org.eclipse.m2e.core.internal.embedder.MavenExecutionContext.executeBare(MavenExecutionContext.java:394)
> at
> org.eclipse.m2e.core.internal.embedder.MavenExecutionContext.execute(MavenExecutionContext.java:228)
> at
> org.eclipse.m2e.core.internal.builder.MavenBuilder$BuildMethod.lambda$0(MavenBuilder.java:100)
> at
> org.eclipse.m2e.core.internal.embedder.MavenExecutionContext.executeBare(MavenExecutionContext.java:394)
> at
> org.eclipse.m2e.core.internal.embedder.MavenExecutionContext.execute(MavenExecutionContext.java:275)
> at
> org.eclipse.m2e.core.internal.embedder.MavenExecutionContext.execute(MavenExecutionContext.java:214)
> at
> org.eclipse.m2e.core.internal.builder.MavenBuilder$BuildMethod.execute(MavenBuilder.java:83)
> at
> org.eclipse.m2e.core.internal.builder.MavenBuilder.build(MavenBuilder.java:192)
> at
> org.eclipse.core.internal.events.BuildManager$2.run(BuildManager.java:1079)
> at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:45)
> at
> org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:296)
> at
> org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:352)
> at
> org.eclipse.core.internal.events.BuildManager$1.run(BuildManager.java:441)
> at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:45)
> at
> org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:444)
> at
> org.eclipse.core.internal.events.BuildManager.basicBuildLoop(BuildManager.java:555)
> at
> org.eclipse.core.internal.events.BuildManager.basicBuildLoop(BuildManager.java:503)
> at
> org.eclipse.core.internal.events.BuildManager.build(BuildManager.java:585)
> at
> org.eclipse.core.internal.events.AutoBuildJob.doBuild(AutoBuildJob.java:207)
> at
> org.eclipse.core.internal.events.AutoBuildJob.run(AutoBuildJob.java:300)
> at org.eclipse.core.internal.jobs.Worker.run(Worker.java:63)
> Caused by: org.apache.maven.plugin.PluginExecutionException: Execution
> default-generate-metadata of goal
>
[jira] [Updated] (JCRVLT-749) IAE in generate-metadata during incremental builds
[
https://issues.apache.org/jira/browse/JCRVLT-749?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konrad Windszus updated JCRVLT-749:
---
Description:
The following error can be seen with goal {{generate-metadata}} when being
executed with m2e
{code}
Failed to execute mojo
org.apache.jackrabbit:filevault-package-maven-plugin:1.3.6:generate-metadata
{execution: default-generate-metadata}
(org.apache.jackrabbit:filevault-package-maven-plugin:1.3.6:generate-metadata:default-generate-metadata:generate-test-sources)
org.eclipse.core.runtime.CoreException: Failed to execute mojo
org.apache.jackrabbit:filevault-package-maven-plugin:1.3.6:generate-metadata
{execution: default-generate-metadata}
at
org.eclipse.m2e.core.internal.embedder.MavenExecutionContext.executeMojo(MavenExecutionContext.java:340)
at
org.eclipse.m2e.core.internal.embedder.MavenExecutionContext.lambda$0(MavenExecutionContext.java:291)
at
org.eclipse.m2e.core.internal.embedder.MavenExecutionContext.executeBare(MavenExecutionContext.java:394)
at
org.eclipse.m2e.core.internal.embedder.MavenExecutionContext.execute(MavenExecutionContext.java:275)
at
org.eclipse.m2e.core.internal.embedder.MavenExecutionContext.execute(MavenExecutionContext.java:290)
at
org.eclipse.m2e.core.project.configurator.MojoExecutionBuildParticipant.build(MojoExecutionBuildParticipant.java:57)
at
org.eclipse.m2e.core.internal.builder.MavenBuilderImpl.lambda$2(MavenBuilderImpl.java:153)
at java.base/java.util.LinkedHashMap.forEach(LinkedHashMap.java:986)
at
org.eclipse.m2e.core.internal.builder.MavenBuilderImpl.build(MavenBuilderImpl.java:133)
at
org.eclipse.m2e.core.internal.builder.MavenBuilder$1.method(MavenBuilder.java:164)
at
org.eclipse.m2e.core.internal.builder.MavenBuilder$1.method(MavenBuilder.java:1)
at
org.eclipse.m2e.core.internal.builder.MavenBuilder$BuildMethod.lambda$1(MavenBuilder.java:109)
at
org.eclipse.m2e.core.internal.embedder.MavenExecutionContext.executeBare(MavenExecutionContext.java:394)
at
org.eclipse.m2e.core.internal.embedder.MavenExecutionContext.execute(MavenExecutionContext.java:228)
at
org.eclipse.m2e.core.internal.builder.MavenBuilder$BuildMethod.lambda$0(MavenBuilder.java:100)
at
org.eclipse.m2e.core.internal.embedder.MavenExecutionContext.executeBare(MavenExecutionContext.java:394)
at
org.eclipse.m2e.core.internal.embedder.MavenExecutionContext.execute(MavenExecutionContext.java:275)
at
org.eclipse.m2e.core.internal.embedder.MavenExecutionContext.execute(MavenExecutionContext.java:214)
at
org.eclipse.m2e.core.internal.builder.MavenBuilder$BuildMethod.execute(MavenBuilder.java:83)
at
org.eclipse.m2e.core.internal.builder.MavenBuilder.build(MavenBuilder.java:192)
at
org.eclipse.core.internal.events.BuildManager$2.run(BuildManager.java:1079)
at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:45)
at
org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:296)
at
org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:352)
at
org.eclipse.core.internal.events.BuildManager$1.run(BuildManager.java:441)
at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:45)
at
org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:444)
at
org.eclipse.core.internal.events.BuildManager.basicBuildLoop(BuildManager.java:555)
at
org.eclipse.core.internal.events.BuildManager.basicBuildLoop(BuildManager.java:503)
at
org.eclipse.core.internal.events.BuildManager.build(BuildManager.java:585)
at
org.eclipse.core.internal.events.AutoBuildJob.doBuild(AutoBuildJob.java:207)
at
org.eclipse.core.internal.events.AutoBuildJob.run(AutoBuildJob.java:300)
at org.eclipse.core.internal.jobs.Worker.run(Worker.java:63)
Caused by: org.apache.maven.plugin.PluginExecutionException: Execution
default-generate-metadata of goal
org.apache.jackrabbit:filevault-package-maven-plugin:1.3.6:generate-metadata
failed: Could not figure out version part in filename 'pom.xml'. For this
artifact you cannot use 'isAllVersionsFilter=true'
at
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:133)
at
org.eclipse.m2e.core.internal.embedder.MavenExecutionContext.executeMojo(MavenExecutionContext.java:338)
... 32 more
Caused by: java.lang.IllegalArgumentException: Could not figure out version
part in filename 'pom.xml'. For this artifact you cannot use
'isAllVersionsFilter=true'
at
org.apache.jackrabbit.filevault.maven.packaging.mojo.GenerateMetadataMojo.getPathFilterSetForEmbeddedFile(GenerateMetadataMojo.java:1234)
at
[jira] [Created] (JCRVLT-749) IAE in generate-metadata during incremental builds
Konrad Windszus created JCRVLT-749:
--
Summary: IAE in generate-metadata during incremental builds
Key: JCRVLT-749
URL: https://issues.apache.org/jira/browse/JCRVLT-749
Project: Jackrabbit FileVault
Issue Type: Improvement
Affects Versions: package-maven-plugin-1.3.6
Reporter: Konrad Windszus
Assignee: Konrad Windszus
The following error can be seen with goal {{generate-metadata}} when being
executed with m2e
{code}
Failed to execute mojo
org.apache.jackrabbit:filevault-package-maven-plugin:1.3.6:generate-metadata
{execution: default-generate-metadata}
(org.apache.jackrabbit:filevault-package-maven-plugin:1.3.6:generate-metadata:default-generate-metadata:generate-test-sources)
org.eclipse.core.runtime.CoreException: Failed to execute mojo
org.apache.jackrabbit:filevault-package-maven-plugin:1.3.6:generate-metadata
{execution: default-generate-metadata}
at
org.eclipse.m2e.core.internal.embedder.MavenExecutionContext.executeMojo(MavenExecutionContext.java:340)
at
org.eclipse.m2e.core.internal.embedder.MavenExecutionContext.lambda$0(MavenExecutionContext.java:291)
at
org.eclipse.m2e.core.internal.embedder.MavenExecutionContext.executeBare(MavenExecutionContext.java:394)
at
org.eclipse.m2e.core.internal.embedder.MavenExecutionContext.execute(MavenExecutionContext.java:275)
at
org.eclipse.m2e.core.internal.embedder.MavenExecutionContext.execute(MavenExecutionContext.java:290)
at
org.eclipse.m2e.core.project.configurator.MojoExecutionBuildParticipant.build(MojoExecutionBuildParticipant.java:57)
at
org.eclipse.m2e.core.internal.builder.MavenBuilderImpl.lambda$2(MavenBuilderImpl.java:153)
at java.base/java.util.LinkedHashMap.forEach(LinkedHashMap.java:986)
at
org.eclipse.m2e.core.internal.builder.MavenBuilderImpl.build(MavenBuilderImpl.java:133)
at
org.eclipse.m2e.core.internal.builder.MavenBuilder$1.method(MavenBuilder.java:164)
at
org.eclipse.m2e.core.internal.builder.MavenBuilder$1.method(MavenBuilder.java:1)
at
org.eclipse.m2e.core.internal.builder.MavenBuilder$BuildMethod.lambda$1(MavenBuilder.java:109)
at
org.eclipse.m2e.core.internal.embedder.MavenExecutionContext.executeBare(MavenExecutionContext.java:394)
at
org.eclipse.m2e.core.internal.embedder.MavenExecutionContext.execute(MavenExecutionContext.java:228)
at
org.eclipse.m2e.core.internal.builder.MavenBuilder$BuildMethod.lambda$0(MavenBuilder.java:100)
at
org.eclipse.m2e.core.internal.embedder.MavenExecutionContext.executeBare(MavenExecutionContext.java:394)
at
org.eclipse.m2e.core.internal.embedder.MavenExecutionContext.execute(MavenExecutionContext.java:275)
at
org.eclipse.m2e.core.internal.embedder.MavenExecutionContext.execute(MavenExecutionContext.java:214)
at
org.eclipse.m2e.core.internal.builder.MavenBuilder$BuildMethod.execute(MavenBuilder.java:83)
at
org.eclipse.m2e.core.internal.builder.MavenBuilder.build(MavenBuilder.java:192)
at
org.eclipse.core.internal.events.BuildManager$2.run(BuildManager.java:1079)
at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:45)
at
org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:296)
at
org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:352)
at
org.eclipse.core.internal.events.BuildManager$1.run(BuildManager.java:441)
at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:45)
at
org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:444)
at
org.eclipse.core.internal.events.BuildManager.basicBuildLoop(BuildManager.java:555)
at
org.eclipse.core.internal.events.BuildManager.basicBuildLoop(BuildManager.java:503)
at
org.eclipse.core.internal.events.BuildManager.build(BuildManager.java:585)
at
org.eclipse.core.internal.events.AutoBuildJob.doBuild(AutoBuildJob.java:207)
at
org.eclipse.core.internal.events.AutoBuildJob.run(AutoBuildJob.java:300)
at org.eclipse.core.internal.jobs.Worker.run(Worker.java:63)
Caused by: org.apache.maven.plugin.PluginExecutionException: Execution
default-generate-metadata of goal
org.apache.jackrabbit:filevault-package-maven-plugin:1.3.6:generate-metadata
failed: Could not figure out version part in filename 'pom.xml'. For this
artifact you cannot use 'isAllVersionsFilter=true'
at
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:133)
at
org.eclipse.m2e.core.internal.embedder.MavenExecutionContext.executeMojo(MavenExecutionContext.java:338)
... 32 more
Caused by: java.lang.IllegalArgumentException: Could not figure out version
part in filename 'pom.xml'. For this artifact you cannot use
[jira] [Assigned] (DOXIASITETOOLS-334) Pass project relative source path to Parser.parse(...) as reference argument
[ https://issues.apache.org/jira/browse/DOXIASITETOOLS-334?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Konrad Windszus reassigned DOXIASITETOOLS-334: -- Assignee: Konrad Windszus > Pass project relative source path to Parser.parse(...) as reference argument > > > Key: DOXIASITETOOLS-334 > URL: https://issues.apache.org/jira/browse/DOXIASITETOOLS-334 > Project: Maven Doxia Sitetools > Issue Type: Improvement > Components: Site renderer >Reporter: Konrad Windszus >Assignee: Konrad Windszus >Priority: Major > Fix For: 2.0.0-M18 > > > Currently only the file name (without its path) is passed in > https://github.com/apache/maven-doxia-sitetools/blob/96e245055fa90689ab5464a39b2bea5d4477cedf/doxia-site-renderer/src/main/java/org/apache/maven/doxia/siterenderer/DefaultSiteRenderer.java#L369. > In order to ease identifying the file the relative path should be passed. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (DOXIASITETOOLS-334) Pass project relative source path to Parser.parse(...) as reference argument
[ https://issues.apache.org/jira/browse/DOXIASITETOOLS-334?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Konrad Windszus resolved DOXIASITETOOLS-334. Resolution: Fixed Fixed in https://github.com/apache/maven-doxia-sitetools/commit/79086a0a3f4b256ff053bb771aefaa6387d2d7cb. > Pass project relative source path to Parser.parse(...) as reference argument > > > Key: DOXIASITETOOLS-334 > URL: https://issues.apache.org/jira/browse/DOXIASITETOOLS-334 > Project: Maven Doxia Sitetools > Issue Type: Improvement > Components: Site renderer >Reporter: Konrad Windszus >Priority: Major > Fix For: 2.0.0-M18 > > > Currently only the file name (without its path) is passed in > https://github.com/apache/maven-doxia-sitetools/blob/96e245055fa90689ab5464a39b2bea5d4477cedf/doxia-site-renderer/src/main/java/org/apache/maven/doxia/siterenderer/DefaultSiteRenderer.java#L369. > In order to ease identifying the file the relative path should be passed. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (LANG-1718) FastDateFormat.getTimeInstance(FastDateFormat.SHORT, Locale.US) uses incorrect separator on JDK21
[
https://issues.apache.org/jira/browse/LANG-1718?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17833419#comment-17833419
]
Konrad Windszus commented on LANG-1718:
---
Only Java 23 will provide a backwards compatible solution via
{{{}parseLenient{}}}: https://inside.java/2024/03/29/quality-heads-up/
> FastDateFormat.getTimeInstance(FastDateFormat.SHORT, Locale.US) uses
> incorrect separator on JDK21
> -
>
> Key: LANG-1718
> URL: https://issues.apache.org/jira/browse/LANG-1718
> Project: Commons Lang
> Issue Type: Bug
> Components: lang.time.*
>Affects Versions: 3.13.0
>Reporter: Konrad Windszus
>Priority: Major
>
> The following code piece fails with a ParseException on JDK 21.0.1 but
> succeeds with JDK 17.0.7 (and earlier)
> {code}
> FastDateFormat dateFormat =
> FastDateFormat.getTimeInstance(FastDateFormat.SHORT, Locale.US);
> dateFormat2.parse("11:00 AM");
> {code}
> The reason for that is that the {{dateFormat.pattern}} with JDK21 is
> {code}
> [104, 0, 58, 0, 109, 0, 109, 0, 47, 32, 97, 0]
> {code}
> while with JDK 17 it is
> {code}
> [104, 58, 109, 109, 32, 97]
> {code}
> Notice the difference in the separator between the time and the am/pm!
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (DOXIASITETOOLS-334) Pass project relative source path to Parser.parse(...) as reference argument
[ https://issues.apache.org/jira/browse/DOXIASITETOOLS-334?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Konrad Windszus updated DOXIASITETOOLS-334: --- Summary: Pass project relative source path to Parser.parse(...) as reference argument (was: Pass basedir relative source path to Parser.parse(...) as reference argument) > Pass project relative source path to Parser.parse(...) as reference argument > > > Key: DOXIASITETOOLS-334 > URL: https://issues.apache.org/jira/browse/DOXIASITETOOLS-334 > Project: Maven Doxia Sitetools > Issue Type: Improvement > Components: Site renderer >Reporter: Konrad Windszus >Priority: Major > Fix For: 2.0.0-M18 > > > Currently only the file name (without its path) is passed in > https://github.com/apache/maven-doxia-sitetools/blob/96e245055fa90689ab5464a39b2bea5d4477cedf/doxia-site-renderer/src/main/java/org/apache/maven/doxia/siterenderer/DefaultSiteRenderer.java#L369. > In order to ease identifying the file the relative path should be passed. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (DOXIASITETOOLS-334) Pass basedir relative source path to Parser.parse(...) as reference argument
[ https://issues.apache.org/jira/browse/DOXIASITETOOLS-334?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17833267#comment-17833267 ] Konrad Windszus commented on DOXIASITETOOLS-334: I don't see how [https://github.com/apache/maven-doxia-sitetools/blob/96e245055fa90689ab5464a39b2bea5d4477cedf/doxia-site-renderer/src/main/java/org/apache/maven/doxia/siterenderer/DefaultSiteRenderer.java#L584-L585] is related to this issue. > Pass basedir relative source path to Parser.parse(...) as reference argument > > > Key: DOXIASITETOOLS-334 > URL: https://issues.apache.org/jira/browse/DOXIASITETOOLS-334 > Project: Maven Doxia Sitetools > Issue Type: Improvement > Components: Site renderer >Reporter: Konrad Windszus >Priority: Major > Fix For: 2.0.0-M18 > > > Currently only the file name (without its path) is passed in > https://github.com/apache/maven-doxia-sitetools/blob/96e245055fa90689ab5464a39b2bea5d4477cedf/doxia-site-renderer/src/main/java/org/apache/maven/doxia/siterenderer/DefaultSiteRenderer.java#L369. > In order to ease identifying the file the relative path should be passed. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (DOXIASITETOOLS-334) Pass basedir relative source path to Parser.parse(...) as reference argument
[
https://issues.apache.org/jira/browse/DOXIASITETOOLS-334?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17833263#comment-17833263
]
Konrad Windszus commented on DOXIASITETOOLS-334:
Because the parser does otherwise not know the basedir and since DOXIA-723 uses
the reference argument to emit log messages you see logs like
{code}
[WARNING] analyze-classes-mojo.xml, line 7, column 56: Anchor name "myanchor"
used more than once
{code}
instead of
{code}
[WARNING] target/generated-site/xdoc/analyze-classes-mojo.xml, line 7, column
56: Anchor name "myanchor" used more than once
{code}
> Pass basedir relative source path to Parser.parse(...) as reference argument
>
>
> Key: DOXIASITETOOLS-334
> URL: https://issues.apache.org/jira/browse/DOXIASITETOOLS-334
> Project: Maven Doxia Sitetools
> Issue Type: Improvement
> Components: Site renderer
>Reporter: Konrad Windszus
>Priority: Major
> Fix For: 2.0.0-M18
>
>
> Currently only the file name (without its path) is passed in
> https://github.com/apache/maven-doxia-sitetools/blob/96e245055fa90689ab5464a39b2bea5d4477cedf/doxia-site-renderer/src/main/java/org/apache/maven/doxia/siterenderer/DefaultSiteRenderer.java#L369.
> In order to ease identifying the file the relative path should be passed.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (DOXIASITETOOLS-334) Pass basedir relative source path to Parser.parse(...) as reference argument
[ https://issues.apache.org/jira/browse/DOXIASITETOOLS-334?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Konrad Windszus updated DOXIASITETOOLS-334: --- Summary: Pass basedir relative source path to Parser.parse(...) as reference argument (was: Pass relative source path to Parser.parse(...) as reference argument) > Pass basedir relative source path to Parser.parse(...) as reference argument > > > Key: DOXIASITETOOLS-334 > URL: https://issues.apache.org/jira/browse/DOXIASITETOOLS-334 > Project: Maven Doxia Sitetools > Issue Type: Improvement > Components: Site renderer >Reporter: Konrad Windszus >Priority: Major > Fix For: 2.0.0-M18 > > > Currently only the file name (without its path) is passed in > https://github.com/apache/maven-doxia-sitetools/blob/96e245055fa90689ab5464a39b2bea5d4477cedf/doxia-site-renderer/src/main/java/org/apache/maven/doxia/siterenderer/DefaultSiteRenderer.java#L369. > In order to ease identifying the file the relative path should be passed. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (DOXIASITETOOLS-334) Pass relative source path to Parser.parse(...) as reference argument
[
https://issues.apache.org/jira/browse/DOXIASITETOOLS-334?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17833258#comment-17833258
]
Konrad Windszus commented on DOXIASITETOOLS-334:
But then we should really pass {{doxiaSourcePath}} as last argument (reference)
to
https://github.com/apache/maven-doxia-sitetools/blob/96e245055fa90689ab5464a39b2bea5d4477cedf/doxia-site-renderer/src/main/java/org/apache/maven/doxia/siterenderer/DefaultSiteRenderer.java#L369
instead of {{inputPath}}.
> Pass relative source path to Parser.parse(...) as reference argument
>
>
> Key: DOXIASITETOOLS-334
> URL: https://issues.apache.org/jira/browse/DOXIASITETOOLS-334
> Project: Maven Doxia Sitetools
> Issue Type: Improvement
> Components: Site renderer
>Reporter: Konrad Windszus
>Priority: Major
> Fix For: 2.0.0-M18
>
>
> Currently only the file name (without its path) is passed in
> https://github.com/apache/maven-doxia-sitetools/blob/96e245055fa90689ab5464a39b2bea5d4477cedf/doxia-site-renderer/src/main/java/org/apache/maven/doxia/siterenderer/DefaultSiteRenderer.java#L369.
> In order to ease identifying the file the relative path should be passed.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (DOXIASITETOOLS-334) Pass relative source path to Parser.parse(...) as reference argument
[ https://issues.apache.org/jira/browse/DOXIASITETOOLS-334?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17833241#comment-17833241 ] Konrad Windszus commented on DOXIASITETOOLS-334: This is not really what I expected, but helpful. So input path is really always only the file name (despite its name)? > Pass relative source path to Parser.parse(...) as reference argument > > > Key: DOXIASITETOOLS-334 > URL: https://issues.apache.org/jira/browse/DOXIASITETOOLS-334 > Project: Maven Doxia Sitetools > Issue Type: Improvement > Components: Site renderer >Reporter: Konrad Windszus >Priority: Major > Fix For: 2.0.0-M18 > > > Currently only the file name (without its path) is passed in > https://github.com/apache/maven-doxia-sitetools/blob/96e245055fa90689ab5464a39b2bea5d4477cedf/doxia-site-renderer/src/main/java/org/apache/maven/doxia/siterenderer/DefaultSiteRenderer.java#L369. > In order to ease identifying the file the relative path should be passed. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (DOXIASITETOOLS-334) Pass relative source path to Parser.parse(...) as reference argument
[
https://issues.apache.org/jira/browse/DOXIASITETOOLS-334?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17833116#comment-17833116
]
Konrad Windszus commented on DOXIASITETOOLS-334:
[~michael-o] I would appreciate if you can clarify the meaning of those three
fields of the {{DocumentRenderingContext}}:
# basedir (absolute or relative, if relative, to what path?)
# basedirRelativePath (what should it point to?)
# outputPath/inputPath (relative to which directory?)
https://github.com/apache/maven-doxia-sitetools/blob/96e245055fa90689ab5464a39b2bea5d4477cedf/doxia-site-renderer/src/main/java/org/apache/maven/doxia/siterenderer/DocumentRenderingContext.java#L97C13-L99C29
> Pass relative source path to Parser.parse(...) as reference argument
>
>
> Key: DOXIASITETOOLS-334
> URL: https://issues.apache.org/jira/browse/DOXIASITETOOLS-334
> Project: Maven Doxia Sitetools
> Issue Type: Improvement
> Components: Site renderer
>Reporter: Konrad Windszus
>Priority: Major
> Fix For: 2.0.0-M18
>
>
> Currently only the file name (without its path) is passed in
> https://github.com/apache/maven-doxia-sitetools/blob/96e245055fa90689ab5464a39b2bea5d4477cedf/doxia-site-renderer/src/main/java/org/apache/maven/doxia/siterenderer/DefaultSiteRenderer.java#L369.
> In order to ease identifying the file the relative path should be passed.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (DOXIASITETOOLS-334) Pass relative source path to Parser.parse(...) as reference argument
[ https://issues.apache.org/jira/browse/DOXIASITETOOLS-334?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17833109#comment-17833109 ] Konrad Windszus commented on DOXIASITETOOLS-334: The are relative to the module base dir according to https://github.com/apache/maven-doxia-sitetools/blob/96e245055fa90689ab5464a39b2bea5d4477cedf/doxia-site-renderer/src/main/java/org/apache/maven/doxia/siterenderer/DefaultSiteRenderer.java#L207 (therefore often contain only a filename without any path info). But in order to be really helpful, they should be relative to the Maven basedir. > Pass relative source path to Parser.parse(...) as reference argument > > > Key: DOXIASITETOOLS-334 > URL: https://issues.apache.org/jira/browse/DOXIASITETOOLS-334 > Project: Maven Doxia Sitetools > Issue Type: Improvement > Components: Site renderer >Reporter: Konrad Windszus >Priority: Major > Fix For: 2.0.0-M18 > > > Currently only the file name (without its path) is passed in > https://github.com/apache/maven-doxia-sitetools/blob/96e245055fa90689ab5464a39b2bea5d4477cedf/doxia-site-renderer/src/main/java/org/apache/maven/doxia/siterenderer/DefaultSiteRenderer.java#L369. > In order to ease identifying the file the relative path should be passed. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (SLING-12278) Improve handling of late initialized context in SlingContextExtension/OsgiContextExtension
[
https://issues.apache.org/jira/browse/SLING-12278?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konrad Windszus reassigned SLING-12278:
---
Assignee: (was: Konrad Windszus)
> Improve handling of late initialized context in
> SlingContextExtension/OsgiContextExtension
> --
>
> Key: SLING-12278
> URL: https://issues.apache.org/jira/browse/SLING-12278
> Project: Sling
> Issue Type: Improvement
>Reporter: Konrad Windszus
>Priority: Major
>
> Currently neither in
> https://sling.apache.org/documentation/development/osgi-mock.html#junit-5-osgi-context-junit-extension
> nor in
> https://sling.apache.org/documentation/development/sling-mock.html#junit-5-sling-context-junit-extension
> it is mentioned that the context must not be initialized in {{@BeforeAll}}
> or {{@BeforeEach}} as at that point in time the extension has already
> initialized another context. Those two context may lead to subtle issues (for
> example if resources are only added in the second context). For a concrete
> example look at https://github.com/wcm-io/io.wcm.testing.aem-mock/issues/37.
> In the best case the JUnit5 extension never creates a context (but only uses
> the existing instance) or at least creation should be deferred until the
> Before methods have been executed.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (SLING-12278) Improve handling of late instantiated context in SlingContextExtension/OsgiContextExtension
[
https://issues.apache.org/jira/browse/SLING-12278?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konrad Windszus updated SLING-12278:
Summary: Improve handling of late instantiated context in
SlingContextExtension/OsgiContextExtension (was: Improve handling of late
initialized context in SlingContextExtension/OsgiContextExtension)
> Improve handling of late instantiated context in
> SlingContextExtension/OsgiContextExtension
> ---
>
> Key: SLING-12278
> URL: https://issues.apache.org/jira/browse/SLING-12278
> Project: Sling
> Issue Type: Improvement
>Reporter: Konrad Windszus
>Priority: Major
>
> Currently neither in
> https://sling.apache.org/documentation/development/osgi-mock.html#junit-5-osgi-context-junit-extension
> nor in
> https://sling.apache.org/documentation/development/sling-mock.html#junit-5-sling-context-junit-extension
> it is mentioned that the context must not be initialized in {{@BeforeAll}}
> or {{@BeforeEach}} as at that point in time the extension has already
> initialized another context. Those two context may lead to subtle issues (for
> example if resources are only added in the second context). For a concrete
> example look at https://github.com/wcm-io/io.wcm.testing.aem-mock/issues/37.
> In the best case the JUnit5 extension never creates a context (but only uses
> the existing instance) or at least creation should be deferred until the
> Before methods have been executed.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (SLING-12278) Improve handling of late instantiated context in SlingContextExtension/OsgiContextExtension
[
https://issues.apache.org/jira/browse/SLING-12278?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konrad Windszus updated SLING-12278:
Description:
Currently neither in
https://sling.apache.org/documentation/development/osgi-mock.html#junit-5-osgi-context-junit-extension
nor in
https://sling.apache.org/documentation/development/sling-mock.html#junit-5-sling-context-junit-extension
it is mentioned that the context must not be instantiated in {{@BeforeAll}} or
{{@BeforeEach}} as at that point in time the extension has already instantiated
another context. Those two contexts may lead to subtle issues (for example if
resources are only added in the second context). For a concrete example look at
https://github.com/wcm-io/io.wcm.testing.aem-mock/issues/37.
In the best case the JUnit5 extension never creates a context (but only uses
the existing instance) or at least creation should be deferred until the Before
methods have been executed.
was:
Currently neither in
https://sling.apache.org/documentation/development/osgi-mock.html#junit-5-osgi-context-junit-extension
nor in
https://sling.apache.org/documentation/development/sling-mock.html#junit-5-sling-context-junit-extension
it is mentioned that the context must not be initialized in {{@BeforeAll}} or
{{@BeforeEach}} as at that point in time the extension has already initialized
another context. Those two context may lead to subtle issues (for example if
resources are only added in the second context). For a concrete example look at
https://github.com/wcm-io/io.wcm.testing.aem-mock/issues/37.
In the best case the JUnit5 extension never creates a context (but only uses
the existing instance) or at least creation should be deferred until the Before
methods have been executed.
> Improve handling of late instantiated context in
> SlingContextExtension/OsgiContextExtension
> ---
>
> Key: SLING-12278
> URL: https://issues.apache.org/jira/browse/SLING-12278
> Project: Sling
> Issue Type: Improvement
>Reporter: Konrad Windszus
>Priority: Major
>
> Currently neither in
> https://sling.apache.org/documentation/development/osgi-mock.html#junit-5-osgi-context-junit-extension
> nor in
> https://sling.apache.org/documentation/development/sling-mock.html#junit-5-sling-context-junit-extension
> it is mentioned that the context must not be instantiated in {{@BeforeAll}}
> or {{@BeforeEach}} as at that point in time the extension has already
> instantiated another context. Those two contexts may lead to subtle issues
> (for example if resources are only added in the second context). For a
> concrete example look at
> https://github.com/wcm-io/io.wcm.testing.aem-mock/issues/37.
> In the best case the JUnit5 extension never creates a context (but only uses
> the existing instance) or at least creation should be deferred until the
> Before methods have been executed.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
