[jira] [Updated] (MSITE-804) update Doxia Site Renderer to 1.8
[ https://issues.apache.org/jira/browse/MSITE-804?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hervé Boutemy updated MSITE-804: Fix Version/s: 3.7 > update Doxia Site Renderer to 1.8 > - > > Key: MSITE-804 > URL: https://issues.apache.org/jira/browse/MSITE-804 > Project: Maven Site Plugin > Issue Type: Improvement > Components: doxia integration >Affects Versions: 3.6 >Reporter: Hervé Boutemy > Fix For: 3.7 > > > to benefit from DOXIASITETOOLS-181 and DOXIASITETOOLS-182 -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (MSITE-804) update Doxia Site Renderer to 1.8
[ https://issues.apache.org/jira/browse/MSITE-804?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hervé Boutemy updated MSITE-804: Affects Version/s: 3.6 > update Doxia Site Renderer to 1.8 > - > > Key: MSITE-804 > URL: https://issues.apache.org/jira/browse/MSITE-804 > Project: Maven Site Plugin > Issue Type: Improvement > Components: doxia integration >Affects Versions: 3.6 >Reporter: Hervé Boutemy > Fix For: 3.7 > > > to benefit from DOXIASITETOOLS-181 and DOXIASITETOOLS-182 -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (MSITE-804) update Doxia Site Renderer to 1.8
[ https://issues.apache.org/jira/browse/MSITE-804?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hervé Boutemy updated MSITE-804: Component/s: doxia integration > update Doxia Site Renderer to 1.8 > - > > Key: MSITE-804 > URL: https://issues.apache.org/jira/browse/MSITE-804 > Project: Maven Site Plugin > Issue Type: Improvement > Components: doxia integration >Affects Versions: 3.6 >Reporter: Hervé Boutemy > Fix For: 3.7 > > > to benefit from DOXIASITETOOLS-181 and DOXIASITETOOLS-182 -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (MSITE-804) update Doxia Site Renderer to 1.8
Hervé Boutemy created MSITE-804: --- Summary: update Doxia Site Renderer to 1.8 Key: MSITE-804 URL: https://issues.apache.org/jira/browse/MSITE-804 Project: Maven Site Plugin Issue Type: Improvement Reporter: Hervé Boutemy to benefit from DOXIASITETOOLS-181 and DOXIASITETOOLS-182 -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[GitHub] maven-surefire issue #166: Support filtering of tests from Base Class (TestN...
Github user krmahadevan commented on the issue: https://github.com/apache/maven-surefire/pull/166 @Tibor17 - Looks like a lot of things changed. Now after rebasing off of master, I dont even get IntelliJ to recognize the test classes that I added. So not sure what is going on there. With respect to the formatting, I have tried importing into the IDE and applying it. But not sure if its actually changing the format. I had a lot of time at my hand when I raised this PR back in October, but now I am currently tied up with a lot of stuff at work. So I am not sure when I am gonna get to this. ---
[jira] [Created] (DOXIASITETOOLS-182) create DocumentContent interface to model SiteRendererSink output
Hervé Boutemy created DOXIASITETOOLS-182: Summary: create DocumentContent interface to model SiteRendererSink output Key: DOXIASITETOOLS-182 URL: https://issues.apache.org/jira/browse/DOXIASITETOOLS-182 Project: Maven Doxia Sitetools Issue Type: Improvement Components: Site renderer Affects Versions: 1.7.5 Reporter: Hervé Boutemy Assignee: Hervé Boutemy Fix For: 1.8 when merging document content into template, the fact that the document content has been created with a Doxia Sink has no meaning: what is important is that the useful output fields are available (title, date, authors, head, body, doc rendering context) creating an interface for this output will ease understanding of the mechanics (and avoid noise about the specific Sink) -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (MNG-6308) display packaging when building a module
[
https://issues.apache.org/jira/browse/MNG-6308?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16286987#comment-16286987
]
Hervé Boutemy commented on MNG-6308:
I like
{noformat}
[INFO] < org.apache.maven:apache-maven:pom >---
[INFO] Building Apache Maven Distribution 3.5.3-SNAPSHOT[15/15]
[INFO]
{noformat}
> display packaging when building a module
>
>
> Key: MNG-6308
> URL: https://issues.apache.org/jira/browse/MNG-6308
> Project: Maven
> Issue Type: Improvement
>Affects Versions: 3.5.2
>Reporter: Hervé Boutemy
>Assignee: Hervé Boutemy
>
> Packaging is a key information, since it defines what bindings will be: it is
> short and should be visible in the build log
> proposal:
> {code}[INFO]
>
> [INFO] Building Apache Maven Distribution 3.5.3-SNAPSHOT
> [15/15]
> [INFO] --- pom
> --{code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (WAGON-486) Wagon fails to download artifacts if number of dropped pooled connections (by intermediate) are greater than default retry count
[ https://issues.apache.org/jira/browse/WAGON-486?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16286848#comment-16286848 ] Matt Nelson commented on WAGON-486: --- Jumped the gun on this one a little bit, turns out the root cause was actually MRESOLVER-25 > Wagon fails to download artifacts if number of dropped pooled connections (by > intermediate) are greater than default retry count > > > Key: WAGON-486 > URL: https://issues.apache.org/jira/browse/WAGON-486 > Project: Maven Wagon > Issue Type: Bug >Reporter: Martin Myslík > Attachments: build-failure-maven-3.5.0-patched-debug-updated.txt, > build-failure-maven-3.5.0-patched-debug.txt, build-failure-vanilla.txt, > build-success-keep-alive-false.txt, > build-success-maven-3.5.0-patched-debug.txt, build-success-pooling-false.txt, > dump-failed-build.pcap, dump.pcap > > > I was recently discussing and issue with Atlassian team concerning failing > build on Atlassian Pipelines when running Maven build for more than 5 minutes. > The issue was with NAT timeout which kills all idle connections after 5 > mintues and Maven does not try to reconnect once the connection is killed > (and hence cannot download artifacts from Maven central). > Please, take a look at the open issue (it contains more detailed description > and also comments from Atlassian which suggested opening an issue with > Maven): > https://bitbucket.org/site/master/issues/13988/pipelines-kills-idle-maven-connections > Could you, please, take a minute and explain how could proceed with solving > this issue? I am not sure whether this is something that Maven should handle > or whether it is Atlassians issue. > Thank you for your input. > This is the link to my public repo with test project running tests for 15 > mintues. This build fails on Pipelines because of Maven connection that is > being killed during the test: https://bitbucket.org/Smedzlatko/del-me -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (MNG-6298) 3.5.2: ClassNotFoundException: javax.annotation.security.RolesAllowed
[
https://issues.apache.org/jira/browse/MNG-6298?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16286382#comment-16286382
]
Bengt Söderberg commented on MNG-6298:
--
Done. Added minimal regression test that fails without the fix. Unsure about
versioning so set it to 3.5.3 and onwards for now, range of test might need
adjusting depending on version it ends up in.
> 3.5.2: ClassNotFoundException: javax.annotation.security.RolesAllowed
> -
>
> Key: MNG-6298
> URL: https://issues.apache.org/jira/browse/MNG-6298
> Project: Maven
> Issue Type: Bug
> Components: Class Loading
>Affects Versions: 3.5.2
> Environment: Mac OS X 10.12.6, Ubuntu 15.10 64 bit, and Windows is
> presumed.
>Reporter: Ryan Heaton
>Priority: Critical
> Fix For: 3.5.3-candidate
>
>
> Maven 3.5.2 appears to have introduces some kind of a class loading error,
> manifesting itself like this:
> {noformat}
> Caused by: java.lang.ClassNotFoundException:
> javax.annotation.security.RolesAllowed
> at
> org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy.loadClass(SelfFirstStrategy.java:50)
> at
> org.codehaus.plexus.classworlds.realm.ClassRealm.unsynchronizedLoadClass(ClassRealm.java:271)
> at
> org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm.java:247)
> at
> org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm.java:239)
> ... 184 more
> {noformat}
> Previous versions of Maven do not manifest this.
> To reproduce this:
> * Clone [the Enunciate sample
> project|https://github.com/stoicflame/enunciate-sample].
> * Build the project (mvn clean package) with 3.5.0 and note the success.
> * Build the project with 3.5.2 and note the failure.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (MNG-6308) display packaging when building a module
[
https://issues.apache.org/jira/browse/MNG-6308?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16286504#comment-16286504
]
Michael Osipov commented on MNG-6308:
-
No duplication, exactly the way you have depicted.
> display packaging when building a module
>
>
> Key: MNG-6308
> URL: https://issues.apache.org/jira/browse/MNG-6308
> Project: Maven
> Issue Type: Improvement
>Affects Versions: 3.5.2
>Reporter: Hervé Boutemy
>Assignee: Hervé Boutemy
>
> Packaging is a key information, since it defines what bindings will be: it is
> short and should be visible in the build log
> proposal:
> {code}[INFO]
>
> [INFO] Building Apache Maven Distribution 3.5.3-SNAPSHOT
> [15/15]
> [INFO] --- pom
> --{code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (WAGON-486) Wagon fails to download artifacts if number of dropped pooled connections (by intermediate) are greater than default retry count
[
https://issues.apache.org/jira/browse/WAGON-486?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16286681#comment-16286681
]
Matt Nelson commented on WAGON-486:
---
I believe I am running into a similar issue. The stack trace is slightly
different because I got it via executing jstack on the hung process. Has there
been any additional progress with integrating the changes [~michael-o] proposed?
{noformat}
"BuilderThread 1" #31 prio=5 os_prio=0 tid=0x7fe198b99800 nid=0x2cce
runnable [0x7fe193606000]
java.lang.Thread.State: RUNNABLE
at java.net.SocketInputStream.socketRead0(Native Method)
at java.net.SocketInputStream.socketRead(SocketInputStream.java:116)
at java.net.SocketInputStream.read(SocketInputStream.java:171)
at java.net.SocketInputStream.read(SocketInputStream.java:141)
at sun.security.ssl.InputRecord.readFully(InputRecord.java:465)
at sun.security.ssl.InputRecord.read(InputRecord.java:503)
at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:983)
- locked <0xc74f25a0> (a java.lang.Object)
at sun.security.ssl.SSLSocketImpl.readDataRecord(SSLSocketImpl.java:940)
at sun.security.ssl.AppInputStream.read(AppInputStream.java:105)
- locked <0xc74f2178> (a sun.security.ssl.AppInputStream)
at
org.apache.maven.wagon.providers.http.httpclient.impl.io.SessionInputBufferImpl.streamRead(SessionInputBufferImpl.java:139)
at
org.apache.maven.wagon.providers.http.httpclient.impl.io.SessionInputBufferImpl.fillBuffer(SessionInputBufferImpl.java:155)
at
org.apache.maven.wagon.providers.http.httpclient.impl.io.SessionInputBufferImpl.readLine(SessionInputBufferImpl.java:284)
at
org.apache.maven.wagon.providers.http.httpclient.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpResponseParser.java:140)
at
org.apache.maven.wagon.providers.http.httpclient.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpResponseParser.java:57)
at
org.apache.maven.wagon.providers.http.httpclient.impl.io.AbstractMessageParser.parse(AbstractMessageParser.java:261)
at
org.apache.maven.wagon.providers.http.httpclient.impl.DefaultBHttpClientConnection.receiveResponseHeader(DefaultBHttpClientConnection.java:165)
at
org.apache.maven.wagon.providers.http.httpclient.impl.conn.CPoolProxy.receiveResponseHeader(CPoolProxy.java:167)
at
org.apache.maven.wagon.providers.http.httpclient.protocol.HttpRequestExecutor.doReceiveResponse(HttpRequestExecutor.java:272)
at
org.apache.maven.wagon.providers.http.httpclient.protocol.HttpRequestExecutor.execute(HttpRequestExecutor.java:124)
at
org.apache.maven.wagon.providers.http.httpclient.impl.execchain.MainClientExec.execute(MainClientExec.java:271)
at
org.apache.maven.wagon.providers.http.httpclient.impl.execchain.ProtocolExec.execute(ProtocolExec.java:184)
at
org.apache.maven.wagon.providers.http.httpclient.impl.execchain.RetryExec.execute(RetryExec.java:88)
at
org.apache.maven.wagon.providers.http.httpclient.impl.execchain.RedirectExec.execute(RedirectExec.java:110)
at
org.apache.maven.wagon.providers.http.httpclient.impl.client.InternalHttpClient.doExecute(InternalHttpClient.java:184)
at
org.apache.maven.wagon.providers.http.httpclient.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:82)
at
org.apache.maven.wagon.providers.http.AbstractHttpClientWagon.execute(AbstractHttpClientWagon.java:834)
at
org.apache.maven.wagon.providers.http.AbstractHttpClientWagon.fillInputData(AbstractHttpClientWagon.java:985)
at
org.apache.maven.wagon.providers.http.AbstractHttpClientWagon.fillInputData(AbstractHttpClientWagon.java:962)
at
org.apache.maven.wagon.StreamWagon.getInputStream(StreamWagon.java:126)
at org.apache.maven.wagon.StreamWagon.getIfNewer(StreamWagon.java:88)
at org.apache.maven.wagon.StreamWagon.get(StreamWagon.java:61)
at
org.eclipse.aether.transport.wagon.WagonTransporter$GetTaskRunner.run(WagonTransporter.java:567)
at
org.eclipse.aether.transport.wagon.WagonTransporter.execute(WagonTransporter.java:435)
at
org.eclipse.aether.transport.wagon.WagonTransporter.get(WagonTransporter.java:412)
at
org.eclipse.aether.connector.basic.BasicRepositoryConnector$GetTaskRunner.runTask(BasicRepositoryConnector.java:453)
at
org.eclipse.aether.connector.basic.BasicRepositoryConnector$TaskRunner.run(BasicRepositoryConnector.java:360)
at
org.eclipse.aether.util.concurrency.RunnableErrorForwarder$1.run(RunnableErrorForwarder.java:75)
at
org.eclipse.aether.connector.basic.BasicRepositoryConnector$DirectExecutor.execute(BasicRepositoryConnector.java:583)
at
[jira] [Commented] (MNG-6308) display packaging when building a module
[
https://issues.apache.org/jira/browse/MNG-6308?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16286565#comment-16286565
]
Robert Scholte commented on MNG-6308:
-
when 80 is not enough... We might need to do the same as Twitter: double the
length (or best fit)
{noformat}
[INFO] -<
org.apache.maven.plugins:maven-compiler-plugin:maven-plugin:3.5.3-SNAPSHOT >-
[INFO] Building Apache Maven Compiler Plugin[15/15]
[INFO]
{noformat}
> display packaging when building a module
>
>
> Key: MNG-6308
> URL: https://issues.apache.org/jira/browse/MNG-6308
> Project: Maven
> Issue Type: Improvement
>Affects Versions: 3.5.2
>Reporter: Hervé Boutemy
>Assignee: Hervé Boutemy
>
> Packaging is a key information, since it defines what bindings will be: it is
> short and should be visible in the build log
> proposal:
> {code}[INFO]
>
> [INFO] Building Apache Maven Distribution 3.5.3-SNAPSHOT
> [15/15]
> [INFO] --- pom
> --{code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (MNG-6308) display packaging when building a module
[
https://issues.apache.org/jira/browse/MNG-6308?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16286488#comment-16286488
]
Robert Scholte commented on MNG-6308:
-
I don't want to duplicate the version, so that would mean shifting it, like:
{noformat}
[INFO] --< org.apache.maven:apache-maven:pom:3.5.3-SNAPSHOT >--
[INFO] Building Apache Maven Distribution [15/15]
[INFO]
{noformat}
> display packaging when building a module
>
>
> Key: MNG-6308
> URL: https://issues.apache.org/jira/browse/MNG-6308
> Project: Maven
> Issue Type: Improvement
>Affects Versions: 3.5.2
>Reporter: Hervé Boutemy
>Assignee: Hervé Boutemy
>
> Packaging is a key information, since it defines what bindings will be: it is
> short and should be visible in the build log
> proposal:
> {code}[INFO]
>
> [INFO] Building Apache Maven Distribution 3.5.3-SNAPSHOT
> [15/15]
> [INFO] --- pom
> --{code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (MNG-6308) display packaging when building a module
[
https://issues.apache.org/jira/browse/MNG-6308?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16286469#comment-16286469
]
Michael Osipov commented on MNG-6308:
-
Robet, not bad at all. Though, I prefer version two. Why not pull the artifact
version up to the live with the coords? Just like we use in MDEP or other
plugins which use compact coord format?
> display packaging when building a module
>
>
> Key: MNG-6308
> URL: https://issues.apache.org/jira/browse/MNG-6308
> Project: Maven
> Issue Type: Improvement
>Affects Versions: 3.5.2
>Reporter: Hervé Boutemy
>Assignee: Hervé Boutemy
>
> Packaging is a key information, since it defines what bindings will be: it is
> short and should be visible in the build log
> proposal:
> {code}[INFO]
>
> [INFO] Building Apache Maven Distribution 3.5.3-SNAPSHOT
> [15/15]
> [INFO] --- pom
> --{code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (WAGON-492) Using Wagon component with Spring
[ https://issues.apache.org/jira/browse/WAGON-492?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16286446#comment-16286446 ] Michael Osipov commented on WAGON-492: -- No, I need a complete sample project. This is some kind of dep/version mismatch. > Using Wagon component with Spring > - > > Key: WAGON-492 > URL: https://issues.apache.org/jira/browse/WAGON-492 > Project: Maven Wagon > Issue Type: Bug > Components: wagon-provider-api >Affects Versions: 2.12 >Reporter: Laurent Granié > Attachments: DownloaderBean.java > > > I'm using Wagon with Spring. > With version 2.10 it's ok. But since version 2.12 I can not load component > into Spring. > You can find my DownloaderServiceBean attached. > The error is like : > Unsatisfied dependency expressed through field 'downloader': Error > creating bean with name 'downloaderBean': Invocation of init method > failed; nested exception is java.lang.NoSuchMethodError: > org.codehaus.plexus.configuration.PlexusConfiguration.setName(Ljava/lang/String;)V; > nested exception is > org.springframework.beans.factory.BeanCreationException: Error > creating bean with name 'downloaderBean': Invocation of init method > failed; nested exception is java.lang.NoSuchMethodError: > org.codehaus.plexus.configuration.PlexusConfiguration.setName(Ljava/lang/String;)V -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (MSHADE-268) improving inclusion of open source code referenced by java projects.
[ https://issues.apache.org/jira/browse/MSHADE-268?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16286356#comment-16286356 ] Robert Scholte commented on MSHADE-268: --- If you're working on a library and want to shade, you probably want to relocate as well. In that case downloading the sources won't be enough. Those sources must be relocated as well. There's no option yet to shade attachments like sources and javadoc. If you're working on an apllication, I don't see the need for these sources. Shading is done during packaging, so during development you can still use the original sources. > improving inclusion of open source code referenced by java projects. > - > > Key: MSHADE-268 > URL: https://issues.apache.org/jira/browse/MSHADE-268 > Project: Maven Shade Plugin > Issue Type: New Feature >Reporter: Sunil Kumar Singh > > All the details are on git hub at: > https://github.com/ksunilsingh/code-collector > This is an idea on improving inclusion of open source code referenced by java > projects. Currently when we use a java build system (such as maven or > gradle), the build system downloads the jar files referenced by a java > project. What I am proposing here is a replacement for that: > Find out all the classes referenced by the classes in a java project (say, > project A). > Download the source code for these dependencies recursively and include the > downloaded source code in the source tree of project A. > Remove the dependency(ies) from project build configuration file (e.g. > pom.xml) and build the project. > The resulting jar file would be smaller in size than if the full jar for the > dependency is included as is. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Moved] (MSHADE-268) improving inclusion of open source code referenced by java projects.
[ https://issues.apache.org/jira/browse/MSHADE-268?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Scholte moved MNG-6287 to MSHADE-268: Key: MSHADE-268 (was: MNG-6287) Project: Maven Shade Plugin (was: Maven) > improving inclusion of open source code referenced by java projects. > - > > Key: MSHADE-268 > URL: https://issues.apache.org/jira/browse/MSHADE-268 > Project: Maven Shade Plugin > Issue Type: New Feature >Reporter: Sunil Kumar Singh > > All the details are on git hub at: > https://github.com/ksunilsingh/code-collector > This is an idea on improving inclusion of open source code referenced by java > projects. Currently when we use a java build system (such as maven or > gradle), the build system downloads the jar files referenced by a java > project. What I am proposing here is a replacement for that: > Find out all the classes referenced by the classes in a java project (say, > project A). > Download the source code for these dependencies recursively and include the > downloaded source code in the source tree of project A. > Remove the dependency(ies) from project build configuration file (e.g. > pom.xml) and build the project. > The resulting jar file would be smaller in size than if the full jar for the > dependency is included as is. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (MNG-6308) display packaging when building a module
[
https://issues.apache.org/jira/browse/MNG-6308?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16286335#comment-16286335
]
Robert Scholte commented on MNG-6308:
-
How about combining it with my wish to show the groupId and artifactId as well,
centered:
{noformat}
[INFO]
[INFO] Building Apache Maven Distribution 3.5.3-SNAPSHOT[15/15]
[INFO] < org.apache.maven:apache-maven:pom >---
{noformat}
or
{noformat}
[INFO] < org.apache.maven:apache-maven:pom >---
[INFO] Building Apache Maven Distribution 3.5.3-SNAPSHOT[15/15]
[INFO]
{noformat}
> display packaging when building a module
>
>
> Key: MNG-6308
> URL: https://issues.apache.org/jira/browse/MNG-6308
> Project: Maven
> Issue Type: Improvement
>Affects Versions: 3.5.2
>Reporter: Hervé Boutemy
>Assignee: Hervé Boutemy
>
> Packaging is a key information, since it defines what bindings will be: it is
> short and should be visible in the build log
> proposal:
> {code}[INFO]
>
> [INFO] Building Apache Maven Distribution 3.5.3-SNAPSHOT
> [15/15]
> [INFO] --- pom
> --{code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (MNG-5359) Declared execution in PluginMgmt gets bound to lifecycle (regression)
[ https://issues.apache.org/jira/browse/MNG-5359?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16286158#comment-16286158 ] Hudson commented on MNG-5359: - Build unstable in Jenkins: Maven TLP (wip) » maven » pre-reset-master #3 See https://builds.apache.org/job/maven-wip/job/maven/job/pre-reset-master/3/ > Declared execution in PluginMgmt gets bound to lifecycle (regression) > - > > Key: MNG-5359 > URL: https://issues.apache.org/jira/browse/MNG-5359 > Project: Maven > Issue Type: Bug > Components: Plugins and Lifecycle >Affects Versions: 3.0.1, 3.0.2, 3.0.3, 3.0.4 > Environment: Mac OS 10.7.5, Apple JDK 1.6.0_35 > (Same behavior seen on Windows XP with Sun JDK 1.6.0 as well) >Reporter: Anders Hammar > Fix For: 3.5.x-candidate > > Attachments: MNG-5359-IT.patch, binding-test.zip > > > If a plugin execution binding is declared in pluginManagement it gets bound > to the build lifecycle in Maven 3.0.x, but not with Maven 2.2.1. > My understanding is that the behavior in Maven 3.0 is wrong; an execution > binding needs to be declared in build/plugins/plugin to be bound. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (MNG-6079) 3.4 regression: cannot override version of a dependencyManagement in a submodule any more
[
https://issues.apache.org/jira/browse/MNG-6079?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16286178#comment-16286178
]
Hudson commented on MNG-6079:
-
Build unstable in Jenkins: Maven TLP (wip) » maven » pre-reset-master #3
See https://builds.apache.org/job/maven-wip/job/maven/job/pre-reset-master/3/
> 3.4 regression: cannot override version of a dependencyManagement in a
> submodule any more
> -
>
> Key: MNG-6079
> URL: https://issues.apache.org/jira/browse/MNG-6079
> Project: Maven
> Issue Type: Bug
> Components: Dependencies
>Affects Versions: needing-scrub-3.4.0-fallout
>Reporter: Samuel Langlois
> Attachments: parent-pom.xml, pom.xml
>
>
> When you import a {{}} section from another pom, you
> can use a property for the version:
> {code}
>
>
>
> org.apache.maven.surefire
> surefire
> ${surefire.version}
> pom
> import
>
>
>
> {code}
> In Maven 3.3 and before, that version could be overridden in submodules, by
> overriding the property.
> In Maven 3.4, this doesn't work any more: redefining the property doesn't
> change the dependencies which are defined.
> I attach a simple example that uses surefire dependencies.
> {{mvn dependency:list}} will yield different results:
> * surefire-api:jar:2.12 with Maven 3.3, because this is the overridden
> version in the pom
> * surefire-api:jar:2.10 with Maven 3.4 (as of snapshot 2016-08-06), which is
> the version defined in the parent pom
> It is admittedly a corner case, or potentially a bug fix. In Maven 3.4, the
> behaviour of is now more consistent with the one of
> , where you can't redefine a dependency version simply by
> overriding a property.
> It is however a change in behaviour -- which broke my build.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (MNG-6084) Support JSR 250 annotations
[ https://issues.apache.org/jira/browse/MNG-6084?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16286181#comment-16286181 ] Hudson commented on MNG-6084: - Build unstable in Jenkins: Maven TLP (wip) » maven » pre-reset-master #3 See https://builds.apache.org/job/maven-wip/job/maven/job/pre-reset-master/3/ > Support JSR 250 annotations > --- > > Key: MNG-6084 > URL: https://issues.apache.org/jira/browse/MNG-6084 > Project: Maven > Issue Type: New Feature > Components: core >Affects Versions: 3.3.9 >Reporter: Dan Tran >Assignee: Dan Tran > Fix For: 3.5.2 > > > JSR330 ( @Named, @Singeton, etc) currently supported for plugin development. > Would like to see JSR250 as well(@PostConstruct, etc) > Detail discussion is at > http://maven.40175.n5.nabble.com/Maven-Plugin-and-JSR330-td5879508.html -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (MNG-5958) java.lang.String cannot be cast to org.apache.maven.lifecycle.mapping.LifecyclePhase
[
https://issues.apache.org/jira/browse/MNG-5958?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16286167#comment-16286167
]
Hudson commented on MNG-5958:
-
Build unstable in Jenkins: Maven TLP (wip) » maven » pre-reset-master #3
See https://builds.apache.org/job/maven-wip/job/maven/job/pre-reset-master/3/
> java.lang.String cannot be cast to
> org.apache.maven.lifecycle.mapping.LifecyclePhase
>
>
> Key: MNG-5958
> URL: https://issues.apache.org/jira/browse/MNG-5958
> Project: Maven
> Issue Type: Bug
> Components: Plugins and Lifecycle
>Affects Versions: 3.3.9
> Environment: win 8.1
>Reporter: Meytal Genah
>Assignee: Christian Schulte
>Priority: Minor
> Fix For: 3.5.0-alpha-1, 3.5.0
>
>
> Our app uses flex mojo.
> We upgraded from Maven 3.3.3 to Maven 3.3.9 and when building we get:
> {noformat}[ERROR] Internal error: java.lang.ClassCastException:
> java.lang.String cannot be cast to
> org.apache.maven.lifecycle.mapping.LifecyclePhase -> [Help 1]
> org.apache.maven.InternalErrorException: Internal error:
> java.lang.ClassCastException: java.lang.String cannot be cast to
> org.apache.maven.lifecycle.mapping.LifecyclePhas
> e
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:121)
> at org.apache.maven.cli.MavenCli.execute(MavenCli.java:863)
> at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:288)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:199)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:497)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
> Caused by: java.lang.ClassCastException: java.lang.String cannot be cast to
> org.apache.maven.lifecycle.mapping.LifecyclePhase
> at
> org.apache.maven.lifecycle.internal.DefaultLifecyclePluginAnalyzer.getPluginsBoundByDefaultToAllLifecycles(DefaultLifecyclePluginAnalyzer.java:119)
> at
> org.apache.maven.model.plugin.DefaultLifecycleBindingsInjector.injectLifecycleBindings(DefaultLifecycleBindingsInjector.java:64)
> at
> org.apache.maven.model.building.DefaultModelBuilder.build(DefaultModelBuilder.java:451)
> at
> org.apache.maven.model.building.DefaultModelBuilder.build(DefaultModelBuilder.java:421)
> at
> org.apache.maven.project.DefaultProjectBuilder.build(DefaultProjectBuilder.java:620)
> at
> org.apache.maven.project.DefaultProjectBuilder.build(DefaultProjectBuilder.java:626)
> at
> org.apache.maven.project.DefaultProjectBuilder.build(DefaultProjectBuilder.java:626)
> at
> org.apache.maven.project.DefaultProjectBuilder.build(DefaultProjectBuilder.java:626)
> at
> org.apache.maven.project.DefaultProjectBuilder.build(DefaultProjectBuilder.java:626)
> at
> org.apache.maven.project.DefaultProjectBuilder.build(DefaultProjectBuilder.java:411)
> at
> org.apache.maven.graph.DefaultGraphBuilder.collectProjects(DefaultGraphBuilder.java:419)
> at
> org.apache.maven.graph.DefaultGraphBuilder.getProjectsForMavenReactor(DefaultGraphBuilder.java:410)
> at
> org.apache.maven.graph.DefaultGraphBuilder.build(DefaultGraphBuilder.java:83)
> at org.apache.maven.DefaultMaven.buildGraph(DefaultMaven.java:491)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:219)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:193)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:106)
> ... 11 more{noformat}
> I didn’t see anyone encountering the same problem. Maybe it is related to the
> fix of https://issues.apache.org/jira/browse/MNG-5805.
> Also, according to the stack trace, the invalid casting is in this line:
> {code:java}LifecyclePhase goals =
> goalsForLifecyclePhase.getValue();{code}
> this is the content of the pom.xml:
> {code:xml}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/maven-v4_0_0.xsd;>
> 4.0.0
>
>com.myapp.plugin
> GUI
>
[jira] [Commented] (MNG-6055) Move the release profile out of Maven's core so it can be more easily changed.
[ https://issues.apache.org/jira/browse/MNG-6055?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16286176#comment-16286176 ] Hudson commented on MNG-6055: - Build unstable in Jenkins: Maven TLP (wip) » maven » pre-reset-master #3 See https://builds.apache.org/job/maven-wip/job/maven/job/pre-reset-master/3/ > Move the release profile out of Maven's core so it can be more easily changed. > -- > > Key: MNG-6055 > URL: https://issues.apache.org/jira/browse/MNG-6055 > Project: Maven > Issue Type: Improvement >Reporter: Christian Schulte > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (MNG-4721) Create an integration test to check handling of optional plugin dependencies
[ https://issues.apache.org/jira/browse/MNG-4721?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16286184#comment-16286184 ] Hudson commented on MNG-4721: - Build unstable in Jenkins: Maven TLP (wip) » maven » pre-reset-master #3 See https://builds.apache.org/job/maven-wip/job/maven/job/pre-reset-master/3/ > Create an integration test to check handling of optional plugin dependencies > - > > Key: MNG-4721 > URL: https://issues.apache.org/jira/browse/MNG-4721 > Project: Maven > Issue Type: Task > Components: Integration Tests >Reporter: Benjamin Bentmann >Assignee: Benjamin Bentmann > > Optional dependency handling in the context of resolving the plugin class > path is currently not covered and subject to unnoticed breaking. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (MNG-6049) Add behavior to filter resolved version ranges of an artifact
[
https://issues.apache.org/jira/browse/MNG-6049?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16286174#comment-16286174
]
Hudson commented on MNG-6049:
-
Build unstable in Jenkins: Maven TLP (wip) » maven » pre-reset-master #3
See https://builds.apache.org/job/maven-wip/job/maven/job/pre-reset-master/3/
> Add behavior to filter resolved version ranges of an artifact
> -
>
> Key: MNG-6049
> URL: https://issues.apache.org/jira/browse/MNG-6049
> Project: Maven
> Issue Type: Improvement
> Components: core, Dependencies
>Reporter: Uwe Barthel
>Priority: Critical
> Fix For: 3.6.0-candidate
>
>
> The discussion on issue MNG-3092 shows the seriously needs of different kinds
> of version range resolving in Maven.
> This solution provides a hook for Maven extensions/plugins to change the list
> of resolved version range results as required.
> The {{DefaultVersionRangeResolver}} will be extended with a filter for
> version range results. A new interface {{VersionRangeResultFilter}} is added
> and a non-filtering {{DefaultVersionRangeResultFilter}}.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (MNG-597) Maven doesn't work in Turkish locale
[ https://issues.apache.org/jira/browse/MNG-597?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16286183#comment-16286183 ] Hudson commented on MNG-597: Build unstable in Jenkins: Maven TLP (wip) » maven » pre-reset-master #3 See https://builds.apache.org/job/maven-wip/job/maven/job/pre-reset-master/3/ > Maven doesn't work in Turkish locale > > > Key: MNG-597 > URL: https://issues.apache.org/jira/browse/MNG-597 > Project: Maven > Issue Type: Bug > Components: Plugins and Lifecycle >Reporter: Brett Porter >Assignee: Brett Porter >Priority: Minor > Fix For: 2.0 (RC) > > > http://mail-archives.apache.org/mod_mbox/maven-dev/200507.mbox/%3c402444b9050709065872583...@mail.gmail.com%3e -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (MNG-6139) Addition of command line option 'legacy-dependency-management'.
[ https://issues.apache.org/jira/browse/MNG-6139?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16286187#comment-16286187 ] Hudson commented on MNG-6139: - Build unstable in Jenkins: Maven TLP (wip) » maven » pre-reset-master #3 See https://builds.apache.org/job/maven-wip/job/maven/job/pre-reset-master/3/ > Addition of command line option 'legacy-dependency-management'. > --- > > Key: MNG-6139 > URL: https://issues.apache.org/jira/browse/MNG-6139 > Project: Maven > Issue Type: New Feature >Reporter: Christian Schulte >Priority: Critical > > See the issues this issue is linked to. The command line option will simply > allow users to disable the bugfixes and get the former incorrect behaviour. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (MNG-5799) Incorrect execution order of plugins in the same phase
[
https://issues.apache.org/jira/browse/MNG-5799?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16286170#comment-16286170
]
Hudson commented on MNG-5799:
-
Build unstable in Jenkins: Maven TLP (wip) » maven » pre-reset-master #3
See https://builds.apache.org/job/maven-wip/job/maven/job/pre-reset-master/3/
> Incorrect execution order of plugins in the same phase
> --
>
> Key: MNG-5799
> URL: https://issues.apache.org/jira/browse/MNG-5799
> Project: Maven
> Issue Type: Bug
> Components: Plugins and Lifecycle
>Affects Versions: 3.2.5
> Environment: Apache Maven 3.2.5
> (12a6b3acb947671f09b81f49094c53f426d8cea1; 2014-12-14T18:29:23+01:00)
>Reporter: Gerhard Poul
>
> When multiple plugins are used and assigned to the same phase they are not
> executed in the order they're listed in the POM.
> Repro case: https://github.com/gpoul/arquillian-container-was/tree/MNG-5799
> Repro steps: Execute {{mvn test}} in folder {{wlp-managed-8.5}}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (MNG-3599) webdav does not set http-proxy correctly
[ https://issues.apache.org/jira/browse/MNG-3599?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16286188#comment-16286188 ] Hudson commented on MNG-3599: - Build unstable in Jenkins: Maven TLP (wip) » maven » pre-reset-master #3 See https://builds.apache.org/job/maven-wip/job/maven/job/pre-reset-master/3/ > webdav does not set http-proxy correctly > > > Key: MNG-3599 > URL: https://issues.apache.org/jira/browse/MNG-3599 > Project: Maven > Issue Type: Bug >Affects Versions: 2.0.9 >Reporter: Brett Porter >Assignee: Brett Porter > Fix For: 2.1.0-M1 > > Attachments: MNG-3599.patch, webdav.log > > > patch is attached to WAGON-82 > (0001-Make-the-artifact-manager-using-wagons-ProxyInfoProv.patch), utilising > the new APIs in beta-3 -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (MNG-6127) Fix plugin execution configuration interference
[ https://issues.apache.org/jira/browse/MNG-6127?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16286182#comment-16286182 ] Hudson commented on MNG-6127: - Build unstable in Jenkins: Maven TLP (wip) » maven » pre-reset-master #3 See https://builds.apache.org/job/maven-wip/job/maven/job/pre-reset-master/3/ > Fix plugin execution configuration interference > --- > > Key: MNG-6127 > URL: https://issues.apache.org/jira/browse/MNG-6127 > Project: Maven > Issue Type: Bug > Components: core >Affects Versions: 3.3.9 >Reporter: Mario Krizmanic >Assignee: Robert Scholte > Fix For: 3.5.2 > > > The plugin execution configuration may interfere across maven modules > included in a build in case a plugin extension provides a default > configuration. > Because the custom plugin configuration defined in the maven modules is > merged to the plugin execution configuration and the merged configuration is > re-used during building the other included maven modules, so the other maven > modules may be build using the invalid configuration. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (MNG-6082) Introduction of model version 4.1.0
[ https://issues.apache.org/jira/browse/MNG-6082?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16286179#comment-16286179 ] Hudson commented on MNG-6082: - Build unstable in Jenkins: Maven TLP (wip) » maven » pre-reset-master #3 See https://builds.apache.org/job/maven-wip/job/maven/job/pre-reset-master/3/ > Introduction of model version 4.1.0 > --- > > Key: MNG-6082 > URL: https://issues.apache.org/jira/browse/MNG-6082 > Project: Maven > Issue Type: New Feature >Reporter: Christian Schulte >Priority: Critical > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (MNG-4645) Move central repo definition out of Maven's core so it can be more easily changed
[ https://issues.apache.org/jira/browse/MNG-4645?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16286175#comment-16286175 ] Hudson commented on MNG-4645: - Build unstable in Jenkins: Maven TLP (wip) » maven » pre-reset-master #3 See https://builds.apache.org/job/maven-wip/job/maven/job/pre-reset-master/3/ > Move central repo definition out of Maven's core so it can be more easily > changed > - > > Key: MNG-4645 > URL: https://issues.apache.org/jira/browse/MNG-4645 > Project: Maven > Issue Type: Improvement >Affects Versions: 3.3.3 >Reporter: Paul Gier > > The Maven central repository is currently a hidden default repository > available to Maven. The configuration of the central repo can be changed > only if you know the (somewhat obscure) repository id "central". It would be > better if the configuration of the central repository was moved from the > Maven internals to the default settings.xml. This way the repository would > still be available to a default Maven install, but would also be clear to > users how the central repo is configured in case it needs to be changed for > mirror settings or some other reason. It would also make the repository > ordering in the settings more clear. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (MNG-6135) Maven plugins and core extensions are not dependencies, they should be resolved the same way as projects.
[
https://issues.apache.org/jira/browse/MNG-6135?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16286186#comment-16286186
]
Hudson commented on MNG-6135:
-
Build unstable in Jenkins: Maven TLP (wip) » maven » pre-reset-master #3
See https://builds.apache.org/job/maven-wip/job/maven/job/pre-reset-master/3/
> Maven plugins and core extensions are not dependencies, they should be
> resolved the same way as projects.
> -
>
> Key: MNG-6135
> URL: https://issues.apache.org/jira/browse/MNG-6135
> Project: Maven
> Issue Type: Bug
>Reporter: Christian Schulte
>Priority: Critical
> Fix For: 3.6.0-candidate
>
>
> Due to a bug in the Maven resolver, plugin and core extensions were resolved
> incorrectly: the direct {{test}} and {{provided}} dependencies were ignored.
> Ironically, this fix breaks some plugins because direct {{test}} dependencies
> now take precedence over transitive {{compile}} one: see MNG-5739
> (we know only one case where {{provided}} case has an impact: MPLUGIN-296,
> and in this only case, the new behaviour is more consistent than the previous)
>
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (MSHARED-547) Support colorized output checks (ignore ANSI escape codes)
[ https://issues.apache.org/jira/browse/MSHARED-547?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16286171#comment-16286171 ] Hudson commented on MSHARED-547: Build unstable in Jenkins: Maven TLP (wip) » maven » pre-reset-master #3 See https://builds.apache.org/job/maven-wip/job/maven/job/pre-reset-master/3/ > Support colorized output checks (ignore ANSI escape codes) > -- > > Key: MSHARED-547 > URL: https://issues.apache.org/jira/browse/MSHARED-547 > Project: Maven Shared Components > Issue Type: Improvement > Components: maven-verifier >Affects Versions: maven-verifier-1.6 >Reporter: Hervé Boutemy >Assignee: Hervé Boutemy > Fix For: maven-verifier-1.7 > > > adding colorized output to Maven MNG-3507 will cause issues if verifier can't > ignore ANSI codes -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (MNG-5761) Dependency management is not transitive.
[ https://issues.apache.org/jira/browse/MNG-5761?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16286185#comment-16286185 ] Hudson commented on MNG-5761: - Build unstable in Jenkins: Maven TLP (wip) » maven » pre-reset-master #3 See https://builds.apache.org/job/maven-wip/job/maven/job/pre-reset-master/3/ > Dependency management is not transitive. > > > Key: MNG-5761 > URL: https://issues.apache.org/jira/browse/MNG-5761 > Project: Maven > Issue Type: Bug > Components: Dependencies >Affects Versions: 3.2.5 >Reporter: Jeff Schnitzer >Priority: Critical > Fix For: 3.6.0-candidate > > Attachments: MNG-5761.zip > > > A detailed description of the issue is here: > http://stackoverflow.com/questions/28312975/maven-dependencymanagement-version-ignored-in-transitive-dependencies > The short of it is that maven appears to be using the wrong > version in a transitive dependency. There are two > relevant sections in the build, one pulled in by guice > and one pulled in by gwizard-parent. These are the dependency paths from the > top: > gwizard-example -> gwizard-config -> gwizard-parent > gwizard-example -> gwizard-config -> guice -> guice-parent > gwizard-parent's dependencyManagement specifies guava 18 > guice-parent's dependencyManagement specifies guava 16 > Guava 16 is winning. This seems highly undesirable, and in fact it breaks our > build. I would expect that in a version # fight, "closest to the top" should > win. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (MNG-5527) Dependency management import should support relocations.
[
https://issues.apache.org/jira/browse/MNG-5527?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16286173#comment-16286173
]
Hudson commented on MNG-5527:
-
Build unstable in Jenkins: Maven TLP (wip) » maven » pre-reset-master #3
See https://builds.apache.org/job/maven-wip/job/maven/job/pre-reset-master/3/
> Dependency management import should support relocations.
>
>
> Key: MNG-5527
> URL: https://issues.apache.org/jira/browse/MNG-5527
> Project: Maven
> Issue Type: Bug
> Components: Dependencies
> Environment: maven-3.1.0
> Fedora 18 x86_64
>Reporter: Matous Jobanek
> Fix For: 3.5.x-candidate
>
>
> Consider the following scenario:
> {code:xml}
>
> 4.0.0
> old.groupId.bom
> my-artifactId-bom
> 1.0
> pom
>
>
> new.groupId.bom
> my-artifactId-bom
> 2.0
>
>
>
> {code}
> {code:xml}
>
> 4.0.0
> my.project.groupId
> my-project
> 1.0
> war
>
>
>
> old.groupId.bom
> my-artifactId-bom
> 1.0
> pom
> import
>
>
>
> ...
>
> {code}
> The expected result according to [1]:
> During building the "my-project" it should print the WARNING with the
> information about the relocation and it should be automatically redirected
> from old.groupId.bom:my-artifactId-bom:1.0 to
> new.groupId.bom:my-artifactId-bom:2.0 and use dependencies from the new pom.
> Actual results:
> There is no WARNING and no redirection to the new pom and maven is trying to
> obtain dependencies from the old pom (old.groupId.bom:my-artifactId-bom:1.0).
>
> Nevertheless, when the pom is declared as a "normal dependency" (not in the
> "dependencyManagement" part) it works without any problem - it prints the
> WARNING and redirects to the new pom, but this is not the case we are using.
> [1] http://maven.apache.org/guides/mini/guide-relocation.html
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (MNG-5600) Dependency management import should support exclusions.
[
https://issues.apache.org/jira/browse/MNG-5600?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16286172#comment-16286172
]
Hudson commented on MNG-5600:
-
Build unstable in Jenkins: Maven TLP (wip) » maven » pre-reset-master #3
See https://builds.apache.org/job/maven-wip/job/maven/job/pre-reset-master/3/
> Dependency management import should support exclusions.
> ---
>
> Key: MNG-5600
> URL: https://issues.apache.org/jira/browse/MNG-5600
> Project: Maven
> Issue Type: Improvement
> Components: Dependencies
>Reporter: Radai Rosenblatt
> Fix For: 3.5.x-candidate
>
>
> suppose i have a multi-module project that uses spring, and so have this in
> dependency-managements in a parent pom:
> {code:xml}
>
> org.springframework
> spring-framework-bom
> ${org.springframework.version}
> pom
> import
>
> {code}
> spring artifacts (or at least a lot of them) have a dependency on
> commons-logging. right now, if i want to exclude commons-logging i have to
> add an exclusion to every spring dependency in every module of my project,
> which is actually more XML overall than giving up on using the bom dependency
> altogether and listing all spring dependencies with excludes once in the
> parent dependency management.
> I'd like to be able to do this:
> {code:xml}
>
> org.springframework
> spring-framework-bom
> ${org.springframework.version}
> pom
> import
>
>
> commons-logging
> commons-logging
>
>
>
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (MNG-6075) Increase the model validation level to the next minor level version.
[ https://issues.apache.org/jira/browse/MNG-6075?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16286177#comment-16286177 ] Hudson commented on MNG-6075: - Build unstable in Jenkins: Maven TLP (wip) » maven » pre-reset-master #3 See https://builds.apache.org/job/maven-wip/job/maven/job/pre-reset-master/3/ > Increase the model validation level to the next minor level version. > > > Key: MNG-6075 > URL: https://issues.apache.org/jira/browse/MNG-6075 > Project: Maven > Issue Type: Task >Reporter: Christian Schulte >Priority: Critical > > Maven 3 has warned about various model related issues clearly stating that > not reacting to those warnings may break with a future Maven version. > Starting with Maven 3.4, the model validation level has been increased to the > next minor version so that such warnings will become errors as of 3.4. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (MNG-5889) .mvn directory should be picked when using --file
[
https://issues.apache.org/jira/browse/MNG-5889?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16286180#comment-16286180
]
Hudson commented on MNG-5889:
-
Build unstable in Jenkins: Maven TLP (wip) » maven » pre-reset-master #3
See https://builds.apache.org/job/maven-wip/job/maven/job/pre-reset-master/3/
> .mvn directory should be picked when using --file
> -
>
> Key: MNG-5889
> URL: https://issues.apache.org/jira/browse/MNG-5889
> Project: Maven
> Issue Type: Improvement
> Components: Bootstrap & Build
>Affects Versions: 3.3.3, 3.3.9
>Reporter: Daniel Spilker
>Assignee: Tibor Digana
> Fix For: 3.5.0-alpha-1, 3.5.0
>
>
> The {{.mvn}} directory is not picked up when using the {{--file}} switch to
> build a project from outside of the multi-module root.
> Example:
> * the module root is {{/foo/bar}}
> * {{.mvn}} is located at {{/foo/bar/.mvn}}
> * current directory is {{/foo}}
> * Maven is invoked with {{mvn --file bar/module/pom.xml}}
> I would expect the {{.mvn}} directory detection to start at the directory of
> the POM selected by {{--file}} and then go through the parent directories.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (MNG-3259) Regression: Maven drops dependencies in multi-module build
[ https://issues.apache.org/jira/browse/MNG-3259?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16286165#comment-16286165 ] Hudson commented on MNG-3259: - Build unstable in Jenkins: Maven TLP (wip) » maven » pre-reset-master #3 See https://builds.apache.org/job/maven-wip/job/maven/job/pre-reset-master/3/ > Regression: Maven drops dependencies in multi-module build > -- > > Key: MNG-3259 > URL: https://issues.apache.org/jira/browse/MNG-3259 > Project: Maven > Issue Type: Bug > Components: Dependencies >Affects Versions: 2.0.7, 2.0.8, 3.0-alpha-1 >Reporter: Joerg Schaible >Assignee: John Casey >Priority: Blocker > Fix For: 2.0.9 > > Attachments: MNG-3259-2.zip, MNG-3259.zip > > Time Spent: 5h > Remaining Estimate: 0h > > Under some circumstances Maven "forgets" about test dependencies in > multi-module builds. The affected module can be build only if the build is > started from its local project directory. If the build is run from a parent > directory, the test fails because of missing classes. This issue applies to > M207 and recent M208-RC1, the project can be build without problems with M205 > (M206 is completely bogus). The problem was for us already the show stopper > for M207 and I thought with some of the now resolved issues it has been gone, > but I was wrong. I did not report it earlier, because I was never able to > reproduce the problem with a minimal build ... until now and it took me about > 3 days to create a demonstrating multi module project. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (MNG-5227) The 'optional' flag of a dependency should be manageable.
[
https://issues.apache.org/jira/browse/MNG-5227?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16286161#comment-16286161
]
Hudson commented on MNG-5227:
-
Build unstable in Jenkins: Maven TLP (wip) » maven » pre-reset-master #3
See https://builds.apache.org/job/maven-wip/job/maven/job/pre-reset-master/3/
> The 'optional' flag of a dependency should be manageable.
> -
>
> Key: MNG-5227
> URL: https://issues.apache.org/jira/browse/MNG-5227
> Project: Maven
> Issue Type: New Feature
> Components: Artifacts and Repositories
>Affects Versions: 3.0.3
>Reporter: Christian Schulte
>Priority: Minor
> Fix For: 3.6.0-candidate
>
> Attachments: MNG-5227.patch, MNG-5227.patch
>
>
> {code}
>
>
>
> groupId
> artifactId
> version
> false
>
>
>
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (MNG-4600) [regression] Optional flag from dependency management applied to dependencies
[
https://issues.apache.org/jira/browse/MNG-4600?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16286162#comment-16286162
]
Hudson commented on MNG-4600:
-
Build unstable in Jenkins: Maven TLP (wip) » maven » pre-reset-master #3
See https://builds.apache.org/job/maven-wip/job/maven/job/pre-reset-master/3/
> [regression] Optional flag from dependency management applied to dependencies
> -
>
> Key: MNG-4600
> URL: https://issues.apache.org/jira/browse/MNG-4600
> Project: Maven
> Issue Type: Bug
> Components: Dependencies
>Affects Versions: 3.0-alpha-7
> Environment: Apache Maven 3.0-alpha-7 (r921173; 2010-03-09
> 23:31:07+0100)
> Java version: 1.5.0_17
> Java home: c:\projet\MM\outils\jdk\1.5.0\jre
> Default locale: fr_FR, platform encoding: Cp1252
> OS name: "windows xp" version: "5.1" arch: "x86" Family: "windows"
>Reporter: Baptiste MATHUS
>Assignee: Benjamin Bentmann
> Fix For: 3.0-beta-1
>
> Attachments: bug-maven.zip
>
>
> The situation is quite complex to explain. I've a parent pom that defines
> dependencies in depMgmt. There's two projects in the multimodule project, the
> second depending on the first.
> Excerpt (parent/depMgmt):
> {code:xml}
> ch.qos.logback
> logback-classic
> ${logback.version}
> runtime
> true{code}
> First child (redefines scope only):
> {code:xml}
> ch.qos.logback
> logback-classic
> compile
> {code}
> Second child:
> {code:xml}
> org.slf4j
> slf4j-api
>
>
> m3pb
> subproject1
> ${project.version}
> {code}
> When running with maven 2, it works. When ran with maven 3, it fails on the
> second project, with a NoClassDefFoundError on the logback jar.
> I seem to understand this is actually a bug in maven 2: as the depMgmt
> defines optional=true, it shouldn't have been working in maven2 without
> redeclaring the dependency in the second project.
> From my understanding:
> * With maven 2, the transivity is taken in account and gives logback through
> the subproject1 link (from the second)
> * With maven 3, this just doesn't work and this is the correct behaviour.
> Please excuse my basic analysis.
> I'm attaching a test project to let see more precisely the problem.
> If you need any help, please let me know.
> Cheers
> --
> Baptiste
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (MNG-4463) Dependency management import should support version ranges.
[
https://issues.apache.org/jira/browse/MNG-4463?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16286164#comment-16286164
]
Hudson commented on MNG-4463:
-
Build unstable in Jenkins: Maven TLP (wip) » maven » pre-reset-master #3
See https://builds.apache.org/job/maven-wip/job/maven/job/pre-reset-master/3/
> Dependency management import should support version ranges.
> ---
>
> Key: MNG-4463
> URL: https://issues.apache.org/jira/browse/MNG-4463
> Project: Maven
> Issue Type: Bug
>Affects Versions: 2.2.1
> Environment: Maven 2.2.1
>Reporter: Rob ten Hove
> Fix For: 3.5.x-candidate
>
>
> Version ranges cannot be used for artifacts with {{import}} scope. If a
> version range is used for such an artifact, Maven cannot find it. Looking at
> the console output shows that it takes the version range as the version,
> without resolving it:
> {noformat}Downloading:
> http://some-repo/group/artifact/[1.0.0,2.0.0)/artifact-[1.0.0,2.0.0).pom{noformat}
> This is the POM snippet:
> {code:xml}
>
>
>
> group
> artifact
> [1.0.0,2.0.0)
>
> pom
> import
>
>
>
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (MNG-2478) add "resources-filtered" filtered resource directories to super POM
[
https://issues.apache.org/jira/browse/MNG-2478?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16286169#comment-16286169
]
Hudson commented on MNG-2478:
-
Build unstable in Jenkins: Maven TLP (wip) » maven » pre-reset-master #3
See https://builds.apache.org/job/maven-wip/job/maven/job/pre-reset-master/3/
> add "resources-filtered" filtered resource directories to super POM
> ---
>
> Key: MNG-2478
> URL: https://issues.apache.org/jira/browse/MNG-2478
> Project: Maven
> Issue Type: New Feature
> Components: POM
>Affects Versions: 2.0.4
> Environment: any
>Reporter: Jörg Hohwiller
> Fix For: needing-scrub-3.4.0-fallout
>
>
> The super POM contains default folders for resources that are NOT filtered
> (src/main/resources and src/test/resources). If one (additionally) needs a
> filtered resources folder, it needs to override the default and therefore has
> to add all default folders if he does NOT want to "loose" the defaults.
> To make this easier my suggestion is to add filtered resource folders to the
> super POM. This should also fit to the philosophy of maven that aims to have
> defaults and only declare as little custom configuration as needed.
> My personal favorite for the foldernames would be "templates" but to make
> things more obvious to the user maybe "resources-filtered" would be better.
> Actually I do not care to much about the name...
> So the resources in the super POM should look like this:
> {code:xml}
>
> src/main/resources
>
>
>
> src/main/resources-filtered
> true
>
>
>
>
>
> src/test/resources
>
>
>
> src/test/resources-filtered
> true
>
>
> {code}
> Update: The folder name has been changed to "resources-filtered".
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (MNG-5971) Imported dependencies should be available to inheritance processing
[
https://issues.apache.org/jira/browse/MNG-5971?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16286168#comment-16286168
]
Hudson commented on MNG-5971:
-
Build unstable in Jenkins: Maven TLP (wip) » maven » pre-reset-master #3
See https://builds.apache.org/job/maven-wip/job/maven/job/pre-reset-master/3/
> Imported dependencies should be available to inheritance processing
> ---
>
> Key: MNG-5971
> URL: https://issues.apache.org/jira/browse/MNG-5971
> Project: Maven
> Issue Type: Bug
> Components: Dependencies
>Affects Versions: 3.3.3
>Reporter: Stephane Nicoll
>Priority: Trivial
> Fix For: 3.6.0-candidate
>
> Attachments: bom-cloud.zip
>
>
> When a project extends from a parent with a {{dependencyManagement}} section,
> it is not always possible to properly override (and align) the version to use
> for a group of dependencies.
> We typically use Bill Of Materials to gather a group of modules and make sure
> their versions are consistent.
> The following project demonstrates the issue:
> https://github.com/snicoll-scratches/maven-dependency-management
> The first commit is a working use case where the parent uses a bom with
> version A and we use the same bom with version B in the child. Version B is
> used as expected.
> The second commit demonstrates the faulty scenario. Rather than using a bom
> in the parent, we use a direct dependency (provided by that bom). We still
> use the bom with a different version. In that case all the dependencies but
> the one provided by the parent are overridden (leading to mixed versions for
> the dependencies provided by the BOM).
> It looks like the distance is still used to compute the version while the
> graph of dependencies should be flatten at each step for a proper override.
> Thoughts? Thanks!
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (MNG-5783) cobertura-maven-plugin:instrument failing NoClassDefFoundError: org/slf4j/LoggerFactory
[
https://issues.apache.org/jira/browse/MNG-5783?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16286166#comment-16286166
]
Hudson commented on MNG-5783:
-
Build unstable in Jenkins: Maven TLP (wip) » maven » pre-reset-master #3
See https://builds.apache.org/job/maven-wip/job/maven/job/pre-reset-master/3/
> cobertura-maven-plugin:instrument failing NoClassDefFoundError:
> org/slf4j/LoggerFactory
> ---
>
> Key: MNG-5783
> URL: https://issues.apache.org/jira/browse/MNG-5783
> Project: Maven
> Issue Type: Bug
>Affects Versions: 3.3.0
>Reporter: Hervé Boutemy
>Assignee: igorfie
>Priority: Critical
> Fix For: 3.3.1
>
> Attachments: build-3.2.5.log, build-3.3.0-SNAPSHOT.log
>
>
> testing cobertura-maven-plugin from svn
> http://mojo.codehaus.org/cobertura-maven-plugin/
> IT pass with Maven 3.2.5 but fail with 3.3.0-SNAPSHOT
> (not the same issue as MNG-5779)
> {noformat}[DEBUG] /bin/sh -c /opt/jdk1.7.0_71/jre/bin/java
> -Dlog4j.configuration=file:/tmp/log4j1560920244563737852config.properties
> -Xmx1024m net.sourceforge.cobertura.instrument.InstrumentMain --commandsfile
> /tmp/cobertura.4914644993417176752.cmdline
> [DEBUG] exit code: 1
> [DEBUG]
> [DEBUG] Standard error from the Cobertura task:
> [DEBUG]
> [ERROR] Exception in thread "main" java.lang.NoClassDefFoundError:
> org/slf4j/LoggerFactory
> at
> net.sourceforge.cobertura.instrument.InstrumentMain$LoggerWrapper.(InstrumentMain.java:165)
> at
> net.sourceforge.cobertura.instrument.InstrumentMain$LoggerWrapper.(InstrumentMain.java:164)
> at
> net.sourceforge.cobertura.instrument.InstrumentMain.(InstrumentMain.java:66)
> Caused by: java.lang.ClassNotFoundException: org.slf4j.LoggerFactory
> at java.net.URLClassLoader$1.run(URLClassLoader.java:366)
> at java.net.URLClassLoader$1.run(URLClassLoader.java:355)
> at java.security.AccessController.doPrivileged(Native Method)
> at java.net.URLClassLoader.findClass(URLClassLoader.java:354)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:425)
> at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:308)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:358)
> ... 3 more
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (MNG-5940) Change the maven-source-plugin jar goal into jar-no-fork in Maven Super POM
[
https://issues.apache.org/jira/browse/MNG-5940?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16286163#comment-16286163
]
Hudson commented on MNG-5940:
-
Build unstable in Jenkins: Maven TLP (wip) » maven » pre-reset-master #3
See https://builds.apache.org/job/maven-wip/job/maven/job/pre-reset-master/3/
> Change the maven-source-plugin jar goal into jar-no-fork in Maven Super POM
> ---
>
> Key: MNG-5940
> URL: https://issues.apache.org/jira/browse/MNG-5940
> Project: Maven
> Issue Type: Improvement
> Components: core
>Reporter: Karl Heinz Marbaise
>Priority: Minor
> Fix For: needing-scrub-3.4.0-fallout
>
>
> At the moment the {{maven-source-plugin:jar}} goal is defined in the Maven
> super pom:
> {code:xml}
>
> true
> maven-source-plugin
>
>
> attach-sources
>
> jar
>
>
>
>
> {code}
> where the goal of {{maven-source-plugin}} should be changed from {{jar}} into
> {{jar-no-fork}}, cause most of the time you need to override this behaviour.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (MNG-5968) plugin version updates in Maven core build
[
https://issues.apache.org/jira/browse/MNG-5968?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16286160#comment-16286160
]
Hudson commented on MNG-5968:
-
Build unstable in Jenkins: Maven TLP (wip) » maven » pre-reset-master #3
See https://builds.apache.org/job/maven-wip/job/maven/job/pre-reset-master/3/
> plugin version updates in Maven core build
> --
>
> Key: MNG-5968
> URL: https://issues.apache.org/jira/browse/MNG-5968
> Project: Maven
> Issue Type: Improvement
>Affects Versions: 3.3.9
>Reporter: Christian Schulte
>Assignee: Michael Osipov
>Priority: Minor
> Fix For: 3.5.0-alpha-1, 3.5.0
>
>
> upgrade some plugins in Maven core build (pom.xml), just because newest are
> expected to be better (no known bug):
> ||groupId||artifactId||previous version||target version||
> |{{org.codehaus.mojo}}|{{buildnumber-maven-plugincol}}|1.2|1.4|
> |{{org.codehaus.mojo}}|{{animal-sniffer-maven-plugin}}|1.14|1.15|
> |{{org.apache.maven.plugins}}|{{maven-doap-plugin}}|1.1|1.2|
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (MNG-5581) Provide a way to customize lifecycle mapping logic
[ https://issues.apache.org/jira/browse/MNG-5581?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16286159#comment-16286159 ] Hudson commented on MNG-5581: - Build unstable in Jenkins: Maven TLP (wip) » maven » pre-reset-master #3 See https://builds.apache.org/job/maven-wip/job/maven/job/pre-reset-master/3/ > Provide a way to customize lifecycle mapping logic > -- > > Key: MNG-5581 > URL: https://issues.apache.org/jira/browse/MNG-5581 > Project: Maven > Issue Type: Improvement >Reporter: Igor Fedorenko >Assignee: igorfie > Fix For: 3.2.1 > > > Default lifecycle mapping logic uses plugin execution configuration > element to map to lifecycle instance. For custom lifecycles I would like to > be able to provide custom logic. Specific usecase is to be able to define > custom lifecycle which only runs specific phase from the default lifecycle > and nothing else. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (MNG-2199) Support version ranges in parent elements
[
https://issues.apache.org/jira/browse/MNG-2199?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16286157#comment-16286157
]
Hudson commented on MNG-2199:
-
Build unstable in Jenkins: Maven TLP (wip) » maven » pre-reset-master #3
See https://builds.apache.org/job/maven-wip/job/maven/job/pre-reset-master/3/
> Support version ranges in parent elements
> -
>
> Key: MNG-2199
> URL: https://issues.apache.org/jira/browse/MNG-2199
> Project: Maven
> Issue Type: Wish
> Components: Inheritance and Interpolation, POM, Reactor and workspace
>Affects Versions: 2.0.3
>Reporter: Christian Schulte
>Assignee: Christian Schulte
> Fix For: 3.5.0-alpha-1, 3.5.0
>
> Attachments: MNG-2199-3.0.4.patch, MNG-2199-3.0.4.patch,
> MNG-2199-3.1.0-alpha-1.patch, MNG-2199.patch, MNG-2199.patch, MNG-2199.patch,
> MNG-2199.patch, MNG-2199.patch, MNG-2199.patch, test-project.zip
>
>
> It would be great if Maven supports version ranges when specifying parent
> artifacts in a multi-module build. Currently this does not work.
> {code:xml}
> artifactId
> groupId
> [2.0, 2.0.1]
> {code}
> {noformat}[INFO] Scanning for projects...
> Downloading: http://repo1.maven.org/maven2/groupId/artifactId/[2.0,
> 2.0.1]/artifactId-[2.0, 2.0.1].pom{noformat}
> Additionally it would be great if this
> {code:xml}
> artifactId
> groupId
> [2.0, ${pom.version}]
> {code}
> {noformat}[INFO] Scanning for projects...
> Downloading: http://repo1.maven.org/maven2/groupId/artifactId/[2.0,
> ${pom.version}]/artifactId-[2.0, ${pom.version}].pom{noformat}
> would also work, if the version is specified in the same pom.xml which
> defines this parent definition.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (MINVOKER-231) Invoker plugin cannot set the threadcount of the invoked Maven
Timothy Ward created MINVOKER-231: - Summary: Invoker plugin cannot set the threadcount of the invoked Maven Key: MINVOKER-231 URL: https://issues.apache.org/jira/browse/MINVOKER-231 Project: Maven Invoker Plugin Issue Type: New Feature Affects Versions: 3.0.1 Reporter: Timothy Ward There is no obvious way to set the Thread Count (usually passed as `-T 4` in the CLI) when using invoker:run. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (MCOMPILER-318) Groovy files not been compiled when used with java9 spring boot
[ https://issues.apache.org/jira/browse/MCOMPILER-318?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yugant H Shah updated MCOMPILER-318: Description: Compiling java9+ groovy + maven code base does not compile groovy files. Attached is the sample project [ERROR] Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:3.7.0:compile (default-compile) on project api: Compilation failure: Compilation failure: [ERROR] lombok/dummy/ForceNewRound0.java:[1,1] file should be on source path, or on patch path for module [ERROR] /Users/yushah/home/git/JigsawTest/com.allstate.jigsaw.api/src/main/java/com/allstate/jigsaw/ServiceA.java:[24,32] cannot find symbol [ERROR] symbol: class GroovyService [ERROR] location: package com.allstate.jigsaw [ERROR] -> [Help 1] [ERROR] was: Compiling java9+ groovy + maven code base does not compile groovy files. Attached is the sample project > Groovy files not been compiled when used with java9 spring boot > --- > > Key: MCOMPILER-318 > URL: https://issues.apache.org/jira/browse/MCOMPILER-318 > Project: Maven Compiler Plugin > Issue Type: Bug >Affects Versions: 3.6.2, 3.7.0 >Reporter: Yugant H Shah > Attachments: JigsawTest.zip > > > Compiling java9+ groovy + maven code base does not compile groovy files. > Attached is the sample project > [ERROR] Failed to execute goal > org.apache.maven.plugins:maven-compiler-plugin:3.7.0:compile > (default-compile) on project api: Compilation failure: Compilation failure: > [ERROR] lombok/dummy/ForceNewRound0.java:[1,1] file should be on source path, > or on patch path for module > [ERROR] > /Users/yushah/home/git/JigsawTest/com.allstate.jigsaw.api/src/main/java/com/allstate/jigsaw/ServiceA.java:[24,32] > cannot find symbol > [ERROR] symbol: class GroovyService > [ERROR] location: package com.allstate.jigsaw > [ERROR] -> [Help 1] > [ERROR] -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (MCOMPILER-318) Groovy files not been compiled when used with java9 spring boot
Yugant H Shah created MCOMPILER-318: --- Summary: Groovy files not been compiled when used with java9 spring boot Key: MCOMPILER-318 URL: https://issues.apache.org/jira/browse/MCOMPILER-318 Project: Maven Compiler Plugin Issue Type: Bug Affects Versions: 3.7.0, 3.6.2 Reporter: Yugant H Shah Attachments: JigsawTest.zip Compiling java9+ groovy + maven code base does not compile groovy files. Attached is the sample project -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (MCOMPILER-310) Different behaviour between JDK 8 / JDK 9 related to annotation processor usage
[
https://issues.apache.org/jira/browse/MCOMPILER-310?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16285840#comment-16285840
]
Werner Glanzer commented on MCOMPILER-310:
--
Is there any activity on this issue?
Is it an issue?
> Different behaviour between JDK 8 / JDK 9 related to annotation processor
> usage
> ---
>
> Key: MCOMPILER-310
> URL: https://issues.apache.org/jira/browse/MCOMPILER-310
> Project: Maven Compiler Plugin
> Issue Type: Bug
>Affects Versions: 3.7.0
>Reporter: Karl Heinz Marbaise
>Priority: Critical
>
> Based on the
> [https://stackoverflow.com/questions/46500984/immutables-dont-generate-code-with-java-9-with-modules|SO
> question] is looks like we have a difference in behaviour between JDK 8 /
> JDK 9 related to the picking up of annotation processors.
> If you run the following code under JDK 8 (except for a module-info.java
> file):
> {code:xml}
>
> 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;>
> 4.0.0
> example
> jigsaw
> 1.0-SNAPSHOT
>
> UTF-8
>
>
>
> org.immutables
> value
> 2.5.6
> provided
>
>
>
>
>
> org.apache.maven.plugins
> maven-compiler-plugin
> 3.7.0
>
>
>
>
> {code}
> The maven-compiler-plugin will automatically pickup the annotation processor
> and produce the classed from the annotation.
> If you run the same with JDK 9 this will not work anymore. Only if you
> explicitly add the annotation processor configuration to
> maven-compiler-plugin it will work as expected:
> {code:xml}
>
> 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;>
> 4.0.0
> example
> jigsaw
> 1.0-SNAPSHOT
>
> UTF-8
>
>
>
> org.immutables
> value
> 2.5.6
> provided
>
>
>
>
>
> org.apache.maven.plugins
> maven-compiler-plugin
> 3.7.0
>
> 9
> 9
>
>
> org.immutables
> value
> 2.5.6
>
>
>
>
>
>
>
> {code}
> I'm not sure if this is based on the usage of modules (module-path instead of
> classpath)?
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (MNG-6287) improving inclusion of open source code referenced by java projects.
[ https://issues.apache.org/jira/browse/MNG-6287?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16285706#comment-16285706 ] Sunil Kumar Singh commented on MNG-6287: Thanks Robert. I tried it today and I agree with you that the functionality that I have implemented in the code-collector is very similar to what maven-shade-plugin does with the minimizeJar set to true. Probably the only thing that my code does additionally is that it downloads the source code for the reduced set of dependencies so the user can visualize it and see it in her source code tree if using an IDE. May be we can add a flag in the configuration section in the maven-shade-plugin to download the source code for these dependencies. or is it already there as well? > improving inclusion of open source code referenced by java projects. > - > > Key: MNG-6287 > URL: https://issues.apache.org/jira/browse/MNG-6287 > Project: Maven > Issue Type: New Feature >Reporter: Sunil Kumar Singh > > All the details are on git hub at: > https://github.com/ksunilsingh/code-collector > This is an idea on improving inclusion of open source code referenced by java > projects. Currently when we use a java build system (such as maven or > gradle), the build system downloads the jar files referenced by a java > project. What I am proposing here is a replacement for that: > Find out all the classes referenced by the classes in a java project (say, > project A). > Download the source code for these dependencies recursively and include the > downloaded source code in the source tree of project A. > Remove the dependency(ies) from project build configuration file (e.g. > pom.xml) and build the project. > The resulting jar file would be smaller in size than if the full jar for the > dependency is included as is. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (WAGON-492) Using Wagon component with Spring
[ https://issues.apache.org/jira/browse/WAGON-492?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16285667#comment-16285667 ] Laurent Granié commented on WAGON-492: -- Is DownloaderBean.java in the Attachments part enough? > Using Wagon component with Spring > - > > Key: WAGON-492 > URL: https://issues.apache.org/jira/browse/WAGON-492 > Project: Maven Wagon > Issue Type: Bug > Components: wagon-provider-api >Affects Versions: 2.12 >Reporter: Laurent Granié > Attachments: DownloaderBean.java > > > I'm using Wagon with Spring. > With version 2.10 it's ok. But since version 2.12 I can not load component > into Spring. > You can find my DownloaderServiceBean attached. > The error is like : > Unsatisfied dependency expressed through field 'downloader': Error > creating bean with name 'downloaderBean': Invocation of init method > failed; nested exception is java.lang.NoSuchMethodError: > org.codehaus.plexus.configuration.PlexusConfiguration.setName(Ljava/lang/String;)V; > nested exception is > org.springframework.beans.factory.BeanCreationException: Error > creating bean with name 'downloaderBean': Invocation of init method > failed; nested exception is java.lang.NoSuchMethodError: > org.codehaus.plexus.configuration.PlexusConfiguration.setName(Ljava/lang/String;)V -- This message was sent by Atlassian JIRA (v6.4.14#64029)
