[jira] [Commented] (MNG-6391) Printout version of last built module in reactor build
[
https://issues.apache.org/jira/browse/MNG-6391?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16635057#comment-16635057
]
Robert Scholte commented on MNG-6391:
-
I've been thinking about that option too and I agree that added the root
artifactId or name makes sense. Now it looks like some unrelated version. Plus
there's still enough space.
> Printout version of last built module in reactor build
> --
>
> Key: MNG-6391
> URL: https://issues.apache.org/jira/browse/MNG-6391
> Project: Maven
> Issue Type: Improvement
> Components: core
>Affects Versions: 3.5.3
>Reporter: Alexander Griesbaum
>Assignee: Karl Heinz Marbaise
>Priority: Minor
> Fix For: 3.6.0
>
>
> MNG-6352 introduced printout of the version in a reactor build.
> If I build a multi-module project, not just the parent has the version
> printout but also the last built module.
> {code:java}
> [INFO]
>
> [INFO] Reactor Summary:
> [INFO]
> [INFO] parent 4.0.0-SNAPSHOT . SUCCESS [ 3.610 s]
> [INFO] parent-lib SUCCESS [ 0.492 s]
> [INFO] commons ... SUCCESS [ 25.444 s]
> [INFO] loadbalancer-starter .. SUCCESS [ 21.198 s]
> [INFO] proxy-config-starter 4.0.0-SNAPSHOT ... SUCCESS [ 7.496 s]
> [INFO]
>
> [INFO] BUILD SUCCESS
> [INFO]
>
> {code}
> If I remove the "proxy-config-starter" module, "loadbalancer-starter" got the
> version printout.
> Also this is not the order I configured the modules in the parent pom but I
> think this could be something on my side.
> {code:java}
>
> commons
> loadbalancer-starter
> parent-lib
> proxy-config-starter
>
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (JXR-141) Invalid HTML generation
Anthony Whitford created JXR-141:
Summary: Invalid HTML generation
Key: JXR-141
URL: https://issues.apache.org/jira/browse/JXR-141
Project: Maven JXR
Issue Type: Bug
Components: jxr
Affects Versions: 3.0.0
Environment: Windows 7, Java 8 Update 60, Maven 3.3.9
Reporter: Anthony Whitford
I am getting invalid HTML generated, like:
{code:xml}
51 public TreeNode
(final String text, TreeNode"jxr_keyword">final
Boolean checked, final TreeNode[]
children) {
{code}
Specifically, look at:
{code:xml}
TreeNode"jxr_keyword">final
Boolean checked
{code}
The original Java code is:
{code}
public TreeNode (final String text, final Boolean checked, final TreeNode[]
children) {
{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MNG-6311) Maven intolerably slow when import scope used heavily in large project
[ https://issues.apache.org/jira/browse/MNG-6311?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16634755#comment-16634755 ] Hudson commented on MNG-6311: - Build succeeded in Jenkins: Maven TLP » maven » jenkins-relativize-problem #4 See https://builds.apache.org/job/maven-box/job/maven/job/jenkins-relativize-problem/4/ > Maven intolerably slow when import scope used heavily in large project > -- > > Key: MNG-6311 > URL: https://issues.apache.org/jira/browse/MNG-6311 > Project: Maven > Issue Type: Bug > Components: core, Performance >Affects Versions: 3.5.0, 3.5.2 >Reporter: David Churcher >Assignee: Sylwester Lachiewicz >Priority: Major > Labels: performance > Fix For: 3.6.0 > > Attachments: Call-tree-–-All-threads-together.html, > anon-hierarchy-maven-output.zip, modelcachefix.diff > > > I have a build performance problem that is identical to MNG-5312, and has > appeared since MNG-6030 in Maven v3.5.0 reversed the patch for MNG-5312, > removing the ModelCache from some of the overloads for > DefaultProjectBuilder.build. > As in MNG-5312 the problem is in a large proprietary project. It uses up to 8 > levels of parent POMs, many of which use the import scope and have large > dependency-management sections, and has hundreds of dependencies that also > use the same parent POM hierarchy. Adding some logging shows that Maven does > over 800,000 uncached reads of parent POM files, which takes about half an > hour. With model caching this goes down to a few seconds. > I've attached a patch that fixes this by using a class-level ModelCache in > DefaultProjectBuilder. This does not suffer from the memory usage problems > reported in MNG-6030. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MNG-6479) Upgrade XMLUnit to 2.2.1
[ https://issues.apache.org/jira/browse/MNG-6479?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16634761#comment-16634761 ] Hudson commented on MNG-6479: - Build succeeded in Jenkins: Maven TLP » maven » jenkins-relativize-problem #4 See https://builds.apache.org/job/maven-box/job/maven/job/jenkins-relativize-problem/4/ > Upgrade XMLUnit to 2.2.1 > > > Key: MNG-6479 > URL: https://issues.apache.org/jira/browse/MNG-6479 > Project: Maven > Issue Type: Dependency upgrade >Reporter: Sylwester Lachiewicz >Assignee: Sylwester Lachiewicz >Priority: Trivial > Fix For: 3.6.0 > > > Upgrade XMLUnit test dependency from 1.x line to 2.2.1 and correct test cases > _XMLUnit 2.x will never try to compare unmatched nodes with arbitrary other > nodes_ -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MNG-6478) Upgrade parent to 33 for sha512 checksum on release
[ https://issues.apache.org/jira/browse/MNG-6478?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16634757#comment-16634757 ] Hudson commented on MNG-6478: - Build succeeded in Jenkins: Maven TLP » maven » jenkins-relativize-problem #4 See https://builds.apache.org/job/maven-box/job/maven/job/jenkins-relativize-problem/4/ > Upgrade parent to 33 for sha512 checksum on release > --- > > Key: MNG-6478 > URL: https://issues.apache.org/jira/browse/MNG-6478 > Project: Maven > Issue Type: Dependency upgrade >Affects Versions: 3.6.0 >Reporter: Hervé Boutemy >Assignee: Hervé Boutemy >Priority: Major > Fix For: 3.6.0 > > > benefit from MPOM-205 and customize for Maven core (which does not have > classical release files) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MNG-6415) Project Artifacts Cache does not retain the order of classpath entries.
[ https://issues.apache.org/jira/browse/MNG-6415?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16634763#comment-16634763 ] Hudson commented on MNG-6415: - Build succeeded in Jenkins: Maven TLP » maven » jenkins-relativize-problem #4 See https://builds.apache.org/job/maven-box/job/maven/job/jenkins-relativize-problem/4/ > Project Artifacts Cache does not retain the order of classpath entries. > --- > > Key: MNG-6415 > URL: https://issues.apache.org/jira/browse/MNG-6415 > Project: Maven > Issue Type: Bug > Components: core >Affects Versions: 3.5.2 > Environment: Windows 7, JDK8u144 >Reporter: Seckin Onur SELAMET >Assignee: Robert Scholte >Priority: Major > Labels: CLASSPATH > Fix For: 3.6.0 > > Attachments: > [MNG-6415]_Fixes_Project_Artifact_Cache_classpath_order_retaining_issue_.patch > > > Project artifacts cache does not retain the order of classpath entries. > Wrong Object type used in implementation. HashSet can not guarantee the order > of elements. > In runtime ProjectArtifacts passed as LinkedHashSet already which is safe. > > Possible fix is provided in comments section. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MNG-6358) Maven build should not require access to apache.org
[
https://issues.apache.org/jira/browse/MNG-6358?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16634760#comment-16634760
]
Hudson commented on MNG-6358:
-
Build succeeded in Jenkins: Maven TLP » maven » jenkins-relativize-problem #4
See
https://builds.apache.org/job/maven-box/job/maven/job/jenkins-relativize-problem/4/
> Maven build should not require access to apache.org
> ---
>
> Key: MNG-6358
> URL: https://issues.apache.org/jira/browse/MNG-6358
> Project: Maven
> Issue Type: Bug
> Components: Bootstrap & Build
>Affects Versions: 3.2.1, 3.5.2
> Environment: RHEL 7.4
> JDK 1.8.0_141
>Reporter: Adam John Burley
>Assignee: Hervé Boutemy
>Priority: Minor
> Fix For: 3.6.0
>
>
> I am trying to build Maven 3.5.2 from source using Maven 3.0.5. The machine I
> am building on has access to an internal Maven repository, but doesn't have
> access to the Internet.
> The build fails, seemingly because it cannot access {{apache.org}} to
> download the license. But I don't understand why it needs to do this, as the
> license is already contained in file {{apache-jar-resource-bundle}} which is
> retrieved as a Maven dependency.
> Here is the log I get:
> {code}
> [INFO] --- apache-rat-plugin:0.11:check (rat-check) @ apache-maven ---
> [INFO] 51 implicit excludes (use -debug for more details).
> [INFO] Exclude: src/test/resources*/**
> [INFO] Exclude: src/test/projects/**
> [INFO] Exclude: src/test/remote-repo/**
> [INFO] Exclude: **/*.odg
> [INFO] Exclude: src/bin/m2.conf
> [INFO] Exclude: bootstrap/**
> [INFO] Exclude: README.bootstrap.txt
> [INFO] Exclude: .repository/**
> [INFO] Exclude: .maven/spy.log
> [INFO] Exclude: .java-version
> [INFO] Exclude: README.md
> [INFO] Exclude: DEPENDENCIES
> [INFO] 19 resources included (use -debug for more details)
> [INFO] Rat check: Summary of files. Unapproved: 0 unknown: 0 generated: 0
> approved: 16 licence.
> [INFO]
> [INFO] --- maven-dependency-plugin:2.8:unpack-dependencies
> (unpack-jansi-native) @ apache-maven ---
> [INFO] Unpacking
> /root/.m2/repository/org/fusesource/jansi/jansi/1.16/jansi-1.16.jar to
> /tmp/maven-build/apache-maven/target/dependency with includes
> "META-INF/native/**" and excludes ""
> [INFO]
> [INFO] --- maven-remote-resources-plugin:1.5:process (default) @ apache-maven
> ---
> [INFO]
>
> [INFO] Reactor Summary:
> [INFO]
> [INFO] Apache Maven .. SUCCESS [25.091s]
> [INFO] Maven Model ... SUCCESS [18.000s]
> [INFO] Maven Artifact SUCCESS [4.418s]
> [INFO] Maven Plugin API .. SUCCESS [4.677s]
> [INFO] Maven Builder Support . SUCCESS [1.900s]
> [INFO] Maven Model Builder ... SUCCESS [5.690s]
> [INFO] Maven Settings SUCCESS [1.905s]
> [INFO] Maven Settings Builder SUCCESS [2.010s]
> [INFO] Maven Repository Metadata Model ... SUCCESS [1.511s]
> [INFO] Maven Artifact Resolver Provider .. SUCCESS [5.110s]
> [INFO] Maven Core SUCCESS [13.168s]
> [INFO] Maven SLF4J Simple Provider ... SUCCESS [5.013s]
> [INFO] Maven Embedder SUCCESS [3.617s]
> [INFO] Maven Compat .. SUCCESS [4.462s]
> [INFO] Apache Maven Distribution . FAILURE [4:18.467s]
> [INFO]
>
> [INFO] BUILD FAILURE
> [INFO]
>
> [INFO] Total time: 5:58.134s
> [INFO] Finished at: Mon Feb 12 21:03:11 GMT 2018
> [INFO] Final Memory: 83M/190M
> [INFO]
>
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-remote-resources-plugin:1.5:process (default)
> on project apache-maven: Error rendering velocity resource. Invocation of
> method 'getResourceAsFile' in class
> org.codehaus.plexus.resource.DefaultResourceManager threw exception
> org.codehaus.plexus.resource.loader.ResourceNotFoundException: Could not find
> resource 'https://www.apache.org/licenses/LICENSE-2.0.txt'. at
> remote-resources[line 38, column 26] -> [Help 1]
> [ERROR]
> [ERROR] To see the full stack trace of the errors, re-run Maven with the -e
> switch.
> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
> [ERROR]
> [ERROR] For more information about the errors and possible solutions, please
> read
[jira] [Commented] (MNG-5951) add an option to avoid path addition to inherited URLs
[
https://issues.apache.org/jira/browse/MNG-5951?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16634759#comment-16634759
]
Hudson commented on MNG-5951:
-
Build succeeded in Jenkins: Maven TLP » maven » jenkins-relativize-problem #4
See
https://builds.apache.org/job/maven-box/job/maven/job/jenkins-relativize-problem/4/
> add an option to avoid path addition to inherited URLs
> --
>
> Key: MNG-5951
> URL: https://issues.apache.org/jira/browse/MNG-5951
> Project: Maven
> Issue Type: Improvement
> Components: Inheritance and Interpolation
>Affects Versions: 3.0.5, 3.1.1, 3.2.5, 3.3.9
>Reporter: Jörg Sesterhenn
>Assignee: Hervé Boutemy
>Priority: Major
> Fix For: 3.6.0
>
> Attachments: MNG-5951.zip
>
>
> What I am trying to achieve is
> the definition of a project.url in a parent pom
> in a way that all children inherit a url ending with
> {code}
> ${project.groupId}/${project.artifactId}/${project.version}/
> {code}
> in order to be able to publish sites of all artifacts in all versions in
> parallel
> without having to redefine the url in every child pom.
> This is currently not working as expected in maven due to the default child
> urls calculation which leads to urls that add up parent urls like
> http://my.domain.de/sites/de.enterprise.calculatorsGroupId/calculator-artifactID/1.0.0-SNAPSHOT/internetAppParentPOM/calculatorParentPom/calculator-artifactID/
> The part *"internetAppParentPOM/calculatorParentPom/"* is added by automatic
> child url calculation (those are the artifactIds of all parent poms beneath
> our enterprise parent pom where the url is defined) and *is expexted to not
> be there at all*. The repeated artifactID at the end of the url is
> superfluous as well but tollerable.
> I expect maven-core to be changed so that I can turn on/off the automatic
> calculation of child URLs as an option which is by default on (current
> behaviour so nothing will change unless configured explicitly).
> See the discussion in MSITE-672.
> As this can not be done in the maven-site-plugin there needs to be a change
> in Maven itself (core), in Maven Model Builder, ie the way effective model is
> calculated, and more precisely in the inheritance step:
> http://maven.apache.org/ref/current/maven-model-builder/.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MNG-6414) Add more Apache license header patterns to skip downloading Apache license
[
https://issues.apache.org/jira/browse/MNG-6414?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16634758#comment-16634758
]
Hudson commented on MNG-6414:
-
Build succeeded in Jenkins: Maven TLP » maven » jenkins-relativize-problem #4
See
https://builds.apache.org/job/maven-box/job/maven/job/jenkins-relativize-problem/4/
> Add more Apache license header patterns to skip downloading Apache license
> --
>
> Key: MNG-6414
> URL: https://issues.apache.org/jira/browse/MNG-6414
> Project: Maven
> Issue Type: Improvement
>Affects Versions: 3.2.1, 3.3.9, 3.5.4
>Reporter: Sylwester Lachiewicz
>Assignee: Sylwester Lachiewicz
>Priority: Minor
> Fix For: 3.6.0
>
>
> While preparing Maven distribution, maven-remote-resources-plugin uses
> {{appended-resources/META-INF/LICENSE.vm}} to add content to {{LICENSE}} and
> try to download licenses for all dependencies that are not Apache licensed
> (see end of {{LICENSE}} and resulting {{lib/*.license}} in Maven binary
> distribution, since Maven 3.2.1 MNG-5494).
> License file is not downloaded only when project/license/name is strictly
> equal to "The Apache Software License, Version 2.0": this is too restrictive,
> as we see Apache license downloaded many times from https://www.apache.org/
> (causing some issues with https: MNG-6358).
> After debugging these cases, additional patterns for Apache license exist and
> need to be added to exception list in
> {{appended-resources/META-INF/LICENSE.vm}}:
> - "Apache License, Version 2.0"
> - "The Apache Software License, Version 2.0"
> - "ASLv2"
> - "Apache Public License 2.0"
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MNG-6480) Eclipse.org site is down, and you are unable to build Maven?
[
https://issues.apache.org/jira/browse/MNG-6480?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16634762#comment-16634762
]
Hudson commented on MNG-6480:
-
Build succeeded in Jenkins: Maven TLP » maven » jenkins-relativize-problem #4
See
https://builds.apache.org/job/maven-box/job/maven/job/jenkins-relativize-problem/4/
> Eclipse.org site is down, and you are unable to build Maven?
>
>
> Key: MNG-6480
> URL: https://issues.apache.org/jira/browse/MNG-6480
> Project: Maven
> Issue Type: Improvement
>Reporter: Cservenak, Tamas
>Assignee: Hervé Boutemy
>Priority: Major
> Fix For: 3.6.0
>
>
> Was trying to build Maven locally, just to see it is failing (actually, too
> way long was stuck in console). Had no idea what is happening until I did
> {{-X}}, to see it is {{maven-remote-resources-plugin}} (see below).
> I am quite surprised to see, that if {{eclipse.org}} site is down (as in this
> moment), one cannot build Apache Maven, and I find it quite ironic.
> {noformat}
> [DEBUG] URLResourceLoader: Exception when looking for
> 'http://www.eclipse.org/legal/epl-v10.html' at ''
> java.net.SocketException: Unexpected end of file from server
> at sun.net.www.http.HttpClient.parseHTTPHeader(HttpClient.java:792)
> at sun.net.www.http.HttpClient.parseHTTP(HttpClient.java:647)
> at sun.net.www.http.HttpClient.parseHTTPHeader(HttpClient.java:789)
> at sun.net.www.http.HttpClient.parseHTTP(HttpClient.java:647)
> at
> sun.net.www.protocol.http.HttpURLConnection.getInputStream0(HttpURLConnection.java:1536)
> at
> sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1441)
> at java.net.URL.openStream(URL.java:1045)
> at
> org.codehaus.plexus.resource.loader.URLResourceLoader.getResource(URLResourceLoader.java:73)
> at
> org.codehaus.plexus.resource.DefaultResourceManager.getResource(DefaultResourceManager.java:159)
> at
> org.codehaus.plexus.resource.DefaultResourceManager.getResourceAsFile(DefaultResourceManager.java:91)
> at sun.reflect.GeneratedMethodAccessor69.invoke(Unknown Source)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.apache.velocity.util.introspection.UberspectImpl$VelMethodImpl.doInvoke(UberspectImpl.java:395)
> at
> org.apache.velocity.util.introspection.UberspectImpl$VelMethodImpl.invoke(UberspectImpl.java:384)
> at
> org.apache.velocity.runtime.parser.node.ASTMethod.execute(ASTMethod.java:173)
> at
> org.apache.velocity.runtime.parser.node.ASTReference.execute(ASTReference.java:280)
> at
> org.apache.velocity.runtime.parser.node.ASTReference.value(ASTReference.java:567)
> at
> org.apache.velocity.runtime.parser.node.ASTExpression.value(ASTExpression.java:71)
> at
> org.apache.velocity.runtime.parser.node.ASTSetDirective.render(ASTSetDirective.java:142)
> at
> org.apache.velocity.runtime.parser.node.ASTBlock.render(ASTBlock.java:72)
> at
> org.apache.velocity.runtime.parser.node.ASTIfStatement.render(ASTIfStatement.java:87)
> at
> org.apache.velocity.runtime.parser.node.ASTBlock.render(ASTBlock.java:72)
> at
> org.apache.velocity.runtime.parser.node.ASTIfStatement.render(ASTIfStatement.java:87)
> at
> org.apache.velocity.runtime.parser.node.ASTBlock.render(ASTBlock.java:72)
> at
> org.apache.velocity.runtime.directive.Foreach.render(Foreach.java:420)
> at
> org.apache.velocity.runtime.parser.node.ASTDirective.render(ASTDirective.java:207)
> at
> org.apache.velocity.runtime.parser.node.ASTBlock.render(ASTBlock.java:72)
> at
> org.apache.velocity.runtime.directive.Foreach.render(Foreach.java:420)
> at
> org.apache.velocity.runtime.parser.node.ASTDirective.render(ASTDirective.java:207)
> at
> org.apache.velocity.runtime.parser.node.SimpleNode.render(SimpleNode.java:342)
> at
> org.apache.velocity.runtime.RuntimeInstance.render(RuntimeInstance.java:1378)
> at
> org.apache.velocity.runtime.RuntimeInstance.evaluate(RuntimeInstance.java:1314)
> at org.apache.velocity.app.Velocity.evaluate(Velocity.java:254)
> at
> org.apache.maven.plugin.resources.remote.ProcessRemoteResourcesMojo.processResourceBundles(ProcessRemoteResourcesMojo.java:1218)
> at
> org.apache.maven.plugin.resources.remote.ProcessRemoteResourcesMojo.execute(ProcessRemoteResourcesMojo.java:520)
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:134)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:207)
> at
> org.apache.maven.l
[GitHub] olamy commented on a change in pull request #184: Repair Jenkins job - add a full path to workspace when run on Windows
olamy commented on a change in pull request #184: Repair Jenkins job - add a
full path to workspace when run on Windows
URL: https://github.com/apache/maven/pull/184#discussion_r221782663
##
File path: Jenkinsfile
##
@@ -79,7 +79,7 @@ for (String os in runITsOses) {
// on Windows, need a short path or we hit 256 character
limit for paths
// using EXECUTOR_NUMBER guarantees that concurrent builds
on same agent
// will not trample each other
-dir(isUnix() ? 'test' : "/mvn-it-${EXECUTOR_NUMBER}.tmp") {
+dir(isUnix() ? 'test' :
"c:\\mvn-it-${EXECUTOR_NUMBER}.tmp") {
Review comment:
I'm not a windows expert but ``` c: ``` seems to be hardcoded and can cause
some issues?
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] slachiewicz opened a new pull request #184: Repair Jenkins job - add a full path to workspace when run on Windows
slachiewicz opened a new pull request #184: Repair Jenkins job - add a full path to workspace when run on Windows URL: https://github.com/apache/maven/pull/184 Fixes errors like: Cannot relativize 'c:\mvn-it-0.tmp\core-it-support\..' relatively to '/mvn-it-0.tmp' Reference JENKINS-52657 This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Created] (MINSTALL-152) Maven Install Plugin Version 3.0.0-M1 unable to build POMs with packaging set "feature"
Stan Brown created MINSTALL-152:
---
Summary: Maven Install Plugin Version 3.0.0-M1 unable to build
POMs with packaging set "feature"
Key: MINSTALL-152
URL: https://issues.apache.org/jira/browse/MINSTALL-152
Project: Maven Install Plugin
Issue Type: Bug
Components: install:install
Affects Versions: 3.0.0-M1
Environment: Solaris 11.3
Reporter: Stan Brown
I've received the following error executing the command mvn clean deploy:
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-install-plugin:3.0.0-M1:install
(default-install) on project sis-gradaid-features-pprd:
NoFileAssignedException: The packaging plugin for this project did not assign a
main file to the project but it has attachments. Change packaging to 'pom'. ->
[Help 1] org.apache.maven.lifecycle.LifecycleExecutionException: Failed to
execute goal org.apache.maven.plugins:maven-install-plugin:3.0.0-M1:install
(default-install) on project sis-gradaid-features-pprd: NoFileAssignedException
The packaging in the POM that failed is set to "feature", which is managed by
the plugin karaf-maven-plugin.
Maven versions 3.0.4 and 3.2.3 have been used to build our project.
Here's the POM that failed:
{noformat}
http://maven.apache.org/POM/4.0.0";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
http://maven.apache.org/xsd/maven-4.0.0.xsd";>
sis
edu.uci.oit.sis
0.5.33-SNAPSHOT
4.0.0
sis-gradaid-features
feature
SIS :: Grad Aid :: Features
SIS Grad Aid Features
true
org.apache.karaf.tooling
karaf-maven-plugin
4.0.0
true
org.apache.karaf.tooling
karaf-maven-plugin
50
true
(obr)
true
false
true
true
{noformat}
Here's the summary:
{noformat}
[INFO]
[INFO] Reactor Summary:
[INFO]
[INFO] SIS :: Grad Aid :: PPRD ... SUCCESS [9.100s]
[INFO] SIS :: Grad Aid :: Student Info :: PPRD ... SUCCESS [21.268s]
[INFO] SIS :: Grad Aid :: Features :: PPRD ... FAILURE [2.040s]
[INFO] SIS :: Grad Aid :: Hibernate :: Fragment :: PPRD .. SKIPPED
[INFO]
{noformat}
Thanks for your help.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (MNG-6479) Upgrade XMLUnit to 2.2.1
[ https://issues.apache.org/jira/browse/MNG-6479?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sylwester Lachiewicz updated MNG-6479: -- Fix Version/s: (was: 3.6.0-candidate) 3.6.0 > Upgrade XMLUnit to 2.2.1 > > > Key: MNG-6479 > URL: https://issues.apache.org/jira/browse/MNG-6479 > Project: Maven > Issue Type: Dependency upgrade >Reporter: Sylwester Lachiewicz >Assignee: Sylwester Lachiewicz >Priority: Trivial > Fix For: 3.6.0 > > > Upgrade XMLUnit test dependency from 1.x line to 2.2.1 and correct test cases > _XMLUnit 2.x will never try to compare unmatched nodes with arbitrary other > nodes_ -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (MNG-6479) Upgrade XMLUnit to 2.2.1
[ https://issues.apache.org/jira/browse/MNG-6479?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sylwester Lachiewicz closed MNG-6479. - Resolution: Fixed > Upgrade XMLUnit to 2.2.1 > > > Key: MNG-6479 > URL: https://issues.apache.org/jira/browse/MNG-6479 > Project: Maven > Issue Type: Dependency upgrade >Reporter: Sylwester Lachiewicz >Assignee: Sylwester Lachiewicz >Priority: Trivial > Fix For: 3.6.0 > > > Upgrade XMLUnit test dependency from 1.x line to 2.2.1 and correct test cases > _XMLUnit 2.x will never try to compare unmatched nodes with arbitrary other > nodes_ -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (MNG-6479) Upgrade XMLUnit to 2.2.1
[ https://issues.apache.org/jira/browse/MNG-6479?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sylwester Lachiewicz reassigned MNG-6479: - Assignee: Sylwester Lachiewicz > Upgrade XMLUnit to 2.2.1 > > > Key: MNG-6479 > URL: https://issues.apache.org/jira/browse/MNG-6479 > Project: Maven > Issue Type: Dependency upgrade >Reporter: Sylwester Lachiewicz >Assignee: Sylwester Lachiewicz >Priority: Trivial > Fix For: 3.6.0 > > > Upgrade XMLUnit test dependency from 1.x line to 2.2.1 and correct test cases > _XMLUnit 2.x will never try to compare unmatched nodes with arbitrary other > nodes_ -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (SUREFIRE-1576) Spring Boot Context Failure using Surefire Plugin and -f ./pom.xml
Steven Gantz created SUREFIRE-1576:
--
Summary: Spring Boot Context Failure using Surefire Plugin and -f
./pom.xml
Key: SUREFIRE-1576
URL: https://issues.apache.org/jira/browse/SUREFIRE-1576
Project: Maven Surefire
Issue Type: Bug
Components: classloading
Affects Versions: 2.22.0
Environment: Ubuntu, RHEL, OSX, W7
Reporter: Steven Gantz
When running the Maven Surefire Plugin under specific circumstances, the Spring
context fails to load properly and presents multiple errors.
I reached out to the Spring boot repository on Github and had the following
discussion: [https://github.com/spring-projects/spring-boot/issues/14649]
The short version is that when running the following command:
{{mvn clean install -f ./pom.xml}}
The classpath is built like so:
{{[file:/Users/awilkinson/Downloads/whacky-pom/./target/test-classes/|file:///Users/awilkinson/Downloads/whacky-pom/target/test-classes/]
[file:/Users/awilkinson/Downloads/whacky-pom/./target/classes/|file:///Users/awilkinson/Downloads/whacky-pom/target/classes/]}}
Below is a comment from a spring boot maintainer:
This looks like a bug in Surefire to me. When the build is run with {{-f
./pom.xml}} that paths in the manifest of the Surefire Booter jar have
extraneous {{/./}} segments in their paths:
The simple solution is to not do ./pom.xml. However, this issue is occurring in
our CI server where most teams use {{-f ./pom.xml}} implicitly as they just
pass that in as the pom path. However, this only happens in projects using
Spring-Data-JPA and a specific list of dependencies.
Is this by design? Is it possible the library is using the paths improperly and
it isn't surefire?
Is this a bug to be fixed?
I think I can patch the CI server to handle this, but it can potentially happen
to anyone. Just looking for feedback and potential action.
On a side note, this is my first foray into any type of open source software
"contribution/interaction" wise, so please feel free to point out anything I've
done incorrectly.
If pointed in the right direction, I'd love to attempt a PR to resolve this
issue.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MNG-6391) Printout version of last built module in reactor build
[
https://issues.apache.org/jira/browse/MNG-6391?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16634626#comment-16634626
]
Michael Osipov commented on MNG-6391:
-
I like the aggregator output a lot, bu thte reactor output somehow wrong. The
reactor summary is for a combined project project and not for a version. The
version is just a metadatum of the project.
Maybe {{Reactor Summary for ${root.name} ${root.version\}}}?
> Printout version of last built module in reactor build
> --
>
> Key: MNG-6391
> URL: https://issues.apache.org/jira/browse/MNG-6391
> Project: Maven
> Issue Type: Improvement
> Components: core
>Affects Versions: 3.5.3
>Reporter: Alexander Griesbaum
>Assignee: Karl Heinz Marbaise
>Priority: Minor
> Fix For: 3.6.0
>
>
> MNG-6352 introduced printout of the version in a reactor build.
> If I build a multi-module project, not just the parent has the version
> printout but also the last built module.
> {code:java}
> [INFO]
>
> [INFO] Reactor Summary:
> [INFO]
> [INFO] parent 4.0.0-SNAPSHOT . SUCCESS [ 3.610 s]
> [INFO] parent-lib SUCCESS [ 0.492 s]
> [INFO] commons ... SUCCESS [ 25.444 s]
> [INFO] loadbalancer-starter .. SUCCESS [ 21.198 s]
> [INFO] proxy-config-starter 4.0.0-SNAPSHOT ... SUCCESS [ 7.496 s]
> [INFO]
>
> [INFO] BUILD SUCCESS
> [INFO]
>
> {code}
> If I remove the "proxy-config-starter" module, "loadbalancer-starter" got the
> version printout.
> Also this is not the order I configured the modules in the parent pom but I
> think this could be something on my side.
> {code:java}
>
> commons
> loadbalancer-starter
> parent-lib
> proxy-config-starter
>
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (MDEPLOY-244) maven deploy plugin 3.0.0-M1 breaks RPM deploys
[ https://issues.apache.org/jira/browse/MDEPLOY-244?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] William So updated MDEPLOY-244: --- Attachment: test-maven-deploy.zip > maven deploy plugin 3.0.0-M1 breaks RPM deploys > --- > > Key: MDEPLOY-244 > URL: https://issues.apache.org/jira/browse/MDEPLOY-244 > Project: Maven Deploy Plugin > Issue Type: Bug > Components: deploy:deploy-file >Affects Versions: 3.0.0-M1 >Reporter: William So >Priority: Critical > Attachments: test-maven-deploy.zip > > > After upgrading to maven deploy plugin to 3.0.0-M1, our Maven Builds that > uploads an RPM artifact broke. All other artifacts, like zips, pom, jar, > etc.. was able to upload without problems. But as soon as the build tried > to upload an RPM the upload threw an 401 Error: > > [Continue Pipeline] [ERROR] Failed to execute goal > org.apache.maven.plugins:maven-deploy-plugin:3.0.0-M1:deploy (default-deploy) > on project company-fancyname-atg-apptype-ibm-qa4: ArtifactDeployerException: > Failed to deploy artifacts: Could not transfer artifact > com.sephops.fancyname:company-fancyname-atg-apptype-ibm-qa4:rpm:ProjectName-20181001.061415-35 > from/to company-snapshot-yum::default > (http://artifactory.com/artifactory/company-snapshot-yum-local): Failed to > transfer file: > http://artifactory.com/artifactory/company-snapshot-yum-local/com/sephops/fancyname/company-fancyname-atg-apptype-ibm-qa4/ProjectName-SNAPSHOT/company-fancyname-atg-apptype-ibm-qa4-ProjectName-20181001.061415-35.rpm. > Return code is: 401, ReasonPhrase: Unauthorized. -> [Help 1] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (MDEPLOY-244) maven deploy plugin 3.0.0-M1 breaks RPM deploys
[ https://issues.apache.org/jira/browse/MDEPLOY-244?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] William So updated MDEPLOY-244: --- Attachment: (was: test-maven-deploy.zip) > maven deploy plugin 3.0.0-M1 breaks RPM deploys > --- > > Key: MDEPLOY-244 > URL: https://issues.apache.org/jira/browse/MDEPLOY-244 > Project: Maven Deploy Plugin > Issue Type: Bug > Components: deploy:deploy-file >Affects Versions: 3.0.0-M1 >Reporter: William So >Priority: Critical > Attachments: test-maven-deploy.zip > > > After upgrading to maven deploy plugin to 3.0.0-M1, our Maven Builds that > uploads an RPM artifact broke. All other artifacts, like zips, pom, jar, > etc.. was able to upload without problems. But as soon as the build tried > to upload an RPM the upload threw an 401 Error: > > [Continue Pipeline] [ERROR] Failed to execute goal > org.apache.maven.plugins:maven-deploy-plugin:3.0.0-M1:deploy (default-deploy) > on project company-fancyname-atg-apptype-ibm-qa4: ArtifactDeployerException: > Failed to deploy artifacts: Could not transfer artifact > com.sephops.fancyname:company-fancyname-atg-apptype-ibm-qa4:rpm:ProjectName-20181001.061415-35 > from/to company-snapshot-yum::default > (http://artifactory.com/artifactory/company-snapshot-yum-local): Failed to > transfer file: > http://artifactory.com/artifactory/company-snapshot-yum-local/com/sephops/fancyname/company-fancyname-atg-apptype-ibm-qa4/ProjectName-SNAPSHOT/company-fancyname-atg-apptype-ibm-qa4-ProjectName-20181001.061415-35.rpm. > Return code is: 401, ReasonPhrase: Unauthorized. -> [Help 1] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MDEPLOY-244) maven deploy plugin 3.0.0-M1 breaks RPM deploys
[ https://issues.apache.org/jira/browse/MDEPLOY-244?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16634587#comment-16634587 ] William So commented on MDEPLOY-244: Sample project attached. parent pom file defines our plugins. you can toggle between the two version of maven-deploy from the parent. Child pom is the creation of a dummy RPM file. Command we use to deploy is: mvn clean deploy -P yum-snapshot Settings.xml is an example one that we use. > maven deploy plugin 3.0.0-M1 breaks RPM deploys > --- > > Key: MDEPLOY-244 > URL: https://issues.apache.org/jira/browse/MDEPLOY-244 > Project: Maven Deploy Plugin > Issue Type: Bug > Components: deploy:deploy-file >Affects Versions: 3.0.0-M1 >Reporter: William So >Priority: Critical > Attachments: test-maven-deploy.zip > > > After upgrading to maven deploy plugin to 3.0.0-M1, our Maven Builds that > uploads an RPM artifact broke. All other artifacts, like zips, pom, jar, > etc.. was able to upload without problems. But as soon as the build tried > to upload an RPM the upload threw an 401 Error: > > [Continue Pipeline] [ERROR] Failed to execute goal > org.apache.maven.plugins:maven-deploy-plugin:3.0.0-M1:deploy (default-deploy) > on project company-fancyname-atg-apptype-ibm-qa4: ArtifactDeployerException: > Failed to deploy artifacts: Could not transfer artifact > com.sephops.fancyname:company-fancyname-atg-apptype-ibm-qa4:rpm:ProjectName-20181001.061415-35 > from/to company-snapshot-yum::default > (http://artifactory.com/artifactory/company-snapshot-yum-local): Failed to > transfer file: > http://artifactory.com/artifactory/company-snapshot-yum-local/com/sephops/fancyname/company-fancyname-atg-apptype-ibm-qa4/ProjectName-SNAPSHOT/company-fancyname-atg-apptype-ibm-qa4-ProjectName-20181001.061415-35.rpm. > Return code is: 401, ReasonPhrase: Unauthorized. -> [Help 1] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (MDEPLOY-244) maven deploy plugin 3.0.0-M1 breaks RPM deploys
[ https://issues.apache.org/jira/browse/MDEPLOY-244?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] William So updated MDEPLOY-244: --- Attachment: test-maven-deploy.zip > maven deploy plugin 3.0.0-M1 breaks RPM deploys > --- > > Key: MDEPLOY-244 > URL: https://issues.apache.org/jira/browse/MDEPLOY-244 > Project: Maven Deploy Plugin > Issue Type: Bug > Components: deploy:deploy-file >Affects Versions: 3.0.0-M1 >Reporter: William So >Priority: Critical > Attachments: test-maven-deploy.zip > > > After upgrading to maven deploy plugin to 3.0.0-M1, our Maven Builds that > uploads an RPM artifact broke. All other artifacts, like zips, pom, jar, > etc.. was able to upload without problems. But as soon as the build tried > to upload an RPM the upload threw an 401 Error: > > [Continue Pipeline] [ERROR] Failed to execute goal > org.apache.maven.plugins:maven-deploy-plugin:3.0.0-M1:deploy (default-deploy) > on project company-fancyname-atg-apptype-ibm-qa4: ArtifactDeployerException: > Failed to deploy artifacts: Could not transfer artifact > com.sephops.fancyname:company-fancyname-atg-apptype-ibm-qa4:rpm:ProjectName-20181001.061415-35 > from/to company-snapshot-yum::default > (http://artifactory.com/artifactory/company-snapshot-yum-local): Failed to > transfer file: > http://artifactory.com/artifactory/company-snapshot-yum-local/com/sephops/fancyname/company-fancyname-atg-apptype-ibm-qa4/ProjectName-SNAPSHOT/company-fancyname-atg-apptype-ibm-qa4-ProjectName-20181001.061415-35.rpm. > Return code is: 401, ReasonPhrase: Unauthorized. -> [Help 1] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MJLINK-27) Code incorrectly assumes that two modules won't have the same name
[
https://issues.apache.org/jira/browse/MJLINK-27?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16634583#comment-16634583
]
Gili commented on MJLINK-27:
Karl,
[http://openjdk.java.net/jeps/261] defines an element as a JAR file or a
directory.
{quote}When searching a module path for a module of a particular name, the
module system takes the first definition of a module of that name
{quote}
I want to emphasize this sentence. They wouldn't talk about using the first
match if having multiple modules with the same name always failed.
{quote}if an element of a module path contains definitions of multiple modules
with the same name then resolution fails and the compiler, linker, or virtual
machine will report an error and exit.
{quote}
Let's break this down piece by piece.
* A JAR file cannot contain multiple files with the same path, hence it cannot
contain multiple modules with the same name.
* The only element that may contain multiple modules with the same name is a
directory.
* Hence, if a directory contains multiple modules with the same name then
resolution will fail.
* If multiple JAR files contain a module with the same name, then the first
match on the module path is used.
> Code incorrectly assumes that two modules won't have the same name
> --
>
> Key: MJLINK-27
> URL: https://issues.apache.org/jira/browse/MJLINK-27
> Project: Maven JLink Plugin
> Issue Type: Bug
>Affects Versions: 3.0.0-alpha-2
>Reporter: Gili
>Priority: Major
>
> Karl Heinz Marbaise closed MJLINK-7 referencing [a Stackoverflow
> post|https://stackoverflow.com/questions/46573572/java-9-possible-to-have-2-modules-with-same-name-on-module-path/46574200#46574200]
> to prove that module names must be unique. In fact, this Stackoverflow post
> says the exact opposite. The bottom half of the post states that modules in
> separate directories **are** allowed to have the same name. The bottom of the
> post concludes:
> {quote}That makes it possible to have the same module in different
> directories.
> {quote}
> It doesn't have to be the same module per-se. It is possible for two
> different implementations with the same module name to reside on the module
> path, so long as the modules reside in different directory. This is useful
> for "class shadowing". In my particular case, I ship a no-op implementation
> of a module by default but users can insert a working implementation in front
> of the module path to enable the feature.
> Please reopen this issue or continue its work here.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MJLINK-27) Code incorrectly assumes that two modules won't have the same name
[
https://issues.apache.org/jira/browse/MJLINK-27?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16634564#comment-16634564
]
Karl Heinz Marbaise commented on MJLINK-27:
---
So based on what I've read in the [http://openjdk.java.net/jeps/261] which is
the following (quote from the JEP261):
{quote}When searching a module path for a module of a particular name, the
module system takes the first definition of a module of that name. Version
strings, if present, are ignored; if an element of a module path contains
definitions of multiple modules with the same name then resolution fails and
the compiler, linker, or virtual machine will report an error and exit. It is
the responsibility of build tools and container applications to configure
module paths so as to avoid version conflicts; it is not a goal of the module
system to address the version-selection problem.
{quote}
I would like to emphasize the following:
{quote}if an element of a module path contains definitions of multiple modules
with the same name then resolution fails and the compiler, linker, or virtual
machine will report an error and exit.{quote}
> Code incorrectly assumes that two modules won't have the same name
> --
>
> Key: MJLINK-27
> URL: https://issues.apache.org/jira/browse/MJLINK-27
> Project: Maven JLink Plugin
> Issue Type: Bug
>Affects Versions: 3.0.0-alpha-2
>Reporter: Gili
>Priority: Major
>
> Karl Heinz Marbaise closed MJLINK-7 referencing [a Stackoverflow
> post|https://stackoverflow.com/questions/46573572/java-9-possible-to-have-2-modules-with-same-name-on-module-path/46574200#46574200]
> to prove that module names must be unique. In fact, this Stackoverflow post
> says the exact opposite. The bottom half of the post states that modules in
> separate directories **are** allowed to have the same name. The bottom of the
> post concludes:
> {quote}That makes it possible to have the same module in different
> directories.
> {quote}
> It doesn't have to be the same module per-se. It is possible for two
> different implementations with the same module name to reside on the module
> path, so long as the modules reside in different directory. This is useful
> for "class shadowing". In my particular case, I ship a no-op implementation
> of a module by default but users can insert a working implementation in front
> of the module path to enable the feature.
> Please reopen this issue or continue its work here.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MDEPLOY-244) maven deploy plugin 3.0.0-M1 breaks RPM deploys
[ https://issues.apache.org/jira/browse/MDEPLOY-244?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16634557#comment-16634557 ] Karl Heinz Marbaise commented on MDEPLOY-244: - If you create a sample project would be great...so I can reproduce it... > maven deploy plugin 3.0.0-M1 breaks RPM deploys > --- > > Key: MDEPLOY-244 > URL: https://issues.apache.org/jira/browse/MDEPLOY-244 > Project: Maven Deploy Plugin > Issue Type: Bug > Components: deploy:deploy-file >Affects Versions: 3.0.0-M1 >Reporter: William So >Priority: Critical > > After upgrading to maven deploy plugin to 3.0.0-M1, our Maven Builds that > uploads an RPM artifact broke. All other artifacts, like zips, pom, jar, > etc.. was able to upload without problems. But as soon as the build tried > to upload an RPM the upload threw an 401 Error: > > [Continue Pipeline] [ERROR] Failed to execute goal > org.apache.maven.plugins:maven-deploy-plugin:3.0.0-M1:deploy (default-deploy) > on project company-fancyname-atg-apptype-ibm-qa4: ArtifactDeployerException: > Failed to deploy artifacts: Could not transfer artifact > com.sephops.fancyname:company-fancyname-atg-apptype-ibm-qa4:rpm:ProjectName-20181001.061415-35 > from/to company-snapshot-yum::default > (http://artifactory.com/artifactory/company-snapshot-yum-local): Failed to > transfer file: > http://artifactory.com/artifactory/company-snapshot-yum-local/com/sephops/fancyname/company-fancyname-atg-apptype-ibm-qa4/ProjectName-SNAPSHOT/company-fancyname-atg-apptype-ibm-qa4-ProjectName-20181001.061415-35.rpm. > Return code is: 401, ReasonPhrase: Unauthorized. -> [Help 1] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (MNG-6391) Printout version of last built module in reactor build
[
https://issues.apache.org/jira/browse/MNG-6391?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Heinz Marbaise updated MNG-6391:
-
Fix Version/s: (was: 3.6.x-candidate)
3.6.0
> Printout version of last built module in reactor build
> --
>
> Key: MNG-6391
> URL: https://issues.apache.org/jira/browse/MNG-6391
> Project: Maven
> Issue Type: Improvement
> Components: core
>Affects Versions: 3.5.3
>Reporter: Alexander Griesbaum
>Assignee: Karl Heinz Marbaise
>Priority: Minor
> Fix For: 3.6.0
>
>
> MNG-6352 introduced printout of the version in a reactor build.
> If I build a multi-module project, not just the parent has the version
> printout but also the last built module.
> {code:java}
> [INFO]
>
> [INFO] Reactor Summary:
> [INFO]
> [INFO] parent 4.0.0-SNAPSHOT . SUCCESS [ 3.610 s]
> [INFO] parent-lib SUCCESS [ 0.492 s]
> [INFO] commons ... SUCCESS [ 25.444 s]
> [INFO] loadbalancer-starter .. SUCCESS [ 21.198 s]
> [INFO] proxy-config-starter 4.0.0-SNAPSHOT ... SUCCESS [ 7.496 s]
> [INFO]
>
> [INFO] BUILD SUCCESS
> [INFO]
>
> {code}
> If I remove the "proxy-config-starter" module, "loadbalancer-starter" got the
> version printout.
> Also this is not the order I configured the modules in the parent pom but I
> think this could be something on my side.
> {code:java}
>
> commons
> loadbalancer-starter
> parent-lib
> proxy-config-starter
>
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (MNG-6391) Printout version of last built module in reactor build
[
https://issues.apache.org/jira/browse/MNG-6391?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16634427#comment-16634427
]
Karl Heinz Marbaise edited comment on MNG-6391 at 10/1/18 8:03 PM:
---
The result now looks like this:
{code}
[INFO] --- maven-assembly-plugin:3.1.0:single (assemblies) @ assembly ---
[INFO] Reading assembly descriptor: assembly.xml
[INFO] Reading assembly descriptor: jar-with-prod.xml
[INFO] Reading assembly descriptor: jar-with-dev.xml
[INFO] Building zip:
/Users/kama/ws-git/javaee/assembly/target/assembly-7.8.9-SNAPSHOT-archive.zip
[INFO] Building jar:
/Users/kama/ws-git/javaee/assembly/target/assembly-7.8.9-SNAPSHOT-prod.jar
[INFO] Building jar:
/Users/kama/ws-git/javaee/assembly/target/assembly-7.8.9-SNAPSHOT-dev.jar
[INFO]
[INFO] Reactor Summary for 7.8.9-SNAPSHOT:
[INFO]
[INFO] parent . SUCCESS [ 1.396 s]
[INFO] domain . SUCCESS [ 0.923 s]
[INFO] service-client . SUCCESS [ 0.083 s]
[INFO] webgui . SUCCESS [ 0.478 s]
[INFO] service SUCCESS [ 0.455 s]
[INFO] app SUCCESS [ 0.263 s]
[INFO] appasm . SUCCESS [ 0.207 s]
[INFO] shade .. SUCCESS [ 0.460 s]
[INFO] assembly ... SUCCESS [ 1.577 s]
[INFO]
[INFO] BUILD SUCCESS
[INFO]
[INFO] Total time: 6.356 s
[INFO] Finished at: 2018-10-01T20:13:51+02:00
[INFO]
{code}
And an aggregator will look like this:
{code}
[INFO]
[INFO] --- maven-clean-plugin:2.5:clean (default-clean) @
maven-plugins-aggregator ---
[INFO]
[INFO] Reactor Summary:
[INFO]
[INFO] Apache Maven ACR Plugin 3.0.1-SNAPSHOT . SUCCESS [ 0.708 s]
[INFO] Apache Maven AntRun Plugin 3.0.0-SNAPSHOT .. SUCCESS [ 0.004 s]
[INFO] Apache Maven Changelog Plugin 2.4-SNAPSHOT . SUCCESS [ 0.003 s]
[INFO] Apache Maven Changes Plugin 3.0.0-SNAPSHOT . SUCCESS [ 0.127 s]
[INFO] Apache Maven Clean Plugin 3.0.1-SNAPSHOT ... SUCCESS [ 0.003 s]
[INFO] Apache Maven Compiler Plugin 3.7.1-SNAPSHOT SUCCESS [ 0.020 s]
[INFO] Apache Maven Deploy Plugin 3.0.0-SNAPSHOT .. SUCCESS [ 0.004 s]
[INFO] Apache Maven Documentation Checker Plugin 1.2-SNAPSHOT SUCCESS [ 0.082
s]
[INFO] Apache Maven EAR Plugin 3.0.0-SNAPSHOT . SUCCESS [ 0.003 s]
[INFO] Apache Maven EJB Plugin 3.0.1-SNAPSHOT . SUCCESS [ 0.004 s]
[INFO] Apache Maven Help Plugin 3.0.0-SNAPSHOT SUCCESS [ 0.004 s]
[INFO] Apache Maven Install Plugin 3.0.0-SNAPSHOT . SUCCESS [ 0.012 s]
[INFO] Apache Maven Jarsigner Plugin 1.5-SNAPSHOT . SUCCESS [ 0.004 s]
[INFO] Apache Maven JDeps Plugin 3.1.1-SNAPSHOT ... SUCCESS [ 0.003 s]
[INFO] Apache Maven Linkcheck Plugin 1.3-SNAPSHOT . SUCCESS [ 0.003 s]
[INFO] Apache Maven Patch Plugin 1.3-SNAPSHOT . SUCCESS [ 0.003 s]
[INFO] Apache Maven PDF Plugin 1.4-SNAPSHOT ... SUCCESS [ 0.003 s]
[INFO] Apache Maven RAR Plugin 3.0.0-SNAPSHOT . SUCCESS [ 0.003 s]
[INFO] Apache Maven Repository Plugin 2.5-SNAPSHOT SUCCESS [ 0.002 s]
[INFO] Apache Maven Resources Plugin 3.0.3-SNAPSHOT ... SUCCESS [ 0.003 s]
[INFO] Apache Maven Site Plugin 3.7-SNAPSHOT .. SUCCESS [ 0.004 s]
[INFO] Apache Maven Source Plugin 3.0.2-SNAPSHOT .. SUCCESS [ 0.004 s]
[INFO] Apache Maven Stage Plugin 1.1-SNAPSHOT . SUCCESS [ 0.003 s]
[INFO] Apache Maven Toolchains Plugin 3.0.0-SNAPSHOT .. SUCCESS [ 0.003 s]
[INFO] Apache Maven Verifier Plugin 3.0.0-SNAPSHOT SUCCESS [ 0.065 s]
[INFO] Apache Maven WAR Plugin 3.2.1-SNAPSHOT . SUCCESS [ 0.002 s]
[INFO] Apache Maven DOAP Plugin 1.3-SNAPSHOT .. SUCCESS [ 0.004 s]
[INFO] Apache Maven Invoker Plugin 3.0.2-SNAPSHOT . SUCCESS [ 0.012 s]
[INFO] Apache Maven JAR Plugin 3.0.3-SNAPSHOT . SUCCESS [ 0.002 s]
[INFO] Apache Maven Assembly Plugin 3.1.1-SNAPSHOT SUCCESS [ 0.047 s]
[INFO] Apache Maven Checkstyle Plugin 3.0.0-SNAPSHOT .. SUCCESS [ 0.048 s]
[INFO] Apache Maven Javadoc Plugin 3.0.0-SNAPSHOT . SUCCESS [ 0.002 s]
[INFO] Apache Maven PMD Plugin 3.9-SNAPSHOT ... SUCCESS [ 0.002 s]
[INFO] Apache Maven JLink Plugin 3.0.0-
[jira] [Commented] (MDEPLOY-244) maven deploy plugin 3.0.0-M1 breaks RPM deploys
[ https://issues.apache.org/jira/browse/MDEPLOY-244?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16634547#comment-16634547 ] William So commented on MDEPLOY-244: JDK Version: 1.8.0_181 Maven Version: 3.3.9 Tested on plain Command line and from Jenkins, both caused the issue. RPM built using: RPM Maven Plugin Sample project TBD, i will need to recreate a generic one since I can't share the one i have. > maven deploy plugin 3.0.0-M1 breaks RPM deploys > --- > > Key: MDEPLOY-244 > URL: https://issues.apache.org/jira/browse/MDEPLOY-244 > Project: Maven Deploy Plugin > Issue Type: Bug > Components: deploy:deploy-file >Affects Versions: 3.0.0-M1 >Reporter: William So >Priority: Critical > > After upgrading to maven deploy plugin to 3.0.0-M1, our Maven Builds that > uploads an RPM artifact broke. All other artifacts, like zips, pom, jar, > etc.. was able to upload without problems. But as soon as the build tried > to upload an RPM the upload threw an 401 Error: > > [Continue Pipeline] [ERROR] Failed to execute goal > org.apache.maven.plugins:maven-deploy-plugin:3.0.0-M1:deploy (default-deploy) > on project company-fancyname-atg-apptype-ibm-qa4: ArtifactDeployerException: > Failed to deploy artifacts: Could not transfer artifact > com.sephops.fancyname:company-fancyname-atg-apptype-ibm-qa4:rpm:ProjectName-20181001.061415-35 > from/to company-snapshot-yum::default > (http://artifactory.com/artifactory/company-snapshot-yum-local): Failed to > transfer file: > http://artifactory.com/artifactory/company-snapshot-yum-local/com/sephops/fancyname/company-fancyname-atg-apptype-ibm-qa4/ProjectName-SNAPSHOT/company-fancyname-atg-apptype-ibm-qa4-ProjectName-20181001.061415-35.rpm. > Return code is: 401, ReasonPhrase: Unauthorized. -> [Help 1] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MDEPLOY-244) maven deploy plugin 3.0.0-M1 breaks RPM deploys
[ https://issues.apache.org/jira/browse/MDEPLOY-244?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16634453#comment-16634453 ] Karl Heinz Marbaise commented on MDEPLOY-244: - Would you please add an example project to this issue? which can reproduce the issue? Please also add the full command line call and all relevant informations like JDK version, Maven version? Calling via plain command line? Or are you calling from within Jenkins? BTW: How is the RPM being built? > maven deploy plugin 3.0.0-M1 breaks RPM deploys > --- > > Key: MDEPLOY-244 > URL: https://issues.apache.org/jira/browse/MDEPLOY-244 > Project: Maven Deploy Plugin > Issue Type: Bug > Components: deploy:deploy-file >Affects Versions: 3.0.0-M1 >Reporter: William So >Priority: Critical > > After upgrading to maven deploy plugin to 3.0.0-M1, our Maven Builds that > uploads an RPM artifact broke. All other artifacts, like zips, pom, jar, > etc.. was able to upload without problems. But as soon as the build tried > to upload an RPM the upload threw an 401 Error: > > [Continue Pipeline] [ERROR] Failed to execute goal > org.apache.maven.plugins:maven-deploy-plugin:3.0.0-M1:deploy (default-deploy) > on project company-fancyname-atg-apptype-ibm-qa4: ArtifactDeployerException: > Failed to deploy artifacts: Could not transfer artifact > com.sephops.fancyname:company-fancyname-atg-apptype-ibm-qa4:rpm:ProjectName-20181001.061415-35 > from/to company-snapshot-yum::default > (http://artifactory.com/artifactory/company-snapshot-yum-local): Failed to > transfer file: > http://artifactory.com/artifactory/company-snapshot-yum-local/com/sephops/fancyname/company-fancyname-atg-apptype-ibm-qa4/ProjectName-SNAPSHOT/company-fancyname-atg-apptype-ibm-qa4-ProjectName-20181001.061415-35.rpm. > Return code is: 401, ReasonPhrase: Unauthorized. -> [Help 1] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MINSTALL-151) Projects without primary artifacts, but with attachment artifacts fail install
[
https://issues.apache.org/jira/browse/MINSTALL-151?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16634448#comment-16634448
]
Peter Huffer commented on MINSTALL-151:
---
Thanks for the quick responses. I am okay with closing this ticket as won't do
and defining the primary artifacts in our plugin's configuration, as well as
locking down our plugin version.
> Projects without primary artifacts, but with attachment artifacts fail install
> --
>
> Key: MINSTALL-151
> URL: https://issues.apache.org/jira/browse/MINSTALL-151
> Project: Maven Install Plugin
> Issue Type: Bug
>Affects Versions: 3.0.0-M1
>Reporter: Peter Huffer
>Priority: Major
> Attachments: minstall-151.zip
>
>
> I have a module which has a packaging of {{feature}} from the
> {{karaf-maven-plugin}}. When running the {{mvn install}} command, the
> following error occurs:
> {code:java}
> Failed to execute goal
> org.apache.maven.plugins:maven-install-plugin:3.0.0-M1:install
> (default-install) on project : NoFileAssignedException: The
> packaging plugin for this project did not assign a main file to the project
> but it has attachments. Change packaging to 'pom'. -> [Help 1]
> {code}
> Reverting back to version {{2.5.2}} made the {{mvn install}} command succeed.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (MINSTALL-151) Projects without primary artifacts, but with attachment artifacts fail install
[
https://issues.apache.org/jira/browse/MINSTALL-151?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16634446#comment-16634446
]
Guillermo Fernandes edited comment on MINSTALL-151 at 10/1/18 6:26 PM:
---
Ok, I understood. Will change the plugin on our side to set the main artifact
file. Thank you!
was (Author: gsfernandes):
Ok, I understood. Will change the plugin on our side. Thank you!
> Projects without primary artifacts, but with attachment artifacts fail install
> --
>
> Key: MINSTALL-151
> URL: https://issues.apache.org/jira/browse/MINSTALL-151
> Project: Maven Install Plugin
> Issue Type: Bug
>Affects Versions: 3.0.0-M1
>Reporter: Peter Huffer
>Priority: Major
> Attachments: minstall-151.zip
>
>
> I have a module which has a packaging of {{feature}} from the
> {{karaf-maven-plugin}}. When running the {{mvn install}} command, the
> following error occurs:
> {code:java}
> Failed to execute goal
> org.apache.maven.plugins:maven-install-plugin:3.0.0-M1:install
> (default-install) on project : NoFileAssignedException: The
> packaging plugin for this project did not assign a main file to the project
> but it has attachments. Change packaging to 'pom'. -> [Help 1]
> {code}
> Reverting back to version {{2.5.2}} made the {{mvn install}} command succeed.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MINSTALL-151) Projects without primary artifacts, but with attachment artifacts fail install
[
https://issues.apache.org/jira/browse/MINSTALL-151?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16634446#comment-16634446
]
Guillermo Fernandes commented on MINSTALL-151:
--
Ok, I understood. Will change the plugin on our side. Thank you!
> Projects without primary artifacts, but with attachment artifacts fail install
> --
>
> Key: MINSTALL-151
> URL: https://issues.apache.org/jira/browse/MINSTALL-151
> Project: Maven Install Plugin
> Issue Type: Bug
>Affects Versions: 3.0.0-M1
>Reporter: Peter Huffer
>Priority: Major
> Attachments: minstall-151.zip
>
>
> I have a module which has a packaging of {{feature}} from the
> {{karaf-maven-plugin}}. When running the {{mvn install}} command, the
> following error occurs:
> {code:java}
> Failed to execute goal
> org.apache.maven.plugins:maven-install-plugin:3.0.0-M1:install
> (default-install) on project : NoFileAssignedException: The
> packaging plugin for this project did not assign a main file to the project
> but it has attachments. Change packaging to 'pom'. -> [Help 1]
> {code}
> Reverting back to version {{2.5.2}} made the {{mvn install}} command succeed.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (MSHADE-300) Allow retention of module-info class by property
[ https://issues.apache.org/jira/browse/MSHADE-300?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Scholte closed MSHADE-300. - Resolution: Won't Fix Assignee: Robert Scholte Okay, so let's close this as "Won't fix" for the mentioned reason. > Allow retention of module-info class by property > > > Key: MSHADE-300 > URL: https://issues.apache.org/jira/browse/MSHADE-300 > Project: Maven Shade Plugin > Issue Type: New Feature >Affects Versions: 3.2.0 >Reporter: Rafael Winterhalter >Assignee: Robert Scholte >Priority: Major > Attachments: MSHADE300.patch > > > Currently, the shader removes any module-info.class file that is found during > the shading process. This makes perfect sense as the integrity of the > module-info class file breaks as a result of the relocation and any potential > renaming. > Many library vendors that use the shade plugin do so to import minor > dependencies into their namespace. In my case, I depend on ASM and use > another Maven plugin to generate a module-info.class file which does not > require ASM and would work correctly. Unfortunately, this working > module-info.class file is filtered out by the shade plugin. > To overcome this limitation, I suggest adding a 'retainModuleInfo' property > that allows for the retention of the module-info.class file that is extracted > from the main artifact. I understand that this might be an edge case but > given the module system only being partially adopted it would help some > low-level library vendors like myself a lot if this feature would be included > in the plugin. > I have attached a patch file that implements this feature and it only > requires minimal changes in the plugin. I have also validated that this > feature works for my project (Byte Buddy). > If you could merge and release this extension, I would hope to include module > descriptors in Byte Buddy in the upcoming Java 11-compatible release. Thanks > a lot! -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MSHADE-300) Allow retention of module-info class by property
[ https://issues.apache.org/jira/browse/MSHADE-300?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16634432#comment-16634432 ] Rafael Winterhalter commented on MSHADE-300: In the mean time, I think that I have found a cleaner way to achieve this. Instead of adding the module-info.class file to the target folder, I inject it into the shaded jar directly. I had another use case where I produced both a "normal" and a shaded jar where I required two module descriptors and this is not possible using the approach that I suggested here. Instead, I published a plugin to do so: [https://github.com/raphw/modulemaker-maven-plugin] I think this is the better approach compared to merging this into shade after trying out both approaches. > Allow retention of module-info class by property > > > Key: MSHADE-300 > URL: https://issues.apache.org/jira/browse/MSHADE-300 > Project: Maven Shade Plugin > Issue Type: New Feature >Affects Versions: 3.2.0 >Reporter: Rafael Winterhalter >Priority: Major > Attachments: MSHADE300.patch > > > Currently, the shader removes any module-info.class file that is found during > the shading process. This makes perfect sense as the integrity of the > module-info class file breaks as a result of the relocation and any potential > renaming. > Many library vendors that use the shade plugin do so to import minor > dependencies into their namespace. In my case, I depend on ASM and use > another Maven plugin to generate a module-info.class file which does not > require ASM and would work correctly. Unfortunately, this working > module-info.class file is filtered out by the shade plugin. > To overcome this limitation, I suggest adding a 'retainModuleInfo' property > that allows for the retention of the module-info.class file that is extracted > from the main artifact. I understand that this might be an edge case but > given the module system only being partially adopted it would help some > low-level library vendors like myself a lot if this feature would be included > in the plugin. > I have attached a patch file that implements this feature and it only > requires minimal changes in the plugin. I have also validated that this > feature works for my project (Byte Buddy). > If you could merge and release this extension, I would hope to include module > descriptors in Byte Buddy in the upcoming Java 11-compatible release. Thanks > a lot! -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (MDEPLOY-244) maven deploy plugin 3.0.0-M1 breaks RPM deploys
William So created MDEPLOY-244: -- Summary: maven deploy plugin 3.0.0-M1 breaks RPM deploys Key: MDEPLOY-244 URL: https://issues.apache.org/jira/browse/MDEPLOY-244 Project: Maven Deploy Plugin Issue Type: Bug Components: deploy:deploy-file Affects Versions: 3.0.0-M1 Reporter: William So After upgrading to maven deploy plugin to 3.0.0-M1, our Maven Builds that uploads an RPM artifact broke. All other artifacts, like zips, pom, jar, etc.. was able to upload without problems. But as soon as the build tried to upload an RPM the upload threw an 401 Error: [Continue Pipeline] [ERROR] Failed to execute goal org.apache.maven.plugins:maven-deploy-plugin:3.0.0-M1:deploy (default-deploy) on project company-fancyname-atg-apptype-ibm-qa4: ArtifactDeployerException: Failed to deploy artifacts: Could not transfer artifact com.sephops.fancyname:company-fancyname-atg-apptype-ibm-qa4:rpm:ProjectName-20181001.061415-35 from/to company-snapshot-yum::default (http://artifactory.com/artifactory/company-snapshot-yum-local): Failed to transfer file: http://artifactory.com/artifactory/company-snapshot-yum-local/com/sephops/fancyname/company-fancyname-atg-apptype-ibm-qa4/ProjectName-SNAPSHOT/company-fancyname-atg-apptype-ibm-qa4-ProjectName-20181001.061415-35.rpm. Return code is: 401, ReasonPhrase: Unauthorized. -> [Help 1] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MNG-6391) Printout version of last built module in reactor build
[
https://issues.apache.org/jira/browse/MNG-6391?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16634427#comment-16634427
]
Karl Heinz Marbaise commented on MNG-6391:
--
The result now looks like this:
{code}
[INFO] --- maven-assembly-plugin:3.1.0:single (assemblies) @ assembly ---
[INFO] Reading assembly descriptor: assembly.xml
[INFO] Reading assembly descriptor: jar-with-prod.xml
[INFO] Reading assembly descriptor: jar-with-dev.xml
[INFO] Building zip:
/Users/kama/ws-git/javaee/assembly/target/assembly-7.8.9-SNAPSHOT-archive.zip
[INFO] Building jar:
/Users/kama/ws-git/javaee/assembly/target/assembly-7.8.9-SNAPSHOT-prod.jar
[INFO] Building jar:
/Users/kama/ws-git/javaee/assembly/target/assembly-7.8.9-SNAPSHOT-dev.jar
[INFO]
[INFO] Reactor Summary (7.8.9-SNAPSHOT):
[INFO]
[INFO] parent . SUCCESS [ 1.396 s]
[INFO] domain . SUCCESS [ 0.923 s]
[INFO] service-client . SUCCESS [ 0.083 s]
[INFO] webgui . SUCCESS [ 0.478 s]
[INFO] service SUCCESS [ 0.455 s]
[INFO] app SUCCESS [ 0.263 s]
[INFO] appasm . SUCCESS [ 0.207 s]
[INFO] shade .. SUCCESS [ 0.460 s]
[INFO] assembly ... SUCCESS [ 1.577 s]
[INFO]
[INFO] BUILD SUCCESS
[INFO]
[INFO] Total time: 6.356 s
[INFO] Finished at: 2018-10-01T20:13:51+02:00
[INFO]
{code}
And an aggregator will look like this:
{code}
[INFO]
[INFO] --- maven-clean-plugin:2.5:clean (default-clean) @
maven-plugins-aggregator ---
[INFO]
[INFO] Reactor Summary:
[INFO]
[INFO] Apache Maven ACR Plugin 3.0.1-SNAPSHOT . SUCCESS [ 0.708 s]
[INFO] Apache Maven AntRun Plugin 3.0.0-SNAPSHOT .. SUCCESS [ 0.004 s]
[INFO] Apache Maven Changelog Plugin 2.4-SNAPSHOT . SUCCESS [ 0.003 s]
[INFO] Apache Maven Changes Plugin 3.0.0-SNAPSHOT . SUCCESS [ 0.127 s]
[INFO] Apache Maven Clean Plugin 3.0.1-SNAPSHOT ... SUCCESS [ 0.003 s]
[INFO] Apache Maven Compiler Plugin 3.7.1-SNAPSHOT SUCCESS [ 0.020 s]
[INFO] Apache Maven Deploy Plugin 3.0.0-SNAPSHOT .. SUCCESS [ 0.004 s]
[INFO] Apache Maven Documentation Checker Plugin 1.2-SNAPSHOT SUCCESS [ 0.082
s]
[INFO] Apache Maven EAR Plugin 3.0.0-SNAPSHOT . SUCCESS [ 0.003 s]
[INFO] Apache Maven EJB Plugin 3.0.1-SNAPSHOT . SUCCESS [ 0.004 s]
[INFO] Apache Maven Help Plugin 3.0.0-SNAPSHOT SUCCESS [ 0.004 s]
[INFO] Apache Maven Install Plugin 3.0.0-SNAPSHOT . SUCCESS [ 0.012 s]
[INFO] Apache Maven Jarsigner Plugin 1.5-SNAPSHOT . SUCCESS [ 0.004 s]
[INFO] Apache Maven JDeps Plugin 3.1.1-SNAPSHOT ... SUCCESS [ 0.003 s]
[INFO] Apache Maven Linkcheck Plugin 1.3-SNAPSHOT . SUCCESS [ 0.003 s]
[INFO] Apache Maven Patch Plugin 1.3-SNAPSHOT . SUCCESS [ 0.003 s]
[INFO] Apache Maven PDF Plugin 1.4-SNAPSHOT ... SUCCESS [ 0.003 s]
[INFO] Apache Maven RAR Plugin 3.0.0-SNAPSHOT . SUCCESS [ 0.003 s]
[INFO] Apache Maven Repository Plugin 2.5-SNAPSHOT SUCCESS [ 0.002 s]
[INFO] Apache Maven Resources Plugin 3.0.3-SNAPSHOT ... SUCCESS [ 0.003 s]
[INFO] Apache Maven Site Plugin 3.7-SNAPSHOT .. SUCCESS [ 0.004 s]
[INFO] Apache Maven Source Plugin 3.0.2-SNAPSHOT .. SUCCESS [ 0.004 s]
[INFO] Apache Maven Stage Plugin 1.1-SNAPSHOT . SUCCESS [ 0.003 s]
[INFO] Apache Maven Toolchains Plugin 3.0.0-SNAPSHOT .. SUCCESS [ 0.003 s]
[INFO] Apache Maven Verifier Plugin 3.0.0-SNAPSHOT SUCCESS [ 0.065 s]
[INFO] Apache Maven WAR Plugin 3.2.1-SNAPSHOT . SUCCESS [ 0.002 s]
[INFO] Apache Maven DOAP Plugin 1.3-SNAPSHOT .. SUCCESS [ 0.004 s]
[INFO] Apache Maven Invoker Plugin 3.0.2-SNAPSHOT . SUCCESS [ 0.012 s]
[INFO] Apache Maven JAR Plugin 3.0.3-SNAPSHOT . SUCCESS [ 0.002 s]
[INFO] Apache Maven Assembly Plugin 3.1.1-SNAPSHOT SUCCESS [ 0.047 s]
[INFO] Apache Maven Checkstyle Plugin 3.0.0-SNAPSHOT .. SUCCESS [ 0.048 s]
[INFO] Apache Maven Javadoc Plugin 3.0.0-SNAPSHOT . SUCCESS [ 0.002 s]
[INFO] Apache Maven PMD Plugin 3.9-SNAPSHOT ... SUCCESS [ 0.002 s]
[INFO] Apache Maven JLink Plugin 3.0.0-alpha-2-SNAPSHOT ... SUCCESS [ 0.007 s]
[INFO] Apa
[jira] [Commented] (MNG-6391) Printout version of last built module in reactor build
[
https://issues.apache.org/jira/browse/MNG-6391?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16634406#comment-16634406
]
Hudson commented on MNG-6391:
-
Build succeeded in Jenkins: Maven TLP » maven » MNG-6391 #23
See https://builds.apache.org/job/maven-box/job/maven/job/MNG-6391/23/
> Printout version of last built module in reactor build
> --
>
> Key: MNG-6391
> URL: https://issues.apache.org/jira/browse/MNG-6391
> Project: Maven
> Issue Type: Improvement
> Components: core
>Affects Versions: 3.5.3
>Reporter: Alexander Griesbaum
>Assignee: Karl Heinz Marbaise
>Priority: Minor
> Fix For: 3.6.x-candidate
>
>
> MNG-6352 introduced printout of the version in a reactor build.
> If I build a multi-module project, not just the parent has the version
> printout but also the last built module.
> {code:java}
> [INFO]
>
> [INFO] Reactor Summary:
> [INFO]
> [INFO] parent 4.0.0-SNAPSHOT . SUCCESS [ 3.610 s]
> [INFO] parent-lib SUCCESS [ 0.492 s]
> [INFO] commons ... SUCCESS [ 25.444 s]
> [INFO] loadbalancer-starter .. SUCCESS [ 21.198 s]
> [INFO] proxy-config-starter 4.0.0-SNAPSHOT ... SUCCESS [ 7.496 s]
> [INFO]
>
> [INFO] BUILD SUCCESS
> [INFO]
>
> {code}
> If I remove the "proxy-config-starter" module, "loadbalancer-starter" got the
> version printout.
> Also this is not the order I configured the modules in the parent pom but I
> think this could be something on my side.
> {code:java}
>
> commons
> loadbalancer-starter
> parent-lib
> proxy-config-starter
>
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MINSTALL-151) Projects without primary artifacts, but with attachment artifacts fail install
[
https://issues.apache.org/jira/browse/MINSTALL-151?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16634403#comment-16634403
]
Karl Heinz Marbaise commented on MINSTALL-151:
--
Some more hints on the current behaviour: see MINSTALL-118
> Projects without primary artifacts, but with attachment artifacts fail install
> --
>
> Key: MINSTALL-151
> URL: https://issues.apache.org/jira/browse/MINSTALL-151
> Project: Maven Install Plugin
> Issue Type: Bug
>Affects Versions: 3.0.0-M1
>Reporter: Peter Huffer
>Priority: Major
> Attachments: minstall-151.zip
>
>
> I have a module which has a packaging of {{feature}} from the
> {{karaf-maven-plugin}}. When running the {{mvn install}} command, the
> following error occurs:
> {code:java}
> Failed to execute goal
> org.apache.maven.plugins:maven-install-plugin:3.0.0-M1:install
> (default-install) on project : NoFileAssignedException: The
> packaging plugin for this project did not assign a main file to the project
> but it has attachments. Change packaging to 'pom'. -> [Help 1]
> {code}
> Reverting back to version {{2.5.2}} made the {{mvn install}} command succeed.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MJAR-238) Allow setting of module main class
[
https://issues.apache.org/jira/browse/MJAR-238?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16634375#comment-16634375
]
ASF GitHub Bot commented on MJAR-238:
-
plamentotev commented on a change in pull request #2: [MJAR-238] Allow setting
of module main class
URL: https://github.com/apache/maven-jar-plugin/pull/2#discussion_r221694289
##
File path: src/main/java/org/apache/maven/plugins/jar/AbstractJarMojo.java
##
@@ -76,7 +76,7 @@
/**
* The Jar archiver.
*/
-@Component( role = Archiver.class, hint = "jar" )
+@Component( role = Archiver.class, hint = "mjar" )
Review comment:
The thing is how to know if the JAR file is going to contain
`module-info.class` or not? The inclusion of the content is delegated to Maven
Archiver:
```java
archiver.getArchiver().addDirectory( contentDirectory, getIncludes(),
getExcludes() );
```
And in general the idea of `ModularJarArchiver` is to be safe to be used for
"regular" JAR files as well. You can think for it as an `JarArchiver` that can
handle modules if needed. The old `JarArchiver` could be used where you want to
treat JAR strictly as archive - such as source JAR or if you explicitly want
the module descriptor to be left unmodified (but is there such use case for the
JAR plugin?)
That being said I agree that would be better if we know in advance if we
need `ModularJarArchiver` or `JarArchiver` based on the existance of module
descriptor (at very least will make the code intention more explicit and easy
to read), so if there is some acceptable way to know that I'll modify the PR.
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
> Allow setting of module main class
> --
>
> Key: MJAR-238
> URL: https://issues.apache.org/jira/browse/MJAR-238
> Project: Maven JAR Plugin
> Issue Type: Improvement
> Environment: Java9 build 9+176, MacOS
>Reporter: Machiel Groeneveld
>Assignee: Robert Scholte
>Priority: Minor
>
> When a Java9 module is created using the maven-jar plugin, setting the
> manifest/mainclass does not set the module main class. Therefore the module
> is not executable without specifying the main class. Executing the module
> using java -m domain.app gives the following error:
> _module jigsaw.app does not have a MainClass attribute_
> According to the module specification a module (jar) can have a main class
> set. If I understand correctly it's inside the module-info.class as a
> property called ModuleMainClass
> When using the JDK9 jar command it will update the jar and the
> module-info.class.
> {noformat}
> -e, --main-class=CLASSNAME The application entry point for stand-alone
> applications bundled into a modular, or
> executable,
> jar archive
> {noformat}
> I guess it would make sense to have this as a separate configuration item
> since the mainclass entry in the manifest file is not needed in 'module mode'
> and vice versa.
> If this is a duplicate of another issue, please close this one, I couldn't
> find any existing issues related to this.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] plamentotev commented on a change in pull request #2: [MJAR-238] Allow setting of module main class
plamentotev commented on a change in pull request #2: [MJAR-238] Allow setting of module main class URL: https://github.com/apache/maven-jar-plugin/pull/2#discussion_r221694289 ## File path: src/main/java/org/apache/maven/plugins/jar/AbstractJarMojo.java ## @@ -76,7 +76,7 @@ /** * The Jar archiver. */ -@Component( role = Archiver.class, hint = "jar" ) +@Component( role = Archiver.class, hint = "mjar" ) Review comment: The thing is how to know if the JAR file is going to contain `module-info.class` or not? The inclusion of the content is delegated to Maven Archiver: ```java archiver.getArchiver().addDirectory( contentDirectory, getIncludes(), getExcludes() ); ``` And in general the idea of `ModularJarArchiver` is to be safe to be used for "regular" JAR files as well. You can think for it as an `JarArchiver` that can handle modules if needed. The old `JarArchiver` could be used where you want to treat JAR strictly as archive - such as source JAR or if you explicitly want the module descriptor to be left unmodified (but is there such use case for the JAR plugin?) That being said I agree that would be better if we know in advance if we need `ModularJarArchiver` or `JarArchiver` based on the existance of module descriptor (at very least will make the code intention more explicit and easy to read), so if there is some acceptable way to know that I'll modify the PR. 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] (MJAR-238) Allow setting of module main class
[
https://issues.apache.org/jira/browse/MJAR-238?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16634374#comment-16634374
]
ASF GitHub Bot commented on MJAR-238:
-
plamentotev commented on a change in pull request #2: [MJAR-238] Allow setting
of module main class
URL: https://github.com/apache/maven-jar-plugin/pull/2#discussion_r221694289
##
File path: src/main/java/org/apache/maven/plugins/jar/AbstractJarMojo.java
##
@@ -76,7 +76,7 @@
/**
* The Jar archiver.
*/
-@Component( role = Archiver.class, hint = "jar" )
+@Component( role = Archiver.class, hint = "mjar" )
Review comment:
The thing is how to know if the JAR file is going to contain
`module-info.class` or not? The inclusion of the content is delegated to Maven
Archiver:
```java
archiver.getArchiver().addDirectory( contentDirectory, getIncludes(),
getExcludes() );
```
And in general the idea of `ModularJarArchiver` is to be safe to be used for
"regular" JAR files as well. You can think for it as an `JarArchiver` that can
handle modules if needed. The old `JarArchiver` could be used where you want to
treat JAR strictly as archive - such as source JAR or if you explicitly want
the module descriptor to be left unmodified (but is there such use case for the
JAR plugin?)
That being said I agree that would be better if we know in advance if we
need `ModularJarArchiver` or `JarArchiver` based on the existance of module
descriptor (at very least will make the code intention more explicit and easy
to read), so if there some acceptable way to know that I'll modify the PR.
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
> Allow setting of module main class
> --
>
> Key: MJAR-238
> URL: https://issues.apache.org/jira/browse/MJAR-238
> Project: Maven JAR Plugin
> Issue Type: Improvement
> Environment: Java9 build 9+176, MacOS
>Reporter: Machiel Groeneveld
>Assignee: Robert Scholte
>Priority: Minor
>
> When a Java9 module is created using the maven-jar plugin, setting the
> manifest/mainclass does not set the module main class. Therefore the module
> is not executable without specifying the main class. Executing the module
> using java -m domain.app gives the following error:
> _module jigsaw.app does not have a MainClass attribute_
> According to the module specification a module (jar) can have a main class
> set. If I understand correctly it's inside the module-info.class as a
> property called ModuleMainClass
> When using the JDK9 jar command it will update the jar and the
> module-info.class.
> {noformat}
> -e, --main-class=CLASSNAME The application entry point for stand-alone
> applications bundled into a modular, or
> executable,
> jar archive
> {noformat}
> I guess it would make sense to have this as a separate configuration item
> since the mainclass entry in the manifest file is not needed in 'module mode'
> and vice versa.
> If this is a duplicate of another issue, please close this one, I couldn't
> find any existing issues related to this.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] plamentotev commented on a change in pull request #2: [MJAR-238] Allow setting of module main class
plamentotev commented on a change in pull request #2: [MJAR-238] Allow setting of module main class URL: https://github.com/apache/maven-jar-plugin/pull/2#discussion_r221694289 ## File path: src/main/java/org/apache/maven/plugins/jar/AbstractJarMojo.java ## @@ -76,7 +76,7 @@ /** * The Jar archiver. */ -@Component( role = Archiver.class, hint = "jar" ) +@Component( role = Archiver.class, hint = "mjar" ) Review comment: The thing is how to know if the JAR file is going to contain `module-info.class` or not? The inclusion of the content is delegated to Maven Archiver: ```java archiver.getArchiver().addDirectory( contentDirectory, getIncludes(), getExcludes() ); ``` And in general the idea of `ModularJarArchiver` is to be safe to be used for "regular" JAR files as well. You can think for it as an `JarArchiver` that can handle modules if needed. The old `JarArchiver` could be used where you want to treat JAR strictly as archive - such as source JAR or if you explicitly want the module descriptor to be left unmodified (but is there such use case for the JAR plugin?) That being said I agree that would be better if we know in advance if we need `ModularJarArchiver` or `JarArchiver` based on the existance of module descriptor (at very least will make the code intention more explicit and easy to read), so if there some acceptable way to know that I'll modify the PR. 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] (MINSTALL-151) Projects without primary artifacts, but with attachment artifacts fail install
[
https://issues.apache.org/jira/browse/MINSTALL-151?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16634369#comment-16634369
]
Karl Heinz Marbaise commented on MINSTALL-151:
--
[~gsfernandes] You are right with ...it was working before for a long
time...but that is a major version release which can break and will break
things otherwise we would never be able to evolve things...
The point with 3.0.0-M1 is: It is released (now in central) and can't go back
or being changed or being removed only with 3.0.0-M2 etc. or 3.0.0 I can do
changes in it...
What I can do is: Release a version 3.0.0-M2 which will produce a WARNING with
a Hint becoming an error with final 3.0.0 release? But usually WARNINGs are
ignored...
Furthermore it shows how many people do not correctly pin the version of their
plugins...
Apart from that I fear that many custom plugins are doing this wrong...
> Projects without primary artifacts, but with attachment artifacts fail install
> --
>
> Key: MINSTALL-151
> URL: https://issues.apache.org/jira/browse/MINSTALL-151
> Project: Maven Install Plugin
> Issue Type: Bug
>Affects Versions: 3.0.0-M1
>Reporter: Peter Huffer
>Priority: Major
> Attachments: minstall-151.zip
>
>
> I have a module which has a packaging of {{feature}} from the
> {{karaf-maven-plugin}}. When running the {{mvn install}} command, the
> following error occurs:
> {code:java}
> Failed to execute goal
> org.apache.maven.plugins:maven-install-plugin:3.0.0-M1:install
> (default-install) on project : NoFileAssignedException: The
> packaging plugin for this project did not assign a main file to the project
> but it has attachments. Change packaging to 'pom'. -> [Help 1]
> {code}
> Reverting back to version {{2.5.2}} made the {{mvn install}} command succeed.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MINSTALL-151) Projects without primary artifacts, but with attachment artifacts fail install
[
https://issues.apache.org/jira/browse/MINSTALL-151?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16634357#comment-16634357
]
Guillermo Fernandes commented on MINSTALL-151:
--
I would say that makes sense to break if the plugin defines a packaging and it
not setting the main artifact but... it was working before for a long time...
So, I would either prefer a warning message instead of this exception and let
the whole community know that this will be changed from a warning message to an
error in 3.0.0 version.
The thing here is that suddenly we have seen this issue in customer
environments as well in our environments when installing artifacts that use our
maven plugin (which defines the custom packaging and is not setting the main
artifact) as we were not setting a fixed version of maven-install-plugin as
soon as 3.0.0-M1 was deployed they started to use this version and got this
issue.
Would it make sense as even this is a milestone version to log a warning and
once 3.0.0 is released just throw the error?
I'm wondering how many custom maven plugins may have this issue too.
> Projects without primary artifacts, but with attachment artifacts fail install
> --
>
> Key: MINSTALL-151
> URL: https://issues.apache.org/jira/browse/MINSTALL-151
> Project: Maven Install Plugin
> Issue Type: Bug
>Affects Versions: 3.0.0-M1
>Reporter: Peter Huffer
>Priority: Major
> Attachments: minstall-151.zip
>
>
> I have a module which has a packaging of {{feature}} from the
> {{karaf-maven-plugin}}. When running the {{mvn install}} command, the
> following error occurs:
> {code:java}
> Failed to execute goal
> org.apache.maven.plugins:maven-install-plugin:3.0.0-M1:install
> (default-install) on project : NoFileAssignedException: The
> packaging plugin for this project did not assign a main file to the project
> but it has attachments. Change packaging to 'pom'. -> [Help 1]
> {code}
> Reverting back to version {{2.5.2}} made the {{mvn install}} command succeed.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (MSHARED-760) Do not fail if no main artifact has been set, but attachments existing
Karl Heinz Marbaise created MSHARED-760: --- Summary: Do not fail if no main artifact has been set, but attachments existing Key: MSHARED-760 URL: https://issues.apache.org/jira/browse/MSHARED-760 Project: Maven Shared Components Issue Type: New Feature Components: maven-artifact-transfer Affects Versions: maven-artifact-transfer-0.11.0 Reporter: Karl Heinz Marbaise Assignee: Karl Heinz Marbaise Fix For: maven-artifact-transfer-0.11.0 We should not fail if no main artifact has been set but attachments do exist. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MINSTALL-151) Projects without primary artifacts, but with attachment artifacts fail install
[
https://issues.apache.org/jira/browse/MINSTALL-151?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16634343#comment-16634343
]
Karl Heinz Marbaise commented on MINSTALL-151:
--
[~gsfernandes] You have given the answer yourself.
{quote}I know that would make sense to fail on this scenarios..{quote}
I would say a plugin (own packaging) which does not correctly set the main
artifact is doing something wrong...
> Projects without primary artifacts, but with attachment artifacts fail install
> --
>
> Key: MINSTALL-151
> URL: https://issues.apache.org/jira/browse/MINSTALL-151
> Project: Maven Install Plugin
> Issue Type: Bug
>Affects Versions: 3.0.0-M1
>Reporter: Peter Huffer
>Priority: Major
> Attachments: minstall-151.zip
>
>
> I have a module which has a packaging of {{feature}} from the
> {{karaf-maven-plugin}}. When running the {{mvn install}} command, the
> following error occurs:
> {code:java}
> Failed to execute goal
> org.apache.maven.plugins:maven-install-plugin:3.0.0-M1:install
> (default-install) on project : NoFileAssignedException: The
> packaging plugin for this project did not assign a main file to the project
> but it has attachments. Change packaging to 'pom'. -> [Help 1]
> {code}
> Reverting back to version {{2.5.2}} made the {{mvn install}} command succeed.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (MINSTALL-151) Projects without primary artifacts, but with attachment artifacts fail install
[
https://issues.apache.org/jira/browse/MINSTALL-151?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16634341#comment-16634341
]
Peter Huffer edited comment on MINSTALL-151 at 10/1/18 5:13 PM:
[~khmarbaise] I think the important part is getting the custom packaging and
having attachments without a primary artifact in the project based on
[~gsfernandes]' comment.
was (Author: peter.huffer):
[~khmarbaise] I think the important part is getting the custom packaging and
having attachments in the project based on [~gsfernandes]' comment.
> Projects without primary artifacts, but with attachment artifacts fail install
> --
>
> Key: MINSTALL-151
> URL: https://issues.apache.org/jira/browse/MINSTALL-151
> Project: Maven Install Plugin
> Issue Type: Bug
>Affects Versions: 3.0.0-M1
>Reporter: Peter Huffer
>Priority: Major
> Attachments: minstall-151.zip
>
>
> I have a module which has a packaging of {{feature}} from the
> {{karaf-maven-plugin}}. When running the {{mvn install}} command, the
> following error occurs:
> {code:java}
> Failed to execute goal
> org.apache.maven.plugins:maven-install-plugin:3.0.0-M1:install
> (default-install) on project : NoFileAssignedException: The
> packaging plugin for this project did not assign a main file to the project
> but it has attachments. Change packaging to 'pom'. -> [Help 1]
> {code}
> Reverting back to version {{2.5.2}} made the {{mvn install}} command succeed.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MINSTALL-151) Projects without primary artifacts, but with attachment artifacts fail install
[
https://issues.apache.org/jira/browse/MINSTALL-151?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16634341#comment-16634341
]
Peter Huffer commented on MINSTALL-151:
---
[~khmarbaise] I think the important part is getting the custom packaging and
having attachments in the project based on [~gsfernandes]' comment.
> Projects without primary artifacts, but with attachment artifacts fail install
> --
>
> Key: MINSTALL-151
> URL: https://issues.apache.org/jira/browse/MINSTALL-151
> Project: Maven Install Plugin
> Issue Type: Bug
>Affects Versions: 3.0.0-M1
>Reporter: Peter Huffer
>Priority: Major
> Attachments: minstall-151.zip
>
>
> I have a module which has a packaging of {{feature}} from the
> {{karaf-maven-plugin}}. When running the {{mvn install}} command, the
> following error occurs:
> {code:java}
> Failed to execute goal
> org.apache.maven.plugins:maven-install-plugin:3.0.0-M1:install
> (default-install) on project : NoFileAssignedException: The
> packaging plugin for this project did not assign a main file to the project
> but it has attachments. Change packaging to 'pom'. -> [Help 1]
> {code}
> Reverting back to version {{2.5.2}} made the {{mvn install}} command succeed.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MINSTALL-151) Projects without primary artifacts, but with attachment artifacts fails install
[
https://issues.apache.org/jira/browse/MINSTALL-151?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16634330#comment-16634330
]
Peter Huffer commented on MINSTALL-151:
---
[~gsfernandes] I updated the ticket title with that info to be more accurate.
> Projects without primary artifacts, but with attachment artifacts fails
> install
> ---
>
> Key: MINSTALL-151
> URL: https://issues.apache.org/jira/browse/MINSTALL-151
> Project: Maven Install Plugin
> Issue Type: Bug
>Affects Versions: 3.0.0-M1
>Reporter: Peter Huffer
>Priority: Major
> Attachments: minstall-151.zip
>
>
> I have a module which has a packaging of {{feature}} from the
> {{karaf-maven-plugin}}. When running the {{mvn install}} command, the
> following error occurs:
> {code:java}
> Failed to execute goal
> org.apache.maven.plugins:maven-install-plugin:3.0.0-M1:install
> (default-install) on project : NoFileAssignedException: The
> packaging plugin for this project did not assign a main file to the project
> but it has attachments. Change packaging to 'pom'. -> [Help 1]
> {code}
> Reverting back to version {{2.5.2}} made the {{mvn install}} command succeed.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (MINSTALL-151) Projects without primary artifacts, but with attachment artifacts fail install
[
https://issues.apache.org/jira/browse/MINSTALL-151?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Peter Huffer updated MINSTALL-151:
--
Summary: Projects without primary artifacts, but with attachment artifacts
fail install (was: Projects without primary artifacts, but with attachment
artifacts fails install)
> Projects without primary artifacts, but with attachment artifacts fail install
> --
>
> Key: MINSTALL-151
> URL: https://issues.apache.org/jira/browse/MINSTALL-151
> Project: Maven Install Plugin
> Issue Type: Bug
>Affects Versions: 3.0.0-M1
>Reporter: Peter Huffer
>Priority: Major
> Attachments: minstall-151.zip
>
>
> I have a module which has a packaging of {{feature}} from the
> {{karaf-maven-plugin}}. When running the {{mvn install}} command, the
> following error occurs:
> {code:java}
> Failed to execute goal
> org.apache.maven.plugins:maven-install-plugin:3.0.0-M1:install
> (default-install) on project : NoFileAssignedException: The
> packaging plugin for this project did not assign a main file to the project
> but it has attachments. Change packaging to 'pom'. -> [Help 1]
> {code}
> Reverting back to version {{2.5.2}} made the {{mvn install}} command succeed.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MINSTALL-151) Module packaging of `feature` fails to install
[
https://issues.apache.org/jira/browse/MINSTALL-151?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16634328#comment-16634328
]
Karl Heinz Marbaise commented on MINSTALL-151:
--
So maybe I misunderstand a thing but based on the [docs of
karaf-maven-plugin|https://karaf.apache.org/manual/latest/#_maven_plugin]
{quote}The feature packaging verifies a features.xml descriptor using the
karaf:verify goal.{quote}
This means for me calling {{install}} on such project is not correct. It does
not package/prepare a package like information...
> Module packaging of `feature` fails to install
> --
>
> Key: MINSTALL-151
> URL: https://issues.apache.org/jira/browse/MINSTALL-151
> Project: Maven Install Plugin
> Issue Type: Bug
>Affects Versions: 3.0.0-M1
>Reporter: Peter Huffer
>Priority: Major
> Attachments: minstall-151.zip
>
>
> I have a module which has a packaging of {{feature}} from the
> {{karaf-maven-plugin}}. When running the {{mvn install}} command, the
> following error occurs:
> {code:java}
> Failed to execute goal
> org.apache.maven.plugins:maven-install-plugin:3.0.0-M1:install
> (default-install) on project : NoFileAssignedException: The
> packaging plugin for this project did not assign a main file to the project
> but it has attachments. Change packaging to 'pom'. -> [Help 1]
> {code}
> Reverting back to version {{2.5.2}} made the {{mvn install}} command succeed.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (MINSTALL-151) Projects without primary artifacts, but with attachment artifacts fails install
[
https://issues.apache.org/jira/browse/MINSTALL-151?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Peter Huffer updated MINSTALL-151:
--
Summary: Projects without primary artifacts, but with attachment artifacts
fails install (was: Module packaging of `feature` fails to install)
> Projects without primary artifacts, but with attachment artifacts fails
> install
> ---
>
> Key: MINSTALL-151
> URL: https://issues.apache.org/jira/browse/MINSTALL-151
> Project: Maven Install Plugin
> Issue Type: Bug
>Affects Versions: 3.0.0-M1
>Reporter: Peter Huffer
>Priority: Major
> Attachments: minstall-151.zip
>
>
> I have a module which has a packaging of {{feature}} from the
> {{karaf-maven-plugin}}. When running the {{mvn install}} command, the
> following error occurs:
> {code:java}
> Failed to execute goal
> org.apache.maven.plugins:maven-install-plugin:3.0.0-M1:install
> (default-install) on project : NoFileAssignedException: The
> packaging plugin for this project did not assign a main file to the project
> but it has attachments. Change packaging to 'pom'. -> [Help 1]
> {code}
> Reverting back to version {{2.5.2}} made the {{mvn install}} command succeed.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MINSTALL-151) Module packaging of `feature` fails to install
[
https://issues.apache.org/jira/browse/MINSTALL-151?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16634313#comment-16634313
]
Guillermo Fernandes commented on MINSTALL-151:
--
Hi [~khmarbaise],
We are having the same issue, seems that 3.0.0-M1 has changed its behaviour
when installing a project without main artifact but with attachments.
maven-installer-plugin 2.5.2 was just logging an info message on this scenario:
[https://github.com/apache/maven-install-plugin/blob/maven-install-plugin-2.5.2/src/main/java/org/apache/maven/plugin/install/InstallMojo.java#L203]
{code:java}
getLog().info( "No primary artifact to install, installing attached artifacts
instead." );{code}
3.0.0-M1 instead delegates this logic to maven-artifact-transfer which instead
throws an exception on this scenario:
[https://github.com/apache/maven-artifact-transfer/blob/maven-artifact-transfer-0.10.0/src/main/java/org/apache/maven/shared/transfer/project/install/internal/DefaultProjectInstaller.java#L116]
I know that would make sense to fail on this scenarios but I'm wondering if
this intentional or just you were not aware that this will break builds where
plugins declare a custom packaging and are not setting the main artifact to the
project.
Regards,
> Module packaging of `feature` fails to install
> --
>
> Key: MINSTALL-151
> URL: https://issues.apache.org/jira/browse/MINSTALL-151
> Project: Maven Install Plugin
> Issue Type: Bug
>Affects Versions: 3.0.0-M1
>Reporter: Peter Huffer
>Priority: Major
> Attachments: minstall-151.zip
>
>
> I have a module which has a packaging of {{feature}} from the
> {{karaf-maven-plugin}}. When running the {{mvn install}} command, the
> following error occurs:
> {code:java}
> Failed to execute goal
> org.apache.maven.plugins:maven-install-plugin:3.0.0-M1:install
> (default-install) on project : NoFileAssignedException: The
> packaging plugin for this project did not assign a main file to the project
> but it has attachments. Change packaging to 'pom'. -> [Help 1]
> {code}
> Reverting back to version {{2.5.2}} made the {{mvn install}} command succeed.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (MINSTALL-151) Module packaging of `feature` fails to install
[
https://issues.apache.org/jira/browse/MINSTALL-151?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16634313#comment-16634313
]
Guillermo Fernandes edited comment on MINSTALL-151 at 10/1/18 4:52 PM:
---
Hi [~khmarbaise],
We are having the same issue, seems that 3.0.0-M1 has changed its behaviour
when installing a project without main artifact but with attachments.
maven-installer-plugin 2.5.2 was just logging an info message on this scenario:
[https://github.com/apache/maven-install-plugin/blob/maven-install-plugin-2.5.2/src/main/java/org/apache/maven/plugin/install/InstallMojo.java#L203]
{code:java}
getLog().info( "No primary artifact to install, installing attached artifacts
instead." );{code}
3.0.0-M1 instead delegates this logic to maven-artifact-transfer which throws
an exception on this case:
[https://github.com/apache/maven-artifact-transfer/blob/maven-artifact-transfer-0.10.0/src/main/java/org/apache/maven/shared/transfer/project/install/internal/DefaultProjectInstaller.java#L116]
I know that would make sense to fail on this scenarios but I'm wondering if
this intentional or just you were not aware that this will break builds where
plugins declare a custom packaging and are not setting the main artifact to the
project.
Regards,
was (Author: gsfernandes):
Hi [~khmarbaise],
We are having the same issue, seems that 3.0.0-M1 has changed its behaviour
when installing a project without main artifact but with attachments.
maven-installer-plugin 2.5.2 was just logging an info message on this scenario:
[https://github.com/apache/maven-install-plugin/blob/maven-install-plugin-2.5.2/src/main/java/org/apache/maven/plugin/install/InstallMojo.java#L203]
{code:java}
getLog().info( "No primary artifact to install, installing attached artifacts
instead." );{code}
3.0.0-M1 instead delegates this logic to maven-artifact-transfer which instead
throws an exception on this scenario:
[https://github.com/apache/maven-artifact-transfer/blob/maven-artifact-transfer-0.10.0/src/main/java/org/apache/maven/shared/transfer/project/install/internal/DefaultProjectInstaller.java#L116]
I know that would make sense to fail on this scenarios but I'm wondering if
this intentional or just you were not aware that this will break builds where
plugins declare a custom packaging and are not setting the main artifact to the
project.
Regards,
> Module packaging of `feature` fails to install
> --
>
> Key: MINSTALL-151
> URL: https://issues.apache.org/jira/browse/MINSTALL-151
> Project: Maven Install Plugin
> Issue Type: Bug
>Affects Versions: 3.0.0-M1
>Reporter: Peter Huffer
>Priority: Major
> Attachments: minstall-151.zip
>
>
> I have a module which has a packaging of {{feature}} from the
> {{karaf-maven-plugin}}. When running the {{mvn install}} command, the
> following error occurs:
> {code:java}
> Failed to execute goal
> org.apache.maven.plugins:maven-install-plugin:3.0.0-M1:install
> (default-install) on project : NoFileAssignedException: The
> packaging plugin for this project did not assign a main file to the project
> but it has attachments. Change packaging to 'pom'. -> [Help 1]
> {code}
> Reverting back to version {{2.5.2}} made the {{mvn install}} command succeed.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (MINSTALL-151) Module packaging of `feature` fails to install
[
https://issues.apache.org/jira/browse/MINSTALL-151?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Peter Huffer updated MINSTALL-151:
--
Attachment: (was: feature.xml)
> Module packaging of `feature` fails to install
> --
>
> Key: MINSTALL-151
> URL: https://issues.apache.org/jira/browse/MINSTALL-151
> Project: Maven Install Plugin
> Issue Type: Bug
>Affects Versions: 3.0.0-M1
>Reporter: Peter Huffer
>Priority: Major
> Attachments: minstall-151.zip
>
>
> I have a module which has a packaging of {{feature}} from the
> {{karaf-maven-plugin}}. When running the {{mvn install}} command, the
> following error occurs:
> {code:java}
> Failed to execute goal
> org.apache.maven.plugins:maven-install-plugin:3.0.0-M1:install
> (default-install) on project : NoFileAssignedException: The
> packaging plugin for this project did not assign a main file to the project
> but it has attachments. Change packaging to 'pom'. -> [Help 1]
> {code}
> Reverting back to version {{2.5.2}} made the {{mvn install}} command succeed.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (MINSTALL-151) Module packaging of `feature` fails to install
[
https://issues.apache.org/jira/browse/MINSTALL-151?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Peter Huffer updated MINSTALL-151:
--
Attachment: minstall-151.zip
> Module packaging of `feature` fails to install
> --
>
> Key: MINSTALL-151
> URL: https://issues.apache.org/jira/browse/MINSTALL-151
> Project: Maven Install Plugin
> Issue Type: Bug
>Affects Versions: 3.0.0-M1
>Reporter: Peter Huffer
>Priority: Major
> Attachments: minstall-151.zip
>
>
> I have a module which has a packaging of {{feature}} from the
> {{karaf-maven-plugin}}. When running the {{mvn install}} command, the
> following error occurs:
> {code:java}
> Failed to execute goal
> org.apache.maven.plugins:maven-install-plugin:3.0.0-M1:install
> (default-install) on project : NoFileAssignedException: The
> packaging plugin for this project did not assign a main file to the project
> but it has attachments. Change packaging to 'pom'. -> [Help 1]
> {code}
> Reverting back to version {{2.5.2}} made the {{mvn install}} command succeed.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MINSTALL-151) Module packaging of `feature` fails to install
[
https://issues.apache.org/jira/browse/MINSTALL-151?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16634304#comment-16634304
]
Peter Huffer commented on MINSTALL-151:
---
[~khmarbaise] ahh duh. Uploaded the zip :)
> Module packaging of `feature` fails to install
> --
>
> Key: MINSTALL-151
> URL: https://issues.apache.org/jira/browse/MINSTALL-151
> Project: Maven Install Plugin
> Issue Type: Bug
>Affects Versions: 3.0.0-M1
>Reporter: Peter Huffer
>Priority: Major
> Attachments: minstall-151.zip
>
>
> I have a module which has a packaging of {{feature}} from the
> {{karaf-maven-plugin}}. When running the {{mvn install}} command, the
> following error occurs:
> {code:java}
> Failed to execute goal
> org.apache.maven.plugins:maven-install-plugin:3.0.0-M1:install
> (default-install) on project : NoFileAssignedException: The
> packaging plugin for this project did not assign a main file to the project
> but it has attachments. Change packaging to 'pom'. -> [Help 1]
> {code}
> Reverting back to version {{2.5.2}} made the {{mvn install}} command succeed.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (MINSTALL-151) Module packaging of `feature` fails to install
[
https://issues.apache.org/jira/browse/MINSTALL-151?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Peter Huffer updated MINSTALL-151:
--
Attachment: (was: pom.xml)
> Module packaging of `feature` fails to install
> --
>
> Key: MINSTALL-151
> URL: https://issues.apache.org/jira/browse/MINSTALL-151
> Project: Maven Install Plugin
> Issue Type: Bug
>Affects Versions: 3.0.0-M1
>Reporter: Peter Huffer
>Priority: Major
> Attachments: minstall-151.zip
>
>
> I have a module which has a packaging of {{feature}} from the
> {{karaf-maven-plugin}}. When running the {{mvn install}} command, the
> following error occurs:
> {code:java}
> Failed to execute goal
> org.apache.maven.plugins:maven-install-plugin:3.0.0-M1:install
> (default-install) on project : NoFileAssignedException: The
> packaging plugin for this project did not assign a main file to the project
> but it has attachments. Change packaging to 'pom'. -> [Help 1]
> {code}
> Reverting back to version {{2.5.2}} made the {{mvn install}} command succeed.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MINSTALL-151) Module packaging of `feature` fails to install
[
https://issues.apache.org/jira/browse/MINSTALL-151?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16634302#comment-16634302
]
Karl Heinz Marbaise commented on MINSTALL-151:
--
Simplest would be to zip/tar.gz the example project and attach that ;-)...
> Module packaging of `feature` fails to install
> --
>
> Key: MINSTALL-151
> URL: https://issues.apache.org/jira/browse/MINSTALL-151
> Project: Maven Install Plugin
> Issue Type: Bug
>Affects Versions: 3.0.0-M1
>Reporter: Peter Huffer
>Priority: Major
> Attachments: feature.xml, pom.xml
>
>
> I have a module which has a packaging of {{feature}} from the
> {{karaf-maven-plugin}}. When running the {{mvn install}} command, the
> following error occurs:
> {code:java}
> Failed to execute goal
> org.apache.maven.plugins:maven-install-plugin:3.0.0-M1:install
> (default-install) on project : NoFileAssignedException: The
> packaging plugin for this project did not assign a main file to the project
> but it has attachments. Change packaging to 'pom'. -> [Help 1]
> {code}
> Reverting back to version {{2.5.2}} made the {{mvn install}} command succeed.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MINSTALL-151) Module packaging of `feature` fails to install
[
https://issues.apache.org/jira/browse/MINSTALL-151?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16634297#comment-16634297
]
Peter Huffer commented on MINSTALL-151:
---
[~khmarbaise] I'm not sure what the best way to upload my example project is. I
put up the pom.xml though as well as an empty feature.xml file that should go
under a {{src/main/feature}} directory. If there is a better way to upload the
example let me know and I'll do it.
> Module packaging of `feature` fails to install
> --
>
> Key: MINSTALL-151
> URL: https://issues.apache.org/jira/browse/MINSTALL-151
> Project: Maven Install Plugin
> Issue Type: Bug
>Affects Versions: 3.0.0-M1
>Reporter: Peter Huffer
>Priority: Major
> Attachments: feature.xml, pom.xml
>
>
> I have a module which has a packaging of {{feature}} from the
> {{karaf-maven-plugin}}. When running the {{mvn install}} command, the
> following error occurs:
> {code:java}
> Failed to execute goal
> org.apache.maven.plugins:maven-install-plugin:3.0.0-M1:install
> (default-install) on project : NoFileAssignedException: The
> packaging plugin for this project did not assign a main file to the project
> but it has attachments. Change packaging to 'pom'. -> [Help 1]
> {code}
> Reverting back to version {{2.5.2}} made the {{mvn install}} command succeed.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (MINSTALL-151) Module packaging of `feature` fails to install
[
https://issues.apache.org/jira/browse/MINSTALL-151?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Peter Huffer updated MINSTALL-151:
--
Attachment: feature.xml
> Module packaging of `feature` fails to install
> --
>
> Key: MINSTALL-151
> URL: https://issues.apache.org/jira/browse/MINSTALL-151
> Project: Maven Install Plugin
> Issue Type: Bug
>Affects Versions: 3.0.0-M1
>Reporter: Peter Huffer
>Priority: Major
> Attachments: feature.xml, pom.xml
>
>
> I have a module which has a packaging of {{feature}} from the
> {{karaf-maven-plugin}}. When running the {{mvn install}} command, the
> following error occurs:
> {code:java}
> Failed to execute goal
> org.apache.maven.plugins:maven-install-plugin:3.0.0-M1:install
> (default-install) on project : NoFileAssignedException: The
> packaging plugin for this project did not assign a main file to the project
> but it has attachments. Change packaging to 'pom'. -> [Help 1]
> {code}
> Reverting back to version {{2.5.2}} made the {{mvn install}} command succeed.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (MINSTALL-151) Module packaging of `feature` fails to install
[
https://issues.apache.org/jira/browse/MINSTALL-151?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Peter Huffer updated MINSTALL-151:
--
Attachment: pom.xml
> Module packaging of `feature` fails to install
> --
>
> Key: MINSTALL-151
> URL: https://issues.apache.org/jira/browse/MINSTALL-151
> Project: Maven Install Plugin
> Issue Type: Bug
>Affects Versions: 3.0.0-M1
>Reporter: Peter Huffer
>Priority: Major
> Attachments: feature.xml, pom.xml
>
>
> I have a module which has a packaging of {{feature}} from the
> {{karaf-maven-plugin}}. When running the {{mvn install}} command, the
> following error occurs:
> {code:java}
> Failed to execute goal
> org.apache.maven.plugins:maven-install-plugin:3.0.0-M1:install
> (default-install) on project : NoFileAssignedException: The
> packaging plugin for this project did not assign a main file to the project
> but it has attachments. Change packaging to 'pom'. -> [Help 1]
> {code}
> Reverting back to version {{2.5.2}} made the {{mvn install}} command succeed.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MINSTALL-151) Module packaging of `feature` fails to install
[
https://issues.apache.org/jira/browse/MINSTALL-151?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16634269#comment-16634269
]
Karl Heinz Marbaise commented on MINSTALL-151:
--
[~cffk] I suppose you don't have defined all the plugin versions you are using..
[~peter.huffer] That would be great so i can create an integration test of it...
> Module packaging of `feature` fails to install
> --
>
> Key: MINSTALL-151
> URL: https://issues.apache.org/jira/browse/MINSTALL-151
> Project: Maven Install Plugin
> Issue Type: Bug
>Affects Versions: 3.0.0-M1
>Reporter: Peter Huffer
>Priority: Major
>
> I have a module which has a packaging of {{feature}} from the
> {{karaf-maven-plugin}}. When running the {{mvn install}} command, the
> following error occurs:
> {code:java}
> Failed to execute goal
> org.apache.maven.plugins:maven-install-plugin:3.0.0-M1:install
> (default-install) on project : NoFileAssignedException: The
> packaging plugin for this project did not assign a main file to the project
> but it has attachments. Change packaging to 'pom'. -> [Help 1]
> {code}
> Reverting back to version {{2.5.2}} made the {{mvn install}} command succeed.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MINSTALL-151) Module packaging of `feature` fails to install
[
https://issues.apache.org/jira/browse/MINSTALL-151?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16634259#comment-16634259
]
Charles Karney commented on MINSTALL-151:
-
[~peter.huffer] Thanks! That worked...
> Module packaging of `feature` fails to install
> --
>
> Key: MINSTALL-151
> URL: https://issues.apache.org/jira/browse/MINSTALL-151
> Project: Maven Install Plugin
> Issue Type: Bug
>Affects Versions: 3.0.0-M1
>Reporter: Peter Huffer
>Priority: Major
>
> I have a module which has a packaging of {{feature}} from the
> {{karaf-maven-plugin}}. When running the {{mvn install}} command, the
> following error occurs:
> {code:java}
> Failed to execute goal
> org.apache.maven.plugins:maven-install-plugin:3.0.0-M1:install
> (default-install) on project : NoFileAssignedException: The
> packaging plugin for this project did not assign a main file to the project
> but it has attachments. Change packaging to 'pom'. -> [Help 1]
> {code}
> Reverting back to version {{2.5.2}} made the {{mvn install}} command succeed.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (MINSTALL-151) Module packaging of `feature` fails to install
[
https://issues.apache.org/jira/browse/MINSTALL-151?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16634255#comment-16634255
]
Peter Huffer edited comment on MINSTALL-151 at 10/1/18 4:12 PM:
[~cffk] In our root pom in the pluginManagement section we did
{code:java}
org.apache.maven.plugins
maven-install-plugin
2.5.2
{code}
as a fix for now. It worked for us.
[~khmarbaise] Yup, I'll work on a quick example.
was (Author: peter.huffer):
[~cffk] In our root pom in the dependenyManagement section we did
{code:java}
org.apache.maven.plugins
maven-install-plugin
2.5.2
{code}
as a fix for now. It worked for us.
[~khmarbaise] Yup, I'll work on a quick example.
> Module packaging of `feature` fails to install
> --
>
> Key: MINSTALL-151
> URL: https://issues.apache.org/jira/browse/MINSTALL-151
> Project: Maven Install Plugin
> Issue Type: Bug
>Affects Versions: 3.0.0-M1
>Reporter: Peter Huffer
>Priority: Major
>
> I have a module which has a packaging of {{feature}} from the
> {{karaf-maven-plugin}}. When running the {{mvn install}} command, the
> following error occurs:
> {code:java}
> Failed to execute goal
> org.apache.maven.plugins:maven-install-plugin:3.0.0-M1:install
> (default-install) on project : NoFileAssignedException: The
> packaging plugin for this project did not assign a main file to the project
> but it has attachments. Change packaging to 'pom'. -> [Help 1]
> {code}
> Reverting back to version {{2.5.2}} made the {{mvn install}} command succeed.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MINSTALL-151) Module packaging of `feature` fails to install
[
https://issues.apache.org/jira/browse/MINSTALL-151?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16634255#comment-16634255
]
Peter Huffer commented on MINSTALL-151:
---
[~cffk] In our root pom in the dependenyManagement section we did
{code:java}
org.apache.maven.plugins
maven-install-plugin
2.5.2
{code}
as a fix for now. It worked for us.
[~khmarbaise] Yup, I'll work on a quick example.
> Module packaging of `feature` fails to install
> --
>
> Key: MINSTALL-151
> URL: https://issues.apache.org/jira/browse/MINSTALL-151
> Project: Maven Install Plugin
> Issue Type: Bug
>Affects Versions: 3.0.0-M1
>Reporter: Peter Huffer
>Priority: Major
>
> I have a module which has a packaging of {{feature}} from the
> {{karaf-maven-plugin}}. When running the {{mvn install}} command, the
> following error occurs:
> {code:java}
> Failed to execute goal
> org.apache.maven.plugins:maven-install-plugin:3.0.0-M1:install
> (default-install) on project : NoFileAssignedException: The
> packaging plugin for this project did not assign a main file to the project
> but it has attachments. Change packaging to 'pom'. -> [Help 1]
> {code}
> Reverting back to version {{2.5.2}} made the {{mvn install}} command succeed.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MINSTALL-151) Module packaging of `feature` fails to install
[
https://issues.apache.org/jira/browse/MINSTALL-151?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16634251#comment-16634251
]
Charles Karney commented on MINSTALL-151:
-
This is a show-stopper for us. Our entire build framework is down. Is it
possible to change pom.xml to get it to use maven-install-plugin 2.5.2.
> Module packaging of `feature` fails to install
> --
>
> Key: MINSTALL-151
> URL: https://issues.apache.org/jira/browse/MINSTALL-151
> Project: Maven Install Plugin
> Issue Type: Bug
>Affects Versions: 3.0.0-M1
>Reporter: Peter Huffer
>Priority: Major
>
> I have a module which has a packaging of {{feature}} from the
> {{karaf-maven-plugin}}. When running the {{mvn install}} command, the
> following error occurs:
> {code:java}
> Failed to execute goal
> org.apache.maven.plugins:maven-install-plugin:3.0.0-M1:install
> (default-install) on project : NoFileAssignedException: The
> packaging plugin for this project did not assign a main file to the project
> but it has attachments. Change packaging to 'pom'. -> [Help 1]
> {code}
> Reverting back to version {{2.5.2}} made the {{mvn install}} command succeed.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MINSTALL-151) Module packaging of `feature` fails to install
[
https://issues.apache.org/jira/browse/MINSTALL-151?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16634208#comment-16634208
]
Karl Heinz Marbaise commented on MINSTALL-151:
--
Can you please attach a full working example ?
> Module packaging of `feature` fails to install
> --
>
> Key: MINSTALL-151
> URL: https://issues.apache.org/jira/browse/MINSTALL-151
> Project: Maven Install Plugin
> Issue Type: Bug
>Affects Versions: 3.0.0-M1
>Reporter: Peter Huffer
>Priority: Major
>
> I have a module which has a packaging of {{feature}} from the
> {{karaf-maven-plugin}}. When running the {{mvn install}} command, the
> following error occurs:
> {code:java}
> Failed to execute goal
> org.apache.maven.plugins:maven-install-plugin:3.0.0-M1:install
> (default-install) on project : NoFileAssignedException: The
> packaging plugin for this project did not assign a main file to the project
> but it has attachments. Change packaging to 'pom'. -> [Help 1]
> {code}
> Reverting back to version {{2.5.2}} made the {{mvn install}} command succeed.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (MINSTALL-151) Module packaging of `feature` fails to install
[
https://issues.apache.org/jira/browse/MINSTALL-151?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Peter Huffer updated MINSTALL-151:
--
Description:
I have a module which has a packaging of {{feature}} from the
{{karaf-maven-plugin}}. When running the {{mvn install}} command, the following
error occurs:
{code:java}
Failed to execute goal
org.apache.maven.plugins:maven-install-plugin:3.0.0-M1:install
(default-install) on project : NoFileAssignedException: The
packaging plugin for this project did not assign a main file to the project but
it has attachments. Change packaging to 'pom'. -> [Help 1]
{code}
Reverting back to version {{2.5.2}} made the {{mvn install}} command succeed.
was:
I have a module which has a packaging of `feature` from the
`karaf-maven-plugin`. When running the `mvn install` command, the following
error occurs:
{code:java}
Failed to execute goal
org.apache.maven.plugins:maven-install-plugin:3.0.0-M1:install
(default-install) on project : NoFileAssignedException: The
packaging plugin for this project did not assign a main file to the project but
it has attachments. Change packaging to 'pom'. -> [Help 1]
{code}
Reverting back to version `2.5.2` made the `mvn install` command succeed.
> Module packaging of `feature` fails to install
> --
>
> Key: MINSTALL-151
> URL: https://issues.apache.org/jira/browse/MINSTALL-151
> Project: Maven Install Plugin
> Issue Type: Bug
>Affects Versions: 3.0.0-M1
>Reporter: Peter Huffer
>Priority: Major
>
> I have a module which has a packaging of {{feature}} from the
> {{karaf-maven-plugin}}. When running the {{mvn install}} command, the
> following error occurs:
> {code:java}
> Failed to execute goal
> org.apache.maven.plugins:maven-install-plugin:3.0.0-M1:install
> (default-install) on project : NoFileAssignedException: The
> packaging plugin for this project did not assign a main file to the project
> but it has attachments. Change packaging to 'pom'. -> [Help 1]
> {code}
> Reverting back to version {{2.5.2}} made the {{mvn install}} command succeed.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (MINSTALL-151) Module packaging of `feature` fails to install
Peter Huffer created MINSTALL-151:
-
Summary: Module packaging of `feature` fails to install
Key: MINSTALL-151
URL: https://issues.apache.org/jira/browse/MINSTALL-151
Project: Maven Install Plugin
Issue Type: Bug
Affects Versions: 3.0.0-M1
Reporter: Peter Huffer
I have a module which has a packaging of `feature` from the
`karaf-maven-plugin`. When running the `mvn install` command, the following
error occurs:
{code:java}
Failed to execute goal
org.apache.maven.plugins:maven-install-plugin:3.0.0-M1:install
(default-install) on project : NoFileAssignedException: The
packaging plugin for this project did not assign a main file to the project but
it has attachments. Change packaging to 'pom'. -> [Help 1]
{code}
Reverting back to version `2.5.2` made the `mvn install` command succeed.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (SUREFIRE-1575) Distribute tests ad-hoc across foks
[
https://issues.apache.org/jira/browse/SUREFIRE-1575?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Orth updated SUREFIRE-1575:
--
Summary: Distribute tests ad-hoc across foks (was: Distribute Tests ad-hoc
across foks)
> Distribute tests ad-hoc across foks
> ---
>
> Key: SUREFIRE-1575
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1575
> Project: Maven Surefire
> Issue Type: Improvement
> Components: Maven Surefire Plugin
>Affects Versions: 2.22.0
>Reporter: Julian Orth
>Priority: Minor
> Labels: performance
>
> Hi,
> consider the case where surefire is configured with {{forkCount > 1}}.
> Currently the distribution of classes across forks appears to work as follows:
> * Divide all included test classes in {{forkCount}} buckets and write each
> bucket to a jar
> * Start {{forkCount}} JVMs, each with one of the jars as an argument
> * Have each JVM run the tests in its jar
> This can cause less than optimal test run times. For example:
> * If a significant number of tests is excluded via the {{groups}} mechanism,
> all but one JVM might exit immediately, leaving the remaining JVM to execute
> all included tests.
> * If a large number of tests runs in a small amount of time and a small
> number of tests consume almost 100% of the single-JVM run time, then these
> expensive tests might be assigned to a single JVM.
> Therefore, I would like to suggest the following changes to the distribution
> process:
> * All {{forkCount}} JVMs are started with the same jar.
> * Whenever one of the forks wants to run a test class, it asks the master
> process for the next test class name via some IPC mechanism. I assume such an
> IPC mechanism already exists for sending _Running_ and _Tests run_ messages.
> * If there is another unrun test class, the master process sends the fully
> qualified class name, otherwise it notifies the child that there are no more
> tests to run.
> * The child then exits if there are no more test classes or runs the test
> class.
> Via this mechanism, the test run time achieves the theoretically optimal time
> of {{sum(individual test run times) / forkCount + (time of longest runnning
> test class)}}.
> I would be willing to implement this.
> Julian
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (SUREFIRE-1575) Distribute Tests ad-hoc across foks
[
https://issues.apache.org/jira/browse/SUREFIRE-1575?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Orth updated SUREFIRE-1575:
--
Description:
Hi,
consider the case where surefire is configured with {{forkCount > 1}}.
Currently the distribution of classes across forks appears to work as follows:
* Divide all included test classes in {{forkCount}} buckets and write each
bucket to a jar
* Start {{forkCount}} JVMs, each with one of the jars as an argument
* Have each JVM run the tests in its jar
This can cause less than optimal test run times. For example:
* If a significant number of tests is excluded via the {{groups}} mechanism,
all but one JVM might exit immediately, leaving the remaining JVM to execute
all included tests.
* If a large number of tests runs in a small amount of time and a small number
of tests consume almost 100% of the single-JVM run time, then these expensive
tests might be assigned to a single JVM.
Therefore, I would like to suggest the following changes to the distribution
process:
* All {{forkCount}} JVMs are started with the same jar.
* Whenever one of the forks wants to run a test class, it asks the master
process for the next test class name via some IPC mechanism. I assume such an
IPC mechanism already exists for sending _Running_ and _Tests run_ messages.
* If there is another unrun test class, the master process sends the fully
qualified class name, otherwise it notifies the child that there are no more
tests to run.
* The child then exits if there are no more test classes or runs the test class.
Via this mechanism, the test run time achieves the theoretically optimal time
of {{sum(individual test run times) / forkCount + (time of longest runnning
test class)}}.
I would be willing to implement this.
Julian
was:
Hi,
consider the case where surefire is configured with {{forkCount > 1}}.
Currently the distribution of classes across forks appears to work as follows:
* Divide all included test classes in {{forkCount}} buckets and write each
bucket to a jar
* Start {{forkCount}} JVMs, each with one of the jars as an argument
* Have each JVM run the tests in its jar
This can cause less than optimal test run times. For example:
* If a significant number of tests is excluded via the {{groups}} mechanism,
all but one JVM might exit immediately, leaving the remaining JVM to execute
all included tests.
* If a large number of tests runs in a small amount of time and a small amount
of tests consumes almost 100% of the single-JVM run time, then these expensive
tests might be assigned to a single JVM.
Therefore, I would like to suggest the following changes to the distribution
process:
* All {{forkCount}} JVMs are started with the same jar.
* Whenever one of the forks wants to run a test class, it asks the master
process for the next test class name via some IPC mechanism. I assume such an
IPC mechanism already exists for sending _Running_ and _Tests run_ messages.
* If there is another unrun test class, the master process sends the fully
qualified class name, otherwise it notifies the child that there are no more
tests to run.
* The child then exits if there are no more test classes or runs the test class.
Via this mechanism, the test run time achieves the theoretically optimal time
of {{sum(individual test run times) / forkCount + (time of longest runnning
test class)}}.
I would be willing to implement this.
Julian
> Distribute Tests ad-hoc across foks
> ---
>
> Key: SUREFIRE-1575
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1575
> Project: Maven Surefire
> Issue Type: Improvement
> Components: Maven Surefire Plugin
>Affects Versions: 2.22.0
>Reporter: Julian Orth
>Priority: Minor
> Labels: performance
>
> Hi,
> consider the case where surefire is configured with {{forkCount > 1}}.
> Currently the distribution of classes across forks appears to work as follows:
> * Divide all included test classes in {{forkCount}} buckets and write each
> bucket to a jar
> * Start {{forkCount}} JVMs, each with one of the jars as an argument
> * Have each JVM run the tests in its jar
> This can cause less than optimal test run times. For example:
> * If a significant number of tests is excluded via the {{groups}} mechanism,
> all but one JVM might exit immediately, leaving the remaining JVM to execute
> all included tests.
> * If a large number of tests runs in a small amount of time and a small
> number of tests consume almost 100% of the single-JVM run time, then these
> expensive tests might be assigned to a single JVM.
> Therefore, I would like to suggest the following changes to the distribution
> process:
> * All {{forkCount}} JVMs are started with the same jar.
> * Whenever one of the forks wants to run a test class, it asks the ma
[jira] [Created] (SUREFIRE-1575) Distribute Tests ad-hoc across foks
Julian Orth created SUREFIRE-1575:
-
Summary: Distribute Tests ad-hoc across foks
Key: SUREFIRE-1575
URL: https://issues.apache.org/jira/browse/SUREFIRE-1575
Project: Maven Surefire
Issue Type: Improvement
Components: Maven Surefire Plugin
Affects Versions: 2.22.0
Reporter: Julian Orth
Hi,
consider the case where surefire is configured with {{forkCount > 1}}.
Currently the distribution of classes across forks appears to work as follows:
* Divide all included test classes in {{forkCount}} buckets and write each
bucket to a jar
* Start {{forkCount}} JVMs, each with one of the jars as an argument
* Have each JVM run the tests in its jar
This can cause less than optimal test run times. For example:
* If a significant number of tests is excluded via the {{groups}} mechanism,
all but one JVM might exit immediately, leaving the remaining JVM to execute
all included tests.
* If a large number of tests runs in a small amount of time and a small amount
of tests consumes almost 100% of the single-JVM run time, then these expensive
tests might be assigned to a single JVM.
Therefore, I would like to suggest the following changes to the distribution
process:
* All {{forkCount}} JVMs are started with the same jar.
* Whenever one of the forks wants to run a test class, it asks the master
process for the next test class name via some IPC mechanism. I assume such an
IPC mechanism already exists for sending _Running_ and _Tests run_ messages.
* If there is another unrun test class, the master process sends the fully
qualified class name, otherwise it notifies the child that there are no more
tests to run.
* The child then exits if there are no more test classes or runs the test class.
Via this mechanism, the test run time achieves the theoretically optimal time
of {{sum(individual test run times) / forkCount + (time of longest runnning
test class)}}.
I would be willing to implement this.
Julian
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (MDEP-629) Unpack goal with includes/excludes does not honor marker files
[
https://issues.apache.org/jira/browse/MDEP-629?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jörg Delker updated MDEP-629:
-
Summary: Unpack goal with includes/excludes does not honor marker files
(was: Unpack goal with includes/excludes doer not honor marker files)
> Unpack goal with includes/excludes does not honor marker files
> --
>
> Key: MDEP-629
> URL: https://issues.apache.org/jira/browse/MDEP-629
> Project: Maven Dependency Plugin
> Issue Type: Bug
> Components: unpack, unpack-dependencies
>Affects Versions: 3.1.1
>Reporter: Jörg Delker
>Priority: Major
>
> When using the unpack goal to extract an artifact dependency, that action is
> performed regardless of any previous run which already created a marker file.
> Consider this pom extract:
> {noformat}
>
> org.apache.maven.plugins
> maven-dependency-plugin
> 3.1.1
>
>
> unpack
> generate-sources
>
> unpack
>
>
> ${my.excludes}
>
>
> groupid
> artifactid
> war
> false
>
>
>
>
>
> {noformat}
> After executing "mvn generate-sources", the following marker file has been
> created:
> {{target/dependency-maven-plugin-markers/myartifactfile-1.01480985089}}
> Obviously, this file is not checked when this run is repeated.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MDEP-629) Unpack goal with includes/excludes doer not honor marker files
[
https://issues.apache.org/jira/browse/MDEP-629?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16633847#comment-16633847
]
Jörg Delker commented on MDEP-629:
--
So, the final cause seems to be the ordering in
UnpackMojo:getProcessedArtifactItems.
The implicit check for the marker file is performed *before* the
includes/excludes are applied to the artifactItem.
> Unpack goal with includes/excludes doer not honor marker files
> --
>
> Key: MDEP-629
> URL: https://issues.apache.org/jira/browse/MDEP-629
> Project: Maven Dependency Plugin
> Issue Type: Bug
> Components: unpack, unpack-dependencies
>Affects Versions: 3.1.1
>Reporter: Jörg Delker
>Priority: Major
>
> When using the unpack goal to extract an artifact dependency, that action is
> performed regardless of any previous run which already created a marker file.
> Consider this pom extract:
> {noformat}
>
> org.apache.maven.plugins
> maven-dependency-plugin
> 3.1.1
>
>
> unpack
> generate-sources
>
> unpack
>
>
> ${my.excludes}
>
>
> groupid
> artifactid
> war
> false
>
>
>
>
>
> {noformat}
> After executing "mvn generate-sources", the following marker file has been
> created:
> {{target/dependency-maven-plugin-markers/myartifactfile-1.01480985089}}
> Obviously, this file is not checked when this run is repeated.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MDEP-629) Unpack goal with includes/excludes doer not honor marker files
[
https://issues.apache.org/jira/browse/MDEP-629?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16633840#comment-16633840
]
Jörg Delker commented on MDEP-629:
--
I've debugged this and figured the following:
When the UnpackMojo is evaluating the artifacts in getProcessedArtifactItems,
it calls super.getProcessedArtifactItems. Within further calls, that method
checks for an existing marker file in DefaultFileMarkerHandler.isMarkerSet(),
with a file name that is build though getMarkerFile().
That method is provided through UnpackFileMarkerHandler:getMarkerFile(), which
constructs a file name from various settings. Part of that are the "includes"
and "excludes" that were used in the artifact definition (see pom above). If
any of those are set, a unique hash is computed and appended to the marker file
name.
However, debugging shows, that the exclude as defined in the pom has not been
applied to the artifact yet and is therefor not included in the computation of
the marker file. In fact, the marker file is computes as
{{target/dependency-maven-plugin-markers/myartifactfile-1.0.marker}}
when the check for existence is performed.
After the unpack operation has been performed, a new marker file is created to
state the successful operation. This time, the artifact is complete - including
the exclude definition. So the computed marker file is
{{target/dependency-maven-plugin-markers/myartifactfile-1.01480985089}}
Quod erat demonstrandum.
Due to the different file name computations, the UnpackMojo is not capable of
detecting the already extracted dependency.
> Unpack goal with includes/excludes doer not honor marker files
> --
>
> Key: MDEP-629
> URL: https://issues.apache.org/jira/browse/MDEP-629
> Project: Maven Dependency Plugin
> Issue Type: Bug
> Components: unpack, unpack-dependencies
>Affects Versions: 3.1.1
>Reporter: Jörg Delker
>Priority: Major
>
> When using the unpack goal to extract an artifact dependency, that action is
> performed regardless of any previous run which already created a marker file.
> Consider this pom extract:
> {noformat}
>
> org.apache.maven.plugins
> maven-dependency-plugin
> 3.1.1
>
>
> unpack
> generate-sources
>
> unpack
>
>
> ${my.excludes}
>
>
> groupid
> artifactid
> war
> false
>
>
>
>
>
> {noformat}
> After executing "mvn generate-sources", the following marker file has been
> created:
> {{target/dependency-maven-plugin-markers/myartifactfile-1.01480985089}}
> Obviously, this file is not checked when this run is repeated.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (MDEP-629) Unpack goal with includes/excludes doer not honor marker files
Jörg Delker created MDEP-629:
Summary: Unpack goal with includes/excludes doer not honor marker
files
Key: MDEP-629
URL: https://issues.apache.org/jira/browse/MDEP-629
Project: Maven Dependency Plugin
Issue Type: Bug
Components: unpack, unpack-dependencies
Affects Versions: 3.1.1
Reporter: Jörg Delker
When using the unpack goal to extract an artifact dependency, that action is
performed regardless of any previous run which already created a marker file.
Consider this pom extract:
{noformat}
org.apache.maven.plugins
maven-dependency-plugin
3.1.1
unpack
generate-sources
unpack
${my.excludes}
groupid
artifactid
war
false
{noformat}
After executing "mvn generate-sources", the following marker file has been
created:
{{target/dependency-maven-plugin-markers/myartifactfile-1.01480985089}}
Obviously, this file is not checked when this run is repeated.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
