[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)
[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: 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
>Assignee: 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] [Created] (DOXIASITETOOLS-334) Pass relative source path to Parser.parse(...) as reference argument
Konrad Windszus created DOXIASITETOOLS-334: -- Summary: 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 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] (DOXIA-733) SinkWrapper must allow overwriting legacy Doxia 1.0 methods
[
https://issues.apache.org/jira/browse/DOXIA-733?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konrad Windszus resolved DOXIA-733.
---
Resolution: Invalid
> SinkWrapper must allow overwriting legacy Doxia 1.0 methods
> ---
>
> Key: DOXIA-733
> URL: https://issues.apache.org/jira/browse/DOXIA-733
> Project: Maven Doxia
> Issue Type: Improvement
> Components: Core
>Affects Versions: 2.0.0-M9
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
>
> Currently {{SinkWrapper}} extends {{AbstractSink}}. The latter declares lots
> of Doxia 1.0 methods as final though (and just delegates to the Doxia 1.1/2.0
> equivalent).
> While this is fine for regular Sink implementations it does not work for a
> SinkWrapper (which is not involved when the delegation takes place).
> Therefore those methods must not be final in {{SinkWrapper}}.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (DOXIA-733) SinkWrapper must allow overwriting legacy Doxia 1.0 methods
[
https://issues.apache.org/jira/browse/DOXIA-733?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17833055#comment-17833055
]
Konrad Windszus commented on DOXIA-733:
---
As each method in Java is virtual even SinkWrappers have the Doxia1.1/2.0
method correctly called from the final AbstractSink Doxia 1.0 method.
> SinkWrapper must allow overwriting legacy Doxia 1.0 methods
> ---
>
> Key: DOXIA-733
> URL: https://issues.apache.org/jira/browse/DOXIA-733
> Project: Maven Doxia
> Issue Type: Improvement
> Components: Core
>Affects Versions: 2.0.0-M9
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
>
> Currently {{SinkWrapper}} extends {{AbstractSink}}. The latter declares lots
> of Doxia 1.0 methods as final though (and just delegates to the Doxia 1.1/2.0
> equivalent).
> While this is fine for regular Sink implementations it does not work for a
> SinkWrapper (which is not involved when the delegation takes place).
> Therefore those methods must not be final in {{SinkWrapper}}.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (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:comment-tabpanel=17831923#comment-17831923
]
Konrad Windszus commented on SLING-12278:
-
I think
https://junit.org/junit5/docs/current/user-guide/#extensions-registration-programmatic
is the better pattern for parameterizing JUnit extensions.
> 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] [Commented] (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:comment-tabpanel=17831922#comment-17831922
]
Konrad Windszus commented on SLING-12278:
-
[~sseifert] I would appreciate your input here as for me there is way too much
magic inside
https://github.com/apache/sling-org-apache-sling-testing-sling-mock/blob/41c4a554333a2fc8c32f9bd233290132b638de4b/junit5/src/main/java/org/apache/sling/testing/mock/sling/junit5/SlingContextExtension.java#L41-L62.
> 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] [Created] (SLING-12278) Improve handling of late initialized context in SlingContextExtension/OsgiContextExtension
Konrad Windszus created SLING-12278:
---
Summary: 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
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] [Created] (SLING-12277) Improve logging during AbstractSlingRepositoryManager.executeRepositoryInitializers()
Konrad Windszus created SLING-12277:
---
Summary: Improve logging during
AbstractSlingRepositoryManager.executeRepositoryInitializers()
Key: SLING-12277
URL: https://issues.apache.org/jira/browse/SLING-12277
Project: Sling
Issue Type: Improvement
Components: JCR
Affects Versions: JCR Base 3.2.0
Reporter: Konrad Windszus
As long running {{SlingRepositoryInitializer}} services can defer the startup
quite a lot, it would be helpful to emit regular log messages (with INFO level)
while looping through
https://github.com/apache/sling-org-apache-sling-jcr-base/blob/c8a53dff4ec163e19a014c470126eb4450f78cde/src/main/java/org/apache/sling/jcr/base/AbstractSlingRepositoryManager.java#L625.
The log messages should include:
- Time since repo start,
- Currently running initializer (class name)
- Index of current initializer and total number of initializers
That should allow to predict by looking at the log, if there is any progress in
starting the repo and how long it will probably still take.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (SCM-1016) Build fails with JDK21
[
https://issues.apache.org/jira/browse/SCM-1016?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konrad Windszus resolved SCM-1016.
--
Fix Version/s: 2.1.0
Resolution: Fixed
Fixed in
https://github.com/apache/maven-scm/commit/90f9abc4397e269b929b039dda567f538b28375d.
> Build fails with JDK21
> --
>
> Key: SCM-1016
> URL: https://issues.apache.org/jira/browse/SCM-1016
> Project: Maven SCM
> Issue Type: Bug
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
> Fix For: 2.1.0
>
>
> The following error is emitted
> {code}
> [ERROR] Step 'palantir-java-format' found problem in
> 'src/main/java/org/apache/maven/scm/AbstractScmVersion.java':
> 'com.sun.tools.javac.tree.JCTree
> com.sun.tools.javac.tree.JCTree$JCImport.getQualifiedIdentifier()'
> java.lang.NoSuchMethodError: 'com.sun.tools.javac.tree.JCTree
> com.sun.tools.javac.tree.JCTree$JCImport.getQualifiedIdentifier()'
> at com.palantir.javaformat.java.RemoveUnusedImports.getSimpleName
> (RemoveUnusedImports.java:245)
> at com.palantir.javaformat.java.RemoveUnusedImports.buildReplacements
> (RemoveUnusedImports.java:225)
> at com.palantir.javaformat.java.RemoveUnusedImports.removeUnusedImports
> (RemoveUnusedImports.java:209)
> at com.diffplug.spotless.glue.pjf.PalantirJavaFormatFormatterFunc.apply
> (PalantirJavaFormatFormatterFunc.java:39)
> at com.diffplug.spotless.FormatterFunc.apply (FormatterFunc.java:32)
> at com.diffplug.spotless.FormatterStepImpl$Standard.format
> (FormatterStepImpl.java:82)
> at com.diffplug.spotless.FormatterStep$Strict.format
> (FormatterStep.java:88)
> at com.diffplug.spotless.Formatter.compute (Formatter.java:230)
> at com.diffplug.spotless.PaddedCell.calculateDirtyState
> (PaddedCell.java:203)
> at com.diffplug.spotless.PaddedCell.calculateDirtyState
> (PaddedCell.java:190)
> at com.diffplug.spotless.maven.SpotlessCheckMojo.process
> (SpotlessCheckMojo.java:51)
> at com.diffplug.spotless.maven.AbstractSpotlessMojo.execute
> (AbstractSpotlessMojo.java:198)
> at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo
> (DefaultBuildPluginManager.java:126)
> at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute2
> (MojoExecutor.java:328)
> at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute
> (MojoExecutor.java:316)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:212)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:174)
> at org.apache.maven.lifecycle.internal.MojoExecutor.access$000
> (MojoExecutor.java:75)
> at org.apache.maven.lifecycle.internal.MojoExecutor$1.run
> (MojoExecutor.java:162)
> at org.apache.maven.plugin.DefaultMojosExecutionStrategy.execute
> (DefaultMojosExecutionStrategy.java:39)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:159)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:105)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:73)
> at
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build
> (SingleThreadedBuilder.java:53)
> at org.apache.maven.lifecycle.internal.LifecycleStarter.execute
> (LifecycleStarter.java:118)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:261)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:173)
> at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:101)
> at org.apache.maven.cli.MavenCli.execute (MavenCli.java:906)
> at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:283)
> at org.apache.maven.cli.MavenCli.main (MavenCli.java:206)
> at jdk.internal.reflect.DirectMethodHandleAccessor.invoke
> (DirectMethodHandleAccessor.java:103)
> at java.lang.reflect.Method.invoke (Method.java:580)
> at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced
> (Launcher.java:283)
> at org.codehaus.plexus.classworlds.launcher.Launcher.launch
> (Launcher.java:226)
> at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode
> (Launcher.java:407)
> at org.codehaus.plexus.classworlds.launcher.Launcher.main
> (Launcher.java:348)
> {code}
> This is due to using an outdated palantir formatter in spotless-maven-plugin
> not yet compatible with Java 21
> (https://github.com/palantir/palantir-java-format/issues/885).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (SCM-1016) Build fails with JDK21
Konrad Windszus created SCM-1016:
Summary: Build fails with JDK21
Key: SCM-1016
URL: https://issues.apache.org/jira/browse/SCM-1016
Project: Maven SCM
Issue Type: Bug
Reporter: Konrad Windszus
The following error is emitted
{code}
[ERROR] Step 'palantir-java-format' found problem in
'src/main/java/org/apache/maven/scm/AbstractScmVersion.java':
'com.sun.tools.javac.tree.JCTree
com.sun.tools.javac.tree.JCTree$JCImport.getQualifiedIdentifier()'
java.lang.NoSuchMethodError: 'com.sun.tools.javac.tree.JCTree
com.sun.tools.javac.tree.JCTree$JCImport.getQualifiedIdentifier()'
at com.palantir.javaformat.java.RemoveUnusedImports.getSimpleName
(RemoveUnusedImports.java:245)
at com.palantir.javaformat.java.RemoveUnusedImports.buildReplacements
(RemoveUnusedImports.java:225)
at com.palantir.javaformat.java.RemoveUnusedImports.removeUnusedImports
(RemoveUnusedImports.java:209)
at com.diffplug.spotless.glue.pjf.PalantirJavaFormatFormatterFunc.apply
(PalantirJavaFormatFormatterFunc.java:39)
at com.diffplug.spotless.FormatterFunc.apply (FormatterFunc.java:32)
at com.diffplug.spotless.FormatterStepImpl$Standard.format
(FormatterStepImpl.java:82)
at com.diffplug.spotless.FormatterStep$Strict.format (FormatterStep.java:88)
at com.diffplug.spotless.Formatter.compute (Formatter.java:230)
at com.diffplug.spotless.PaddedCell.calculateDirtyState
(PaddedCell.java:203)
at com.diffplug.spotless.PaddedCell.calculateDirtyState
(PaddedCell.java:190)
at com.diffplug.spotless.maven.SpotlessCheckMojo.process
(SpotlessCheckMojo.java:51)
at com.diffplug.spotless.maven.AbstractSpotlessMojo.execute
(AbstractSpotlessMojo.java:198)
at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo
(DefaultBuildPluginManager.java:126)
at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute2
(MojoExecutor.java:328)
at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute
(MojoExecutor.java:316)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute
(MojoExecutor.java:212)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute
(MojoExecutor.java:174)
at org.apache.maven.lifecycle.internal.MojoExecutor.access$000
(MojoExecutor.java:75)
at org.apache.maven.lifecycle.internal.MojoExecutor$1.run
(MojoExecutor.java:162)
at org.apache.maven.plugin.DefaultMojosExecutionStrategy.execute
(DefaultMojosExecutionStrategy.java:39)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute
(MojoExecutor.java:159)
at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
(LifecycleModuleBuilder.java:105)
at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
(LifecycleModuleBuilder.java:73)
at
org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build
(SingleThreadedBuilder.java:53)
at org.apache.maven.lifecycle.internal.LifecycleStarter.execute
(LifecycleStarter.java:118)
at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:261)
at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:173)
at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:101)
at org.apache.maven.cli.MavenCli.execute (MavenCli.java:906)
at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:283)
at org.apache.maven.cli.MavenCli.main (MavenCli.java:206)
at jdk.internal.reflect.DirectMethodHandleAccessor.invoke
(DirectMethodHandleAccessor.java:103)
at java.lang.reflect.Method.invoke (Method.java:580)
at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced
(Launcher.java:283)
at org.codehaus.plexus.classworlds.launcher.Launcher.launch
(Launcher.java:226)
at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode
(Launcher.java:407)
at org.codehaus.plexus.classworlds.launcher.Launcher.main
(Launcher.java:348)
{code}
This is due to using an outdated palantir formatter in spotless-maven-plugin
not yet compatible with Java 21
(https://github.com/palantir/palantir-java-format/issues/885).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (SCM-1016) Build fails with JDK21
[
https://issues.apache.org/jira/browse/SCM-1016?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konrad Windszus reassigned SCM-1016:
Assignee: Konrad Windszus
> Build fails with JDK21
> --
>
> Key: SCM-1016
> URL: https://issues.apache.org/jira/browse/SCM-1016
> Project: Maven SCM
> Issue Type: Bug
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
>
> The following error is emitted
> {code}
> [ERROR] Step 'palantir-java-format' found problem in
> 'src/main/java/org/apache/maven/scm/AbstractScmVersion.java':
> 'com.sun.tools.javac.tree.JCTree
> com.sun.tools.javac.tree.JCTree$JCImport.getQualifiedIdentifier()'
> java.lang.NoSuchMethodError: 'com.sun.tools.javac.tree.JCTree
> com.sun.tools.javac.tree.JCTree$JCImport.getQualifiedIdentifier()'
> at com.palantir.javaformat.java.RemoveUnusedImports.getSimpleName
> (RemoveUnusedImports.java:245)
> at com.palantir.javaformat.java.RemoveUnusedImports.buildReplacements
> (RemoveUnusedImports.java:225)
> at com.palantir.javaformat.java.RemoveUnusedImports.removeUnusedImports
> (RemoveUnusedImports.java:209)
> at com.diffplug.spotless.glue.pjf.PalantirJavaFormatFormatterFunc.apply
> (PalantirJavaFormatFormatterFunc.java:39)
> at com.diffplug.spotless.FormatterFunc.apply (FormatterFunc.java:32)
> at com.diffplug.spotless.FormatterStepImpl$Standard.format
> (FormatterStepImpl.java:82)
> at com.diffplug.spotless.FormatterStep$Strict.format
> (FormatterStep.java:88)
> at com.diffplug.spotless.Formatter.compute (Formatter.java:230)
> at com.diffplug.spotless.PaddedCell.calculateDirtyState
> (PaddedCell.java:203)
> at com.diffplug.spotless.PaddedCell.calculateDirtyState
> (PaddedCell.java:190)
> at com.diffplug.spotless.maven.SpotlessCheckMojo.process
> (SpotlessCheckMojo.java:51)
> at com.diffplug.spotless.maven.AbstractSpotlessMojo.execute
> (AbstractSpotlessMojo.java:198)
> at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo
> (DefaultBuildPluginManager.java:126)
> at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute2
> (MojoExecutor.java:328)
> at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute
> (MojoExecutor.java:316)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:212)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:174)
> at org.apache.maven.lifecycle.internal.MojoExecutor.access$000
> (MojoExecutor.java:75)
> at org.apache.maven.lifecycle.internal.MojoExecutor$1.run
> (MojoExecutor.java:162)
> at org.apache.maven.plugin.DefaultMojosExecutionStrategy.execute
> (DefaultMojosExecutionStrategy.java:39)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:159)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:105)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:73)
> at
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build
> (SingleThreadedBuilder.java:53)
> at org.apache.maven.lifecycle.internal.LifecycleStarter.execute
> (LifecycleStarter.java:118)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:261)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:173)
> at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:101)
> at org.apache.maven.cli.MavenCli.execute (MavenCli.java:906)
> at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:283)
> at org.apache.maven.cli.MavenCli.main (MavenCli.java:206)
> at jdk.internal.reflect.DirectMethodHandleAccessor.invoke
> (DirectMethodHandleAccessor.java:103)
> at java.lang.reflect.Method.invoke (Method.java:580)
> at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced
> (Launcher.java:283)
> at org.codehaus.plexus.classworlds.launcher.Launcher.launch
> (Launcher.java:226)
> at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode
> (Launcher.java:407)
> at org.codehaus.plexus.classworlds.launcher.Launcher.main
> (Launcher.java:348)
> {code}
> This is due to using an outdated palantir formatter in spotless-maven-plugin
> not yet compatible with Java 21
> (https://github.com/palantir/palantir-java-format/issues/885).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (JCRVLT-748) Fix XSD namespaces
Konrad Windszus created JCRVLT-748: -- Summary: Fix XSD namespaces Key: JCRVLT-748 URL: https://issues.apache.org/jira/browse/JCRVLT-748 Project: Jackrabbit FileVault Issue Type: Improvement Reporter: Konrad Windszus Assignee: Konrad Windszus Using the XSD as outlined in https://jackrabbit.apache.org/filevault/filter.html#general-structure does not work, because https://jackrabbit.apache.org/filevault/xsd/workspacefilter-1.0.xsd does not define a target namespace. One either has to reference the schema without a namespace (https://www.w3.org/TR/xmlschema11-1/#xsi_schemaLocation) or define a target namespace in the XSD. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (SLING-12275) Undeprecate optional element for injector specific annotations
[
https://issues.apache.org/jira/browse/SLING-12275?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konrad Windszus resolved SLING-12275.
-
Resolution: Invalid
Sorry, too early for me. There is already the replacement {{injectionStrategy}}
on the injector specific annotation.
> Undeprecate optional element for injector specific annotations
> --
>
> Key: SLING-12275
> URL: https://issues.apache.org/jira/browse/SLING-12275
> Project: Sling
> Issue Type: Improvement
> Components: Sling Models
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
>
> In the context of SLING-4155 the {{optional}} element has been deprecated.
> It is still necessary though in cases where different element have different
> injection strategies.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (SLING-12275) Undeprecate optional element for injector specific annotations
Konrad Windszus created SLING-12275:
---
Summary: Undeprecate optional element for injector specific
annotations
Key: SLING-12275
URL: https://issues.apache.org/jira/browse/SLING-12275
Project: Sling
Issue Type: Improvement
Components: Sling Models
Reporter: Konrad Windszus
Assignee: Konrad Windszus
In the context of SLING-4155 the {{optional}} element has been deprecated.
It is still necessary though in cases where different element have different
injection strategies.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (SLING-12271) Supported source version 'RELEASE_8' from annotation processor 'org.apache.sling.models.annotations.apt.ValidatingAnnotationProcessor' less than -source '11'
[
https://issues.apache.org/jira/browse/SLING-12271?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konrad Windszus resolved SLING-12271.
-
Fix Version/s: Models API 1.5.2
Resolution: Fixed
> Supported source version 'RELEASE_8' from annotation processor
> 'org.apache.sling.models.annotations.apt.ValidatingAnnotationProcessor' less
> than -source '11'
> -
>
> Key: SLING-12271
> URL: https://issues.apache.org/jira/browse/SLING-12271
> Project: Sling
> Issue Type: Improvement
> Components: Sling Models
>Affects Versions: Models API 1.5.0
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
> Fix For: Models API 1.5.2
>
>
> The annotation processor introduced with SLING-11507 only supports Java 8
> source code version according to the annotation
> https://github.com/apache/sling-org-apache-sling-models-api/blob/3a2bfd7882ef0ef453261aff4f58adeee171c4c7/src/main/java/org/apache/sling/models/annotations/apt/ValidatingAnnotationProcessor.java#L41.
> This leads to the following warning during compilation when using javac's
> {{source}} or {{release}} option with any other value than 1.8/8.
> {code}
> [WARNING] Supported source version 'RELEASE_8' from annotation processor
> 'org.apache.sling.models.annotations.apt.ValidatingAnnotationProcessor' less
> than -source '11'
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (SLING-12271) Supported source version 'RELEASE_8' from annotation processor 'org.apache.sling.models.annotations.apt.ValidatingAnnotationProcessor' less than -source '11'
[
https://issues.apache.org/jira/browse/SLING-12271?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17829942#comment-17829942
]
Konrad Windszus commented on SLING-12271:
-
Fixed in
https://github.com/apache/sling-org-apache-sling-models-api/commit/6d6b5609fe11ad1f4a5014ce2b9254ba1c836147.
> Supported source version 'RELEASE_8' from annotation processor
> 'org.apache.sling.models.annotations.apt.ValidatingAnnotationProcessor' less
> than -source '11'
> -
>
> Key: SLING-12271
> URL: https://issues.apache.org/jira/browse/SLING-12271
> Project: Sling
> Issue Type: Improvement
> Components: Sling Models
>Affects Versions: Models API 1.5.0
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
>
> The annotation processor introduced with SLING-11507 only supports Java 8
> source code version according to the annotation
> https://github.com/apache/sling-org-apache-sling-models-api/blob/3a2bfd7882ef0ef453261aff4f58adeee171c4c7/src/main/java/org/apache/sling/models/annotations/apt/ValidatingAnnotationProcessor.java#L41.
> This leads to the following warning during compilation when using javac's
> {{source}} or {{release}} option with any other value than 1.8/8.
> {code}
> [WARNING] Supported source version 'RELEASE_8' from annotation processor
> 'org.apache.sling.models.annotations.apt.ValidatingAnnotationProcessor' less
> than -source '11'
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (SLING-12263) Separate real OSGi bundles from simple JARs in Downloads page
[ https://issues.apache.org/jira/browse/SLING-12263?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Konrad Windszus resolved SLING-12263. - Resolution: Fixed > Separate real OSGi bundles from simple JARs in Downloads page > - > > Key: SLING-12263 > URL: https://issues.apache.org/jira/browse/SLING-12263 > Project: Sling > Issue Type: Improvement > Components: Site >Reporter: Konrad Windszus >Assignee: Konrad Windszus >Priority: Major > > Currently the page https://sling.apache.org/downloads.cgi#sling-components > has a section "Sling Components" which contains most of the Sling modules. > However not all in that list are bundles. > Therefore I propose to rename "Sling Components" to "Sling Bundles" (and only > list real OSGi bundles there) and add an additional section named "Sling > Helpers" and list all JARs there which do not fit in any other category > (maven plugins, bnd plugins, IDE or Sling Application). > Those are primarily all annotation modules like > - https://github.com/apache/sling-adapter-annotations > - https://github.com/apache/sling-org-apache-sling-adapter-annotations > but also > - > https://github.com/apache/sling-org-apache-sling-installer-provider-installhook > ... -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (SLING-12273) Build breaks on Java 21
[
https://issues.apache.org/jira/browse/SLING-12273?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konrad Windszus resolved SLING-12273.
-
Resolution: Fixed
Fixed by updating to sling-bundle-parent 60 in
https://github.com/apache/sling-org-apache-sling-models-api/commit/fbfb295c90b08336e75cfb2d59ebbcd09a329da9
and the two subsequent commits.
> Build breaks on Java 21
> ---
>
> Key: SLING-12273
> URL: https://issues.apache.org/jira/browse/SLING-12273
> Project: Sling
> Issue Type: Improvement
> Components: Sling Models
>Affects Versions: Models API 1.5.0
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
> Fix For: Models API 1.5.2
>
>
> The following error is emitted in during building with Maven
> (https://ci-builds.apache.org/blue/organizations/jenkins/Sling%2Fmodules%2Fsling-org-apache-sling-models-api/detail/master/212/pipeline/)
> {code}
> [INFO] --- invoker:3.3.0:run (integration-test) @ org.apache.sling.models.api
> ---
> [INFO] Building: validating-annotation-processor/pom.xml
> [INFO] run post-build script verify.groovy
> [INFO] BUG! exception in phase 'semantic analysis' in source unit
> 'Script1.groovy' Unsupported class file major version 65
> [INFO] validating-annotation-processor/pom.xml .. FAILED
> (15.5 s)
> [INFO] -
> [INFO] Build Summary:
> [INFO] Passed: 0, Failed: 1, Errors: 0, Skipped: 0
> [INFO] -
> [ERROR] The following builds failed:
> [ERROR] * validating-annotation-processor/pom.xml
> [INFO] -
> [INFO]
>
> [INFO] BUILD FAILURE
> [INFO]
>
> [INFO] Total time: 51.891 s
> [INFO] Finished at: 2024-03-15T23:26:49Z
> [INFO]
>
> [INFO] [jenkins-event-spy] Generated
> /home/jenkins/workspace/g-apache-sling-models-api_master/jdk_21_latest@tmp/withMaven74374c80/maven-spy-20240315-232556-91012999432982760308630.log
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-invoker-plugin:3.3.0:run (integration-test) on
> project org.apache.sling.models.api: 1 build failed. See console output above
> for details. -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal org.apache.maven.plugins:maven-invoker-plugin:3.3.0:run
> (integration-test) on project org.apache.sling.models.api: 1 build failed.
> See console output above for details.
> at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute2
> (MojoExecutor.java:333)
> at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute
> (MojoExecutor.java:316)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:212)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:174)
> at org.apache.maven.lifecycle.internal.MojoExecutor.access$000
> (MojoExecutor.java:75)
> at org.apache.maven.lifecycle.internal.MojoExecutor$1.run
> (MojoExecutor.java:162)
> at org.apache.maven.plugin.DefaultMojosExecutionStrategy.execute
> (DefaultMojosExecutionStrategy.java:39)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:159)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:105)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:73)
> at
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build
> (SingleThreadedBuilder.java:53)
> at org.apache.maven.lifecycle.internal.LifecycleStarter.execute
> (LifecycleStarter.java:118)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:261)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:173)
> at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:101)
> at org.apache.maven.cli.MavenCli.execute (MavenCli.java:906)
> at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:283)
> at org.apache.maven.cli.MavenCli.main (MavenCli.java:206)
> at jdk.internal.reflect.DirectMethodHandleAccessor.invoke
> (DirectMethodHandleAccessor.java:103)
> at java.lang.reflect.Method.invoke (Method.java:580)
> at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced
> (Launcher.java:283)
> at org.codehaus.plexus.classworlds.launcher.Launcher.launch
> (Launcher.java:226)
> at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode
> (Launcher.java:407)
> at
[jira] [Assigned] (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 reassigned MENFORCER-500:
-
Assignee: Konrad Windszus
> 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
>
> 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] (MENFORCER-496) Add rule to enforce a specific repository id
[
https://issues.apache.org/jira/browse/MENFORCER-496?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17829685#comment-17829685
]
Konrad Windszus commented on MENFORCER-496:
---
This is already possible via {{requireNoRepositories}}
(https://maven.apache.org/enforcer/enforcer-rules/requireNoRepositories.html)
with parameter {{allowedRepositories}}.
> Add rule to enforce a specific repository id
>
>
> Key: MENFORCER-496
> URL: https://issues.apache.org/jira/browse/MENFORCER-496
> Project: Maven Enforcer Plugin
> Issue Type: Improvement
> Components: Standard Rules
>Reporter: Konrad Windszus
>Priority: Major
>
> Very often in corporate environments a MRM is used which requires certain
> credentials (maintained per id in {{settings.xml}}) both for uploading as
> well as for downloading artifacts. It is crucial that both the repository
> within [distribution managment|https://maven.apache.org/pom.html#Repository]
> as well as the [repository for downloading
> dependencies|https://maven.apache.org/pom.html#Repositories] from that MRM
> uses a certain id.
> It would be beneficial to be able to enforce a certain id for repository URLs
> matching a certain pattern.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
