[jira] [Closed] (MSHARED-837) add an API to configure Reproducible Builds with outputTimestamp
[
https://issues.apache.org/jira/browse/MSHARED-837?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Herve Boutemy closed MSHARED-837.
-
Resolution: Fixed
https://gitbox.apache.org/repos/asf?p=maven-archiver.git&a=commit&h=60f166a66d485c7963035a97c76ca8fd9872d157
> add an API to configure Reproducible Builds with outputTimestamp
>
>
> Key: MSHARED-837
> URL: https://issues.apache.org/jira/browse/MSHARED-837
> Project: Maven Shared Components
> Issue Type: New Feature
> Components: maven-archiver
>Affects Versions: maven-archiver-3.4.0
>Reporter: Herve Boutemy
>Assignee: Herve Boutemy
>Priority: Major
> Fix For: maven-archiver-3.5.0
>
>
> creating an archive in a Reproducible Builds way requires to configure
> archiver with an output timestamp: see
> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=74682318
> The timestamp value can't be natively injected as Date with Plexus, because
> Plexus Date injection uses local timezone, then is not reproducible: see
> https://codehaus-plexus.github.io/plexus-containers/plexus-container-default/xref/org/codehaus/plexus/component/configurator/converters/basic/DateConverter.html
> Then we need top inject ${project.build.outputTimestamp} as a String and
> provide an API to parse this String to a Date, before calling
> plexus-archiver's configureReproducible
> https://github.com/codehaus-plexus/plexus-archiver/pull/121
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (MSHARED-838) upgrade plexus-archiver to 4.2.0 and plexus-utils to 3.3.0
[ https://issues.apache.org/jira/browse/MSHARED-838?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Herve Boutemy closed MSHARED-838. - Assignee: Herve Boutemy Resolution: Fixed https://gitbox.apache.org/repos/asf?p=maven-archiver.git&a=commit&h=f2c8803eb502fe41e949e4dbd14971ffe4e7bfa7 > upgrade plexus-archiver to 4.2.0 and plexus-utils to 3.3.0 > -- > > Key: MSHARED-838 > URL: https://issues.apache.org/jira/browse/MSHARED-838 > Project: Maven Shared Components > Issue Type: Dependency upgrade > Components: maven-archiver >Affects Versions: maven-archiver-3.4.0 >Reporter: Herve Boutemy >Assignee: Herve Boutemy >Priority: Major > Fix For: maven-archiver-3.5.0 > > > as requirement of Reproducible Builds > https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=74682318 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MSHARED-837) add an API to configure Reproducible Builds with outputTimestamp
[
https://issues.apache.org/jira/browse/MSHARED-837?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16955081#comment-16955081
]
Hudson commented on MSHARED-837:
Build succeeded in Jenkins: Maven TLP » maven-archiver » master #21
See https://builds.apache.org/job/maven-box/job/maven-archiver/job/master/21/
> add an API to configure Reproducible Builds with outputTimestamp
>
>
> Key: MSHARED-837
> URL: https://issues.apache.org/jira/browse/MSHARED-837
> Project: Maven Shared Components
> Issue Type: New Feature
> Components: maven-archiver
>Affects Versions: maven-archiver-3.4.0
>Reporter: Herve Boutemy
>Assignee: Herve Boutemy
>Priority: Major
> Fix For: maven-archiver-3.4.1
>
>
> creating an archive in a Reproducible Builds way requires to configure
> archiver with an output timestamp: see
> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=74682318
> The timestamp value can't be natively injected as Date with Plexus, because
> Plexus Date injection uses local timezone, then is not reproducible: see
> https://codehaus-plexus.github.io/plexus-containers/plexus-container-default/xref/org/codehaus/plexus/component/configurator/converters/basic/DateConverter.html
> Then we need top inject ${project.build.outputTimestamp} as a String and
> provide an API to parse this String to a Date, before calling
> plexus-archiver's configureReproducible
> https://github.com/codehaus-plexus/plexus-archiver/pull/121
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (MNG-6765) [Regression] tycho pom-less builds fails with 3.6.2
[
https://issues.apache.org/jira/browse/MNG-6765?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16954985#comment-16954985
]
Herve Boutemy edited comment on MNG-6765 at 10/19/19 5:42 AM:
--
[https://ci.eclipse.org/tycho/job/tycho-build-with-maven-snapshots/43/]
confirms that Eclipse Tycho, which had failing test for pom-less with
3.6.3-SNAPSHOT last week, seems to work fine with
[https://builds.apache.org/job/maven-box/job/maven/job/MNG-6765/2/artifact/org/apache/maven/apache-maven/3.6.3-SNAPSHOT/apache-maven-3.6.3-SNAPSHOT-bin.tar.gz]
https://github.com/apache/maven/tree/MNG-6765
was (Author: mickael.istria):
https://ci.eclipse.org/tycho/job/tycho-build-with-maven-snapshots/43/ confirms
that Eclipse Tycho, which had failing test for pom-less with 3.6.3-SNAPSHOT
last week, seems to work fine with
https://builds.apache.org/job/maven-box/job/maven/job/MNG-6765/2/artifact/org/apache/maven/apache-maven/3.6.3-SNAPSHOT/apache-maven-3.6.3-SNAPSHOT-bin.tar.gz
> [Regression] tycho pom-less builds fails with 3.6.2
> ---
>
> Key: MNG-6765
> URL: https://issues.apache.org/jira/browse/MNG-6765
> Project: Maven
> Issue Type: Bug
>Affects Versions: 3.6.2
>Reporter: Jonathan Chen
>Assignee: Robert Scholte
>Priority: Critical
>
> Projects using tycho pom-less builds fail with maven-3.6.2.
> One such example would be using maven-3.6.2 to build Eclipse-4.13, which
> fails pretty early in the build with:
> {noformat}
> [INFO] Scanning for projects...
> [ERROR] [ERROR] Some problems were encountered while processing the POMs:
> [FATAL] Non-readable POM
> /home/jonc/work/ports/freebsd-eclipse/eclipse.platform.releng.aggregator/eclipse.pde.ui/apitools/org.eclipse.pde.api.tools.ee.cdcfoundation10/.polyglot.build.properties:
> input contained no data @
> [FATAL] Non-readable POM
> /home/jonc/work/ports/freebsd-eclipse/eclipse.platform.releng.aggregator/eclipse.pde.ui/apitools/org.eclipse.pde.api.tools.ee.cdcfoundation11/.polyglot.build.properties:
> input contained no data @
> [FATAL] Non-readable POM
> /home/jonc/work/ports/freebsd-eclipse/eclipse.platform.releng.aggregator/eclipse.pde.ui/apitools/org.eclipse.pde.api.tools.ee.feature/.polyglot.build.properties:
> input contained no data @
> [FATAL] Non-readable POM
> /home/jonc/work/ports/freebsd-eclipse/eclipse.platform.releng.aggregator/eclipse.pde.ui/apitools/org.eclipse.pde.api.tools.ee.j2se12/.polyglot.build.properties:
> input contained no data @
> [FATAL] Non-readable POM
> /home/jonc/work/ports/freebsd-eclipse/eclipse.platform.releng.aggregator/eclipse.pde.ui/apitools/org.eclipse.pde.api.tools.ee.j2se13/.polyglot.build.properties:
> input contained no data @
> [FATAL] Non-readable POM
> /home/jonc/work/ports/freebsd-eclipse/eclipse.platform.releng.aggregator/eclipse.pde.ui/apitools/org.eclipse.pde.api.tools.ee.j2se14/.polyglot.build.properties:
> input contained no data @
> [FATAL] Non-readable POM
> /home/jonc/work/ports/freebsd-eclipse/eclipse.platform.releng.aggregator/eclipse.pde.ui/apitools/org.eclipse.pde.api.tools.ee.j2se15/.polyglot.build.properties:
> input contained no data @
> [FATAL] Non-readable POM
> /home/jonc/work/ports/freebsd-eclipse/eclipse.platform.releng.aggregator/eclipse.pde.ui/apitools/org.eclipse.pde.api.tools.ee.javase16/.polyglot.build.properties:
> input contained no data @
> [FATAL] Non-readable POM
> /home/jonc/work/ports/freebsd-eclipse/eclipse.platform.releng.aggregator/eclipse.pde.ui/apitools/org.eclipse.pde.api.tools.ee.javase17/.polyglot.build.properties:
> input contained no data @
> ...
> {noformat}
> These errors do not arise with maven-3.6.0 or maven-3.6.1
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [maven-integration-testing] srdo commented on issue #50: [MNG-6759] - Add test demonstrating the issue where the wrong reposit…
srdo commented on issue #50: [MNG-6759] - Add test demonstrating the issue where the wrong reposit… URL: https://github.com/apache/maven-integration-testing/pull/50#issuecomment-544013139 Fixed so the test now has no external dependencies. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Commented] (MNG-6765) [Regression] tycho pom-less builds fails with 3.6.2
[
https://issues.apache.org/jira/browse/MNG-6765?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16954985#comment-16954985
]
Mickael Istria commented on MNG-6765:
-
https://ci.eclipse.org/tycho/job/tycho-build-with-maven-snapshots/43/ confirms
that Eclipse Tycho, which had failing test for pom-less with 3.6.3-SNAPSHOT
last week, seems to work fine with
https://builds.apache.org/job/maven-box/job/maven/job/MNG-6765/2/artifact/org/apache/maven/apache-maven/3.6.3-SNAPSHOT/apache-maven-3.6.3-SNAPSHOT-bin.tar.gz
> [Regression] tycho pom-less builds fails with 3.6.2
> ---
>
> Key: MNG-6765
> URL: https://issues.apache.org/jira/browse/MNG-6765
> Project: Maven
> Issue Type: Bug
>Affects Versions: 3.6.2
>Reporter: Jonathan Chen
>Assignee: Robert Scholte
>Priority: Critical
>
> Projects using tycho pom-less builds fail with maven-3.6.2.
> One such example would be using maven-3.6.2 to build Eclipse-4.13, which
> fails pretty early in the build with:
> {noformat}
> [INFO] Scanning for projects...
> [ERROR] [ERROR] Some problems were encountered while processing the POMs:
> [FATAL] Non-readable POM
> /home/jonc/work/ports/freebsd-eclipse/eclipse.platform.releng.aggregator/eclipse.pde.ui/apitools/org.eclipse.pde.api.tools.ee.cdcfoundation10/.polyglot.build.properties:
> input contained no data @
> [FATAL] Non-readable POM
> /home/jonc/work/ports/freebsd-eclipse/eclipse.platform.releng.aggregator/eclipse.pde.ui/apitools/org.eclipse.pde.api.tools.ee.cdcfoundation11/.polyglot.build.properties:
> input contained no data @
> [FATAL] Non-readable POM
> /home/jonc/work/ports/freebsd-eclipse/eclipse.platform.releng.aggregator/eclipse.pde.ui/apitools/org.eclipse.pde.api.tools.ee.feature/.polyglot.build.properties:
> input contained no data @
> [FATAL] Non-readable POM
> /home/jonc/work/ports/freebsd-eclipse/eclipse.platform.releng.aggregator/eclipse.pde.ui/apitools/org.eclipse.pde.api.tools.ee.j2se12/.polyglot.build.properties:
> input contained no data @
> [FATAL] Non-readable POM
> /home/jonc/work/ports/freebsd-eclipse/eclipse.platform.releng.aggregator/eclipse.pde.ui/apitools/org.eclipse.pde.api.tools.ee.j2se13/.polyglot.build.properties:
> input contained no data @
> [FATAL] Non-readable POM
> /home/jonc/work/ports/freebsd-eclipse/eclipse.platform.releng.aggregator/eclipse.pde.ui/apitools/org.eclipse.pde.api.tools.ee.j2se14/.polyglot.build.properties:
> input contained no data @
> [FATAL] Non-readable POM
> /home/jonc/work/ports/freebsd-eclipse/eclipse.platform.releng.aggregator/eclipse.pde.ui/apitools/org.eclipse.pde.api.tools.ee.j2se15/.polyglot.build.properties:
> input contained no data @
> [FATAL] Non-readable POM
> /home/jonc/work/ports/freebsd-eclipse/eclipse.platform.releng.aggregator/eclipse.pde.ui/apitools/org.eclipse.pde.api.tools.ee.javase16/.polyglot.build.properties:
> input contained no data @
> [FATAL] Non-readable POM
> /home/jonc/work/ports/freebsd-eclipse/eclipse.platform.releng.aggregator/eclipse.pde.ui/apitools/org.eclipse.pde.api.tools.ee.javase17/.polyglot.build.properties:
> input contained no data @
> ...
> {noformat}
> These errors do not arise with maven-3.6.0 or maven-3.6.1
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-6772) Super POM overwrites remapped central repository in nested import POMs
[
https://issues.apache.org/jira/browse/MNG-6772?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16954977#comment-16954977
]
Eddie Wiegers commented on MNG-6772:
In our case Maven Central is reachable, we are just trying to force our builds
to go through our corporate repository manager for all artifacts instead of
pulling directly from Central. Builds can be performed on a variety of
developer machines, CI nodes, and occasionally separate release build nodes, so
controlling repositories via the POM and having the build be easily
reproducible seems more attractive than having to make sure settings.xml is set
up correctly everywhere. It{{ _almost_ }}works, but this edge case seems to be
one of the only things that doesn't work. If this setup isn't recommended by
the Maven community then perhaps we'll look into removing all repositories from
the POM and look into the effort to land standard settings everywhere instead.
> Super POM overwrites remapped central repository in nested import POMs
> --
>
> Key: MNG-6772
> URL: https://issues.apache.org/jira/browse/MNG-6772
> Project: Maven
> Issue Type: Bug
> Components: Artifacts and Repositories, POM
>Affects Versions: 3.6.2
>Reporter: Eddie Wiegers
>Priority: Major
> Time Spent: 20m
> Remaining Estimate: 0h
>
> My projects define a repository with {{central,}} which is meant to
> specifically override the entry in the Super POM. This is specifically what
> [JFrog Artifactory
> recommends|https://www.jfrog.com/confluence/display/RTF/Maven+Repository#MavenRepository-ManuallyOverridingtheBuilt-inRepositories]
> doing, and seems valid in situations where the _real_ Maven Central may be
> unreachable.
>
> The override takes precedence almost all of the time. However, there is at
> least one scenario where this is not the case, and that is when importing a
> POM that in turn imports another POM.
>
> Digging into the code, it appears the reason this happens is because the
> {{DefaultModelBuilder}} overwrites repositories after interpolation is
> complete:
> [https://github.com/apache/maven/blob/53f04f03e3e58c75dcc791d557758357a6ec7983/maven-model-builder/src/main/java/org/apache/maven/model/building/DefaultModelBuilder.java#L411]
>
> From what I can tell, this is done with the intention of overwriting
> repositories that were added to the local resolver prior to interpolation
> with the interpolated version. Due to the way the {{DefaultModelResolver}}
> works, an unintended side effect is that the {{central}} repository from the
> Super POM is added once after each interpolation. The first time the
> repository is added, it is added to the {{repositoryIds}} but doesn't
> actually remove the original repository. The second time it is added is when
> the original repository will be replaced. Currently, the repositoryIds are
> preserved in the {{ModelResolver}} when resolving import POMs, leading to the
> behavior I am seeing where the second nested import POM ends up being where
> the failure occurs.
>
> I am planning on submitting a PR to clone the {{ModelResolver}} in a way that
> resets the repositoryIds prior to import POMs being resolved, since they are
> separate artifact builds. That seems like the most consistent fix to me that
> covers cases outside of the the Super POM's {{central}} definition.
>
> *Workarounds*:
> The current workaround is to use a repository ID other than {{central}} for
> my Artifactory repository, which isn't ideal since it leaves the potential
> for long timeouts to occur on the real {{central}} when an artifact can't be
> resolved from my Artifactory repository.
>
> Mirrors are not an ideal workaround since getting them in place on all
> possible build environments isn't trivial.
>
> When looking at the code I noticed
> {{RepositorySystemSession#isIgnoreArtifactDescriptorRepositories()}} being
> checked in various places, which seems like it would also act as a potential
> workaround, but I don't see a way to enable this value via MavenCLI or
> properties of any kind. It seems like this value aligns well with what
> Artifactory is already trying to enforce, so it would make sense to enable
> this in projects that intend to exclusively use Artifactory. Is there a
> supported way to set this value outside of constructing a Maven build in code?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (MDEP-662) Re-Add Dependency Tree Verbose
[
https://issues.apache.org/jira/browse/MDEP-662?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte closed MDEP-662.
---
Assignee: Robert Scholte
Resolution: Duplicate
> Re-Add Dependency Tree Verbose
> --
>
> Key: MDEP-662
> URL: https://issues.apache.org/jira/browse/MDEP-662
> Project: Maven Dependency Plugin
> Issue Type: Improvement
> Components: tree
>Affects Versions: 3.1.1
>Reporter: Olof Larsson
>Assignee: Robert Scholte
>Priority: Minor
> Attachments: dependency-tree-verbose-colorized-screen.png
>
>
> Please re-add "*mvn dependency:tree -Dverbose*".
> *Ticket Bounty:* 300USD (will send via PayPal to address of authors choice
> upon feature re-addition with proper Maven 3 support)
> I find the command to be really useful and use it daily to check for
> transitive dependency clashes.
> It seems the command was removed in maven-dependency-plugin:2.11 because it
> used an outdated version of the dependency resolution mechanism?
> As a workaround I currently invoke the command like this:
> *mvn org.apache.maven.plugins:maven-dependency-plugin:2.10:tree -Dverbose*
> It's so useful I even added some colorization in bash:
>
> {code:java}
> function mdt() {
> mvn org.apache.maven.plugins:maven-dependency-plugin:2.10:tree -Dverbose
> $@ \
> | GREP_COLOR='01;31' grep --color=always -E 'omitted for conflict
> with|$' \
> | GREP_COLOR='01;31' grep --color=always -E 'version managed from|$' \
> | GREP_COLOR='01;32' grep --color=always -E 'omitted for duplicate|$'
> \
> | GREP_COLOR='01;35' grep --color=always -E ':test|$'
> }
> {code}
> !dependency-tree-verbose-colorized-screen.png|width=588,height=602!
> I execute this command every time I wonder if I messed up any transitive
> dependencies. It's a really good and quick sanity check command, and I think
> there's a strong user case for it.
> Sadly the workaround I use is an incorrect one. It will lie. The proper
> solution is probably to readd the feature with the new Aether resolution
> mechanism (Maven 3)?
> Examples of other people asking for the same thing:
> *
> [http://maven.40175.n5.nabble.com/Not-a-chance-to-show-conflicts-in-dependency-tree-td5944874.html]
> *
> [https://stackoverflow.com/questions/46416236/mvn-dependencytree-is-there-an-equivalent-available-for-verbose-output]
> Related Maven Link:
> *
> [https://cwiki.apache.org/confluence/display/MAVEN/Maven+3.x+Compatibility+Notes#Maven3.xCompatibilityNotes-DependencyResolution]
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (MNG-6772) Super POM overwrites remapped central repository in nested import POMs
[
https://issues.apache.org/jira/browse/MNG-6772?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eddie Wiegers updated MNG-6772:
---
Description:
My projects define a repository with {{central,}} which is meant to
specifically override the entry in the Super POM. This is specifically what
[JFrog Artifactory
recommends|https://www.jfrog.com/confluence/display/RTF/Maven+Repository#MavenRepository-ManuallyOverridingtheBuilt-inRepositories]
doing, and seems valid in situations where the _real_ Maven Central may be
unreachable.
The override takes precedence almost all of the time. However, there is at
least one scenario where this is not the case, and that is when importing a POM
that in turn imports another POM.
Digging into the code, it appears the reason this happens is because the
{{DefaultModelBuilder}} overwrites repositories after interpolation is complete:
[https://github.com/apache/maven/blob/53f04f03e3e58c75dcc791d557758357a6ec7983/maven-model-builder/src/main/java/org/apache/maven/model/building/DefaultModelBuilder.java#L411]
>From what I can tell, this is done with the intention of overwriting
>repositories that were added to the local resolver prior to interpolation with
>the interpolated version. Due to the way the {{DefaultModelResolver}} works,
>an unintended side effect is that the {{central}} repository from the Super
>POM is added once after each interpolation. The first time the repository is
>added, it is added to the {{repositoryIds}} but doesn't actually remove the
>original repository. The second time it is added is when the original
>repository will be replaced. Currently, the repositoryIds are preserved in the
>{{ModelResolver}} when resolving import POMs, leading to the behavior I am
>seeing where the second nested import POM ends up being where the failure
>occurs.
I am planning on submitting a PR to clone the {{ModelResolver}} in a way that
resets the repositoryIds prior to import POMs being resolved, since they are
separate artifact builds. That seems like the most consistent fix to me that
covers cases outside of the the Super POM's {{central}} definition.
*Workarounds*:
The current workaround is to use a repository ID other than {{central}} for my
Artifactory repository, which isn't ideal since it leaves the potential for
long timeouts to occur on the real {{central}} when an artifact can't be
resolved from my Artifactory repository.
Mirrors are not an ideal workaround since getting them in place on all possible
build environments isn't trivial.
When looking at the code I noticed
{{RepositorySystemSession#isIgnoreArtifactDescriptorRepositories()}} being
checked in various places, which seems like it would also act as a potential
workaround, but I don't see a way to enable this value via MavenCLI or
properties of any kind. It seems like this value aligns well with what
Artifactory is already trying to enforce, so it would make sense to enable this
in projects that intend to exclusively use Artifactory. Is there a supported
way to set this value outside of constructing a Maven build in code?
was:
My projects define a repository with {{central,}} which is meant to
specifically override the entry in the Super POM. This is specifically what
[JFrog Artifactory
recommends|[https://www.jfrog.com/confluence/display/RTF/Maven+Repository#MavenRepository-ManuallyOverridingtheBuilt-inRepositories]]
doing, and seems valid in situations where the _real_ Maven Central may be
unreachable.
The override takes precedence almost all of the time. However, there is at
least one scenario where this is not the case, and that is when importing a POM
that in turn imports another POM.
Digging into the code, it appears the reason this happens is because the
{{DefaultModelBuilder}} overwrites repositories after interpolation is complete:
[https://github.com/apache/maven/blob/53f04f03e3e58c75dcc791d557758357a6ec7983/maven-model-builder/src/main/java/org/apache/maven/model/building/DefaultModelBuilder.java#L411]
>From what I can tell, this is done with the intention of overwriting
>repositories that were added to the local resolver prior to interpolation with
>the interpolated version. Due to the way the {{DefaultModelResolver}} works,
>an unintended side effect is that the {{central}} repository from the Super
>POM is added once after each interpolation. The first time the repository is
>added, it is added to the {{repositoryIds}} but doesn't actually remove the
>original repository. The second time it is added is when the original
>repository will be replaced. Currently, the repositoryIds are preserved in the
>{{ModelResolver}} when resolving import POMs, leading to the behavior I am
>seeing where the second nested import POM ends up being where the failure
>occurs.
I am planning on submitting a PR to clone the {{ModelResolver}} in a way that
reset
[jira] [Commented] (MNG-6772) Super POM overwrites remapped central repository in nested import POMs
[
https://issues.apache.org/jira/browse/MNG-6772?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16954957#comment-16954957
]
Robert Scholte commented on MNG-6772:
-
Brian Fox already wrote an article about this like ten years ago:
https://blog.sonatype.com/2009/02/why-putting-repositories-in-your-poms-is-a-bad-idea/
To me repositories should never be overridden in the pom, despite the advice of
JFrog (would like to see the right URL, though). You may introduce new
repositories if plugins or depedencies are in a different repo than the
inherited ones.
The proper way to change URLs is by using mirrors. This was actually the
original purpose of mirrors. At some point mirrorOf * was introduced for
repositoryManagers, but I think that was a mistake, it is more a proxy, but
this happened a long time ago, we just need to accept that choice.
Out of curiosity, how often does it happen that Maven Central is unreachable or
gives timeout (and where you are certain it is a Sonatype issue and not your
own infra)?
> Super POM overwrites remapped central repository in nested import POMs
> --
>
> Key: MNG-6772
> URL: https://issues.apache.org/jira/browse/MNG-6772
> Project: Maven
> Issue Type: Bug
> Components: Artifacts and Repositories, POM
>Affects Versions: 3.6.2
>Reporter: Eddie Wiegers
>Priority: Major
> Time Spent: 20m
> Remaining Estimate: 0h
>
> My projects define a repository with {{central,}} which is meant to
> specifically override the entry in the Super POM. This is specifically what
> [JFrog Artifactory
> recommends|[https://www.jfrog.com/confluence/display/RTF/Maven+Repository#MavenRepository-ManuallyOverridingtheBuilt-inRepositories]]
> doing, and seems valid in situations where the _real_ Maven Central may be
> unreachable.
>
> The override takes precedence almost all of the time. However, there is at
> least one scenario where this is not the case, and that is when importing a
> POM that in turn imports another POM.
>
> Digging into the code, it appears the reason this happens is because the
> {{DefaultModelBuilder}} overwrites repositories after interpolation is
> complete:
> [https://github.com/apache/maven/blob/53f04f03e3e58c75dcc791d557758357a6ec7983/maven-model-builder/src/main/java/org/apache/maven/model/building/DefaultModelBuilder.java#L411]
>
> From what I can tell, this is done with the intention of overwriting
> repositories that were added to the local resolver prior to interpolation
> with the interpolated version. Due to the way the {{DefaultModelResolver}}
> works, an unintended side effect is that the {{central}} repository from the
> Super POM is added once after each interpolation. The first time the
> repository is added, it is added to the {{repositoryIds}} but doesn't
> actually remove the original repository. The second time it is added is when
> the original repository will be replaced. Currently, the repositoryIds are
> preserved in the {{ModelResolver}} when resolving import POMs, leading to the
> behavior I am seeing where the second nested import POM ends up being where
> the failure occurs.
>
> I am planning on submitting a PR to clone the {{ModelResolver}} in a way that
> resets the repositoryIds prior to import POMs being resolved, since they are
> separate artifact builds. That seems like the most consistent fix to me that
> covers cases outside of the the Super POM's {{central}} definition.
>
> *Workarounds*:
> The current workaround is to use a repository ID other than {{central}} for
> my Artifactory repository, which isn't ideal since it leaves the potential
> for long timeouts to occur on the real {{central}} when an artifact can't be
> resolved from my Artifactory repository.
>
> Mirrors are not an ideal workaround since getting them in place on all
> possible build environments isn't trivial.
>
> When looking at the code I noticed
> {{RepositorySystemSession#isIgnoreArtifactDescriptorRepositories()}} being
> checked in various places, which seems like it would also act as a potential
> workaround, but I don't see a way to enable this value via MavenCLI or
> properties of any kind. It seems like this value aligns well with what
> Artifactory is already trying to enforce, so it would make sense to enable
> this in projects that intend to exclusively use Artifactory. Is there a
> supported way to set this value outside of constructing a Maven build in code?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [maven-javadoc-plugin] michael-o commented on issue #32: [MJAVADOC-625] Support for multiple stylesheets
michael-o commented on issue #32: [MJAVADOC-625] Support for multiple stylesheets URL: https://github.com/apache/maven-javadoc-plugin/pull/32#issuecomment-543942457 I understand that, but if the original option can be called multiple times, it feels natural that this plugin supports this too. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [maven-surefire] Tibor17 commented on issue #245: Surefire-1584: Add option to rerun failing tests for JUnit5
Tibor17 commented on issue #245: Surefire-1584: Add option to rerun failing tests for JUnit5 URL: https://github.com/apache/maven-surefire/pull/245#issuecomment-543901329 @quiram If I understood the bug right in our code, it should be possible to reproduce it even without Spring Boot. You are trying to use the original commercial project and then you are reducing it somehow? Take your time, no worries, I will wait because this issue is important for reliability of this feature. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [maven-surefire] quiram commented on issue #245: Surefire-1584: Add option to rerun failing tests for JUnit5
quiram commented on issue #245: Surefire-1584: Add option to rerun failing tests for JUnit5 URL: https://github.com/apache/maven-surefire/pull/245#issuecomment-543898178 I can't provide the exact case because that's internal code, and when I tried to produce a sample project I didn't manage to reproduce it, but I'll keep trying. @Col-E if you do create a new issue please let me know to continue the conversation there. Thanks! This is an automated message from the Apache Git Service. To respond to the message, please log on to 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] (MWAR-426) Failed to execute goal org.apache.maven.plugins:maven-war-plugin:2.6:exploded (pre-exploded-war) openjdk1.8u222
[ https://issues.apache.org/jira/browse/MWAR-426?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Scholte updated MWAR-426: Affects Version/s: 2.6 > Failed to execute goal org.apache.maven.plugins:maven-war-plugin:2.6:exploded > (pre-exploded-war) openjdk1.8u222 > --- > > Key: MWAR-426 > URL: https://issues.apache.org/jira/browse/MWAR-426 > Project: Maven WAR Plugin > Issue Type: Bug >Affects Versions: 2.6 > Environment: NAME="Ubuntu" > VERSION="18.04.3 LTS (Bionic Beaver)" > ID=ubuntu > ID_LIKE=debian > PRETTY_NAME="Ubuntu 18.04.3 LTS" > VERSION_ID="18.04" > # arch > x86_64 > # java -version > openjdk version "1.8.0_222" > OpenJDK Runtime Environment (build 1.8.0_222-8u222-b10-1ubuntu1~18.04.1-b10) > OpenJDK 64-Bit Server VM (build 25.222-b10, mixed mode) > # mvn --version > Apache Maven 3.6.0 > Maven home: /usr/share/maven > Java version: 1.8.0_222, vendor: Private Build, runtime: > /usr/lib/jvm/java-8-openjdk-amd64/jre > Default locale: en_US, platform encoding: ANSI_X3.4-1968 > OS name: "linux", version: "4.4.0-154-generic", arch: "amd64", family: "unix" >Reporter: Vibhuti Sawant >Priority: Blocker > > [ERROR] Failed to execute goal > org.apache.maven.plugins:maven-war-plugin:2.6:exploded (pre-exploded-war) on > project alfresco-platform: Execution pre-exploded-war of goal > org.apache.maven.plugins:maven-war-plugin:2.6:exploded failed: Cannot > construct org.apache.maven.plugin.war.util.WebappStructure as it does not > have a no-args constructor : Cannot construct > org.apache.maven.plugin.war.util.WebappStructure as it does not have a > no-args constructor > [ERROR] Debugging information > [ERROR] message : Cannot construct > org.apache.maven.plugin.war.util.WebappStructure as it does not have a > no-args constructor > [ERROR] cause-exception : > com.thoughtworks.xstream.converters.reflection.ObjectAccessException > [ERROR] cause-message : Cannot construct > org.apache.maven.plugin.war.util.WebappStructure as it does not have a > no-args constructor > [ERROR] class : org.apache.maven.plugin.war.util.WebappStructure > [ERROR] required-type : org.apache.maven.plugin.war.util.WebappStructure > [ERROR] converter-type : > com.thoughtworks.xstream.converters.reflection.ReflectionConverter > [ERROR] path : /webapp-structure > [ERROR] version : null > [ERROR] --- > [ERROR] -> [Help 1] > > please guide in understanding what could be the issue. As the same command > had worked fine with previous openjdk versions. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Moved] (MWAR-426) Failed to execute goal org.apache.maven.plugins:maven-war-plugin:2.6:exploded (pre-exploded-war) openjdk1.8u222
[ https://issues.apache.org/jira/browse/MWAR-426?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Scholte moved MNG-6750 to MWAR-426: -- Key: MWAR-426 (was: MNG-6750) Project: Maven WAR Plugin (was: Maven) > Failed to execute goal org.apache.maven.plugins:maven-war-plugin:2.6:exploded > (pre-exploded-war) openjdk1.8u222 > --- > > Key: MWAR-426 > URL: https://issues.apache.org/jira/browse/MWAR-426 > Project: Maven WAR Plugin > Issue Type: Bug > Environment: NAME="Ubuntu" > VERSION="18.04.3 LTS (Bionic Beaver)" > ID=ubuntu > ID_LIKE=debian > PRETTY_NAME="Ubuntu 18.04.3 LTS" > VERSION_ID="18.04" > # arch > x86_64 > # java -version > openjdk version "1.8.0_222" > OpenJDK Runtime Environment (build 1.8.0_222-8u222-b10-1ubuntu1~18.04.1-b10) > OpenJDK 64-Bit Server VM (build 25.222-b10, mixed mode) > # mvn --version > Apache Maven 3.6.0 > Maven home: /usr/share/maven > Java version: 1.8.0_222, vendor: Private Build, runtime: > /usr/lib/jvm/java-8-openjdk-amd64/jre > Default locale: en_US, platform encoding: ANSI_X3.4-1968 > OS name: "linux", version: "4.4.0-154-generic", arch: "amd64", family: "unix" >Reporter: Vibhuti Sawant >Priority: Blocker > > [ERROR] Failed to execute goal > org.apache.maven.plugins:maven-war-plugin:2.6:exploded (pre-exploded-war) on > project alfresco-platform: Execution pre-exploded-war of goal > org.apache.maven.plugins:maven-war-plugin:2.6:exploded failed: Cannot > construct org.apache.maven.plugin.war.util.WebappStructure as it does not > have a no-args constructor : Cannot construct > org.apache.maven.plugin.war.util.WebappStructure as it does not have a > no-args constructor > [ERROR] Debugging information > [ERROR] message : Cannot construct > org.apache.maven.plugin.war.util.WebappStructure as it does not have a > no-args constructor > [ERROR] cause-exception : > com.thoughtworks.xstream.converters.reflection.ObjectAccessException > [ERROR] cause-message : Cannot construct > org.apache.maven.plugin.war.util.WebappStructure as it does not have a > no-args constructor > [ERROR] class : org.apache.maven.plugin.war.util.WebappStructure > [ERROR] required-type : org.apache.maven.plugin.war.util.WebappStructure > [ERROR] converter-type : > com.thoughtworks.xstream.converters.reflection.ReflectionConverter > [ERROR] path : /webapp-structure > [ERROR] version : null > [ERROR] --- > [ERROR] -> [Help 1] > > please guide in understanding what could be the issue. As the same command > had worked fine with previous openjdk versions. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [maven-surefire] Tibor17 commented on issue #245: Surefire-1584: Add option to rerun failing tests for JUnit5
Tibor17 commented on issue #245: Surefire-1584: Add option to rerun failing tests for JUnit5 URL: https://github.com/apache/maven-surefire/pull/245#issuecomment-543869144 @Col-E ok, :-) thx, but do it in a new PR and new branch. Delete the old branch because I modified yours (added tests and `restart()`) and now it is in master. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [maven-surefire] Col-E commented on issue #245: Surefire-1584: Add option to rerun failing tests for JUnit5
Col-E commented on issue #245: Surefire-1584: Add option to rerun failing tests for JUnit5 URL: https://github.com/apache/maven-surefire/pull/245#issuecomment-543864271 I'll happily work on a fix for this bug as soon as an offending test case is produced :+1: This is an automated message from the Apache Git Service. To respond to the message, please log on to 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] [Closed] (MNG-6758) [Regression] Compilation failure
[
https://issues.apache.org/jira/browse/MNG-6758?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte closed MNG-6758.
---
Assignee: Robert Scholte
Resolution: Cannot Reproduce
I cannot reproduce the issue, compiles as expected with both versions.
Also, I cannot see how Maven could cause such an exception, that's really at a
different level.
(and please provide a small reproducible project next time, so we can transform
it into a unittest or integration-test. Quarkus is just too big to analyse for
1 issue)
> [Regression] Compilation failure
>
>
> Key: MNG-6758
> URL: https://issues.apache.org/jira/browse/MNG-6758
> Project: Maven
> Issue Type: Bug
>Affects Versions: 3.6.2
>Reporter: Guillaume Nodet
>Assignee: Robert Scholte
>Priority: Critical
>
> Compilation failure when building with maven 3.6.2 but works with 3.6.1.
> {{Repository: [https://github.com/quarkusio/quarkus.git]}}
> {{Branch: 0.21}}
> {{Commit: }}{{63643eff9b10cd5e14aa12a75aae2e0b6e771612}}
>
> Steps to reproduce:
> {{git clone [https://github.com/quarkusio/quarkus.git]}}
> {{cd quarkus}}
> {{git checkout 63643eff9b10cd5e14aa12a75aae2e0b6e771612}}
> {{mvn install -DskipTests}}
>
> This leads to the following error:
> {{[*ERROR*] Failed to execute goal
> io.quarkus:quarkus-maven-plugin:999-SRC-revision-c9add195bbc0014a984dc0f73835e84ff042d021:build
> *(default)* on project quarkus-integration-test-hibernate-validator: *Failed
> to build a runnable JAR*: Failed to build a runner jar: Failed to augment
> application classes: Unsupported method parameter class
> io.quarkus.resteasy.server.common.runtime.ResteasyServerCommonRecorder at
> io.quarkus.resteasy.server.common.runtime.ResteasyServerCommonRecorder arg0
> of
> io.quarkus.resteasy.server.common.deployment.ResteasyInjectionReadyBuildItem
> io.quarkus.resteasy.server.common.deployment.ResteasyServerCommonProcessor.setupInjection(io.quarkus.resteasy.server.common.runtime.ResteasyServerCommonRecorder,io.quarkus.arc.deployment.BeanContainerBuildItem,java.util.List)
> of class
> io.quarkus.resteasy.server.common.deployment.ResteasyServerCommonProcessor ->
> *[Help 1]*}}
> Which seems to be caused by an annotation not being recognized correctly
> (different classloader ?).
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (MRELEASE-1030) Introduce flag to push once, not twice, during release:prepare
[ https://issues.apache.org/jira/browse/MRELEASE-1030?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Burrell updated MRELEASE-1030: - Description: h2. Scenario: When performing `release:prepare` the following action is taken. * solidify releases * commit and push * tag this commit * push tag * move to next snapshot * commit and push h2. Problem: This behaviour in a git based CI environment results in additional unnecessary builds as an untagged commit is delivered, quickly followed by the same commit in tagged form. Build systems are setup to look for tagged commits to initiate a release process, but the double push results in a 2 builds: (the same code, but one untagged). h2. Proposal: The commit and push that happens in stage 2 above should be a commit only. The push should be a push of the tag (which implicitly pushes the commit). To maintain backward compatibility this behaviour should be a flag, with the default to current behaviour. If this plugin is built on the scm code base then I suspect this is down to generic usage of the scm, without consideration of the nuances of git. (Pushing after every commit). The scm plugin does indeed have a flag for this purpose but we are not making use of it or allowing it to be configured in the release plugin. I think `pushChanges` [here|#l95]] would suppress all pushes from being committed including the tag and nextsnapshot commits, and so would not work. was: h2. Scenario: When performing release:prepare the following action is taken. * solidify releases * commit and push * tag this commit * push tag * move to next snapshot * commit and push h2. Problem: This behaviour in a git based CI environment results in additional unnecessary builds as an untagged commit is delivered, quickly followed by the same commit in tagged form. Build systems are setup to look for tagged commits to initiate a release process, but the double push results in a 2 builds: (the same code, but one untagged). h2. Proposal: The commit and push that happens in stage 2 above should be a commit only. The push should be a push of the tag (which implicitly pushes the commit). To maintain backward compatibility this behaviour should be a flag, with the default to current behaviour. If this plugin is built on the scm code base then I suspect this is down to generic usage of the scm, without consideration of the nuances of git. (Pushing after every commit). The scm plugin does indeed have a flag for this purpose but we are not making use of it or allowing it to be configured in the release plugin. I think `pushChanges` [here|#l95]] would suppress all pushes from being committed including the tag and nextsnapshot commits, and so would not work. > Introduce flag to push once, not twice, during release:prepare > -- > > Key: MRELEASE-1030 > URL: https://issues.apache.org/jira/browse/MRELEASE-1030 > Project: Maven Release Plugin > Issue Type: Improvement > Components: prepare >Affects Versions: 2.5.3 >Reporter: Daniel Burrell >Priority: Major > > h2. Scenario: > When performing `release:prepare` the following action is taken. > * solidify releases > * commit and push > * tag this commit > * push tag > * move to next snapshot > * commit and push > h2. Problem: > This behaviour in a git based CI environment results in additional > unnecessary builds as an untagged commit is delivered, quickly followed by > the same commit in tagged form. Build systems are setup to look for tagged > commits to initiate a release process, but the double push results in a 2 > builds: (the same code, but one untagged). > h2. Proposal: > The commit and push that happens in stage 2 above should be a commit only. > The push should be a push of the tag (which implicitly pushes the commit). > To maintain backward compatibility this behaviour should be a flag, with the > default to current behaviour. > If this plugin is built on the scm code base then I suspect this is down to > generic usage of the scm, without consideration of the nuances of git. > (Pushing after every commit). The scm plugin does indeed have a flag for this > purpose but we are not making use of it or allowing it to be configured in > the release plugin. > I think `pushChanges` [here|#l95]] would suppress all pushes from being > committed including the tag and nextsnapshot commits, and so would not work. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (MRELEASE-1030) Introduce flag to push once, not twice, during release:prepare
[ https://issues.apache.org/jira/browse/MRELEASE-1030?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Burrell updated MRELEASE-1030: - Description: h2. Scenario: When performing release:prepare the following action is taken. * solidify releases * commit and push * tag this commit * push tag * move to next snapshot * commit and push h2. Problem: This behaviour in a git based CI environment results in additional unnecessary builds as an untagged commit is delivered, quickly followed by the same commit in tagged form. Build systems are setup to look for tagged commits to initiate a release process, but the double push results in a 2 builds: (the same code, but one untagged). h2. Proposal: The commit and push that happens in stage 2 above should be a commit only. The push should be a push of the tag (which implicitly pushes the commit). To maintain backward compatibility this behaviour should be a flag, with the default to current behaviour. If this plugin is built on the scm code base then I suspect this is down to generic usage of the scm, without consideration of the nuances of git. (Pushing after every commit). The scm plugin does indeed have a flag for this purpose but we are not making use of it or allowing it to be configured in the release plugin. I think `pushChanges` [here|#l95]] would suppress all pushes from being committed including the tag and nextsnapshot commits, and so would not work. was: When performing release:prepare the following action is taken. * solidify releases * commit and push * tag this commit * push tag * move to next snapshot * commit and push This behaviour in a git based CI environment results in additional unnecessary builds as an untagged commit is delivered, quickly followed by the same commit in tagged form. Build systems are setup to look for tagged commits to initiate a release process, but the double push results in a 2 builds: (the same code, but one untagged). proposal: The commit and push that happens in stage 2 above should be a commit only. the push should be a push of the tag (which implicitly pushes the commit). To maintain backward compatibility this behaviour should be a flag, with the default to current behaviour I suspect this issue is caused by generic usage of scm info, without consideration of the nuances of git. (Pushing after every commit). The scm plugin does indeed have a flag for this purpose but we are not making use of it or exposing it at the release plugin level > Introduce flag to push once, not twice, during release:prepare > -- > > Key: MRELEASE-1030 > URL: https://issues.apache.org/jira/browse/MRELEASE-1030 > Project: Maven Release Plugin > Issue Type: Improvement > Components: prepare >Affects Versions: 2.5.3 >Reporter: Daniel Burrell >Priority: Major > > h2. Scenario: > When performing release:prepare the following action is taken. * solidify > releases * commit and push * tag this commit * push tag * move to next > snapshot * commit and push > h2. Problem: > This behaviour in a git based CI environment results in additional > unnecessary builds as an untagged commit is delivered, quickly followed by > the same commit in tagged form. Build systems are setup to look for tagged > commits to initiate a release process, but the double push results in a 2 > builds: (the same code, but one untagged). > h2. Proposal: > The commit and push that happens in stage 2 above should be a commit only. > The push should be a push of the tag (which implicitly pushes the commit). > To maintain backward compatibility this behaviour should be a flag, with the > default to current behaviour. > If this plugin is built on the scm code base then I suspect this is down to > generic usage of the scm, without consideration of the nuances of git. > (Pushing after every commit). The scm plugin does indeed have a flag for this > purpose but we are not making use of it or allowing it to be configured in > the release plugin. > I think `pushChanges` [here|#l95]] would suppress all pushes from being > committed including the tag and nextsnapshot commits, and so would not work. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-6765) [Regression] tycho pom-less builds fails with 3.6.2
[
https://issues.apache.org/jira/browse/MNG-6765?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16954785#comment-16954785
]
Hudson commented on MNG-6765:
-
Build succeeded in Jenkins: Maven TLP » maven » MNG-6765 #2
See https://builds.apache.org/job/maven-box/job/maven/job/MNG-6765/2/
> [Regression] tycho pom-less builds fails with 3.6.2
> ---
>
> Key: MNG-6765
> URL: https://issues.apache.org/jira/browse/MNG-6765
> Project: Maven
> Issue Type: Bug
>Affects Versions: 3.6.2
>Reporter: Jonathan Chen
>Assignee: Robert Scholte
>Priority: Critical
>
> Projects using tycho pom-less builds fail with maven-3.6.2.
> One such example would be using maven-3.6.2 to build Eclipse-4.13, which
> fails pretty early in the build with:
> {noformat}
> [INFO] Scanning for projects...
> [ERROR] [ERROR] Some problems were encountered while processing the POMs:
> [FATAL] Non-readable POM
> /home/jonc/work/ports/freebsd-eclipse/eclipse.platform.releng.aggregator/eclipse.pde.ui/apitools/org.eclipse.pde.api.tools.ee.cdcfoundation10/.polyglot.build.properties:
> input contained no data @
> [FATAL] Non-readable POM
> /home/jonc/work/ports/freebsd-eclipse/eclipse.platform.releng.aggregator/eclipse.pde.ui/apitools/org.eclipse.pde.api.tools.ee.cdcfoundation11/.polyglot.build.properties:
> input contained no data @
> [FATAL] Non-readable POM
> /home/jonc/work/ports/freebsd-eclipse/eclipse.platform.releng.aggregator/eclipse.pde.ui/apitools/org.eclipse.pde.api.tools.ee.feature/.polyglot.build.properties:
> input contained no data @
> [FATAL] Non-readable POM
> /home/jonc/work/ports/freebsd-eclipse/eclipse.platform.releng.aggregator/eclipse.pde.ui/apitools/org.eclipse.pde.api.tools.ee.j2se12/.polyglot.build.properties:
> input contained no data @
> [FATAL] Non-readable POM
> /home/jonc/work/ports/freebsd-eclipse/eclipse.platform.releng.aggregator/eclipse.pde.ui/apitools/org.eclipse.pde.api.tools.ee.j2se13/.polyglot.build.properties:
> input contained no data @
> [FATAL] Non-readable POM
> /home/jonc/work/ports/freebsd-eclipse/eclipse.platform.releng.aggregator/eclipse.pde.ui/apitools/org.eclipse.pde.api.tools.ee.j2se14/.polyglot.build.properties:
> input contained no data @
> [FATAL] Non-readable POM
> /home/jonc/work/ports/freebsd-eclipse/eclipse.platform.releng.aggregator/eclipse.pde.ui/apitools/org.eclipse.pde.api.tools.ee.j2se15/.polyglot.build.properties:
> input contained no data @
> [FATAL] Non-readable POM
> /home/jonc/work/ports/freebsd-eclipse/eclipse.platform.releng.aggregator/eclipse.pde.ui/apitools/org.eclipse.pde.api.tools.ee.javase16/.polyglot.build.properties:
> input contained no data @
> [FATAL] Non-readable POM
> /home/jonc/work/ports/freebsd-eclipse/eclipse.platform.releng.aggregator/eclipse.pde.ui/apitools/org.eclipse.pde.api.tools.ee.javase17/.polyglot.build.properties:
> input contained no data @
> ...
> {noformat}
> These errors do not arise with maven-3.6.0 or maven-3.6.1
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [maven-install-plugin] khmarbaise commented on issue #5: Fix typo in InstallMojo.java
khmarbaise commented on issue #5: Fix typo in InstallMojo.java URL: https://github.com/apache/maven-install-plugin/pull/5#issuecomment-543815266 Is merged into master. Thanks. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [maven-install-plugin] khmarbaise closed pull request #5: Fix typo in InstallMojo.java
khmarbaise closed pull request #5: Fix typo in InstallMojo.java URL: https://github.com/apache/maven-install-plugin/pull/5 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Comment Edited] (MSHARED-167) dependency:tree omits batik-js
[
https://issues.apache.org/jira/browse/MSHARED-167?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16953780#comment-16953780
]
Olof Larsson edited comment on MSHARED-167 at 10/18/19 3:52 PM:
I just added this related ticket with a completion bounty:
https://issues.apache.org/jira/browse/MDEP-662
was (Author: olof larsson):
I just added this related ticket with a completion bounty:
https://issues.apache.org/jira/browse/MNG-6786
> dependency:tree omits batik-js
> --
>
> Key: MSHARED-167
> URL: https://issues.apache.org/jira/browse/MSHARED-167
> Project: Maven Shared Components
> Issue Type: Bug
> Components: maven-dependency-tree
>Affects Versions: maven-dependency-tree-1.2
> Environment: Maven 3.0, Ubuntu, JDK 6.
>Reporter: Jesse N. Glick
>Assignee: Herve Boutemy
>Priority: Major
> Fix For: maven-dependency-tree-2.0
>
> Attachments:
> test_test-dependency-tree_jar_1.0-SNAPSHOT_101018-185145.zip
>
>
> (Not sure what the right place to file this is. {{maven-dependency-tree 1.2}}
> gives {{MNG}} as the JIRA component by inheritance.)
> {{mvn dependency:tree}} on the attached project lists {{batik-script}} by way
> of {{batik-bridge}} as expected, but then fails to show {{batik-js}} as a
> dependency of that. If you list {{batik-script}} as a direct dependency,
> {{batik-js}} is correctly shown.
> Possibly related is that Maven 2.2.1 also fails to find {{batik-js}} in
> {{MavenProject.getRuntimeArtifacts}}, so {{clean package}} fails, whereas
> this works fine under Maven 3.0. Yet just running the dependency plugin under
> M3 does not suffice to pick up this fix, wherever it was - MNG-4690?
> Although the Batik JARs are built from an odd source tree, the artifacts as
> present in the local repository look normal enough; all of the dependencies
> involved are simple compile scope without exclusions etc.
> Marking "major" since this seems to cause MNBMODULE-102 (producing build
> errors for certain projects); also I have noticed that the dependency graph
> feature in the NB IDE omits {{batik-js}}, and there may be other user-visible
> effects of this bug.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (MSHARED-339) DependencyGraphBuilder does not provide verbose tree
[ https://issues.apache.org/jira/browse/MSHARED-339?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16953779#comment-16953779 ] Olof Larsson edited comment on MSHARED-339 at 10/18/19 3:52 PM: I just added this related ticket with a completion bounty: https://issues.apache.org/jira/browse/MDEP-662 was (Author: olof larsson): I just added this related ticket with a completion bounty: https://issues.apache.org/jira/browse/MNG-6786 > DependencyGraphBuilder does not provide verbose tree > > > Key: MSHARED-339 > URL: https://issues.apache.org/jira/browse/MSHARED-339 > Project: Maven Shared Components > Issue Type: Improvement > Components: maven-dependency-tree >Affects Versions: maven-dependency-tree-2.1 >Reporter: Paul Gier >Priority: Major > > The dependency graph builder provides a dependency tree which has already > filtered out duplicate dependencies. In some cases such as testing > dependency convergence or viewing the verbose dependency tree, it's useful to > get information about the full tree including duplicates. > The dependency graph builder should provide an option for including the > unfiltered dependency tree. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [maven-install-plugin] dNhax commented on issue #5: Fix typo in InstallMojo.java
dNhax commented on issue #5: Fix typo in InstallMojo.java URL: https://github.com/apache/maven-install-plugin/pull/5#issuecomment-543806304 You're welcome, glad that I could help. :) This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [maven-install-plugin] khmarbaise commented on issue #5: Fix typo in InstallMojo.java
khmarbaise commented on issue #5: Fix typo in InstallMojo.java URL: https://github.com/apache/maven-install-plugin/pull/5#issuecomment-543804658 Good catch. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [maven-install-plugin] khmarbaise commented on issue #5: Fix typo in InstallMojo.java
khmarbaise commented on issue #5: Fix typo in InstallMojo.java URL: https://github.com/apache/maven-install-plugin/pull/5#issuecomment-543804884 I will merge that. Thanks for your contribution. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [maven-install-plugin] dNhax opened a new pull request #5: Fix typo in InstallMojo.java
dNhax opened a new pull request #5: Fix typo in InstallMojo.java URL: https://github.com/apache/maven-install-plugin/pull/5 This is an automated message from the Apache Git Service. To respond to the message, please log on to 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] [Assigned] (MNG-6765) [Regression] tycho pom-less builds fails with 3.6.2
[
https://issues.apache.org/jira/browse/MNG-6765?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte reassigned MNG-6765:
---
Assignee: Robert Scholte
> [Regression] tycho pom-less builds fails with 3.6.2
> ---
>
> Key: MNG-6765
> URL: https://issues.apache.org/jira/browse/MNG-6765
> Project: Maven
> Issue Type: Bug
>Affects Versions: 3.6.2
>Reporter: Jonathan Chen
>Assignee: Robert Scholte
>Priority: Critical
>
> Projects using tycho pom-less builds fail with maven-3.6.2.
> One such example would be using maven-3.6.2 to build Eclipse-4.13, which
> fails pretty early in the build with:
> {noformat}
> [INFO] Scanning for projects...
> [ERROR] [ERROR] Some problems were encountered while processing the POMs:
> [FATAL] Non-readable POM
> /home/jonc/work/ports/freebsd-eclipse/eclipse.platform.releng.aggregator/eclipse.pde.ui/apitools/org.eclipse.pde.api.tools.ee.cdcfoundation10/.polyglot.build.properties:
> input contained no data @
> [FATAL] Non-readable POM
> /home/jonc/work/ports/freebsd-eclipse/eclipse.platform.releng.aggregator/eclipse.pde.ui/apitools/org.eclipse.pde.api.tools.ee.cdcfoundation11/.polyglot.build.properties:
> input contained no data @
> [FATAL] Non-readable POM
> /home/jonc/work/ports/freebsd-eclipse/eclipse.platform.releng.aggregator/eclipse.pde.ui/apitools/org.eclipse.pde.api.tools.ee.feature/.polyglot.build.properties:
> input contained no data @
> [FATAL] Non-readable POM
> /home/jonc/work/ports/freebsd-eclipse/eclipse.platform.releng.aggregator/eclipse.pde.ui/apitools/org.eclipse.pde.api.tools.ee.j2se12/.polyglot.build.properties:
> input contained no data @
> [FATAL] Non-readable POM
> /home/jonc/work/ports/freebsd-eclipse/eclipse.platform.releng.aggregator/eclipse.pde.ui/apitools/org.eclipse.pde.api.tools.ee.j2se13/.polyglot.build.properties:
> input contained no data @
> [FATAL] Non-readable POM
> /home/jonc/work/ports/freebsd-eclipse/eclipse.platform.releng.aggregator/eclipse.pde.ui/apitools/org.eclipse.pde.api.tools.ee.j2se14/.polyglot.build.properties:
> input contained no data @
> [FATAL] Non-readable POM
> /home/jonc/work/ports/freebsd-eclipse/eclipse.platform.releng.aggregator/eclipse.pde.ui/apitools/org.eclipse.pde.api.tools.ee.j2se15/.polyglot.build.properties:
> input contained no data @
> [FATAL] Non-readable POM
> /home/jonc/work/ports/freebsd-eclipse/eclipse.platform.releng.aggregator/eclipse.pde.ui/apitools/org.eclipse.pde.api.tools.ee.javase16/.polyglot.build.properties:
> input contained no data @
> [FATAL] Non-readable POM
> /home/jonc/work/ports/freebsd-eclipse/eclipse.platform.releng.aggregator/eclipse.pde.ui/apitools/org.eclipse.pde.api.tools.ee.javase17/.polyglot.build.properties:
> input contained no data @
> ...
> {noformat}
> These errors do not arise with maven-3.6.0 or maven-3.6.1
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [maven-surefire] Tibor17 commented on issue #245: Surefire-1584: Add option to rerun failing tests for JUnit5
Tibor17 commented on issue #245: Surefire-1584: Add option to rerun failing tests for JUnit5 URL: https://github.com/apache/maven-surefire/pull/245#issuecomment-543774689 > > > > @quiram > > An exception or assertion failure does not crash the code in Surefire and JUnit. These exceptions are properly handled by the JUnit. > > Sorry, did you mean exception or extension? I was talking about JUnit Jupiter Extensions, not exceptions. I thought maybe the extension interacts with the test lifecycle in a way that clashes with surefire. However, it seems you have found the likely root cause, so I guess the extension is not a problem. I understood `exception`, sorry. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [maven-surefire] quiram edited a comment on issue #245: Surefire-1584: Add option to rerun failing tests for JUnit5
quiram edited a comment on issue #245: Surefire-1584: Add option to rerun failing tests for JUnit5 URL: https://github.com/apache/maven-surefire/pull/245#issuecomment-543758352 > @quiram > An exception or assertion failure does not crash the code in Surefire and JUnit. These exceptions are properly handled by the JUnit. @Tibor17 Sorry, did you mean exception or extension? I was talking about JUnit Jupiter Extensions, not exceptions. I thought maybe the extension interacts with the test lifecycle in a way that clashes with surefire. However, it seems you have found the likely root cause, so I guess the extension is not a problem. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [maven-surefire] quiram commented on issue #245: Surefire-1584: Add option to rerun failing tests for JUnit5
quiram commented on issue #245: Surefire-1584: Add option to rerun failing tests for JUnit5 URL: https://github.com/apache/maven-surefire/pull/245#issuecomment-543758352 > @quiram > An exception or assertion failure does not crash the code in Surefire and JUnit. These exceptions are properly handled by the JUnit. Sorry, did you mean exception or extension? I was talking about JUnit Jupiter Extensions, not exceptions. I thought maybe the extension interacts with the test lifecycle in a way that clashes with surefire. However, it seems you have found the likely root cause, so I guess the extension is not a problem. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [maven-surefire] Tibor17 commented on issue #245: Surefire-1584: Add option to rerun failing tests for JUnit5
Tibor17 commented on issue #245: Surefire-1584: Add option to rerun failing tests for JUnit5 URL: https://github.com/apache/maven-surefire/pull/245#issuecomment-543745287 @quiram I will wait for @Col-E because i have investigated an issue in the code, see https://github.com/apache/maven-surefire/pull/245#issuecomment-543712421. After @Col-E would confirm the bug, we would fix it and prove it with a test from @quiram . Then we would be able to cute a new release version. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [maven-surefire] Tibor17 commented on issue #245: Surefire-1584: Add option to rerun failing tests for JUnit5
Tibor17 commented on issue #245: Surefire-1584: Add option to rerun failing tests for JUnit5 URL: https://github.com/apache/maven-surefire/pull/245#issuecomment-543742706 @quiram An exception or assertion failure does not crash the code in Surefire and JUnit. These exceptions are properly handled by the JUnit. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [maven-surefire] quiram commented on issue #245: Surefire-1584: Add option to rerun failing tests for JUnit5
quiram commented on issue #245: Surefire-1584: Add option to rerun failing tests for JUnit5 URL: https://github.com/apache/maven-surefire/pull/245#issuecomment-543741432 One thing I can tell, in case it helps, is that the tests where I have witnessed this are Spring Boot tests that use the `SpringExtension`, maybe that's somehow causing some interaction? This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [maven-surefire] quiram commented on issue #245: Surefire-1584: Add option to rerun failing tests for JUnit5
quiram commented on issue #245: Surefire-1584: Add option to rerun failing tests for JUnit5 URL: https://github.com/apache/maven-surefire/pull/245#issuecomment-543727605 Hi @Col-E, I'm trying to create a repository with a sample project that demonstrates this but I haven't been able to do it yet. The feature does work correctly on a simple setting, so maybe something about the complexity on my project is triggering the failure. I'll try a few things to see if I can spot the error. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Commented] (SUREFIRE-1584) Rerun Failing Tests with JUnit 5
[ https://issues.apache.org/jira/browse/SUREFIRE-1584?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16954569#comment-16954569 ] Abraham commented on SUREFIRE-1584: --- Thanks [~tibordigana], I'll continue the conversation on GitHub. > Rerun Failing Tests with JUnit 5 > > > Key: SUREFIRE-1584 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1584 > Project: Maven Surefire > Issue Type: New Feature > Components: JUnit 5.x support, Maven Surefire Report Plugin >Affects Versions: 2.22.0 >Reporter: Tic Tac >Assignee: Tibor Digana >Priority: Major > Labels: junit5 > Fix For: 3.0.0-M4 > > Attachments: FlakyReruns.png > > > The very useful feature for integration tests ¨[Rerun Failing > Tests|https://maven.apache.org/surefire/maven-surefire-plugin/examples/rerun-failing-tests.html]¨ > is currently only supported for the very outdated JUnit 4. > The documentation says: ¨This feature is supported only for JUnit 4.x.¨ > Can you please support this feature for JUnit 5.3 or later? -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [maven-surefire] Tibor17 edited a comment on issue #245: Surefire-1584: Add option to rerun failing tests for JUnit5
Tibor17 edited a comment on issue #245: Surefire-1584: Add option to rerun failing tests for JUnit5 URL: https://github.com/apache/maven-surefire/pull/245#issuecomment-543712421 @Col-E I think I understand the problem. We consider the `adapter` been `stateless` in every loop. In reality we modify the collection of failures from the first set of failure and the adapter is `stateful`. https://github.com/apache/maven-surefire/pull/245/commits/fe17751602f597d7b694ec8a65fc389aee0bac25#diff-b3a2904e92be87f11f2622fbfd122e31R152 So my proposal is to grap the collection of failures and make a copy, and then iterate over the elements. I hope I got it right. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [maven-surefire] Tibor17 commented on issue #245: Surefire-1584: Add option to rerun failing tests for JUnit5
Tibor17 commented on issue #245: Surefire-1584: Add option to rerun failing tests for JUnit5 URL: https://github.com/apache/maven-surefire/pull/245#issuecomment-543712421 @Col-E I think I nderstand the problem. We consider the `adapter` been `stateless` in every loop. In reality we modify the collection of failures from the first set of failure and the adapter is `stateful`. https://github.com/apache/maven-surefire/pull/245/commits/fe17751602f597d7b694ec8a65fc389aee0bac25#diff-b3a2904e92be87f11f2622fbfd122e31R152 So my proposal is to grap the collection of failures and make a copy, and then iterate over the elements. I hope I got it right. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [maven-surefire] Tibor17 commented on issue #245: Surefire-1584: Add option to rerun failing tests for JUnit5
Tibor17 commented on issue #245: Surefire-1584: Add option to rerun failing tests for JUnit5 URL: https://github.com/apache/maven-surefire/pull/245#issuecomment-543702810 Hi @Col-E Matt, How are you. We have some issue with our feature. Can you pls talk with one of our user, for more information see his comment https://issues.apache.org/jira/browse/SUREFIRE-1584?focusedCommentId=16954490&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16954490 Perhaps you already know what's going on. Thx This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Commented] (SUREFIRE-1584) Rerun Failing Tests with JUnit 5
[ https://issues.apache.org/jira/browse/SUREFIRE-1584?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16954530#comment-16954530 ] Tibor Digana commented on SUREFIRE-1584: [~quiram] thf for testing this feature. Pls talk with the developer of this feature https://github.com/apache/maven-surefire/pull/245 I saw the unit tests but i did not see this error there. It would be very handy for the developer to prepare a trivial project to reproduce this error. > Rerun Failing Tests with JUnit 5 > > > Key: SUREFIRE-1584 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1584 > Project: Maven Surefire > Issue Type: New Feature > Components: JUnit 5.x support, Maven Surefire Report Plugin >Affects Versions: 2.22.0 >Reporter: Tic Tac >Assignee: Tibor Digana >Priority: Major > Labels: junit5 > Fix For: 3.0.0-M4 > > Attachments: FlakyReruns.png > > > The very useful feature for integration tests ¨[Rerun Failing > Tests|https://maven.apache.org/surefire/maven-surefire-plugin/examples/rerun-failing-tests.html]¨ > is currently only supported for the very outdated JUnit 4. > The documentation says: ¨This feature is supported only for JUnit 4.x.¨ > Can you please support this feature for JUnit 5.3 or later? -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [maven-javadoc-plugin] schelldorfer commented on issue #32: [MJAVADOC-625] Support for multiple stylesheets
schelldorfer commented on issue #32: [MJAVADOC-625] Support for multiple stylesheets URL: https://github.com/apache/maven-javadoc-plugin/pull/32#issuecomment-543676082 When using "stylesheet" / "stylesheetfile", this overwrites the default javadoc stylesheet. There is no possibility with the current Maven Javadoc plugin to keep the default javadoc stylesheet and have an additional custom stylesheet. With this PR, this is possible (keep the default javadoc stylesheet and provide an additional custom stylesheet). This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Comment Edited] (SUREFIRE-1584) Rerun Failing Tests with JUnit 5
[ https://issues.apache.org/jira/browse/SUREFIRE-1584?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16954490#comment-16954490 ] Abraham edited comment on SUREFIRE-1584 at 10/18/19 10:40 AM: -- Hi [~tibordigana]. I seem to be experiencing an issue with this: when several tests within the same file fail, it seems the plugin retries only the first one, the others are simply tagged as failures. Is this something you can reproduce? Would you like me to create a new ticket for this? Thanks _Edit:_ This is happening at least with failsafe, I haven't tried with surefire. was (Author: quiram): Hi [~tibordigana]. I seem to be experiencing an issue with this: when several tests within the same file fail, it seems the plugin retries only the first one, the others are simply tagged as failures. Is this something you can reproduce? Would you like me to create a new ticket for this? Thanks > Rerun Failing Tests with JUnit 5 > > > Key: SUREFIRE-1584 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1584 > Project: Maven Surefire > Issue Type: New Feature > Components: JUnit 5.x support, Maven Surefire Report Plugin >Affects Versions: 2.22.0 >Reporter: Tic Tac >Assignee: Tibor Digana >Priority: Major > Labels: junit5 > Fix For: 3.0.0-M4 > > Attachments: FlakyReruns.png > > > The very useful feature for integration tests ¨[Rerun Failing > Tests|https://maven.apache.org/surefire/maven-surefire-plugin/examples/rerun-failing-tests.html]¨ > is currently only supported for the very outdated JUnit 4. > The documentation says: ¨This feature is supported only for JUnit 4.x.¨ > Can you please support this feature for JUnit 5.3 or later? -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (SUREFIRE-1584) Rerun Failing Tests with JUnit 5
[ https://issues.apache.org/jira/browse/SUREFIRE-1584?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16954490#comment-16954490 ] Abraham commented on SUREFIRE-1584: --- Hi [~tibordigana]. I seem to be experiencing an issue with this: when several tests within the same file fail, it seems the plugin retries only the first one, the others are simply tagged as failures. Is this something you can reproduce? Would you like me to create a new ticket for this? Thanks > Rerun Failing Tests with JUnit 5 > > > Key: SUREFIRE-1584 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1584 > Project: Maven Surefire > Issue Type: New Feature > Components: JUnit 5.x support, Maven Surefire Report Plugin >Affects Versions: 2.22.0 >Reporter: Tic Tac >Assignee: Tibor Digana >Priority: Major > Labels: junit5 > Fix For: 3.0.0-M4 > > Attachments: FlakyReruns.png > > > The very useful feature for integration tests ¨[Rerun Failing > Tests|https://maven.apache.org/surefire/maven-surefire-plugin/examples/rerun-failing-tests.html]¨ > is currently only supported for the very outdated JUnit 4. > The documentation says: ¨This feature is supported only for JUnit 4.x.¨ > Can you please support this feature for JUnit 5.3 or later? -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [maven-javadoc-plugin] michael-o commented on issue #32: [MJAVADOC-625] Support for multiple stylesheets
michael-o commented on issue #32: [MJAVADOC-625] Support for multiple stylesheets URL: https://github.com/apache/maven-javadoc-plugin/pull/32#issuecomment-543581574 You won't lose the default one. The JIRA issue says that this adds additional ones to the main stylesheet. Did I misread the JIRA issue? This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [maven-javadoc-plugin] schelldorfer commented on issue #32: [MJAVADOC-625] Support for multiple stylesheets
schelldorfer commented on issue #32: [MJAVADOC-625] Support for multiple stylesheets URL: https://github.com/apache/maven-javadoc-plugin/pull/32#issuecomment-543574817 The main idea of this PR is to have an additional stylesheet without loosing the default stylesheet. This is an automated message from the Apache Git Service. To respond to the message, please log on to 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
