[jira] [Commented] (MDEP-632) cron-utils 7.0.7 doesn't have updated slf4j-api 1.7.25,Latest update has old jar 1.7.12
[ https://issues.apache.org/jira/browse/MDEP-632?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16694345#comment-16694345 ] Karl Heinz Marbaise commented on MDEP-632: -- What do you mean by: 'but its not updated`? Who is not updated ? Where? > cron-utils 7.0.7 doesn't have updated slf4j-api 1.7.25,Latest update has old > jar 1.7.12 > --- > > Key: MDEP-632 > URL: https://issues.apache.org/jira/browse/MDEP-632 > Project: Maven Dependency Plugin > Issue Type: Bug >Reporter: Prakash >Priority: Major > Attachments: image-2018-11-21-13-14-20-805.png > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MDEP-632) cron-utils 7.0.7 doesn't have updated slf4j-api 1.7.25,Latest update has old jar 1.7.12
[ https://issues.apache.org/jira/browse/MDEP-632?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16694341#comment-16694341 ] Prakash commented on MDEP-632: -- !image-2018-11-21-13-14-20-805.png! Portal show cron-utills 7.0.7 has updated sl4j dependency but its not updated > cron-utils 7.0.7 doesn't have updated slf4j-api 1.7.25,Latest update has old > jar 1.7.12 > --- > > Key: MDEP-632 > URL: https://issues.apache.org/jira/browse/MDEP-632 > Project: Maven Dependency Plugin > Issue Type: Bug >Reporter: Prakash >Priority: Major > Attachments: image-2018-11-21-13-14-20-805.png > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (MDEP-632) cron-utils 7.0.7 doesn't have updated slf4j-api 1.7.25,Latest update has old jar 1.7.12
[ https://issues.apache.org/jira/browse/MDEP-632?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Prakash updated MDEP-632: - Attachment: image-2018-11-21-13-14-20-805.png > cron-utils 7.0.7 doesn't have updated slf4j-api 1.7.25,Latest update has old > jar 1.7.12 > --- > > Key: MDEP-632 > URL: https://issues.apache.org/jira/browse/MDEP-632 > Project: Maven Dependency Plugin > Issue Type: Bug >Reporter: Prakash >Priority: Major > Attachments: image-2018-11-21-13-14-20-805.png > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MDEP-632) cron-utils 7.0.7 doesn't have updated slf4j-api 1.7.25,Latest update has old jar 1.7.12
[ https://issues.apache.org/jira/browse/MDEP-632?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16694339#comment-16694339 ] Karl Heinz Marbaise commented on MDEP-632: -- Can you explain what your issue is? Unfortunately I don't understand why you have filed in an issue? > cron-utils 7.0.7 doesn't have updated slf4j-api 1.7.25,Latest update has old > jar 1.7.12 > --- > > Key: MDEP-632 > URL: https://issues.apache.org/jira/browse/MDEP-632 > Project: Maven Dependency Plugin > Issue Type: Bug >Reporter: Prakash >Priority: Major > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (MDEP-632) cron-utils 7.0.7 doesn't have updated slf4j-api 1.7.25,Latest update has old jar 1.7.12
Prakash created MDEP-632: Summary: cron-utils 7.0.7 doesn't have updated slf4j-api 1.7.25,Latest update has old jar 1.7.12 Key: MDEP-632 URL: https://issues.apache.org/jira/browse/MDEP-632 Project: Maven Dependency Plugin Issue Type: Bug Reporter: Prakash -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MRRESOURCES-102) Filtering of non-.vm files
[
https://issues.apache.org/jira/browse/MRRESOURCES-102?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16694268#comment-16694268
]
ASF GitHub Bot commented on MRRESOURCES-102:
judby commented on a change in pull request #2: Implement MRRESOURCES-102
URL:
https://github.com/apache/maven-remote-resources-plugin/pull/2#discussion_r235259046
##
File path:
src/main/java/org/apache/maven/plugin/resources/remote/ProcessRemoteResourcesMojo.java
##
@@ -1336,6 +1341,41 @@ else if ( appendedVmResourceFile.exists() )
}
}
+private void copyBundleResource( ClassLoader classLoader, String
bundleResource, File to )
+throws IOException
+{
+URL resUrl = classLoader.getResource( bundleResource );
+if ( resUrl != null )
+{
+FileUtils.copyURLToFile( resUrl, to );
+}
+}
+
+private void filterBundleResource( ClassLoader classLoader, String
bundleResource, File to )
+throws IOException, MojoExecutionException
+{
+File tmpFile = null;
+try
+{
+tmpFile = File.createTempFile( "maven-remote-resources-plugin",
null );
+tmpFile.deleteOnExit();
Review comment:
Consider moving `deleteOnExit()` to the finally, where the file will either
be deleted at once, or a warning will be written.
`deleteOnExit()` adds the `Path` to a list of files to delete on exit and
does not scale well if there are many files.
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> Filtering of non-.vm files
> --
>
> Key: MRRESOURCES-102
> URL: https://issues.apache.org/jira/browse/MRRESOURCES-102
> Project: Maven Remote Resources Plugin
> Issue Type: New Feature
>Affects Versions: 1.5
>Reporter: Falko Modler
>Priority: Major
>
> It would be a very welcomed addition if the plugin would also filter
> non-verlocity (.vm) files.
> See also: MRRESOURCES-83
> Renaming the files in question to *.vm is not an option for me because:
> - MRRESOURCES-94
> - the module _providing_ the file(s) also needs them _without_ .vm suffix
> (fixing this would require some other plugin)
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MRRESOURCES-102) Filtering of non-.vm files
[
https://issues.apache.org/jira/browse/MRRESOURCES-102?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16694269#comment-16694269
]
ASF GitHub Bot commented on MRRESOURCES-102:
judby commented on a change in pull request #2: Implement MRRESOURCES-102
URL:
https://github.com/apache/maven-remote-resources-plugin/pull/2#discussion_r235259046
##
File path:
src/main/java/org/apache/maven/plugin/resources/remote/ProcessRemoteResourcesMojo.java
##
@@ -1336,6 +1341,41 @@ else if ( appendedVmResourceFile.exists() )
}
}
+private void copyBundleResource( ClassLoader classLoader, String
bundleResource, File to )
+throws IOException
+{
+URL resUrl = classLoader.getResource( bundleResource );
+if ( resUrl != null )
+{
+FileUtils.copyURLToFile( resUrl, to );
+}
+}
+
+private void filterBundleResource( ClassLoader classLoader, String
bundleResource, File to )
+throws IOException, MojoExecutionException
+{
+File tmpFile = null;
+try
+{
+tmpFile = File.createTempFile( "maven-remote-resources-plugin",
null );
+tmpFile.deleteOnExit();
Review comment:
Consider moving `deleteOnExit()` to the finally block, where the file will
either be deleted at once, or a warning will be written.
`deleteOnExit()` adds the `Path` to a list of files to delete on exit and
does not scale well if there are many files.
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> Filtering of non-.vm files
> --
>
> Key: MRRESOURCES-102
> URL: https://issues.apache.org/jira/browse/MRRESOURCES-102
> Project: Maven Remote Resources Plugin
> Issue Type: New Feature
>Affects Versions: 1.5
>Reporter: Falko Modler
>Priority: Major
>
> It would be a very welcomed addition if the plugin would also filter
> non-verlocity (.vm) files.
> See also: MRRESOURCES-83
> Renaming the files in question to *.vm is not an option for me because:
> - MRRESOURCES-94
> - the module _providing_ the file(s) also needs them _without_ .vm suffix
> (fixing this would require some other plugin)
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] judby commented on a change in pull request #2: Implement MRRESOURCES-102
judby commented on a change in pull request #2: Implement MRRESOURCES-102
URL:
https://github.com/apache/maven-remote-resources-plugin/pull/2#discussion_r235259046
##
File path:
src/main/java/org/apache/maven/plugin/resources/remote/ProcessRemoteResourcesMojo.java
##
@@ -1336,6 +1341,41 @@ else if ( appendedVmResourceFile.exists() )
}
}
+private void copyBundleResource( ClassLoader classLoader, String
bundleResource, File to )
+throws IOException
+{
+URL resUrl = classLoader.getResource( bundleResource );
+if ( resUrl != null )
+{
+FileUtils.copyURLToFile( resUrl, to );
+}
+}
+
+private void filterBundleResource( ClassLoader classLoader, String
bundleResource, File to )
+throws IOException, MojoExecutionException
+{
+File tmpFile = null;
+try
+{
+tmpFile = File.createTempFile( "maven-remote-resources-plugin",
null );
+tmpFile.deleteOnExit();
Review comment:
Consider moving `deleteOnExit()` to the finally block, where the file will
either be deleted at once, or a warning will be written.
`deleteOnExit()` adds the `Path` to a list of files to delete on exit and
does not scale well if there are many files.
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
With regards,
Apache Git Services
[GitHub] judby commented on a change in pull request #2: Implement MRRESOURCES-102
judby commented on a change in pull request #2: Implement MRRESOURCES-102
URL:
https://github.com/apache/maven-remote-resources-plugin/pull/2#discussion_r235259046
##
File path:
src/main/java/org/apache/maven/plugin/resources/remote/ProcessRemoteResourcesMojo.java
##
@@ -1336,6 +1341,41 @@ else if ( appendedVmResourceFile.exists() )
}
}
+private void copyBundleResource( ClassLoader classLoader, String
bundleResource, File to )
+throws IOException
+{
+URL resUrl = classLoader.getResource( bundleResource );
+if ( resUrl != null )
+{
+FileUtils.copyURLToFile( resUrl, to );
+}
+}
+
+private void filterBundleResource( ClassLoader classLoader, String
bundleResource, File to )
+throws IOException, MojoExecutionException
+{
+File tmpFile = null;
+try
+{
+tmpFile = File.createTempFile( "maven-remote-resources-plugin",
null );
+tmpFile.deleteOnExit();
Review comment:
Consider moving `deleteOnExit()` to the finally, where the file will either
be deleted at once, or a warning will be written.
`deleteOnExit()` adds the `Path` to a list of files to delete on exit and
does not scale well if there are many files.
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
With regards,
Apache Git Services
[jira] [Commented] (MNG-6261) Relative parent POM resolution failing in 3.5.0 with complex multimodule builds
[
https://issues.apache.org/jira/browse/MNG-6261?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16694258#comment-16694258
]
ASF GitHub Bot commented on MNG-6261:
-
judby commented on a change in pull request #192: [MNG-6261] - using java File
api to compare
URL: https://github.com/apache/maven/pull/192#discussion_r235257910
##
File path:
maven-model-builder/src/main/java/org/apache/maven/model/building/FileModelSource.java
##
@@ -80,4 +80,27 @@ public URI getLocationURI()
{
return getFile().toURI();
}
+
+@Override
+public boolean equals( Object obj )
+{
+if ( this == obj )
+{
+return true;
+}
+
+if ( ( obj == null ) || !( obj instanceof FileModelSource ) )
Review comment:
Compare with null not necessary since `null instanceof FileModelSource` is
`false`
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> Relative parent POM resolution failing in 3.5.0 with complex multimodule
> builds
> ---
>
> Key: MNG-6261
> URL: https://issues.apache.org/jira/browse/MNG-6261
> Project: Maven
> Issue Type: Bug
>Affects Versions: 3.5.0
>Reporter: Dawid Weiss
>Priority: Minor
> Labels: up-for-grabs
> Fix For: 3.6.x-candidate
>
> Attachments: capture-6.png, repro.zip
>
>
> In my effort to upgrade an existing (fairly complex) Maven build to Java
> 1.9.0 I updated Maven to 3.5.0 (from 3.3.9). Unfortunately I get errors when
> the project's modules are resolved:
> {noformat}
> > mvn validate
> [FATAL] Non-resolvable parent POM for
> com.carrotsearch.lingo4g:lingo4g-public-bom:[unknown-version]: Could not find
> artifact com.carrotsearch.lingo4g:lingo4g-public:pom:1.6.0-SNAPSHOT and
> 'parent.relativePath' points at wrong local POM @ line 5, column 11
> ...
> (and many follow).
> {noformat}
> This build has a correct pom parent-structure (a tree), but is fairly complex
> -- the submodule hierarchy is not aligned with parent-child pom hierarchy
> (it's best to look at the repro code to understand how it's structured).
> However, it's been working correctly with all prior Maven versions and I
> wonder if it's a regression bug or maybe underspecified Maven requirement
> (that should be enforced with a warning and not lead to this odd runtime
> message).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MRRESOURCES-102) Filtering of non-.vm files
[
https://issues.apache.org/jira/browse/MRRESOURCES-102?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16694261#comment-16694261
]
ASF GitHub Bot commented on MRRESOURCES-102:
judby commented on a change in pull request #2: Implement MRRESOURCES-102
URL:
https://github.com/apache/maven-remote-resources-plugin/pull/2#discussion_r235258316
##
File path:
src/main/java/org/apache/maven/plugin/resources/remote/ProcessRemoteResourcesMojo.java
##
@@ -847,8 +853,7 @@ protected boolean copyResourceIfExists( File file, String
relFileName, VelocityC
}
else if ( resource.isFiltering() )
{
-
-MavenFileFilterRequest req = setupRequest( resource,
source, file );
+MavenFileFilterRequest req = setupRequest( source, file,
resource.isFiltering() );
Review comment:
`req = setupRequest( source, file, true );`
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> Filtering of non-.vm files
> --
>
> Key: MRRESOURCES-102
> URL: https://issues.apache.org/jira/browse/MRRESOURCES-102
> Project: Maven Remote Resources Plugin
> Issue Type: New Feature
>Affects Versions: 1.5
>Reporter: Falko Modler
>Priority: Major
>
> It would be a very welcomed addition if the plugin would also filter
> non-verlocity (.vm) files.
> See also: MRRESOURCES-83
> Renaming the files in question to *.vm is not an option for me because:
> - MRRESOURCES-94
> - the module _providing_ the file(s) also needs them _without_ .vm suffix
> (fixing this would require some other plugin)
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] judby commented on a change in pull request #2: Implement MRRESOURCES-102
judby commented on a change in pull request #2: Implement MRRESOURCES-102
URL:
https://github.com/apache/maven-remote-resources-plugin/pull/2#discussion_r235258316
##
File path:
src/main/java/org/apache/maven/plugin/resources/remote/ProcessRemoteResourcesMojo.java
##
@@ -847,8 +853,7 @@ protected boolean copyResourceIfExists( File file, String
relFileName, VelocityC
}
else if ( resource.isFiltering() )
{
-
-MavenFileFilterRequest req = setupRequest( resource,
source, file );
+MavenFileFilterRequest req = setupRequest( source, file,
resource.isFiltering() );
Review comment:
`req = setupRequest( source, file, true );`
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
With regards,
Apache Git Services
[GitHub] judby commented on a change in pull request #192: [MNG-6261] - using java File api to compare
judby commented on a change in pull request #192: [MNG-6261] - using java File
api to compare
URL: https://github.com/apache/maven/pull/192#discussion_r235257910
##
File path:
maven-model-builder/src/main/java/org/apache/maven/model/building/FileModelSource.java
##
@@ -80,4 +80,27 @@ public URI getLocationURI()
{
return getFile().toURI();
}
+
+@Override
+public boolean equals( Object obj )
+{
+if ( this == obj )
+{
+return true;
+}
+
+if ( ( obj == null ) || !( obj instanceof FileModelSource ) )
Review comment:
Compare with null not necessary since `null instanceof FileModelSource` is
`false`
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
With regards,
Apache Git Services
[jira] [Comment Edited] (MNG-6523) System Dependencies Deprication
[
https://issues.apache.org/jira/browse/MNG-6523?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16694221#comment-16694221
]
Alireza Fattahi edited comment on MNG-6523 at 11/21/18 4:53 AM:
Well here is my usecase
My usecase has a +long story+ behind it but I try to make it short :):
Our security department develops and update some security related stuff and
bundles them as a jar file. They do not want to upload it to any repository (
even the internal repository). Instead they copy this file on an remote secured
server and we are not allowed to move it or copy and re-read this from any
repository. We use `{{systemPath}}` to link it to our project during build
time. ( Why they did not want to use repository and this seems to be strange?
Well as I said +very+ long story but you can not always convince the security
guys and it is not easy to change their beliefs also you can not easily change
big software company deployment rules :) . "It has been there for a long time
and it is working quite well so no reason to change it!!" as they always say)
On the other hand, I believe other developers may had other use cases too. For
example some one mentioned this: There happens when you want to quickly test
some ( may be old ) jar files, This is a quick way to do it without the need to
upload it to any repository ( and also remember to remove it from there)
Thanks [~michael-o] for reading it
was (Author: afattahi):
Well here is my usecase
My usecase has a long story behind it but to make I try to make it short :):
Our security department develops and update some security related stuff and
bundles them as a jar file. They do not want to upload it to any repository (
even the internal repository). Instead they copy this file on an remote secured
server and we are not allowed to move it or copy and re-read this from any
repository. We use `{{systemPath}}` to link it to our project during build
time. ( Why they did not want to use repository and this seems to be strange?
Well as I said +very+ long story but you can not always convince the security
guys and it is not easy to change their beliefs also you can not easily change
big software company deployment rules :) . "It has been there for a long time
and it is working quite well so no reason to change it!!" as they always say)
On the other hand, I believe other developers may had other use cases too. For
example some one mentioned this: There happens when you want to quickly test
some ( may be old ) jar files, This is a quick way to do it without the need to
upload it to any repository ( and also remember to remove it from there)
Thanks [~michael-o] for reading it
> System Dependencies Deprication
> ---
>
> Key: MNG-6523
> URL: https://issues.apache.org/jira/browse/MNG-6523
> Project: Maven
> Issue Type: Wish
>Reporter: Alireza Fattahi
>Priority: Major
> Fix For: wontfix-candidate
>
>
> Please let me know if this is wrong place for discussions about this.
>
> As mentioned in
> [https://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#System_Dependencies]
> the System Dependencies will be depreciated and should not be used.
> Well this feature seems very useful in some cases and must developers find it
> easy to use:
> [https://stackoverflow.com/a/4491469/2648077]
> [https://stackoverflow.com/a/22300875/2648077]
>
> Well I wish it wouldn't be deprecated at all :)
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MNG-6523) System Dependencies Deprication
[
https://issues.apache.org/jira/browse/MNG-6523?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16694221#comment-16694221
]
Alireza Fattahi commented on MNG-6523:
--
Well here is my usecase
My usecase has a long story behind it but to make I try to make it short :):
Our security department develops and update some security related stuff and
bundles them as a jar file. They do not want to upload it to any repository (
even the internal repository). Instead they copy this file on an remote secured
server and we are not allowed to move it or copy and re-read this from any
repository. We use `{{systemPath}}` to link it to our project during build
time. ( Why they did not want to use repository and this seems to be strange?
Well as I said +very+ long story but you can not always convince the security
guys and it is not easy to change their beliefs also you can not easily change
big software company deployment rules :) . "It has been there for a long time
and it is working quite well so no reason to change it!!" as they always say)
On the other hand, I believe other developers may had other use cases too. For
example some one mentioned this: There happens when you want to quickly test
some ( may be old ) jar files, This is a quick way to do it without the need to
upload it to any repository ( and also remember to remove it from there)
Thanks [~michael-o] for reading it
> System Dependencies Deprication
> ---
>
> Key: MNG-6523
> URL: https://issues.apache.org/jira/browse/MNG-6523
> Project: Maven
> Issue Type: Wish
>Reporter: Alireza Fattahi
>Priority: Major
> Fix For: wontfix-candidate
>
>
> Please let me know if this is wrong place for discussions about this.
>
> As mentioned in
> [https://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#System_Dependencies]
> the System Dependencies will be depreciated and should not be used.
> Well this feature seems very useful in some cases and must developers find it
> easy to use:
> [https://stackoverflow.com/a/4491469/2648077]
> [https://stackoverflow.com/a/22300875/2648077]
>
> Well I wish it wouldn't be deprecated at all :)
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] olamy closed pull request #2: update dev list link in readme
olamy closed pull request #2: update dev list link in readme URL: https://github.com/apache/maven-help-plugin/pull/2 This is a PR merged from a forked repository. As GitHub hides the original diff on merge, it is displayed below for the sake of provenance: As this is a foreign pull request (from a fork), the diff is supplied below (as it won't show otherwise due to GitHub magic): diff --git a/README.md b/README.md index 2d2d826..cc627a5 100644 --- a/README.md +++ b/README.md @@ -35,7 +35,7 @@ Getting Started + Make sure you have a [JIRA account](https://issues.apache.org/jira/). + Make sure you have a [GitHub account](https://github.com/signup/free). + If you're planning to implement a new feature, it makes sense to discuss your changes - on the [dev list](https://maven.apache.org/mail-lists.html) first. + on the [dev list](https://maven.apache.org/mailing-lists.html) first. This way you can make sure you're not wasting your time on something that isn't considered to be in Apache Maven's scope. + Submit a ticket for your issue, assuming one does not already exist. This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] rremer opened a new pull request #2: update dev list link in readme
rremer opened a new pull request #2: update dev list link in readme URL: https://github.com/apache/maven-help-plugin/pull/2 Dumb link update. This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Commented] (MNG-6261) Relative parent POM resolution failing in 3.5.0 with complex multimodule builds
[
https://issues.apache.org/jira/browse/MNG-6261?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16693969#comment-16693969
]
ASF GitHub Bot commented on MNG-6261:
-
eolivelli commented on a change in pull request #192: [MNG-6261] - using java
File api to compare
URL: https://github.com/apache/maven/pull/192#discussion_r235222701
##
File path:
maven-model-builder/src/test/java/org/apache/maven/model/building/FileModelSourceTest.java
##
@@ -0,0 +1,74 @@
+package org.apache.maven.model.building;
+
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied. See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ */
+import java.io.File;
+import junit.framework.TestCase;
+import static junit.framework.TestCase.assertFalse;
+import static junit.framework.TestCase.assertTrue;
+import org.apache.commons.lang3.SystemUtils;
+import static org.junit.Assume.assumeTrue;
+import org.junit.Rule;
+import org.junit.Test;
+import org.junit.rules.TemporaryFolder;
+
+/**
+ *
+ * @author fabiano
Review comment:
I think this comment should be fixed, removing the author and adding a
minimal description
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> Relative parent POM resolution failing in 3.5.0 with complex multimodule
> builds
> ---
>
> Key: MNG-6261
> URL: https://issues.apache.org/jira/browse/MNG-6261
> Project: Maven
> Issue Type: Bug
>Affects Versions: 3.5.0
>Reporter: Dawid Weiss
>Priority: Minor
> Labels: up-for-grabs
> Fix For: 3.6.x-candidate
>
> Attachments: capture-6.png, repro.zip
>
>
> In my effort to upgrade an existing (fairly complex) Maven build to Java
> 1.9.0 I updated Maven to 3.5.0 (from 3.3.9). Unfortunately I get errors when
> the project's modules are resolved:
> {noformat}
> > mvn validate
> [FATAL] Non-resolvable parent POM for
> com.carrotsearch.lingo4g:lingo4g-public-bom:[unknown-version]: Could not find
> artifact com.carrotsearch.lingo4g:lingo4g-public:pom:1.6.0-SNAPSHOT and
> 'parent.relativePath' points at wrong local POM @ line 5, column 11
> ...
> (and many follow).
> {noformat}
> This build has a correct pom parent-structure (a tree), but is fairly complex
> -- the submodule hierarchy is not aligned with parent-child pom hierarchy
> (it's best to look at the repro code to understand how it's structured).
> However, it's been working correctly with all prior Maven versions and I
> wonder if it's a regression bug or maybe underspecified Maven requirement
> (that should be enforced with a warning and not lead to this odd runtime
> message).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MNG-6261) Relative parent POM resolution failing in 3.5.0 with complex multimodule builds
[
https://issues.apache.org/jira/browse/MNG-6261?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16693970#comment-16693970
]
ASF GitHub Bot commented on MNG-6261:
-
eolivelli commented on a change in pull request #192: [MNG-6261] - using java
File api to compare
URL: https://github.com/apache/maven/pull/192#discussion_r235223001
##
File path:
maven-model-builder/src/test/java/org/apache/maven/model/building/FileModelSourceTest.java
##
@@ -0,0 +1,74 @@
+package org.apache.maven.model.building;
+
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied. See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ */
+import java.io.File;
+import junit.framework.TestCase;
+import static junit.framework.TestCase.assertFalse;
+import static junit.framework.TestCase.assertTrue;
+import org.apache.commons.lang3.SystemUtils;
+import static org.junit.Assume.assumeTrue;
+import org.junit.Rule;
+import org.junit.Test;
+import org.junit.rules.TemporaryFolder;
+
+/**
+ *
+ * @author fabiano
+ */
+public class FileModelSourceTest
+{
+
+@Rule
+public TemporaryFolder folder = new TemporaryFolder();
+
+/**
+ * Test of equals method, of class FileModelSource.
+ */
+@Test
+public void testEquals()
+throws Exception
+{
+File tempFile = File.createTempFile( "pomTest-", ".xml" );
Review comment:
If you are using TemporaryFolder why are you using also File.createTempFile?
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> Relative parent POM resolution failing in 3.5.0 with complex multimodule
> builds
> ---
>
> Key: MNG-6261
> URL: https://issues.apache.org/jira/browse/MNG-6261
> Project: Maven
> Issue Type: Bug
>Affects Versions: 3.5.0
>Reporter: Dawid Weiss
>Priority: Minor
> Labels: up-for-grabs
> Fix For: 3.6.x-candidate
>
> Attachments: capture-6.png, repro.zip
>
>
> In my effort to upgrade an existing (fairly complex) Maven build to Java
> 1.9.0 I updated Maven to 3.5.0 (from 3.3.9). Unfortunately I get errors when
> the project's modules are resolved:
> {noformat}
> > mvn validate
> [FATAL] Non-resolvable parent POM for
> com.carrotsearch.lingo4g:lingo4g-public-bom:[unknown-version]: Could not find
> artifact com.carrotsearch.lingo4g:lingo4g-public:pom:1.6.0-SNAPSHOT and
> 'parent.relativePath' points at wrong local POM @ line 5, column 11
> ...
> (and many follow).
> {noformat}
> This build has a correct pom parent-structure (a tree), but is fairly complex
> -- the submodule hierarchy is not aligned with parent-child pom hierarchy
> (it's best to look at the repro code to understand how it's structured).
> However, it's been working correctly with all prior Maven versions and I
> wonder if it's a regression bug or maybe underspecified Maven requirement
> (that should be enforced with a warning and not lead to this odd runtime
> message).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] eolivelli commented on a change in pull request #192: [MNG-6261] - using java File api to compare
eolivelli commented on a change in pull request #192: [MNG-6261] - using java
File api to compare
URL: https://github.com/apache/maven/pull/192#discussion_r235223001
##
File path:
maven-model-builder/src/test/java/org/apache/maven/model/building/FileModelSourceTest.java
##
@@ -0,0 +1,74 @@
+package org.apache.maven.model.building;
+
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied. See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ */
+import java.io.File;
+import junit.framework.TestCase;
+import static junit.framework.TestCase.assertFalse;
+import static junit.framework.TestCase.assertTrue;
+import org.apache.commons.lang3.SystemUtils;
+import static org.junit.Assume.assumeTrue;
+import org.junit.Rule;
+import org.junit.Test;
+import org.junit.rules.TemporaryFolder;
+
+/**
+ *
+ * @author fabiano
+ */
+public class FileModelSourceTest
+{
+
+@Rule
+public TemporaryFolder folder = new TemporaryFolder();
+
+/**
+ * Test of equals method, of class FileModelSource.
+ */
+@Test
+public void testEquals()
+throws Exception
+{
+File tempFile = File.createTempFile( "pomTest-", ".xml" );
Review comment:
If you are using TemporaryFolder why are you using also File.createTempFile?
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
With regards,
Apache Git Services
[GitHub] eolivelli commented on a change in pull request #192: [MNG-6261] - using java File api to compare
eolivelli commented on a change in pull request #192: [MNG-6261] - using java File api to compare URL: https://github.com/apache/maven/pull/192#discussion_r235222701 ## File path: maven-model-builder/src/test/java/org/apache/maven/model/building/FileModelSourceTest.java ## @@ -0,0 +1,74 @@ +package org.apache.maven.model.building; + +/* + * Licensed to the Apache Software Foundation (ASF) under one + * or more contributor license agreements. See the NOTICE file + * distributed with this work for additional information + * regarding copyright ownership. The ASF licenses this file + * to you under the Apache License, Version 2.0 (the + * "License"); you may not use this file except in compliance + * with the License. You may obtain a copy of the License at + * + * http://www.apache.org/licenses/LICENSE-2.0 + * + * Unless required by applicable law or agreed to in writing, + * software distributed under the License is distributed on an + * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY + * KIND, either express or implied. See the License for the + * specific language governing permissions and limitations + * under the License. + */ +import java.io.File; +import junit.framework.TestCase; +import static junit.framework.TestCase.assertFalse; +import static junit.framework.TestCase.assertTrue; +import org.apache.commons.lang3.SystemUtils; +import static org.junit.Assume.assumeTrue; +import org.junit.Rule; +import org.junit.Test; +import org.junit.rules.TemporaryFolder; + +/** + * + * @author fabiano Review comment: I think this comment should be fixed, removing the author and adding a minimal description This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Updated] (MJAR-198) jar:jar without classifier replaces default jar
[ https://issues.apache.org/jira/browse/MJAR-198?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hervé Boutemy updated MJAR-198: --- Description: If I add an execution of jar:jar in a project of packaging jar and do not configure a classifier for the additional jar, the additional jar will be installed instead of the default jar. Omitting a classifier in the configuration for the goal jar:jar is [documented to have the effect that the jar will not be attached|https://maven.apache.org/plugins/maven-jar-plugin/jar-mojo.html#classifier] and this is the behavior that I want. Instead, the jar is attached and replaces the default jar. AbstractJarMojo.java:254 checks nullness of classifier to decide whether to attach or not. JarMojo.java:51 declares a default value the empty string for classifier. Maybe the combination of these lines cause the bug. [http://svn.apache.org/viewvc/maven/plugins/tags/maven-jar-plugin-2.6/src/main/java/org/apache/maven/plugin/jar/AbstractJarMojo.java?revision=1664111=markup] [http://svn.apache.org/viewvc/maven/plugins/tags/maven-jar-plugin-2.6/src/main/java/org/apache/maven/plugin/jar/JarMojo.java?revision=1664111=markup] was: If I add an execution of jar:jar in a project of packaging jar and do not configure a classifier for the additional jar, the additional jar will be installed instead of the default jar. Omitting a classifier in the configuration for the goal jar:jar is documented to have the effect that the jar will not be attached and this is the behavior that I want. Instead, the jar is attached and replaces the default jar. AbstractJarMojo.java:254 checks nullness of classifier to decide whether to attach or not. JarMojo.java:51 declares a default value the empty string for classifier. Maybe the combination of these lines cause the bug. http://svn.apache.org/viewvc/maven/plugins/tags/maven-jar-plugin-2.6/src/main/java/org/apache/maven/plugin/jar/AbstractJarMojo.java?revision=1664111=markup http://svn.apache.org/viewvc/maven/plugins/tags/maven-jar-plugin-2.6/src/main/java/org/apache/maven/plugin/jar/JarMojo.java?revision=1664111=markup > jar:jar without classifier replaces default jar > --- > > Key: MJAR-198 > URL: https://issues.apache.org/jira/browse/MJAR-198 > Project: Maven JAR Plugin > Issue Type: Bug >Affects Versions: 2.3.1, 2.3.2, 2.4, 2.5, 2.6 > Environment: Windows 8.1 Pro > JDK 1.8 45 > Maven 3.2.5 >Reporter: Elias Elmqvist Wulcan >Assignee: Karl Heinz Marbaise >Priority: Minor > Labels: newbie > Fix For: 3.0.0 > > Attachments: 0.tar, mvn.install.debug.txt > > > If I add an execution of jar:jar in a project of packaging jar and do not > configure a classifier for the additional jar, the additional jar will be > installed instead of the default jar. > Omitting a classifier in the configuration for the goal jar:jar is > [documented to have the effect that the jar will not be > attached|https://maven.apache.org/plugins/maven-jar-plugin/jar-mojo.html#classifier] > and this is the behavior that I want. Instead, the jar is attached and > replaces the default jar. > AbstractJarMojo.java:254 checks nullness of classifier to decide whether to > attach or not. JarMojo.java:51 declares a default value the empty string for > classifier. Maybe the combination of these lines cause the bug. > > [http://svn.apache.org/viewvc/maven/plugins/tags/maven-jar-plugin-2.6/src/main/java/org/apache/maven/plugin/jar/AbstractJarMojo.java?revision=1664111=markup] > > [http://svn.apache.org/viewvc/maven/plugins/tags/maven-jar-plugin-2.6/src/main/java/org/apache/maven/plugin/jar/JarMojo.java?revision=1664111=markup] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (MNGSITE-292) Update the mini guide to creating archectypes to Archetype 2.x
[
https://issues.apache.org/jira/browse/MNGSITE-292?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hervé Boutemy updated MNGSITE-292:
--
Description:
as noticed by a user recently, the [mini-guide "Guide to Creating
Archetypes"|https://maven.apache.org/guides/mini/guide-creating-archetypes.html]
explains about Archetype 1.x which is deprecated in favor of Archetype 2.x:
* Archetype 1.x used {{archetype.xml}} descriptor:
[https://maven.apache.org/archetype/archetype-common/archetype.html]
* Archetype 2.x uses a different descriptor {{archetype-metadata.xml}} with a
different schema :
[https://maven.apache.org/archetype/archetype-models/archetype-descriptor/archetype-descriptor.html]
there may be other differences when upgrading from Archetype 1 to Archetype 2,
I did not investigate in details
was:
as noticed by a user recently, the
[mini-guide|https://maven.apache.org/guides/mini/guide-creating-archetypes.html]
explains about Archetype 1.x which is deprecated in favor of Archetype 2.x
Archetype 1.x used archetype.xml descriptor:
[https://maven.apache.org/archetype/archetype-common/archetype.html]
Archetype 2.x uses a different descriptor archetype-metadata.xml with a
different schema :
[https://maven.apache.org/archetype/archetype-models/archetype-descriptor/archetype-descriptor.html]
there may be other differences when upgrading from Archetype 1 to Archetype 2,
I did not investigate in details
> Update the mini guide to creating archectypes to Archetype 2.x
> --
>
> Key: MNGSITE-292
> URL: https://issues.apache.org/jira/browse/MNGSITE-292
> Project: Maven Project Web Site
> Issue Type: Improvement
>Reporter: Hervé Boutemy
>Priority: Major
> Labels: up-for-grabs
>
> as noticed by a user recently, the [mini-guide "Guide to Creating
> Archetypes"|https://maven.apache.org/guides/mini/guide-creating-archetypes.html]
> explains about Archetype 1.x which is deprecated in favor of Archetype 2.x:
> * Archetype 1.x used {{archetype.xml}} descriptor:
> [https://maven.apache.org/archetype/archetype-common/archetype.html]
> * Archetype 2.x uses a different descriptor {{archetype-metadata.xml}} with
> a different schema :
> [https://maven.apache.org/archetype/archetype-models/archetype-descriptor/archetype-descriptor.html]
> there may be other differences when upgrading from Archetype 1 to Archetype
> 2, I did not investigate in details
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MSHADE-291) shadedPattern applied multiples times when relocating the contents of META-INF/services files
[
https://issues.apache.org/jira/browse/MSHADE-291?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16693781#comment-16693781
]
Jan Luehe commented on MSHADE-291:
--
Got it! Thank you for the explanation, [~rfscholte]
> shadedPattern applied multiples times when relocating the contents of
> META-INF/services files
> -
>
> Key: MSHADE-291
> URL: https://issues.apache.org/jira/browse/MSHADE-291
> Project: Maven Shade Plugin
> Issue Type: Bug
>Affects Versions: 3.1.1, 3.2.0, 3.2.1
>Reporter: Jan Luehe
>Assignee: Robert Scholte
>Priority: Major
> Labels: up-for-grabs
> Fix For: 3.2.2
>
>
> Steps to reproduce:
> 1. Modified the test case for
> https://issues.apache.org/jira/browse/MSHADE-190, as follows:
> {code:java}
> diff --git a/pom.xml b/pom.xml
> index 746b700..aea9abb 100644
> --- a/pom.xml
> +++ b/pom.xml
> @@ -68,12 +68,12 @@
>
> org.apache.maven.plugins
> maven-shade-plugin
> -2.4
> +3.1.1
>
>
>
> -org.eclipse.*
> -borg.eclipse.*
> +org.eclipse
> +org.eclipse1234
>
>
>
> {code}
> 2. mvn package
> 3. jar -xvf target/shade-meta-tc-1.0-SNAPSHOT.jar META-INF/services
> 4. cat META-INF/services/org.osgi.framework.launch.FrameworkFactory
> The shaded service implementation class looks as follows:
> {code:java}
> org.eclipse12341234.osgi.launch.EquinoxFactory
> {code}
> It appears that shadedPattern was applied twice.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (MNGSITE-292) Update the mini guide to creating archectypes to Archetype 2.x
[ https://issues.apache.org/jira/browse/MNGSITE-292?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hervé Boutemy updated MNGSITE-292: -- Description: as noticed by a user recently, the [mini-guide|https://maven.apache.org/guides/mini/guide-creating-archetypes.html] explains about Archetype 1.x which is deprecated in favor of Archetype 2.x Archetype 1.x used archetype.xml descriptor: [https://maven.apache.org/archetype/archetype-common/archetype.html] Archetype 2.x uses a different descriptor archetype-metadata.xml with a different schema : [https://maven.apache.org/archetype/archetype-models/archetype-descriptor/archetype-descriptor.html] there may be other differences when upgrading from Archetype 1 to Archetype 2, I did not investigate in details was: as noticed by a user recently, the [mini-guide|https://maven.apache.org/guides/mini/guide-creating-archetypes.html] explains about Archetype 1.x which is deprecated in favor of Archetype 2.x Archetype 1.x used generate goal and archetype.xml descriptor: [https://maven.apache.org/archetype/archetype-common/archetype.html] Archetype 2.x uses a different descriptor archetype-metadata.xml with a different schema : [https://maven.apache.org/archetype/archetype-models/archetype-descriptor/archetype-descriptor.html] there may be other differences when upgrading from Archetype 1 to Archetype 2, I did not investigate in details > Update the mini guide to creating archectypes to Archetype 2.x > -- > > Key: MNGSITE-292 > URL: https://issues.apache.org/jira/browse/MNGSITE-292 > Project: Maven Project Web Site > Issue Type: Improvement >Reporter: Hervé Boutemy >Priority: Major > Labels: up-for-grabs > > as noticed by a user recently, the > [mini-guide|https://maven.apache.org/guides/mini/guide-creating-archetypes.html] > explains about Archetype 1.x which is deprecated in favor of Archetype 2.x > Archetype 1.x used archetype.xml descriptor: > [https://maven.apache.org/archetype/archetype-common/archetype.html] > Archetype 2.x uses a different descriptor archetype-metadata.xml with a > different schema : > [https://maven.apache.org/archetype/archetype-models/archetype-descriptor/archetype-descriptor.html] > there may be other differences when upgrading from Archetype 1 to Archetype > 2, I did not investigate in details -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (MNGSITE-292) Update the mini guide to creating archectypes to Archetype 2.x
[ https://issues.apache.org/jira/browse/MNGSITE-292?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hervé Boutemy updated MNGSITE-292: -- Description: as noticed by a user recently, the [mini-guide|https://maven.apache.org/guides/mini/guide-creating-archetypes.html] explains about Archetype 1.x which is deprecated in favor of Archetype 2.x Archetype 1.x used generate goal and archetype.xml descriptor: [https://maven.apache.org/archetype/archetype-common/archetype.html] Archetype 2.x uses a different descriptor archetype-metadata.xml with a different schema : [https://maven.apache.org/archetype/archetype-models/archetype-descriptor/archetype-descriptor.html] there may be other differences when upgrading from Archetype 1 to Archetype 2, I did not investigate in details was: as noticed by a user recently, the [mini-guide|https://maven.apache.org/guides/mini/guide-creating-archetypes.html] explains about Archetype 1.x which is deprecated in favor of Archetype 2.x Archetype 1.x used archetype.xml descriptor: [https://maven.apache.org/archetype/archetype-common/archetype.html] Archetype 2.x uses a different descriptor archetype-metadata.xml with a different schema : [https://maven.apache.org/archetype/archetype-models/archetype-descriptor/archetype-descriptor.html] there may be other differences when upgrading from Archetype 1 to Archetype 2, I did not investigate in details > Update the mini guide to creating archectypes to Archetype 2.x > -- > > Key: MNGSITE-292 > URL: https://issues.apache.org/jira/browse/MNGSITE-292 > Project: Maven Project Web Site > Issue Type: Improvement >Reporter: Hervé Boutemy >Priority: Major > Labels: up-for-grabs > > as noticed by a user recently, the > [mini-guide|https://maven.apache.org/guides/mini/guide-creating-archetypes.html] > explains about Archetype 1.x which is deprecated in favor of Archetype 2.x > Archetype 1.x used generate goal and archetype.xml descriptor: > [https://maven.apache.org/archetype/archetype-common/archetype.html] > Archetype 2.x uses a different descriptor archetype-metadata.xml with a > different schema : > [https://maven.apache.org/archetype/archetype-models/archetype-descriptor/archetype-descriptor.html] > there may be other differences when upgrading from Archetype 1 to Archetype > 2, I did not investigate in details -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MPIR-373) Upgrade from 2.9 to 3.0.0 introduces additional warning
[
https://issues.apache.org/jira/browse/MPIR-373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16693705#comment-16693705
]
Robert Scholte commented on MPIR-373:
-
I haven't looked at this for quite some time, sorry.
> Upgrade from 2.9 to 3.0.0 introduces additional warning
> ---
>
> Key: MPIR-373
> URL: https://issues.apache.org/jira/browse/MPIR-373
> Project: Maven Project Info Reports Plugin
> Issue Type: Bug
>Affects Versions: 3.0.0
>Reporter: GWR
>Priority: Minor
> Attachments: pom.xml
>
>
> a new warning-message introduced, causing some confusion in the devteam.
> When stepping up to maven-project-info-reports-plugin:3.0.0 (from2.9) the
> stacktrace below is seen.
> mvn3.0.5, 3.3.9 and 3.5.2 all give same stacktrace.
> Seems to caused by the xml-resolver:1.2, having a pom.xml containing the
> section.
>
> {code:java}
>
> deployed
>
> {code}
> Is there some more restrictive pom validation introduced with
> maven-project-info-reports-plugin:3.0.0
> {code:java}
> $ mvn project-info-reports:dependencies
> [WARNING] Unable to create Maven project from repository for artifact
> xml-resolver:xml-resolver:jar:1.2
> org.apache.maven.project.ProjectBuildingException: Some problems were
> encountered while processing the POMs:
> [ERROR] 'distributionManagement.status' must not be specified. @ line 36,
> column 13
> at org.apache.maven.project.DefaultProjectBuilder.build
> (DefaultProjectBuilder.java:191)
> at org.apache.maven.project.DefaultProjectBuilder.build
> (DefaultProjectBuilder.java:326)
> at
> org.apache.maven.report.projectinfo.dependencies.RepositoryUtils.getMavenProjectFromRepository
> (RepositoryUtils.java:125)
> at
> org.apache.maven.report.projectinfo.dependencies.renderer.DependenciesRenderer.printDescriptionsAndURLs
> (DependenciesRenderer.java:890)
> at
> org.apache.maven.report.projectinfo.dependencies.renderer.DependenciesRenderer.printDependencyListing
> (DependenciesRenderer.java:847)
> at
> org.apache.maven.report.projectinfo.dependencies.renderer.DependenciesRenderer.printDependencyListing
> (DependenciesRenderer.java:867)
> at
> org.apache.maven.report.projectinfo.dependencies.renderer.DependenciesRenderer.printDependencyListing
> (DependenciesRenderer.java:867)
> at
> org.apache.maven.report.projectinfo.dependencies.renderer.DependenciesRenderer.printDependencyListing
> (DependenciesRenderer.java:867)
> at
> org.apache.maven.report.projectinfo.dependencies.renderer.DependenciesRenderer.renderSectionDependencyTree
> (DependenciesRenderer.java:486)
> at
> org.apache.maven.report.projectinfo.dependencies.renderer.DependenciesRenderer.renderSectionProjectDependencyGraph
> (DependenciesRenderer.java:449)
> at
> org.apache.maven.report.projectinfo.dependencies.renderer.DependenciesRenderer.renderBody
> (DependenciesRenderer.java:222)
> at org.apache.maven.reporting.AbstractMavenReportRenderer.render
> (AbstractMavenReportRenderer.java:80)
> at org.apache.maven.report.projectinfo.DependenciesReport.executeReport
> (DependenciesReport.java:162)
> at org.apache.maven.reporting.AbstractMavenReport.generate
> (AbstractMavenReport.java:251)
> at org.apache.maven.report.projectinfo.AbstractProjectInfoReport.execute
> (AbstractProjectInfoReport.java:220)
> at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo
> (DefaultBuildPluginManager.java:134)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:208)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:154)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:146)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:117)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:81)
> at
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build
> (SingleThreadedBuilder.java:51)
> at org.apache.maven.lifecycle.internal.LifecycleStarter.execute
> (LifecycleStarter.java:128)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:309)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:194)
> at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:107)
> at org.apache.maven.cli.MavenCli.execute (MavenCli.java:955)
> at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:290)
> at org.apache.maven.cli.MavenCli.main (MavenCli.java:194)
> at sun.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke
> (NativeMethodAccessorImpl.java:62)
> at
[jira] [Commented] (MPIR-373) Upgrade from 2.9 to 3.0.0 introduces additional warning
[
https://issues.apache.org/jira/browse/MPIR-373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16693697#comment-16693697
]
Olaf Flebbe commented on MPIR-373:
--
Hi , this issue is triggered by recent maven-site-pugin report as well.
Aggravated that Jenkins is looking out for i[ERROR] in output and triggers an
failed build, though it is more or less a warning, since we cannot fix things
in central.
[~rfscholte] Do you have already a patch handy ? I would vote for this kind of
solution .
> Upgrade from 2.9 to 3.0.0 introduces additional warning
> ---
>
> Key: MPIR-373
> URL: https://issues.apache.org/jira/browse/MPIR-373
> Project: Maven Project Info Reports Plugin
> Issue Type: Bug
>Affects Versions: 3.0.0
>Reporter: GWR
>Priority: Minor
> Attachments: pom.xml
>
>
> a new warning-message introduced, causing some confusion in the devteam.
> When stepping up to maven-project-info-reports-plugin:3.0.0 (from2.9) the
> stacktrace below is seen.
> mvn3.0.5, 3.3.9 and 3.5.2 all give same stacktrace.
> Seems to caused by the xml-resolver:1.2, having a pom.xml containing the
> section.
>
> {code:java}
>
> deployed
>
> {code}
> Is there some more restrictive pom validation introduced with
> maven-project-info-reports-plugin:3.0.0
> {code:java}
> $ mvn project-info-reports:dependencies
> [WARNING] Unable to create Maven project from repository for artifact
> xml-resolver:xml-resolver:jar:1.2
> org.apache.maven.project.ProjectBuildingException: Some problems were
> encountered while processing the POMs:
> [ERROR] 'distributionManagement.status' must not be specified. @ line 36,
> column 13
> at org.apache.maven.project.DefaultProjectBuilder.build
> (DefaultProjectBuilder.java:191)
> at org.apache.maven.project.DefaultProjectBuilder.build
> (DefaultProjectBuilder.java:326)
> at
> org.apache.maven.report.projectinfo.dependencies.RepositoryUtils.getMavenProjectFromRepository
> (RepositoryUtils.java:125)
> at
> org.apache.maven.report.projectinfo.dependencies.renderer.DependenciesRenderer.printDescriptionsAndURLs
> (DependenciesRenderer.java:890)
> at
> org.apache.maven.report.projectinfo.dependencies.renderer.DependenciesRenderer.printDependencyListing
> (DependenciesRenderer.java:847)
> at
> org.apache.maven.report.projectinfo.dependencies.renderer.DependenciesRenderer.printDependencyListing
> (DependenciesRenderer.java:867)
> at
> org.apache.maven.report.projectinfo.dependencies.renderer.DependenciesRenderer.printDependencyListing
> (DependenciesRenderer.java:867)
> at
> org.apache.maven.report.projectinfo.dependencies.renderer.DependenciesRenderer.printDependencyListing
> (DependenciesRenderer.java:867)
> at
> org.apache.maven.report.projectinfo.dependencies.renderer.DependenciesRenderer.renderSectionDependencyTree
> (DependenciesRenderer.java:486)
> at
> org.apache.maven.report.projectinfo.dependencies.renderer.DependenciesRenderer.renderSectionProjectDependencyGraph
> (DependenciesRenderer.java:449)
> at
> org.apache.maven.report.projectinfo.dependencies.renderer.DependenciesRenderer.renderBody
> (DependenciesRenderer.java:222)
> at org.apache.maven.reporting.AbstractMavenReportRenderer.render
> (AbstractMavenReportRenderer.java:80)
> at org.apache.maven.report.projectinfo.DependenciesReport.executeReport
> (DependenciesReport.java:162)
> at org.apache.maven.reporting.AbstractMavenReport.generate
> (AbstractMavenReport.java:251)
> at org.apache.maven.report.projectinfo.AbstractProjectInfoReport.execute
> (AbstractProjectInfoReport.java:220)
> at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo
> (DefaultBuildPluginManager.java:134)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:208)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:154)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:146)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:117)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:81)
> at
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build
> (SingleThreadedBuilder.java:51)
> at org.apache.maven.lifecycle.internal.LifecycleStarter.execute
> (LifecycleStarter.java:128)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:309)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:194)
> at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:107)
> at org.apache.maven.cli.MavenCli.execute (MavenCli.java:955)
> at
[jira] [Updated] (MNGSITE-292) Update the mini guide to creating archectypes to Archetype 2.x
[ https://issues.apache.org/jira/browse/MNGSITE-292?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hervé Boutemy updated MNGSITE-292: -- Description: as noticed by a user recently, the [mini-guide|https://maven.apache.org/guides/mini/guide-creating-archetypes.html] explains about Archetype 1.x which is deprecated in favor of Archetype 2.x Archetype 1.x used archetype.xml descriptor: [https://maven.apache.org/archetype/archetype-common/archetype.html] Archetype 2.x uses a different descriptor archetype-metadata.xml with a different schema : [https://maven.apache.org/archetype/archetype-models/archetype-descriptor/archetype-descriptor.html] there may be other differences when upgrading from Archetype 1 to Archetype 2, I did not investigate in details was:as noticed by a user recently, the [mini-guide|https://maven.apache.org/guides/mini/guide-creating-archetypes.html] explains about Archetype 1.x, with its archetype.xml descriptor, which is deprecated: Archetype 2.x has its descriptor with a different schema under archetype-metadata.xml (there may be other differences, I did not investigate in details) > Update the mini guide to creating archectypes to Archetype 2.x > -- > > Key: MNGSITE-292 > URL: https://issues.apache.org/jira/browse/MNGSITE-292 > Project: Maven Project Web Site > Issue Type: Improvement >Reporter: Hervé Boutemy >Priority: Major > Labels: up-for-grabs > > as noticed by a user recently, the > [mini-guide|https://maven.apache.org/guides/mini/guide-creating-archetypes.html] > explains about Archetype 1.x which is deprecated in favor of Archetype 2.x > Archetype 1.x used archetype.xml descriptor: > [https://maven.apache.org/archetype/archetype-common/archetype.html] > Archetype 2.x uses a different descriptor archetype-metadata.xml with a > different schema : > [https://maven.apache.org/archetype/archetype-models/archetype-descriptor/archetype-descriptor.html] > there may be other differences when upgrading from Archetype 1 to Archetype > 2, I did not investigate in details -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MSHADE-291) shadedPattern applied multiples times when relocating the contents of META-INF/services files
[
https://issues.apache.org/jira/browse/MSHADE-291?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16693640#comment-16693640
]
Robert Scholte commented on MSHADE-291:
---
[~jluehe] even though
[releasing|https://maven.apache.org/developers/release/maven-project-release-procedure.html]
isn't that hard, the [voting|https://www.apache.org/foundation/voting.html]
process will always claim time from several Maven PMC members. For that reason
I prefer not to do releases for a single issue.
However, if you manage to provide PRs for open issues of this plugin you
increase the chance of a release.
> shadedPattern applied multiples times when relocating the contents of
> META-INF/services files
> -
>
> Key: MSHADE-291
> URL: https://issues.apache.org/jira/browse/MSHADE-291
> Project: Maven Shade Plugin
> Issue Type: Bug
>Affects Versions: 3.1.1, 3.2.0, 3.2.1
>Reporter: Jan Luehe
>Assignee: Robert Scholte
>Priority: Major
> Labels: up-for-grabs
> Fix For: 3.2.2
>
>
> Steps to reproduce:
> 1. Modified the test case for
> https://issues.apache.org/jira/browse/MSHADE-190, as follows:
> {code:java}
> diff --git a/pom.xml b/pom.xml
> index 746b700..aea9abb 100644
> --- a/pom.xml
> +++ b/pom.xml
> @@ -68,12 +68,12 @@
>
> org.apache.maven.plugins
> maven-shade-plugin
> -2.4
> +3.1.1
>
>
>
> -org.eclipse.*
> -borg.eclipse.*
> +org.eclipse
> +org.eclipse1234
>
>
>
> {code}
> 2. mvn package
> 3. jar -xvf target/shade-meta-tc-1.0-SNAPSHOT.jar META-INF/services
> 4. cat META-INF/services/org.osgi.framework.launch.FrameworkFactory
> The shaded service implementation class looks as follows:
> {code:java}
> org.eclipse12341234.osgi.launch.EquinoxFactory
> {code}
> It appears that shadedPattern was applied twice.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (MNGSITE-292) Update the mini guide to creating archectypes to Archetype 2.x
[ https://issues.apache.org/jira/browse/MNGSITE-292?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hervé Boutemy updated MNGSITE-292: -- Labels: up-for-grabs (was: ) > Update the mini guide to creating archectypes to Archetype 2.x > -- > > Key: MNGSITE-292 > URL: https://issues.apache.org/jira/browse/MNGSITE-292 > Project: Maven Project Web Site > Issue Type: Improvement >Reporter: Hervé Boutemy >Priority: Major > Labels: up-for-grabs > > as noticed by a user recently, the > [mini-guide|https://maven.apache.org/guides/mini/guide-creating-archetypes.html] > explains about Archetype 1.x, with its archetype.xml descriptor, which is > deprecated: Archetype 2.x has its descriptor with a different schema under > archetype-metadata.xml (there may be other differences, I did not investigate > in details) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MSHADE-291) shadedPattern applied multiples times when relocating the contents of META-INF/services files
[
https://issues.apache.org/jira/browse/MSHADE-291?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16693601#comment-16693601
]
Jan Luehe commented on MSHADE-291:
--
[~fabcipriano] and [~rfscholte], thank you for the fix! Would it be possible to
make version 3.2.2 available at
https://mvnrepository.com/artifact/org.apache.maven.plugins/maven-shade-plugin?
> shadedPattern applied multiples times when relocating the contents of
> META-INF/services files
> -
>
> Key: MSHADE-291
> URL: https://issues.apache.org/jira/browse/MSHADE-291
> Project: Maven Shade Plugin
> Issue Type: Bug
>Affects Versions: 3.1.1, 3.2.0, 3.2.1
>Reporter: Jan Luehe
>Assignee: Robert Scholte
>Priority: Major
> Labels: up-for-grabs
> Fix For: 3.2.2
>
>
> Steps to reproduce:
> 1. Modified the test case for
> https://issues.apache.org/jira/browse/MSHADE-190, as follows:
> {code:java}
> diff --git a/pom.xml b/pom.xml
> index 746b700..aea9abb 100644
> --- a/pom.xml
> +++ b/pom.xml
> @@ -68,12 +68,12 @@
>
> org.apache.maven.plugins
> maven-shade-plugin
> -2.4
> +3.1.1
>
>
>
> -org.eclipse.*
> -borg.eclipse.*
> +org.eclipse
> +org.eclipse1234
>
>
>
> {code}
> 2. mvn package
> 3. jar -xvf target/shade-meta-tc-1.0-SNAPSHOT.jar META-INF/services
> 4. cat META-INF/services/org.osgi.framework.launch.FrameworkFactory
> The shaded service implementation class looks as follows:
> {code:java}
> org.eclipse12341234.osgi.launch.EquinoxFactory
> {code}
> It appears that shadedPattern was applied twice.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (MNG-6523) System Dependencies Deprication
[ https://issues.apache.org/jira/browse/MNG-6523?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov updated MNG-6523: Fix Version/s: wontfix-candidate > System Dependencies Deprication > --- > > Key: MNG-6523 > URL: https://issues.apache.org/jira/browse/MNG-6523 > Project: Maven > Issue Type: Wish >Reporter: Alireza Fattahi >Priority: Major > Fix For: wontfix-candidate > > > Please let me know if this is wrong place for discussions about this. > > As mentioned in > [https://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#System_Dependencies] > the System Dependencies will be depreciated and should not be used. > Well this feature seems very useful in some cases and must developers find it > easy to use: > [https://stackoverflow.com/a/4491469/2648077] > [https://stackoverflow.com/a/22300875/2648077] > > Well I wish it wouldn't be deprecated at all :) > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MNG-6523) System Dependencies Deprication
[ https://issues.apache.org/jira/browse/MNG-6523?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16693293#comment-16693293 ] Michael Osipov commented on MNG-6523: - Please the exact usecase where this is useful and cannot be deployed to a repo. I fail to find one. > System Dependencies Deprication > --- > > Key: MNG-6523 > URL: https://issues.apache.org/jira/browse/MNG-6523 > Project: Maven > Issue Type: Wish >Reporter: Alireza Fattahi >Priority: Major > > Please let me know if this is wrong place for discussions about this. > > As mentioned in > [https://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#System_Dependencies] > the System Dependencies will be depreciated and should not be used. > Well this feature seems very useful in some cases and must developers find it > easy to use: > [https://stackoverflow.com/a/4491469/2648077] > [https://stackoverflow.com/a/22300875/2648077] > > Well I wish it wouldn't be deprecated at all :) > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (MNG-6523) System Dependencies Deprication
[ https://issues.apache.org/jira/browse/MNG-6523?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16693293#comment-16693293 ] Michael Osipov edited comment on MNG-6523 at 11/20/18 2:17 PM: --- Please the exact usecase where this is useful and cannot be deployed to a repo. I fail to find one. The SO answer can be covered with the description above. was (Author: michael-o): Please the exact usecase where this is useful and cannot be deployed to a repo. I fail to find one. > System Dependencies Deprication > --- > > Key: MNG-6523 > URL: https://issues.apache.org/jira/browse/MNG-6523 > Project: Maven > Issue Type: Wish >Reporter: Alireza Fattahi >Priority: Major > > Please let me know if this is wrong place for discussions about this. > > As mentioned in > [https://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#System_Dependencies] > the System Dependencies will be depreciated and should not be used. > Well this feature seems very useful in some cases and must developers find it > easy to use: > [https://stackoverflow.com/a/4491469/2648077] > [https://stackoverflow.com/a/22300875/2648077] > > Well I wish it wouldn't be deprecated at all :) > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (MSHARED-777) Remove deprecated main attributes from generated manifest
[
https://issues.apache.org/jira/browse/MSHARED-777?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov reassigned MSHARED-777:
--
Assignee: Michael Osipov
> Remove deprecated main attributes from generated manifest
> -
>
> Key: MSHARED-777
> URL: https://issues.apache.org/jira/browse/MSHARED-777
> Project: Maven Shared Components
> Issue Type: Improvement
> Components: maven-archiver
>Affects Versions: maven-archiver-3.2.0
>Reporter: Franz van Betteraey
>Assignee: Michael Osipov
>Priority: Minor
>
> The MANIFEST implementation entries can be generated by using the
> 'addDefaultImplementationEntries' of the Apache Maven Archiver configuration
> (http://maven.apache.org/shared/maven-archiver/index.html#class_manifest)
> like this:
>
>
>
> true
>
>
>
> This will add
> Implementation-Title: ${project.name}
> Implementation-Version: ${project.version}
> Implementation-Vendor-Id: ${project.groupId}
> Implementation-Vendor: ${project.organization.name}
> Implementation-URL: ${project.url}
> to the MANIFEST.MF file. But
> Implementation-Vendor-Id and
> Implementation-URL
> are deprecated by now (at least since Java 8 as seen here):
> https://docs.oracle.com/javase/8/docs/technotes/guides/jar/jar.html#Main_Attributes
> In the Java 11 jar Manifest Specification they are not mentioned anymore.
> https://docs.oracle.com/en/java/javase/11/docs/specs/jar/jar.html#manifest-specification
> Thus I guess they also should be removed while generating the main
> implementation entries by the Maven Archiver.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (MSHARED-777) Remove deprecated main attributes from generated manifest
[
https://issues.apache.org/jira/browse/MSHARED-777?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated MSHARED-777:
---
Summary: Remove deprecated main attributes from generated manifest (was:
remove deprecated main attributes from generated MANIFEST)
> Remove deprecated main attributes from generated manifest
> -
>
> Key: MSHARED-777
> URL: https://issues.apache.org/jira/browse/MSHARED-777
> Project: Maven Shared Components
> Issue Type: Improvement
> Components: maven-archiver
>Affects Versions: maven-archiver-3.2.0
>Reporter: Franz van Betteraey
>Priority: Minor
>
> The MANIFEST implementation entries can be generated by using the
> 'addDefaultImplementationEntries' of the Apache Maven Archiver configuration
> (http://maven.apache.org/shared/maven-archiver/index.html#class_manifest)
> like this:
>
>
>
> true
>
>
>
> This will add
> Implementation-Title: ${project.name}
> Implementation-Version: ${project.version}
> Implementation-Vendor-Id: ${project.groupId}
> Implementation-Vendor: ${project.organization.name}
> Implementation-URL: ${project.url}
> to the MANIFEST.MF file. But
> Implementation-Vendor-Id and
> Implementation-URL
> are deprecated by now (at least since Java 8 as seen here):
> https://docs.oracle.com/javase/8/docs/technotes/guides/jar/jar.html#Main_Attributes
> In the Java 11 jar Manifest Specification they are not mentioned anymore.
> https://docs.oracle.com/en/java/javase/11/docs/specs/jar/jar.html#manifest-specification
> Thus I guess they also should be removed while generating the main
> implementation entries by the Maven Archiver.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Moved] (MSHARED-777) remove deprecated main attributes from generated MANIFEST
[
https://issues.apache.org/jira/browse/MSHARED-777?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov moved MNG-6521 to MSHARED-777:
-
Affects Version/s: (was: 3.6.0)
maven-archiver-3.2.0
Component/s: (was: Artifacts and Repositories)
maven-archiver
Key: MSHARED-777 (was: MNG-6521)
Project: Maven Shared Components (was: Maven)
> remove deprecated main attributes from generated MANIFEST
> -
>
> Key: MSHARED-777
> URL: https://issues.apache.org/jira/browse/MSHARED-777
> Project: Maven Shared Components
> Issue Type: Improvement
> Components: maven-archiver
>Affects Versions: maven-archiver-3.2.0
>Reporter: Franz van Betteraey
>Priority: Minor
>
> The MANIFEST implementation entries can be generated by using the
> 'addDefaultImplementationEntries' of the Apache Maven Archiver configuration
> (http://maven.apache.org/shared/maven-archiver/index.html#class_manifest)
> like this:
>
>
>
> true
>
>
>
> This will add
> Implementation-Title: ${project.name}
> Implementation-Version: ${project.version}
> Implementation-Vendor-Id: ${project.groupId}
> Implementation-Vendor: ${project.organization.name}
> Implementation-URL: ${project.url}
> to the MANIFEST.MF file. But
> Implementation-Vendor-Id and
> Implementation-URL
> are deprecated by now (at least since Java 8 as seen here):
> https://docs.oracle.com/javase/8/docs/technotes/guides/jar/jar.html#Main_Attributes
> In the Java 11 jar Manifest Specification they are not mentioned anymore.
> https://docs.oracle.com/en/java/javase/11/docs/specs/jar/jar.html#manifest-specification
> Thus I guess they also should be removed while generating the main
> implementation entries by the Maven Archiver.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MNG-6521) remove deprecated main attributes from generated MANIFEST
[
https://issues.apache.org/jira/browse/MNG-6521?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16693151#comment-16693151
]
Michael Osipov commented on MNG-6521:
-
I do agree, anyhting else which is not in the spec?
> remove deprecated main attributes from generated MANIFEST
> -
>
> Key: MNG-6521
> URL: https://issues.apache.org/jira/browse/MNG-6521
> Project: Maven
> Issue Type: Improvement
> Components: Artifacts and Repositories
>Affects Versions: 3.6.0
>Reporter: Franz van Betteraey
>Priority: Minor
>
> The MANIFEST implementation entries can be generated by using the
> 'addDefaultImplementationEntries' of the Apache Maven Archiver configuration
> (http://maven.apache.org/shared/maven-archiver/index.html#class_manifest)
> like this:
>
>
>
> true
>
>
>
> This will add
> Implementation-Title: ${project.name}
> Implementation-Version: ${project.version}
> Implementation-Vendor-Id: ${project.groupId}
> Implementation-Vendor: ${project.organization.name}
> Implementation-URL: ${project.url}
> to the MANIFEST.MF file. But
> Implementation-Vendor-Id and
> Implementation-URL
> are deprecated by now (at least since Java 8 as seen here):
> https://docs.oracle.com/javase/8/docs/technotes/guides/jar/jar.html#Main_Attributes
> In the Java 11 jar Manifest Specification they are not mentioned anymore.
> https://docs.oracle.com/en/java/javase/11/docs/specs/jar/jar.html#manifest-specification
> Thus I guess they also should be removed while generating the main
> implementation entries by the Maven Archiver.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MNG-6521) remove deprecated main attributes from generated MANIFEST
[
https://issues.apache.org/jira/browse/MNG-6521?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16692809#comment-16692809
]
Franz van Betteraey commented on MNG-6521:
--
I don't think that they really hurt but the content of the MANIFEST seems to be
exactly specified and thus I would prefer if the content would follow the
specification.
In fact, I became aware of this when I wanted to look up the meaning for
_Implementation-Vendor-Id_, but couldn't find it in the current specification.
The default value of _${project.groupId}_ doesn't make sense for us either.
> remove deprecated main attributes from generated MANIFEST
> -
>
> Key: MNG-6521
> URL: https://issues.apache.org/jira/browse/MNG-6521
> Project: Maven
> Issue Type: Improvement
> Components: Artifacts and Repositories
>Affects Versions: 3.6.0
>Reporter: Franz van Betteraey
>Priority: Minor
>
> The MANIFEST implementation entries can be generated by using the
> 'addDefaultImplementationEntries' of the Apache Maven Archiver configuration
> (http://maven.apache.org/shared/maven-archiver/index.html#class_manifest)
> like this:
>
>
>
> true
>
>
>
> This will add
> Implementation-Title: ${project.name}
> Implementation-Version: ${project.version}
> Implementation-Vendor-Id: ${project.groupId}
> Implementation-Vendor: ${project.organization.name}
> Implementation-URL: ${project.url}
> to the MANIFEST.MF file. But
> Implementation-Vendor-Id and
> Implementation-URL
> are deprecated by now (at least since Java 8 as seen here):
> https://docs.oracle.com/javase/8/docs/technotes/guides/jar/jar.html#Main_Attributes
> In the Java 11 jar Manifest Specification they are not mentioned anymore.
> https://docs.oracle.com/en/java/javase/11/docs/specs/jar/jar.html#manifest-specification
> Thus I guess they also should be removed while generating the main
> implementation entries by the Maven Archiver.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
