[jira] [Created] (MWRAPPER-99) Support MAVEN_ARGS environment variable
Piotr Karwasz created MWRAPPER-99:
-
Summary: Support MAVEN_ARGS environment variable
Key: MWRAPPER-99
URL: https://issues.apache.org/jira/browse/MWRAPPER-99
Project: Maven Wrapper
Issue Type: Improvement
Affects Versions: 3.1.1
Reporter: Piotr Karwasz
Starting with Maven 3.9.0 the {{mvn/mvn.cmd}} scripts support a {{MAVEN_ARGS}}
environment variable that can be used to pass additional arguments to Maven
(cf. [documentation|https://maven.apache.org/configure.html]).
The (undocumented?) {{MAVEN_CONFIG}} variable plays the same role in the
{{mvnw/mvnw.cmd}} scripts.
Maven Wrapper should probably switch to {{MAVEN_ARGS}} as variable name
(maintaining backward compatibility).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (MJLINK-75) Reproducibility of ZIP artifacts
Piotr Karwasz created MJLINK-75:
---
Summary: Reproducibility of ZIP artifacts
Key: MJLINK-75
URL: https://issues.apache.org/jira/browse/MJLINK-75
Project: Maven JLink Plugin
Issue Type: Bug
Affects Versions: 3.1.0
Reporter: Piotr Karwasz
The artifacts produced by this plugin do not use the
{{'project.build.outputTimestamp'}} property for the ZIP file entries and
therefore are not reproducible.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MJLINK-75) Reproducibility of ZIP artifacts
[
https://issues.apache.org/jira/browse/MJLINK-75?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17809656#comment-17809656
]
Piotr Karwasz commented on MJLINK-75:
-
[~bmarwell] ,
The {{lib/modules}} file generated by {{jlink}} in Java 21 is fully
reproducible.
The problem with reproducibility only appears in the ZIP file generated by
Maven JLink plugin. I'll try to submit a PR if I find the time.
> Reproducibility of ZIP artifacts
>
>
> Key: MJLINK-75
> URL: https://issues.apache.org/jira/browse/MJLINK-75
> Project: Maven JLink Plugin
> Issue Type: New Feature
>Affects Versions: 3.1.0
>Reporter: Piotr Karwasz
>Priority: Minor
> Fix For: 3.2.0
>
>
> The artifacts produced by this plugin do not use the
> {{'project.build.outputTimestamp'}} property for the ZIP file entries and
> therefore are not reproducible.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (MRESOLVER-288) Improve Ant task support for dependency management
Piotr Karwasz created MRESOLVER-288: --- Summary: Improve Ant task support for dependency management Key: MRESOLVER-288 URL: https://issues.apache.org/jira/browse/MRESOLVER-288 Project: Maven Resolver Issue Type: Improvement Components: Ant Tasks Affects Versions: ant-tasks-1.4.0 Reporter: Piotr Karwasz Ant tasks supports dependency management only for direct dependencies (due to Maven Model Builder), while there is no support for managed transitive dependencies. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MRESOLVER-288) Improve Ant task support for dependency management
[ https://issues.apache.org/jira/browse/MRESOLVER-288?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Piotr Karwasz updated MRESOLVER-288: Description: Ant tasks supports dependency management only for direct dependencies (due to Maven Model Builder), while there is no support for managed transitive dependencies. I submitted was:Ant tasks supports dependency management only for direct dependencies (due to Maven Model Builder), while there is no support for managed transitive dependencies. > Improve Ant task support for dependency management > -- > > Key: MRESOLVER-288 > URL: https://issues.apache.org/jira/browse/MRESOLVER-288 > Project: Maven Resolver > Issue Type: Improvement > Components: Ant Tasks >Affects Versions: ant-tasks-1.4.0 >Reporter: Piotr Karwasz >Priority: Minor > > Ant tasks supports dependency management only for direct dependencies (due to > Maven Model Builder), while there is no support for managed transitive > dependencies. > I submitted -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MRESOLVER-288) Improve Ant task support for dependency management
[ https://issues.apache.org/jira/browse/MRESOLVER-288?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Piotr Karwasz updated MRESOLVER-288: Description: Ant tasks supports dependency management only for direct dependencies (due to Maven Model Builder), while there is no support for managed transitive dependencies. I submitted a [Github PR|https://github.com/apache/maven-resolver-ant-tasks/pull/15] that adds support for dependency management whenever the dependency data come from a POM file. was: Ant tasks supports dependency management only for direct dependencies (due to Maven Model Builder), while there is no support for managed transitive dependencies. I submitted > Improve Ant task support for dependency management > -- > > Key: MRESOLVER-288 > URL: https://issues.apache.org/jira/browse/MRESOLVER-288 > Project: Maven Resolver > Issue Type: Improvement > Components: Ant Tasks >Affects Versions: ant-tasks-1.4.0 >Reporter: Piotr Karwasz >Priority: Minor > > Ant tasks supports dependency management only for direct dependencies (due to > Maven Model Builder), while there is no support for managed transitive > dependencies. > I submitted a [Github > PR|https://github.com/apache/maven-resolver-ant-tasks/pull/15] that adds > support for dependency management whenever the dependency data come from a > POM file. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MRESOLVER-192) Remove support for reading POMs
[
https://issues.apache.org/jira/browse/MRESOLVER-192?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17629393#comment-17629393
]
Piotr Karwasz commented on MRESOLVER-192:
-
[~michael-o],
IMHO even partial support for POMs is better than none. We use
{{maven-resolver-ant-tasks}} as a transitional tool until we migrate all our
custom Ant tasks to Maven. Having a common configuration format with Maven is a
big advantage that {{maven-resolver-ant-tasks}} has over other projects such as
Ivy.
> Remove support for reading POMs
> ---
>
> Key: MRESOLVER-192
> URL: https://issues.apache.org/jira/browse/MRESOLVER-192
> Project: Maven Resolver
> Issue Type: Task
> Components: Ant Tasks
>Affects Versions: ant-tasks-1.3.1
>Reporter: Michael Osipov
>Priority: Major
> Fix For: ant-tasks-2.0.0
>
>
> Since we don't want and cannot to keep up how Maven handles data over to
> Resolver, users are strongly advised to use Maven if they want to resolve
> POMs and not Maven Resolver Ant Tasks. This code part will be removed.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MRESOLVER-192) Remove support for reading POMs
[
https://issues.apache.org/jira/browse/MRESOLVER-192?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17629397#comment-17629397
]
Piotr Karwasz commented on MRESOLVER-192:
-
Yes, in the long term Ant will be entirely replaced by Maven. However in the
mean time we can profit from the better support for Maven offered IDEs (e.g.
automatic source download or reconfiguration after a version bump) during
development, while the release process uses a legacy Ant script.
I have no strong opinion whether support for POMs should be dropped or not, but
I though I should document our use case and I am grateful for the current
features of {{maven-resolver-ant-tasks}} you implemented.
> Remove support for reading POMs
> ---
>
> Key: MRESOLVER-192
> URL: https://issues.apache.org/jira/browse/MRESOLVER-192
> Project: Maven Resolver
> Issue Type: Task
> Components: Ant Tasks
>Affects Versions: ant-tasks-1.3.1
>Reporter: Michael Osipov
>Priority: Major
> Fix For: ant-tasks-2.0.0
>
>
> Since we don't want and cannot to keep up how Maven handles data over to
> Resolver, users are strongly advised to use Maven if they want to resolve
> POMs and not Maven Resolver Ant Tasks. This code part will be removed.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (SUREFIRE-2073) Surefire should fork before class scan
Piotr Karwasz created SUREFIRE-2073:
---
Summary: Surefire should fork before class scan
Key: SUREFIRE-2073
URL: https://issues.apache.org/jira/browse/SUREFIRE-2073
Project: Maven Surefire
Issue Type: Bug
Components: JUnit 5.x support
Affects Versions: 3.0.0-M6
Reporter: Piotr Karwasz
On projects using toolchains submodules can be compiled with a different Java
version than the main project. This can result in an
{{UnsupportedClassVersionError}} if the class scan is performed by the main
Maven JVM:
{noformat}
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-surefire-plugin:3.0.0-M5:test (test) on project
log4j-api-java9: Execution test of goal
org.apache.maven.plugins:maven-surefire-plugin:3.0.0-M5:test failed:
java.lang.UnsupportedClassVersionError:
org/apache/logging/log4j/util/java9/ProcessIdUtilTest has been compiled by a
more recent version of the Java Runtime (class file version 53.0), this version
of the Java Runtime only recognizes class file versions up to 52.0 -> [Help
1]{noformat}
Therefore Surefire should probably fork a new instance to scan for test classes
whenever {{forkCount}} is not zero.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (SUREFIRE-2073) Surefire should fork before class scan
[
https://issues.apache.org/jira/browse/SUREFIRE-2073?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17522734#comment-17522734
]
Piotr Karwasz commented on SUREFIRE-2073:
-
[~tibordigana],
Thank you for your fast answer. In the end I was able to work around this
limitation by compiling all test classes with Maven's default JVM (Java 8 in my
case) and use a separate source folder for {{{}module-info.java{}}}.
However in the long run I would like to solve the problem properly. The new
design you are referring to is the one from SUREFIRE-2049? Are there some
subtasks of this new design that are open to external contributors?
> Surefire should fork before class scan
> --
>
> Key: SUREFIRE-2073
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2073
> Project: Maven Surefire
> Issue Type: Bug
> Components: JUnit 5.x support
>Affects Versions: 3.0.0-M6
>Reporter: Piotr Karwasz
>Priority: Major
>
> On projects using toolchains submodules can be compiled with a different Java
> version than the main project. This can result in an
> {{UnsupportedClassVersionError}} if the class scan is performed by the main
> Maven JVM:
> {noformat}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-surefire-plugin:3.0.0-M5:test (test) on
> project log4j-api-java9: Execution test of goal
> org.apache.maven.plugins:maven-surefire-plugin:3.0.0-M5:test failed:
> java.lang.UnsupportedClassVersionError:
> org/apache/logging/log4j/util/java9/ProcessIdUtilTest has been compiled by a
> more recent version of the Java Runtime (class file version 53.0), this
> version of the Java Runtime only recognizes class file versions up to 52.0 ->
> [Help 1]{noformat}
> Therefore Surefire should probably fork a new instance to scan for test
> classes whenever {{forkCount}} is not zero.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (MNG-7905) Link to security issue reporting information
[
https://issues.apache.org/jira/browse/MNG-7905?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17901437#comment-17901437
]
Piotr Karwasz commented on MNG-7905:
We could define some special [developer
role|https://maven.apache.org/pom.html#Developers] for the Security Team.
I understand that the roles are tags and users are allowed to put anything in
there, but we could have a small taxonomy for the ASF and hope it will have a
wider adoption. The purpose of a "Security Team" role seems unambiguous to me.
We could also have an ASF-specific "Project Management Committee" developer
with a link to the current list of PMC members and an e-mail contact for the
developer mailing list.
> Link to security issue reporting information
>
>
> Key: MNG-7905
> URL: https://issues.apache.org/jira/browse/MNG-7905
> Project: Maven
> Issue Type: Wish
> Components: Core
>Reporter: Arnout Engelen
>Priority: Minor
>
> The pom.xml already has a place where a project can describe how to report
> issues to the project ('issueManagement'). It might be nice to also provide a
> place to describe how to report security issues to the project, as that might
> be different from regular issues?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MSHARED-1466) add default MANIFEST entry for release/target JDK
[
https://issues.apache.org/jira/browse/MSHARED-1466?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17929483#comment-17929483
]
Piotr Karwasz commented on MSHARED-1466:
{{Target-Jdk-Spec}} sounds good to me. I don't think it is worth
differentiating between {{maven.compiler.target}} and
{{maven.compiler.release}}, since only one of them will be effective.
> add default MANIFEST entry for release/target JDK
> -
>
> Key: MSHARED-1466
> URL: https://issues.apache.org/jira/browse/MSHARED-1466
> Project: Maven Shared Components
> Issue Type: New Feature
> Components: maven-archiver
>Affects Versions: maven-archiver-3.6.3, maven-archiver-4.0.0-beta-1
>Reporter: Herve Boutemy
>Priority: Major
>
> we currently have {{Build-Jdk-Spec}} by default
> https://maven.apache.org/shared-archives/maven-archiver-3.6.3/#manifest
> it documents the JDK major version used during the build: ok, why not
> but what users really need is the target bytecode version = the minimum JRE
> version that they'll have to use
> = what we put in documentation as "Java Version"
> https://maven.apache.org/shared-archives/maven-archiver-3.6.3/summary.html
> recording it in MANIFEST.MF would make it much more accessible:
> {{Target-Jdk-Spec}} and {{Release-Jdk-Spec}} based on
> {{maven.compiler.target}} or {{maven.compiler.release}} properties?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
