[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=16625393#comment-16625393 ] Hudson commented on MNG-6479: - Build unstable in Jenkins: Maven TLP » maven » MNG-6391 #21 See https://builds.apache.org/job/maven-box/job/maven/job/MNG-6391/21/ > 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 >Priority: Trivial > Fix For: 3.6.0-candidate > > > 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-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=16625394#comment-16625394
]
Hudson commented on MNG-6480:
-
Build unstable in Jenkins: Maven TLP » maven » MNG-6391 #21
See https://builds.apache.org/job/maven-box/job/maven/job/MNG-6391/21/
> 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
>
[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=16625390#comment-16625390
]
Hudson commented on MNG-6414:
-
Build unstable in Jenkins: Maven TLP » maven » MNG-6391 #21
See https://builds.apache.org/job/maven-box/job/maven/job/MNG-6391/21/
> 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-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=16625395#comment-16625395
]
Hudson commented on MNG-6391:
-
Build unstable in Jenkins: Maven TLP » maven » MNG-6391 #21
See https://builds.apache.org/job/maven-box/job/maven/job/MNG-6391/21/
> 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] (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=16625391#comment-16625391
]
Hudson commented on MNG-5951:
-
Build unstable in Jenkins: Maven TLP » maven » MNG-6391 #21
See https://builds.apache.org/job/maven-box/job/maven/job/MNG-6391/21/
> 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-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=16625389#comment-16625389 ] Hudson commented on MNG-6478: - Build unstable in Jenkins: Maven TLP » maven » MNG-6391 #21 See https://builds.apache.org/job/maven-box/job/maven/job/MNG-6391/21/ > 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-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=16625392#comment-16625392
]
Hudson commented on MNG-6358:
-
Build unstable in Jenkins: Maven TLP » maven » MNG-6391 #21
See https://builds.apache.org/job/maven-box/job/maven/job/MNG-6391/21/
> 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 the following articles:
> [ERROR] [Help 1]
>
[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=16625388#comment-16625388 ] Hudson commented on MNG-6311: - Build unstable in Jenkins: Maven TLP » maven » MNG-6391 #21 See https://builds.apache.org/job/maven-box/job/maven/job/MNG-6391/21/ > 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)
[GitHub] tawek opened a new pull request #22: Introduce caching for tracking files.
tawek opened a new pull request #22: Introduce caching for tracking files. URL: https://github.com/apache/maven-resolver/pull/22 Reason: The tracking file manager typically in large m2e projects will be used hundreds of times (due to hundreds of artifacts). If the projects are refreshed the files are re-read again and again. This could amount to as much as 43% of time spent in m2e MavenBuilder (in my scenario on Windows platform) Changes: This commit introduces the read cache for tracking files assuming that those files do not change frequently (or at all). The cache entries are verified once per minute if the underlying file had changed its lastModified timestamp and if so they are re-read. If the file timestamp had not changed the entry is valid for one more minute. Additionally since on Windows canonicalization is expensive operation it is also being cached. Cached properties are defensively copied when returned. TODOs: - the cache is unbounded and there is no clearing policy based on LRU and maximum size (for instance). However for typical usages this will not be a problem since number of artifacts is probably couple of thousands and should not pose a problem for memory. I'm making this PR without much hope of approving it - this may not be something that is perceived as problematic by maintainers of this library, but I've stumbled on this issue while profiling m2e builds which are taking quite long (and I've decided to do something about it). This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Updated] (MRRESOURCES-106) ProcessRemoteResourcesMojo#getProjects() can end up consuming a lot of memory for big projects
[ https://issues.apache.org/jira/browse/MRRESOURCES-106?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hervé Boutemy updated MRRESOURCES-106: -- Fix Version/s: (was: 1.6.0) > ProcessRemoteResourcesMojo#getProjects() can end up consuming a lot of memory > for big projects > -- > > Key: MRRESOURCES-106 > URL: https://issues.apache.org/jira/browse/MRRESOURCES-106 > Project: Maven Remote Resources Plugin > Issue Type: Bug >Affects Versions: 1.5 >Reporter: Thomas Mortagne >Assignee: Hervé Boutemy >Priority: Major > > At XWiki we are using the remote resource plugin to generate a NOTICE files > we put in the META-INF of all jars. The file can be found on > https://github.com/xwiki/xwiki-commons/blob/master/xwiki-commons-tools/xwiki-commons-tool-license-resources/src/main/resources/META-INF/NOTICE.vm. > We have a lot of memory issues and we kept increasing the max memory but it > was starting to be a bit insane (we now get a OOM with -Xmx2500m) so I > finally took a profiler to try to figure out where all this memory goes. > We did noticed for a while that remote resource plugin is taking longer and > longer to execute during the build so I had my doubts already. > What Yourkit is telling me is that almost half of the memory (400MB here > because I reduced the max memory for it to fail earlier) is retained by an > ArrayList of MavenProject instances located in > ProcessRemoteResourcesMojo#getProjects(). > It can be reproduced by building https://github.com/xwiki/xwiki-platform (you > will need to add some repositories in your settings.xml, you can find them on > http://dev.xwiki.org/xwiki/bin/view/Community/Building/#HInstallingMaven). > Also I can probably put the memory dump I have somewhere if someone wants to > download it. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Reopened] (MRRESOURCES-106) ProcessRemoteResourcesMojo#getProjects() can end up consuming a lot of memory for big projects
[ https://issues.apache.org/jira/browse/MRRESOURCES-106?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hervé Boutemy reopened MRRESOURCES-106: --- ok, reopening and changing the "duplicates" link to "relates to" do you know why getProjects() can be so resource intensive? > ProcessRemoteResourcesMojo#getProjects() can end up consuming a lot of memory > for big projects > -- > > Key: MRRESOURCES-106 > URL: https://issues.apache.org/jira/browse/MRRESOURCES-106 > Project: Maven Remote Resources Plugin > Issue Type: Bug >Affects Versions: 1.5 >Reporter: Thomas Mortagne >Assignee: Hervé Boutemy >Priority: Major > Fix For: 1.6.0 > > > At XWiki we are using the remote resource plugin to generate a NOTICE files > we put in the META-INF of all jars. The file can be found on > https://github.com/xwiki/xwiki-commons/blob/master/xwiki-commons-tools/xwiki-commons-tool-license-resources/src/main/resources/META-INF/NOTICE.vm. > We have a lot of memory issues and we kept increasing the max memory but it > was starting to be a bit insane (we now get a OOM with -Xmx2500m) so I > finally took a profiler to try to figure out where all this memory goes. > We did noticed for a while that remote resource plugin is taking longer and > longer to execute during the build so I had my doubts already. > What Yourkit is telling me is that almost half of the memory (400MB here > because I reduced the max memory for it to fail earlier) is retained by an > ArrayList of MavenProject instances located in > ProcessRemoteResourcesMojo#getProjects(). > It can be reproduced by building https://github.com/xwiki/xwiki-platform (you > will need to add some repositories in your settings.xml, you can find them on > http://dev.xwiki.org/xwiki/bin/view/Community/Building/#HInstallingMaven). > Also I can probably put the memory dump I have somewhere if someone wants to > download it. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (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:all-tabpanel ] Robert Scholte updated MNG-6415: Fix Version/s: 3.6.0-candidate > 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 >Priority: Major > Labels: CLASSPATH, up-for-grabs > Fix For: 3.6.0-candidate > > 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] (MRRESOURCES-94) Performance issue in ProcessRemoteResourcesMojo.configureVelocityContext(...)
[
https://issues.apache.org/jira/browse/MRRESOURCES-94?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16625247#comment-16625247
]
Falko Modler commented on MRRESOURCES-94:
-
I'd like to point out that the fix that has just been merged is only a solution
for those who *don't* use {{projects}} / {{projectsSortedByOrganization}} or
who don't even use velocity templates.
> Performance issue in ProcessRemoteResourcesMojo.configureVelocityContext(...)
> -
>
> Key: MRRESOURCES-94
> URL: https://issues.apache.org/jira/browse/MRRESOURCES-94
> Project: Maven Remote Resources Plugin
> Issue Type: Bug
>Affects Versions: 1.5
>Reporter: Falko Modler
>Assignee: Hervé Boutemy
>Priority: Major
> Fix For: 1.6.0
>
>
> I was wondering why our multi-threaded maven build of 80+ modules took so
> long even when excluding tests. I checked every plugin execution and to my
> surprise, {{maven-remote-resources-plugin}} was the number 1 consumer
> *before* compiler-plugin etc.
> We use {{maven-remote-resources-plugin}} just to exchange some few xml files
> among the modules, nothing spectacular!
> While debugging the plugin I found out that
> {{ProcessRemoteResourcesMojo.configureVelocityContext(VelocityContext
> context)}} may take *up to 30 seconds* for our project setup which is not
> acceptable.
> Almost certainly the problem is caused by the following project lookups
> (especially {{getProjects()}}):
> {noformat}
> List projects = getProjects();
> context.put( "projects", projects );
> context.put( "projectsSortedByOrganization",
> getProjectsSortedByOrganization( projects ) );
> {noformat}
> As we do not use velocity templates at all, the solution for us was to patch
> the plugin to call {{configureVelocityContext(...)}} only on demand, not
> eagerly. Of course this won't help when using velocity templates...
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MRRESOURCES-106) ProcessRemoteResourcesMojo#getProjects() can end up consuming a lot of memory for big projects
[
https://issues.apache.org/jira/browse/MRRESOURCES-106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16625246#comment-16625246
]
Falko Modler commented on MRRESOURCES-106:
--
[~hboutemy] I don't think my fix for MRRESOURCES-94 is going to help here:
The OP is actually using a velocity template which does use
{{projectsSortedByOrganization}}, so the (expensive) lookup will still kick in,
only at a later point.
> ProcessRemoteResourcesMojo#getProjects() can end up consuming a lot of memory
> for big projects
> --
>
> Key: MRRESOURCES-106
> URL: https://issues.apache.org/jira/browse/MRRESOURCES-106
> Project: Maven Remote Resources Plugin
> Issue Type: Bug
>Affects Versions: 1.5
>Reporter: Thomas Mortagne
>Assignee: Hervé Boutemy
>Priority: Major
> Fix For: 1.6.0
>
>
> At XWiki we are using the remote resource plugin to generate a NOTICE files
> we put in the META-INF of all jars. The file can be found on
> https://github.com/xwiki/xwiki-commons/blob/master/xwiki-commons-tools/xwiki-commons-tool-license-resources/src/main/resources/META-INF/NOTICE.vm.
> We have a lot of memory issues and we kept increasing the max memory but it
> was starting to be a bit insane (we now get a OOM with -Xmx2500m) so I
> finally took a profiler to try to figure out where all this memory goes.
> We did noticed for a while that remote resource plugin is taking longer and
> longer to execute during the build so I had my doubts already.
> What Yourkit is telling me is that almost half of the memory (400MB here
> because I reduced the max memory for it to fail earlier) is retained by an
> ArrayList of MavenProject instances located in
> ProcessRemoteResourcesMojo#getProjects().
> It can be reproduced by building https://github.com/xwiki/xwiki-platform (you
> will need to add some repositories in your settings.xml, you can find them on
> http://dev.xwiki.org/xwiki/bin/view/Community/Building/#HInstallingMaven).
> Also I can probably put the memory dump I have somewhere if someone wants to
> download it.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MRRESOURCES-94) Performance issue in ProcessRemoteResourcesMojo.configureVelocityContext(...)
[
https://issues.apache.org/jira/browse/MRRESOURCES-94?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16625245#comment-16625245
]
ASF GitHub Bot commented on MRRESOURCES-94:
---
Github user famod closed the pull request at:
https://github.com/apache/maven-plugins/pull/124
> Performance issue in ProcessRemoteResourcesMojo.configureVelocityContext(...)
> -
>
> Key: MRRESOURCES-94
> URL: https://issues.apache.org/jira/browse/MRRESOURCES-94
> Project: Maven Remote Resources Plugin
> Issue Type: Bug
>Affects Versions: 1.5
>Reporter: Falko Modler
>Assignee: Hervé Boutemy
>Priority: Major
> Fix For: 1.6.0
>
>
> I was wondering why our multi-threaded maven build of 80+ modules took so
> long even when excluding tests. I checked every plugin execution and to my
> surprise, {{maven-remote-resources-plugin}} was the number 1 consumer
> *before* compiler-plugin etc.
> We use {{maven-remote-resources-plugin}} just to exchange some few xml files
> among the modules, nothing spectacular!
> While debugging the plugin I found out that
> {{ProcessRemoteResourcesMojo.configureVelocityContext(VelocityContext
> context)}} may take *up to 30 seconds* for our project setup which is not
> acceptable.
> Almost certainly the problem is caused by the following project lookups
> (especially {{getProjects()}}):
> {noformat}
> List projects = getProjects();
> context.put( "projects", projects );
> context.put( "projectsSortedByOrganization",
> getProjectsSortedByOrganization( projects ) );
> {noformat}
> As we do not use velocity templates at all, the solution for us was to patch
> the plugin to call {{configureVelocityContext(...)}} only on demand, not
> eagerly. Of course this won't help when using velocity templates...
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MRRESOURCES-94) Performance issue in ProcessRemoteResourcesMojo.configureVelocityContext(...)
[
https://issues.apache.org/jira/browse/MRRESOURCES-94?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16625244#comment-16625244
]
ASF GitHub Bot commented on MRRESOURCES-94:
---
Github user famod closed the pull request at:
https://github.com/apache/maven-plugins/pull/123
> Performance issue in ProcessRemoteResourcesMojo.configureVelocityContext(...)
> -
>
> Key: MRRESOURCES-94
> URL: https://issues.apache.org/jira/browse/MRRESOURCES-94
> Project: Maven Remote Resources Plugin
> Issue Type: Bug
>Affects Versions: 1.5
>Reporter: Falko Modler
>Assignee: Hervé Boutemy
>Priority: Major
> Fix For: 1.6.0
>
>
> I was wondering why our multi-threaded maven build of 80+ modules took so
> long even when excluding tests. I checked every plugin execution and to my
> surprise, {{maven-remote-resources-plugin}} was the number 1 consumer
> *before* compiler-plugin etc.
> We use {{maven-remote-resources-plugin}} just to exchange some few xml files
> among the modules, nothing spectacular!
> While debugging the plugin I found out that
> {{ProcessRemoteResourcesMojo.configureVelocityContext(VelocityContext
> context)}} may take *up to 30 seconds* for our project setup which is not
> acceptable.
> Almost certainly the problem is caused by the following project lookups
> (especially {{getProjects()}}):
> {noformat}
> List projects = getProjects();
> context.put( "projects", projects );
> context.put( "projectsSortedByOrganization",
> getProjectsSortedByOrganization( projects ) );
> {noformat}
> As we do not use velocity templates at all, the solution for us was to patch
> the plugin to call {{configureVelocityContext(...)}} only on demand, not
> eagerly. Of course this won't help when using velocity templates...
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (MRRESOURCES-106) ProcessRemoteResourcesMojo#getProjects() can end up consuming a lot of memory for big projects
[ https://issues.apache.org/jira/browse/MRRESOURCES-106?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hervé Boutemy closed MRRESOURCES-106. - Resolution: Fixed Assignee: Hervé Boutemy fixed in MRRESOURCES-94 > ProcessRemoteResourcesMojo#getProjects() can end up consuming a lot of memory > for big projects > -- > > Key: MRRESOURCES-106 > URL: https://issues.apache.org/jira/browse/MRRESOURCES-106 > Project: Maven Remote Resources Plugin > Issue Type: Bug >Affects Versions: 1.5 >Reporter: Thomas Mortagne >Assignee: Hervé Boutemy >Priority: Major > Fix For: 1.6.0 > > > At XWiki we are using the remote resource plugin to generate a NOTICE files > we put in the META-INF of all jars. The file can be found on > https://github.com/xwiki/xwiki-commons/blob/master/xwiki-commons-tools/xwiki-commons-tool-license-resources/src/main/resources/META-INF/NOTICE.vm. > We have a lot of memory issues and we kept increasing the max memory but it > was starting to be a bit insane (we now get a OOM with -Xmx2500m) so I > finally took a profiler to try to figure out where all this memory goes. > We did noticed for a while that remote resource plugin is taking longer and > longer to execute during the build so I had my doubts already. > What Yourkit is telling me is that almost half of the memory (400MB here > because I reduced the max memory for it to fail earlier) is retained by an > ArrayList of MavenProject instances located in > ProcessRemoteResourcesMojo#getProjects(). > It can be reproduced by building https://github.com/xwiki/xwiki-platform (you > will need to add some repositories in your settings.xml, you can find them on > http://dev.xwiki.org/xwiki/bin/view/Community/Building/#HInstallingMaven). > Also I can probably put the memory dump I have somewhere if someone wants to > download it. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (MRRESOURCES-94) Performance issue in ProcessRemoteResourcesMojo.configureVelocityContext(...)
[
https://issues.apache.org/jira/browse/MRRESOURCES-94?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hervé Boutemy closed MRRESOURCES-94.
Resolution: Fixed
Assignee: Hervé Boutemy
fixed by providing project* values lazily
https://gitbox.apache.org/repos/asf?p=maven-remote-resources-plugin.git=commit=0f09659d52e0d6aa5af487a6c591c223cfafa34f
thank you Falko
> Performance issue in ProcessRemoteResourcesMojo.configureVelocityContext(...)
> -
>
> Key: MRRESOURCES-94
> URL: https://issues.apache.org/jira/browse/MRRESOURCES-94
> Project: Maven Remote Resources Plugin
> Issue Type: Bug
>Affects Versions: 1.5
>Reporter: Falko Modler
>Assignee: Hervé Boutemy
>Priority: Major
> Fix For: 1.6.0
>
>
> I was wondering why our multi-threaded maven build of 80+ modules took so
> long even when excluding tests. I checked every plugin execution and to my
> surprise, {{maven-remote-resources-plugin}} was the number 1 consumer
> *before* compiler-plugin etc.
> We use {{maven-remote-resources-plugin}} just to exchange some few xml files
> among the modules, nothing spectacular!
> While debugging the plugin I found out that
> {{ProcessRemoteResourcesMojo.configureVelocityContext(VelocityContext
> context)}} may take *up to 30 seconds* for our project setup which is not
> acceptable.
> Almost certainly the problem is caused by the following project lookups
> (especially {{getProjects()}}):
> {noformat}
> List projects = getProjects();
> context.put( "projects", projects );
> context.put( "projectsSortedByOrganization",
> getProjectsSortedByOrganization( projects ) );
> {noformat}
> As we do not use velocity templates at all, the solution for us was to patch
> the plugin to call {{configureVelocityContext(...)}} only on demand, not
> eagerly. Of course this won't help when using velocity templates...
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MRRESOURCES-94) Performance issue in ProcessRemoteResourcesMojo.configureVelocityContext(...)
[
https://issues.apache.org/jira/browse/MRRESOURCES-94?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16625228#comment-16625228
]
Hudson commented on MRRESOURCES-94:
---
Build succeeded in Jenkins: Maven TLP » maven-remote-resources-plugin » master
#31
See
https://builds.apache.org/job/maven-box/job/maven-remote-resources-plugin/job/master/31/
> Performance issue in ProcessRemoteResourcesMojo.configureVelocityContext(...)
> -
>
> Key: MRRESOURCES-94
> URL: https://issues.apache.org/jira/browse/MRRESOURCES-94
> Project: Maven Remote Resources Plugin
> Issue Type: Bug
>Affects Versions: 1.5
>Reporter: Falko Modler
>Priority: Major
> Fix For: 1.6.0
>
>
> I was wondering why our multi-threaded maven build of 80+ modules took so
> long even when excluding tests. I checked every plugin execution and to my
> surprise, {{maven-remote-resources-plugin}} was the number 1 consumer
> *before* compiler-plugin etc.
> We use {{maven-remote-resources-plugin}} just to exchange some few xml files
> among the modules, nothing spectacular!
> While debugging the plugin I found out that
> {{ProcessRemoteResourcesMojo.configureVelocityContext(VelocityContext
> context)}} may take *up to 30 seconds* for our project setup which is not
> acceptable.
> Almost certainly the problem is caused by the following project lookups
> (especially {{getProjects()}}):
> {noformat}
> List projects = getProjects();
> context.put( "projects", projects );
> context.put( "projectsSortedByOrganization",
> getProjectsSortedByOrganization( projects ) );
> {noformat}
> As we do not use velocity templates at all, the solution for us was to patch
> the plugin to call {{configureVelocityContext(...)}} only on demand, not
> eagerly. Of course this won't help when using velocity templates...
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (MDEPLOY-243) Remove JIRA report from generated site
Karl Heinz Marbaise created MDEPLOY-243: --- Summary: Remove JIRA report from generated site Key: MDEPLOY-243 URL: https://issues.apache.org/jira/browse/MDEPLOY-243 Project: Maven Deploy Plugin Issue Type: Task Affects Versions: 3.0.0-M1 Reporter: Karl Heinz Marbaise Fix For: 3.0.0 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MRRESOURCES-85) Add m2e mapping
[
https://issues.apache.org/jira/browse/MRRESOURCES-85?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16625171#comment-16625171
]
Karl Heinz Marbaise commented on MRRESOURCES-85:
Unfortunately yes, cause I don't have implemented the BuildContext API yet...
> Add m2e mapping
> ---
>
> Key: MRRESOURCES-85
> URL: https://issues.apache.org/jira/browse/MRRESOURCES-85
> Project: Maven Remote Resources Plugin
> Issue Type: Improvement
>Affects Versions: 1.6.0
>Reporter: Karl Heinz Marbaise
>Priority: Minor
> Fix For: 1.6.0
>
>
> Add mapping for m2e for plugin something like this.
> {code:xml}
>
>
>
>
>
>
> bundle
> process
>
>
>
>
> true
> true
>
>
>
>
>
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MRRESOURCES-85) Add m2e mapping
[
https://issues.apache.org/jira/browse/MRRESOURCES-85?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16625168#comment-16625168
]
Hervé Boutemy commented on MRRESOURCES-85:
--
[~khmarbaise] is there anything preventing you to commit this?
> Add m2e mapping
> ---
>
> Key: MRRESOURCES-85
> URL: https://issues.apache.org/jira/browse/MRRESOURCES-85
> Project: Maven Remote Resources Plugin
> Issue Type: Improvement
>Affects Versions: 1.6.0
>Reporter: Karl Heinz Marbaise
>Priority: Minor
> Fix For: 1.6.0
>
>
> Add mapping for m2e for plugin something like this.
> {code:xml}
>
>
>
>
>
>
> bundle
> process
>
>
>
>
> true
> true
>
>
>
>
>
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (MRRESOURCES-110) Upgrade parent to version 33
[ https://issues.apache.org/jira/browse/MRRESOURCES-110?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hervé Boutemy closed MRRESOURCES-110. - Resolution: Fixed Assignee: Hervé Boutemy https://gitbox.apache.org/repos/asf?p=maven-remote-resources-plugin.git;a=commit;h=5311144095a52683d78d28ea554d6083e7dc37b1 > Upgrade parent to version 33 > > > Key: MRRESOURCES-110 > URL: https://issues.apache.org/jira/browse/MRRESOURCES-110 > Project: Maven Remote Resources Plugin > Issue Type: Dependency upgrade >Affects Versions: 1.6.0 >Reporter: Karl Heinz Marbaise >Assignee: Hervé Boutemy >Priority: Minor > Fix For: 1.6.0 > > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (MJAR-257) Option to strip non-deterministic aspects of jars post-reation
Paul Hammant created MJAR-257: - Summary: Option to strip non-deterministic aspects of jars post-reation Key: MJAR-257 URL: https://issues.apache.org/jira/browse/MJAR-257 Project: Maven JAR Plugin Issue Type: New Feature Reporter: Paul Hammant [https://github.com/esoule/strip-nondeterminism] is a Perl script to do the same. These things could be replicated in Java, and it would be good for the community to attempt to chase some of the features of other build technologies, and initiatives. Optional of course: true -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MDEPLOY-242) Lift JDK minimum to JDK 7
[ https://issues.apache.org/jira/browse/MDEPLOY-242?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16625099#comment-16625099 ] Hudson commented on MDEPLOY-242: Build succeeded in Jenkins: Maven TLP » maven-deploy-plugin » master #30 See https://builds.apache.org/job/maven-box/job/maven-deploy-plugin/job/master/30/ > Lift JDK minimum to JDK 7 > - > > Key: MDEPLOY-242 > URL: https://issues.apache.org/jira/browse/MDEPLOY-242 > Project: Maven Deploy Plugin > Issue Type: Task >Affects Versions: 3.0.0 >Reporter: Karl Heinz Marbaise >Assignee: Karl Heinz Marbaise >Priority: Minor > Fix For: 3.0.0 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MINSTALL-150) Lift JDK minimum to JDK 7
[ https://issues.apache.org/jira/browse/MINSTALL-150?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16625098#comment-16625098 ] Hudson commented on MINSTALL-150: - Build succeeded in Jenkins: Maven TLP » maven-install-plugin » master #29 See https://builds.apache.org/job/maven-box/job/maven-install-plugin/job/master/29/ > Lift JDK minimum to JDK 7 > - > > Key: MINSTALL-150 > URL: https://issues.apache.org/jira/browse/MINSTALL-150 > Project: Maven Install Plugin > Issue Type: Task >Affects Versions: 3.0.0 >Reporter: Karl Heinz Marbaise >Assignee: Karl Heinz Marbaise >Priority: Minor > Fix For: 3.0.0 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MINSTALL-150) Lift JDK minimum to JDK 7
[ https://issues.apache.org/jira/browse/MINSTALL-150?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16625096#comment-16625096 ] Karl Heinz Marbaise commented on MINSTALL-150: -- Done in [c5b4c19e1f5a707e01f1fbdf856568d47f0d158f|https://gitbox.apache.org/repos/asf?p=maven-install-plugin.git;a=commitdiff;h=c5b4c19e1f5a707e01f1fbdf856568d47f0d158f] > Lift JDK minimum to JDK 7 > - > > Key: MINSTALL-150 > URL: https://issues.apache.org/jira/browse/MINSTALL-150 > Project: Maven Install Plugin > Issue Type: Task >Affects Versions: 3.0.0 >Reporter: Karl Heinz Marbaise >Assignee: Karl Heinz Marbaise >Priority: Minor > Fix For: 3.0.0 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (MDEPLOY-242) Lift JDK minimum to JDK 7
[ https://issues.apache.org/jira/browse/MDEPLOY-242?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Heinz Marbaise closed MDEPLOY-242. --- Resolution: Done > Lift JDK minimum to JDK 7 > - > > Key: MDEPLOY-242 > URL: https://issues.apache.org/jira/browse/MDEPLOY-242 > Project: Maven Deploy Plugin > Issue Type: Task >Affects Versions: 3.0.0 >Reporter: Karl Heinz Marbaise >Assignee: Karl Heinz Marbaise >Priority: Minor > Fix For: 3.0.0 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (MINSTALL-150) Lift JDK minimum to JDK 7
[ https://issues.apache.org/jira/browse/MINSTALL-150?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Heinz Marbaise closed MINSTALL-150. Resolution: Done > Lift JDK minimum to JDK 7 > - > > Key: MINSTALL-150 > URL: https://issues.apache.org/jira/browse/MINSTALL-150 > Project: Maven Install Plugin > Issue Type: Task >Affects Versions: 3.0.0 >Reporter: Karl Heinz Marbaise >Assignee: Karl Heinz Marbaise >Priority: Minor > Fix For: 3.0.0 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MDEPLOY-242) Lift JDK minimum to JDK 7
[ https://issues.apache.org/jira/browse/MDEPLOY-242?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16625097#comment-16625097 ] Karl Heinz Marbaise commented on MDEPLOY-242: - Done in [54329afd813cfca8c298eda1710468578998224d|https://gitbox.apache.org/repos/asf?p=maven-deploy-plugin.git;a=commitdiff;h=54329afd813cfca8c298eda1710468578998224d] > Lift JDK minimum to JDK 7 > - > > Key: MDEPLOY-242 > URL: https://issues.apache.org/jira/browse/MDEPLOY-242 > Project: Maven Deploy Plugin > Issue Type: Task >Affects Versions: 3.0.0 >Reporter: Karl Heinz Marbaise >Assignee: Karl Heinz Marbaise >Priority: Minor > Fix For: 3.0.0 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (MDEPLOY-242) Lift JDK minimum to JDK 7
Karl Heinz Marbaise created MDEPLOY-242: --- Summary: Lift JDK minimum to JDK 7 Key: MDEPLOY-242 URL: https://issues.apache.org/jira/browse/MDEPLOY-242 Project: Maven Deploy Plugin Issue Type: Task Affects Versions: 3.0.0 Reporter: Karl Heinz Marbaise Assignee: Karl Heinz Marbaise Fix For: 3.0.0 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (MINSTALL-150) Lift JDK minimum to JDK 7
Karl Heinz Marbaise created MINSTALL-150: Summary: Lift JDK minimum to JDK 7 Key: MINSTALL-150 URL: https://issues.apache.org/jira/browse/MINSTALL-150 Project: Maven Install Plugin Issue Type: Task Affects Versions: 3.0.0 Reporter: Karl Heinz Marbaise Assignee: Karl Heinz Marbaise Fix For: 3.0.0 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MINSTALL-149) Remove updateReleaseInfo parameter
[ https://issues.apache.org/jira/browse/MINSTALL-149?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16625087#comment-16625087 ] Hudson commented on MINSTALL-149: - Build succeeded in Jenkins: Maven TLP » maven-install-plugin » master #27 See https://builds.apache.org/job/maven-box/job/maven-install-plugin/job/master/27/ > Remove updateReleaseInfo parameter > -- > > Key: MINSTALL-149 > URL: https://issues.apache.org/jira/browse/MINSTALL-149 > Project: Maven Install Plugin > Issue Type: Task >Affects Versions: 3.0.0 >Reporter: Karl Heinz Marbaise >Assignee: Karl Heinz Marbaise >Priority: Blocker > Fix For: 3.0.0 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MINSTALL-149) Remove updateReleaseInfo parameter
[ https://issues.apache.org/jira/browse/MINSTALL-149?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16625086#comment-16625086 ] Karl Heinz Marbaise commented on MINSTALL-149: -- Done in [63a36963dcc16baf6ee412bbb3cf0656d1deae3f|https://gitbox.apache.org/repos/asf?p=maven-install-plugin.git;a=commitdiff;h=63a36963dcc16baf6ee412bbb3cf0656d1deae3f] > Remove updateReleaseInfo parameter > -- > > Key: MINSTALL-149 > URL: https://issues.apache.org/jira/browse/MINSTALL-149 > Project: Maven Install Plugin > Issue Type: Task >Affects Versions: 3.0.0 >Reporter: Karl Heinz Marbaise >Assignee: Karl Heinz Marbaise >Priority: Blocker > Fix For: 3.0.0 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (MINSTALL-149) Remove updateReleaseInfo parameter
[ https://issues.apache.org/jira/browse/MINSTALL-149?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Heinz Marbaise closed MINSTALL-149. Resolution: Done > Remove updateReleaseInfo parameter > -- > > Key: MINSTALL-149 > URL: https://issues.apache.org/jira/browse/MINSTALL-149 > Project: Maven Install Plugin > Issue Type: Task >Affects Versions: 3.0.0 >Reporter: Karl Heinz Marbaise >Assignee: Karl Heinz Marbaise >Priority: Blocker > Fix For: 3.0.0 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MINSTALL-148) Document change about createChecksums
[ https://issues.apache.org/jira/browse/MINSTALL-148?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16625078#comment-16625078 ] Karl Heinz Marbaise commented on MINSTALL-148: -- Done in [82374f1aac324f3a529a0754d72685f3dda10ae8|https://gitbox.apache.org/repos/asf?p=maven-install-plugin.git;a=commitdiff;h=82374f1aac324f3a529a0754d72685f3dda10ae8] > Document change about createChecksums > - > > Key: MINSTALL-148 > URL: https://issues.apache.org/jira/browse/MINSTALL-148 > Project: Maven Install Plugin > Issue Type: Task >Affects Versions: 3.0.0 >Reporter: Karl Heinz Marbaise >Assignee: Karl Heinz Marbaise >Priority: Blocker > Fix For: 3.0.0 > > > Document change about createChecksums and remove documentation about create > checksums from plugin. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (MINSTALL-148) Document change about createChecksums
[ https://issues.apache.org/jira/browse/MINSTALL-148?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Heinz Marbaise closed MINSTALL-148. Resolution: Done > Document change about createChecksums > - > > Key: MINSTALL-148 > URL: https://issues.apache.org/jira/browse/MINSTALL-148 > Project: Maven Install Plugin > Issue Type: Task >Affects Versions: 3.0.0 >Reporter: Karl Heinz Marbaise >Assignee: Karl Heinz Marbaise >Priority: Blocker > Fix For: 3.0.0 > > > Document change about createChecksums and remove documentation about create > checksums from plugin. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MINSTALL-148) Document change about createChecksums
[ https://issues.apache.org/jira/browse/MINSTALL-148?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16625077#comment-16625077 ] Hudson commented on MINSTALL-148: - Build succeeded in Jenkins: Maven TLP » maven-install-plugin » master #26 See https://builds.apache.org/job/maven-box/job/maven-install-plugin/job/master/26/ > Document change about createChecksums > - > > Key: MINSTALL-148 > URL: https://issues.apache.org/jira/browse/MINSTALL-148 > Project: Maven Install Plugin > Issue Type: Task >Affects Versions: 3.0.0 >Reporter: Karl Heinz Marbaise >Assignee: Karl Heinz Marbaise >Priority: Blocker > Fix For: 3.0.0 > > > Document change about createChecksums and remove documentation about create > checksums from plugin. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MNG-5668) post- should always be executed after
[
https://issues.apache.org/jira/browse/MNG-5668?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16625058#comment-16625058
]
Robert Scholte commented on MNG-5668:
-
Since lifecycle are written as components, only XMLelements can be used.
Inspired by [Ant|http://ant-contrib.sourceforge.net/tasks/tasks/trycatch.html]
we could do something similar:
{code:xml}
pre-integration-test
integration-test
pre-integration-test
{code}
> post- should always be executed after
>
>
> Key: MNG-5668
> URL: https://issues.apache.org/jira/browse/MNG-5668
> Project: Maven
> Issue Type: Sub-task
> Components: FDPFC, Plugins and Lifecycle
>Reporter: Robert Scholte
>Assignee: Robert Scholte
>Priority: Major
>
> Original proposal:
> {quote}
> There are right now 3 phases which also have a pre- and post-,
> namely integration-test, clean and site. However, even if one has bound goals
> to the post-phases, they're probably never called.
> When there's an integration-test starting up some server, you'd probably
> always want to kill it no matter what happens during the IT (let say a NPE).
> The proposal is to execute the post- as the finally block in Java. If
> you really want to execute only the integration-test without the post, the
> phase should be marked, e.g. 'mvn [integration-test]', where the brackets
> lock the phase.
> {quote}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MINVOKER-243) invoker:install doesn't copy transitive dependencies anymore (as of 3.1.0)
[
https://issues.apache.org/jira/browse/MINVOKER-243?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16625036#comment-16625036
]
Robert Scholte commented on MINVOKER-243:
-
Maybe good to explain which transitive dependencies. {{invoker:install}} should
only install artifacts that are part from the multimodule project, not any
third party artifact.
> invoker:install doesn't copy transitive dependencies anymore (as of 3.1.0)
> --
>
> Key: MINVOKER-243
> URL: https://issues.apache.org/jira/browse/MINVOKER-243
> Project: Maven Invoker Plugin
> Issue Type: Bug
>Affects Versions: 3.1.0
>Reporter: Christopher Tubbs
>Priority: Blocker
>
> Something seems to have broken between 3.0.1 and 3.1.0, as the install goal
> no longer copies transitive dependencies to the localRepositoryPath as it did
> in version 3.0.1.
> This is very problematic, because if the artifacts are not in the
> localRepositoryPath, the invoked project will try to download them from a
> remote repository, which isn't possible for SNAPSHOT versions (such as those
> in a sibling module in a multi-module project). This can make it difficult to
> even build a multi-module project, unless the invoked task is skipped and the
> sibling module can be published to a remote snapshot repository temporarily,
> and then the build re-executed normally. (Saw this happen in Apache Accumulo
> after upgrading to apache-21.pom)
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (MINSTALL-149) Remove updateReleaseInfo parameter
Karl Heinz Marbaise created MINSTALL-149: Summary: Remove updateReleaseInfo parameter Key: MINSTALL-149 URL: https://issues.apache.org/jira/browse/MINSTALL-149 Project: Maven Install Plugin Issue Type: Task Affects Versions: 3.0.0 Reporter: Karl Heinz Marbaise Assignee: Karl Heinz Marbaise Fix For: 3.0.0 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (MINSTALL-148) Document change about createChecksums
Karl Heinz Marbaise created MINSTALL-148: Summary: Document change about createChecksums Key: MINSTALL-148 URL: https://issues.apache.org/jira/browse/MINSTALL-148 Project: Maven Install Plugin Issue Type: Task Affects Versions: 3.0.0 Reporter: Karl Heinz Marbaise Assignee: Karl Heinz Marbaise Fix For: 3.0.0 Document change about createChecksums and remove documentation about create checksums from plugin. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
