[jira] [Created] (DOXIA-738) Add Footnoting feature from doxia footnote plugin
Claude Warren created DOXIA-738: --- Summary: Add Footnoting feature from doxia footnote plugin Key: DOXIA-738 URL: https://issues.apache.org/jira/browse/DOXIA-738 Project: Maven Doxia Issue Type: Improvement Components: Module - Markdown Affects Versions: 1.12.0 Reporter: Claude Warren I would like to use the footnoting markdown format available on git and a number of other sited within the documentation generated for Apache websites. To do this, the flexmark footnote extension needs to be added to the Markdown parser -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (SUREFIRE-2217) Surefire wrongly reports number of Junit tests run for test classes with common base class
[
https://issues.apache.org/jira/browse/SUREFIRE-2217?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17856312#comment-17856312
]
Brian Demers commented on SUREFIRE-2217:
I just ran into a similar issue:
Most of these test have a single test method, so seeing `Tests run: 0` stuck
out.
{code:java}
[INFO] Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 1.133 s
-- in dev.jprompts.prompts.impl.JLinePauseTest
[INFO] Tests run: 0, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 1.134 s
-- in dev.jprompts.prompts.impl.DisplayRadioTest
[INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 1.136 s
-- in dev.jprompts.prompts.impl.DumbRadioTest
[INFO] Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 1.144 s
-- in dev.jprompts.prompts.impl.DisplayCheckboxTest
[INFO] Tests run: 0, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 1.144 s
-- in dev.jprompts.prompts.impl.DumbCheckboxTest
[INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 2.142 s
-- in dev.jprompts.prompts.impl.JLinePromptTest {code}
Looks like the same issue as [~losipiuk] posted, additional details:
Surefire: 3.3.0
JUnit: 5.10.2
Single fork, test concurrency configured via JUnit platform:
{code:java}
junit.jupiter.execution.parallel.enabled = true
junit.jupiter.execution.parallel.mode.default = concurrent
{code}
> Surefire wrongly reports number of Junit tests run for test classes with
> common base class
> --
>
> Key: SUREFIRE-2217
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2217
> Project: Maven Surefire
> Issue Type: Bug
>Reporter: Lukasz Osipiuk
>Priority: Minor
>
> Surefire wrongly reports number of Junit tests run for test classes with
> common base class when subclasses are run concurrently.
> It looks like when first test class completes surefire reports the number of
> tests which have been run which is sum of tests run so far from both
> subclasses.
>
> Observed in trinodb/trino. See this issue:
> [https://github.com/trinodb/trino/issues/19908]
>
> cc: [~findepi] [~martint]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (MRESOLVER-571) Import o.e.aether packages with the exact same version in OSGi metadata
Hannes Wellmann created MRESOLVER-571:
-
Summary: Import o.e.aether packages with the exact same version in
OSGi metadata
Key: MRESOLVER-571
URL: https://issues.apache.org/jira/browse/MRESOLVER-571
Project: Maven Resolver
Issue Type: New Feature
Components: Resolver
Affects Versions: 1.9.20, 2.0.0-alpha-11
Reporter: Hannes Wellmann
The documentation states that only maven-resolver artifacts of the exact same
version should be used together:
* [https://maven.apache.org/resolver/api-compatibility.html#outside-of-maven]
*
[https://maven.apache.org/resolver/third-party-integrations.html#maven-resolver-supplier]
But currently the OSGi metadata declare version ranges for imported packages up
until (excluding) the next major version:
{{org.eclipse.aether;version="[1.9,2)"}}
My suggestion is to reflect the requirement for a strict version alignment in
the OSGi metadata and change the Package-Imports to (for example for the next
1.9.21 version):
{{org.eclipse.aether;version="[1.9.21,1.9.21]"}}
{{Of course this would make it impossible (without nasty tricks/out of the box)
to break that (strong) recommendation in OSGi runtimes if unexpected
circumstances would require it.}}
{{I'm currently working on providing a PR for the }}1.9.x{{ and }}master/2.x{{
branch}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MRESOLVER-570) Remove excessive strictness of OSGi dependency metadata
[
https://issues.apache.org/jira/browse/MRESOLVER-570?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17856285#comment-17856285
]
Tamas Cservenak commented on MRESOLVER-570:
---
FTR, 2.0.0 (maybe beta-1, maybe "final", is undecided yet) is out soon. The
1.9.21 OTOH has this single issue yet.
> Remove excessive strictness of OSGi dependency metadata
> ---
>
> Key: MRESOLVER-570
> URL: https://issues.apache.org/jira/browse/MRESOLVER-570
> Project: Maven Resolver
> Issue Type: Improvement
> Components: Resolver
>Affects Versions: 2.0.0-alpha-11, 1.9.20
>Reporter: Hannes Wellmann
>Priority: Major
> Fix For: 2.0.0, 1.9.21, 2.0.0-beta-1
>
>
> The OSGi dependency metadata in multiple resolver artifacts are stricter than
> the declared Maven dependency counterparts and should be harmonized.
> For example for the {{maven-resolver-impl}} the dependencies to
> {{{}Guice{}}}, {{Eclipse Sisu}} and {{javax.inject}} are not marked as
> optional.
> Furthermore the dependency to the org.slf4j.spi package has a version range
> of [1.7,2) which mandates a 1.x slf4j-api bundle in the runtime, while the
> class used from that package is also available in a 2.x version of slf4j-api.
> For all other artifacts the dependency to to javax.inject should be optional
> as well.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MRESOLVER-570) Remove excessive strictness of OSGi dependency metadata
[
https://issues.apache.org/jira/browse/MRESOLVER-570?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17856274#comment-17856274
]
Tamas Cservenak commented on MRESOLVER-570:
---
Thanks for issue! Could you please provide PR for both, 2.x and 1.9.x branches?
Am personally not an OSGi guy (read: no idea what changes needed).
> Remove excessive strictness of OSGi dependency metadata
> ---
>
> Key: MRESOLVER-570
> URL: https://issues.apache.org/jira/browse/MRESOLVER-570
> Project: Maven Resolver
> Issue Type: Improvement
> Components: Resolver
>Affects Versions: 2.0.0-alpha-11, 1.9.20
>Reporter: Hannes Wellmann
>Priority: Major
> Fix For: 2.0.0, 1.9.21
>
>
> The OSGi dependency metadata in multiple resolver artifacts are stricter than
> the declared Maven dependency counterparts and should be harmonized.
> For example for the {{maven-resolver-impl}} the dependencies to
> {{{}Guice{}}}, {{Eclipse Sisu}} and {{javax.inject}} are not marked as
> optional.
> Furthermore the dependency to the org.slf4j.spi package has a version range
> of [1.7,2) which mandates a 1.x slf4j-api bundle in the runtime, while the
> class used from that package is also available in a 2.x version of slf4j-api.
> For all other artifacts the dependency to to javax.inject should be optional
> as well.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MRESOLVER-570) Remove excessive strictness of OSGi dependency metadata
[
https://issues.apache.org/jira/browse/MRESOLVER-570?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tamas Cservenak updated MRESOLVER-570:
--
Fix Version/s: 2.0.0-beta-1
> Remove excessive strictness of OSGi dependency metadata
> ---
>
> Key: MRESOLVER-570
> URL: https://issues.apache.org/jira/browse/MRESOLVER-570
> Project: Maven Resolver
> Issue Type: Improvement
> Components: Resolver
>Affects Versions: 2.0.0-alpha-11, 1.9.20
>Reporter: Hannes Wellmann
>Priority: Major
> Fix For: 2.0.0, 1.9.21, 2.0.0-beta-1
>
>
> The OSGi dependency metadata in multiple resolver artifacts are stricter than
> the declared Maven dependency counterparts and should be harmonized.
> For example for the {{maven-resolver-impl}} the dependencies to
> {{{}Guice{}}}, {{Eclipse Sisu}} and {{javax.inject}} are not marked as
> optional.
> Furthermore the dependency to the org.slf4j.spi package has a version range
> of [1.7,2) which mandates a 1.x slf4j-api bundle in the runtime, while the
> class used from that package is also available in a 2.x version of slf4j-api.
> For all other artifacts the dependency to to javax.inject should be optional
> as well.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MRESOLVER-570) Remove excessive strictness of OSGi dependency metadata
[
https://issues.apache.org/jira/browse/MRESOLVER-570?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tamas Cservenak updated MRESOLVER-570:
--
Fix Version/s: 2.0.0
1.9.21
> Remove excessive strictness of OSGi dependency metadata
> ---
>
> Key: MRESOLVER-570
> URL: https://issues.apache.org/jira/browse/MRESOLVER-570
> Project: Maven Resolver
> Issue Type: Improvement
> Components: Resolver
>Affects Versions: 2.0.0-alpha-11, 1.9.20
>Reporter: Hannes Wellmann
>Priority: Major
> Fix For: 2.0.0, 1.9.21
>
>
> The OSGi dependency metadata in multiple resolver artifacts are stricter than
> the declared Maven dependency counterparts and should be harmonized.
> For example for the {{maven-resolver-impl}} the dependencies to
> {{{}Guice{}}}, {{Eclipse Sisu}} and {{javax.inject}} are not marked as
> optional.
> Furthermore the dependency to the org.slf4j.spi package has a version range
> of [1.7,2) which mandates a 1.x slf4j-api bundle in the runtime, while the
> class used from that package is also available in a 2.x version of slf4j-api.
> For all other artifacts the dependency to to javax.inject should be optional
> as well.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (MRESOLVER-570) Remove excessive strictness of OSGi dependency metadata
Hannes Wellmann created MRESOLVER-570:
-
Summary: Remove excessive strictness of OSGi dependency metadata
Key: MRESOLVER-570
URL: https://issues.apache.org/jira/browse/MRESOLVER-570
Project: Maven Resolver
Issue Type: Improvement
Components: Resolver
Affects Versions: 1.9.20, 2.0.0-alpha-11
Reporter: Hannes Wellmann
The OSGi dependency metadata in multiple resolver artifacts are stricter than
the declared Maven dependency counterparts and should be harmonized.
For example for the {{maven-resolver-impl}} the dependencies to {{{}Guice{}}},
{{Eclipse Sisu}} and {{javax.inject}} are not marked as optional.
Furthermore the dependency to the org.slf4j.spi package has a version range of
[1.7,2) which mandates a 1.x slf4j-api bundle in the runtime, while the class
used from that package is also available in a 2.x version of slf4j-api.
For all other artifacts the dependency to to javax.inject should be optional as
well.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MBUILDCACHE-73) Add project version as additional property for reconcilation
[
https://issues.apache.org/jira/browse/MBUILDCACHE-73?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17856251#comment-17856251
]
Patrik Dudits commented on MBUILDCACHE-73:
--
Yes, the issue with {{project.version}} is solved. However I'd rather extend
title to be able to use arbitrary expression in reconcilation. Or do I create a
new one?
> Add project version as additional property for reconcilation
>
>
> Key: MBUILDCACHE-73
> URL: https://issues.apache.org/jira/browse/MBUILDCACHE-73
> Project: Maven Build Cache Extension
> Issue Type: New Feature
>Affects Versions: 1.0.1
>Reporter: Patrik Dudits
>Priority: Major
>
> Certain plugins or goals might require to run when project version changes
> regardless of other inputs. A typical example would be {{deploy:deploy}} or
> in my specific case {{docker:build}} - It is OK to reuse the build artifact,
> but if version changed, I do want to upload it.
> Currently only way to achieve that is to put the goal into {{runAlways}}
> section. But that results in needles snapshots to be deployed or docker
> images being built even if there's no relevant change.
> The reconcile section allows to specify properties for futher fine tuning the
> input. These are limited to goal parameters, and neither of my examples
> contain project version as a parameter, both use project model to fetch it.
> Proposal would be to extend tag {{reconcile}} either with:
> * special magic name {{project.version}} to include version tracking, so
> this could be achieved by {{}}
> * attribute {{{}expression{}}}, to achieve the result with {{ propertyName="version" expression="${project.version}"/>}}
> * interpolating {{defaultValue}} attribute
> The second form would be preferrable as it has much larger scale of
> application, I can imagine putting base docker image digests in environment
> variable to invalidate builds when base tag gets updated. It is also more
> discoverable than third option.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MBUILDCACHE-73) Add project version as additional property for reconcilation
[
https://issues.apache.org/jira/browse/MBUILDCACHE-73?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17856246#comment-17856246
]
Xaver commented on MBUILDCACHE-73:
--
I think this Issue may be closed. With MBUILDCACHE-81 /
https://github.com/apache/maven-build-cache-extension/pull/129 the
{{calculateProjectVersionChecksum}} attribute was added
> Add project version as additional property for reconcilation
>
>
> Key: MBUILDCACHE-73
> URL: https://issues.apache.org/jira/browse/MBUILDCACHE-73
> Project: Maven Build Cache Extension
> Issue Type: New Feature
>Affects Versions: 1.0.1
>Reporter: Patrik Dudits
>Priority: Major
>
> Certain plugins or goals might require to run when project version changes
> regardless of other inputs. A typical example would be {{deploy:deploy}} or
> in my specific case {{docker:build}} - It is OK to reuse the build artifact,
> but if version changed, I do want to upload it.
> Currently only way to achieve that is to put the goal into {{runAlways}}
> section. But that results in needles snapshots to be deployed or docker
> images being built even if there's no relevant change.
> The reconcile section allows to specify properties for futher fine tuning the
> input. These are limited to goal parameters, and neither of my examples
> contain project version as a parameter, both use project model to fetch it.
> Proposal would be to extend tag {{reconcile}} either with:
> * special magic name {{project.version}} to include version tracking, so
> this could be achieved by {{}}
> * attribute {{{}expression{}}}, to achieve the result with {{ propertyName="version" expression="${project.version}"/>}}
> * interpolating {{defaultValue}} attribute
> The second form would be preferrable as it has much larger scale of
> application, I can imagine putting base docker image digests in environment
> variable to invalidate builds when base tag gets updated. It is also more
> discoverable than third option.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (MNG-8160) Recreate the transformed artifact if it has been deleted
[ https://issues.apache.org/jira/browse/MNG-8160?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet resolved MNG-8160. -- Fix Version/s: 4.0.0-beta-4 Resolution: Fixed > Recreate the transformed artifact if it has been deleted > > > Key: MNG-8160 > URL: https://issues.apache.org/jira/browse/MNG-8160 > Project: Maven > Issue Type: Bug >Affects Versions: 4.0.0-beta-3 >Reporter: Guillaume Nodet >Assignee: Guillaume Nodet >Priority: Major > Fix For: 4.0.0-beta-4 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (MNG-8161) Recreate the transformed artifact if it has been deleted
[ https://issues.apache.org/jira/browse/MNG-8161?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet closed MNG-8161. Resolution: Duplicate > Recreate the transformed artifact if it has been deleted > > > Key: MNG-8161 > URL: https://issues.apache.org/jira/browse/MNG-8161 > Project: Maven > Issue Type: Bug >Affects Versions: 4.0.0-beta-3 >Reporter: Guillaume Nodet >Assignee: Guillaume Nodet >Priority: Major > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MNG-8161) Recreate the transformed artifact if it has been deleted
Guillaume Nodet created MNG-8161: Summary: Recreate the transformed artifact if it has been deleted Key: MNG-8161 URL: https://issues.apache.org/jira/browse/MNG-8161 Project: Maven Issue Type: Bug Affects Versions: 4.0.0-beta-3 Reporter: Guillaume Nodet Assignee: Guillaume Nodet -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MNG-8160) Recreate the transformed artifact if it has been deleted
Guillaume Nodet created MNG-8160: Summary: Recreate the transformed artifact if it has been deleted Key: MNG-8160 URL: https://issues.apache.org/jira/browse/MNG-8160 Project: Maven Issue Type: Bug Affects Versions: 4.0.0-beta-3 Reporter: Guillaume Nodet Assignee: Guillaume Nodet -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MSHARED-1416) Review and improve the term "Jdk revision"
[ https://issues.apache.org/jira/browse/MSHARED-1416?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17856202#comment-17856202 ] Michael Osipov commented on MSHARED-1416: - I explicitly do not want to mention runtime because what we do is a static class file analysis > Review and improve the term "Jdk revision" > -- > > Key: MSHARED-1416 > URL: https://issues.apache.org/jira/browse/MSHARED-1416 > Project: Maven Shared Components > Issue Type: Task > Components: maven-shared-jar >Affects Versions: maven-shared-jar-3.1.0 >Reporter: Michael Osipov >Assignee: Michael Osipov >Priority: Major > > This term is confusing because this does not relate the used JDK revision at > all. It solely relates to the Java class file version a source file has been > compiled. It does not have to be the same version or revision as the JDK. > Goal is to deprecate the current one and replace with the term "Java Version". -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MNG-8159) Fix search for topDirectory when using -f / --file for Maven 3.9.x
[ https://issues.apache.org/jira/browse/MNG-8159?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak updated MNG-8159: - Fix Version/s: 3.9.9 > Fix search for topDirectory when using -f / --file for Maven 3.9.x > -- > > Key: MNG-8159 > URL: https://issues.apache.org/jira/browse/MNG-8159 > Project: Maven > Issue Type: Bug > Components: Core >Affects Versions: 3.9.2, 3.9.3, 3.9.4, 3.9.5, 3.9.6, 3.9.7, 3.9.8 >Reporter: James Z.M. Gao >Priority: Major > Fix For: 3.9.9 > > > 3.9.x branch does not appliy the patch on master > https://github.com/apache/maven/commit/08e996bb28266a5b1707f45d20809ba44117e16a -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MSHARED-1416) Review and improve the term "Jdk revision"
[
https://issues.apache.org/jira/browse/MSHARED-1416?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17856146#comment-17856146
]
Michael Osipov commented on MSHARED-1416:
-
What about {{maxJavaClassVersion}}?
> Review and improve the term "Jdk revision"
> --
>
> Key: MSHARED-1416
> URL: https://issues.apache.org/jira/browse/MSHARED-1416
> Project: Maven Shared Components
> Issue Type: Task
> Components: maven-shared-jar
>Affects Versions: maven-shared-jar-3.1.0
>Reporter: Michael Osipov
>Assignee: Michael Osipov
>Priority: Major
>
> This term is confusing because this does not relate the used JDK revision at
> all. It solely relates to the Java class file version a source file has been
> compiled. It does not have to be the same version or revision as the JDK.
> Goal is to deprecate the current one and replace with the term "Java Version".
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MNG-8159) Fix search for topDirectory when using -f / --file for Maven 3.9.x
[ https://issues.apache.org/jira/browse/MNG-8159?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17856144#comment-17856144 ] Michael Osipov commented on MNG-8159: - [~cstamas] > Fix search for topDirectory when using -f / --file for Maven 3.9.x > -- > > Key: MNG-8159 > URL: https://issues.apache.org/jira/browse/MNG-8159 > Project: Maven > Issue Type: Bug > Components: Core >Affects Versions: 3.9.2, 3.9.3, 3.9.4, 3.9.5, 3.9.6, 3.9.7, 3.9.8 >Reporter: James Z.M. Gao >Priority: Major > > 3.9.x branch does not appliy the patch on master > https://github.com/apache/maven/commit/08e996bb28266a5b1707f45d20809ba44117e16a -- This message was sent by Atlassian Jira (v8.20.10#820010)
