[jira] [Comment Edited] (MRELEASE-1011) Deploy without deleting local copy
[ https://issues.apache.org/jira/browse/MRELEASE-1011?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16570949#comment-16570949 ] Chris Hennick edited comment on MRELEASE-1011 at 8/7/18 12:08 AM: -- Per some discussion at [https://groups.google.com/a/glists.sonatype.com/forum/#!topic/nexus-users/KfZQ1QTpvgY] I may be able to use [nexus-staging-maven-plugin|https://github.com/sonatype/nexus-maven-plugins/tree/master/staging/maven-plugin] for the releases themselves, and maven-release-plugin only to set version numbers. (That does introduce the anomaly of having to alter a build in order to promote it, since the releases on Maven Central have to include the pom.xml, which in turn has to include a version number that either does or doesn't end in -SNAPSHOT. But I'm sure enough other people have been in that situation for there to be standard solutions to any problems it might cause.) was (Author: pr0methean): Per some discussion at [https://groups.google.com/a/glists.sonatype.com/forum/#!topic/nexus-users/KfZQ1QTpvgY] I may be able to use [nexus-staging-maven-plugin|https://github.com/sonatype/nexus-maven-plugins/tree/master/staging/maven-plugin] for the releases themselves, and maven-release-plugin only to set version numbers (although that does introduce the anomaly of having to alter a build in order to promote it, since the releases on Maven Central have to include the pom.xml, which in turn has to include a version number that either does or doesn't end in -SNAPSHOT). > Deploy without deleting local copy > -- > > Key: MRELEASE-1011 > URL: https://issues.apache.org/jira/browse/MRELEASE-1011 > Project: Maven Release Plugin > Issue Type: Improvement >Affects Versions: 2.5.3 >Reporter: Chris Hennick >Priority: Major > > The `nexus-staging` plugin's `close` and `release` goals require that the > local copy of the release still exist, but the `deploy` goal cleans it up. > Thus, on my Maven Central project, > [https://github.com/Pr0methean/BetterRandom/commit/e3003a47d1dc85b42019612fff8d5431bae601a1] > (which seems to be the only way to automate the steps of closing and > releasing after uploading) fails. How can I perform the deletion separately > from the rest of the `deploy` goal so that it will succeed? This is blocking > my adoption of continuous delivery. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (MRELEASE-1011) Deploy without deleting local copy
[ https://issues.apache.org/jira/browse/MRELEASE-1011?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16570949#comment-16570949 ] Chris Hennick edited comment on MRELEASE-1011 at 8/7/18 12:07 AM: -- Per some discussion at [https://groups.google.com/a/glists.sonatype.com/forum/#!topic/nexus-users/KfZQ1QTpvgY] I may be able to use [nexus-staging-maven-plugin|https://github.com/sonatype/nexus-maven-plugins/tree/master/staging/maven-plugin] for the releases themselves, and maven-release-plugin only to set version numbers (although that does introduce the anomaly of having to alter a build in order to promote it, since the releases on Maven Central have to include the pom.xml, which in turn has to include a version number that either does or doesn't end in -SNAPSHOT). was (Author: pr0methean): Per some discussion at [https://groups.google.com/a/glists.sonatype.com/forum/#!topic/nexus-users/KfZQ1QTpvgY|https://groups.google.com/a/glists.sonatype.com/forum/#!topic/nexus-users/KfZQ1QTpvgY.] I may be able to use [nexus-staging-maven-plugin|https://github.com/sonatype/nexus-maven-plugins/tree/master/staging/maven-plugin] for the releases themselves, and maven-release-plugin only to set version numbers (although that does introduce the anomaly of having to alter a build in order to promote it, since the releases on Maven Central have to include the pom.xml). > Deploy without deleting local copy > -- > > Key: MRELEASE-1011 > URL: https://issues.apache.org/jira/browse/MRELEASE-1011 > Project: Maven Release Plugin > Issue Type: Improvement >Affects Versions: 2.5.3 >Reporter: Chris Hennick >Priority: Major > > The `nexus-staging` plugin's `close` and `release` goals require that the > local copy of the release still exist, but the `deploy` goal cleans it up. > Thus, on my Maven Central project, > [https://github.com/Pr0methean/BetterRandom/commit/e3003a47d1dc85b42019612fff8d5431bae601a1] > (which seems to be the only way to automate the steps of closing and > releasing after uploading) fails. How can I perform the deletion separately > from the rest of the `deploy` goal so that it will succeed? This is blocking > my adoption of continuous delivery. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MRELEASE-1011) Deploy without deleting local copy
[ https://issues.apache.org/jira/browse/MRELEASE-1011?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16570949#comment-16570949 ] Chris Hennick commented on MRELEASE-1011: - Per some discussion at [https://groups.google.com/a/glists.sonatype.com/forum/#!topic/nexus-users/KfZQ1QTpvgY|https://groups.google.com/a/glists.sonatype.com/forum/#!topic/nexus-users/KfZQ1QTpvgY.] I may be able to use [nexus-staging-maven-plugin|https://github.com/sonatype/nexus-maven-plugins/tree/master/staging/maven-plugin] for the releases themselves, and maven-release-plugin only to set version numbers (although that does introduce the anomaly of having to alter a build in order to promote it, since the releases on Maven Central have to include the pom.xml). > Deploy without deleting local copy > -- > > Key: MRELEASE-1011 > URL: https://issues.apache.org/jira/browse/MRELEASE-1011 > Project: Maven Release Plugin > Issue Type: Improvement >Affects Versions: 2.5.3 >Reporter: Chris Hennick >Priority: Major > > The `nexus-staging` plugin's `close` and `release` goals require that the > local copy of the release still exist, but the `deploy` goal cleans it up. > Thus, on my Maven Central project, > [https://github.com/Pr0methean/BetterRandom/commit/e3003a47d1dc85b42019612fff8d5431bae601a1] > (which seems to be the only way to automate the steps of closing and > releasing after uploading) fails. How can I perform the deletion separately > from the rest of the `deploy` goal so that it will succeed? This is blocking > my adoption of continuous delivery. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MNG-6261) Relative parent POM resolution failing in 3.5.0 with complex multimodule builds
[
https://issues.apache.org/jira/browse/MNG-6261?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16570830#comment-16570830
]
Robert Scholte commented on MNG-6261:
-
I think the cleanest fix is to wrap pomFile in a {{FileModelSource}} and do an
{{equals()}} with {{expectedParentSource}}. This also means that it is easy to
unittest , verify all combinations of drive letters with
FileModelSource.equals(). Hence I marked it as for-the-grabs. Now waiting for
somebody to pick this up.
> Relative parent POM resolution failing in 3.5.0 with complex multimodule
> builds
> ---
>
> Key: MNG-6261
> URL: https://issues.apache.org/jira/browse/MNG-6261
> Project: Maven
> Issue Type: Bug
>Affects Versions: 3.5.0
>Reporter: Dawid Weiss
>Assignee: Robert Scholte
>Priority: Minor
> Labels: up-for-grabs
> Fix For: 3.6.x-candidate
>
> Attachments: capture-6.png, repro.zip
>
>
> In my effort to upgrade an existing (fairly complex) Maven build to Java
> 1.9.0 I updated Maven to 3.5.0 (from 3.3.9). Unfortunately I get errors when
> the project's modules are resolved:
> {noformat}
> > mvn validate
> [FATAL] Non-resolvable parent POM for
> com.carrotsearch.lingo4g:lingo4g-public-bom:[unknown-version]: Could not find
> artifact com.carrotsearch.lingo4g:lingo4g-public:pom:1.6.0-SNAPSHOT and
> 'parent.relativePath' points at wrong local POM @ line 5, column 11
> ...
> (and many follow).
> {noformat}
> This build has a correct pom parent-structure (a tree), but is fairly complex
> -- the submodule hierarchy is not aligned with parent-child pom hierarchy
> (it's best to look at the repro code to understand how it's structured).
> However, it's been working correctly with all prior Maven versions and I
> wonder if it's a regression bug or maybe underspecified Maven requirement
> (that should be enforced with a warning and not lead to this odd runtime
> message).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (MPOM-205) create checksum in target/ during release
[ https://issues.apache.org/jira/browse/MPOM-205?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hervé Boutemy updated MPOM-205: --- Description: currently, during Apache release, checksums are not created in target/ directory: checksums are created on the fly during deploy to the Maven repository while source release archive and its signature are available in target/, checksums are not there: this gives people the bad habit to download everything (not only checksums) from Apache Nexus repository after deploy to copy to Apache /dist/ it would be useful to have the checksums available in target/ this would also prepare having new Apache checksums requirements for Apache mirroring was: currently, during Apache release, checksums are not created in target/ directory: checksums are created on the fly during deploy to the Maven repository while source release archive and its signature are available in target/, checksums are not there: this give people the bad habit to download from Apache Nexus repository after deploy to copy to Apache /dist/ it would be useful to have the checksums available in target/ this would also prepare having new Apache checksums requirements for Apache mirroring > create checksum in target/ during release > - > > Key: MPOM-205 > URL: https://issues.apache.org/jira/browse/MPOM-205 > Project: Maven POMs > Issue Type: New Feature > Components: asf >Affects Versions: ASF-20 >Reporter: Hervé Boutemy >Priority: Major > > currently, during Apache release, checksums are not created in target/ > directory: checksums are created on the fly during deploy to the Maven > repository > while source release archive and its signature are available in target/, > checksums are not there: this gives people the bad habit to download > everything (not only checksums) from Apache Nexus repository after deploy to > copy to Apache /dist/ > it would be useful to have the checksums available in target/ > this would also prepare having new Apache checksums requirements for Apache > mirroring -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (MPOM-205) create checksum in target/ during release
[ https://issues.apache.org/jira/browse/MPOM-205?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hervé Boutemy updated MPOM-205: --- Summary: create checksum in target/ during release (was: create checksum in target during release) > create checksum in target/ during release > - > > Key: MPOM-205 > URL: https://issues.apache.org/jira/browse/MPOM-205 > Project: Maven POMs > Issue Type: New Feature > Components: asf >Affects Versions: ASF-20 >Reporter: Hervé Boutemy >Priority: Major > > currently, during Apache release, checksums are not created in target/ > directory: checksums are created on the fly during deploy to the Maven > repository > while source release archive and its signature are available in target/, > checksums are not there: this give people the bad habit to download from > Apache Nexus repository after deploy to copy to Apache /dist/ > it would be useful to have the checksums available in target/ > this would also prepare having new Apache checksums requirements for Apache > mirroring -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (MPOM-205) create checksum in target during release
[ https://issues.apache.org/jira/browse/MPOM-205?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hervé Boutemy updated MPOM-205: --- Description: currently, during Apache release, checksums are not created in target/ directory: checksums are created on the fly during deploy to the Maven repository while source release archive and its signature are available in target/, checksums are not there: this give people the bad habit to download from Apache Nexus repository after deploy to copy to Apache /dist/ it would be useful to have the checksums available in target/ this would also prepare having new Apache checksums requirements for Apache mirroring was: currently, during Apache release, checksums are not created in target/ directory: checksums are created on the fly during deploy to the Maven repository while source release archive and its signature is available in target/, checksums are not there: this give people the bad habit to download from Apache Nexus repository it would be useful to have the checksums available in target/ this would also prepare having new Apache checksums requirements for Apache mirroring > create checksum in target during release > > > Key: MPOM-205 > URL: https://issues.apache.org/jira/browse/MPOM-205 > Project: Maven POMs > Issue Type: New Feature > Components: asf >Affects Versions: ASF-20 >Reporter: Hervé Boutemy >Priority: Major > > currently, during Apache release, checksums are not created in target/ > directory: checksums are created on the fly during deploy to the Maven > repository > while source release archive and its signature are available in target/, > checksums are not there: this give people the bad habit to download from > Apache Nexus repository after deploy to copy to Apache /dist/ > it would be useful to have the checksums available in target/ > this would also prepare having new Apache checksums requirements for Apache > mirroring -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (MPOM-205) create checksum in target during release
Hervé Boutemy created MPOM-205: -- Summary: create checksum in target during release Key: MPOM-205 URL: https://issues.apache.org/jira/browse/MPOM-205 Project: Maven POMs Issue Type: New Feature Components: asf Affects Versions: ASF-20 Reporter: Hervé Boutemy currently, during Apache release, checksums are not created in target/ directory: checksums are created on the fly during deploy to the Maven repository while source release archive and its signature is available in target/, checksums are not there: this give people the bad habit to download from Apache Nexus repository it would be useful to have the checksums available in target/ this would also prepare having new Apache checksums requirements for Apache mirroring -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] thorntonrp opened a new pull request #176: Fix to prevent warning due to CI-friendly version in the parent pom
thorntonrp opened a new pull request #176: Fix to prevent warning due to CI-friendly version in the parent pom URL: https://github.com/apache/maven/pull/176 This PR fixes the following issue: https://issues.apache.org/jira/browse/MNG-6455 This is an automated message from the Apache Git Service. To respond to the message, please log on 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 With regards, Apache Git Services
[jira] [Created] (MNG-6455) ci-friendly version in parent pom displays build warning in child project
Robert Thornton created MNG-6455:
Summary: ci-friendly version in parent pom displays build warning
in child project
Key: MNG-6455
URL: https://issues.apache.org/jira/browse/MNG-6455
Project: Maven
Issue Type: Bug
Reporter: Robert Thornton
I have a project that is using a parent project with ci-friendly versions, but
while Maven is scanning for projects, it is looking for
"my-parent-$%7Brevision%7D.pom" instead of "my-parent-1.0-a8e435". The project
builds, but a warning is printed which confuses some of the teams using my
parent pom.
{{[INFO] Scanning for projects...}}
{{Downloading from mvn-lds:
https://code.myserver.org/artifactory/mvn-repo/my/stack/platform/my-parent/$%7Brevision%7D/my-parent-$%7Brevision%7D.pom}}
{{[WARNING] Failed to build parent project for
my.stack.platform:my-project:pom:4.8.2.RELEASE}}
I've tracked the issue down to DefaultProjectBuilder, line 671 where
`project.getParentArtifact()` is returning an Artifact object with the
unresolved version.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MRELEASE-1011) Deploy without deleting local copy
[ https://issues.apache.org/jira/browse/MRELEASE-1011?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16570668#comment-16570668 ] Robert Scholte commented on MRELEASE-1011: -- I don't think your question is unique, but you should verify this with the maintainers of the [nexus-staging-maven-plugin|https://github.com/sonatype/nexus-maven-plugins/tree/master/staging/maven-plugin]. I wonder if the maven-release-plugin fits in the continuous delivery process, every commit is a potential release, so the tagging is overhead, the revision is good enough. Though you must ensure a stable build, probably with several maven-enforcer rules. > Deploy without deleting local copy > -- > > Key: MRELEASE-1011 > URL: https://issues.apache.org/jira/browse/MRELEASE-1011 > Project: Maven Release Plugin > Issue Type: Improvement >Affects Versions: 2.5.3 >Reporter: Chris Hennick >Priority: Major > > The `nexus-staging` plugin's `close` and `release` goals require that the > local copy of the release still exist, but the `deploy` goal cleans it up. > Thus, on my Maven Central project, > [https://github.com/Pr0methean/BetterRandom/commit/e3003a47d1dc85b42019612fff8d5431bae601a1] > (which seems to be the only way to automate the steps of closing and > releasing after uploading) fails. How can I perform the deletion separately > from the rest of the `deploy` goal so that it will succeed? This is blocking > my adoption of continuous delivery. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (MRELEASE-1011) Deploy without deleting local copy
Chris Hennick created MRELEASE-1011: --- Summary: Deploy without deleting local copy Key: MRELEASE-1011 URL: https://issues.apache.org/jira/browse/MRELEASE-1011 Project: Maven Release Plugin Issue Type: Improvement Affects Versions: 2.5.3 Reporter: Chris Hennick The `nexus-staging` plugin's `close` and `release` goals require that the local copy of the release still exist, but the `deploy` goal cleans it up. Thus, on my Maven Central project, [https://github.com/Pr0methean/BetterRandom/commit/e3003a47d1dc85b42019612fff8d5431bae601a1] (which seems to be the only way to automate the steps of closing and releasing after uploading) fails. How can I perform the deletion separately from the rest of the `deploy` goal so that it will succeed? This is blocking my adoption of continuous delivery. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MRELEASE-954) maven-release-plugin should push less often to git server
[ https://issues.apache.org/jira/browse/MRELEASE-954?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16570341#comment-16570341 ] Thomas Mortagne commented on MRELEASE-954: -- Big +1 on this one especially ending up on the remote repository with non SNAPSHOT version even if for a brief period of time. We just been hit by this issue with Jenkins being faster than the release plugin so yes it can happen :) > maven-release-plugin should push less often to git server > - > > Key: MRELEASE-954 > URL: https://issues.apache.org/jira/browse/MRELEASE-954 > Project: Maven Release Plugin > Issue Type: Improvement > Components: Git >Affects Versions: 2.5.3 >Reporter: Markus Karg >Priority: Minor > > mvn release:prepare runs three times git push which is bad: > A single push at the end is enough to bring all commits and tags to the > server finally > It consumes more time than essentially necessary > It is risky, because in case the first POM change A-SNAPSHOT -> A is pushed > to the server but an error happens (bug in plugin, crash of client, whatever) > then a "half prepared" state is on the server (the second POM change A -> > B-SNAPSHOT is missing) and you cannot auto-recover from that without manual > action (as mvn release:clean does not undo the tag). If there is only one > single push at the end, then EVERYTHING, two commits and a tag, is pushed as > a single transaction to the server, which is much better! -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (MRESOLVER-53) Document runtime exceptions
Elliotte Rusty Harold created MRESOLVER-53: -- Summary: Document runtime exceptions Key: MRESOLVER-53 URL: https://issues.apache.org/jira/browse/MRESOLVER-53 Project: Maven Resolver Issue Type: Bug Components: resolver Affects Versions: Maven Artifact Resolver 1.1.1 Reporter: Elliotte Rusty Harold The API documentation should specify which runtime exceptions are thrown when and why. For instance, DefaultArtifact's constructors seem to throw IllegalArgumentExceptions if given bad coordinates: Exception in thread "main" java.lang.IllegalArgumentException: Bad artifact coordinates blah blah, expected format is :[:[:]]: That's reasonable. However it's not mentioned in the Javadoc, and I'm about to commit code to my project that depends on this behavior. We should document and commit to these. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
