[jira] [Commented] (MASFRES-42) Make maven to parallel job when installing dependencies
[ https://issues.apache.org/jira/browse/MASFRES-42?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17243780#comment-17243780 ] Michael Osipov commented on MASFRES-42: --- Please add a comment because this is not enough and this is the wrong project... > Make maven to parallel job when installing dependencies > --- > > Key: MASFRES-42 > URL: https://issues.apache.org/jira/browse/MASFRES-42 > Project: Apache Maven Resource Bundles > Issue Type: Improvement >Reporter: David Alen >Priority: Trivial > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-7044) Allow use of attributes in Maven pom.xml
[ https://issues.apache.org/jira/browse/MNG-7044?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17243753#comment-17243753 ] Michael Osipov commented on MNG-7044: - File an issue with Modelo and I will fix the 404. > Allow use of attributes in Maven pom.xml > > > Key: MNG-7044 > URL: https://issues.apache.org/jira/browse/MNG-7044 > Project: Maven > Issue Type: New Feature > Components: core, POM >Reporter: Will Iverson >Priority: Minor > Labels: features > > Proposal: The current pom.xml file is very verbose due to the exclusive use > of XML elements. This makes even simple declarations such as dependencies > unnecessarily verbose. > I would propose that a future version of Maven allow for the use of > attributes as an alternative declaration for pom.xml configuration. This > would only affect how Maven ingests project files - for consistency and > backward compatibility all generated pom.xml files would continue to be > element based. > Projects that declared a conflicting/duplicate attribute/element pairing > would be considered to be malformed, and would result in a built break. > By way of example of the benefit of this proposal, this declaration would be > reduced from: > > commons-cli > commons-cli > 1.4 > > ...to... > > This would allow many Maven projects to *dramatically* decrease the total > line count, which is one of the frequent criticisms of Maven compared with > other build tools. > If there is interest, I would be happy to help support this. My > hope/expectation is that the changes required to support this in Maven itself > would be quite minor - simply adding a bit of additional logic to look for > attributes in the XML parse and error reporting in the event of a duplication > (as well as supporting test cases). That said, I don't want to send in > patches for a change like this that would be dead on arrival. > This would, of course, represent a potentially large impact on the user and > tooling space (in particular, IDEs that integrate Maven support). As the > emitted files for resolved pom.xml files (those that are published in repos) > would remain the same, hopefully the overall impacts would be manageable. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [maven-script-interpreter] dependabot[bot] opened a new pull request #33: Bump groovy from 2.4.20 to 2.4.21
dependabot[bot] opened a new pull request #33: URL: https://github.com/apache/maven-script-interpreter/pull/33 Bumps [groovy](https://github.com/apache/groovy) from 2.4.20 to 2.4.21. Commits See full diff in https://github.com/apache/groovy/commits;>compare view [](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 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-invoker-plugin] dependabot[bot] opened a new pull request #32: Bump groovy-all from 2.4.20 to 2.4.21
dependabot[bot] opened a new pull request #32: URL: https://github.com/apache/maven-invoker-plugin/pull/32 Bumps [groovy-all](https://github.com/apache/groovy) from 2.4.20 to 2.4.21. Commits See full diff in https://github.com/apache/groovy/commits;>compare view [](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 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] [Created] (MRESOURCES-271) Connection reset error from Azure pipelines
Arul Elvis J created MRESOURCES-271:
---
Summary: Connection reset error from Azure pipelines
Key: MRESOURCES-271
URL: https://issues.apache.org/jira/browse/MRESOURCES-271
Project: Maven Resources Plugin
Issue Type: Bug
Environment: In both Ubuntu and Windows agent specification
Reporter: Arul Elvis J
Attachments: logs_143613.zip
When the pipelines are executed in Azure pipelines, we are facing connection
reset error. Azure pipelines team claims that connection is closed from Maven
central repo end. Below is the error message. Have attached the complete log
zip file for your reference. Can you please prioritize as soon as possible, as
it is impacting all the pipelines including the production builds ?
{{ }}
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-resources-plugin:3.0.2:resources
(default-resources) on project bata-s-sfdc-deferredpromo: Execution
default-resources of goal
org.apache.maven.plugins:maven-resources-plugin:3.0.2:resources failed: Plugin
org.apache.maven.plugins:maven-resources-plugin:3.0.2 or one of its
dependencies could not be resolved: Failed to collect dependencies at
org.apache.maven.plugins:maven-resources-plugin:jar:3.0.2 ->
org.apache.maven:maven-plugin-api:jar:3.0 ->
org.sonatype.sisu:sisu-inject-plexus:jar:1.4.2 ->
org.codehaus.plexus:plexus-component-annotations:jar:1.6: Failed to read
artifact descriptor for
org.codehaus.plexus:plexus-component-annotations:jar:1.6: Could not transfer
artifact org.codehaus.plexus:plexus-component-annotations:pom:1.6 from/to
central ([https://repo.maven.apache.org/maven2)]: Connection reset -> [Help 1]
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e
switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the errors and possible solutions, please
read the following articles:
[ERROR] [Help 1]
[http://cwiki.apache.org/confluence/display/MAVEN/PluginResolutionException]
The process
'C:\ProgramData\chocolatey\lib\maven\apache-maven-3.6.3\bin\mvn.cmd' failed
with exit code 1
Could not retrieve code analysis results - Maven run failed.
{{##[error]Build failed. }}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (SUREFIRE-1840) Why sudo docker?
[ https://issues.apache.org/jira/browse/SUREFIRE-1840?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17243591#comment-17243591 ] Matthew Wang commented on SUREFIRE-1840: I have submitted a PR with the aforementioned change. > Why sudo docker? > > > Key: SUREFIRE-1840 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1840 > Project: Maven Surefire > Issue Type: Bug > Components: documentation >Reporter: Sebb >Assignee: Tibor Digana >Priority: Major > Labels: up-for-grabs > > The page > https://maven.apache.org/surefire/maven-surefire-plugin/docker.html > says > "$ sudo docker build --no-cache -t my-image:1 -f ./Dockerfile ." > Is sudo really needed here? > If so, the reason should be explained and any limitations noted. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (MASFRES-42) Make maven to parallel job when installing dependencies
David Alen created MASFRES-42: - Summary: Make maven to parallel job when installing dependencies Key: MASFRES-42 URL: https://issues.apache.org/jira/browse/MASFRES-42 Project: Apache Maven Resource Bundles Issue Type: Improvement Reporter: David Alen -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [maven-archetypes] elharo commented on a change in pull request #3: Enabled generating Java 9+ projects as well as using JUnit 5.x
elharo commented on a change in pull request #3:
URL: https://github.com/apache/maven-archetypes/pull/3#discussion_r535655913
##
File path:
maven-archetype-quickstart/src/main/resources-filtered/archetype-resources/pom.xml
##
@@ -14,17 +44,19 @@
UTF-8
-1.7
-1.7
+#if ( ${javaCompilerVersion} == $null )
+#compilerProperties( "1.7" )
+#else
+#compilerProperties( ${javaCompilerVersion} )
+#end
-
- junit
- junit
- 4.11
- test
-
+#if ( ${junitVersion} == $null )
+#junit( "4.12" )
Review comment:
now 4.13.1 or github will spam projects with security warnings :-(
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-7044) Allow use of attributes in Maven pom.xml
[ https://issues.apache.org/jira/browse/MNG-7044?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17243521#comment-17243521 ] Will Iverson commented on MNG-7044: --- On this page: [https://codehaus-plexus.github.io/modello/modello-maven-plugin/faq.html] there's a reference to a Modello wiki at [http://docs.codehaus.org/display/MODELLO/Home] that's dead. Found some of it on wayback, last snapshot in 2015. Looks like some conceptual overview stuff, but all-in-all Modello looks like a fairly conventional static code generator. > Allow use of attributes in Maven pom.xml > > > Key: MNG-7044 > URL: https://issues.apache.org/jira/browse/MNG-7044 > Project: Maven > Issue Type: New Feature > Components: core, POM >Reporter: Will Iverson >Priority: Minor > Labels: features > > Proposal: The current pom.xml file is very verbose due to the exclusive use > of XML elements. This makes even simple declarations such as dependencies > unnecessarily verbose. > I would propose that a future version of Maven allow for the use of > attributes as an alternative declaration for pom.xml configuration. This > would only affect how Maven ingests project files - for consistency and > backward compatibility all generated pom.xml files would continue to be > element based. > Projects that declared a conflicting/duplicate attribute/element pairing > would be considered to be malformed, and would result in a built break. > By way of example of the benefit of this proposal, this declaration would be > reduced from: > > commons-cli > commons-cli > 1.4 > > ...to... > > This would allow many Maven projects to *dramatically* decrease the total > line count, which is one of the frequent criticisms of Maven compared with > other build tools. > If there is interest, I would be happy to help support this. My > hope/expectation is that the changes required to support this in Maven itself > would be quite minor - simply adding a bit of additional logic to look for > attributes in the XML parse and error reporting in the event of a duplication > (as well as supporting test cases). That said, I don't want to send in > patches for a change like this that would be dead on arrival. > This would, of course, represent a potentially large impact on the user and > tooling space (in particular, IDEs that integrate Maven support). As the > emitted files for resolved pom.xml files (those that are published in repos) > would remain the same, hopefully the overall impacts would be manageable. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-7044) Allow use of attributes in Maven pom.xml
[ https://issues.apache.org/jira/browse/MNG-7044?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17243516#comment-17243516 ] Michael Osipov commented on MNG-7044: - See here: https://codehaus-plexus.github.io/modello/modello.html > Allow use of attributes in Maven pom.xml > > > Key: MNG-7044 > URL: https://issues.apache.org/jira/browse/MNG-7044 > Project: Maven > Issue Type: New Feature > Components: core, POM >Reporter: Will Iverson >Priority: Minor > Labels: features > > Proposal: The current pom.xml file is very verbose due to the exclusive use > of XML elements. This makes even simple declarations such as dependencies > unnecessarily verbose. > I would propose that a future version of Maven allow for the use of > attributes as an alternative declaration for pom.xml configuration. This > would only affect how Maven ingests project files - for consistency and > backward compatibility all generated pom.xml files would continue to be > element based. > Projects that declared a conflicting/duplicate attribute/element pairing > would be considered to be malformed, and would result in a built break. > By way of example of the benefit of this proposal, this declaration would be > reduced from: > > commons-cli > commons-cli > 1.4 > > ...to... > > This would allow many Maven projects to *dramatically* decrease the total > line count, which is one of the frequent criticisms of Maven compared with > other build tools. > If there is interest, I would be happy to help support this. My > hope/expectation is that the changes required to support this in Maven itself > would be quite minor - simply adding a bit of additional logic to look for > attributes in the XML parse and error reporting in the event of a duplication > (as well as supporting test cases). That said, I don't want to send in > patches for a change like this that would be dead on arrival. > This would, of course, represent a potentially large impact on the user and > tooling space (in particular, IDEs that integrate Maven support). As the > emitted files for resolved pom.xml files (those that are published in repos) > would remain the same, hopefully the overall impacts would be manageable. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-6772) Super POM overwrites remapped central repository in nested import POMs
[
https://issues.apache.org/jira/browse/MNG-6772?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17243515#comment-17243515
]
Eddie Wiegers commented on MNG-6772:
[~michael-o]
Fair enough, I concede. I still consider overriding {{central}} in the POM
instead of settings.xml a design choice rather than a loop hole based on the
repository order you linked. It should be valid to overwrite at any layer that
has higher precedence than the Super POM, and we chose to overwrite in the
Local POM because that override lives with the project in source control so
seems more portable than trying to make sure settings.xml is set up properly on
every machine that performs builds.
If this is not an intended workflow, perhaps we'll just remove the overrides
from the POM completely so that builds fail to resolve even our internal parent
POM which will fail fast and hopefully clue developers in that they are missing
crucial configuration instead of having things mostly work but fail in some
edge cases.
Because JFrog's documentation states:
{quote}To do so, you need to insert the following into your parent POM or
settings.xml (under an active profile)
{quote}
I would recommend reaching out to them and having them update the documentation
to only mention the settings.xml, as I have to imagine there are many
Artifactory users that have configured their POMs this way and will break if
Maven stops allowing it.
Thanks for engaging in this discussion, and perhaps I'll be able to contribute
something more valuable in the future.
> Super POM overwrites remapped central repository in nested import POMs
> --
>
> Key: MNG-6772
> URL: https://issues.apache.org/jira/browse/MNG-6772
> Project: Maven
> Issue Type: Bug
> Components: Artifacts and Repositories, POM
>Affects Versions: 3.6.2
>Reporter: Eddie Wiegers
>Assignee: Sylwester Lachiewicz
>Priority: Major
> Fix For: wontfix-candidate, 4.0.0, 4.0.0-alpha-1
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> My projects define a repository with {{central,}} which is meant to
> specifically override the entry in the Super POM. This is specifically what
> [JFrog Artifactory
> recommends|https://www.jfrog.com/confluence/display/RTF/Maven+Repository#MavenRepository-ManuallyOverridingtheBuilt-inRepositories]
> doing, and seems valid in situations where the _real_ Maven Central may be
> unreachable.
>
> The override takes precedence almost all of the time. However, there is at
> least one scenario where this is not the case, and that is when importing a
> POM that in turn imports another POM.
>
> Digging into the code, it appears the reason this happens is because the
> {{DefaultModelBuilder}} overwrites repositories after interpolation is
> complete:
> [https://github.com/apache/maven/blob/53f04f03e3e58c75dcc791d557758357a6ec7983/maven-model-builder/src/main/java/org/apache/maven/model/building/DefaultModelBuilder.java#L411]
>
> From what I can tell, this is done with the intention of overwriting
> repositories that were added to the local resolver prior to interpolation
> with the interpolated version. Due to the way the {{DefaultModelResolver}}
> works, an unintended side effect is that the {{central}} repository from the
> Super POM is added once after each interpolation. The first time the
> repository is added, it is added to the {{repositoryIds}} but doesn't
> actually remove the original repository. The second time it is added is when
> the original repository will be replaced. Currently, the repositoryIds are
> preserved in the {{ModelResolver}} when resolving import POMs, leading to the
> behavior I am seeing where the second nested import POM ends up being where
> the failure occurs.
>
> I am planning on submitting a PR to clone the {{ModelResolver}} in a way that
> resets the repositoryIds prior to import POMs being resolved, since they are
> separate artifact builds. That seems like the most consistent fix to me that
> covers cases outside of the the Super POM's {{central}} definition.
>
> *Workarounds*:
> The current workaround is to use a repository ID other than {{central}} for
> my Artifactory repository, which isn't ideal since it leaves the potential
> for long timeouts to occur on the real {{central}} when an artifact can't be
> resolved from my Artifactory repository.
>
> Mirrors are not an ideal workaround since getting them in place on all
> possible build environments isn't trivial.
>
> When looking at the code I noticed
> {{RepositorySystemSession#isIgnoreArtifactDescriptorRepositories()}} being
> checked in various places, which seems like it would also act as a potential
> workaround, but I don't see a way to enable this value via MavenCLI or
>
[jira] [Commented] (WAGON-590) Maven 3.5.0+ doesn't seem to send credentials after 301/302 HTTP redirect
[
https://issues.apache.org/jira/browse/WAGON-590?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17243512#comment-17243512
]
Michael Osipov commented on WAGON-590:
--
Great, would you mind to add the BasicAuthScope documentation to
https://maven.apache.org/guides/mini/guide-http-settings.html?
> Maven 3.5.0+ doesn't seem to send credentials after 301/302 HTTP redirect
> -
>
> Key: WAGON-590
> URL: https://issues.apache.org/jira/browse/WAGON-590
> Project: Maven Wagon
> Issue Type: Bug
>Affects Versions: 3.4.0
>Reporter: Cintia DR
>Priority: Major
> Fix For: waiting-for-feedback
>
> Attachments: 0001-conditonally-set-AuthScope-to-any.patch, Screen
> Shot 2020-04-28 at 7.45.33 pm.png, any-auth.log,
> expect-continue-done-right-any-auth.log, master_osx.log, master_ubuntu.log,
> maven_x.log, mvn-master-batch.log, mvn-wagon590branch-debug-osx.log,
> mvn-wagon590branch-osx.log, mvn339_osx.log, mvn339_ubuntu.log, scoped-auth.log
>
>
> Since maven 3.5.0 (including 3.6.3), maven seems to not send server
> credentials if distributionManagement server response was a 301 or 302 HTTP
> redirect. Note that the redirect is followed, but I receive unauthorised code.
> Maven 3.2.5 and 3.3.9 work as expected. I could reproduce it on ubuntu and
> OSX. Both are JDK 8, not sure if it could make any difference.
>
> All maven versions (including 3.2.5 and 3.3.9) are using the same version of
> the deploy plugin (2.7), and upgrading it made no difference whatsoever.
>
> If I use '[https://openmrs.jfrog.io/artifactory/snapshots/'] as my
> 'distributionManagement', credentials are sent.
> If I use
> '[https://mavenrepo.openmrs.org/proxy/snapshots/|https://mavenrepo.openmrs.org/snapshots/']'
> (a reverse proxy to
> '[https://openmrs.jfrog.io/artifactory/snapshots/|https://openmrs.jfrog.io/artifactory/snapshots/']')
> credentials are sent.
> If I use '[https://mavenrepo.openmrs.org/snapshots/'] (a 301 redirect to
> [https://openmrs.jfrog.io/artifactory/snapshots/|https://openmrs.jfrog.io/artifactory/snapshots/'])
> as my distributionManagement, credentials are _not_ sent and the request
> fails as it's unauthenticated.
>
> You can see the configuration of 'mavenrepo.openmrs.org' server here:
> [https://github.com/openmrs/openmrs-contrib-itsmresources/blob/master/ansible/host_vars/campo.openmrs.org/vars#L33]
>
> All my artefacts are public to download, so I don't have a way to testing
> downloading artefacts with server credentials.
>
>
> This is how the output looks like in maven 3.6.3:
> {code:java}
>
> [INFO] --- maven-deploy-plugin:2.7:deploy (default-deploy) @
> releasetestmodule ---
> Downloading from openmrs-repo-snapshots:
> https://mavenrepo.openmrs.org/nexus/content/repositories/snapshots/org/openmrs/module/releasetestmodule/2.1.22-SNAPSHOT/maven-metadata.xml
> Downloaded from openmrs-repo-snapshots:
> https://mavenrepo.openmrs.org/nexus/content/repositories/snapshots/org/openmrs/module/releasetestmodule/2.1.22-SNAPSHOT/maven-metadata.xml
> (616 B at 132 B/s)
> Uploading to openmrs-repo-snapshots:
> https://mavenrepo.openmrs.org/nexus/content/repositories/snapshots/org/openmrs/module/releasetestmodule/2.1.22-SNAPSHOT/releasetestmodule-2.1.22-20200427.091851-13.pom
> ...
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-deploy-plugin:2.7:deploy (default-deploy) on
> project releasetestmodule: Failed to deploy artifacts: Could not transfer
> artifact org.openmrs.module:releasetestmodule:pom:2.1.22-20200427.091851-13
> from/to openmrs-repo-snapshots
> (https://mavenrepo.openmrs.org/nexus/content/repositories/snapshots):
> Transfer failed for
> https://openmrs.jfrog.io/artifactory/snapshots/org/openmrs/module/releasetestmodule/2.1.22-SNAPSHOT/releasetestmodule-2.1.22-20200427.091851-13.pom
> 401 Unauthorized -> [Help 1]{code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [maven] michael-o commented on a change in pull request #408: [MNG-7045] - Drop useless and outdated cdi-api from maven
michael-o commented on a change in pull request #408: URL: https://github.com/apache/maven/pull/408#discussion_r535520116 ## File path: maven-core/src/main/resources/META-INF/maven/extension.xml ## @@ -96,9 +96,11 @@ under the License. javax.inject.* - +
[jira] [Commented] (MNG-7045) Drop CDI API from Maven
[ https://issues.apache.org/jira/browse/MNG-7045?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17243488#comment-17243488 ] Mark Struberg commented on MNG-7045: +1 I was opposed to even the atinject and slf4j apis back then. Maven should imo be fully self-contained without any classpath conflicts. > Drop CDI API from Maven > --- > > Key: MNG-7045 > URL: https://issues.apache.org/jira/browse/MNG-7045 > Project: Maven > Issue Type: Bug > Components: core >Reporter: Romain Manni-Bucau >Priority: Major > > This is an old leak which triggered a lot of regressions and still triggers > bugs in mojos. > Since there is on real justification in maven itself (@Typed is not since > there are alternative and cdi is not used in any piece of maven), let's drop > it. > If a plugin needs it, it already has it since cdi-api is outdated anyway. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (MNG-7045) Drop CDI API from Maven
[ https://issues.apache.org/jira/browse/MNG-7045?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov updated MNG-7045: Summary: Drop CDI API from Maven (was: Drop pi from maven) > Drop CDI API from Maven > --- > > Key: MNG-7045 > URL: https://issues.apache.org/jira/browse/MNG-7045 > Project: Maven > Issue Type: Bug > Components: core >Reporter: Romain Manni-Bucau >Priority: Major > > This is an old leak which triggered a lot of regressions and still triggers > bugs in mojos. > Since there is on real justification in maven itself (@Typed is not since > there are alternative and cdi is not used in any piece of maven), let's drop > it. > If a plugin needs it, it already has it since cdi-api is outdated anyway. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (MNG-7045) Drop pi from maven
[ https://issues.apache.org/jira/browse/MNG-7045?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov updated MNG-7045: Summary: Drop pi from maven (was: Drop cdi-api from maven) > Drop pi from maven > -- > > Key: MNG-7045 > URL: https://issues.apache.org/jira/browse/MNG-7045 > Project: Maven > Issue Type: Bug > Components: core >Reporter: Romain Manni-Bucau >Priority: Major > > This is an old leak which triggered a lot of regressions and still triggers > bugs in mojos. > Since there is on real justification in maven itself (@Typed is not since > there are alternative and cdi is not used in any piece of maven), let's drop > it. > If a plugin needs it, it already has it since cdi-api is outdated anyway. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-7045) Drop cdi-api from maven
[ https://issues.apache.org/jira/browse/MNG-7045?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17243465#comment-17243465 ] Michael Osipov commented on MNG-7045: - Can you point to a few explicit bugs? I can't remember someone has ever reported something. > Drop cdi-api from maven > --- > > Key: MNG-7045 > URL: https://issues.apache.org/jira/browse/MNG-7045 > Project: Maven > Issue Type: Bug > Components: core >Reporter: Romain Manni-Bucau >Priority: Major > > This is an old leak which triggered a lot of regressions and still triggers > bugs in mojos. > Since there is on real justification in maven itself (@Typed is not since > there are alternative and cdi is not used in any piece of maven), let's drop > it. > If a plugin needs it, it already has it since cdi-api is outdated anyway. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [maven] rmannibucau opened a new pull request #408: [MNG-7045] - Drop useless and outdated cdi-api from maven
rmannibucau opened a new pull request #408: URL: https://github.com/apache/maven/pull/408 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/MNG) 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. - [ ] Each commit in the pull request should have a meaningful subject line and body. - [ ] Format the pull request title like `[MNG-XXX] - Fixes bug in ApproximateQuantiles`, where you replace `MNG-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. - [ ] Write a pull request description that is detailed enough to understand what the pull request does, how, and why. - [ ] Run `mvn clean verify` to make sure basic checks pass. A more thorough check will be performed on your pull request automatically. - [ ] You have run the [Core IT][core-its] successfully. 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. - [ ] 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) - [ ] In any other case, please file an [Apache Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf). [core-its]: https://maven.apache.org/core-its/core-it-suite/ 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] [Created] (MNG-7045) Drop cdi-api from maven
Romain Manni-Bucau created MNG-7045: --- Summary: Drop cdi-api from maven Key: MNG-7045 URL: https://issues.apache.org/jira/browse/MNG-7045 Project: Maven Issue Type: Bug Components: core Reporter: Romain Manni-Bucau This is an old leak which triggered a lot of regressions and still triggers bugs in mojos. Since there is on real justification in maven itself (@Typed is not since there are alternative and cdi is not used in any piece of maven), let's drop it. If a plugin needs it, it already has it since cdi-api is outdated anyway. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (MINSTALL-169) Handle non-pom packaging with only a pom artifact
Ben Tatham created MINSTALL-169:
---
Summary: Handle non-pom packaging with only a pom artifact
Key: MINSTALL-169
URL: https://issues.apache.org/jira/browse/MINSTALL-169
Project: Maven Install Plugin
Issue Type: Improvement
Components: install:install
Reporter: Ben Tatham
Note: this story affects maven-install-plugin and maven-deploy-plugin equally.
Currently, in
[DefaultProjectInstaller|https://github.com/apache/maven-artifact-transfer/blob/dfb1e61c4f5db6fe167b3d879a37ab5e25c8475c/src/main/java/org/apache/maven/shared/transfer/project/install/internal/DefaultProjectInstaller.java#L82],
if a project does not have literally "pom" as packaging, then if there are no
other artifacts, install:install fails (as does deploy:deploy) with
{code:java}
NoFileAssignedException: The packaging plugin for this project did not assign a
main file to the project but it has attachments. Change packaging to
'pom'.{code}
However, for some custom lifecycles (and therefore different packaging types),
we might want to be able to have a lifecycle that just installs/deploys the pom
file alone with no additional artifacts.
Further, if a plugin explicitly sets the main artifact (via
MavenProject.setArtifact) to the `ProjectArtifact`, aka the pom file itself
(which I tried as a work around), then install and deploy perform the same
action twice (which would then break deploy, if the maven central repo blocks
duplicate pushes, as we have setup in our Nexus environment for release
(non-snapshot) artifacts)
Our use case might be weird, but we want to be able to use maven to lookup
version updates for it, even though the artifacts themselves are not in maven
(our use case is docker, helm charts, etc).
I see this as a relatively simple fix in the above mentioned class, and am
happy to contribute a pull request for it.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-7044) Allow use of attributes in Maven pom.xml
[ https://issues.apache.org/jira/browse/MNG-7044?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17243432#comment-17243432 ] Will Iverson commented on MNG-7044: --- KK, so the validation of the model happens in Java. The actual parsing of the model appears to be from Java code generated by Modello. It appears that the Modello Maven plugin is used to generate Java parsing code from a Modello file. This page has links with the Modello plugin and the Maven Modello file available here: [http://codehaus-plexus.github.io/modello/modello-maven-plugin/faq.html] Interestingly, the existing page for Modello lists other formats besides XML (e.g. YAML). [http://codehaus-plexus.github.io/modello/modello-maven-plugin/index.html] This is the Maven core project that actually generates the Model parsing from Modello: [https://github.com/apache/maven/tree/master/maven-model] That maven-model project is interesting, as there is essentially no code in it at all, just the Modello generation. Checking that code out and running it to generate the Modello XML parsing is quite interesting and (happily) pretty straight-forward. It appears that the theoretical path is to add an option to the Modello Java generator to add attribute processing via a flag. So, then the process is (again, to flog theoretical) submit a patch to add the option to Modello to allow for attribute alias generation (looks like just a few lines), and then submit a patch to turn that option on in the maven-model project (a single line to enable it in the Modello configuration). Unfortunately, the links on the Modello page to documentation appear to be broken due to the codehaus dissolution. Let me know any thoughts/observations. I would guess adding an option to Modello to generate attribute aliasing is, in itself, pretty innocuous/likely to be accepted. Which, in turn, would mean that flipping the option on would be a single line PR for maven-model. Huh. > Allow use of attributes in Maven pom.xml > > > Key: MNG-7044 > URL: https://issues.apache.org/jira/browse/MNG-7044 > Project: Maven > Issue Type: New Feature > Components: core, POM >Reporter: Will Iverson >Priority: Minor > Labels: features > > Proposal: The current pom.xml file is very verbose due to the exclusive use > of XML elements. This makes even simple declarations such as dependencies > unnecessarily verbose. > I would propose that a future version of Maven allow for the use of > attributes as an alternative declaration for pom.xml configuration. This > would only affect how Maven ingests project files - for consistency and > backward compatibility all generated pom.xml files would continue to be > element based. > Projects that declared a conflicting/duplicate attribute/element pairing > would be considered to be malformed, and would result in a built break. > By way of example of the benefit of this proposal, this declaration would be > reduced from: > > commons-cli > commons-cli > 1.4 > > ...to... > > This would allow many Maven projects to *dramatically* decrease the total > line count, which is one of the frequent criticisms of Maven compared with > other build tools. > If there is interest, I would be happy to help support this. My > hope/expectation is that the changes required to support this in Maven itself > would be quite minor - simply adding a bit of additional logic to look for > attributes in the XML parse and error reporting in the event of a duplication > (as well as supporting test cases). That said, I don't want to send in > patches for a change like this that would be dead on arrival. > This would, of course, represent a potentially large impact on the user and > tooling space (in particular, IDEs that integrate Maven support). As the > emitted files for resolved pom.xml files (those that are published in repos) > would remain the same, hopefully the overall impacts would be manageable. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-6239) jansi messes up System.err and System.out
[
https://issues.apache.org/jira/browse/MNG-6239?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17243151#comment-17243151
]
Simone Bordet commented on MNG-6239:
I have updated my local Maven 3.6.3 with jansi-2.0.1 and the issue is fixed for
me.
> jansi messes up System.err and System.out
> -
>
> Key: MNG-6239
> URL: https://issues.apache.org/jira/browse/MNG-6239
> Project: Maven
> Issue Type: Bug
> Components: core
>Affects Versions: 3.5.0
> Environment: Java 1.8.0_131, Ubuntu 17.04
>Reporter: Simone Bordet
>Priority: Minor
> Attachments: mvn-jansi.tgz
>
>
> I use the Maven Exec Plugin to run a class that asks for interactive input
> from the user. This was working in 3.3.9, but does not work in 3.5.0.
> Anything printed on {{System.err}} or {{System.out}} without a newline is not
> printed immediately on the terminal window.
> Example:
> {code:java}
> BufferedReader console = new BufferedReader(new InputStreamReader(System.in));
> System.err.printf("listen port: ");
> String value = console.readLine().trim();
> {code}
> The example above would not print {{listen port:}} on the terminal.
> Attached you can find a project that reproduces this issue.
> Unpack the project and then run:
> {noformat}
> $ mvn install && mvn exec:exec
> {noformat}
> The expected output of the reproducer would be:
> {noformat}
> err.println
> out.println
> err.printerr.printfout.printout.printf
> {noformat}
> instead I get:
> {noformat}
> err.println
> out.println
> {noformat}
> Removing {{jansi-1.13.jar}} from {{$MAVEN/lib/}} fixes the issue.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MRELEASE-899) release:prepare should not change the line separator but detect effective line separator from pom.xml
[
https://issues.apache.org/jira/browse/MRELEASE-899?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17243124#comment-17243124
]
Alexander Kriegisch commented on MRELEASE-899:
--
_Disclaimer: I never even looked at the PR source code, I am purely talking on
a functional level here, not discussing if the PR addresses the issue
appropriately. I fully trust the team of maintainers to assess that._
> release:prepare should not change the line separator but detect effective
> line separator from pom.xml
> -
>
> Key: MRELEASE-899
> URL: https://issues.apache.org/jira/browse/MRELEASE-899
> Project: Maven Release Plugin
> Issue Type: Improvement
>Reporter: Ralph van Etten
>Priority: Major
>
> Currently the plugin use the system property {{line.separator}} when it
> rewrites the pom.xml.
> This causes trouble, because every line in changed, when a project is
> released sometimes under Windows and sometimes under Linux (because of its
> different line separators).
> (http://stackoverflow.com/questions/11868590/maven-release-plugin-and-windows-line-breaks)
> Therefore it would be a nice feature when the plugin would not use the
> systems line separator but the line separator that is already used in the
> pom.xml.
> On the other hand, changing the existing behaviour would maybe, also harm
> someone else.
> Therefore it would be an great feature when there would be an property that
> define the expected behaviour, maybe in the same way it is done by the
> maven-assembly-plugin's property fileSet.lineEnding
> (http://maven.apache.org/plugins/maven-assembly-plugin/component.html#class_fileSet)
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MRELEASE-899) release:prepare should not change the line separator but detect effective line separator from pom.xml
[
https://issues.apache.org/jira/browse/MRELEASE-899?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17243122#comment-17243122
]
Michael Osipov commented on MRELEASE-899:
-
As far as I solution is concerned, I don't the option. A line ending detector
would be much better.
> release:prepare should not change the line separator but detect effective
> line separator from pom.xml
> -
>
> Key: MRELEASE-899
> URL: https://issues.apache.org/jira/browse/MRELEASE-899
> Project: Maven Release Plugin
> Issue Type: Improvement
>Reporter: Ralph van Etten
>Priority: Major
>
> Currently the plugin use the system property {{line.separator}} when it
> rewrites the pom.xml.
> This causes trouble, because every line in changed, when a project is
> released sometimes under Windows and sometimes under Linux (because of its
> different line separators).
> (http://stackoverflow.com/questions/11868590/maven-release-plugin-and-windows-line-breaks)
> Therefore it would be a nice feature when the plugin would not use the
> systems line separator but the line separator that is already used in the
> pom.xml.
> On the other hand, changing the existing behaviour would maybe, also harm
> someone else.
> Therefore it would be an great feature when there would be an property that
> define the expected behaviour, maybe in the same way it is done by the
> maven-assembly-plugin's property fileSet.lineEnding
> (http://maven.apache.org/plugins/maven-assembly-plugin/component.html#class_fileSet)
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (MRELEASE-899) release:prepare should not change the line separator but detect effective line separator from pom.xml
[
https://issues.apache.org/jira/browse/MRELEASE-899?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17243122#comment-17243122
]
Michael Osipov edited comment on MRELEASE-899 at 12/3/20, 11:25 AM:
As far as a solution is concerned, I don't the option from the PR. A line
ending detector would be much better.
was (Author: michael-o):
As far as a solution is concerned, I don't the option. A line ending detector
would be much better.
> release:prepare should not change the line separator but detect effective
> line separator from pom.xml
> -
>
> Key: MRELEASE-899
> URL: https://issues.apache.org/jira/browse/MRELEASE-899
> Project: Maven Release Plugin
> Issue Type: Improvement
>Reporter: Ralph van Etten
>Priority: Major
>
> Currently the plugin use the system property {{line.separator}} when it
> rewrites the pom.xml.
> This causes trouble, because every line in changed, when a project is
> released sometimes under Windows and sometimes under Linux (because of its
> different line separators).
> (http://stackoverflow.com/questions/11868590/maven-release-plugin-and-windows-line-breaks)
> Therefore it would be a nice feature when the plugin would not use the
> systems line separator but the line separator that is already used in the
> pom.xml.
> On the other hand, changing the existing behaviour would maybe, also harm
> someone else.
> Therefore it would be an great feature when there would be an property that
> define the expected behaviour, maybe in the same way it is done by the
> maven-assembly-plugin's property fileSet.lineEnding
> (http://maven.apache.org/plugins/maven-assembly-plugin/component.html#class_fileSet)
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (MRELEASE-899) release:prepare should not change the line separator but detect effective line separator from pom.xml
[
https://issues.apache.org/jira/browse/MRELEASE-899?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17243122#comment-17243122
]
Michael Osipov edited comment on MRELEASE-899 at 12/3/20, 11:25 AM:
As far as a solution is concerned, I don't the option. A line ending detector
would be much better.
was (Author: michael-o):
As far as I solution is concerned, I don't the option. A line ending detector
would be much better.
> release:prepare should not change the line separator but detect effective
> line separator from pom.xml
> -
>
> Key: MRELEASE-899
> URL: https://issues.apache.org/jira/browse/MRELEASE-899
> Project: Maven Release Plugin
> Issue Type: Improvement
>Reporter: Ralph van Etten
>Priority: Major
>
> Currently the plugin use the system property {{line.separator}} when it
> rewrites the pom.xml.
> This causes trouble, because every line in changed, when a project is
> released sometimes under Windows and sometimes under Linux (because of its
> different line separators).
> (http://stackoverflow.com/questions/11868590/maven-release-plugin-and-windows-line-breaks)
> Therefore it would be a nice feature when the plugin would not use the
> systems line separator but the line separator that is already used in the
> pom.xml.
> On the other hand, changing the existing behaviour would maybe, also harm
> someone else.
> Therefore it would be an great feature when there would be an property that
> define the expected behaviour, maybe in the same way it is done by the
> maven-assembly-plugin's property fileSet.lineEnding
> (http://maven.apache.org/plugins/maven-assembly-plugin/component.html#class_fileSet)
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MRELEASE-899) release:prepare should not change the line separator but detect effective line separator from pom.xml
[
https://issues.apache.org/jira/browse/MRELEASE-899?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17243119#comment-17243119
]
Alexander Kriegisch commented on MRELEASE-899:
--
Why has this turned into a meta discussion? The plugin used to respect the
original line break style before (and so do other Maven plugins), now it does
not. People have their reasons for configuring Git like this or like that.
Nothing about it is per se "faulty". Why else would it be configurable, if not
in order to accommodate different projects, platforms and situations? Why would
a Maven plugin changing existing files in a work directory and performing
commits from there just decide by itself how users should configure Git?
> release:prepare should not change the line separator but detect effective
> line separator from pom.xml
> -
>
> Key: MRELEASE-899
> URL: https://issues.apache.org/jira/browse/MRELEASE-899
> Project: Maven Release Plugin
> Issue Type: Improvement
>Reporter: Ralph van Etten
>Priority: Major
>
> Currently the plugin use the system property {{line.separator}} when it
> rewrites the pom.xml.
> This causes trouble, because every line in changed, when a project is
> released sometimes under Windows and sometimes under Linux (because of its
> different line separators).
> (http://stackoverflow.com/questions/11868590/maven-release-plugin-and-windows-line-breaks)
> Therefore it would be a nice feature when the plugin would not use the
> systems line separator but the line separator that is already used in the
> pom.xml.
> On the other hand, changing the existing behaviour would maybe, also harm
> someone else.
> Therefore it would be an great feature when there would be an property that
> define the expected behaviour, maybe in the same way it is done by the
> maven-assembly-plugin's property fileSet.lineEnding
> (http://maven.apache.org/plugins/maven-assembly-plugin/component.html#class_fileSet)
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MRELEASE-899) release:prepare should not change the line separator but detect effective line separator from pom.xml
[
https://issues.apache.org/jira/browse/MRELEASE-899?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17243110#comment-17243110
]
Michael Osipov commented on MRELEASE-899:
-
Can you explain why this chaos is desired: my SCM is *properly *configured to
check-out "as is" and check-in "as is".
> release:prepare should not change the line separator but detect effective
> line separator from pom.xml
> -
>
> Key: MRELEASE-899
> URL: https://issues.apache.org/jira/browse/MRELEASE-899
> Project: Maven Release Plugin
> Issue Type: Improvement
>Reporter: Ralph van Etten
>Priority: Major
>
> Currently the plugin use the system property {{line.separator}} when it
> rewrites the pom.xml.
> This causes trouble, because every line in changed, when a project is
> released sometimes under Windows and sometimes under Linux (because of its
> different line separators).
> (http://stackoverflow.com/questions/11868590/maven-release-plugin-and-windows-line-breaks)
> Therefore it would be a nice feature when the plugin would not use the
> systems line separator but the line separator that is already used in the
> pom.xml.
> On the other hand, changing the existing behaviour would maybe, also harm
> someone else.
> Therefore it would be an great feature when there would be an property that
> define the expected behaviour, maybe in the same way it is done by the
> maven-assembly-plugin's property fileSet.lineEnding
> (http://maven.apache.org/plugins/maven-assembly-plugin/component.html#class_fileSet)
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MRELEASE-899) release:prepare should not change the line separator but detect effective line separator from pom.xml
[
https://issues.apache.org/jira/browse/MRELEASE-899?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17243108#comment-17243108
]
James Nord commented on MRELEASE-899:
-
NB: you can also easily reproduce this issue by using a *nix setup and cloning
a repo that has a `pom.xml` using windows (\r\n) line feeds and doing a
release. That will convert the Windows lineends back to UNIX style :)
> release:prepare should not change the line separator but detect effective
> line separator from pom.xml
> -
>
> Key: MRELEASE-899
> URL: https://issues.apache.org/jira/browse/MRELEASE-899
> Project: Maven Release Plugin
> Issue Type: Improvement
>Reporter: Ralph van Etten
>Priority: Major
>
> Currently the plugin use the system property {{line.separator}} when it
> rewrites the pom.xml.
> This causes trouble, because every line in changed, when a project is
> released sometimes under Windows and sometimes under Linux (because of its
> different line separators).
> (http://stackoverflow.com/questions/11868590/maven-release-plugin-and-windows-line-breaks)
> Therefore it would be a nice feature when the plugin would not use the
> systems line separator but the line separator that is already used in the
> pom.xml.
> On the other hand, changing the existing behaviour would maybe, also harm
> someone else.
> Therefore it would be an great feature when there would be an property that
> define the expected behaviour, maybe in the same way it is done by the
> maven-assembly-plugin's property fileSet.lineEnding
> (http://maven.apache.org/plugins/maven-assembly-plugin/component.html#class_fileSet)
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MRELEASE-899) release:prepare should not change the line separator but detect effective line separator from pom.xml
[
https://issues.apache.org/jira/browse/MRELEASE-899?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17243096#comment-17243096
]
James Nord commented on MRELEASE-899:
-
> Is this still relevant?
Yes, very much so.
[https://github.com/jenkinsci/acceptance-test-harness/commit/4ef0f25275e881c494639dfc44f75ac8c77dbff2#diff-9c5fb3d1b7e3b0f54bc5c4182965c4fe1f9023d449017cece3005d3f90e8e4d8]
> Are people still not able to properly configure their SCM?
my SCM is *properly *configured to {{check-out}} "{{as is}}" and {{check-in}}
"{{as is}}".
> release:prepare should not change the line separator but detect effective
> line separator from pom.xml
> -
>
> Key: MRELEASE-899
> URL: https://issues.apache.org/jira/browse/MRELEASE-899
> Project: Maven Release Plugin
> Issue Type: Improvement
>Reporter: Ralph van Etten
>Priority: Major
>
> Currently the plugin use the system property {{line.separator}} when it
> rewrites the pom.xml.
> This causes trouble, because every line in changed, when a project is
> released sometimes under Windows and sometimes under Linux (because of its
> different line separators).
> (http://stackoverflow.com/questions/11868590/maven-release-plugin-and-windows-line-breaks)
> Therefore it would be a nice feature when the plugin would not use the
> systems line separator but the line separator that is already used in the
> pom.xml.
> On the other hand, changing the existing behaviour would maybe, also harm
> someone else.
> Therefore it would be an great feature when there would be an property that
> define the expected behaviour, maybe in the same way it is done by the
> maven-assembly-plugin's property fileSet.lineEnding
> (http://maven.apache.org/plugins/maven-assembly-plugin/component.html#class_fileSet)
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [maven-release] jtnord commented on a change in pull request #62: [MRELEASE-899] Feature/lineseparator
jtnord commented on a change in pull request #62:
URL: https://github.com/apache/maven-release/pull/62#discussion_r535076817
##
File path:
maven-release-plugin/src/main/java/org/apache/maven/plugins/release/PrepareReleaseMojo.java
##
@@ -387,4 +403,27 @@ protected void prepareRelease( boolean generateReleasePoms
)
}
}
+private String resolveLineSeparator()
+{
+if ( lineSeparator == null )
+{
+return System.getProperty( "line.separator" );
+}
+
+switch ( lineSeparator )
Review comment:
it would be really great if there was a "same as source" option that
sniffed the line endings in the current projects `pom.xml` and used that as the
default rather than the jvm default. this would fix MRELEASE-899 without
having to make any changes, and should not affect any user who was not affected
by MRELEASE-899 (or its inverse that \n would be used on *nix when a \r\n file
was checked out) already.
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] (MRELEASE-899) release:prepare should not change the line separator but detect effective line separator from pom.xml
[
https://issues.apache.org/jira/browse/MRELEASE-899?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17243093#comment-17243093
]
Michael Osipov commented on MRELEASE-899:
-
Thanks, the discussion in Git for Windows is quite lengthly. It will take time
to process it.
> release:prepare should not change the line separator but detect effective
> line separator from pom.xml
> -
>
> Key: MRELEASE-899
> URL: https://issues.apache.org/jira/browse/MRELEASE-899
> Project: Maven Release Plugin
> Issue Type: Improvement
>Reporter: Ralph van Etten
>Priority: Major
>
> Currently the plugin use the system property {{line.separator}} when it
> rewrites the pom.xml.
> This causes trouble, because every line in changed, when a project is
> released sometimes under Windows and sometimes under Linux (because of its
> different line separators).
> (http://stackoverflow.com/questions/11868590/maven-release-plugin-and-windows-line-breaks)
> Therefore it would be a nice feature when the plugin would not use the
> systems line separator but the line separator that is already used in the
> pom.xml.
> On the other hand, changing the existing behaviour would maybe, also harm
> someone else.
> Therefore it would be an great feature when there would be an property that
> define the expected behaviour, maybe in the same way it is done by the
> maven-assembly-plugin's property fileSet.lineEnding
> (http://maven.apache.org/plugins/maven-assembly-plugin/component.html#class_fileSet)
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (MRELEASE-899) release:prepare should not change the line separator but detect effective line separator from pom.xml
[
https://issues.apache.org/jira/browse/MRELEASE-899?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17243062#comment-17243062
]
Alexander Kriegisch edited comment on MRELEASE-899 at 12/3/20, 9:57 AM:
[~michael-o], if you follow the link to the related Git issue I posted in
[#comment-14718349], there again are detailed instructions how to reproduce the
problem including a link to a sample repository. You can just try for yourself
if you like. I have not tried this in a while because this issue was silent for
so many years.
If you can reproduce and fix it, I can re-test with the reported Maven version
and a fixed one, though.
Update: The comment in the other ticket explaining how to reproduce it is [this
one|https://github.com/git-for-windows/git/issues/315#issuecomment-134602042]
was (Author: kriegaex):
[~michael-o], if you follow the link to the related Git issue I posted in
[#comment-14718349], there again are detailed instructions how to reproduce the
problem including a link to a sample repository. You can just try for yourself
if you like. I have not tried this in a while because this issue was silent for
so many years.
If you can reproduce and fix it, I can re-test with the reported Maven version
and a fixed one, though.
Update: The comment in the other explaining how to reproduce it is [this
one|https://github.com/git-for-windows/git/issues/315#issuecomment-134602042]
> release:prepare should not change the line separator but detect effective
> line separator from pom.xml
> -
>
> Key: MRELEASE-899
> URL: https://issues.apache.org/jira/browse/MRELEASE-899
> Project: Maven Release Plugin
> Issue Type: Improvement
>Reporter: Ralph van Etten
>Priority: Major
>
> Currently the plugin use the system property {{line.separator}} when it
> rewrites the pom.xml.
> This causes trouble, because every line in changed, when a project is
> released sometimes under Windows and sometimes under Linux (because of its
> different line separators).
> (http://stackoverflow.com/questions/11868590/maven-release-plugin-and-windows-line-breaks)
> Therefore it would be a nice feature when the plugin would not use the
> systems line separator but the line separator that is already used in the
> pom.xml.
> On the other hand, changing the existing behaviour would maybe, also harm
> someone else.
> Therefore it would be an great feature when there would be an property that
> define the expected behaviour, maybe in the same way it is done by the
> maven-assembly-plugin's property fileSet.lineEnding
> (http://maven.apache.org/plugins/maven-assembly-plugin/component.html#class_fileSet)
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (MRELEASE-899) release:prepare should not change the line separator but detect effective line separator from pom.xml
[
https://issues.apache.org/jira/browse/MRELEASE-899?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17243062#comment-17243062
]
Alexander Kriegisch edited comment on MRELEASE-899 at 12/3/20, 9:56 AM:
[~michael-o], if you follow the link to the related Git issue I posted in
[#comment-14718349], there again are detailed instructions how to reproduce the
problem including a link to a sample repository. You can just try for yourself
if you like. I have not tried this in a while because this issue was silent for
so many years.
If you can reproduce and fix it, I can re-test with the reported Maven version
and a fixed one, though.
Update: The comment in the other explaining how to reproduce it is [this
one|https://github.com/git-for-windows/git/issues/315#issuecomment-134602042]
was (Author: kriegaex):
[~michael-o], if you follow the link to the related Git issue I posted in
[#comment-14718349], there again are detailed instructions how to reproduce the
problem including a link to a sample repository. You can just try for yourself
if you like. I have not tried this in a while because this issue was silent for
so many years.
If you can reproduce and fix it, I can re-test with the reported Maven version
and a fixed one, though.
> release:prepare should not change the line separator but detect effective
> line separator from pom.xml
> -
>
> Key: MRELEASE-899
> URL: https://issues.apache.org/jira/browse/MRELEASE-899
> Project: Maven Release Plugin
> Issue Type: Improvement
>Reporter: Ralph van Etten
>Priority: Major
>
> Currently the plugin use the system property {{line.separator}} when it
> rewrites the pom.xml.
> This causes trouble, because every line in changed, when a project is
> released sometimes under Windows and sometimes under Linux (because of its
> different line separators).
> (http://stackoverflow.com/questions/11868590/maven-release-plugin-and-windows-line-breaks)
> Therefore it would be a nice feature when the plugin would not use the
> systems line separator but the line separator that is already used in the
> pom.xml.
> On the other hand, changing the existing behaviour would maybe, also harm
> someone else.
> Therefore it would be an great feature when there would be an property that
> define the expected behaviour, maybe in the same way it is done by the
> maven-assembly-plugin's property fileSet.lineEnding
> (http://maven.apache.org/plugins/maven-assembly-plugin/component.html#class_fileSet)
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (MRELEASE-899) release:prepare should not change the line separator but detect effective line separator from pom.xml
[
https://issues.apache.org/jira/browse/MRELEASE-899?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17243062#comment-17243062
]
Alexander Kriegisch edited comment on MRELEASE-899 at 12/3/20, 9:55 AM:
[~michael-o], if you follow the link to the related Git issue I posted in
[#comment-14718349], there again are detailed instructions how to reproduce the
problem including a link to a sample repository. You can just try for yourself
if you like. I have not tried this in a while because this issue was silent for
so many years.
If you can reproduce and fix it, I can re-test with the reported Maven version
and a fixed one, though.
was (Author: kriegaex):
[~michael-o], if you follow the link to the related Git issue I posted in
[#comment-14718349], there again are detailed instructions how to reproduce the
problem including a link to a sample repository. You can just try for yourself
if you like. I have not tried this in a while because this issue was silent for
so many years.
> release:prepare should not change the line separator but detect effective
> line separator from pom.xml
> -
>
> Key: MRELEASE-899
> URL: https://issues.apache.org/jira/browse/MRELEASE-899
> Project: Maven Release Plugin
> Issue Type: Improvement
>Reporter: Ralph van Etten
>Priority: Major
>
> Currently the plugin use the system property {{line.separator}} when it
> rewrites the pom.xml.
> This causes trouble, because every line in changed, when a project is
> released sometimes under Windows and sometimes under Linux (because of its
> different line separators).
> (http://stackoverflow.com/questions/11868590/maven-release-plugin-and-windows-line-breaks)
> Therefore it would be a nice feature when the plugin would not use the
> systems line separator but the line separator that is already used in the
> pom.xml.
> On the other hand, changing the existing behaviour would maybe, also harm
> someone else.
> Therefore it would be an great feature when there would be an property that
> define the expected behaviour, maybe in the same way it is done by the
> maven-assembly-plugin's property fileSet.lineEnding
> (http://maven.apache.org/plugins/maven-assembly-plugin/component.html#class_fileSet)
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (MRELEASE-899) release:prepare should not change the line separator but detect effective line separator from pom.xml
[
https://issues.apache.org/jira/browse/MRELEASE-899?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17243062#comment-17243062
]
Alexander Kriegisch edited comment on MRELEASE-899 at 12/3/20, 9:54 AM:
[~michael-o], if you follow the link to the related Git issue I posted in
[#comment-14718349], there again are detailed instructions how to reproduce the
problem including a link to a sample repository. You can just try for yourself
if you like. I have not tried this in a while because this issue was silent for
so many years.
was (Author: kriegaex):
[~michael-o], if you follow the link to the related Git issue I posted in
[#comment-14718349], there again are detailed instructions how to reproduce the
problem including a link to a sample repository. You can just try for yourself
if you like.
> release:prepare should not change the line separator but detect effective
> line separator from pom.xml
> -
>
> Key: MRELEASE-899
> URL: https://issues.apache.org/jira/browse/MRELEASE-899
> Project: Maven Release Plugin
> Issue Type: Improvement
>Reporter: Ralph van Etten
>Priority: Major
>
> Currently the plugin use the system property {{line.separator}} when it
> rewrites the pom.xml.
> This causes trouble, because every line in changed, when a project is
> released sometimes under Windows and sometimes under Linux (because of its
> different line separators).
> (http://stackoverflow.com/questions/11868590/maven-release-plugin-and-windows-line-breaks)
> Therefore it would be a nice feature when the plugin would not use the
> systems line separator but the line separator that is already used in the
> pom.xml.
> On the other hand, changing the existing behaviour would maybe, also harm
> someone else.
> Therefore it would be an great feature when there would be an property that
> define the expected behaviour, maybe in the same way it is done by the
> maven-assembly-plugin's property fileSet.lineEnding
> (http://maven.apache.org/plugins/maven-assembly-plugin/component.html#class_fileSet)
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MRELEASE-899) release:prepare should not change the line separator but detect effective line separator from pom.xml
[
https://issues.apache.org/jira/browse/MRELEASE-899?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17243062#comment-17243062
]
Alexander Kriegisch commented on MRELEASE-899:
--
[~michael-o], if you follow the link to the related Git issue I posted in
[#comment-14718349], there again are detailed instructions how to reproduce the
problem including a link to a sample repository. You can just try for yourself
if you like.
> release:prepare should not change the line separator but detect effective
> line separator from pom.xml
> -
>
> Key: MRELEASE-899
> URL: https://issues.apache.org/jira/browse/MRELEASE-899
> Project: Maven Release Plugin
> Issue Type: Improvement
>Reporter: Ralph van Etten
>Priority: Major
>
> Currently the plugin use the system property {{line.separator}} when it
> rewrites the pom.xml.
> This causes trouble, because every line in changed, when a project is
> released sometimes under Windows and sometimes under Linux (because of its
> different line separators).
> (http://stackoverflow.com/questions/11868590/maven-release-plugin-and-windows-line-breaks)
> Therefore it would be a nice feature when the plugin would not use the
> systems line separator but the line separator that is already used in the
> pom.xml.
> On the other hand, changing the existing behaviour would maybe, also harm
> someone else.
> Therefore it would be an great feature when there would be an property that
> define the expected behaviour, maybe in the same way it is done by the
> maven-assembly-plugin's property fileSet.lineEnding
> (http://maven.apache.org/plugins/maven-assembly-plugin/component.html#class_fileSet)
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (WAGON-590) Maven 3.5.0+ doesn't seem to send credentials after 301/302 HTTP redirect
[
https://issues.apache.org/jira/browse/WAGON-590?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17243053#comment-17243053
]
IG commented on WAGON-590:
--
Made it work with the following settings and wagon-3.4.2 inside maven 3.6.3 :
{code:java}
ANY
ANY
http.protocol.cookie-policy
standard
{code}
cookie-policy was still required for correct cookie handling.
> Maven 3.5.0+ doesn't seem to send credentials after 301/302 HTTP redirect
> -
>
> Key: WAGON-590
> URL: https://issues.apache.org/jira/browse/WAGON-590
> Project: Maven Wagon
> Issue Type: Bug
>Affects Versions: 3.4.0
>Reporter: Cintia DR
>Priority: Major
> Fix For: waiting-for-feedback
>
> Attachments: 0001-conditonally-set-AuthScope-to-any.patch, Screen
> Shot 2020-04-28 at 7.45.33 pm.png, any-auth.log,
> expect-continue-done-right-any-auth.log, master_osx.log, master_ubuntu.log,
> maven_x.log, mvn-master-batch.log, mvn-wagon590branch-debug-osx.log,
> mvn-wagon590branch-osx.log, mvn339_osx.log, mvn339_ubuntu.log, scoped-auth.log
>
>
> Since maven 3.5.0 (including 3.6.3), maven seems to not send server
> credentials if distributionManagement server response was a 301 or 302 HTTP
> redirect. Note that the redirect is followed, but I receive unauthorised code.
> Maven 3.2.5 and 3.3.9 work as expected. I could reproduce it on ubuntu and
> OSX. Both are JDK 8, not sure if it could make any difference.
>
> All maven versions (including 3.2.5 and 3.3.9) are using the same version of
> the deploy plugin (2.7), and upgrading it made no difference whatsoever.
>
> If I use '[https://openmrs.jfrog.io/artifactory/snapshots/'] as my
> 'distributionManagement', credentials are sent.
> If I use
> '[https://mavenrepo.openmrs.org/proxy/snapshots/|https://mavenrepo.openmrs.org/snapshots/']'
> (a reverse proxy to
> '[https://openmrs.jfrog.io/artifactory/snapshots/|https://openmrs.jfrog.io/artifactory/snapshots/']')
> credentials are sent.
> If I use '[https://mavenrepo.openmrs.org/snapshots/'] (a 301 redirect to
> [https://openmrs.jfrog.io/artifactory/snapshots/|https://openmrs.jfrog.io/artifactory/snapshots/'])
> as my distributionManagement, credentials are _not_ sent and the request
> fails as it's unauthenticated.
>
> You can see the configuration of 'mavenrepo.openmrs.org' server here:
> [https://github.com/openmrs/openmrs-contrib-itsmresources/blob/master/ansible/host_vars/campo.openmrs.org/vars#L33]
>
> All my artefacts are public to download, so I don't have a way to testing
> downloading artefacts with server credentials.
>
>
> This is how the output looks like in maven 3.6.3:
> {code:java}
>
> [INFO] --- maven-deploy-plugin:2.7:deploy (default-deploy) @
> releasetestmodule ---
> Downloading from openmrs-repo-snapshots:
> https://mavenrepo.openmrs.org/nexus/content/repositories/snapshots/org/openmrs/module/releasetestmodule/2.1.22-SNAPSHOT/maven-metadata.xml
> Downloaded from openmrs-repo-snapshots:
> https://mavenrepo.openmrs.org/nexus/content/repositories/snapshots/org/openmrs/module/releasetestmodule/2.1.22-SNAPSHOT/maven-metadata.xml
> (616 B at 132 B/s)
> Uploading to openmrs-repo-snapshots:
> https://mavenrepo.openmrs.org/nexus/content/repositories/snapshots/org/openmrs/module/releasetestmodule/2.1.22-SNAPSHOT/releasetestmodule-2.1.22-20200427.091851-13.pom
> ...
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-deploy-plugin:2.7:deploy (default-deploy) on
> project releasetestmodule: Failed to deploy artifacts: Could not transfer
> artifact org.openmrs.module:releasetestmodule:pom:2.1.22-20200427.091851-13
> from/to openmrs-repo-snapshots
> (https://mavenrepo.openmrs.org/nexus/content/repositories/snapshots):
> Transfer failed for
> https://openmrs.jfrog.io/artifactory/snapshots/org/openmrs/module/releasetestmodule/2.1.22-SNAPSHOT/releasetestmodule-2.1.22-20200427.091851-13.pom
> 401 Unauthorized -> [Help 1]{code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MRELEASE-899) release:prepare should not change the line separator but detect effective line separator from pom.xml
[
https://issues.apache.org/jira/browse/MRELEASE-899?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17243044#comment-17243044
]
Ralph van Etten commented on MRELEASE-899:
--
this plugin and maven in general
> release:prepare should not change the line separator but detect effective
> line separator from pom.xml
> -
>
> Key: MRELEASE-899
> URL: https://issues.apache.org/jira/browse/MRELEASE-899
> Project: Maven Release Plugin
> Issue Type: Improvement
>Reporter: Ralph van Etten
>Priority: Major
>
> Currently the plugin use the system property {{line.separator}} when it
> rewrites the pom.xml.
> This causes trouble, because every line in changed, when a project is
> released sometimes under Windows and sometimes under Linux (because of its
> different line separators).
> (http://stackoverflow.com/questions/11868590/maven-release-plugin-and-windows-line-breaks)
> Therefore it would be a nice feature when the plugin would not use the
> systems line separator but the line separator that is already used in the
> pom.xml.
> On the other hand, changing the existing behaviour would maybe, also harm
> someone else.
> Therefore it would be an great feature when there would be an property that
> define the expected behaviour, maybe in the same way it is done by the
> maven-assembly-plugin's property fileSet.lineEnding
> (http://maven.apache.org/plugins/maven-assembly-plugin/component.html#class_fileSet)
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MRELEASE-899) release:prepare should not change the line separator but detect effective line separator from pom.xml
[
https://issues.apache.org/jira/browse/MRELEASE-899?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17243028#comment-17243028
]
Michael Osipov commented on MRELEASE-899:
-
What do you mean by "it"?
> release:prepare should not change the line separator but detect effective
> line separator from pom.xml
> -
>
> Key: MRELEASE-899
> URL: https://issues.apache.org/jira/browse/MRELEASE-899
> Project: Maven Release Plugin
> Issue Type: Improvement
>Reporter: Ralph van Etten
>Priority: Major
>
> Currently the plugin use the system property {{line.separator}} when it
> rewrites the pom.xml.
> This causes trouble, because every line in changed, when a project is
> released sometimes under Windows and sometimes under Linux (because of its
> different line separators).
> (http://stackoverflow.com/questions/11868590/maven-release-plugin-and-windows-line-breaks)
> Therefore it would be a nice feature when the plugin would not use the
> systems line separator but the line separator that is already used in the
> pom.xml.
> On the other hand, changing the existing behaviour would maybe, also harm
> someone else.
> Therefore it would be an great feature when there would be an property that
> define the expected behaviour, maybe in the same way it is done by the
> maven-assembly-plugin's property fileSet.lineEnding
> (http://maven.apache.org/plugins/maven-assembly-plugin/component.html#class_fileSet)
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (MNG-5639) Support resolution of Import Scope POMs from Repo that contains a ${parameter}
[
https://issues.apache.org/jira/browse/MNG-5639?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov closed MNG-5639.
---
Fix Version/s: (was: 4.0.x-candidate)
3.2.2
Assignee: Jason van Zyl
Resolution: Fixed
> Support resolution of Import Scope POMs from Repo that contains a ${parameter}
> --
>
> Key: MNG-5639
> URL: https://issues.apache.org/jira/browse/MNG-5639
> Project: Maven
> Issue Type: Improvement
> Components: Dependencies
>Affects Versions: 3.2.1
>Reporter: Mark Ingram
>Assignee: Jason van Zyl
>Priority: Minor
> Fix For: 3.2.2
>
> Attachments: pom.xml
>
>
> Running mvn help:effective-pom on the attached POM:
> {noformat}[ERROR] The project
> com.ming:maven-failing-import-pom-example:1.0.0-SNAPSHOT
> (C:\wip\scratch-dev\maven-import-dependency-management\pom.xml) has 1 error
> [ERROR] Non-resolvable import POM: Could not transfer artifact
> org.springframework:spring-framework-bom:pom:4.0.0.R2 from/to
> spring-milestones (${spring.url}): No connector available to access
> repository spring-milestones (${spring.url}) of type default using the
> available factories WagonRepositoryConnectorFactory @ line 20, column 25 ->
> Help 2]{noformat}
> mvn help:effective-pom -Prepo-will-succeed works as expected.
> Note that prior to attempting the failing resolution, the full project POM
> model has successfully been resolved. So the correct value for the property
> is known and could in theory be substituted into the repository URL before
> the failing import pom resolve attempt.
> Will create a Github pull request with one possible solution to this - it
> includes a JUnit test case.
> Note: agreed this is a contrived example. To try and give an idea of the
> actual use case - several development streams are setup with individual
> sandboxed Nexus repository holding specific version of several shared
> components. The repository configuration uses the pattern
> $\{nexus.baseurl}/content/groups/$\{stream.name} with the properties set in
> settings.xml file.
> One workaround would be to create profiles for every work stream that
> explicitly list the full repository URL, even then the above feature would be
> nice to allow the $\{nexus.baseurl} to avoid repeating that part.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MRELEASE-899) release:prepare should not change the line separator but detect effective line separator from pom.xml
[
https://issues.apache.org/jira/browse/MRELEASE-899?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17243015#comment-17243015
]
Ralph van Etten commented on MRELEASE-899:
--
I don't know if this is still relevant. I've stopped using it years ago.
> release:prepare should not change the line separator but detect effective
> line separator from pom.xml
> -
>
> Key: MRELEASE-899
> URL: https://issues.apache.org/jira/browse/MRELEASE-899
> Project: Maven Release Plugin
> Issue Type: Improvement
>Reporter: Ralph van Etten
>Priority: Major
>
> Currently the plugin use the system property {{line.separator}} when it
> rewrites the pom.xml.
> This causes trouble, because every line in changed, when a project is
> released sometimes under Windows and sometimes under Linux (because of its
> different line separators).
> (http://stackoverflow.com/questions/11868590/maven-release-plugin-and-windows-line-breaks)
> Therefore it would be a nice feature when the plugin would not use the
> systems line separator but the line separator that is already used in the
> pom.xml.
> On the other hand, changing the existing behaviour would maybe, also harm
> someone else.
> Therefore it would be an great feature when there would be an property that
> define the expected behaviour, maybe in the same way it is done by the
> maven-assembly-plugin's property fileSet.lineEnding
> (http://maven.apache.org/plugins/maven-assembly-plugin/component.html#class_fileSet)
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-5639) Support resolution of Import Scope POMs from Repo that contains a ${parameter}
[
https://issues.apache.org/jira/browse/MNG-5639?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17243014#comment-17243014
]
Michael Osipov commented on MNG-5639:
-
Tried the revert on Core ITs. Except for MNG-5639 IT nothing else fails.
> Support resolution of Import Scope POMs from Repo that contains a ${parameter}
> --
>
> Key: MNG-5639
> URL: https://issues.apache.org/jira/browse/MNG-5639
> Project: Maven
> Issue Type: Improvement
> Components: Dependencies
>Affects Versions: 3.2.1
>Reporter: Mark Ingram
>Priority: Minor
> Fix For: 4.0.x-candidate
>
> Attachments: pom.xml
>
>
> Running mvn help:effective-pom on the attached POM:
> {noformat}[ERROR] The project
> com.ming:maven-failing-import-pom-example:1.0.0-SNAPSHOT
> (C:\wip\scratch-dev\maven-import-dependency-management\pom.xml) has 1 error
> [ERROR] Non-resolvable import POM: Could not transfer artifact
> org.springframework:spring-framework-bom:pom:4.0.0.R2 from/to
> spring-milestones (${spring.url}): No connector available to access
> repository spring-milestones (${spring.url}) of type default using the
> available factories WagonRepositoryConnectorFactory @ line 20, column 25 ->
> Help 2]{noformat}
> mvn help:effective-pom -Prepo-will-succeed works as expected.
> Note that prior to attempting the failing resolution, the full project POM
> model has successfully been resolved. So the correct value for the property
> is known and could in theory be substituted into the repository URL before
> the failing import pom resolve attempt.
> Will create a Github pull request with one possible solution to this - it
> includes a JUnit test case.
> Note: agreed this is a contrived example. To try and give an idea of the
> actual use case - several development streams are setup with individual
> sandboxed Nexus repository holding specific version of several shared
> components. The repository configuration uses the pattern
> $\{nexus.baseurl}/content/groups/$\{stream.name} with the properties set in
> settings.xml file.
> One workaround would be to create profiles for every work stream that
> explicitly list the full repository URL, even then the above feature would be
> nice to allow the $\{nexus.baseurl} to avoid repeating that part.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MRELEASE-899) release:prepare should not change the line separator but detect effective line separator from pom.xml
[
https://issues.apache.org/jira/browse/MRELEASE-899?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17243000#comment-17243000
]
Michael Osipov commented on MRELEASE-899:
-
I wanted a confirmation whether this still applies. You did not provide any. We
don't have a policy we are volunteers, we don't have to do anything. We do this
in our free time.
> release:prepare should not change the line separator but detect effective
> line separator from pom.xml
> -
>
> Key: MRELEASE-899
> URL: https://issues.apache.org/jira/browse/MRELEASE-899
> Project: Maven Release Plugin
> Issue Type: Improvement
>Reporter: Ralph van Etten
>Priority: Major
>
> Currently the plugin use the system property {{line.separator}} when it
> rewrites the pom.xml.
> This causes trouble, because every line in changed, when a project is
> released sometimes under Windows and sometimes under Linux (because of its
> different line separators).
> (http://stackoverflow.com/questions/11868590/maven-release-plugin-and-windows-line-breaks)
> Therefore it would be a nice feature when the plugin would not use the
> systems line separator but the line separator that is already used in the
> pom.xml.
> On the other hand, changing the existing behaviour would maybe, also harm
> someone else.
> Therefore it would be an great feature when there would be an property that
> define the expected behaviour, maybe in the same way it is done by the
> maven-assembly-plugin's property fileSet.lineEnding
> (http://maven.apache.org/plugins/maven-assembly-plugin/component.html#class_fileSet)
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
