[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&focusedCommentId=17248307#comment-17248307
]
Alexander Kriegisch edited comment on MRELEASE-899 at 12/12/20, 8:17 AM:
-
[~michael-o], I was not talking about an editor but about Git. Git is an SCM,
not an editor. The entity editing the POM is this plugin!
Um, of course it would be nice to have a little line detector tool in Commons
IO. But why push off this requirement to another project -if a change in this
one caused something which was previously working to suddenly break-? Why not
implement a solution here first and then let Commons IO maintainers decide if
they want to take over the functionality in identical or similar form? After
that and totally decoupled from the Commons IO release cycle, you could still
transition/migrate to the solution in that library.
*Edit:* Sorry, ** this issue is so old I remembered wrong. Probably the
plugin's behaviour has not changed but the problems are caused by a change
within Git for Windows which they refused to fix when asked a few years ago. I
struck through the incorrect part of my previous statement above. My apologies
for mixing up things in my faint memory.
If anyone likes to take a look at a seemingly quite sophisticated line
detector, IntelliJ IDEA has something like that:
[https://github.com/JetBrains/intellij-community/blob/837fed317de77e85c65ea0b75ea24f28a210eba4/platform/core-impl/src/com/intellij/openapi/fileEditor/impl/LoadTextUtil.java#L664-L684]
[https://github.com/JetBrains/intellij-community/blob/837fed317de77e85c65ea0b75ea24f28a210eba4/platform/core-impl/src/com/intellij/openapi/fileEditor/impl/LoadTextUtil.java#L718-L743]
I did not look into the details, but maybe this is something to get inspiration
from.
was (Author: kriegaex):
[~michael-o], I was not talking about an editor but about Git. Git is an SCM,
not an editor. The entity editing the POM is this plugin!
Um, of course it would be nice to have a little line detector tool in Commons
IO. But why push off this requirement to another project if a change in this
one caused something which was previously working to suddenly break? Why not
implement a solution here first and then let Commons IO maintainers decide if
they want to take over the functionality in identical or similar form? After
that and totally decoupled from the Commons IO release cycle, you could still
transition/migrate to the solution in that library.
> 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&focusedCommentId=17248307#comment-17248307
]
Alexander Kriegisch edited comment on MRELEASE-899 at 12/12/20, 8:19 AM:
-
[~michael-o], I was not talking about an editor but about Git. Git is an SCM,
not an editor. The entity editing the POM is this plugin!
Um, of course it would be nice to have a little line detector tool in Commons
IO. But why push off this requirement to another project -if a change in this
one caused something which was previously working to suddenly break-? Why not
implement a solution here first and then let Commons IO maintainers decide if
they want to take over the functionality in identical or similar form? After
that and totally decoupled from the Commons IO release cycle, you could still
transition/migrate to the solution in that library.
*Edit:* Sorry, this issue is so old I remembered wrong. Probably the plugin's
behaviour has not changed but the problems are caused by a change within Git
for Windows which they refused to fix when asked a few years ago. I struck
through the incorrect part of my previous statement above. My apologies for
mixing up things in my faint memory.
If anyone likes to take a look at a seemingly quite sophisticated line
detector, IntelliJ IDEA has something like that:
[https://github.com/JetBrains/intellij-community/blob/837fed317de77e85c65ea0b75ea24f28a210eba4/platform/core-impl/src/com/intellij/openapi/fileEditor/impl/LoadTextUtil.java#L664-L684]
[https://github.com/JetBrains/intellij-community/blob/837fed317de77e85c65ea0b75ea24f28a210eba4/platform/core-impl/src/com/intellij/openapi/fileEditor/impl/LoadTextUtil.java#L718-L743]
I did not look into the details, but maybe this is something to get inspiration
from.
was (Author: kriegaex):
[~michael-o], I was not talking about an editor but about Git. Git is an SCM,
not an editor. The entity editing the POM is this plugin!
Um, of course it would be nice to have a little line detector tool in Commons
IO. But why push off this requirement to another project -if a change in this
one caused something which was previously working to suddenly break-? Why not
implement a solution here first and then let Commons IO maintainers decide if
they want to take over the functionality in identical or similar form? After
that and totally decoupled from the Commons IO release cycle, you could still
transition/migrate to the solution in that library.
*Edit:* Sorry, ** this issue is so old I remembered wrong. Probably the
plugin's behaviour has not changed but the problems are caused by a change
within Git for Windows which they refused to fix when asked a few years ago. I
struck through the incorrect part of my previous statement above. My apologies
for mixing up things in my faint memory.
If anyone likes to take a look at a seemingly quite sophisticated line
detector, IntelliJ IDEA has something like that:
[https://github.com/JetBrains/intellij-community/blob/837fed317de77e85c65ea0b75ea24f28a210eba4/platform/core-impl/src/com/intellij/openapi/fileEditor/impl/LoadTextUtil.java#L664-L684]
[https://github.com/JetBrains/intellij-community/blob/837fed317de77e85c65ea0b75ea24f28a210eba4/platform/core-impl/src/com/intellij/openapi/fileEditor/impl/LoadTextUtil.java#L718-L743]
I did not look into the details, but maybe this is something to get inspiration
from.
> 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#803
[GitHub] [maven-deploy-plugin] mickroll commented on a change in pull request #12: [MDEPLOY-279] Better validation for alt deploy repository mojo parameter
mickroll commented on a change in pull request #12:
URL: https://github.com/apache/maven-deploy-plugin/pull/12#discussion_r541552391
##
File path: src/main/java/org/apache/maven/plugins/deploy/DeployMojo.java
##
@@ -248,19 +249,40 @@ else if ( !ArtifactUtils.isSnapshot( project.getVersion()
) && altReleaseDeploym
{
getLog().info( "Using alternate deployment repository " +
altDeploymentRepo );
-Matcher matcher = ALT_REPO_SYNTAX_PATTERN.matcher(
altDeploymentRepo );
+Matcher matcher = ALT_LEGACY_REPO_SYNTAX_PATTERN.matcher(
altDeploymentRepo );
-if ( !matcher.matches() )
+if ( matcher.matches() )
{
-throw new MojoFailureException( altDeploymentRepo, "Invalid
syntax for repository.",
-"Invalid syntax for
alternative repository. Use \"id::url\"." );
+getLog().warn( "Legacy form of alternate deployment parameter
used, update parameter to match plugin version." );
Review comment:
This message hides a lot of information that was gathered before. At
this point, the plugin knows that `id::layout::url` was used (but expects
`id::url`, of course). The message should reflect that, not just by saying `you
used the old notation, use the new one. RTFM`, but more like `you used the 2.x
notation id::layout::url, 3.x expects id::url`.
This would give not just a hint to whats wrong, but provide a solution... To
me, this is the difference of a good plugin to a great one :sunglasses:
With this, it would be totally fine (and expected) to fail with the message,
not continuing the build 'magically' if the layout is `default`.
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-deploy-plugin] cstamas commented on a change in pull request #12: [MDEPLOY-279] Better validation for alt deploy repository mojo parameter
cstamas commented on a change in pull request #12:
URL: https://github.com/apache/maven-deploy-plugin/pull/12#discussion_r541560654
##
File path: src/main/java/org/apache/maven/plugins/deploy/DeployMojo.java
##
@@ -248,19 +249,40 @@ else if ( !ArtifactUtils.isSnapshot( project.getVersion()
) && altReleaseDeploym
{
getLog().info( "Using alternate deployment repository " +
altDeploymentRepo );
-Matcher matcher = ALT_REPO_SYNTAX_PATTERN.matcher(
altDeploymentRepo );
+Matcher matcher = ALT_LEGACY_REPO_SYNTAX_PATTERN.matcher(
altDeploymentRepo );
-if ( !matcher.matches() )
+if ( matcher.matches() )
{
-throw new MojoFailureException( altDeploymentRepo, "Invalid
syntax for repository.",
-"Invalid syntax for
alternative repository. Use \"id::url\"." );
+getLog().warn( "Legacy form of alternate deployment parameter
used, update parameter to match plugin version." );
Review comment:
Will rework the PR then as follows:
* Mojo will first match LEGACY pattern,
* if matched, build will fail, but the message will be saying what the
problem is (legacy notation) and provide solution (modern notation), will not
"magically" continue if layout is `default`
* continue with current pattern...
This order (legacy then modern) is needed, as we saw, that modern pattern
"matches" legacy notation, but messes up repositoryId (ends up w/
`serverId::default` and fails to find serverId in settings). This way, we
exclude that possibility to have 2 (legacy), 3 (plain wrong) and more `::`s in
string, as all those will be caught by legacy pattern (and in that case would
provide bad "solution".
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&focusedCommentId=17248333#comment-17248333
]
Michael Osipov commented on MRELEASE-899:
-
I have suffered from the View/Edit issue many times...
Since the IntelliJ source is ALv2.0, but may someone can skim and port to
MRELEASE. That's be awesome.
> 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-deploy-plugin] michael-o commented on a change in pull request #12: [MDEPLOY-279] Better validation for alt deploy repository mojo parameter
michael-o commented on a change in pull request #12:
URL: https://github.com/apache/maven-deploy-plugin/pull/12#discussion_r541561101
##
File path: src/main/java/org/apache/maven/plugins/deploy/DeployMojo.java
##
@@ -248,19 +249,40 @@ else if ( !ArtifactUtils.isSnapshot( project.getVersion()
) && altReleaseDeploym
{
getLog().info( "Using alternate deployment repository " +
altDeploymentRepo );
-Matcher matcher = ALT_REPO_SYNTAX_PATTERN.matcher(
altDeploymentRepo );
+Matcher matcher = ALT_LEGACY_REPO_SYNTAX_PATTERN.matcher(
altDeploymentRepo );
-if ( !matcher.matches() )
+if ( matcher.matches() )
{
-throw new MojoFailureException( altDeploymentRepo, "Invalid
syntax for repository.",
-"Invalid syntax for
alternative repository. Use \"id::url\"." );
+getLog().warn( "Legacy form of alternate deployment parameter
used, update parameter to match plugin version." );
Review comment:
Very nice! As I have said it is all about greedy regex
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-deploy-plugin] cstamas commented on a change in pull request #12: [MDEPLOY-279] Better validation for alt deploy repository mojo parameter
cstamas commented on a change in pull request #12:
URL: https://github.com/apache/maven-deploy-plugin/pull/12#discussion_r541561424
##
File path: src/main/java/org/apache/maven/plugins/deploy/DeployMojo.java
##
@@ -248,19 +249,40 @@ else if ( !ArtifactUtils.isSnapshot( project.getVersion()
) && altReleaseDeploym
{
getLog().info( "Using alternate deployment repository " +
altDeploymentRepo );
-Matcher matcher = ALT_REPO_SYNTAX_PATTERN.matcher(
altDeploymentRepo );
+Matcher matcher = ALT_LEGACY_REPO_SYNTAX_PATTERN.matcher(
altDeploymentRepo );
-if ( !matcher.matches() )
+if ( matcher.matches() )
{
-throw new MojoFailureException( altDeploymentRepo, "Invalid
syntax for repository.",
-"Invalid syntax for
alternative repository. Use \"id::url\"." );
+getLog().warn( "Legacy form of alternate deployment parameter
used, update parameter to match plugin version." );
Review comment:
... now only to figure out on which computer I created this PR
:laughing:
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] (MRESOLVER-151) Switch the default checksum policy from "warn" to "fail"
[
https://issues.apache.org/jira/browse/MRESOLVER-151?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17248335#comment-17248335
]
Michael Osipov commented on MRESOLVER-151:
--
Correct, that's an implemenation error.
> Switch the default checksum policy from "warn" to "fail"
>
>
> Key: MRESOLVER-151
> URL: https://issues.apache.org/jira/browse/MRESOLVER-151
> Project: Maven Resolver
> Issue Type: Task
> Components: Resolver
>Affects Versions: 1.6.1
>Reporter: Michael Osipov
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 1.7.0
>
>
> This mirrors MNG-5728. The change has to happen in
> {{DefaultChecksumPolicyProvider}}.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MPLUGIN-243) add an option to hide a mojo parameter from generated documentation
[ https://issues.apache.org/jira/browse/MPLUGIN-243?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17248334#comment-17248334 ] Michael Osipov commented on MPLUGIN-243: [~muesli4], do you want me to reopen? No one worked on this for several years. Do you consider to pick this up or do we want this to dangle for another 5 years? > add an option to hide a mojo parameter from generated documentation > --- > > Key: MPLUGIN-243 > URL: https://issues.apache.org/jira/browse/MPLUGIN-243 > Project: Maven Plugin Tools > Issue Type: Improvement > Components: maven-plugin-annotations, > maven-plugin-tools-annotations, maven-plugin-tools-java, > maven-plugin-tools-javadoc >Affects Versions: 3.2 >Reporter: Herve Boutemy >Priority: Minor > > when a parameter is defined in a parent mojo, because it needs to be shared > by some child mojos, but some other child mojos don't use the feature, > parameter documentation just adds unnecessary complexity > see MDEP-413 for such an example -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (MRESOLVER-151) Switch the default checksum policy from "warn" to "fail"
[
https://issues.apache.org/jira/browse/MRESOLVER-151?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17248335#comment-17248335
]
Michael Osipov edited comment on MRESOLVER-151 at 12/12/20, 11:59 AM:
--
Correct, that's an implemenation error. I will create new issue for that.
But this issue, is the approach acceptable?
was (Author: michael-o):
Correct, that's an implemenation error.
> Switch the default checksum policy from "warn" to "fail"
>
>
> Key: MRESOLVER-151
> URL: https://issues.apache.org/jira/browse/MRESOLVER-151
> Project: Maven Resolver
> Issue Type: Task
> Components: Resolver
>Affects Versions: 1.6.1
>Reporter: Michael Osipov
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 1.7.0
>
>
> This mirrors MNG-5728. The change has to happen in
> {{DefaultChecksumPolicyProvider}}.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [maven] michael-o commented on pull request #409: Revert MNG-5639
michael-o commented on pull request #409: URL: https://github.com/apache/maven/pull/409#issuecomment-743745983 @rf Sine you accepted the IT PR, would you accept this one as well? 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] michael-o edited a comment on pull request #409: Revert MNG-5639
michael-o edited a comment on pull request #409: URL: https://github.com/apache/maven/pull/409#issuecomment-743745983 @rfscholte Sine you accepted the IT PR, would you accept this one as well? 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] (MRESOLVER-151) Switch the default checksum policy from "warn" to "fail"
[
https://issues.apache.org/jira/browse/MRESOLVER-151?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17248338#comment-17248338
]
Robert Scholte commented on MRESOLVER-151:
--
My conclusion is, that there will be no need for a default policy anymore.
> Switch the default checksum policy from "warn" to "fail"
>
>
> Key: MRESOLVER-151
> URL: https://issues.apache.org/jira/browse/MRESOLVER-151
> Project: Maven Resolver
> Issue Type: Task
> Components: Resolver
>Affects Versions: 1.6.1
>Reporter: Michael Osipov
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 1.7.0
>
>
> This mirrors MNG-5728. The change has to happen in
> {{DefaultChecksumPolicyProvider}}.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MDEPLOY-279) Missing validation of altDeploymentRepository mojo parameter
[
https://issues.apache.org/jira/browse/MDEPLOY-279?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17248339#comment-17248339
]
Tamás Cservenák commented on MDEPLOY-279:
-
But still, that would fail at deploy attempt, too late IMHO. I think current PR
reflects the intent the best:
* fail fast build with any (legacy, insane) altDeployment string
* provide useful error message when legacy used (user can just use it:
copy+paste)
* works only with "modern" syntax
This is most fool proof and even "hasty proof" (for my case) as my "reproducer"
that is about switching m-d-p between 2.x and 3.x would simply fail, as I was
unaware that 3.x changed syntax, and expected to have "same thing" for same CLI
input but different plugin version, which, is not true.
> Missing validation of altDeploymentRepository mojo parameter
>
>
> Key: MDEPLOY-279
> URL: https://issues.apache.org/jira/browse/MDEPLOY-279
> Project: Maven Deploy Plugin
> Issue Type: Bug
> Components: deploy:deploy
>Affects Versions: 3.0.0-M1
>Reporter: Tamás Cservenák
>Assignee: Michael Osipov
>Priority: Major
>
> Reproducer: [https://github.com/cstamas/mvn-md-bug]
> Command like: {{mvn clean deploy
> -DaltDeploymentRepository=localhost-nexus::default::http://localhost:8081/content/repositories/snapshots/}}
> (w/ 3.0.0-M1 m-d-p, needs POM edit)
> As seen in MDEPLOY-274, m-d-p 2.x succeeds, while 3.x fails with _same CLI
> command line_.
> True, the parameter did change between 2.x and 3.x, still IMO validation is
> missing: 3.x should either fail early (not at attempted deploy w/o
> credentials) or at least WARN about "not recognized parameter", or best.
> accept 2.x format as well, but only if layout is "default".
> Maybe some other changed parameters needs some validation as well.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [maven-deploy-plugin] cstamas opened a new pull request #13: Add GH CI
cstamas opened a new pull request #13: URL: https://github.com/apache/maven-deploy-plugin/pull/13 To validate PRs w/ running UTs and ITs 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-deploy-plugin] slachiewicz merged pull request #13: Add GH CI
slachiewicz merged pull request #13: URL: https://github.com/apache/maven-deploy-plugin/pull/13 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MPLUGIN-243) add an option to hide a mojo parameter from generated documentation
[ https://issues.apache.org/jira/browse/MPLUGIN-243?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17248344#comment-17248344 ] Moritz Bruder commented on MPLUGIN-243: --- [~michael-o], I'm currently reading into the code. I'm interested in working on a few issues regarding the Parameter-Annotation. This also includes to make the programmatic mechanism for complex types as parameters a bit safer (e.g., by providing a different annotation). First of all, I want to know whether someone is interested in such changes or if there is opposition to those ideas. It may take some time because I don't have that much. > add an option to hide a mojo parameter from generated documentation > --- > > Key: MPLUGIN-243 > URL: https://issues.apache.org/jira/browse/MPLUGIN-243 > Project: Maven Plugin Tools > Issue Type: Improvement > Components: maven-plugin-annotations, > maven-plugin-tools-annotations, maven-plugin-tools-java, > maven-plugin-tools-javadoc >Affects Versions: 3.2 >Reporter: Herve Boutemy >Priority: Minor > > when a parameter is defined in a parent mojo, because it needs to be shared > by some child mojos, but some other child mojos don't use the feature, > parameter documentation just adds unnecessary complexity > see MDEP-413 for such an example -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MDEPLOY-254) Maven Deploy Plugin deploy jar twice : Maven 3.3.3
[
https://issues.apache.org/jira/browse/MDEPLOY-254?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17248349#comment-17248349
]
Tamás Cservenák commented on MDEPLOY-254:
-
I see MNG-5868 that should fix this? Is on master, not yet released. Also,
Maven 3.0 rejected duplicates as well, so the "duplication detection" got
removed somewhere between 3 and current master?
> Maven Deploy Plugin deploy jar twice : Maven 3.3.3
> --
>
> Key: MDEPLOY-254
> URL: https://issues.apache.org/jira/browse/MDEPLOY-254
> Project: Maven Deploy Plugin
> Issue Type: Bug
>Reporter: Akshay
>Assignee: Karl Heinz Marbaise
>Priority: Blocker
> Fix For: waiting-for-feedback
>
> Attachments: log1-mvn_clean_deploy_-Ptwice-source-jar-goal.txt,
> log2-mvn_clean_deploy_-Psource-and-shade-plugin.txt, sample-project.zip
>
>
> Failed to execute goal
> org.apache.maven.plugins:maven-deploy-plugin:2.7:deploy (default-deploy) on
> project ** :
> Failed to retrieve remote metadata **/maven-metadata.xml:
> Could not transfer metadata ** from/to **
> {color:#FF} Not authorized , ReasonPhrase:Unauthorized. {color}
>
> Wanted to know if the fix is out in a later version of Maven?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (MDEPLOY-280) Ability so skip certain classifiers from deploy
Tamás Cservenák created MDEPLOY-280: --- Summary: Ability so skip certain classifiers from deploy Key: MDEPLOY-280 URL: https://issues.apache.org/jira/browse/MDEPLOY-280 Project: Maven Deploy Plugin Issue Type: Improvement Components: deploy:deploy Reporter: Tamás Cservenák There are cases when producing and attaching "derivative" artifacts (docker image of main artifact, rpm of same, etc) is needed, but their deploy is not wanted, as they are either used only during ITs, and are "just derivative", or, they are to be deployed in their format specific registries/repositories instead. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [maven-deploy-plugin] cstamas opened a new pull request #14: [MDEPLOY-280] Ability so skip specified classifiers from deploy
cstamas opened a new pull request #14: URL: https://github.com/apache/maven-deploy-plugin/pull/14 Add deploy mojo parameter that allows one to skip certain classifiers from deploy. 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] (MDEPLOY-280) Ability so skip certain classifiers from deploy
[ https://issues.apache.org/jira/browse/MDEPLOY-280?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17248418#comment-17248418 ] Robert Scholte commented on MDEPLOY-280: I would expect specialized packaging lifecycles that don't define the install and deploy phase. Or am I missing something? To me it would make more sense to solve this at the plugin that attaches the artifact, because now both both install and deploy need this kind of fix. That's a sign for me that this is solved at the wrong spot. > Ability so skip certain classifiers from deploy > --- > > Key: MDEPLOY-280 > URL: https://issues.apache.org/jira/browse/MDEPLOY-280 > Project: Maven Deploy Plugin > Issue Type: Improvement > Components: deploy:deploy >Reporter: Tamás Cservenák >Priority: Minor > > There are cases when producing and attaching "derivative" artifacts (docker > image of main artifact, rpm of same, etc) is needed, but their deploy is not > wanted, as they are either used only during ITs, and are "just derivative", > or, they are to be deployed in their format specific registries/repositories > instead. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MDEPLOY-280) Ability so skip certain classifiers from deploy
[ https://issues.apache.org/jira/browse/MDEPLOY-280?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17248420#comment-17248420 ] Tamás Cservenák commented on MDEPLOY-280: - I agree with you, ideally, yes, this is the "producer" issue (something that produces and attaches). The M-D-P change could be more like a "last resort" (maybe emphasize that in parameter doco as well), something you really want to use ONLY until the "producer" does not accept the patch someone provided :) or does not address the issue somehow differently. So if you use some plugin, cannot modify it immediately (to prevent attaching something, but your build does need it's product), the possibility is still there... > Ability so skip certain classifiers from deploy > --- > > Key: MDEPLOY-280 > URL: https://issues.apache.org/jira/browse/MDEPLOY-280 > Project: Maven Deploy Plugin > Issue Type: Improvement > Components: deploy:deploy >Reporter: Tamás Cservenák >Priority: Minor > > There are cases when producing and attaching "derivative" artifacts (docker > image of main artifact, rpm of same, etc) is needed, but their deploy is not > wanted, as they are either used only during ITs, and are "just derivative", > or, they are to be deployed in their format specific registries/repositories > instead. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-7037) Add JPMS support -> solve split packages problem
[ https://issues.apache.org/jira/browse/MNG-7037?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17248422#comment-17248422 ] Pavel_K commented on MNG-7037: -- [~michael-o] Package naming strategy must be developed by the lead developers of the project. I am just a maven user. So, it is at least wrong to suggest me to make a PR. > Add JPMS support -> solve split packages problem > > > Key: MNG-7037 > URL: https://issues.apache.org/jira/browse/MNG-7037 > Project: Maven > Issue Type: Improvement >Affects Versions: 3.6.3 >Reporter: Pavel_K >Priority: Major > > I use apache maven with apache maven resolver in JPMS environment as > automatic modules. At least I wanted to use them this way. When I started my > application I got > java.lang.module.ResolutionException: Modules maven.model.builder and > maven.model export package org.apache.maven.model.merge to module > mymodule.core. > Please, add JPMS support. 2020 is ending and there are still split packages. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MDEPLOY-280) Ability so skip certain classifiers from deploy
[ https://issues.apache.org/jira/browse/MDEPLOY-280?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17248438#comment-17248438 ] Robert Scholte commented on MDEPLOY-280: In my quest to reduce the number of skip parameters, let's not try to introduce new ones if we know the problem is actually somewhere else. > Ability so skip certain classifiers from deploy > --- > > Key: MDEPLOY-280 > URL: https://issues.apache.org/jira/browse/MDEPLOY-280 > Project: Maven Deploy Plugin > Issue Type: Improvement > Components: deploy:deploy >Reporter: Tamás Cservenák >Priority: Minor > > There are cases when producing and attaching "derivative" artifacts (docker > image of main artifact, rpm of same, etc) is needed, but their deploy is not > wanted, as they are either used only during ITs, and are "just derivative", > or, they are to be deployed in their format specific registries/repositories > instead. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (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&focusedCommentId=17248450#comment-17248450 ] Will Iverson edited comment on MNG-7044 at 12/12/20, 8:07 PM: -- I just did some more testing, and it appears that the pom.xml in the user's project is the same as the pom that gets published (e.g. included in the jar generated by package), which would absolutely lead to breakage. That level of breakage is contrary to the whole point of this proposal (allow a user local pom.xml to use attributes, but keep the pom.xml published to repositories the same as today with elements). I thought that the published pom.xml included in the release was generated/modified, but that's apparently not true (and clarifies the purpose of the Build vs Consumer POM proposal (https://cwiki.apache.org/confluence/display/MAVEN/Build+vs+Consumer+POM). In the past I could have sworn the final pom published was not the same as the pom.xml in the user directory, but that appears to not be the case (at least for an ordinary project). It's possible that some tooling I was using (e.g. my CI tool) was tweaking the pom during publishing, which is where I got the idea that happened by default. *To restate more simply: The pom.xml in the user's directory is the _same_ as the pom.xml that is bundled into the JAR produced by package. So, _no_ changes can be made to the userland pom.xml without also breaking downstream publishing. * That's a killer for the proposal, at least if/until Build vs Consumer comes along. In the meantime, the only thing I can think of is for Maven core to add a bit more native support for polyglot to make it easier to work with, but that's an entirely different thing. Here is the link to Build/Consumer: https://cwiki.apache.org/confluence/display/MAVEN/Build+vs+Consumer+POM Go ahead and close this issue - if possible go ahead and link it to an issue for Build/Consumer if it exists in JIRA. Thanks! -Will was (Author: wiverson): I just did some more testing, and it appears that the pom.xml in the user's project is the same as the pom that gets published (e.g. included in the jar generated by package), which would absolutely lead to breakage. That level of breakage is contrary to the whole point of this proposal (allow a user local pom.xml to use attributes, but keep the pom.xml published to repositories the same as today with elements). I thought that the published pom.xml included in the release was generated/modified, but that's apparently not true (and clarifies the purpose of the Build vs Consumer POM proposal (https://cwiki.apache.org/confluence/display/MAVEN/Build+vs+Consumer+POM). In the past I could have sworn the final pom published was not the same as the pom.xml in the user directory, but that appears to not be the case (at least for an ordinary project). It's possible that some tooling I was using (e.g. my CI tool) was tweaking the pom during publishing, which is where I got the idea that happened by default. *To restate more simply: The pom.xml in the user's directory is the *same* as the pom.xml that is bundled into the JAR produced by package. So, *no* changes can be made to the userland pom.xml without also breaking downstream publishing. * That's a killer for the proposal, at least if/until Build vs Consumer comes along. In the meantime, the only thing I can think of is for Maven core to add a bit more native support for polyglot to make it easier to work with, but that's an entirely different thing. Here is the link to Build/Consumer: https://cwiki.apache.org/confluence/display/MAVEN/Build+vs+Consumer+POM Go ahead and close this issue - if possible go ahead and link it to an issue for Build/Consumer if it exists in JIRA. Thanks! -Will > 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 wou
[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&focusedCommentId=17248450#comment-17248450 ] Will Iverson commented on MNG-7044: --- I just did some more testing, and it appears that the pom.xml in the user's project is the same as the pom that gets published (e.g. included in the jar generated by package), which would absolutely lead to breakage. That level of breakage is contrary to the whole point of this proposal (allow a user local pom.xml to use attributes, but keep the pom.xml published to repositories the same as today with elements). I thought that the published pom.xml included in the release was generated/modified, but that's apparently not true (and clarifies the purpose of the Build vs Consumer POM proposal (https://cwiki.apache.org/confluence/display/MAVEN/Build+vs+Consumer+POM). In the past I could have sworn the final pom published was not the same as the pom.xml in the user directory, but that appears to not be the case (at least for an ordinary project). It's possible that some tooling I was using (e.g. my CI tool) was tweaking the pom during publishing, which is where I got the idea that happened by default. *To restate more simply: The pom.xml in the user's directory is the *same* as the pom.xml that is bundled into the JAR produced by package. So, *no* changes can be made to the userland pom.xml without also breaking downstream publishing. * That's a killer for the proposal, at least if/until Build vs Consumer comes along. In the meantime, the only thing I can think of is for Maven core to add a bit more native support for polyglot to make it easier to work with, but that's an entirely different thing. Here is the link to Build/Consumer: https://cwiki.apache.org/confluence/display/MAVEN/Build+vs+Consumer+POM Go ahead and close this issue - if possible go ahead and link it to an issue for Build/Consumer if it exists in JIRA. Thanks! -Will > 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] [Comment Edited] (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&focusedCommentId=17248450#comment-17248450 ] Will Iverson edited comment on MNG-7044 at 12/12/20, 8:08 PM: -- I just did some more testing, and it appears that the pom.xml in the user's project is the same as the pom that gets published (e.g. included in the jar generated by package), which would absolutely lead to breakage. That level of breakage is contrary to the whole point of this proposal (allow a user local pom.xml to use attributes, but keep the pom.xml published to repositories the same as today with elements). I thought that the published pom.xml included in the release was generated/modified, but that's apparently not true (and clarifies the purpose of the Build vs Consumer POM proposal (https://cwiki.apache.org/confluence/display/MAVEN/Build+vs+Consumer+POM). In the past I could have sworn the final pom published was not the same as the pom.xml in the user directory, but that appears to not be the case (at least for an ordinary project). It's possible that some tooling I was using (e.g. my CI tool) was tweaking the pom during publishing, which is where I got the idea that happened by default. *To restate more simply: The pom.xml in the user's directory is the _same_ as the pom.xml that is bundled into the JAR produced by package. So, _no_ changes can be made to the userland pom.xml without also breaking downstream publishing. * That's a killer for the proposal, at least if/until Build vs Consumer comes along. In the meantime, the only thing I can think of is for Maven core to add a bit more native support for polyglot to make it easier to work with, but that's an entirely different thing. Here is the link to Build/Consumer: https://cwiki.apache.org/confluence/display/MAVEN/Build+vs+Consumer+POM Go ahead and close this issue - if possible go ahead and link it to an issue for Build/Consumer if it exists in JIRA. Thanks! -Will was (Author: wiverson): I just did some more testing, and it appears that the pom.xml in the user's project is the same as the pom that gets published (e.g. included in the jar generated by package), which would absolutely lead to breakage. That level of breakage is contrary to the whole point of this proposal (allow a user local pom.xml to use attributes, but keep the pom.xml published to repositories the same as today with elements). I thought that the published pom.xml included in the release was generated/modified, but that's apparently not true (and clarifies the purpose of the Build vs Consumer POM proposal (https://cwiki.apache.org/confluence/display/MAVEN/Build+vs+Consumer+POM). In the past I could have sworn the final pom published was not the same as the pom.xml in the user directory, but that appears to not be the case (at least for an ordinary project). It's possible that some tooling I was using (e.g. my CI tool) was tweaking the pom during publishing, which is where I got the idea that happened by default. *To restate more simply: The pom.xml in the user's directory is the _same_ as the pom.xml that is bundled into the JAR produced by package. So, _no_ changes can be made to the userland pom.xml without also breaking downstream publishing. * That's a killer for the proposal, at least if/until Build vs Consumer comes along. In the meantime, the only thing I can think of is for Maven core to add a bit more native support for polyglot to make it easier to work with, but that's an entirely different thing. Here is the link to Build/Consumer: https://cwiki.apache.org/confluence/display/MAVEN/Build+vs+Consumer+POM Go ahead and close this issue - if possible go ahead and link it to an issue for Build/Consumer if it exists in JIRA. Thanks! -Will > 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
[jira] [Comment Edited] (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&focusedCommentId=17248450#comment-17248450 ] Will Iverson edited comment on MNG-7044 at 12/12/20, 8:08 PM: -- I just did some more testing, and it appears that the pom.xml in the user's project is the same as the pom that gets published (e.g. included in the jar generated by package), which would absolutely lead to breakage. That level of breakage is contrary to the whole point of this proposal (allow a user local pom.xml to use attributes, but keep the pom.xml published to repositories the same as today with elements). I thought that the published pom.xml included in the release was generated/modified, but that's apparently not true (and clarifies the purpose of the Build vs Consumer POM proposal (https://cwiki.apache.org/confluence/display/MAVEN/Build+vs+Consumer+POM). In the past I could have sworn the final pom published was not the same as the pom.xml in the user directory, but that appears to not be the case (at least for an ordinary project). It's possible that some tooling I was using (e.g. my CI tool) was tweaking the pom during publishing, which is where I got the idea that happened by default. *To restate more simply: *The pom.xml in the user's directory is the _same_ as the pom.xml that is bundled into the JAR produced by package. So, _no_ changes can be made to the userland pom.xml without also breaking downstream publishing.* That's a killer for the proposal, at least if/until Build vs Consumer comes along. In the meantime, the only thing I can think of is for Maven core to add a bit more native support for polyglot to make it easier to work with, but that's an entirely different thing. Here is the link to Build/Consumer: https://cwiki.apache.org/confluence/display/MAVEN/Build+vs+Consumer+POM Go ahead and close this issue - if possible go ahead and link it to an issue for Build/Consumer if it exists in JIRA. Thanks! -Will was (Author: wiverson): I just did some more testing, and it appears that the pom.xml in the user's project is the same as the pom that gets published (e.g. included in the jar generated by package), which would absolutely lead to breakage. That level of breakage is contrary to the whole point of this proposal (allow a user local pom.xml to use attributes, but keep the pom.xml published to repositories the same as today with elements). I thought that the published pom.xml included in the release was generated/modified, but that's apparently not true (and clarifies the purpose of the Build vs Consumer POM proposal (https://cwiki.apache.org/confluence/display/MAVEN/Build+vs+Consumer+POM). In the past I could have sworn the final pom published was not the same as the pom.xml in the user directory, but that appears to not be the case (at least for an ordinary project). It's possible that some tooling I was using (e.g. my CI tool) was tweaking the pom during publishing, which is where I got the idea that happened by default. *To restate more simply: The pom.xml in the user's directory is the _same_ as the pom.xml that is bundled into the JAR produced by package. So, _no_ changes can be made to the userland pom.xml without also breaking downstream publishing. * That's a killer for the proposal, at least if/until Build vs Consumer comes along. In the meantime, the only thing I can think of is for Maven core to add a bit more native support for polyglot to make it easier to work with, but that's an entirely different thing. Here is the link to Build/Consumer: https://cwiki.apache.org/confluence/display/MAVEN/Build+vs+Consumer+POM Go ahead and close this issue - if possible go ahead and link it to an issue for Build/Consumer if it exists in JIRA. Thanks! -Will > 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
[jira] [Comment Edited] (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&focusedCommentId=17248450#comment-17248450 ] Will Iverson edited comment on MNG-7044 at 12/12/20, 8:09 PM: -- I just did some more testing, and it appears that the pom.xml in the user's project is the same as the pom that gets published (e.g. included in the jar generated by package), which would absolutely lead to breakage. That level of breakage is contrary to the whole point of this proposal (allow a user local pom.xml to use attributes, but keep the pom.xml published to repositories the same as today with elements). I thought that the published pom.xml included in the release was generated/modified, but that's apparently not true (and clarifies the purpose of the Build vs Consumer POM proposal (https://cwiki.apache.org/confluence/display/MAVEN/Build+vs+Consumer+POM). In the past I could have sworn the final pom published was not the same as the pom.xml in the user directory, but that appears to not be the case (at least for an ordinary project). It's possible that some tooling I was using (e.g. my CI tool) was tweaking the pom during publishing, which is where I got the idea that happened by default. *To restate more simply: The pom.xml in the user's directory is the _same_ as the pom.xml that is bundled into the JAR produced by package. So, _no_ changes can be made to the userland pom.xml without also breaking downstream publishing.* That's a killer for the proposal, at least if/until Build vs Consumer comes along. In the meantime, the only thing I can think of is for Maven core to add a bit more native support for polyglot to make it easier to work with, but that's an entirely different thing. Here is the link to Build/Consumer: https://cwiki.apache.org/confluence/display/MAVEN/Build+vs+Consumer+POM Go ahead and close this issue - if possible go ahead and link it to an issue for Build/Consumer if it exists in JIRA. Thanks! -Will was (Author: wiverson): I just did some more testing, and it appears that the pom.xml in the user's project is the same as the pom that gets published (e.g. included in the jar generated by package), which would absolutely lead to breakage. That level of breakage is contrary to the whole point of this proposal (allow a user local pom.xml to use attributes, but keep the pom.xml published to repositories the same as today with elements). I thought that the published pom.xml included in the release was generated/modified, but that's apparently not true (and clarifies the purpose of the Build vs Consumer POM proposal (https://cwiki.apache.org/confluence/display/MAVEN/Build+vs+Consumer+POM). In the past I could have sworn the final pom published was not the same as the pom.xml in the user directory, but that appears to not be the case (at least for an ordinary project). It's possible that some tooling I was using (e.g. my CI tool) was tweaking the pom during publishing, which is where I got the idea that happened by default. *To restate more simply: *The pom.xml in the user's directory is the _same_ as the pom.xml that is bundled into the JAR produced by package. So, _no_ changes can be made to the userland pom.xml without also breaking downstream publishing.* That's a killer for the proposal, at least if/until Build vs Consumer comes along. In the meantime, the only thing I can think of is for Maven core to add a bit more native support for polyglot to make it easier to work with, but that's an entirely different thing. Here is the link to Build/Consumer: https://cwiki.apache.org/confluence/display/MAVEN/Build+vs+Consumer+POM Go ahead and close this issue - if possible go ahead and link it to an issue for Build/Consumer if it exists in JIRA. Thanks! -Will > 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 woul
[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&focusedCommentId=17248454#comment-17248454 ] Will Iverson commented on MNG-7044: --- One last comment/link - if you want to experiment with different Maven build formats, check out: https://github.com/takari/polyglot-maven/ > 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-ejb-plugin] andreastedile commented on pull request #11: [MEJB-130] Accept ejbVersion 4.x
andreastedile commented on pull request #11: URL: https://github.com/apache/maven-ejb-plugin/pull/11#issuecomment-743847758 I would be interested for EJB version 4 too. 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
