[jira] [Commented] (MJLINK-42) NullPointerException when running jlink:jlink
[
https://issues.apache.org/jira/browse/MJLINK-42?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17230809#comment-17230809
]
Benjamin Marwell commented on MJLINK-42:
> [https://github.com/aalmiray/jlink-mvn-mcve]
Cannot reproduce, but I used Java 14-openj9:
[https://gist.github.com/bmarwell/6f39756780b05233da2c66b912bc2afd]
Also works using JDK 13 (OpenJ9 from adoptopenjdk.net).
PS: You do not need to use {{mvn install}}. You can also use {{mvn clean
verify}}.
> NullPointerException when running jlink:jlink
> -
>
> Key: MJLINK-42
> URL: https://issues.apache.org/jira/browse/MJLINK-42
> Project: Maven JLink Plugin
> Issue Type: Bug
>Affects Versions: 3.0.0-alpha-1
> Environment: macOS 10.14.6
> openjdk version "11.0.4" 2019-07-16 LTS
> OpenJDK Runtime Environment Zulu11.33+15-CA (build 11.0.4+11-LTS)
> OpenJDK 64-Bit Server VM Zulu11.33+15-CA (build 11.0.4+11-LTS, mixed mode)
>Reporter: Dominique Gunia
>Priority: Major
>
> Hi!
> I am getting a NullPointerException when running jlink:jlink:
> {code:java}
> Execution default-cli of goal
> org.apache.maven.plugins:maven-jlink-plugin:3.0.0-alpha-1:jlink failed.
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:224)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:116)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:80)
> at
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
> at
> org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:120)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:347)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:154)
> at org.apache.maven.cli.MavenCli.execute(MavenCli.java:584)
> at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:213)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:157)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:566)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
> at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
> Caused by: org.apache.maven.plugin.PluginExecutionException: Execution
> default-cli of goal
> org.apache.maven.plugins:maven-jlink-plugin:3.0.0-alpha-1:jlink failed.
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:143)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
> ... 19 more
> Caused by: java.lang.NullPointerException
> at
> org.codehaus.plexus.languages.java.jpms.ResolvePathsRequest$1.toPath(ResolvePathsRequest.java:52)
> at
> org.codehaus.plexus.languages.java.jpms.ResolvePathsRequest$1.toPath(ResolvePathsRequest.java:48)
> at
> org.codehaus.plexus.languages.java.jpms.LocationManager.resolvePaths(LocationManager.java:109)
> at org.apache.maven.plugins.jlink.JLinkMojo.preparePaths(JLinkMojo.java:347)
> at org.apache.maven.plugins.jlink.JLinkMojo.execute(JLinkMojo.java:264)
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:132)
> ... 20 more
> {code}
> Is this a known problem? How can it be fixed?
> Thank you very much! :)
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [maven-jlink-plugin] bmarwell opened a new pull request #15: (no-issue) remove unused junit 4.
bmarwell opened a new pull request #15: URL: https://github.com/apache/maven-jlink-plugin/pull/15 … as `junit-vintage-engine` is already on the classpath. --- Following this checklist to help us incorporate your contribution quickly and easily: - [ ] Make sure there is a [JIRA issue](https://issues.apache.org/jira/browse/MJLINK) filed for the change (usually before you start working on it). Trivial changes like typos do not require a JIRA issue. Your pull request should address just this issue, without pulling in other changes. - [X] Each commit in the pull request should have a meaningful subject line and body. - [ ] Format the pull request title like `[MJLINK-XXX] - Fixes bug in ApproximateQuantiles`, where you replace `MJLINK-XXX` with the appropriate JIRA issue. Best practice is to use the JIRA issue title in the pull request title and in the first line of the commit message. - [X] Write a pull request description that is detailed enough to understand what the pull request does, how, and why. - [X] Run `mvn clean verify` to make sure basic checks pass. A more thorough check will be performed on your pull request automatically. - [X] You have run the integration tests successfully (`mvn -Prun-its clean verify`). If your pull request is about ~20 lines of code you don't need to sign an [Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf) if you are unsure please ask on the developers list. To make clear that you license your contribution under the [Apache License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0) you have to acknowledge this by using the following check-box. - [X] I hereby declare this contribution to be licenced under the [Apache License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0) - [X] In any other case, please file an [Apache Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf). 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-jlink-plugin] bmarwell opened a new pull request #14: [MJLINK-41] add support for --add-options argument (JDK14+).
bmarwell opened a new pull request #14: URL: https://github.com/apache/maven-jlink-plugin/pull/14 [Issue 41](https://issues.apache.org/jira/projects/MJLINK/issues/MJLINK-41) suggests three enhancements: * Choose the main module (the one with the main class that should be startet) => already implemented * Provide additional parameters (e.g. --enable-preview) => this PR * Optionally, choose between java and javaw (for GUI applications) TBD if possible. I suggest creating a new, dedicated issue for this request. To test the output: Unzip the resulting artifact and grep for the args in `lib/modules`. --- Following this checklist to help us incorporate your contribution quickly and easily: - [X] Make sure there is a [JIRA issue](https://issues.apache.org/jira/browse/MJLINK) filed for the change (usually before you start working on it). Trivial changes like typos do not require a JIRA issue. Your pull request should address just this issue, without pulling in other changes. - [X] Each commit in the pull request should have a meaningful subject line and body. - [X] Format the pull request title like `[MJLINK-XXX] - Fixes bug in ApproximateQuantiles`, where you replace `MJLINK-XXX` with the appropriate JIRA issue. Best practice is to use the JIRA issue title in the pull request title and in the first line of the commit message. - [X] Write a pull request description that is detailed enough to understand what the pull request does, how, and why. - [X] Run `mvn clean verify` to make sure basic checks pass. A more thorough check will be performed on your pull request automatically. - [X] You have run the integration tests successfully (`mvn -Prun-its clean verify`). If your pull request is about ~20 lines of code you don't need to sign an [Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf) if you are unsure please ask on the developers list. To make clear that you license your contribution under the [Apache License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0) you have to acknowledge this by using the following check-box. - [X] I hereby declare this contribution to be licenced under the [Apache License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0) - [X] In any other case, please file an [Apache Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf). 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MNG-3203) maven should execute compiler:compile and :test-compile in separate executions, to allow separate configuration
[ https://issues.apache.org/jira/browse/MNG-3203?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17230727#comment-17230727 ] Hudson commented on MNG-3203: - Build unstable in Jenkins: Maven » Maven TLP » maven » master #56 See https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/master/56/ > maven should execute compiler:compile and :test-compile in separate > executions, to allow separate configuration > --- > > Key: MNG-3203 > URL: https://issues.apache.org/jira/browse/MNG-3203 > Project: Maven > Issue Type: Improvement > Components: Plugins and Lifecycle >Affects Versions: 2.0.7 >Reporter: John Dennis Casey >Assignee: John Dennis Casey >Priority: Major > Fix For: 2.2.0 > > > Currently, it's impossible to configure the two default maven-compiler-plugin > mojos in the jar lifecycle (:compile and :test-compile) separately without > the configuration for one affecting both. This is because they are both > executed in the same (default) execution. We should be assigning these to > different execution id's, to allow separate configuration. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [maven-jlink-plugin] elharo commented on pull request #13: remove unused JUnit 5
elharo commented on pull request #13: URL: https://github.com/apache/maven-jlink-plugin/pull/13#issuecomment-726127203 I tend to fall on the side of not adding any unnecessary dependencies. The simpler we keep the tree the better. I'm also hesitant to introduce JUnit 5 into the project when everything else and all existing code is using JUnit 4. 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-jlink-plugin] bmarwell commented on pull request #13: remove unused JUnit 5
bmarwell commented on pull request #13: URL: https://github.com/apache/maven-jlink-plugin/pull/13#issuecomment-726123706 0 / -1. While true, this is unused, I'd rather see the junit tests executed by the junit-vintage-engine as this plugin is highly dependent on more recent java versions. As this is a new plugin, the changes would be fairly easy to do and no test would need to be rewritten. Btw: introduced by https://github.com/apache/maven-jlink-plugin/pull/9 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-jlink-plugin] elharo opened a new pull request #13: remove unused JUnit 5
elharo opened a new pull request #13: URL: https://github.com/apache/maven-jlink-plugin/pull/13 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Closed] (MNG-6216) ArrayIndexOutOfBoundsException when parsing POM
[ https://issues.apache.org/jira/browse/MNG-6216?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov closed MNG-6216. --- Fix Version/s: (was: 3.7.x-candidate) 3.7.0 Resolution: Fixed I believe that the actual race condition has been fixed by MNG-2802 with two sync contexts available. > ArrayIndexOutOfBoundsException when parsing POM > > > Key: MNG-6216 > URL: https://issues.apache.org/jira/browse/MNG-6216 > Project: Maven > Issue Type: Bug >Affects Versions: 3.5.0 >Reporter: Marc Savy >Priority: Major > Fix For: 3.7.0 > > Attachments: log > > > When building apiman https://github.com/apiman/apiman.git on Maven 3.5.0 the > XML parser seems to have some issues parsing the apiman-test-common module. > If you want to reproduce, you can simply use mvn clean install, no profiles > needed. > Log: https://gist.github.com/msavy/a1b4307fb238a543dfd6af426b42d446 > Also attached. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (MNG-6553) Packaging 'war' binding plugin upgrades
[ https://issues.apache.org/jira/browse/MNG-6553?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov updated MNG-6553: Fix Version/s: (was: 3.7.0-candidate) 3.7.0 > Packaging 'war' binding plugin upgrades > --- > > Key: MNG-6553 > URL: https://issues.apache.org/jira/browse/MNG-6553 > Project: Maven > Issue Type: Sub-task > Components: core, Dependencies >Affects Versions: 3.5.0, 3.6.0 >Reporter: Michael Osipov >Assignee: Michael Osipov >Priority: Major > Fix For: 3.7.0 > > > This affects: > ||groupId||artifactId||[previous > version|https://maven.apache.org/ref/3.5.0/maven-core/default-bindings.html#Plugin_bindings_for_war_packaging]||target > version|| > |org.apache.maven.plugins|maven-resources-plugin|2.6|3.2.0| > |org.apache.maven.plugins|maven-compiler-plugin|3.1|3.8.1| > |org.apache.maven.plugins|maven-surefire-plugin|2.12.4|3.0.0-M5| > |org.apache.maven.plugins|maven-war-plugin|2.4|3.3.1| > |org.apache.maven.plugins|maven-install-plugin|2.4|3.0.0-M1| > |org.apache.maven.plugins|maven-deploy-plugin|2.7|3.0.0-M1| -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MDEPLOY-131) use default repository when no url specified
[ https://issues.apache.org/jira/browse/MDEPLOY-131?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17230603#comment-17230603 ] Delany commented on MDEPLOY-131: [~rfscholte] If you think this is a code smell wait till you see the shell scripts I've had to deal with because my predecessors felt they couldn't get Maven to do what they needed. What's that, six votes now? https://issues.apache.org/jira/browse/MDEPLOY-277 > use default repository when no url specified > > > Key: MDEPLOY-131 > URL: https://issues.apache.org/jira/browse/MDEPLOY-131 > Project: Maven Deploy Plugin > Issue Type: Improvement > Components: deploy:deploy-file >Reporter: raymond domingo >Priority: Major > Labels: contributers-welcome > Attachments: DeployFileMojo.java, > maven-deploy-useProjectRepo-20170319.patch, patch_deploy_file_mojo.diff > > > When using the deploy goal there is no need to specify the url of the > repository. > When using deploy-file you DO need to specify the url. This is a problem, > because during development I like to deploy to snapshot repository and when > releasing i deploy to release repository and I can't add this logic to the > pom. > Thas is why I like the url paramter to become optional (backwards compatible) > and add default behaviour when it is null. It should just like the deploy > plugin use the default repository. Snapshot for snapshots and release for > none snapshot versions. > I added a patch file fixing this. > I also added complete source of patched Mojo -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-6754) Set the same timestamp in multi module builds
[ https://issues.apache.org/jira/browse/MNG-6754?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17230574#comment-17230574 ] Hudson commented on MNG-6754: - Build unstable in Jenkins: Maven » Maven TLP » maven » master #55 See https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/master/55/ > Set the same timestamp in multi module builds > - > > Key: MNG-6754 > URL: https://issues.apache.org/jira/browse/MNG-6754 > Project: Maven > Issue Type: Improvement > Components: Artifacts and Repositories, Deployment >Affects Versions: 3.6.3 >Reporter: Michael Angstadt >Assignee: Michael Osipov >Priority: Minor > Fix For: 3.7.0 > > > When multi module snapshots are built using Maven, the version timestamp may > be different for each module. This makes it difficult to quickly reference a > historical snapshot of a multi module project, which is something we might do > when determining when a bug was introduced. > [This Stack Overflow question|https://stackoverflow.com/q/45629816/2048802] > provides a good example of the problem. [The accepted > answer|https://stackoverflow.com/a/45715820/2048802] seems like a reasonable > solution, but does not appear to work. [Looking at the > code|https://github.com/apache/maven/blob/d9a0eee7fe2e2b1d77e59cf5bc772e758d29e47d/maven-resolver-provider/src/main/java/org/apache/maven/repository/internal/RemoteSnapshotMetadata.java#L85], > there does not appear to be a way to override the timestamp. > Please add a way to use a consistent timestamp for all modules in a build. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Moved] (MDEPLOY-277) better deploy-file integration
[ https://issues.apache.org/jira/browse/MDEPLOY-277?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov moved MNG-7017 to MDEPLOY-277: - Component/s: (was: Deployment) Key: MDEPLOY-277 (was: MNG-7017) Affects Version/s: (was: 3.6.3) Project: Maven Deploy Plugin (was: Maven) > better deploy-file integration > -- > > Key: MDEPLOY-277 > URL: https://issues.apache.org/jira/browse/MDEPLOY-277 > Project: Maven Deploy Plugin > Issue Type: Improvement >Reporter: Delany >Priority: Minor > > I have a script which deploys hundreds of static JARs to a Nexus repo. I use > the deploy-file goal, which requires the *url* and *repositoryId* properties. > Currently I have to hard-code these into the script. > I want to be able to use the repository url and id I set in the > distributionManagement of my project. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (MDEPLOY-277) better deploy-file integration
[ https://issues.apache.org/jira/browse/MDEPLOY-277?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov updated MDEPLOY-277: --- Affects Version/s: 3.0.0-M1 > better deploy-file integration > -- > > Key: MDEPLOY-277 > URL: https://issues.apache.org/jira/browse/MDEPLOY-277 > Project: Maven Deploy Plugin > Issue Type: Improvement >Affects Versions: 3.0.0-M1 >Reporter: Delany >Priority: Minor > > I have a script which deploys hundreds of static JARs to a Nexus repo. I use > the deploy-file goal, which requires the *url* and *repositoryId* properties. > Currently I have to hard-code these into the script. > I want to be able to use the repository url and id I set in the > distributionManagement of my project. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-7017) better deploy-file integration
[ https://issues.apache.org/jira/browse/MNG-7017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17230570#comment-17230570 ] Michael Osipov commented on MNG-7017: - bq. BTW, when I use deploy-file to deploy an artefact with a classifier, it overwrites the same artefact sans the classifier. Is there a ticket for this? Provide a reproducer with a new ticket. > better deploy-file integration > -- > > Key: MNG-7017 > URL: https://issues.apache.org/jira/browse/MNG-7017 > Project: Maven > Issue Type: Improvement > Components: Deployment >Affects Versions: 3.6.3 >Reporter: Delany >Priority: Minor > > I have a script which deploys hundreds of static JARs to a Nexus repo. I use > the deploy-file goal, which requires the *url* and *repositoryId* properties. > Currently I have to hard-code these into the script. > I want to be able to use the repository url and id I set in the > distributionManagement of my project. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (MNG-7017) better deploy-file integration
[ https://issues.apache.org/jira/browse/MNG-7017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17230570#comment-17230570 ] Michael Osipov edited comment on MNG-7017 at 11/12/20, 11:53 AM: - bq. BTW, when I use deploy-file to deploy an artefact with a classifier, it overwrites the same artefact sans the classifier. Is there a ticket for this? Provide a reproducer with a new ticket for MDEPLOY. was (Author: michael-o): bq. BTW, when I use deploy-file to deploy an artefact with a classifier, it overwrites the same artefact sans the classifier. Is there a ticket for this? Provide a reproducer with a new ticket. > better deploy-file integration > -- > > Key: MNG-7017 > URL: https://issues.apache.org/jira/browse/MNG-7017 > Project: Maven > Issue Type: Improvement > Components: Deployment >Affects Versions: 3.6.3 >Reporter: Delany >Priority: Minor > > I have a script which deploys hundreds of static JARs to a Nexus repo. I use > the deploy-file goal, which requires the *url* and *repositoryId* properties. > Currently I have to hard-code these into the script. > I want to be able to use the repository url and id I set in the > distributionManagement of my project. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-7017) better deploy-file integration
[ https://issues.apache.org/jira/browse/MNG-7017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17230567#comment-17230567 ] Michael Osipov commented on MNG-7017: - Can you provide a command line sample you are passing? > better deploy-file integration > -- > > Key: MNG-7017 > URL: https://issues.apache.org/jira/browse/MNG-7017 > Project: Maven > Issue Type: Improvement > Components: Deployment >Affects Versions: 3.6.3 >Reporter: Delany >Priority: Minor > > I have a script which deploys hundreds of static JARs to a Nexus repo. I use > the deploy-file goal, which requires the *url* and *repositoryId* properties. > Currently I have to hard-code these into the script. > I want to be able to use the repository url and id I set in the > distributionManagement of my project. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-7017) better deploy-file integration
[ https://issues.apache.org/jira/browse/MNG-7017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17230566#comment-17230566 ] Delany commented on MNG-7017: - BTW, when I use deploy-file to deploy an artefact with a classifier, it overwrites the same artefact sans the classifier. Is there a ticket for this? > better deploy-file integration > -- > > Key: MNG-7017 > URL: https://issues.apache.org/jira/browse/MNG-7017 > Project: Maven > Issue Type: Improvement > Components: Deployment >Affects Versions: 3.6.3 >Reporter: Delany >Priority: Minor > > I have a script which deploys hundreds of static JARs to a Nexus repo. I use > the deploy-file goal, which requires the *url* and *repositoryId* properties. > Currently I have to hard-code these into the script. > I want to be able to use the repository url and id I set in the > distributionManagement of my project. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-7017) better deploy-file integration
[
https://issues.apache.org/jira/browse/MNG-7017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17230562#comment-17230562
]
Delany commented on MNG-7017:
-
I set a property
_${build.remote}/repository/${build.name}-endorsed_
and then use that in _${repo.thirdparty}_
It makes it easier to override. That much is fine. Now I want to deploy to the
same repository.
I create a new profile with
_${repo.thirdparty}_ which I
only activate when provisioning repo.thirdparty with my static JARs. But the
deploy-file goal cannot access this URL.
> better deploy-file integration
> --
>
> Key: MNG-7017
> URL: https://issues.apache.org/jira/browse/MNG-7017
> Project: Maven
> Issue Type: Improvement
> Components: Deployment
>Affects Versions: 3.6.3
>Reporter: Delany
>Priority: Minor
>
> I have a script which deploys hundreds of static JARs to a Nexus repo. I use
> the deploy-file goal, which requires the *url* and *repositoryId* properties.
> Currently I have to hard-code these into the script.
> I want to be able to use the repository url and id I set in the
> distributionManagement of my project.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-7017) better deploy-file integration
[ https://issues.apache.org/jira/browse/MNG-7017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17230535#comment-17230535 ] Michael Osipov commented on MNG-7017: - This seems to be a contradiction. Manually deploying JARs means that they are not Maven managed. The POM will be generated on the repo. In which POM do you want to store those attributes? > better deploy-file integration > -- > > Key: MNG-7017 > URL: https://issues.apache.org/jira/browse/MNG-7017 > Project: Maven > Issue Type: Improvement > Components: Deployment >Affects Versions: 3.6.3 >Reporter: Delany >Priority: Minor > > I have a script which deploys hundreds of static JARs to a Nexus repo. I use > the deploy-file goal, which requires the *url* and *repositoryId* properties. > Currently I have to hard-code these into the script. > I want to be able to use the repository url and id I set in the > distributionManagement of my project. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (MNG-6118) Add option to execute goals on a specific module while building a multimodule project
[
https://issues.apache.org/jira/browse/MNG-6118?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov closed MNG-6118.
---
> Add option to execute goals on a specific module while building a multimodule
> project
> -
>
> Key: MNG-6118
> URL: https://issues.apache.org/jira/browse/MNG-6118
> Project: Maven
> Issue Type: Improvement
> Components: Command Line, Plugins and Lifecycle
>Reporter: Robert Scholte
>Assignee: Martin Kanters
>Priority: Major
> Fix For: 3.7.0
>
>
> Suppose we have a multimodule which results in a war. In the end we want to
> run this war in a container like jetty. Up until now the {{jetty:run}} is
> executed on every module, which doesn't make sense for the other modules.
> This is just one of several examples where you want to control on which
> module to execute a specific goal. In case of wars, the plugin could check
> for the packaging type, but in case of jars this won't work.
> There should be a generic solution to mark goals for a specific module.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (MNG-6981) Add --recursive option
[
https://issues.apache.org/jira/browse/MNG-6981?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov closed MNG-6981.
---
> Add --recursive option
> --
>
> Key: MNG-6981
> URL: https://issues.apache.org/jira/browse/MNG-6981
> Project: Maven
> Issue Type: New Feature
> Components: Command Line
>Affects Versions: 3.6.3
>Reporter: Knut Wannheden
>Assignee: Martin Kanters
>Priority: Minor
> Fix For: 3.7.0
>
>
> Since there is already a {{\--non-recursive}} option a new {{\--recursive}}
> option might be confusing, but let me explain my use case. I often use the
> {{-pl}} option and in a multi-module Maven project with more than just two
> "levels", I would like to be able to build a project (or set of projects)
> including all child-modules. This is, AFAIK, currently not possible and what
> I would like to use the new {{\--recursive}} (or similar) option for.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (MNG-6991) settings-defined local repository is not honored
[
https://issues.apache.org/jira/browse/MNG-6991?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov closed MNG-6991.
---
> settings-defined local repository is not honored
>
>
> Key: MNG-6991
> URL: https://issues.apache.org/jira/browse/MNG-6991
> Project: Maven
> Issue Type: Bug
>Reporter: François Guillot
>Assignee: Maarten Mulders
>Priority: Major
> Fix For: 3.7.0
>
>
> We have functional tests using the latest Maven snapshots and they started
> polluting the global ~/.m2/repository.
> [This
> commit|https://github.com/apache/maven/commit/ac80f5c2b93743c36e2b24ca91a47a0f13de981f]
> introduced a bug in the handling of the local repository definition.
> The local repository is taken from settings
> [here|https://github.com/apache/maven/blob/b962ff361aee64a291db588e9f88d86c5f9dee0c/maven-core/src/main/java/org/apache/maven/execution/DefaultMavenExecutionRequestPopulator.java#L234].
> but then, before, Maven was doing (in MavenCli)
> {code}
> String localRepoProperty = request.getUserProperties().getProperty(
> MavenCli.LOCAL_REPO_PROPERTY );
> if ( localRepoProperty == null )
> {
> localRepoProperty = request.getSystemProperties().getProperty(
> MavenCli.LOCAL_REPO_PROPERTY );
> }
> if ( localRepoProperty != null )
> {
> request.setLocalRepositoryPath( localRepoProperty );
> }
> {code}
> effectively replacing the local repository definition only if
> `maven.repo.local` was defined in user or system properties.
>
> After the commit mentioned above, the code does
> {code}
> request.setLocalRepositoryPath( determineLocalRepositoryPath( request
> ) );
> ...
> private String determineLocalRepositoryPath( final
> MavenExecutionRequest request )
> {
> return request.getUserProperties().getProperty(
> MavenCli.LOCAL_REPO_PROPERTY,
> request.getSystemProperties().getProperty(
> MavenCli.LOCAL_REPO_PROPERTY ) // null if not found
> );
> }
> {code}
> effectively _always_ replacing the local repository definition, potentially
> nulling it.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (MNG-7004) Refactor GitHub Actions environment variables since 'set-env' is deprecated
[
https://issues.apache.org/jira/browse/MNG-7004?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov closed MNG-7004.
---
> Refactor GitHub Actions environment variables since 'set-env' is deprecated
> ---
>
> Key: MNG-7004
> URL: https://issues.apache.org/jira/browse/MNG-7004
> Project: Maven
> Issue Type: Improvement
>Reporter: Martin Kanters
>Assignee: Martin Kanters
>Priority: Major
> Labels: up-for-grabs
> Fix For: 3.7.0
>
>
> See the warnings generated on a typical master build:
> [https://github.com/apache/maven/actions/runs/316060775]
> {{The `set-env` command is deprecated and will be disabled soon. Please
> upgrade to using Environment Files. For more information see:
> [https://github.blog/changelog/2020-10-01-github-actions-deprecating-set-env-and-add-path-commands/]}}
> The fix provided in the blog seems simple, but let's make sure it keeps on
> working afterwards.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (MNG-7002) Extend DefaultGraphBuilder unit tests to cover that child projects get included with the --pl switch
[ https://issues.apache.org/jira/browse/MNG-7002?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov closed MNG-7002. --- > Extend DefaultGraphBuilder unit tests to cover that child projects get > included with the --pl switch > > > Key: MNG-7002 > URL: https://issues.apache.org/jira/browse/MNG-7002 > Project: Maven > Issue Type: Improvement > Components: Reactor and workspace >Reporter: Martin Kanters >Assignee: Martin Kanters >Priority: Minor > Labels: up-for-grabs > Fix For: 3.7.0 > > > MNG-6981 was recently merged in master and is only covered in integration > tests. > Since > [DefaultGraphBuilderTest|https://github.com/apache/maven/blob/master/maven-core/src/test/java/org/apache/maven/graph/DefaultGraphBuilderTest.java] > now contains a multi module structure this flow can be tested in unit tests, > offering developers quicker feedback during development. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [maven-integration-testing] asfgit closed pull request #77: Mng 6754 version timestamp in multimodule build
asfgit closed pull request #77: URL: https://github.com/apache/maven-integration-testing/pull/77 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven] asfgit closed pull request #381: [MNG-6754] Set the same timestamp in multi module builds
asfgit closed pull request #381: URL: https://github.com/apache/maven/pull/381 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Closed] (MNG-6754) Set the same timestamp in multi module builds
[ https://issues.apache.org/jira/browse/MNG-6754?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov closed MNG-6754. --- Fix Version/s: (was: 3.7.0-candidate) 3.7.0 Resolution: Fixed Fixed with [72688805c4f95f8ab4ca9ab2ac2cd114667790c9|https://gitbox.apache.org/repos/asf?p=maven.git;a=commit;h=72688805c4f95f8ab4ca9ab2ac2cd114667790c9] and [51e5a9a2ccb7118d3ca9789d363bbcc4d34e8f39|https://gitbox.apache.org/repos/asf?p=maven-integration-testing.git;a=commit;h=51e5a9a2ccb7118d3ca9789d363bbcc4d34e8f39], [d502460347f1867e9ea452a3bb28dce9f889df66|https://gitbox.apache.org/repos/asf?p=maven-integration-testing.git;a=commit;h=d502460347f1867e9ea452a3bb28dce9f889df66]. > Set the same timestamp in multi module builds > - > > Key: MNG-6754 > URL: https://issues.apache.org/jira/browse/MNG-6754 > Project: Maven > Issue Type: Improvement > Components: Artifacts and Repositories, Deployment >Affects Versions: 3.6.3 >Reporter: Michael Angstadt >Assignee: Michael Osipov >Priority: Minor > Fix For: 3.7.0 > > > When multi module snapshots are built using Maven, the version timestamp may > be different for each module. This makes it difficult to quickly reference a > historical snapshot of a multi module project, which is something we might do > when determining when a bug was introduced. > [This Stack Overflow question|https://stackoverflow.com/q/45629816/2048802] > provides a good example of the problem. [The accepted > answer|https://stackoverflow.com/a/45715820/2048802] seems like a reasonable > solution, but does not appear to work. [Looking at the > code|https://github.com/apache/maven/blob/d9a0eee7fe2e2b1d77e59cf5bc772e758d29e47d/maven-resolver-provider/src/main/java/org/apache/maven/repository/internal/RemoteSnapshotMetadata.java#L85], > there does not appear to be a way to override the timestamp. > Please add a way to use a consistent timestamp for all modules in a build. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (MNG-6589) Document property maven.multiModuleProjectDirectory
[ https://issues.apache.org/jira/browse/MNG-6589?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17230485#comment-17230485 ] Michael Osipov edited comment on MNG-6589 at 11/12/20, 9:44 AM: Please raise a new ticket for a public, official property. was (Author: michael-o): Please raise a new for a public, official property. > Document property maven.multiModuleProjectDirectory > --- > > Key: MNG-6589 > URL: https://issues.apache.org/jira/browse/MNG-6589 > Project: Maven > Issue Type: Improvement > Components: Documentation: General >Affects Versions: 3.6.0 >Reporter: Arend v. Reinersdorff >Priority: Major > > I found out about maven.multiModuleProjectDirectory [on > Stackoverflow|https://stackoverflow.com/questions/29778262/what-is-maven-multimoduleprojectdirectory-used-for/29780763]. > This looks useful, but unfortunately there seems to be no documentation. > Could maybe be added in one of these locations: > * [https://cwiki.apache.org/confluence/display/MAVEN/Maven+Properties+Guide] > * > [http://maven.apache.org/ref/3.6.0/maven-model-builder/#Model_Interpolation] > Suggestion: > maven.multiModuleProjectDirectory - "The root directory of the multi module > build. Also set for single module builds. Since Maven 3.3.1" -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-6589) Document property maven.multiModuleProjectDirectory
[ https://issues.apache.org/jira/browse/MNG-6589?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17230485#comment-17230485 ] Michael Osipov commented on MNG-6589: - Please raise a new for a public, official property. > Document property maven.multiModuleProjectDirectory > --- > > Key: MNG-6589 > URL: https://issues.apache.org/jira/browse/MNG-6589 > Project: Maven > Issue Type: Improvement > Components: Documentation: General >Affects Versions: 3.6.0 >Reporter: Arend v. Reinersdorff >Priority: Major > > I found out about maven.multiModuleProjectDirectory [on > Stackoverflow|https://stackoverflow.com/questions/29778262/what-is-maven-multimoduleprojectdirectory-used-for/29780763]. > This looks useful, but unfortunately there seems to be no documentation. > Could maybe be added in one of these locations: > * [https://cwiki.apache.org/confluence/display/MAVEN/Maven+Properties+Guide] > * > [http://maven.apache.org/ref/3.6.0/maven-model-builder/#Model_Interpolation] > Suggestion: > maven.multiModuleProjectDirectory - "The root directory of the multi module > build. Also set for single module builds. Since Maven 3.3.1" -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-6589) Document property maven.multiModuleProjectDirectory
[
https://issues.apache.org/jira/browse/MNG-6589?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17230450#comment-17230450
]
Konrad Windszus commented on MNG-6589:
--
bq. If you think you need a better (official) solution, please create a ticket
for.
Actually there is already MNG-1958 which was closed as duplicate of MNG-5767.
That leads me to believe that property {{maven.multiModuleProjectDirector}} is
the solution for the request in MNG-1958 and therefore an official property. Am
I wrong here?
> Document property maven.multiModuleProjectDirectory
> ---
>
> Key: MNG-6589
> URL: https://issues.apache.org/jira/browse/MNG-6589
> Project: Maven
> Issue Type: Improvement
> Components: Documentation: General
>Affects Versions: 3.6.0
>Reporter: Arend v. Reinersdorff
>Priority: Major
>
> I found out about maven.multiModuleProjectDirectory [on
> Stackoverflow|https://stackoverflow.com/questions/29778262/what-is-maven-multimoduleprojectdirectory-used-for/29780763].
> This looks useful, but unfortunately there seems to be no documentation.
> Could maybe be added in one of these locations:
> * [https://cwiki.apache.org/confluence/display/MAVEN/Maven+Properties+Guide]
> *
> [http://maven.apache.org/ref/3.6.0/maven-model-builder/#Model_Interpolation]
> Suggestion:
> maven.multiModuleProjectDirectory - "The root directory of the multi module
> build. Also set for single module builds. Since Maven 3.3.1"
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (SUREFIRE-1830) Regression when running test using ServiceLoader
[
https://issues.apache.org/jira/browse/SUREFIRE-1830?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17230434#comment-17230434
]
Tibor Digana commented on SUREFIRE-1830:
[~d96knut]
No, it is not working properly, and {{useModulePath=false}} is only a temporal
workaround. The next release has a fix.
> Regression when running test using ServiceLoader
>
>
> Key: SUREFIRE-1830
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1830
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Failsafe Plugin
>Affects Versions: 3.0.0-M5
>Reporter: Knut Wannheden
>Assignee: Tibor Digana
>Priority: Major
>
> When running a test using failsafe which uses {{ServiceLoader}} to load a
> service which is defined in the {{src/test}} source folder, the
> {{ServiceLoader}} fails to find the service. This worked in 3.0.0-M4 and
> earlier releases. For a minimal example take a look at:
> [https://github.com/knutwannheden/maven-surefire-tccl-bug.|https://github.com/knutwannheden/maven-surefire-tccl-bug]
> Note that if the service is defined in {{src/main}} then the service is found.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (SUREFIRE-1830) Regression when running test using ServiceLoader
[
https://issues.apache.org/jira/browse/SUREFIRE-1830?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17230410#comment-17230410
]
Knut Wannheden commented on SUREFIRE-1830:
--
[~tibordigana] Thanks for taking another look at this. Just to clarify: Does
this mean that the 3.0.0-M5 release is working as designed and I have to set
{{useModulePath=false}} for my tests?
> Regression when running test using ServiceLoader
>
>
> Key: SUREFIRE-1830
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1830
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Failsafe Plugin
>Affects Versions: 3.0.0-M5
>Reporter: Knut Wannheden
>Assignee: Tibor Digana
>Priority: Major
>
> When running a test using failsafe which uses {{ServiceLoader}} to load a
> service which is defined in the {{src/test}} source folder, the
> {{ServiceLoader}} fails to find the service. This worked in 3.0.0-M4 and
> earlier releases. For a minimal example take a look at:
> [https://github.com/knutwannheden/maven-surefire-tccl-bug.|https://github.com/knutwannheden/maven-surefire-tccl-bug]
> Note that if the service is defined in {{src/main}} then the service is found.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
