Custom packaging
Hi, I'm writing a plugin that intends to support custom packaging types. The plugin's components.xml looks like: org.apache.maven.lifecycle.mapping.LifecycleMapping my-custom-type org.apache.maven.lifecycle.mapping.DefaultLifecycleMapping default com.foo:foo-maven-plugin:bar The user's project (where this plugin will be used) have a parent POM that binds an additional plugin into the package phase. The problem is that, when executing mvn package, it runs not only com.foo:foo-maven-plugin:bar, but also this additional plugin. Is there a way to avoid this? Note that the parent POM is under my control and I could make changes to it as well if needed. Cheers, -- Álvaro Sánchez-Mariscal alvaro.sanchezmaris...@gmail.com twitter.com/alvaro_sanchez
[GitHub] [maven-doxia] dependabot[bot] opened a new pull request #40: Bump httpclient from 4.5.12 to 4.5.13
dependabot[bot] opened a new pull request #40: URL: https://github.com/apache/maven-doxia/pull/40 Bumps httpclient from 4.5.12 to 4.5.13. [](https://docs.github.com/en/github/managing-security-vulnerabilities/configuring-github-dependabot-security-updates) Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting `@dependabot rebase`. [//]: # (dependabot-automerge-start) [//]: # (dependabot-automerge-end) --- Dependabot commands and options You can trigger Dependabot actions by commenting on this PR: - `@dependabot rebase` will rebase this PR - `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it - `@dependabot merge` will merge this PR after your CI passes on it - `@dependabot squash and merge` will squash and merge this PR after your CI passes on it - `@dependabot cancel merge` will cancel a previously requested merge and block automerging - `@dependabot reopen` will reopen this PR if it is closed - `@dependabot close` will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually - `@dependabot ignore this major version` will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this minor version` will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this dependency` will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself) 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 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
[GitHub] [maven-site] kwin commented on pull request #205: [MNG-6994] clarify repository order
kwin commented on pull request #205: URL: https://github.com/apache/maven-site/pull/205#issuecomment-704502139 Anything else left to change before this can be merged? 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 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Release Maven Resolver version 1.6.1
Hi, +1 from me. Kind regards Karl Heinz Marbaise On 02.10.20 20:32, Michael Osipov wrote: Hi, We solved 25 issues: https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12320628=12348853 There are still a couple of issues left in JIRA: https://issues.apache.org/jira/projects/MRESOLVER/issues?filter=allopenissues Staging repo: https://repository.apache.org/content/repositories/maven-1607/ https://repository.apache.org/content/repositories/maven-1607/org/apache/maven/resolver/maven-resolver/1.6.1/maven-resolver-1.6.1-source-release.zip Source release checksum(s): maven-resolver-1.6.1-source-release.zip ab45c772e9af4061977feb4fb48e3ae9ddd8cbebe41ada40f2a762504e96fd4c0fd4a939ab707667d9888caf92ab9fa354abe0624031c7049b7a2cb133421ddd Staging site: https://maven.apache.org/resolver-archives/resolver-LATEST/ Guide to testing staged releases: https://maven.apache.org/guides/development/guide-testing-releases.html Note: This Resolver offers salvation from a 13.5 years old feature request: MNG-2802 Yes, you can have now concurrent-safe access to your local Maven repository synchronized with Redis. Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Release Maven Resolver version 1.6.1
I need more binding votes. Master is back do not and does not affect this release. @elharo, shall I still cast your vote as -1? Michael Am 2020-10-02 um 20:32 schrieb Michael Osipov: Hi, We solved 25 issues: https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12320628=12348853 There are still a couple of issues left in JIRA: https://issues.apache.org/jira/projects/MRESOLVER/issues?filter=allopenissues Staging repo: https://repository.apache.org/content/repositories/maven-1607/ https://repository.apache.org/content/repositories/maven-1607/org/apache/maven/resolver/maven-resolver/1.6.1/maven-resolver-1.6.1-source-release.zip Source release checksum(s): maven-resolver-1.6.1-source-release.zip ab45c772e9af4061977feb4fb48e3ae9ddd8cbebe41ada40f2a762504e96fd4c0fd4a939ab707667d9888caf92ab9fa354abe0624031c7049b7a2cb133421ddd Staging site: https://maven.apache.org/resolver-archives/resolver-LATEST/ Guide to testing staged releases: https://maven.apache.org/guides/development/guide-testing-releases.html Note: This Resolver offers salvation from a 13.5 years old feature request: MNG-2802 Yes, you can have now concurrent-safe access to your local Maven repository synchronized with Redis. Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Release Maven Resolver version 1.6.1
Am 2020-10-06 um 01:32 schrieb Dan Tran: +1 none-binding However, I still see random compilation failure at my multiple thread build. I am hoping the latest maven-resolver would make it go away :-) Please share, I can quite quickly determine whether this is Resolver or not. On Sun, Oct 4, 2020 at 3:16 PM Hervé BOUTEMY wrote: +1 this time, I could reproduce the build, done with JDK 8 on Windows Regards, Hervé Le vendredi 2 octobre 2020, 20:32:20 CEST Michael Osipov a écrit : Hi, We solved 25 issues: https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12320628 rsion=12348853 There are still a couple of issues left in JIRA: https://issues.apache.org/jira/projects/MRESOLVER/issues?filter=allopenissue s Staging repo: https://repository.apache.org/content/repositories/maven-1607/ https://repository.apache.org/content/repositories/maven-1607/org/apache/mav en/resolver/maven-resolver/1.6.1/maven-resolver-1.6.1-source-release.zip Source release checksum(s): maven-resolver-1.6.1-source-release.zip ab45c772e9af4061977feb4fb48e3ae9ddd8cbebe41ada40f2a762504e96fd4c0fd4a939ab70 7667d9888caf92ab9fa354abe0624031c7049b7a2cb133421ddd Staging site: https://maven.apache.org/resolver-archives/resolver-LATEST/ Guide to testing staged releases: https://maven.apache.org/guides/development/guide-testing-releases.html Note: This Resolver offers salvation from a 13.5 years old feature request: MNG-2802 Yes, you can have now concurrent-safe access to your local Maven repository synchronized with Redis. Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [maven-resolver] branch master updated (aa5e9b1 -> b85faae)
Am 2020-10-05 um 23:39 schrieb Hervé BOUTEMY: moving the plugin to release profile, then have a release build different from the usual SNAPSHOT build does not look a good idea if we need to avoid building with JDK 7 because JDK 8 is required, it's up to Jenkins file to select We already do that for Maven Artifact Transfer for example https://github.com/apache/maven-artifact-transfer/blob/master/Jenkinsfile Merci, this is exactly what I wanted, but did not know where to find. Master is back to normal! - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Maven EAR Plugin 3.1.0 bugs - review pending. Was: [ANN] Apache Maven EAR Plugin 3.1.0 Released
Hi, There was a major bug found in Maven EAR Plugin 3.1.0 (i.e. regression comparing to previous version - 3.0.2) - https://issues.apache.org/jira/browse/MEAR-287. This bug makes Maven EAR Plugin 3.1.0 unusable for such a common scenario like building of maven project without invocation of clean goal. Fix for the bug - https://github.com/apache/maven-ear-plugin/pull/17 - was provided (5 days ago). We need help of community to complete review and release 3.1.1 version. There are 2 additional bugfixes pending (awaiting for review): 1. https://github.com/apache/maven-ear-plugin/pull/19 fix for https://issues.apache.org/jira/browse/MEAR-267, 2. https://github.com/apache/maven-ear-plugin/pull/18 fix for https://issues.apache.org/jira/browse/MEAR-286 and further enhancement of maven project. I appreciate if we could review and complete all 3 pull requests to include them into 3.1.1 version. Thank you. Regards, Marat Abrarov. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Unexpected dependency requirement when performing "package", but not "install"
I just wanted to mention that I saw that a pull request containing a fix for this nuisance was made the same day I opened the ticket in Jira. This is impressive and very much appreciated, so thank you for that! Hoping to see this fix in the next milestone release of Surefire, then! Have a great week! - Eric L On Thu, Oct 1, 2020 at 1:49 PM Eric Lilja wrote: > I opened https://issues.apache.org/jira/browse/SUREFIRE-1850 > > Thanks! > > - Eric L > > On Wed, Sep 30, 2020 at 11:30 PM Eric Lilja wrote: > >> Of course, I will do it when I get to the office tomorrow, thanks! >> >> - Eric L >> >> On Wed, Sep 30, 2020 at 5:51 PM Elliotte Rusty Harold >> wrote: >> >>> Looks like we don't need that. Can you file a bug in Jira? >>> >>> On Wed, Sep 30, 2020 at 11:12 AM Eric Lilja >>> wrote: >>> > >>> > Hello, I have to set up Maven on a system which is completely offline, >>> > restricted to work on a few, select projects. >>> > >>> > During testing, everything initially looked good, I could perform "mvn >>> > clean install" in all projects without issue, and could perform other >>> > Maven-task as well, Intellij was happy, it could resolve all projects >>> > fully, run all test cases etc, and did not complain about any missing >>> > artifacts. >>> > >>> > However, then I noticed, almost by accident, that I couldn't do >>> "package" >>> > or "verify" (which was odd, since install works, which is a later >>> phase!), >>> > because then surefire (3.0.0-M5) would complain it was >>> > missing org.apache.maven:maven-toolchain:jar:3.0-alpha-2 (or one of its >>> > dependencies). >>> > >>> > Why Surefire would suddenly need that artifact (some old alpha from >>> > 2009..), during package- or verify-phase feels weird to me since the >>> later >>> > phase, install, works, and install entails packaging and verification >>> > (compile also works, btw) >>> > >>> > surefire-3.0.0-M3 also suffers from this issue...2.18.1 does not >>> > >>> > What's going on here? Is my analysis correct, that if I can do "mvn >>> clean >>> > install", then "mvn clean package" should not be an issue, since >>> installs >>> > entails packaging? >>> > >>> > For this exotic setup, we can easily work around this, obviously, but >>> it >>> > feels like a bug to me so I wanted to share it with you >>> > >>> > - Eric L >>> >>> >>> >>> -- >>> Elliotte Rusty Harold >>> elh...@ibiblio.org >>> >>> - >>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >>> For additional commands, e-mail: dev-h...@maven.apache.org >>> >>>
