[jira] [Commented] (MINVOKER-213) The plugin should escape any XML special characters (&<>) during interpolating XML files.
[ https://issues.apache.org/jira/browse/MINVOKER-213?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15879619#comment-15879619 ] Hudson commented on MINVOKER-213: - SUCCESS: Integrated in Jenkins build maven-plugins #8891 (See [https://builds.apache.org/job/maven-plugins/8891/]) [MINVOKER-213] The plugin should escape any XML special characters (&<>) during interpolating XML files. (schulte: [http://svn.apache.org/viewvc/?view=rev&rev=1784076]) * (edit) maven-invoker-plugin/src/main/java/org/apache/maven/plugin/invoker/AbstractInvokerMojo.java * (edit) maven-invoker-plugin/src/main/java/org/apache/maven/plugin/invoker/CompositeMap.java > The plugin should escape any XML special characters (&<>) during > interpolating XML files. > - > > Key: MINVOKER-213 > URL: https://issues.apache.org/jira/browse/MINVOKER-213 > Project: Maven Invoker Plugin > Issue Type: Bug >Reporter: Christian Schulte >Assignee: Christian Schulte >Priority: Blocker > Fix For: 3.0.0 > > > When interpolating XML files, the plugin does not escape any special XML > characters and may produce invalid XML. Building a project from inside a > directory like "directory name with spaces and & special char" is not > possible if that directory name is interpolated into XML files where the "&" > character leads to broken XML. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (MASSEMBLY-848) Version range dependencies not resolved from the reactor
[ https://issues.apache.org/jira/browse/MASSEMBLY-848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15879190#comment-15879190 ] ASF GitHub Bot commented on MASSEMBLY-848: -- GitHub user io7m opened a pull request: https://github.com/apache/maven-plugins/pull/104 MASSEMBLY-848 Do not attempt to resolve reactor projects I'm submitting this pull request in the hope of getting some discussion on the issue. I feel like the submitted fix here is not the right way to solve this problem but do not understand enough of the way Maven resolves artifacts to be sure. This change does at least appear to resolve the provided integration test properly and does not break any existing tests. ``` This is an attempt at addressing MASSEMBLY-848: When resolving the dependencies of a project, we explicitly avoid attempting to resolve any dependency artifacts that are also reactor projects. ``` You can merge this pull request into a Git repository by running: $ git pull https://github.com/io7m/maven-plugins trunk Alternatively you can review and apply these changes as the patch at: https://github.com/apache/maven-plugins/pull/104.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #104 commit c1c9576c7cedc3cfb06d79350251f2a4296b308c Author: Mark Raynsford Date: 2017-02-22T20:36:09Z MASSEMBLY-848 Do not attempt to resolve reactor projects This is an attempt at addressing MASSEMBLY-848: When resolving the dependencies of a project, we explicitly avoid attempting to resolve any dependency artifacts that are also reactor projects. > Version range dependencies not resolved from the reactor > > > Key: MASSEMBLY-848 > URL: https://issues.apache.org/jira/browse/MASSEMBLY-848 > Project: Maven Assembly Plugin > Issue Type: Bug >Affects Versions: 3.0.0 > Environment: Apache Maven 3.3.9 > (NON-CANONICAL_2015-11-23T13:17:27+03:00_root; 2015-11-23T10:17:27+00:00) > Maven home: /opt/maven > Java version: 1.8.0_121, vendor: Oracle Corporation > Java home: /usr/lib/jvm/java-8-openjdk/jre > Default locale: en_GB, platform encoding: UTF-8 > OS name: "linux", version: "4.8.13-1-arch", arch: "amd64", family: "unix" >Reporter: Mark Raynsford > Attachments: mvn.log.gz > > > When using modules that have independent version numbers (that is, modules in > the same project may have different version numbers), it's commonplace to > specify dependencies between modules with version ranges when using semantic > versioning. > For some reason, when version ranges are used on dependencies that refer to > modules that are part of the project (and therefore should be in the > reactor), the assembly plugin ignores them and tries to resolve them from the > local repository instead. > The following project reproduces this issue (just "mvn clean package"): > https://github.com/io7m/independent-versioning-20170207 > Interestingly, this didn't happen with the same assembly plugin on older > Maven versions. Here's a successful build on Travis CI: > https://travis-ci.org/io7m/independent-versioning-20170207 -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (SUREFIRE-1337) Add support for additional JUnit Platform selectors and filters
Marc Philipp created SUREFIRE-1337:
--
Summary: Add support for additional JUnit Platform selectors and
filters
Key: SUREFIRE-1337
URL: https://issues.apache.org/jira/browse/SUREFIRE-1337
Project: Maven Surefire
Issue Type: New Feature
Reporter: Marc Philipp
The JUnit Platform provider currently supports includeTags and excludeTags as
synonyms for groups and excludeGroups. The JUnit platform supports additional
filters, e.g. for engines and packages. Moreover, it supports selectors for
URIs, local files, local directories, packages, classes, methods, and classpath
resources.
It would be great if we could add support for these selectors and filters to
the provider via custom configuration properties, e.g. like this:
{code:xml}
maven-surefire-plugin
2.19.1
com.acme.foo
com.acme.bar
foo, bar
acceptance, integration
org.junit.platform
junit-platform-surefire-provider
${junit.platform.version}
{code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (MNG-6156) Resolving dependencies is not thread-safe
[
https://issues.apache.org/jira/browse/MNG-6156?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15879071#comment-15879071
]
Michael Osipov commented on MNG-6156:
-
No, I am currently examining serious regressions in Maven and Surefire master.
> Resolving dependencies is not thread-safe
> -
>
> Key: MNG-6156
> URL: https://issues.apache.org/jira/browse/MNG-6156
> Project: Maven
> Issue Type: Bug
> Components: Artifacts and Repositories
>Affects Versions: 3.3.9
>Reporter: Roland Illig
> Attachments: dependency-list.txt, dependency-list-x.zip,
> wagon-not-threadsafe.zip
>
>
> When building a multi-module project in parallel, Maven updates the local
> Maven repository without taking into account that other threads or processes
> might do the same at the same time.
> To reproduce:
> 1. unpack the attached project
> 2. {{mvn dependency:list -U -B -T100}}
> See the attached {{dependency-list.txt}} for an example output.
> First thing to notice is that the dependency is downloaded 100 times. This is
> unexpected, since the Reactor should coordinate all the modules.
> Second thing to notice is that the build fails, since a dependency "cannot be
> found". This is wrong, since the dependency _can_ be found, it's just not
> processed properly.
> I suspect the {{legacy.DefaultWagonManager}} to be the cause of this, since
> the typical error messages are:
> * {{"Downloaded file does not exist: "}}
> * {{"Error copying temporary file to the final destination: "}}
> * {{"*** CHECKSUM FAILED - RETRYING"}}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (MNG-6156) Resolving dependencies is not thread-safe
[
https://issues.apache.org/jira/browse/MNG-6156?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15879015#comment-15879015
]
Roland Illig commented on MNG-6156:
---
Hello [~michael-o], did you find time to look into this issue?
> Resolving dependencies is not thread-safe
> -
>
> Key: MNG-6156
> URL: https://issues.apache.org/jira/browse/MNG-6156
> Project: Maven
> Issue Type: Bug
> Components: Artifacts and Repositories
>Affects Versions: 3.3.9
>Reporter: Roland Illig
> Attachments: dependency-list.txt, dependency-list-x.zip,
> wagon-not-threadsafe.zip
>
>
> When building a multi-module project in parallel, Maven updates the local
> Maven repository without taking into account that other threads or processes
> might do the same at the same time.
> To reproduce:
> 1. unpack the attached project
> 2. {{mvn dependency:list -U -B -T100}}
> See the attached {{dependency-list.txt}} for an example output.
> First thing to notice is that the dependency is downloaded 100 times. This is
> unexpected, since the Reactor should coordinate all the modules.
> Second thing to notice is that the build fails, since a dependency "cannot be
> found". This is wrong, since the dependency _can_ be found, it's just not
> processed properly.
> I suspect the {{legacy.DefaultWagonManager}} to be the cause of this, since
> the typical error messages are:
> * {{"Downloaded file does not exist: "}}
> * {{"Error copying temporary file to the final destination: "}}
> * {{"*** CHECKSUM FAILED - RETRYING"}}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
