[jira] [Commented] (MNG-6026) Extend the Project Object Model (POM) with trust information (OpenPGP, hash values)
[
https://issues.apache.org/jira/browse/MNG-6026?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17787456#comment-17787456
]
Martin Monperrus commented on MNG-6026:
---
To avoid POM bloat, one option is to store the sha256 in a lockfile, not in the
pom. This is what we do in https://github.com/chains-project/maven-lockfile/
> Extend the Project Object Model (POM) with trust information (OpenPGP, hash
> values)
> ---
>
> Key: MNG-6026
> URL: https://issues.apache.org/jira/browse/MNG-6026
> Project: Maven
> Issue Type: New Feature
> Components: Core
>Reporter: Florian Schmaus
>Priority: Major
> Labels: artifact-verification, security
>
> The origin of this feature request is the Stackoverflow question
> ["Verification of dependency authenticity in Maven POM based automated build
> systems"|http://stackoverflow.com/a/34795359/194894], and [especially a SO
> user requesting me to put this
> up|http://stackoverflow.com/questions/3307146/verification-of-dependency-authenticy-in-maven-pom-based-automated-build-systems/34795359?noredirect=1#comment62178671_34795359].
> h2. Extend the Project Object Model (POM) with trust information (OpenPGP -
> RFC 4480 and hash values)
> What we need is the possibility to model a trust relation from your project
> or artifact to the declared dependencies. So that, if all involved parties
> declare such a relation, we are able to create a "chain of trust" from the
> root (e.g. the project) over its dependencies down to the very last
> transitive dependency. The Project Object Model (POM) needs to be extended by
> a element for dependencies.
> h3. Current Situation
> Right now we have something like
> {code:xml}
>
> junit
> junit
> 4.0
>
> {code}
> h3. Hard dependencies
> For hard dependencies, could include the sha256sum of artifact
> and its POM file:
> {code:xml}
>
> junit
> junit
> [4.0]
>
>
> [sha256 of junit pom file]
> [sha256sum of artifact (junit.jar)]
>
>
>
> {code}
> h3. Soft dependencies
> If soft, which are also called "ranged" or "dynamic", dependencies are used,
> then we could specify the public key (or multiple) of the keypair used to
> sign the artifacts
> {code:xml}
>
> junit
> junit
> [4.0,4.5)
>
> [secure fingerprint of OpenPGP key used to sign the junit
> artifact(s)]
>
>
>
> {code}
> I'm not sure if this is the right place to raise an feature request for the
> POM format itself. I've already tried to get in touch with the right people
> about this feature request, but failed. I'm willing to help designing and
> implementing this, but need guidance.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MPIR-451) Rename "Dependency Information" to "Maven Coordinates".
[
https://issues.apache.org/jira/browse/MPIR-451?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17787424#comment-17787424
]
Michael Osipov commented on MPIR-451:
-
I don't consider {{dependency-info.html}} to be cool or helpful ;-)
> Rename "Dependency Information" to "Maven Coordinates".
>
>
> Key: MPIR-451
> URL: https://issues.apache.org/jira/browse/MPIR-451
> Project: Maven Project Info Reports Plugin
> Issue Type: Improvement
>Reporter: Elliotte Rusty Harold
>Priority: Major
>
> From a thread on commons-math where I noticed I was unable to find the Maven
> coordinates for the project on the project's website:
> The only way to get to that page is scroll about two thirds of the way down a
> sidebar and click one of the four links that mention "dependencies" that
> seems as likely to bring you to a list of commons-math's own dependencies
> rather than how to add this project as a dependency. I'm a Maven comitter
> who's spent way more time in the depths of Maven Project website generation
> than 99.9% of Java programmers and I still couldn't find this the first time
> I looked for it. That's de facto evidence that this information is not easy
> to find.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MPIR-451) Rename "Dependency Information" to "Maven Coordinates".
[ https://issues.apache.org/jira/browse/MPIR-451?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17787419#comment-17787419 ] Elliotte Rusty Harold commented on MPIR-451: The file name doesn't matter as much though it might help a little with SEO to change it. However the link in the sidebar that says Dependency Information should instead be Maven Coordinates Possibly the main header on that page could also change from "Dependency Information" to "Maven Coordinates" I'm a little hesitant to change the file name only because that would break existing links, and "Cool URIs don't change" https://www.w3.org/Provider/Style/URI > Rename "Dependency Information" to "Maven Coordinates". > > > Key: MPIR-451 > URL: https://issues.apache.org/jira/browse/MPIR-451 > Project: Maven Project Info Reports Plugin > Issue Type: Improvement >Reporter: Elliotte Rusty Harold >Priority: Major > > From a thread on commons-math where I noticed I was unable to find the Maven > coordinates for the project on the project's website: > The only way to get to that page is scroll about two thirds of the way down a > sidebar and click one of the four links that mention "dependencies" that > seems as likely to bring you to a list of commons-math's own dependencies > rather than how to add this project as a dependency. I'm a Maven comitter > who's spent way more time in the depths of Maven Project website generation > than 99.9% of Java programmers and I still couldn't find this the first time > I looked for it. That's de facto evidence that this information is not easy > to find. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MDEP-898) Upgrade to JDK11+ build requirement
[
https://issues.apache.org/jira/browse/MDEP-898?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17787417#comment-17787417
]
Michael Osipov commented on MDEP-898:
-
[~hboutemy], I believe that this one is obsolete now, no?
> Upgrade to JDK11+ build requirement
> ---
>
> Key: MDEP-898
> URL: https://issues.apache.org/jira/browse/MDEP-898
> Project: Maven Dependency Plugin
> Issue Type: Improvement
>Affects Versions: 3.6.1
>Reporter: Karl Heinz Marbaise
>Assignee: Karl Heinz Marbaise
>Priority: Minor
> Fix For: 3.6.2
>
>
> * Upgrade build requirement to JDK11+ so we can use
> {{8}} and get rid of
> WARNINGs like {{Warning: bootstrap class path not set in conjunction with
> -source 8}}
> * The reason for the WARNING is that we don't correctly set the bootstrap
> classpath which can be easily handled by using {{--release}} option by JDK9+
> and the real point is that we don't use animalsniffer anymore. That was our
> safety net which is not there anymore.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (MCHECKSTYLE-443) Upgrade to Parent 41
[ https://issues.apache.org/jira/browse/MCHECKSTYLE-443?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov closed MCHECKSTYLE-443. -- Resolution: Fixed Fixed with [56157e4c1d8c3dc25ee69a0dd35a92007ae126a6|https://gitbox.apache.org/repos/asf?p=maven-checkstyle-plugin.git;a=commit;h=56157e4c1d8c3dc25ee69a0dd35a92007ae126a6]. > Upgrade to Parent 41 > > > Key: MCHECKSTYLE-443 > URL: https://issues.apache.org/jira/browse/MCHECKSTYLE-443 > Project: Maven Checkstyle Plugin > Issue Type: Dependency upgrade >Reporter: Michael Osipov >Assignee: Michael Osipov >Priority: Major > Fix For: next-release > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MCHECKSTYLE-443) Upgrade to Parent 41
Michael Osipov created MCHECKSTYLE-443: -- Summary: Upgrade to Parent 41 Key: MCHECKSTYLE-443 URL: https://issues.apache.org/jira/browse/MCHECKSTYLE-443 Project: Maven Checkstyle Plugin Issue Type: Dependency upgrade Reporter: Michael Osipov Assignee: Michael Osipov Fix For: next-release -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (MPMD-388) Upgrade to Parent 41
[ https://issues.apache.org/jira/browse/MPMD-388?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov closed MPMD-388. --- Resolution: Fixed Fixed with [9ce35a43fef8f50d84782eb8a960ceb832d386ec|https://gitbox.apache.org/repos/asf?p=maven-pmd-plugin.git;a=commit;h=9ce35a43fef8f50d84782eb8a960ceb832d386ec]. > Upgrade to Parent 41 > > > Key: MPMD-388 > URL: https://issues.apache.org/jira/browse/MPMD-388 > Project: Maven PMD Plugin > Issue Type: Dependency upgrade >Reporter: Michael Osipov >Assignee: Michael Osipov >Priority: Major > Fix For: next-release > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MPMD-388) Upgrade to Parent 41
Michael Osipov created MPMD-388: --- Summary: Upgrade to Parent 41 Key: MPMD-388 URL: https://issues.apache.org/jira/browse/MPMD-388 Project: Maven PMD Plugin Issue Type: Dependency upgrade Reporter: Michael Osipov Assignee: Michael Osipov Fix For: next-release -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (MPIR-453) Replace Commons IO in favor of standard APIs
[ https://issues.apache.org/jira/browse/MPIR-453?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov closed MPIR-453. --- Resolution: Fixed Fixed with [60cfdeaa49fc6e7f3ace58cb4e42fbb7622f06b5|https://gitbox.apache.org/repos/asf?p=maven-project-info-reports-plugin.git;a=commit;h=60cfdeaa49fc6e7f3ace58cb4e42fbb7622f06b5]. > Replace Commons IO in favor of standard APIs > > > Key: MPIR-453 > URL: https://issues.apache.org/jira/browse/MPIR-453 > Project: Maven Project Info Reports Plugin > Issue Type: Task >Affects Versions: 3.4.5 >Reporter: Michael Osipov >Assignee: Michael Osipov >Priority: Major > Fix For: 3.5.0 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MPIR-453) Replace Commons IO in favor of standard APIs
Michael Osipov created MPIR-453: --- Summary: Replace Commons IO in favor of standard APIs Key: MPIR-453 URL: https://issues.apache.org/jira/browse/MPIR-453 Project: Maven Project Info Reports Plugin Issue Type: Task Affects Versions: 3.4.5 Reporter: Michael Osipov Assignee: Michael Osipov Fix For: 3.5.0 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (MPIR-446) Update to Maven SCM 2.0.1
[ https://issues.apache.org/jira/browse/MPIR-446?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov closed MPIR-446. --- Resolution: Fixed Fixed with [4d94edc4eb51c0349980eea90a6eb893d9f7f738|https://gitbox.apache.org/repos/asf?p=maven-project-info-reports-plugin.git;a=commit;h=4d94edc4eb51c0349980eea90a6eb893d9f7f738]. > Update to Maven SCM 2.0.1 > - > > Key: MPIR-446 > URL: https://issues.apache.org/jira/browse/MPIR-446 > Project: Maven Project Info Reports Plugin > Issue Type: Dependency upgrade >Reporter: Elliotte Rusty Harold >Assignee: Michael Osipov >Priority: Major > Fix For: 3.5.0 > > > Currently blocked waiting for more providers — perforce, starteam, CVS — to > be updated to 2.0.1 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MPIR-446) Update to Maven SCM 2.0.1
[ https://issues.apache.org/jira/browse/MPIR-446?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov updated MPIR-446: Summary: Update to Maven SCM 2.0.1 (was: Update SCM to 2.0.1) > Update to Maven SCM 2.0.1 > - > > Key: MPIR-446 > URL: https://issues.apache.org/jira/browse/MPIR-446 > Project: Maven Project Info Reports Plugin > Issue Type: Dependency upgrade >Reporter: Elliotte Rusty Harold >Assignee: Michael Osipov >Priority: Major > Fix For: 3.5.0 > > > Currently blocked waiting for more providers — perforce, starteam, CVS — to > be updated to 2.0.1 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MPIR-451) Rename "Dependency Information" to "Maven Coordinates".
[ https://issues.apache.org/jira/browse/MPIR-451?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17787401#comment-17787401 ] Michael Osipov commented on MPIR-451: - Do you expect to see: * Change in content? * Change in output name (file name)? > Rename "Dependency Information" to "Maven Coordinates". > > > Key: MPIR-451 > URL: https://issues.apache.org/jira/browse/MPIR-451 > Project: Maven Project Info Reports Plugin > Issue Type: Improvement >Reporter: Elliotte Rusty Harold >Priority: Major > > From a thread on commons-math where I noticed I was unable to find the Maven > coordinates for the project on the project's website: > The only way to get to that page is scroll about two thirds of the way down a > sidebar and click one of the four links that mention "dependencies" that > seems as likely to bring you to a list of commons-math's own dependencies > rather than how to add this project as a dependency. I'm a Maven comitter > who's spent way more time in the depths of Maven Project website generation > than 99.9% of Java programmers and I still couldn't find this the first time > I looked for it. That's de facto evidence that this information is not easy > to find. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MPIR-446) Update SCM to 2.0.1
[ https://issues.apache.org/jira/browse/MPIR-446?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov updated MPIR-446: Fix Version/s: 3.4.6 > Update SCM to 2.0.1 > --- > > Key: MPIR-446 > URL: https://issues.apache.org/jira/browse/MPIR-446 > Project: Maven Project Info Reports Plugin > Issue Type: Dependency upgrade >Reporter: Elliotte Rusty Harold >Assignee: Michael Osipov >Priority: Major > Fix For: 3.4.6 > > > Currently blocked waiting for more providers — perforce, starteam, CVS — to > be updated to 2.0.1 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (MPIR-446) Update SCM to 2.0.1
[ https://issues.apache.org/jira/browse/MPIR-446?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov reassigned MPIR-446: --- Assignee: Michael Osipov > Update SCM to 2.0.1 > --- > > Key: MPIR-446 > URL: https://issues.apache.org/jira/browse/MPIR-446 > Project: Maven Project Info Reports Plugin > Issue Type: Dependency upgrade >Reporter: Elliotte Rusty Harold >Assignee: Michael Osipov >Priority: Major > > Currently blocked waiting for more providers — perforce, starteam, CVS — to > be updated to 2.0.1 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (MPIR-452) Upgrade to Parent 41
[ https://issues.apache.org/jira/browse/MPIR-452?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov closed MPIR-452. --- Resolution: Fixed Fixed with [91a065b3e5b314daf0a6c338f26a8a3ba2f3931e|https://gitbox.apache.org/repos/asf?p=maven-project-info-reports-plugin.git;a=commit;h=91a065b3e5b314daf0a6c338f26a8a3ba2f3931e]. > Upgrade to Parent 41 > > > Key: MPIR-452 > URL: https://issues.apache.org/jira/browse/MPIR-452 > Project: Maven Project Info Reports Plugin > Issue Type: Dependency upgrade >Reporter: Michael Osipov >Assignee: Michael Osipov >Priority: Major > Fix For: 3.4.6 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MPIR-452) Upgrade to Parent 41
Michael Osipov created MPIR-452: --- Summary: Upgrade to Parent 41 Key: MPIR-452 URL: https://issues.apache.org/jira/browse/MPIR-452 Project: Maven Project Info Reports Plugin Issue Type: Dependency upgrade Reporter: Michael Osipov Assignee: Michael Osipov Fix For: 3.4.6 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (MRESOLVER-435) Refresh download page
[ https://issues.apache.org/jira/browse/MRESOLVER-435?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Slawomir Jaranowski closed MRESOLVER-435. - Assignee: Slawomir Jaranowski Resolution: Fixed > Refresh download page > - > > Key: MRESOLVER-435 > URL: https://issues.apache.org/jira/browse/MRESOLVER-435 > Project: Maven Resolver > Issue Type: Task > Components: Resolver >Reporter: Slawomir Jaranowski >Assignee: Slawomir Jaranowski >Priority: Major > Fix For: 2.0.0, 1.9.17 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MRESOLVER-435) Refresh download page
[ https://issues.apache.org/jira/browse/MRESOLVER-435?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17787396#comment-17787396 ] ASF GitHub Bot commented on MRESOLVER-435: -- slawekjaranowski merged PR #371: URL: https://github.com/apache/maven-resolver/pull/371 > Refresh download page > - > > Key: MRESOLVER-435 > URL: https://issues.apache.org/jira/browse/MRESOLVER-435 > Project: Maven Resolver > Issue Type: Task > Components: Resolver >Reporter: Slawomir Jaranowski >Priority: Major > Fix For: 2.0.0, 1.9.17 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: [PR] [MRESOLVER-435] Refresh download page [maven-resolver]
slawekjaranowski merged PR #371: URL: https://github.com/apache/maven-resolver/pull/371 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Updated] (MNG-7920) Usage of packaging BOM fails in maven-install-plugin
[
https://issues.apache.org/jira/browse/MNG-7920?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Heinz Marbaise updated MNG-7920:
-
Description:
Using to use the {{bom}} packaging in a module it will fail with:
{code}
[INFO]
--
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-install-plugin:3.1.1:install (default-install)
on project bom: The packaging plugin for this project did not assign a main
file to the project but it has attachments. Change packaging to 'pom'. -> [Help
1]
{code}
The bom module looks like this:
{code:xml}
http://maven.apache.org/POM/4.1.0";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
xsi:schemaLocation="http://maven.apache.org/POM/4.1.0
http://maven.apache.org/maven-v4_1_0.xsd";>
4.1.0
maven4
bom-example
bom
bom
...maven4
mod-1
maven4
mod-2
{code}
I would assume that I need to upgrade the maven-install-plugin which is capable
of handling that...but I assumed that this conversion is done by core?
was:
Using to use the `bom` packaging in a module it will fail with:
{code}
[INFO]
--
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-install-plugin:3.1.1:install (default-install)
on project bom: The packaging plugin for this project did not assign a main
file to the project but it has attachments. Change packaging to 'pom'. -> [Help
1]
{code}
The bom module looks like this:
{code:xml}
http://maven.apache.org/POM/4.1.0";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
xsi:schemaLocation="http://maven.apache.org/POM/4.1.0
http://maven.apache.org/maven-v4_1_0.xsd";>
4.1.0
maven4
bom-example
bom
bom
...maven4
mod-1
maven4
mod-2
{code}
I would assume that I need to upgrade the maven-install-plugin which is capable
of handling that...but I assumed that this conversion is done by core?
> Usage of packaging BOM fails in maven-install-plugin
>
>
> Key: MNG-7920
> URL: https://issues.apache.org/jira/browse/MNG-7920
> Project: Maven
> Issue Type: Bug
> Components: Deployment
>Affects Versions: 4.0.0-alpha-8
>Reporter: Karl Heinz Marbaise
>Priority: Critical
> Fix For: 4.0.0, 4.0.0-alpha-9
>
>
> Using to use the {{bom}} packaging in a module it will fail with:
> {code}
> [INFO]
> --
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-install-plugin:3.1.1:install (default-install)
> on project bom: The packaging plugin for this project did not assign a main
> file to the project but it has attachments. Change packaging to 'pom'. ->
> [Help 1]
> {code}
> The bom module looks like this:
> {code:xml}
>xmlns="http://maven.apache.org/POM/4.1.0";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
> xsi:schemaLocation="http://maven.apache.org/POM/4.1.0
> http://maven.apache.org/maven-v4_1_0.xsd";>
> 4.1.0
>
> maven4
> bom-example
>
> bom
> bom
>
>
>
> ...maven4
> mod-1
>
>
> maven4
> mod-2
>
>
>
>
> {code}
> I would assume that I need to upgrade the maven-install-plugin which is
> capable of handling that...but I assumed that this conversion is done by core?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MNG-7920) Usage of packaging BOM fails in maven-install-plugin
[
https://issues.apache.org/jira/browse/MNG-7920?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17787394#comment-17787394
]
Karl Heinz Marbaise commented on MNG-7920:
--
So [~crazyhzm] I have tested the given PR and run the same setup with my
reproducer setup. The result is unfortunately not correct either.
One thing is better, it cleans up the WARNING for {{maven-install-plugin}}, but
on the other hand it results in the following {{pom.xml}} file:
{code:xml}
http://maven.apache.org/POM/4.0.0";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
https://maven.apache.org/xsd/maven-4.0.0.xsd";>
4.0.0
maven.four.bug.7920
bom-example
${revision}
bom
bom
Maven Bug :: 7920 :: BOM
maven.four.bug.7920
mod-1
maven.four.bug.7920
mod-2
{code}
This contains even the whole parent including not resolved {{$\{revision\}}}.
> Usage of packaging BOM fails in maven-install-plugin
>
>
> Key: MNG-7920
> URL: https://issues.apache.org/jira/browse/MNG-7920
> Project: Maven
> Issue Type: Bug
> Components: Deployment
>Affects Versions: 4.0.0-alpha-8
>Reporter: Karl Heinz Marbaise
>Priority: Critical
> Fix For: 4.0.0, 4.0.0-alpha-9
>
>
> Using to use the `bom` packaging in a module it will fail with:
> {code}
> [INFO]
> --
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-install-plugin:3.1.1:install (default-install)
> on project bom: The packaging plugin for this project did not assign a main
> file to the project but it has attachments. Change packaging to 'pom'. ->
> [Help 1]
> {code}
> The bom module looks like this:
> {code:xml}
>xmlns="http://maven.apache.org/POM/4.1.0";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
> xsi:schemaLocation="http://maven.apache.org/POM/4.1.0
> http://maven.apache.org/maven-v4_1_0.xsd";>
> 4.1.0
>
> maven4
> bom-example
>
> bom
> bom
>
>
>
> ...maven4
> mod-1
>
>
> maven4
> mod-2
>
>
>
>
> {code}
> I would assume that I need to upgrade the maven-install-plugin which is
> capable of handling that...but I assumed that this conversion is done by core?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MRESOLVER-435) Refresh download page
[ https://issues.apache.org/jira/browse/MRESOLVER-435?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17787393#comment-17787393 ] ASF GitHub Bot commented on MRESOLVER-435: -- slawekjaranowski merged PR #370: URL: https://github.com/apache/maven-resolver/pull/370 > Refresh download page > - > > Key: MRESOLVER-435 > URL: https://issues.apache.org/jira/browse/MRESOLVER-435 > Project: Maven Resolver > Issue Type: Task > Components: Resolver >Reporter: Slawomir Jaranowski >Priority: Major > Fix For: 2.0.0, 1.9.17 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: [PR] [MRESOLVER-435] Refresh download page [maven-resolver]
slawekjaranowski merged PR #370: URL: https://github.com/apache/maven-resolver/pull/370 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MRESOLVER-435) Refresh download page
[ https://issues.apache.org/jira/browse/MRESOLVER-435?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17787392#comment-17787392 ] ASF GitHub Bot commented on MRESOLVER-435: -- slawekjaranowski opened a new pull request, #371: URL: https://github.com/apache/maven-resolver/pull/371 (no comment) > Refresh download page > - > > Key: MRESOLVER-435 > URL: https://issues.apache.org/jira/browse/MRESOLVER-435 > Project: Maven Resolver > Issue Type: Task > Components: Resolver >Reporter: Slawomir Jaranowski >Priority: Major > Fix For: 2.0.0, 1.9.17 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MNG-7937) Add description of mojo complex object types
Ben Tatham created MNG-7937: --- Summary: Add description of mojo complex object types Key: MNG-7937 URL: https://issues.apache.org/jira/browse/MNG-7937 Project: Maven Issue Type: New Feature Components: Plugin API, Plugin Requests Reporter: Ben Tatham Currently, when a mojo uses "complex types" as parameter types, trying to discover what fields are available in those types,. and that those fields do, is difficult. We rely on external documentation or source code itself. This would be helpful for custom plugins, but also for the common public plugins as well (what are the fields of `Artifact` again?) It would be great if the maven-plugin-plugin generated information about these complex types, hopefully pulling javadoc and/or new annotation information from the type fields themselves. I think this would require updates to a few places: * maven-plugin-plugin to generate the information * the plugin xml itself, to describe these types. * maven-help-plugin to display this information. * plugin report generation to include the type information in the plugin/mojo documentation. * (and then tools/IDE's etc could add features to support this as well with auto-complete, etc) Allowing `@Parameter` (or some new field annotation) on the fields to allow aliases, etc would also be helpful, but perhaps not required/separate feature. An example of documentation that could easily be auto-generated and available via help:describe with this feature: [RuleSet|https://www.mojohaus.org/versions/versions-maven-plugin/version-rules.html#using-the-ruleset-element-in-the-pom]. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MRESOLVER-435) Refresh download page
[ https://issues.apache.org/jira/browse/MRESOLVER-435?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17787389#comment-17787389 ] ASF GitHub Bot commented on MRESOLVER-435: -- slawekjaranowski opened a new pull request, #370: URL: https://github.com/apache/maven-resolver/pull/370 (no comment) > Refresh download page > - > > Key: MRESOLVER-435 > URL: https://issues.apache.org/jira/browse/MRESOLVER-435 > Project: Maven Resolver > Issue Type: Task > Components: Resolver >Reporter: Slawomir Jaranowski >Priority: Major > Fix For: 2.0.0, 1.9.17 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (MRESOLVER-434) Upgrade Parent to 41
[ https://issues.apache.org/jira/browse/MRESOLVER-434?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Slawomir Jaranowski closed MRESOLVER-434. - Resolution: Fixed > Upgrade Parent to 41 > > > Key: MRESOLVER-434 > URL: https://issues.apache.org/jira/browse/MRESOLVER-434 > Project: Maven Resolver > Issue Type: Dependency upgrade > Components: Resolver >Reporter: Slawomir Jaranowski >Assignee: Slawomir Jaranowski >Priority: Major > Fix For: 2.0.0, 1.9.17 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MRESOLVER-372) Sporadic AccessDeniedEx on Windows
[
https://issues.apache.org/jira/browse/MRESOLVER-372?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tamas Cservenak updated MRESOLVER-372:
--
Description:
Preambulum: original issue is not related to locking at all, is about change
done in 1.9 where file processor was altered to use nio2 atomic move. Reason
was to prevent possibility of partial download being read by other process (and
prevent incomplete files in case of crash). Seems windows (or java on windows)
have issues with atomic fs ops, causing sporadic (still unsure why)
AccessDeniedExceptions. Below is original issue description as reported:
{code:java}
Caused by: java.nio.file.AccessDeniedException:
xxx-SNAPSHOT.jar.15463549870494779429.tmp -> -SNAPSHOT.jar
at
java.base/sun.nio.fs.WindowsException.translateToIOException(WindowsException.java:89)
at
java.base/sun.nio.fs.WindowsException.rethrowAsIOException(WindowsException.java:103)
at java.base/sun.nio.fs.WindowsFileCopy.move(WindowsFileCopy.java:317)
at
java.base/sun.nio.fs.WindowsFileSystemProvider.move(WindowsFileSystemProvider.java:293)
at java.base/java.nio.file.Files.move(Files.java:1432)
at org.eclipse.aether.util.FileUtils$2.move(FileUtils.java:108)
at
org.eclipse.aether.internal.impl.DefaultFileProcessor.copy(DefaultFileProcessor.java:96)
at
org.eclipse.aether.internal.impl.DefaultFileProcessor.copy(DefaultFileProcessor.java:88)
at
org.eclipse.aether.internal.impl.DefaultArtifactResolver.getFile(DefaultArtifactResolver.java:490)
... 30 more{code}
My suggestion would be that resolver simply uses the temp file if it can't be
moved to final location and marks it as delete on exit. Even though this is not
optimal, it at least ensures the the build does not fail to the cost that next
time the file needs to be downloaded again.
was:
With the new file-locking in maven-resolver there is a problem under windows if
the file is currently used by another process (this can for example happen in
an IDE ...) and resolver likes to move the file:
{code:java}
Caused by: java.nio.file.AccessDeniedException:
xxx-SNAPSHOT.jar.15463549870494779429.tmp -> -SNAPSHOT.jar
at
java.base/sun.nio.fs.WindowsException.translateToIOException(WindowsException.java:89)
at
java.base/sun.nio.fs.WindowsException.rethrowAsIOException(WindowsException.java:103)
at java.base/sun.nio.fs.WindowsFileCopy.move(WindowsFileCopy.java:317)
at
java.base/sun.nio.fs.WindowsFileSystemProvider.move(WindowsFileSystemProvider.java:293)
at java.base/java.nio.file.Files.move(Files.java:1432)
at org.eclipse.aether.util.FileUtils$2.move(FileUtils.java:108)
at
org.eclipse.aether.internal.impl.DefaultFileProcessor.copy(DefaultFileProcessor.java:96)
at
org.eclipse.aether.internal.impl.DefaultFileProcessor.copy(DefaultFileProcessor.java:88)
at
org.eclipse.aether.internal.impl.DefaultArtifactResolver.getFile(DefaultArtifactResolver.java:490)
... 30 more{code}
My suggestion would be that resolver simply uses the temp file if it can't be
moved to final location and marks it as delete on exit. Even though this is not
optimal, it at least ensures the the build does not fail to the cost that next
time the file needs to be downloaded again.
> Sporadic AccessDeniedEx on Windows
> --
>
> Key: MRESOLVER-372
> URL: https://issues.apache.org/jira/browse/MRESOLVER-372
> Project: Maven Resolver
> Issue Type: Bug
> Components: Resolver
>Reporter: Christoph Läubrich
>Assignee: Tamas Cservenak
>Priority: Major
> Fix For: 2.0.0, 1.9.17
>
>
> Preambulum: original issue is not related to locking at all, is about change
> done in 1.9 where file processor was altered to use nio2 atomic move. Reason
> was to prevent possibility of partial download being read by other process
> (and prevent incomplete files in case of crash). Seems windows (or java on
> windows) have issues with atomic fs ops, causing sporadic (still unsure why)
> AccessDeniedExceptions. Below is original issue description as reported:
>
> {code:java}
> Caused by: java.nio.file.AccessDeniedException:
> xxx-SNAPSHOT.jar.15463549870494779429.tmp -> -SNAPSHOT.jar
> at
> java.base/sun.nio.fs.WindowsException.translateToIOException(WindowsException.java:89)
> at
> java.base/sun.nio.fs.WindowsException.rethrowAsIOException(WindowsException.java:103)
> at java.base/sun.nio.fs.WindowsFileCopy.move(WindowsFileCopy.java:317)
> at
> java.base/sun.nio.fs.WindowsFileSystemProvider.move(WindowsFileSystemProvider.java:293)
> at java.base/java.nio.file.Files.move(Files.java:1432)
> at org.eclipse.aether.util.FileUtils$2.move(FileUtils.ja
[jira] [Commented] (MRESOLVER-434) Upgrade Parent to 41
[ https://issues.apache.org/jira/browse/MRESOLVER-434?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17787387#comment-17787387 ] ASF GitHub Bot commented on MRESOLVER-434: -- slawekjaranowski merged PR #369: URL: https://github.com/apache/maven-resolver/pull/369 > Upgrade Parent to 41 > > > Key: MRESOLVER-434 > URL: https://issues.apache.org/jira/browse/MRESOLVER-434 > Project: Maven Resolver > Issue Type: Dependency upgrade > Components: Resolver >Reporter: Slawomir Jaranowski >Assignee: Slawomir Jaranowski >Priority: Major > Fix For: 2.0.0, 1.9.17 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MRESOLVER-372) Sporadic AccessDeniedEx on Windows
[
https://issues.apache.org/jira/browse/MRESOLVER-372?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tamas Cservenak updated MRESOLVER-372:
--
Summary: Sporadic AccessDeniedEx on Windows (was: Download fails if file
is currently in use under windows)
> Sporadic AccessDeniedEx on Windows
> --
>
> Key: MRESOLVER-372
> URL: https://issues.apache.org/jira/browse/MRESOLVER-372
> Project: Maven Resolver
> Issue Type: Bug
> Components: Resolver
>Reporter: Christoph Läubrich
>Assignee: Tamas Cservenak
>Priority: Major
> Fix For: 2.0.0, 1.9.17
>
>
> With the new file-locking in maven-resolver there is a problem under windows
> if the file is currently used by another process (this can for example happen
> in an IDE ...) and resolver likes to move the file:
>
> {code:java}
> Caused by: java.nio.file.AccessDeniedException:
> xxx-SNAPSHOT.jar.15463549870494779429.tmp -> -SNAPSHOT.jar
> at
> java.base/sun.nio.fs.WindowsException.translateToIOException(WindowsException.java:89)
> at
> java.base/sun.nio.fs.WindowsException.rethrowAsIOException(WindowsException.java:103)
> at java.base/sun.nio.fs.WindowsFileCopy.move(WindowsFileCopy.java:317)
> at
> java.base/sun.nio.fs.WindowsFileSystemProvider.move(WindowsFileSystemProvider.java:293)
> at java.base/java.nio.file.Files.move(Files.java:1432)
> at org.eclipse.aether.util.FileUtils$2.move(FileUtils.java:108)
> at
> org.eclipse.aether.internal.impl.DefaultFileProcessor.copy(DefaultFileProcessor.java:96)
> at
> org.eclipse.aether.internal.impl.DefaultFileProcessor.copy(DefaultFileProcessor.java:88)
> at
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.getFile(DefaultArtifactResolver.java:490)
> ... 30 more{code}
>
> My suggestion would be that resolver simply uses the temp file if it can't be
> moved to final location and marks it as delete on exit. Even though this is
> not optimal, it at least ensures the the build does not fail to the cost that
> next time the file needs to be downloaded again.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [PR] [MRESOLVER-434] Upgrade Parent to 41 [maven-resolver]
slawekjaranowski merged PR #369: URL: https://github.com/apache/maven-resolver/pull/369 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Updated] (MRESOLVER-434) Upgrade Parent to 41
[ https://issues.apache.org/jira/browse/MRESOLVER-434?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak updated MRESOLVER-434: -- Component/s: Resolver > Upgrade Parent to 41 > > > Key: MRESOLVER-434 > URL: https://issues.apache.org/jira/browse/MRESOLVER-434 > Project: Maven Resolver > Issue Type: Dependency upgrade > Components: Resolver >Reporter: Slawomir Jaranowski >Priority: Major > Fix For: 2.0.0, 1.9.17 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (MRESOLVER-434) Upgrade Parent to 41
[ https://issues.apache.org/jira/browse/MRESOLVER-434?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak reassigned MRESOLVER-434: - Assignee: Slawomir Jaranowski > Upgrade Parent to 41 > > > Key: MRESOLVER-434 > URL: https://issues.apache.org/jira/browse/MRESOLVER-434 > Project: Maven Resolver > Issue Type: Dependency upgrade > Components: Resolver >Reporter: Slawomir Jaranowski >Assignee: Slawomir Jaranowski >Priority: Major > Fix For: 2.0.0, 1.9.17 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MRESOLVER-434) Upgrade Parent to 41
[ https://issues.apache.org/jira/browse/MRESOLVER-434?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17787386#comment-17787386 ] ASF GitHub Bot commented on MRESOLVER-434: -- slawekjaranowski merged PR #368: URL: https://github.com/apache/maven-resolver/pull/368 > Upgrade Parent to 41 > > > Key: MRESOLVER-434 > URL: https://issues.apache.org/jira/browse/MRESOLVER-434 > Project: Maven Resolver > Issue Type: Dependency upgrade > Components: Resolver >Reporter: Slawomir Jaranowski >Assignee: Slawomir Jaranowski >Priority: Major > Fix For: 2.0.0, 1.9.17 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MRESOLVER-435) Refresh download page
[ https://issues.apache.org/jira/browse/MRESOLVER-435?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak updated MRESOLVER-435: -- Component/s: Resolver > Refresh download page > - > > Key: MRESOLVER-435 > URL: https://issues.apache.org/jira/browse/MRESOLVER-435 > Project: Maven Resolver > Issue Type: Task > Components: Resolver >Reporter: Slawomir Jaranowski >Priority: Major > Fix For: 2.0.0, 1.9.17 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: [PR] [MRESOLVER-434] Upgrade Parent to 41 [maven-resolver]
slawekjaranowski merged PR #368: URL: https://github.com/apache/maven-resolver/pull/368 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MNG-7920) Usage of packaging BOM fails in maven-install-plugin
[
https://issues.apache.org/jira/browse/MNG-7920?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17787385#comment-17787385
]
Karl Heinz Marbaise commented on MNG-7920:
--
So after diving a bit deeper into this... it looks like the resulting
{{pom.xml}} should be made the main artifact of the {{bom}} packaged project
because in the end it's the main artifact of the module. For example if we have
a normal pom packaged module it works the same. The {{maven-install-plugin}}
already WARNs exactly about that. Furthermore is my opinion that the
{{maven-install-plugin}} should not needed to be changed because the main
artifact is the resulting {{pom}}.
So the core should assign the interpolated (bom) as the main artifact
(packaging: pom) while the {{pom-build}} is already attached as classifier
based artifacts.
I created a full reproducer to look more in detail on the problems:
Lets start with the {{bom}} packaging module which contains the following
(original pom):
{code:xml}
maven.four.bug.7920
bom-example
bom
bom
Maven Bug :: 7920 :: BOM
maven.four.bug.7920
mod-1
maven.four.bug.7920
mod-2
..
{code}
So the above {{pom.xml}} is converted into {{pom}} packaging based
{{pom.xml}}.. it looks like this:
{code:xml}
http://maven.apache.org/POM/4.0.0";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
https://maven.apache.org/xsd/maven-4.0.0.xsd";>
4.0.0
maven.four.bug.7920
bom
1.0.0-SNAPSHOT
pom
Maven Bug :: 7920 :: BOM
maven.four.bug.7920
mod-1
maven.four.bug.7920
mod-2
org.junit.jupiter
junit-jupiter
5.10.1
org.assertj
assertj-core
3.24.2
org.assertj
assertj-guava
3.24.2
...
{code}
The list of issues I found from my point of view:
# So the first issue I can identify is that the integrated artifacts:
{code:xml}
maven.four.bug.7920
mod-1
maven.four.bug.7920
mod-2
{code}
do not contain a version number.
# The second issue I can identify is that it contains all bom's resolved which
are from the module parent (see junit-jupiter, assertj, mockito), but **not**
the test scoped dependencies of the {{mod-1}} (added a dependency to
{{junit:junit:4.13.2}} and a non test scoped dependency
{{commons-collections:commons-collections:3.2.2}.
>From my point of view the resulting {{pom.xml}} should look like this:
{code:xml}
http://maven.apache.org/POM/4.0.0";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
https://maven.apache.org/xsd/maven-4.0.0.xsd";>
4.0.0
maven.four.bug.7920
bom
1.0.0-SNAPSHOT
pom
Maven Bug :: 7920 :: BOM
maven.four.bug.7920
mod-1
1.0.0-SNAPSHOT
maven.four.bug.7920
mod-2
1.0.0-SNAPSHOT
{code}
It should contain things like: URL, name, organization, developers, licenses,
issueManagement, ciManagement(no),distributionManagement(no), repositories (no)
The link to the full repoducer:
https://github.com/khmarbaise/maven-bugs/tree/master/MNG-7920
> Usage of packaging BOM fails in maven-install-plugin
>
>
> Key: MNG-7920
> URL: https://issues.apache.org/jira/browse/MNG-7920
> Project: Maven
> Issue Type: Bug
> Components: Deployment
>Affects Versions: 4.0.0-alpha-8
>Reporter: Karl Heinz Marbaise
>Priority: Critical
> Fix For: 4.0.0, 4.0.0-alpha-9
>
>
> Using to use the `bom` packaging in a module it will fail with:
> {code}
> [INFO]
> --
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-install-plugin:3.1.1:install (default-install)
> on project bom: The packaging plugin for this project did not assign a main
> file to the project but it has attachments. Change packaging to 'pom'. ->
> [Help 1]
> {code}
> The bom module looks like this:
> {code:xml}
>xmlns="http://maven.apache.org/POM/4.1.0";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
> xsi:schemaLocation="http://maven.apache.org/POM/4.1.0
> http://maven.apache.org/maven-v4_1_0.xsd";>
> 4.1.0
>
> maven4
> bom-example
>
> bom
> bom
>
>
>
> ...maven4
> mod-1
>
>
> maven4
> mod-2
>
>
>
>
> {code}
> I would assume that I need to upgrade the
[jira] [Closed] (MNGSITE-527) broken link to settings-1.3.0.xsd
[
https://issues.apache.org/jira/browse/MNGSITE-527?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Guillaume Nodet closed MNGSITE-527.
---
Assignee: Guillaume Nodet
Resolution: Fixed
> broken link to settings-1.3.0.xsd
> -
>
> Key: MNGSITE-527
> URL: https://issues.apache.org/jira/browse/MNGSITE-527
> Project: Maven Project Web Site
> Issue Type: Bug
>Reporter: Filipe Roque
>Assignee: Guillaume Nodet
>Priority: Major
>
> The url of the XSD mentioned in the settings.xml settings tag is broken in
> Maven 4
> {code:java}
> http://maven.apache.org/SETTINGS/1.3.0";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
> xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.3.0
> https://maven.apache.org/xsd/settings-1.3.0.xsd";> {code}
> Both the settings.xml found at apache-maven-4.0.0-alpha-8/conf/settings.xml
> and at https://maven.apache.org/ref/4-LATEST/maven-settings/settings.html
> reference a broken url.
> There are older Versions at [http://maven.apache.org/xsd/].
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MNGSITE-527) broken link to settings-1.3.0.xsd
[
https://issues.apache.org/jira/browse/MNGSITE-527?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17787378#comment-17787378
]
ASF GitHub Bot commented on MNGSITE-527:
gnodet merged PR #464:
URL: https://github.com/apache/maven-site/pull/464
> broken link to settings-1.3.0.xsd
> -
>
> Key: MNGSITE-527
> URL: https://issues.apache.org/jira/browse/MNGSITE-527
> Project: Maven Project Web Site
> Issue Type: Bug
>Reporter: Filipe Roque
>Priority: Major
>
> The url of the XSD mentioned in the settings.xml settings tag is broken in
> Maven 4
> {code:java}
> http://maven.apache.org/SETTINGS/1.3.0";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
> xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.3.0
> https://maven.apache.org/xsd/settings-1.3.0.xsd";> {code}
> Both the settings.xml found at apache-maven-4.0.0-alpha-8/conf/settings.xml
> and at https://maven.apache.org/ref/4-LATEST/maven-settings/settings.html
> reference a broken url.
> There are older Versions at [http://maven.apache.org/xsd/].
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [PR] MNGSITE-527 broken link to settings-1.3.0.xsd [maven-site]
gnodet merged PR #464: URL: https://github.com/apache/maven-site/pull/464 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MRESOLVER-434) Upgrade Parent to 41
[ https://issues.apache.org/jira/browse/MRESOLVER-434?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17787374#comment-17787374 ] ASF GitHub Bot commented on MRESOLVER-434: -- slawekjaranowski opened a new pull request, #369: URL: https://github.com/apache/maven-resolver/pull/369 (no comment) > Upgrade Parent to 41 > > > Key: MRESOLVER-434 > URL: https://issues.apache.org/jira/browse/MRESOLVER-434 > Project: Maven Resolver > Issue Type: Dependency upgrade >Reporter: Slawomir Jaranowski >Priority: Major > Fix For: 2.0.0, 1.9.17 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MRESOLVER-434) Upgrade Parent to 41
[ https://issues.apache.org/jira/browse/MRESOLVER-434?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17787366#comment-17787366 ] ASF GitHub Bot commented on MRESOLVER-434: -- slawekjaranowski opened a new pull request, #368: URL: https://github.com/apache/maven-resolver/pull/368 (no comment) > Upgrade Parent to 41 > > > Key: MRESOLVER-434 > URL: https://issues.apache.org/jira/browse/MRESOLVER-434 > Project: Maven Resolver > Issue Type: Dependency upgrade >Reporter: Slawomir Jaranowski >Priority: Major > Fix For: 2.0.0, 1.9.17 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (MNG-7923) Jenkins core does not compile with Maven 4.x
[
https://issues.apache.org/jira/browse/MNG-7923?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17787249#comment-17787249
]
Guillaume Nodet edited comment on MNG-7923 at 11/17/23 6:30 PM:
The CIFriendly feature is broken on Maven 4 since the introduction of the
build/consumer POM feature. The reason is that the interpolation is now done
before assembling the hierarchy when computing the effective POM. So in Maven
4, POMs are loaded, interpolated, then merged. So the ci-friendly properties
which are defined in the parent pom are not available at the time the child is
being loaded.
In Maven 3, this is working, but the parent happens to be loaded with an
un-interpolated version. It kinda works because the model builder tried to
find the parent with a version of {{${revision}${changelist}}} and actually
founds one in the parent folder.
I'd suggest to stick to the tested scenarios, which is to define the
CI-friendly versions externally using system properties that can be defined in
{{.mvn/maven.config}} using:
{code}
-Drevision=2.433
-Dchangelist=-SNAPSHOT
{code}
was (Author: gnt):
The CIFriendly feature is broken on both Maven 4 since the introduction of the
build/consumer POM feature. The reason is that the interpolation is now done
before assembling the hierarchy when computing the effective POM. So in Maven
4, POMs are loaded, interpolated, then merged. So the ci-friendly properties
which are defined in the parent pom are not available at the time the child is
being loaded.
In Maven 3, this is working, but the parent happens to be loaded with an
un-interpolated version. It kinda works because the model builder tried to
find the parent with a version of {{${revision}${changelist}}} and actually
founds one in the parent folder.
I'd suggest to stick to the tested scenarios, which is to define the
CI-friendly versions externally using system properties that can be defined in
{{.mvn/maven.config}} using:
{code}
-Drevision=2.433
-Dchangelist=-SNAPSHOT
{code}
> Jenkins core does not compile with Maven 4.x
>
>
> Key: MNG-7923
> URL: https://issues.apache.org/jira/browse/MNG-7923
> Project: Maven
> Issue Type: Bug
> Components: Core
>Affects Versions: 4.0.0-alpha-2, 4.0.0-alpha-8
>Reporter: Basil Crow
>Priority: Major
>
> Try running {{git clone https://github.com/jenkinsci/jenkins.git && cd
> jenkins && mvn verify -Pquick-build}}. On the latest version of Maven 3.x, it
> works; on the latest Maven 4.x alpha, the build fails immediately with
> "Non-resolvable import POM: The following artifacts could not be resolved".
> If we need to make changes to our POM, then please point me to the
> documentation; otherwise, please fix the bug and let me know which release of
> Maven 4.x alpha I can test with the bug fixed. I bisected the failure to
> MNG-6656 /
> https://github.com/apache/maven/commit/bdec668de9c600165bb69c95b6ea0625d9f74fb0
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MNG-7854) Imported entries that are ignored should be emitted as warning
[ https://issues.apache.org/jira/browse/MNG-7854?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17787302#comment-17787302 ] ASF GitHub Bot commented on MNG-7854: - cstamas commented on PR #1211: URL: https://github.com/apache/maven/pull/1211#issuecomment-1816745193 Well, here is a counter example: I have no **conflicting imports** as I import just one: ``` 4.0.0 org.cstamas test 1.0.0 jar com.google.cloud libraries-bom 26.9.0 pom import ``` and with this PR it produces all these warnings: https://gist.github.com/cstamas/110351c2eeb6b56b8ceee9818be65872 Basically this one single BOM is "self conflicting". What now? > Imported entries that are ignored should be emitted as warning > -- > > Key: MNG-7854 > URL: https://issues.apache.org/jira/browse/MNG-7854 > Project: Maven > Issue Type: Improvement > Components: POM >Reporter: Tamas Cservenak >Priority: Major > > See https://github.com/cstamas/MNG-7852 for reproducer. -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: [PR] [MNG-7854] Warn if imported depMgt is ignored as it already exists [maven]
cstamas commented on PR #1211: URL: https://github.com/apache/maven/pull/1211#issuecomment-1816745193 Well, here is a counter example: I have no **conflicting imports** as I import just one: ``` 4.0.0 org.cstamas test 1.0.0 jar com.google.cloud libraries-bom 26.9.0 pom import ``` and with this PR it produces all these warnings: https://gist.github.com/cstamas/110351c2eeb6b56b8ceee9818be65872 Basically this one single BOM is "self conflicting". What now? -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MNG-7848) Add s390x pipeline to Jenkins CI
[ https://issues.apache.org/jira/browse/MNG-7848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17787288#comment-17787288 ] ASF GitHub Bot commented on MNG-7848: - vivkong commented on PR #1266: URL: https://github.com/apache/maven/pull/1266#issuecomment-1816708237 HI @olamy, Thanks for your help! I will create a PR to upgrade the JDK and fix the s390x build. > Add s390x pipeline to Jenkins CI > > > Key: MNG-7848 > URL: https://issues.apache.org/jira/browse/MNG-7848 > Project: Maven > Issue Type: New Feature > Components: Bootstrap & Build, Integration Tests >Reporter: Kun Lu >Priority: Major > Labels: pull-request-available > > Apache INFRA team has installed necessary JDK flavours on all s390x nodes > (Please check issue > [https://issues.apache.org/jira/projects/INFRA/issues/INFRA-24781]). We’d > like to add the s390x pipeline to Jenkins CI by raising a PR to add ` > Jenkinsfile.s390x` to the Maven code base. > Can anyone from Maven team help us review the PR and create the s390x > pipeline on Jenkins? Thanks! -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: [PR] [MNG-7848] Add Jenkinsfile.s390x for Jenkins CI on s390x [maven]
vivkong commented on PR #1266: URL: https://github.com/apache/maven/pull/1266#issuecomment-1816708237 HI @olamy, Thanks for your help! I will create a PR to upgrade the JDK and fix the s390x build. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MNG-7854) Imported entries that are ignored should be emitted as warning
[ https://issues.apache.org/jira/browse/MNG-7854?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17787284#comment-17787284 ] ASF GitHub Bot commented on MNG-7854: - gnodet commented on PR #1211: URL: https://github.com/apache/maven/pull/1211#issuecomment-1816684817 The idea looks good to me. There's one additional use case that needs to be handled though is the following. Let's say one or two BOMs are imported with a conflicting dependency. Maven would print a warning that the second managed dependency is ignored. The warning should include a way to fix the problem, which is to add an explicit managed dependency before importing the BOMs. Once that's done, the build should not emit a warning anymore imho, as warning with no way to fix is a bad idea. So I think the warning should happen only if no explicit (first level) managed dependency is registered yet. This should be the case if the BOM is imported before the managed dep, or if there's a conflict with two BOMs. > Imported entries that are ignored should be emitted as warning > -- > > Key: MNG-7854 > URL: https://issues.apache.org/jira/browse/MNG-7854 > Project: Maven > Issue Type: Improvement > Components: POM >Reporter: Tamas Cservenak >Priority: Major > > See https://github.com/cstamas/MNG-7852 for reproducer. -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: [PR] [MNG-7854] Warn if imported depMgt is ignored as it already exists [maven]
gnodet commented on PR #1211: URL: https://github.com/apache/maven/pull/1211#issuecomment-1816684817 The idea looks good to me. There's one additional use case that needs to be handled though is the following. Let's say one or two BOMs are imported with a conflicting dependency. Maven would print a warning that the second managed dependency is ignored. The warning should include a way to fix the problem, which is to add an explicit managed dependency before importing the BOMs. Once that's done, the build should not emit a warning anymore imho, as warning with no way to fix is a bad idea. So I think the warning should happen only if no explicit (first level) managed dependency is registered yet. This should be the case if the BOM is imported before the managed dep, or if there's a conflict with two BOMs. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: [PR] Add some love to the API [maven]
gnodet merged PR #1310: URL: https://github.com/apache/maven/pull/1310 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: [PR] Remove reference to plexus XmlStreamReader [maven]
gnodet merged PR #1308: URL: https://github.com/apache/maven/pull/1308 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: [PR] Fix XML parsing problem with empty namespace [maven]
gnodet merged PR #1307: URL: https://github.com/apache/maven/pull/1307 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (SUREFIRE-2211) additionalClasspathElement with UNC path not working with failsafe > 3.0.0-M1
[
https://issues.apache.org/jira/browse/SUREFIRE-2211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17787281#comment-17787281
]
Robert Seidel commented on SUREFIRE-2211:
-
So an easy fix would be to add these lines to toAbsoluteUri:
// unc paths needs to be written as file:
if ( absolutePath.toString().startsWith( "" )) {
return absolutePath.toFile().toURI().toASCIIString();
}
I'll try to provide a PR with tests at the beginning of next week.
> additionalClasspathElement with UNC path not working with failsafe > 3.0.0-M1
> -
>
> Key: SUREFIRE-2211
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2211
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Failsafe Plugin
>Affects Versions: 3.0.0-M2, 3.2.2
> Environment: Windows JDK17.0.5+8
>Reporter: Robert Seidel
>Priority: Major
>
> We are using the configuration parameter additionalClasspathElements
> (https://maven.apache.org/surefire/maven-failsafe-plugin/integration-test-mojo.html#additionalClasspathElements)
> to provide a log4j2 xml configuration during tests. There is configured an
> UNC path like this //our-server/build/failsafe containing the file.
> Until version 3.0.0-M2 everything was fine, the ressource could be found
> within the class loader and log4j was configured correctly (so 3.0.0-M1 was
> ok).
> However since the Milestone 2 of version 3 and with all later versions, the
> ressource could not be found within the classpath, leaving log4j unconfigured.
> From the reporting xml the classpath is configured the same, but the class
> loader behaves differently.
> When using a normal path like c:/build/failsafe the ressource can be found
> without issues.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [PR] Remove usage of old StringTokenizer [maven]
gnodet merged PR #1306: URL: https://github.com/apache/maven/pull/1306 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: [PR] Clean up dependencies versions [maven]
gnodet merged PR #1300: URL: https://github.com/apache/maven/pull/1300 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MNG-7906) Dependency Management import does not work the "maven way"
[
https://issues.apache.org/jira/browse/MNG-7906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17787263#comment-17787263
]
Guillaume Nodet commented on MNG-7906:
--
While MPH-183 could be a way to investigate the problem, not reporting anything
is plainly and simply wrong.
Let's take a simple use case:
* in your project, you see a wrong version of a dependency being imported
* you add a {{}} section in your {{dependencyManagement}} POM
section, usually at the end
* you rebuild, but the wrong version is still used
* you raise a JIRA after having spent hours to investigate the problem with
no solution
So I think the first step would be to add a WARNING when the POM _being built_
contains a managed dependency which is _lost_ because not first.
This will explain to the user what's wrong and that the dependency should be
moved up at the top of the managed dependency section in order to be useful.
That should be easily done and back ported to 3.9.x.
The behaviour could then be changed in 4.x with or without a toggle flag for
compatibility.
But definitely, the first step should be to WARN the user that there's a
problem.
> Dependency Management import does not work the "maven way"
> --
>
> Key: MNG-7906
> URL: https://issues.apache.org/jira/browse/MNG-7906
> Project: Maven
> Issue Type: Bug
> Components: Dependencies, Documentation: General
>Reporter: Tamas Cservenak
>Priority: Major
> Fix For: 4.0.x-candidate
>
>
> This affects all released Maven versions so far.
> Problem reproducer: https://github.com/cstamas/MNG-7852 (repo name is wrong,
> obviously).
> In short: unlike with dependencies, where you CAN override some "deep
> transitive" dependency by re-declaring it directly as 1st level dependency in
> POM, for depMgt import this does not work, actually, it works quite the
> opposite ("first comes, wins"). Moreover, Maven remains silent about this, as
> reproducer shows, and all of this goes unnoticed.
> Solution: at least depMgt import should make "the maven way", maybe not by
> default (to not break existing builds) but configurable. Problem is solved if
> in reproducer:
> - with fix enabled, junit 5.9.3 is used, AND
> - with fix disabled, Maven yells about ignored depMgt import
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [PR] Plugin API [maven]
cstamas commented on PR #1309: URL: https://github.com/apache/maven/pull/1309#issuecomment-1816623196 @mcculls please chime in -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Updated] (MNG-7923) Jenkins core does not compile with Maven 4.x
[
https://issues.apache.org/jira/browse/MNG-7923?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Guillaume Nodet updated MNG-7923:
-
Affects Version/s: 4.0.0-alpha-2
> Jenkins core does not compile with Maven 4.x
>
>
> Key: MNG-7923
> URL: https://issues.apache.org/jira/browse/MNG-7923
> Project: Maven
> Issue Type: Bug
> Components: Core
>Affects Versions: 4.0.0-alpha-2, 4.0.0-alpha-8
>Reporter: Basil Crow
>Priority: Major
>
> Try running {{git clone https://github.com/jenkinsci/jenkins.git && cd
> jenkins && mvn verify -Pquick-build}}. On the latest version of Maven 3.x, it
> works; on the latest Maven 4.x alpha, the build fails immediately with
> "Non-resolvable import POM: The following artifacts could not be resolved".
> If we need to make changes to our POM, then please point me to the
> documentation; otherwise, please fix the bug and let me know which release of
> Maven 4.x alpha I can test with the bug fixed. I bisected the failure to
> MNG-6656 /
> https://github.com/apache/maven/commit/bdec668de9c600165bb69c95b6ea0625d9f74fb0
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (MNG-7923) Jenkins core does not compile with Maven 4.x
[
https://issues.apache.org/jira/browse/MNG-7923?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17787249#comment-17787249
]
Guillaume Nodet edited comment on MNG-7923 at 11/17/23 3:07 PM:
The CIFriendly feature is broken on both Maven 4 since the introduction of the
build/consumer POM feature. The reason is that the interpolation is now done
before assembling the hierarchy when computing the effective POM. So in Maven
4, POMs are loaded, interpolated, then merged. So the ci-friendly properties
which are defined in the parent pom are not available at the time the child is
being loaded.
In Maven 3, this is working, but the parent happens to be loaded with an
un-interpolated version. It kinda works because the model builder tried to
find the parent with a version of {{${revision}${changelist}}} and actually
founds one in the parent folder.
I'd suggest to stick to the tested scenarios, which is to define the
CI-friendly versions externally using system properties that can be defined in
{{.mvn/maven.config}} using:
{code}
-Drevision=2.433
-Dchangelist=-SNAPSHOT
{code}
was (Author: gnt):
Ok, the CIFriendly feature is broken on both Maven 4 since the introduction of
the build/consumer POM feature.
The reason is that the interpolation is now done before assembling the
hierarchy when computing the effective POM.
So in maven 4, POM are loaded, interpolated, then merged. So the ci-friendly
properties which are defined in the parent pom are not available when loading
the child yet.
In Maven 3, this is working, but the parent happens to be loaded with an
un-interpolated version. It kinda works because the model builder tried to
find the parent with a version of {{${revision}${changelist}}} and actually
founds one in the parent folder.
I'd suggest to stick to the tested scenarios, which is to define the
CI-friendly versions externally using system properties that can be defined in
{{.mvn/maven.config}} using:
{code}
-Drevision=2.433
-Dchangelist=-SNAPSHOT
{code}
> Jenkins core does not compile with Maven 4.x
>
>
> Key: MNG-7923
> URL: https://issues.apache.org/jira/browse/MNG-7923
> Project: Maven
> Issue Type: Bug
> Components: Core
>Affects Versions: 4.0.0-alpha-8
>Reporter: Basil Crow
>Priority: Major
>
> Try running {{git clone https://github.com/jenkinsci/jenkins.git && cd
> jenkins && mvn verify -Pquick-build}}. On the latest version of Maven 3.x, it
> works; on the latest Maven 4.x alpha, the build fails immediately with
> "Non-resolvable import POM: The following artifacts could not be resolved".
> If we need to make changes to our POM, then please point me to the
> documentation; otherwise, please fix the bug and let me know which release of
> Maven 4.x alpha I can test with the bug fixed. I bisected the failure to
> MNG-6656 /
> https://github.com/apache/maven/commit/bdec668de9c600165bb69c95b6ea0625d9f74fb0
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (SUREFIRE-2211) additionalClasspathElement with UNC path not working with failsafe > 3.0.0-M1
[
https://issues.apache.org/jira/browse/SUREFIRE-2211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17787251#comment-17787251
]
Robert Seidel edited comment on SUREFIRE-2211 at 11/17/23 3:07 PM:
---
The root cause is
https://github.com/apache/maven-surefire/commit/f5cca5bcc2c85060c21c82eea0081d016cb86909#diff-831c3693e03bf74af278a55df4af2ce453b674930f1932b4f7334b2417cbb595R157
.
Paths.get("c:\\test").toUri().toASCIISTRING() results file:///c:/test
But Paths.get("test\\path").toUri().toASCIIString() results
file://test/path/ which is fine for the usage in an url, but not for the
classpath attribute in the manifest of a jar file, therefor it should be
file:test/path/.
was (Author: JIRAUSER295788):
The root cause is
https://github.com/apache/maven-surefire/commit/f5cca5bcc2c85060c21c82eea0081d016cb86909#diff-831c3693e03bf74af278a55df4af2ce453b674930f1932b4f7334b2417cbb595R157
.
Paths.get("c:\\test").toUri().toASCIISTRING() results file:///c:/test
But Paths.get("test\\path").toUri().toASCIIString() results
file://test/path/ which is fine for the usage in an url, but not for the
classpath attribute in the manifest of a jar file.
> additionalClasspathElement with UNC path not working with failsafe > 3.0.0-M1
> -
>
> Key: SUREFIRE-2211
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2211
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Failsafe Plugin
>Affects Versions: 3.0.0-M2, 3.2.2
> Environment: Windows JDK17.0.5+8
>Reporter: Robert Seidel
>Priority: Major
>
> We are using the configuration parameter additionalClasspathElements
> (https://maven.apache.org/surefire/maven-failsafe-plugin/integration-test-mojo.html#additionalClasspathElements)
> to provide a log4j2 xml configuration during tests. There is configured an
> UNC path like this //our-server/build/failsafe containing the file.
> Until version 3.0.0-M2 everything was fine, the ressource could be found
> within the class loader and log4j was configured correctly (so 3.0.0-M1 was
> ok).
> However since the Milestone 2 of version 3 and with all later versions, the
> ressource could not be found within the classpath, leaving log4j unconfigured.
> From the reporting xml the classpath is configured the same, but the class
> loader behaves differently.
> When using a normal path like c:/build/failsafe the ressource can be found
> without issues.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (SUREFIRE-2211) additionalClasspathElement with UNC path not working with failsafe > 3.0.0-M1
[
https://issues.apache.org/jira/browse/SUREFIRE-2211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17787251#comment-17787251
]
Robert Seidel commented on SUREFIRE-2211:
-
The root cause is
https://github.com/apache/maven-surefire/commit/f5cca5bcc2c85060c21c82eea0081d016cb86909#diff-831c3693e03bf74af278a55df4af2ce453b674930f1932b4f7334b2417cbb595R157
.
Paths.get("c:\\test").toUri().toASCIISTRING() results file:///c:/test
But Paths.get("test\\path").toUri().toASCIIString() results
file://test/path/ which is fine for the usage in an url, but not for the
classpath attribute in the manifest of a jar file.
> additionalClasspathElement with UNC path not working with failsafe > 3.0.0-M1
> -
>
> Key: SUREFIRE-2211
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2211
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Failsafe Plugin
>Affects Versions: 3.0.0-M2, 3.2.2
> Environment: Windows JDK17.0.5+8
>Reporter: Robert Seidel
>Priority: Major
>
> We are using the configuration parameter additionalClasspathElements
> (https://maven.apache.org/surefire/maven-failsafe-plugin/integration-test-mojo.html#additionalClasspathElements)
> to provide a log4j2 xml configuration during tests. There is configured an
> UNC path like this //our-server/build/failsafe containing the file.
> Until version 3.0.0-M2 everything was fine, the ressource could be found
> within the class loader and log4j was configured correctly (so 3.0.0-M1 was
> ok).
> However since the Milestone 2 of version 3 and with all later versions, the
> ressource could not be found within the classpath, leaving log4j unconfigured.
> From the reporting xml the classpath is configured the same, but the class
> loader behaves differently.
> When using a normal path like c:/build/failsafe the ressource can be found
> without issues.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MNG-7923) Jenkins core does not compile with Maven 4.x
[
https://issues.apache.org/jira/browse/MNG-7923?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17787249#comment-17787249
]
Guillaume Nodet commented on MNG-7923:
--
Ok, the CIFriendly feature is broken on both Maven 4 since the introduction of
the build/consumer POM feature.
The reason is that the interpolation is now done before assembling the
hierarchy when computing the effective POM.
So in maven 4, POM are loaded, interpolated, then merged. So the ci-friendly
properties which are defined in the parent pom are not available when loading
the child yet.
In Maven 3, this is working, but the parent happens to be loaded with an
un-interpolated version. It kinda works because the model builder tried to
find the parent with a version of {{${revision}${changelist}}} and actually
founds one in the parent folder.
I'd suggest to stick to the tested scenarios, which is to define the
CI-friendly versions externally using system properties that can be defined in
{{.mvn/maven.config}} using:
{code}
-Drevision=2.433
-Dchangelist=-SNAPSHOT
{code}
> Jenkins core does not compile with Maven 4.x
>
>
> Key: MNG-7923
> URL: https://issues.apache.org/jira/browse/MNG-7923
> Project: Maven
> Issue Type: Bug
> Components: Core
>Affects Versions: 4.0.0-alpha-8
>Reporter: Basil Crow
>Priority: Major
>
> Try running {{git clone https://github.com/jenkinsci/jenkins.git && cd
> jenkins && mvn verify -Pquick-build}}. On the latest version of Maven 3.x, it
> works; on the latest Maven 4.x alpha, the build fails immediately with
> "Non-resolvable import POM: The following artifacts could not be resolved".
> If we need to make changes to our POM, then please point me to the
> documentation; otherwise, please fix the bug and let me know which release of
> Maven 4.x alpha I can test with the bug fixed. I bisected the failure to
> MNG-6656 /
> https://github.com/apache/maven/commit/bdec668de9c600165bb69c95b6ea0625d9f74fb0
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MNG-7923) Jenkins core does not compile with Maven 4.x
[
https://issues.apache.org/jira/browse/MNG-7923?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17787250#comment-17787250
]
ASF GitHub Bot commented on MNG-7923:
-
gnodet closed pull request #1311: [MNG-7923] Fix CI friendly version to look
for properties in the pom
URL: https://github.com/apache/maven/pull/1311
> Jenkins core does not compile with Maven 4.x
>
>
> Key: MNG-7923
> URL: https://issues.apache.org/jira/browse/MNG-7923
> Project: Maven
> Issue Type: Bug
> Components: Core
>Affects Versions: 4.0.0-alpha-8
>Reporter: Basil Crow
>Priority: Major
>
> Try running {{git clone https://github.com/jenkinsci/jenkins.git && cd
> jenkins && mvn verify -Pquick-build}}. On the latest version of Maven 3.x, it
> works; on the latest Maven 4.x alpha, the build fails immediately with
> "Non-resolvable import POM: The following artifacts could not be resolved".
> If we need to make changes to our POM, then please point me to the
> documentation; otherwise, please fix the bug and let me know which release of
> Maven 4.x alpha I can test with the bug fixed. I bisected the failure to
> MNG-6656 /
> https://github.com/apache/maven/commit/bdec668de9c600165bb69c95b6ea0625d9f74fb0
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [PR] [MNG-7923] Fix CI friendly version to look for properties in the pom [maven]
gnodet closed pull request #1311: [MNG-7923] Fix CI friendly version to look for properties in the pom URL: https://github.com/apache/maven/pull/1311 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MCOMPILER-542) clean JDK patch version in module-info.class
[ https://issues.apache.org/jira/browse/MCOMPILER-542?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17787248#comment-17787248 ] ASF GitHub Bot commented on MCOMPILER-542: -- jorsol commented on PR #208: URL: https://github.com/apache/maven-compiler-plugin/pull/208#issuecomment-1816587092 Any feedback on this? > clean JDK patch version in module-info.class > > > Key: MCOMPILER-542 > URL: https://issues.apache.org/jira/browse/MCOMPILER-542 > Project: Maven Compiler Plugin > Issue Type: Improvement >Affects Versions: 3.11.0 >Reporter: Herve Boutemy >Priority: Major > > as seen in MJAR-275, JDK patch version in module-info.class is not included > only when building with a newer JDK release using "--release" flag, see > https://github.com/jvm-repo-rebuild/module-info > we need an issue in JDK to get a proper fix > and waiting for. that, we need a workaround to drop the JDK patch version in > other cases: we'll need to define were is the best place -- > m-jar-p?m-compiler-p? other? -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: [PR] [MCOMPILER-542] Clean JDK patch version in module-info.class [maven-compiler-plugin]
jorsol commented on PR #208: URL: https://github.com/apache/maven-compiler-plugin/pull/208#issuecomment-1816587092 Any feedback on this? -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Comment Edited] (SUREFIRE-1695) Support multiple inheritance of @Categories
[
https://issues.apache.org/jira/browse/SUREFIRE-1695?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17787169#comment-17787169
]
Christian Nüssgens edited comment on SUREFIRE-1695 at 11/17/23 2:42 PM:
I'm currently wondering:
We relied on this fact and now (after upgrading finally to surefire >= 3.0.0)
our tests are not working as expected anymore.
We used this to _override_ Categories of Test-Classes.
Furthermore the surefire-way of interpreting {{@Category}} is not reflecting
the behavior of the JUnit 4.12 Categories runner.
Assume the following Test Classes
{code:java}
@Category(CategoryA.class)
public abstract class AbstractTest {
}
public class TestA extends AbstractTest {
@Test
public void testIt() throws Exception {
//do test
}
}
@Category(CategoryPlayground.class)
public class PlaygroundTestA extends TestA {
@Test
public void testIt() throws Exception {
// do nasty stuff like while(true)
}
}
{code}
The built-in categories Runner behaves as follows
{code:java}
@RunWith(Categories.class)
@IncludeCategory({CategoryA.class})
@SuiteClasses({TestA.class, PlaygroundTestA.class})
public class TheSuite {
}
{code}
If run: only {{TestA}} is executed. The "closest" Categories declaration wins,
although the Categories-annotation itself is "inheritable".
Surefire does behave differently:
{code:xml}
CategoryA
{code}
If run ({{mvn test}}) surefire will execute {{TestA}} and {{PlaygroundTestA}}
(since surefire 3.0.0-M5)
Does one know what the majority expects here? In my opinion it is strange to
handle JUnit Categories different than JUnit itself does.
Is it possible to restore the "old" behavior?
Or maybe make it configurable.
*Edit:* FYI I created a dedicated Issue SUREFIRE-2213. I think no one will
read a new comment on such a old issue ;-)
was (Author: JIRAUSER288303):
I'm currently wondering:
We relied on this fact and now (after upgrading finally to surefire >= 3.0.0)
our tests are not working as expected anymore.
We used this to _override_ Categories of Test-Classes.
Furthermore the surefire-way of interpreting {{@Category}} is not reflecting
the behavior of the JUnit 4.12 Categories runner.
Assume the following Test Classes
{code:java}
@Category(CategoryA.class)
public abstract class AbstractTest {
}
public class TestA extends AbstractTest {
@Test
public void testIt() throws Exception {
//do test
}
}
@Category(CategoryPlayground.class)
public class PlaygroundTestA extends TestA {
@Test
public void testIt() throws Exception {
// do nasty stuff like while(true)
}
}
{code}
The built-in categories Runner behaves as follows
{code:java}
@RunWith(Categories.class)
@IncludeCategory({CategoryA.class})
@SuiteClasses({TestA.class, PlaygroundTestA.class})
public class TheSuite {
}
{code}
If run: only {{TestA}} is executed. The "closest" Categories declaration wins,
although the Categories-annotation itself is "inheritable".
Surefire does behave differently:
{code:xml}
CategoryA
{code}
If run ({{mvn test}}) surefire will execute {{TestA}} and {{PlaygroundTestA}}
(since surefire 3.0.0-M5)
Does one know what the majority expects here? In my opinion it is strange to
handle JUnit Categories different than JUnit itself does.
Is it possible to restore the "old" behavior?
Or maybe make it configurable.
*Edit:* FYI I created a dedicated Issue SUREFIRE-2213
> Support multiple inheritance of @Categories
> ---
>
> Key: SUREFIRE-1695
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1695
> Project: Maven Surefire
> Issue Type: Bug
> Components: Junit 4.7+ (parallel) support, Maven Surefire Plugin
>Affects Versions: 3.0.0-M3
>Reporter: Yiannis Dermitzakis
>Assignee: Tibor Digana
>Priority: Major
> Labels: pull-request-available
> Fix For: 3.0.0-M5
>
> Original Estimate: 0h
> Time Spent: 20m
> Remaining Estimate: 0h
>
> We are using JUnit Categories together with Surefire's /
> tags in a Test hierarchy. However we have observed some inconsistencies in
> the resolution.
> Example:
> * {{AbstractTest}} is tagged with {{@Category(CategoryB.class)}}
> * {{TestA extends AbstractTest}} and is tagged with
> {{@Category(CategoryA.class)}}
> * When running Surefire with {{CategoryB, TestA is not
> executed.
>
> There are a few more failure cases, written as (integration/unit) tests. I
> have provided a PR with a fix.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (SUREFIRE-2211) additionalClasspathElement with UNC path not working with failsafe > 3.0.0-M1
[ https://issues.apache.org/jira/browse/SUREFIRE-2211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17787233#comment-17787233 ] Robert Seidel commented on SUREFIRE-2211: - Mounting as a drive letter will probably be possible, the easier solution would be to copy the files to some local temp dir and add this to the classpath. In the meantime I did find out, what is done wrong: In the past \\our-server\build\failsafe from classpath was added as file:our-server/build/failsafe to the manifest of the surefirebooter jar. Now it looks like file://our-server/build/failsafe which would be correct as an url, but Java expects an URI there https://wiki.eclipse.org/Eclipse/UNC_Paths#java.net.URI. I'll debug further to find the root cause. > additionalClasspathElement with UNC path not working with failsafe > 3.0.0-M1 > - > > Key: SUREFIRE-2211 > URL: https://issues.apache.org/jira/browse/SUREFIRE-2211 > Project: Maven Surefire > Issue Type: Bug > Components: Maven Failsafe Plugin >Affects Versions: 3.0.0-M2, 3.2.2 > Environment: Windows JDK17.0.5+8 >Reporter: Robert Seidel >Priority: Major > > We are using the configuration parameter additionalClasspathElements > (https://maven.apache.org/surefire/maven-failsafe-plugin/integration-test-mojo.html#additionalClasspathElements) > to provide a log4j2 xml configuration during tests. There is configured an > UNC path like this //our-server/build/failsafe containing the file. > Until version 3.0.0-M2 everything was fine, the ressource could be found > within the class loader and log4j was configured correctly (so 3.0.0-M1 was > ok). > However since the Milestone 2 of version 3 and with all later versions, the > ressource could not be found within the classpath, leaving log4j unconfigured. > From the reporting xml the classpath is configured the same, but the class > loader behaves differently. > When using a normal path like c:/build/failsafe the ressource can be found > without issues. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (SUREFIRE-1695) Support multiple inheritance of @Categories
[
https://issues.apache.org/jira/browse/SUREFIRE-1695?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17787169#comment-17787169
]
Christian Nüssgens edited comment on SUREFIRE-1695 at 11/17/23 2:23 PM:
I'm currently wondering:
We relied on this fact and now (after upgrading finally to surefire >= 3.0.0)
our tests are not working as expected anymore.
We used this to _override_ Categories of Test-Classes.
Furthermore the surefire-way of interpreting {{@Category}} is not reflecting
the behavior of the JUnit 4.12 Categories runner.
Assume the following Test Classes
{code:java}
@Category(CategoryA.class)
public abstract class AbstractTest {
}
public class TestA extends AbstractTest {
@Test
public void testIt() throws Exception {
//do test
}
}
@Category(CategoryPlayground.class)
public class PlaygroundTestA extends TestA {
@Test
public void testIt() throws Exception {
// do nasty stuff like while(true)
}
}
{code}
The built-in categories Runner behaves as follows
{code:java}
@RunWith(Categories.class)
@IncludeCategory({CategoryA.class})
@SuiteClasses({TestA.class, PlaygroundTestA.class})
public class TheSuite {
}
{code}
If run: only {{TestA}} is executed. The "closest" Categories declaration wins,
although the Categories-annotation itself is "inheritable".
Surefire does behave differently:
{code:xml}
CategoryA
{code}
If run ({{mvn test}}) surefire will execute {{TestA}} and {{PlaygroundTestA}}
(since surefire 3.0.0-M5)
Does one know what the majority expects here? In my opinion it is strange to
handle JUnit Categories different than JUnit itself does.
Is it possible to restore the "old" behavior?
Or maybe make it configurable.
*Edit:* FYI I created a dedicated Issue SUREFIRE-2213
was (Author: JIRAUSER288303):
I'm currently wondering:
We relied on this fact and now (after upgrading finally to surefire >= 3.0.0)
our tests are not working as expected anymore.
We used this to _override_ Categories of Test-Classes.
Furthermore the surefire-way of interpreting {{@Category}} is not reflecting
the behavior of the JUnit 4.12 Categories runner.
Assume the following Test Classes
{code:java}
@Category(CategoryA.class)
public abstract class AbstractTest {
}
public class TestA extends AbstractTest {
@Test
public void testIt() throws Exception {
//do test
}
}
@Category(CategoryPlayground.class)
public class PlaygroundTestA extends TestA {
@Test
public void testIt() throws Exception {
// do nasty stuff like while(true)
}
}
{code}
The built-in categories Runner behaves as follows
{code:java}
@RunWith(Categories.class)
@IncludeCategory({CategoryA.class})
@SuiteClasses({TestA.class, PlaygroundTestA.class})
public class TheSuite {
}
{code}
If run: only {{TestA}} is executed. The "closest" Categories declaration wins,
although the Categories-annotation itself is "inheritable".
Surefire does behave differently:
{code:xml}
CategoryA
{code}
If run ({{mvn test}}) surefire will execute {{TestA}} and {{PlaygroundTestA}}
(since surefire 3.0.0-M5)
Does one know what the majority expects here? In my opinion it is strange to
handle JUnit Categories different than JUnit itself does.
Is it possible to restore the "old" behavior?
Or maybe make it configurable.
> Support multiple inheritance of @Categories
> ---
>
> Key: SUREFIRE-1695
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1695
> Project: Maven Surefire
> Issue Type: Bug
> Components: Junit 4.7+ (parallel) support, Maven Surefire Plugin
>Affects Versions: 3.0.0-M3
>Reporter: Yiannis Dermitzakis
>Assignee: Tibor Digana
>Priority: Major
> Labels: pull-request-available
> Fix For: 3.0.0-M5
>
> Original Estimate: 0h
> Time Spent: 20m
> Remaining Estimate: 0h
>
> We are using JUnit Categories together with Surefire's /
> tags in a Test hierarchy. However we have observed some inconsistencies in
> the resolution.
> Example:
> * {{AbstractTest}} is tagged with {{@Category(CategoryB.class)}}
> * {{TestA extends AbstractTest}} and is tagged with
> {{@Category(CategoryA.class)}}
> * When running Surefire with {{CategoryB, TestA is not
> executed.
>
> There are a few more failure cases, written as (integration/unit) tests. I
> have provided a PR with a fix.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (SUREFIRE-2213) @Categories (JUnit4) are handeld differnt than JUnit's built-in Categories-Runner
Christian Nüssgens created SUREFIRE-2213:
Summary: @Categories (JUnit4) are handeld differnt than JUnit's
built-in Categories-Runner
Key: SUREFIRE-2213
URL: https://issues.apache.org/jira/browse/SUREFIRE-2213
Project: Maven Surefire
Issue Type: Bug
Components: Junit 4.x support, Maven Surefire Plugin
Affects Versions: 3.2.2, 3.2.1, 3.1.2, 3.1.0, 3.0.0, 3.0.0-M9, 3.0.0-M8,
3.0.0-M7, 3.0.0-M6, 3.0.0-M5
Reporter: Christian Nüssgens
With SUREFIRE-1695 a change was introduced which modified the behavior how
{{}} and {{}} are handled.
Assume the following Test Classes
{code:java}
@Category(CategoryA.class)
public abstract class AbstractTest {
}
public class TestA extends AbstractTest {
@Test
public void testIt() throws Exception {
//do test
}
}
@Category(CategoryPlayground.class)
public class PlaygroundTestA extends TestA {
@Test
public void testIt() throws Exception {
// do nasty stuff like while(true)
}
}
{code}
The built-in categories Runner behaves as follows
{code:java}
@RunWith(Categories.class)
@IncludeCategory({CategoryA.class})
@SuiteClasses({TestA.class, PlaygroundTestA.class})
public class TheSuite {
}
{code}
If run: only {{TestA}} is executed. The "closest" Categories declaration wins,
although the Categories-annotation itself is "inheritable".
Surefire does behave differently:
{code:xml}
CategoryA
{code}
If run ({{mvn test}}) surefire will execute {{TestA}} and {{PlaygroundTestA}}
(since surefire 3.0.0-M5)
We were quite surprised that this behavior changed from surefire 2.x to 3.x and
is now not reflecting the way it is implemented in JUnit itself.
I'm currently not sure _who_ is already relying on the _new_ behavior.
Is it possible to restore the "old" behavior? Or would it be a convenient
approach to make it?configurable.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (SUREFIRE-2211) additionalClasspathElement with UNC path not working with failsafe > 3.0.0-M1
[ https://issues.apache.org/jira/browse/SUREFIRE-2211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17787182#comment-17787182 ] Michael Osipov commented on SUREFIRE-2211: -- Please raise your voice on the offending PRs... > additionalClasspathElement with UNC path not working with failsafe > 3.0.0-M1 > - > > Key: SUREFIRE-2211 > URL: https://issues.apache.org/jira/browse/SUREFIRE-2211 > Project: Maven Surefire > Issue Type: Bug > Components: Maven Failsafe Plugin >Affects Versions: 3.0.0-M2, 3.2.2 > Environment: Windows JDK17.0.5+8 >Reporter: Robert Seidel >Priority: Major > > We are using the configuration parameter additionalClasspathElements > (https://maven.apache.org/surefire/maven-failsafe-plugin/integration-test-mojo.html#additionalClasspathElements) > to provide a log4j2 xml configuration during tests. There is configured an > UNC path like this //our-server/build/failsafe containing the file. > Until version 3.0.0-M2 everything was fine, the ressource could be found > within the class loader and log4j was configured correctly (so 3.0.0-M1 was > ok). > However since the Milestone 2 of version 3 and with all later versions, the > ressource could not be found within the classpath, leaving log4j unconfigured. > From the reporting xml the classpath is configured the same, but the class > loader behaves differently. > When using a normal path like c:/build/failsafe the ressource can be found > without issues. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (SUREFIRE-2211) additionalClasspathElement with UNC path not working with failsafe > 3.0.0-M1
[ https://issues.apache.org/jira/browse/SUREFIRE-2211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17787183#comment-17787183 ] Michael Osipov commented on SUREFIRE-2211: -- In the meantime, is mounting as a drive letter possible? > additionalClasspathElement with UNC path not working with failsafe > 3.0.0-M1 > - > > Key: SUREFIRE-2211 > URL: https://issues.apache.org/jira/browse/SUREFIRE-2211 > Project: Maven Surefire > Issue Type: Bug > Components: Maven Failsafe Plugin >Affects Versions: 3.0.0-M2, 3.2.2 > Environment: Windows JDK17.0.5+8 >Reporter: Robert Seidel >Priority: Major > > We are using the configuration parameter additionalClasspathElements > (https://maven.apache.org/surefire/maven-failsafe-plugin/integration-test-mojo.html#additionalClasspathElements) > to provide a log4j2 xml configuration during tests. There is configured an > UNC path like this //our-server/build/failsafe containing the file. > Until version 3.0.0-M2 everything was fine, the ressource could be found > within the class loader and log4j was configured correctly (so 3.0.0-M1 was > ok). > However since the Milestone 2 of version 3 and with all later versions, the > ressource could not be found within the classpath, leaving log4j unconfigured. > From the reporting xml the classpath is configured the same, but the class > loader behaves differently. > When using a normal path like c:/build/failsafe the ressource can be found > without issues. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MNG-7906) Dependency Management import does not work the "maven way"
[
https://issues.apache.org/jira/browse/MNG-7906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17787178#comment-17787178
]
Elliotte Rusty Harold commented on MNG-7906:
Also, I'm very hesitant to introduce more flags and switches into Maven,
whether in pom.xml or the CLI. It's already overly complex and confusing.
> Dependency Management import does not work the "maven way"
> --
>
> Key: MNG-7906
> URL: https://issues.apache.org/jira/browse/MNG-7906
> Project: Maven
> Issue Type: Bug
> Components: Dependencies, Documentation: General
>Reporter: Tamas Cservenak
>Priority: Major
> Fix For: 4.0.x-candidate
>
>
> This affects all released Maven versions so far.
> Problem reproducer: https://github.com/cstamas/MNG-7852 (repo name is wrong,
> obviously).
> In short: unlike with dependencies, where you CAN override some "deep
> transitive" dependency by re-declaring it directly as 1st level dependency in
> POM, for depMgt import this does not work, actually, it works quite the
> opposite ("first comes, wins"). Moreover, Maven remains silent about this, as
> reproducer shows, and all of this goes unnoticed.
> Solution: at least depMgt import should make "the maven way", maybe not by
> default (to not break existing builds) but configurable. Problem is solved if
> in reproducer:
> - with fix enabled, junit 5.9.3 is used, AND
> - with fix disabled, Maven yells about ignored depMgt import
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (SUREFIRE-2211) additionalClasspathElement with UNC path not working with failsafe > 3.0.0-M1
[ https://issues.apache.org/jira/browse/SUREFIRE-2211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17787177#comment-17787177 ] Robert Seidel commented on SUREFIRE-2211: - I've removed the line, but it doesn't help. Maybe it has also something to do with other changes around there. > additionalClasspathElement with UNC path not working with failsafe > 3.0.0-M1 > - > > Key: SUREFIRE-2211 > URL: https://issues.apache.org/jira/browse/SUREFIRE-2211 > Project: Maven Surefire > Issue Type: Bug > Components: Maven Failsafe Plugin >Affects Versions: 3.0.0-M2, 3.2.2 > Environment: Windows JDK17.0.5+8 >Reporter: Robert Seidel >Priority: Major > > We are using the configuration parameter additionalClasspathElements > (https://maven.apache.org/surefire/maven-failsafe-plugin/integration-test-mojo.html#additionalClasspathElements) > to provide a log4j2 xml configuration during tests. There is configured an > UNC path like this //our-server/build/failsafe containing the file. > Until version 3.0.0-M2 everything was fine, the ressource could be found > within the class loader and log4j was configured correctly (so 3.0.0-M1 was > ok). > However since the Milestone 2 of version 3 and with all later versions, the > ressource could not be found within the classpath, leaving log4j unconfigured. > From the reporting xml the classpath is configured the same, but the class > loader behaves differently. > When using a normal path like c:/build/failsafe the ressource can be found > without issues. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MNG-7906) Dependency Management import does not work the "maven way"
[
https://issues.apache.org/jira/browse/MNG-7906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17787175#comment-17787175
]
Elliotte Rusty Harold commented on MNG-7906:
I went down this rabbit hole for 2+ years, and yes, it's confusing. However,
that ship has sailed. I don't see any realistic possibility to change the rules
now without breaking a large part of the existing Maven and Java ecosystem.
I've done a lot of work on improving the documentation of the admittedly weird
Maven dependency resolution rules, e.g. using the word "closer" without
defining that word in sufficient detail, but if there are places in the
official docs that are still confusing, feel free to file docs bugs and assign
them to me. Beyond that, I'm tempted to close this as Won't Fix.
> Dependency Management import does not work the "maven way"
> --
>
> Key: MNG-7906
> URL: https://issues.apache.org/jira/browse/MNG-7906
> Project: Maven
> Issue Type: Bug
> Components: Dependencies
>Reporter: Tamas Cservenak
>Priority: Blocker
> Fix For: 4.0.x-candidate
>
>
> This affects all released Maven versions so far.
> Problem reproducer: https://github.com/cstamas/MNG-7852 (repo name is wrong,
> obviously).
> In short: unlike with dependencies, where you CAN override some "deep
> transitive" dependency by re-declaring it directly as 1st level dependency in
> POM, for depMgt import this does not work, actually, it works quite the
> opposite ("first comes, wins"). Moreover, Maven remains silent about this, as
> reproducer shows, and all of this goes unnoticed.
> Solution: at least depMgt import should make "the maven way", maybe not by
> default (to not break existing builds) but configurable. Problem is solved if
> in reproducer:
> - with fix enabled, junit 5.9.3 is used, AND
> - with fix disabled, Maven yells about ignored depMgt import
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MNG-7906) Dependency Management import does not work the "maven way"
[
https://issues.apache.org/jira/browse/MNG-7906?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Elliotte Rusty Harold updated MNG-7906:
---
Component/s: Documentation: General
> Dependency Management import does not work the "maven way"
> --
>
> Key: MNG-7906
> URL: https://issues.apache.org/jira/browse/MNG-7906
> Project: Maven
> Issue Type: Bug
> Components: Dependencies, Documentation: General
>Reporter: Tamas Cservenak
>Priority: Major
> Fix For: 4.0.x-candidate
>
>
> This affects all released Maven versions so far.
> Problem reproducer: https://github.com/cstamas/MNG-7852 (repo name is wrong,
> obviously).
> In short: unlike with dependencies, where you CAN override some "deep
> transitive" dependency by re-declaring it directly as 1st level dependency in
> POM, for depMgt import this does not work, actually, it works quite the
> opposite ("first comes, wins"). Moreover, Maven remains silent about this, as
> reproducer shows, and all of this goes unnoticed.
> Solution: at least depMgt import should make "the maven way", maybe not by
> default (to not break existing builds) but configurable. Problem is solved if
> in reproducer:
> - with fix enabled, junit 5.9.3 is used, AND
> - with fix disabled, Maven yells about ignored depMgt import
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MNG-7906) Dependency Management import does not work the "maven way"
[
https://issues.apache.org/jira/browse/MNG-7906?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Elliotte Rusty Harold updated MNG-7906:
---
Priority: Major (was: Blocker)
> Dependency Management import does not work the "maven way"
> --
>
> Key: MNG-7906
> URL: https://issues.apache.org/jira/browse/MNG-7906
> Project: Maven
> Issue Type: Bug
> Components: Dependencies
>Reporter: Tamas Cservenak
>Priority: Major
> Fix For: 4.0.x-candidate
>
>
> This affects all released Maven versions so far.
> Problem reproducer: https://github.com/cstamas/MNG-7852 (repo name is wrong,
> obviously).
> In short: unlike with dependencies, where you CAN override some "deep
> transitive" dependency by re-declaring it directly as 1st level dependency in
> POM, for depMgt import this does not work, actually, it works quite the
> opposite ("first comes, wins"). Moreover, Maven remains silent about this, as
> reproducer shows, and all of this goes unnoticed.
> Solution: at least depMgt import should make "the maven way", maybe not by
> default (to not break existing builds) but configurable. Problem is solved if
> in reproducer:
> - with fix enabled, junit 5.9.3 is used, AND
> - with fix disabled, Maven yells about ignored depMgt import
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (MRESOLVER-372) Download fails if file is currently in use under windows
[
https://issues.apache.org/jira/browse/MRESOLVER-372?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tamas Cservenak closed MRESOLVER-372.
-
Resolution: Fixed
> Download fails if file is currently in use under windows
>
>
> Key: MRESOLVER-372
> URL: https://issues.apache.org/jira/browse/MRESOLVER-372
> Project: Maven Resolver
> Issue Type: Bug
> Components: Resolver
>Reporter: Christoph Läubrich
>Assignee: Tamas Cservenak
>Priority: Major
> Fix For: 2.0.0, 1.9.17
>
>
> With the new file-locking in maven-resolver there is a problem under windows
> if the file is currently used by another process (this can for example happen
> in an IDE ...) and resolver likes to move the file:
>
> {code:java}
> Caused by: java.nio.file.AccessDeniedException:
> xxx-SNAPSHOT.jar.15463549870494779429.tmp -> -SNAPSHOT.jar
> at
> java.base/sun.nio.fs.WindowsException.translateToIOException(WindowsException.java:89)
> at
> java.base/sun.nio.fs.WindowsException.rethrowAsIOException(WindowsException.java:103)
> at java.base/sun.nio.fs.WindowsFileCopy.move(WindowsFileCopy.java:317)
> at
> java.base/sun.nio.fs.WindowsFileSystemProvider.move(WindowsFileSystemProvider.java:293)
> at java.base/java.nio.file.Files.move(Files.java:1432)
> at org.eclipse.aether.util.FileUtils$2.move(FileUtils.java:108)
> at
> org.eclipse.aether.internal.impl.DefaultFileProcessor.copy(DefaultFileProcessor.java:96)
> at
> org.eclipse.aether.internal.impl.DefaultFileProcessor.copy(DefaultFileProcessor.java:88)
> at
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.getFile(DefaultArtifactResolver.java:490)
> ... 30 more{code}
>
> My suggestion would be that resolver simply uses the temp file if it can't be
> moved to final location and marks it as delete on exit. Even though this is
> not optimal, it at least ensures the the build does not fail to the cost that
> next time the file needs to be downloaded again.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MRESOLVER-372) Download fails if file is currently in use under windows
[
https://issues.apache.org/jira/browse/MRESOLVER-372?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17787174#comment-17787174
]
ASF GitHub Bot commented on MRESOLVER-372:
--
cstamas merged PR #365:
URL: https://github.com/apache/maven-resolver/pull/365
> Download fails if file is currently in use under windows
>
>
> Key: MRESOLVER-372
> URL: https://issues.apache.org/jira/browse/MRESOLVER-372
> Project: Maven Resolver
> Issue Type: Bug
> Components: Resolver
>Reporter: Christoph Läubrich
>Assignee: Tamas Cservenak
>Priority: Major
> Fix For: 2.0.0, 1.9.17
>
>
> With the new file-locking in maven-resolver there is a problem under windows
> if the file is currently used by another process (this can for example happen
> in an IDE ...) and resolver likes to move the file:
>
> {code:java}
> Caused by: java.nio.file.AccessDeniedException:
> xxx-SNAPSHOT.jar.15463549870494779429.tmp -> -SNAPSHOT.jar
> at
> java.base/sun.nio.fs.WindowsException.translateToIOException(WindowsException.java:89)
> at
> java.base/sun.nio.fs.WindowsException.rethrowAsIOException(WindowsException.java:103)
> at java.base/sun.nio.fs.WindowsFileCopy.move(WindowsFileCopy.java:317)
> at
> java.base/sun.nio.fs.WindowsFileSystemProvider.move(WindowsFileSystemProvider.java:293)
> at java.base/java.nio.file.Files.move(Files.java:1432)
> at org.eclipse.aether.util.FileUtils$2.move(FileUtils.java:108)
> at
> org.eclipse.aether.internal.impl.DefaultFileProcessor.copy(DefaultFileProcessor.java:96)
> at
> org.eclipse.aether.internal.impl.DefaultFileProcessor.copy(DefaultFileProcessor.java:88)
> at
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.getFile(DefaultArtifactResolver.java:490)
> ... 30 more{code}
>
> My suggestion would be that resolver simply uses the temp file if it can't be
> moved to final location and marks it as delete on exit. Even though this is
> not optimal, it at least ensures the the build does not fail to the cost that
> next time the file needs to be downloaded again.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [PR] [MRESOLVER-372] Rework the FileUtils collocated temp file [maven-resolver]
cstamas merged PR #365: URL: https://github.com/apache/maven-resolver/pull/365 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MRESOLVER-372) Download fails if file is currently in use under windows
[
https://issues.apache.org/jira/browse/MRESOLVER-372?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17787173#comment-17787173
]
ASF GitHub Bot commented on MRESOLVER-372:
--
cstamas merged PR #364:
URL: https://github.com/apache/maven-resolver/pull/364
> Download fails if file is currently in use under windows
>
>
> Key: MRESOLVER-372
> URL: https://issues.apache.org/jira/browse/MRESOLVER-372
> Project: Maven Resolver
> Issue Type: Bug
> Components: Resolver
>Reporter: Christoph Läubrich
>Assignee: Tamas Cservenak
>Priority: Major
> Fix For: 2.0.0, 1.9.17
>
>
> With the new file-locking in maven-resolver there is a problem under windows
> if the file is currently used by another process (this can for example happen
> in an IDE ...) and resolver likes to move the file:
>
> {code:java}
> Caused by: java.nio.file.AccessDeniedException:
> xxx-SNAPSHOT.jar.15463549870494779429.tmp -> -SNAPSHOT.jar
> at
> java.base/sun.nio.fs.WindowsException.translateToIOException(WindowsException.java:89)
> at
> java.base/sun.nio.fs.WindowsException.rethrowAsIOException(WindowsException.java:103)
> at java.base/sun.nio.fs.WindowsFileCopy.move(WindowsFileCopy.java:317)
> at
> java.base/sun.nio.fs.WindowsFileSystemProvider.move(WindowsFileSystemProvider.java:293)
> at java.base/java.nio.file.Files.move(Files.java:1432)
> at org.eclipse.aether.util.FileUtils$2.move(FileUtils.java:108)
> at
> org.eclipse.aether.internal.impl.DefaultFileProcessor.copy(DefaultFileProcessor.java:96)
> at
> org.eclipse.aether.internal.impl.DefaultFileProcessor.copy(DefaultFileProcessor.java:88)
> at
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.getFile(DefaultArtifactResolver.java:490)
> ... 30 more{code}
>
> My suggestion would be that resolver simply uses the temp file if it can't be
> moved to final location and marks it as delete on exit. Even though this is
> not optimal, it at least ensures the the build does not fail to the cost that
> next time the file needs to be downloaded again.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [PR] [MRESOLVER-372] Rework the FileUtils collocated temp file [maven-resolver]
cstamas merged PR #364: URL: https://github.com/apache/maven-resolver/pull/364 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MINSTALL-194) Fail to install snapshot artifact when clean phase is used
[
https://issues.apache.org/jira/browse/MINSTALL-194?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17787172#comment-17787172
]
Tamas Cservenak commented on MINSTALL-194:
--
As I see (more like assume), what happens is that due PMD.aggregate=true, the
plugin will "load all" ([see Andreas
explanation|https://issues.apache.org/jira/browse/MPMD-277?focusedCommentId=16814718&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16814718]),
and that simply put, keeps even project JAR files open, while again Maven
itself tries to "install" these same files (into same place, as I guess we talk
about snaphot project). And here, due MRESOLVER-372 "atomic move" Windows
refuses to atomically replace the file...
> Fail to install snapshot artifact when clean phase is used
> --
>
> Key: MINSTALL-194
> URL: https://issues.apache.org/jira/browse/MINSTALL-194
> Project: Maven Install Plugin
> Issue Type: Bug
> Components: install:install
>Affects Versions: 3.1.1
> Environment: Apache Maven 3.9.5
> (57804ffe001d7215b5e7bcb531cf83df38f93546)
> Maven home: C:\Program Files\Maven\apache-maven-3.9.5-bin\apache-maven-3.9.5
> Java version: 11.0.18, vendor: Oracle Corporation, runtime: C:\Program
> Files\Java\jdk-11
> Default locale: en_US, platform encoding: Cp1252
> OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"
>Reporter: Candice Tosi Michelon
>Priority: Minor
> Attachments: StackTrace.txt, StackTraceDebug.txt,
> image-2023-11-16-08-15-07-597.png
>
>
> {*}After ugrading maven from version 3.6.3 to 3.9.4 a few maven projects
> started failing in the install phase with the error below{*}:
> Failed to install artifact xx:jar:1.1-SNAPSHOT:
> x-1.1-SNAPSHOT.jar.3154215231322123456.tmp -> x-1.1-SNAPSHOT.jar ->
> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal org.apache.maven.plugins:maven-install-plugin:3.1.1:install
> (default-install) on project x: Failed to install artifact
> x:jar:1.1-SNAPSHOT: x-1.1-SNAPSHOT.jar
> Caused by: org.apache.maven.plugin.MojoExecutionException:
> Caused by: org.eclipse.aether.installation.InstallationException:
> Caused by: java.nio.file.AccessDeniedException:
>
> *Command used:* mvn clean install
>
> *All the projects affected have the following characteristics:*
> * Multi-modules
> * The clean phase is used at least once
> * The pmd check is performed
> * A jar snapshot of the module already existis in the maven repository
> folder (.m2)
> This is not a blocker issue because *it is still possible to build the
> projects and install the snapshots* in the local repository if the follwoing
> options are used:
> * Option 1: Avoid using the clean phase. Use only 'mvn install'.
> * Option 2: Use the following mvn commands:
> ** mvn clean
> ** mvn install -N
> ** mvn install -rf
> * Option 3: Use the following commands:
> ** mvn clean install (the build will fail trying to install the jar of one
> of the modules in the .m2 folder)
> ** mvn install -rf installed>
> * Option 4: skip pmd check:
> ** mvn clean install -Dpmd.skip=true
> * Option 5: delete the jar snapshots previously installed in the maven
> repository folder.
> I can't provide a sample project or pom because I was not able to reproduce
> the issue in a new project. Also, there are other projects with the same
> characteristcs that does not present the problem, I could not identify any
> significant difference between them as dependencies and plugins versions, as
> well as build configuration, are mostly the same.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MNG-7892) MavenException should be a checked exception
[ https://issues.apache.org/jira/browse/MNG-7892?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17787170#comment-17787170 ] Elliotte Rusty Harold commented on MNG-7892: That's not the right way to think about this. Checked vs unchecked is *not* about whether to retry the operation. Checked exceptions usually aren't retried. They usually are handled. Checked exceptions report errors external to the program. Here Maven itself is the program in question, not the program the dev is building with maven. Imagine the project being built contains an error such as a dependency with a typo in the group ID. There are two cases: 1. The project is being built interactively with something like mvn clean install at the command line. In this case, maven needs to catch the exception and report the error to the end user. It should not dump a stack trace and shut down. 2. Maven is being invoked through its API, perhaps by a plugin. In this case, the plugin code will catch the exception and deal with it. In both cases though this should be a checked exception because: 1. It must always be dealt with. There is no condition under which the exception should be allowed to bubble up to the top. 2. The developers of Maven, i.e. us, cannot detect or prevent the failure by changing the code in Maven. Then bug is not in our code. It is completely external to the program. Given these conditions, a checked exception ensures that no one forgets to do things they have to do anyway. Making MavenException a runtime exception has no advantage. It does not allow you to write even one fewer error handler. It just makes it harder to remember that the catch block has to be written, and enables code to ship with bugs. > MavenException should be a checked exception > > > Key: MNG-7892 > URL: https://issues.apache.org/jira/browse/MNG-7892 > Project: Maven > Issue Type: Bug > Components: Core >Affects Versions: 4.0.0-alpha-7 >Reporter: Elliotte Rusty Harold >Priority: Major > > MavenException is used to report errors in parsing pom.xml files that are > external the Maven program itself. Whether they are thrown or not does not > indicate a bug in Maven's code. It is an error condition in the user's code > that needs to be prepared for and handled by Maven core, much like a program > should not assume that a file will be read without IOExceptions or XML > parsing errors. Thus this needs to be a checked exception. > Alternatively, if this is used both for cases that arise from outside Maven's > own code and bugs in Maven's code, then two separate exception classes are > needed, one checked and one unchecked. > This is in > api/maven-api-core/src/main/java/org/apache/maven/api/services/MavenException.java -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (SUREFIRE-1695) Support multiple inheritance of @Categories
[
https://issues.apache.org/jira/browse/SUREFIRE-1695?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17787169#comment-17787169
]
Christian Nüssgens edited comment on SUREFIRE-1695 at 11/17/23 12:21 PM:
-
I'm currently wondering:
We relied on this fact and now (after upgrading finally to surefire >= 3.0.0)
our tests are not working as expected anymore.
We used this to _override_ Categories of Test-Classes.
Furthermore the surefire-way of interpreting {{@Category}} is not reflecting
the behavior of the JUnit 4.12 Categories runner.
Assume the following Test Classes
{code:java}
@Category(CategoryA.class)
public abstract class AbstractTest {
}
public class TestA extends AbstractTest {
@Test
public void testIt() throws Exception {
//do test
}
}
@Category(CategoryPlayground.class)
public class PlaygroundTestA extends TestA {
@Test
public void testIt() throws Exception {
// do nasty stuff like while(true)
}
}
{code}
The built-in categories Runner behaves as follows
{code:java}
@RunWith(Categories.class)
@IncludeCategory({CategoryA.class})
@SuiteClasses({TestA.class, PlaygroundTestA.class})
public class TheSuite {
}
{code}
If run: only {{TestA}} is executed. The "closest" Categories declaration wins,
although the Categories-annotation itself is "inheritable".
Surefire does behave differently:
{code:xml}
CategoryA
{code}
If run ({{mvn test}}) surefire will execute {{TestA}} and {{PlaygroundTestA}}
(since surefire 3.0.0-M5)
Does one know what the majority expects here? In my opinion it is strange to
handle JUnit Categories different than JUnit itself does.
Is it possible to restore the "old" behavior?
Or maybe make it configurable.
was (Author: JIRAUSER288303):
I'm currently wondering:
We relied on this fact and now (after upgrading finally to surefire >= 3.0.0)
our tests are not working as expected anymore.
We used this to _override_ Categories of Test-Classes.
Furthermore the surefire-way of interpreting {{@Category}} is not reflecting
the behavior of the JUnit 4.12 Categories runner.
Assume the following Test Classes
{code:java}
@Category(CategoryA.class)
public abstract class AbstractTest {
}
public class TestA extends AbstractTest {
@Test
public void testIt() throws Exception {
//do test
}
}
@Category(CategoryPlayground.class)
public class PlaygroundTestA extends TestA {
@Test
public void testIt() throws Exception {
// do nasty stuff like while(true)
}
}
{code}
The built-in categories Runner behaves as follows
{code:java}
@RunWith(Categories.class)
@IncludeCategory({CategoryA.class})
@SuiteClasses({TestA.class, PlaygroundTestA.class})
public class TheSuite {
}
{code}
If executed: only {{TestA}} is run. The "closest" Categories declaration wins,
although the Categories-annotation itself is "inheritable".
Surefire does behave differently:
{code:xml}
CategoryA
{code}
If executed ({{mvn test}}) surefire will execute {{TestA}} and
{{PlaygroundTestA}} (since surefire 3.0.0-M5)
Does one know what the majority expects here? In my opinion it is strange to
handle JUnit Categories different than JUnit itself does.
Is it possible to restore the "old" behavior?
Or maybe make it configurable.
> Support multiple inheritance of @Categories
> ---
>
> Key: SUREFIRE-1695
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1695
> Project: Maven Surefire
> Issue Type: Bug
> Components: Junit 4.7+ (parallel) support, Maven Surefire Plugin
>Affects Versions: 3.0.0-M3
>Reporter: Yiannis Dermitzakis
>Assignee: Tibor Digana
>Priority: Major
> Labels: pull-request-available
> Fix For: 3.0.0-M5
>
> Original Estimate: 0h
> Time Spent: 20m
> Remaining Estimate: 0h
>
> We are using JUnit Categories together with Surefire's /
> tags in a Test hierarchy. However we have observed some inconsistencies in
> the resolution.
> Example:
> * {{AbstractTest}} is tagged with {{@Category(CategoryB.class)}}
> * {{TestA extends AbstractTest}} and is tagged with
> {{@Category(CategoryA.class)}}
> * When running Surefire with {{CategoryB, TestA is not
> executed.
>
> There are a few more failure cases, written as (integration/unit) tests. I
> have provided a PR with a fix.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (SUREFIRE-1695) Support multiple inheritance of @Categories
[
https://issues.apache.org/jira/browse/SUREFIRE-1695?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17787169#comment-17787169
]
Christian Nüssgens commented on SUREFIRE-1695:
--
I'm currently wondering:
We relied on this fact and now (after upgrading finally to surefire >= 3.0.0)
our tests are not working as expected anymore.
We used this to _override_ Categories of Test-Classes.
Furthermore the surefire-way of interpreting {{@Category}} is not reflecting
the behavior of the JUnit 4.12 Categories runner.
Assume the following Test Classes
{code:java}
@Category(CategoryA.class)
public abstract class AbstractTest {
}
public class TestA extends AbstractTest {
@Test
public void testIt() throws Exception {
//do test
}
}
@Category(CategoryPlayground.class)
public class PlaygroundTestA extends TestA {
@Test
public void testIt() throws Exception {
// do nasty stuff like while(true)
}
}
{code}
The built-in categories Runner behaves as follows
{code:java}
@RunWith(Categories.class)
@IncludeCategory({CategoryA.class})
@SuiteClasses({TestA.class, PlaygroundTestA.class})
public class TheSuite {
}
{code}
If executed: only {{TestA}} is run. The "closest" Categories declaration wins,
although the Categories-annotation itself is "inheritable".
Surefire does behave differently:
{code:xml}
CategoryA
{code}
If executed ({{mvn test}}) surefire will execute {{TestA}} and
{{PlaygroundTestA}} (since surefire 3.0.0-M5)
Does one know what the majority expects here? In my opinion it is strange to
handle JUnit Categories different than JUnit itself does.
Is it possible to restore the "old" behavior?
Or maybe make it configurable.
> Support multiple inheritance of @Categories
> ---
>
> Key: SUREFIRE-1695
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1695
> Project: Maven Surefire
> Issue Type: Bug
> Components: Junit 4.7+ (parallel) support, Maven Surefire Plugin
>Affects Versions: 3.0.0-M3
>Reporter: Yiannis Dermitzakis
>Assignee: Tibor Digana
>Priority: Major
> Labels: pull-request-available
> Fix For: 3.0.0-M5
>
> Original Estimate: 0h
> Time Spent: 20m
> Remaining Estimate: 0h
>
> We are using JUnit Categories together with Surefire's /
> tags in a Test hierarchy. However we have observed some inconsistencies in
> the resolution.
> Example:
> * {{AbstractTest}} is tagged with {{@Category(CategoryB.class)}}
> * {{TestA extends AbstractTest}} and is tagged with
> {{@Category(CategoryA.class)}}
> * When running Surefire with {{CategoryB, TestA is not
> executed.
>
> There are a few more failure cases, written as (integration/unit) tests. I
> have provided a PR with a fix.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MNG-7892) MavenException should be a checked exception
[ https://issues.apache.org/jira/browse/MNG-7892?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elliotte Rusty Harold updated MNG-7892: --- Description: MavenException is used to report errors in parsing pom.xml files that are external the Maven program itself. Whether they are thrown or not does not indicate a bug in Maven's code. It is an error condition in the user's code that needs to be prepared for and handled by Maven core, much like a program should not assume that a file will be read without IOExceptions or XML parsing errors. Thus this needs to be a checked exception. Alternatively, if this is used both for cases that arise from outside Maven's own code and bugs in Maven's code, then two separate exception classes are needed, one checked and one unchecked. This is in api/maven-api-core/src/main/java/org/apache/maven/api/services/MavenException.java was: MavenException is used to report errors in parsing pom.xml files that are external the Maven program itself. Whether they are thrown or not does not indicate a bug in Maven's code. It is an error condition in the user's code that needs to be prepared for and handled by Maven core, much like a program should not assume that a file will be read withouyt IOExceptions or XML parsing errors. Thus this needs to be a checked exception. Alternatively, if this is used bot for cases that arise from outside Maven's own code and bugs in Maven's code, then two separate exception classes are needed, one checked and one unchecked. This is in api/maven-api-core/src/main/java/org/apache/maven/api/services/MavenException.java > MavenException should be a checked exception > > > Key: MNG-7892 > URL: https://issues.apache.org/jira/browse/MNG-7892 > Project: Maven > Issue Type: Bug > Components: Core >Affects Versions: 4.0.0-alpha-7 >Reporter: Elliotte Rusty Harold >Priority: Major > > MavenException is used to report errors in parsing pom.xml files that are > external the Maven program itself. Whether they are thrown or not does not > indicate a bug in Maven's code. It is an error condition in the user's code > that needs to be prepared for and handled by Maven core, much like a program > should not assume that a file will be read without IOExceptions or XML > parsing errors. Thus this needs to be a checked exception. > Alternatively, if this is used both for cases that arise from outside Maven's > own code and bugs in Maven's code, then two separate exception classes are > needed, one checked and one unchecked. > This is in > api/maven-api-core/src/main/java/org/apache/maven/api/services/MavenException.java -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MNG-7923) Jenkins core does not compile with Maven 4.x
[
https://issues.apache.org/jira/browse/MNG-7923?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17787164#comment-17787164
]
Guillaume Nodet commented on MNG-7923:
--
I've created a first PR. This may not be sufficient, but it's a first step.
> Jenkins core does not compile with Maven 4.x
>
>
> Key: MNG-7923
> URL: https://issues.apache.org/jira/browse/MNG-7923
> Project: Maven
> Issue Type: Bug
> Components: Core
>Affects Versions: 4.0.0-alpha-8
>Reporter: Basil Crow
>Priority: Major
>
> Try running {{git clone https://github.com/jenkinsci/jenkins.git && cd
> jenkins && mvn verify -Pquick-build}}. On the latest version of Maven 3.x, it
> works; on the latest Maven 4.x alpha, the build fails immediately with
> "Non-resolvable import POM: The following artifacts could not be resolved".
> If we need to make changes to our POM, then please point me to the
> documentation; otherwise, please fix the bug and let me know which release of
> Maven 4.x alpha I can test with the bug fixed. I bisected the failure to
> MNG-6656 /
> https://github.com/apache/maven/commit/bdec668de9c600165bb69c95b6ea0625d9f74fb0
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MNG-7923) Jenkins core does not compile with Maven 4.x
[
https://issues.apache.org/jira/browse/MNG-7923?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17787163#comment-17787163
]
ASF GitHub Bot commented on MNG-7923:
-
gnodet opened a new pull request, #1311:
URL: https://github.com/apache/maven/pull/1311
This is a first step to fix [MNG-7923]
> Jenkins core does not compile with Maven 4.x
>
>
> Key: MNG-7923
> URL: https://issues.apache.org/jira/browse/MNG-7923
> Project: Maven
> Issue Type: Bug
> Components: Core
>Affects Versions: 4.0.0-alpha-8
>Reporter: Basil Crow
>Priority: Major
>
> Try running {{git clone https://github.com/jenkinsci/jenkins.git && cd
> jenkins && mvn verify -Pquick-build}}. On the latest version of Maven 3.x, it
> works; on the latest Maven 4.x alpha, the build fails immediately with
> "Non-resolvable import POM: The following artifacts could not be resolved".
> If we need to make changes to our POM, then please point me to the
> documentation; otherwise, please fix the bug and let me know which release of
> Maven 4.x alpha I can test with the bug fixed. I bisected the failure to
> MNG-6656 /
> https://github.com/apache/maven/commit/bdec668de9c600165bb69c95b6ea0625d9f74fb0
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (SUREFIRE-2211) additionalClasspathElement with UNC path not working with failsafe > 3.0.0-M1
[ https://issues.apache.org/jira/browse/SUREFIRE-2211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17787147#comment-17787147 ] Robert Seidel edited comment on SUREFIRE-2211 at 11/17/23 12:08 PM: The first failing commit is this one: https://github.com/apache/maven-surefire/commit/f5cca5bcc2c85060c21c82eea0081d016cb86909#diff-8b7d87de30078d9465dc3a997b7121b77e70b150bde4678ffed0fade332ade51 I'm pretty sure https://github.com/apache/maven-surefire/commit/f5cca5bcc2c85060c21c82eea0081d016cb86909#diff-831c3693e03bf74af278a55df4af2ce453b674930f1932b4f7334b2417cbb595R169 destroys UNC paths. Here is how the java.class.path property looks like (from failsafe report xml): . was (Author: JIRAUSER295788): The first failing commit is this one: https://github.com/apache/maven-surefire/commit/f5cca5bcc2c85060c21c82eea0081d016cb86909#diff-8b7d87de30078d9465dc3a997b7121b77e70b150bde4678ffed0fade332ade51 I'm pretty sure https://github.com/apache/maven-surefire/commit/f5cca5bcc2c85060c21c82eea0081d016cb86909#diff-831c3693e03bf74af278a55df4af2ce453b674930f1932b4f7334b2417cbb595R169 destroys UNC paths. Here is how the java.class.path property looks like (from failsafe report xml): . Probably \ should be replaced with /, but double backshlash should not be replaced. > additionalClasspathElement with UNC path not working with failsafe > 3.0.0-M1 > - > > Key: SUREFIRE-2211 > URL: https://issues.apache.org/jira/browse/SUREFIRE-2211 > Project: Maven Surefire > Issue Type: Bug > Components: Maven Failsafe Plugin >Affects Versions: 3.0.0-M2, 3.2.2 > Environment: Windows JDK17.0.5+8 >Reporter: Robert Seidel >Priority: Major > > We are using the configuration parameter additionalClasspathElements > (https://maven.apache.org/surefire/maven-failsafe-plugin/integration-test-mojo.html#additionalClasspathElements) > to provide a log4j2 xml configuration during tests. There is configured an > UNC path like this //our-server/build/failsafe containing the file. > Until version 3.0.0-M2 everything was fine, the ressource could be found > within the class loader and log4j was configured correctly (so 3.0.0-M1 was > ok). > However since the Milestone 2 of version 3 and with all later versions, the > ressource could not be found within the classpath, leaving log4j unconfigured. > From the reporting xml the classpath is configured the same, but the class > loader behaves differently. > When using a normal path like c:/build/failsafe the ressource can be found > without issues. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[PR] [MNG-7923] Fix CI friendly version to look for properties in the pom [maven]
gnodet opened a new pull request, #1311: URL: https://github.com/apache/maven/pull/1311 This is a first step to fix [MNG-7923] -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (SUREFIRE-2212) OutOfMemoryError raised when parsing files with a lot of std-err information in surefire-report-parser
[
https://issues.apache.org/jira/browse/SUREFIRE-2212?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17787162#comment-17787162
]
Ramon Bisswanger commented on SUREFIRE-2212:
Proposed PR: https://github.com/apache/maven-surefire/pull/687
> OutOfMemoryError raised when parsing files with a lot of std-err information
> in surefire-report-parser
> --
>
> Key: SUREFIRE-2212
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2212
> Project: Maven Surefire
> Issue Type: Bug
> Components: surefire-shared-utils
>Affects Versions: 3.2.2
>Reporter: Ramon Bisswanger
>Priority: Major
>
> While parsing large reports, we identified {{OutOfMemoryError}} being raised
> in the {{surefire-report-parser}} in case the test file contains large CDATA
> sections below {{system-err}} / {{system-out}} in the report.
> While this is using a SAX parser, it parses all element contents into a
> string and that can cause issues for large test reports.
> Proposed fix: only keep element contents in memory in case the value is used
> somewhere for the result.
> i.e. {{system-err}} / {{system-out}} is just discarded.
> Sample project which is demonstrating the issue by creating a huge dummy test
> report and then uses the parser:
> [https://github.com/bisswanger/surefire-parser-sample] (see README for
> details)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (SUREFIRE-2212) OutOfMemoryError raised when parsing files with a lot of std-err information in surefire-report-parser
Ramon Bisswanger created SUREFIRE-2212:
--
Summary: OutOfMemoryError raised when parsing files with a lot of
std-err information in surefire-report-parser
Key: SUREFIRE-2212
URL: https://issues.apache.org/jira/browse/SUREFIRE-2212
Project: Maven Surefire
Issue Type: Bug
Components: surefire-shared-utils
Affects Versions: 3.2.2
Reporter: Ramon Bisswanger
While parsing large reports, we identified {{OutOfMemoryError}} being raised in
the {{surefire-report-parser}} in case the test file contains large CDATA
sections below {{system-err}} / {{system-out}} in the report.
While this is using a SAX parser, it parses all element contents into a string
and that can cause issues for large test reports.
Proposed fix: only keep element contents in memory in case the value is used
somewhere for the result.
i.e. {{system-err}} / {{system-out}} is just discarded.
Sample project which is demonstrating the issue by creating a huge dummy test
report and then uses the parser:
[https://github.com/bisswanger/surefire-parser-sample] (see README for details)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (SUREFIRE-2211) additionalClasspathElement with UNC path not working with failsafe > 3.0.0-M1
[ https://issues.apache.org/jira/browse/SUREFIRE-2211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17787159#comment-17787159 ] Michael Osipov commented on SUREFIRE-2211: -- I agree with you that line 169 is wrong. > additionalClasspathElement with UNC path not working with failsafe > 3.0.0-M1 > - > > Key: SUREFIRE-2211 > URL: https://issues.apache.org/jira/browse/SUREFIRE-2211 > Project: Maven Surefire > Issue Type: Bug > Components: Maven Failsafe Plugin >Affects Versions: 3.0.0-M2, 3.2.2 > Environment: Windows JDK17.0.5+8 >Reporter: Robert Seidel >Priority: Major > > We are using the configuration parameter additionalClasspathElements > (https://maven.apache.org/surefire/maven-failsafe-plugin/integration-test-mojo.html#additionalClasspathElements) > to provide a log4j2 xml configuration during tests. There is configured an > UNC path like this //our-server/build/failsafe containing the file. > Until version 3.0.0-M2 everything was fine, the ressource could be found > within the class loader and log4j was configured correctly (so 3.0.0-M1 was > ok). > However since the Milestone 2 of version 3 and with all later versions, the > ressource could not be found within the classpath, leaving log4j unconfigured. > From the reporting xml the classpath is configured the same, but the class > loader behaves differently. > When using a normal path like c:/build/failsafe the ressource can be found > without issues. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (MNG-6026) Extend the Project Object Model (POM) with trust information (OpenPGP, hash values)
[
https://issues.apache.org/jira/browse/MNG-6026?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17787155#comment-17787155
]
Tamas Cservenak edited comment on MNG-6026 at 11/17/23 11:57 AM:
-
POM is already bloated, and adding sections like this:
{noformat}
[sha256 of junit pom file]
[sha256sum of artifact (junit.jar)]
{noformat}
would just bloat it more (w/ info that is incomprehensible for humans, like hex
string of sha256). IMHO, "side loading" this exactly as "trusted checksums"
does it the best way, not placing it into POM, while it IS committed along
sources and POM into SCM.
was (Author: cstamas):
POM is already bloated, and adding sections like this:
{noformat}
[sha256 of junit pom file]
[sha256sum of artifact (junit.jar)]
{noformat}
would just bloat it more (w/ info that is incomprehensible for humans, like hex
string oh sha256). IMHO, "side loading" this exactly as "trusted checksums"
does it the best way, not placing it into POM.
> Extend the Project Object Model (POM) with trust information (OpenPGP, hash
> values)
> ---
>
> Key: MNG-6026
> URL: https://issues.apache.org/jira/browse/MNG-6026
> Project: Maven
> Issue Type: New Feature
> Components: Core
>Reporter: Florian Schmaus
>Priority: Major
> Labels: artifact-verification, security
>
> The origin of this feature request is the Stackoverflow question
> ["Verification of dependency authenticity in Maven POM based automated build
> systems"|http://stackoverflow.com/a/34795359/194894], and [especially a SO
> user requesting me to put this
> up|http://stackoverflow.com/questions/3307146/verification-of-dependency-authenticy-in-maven-pom-based-automated-build-systems/34795359?noredirect=1#comment62178671_34795359].
> h2. Extend the Project Object Model (POM) with trust information (OpenPGP -
> RFC 4480 and hash values)
> What we need is the possibility to model a trust relation from your project
> or artifact to the declared dependencies. So that, if all involved parties
> declare such a relation, we are able to create a "chain of trust" from the
> root (e.g. the project) over its dependencies down to the very last
> transitive dependency. The Project Object Model (POM) needs to be extended by
> a element for dependencies.
> h3. Current Situation
> Right now we have something like
> {code:xml}
>
> junit
> junit
> 4.0
>
> {code}
> h3. Hard dependencies
> For hard dependencies, could include the sha256sum of artifact
> and its POM file:
> {code:xml}
>
> junit
> junit
> [4.0]
>
>
> [sha256 of junit pom file]
> [sha256sum of artifact (junit.jar)]
>
>
>
> {code}
> h3. Soft dependencies
> If soft, which are also called "ranged" or "dynamic", dependencies are used,
> then we could specify the public key (or multiple) of the keypair used to
> sign the artifacts
> {code:xml}
>
> junit
> junit
> [4.0,4.5)
>
> [secure fingerprint of OpenPGP key used to sign the junit
> artifact(s)]
>
>
>
> {code}
> I'm not sure if this is the right place to raise an feature request for the
> POM format itself. I've already tried to get in touch with the right people
> about this feature request, but failed. I'm willing to help designing and
> implementing this, but need guidance.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MNG-6026) Extend the Project Object Model (POM) with trust information (OpenPGP, hash values)
[
https://issues.apache.org/jira/browse/MNG-6026?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17787155#comment-17787155
]
Tamas Cservenak commented on MNG-6026:
--
POM is already bloated, and adding sections like this:
{noformat}
[sha256 of junit pom file]
[sha256sum of artifact (junit.jar)]
{noformat}
would just bloat it more (w/ info that is incomprehensible for humans, like hex
string oh sha256). IMHO, "side loading" this exactly as "trusted checksums"
does it the best way, not placing it into POM.
> Extend the Project Object Model (POM) with trust information (OpenPGP, hash
> values)
> ---
>
> Key: MNG-6026
> URL: https://issues.apache.org/jira/browse/MNG-6026
> Project: Maven
> Issue Type: New Feature
> Components: Core
>Reporter: Florian Schmaus
>Priority: Major
> Labels: artifact-verification, security
>
> The origin of this feature request is the Stackoverflow question
> ["Verification of dependency authenticity in Maven POM based automated build
> systems"|http://stackoverflow.com/a/34795359/194894], and [especially a SO
> user requesting me to put this
> up|http://stackoverflow.com/questions/3307146/verification-of-dependency-authenticy-in-maven-pom-based-automated-build-systems/34795359?noredirect=1#comment62178671_34795359].
> h2. Extend the Project Object Model (POM) with trust information (OpenPGP -
> RFC 4480 and hash values)
> What we need is the possibility to model a trust relation from your project
> or artifact to the declared dependencies. So that, if all involved parties
> declare such a relation, we are able to create a "chain of trust" from the
> root (e.g. the project) over its dependencies down to the very last
> transitive dependency. The Project Object Model (POM) needs to be extended by
> a element for dependencies.
> h3. Current Situation
> Right now we have something like
> {code:xml}
>
> junit
> junit
> 4.0
>
> {code}
> h3. Hard dependencies
> For hard dependencies, could include the sha256sum of artifact
> and its POM file:
> {code:xml}
>
> junit
> junit
> [4.0]
>
>
> [sha256 of junit pom file]
> [sha256sum of artifact (junit.jar)]
>
>
>
> {code}
> h3. Soft dependencies
> If soft, which are also called "ranged" or "dynamic", dependencies are used,
> then we could specify the public key (or multiple) of the keypair used to
> sign the artifacts
> {code:xml}
>
> junit
> junit
> [4.0,4.5)
>
> [secure fingerprint of OpenPGP key used to sign the junit
> artifact(s)]
>
>
>
> {code}
> I'm not sure if this is the right place to raise an feature request for the
> POM format itself. I've already tried to get in touch with the right people
> about this feature request, but failed. I'm willing to help designing and
> implementing this, but need guidance.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MNG-6026) Extend the Project Object Model (POM) with trust information (OpenPGP, hash values)
[
https://issues.apache.org/jira/browse/MNG-6026?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17787152#comment-17787152
]
Guillaume Nodet commented on MNG-6026:
--
Also, even if it's not POM 5.0.0, the POM model is now open for changes. The
latest 4.0.0-alpha-8 defines POM 4.1.0 (not final yet).
> Extend the Project Object Model (POM) with trust information (OpenPGP, hash
> values)
> ---
>
> Key: MNG-6026
> URL: https://issues.apache.org/jira/browse/MNG-6026
> Project: Maven
> Issue Type: New Feature
> Components: Core
>Reporter: Florian Schmaus
>Priority: Major
> Labels: artifact-verification, security
>
> The origin of this feature request is the Stackoverflow question
> ["Verification of dependency authenticity in Maven POM based automated build
> systems"|http://stackoverflow.com/a/34795359/194894], and [especially a SO
> user requesting me to put this
> up|http://stackoverflow.com/questions/3307146/verification-of-dependency-authenticy-in-maven-pom-based-automated-build-systems/34795359?noredirect=1#comment62178671_34795359].
> h2. Extend the Project Object Model (POM) with trust information (OpenPGP -
> RFC 4480 and hash values)
> What we need is the possibility to model a trust relation from your project
> or artifact to the declared dependencies. So that, if all involved parties
> declare such a relation, we are able to create a "chain of trust" from the
> root (e.g. the project) over its dependencies down to the very last
> transitive dependency. The Project Object Model (POM) needs to be extended by
> a element for dependencies.
> h3. Current Situation
> Right now we have something like
> {code:xml}
>
> junit
> junit
> 4.0
>
> {code}
> h3. Hard dependencies
> For hard dependencies, could include the sha256sum of artifact
> and its POM file:
> {code:xml}
>
> junit
> junit
> [4.0]
>
>
> [sha256 of junit pom file]
> [sha256sum of artifact (junit.jar)]
>
>
>
> {code}
> h3. Soft dependencies
> If soft, which are also called "ranged" or "dynamic", dependencies are used,
> then we could specify the public key (or multiple) of the keypair used to
> sign the artifacts
> {code:xml}
>
> junit
> junit
> [4.0,4.5)
>
> [secure fingerprint of OpenPGP key used to sign the junit
> artifact(s)]
>
>
>
> {code}
> I'm not sure if this is the right place to raise an feature request for the
> POM format itself. I've already tried to get in touch with the right people
> about this feature request, but failed. I'm willing to help designing and
> implementing this, but need guidance.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (SUREFIRE-2211) additionalClasspathElement with UNC path not working with failsafe > 3.0.0-M1
[ https://issues.apache.org/jira/browse/SUREFIRE-2211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17787147#comment-17787147 ] Robert Seidel edited comment on SUREFIRE-2211 at 11/17/23 11:41 AM: The first failing commit is this one: https://github.com/apache/maven-surefire/commit/f5cca5bcc2c85060c21c82eea0081d016cb86909#diff-8b7d87de30078d9465dc3a997b7121b77e70b150bde4678ffed0fade332ade51 I'm pretty sure https://github.com/apache/maven-surefire/commit/f5cca5bcc2c85060c21c82eea0081d016cb86909#diff-831c3693e03bf74af278a55df4af2ce453b674930f1932b4f7334b2417cbb595R169 destroys UNC paths. Here is how the java.class.path property looks like (from failsafe report xml): . Probably \ should be replaced with /, but double backshlash should not be replaced. was (Author: JIRAUSER295788): The first failing commit is this one: https://github.com/apache/maven-surefire/commit/f5cca5bcc2c85060c21c82eea0081d016cb86909#diff-8b7d87de30078d9465dc3a997b7121b77e70b150bde4678ffed0fade332ade51 I'm pretty sure https://github.com/apache/maven-surefire/commit/f5cca5bcc2c85060c21c82eea0081d016cb86909#diff-831c3693e03bf74af278a55df4af2ce453b674930f1932b4f7334b2417cbb595R169 destroys UNC paths. Here is how the java.class.path property looks like (from failsafe report xml): . Probably \ should be replaced with /, but \\ should not be replaced. > additionalClasspathElement with UNC path not working with failsafe > 3.0.0-M1 > - > > Key: SUREFIRE-2211 > URL: https://issues.apache.org/jira/browse/SUREFIRE-2211 > Project: Maven Surefire > Issue Type: Bug > Components: Maven Failsafe Plugin >Affects Versions: 3.0.0-M2, 3.2.2 > Environment: Windows JDK17.0.5+8 >Reporter: Robert Seidel >Priority: Major > > We are using the configuration parameter additionalClasspathElements > (https://maven.apache.org/surefire/maven-failsafe-plugin/integration-test-mojo.html#additionalClasspathElements) > to provide a log4j2 xml configuration during tests. There is configured an > UNC path like this //our-server/build/failsafe containing the file. > Until version 3.0.0-M2 everything was fine, the ressource could be found > within the class loader and log4j was configured correctly (so 3.0.0-M1 was > ok). > However since the Milestone 2 of version 3 and with all later versions, the > ressource could not be found within the classpath, leaving log4j unconfigured. > From the reporting xml the classpath is configured the same, but the class > loader behaves differently. > When using a normal path like c:/build/failsafe the ressource can be found > without issues. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (SUREFIRE-2211) additionalClasspathElement with UNC path not working with failsafe > 3.0.0-M1
[ https://issues.apache.org/jira/browse/SUREFIRE-2211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17787147#comment-17787147 ] Robert Seidel edited comment on SUREFIRE-2211 at 11/17/23 11:40 AM: The first failing commit is this one: https://github.com/apache/maven-surefire/commit/f5cca5bcc2c85060c21c82eea0081d016cb86909#diff-8b7d87de30078d9465dc3a997b7121b77e70b150bde4678ffed0fade332ade51 I'm pretty sure https://github.com/apache/maven-surefire/commit/f5cca5bcc2c85060c21c82eea0081d016cb86909#diff-831c3693e03bf74af278a55df4af2ce453b674930f1932b4f7334b2417cbb595R169 destroys UNC paths. Here is how the java.class.path property looks like (from failsafe report xml): . Probably \ should be replaced with /, but \\ should not be replaced. was (Author: JIRAUSER295788): The first failing commit is this one: https://github.com/apache/maven-surefire/commit/f5cca5bcc2c85060c21c82eea0081d016cb86909#diff-8b7d87de30078d9465dc3a997b7121b77e70b150bde4678ffed0fade332ade51 I'm pretty sure https://github.com/apache/maven-surefire/commit/f5cca5bcc2c85060c21c82eea0081d016cb86909#diff-831c3693e03bf74af278a55df4af2ce453b674930f1932b4f7334b2417cbb595R169 destroys UNC paths. Here is how the java.class.path property looks like (from failsafe report xml): . > additionalClasspathElement with UNC path not working with failsafe > 3.0.0-M1 > - > > Key: SUREFIRE-2211 > URL: https://issues.apache.org/jira/browse/SUREFIRE-2211 > Project: Maven Surefire > Issue Type: Bug > Components: Maven Failsafe Plugin >Affects Versions: 3.0.0-M2, 3.2.2 > Environment: Windows JDK17.0.5+8 >Reporter: Robert Seidel >Priority: Major > > We are using the configuration parameter additionalClasspathElements > (https://maven.apache.org/surefire/maven-failsafe-plugin/integration-test-mojo.html#additionalClasspathElements) > to provide a log4j2 xml configuration during tests. There is configured an > UNC path like this //our-server/build/failsafe containing the file. > Until version 3.0.0-M2 everything was fine, the ressource could be found > within the class loader and log4j was configured correctly (so 3.0.0-M1 was > ok). > However since the Milestone 2 of version 3 and with all later versions, the > ressource could not be found within the classpath, leaving log4j unconfigured. > From the reporting xml the classpath is configured the same, but the class > loader behaves differently. > When using a normal path like c:/build/failsafe the ressource can be found > without issues. -- This message was sent by Atlassian Jira (v8.20.10#820010)
