[jira] [Created] (MSHARED-873) make build Reproducible
Herve Boutemy created MSHARED-873: - Summary: make build Reproducible Key: MSHARED-873 URL: https://issues.apache.org/jira/browse/MSHARED-873 Project: Maven Shared Components Issue Type: Improvement Components: maven-archiver Affects Versions: maven-archiver-3.5.0 Reporter: Herve Boutemy Assignee: Herve Boutemy Fix For: maven-archiver -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (SUREFIRE-1768) Main classes not included in classpath when using Java Modules
[
https://issues.apache.org/jira/browse/SUREFIRE-1768?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1707#comment-1707
]
Tibor Digana commented on SUREFIRE-1768:
[~rolaca11]
As [~rfscholte] said he will put this issue on the mailing list. Please
*subscribe *to the [mailing list|https://maven.apache.org/mailing-lists.html]
and find the discussion there.
This is the open mailing list for developers and users:
https://lists.apache.org/list.html?d...@maven.apache.org
https://lists.apache.org/list.html?us...@maven.apache.org
> Main classes not included in classpath when using Java Modules
> --
>
> Key: SUREFIRE-1768
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1768
> Project: Maven Surefire
> Issue Type: Bug
> Components: classloading
>Affects Versions: 3.0.0-M4
> Environment: Windows 10, JDK 11
>Reporter: László Stahorszki
>Priority: Major
>
> According to the
> [documentation|http://maven.apache.org/surefire/maven-surefire-plugin/examples/configuring-classpath.html],
> the `classes` directory should be put on the classpath by default.
> In this case, given that I have a `demo` package in both my main sources and
> my test source, the enumeration
> `classLoader.getResources({color:#6a8759}"demo"{color})` should have 2 URLs
> in it. One for the package in the test sources and one for the main sources.
> When using the Java Module System, this is not the case. Instead, I get two
> URLs, both for the test sources. This error does not occur when not using the
> module system.
> I created a repository, which can reproduce this error. It can be found
> [here|https://github.com/rolaca11/test-classpath-demo]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (SUREFIRE-1768) Main classes not included in classpath when using Java Modules
[
https://issues.apache.org/jira/browse/SUREFIRE-1768?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1707#comment-1707
]
Tibor Digana edited comment on SUREFIRE-1768 at 4/3/20, 9:48 AM:
-
[~rolaca11]
As [~rfscholte] said he will put this issue on the mailing list. Please
*subscribe* to the [mailing list|https://maven.apache.org/mailing-lists.html]
and find the discussion there.
This is the open mailing list for developers and users:
https://lists.apache.org/list.html?d...@maven.apache.org
https://lists.apache.org/list.html?us...@maven.apache.org
was (Author: tibor17):
[~rolaca11]
As [~rfscholte] said he will put this issue on the mailing list. Please
*subscribe *to the [mailing list|https://maven.apache.org/mailing-lists.html]
and find the discussion there.
This is the open mailing list for developers and users:
https://lists.apache.org/list.html?d...@maven.apache.org
https://lists.apache.org/list.html?us...@maven.apache.org
> Main classes not included in classpath when using Java Modules
> --
>
> Key: SUREFIRE-1768
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1768
> Project: Maven Surefire
> Issue Type: Bug
> Components: classloading
>Affects Versions: 3.0.0-M4
> Environment: Windows 10, JDK 11
>Reporter: László Stahorszki
>Priority: Major
>
> According to the
> [documentation|http://maven.apache.org/surefire/maven-surefire-plugin/examples/configuring-classpath.html],
> the `classes` directory should be put on the classpath by default.
> In this case, given that I have a `demo` package in both my main sources and
> my test source, the enumeration
> `classLoader.getResources({color:#6a8759}"demo"{color})` should have 2 URLs
> in it. One for the package in the test sources and one for the main sources.
> When using the Java Module System, this is not the case. Instead, I get two
> URLs, both for the test sources. This error does not occur when not using the
> module system.
> I created a repository, which can reproduce this error. It can be found
> [here|https://github.com/rolaca11/test-classpath-demo]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (SUREFIRE-1768) Main classes not included in classpath when using Java Modules
[
https://issues.apache.org/jira/browse/SUREFIRE-1768?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte closed SUREFIRE-1768.
Assignee: Robert Scholte
Resolution: Not A Problem
This works as designed: the patch acts as an override.
Simone Bordet gave me the following codesnippet of
{{ModulePatcher.PatchedModuleReader.find(String name)}}:
{code:java}
Resource r = findResourceInPatch(name);
if (r != null) {
URI uri = URI.create(r.getURL().toString());
return Optional.of(uri);
} else {
return delegate().find(name);
}
{code}
Alan Bateman gave another piece of code that gives the list of resources in the
module so you can see the effect of the patching:
{code:java}
String name = this.getClass().getModule().getName();
ModuleLayer.boot()
.configuration()
.findModule(name)
.orElseThrow()
.reference()
.open()
.list()
.forEach(System.out::println)
{code}
> Main classes not included in classpath when using Java Modules
> --
>
> Key: SUREFIRE-1768
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1768
> Project: Maven Surefire
> Issue Type: Bug
> Components: classloading
>Affects Versions: 3.0.0-M4
> Environment: Windows 10, JDK 11
>Reporter: László Stahorszki
>Assignee: Robert Scholte
>Priority: Major
>
> According to the
> [documentation|http://maven.apache.org/surefire/maven-surefire-plugin/examples/configuring-classpath.html],
> the `classes` directory should be put on the classpath by default.
> In this case, given that I have a `demo` package in both my main sources and
> my test source, the enumeration
> `classLoader.getResources({color:#6a8759}"demo"{color})` should have 2 URLs
> in it. One for the package in the test sources and one for the main sources.
> When using the Java Module System, this is not the case. Instead, I get two
> URLs, both for the test sources. This error does not occur when not using the
> module system.
> I created a repository, which can reproduce this error. It can be found
> [here|https://github.com/rolaca11/test-classpath-demo]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [maven-surefire] Tibor17 commented on issue #274: SUREFIRE-1628 fix compatibility with maven 3.0.5
Tibor17 commented on issue #274: SUREFIRE-1628 fix compatibility with maven 3.0.5 URL: https://github.com/apache/maven-surefire/pull/274#issuecomment-608369136 @eolivelli Robert mentioned this option of instantiating this `LocationManager` instead of injecting it. If Robert guarantees that future versions wouldn't use injections in the class `LocationManager` then we are on the safe side. 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-1768) Main classes not included in classpath when using Java Modules
[
https://issues.apache.org/jira/browse/SUREFIRE-1768?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17074422#comment-17074422
]
Robert Scholte commented on SUREFIRE-1768:
--
This is new and unexpected to me. I'll put it on the mailinglist first to see
if we might have misunderstood a detail. If not, I can register an issue for it.
btw. I noticed a very small difference between the 2 URLs: one ends with a /
> Main classes not included in classpath when using Java Modules
> --
>
> Key: SUREFIRE-1768
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1768
> Project: Maven Surefire
> Issue Type: Bug
> Components: classloading
>Affects Versions: 3.0.0-M4
> Environment: Windows 10, JDK 11
>Reporter: László Stahorszki
>Priority: Major
>
> According to the
> [documentation|http://maven.apache.org/surefire/maven-surefire-plugin/examples/configuring-classpath.html],
> the `classes` directory should be put on the classpath by default.
> In this case, given that I have a `demo` package in both my main sources and
> my test source, the enumeration
> `classLoader.getResources({color:#6a8759}"demo"{color})` should have 2 URLs
> in it. One for the package in the test sources and one for the main sources.
> When using the Java Module System, this is not the case. Instead, I get two
> URLs, both for the test sources. This error does not occur when not using the
> module system.
> I created a repository, which can reproduce this error. It can be found
> [here|https://github.com/rolaca11/test-classpath-demo]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-6875) mvn test keeps failing after changes removed
[
https://issues.apache.org/jira/browse/MNG-6875?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17074625#comment-17074625
]
Joseph Walton commented on MNG-6875:
The reported error is from [https://github.com/revelc/formatter-maven-plugin].
It [uses a
cache|https://github.com/revelc/formatter-maven-plugin/blob/c24af2ed4ce71367fce92d2938cbf56ded1e9fe1/src/main/java/net/revelc/code/formatter/FormatterMojo.java#L82]
stored in the filesystem; it may be worth reporting a bug against that mojo.
> mvn test keeps failing after changes removed
>
>
> Key: MNG-6875
> URL: https://issues.apache.org/jira/browse/MNG-6875
> Project: Maven
> Issue Type: Bug
>Reporter: Grigoriy Mikhalkin
>Priority: Major
>
> Maven version: 3.6.0
> Problem:
> After i created new branch and did few changes to code, i ran `mvn test` and
> got formatting error:
>
> {code:java}
> somefile has not been previously formatted. Please format file and commit
> before running validation!{code}
>
>
> I stashed changes, so `git status` didn't displayed any changes between
> master and branch, and ran `mvn test` again - still got same error.
>
> Then i switched to master and ran `mvn test` - no errors. Switched to new
> branch again - still having errors. Just in case, i tried to close my IDE and
> log out/in - nothing helps.
>
> From what i understand, even if there some changes in files, that git is not
> tracking, `mvn test` should return identical results in both cases(as code in
> master and branch are same). But in reality it's not the case. Probably,
> maven stores some metadata about git branches, that can cause such behavior?
>
> Btw, not sure if this is really problem with maven. Maybe someone can point
> to right places to look at.
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (MNG-6613) Mirror matching ignores closest/nearest definition
[
https://issues.apache.org/jira/browse/MNG-6613?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov reassigned MNG-6613:
---
Assignee: Michael Osipov
> Mirror matching ignores closest/nearest definition
> --
>
> Key: MNG-6613
> URL: https://issues.apache.org/jira/browse/MNG-6613
> Project: Maven
> Issue Type: Bug
> Components: Artifacts and Repositories
>Affects Versions: 3.5.4, 3.6.1
> Environment: Java 8u202, Java11u2
>Reporter: Michael Osipov
>Assignee: Michael Osipov
>Priority: Critical
> Attachments: log.txt
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Ran our IT suite in a locked down environment at work, w/o direct internet
> access. IT {{mng3461MirrorMatching(itNonGreedyWildcard)}} blocks forever
> because the mirror exclude does not work: {{*,!maven-core-it}}.
> It still tries to download via mirror instead of ignoring it. See attached
> log file. Even switching {{!maven-core-it,*}} makes no difference.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (MNG-5818) Disallow plugins from programmatically adding dependencies to projects
[ https://issues.apache.org/jira/browse/MNG-5818?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17000261#comment-17000261 ] Elliotte Rusty Harold edited comment on MNG-5818 at 4/3/20, 2:54 PM: - This looks done? was (Author: elharo): This loos done? > Disallow plugins from programmatically adding dependencies to projects > -- > > Key: MNG-5818 > URL: https://issues.apache.org/jira/browse/MNG-5818 > Project: Maven > Issue Type: Task >Reporter: Jason van Zyl >Priority: Major > > MavenProject.setDependencyArtifacts(deps) is publicly available to plugins > that can alter the classpath non-declaratively. For compatibility reasons in > MNG-4363 we restored this capability for the cobertura-maven-plugin but it > needs to be removed. It causes some nasty logic in the core, but it being > non-delclarative and magical is the real problem. > We need to deprecate MavenProject.setDependencyArtifacts(deps), and replace > the logic for constructing the artifacts in a better. Preferably passing in > the artifacts in the constructor of MavenProject. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-5818) Disallow plugins from programmatically adding dependencies to projects
[
https://issues.apache.org/jira/browse/MNG-5818?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17074618#comment-17074618
]
Joseph Walton commented on MNG-5818:
The {{@Deprecated}} annotation is added but (e.g.) {{cobertura-maven-plugin}}
2.7, [still calls
{{setDependencyArtifacts}}|https://github.com/mojohaus/cobertura-maven-plugin/blob/4dbda2c19ebad2c5fe7610421254f86faf9642a6/src/main/java/org/codehaus/mojo/cobertura/CoberturaInstrumentMojo.java#L247]:
{code:java}
Set set = new LinkedHashSet(
this.getProject().getDependencyArtifacts() );
set.add( coberturaArtifact );
this.getProject().setDependencyArtifacts( set );
{code}
The comment for
[4567c83|https://github.com/apache/maven/commit/4567c8319e95d58e258e9a8c2067ed9bbe01b58e]
says:
{quote}I'm going to try and create a call-graph for all of Maven Central with my
first test to see if I can accurately detect all usages of
MavenProject.setDependencyArtifacts
of artifact in Maven Central.
{quote}
Either that needs to happen, or this method could be deleted first and mojos
can be fixed when breakage is noticed.
> Disallow plugins from programmatically adding dependencies to projects
> --
>
> Key: MNG-5818
> URL: https://issues.apache.org/jira/browse/MNG-5818
> Project: Maven
> Issue Type: Task
>Reporter: Jason van Zyl
>Priority: Major
>
> MavenProject.setDependencyArtifacts(deps) is publicly available to plugins
> that can alter the classpath non-declaratively. For compatibility reasons in
> MNG-4363 we restored this capability for the cobertura-maven-plugin but it
> needs to be removed. It causes some nasty logic in the core, but it being
> non-delclarative and magical is the real problem.
> We need to deprecate MavenProject.setDependencyArtifacts(deps), and replace
> the logic for constructing the artifacts in a better. Preferably passing in
> the artifacts in the constructor of MavenProject.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-6873) Inconsistent library versions notice.
[
https://issues.apache.org/jira/browse/MNG-6873?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17074627#comment-17074627
]
Joseph Walton commented on MNG-6873:
In general, this is a good problem to fix, but this looks like it could be a
false positive.
For JUnit, this report is comparing the version used in different tests;
everything reported is in {{src/test/resources}}. I don't see any reason for
those versions to align, and I'm assuming that in some cases they're
intentionally divergent as part of the test.
> Inconsistent library versions notice.
> -
>
> Key: MNG-6873
> URL: https://issues.apache.org/jira/browse/MNG-6873
> Project: Maven
> Issue Type: Improvement
>Reporter: Kaifeng Huang
>Priority: Major
> Attachments: apache maven.pdf
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
>
> Hi. I have implemented a tool to detect library version inconsistencies. Your
> project have 1 inconsistent library and 12 false consistent libraries.
>
> Take junit:junit for example, this library is declared as version 3.8.1 in
> maven-core/src/test/resources-project-builder/dependency-inheritance, 4.4 in
> maven-core/src/test/resources-project-builder/dependency-inheritance/sub and
> etc... Such version inconsistencies may cause unnecessary maintenance effort
> in the long run. For example, if two modules become inter-dependent, library
> version conflict may happen. It has already become a common issue and hinders
> development progress. Thus a version harmonization is necessary.
>
> Provided we applied a version harmonization, I calculated the cost it may
> have to harmonize to all upper versions including an up-to-date one. The cost
> refers to POM config changes and API invocation changes. Take junit:junit for
> example, if we harmonize all the library versions into 4.4. The concern is,
> how much should the project code adapt to the newer library version. We list
> an effort table to quantify the harmonization cost.
>
> The effort table shows the overall harmonization cost on APIs. It seems your
> project have no API invokes on this library, which could be safely upgrade to
> 4.4
> ||Index||Module||NA(NAC)||NDA(NDAC)||NMA(NMAC)||
> |1|maven-core/src/test/resources-project-builder/dependency-inheritance|0(0)|0(0)|0(0)|
> |2|maven-core/src/test/resources-project-builder/dependency-inheritance/sub|0(0)|0(0)|0(0)|
>
> Also we provided another table to show the potential files that may be
> affected due to library API change, which could help to spot the concerned
> API usage and rerun the test cases.
> As for false consistency, take junit junit jar for example. The library is
> declared in version 4.13 in all modules. However they are declared
> differently. As components are developed in parallel, if one single library
> version is updated, which could become inconsistent as mentioned above, may
> cause above-mentioned inconsistency issues
> If you are interested, you can have a more complete and detailed report in
> the attached PDF file.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-6613) Mirror matching ignores closest/nearest definition
[
https://issues.apache.org/jira/browse/MNG-6613?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17074601#comment-17074601
]
Joseph Walton commented on MNG-6613:
This looks like it could be a bug with the test, rather than Maven itself. The
existing {{DefaultMirrorSelectorTest}} covers (almost) that case, and passes.
That integration test runs with a user {{settings.xml}} that includes:
{code:java}
maven-core-it
...
...
central
http://maven.apache.org/null
...
*,!maven-core-it
{code}
So that mirror shouldn't be used as a mirror of {{maven-core-its}}. However,
the test also includes {{--global-settings}} that include:
{code:java}
central
Apache Maven Integration Testing Repository
file:target/null
...
{code}
That means that there are two repositories ({{central}} and
{{maven-core-its}}), and the that mirror *also* with an id of {{central}} is
used as a mirror of the {{central}} repository.
As a possible fix, also exclude {{central}} in {{}}:
{code:java}
diff --git
a/core-it-suite/src/test/resources/mng-3461/test-3/settings-template.xml
b/core-it-suite/src/test/resources/mng-3461/test-3/settings-template.xml
index da05129f..346f9fc1 100644
--- a/core-it-suite/src/test/resources/mng-3461/test-3/settings-template.xml
+++ b/core-it-suite/src/test/resources/mng-3461/test-3/settings-template.xml
@@ -49,7 +49,7 @@ under the License.
The explicit mismatch with maven-core-it should be dominant over the
wildcard, even if the wildcard
is given first.
-->
- *,!maven-core-it
+ *,!maven-core-it,!central
{code}
I believe that leaves it as a valid test.
As an aside, anyone who has run this test with Internet access will have made
repeated requests over a non-secure connection for:
{code:java}
http://maven.apache.org/null/org/apache/maven/its/mng3461/a/0.1/a-0.1.pom{code}
It would be nice to confirm that these logs aren't retained.
> Mirror matching ignores closest/nearest definition
> --
>
> Key: MNG-6613
> URL: https://issues.apache.org/jira/browse/MNG-6613
> Project: Maven
> Issue Type: Bug
> Components: Artifacts and Repositories
>Affects Versions: 3.5.4, 3.6.1
> Environment: Java 8u202, Java11u2
>Reporter: Michael Osipov
>Priority: Critical
> Attachments: log.txt
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Ran our IT suite in a locked down environment at work, w/o direct internet
> access. IT {{mng3461MirrorMatching(itNonGreedyWildcard)}} blocks forever
> because the mirror exclude does not work: {{*,!maven-core-it}}.
> It still tries to download via mirror instead of ignoring it. See attached
> log file. Even switching {{!maven-core-it,*}} makes no difference.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-6613) Mirror matching ignores closest/nearest definition
[
https://issues.apache.org/jira/browse/MNG-6613?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17074668#comment-17074668
]
Michael Osipov commented on MNG-6613:
-
Thinking more about this, should there be a circuit breaker? You cannot
(should) not have a mirror of a mirror? Does this make sense at all? Is a
mirror considered as a repo too?
> Mirror matching ignores closest/nearest definition
> --
>
> Key: MNG-6613
> URL: https://issues.apache.org/jira/browse/MNG-6613
> Project: Maven
> Issue Type: Bug
> Components: Artifacts and Repositories
>Affects Versions: 3.5.4, 3.6.1
> Environment: Java 8u202, Java11u2
>Reporter: Michael Osipov
>Assignee: Michael Osipov
>Priority: Critical
> Attachments: log.txt
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Ran our IT suite in a locked down environment at work, w/o direct internet
> access. IT {{mng3461MirrorMatching(itNonGreedyWildcard)}} blocks forever
> because the mirror exclude does not work: {{*,!maven-core-it}}.
> It still tries to download via mirror instead of ignoring it. See attached
> log file. Even switching {{!maven-core-it,*}} makes no difference.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-6858) Need a way to skip empty-string arguments
[
https://issues.apache.org/jira/browse/MNG-6858?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17074632#comment-17074632
]
Joseph Walton commented on MNG-6858:
If you know that have a Bash script, you can use the technique in [this Unix
Stack Exchange answer|https://unix.stackexchange.com/a/446848]. To paraphrase:
{code:java}
params=()
if [ "${ANDROID}" = "true" ]; then
params+=(-Pandroid)
fi
...
mvn "${params[@]}" ...
{code}
This could be less surprising than Maven silently ignore empty strings (always?
Only when they'd otherwise be goals?).
> Need a way to skip empty-string arguments
> -
>
> Key: MNG-6858
> URL: https://issues.apache.org/jira/browse/MNG-6858
> Project: Maven
> Issue Type: Improvement
> Components: Command Line
>Affects Versions: 3.6.1
> Environment: Ubuntu 19.10
>Reporter: Chris Hennick
>Priority: Major
>
> I have a bash script that sets a sometimes-empty variable as follows:
>
> {code:java}
> if [ "${ANDROID}" = "true" ]; then
> MAYBE_ANDROID_FLAG=-Pandroid
> else
> MAYBE_ANDROID_FLAG=
> fi{code}
>
> It's used like so:
>
> {code:java}
> mvn ${MAYBE_ANDROID_FLAG} clean compile jacoco:instrument
> jacoco:prepare-agent test jacoco:restore-instrumented-classes jacoco:report
> -e -B}}{code}
>
> Shell-scripting best practices dictate that ${MAYBE_ANDROID_FLAG} above
> should be in double quotes, but when I do that, I get 'Unknown lifecycle
> phase ""'. For it to be possible to follow best practices, then, we need a
> way to make Maven skip over command-line arguments that are empty strings.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-5818) Disallow plugins from programmatically adding dependencies to projects
[ https://issues.apache.org/jira/browse/MNG-5818?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17074636#comment-17074636 ] Elliotte Rusty Harold commented on MNG-5818: Why don't we try revising the maven-cobertura-plugin to not call this method. That should give us a good idea of what we need to add to replace it. Simply marking this deprecated without a safe replacement in place probably won't nudge clients off this API. > Disallow plugins from programmatically adding dependencies to projects > -- > > Key: MNG-5818 > URL: https://issues.apache.org/jira/browse/MNG-5818 > Project: Maven > Issue Type: Task >Reporter: Jason van Zyl >Priority: Major > > MavenProject.setDependencyArtifacts(deps) is publicly available to plugins > that can alter the classpath non-declaratively. For compatibility reasons in > MNG-4363 we restored this capability for the cobertura-maven-plugin but it > needs to be removed. It causes some nasty logic in the core, but it being > non-delclarative and magical is the real problem. > We need to deprecate MavenProject.setDependencyArtifacts(deps), and replace > the logic for constructing the artifacts in a better. Preferably passing in > the artifacts in the constructor of MavenProject. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [maven-dependency-plugin] elharo merged pull request #44: [MDEP-676] fix test
elharo merged pull request #44: [MDEP-676] fix test URL: https://github.com/apache/maven-dependency-plugin/pull/44 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-integration-testing] josephw opened a new pull request #57: [MNG-6613] Avoid a connection to apache.org when this test runs.
josephw opened a new pull request #57: [MNG-6613] Avoid a connection to apache.org when this test runs. URL: https://github.com/apache/maven-integration-testing/pull/57 This test runs with two repositories configured (maven-core-its and central). Make sure that both are excluded from this mirror's configuration, so it isn't used. As a fallback, in case it is used, at least make it a secure connection. 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] (MNG-6613) Mirror matching ignores closest/nearest definition
[
https://issues.apache.org/jira/browse/MNG-6613?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17074601#comment-17074601
]
Joseph Walton edited comment on MNG-6613 at 4/3/20, 2:01 PM:
-
This looks like it could be a bug with the test, rather than Maven itself. The
existing {{DefaultMirrorSelectorTest}} covers (almost) that case, and passes.
That integration test runs with a user {{settings.xml}} that includes:
{code:java}
maven-core-it
...
...
central
http://maven.apache.org/null
...
*,!maven-core-it
{code}
So that mirror shouldn't be used as a mirror of {{maven-core-its}}. However,
the test also includes {{--global-settings}} that include:
{code:java}
central
Apache Maven Integration Testing Repository
file:target/null
...
{code}
That means that there are two repositories ({{central}} and
{{maven-core-its}}), and the that mirror *also* with an id of {{central}} is
used as a mirror of the {{central}} repository.
As a possible fix, also exclude {{central}} in {{}}:
{code:java}
diff --git
a/core-it-suite/src/test/resources/mng-3461/test-3/settings-template.xml
b/core-it-suite/src/test/resources/mng-3461/test-3/settings-template.xml
index da05129f..346f9fc1 100644
--- a/core-it-suite/src/test/resources/mng-3461/test-3/settings-template.xml
+++ b/core-it-suite/src/test/resources/mng-3461/test-3/settings-template.xml
@@ -49,7 +49,7 @@ under the License.
The explicit mismatch with maven-core-it should be dominant over the
wildcard, even if the wildcard
is given first.
-->
- *,!maven-core-it
+ *,!maven-core-it,!central
{code}
I believe that leaves it as a valid test; [PR
opened|https://github.com/apache/maven-integration-testing/pull/57].
As an aside, anyone who has run this test with Internet access will have made
repeated requests over a non-secure connection for:
{code:java}
http://maven.apache.org/null/org/apache/maven/its/mng3461/a/0.1/a-0.1.pom{code}
It would be nice to confirm that these logs aren't retained.
was (Author: j...@kafsemo.org):
This looks like it could be a bug with the test, rather than Maven itself. The
existing {{DefaultMirrorSelectorTest}} covers (almost) that case, and passes.
That integration test runs with a user {{settings.xml}} that includes:
{code:java}
maven-core-it
...
...
central
http://maven.apache.org/null
...
*,!maven-core-it
{code}
So that mirror shouldn't be used as a mirror of {{maven-core-its}}. However,
the test also includes {{--global-settings}} that include:
{code:java}
central
Apache Maven Integration Testing Repository
file:target/null
...
{code}
That means that there are two repositories ({{central}} and
{{maven-core-its}}), and the that mirror *also* with an id of {{central}} is
used as a mirror of the {{central}} repository.
As a possible fix, also exclude {{central}} in {{}}:
{code:java}
diff --git
a/core-it-suite/src/test/resources/mng-3461/test-3/settings-template.xml
b/core-it-suite/src/test/resources/mng-3461/test-3/settings-template.xml
index da05129f..346f9fc1 100644
--- a/core-it-suite/src/test/resources/mng-3461/test-3/settings-template.xml
+++ b/core-it-suite/src/test/resources/mng-3461/test-3/settings-template.xml
@@ -49,7 +49,7 @@ under the License.
The explicit mismatch with maven-core-it should be dominant over the
wildcard, even if the wildcard
is given first.
-->
- *,!maven-core-it
+ *,!maven-core-it,!central
{code}
I believe that leaves it as a valid test.
As an aside, anyone who has run this test with Internet access will have made
repeated requests over a non-secure connection for:
{code:java}
http://maven.apache.org/null/org/apache/maven/its/mng3461/a/0.1/a-0.1.pom{code}
It would be nice to confirm that these logs aren't retained.
> Mirror matching ignores closest/nearest definition
> --
>
> Key: MNG-6613
> URL: https://issues.apache.org/jira/browse/MNG-6613
> Project: Maven
> Issue Type: Bug
> Components: Artifacts and Repositories
>Affects Versions: 3.5.4, 3.6.1
> Environment: Java 8u202, Java11u2
>Reporter: Michael Osipov
>Priority: Critical
> Attachments: log.txt
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Ran our IT suite in a locked down environment at work, w/o direct internet
> access. IT {{mng3461MirrorMatching(itNonGreedyWildcard)}} blocks forever
> because the mirror exclude does not work: {{*,!maven-core-it}}.
> It still tries to download via mirror instead of ignoring it. See attached
> log file. Even switching
[jira] [Commented] (MNG-6613) Mirror matching ignores closest/nearest definition
[
https://issues.apache.org/jira/browse/MNG-6613?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17074607#comment-17074607
]
Michael Osipov commented on MNG-6613:
-
Thanks, I will try this at work.
> Mirror matching ignores closest/nearest definition
> --
>
> Key: MNG-6613
> URL: https://issues.apache.org/jira/browse/MNG-6613
> Project: Maven
> Issue Type: Bug
> Components: Artifacts and Repositories
>Affects Versions: 3.5.4, 3.6.1
> Environment: Java 8u202, Java11u2
>Reporter: Michael Osipov
>Priority: Critical
> Attachments: log.txt
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Ran our IT suite in a locked down environment at work, w/o direct internet
> access. IT {{mng3461MirrorMatching(itNonGreedyWildcard)}} blocks forever
> because the mirror exclude does not work: {{*,!maven-core-it}}.
> It still tries to download via mirror instead of ignoring it. See attached
> log file. Even switching {{!maven-core-it,*}} makes no difference.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [maven-surefire] rfscholte commented on issue #274: SUREFIRE-1628 fix compatibility with maven 3.0.5
rfscholte commented on issue #274: SUREFIRE-1628 fix compatibility with maven 3.0.5 URL: https://github.com/apache/maven-surefire/pull/274#issuecomment-608454907 I won't guarantee anything. Having it available as a bean gives me the freedom to inject other beans. So far there hasn't been a reason to do so. I would suggest to try and get the LocationManager as bean. If it is null, create one yourself via the constructor. Once surefire requires Maven 3.1, you can drop the null-check. 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] (MNG-6613) Mirror matching ignores closest/nearest definition
[
https://issues.apache.org/jira/browse/MNG-6613?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17074668#comment-17074668
]
Michael Osipov edited comment on MNG-6613 at 4/3/20, 3:34 PM:
--
Thinking more about this, should there be a circuit breaker? You cannot
(should) not have a mirror of a mirror? Does this make sense at all? Is a
mirror considered as a repo too?
[~rfscholte], WDYT?
was (Author: michael-o):
Thinking more about this, should there be a circuit breaker? You cannot
(should) not have a mirror of a mirror? Does this make sense at all? Is a
mirror considered as a repo too?
> Mirror matching ignores closest/nearest definition
> --
>
> Key: MNG-6613
> URL: https://issues.apache.org/jira/browse/MNG-6613
> Project: Maven
> Issue Type: Bug
> Components: Artifacts and Repositories
>Affects Versions: 3.5.4, 3.6.1
> Environment: Java 8u202, Java11u2
>Reporter: Michael Osipov
>Assignee: Michael Osipov
>Priority: Critical
> Attachments: log.txt
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Ran our IT suite in a locked down environment at work, w/o direct internet
> access. IT {{mng3461MirrorMatching(itNonGreedyWildcard)}} blocks forever
> because the mirror exclude does not work: {{*,!maven-core-it}}.
> It still tries to download via mirror instead of ignoring it. See attached
> log file. Even switching {{!maven-core-it,*}} makes no difference.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-6613) Mirror matching ignores closest/nearest definition
[
https://issues.apache.org/jira/browse/MNG-6613?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17074754#comment-17074754
]
Robert Scholte commented on MNG-6613:
-
Based on https://maven.apache.org/guides/mini/guide-mirror-settings.html I'd
say a mirror can only be applied on a repository.
> Mirror matching ignores closest/nearest definition
> --
>
> Key: MNG-6613
> URL: https://issues.apache.org/jira/browse/MNG-6613
> Project: Maven
> Issue Type: Bug
> Components: Artifacts and Repositories
>Affects Versions: 3.5.4, 3.6.1
> Environment: Java 8u202, Java11u2
>Reporter: Michael Osipov
>Assignee: Michael Osipov
>Priority: Critical
> Attachments: log.txt
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Ran our IT suite in a locked down environment at work, w/o direct internet
> access. IT {{mng3461MirrorMatching(itNonGreedyWildcard)}} blocks forever
> because the mirror exclude does not work: {{*,!maven-core-it}}.
> It still tries to download via mirror instead of ignoring it. See attached
> log file. Even switching {{!maven-core-it,*}} makes no difference.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (MNG-6613) Mirror matching ignores closest/nearest definition
[
https://issues.apache.org/jira/browse/MNG-6613?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17074772#comment-17074772
]
Michael Osipov edited comment on MNG-6613 at 4/3/20, 6:11 PM:
--
I have looked into again and I still think that this is a bug in Maven. This is
what I get:
No mirror:
{noformat}
[DEBUG] Repositories (dependencies): [central (file:target/null, default,
releases), maven-core-it
(file:///D:/Entwicklung/Projekte/maven-integration-testing/core-it-suite/target/test-classes/mng-3461/test-3/repo,
default, releases)]
[DEBUG] Repositories (plugins) : [central (file:target/null, default,
releases+snapshots)]
{noformat}
With mirror, named central:
{noformat}
[DEBUG] Repositories (dependencies): [central (http://maven.apache.org/null,
default, releases), maven-core-it
(file:///D:/Entwicklung/Projekte/maven-integration-testing/core-it-suite/target/test-classes/mng-3461/test-3/repo,
default, releases)]
[DEBUG] Repositories (plugins) : [central (http://maven.apache.org/null,
default, releases+snapshots)]
{noformat}
With mirror, named centraaal:
{noformat}
[DEBUG] Using transporter WagonTransporter with priority -1.0 for
http://maven.apache.org/null
[INFO] Downloading from centraaal:
http://maven.apache.org/null/org/apache/maven/its/plugins/maven-it-plugin-dependency-resolution/2.1-SNAPSHOT/maven-metadata.xml
[DEBUG] Could not find metadata
org.apache.maven.its.plugins:maven-it-plugin-dependency-resolution:2.1-SNAPSHOT/maven-metadata.xml
in centraaal (http://maven.apache.org/null)
[DEBUG] Failure to find
org.apache.maven.its.plugins:maven-it-plugin-dependency-resolution:2.1-SNAPSHOT/maven-metadata.xml
in http://maven.apache.org/null was cached in the local repository, resolution
will not be reattempted until the update interval of centraaal has elapsed or
updates are forced
[DEBUG] Using transporter WagonTransporter with priority -1.0 for
http://maven.apache.org/null
[INFO] Downloading from centraaal:
http://maven.apache.org/null/org/apache/maven/its/plugins/maven-it-plugins/2.1-SNAPSHOT/maven-metadata.xml
[DEBUG] Could not find metadata
org.apache.maven.its.plugins:maven-it-plugins:2.1-SNAPSHOT/maven-metadata.xml
in centraaal (http://maven.apache.org/null)
[DEBUG] Using transporter WagonTransporter with priority -1.0 for
http://maven.apache.org/null
[INFO] Downloading from centraaal:
http://maven.apache.org/null/org/apache/maven/its/core-it-support/2.1-SNAPSHOT/maven-metadata.xml
[DEBUG] Could not find metadata
org.apache.maven.its:core-it-support:2.1-SNAPSHOT/maven-metadata.xml in
centraaal (http://maven.apache.org/null)
[DEBUG] Using transporter WagonTransporter with priority -1.0 for
http://maven.apache.org/null
[INFO] Downloading from centraaal:
http://maven.apache.org/null/org/apache/maven/its/core-its/2.1-SNAPSHOT/maven-metadata.xml
[DEBUG] Could not find metadata
org.apache.maven.its:core-its:2.1-SNAPSHOT/maven-metadata.xml in centraaal
(http://maven.apache.org/null)
[DEBUG] Using transporter WagonTransporter with priority -1.0 for
http://maven.apache.org/null
[INFO] Downloading from centraaal:
http://maven.apache.org/null/org/apache/maven/maven-parent/33/maven-parent-33.pom
{noformat}
Why don't I see {{centraal}} in the repo listing? why is there no repo listing
at all? I will debug.
was (Author: michael-o):
I have looked into again and I still think that this is a bug in Maven. This is
what I get:
{noformat}
No mirror:
> [DEBUG] Repositories (dependencies): [central (file:target/null, default,
> releases), maven-core-it
> (file:///D:/Entwicklung/Projekte/maven-integration-testing/core-it-suite/target/test-classes/mng-3461/test-3/repo,
> default, releases)]
> [DEBUG] Repositories (plugins) : [central (file:target/null, default,
> releases+snapshots)]
With mirror, named central:
[DEBUG] Repositories (dependencies): [central (http://maven.apache.org/null,
default, releases), maven-core-it
(file:///D:/Entwicklung/Projekte/maven-integration-testing/core-it-suite/target/test-classes/mng-3461/test-3/repo,
default, releases)]
[DEBUG] Repositories (plugins) : [central (http://maven.apache.org/null,
default, releases+snapshots)]
With mirror, named centraaal:
[DEBUG] Using transporter WagonTransporter with priority -1.0 for
http://maven.apache.org/null
[INFO] Downloading from centraaal:
http://maven.apache.org/null/org/apache/maven/its/plugins/maven-it-plugin-dependency-resolution/2.1-SNAPSHOT/maven-metadata.xml
[DEBUG] Could not find metadata
org.apache.maven.its.plugins:maven-it-plugin-dependency-resolution:2.1-SNAPSHOT/maven-metadata.xml
in centraaal (http://maven.apache.org/null)
[DEBUG] Failure to find
org.apache.maven.its.plugins:maven-it-plugin-dependency-resolution:2.1-SNAPSHOT/maven-metadata.xml
in http://maven.apache.org/null was cached in the local repository, resolution
will not be reattempted until the update interval of
[jira] [Commented] (ARCHETYPE-556) Property in default-value is not replaced when using automated mode
[
https://issues.apache.org/jira/browse/ARCHETYPE-556?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17074735#comment-17074735
]
Olivier Cailloux commented on ARCHETYPE-556:
I can’t reproduce it any more, I think this bug can be closed. (Didn’t find how
to do that.)
> Property in default-value is not replaced when using automated mode
> ---
>
> Key: ARCHETYPE-556
> URL: https://issues.apache.org/jira/browse/ARCHETYPE-556
> Project: Maven Archetype
> Issue Type: Bug
>Reporter: Olivier Cailloux
>Priority: Major
>
> In {{archetype-metadata.xml}} I have:
> {code:xml}
>
> ${groupId}.${artifactId}
>
> {code}
> This default value is used correctly when using mvn archetype in interactive
> mode, but it is used incorrectly when using mvn archetype -B. In that case,
> the value of package is literally ${groupId}.${artifactId} with no
> replacement.
> To reproduce, type:
> {code:java}
> mvn -B archetype:generate -DarchetypeGroupId=io.github.oliviercailloux
> -DarchetypeArtifactId=java-se-1.8-archetype -DgroupId=mygroupid
> -DartifactId=myartifactid
> {code}
> then {{ls a/src/main/java/}}. Observe that the directory is literally
> {{$\{groupId}}} instead of the expected {{mygroupid}}.
> This archetype is published to Maven Central and its source code is
> [here|https://github.com/oliviercailloux/java-se-1.8-archetype].
> Possibly related: 490, comment of 397.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-6613) Mirror matching ignores closest/nearest definition
[
https://issues.apache.org/jira/browse/MNG-6613?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17074761#comment-17074761
]
Michael Osipov commented on MNG-6613:
-
I am currently going through a few test cases and will report shortly.
> Mirror matching ignores closest/nearest definition
> --
>
> Key: MNG-6613
> URL: https://issues.apache.org/jira/browse/MNG-6613
> Project: Maven
> Issue Type: Bug
> Components: Artifacts and Repositories
>Affects Versions: 3.5.4, 3.6.1
> Environment: Java 8u202, Java11u2
>Reporter: Michael Osipov
>Assignee: Michael Osipov
>Priority: Critical
> Attachments: log.txt
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Ran our IT suite in a locked down environment at work, w/o direct internet
> access. IT {{mng3461MirrorMatching(itNonGreedyWildcard)}} blocks forever
> because the mirror exclude does not work: {{*,!maven-core-it}}.
> It still tries to download via mirror instead of ignoring it. See attached
> log file. Even switching {{!maven-core-it,*}} makes no difference.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (MNG-6613) Mirror matching ignores closest/nearest definition
[
https://issues.apache.org/jira/browse/MNG-6613?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17074772#comment-17074772
]
Michael Osipov edited comment on MNG-6613 at 4/3/20, 6:14 PM:
--
I have looked into again and I still think that this is a bug in Maven. This is
what I get:
No mirror:
{noformat}
[DEBUG] Repositories (dependencies): [central (file:target/null, default,
releases), maven-core-it
(file:///D:/Entwicklung/Projekte/maven-integration-testing/core-it-suite/target/test-classes/mng-3461/test-3/repo,
default, releases)]
[DEBUG] Repositories (plugins) : [central (file:target/null, default,
releases+snapshots)]
{noformat}
With mirror, named central:
{noformat}
[DEBUG] Repositories (dependencies): [central (http://maven.apache.org/null,
default, releases), maven-core-it
(file:///D:/Entwicklung/Projekte/maven-integration-testing/core-it-suite/target/test-classes/mng-3461/test-3/repo,
default, releases)]
[DEBUG] Repositories (plugins) : [central (http://maven.apache.org/null,
default, releases+snapshots)]
{noformat}
With mirror, named centraaal:
{noformat}
[DEBUG] Using mirror centraaal (http://maven.apache.org/null) for central
(file:target/null).
...
[DEBUG] Using transporter WagonTransporter with priority -1.0 for
http://maven.apache.org/null
[INFO] Downloading from centraaal:
http://maven.apache.org/null/org/apache/maven/its/plugins/maven-it-plugin-dependency-resolution/2.1-SNAPSHOT/maven-metadata.xml
[DEBUG] Could not find metadata
org.apache.maven.its.plugins:maven-it-plugin-dependency-resolution:2.1-SNAPSHOT/maven-metadata.xml
in centraaal (http://maven.apache.org/null)
[DEBUG] Failure to find
org.apache.maven.its.plugins:maven-it-plugin-dependency-resolution:2.1-SNAPSHOT/maven-metadata.xml
in http://maven.apache.org/null was cached in the local repository, resolution
will not be reattempted until the update interval of centraaal has elapsed or
updates are forced
[DEBUG] Using transporter WagonTransporter with priority -1.0 for
http://maven.apache.org/null
[INFO] Downloading from centraaal:
http://maven.apache.org/null/org/apache/maven/its/plugins/maven-it-plugins/2.1-SNAPSHOT/maven-metadata.xml
[DEBUG] Could not find metadata
org.apache.maven.its.plugins:maven-it-plugins:2.1-SNAPSHOT/maven-metadata.xml
in centraaal (http://maven.apache.org/null)
[DEBUG] Using transporter WagonTransporter with priority -1.0 for
http://maven.apache.org/null
[INFO] Downloading from centraaal:
http://maven.apache.org/null/org/apache/maven/its/core-it-support/2.1-SNAPSHOT/maven-metadata.xml
[DEBUG] Could not find metadata
org.apache.maven.its:core-it-support:2.1-SNAPSHOT/maven-metadata.xml in
centraaal (http://maven.apache.org/null)
[DEBUG] Using transporter WagonTransporter with priority -1.0 for
http://maven.apache.org/null
[INFO] Downloading from centraaal:
http://maven.apache.org/null/org/apache/maven/its/core-its/2.1-SNAPSHOT/maven-metadata.xml
[DEBUG] Could not find metadata
org.apache.maven.its:core-its:2.1-SNAPSHOT/maven-metadata.xml in centraaal
(http://maven.apache.org/null)
[DEBUG] Using transporter WagonTransporter with priority -1.0 for
http://maven.apache.org/null
[INFO] Downloading from centraaal:
http://maven.apache.org/null/org/apache/maven/maven-parent/33/maven-parent-33.pom
{noformat}
Why don't I see {{centraal}} in the repo listing? why is there no repo listing
at all? I will debug.
was (Author: michael-o):
I have looked into again and I still think that this is a bug in Maven. This is
what I get:
No mirror:
{noformat}
[DEBUG] Repositories (dependencies): [central (file:target/null, default,
releases), maven-core-it
(file:///D:/Entwicklung/Projekte/maven-integration-testing/core-it-suite/target/test-classes/mng-3461/test-3/repo,
default, releases)]
[DEBUG] Repositories (plugins) : [central (file:target/null, default,
releases+snapshots)]
{noformat}
With mirror, named central:
{noformat}
[DEBUG] Repositories (dependencies): [central (http://maven.apache.org/null,
default, releases), maven-core-it
(file:///D:/Entwicklung/Projekte/maven-integration-testing/core-it-suite/target/test-classes/mng-3461/test-3/repo,
default, releases)]
[DEBUG] Repositories (plugins) : [central (http://maven.apache.org/null,
default, releases+snapshots)]
{noformat}
With mirror, named centraaal:
{noformat}
[DEBUG] Using transporter WagonTransporter with priority -1.0 for
http://maven.apache.org/null
[INFO] Downloading from centraaal:
http://maven.apache.org/null/org/apache/maven/its/plugins/maven-it-plugin-dependency-resolution/2.1-SNAPSHOT/maven-metadata.xml
[DEBUG] Could not find metadata
org.apache.maven.its.plugins:maven-it-plugin-dependency-resolution:2.1-SNAPSHOT/maven-metadata.xml
in centraaal (http://maven.apache.org/null)
[DEBUG] Failure to find
org.apache.maven.its.plugins:maven-it-plugin-dependency-resolution:2.1-SNAPSHOT/maven-metadata.xml
in
[jira] [Commented] (MSHARED-872) Embedded3xLauncher cannot be initialized
[ https://issues.apache.org/jira/browse/MSHARED-872?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17074755#comment-17074755 ] Hudson commented on MSHARED-872: Build succeeded in Jenkins: Maven TLP » maven-verifier » master #38 See https://builds.apache.org/job/maven-box/job/maven-verifier/job/master/38/ > Embedded3xLauncher cannot be initialized > > > Key: MSHARED-872 > URL: https://issues.apache.org/jira/browse/MSHARED-872 > Project: Maven Shared Components > Issue Type: Bug > Components: maven-verifier >Affects Versions: maven-verifier-1.7.0 >Reporter: Robert Scholte >Assignee: Robert Scholte >Priority: Major > > [cc4d1cb0d20ba9c7e019c47790eec63106775424|https://gitbox.apache.org/repos/asf?p=maven-verifier.git;a=commit;h=cc4d1cb0d20ba9c7e019c47790eec63106775424] > introduced a bug: by casting the null-value, it is considered as an > argument, whereas null is not. > The nulls shouldn't be here, since the method don't have arguments. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [maven-verifier] rfscholte merged pull request #2: deps: update parent POM dependencies
rfscholte merged pull request #2: deps: update parent POM dependencies URL: https://github.com/apache/maven-verifier/pull/2 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] [Created] (MSHARED-872) Embedded3xLauncher cannot be initialized
Robert Scholte created MSHARED-872: -- Summary: Embedded3xLauncher cannot be initialized Key: MSHARED-872 URL: https://issues.apache.org/jira/browse/MSHARED-872 Project: Maven Shared Components Issue Type: Bug Components: maven-verifier Affects Versions: maven-verifier-1.7.0 Reporter: Robert Scholte Assignee: Robert Scholte [cc4d1cb0d20ba9c7e019c47790eec63106775424|https://gitbox.apache.org/repos/asf?p=maven-verifier.git;a=commit;h=cc4d1cb0d20ba9c7e019c47790eec63106775424] introduced a bug: by casting the null-value, it is considered as an argument, whereas null is not. The nulls shouldn't be here, since the method don't have arguments. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (SUREFIRE-1768) Main classes not included in classpath when using Java Modules
[
https://issues.apache.org/jira/browse/SUREFIRE-1768?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17074694#comment-17074694
]
László Stahorszki commented on SUREFIRE-1768:
-
[~rfscholte]
Could you please clarify some things for me:
# What path overrides what? I'm sorry, I don't understand.
# Those snippets help me find resources in given modules as opposed to just on
the plain classpath?
# If 2) is true. Is it designed like this to enforce the encapsulation the
module system was designed for?
Thanks in advance
> Main classes not included in classpath when using Java Modules
> --
>
> Key: SUREFIRE-1768
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1768
> Project: Maven Surefire
> Issue Type: Bug
> Components: classloading
>Affects Versions: 3.0.0-M4
> Environment: Windows 10, JDK 11
>Reporter: László Stahorszki
>Assignee: Robert Scholte
>Priority: Major
>
> According to the
> [documentation|http://maven.apache.org/surefire/maven-surefire-plugin/examples/configuring-classpath.html],
> the `classes` directory should be put on the classpath by default.
> In this case, given that I have a `demo` package in both my main sources and
> my test source, the enumeration
> `classLoader.getResources({color:#6a8759}"demo"{color})` should have 2 URLs
> in it. One for the package in the test sources and one for the main sources.
> When using the Java Module System, this is not the case. Instead, I get two
> URLs, both for the test sources. This error does not occur when not using the
> module system.
> I created a repository, which can reproduce this error. It can be found
> [here|https://github.com/rolaca11/test-classpath-demo]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (SUREFIRE-1768) Main classes not included in classpath when using Java Modules
[
https://issues.apache.org/jira/browse/SUREFIRE-1768?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17074694#comment-17074694
]
László Stahorszki edited comment on SUREFIRE-1768 at 4/3/20, 4:08 PM:
--
[~rfscholte]
Could you please clarify some things for me:
# What patch overrides what? I'm sorry, I don't understand.
# Those snippets help me find resources in given modules as opposed to just on
the plain classpath?
# If 2) is true. Is it designed like this to enforce the encapsulation the
module system was designed for?
Thanks in advance
was (Author: rolaca11):
[~rfscholte]
Could you please clarify some things for me:
# What path overrides what? I'm sorry, I don't understand.
# Those snippets help me find resources in given modules as opposed to just on
the plain classpath?
# If 2) is true. Is it designed like this to enforce the encapsulation the
module system was designed for?
Thanks in advance
> Main classes not included in classpath when using Java Modules
> --
>
> Key: SUREFIRE-1768
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1768
> Project: Maven Surefire
> Issue Type: Bug
> Components: classloading
>Affects Versions: 3.0.0-M4
> Environment: Windows 10, JDK 11
>Reporter: László Stahorszki
>Assignee: Robert Scholte
>Priority: Major
>
> According to the
> [documentation|http://maven.apache.org/surefire/maven-surefire-plugin/examples/configuring-classpath.html],
> the `classes` directory should be put on the classpath by default.
> In this case, given that I have a `demo` package in both my main sources and
> my test source, the enumeration
> `classLoader.getResources({color:#6a8759}"demo"{color})` should have 2 URLs
> in it. One for the package in the test sources and one for the main sources.
> When using the Java Module System, this is not the case. Instead, I get two
> URLs, both for the test sources. This error does not occur when not using the
> module system.
> I created a repository, which can reproduce this error. It can be found
> [here|https://github.com/rolaca11/test-classpath-demo]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-6613) Mirror matching ignores closest/nearest definition
[
https://issues.apache.org/jira/browse/MNG-6613?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17074772#comment-17074772
]
Michael Osipov commented on MNG-6613:
-
I have looked into again and I still think that this is a bug in Maven. This is
what I get:
{noformat}
No mirror:
> [DEBUG] Repositories (dependencies): [central (file:target/null, default,
> releases), maven-core-it
> (file:///D:/Entwicklung/Projekte/maven-integration-testing/core-it-suite/target/test-classes/mng-3461/test-3/repo,
> default, releases)]
> [DEBUG] Repositories (plugins) : [central (file:target/null, default,
> releases+snapshots)]
With mirror, named central:
[DEBUG] Repositories (dependencies): [central (http://maven.apache.org/null,
default, releases), maven-core-it
(file:///D:/Entwicklung/Projekte/maven-integration-testing/core-it-suite/target/test-classes/mng-3461/test-3/repo,
default, releases)]
[DEBUG] Repositories (plugins) : [central (http://maven.apache.org/null,
default, releases+snapshots)]
With mirror, named centraaal:
[DEBUG] Using transporter WagonTransporter with priority -1.0 for
http://maven.apache.org/null
[INFO] Downloading from centraaal:
http://maven.apache.org/null/org/apache/maven/its/plugins/maven-it-plugin-dependency-resolution/2.1-SNAPSHOT/maven-metadata.xml
[DEBUG] Could not find metadata
org.apache.maven.its.plugins:maven-it-plugin-dependency-resolution:2.1-SNAPSHOT/maven-metadata.xml
in centraaal (http://maven.apache.org/null)
[DEBUG] Failure to find
org.apache.maven.its.plugins:maven-it-plugin-dependency-resolution:2.1-SNAPSHOT/maven-metadata.xml
in http://maven.apache.org/null was cached in the local repository, resolution
will not be reattempted until the update interval of centraaal has elapsed or
updates are forced
[DEBUG] Using transporter WagonTransporter with priority -1.0 for
http://maven.apache.org/null
[INFO] Downloading from centraaal:
http://maven.apache.org/null/org/apache/maven/its/plugins/maven-it-plugins/2.1-SNAPSHOT/maven-metadata.xml
[DEBUG] Could not find metadata
org.apache.maven.its.plugins:maven-it-plugins:2.1-SNAPSHOT/maven-metadata.xml
in centraaal (http://maven.apache.org/null)
[DEBUG] Using transporter WagonTransporter with priority -1.0 for
http://maven.apache.org/null
[INFO] Downloading from centraaal:
http://maven.apache.org/null/org/apache/maven/its/core-it-support/2.1-SNAPSHOT/maven-metadata.xml
[DEBUG] Could not find metadata
org.apache.maven.its:core-it-support:2.1-SNAPSHOT/maven-metadata.xml in
centraaal (http://maven.apache.org/null)
[DEBUG] Using transporter WagonTransporter with priority -1.0 for
http://maven.apache.org/null
[INFO] Downloading from centraaal:
http://maven.apache.org/null/org/apache/maven/its/core-its/2.1-SNAPSHOT/maven-metadata.xml
[DEBUG] Could not find metadata
org.apache.maven.its:core-its:2.1-SNAPSHOT/maven-metadata.xml in centraaal
(http://maven.apache.org/null)
[DEBUG] Using transporter WagonTransporter with priority -1.0 for
http://maven.apache.org/null
[INFO] Downloading from centraaal:
http://maven.apache.org/null/org/apache/maven/maven-parent/33/maven-parent-33.pom
{noformat}
Why don't I see {{centraal}} in the repo listing? why is there no repo listing
at all? I will debug.
> Mirror matching ignores closest/nearest definition
> --
>
> Key: MNG-6613
> URL: https://issues.apache.org/jira/browse/MNG-6613
> Project: Maven
> Issue Type: Bug
> Components: Artifacts and Repositories
>Affects Versions: 3.5.4, 3.6.1
> Environment: Java 8u202, Java11u2
>Reporter: Michael Osipov
>Assignee: Michael Osipov
>Priority: Critical
> Attachments: log.txt
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Ran our IT suite in a locked down environment at work, w/o direct internet
> access. IT {{mng3461MirrorMatching(itNonGreedyWildcard)}} blocks forever
> because the mirror exclude does not work: {{*,!maven-core-it}}.
> It still tries to download via mirror instead of ignoring it. See attached
> log file. Even switching {{!maven-core-it,*}} makes no difference.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (SUREFIRE-1719) Race condition results in "VM crash or System.exit called?" failure
[
https://issues.apache.org/jira/browse/SUREFIRE-1719?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17074781#comment-17074781
]
Tigran Mkrtchyan commented on SUREFIRE-1719:
Unfortunately even with current master I can see the error:
{code}
[INFO]
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-surefire-plugin:3.0.0-SNAPSHOT:test
(default-test) on project dcache-common: There are test failures.
[ERROR]
[ERROR] Please refer to
/home/tigran/eProjects/dcache-git/modules/common/target/surefire-reports for
the individual test results.
[ERROR] Please refer to dump files (if any exist) [date].dump,
[date]-jvmRun[N].dump and [date].dumpstream.
[ERROR] ExecutionException The forked VM terminated without properly saying
goodbye. VM crash or System.exit called?
[ERROR] Command was /bin/sh -c cd
/home/tigran/eProjects/dcache-git/modules/common &&
/usr/lib/jvm/java-11-openjdk-11.0.6.10-0.fc31.x86_64/bin/java '${argLine}'
--add-modules=java.security.jgss -jar
/home/tigran/eProjects/dcache-git/modules/common/target/surefire/surefirebooter15798824340157134030.jar
/home/tigran/eProjects/dcache-git/modules/common/target/surefire
2020-04-03T20-17-52_663-jvmRun1 surefire6874474157466927398tmp
surefire_59109352228556929562tmp
[ERROR] Error occurred in starting fork, check output in log
[ERROR] Process Exit Code: 1
{code}
> Race condition results in "VM crash or System.exit called?" failure
> ---
>
> Key: SUREFIRE-1719
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1719
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Surefire Plugin
>Affects Versions: 2.20, 2.20.1, 2.21.0, 2.22.0, 2.22.1, 2.22.2, 3.0.0-M2,
> 3.0.0-M1, 3.0.0-M3
>Reporter: Paul Millar
>Assignee: Tibor Digana
>Priority: Major
> Fix For: 3.0.0-M5
>
> Attachments: build-error-debug.out, build.out, pom.xml
>
>
> After upgrading surefire in our project (dCache) from 2.19.1 to 3.0.0-M3,
> unit tests started to fail with the message "ExecutionException The forked VM
> terminated without properly saying goodbye. VM crash or System.exit called?"
> For reference, the command I am using to verify this problem is "mvn -am -pl
> modules/common clean package" and the surefire configuration is:
> {{}}
> {{ org.apache.maven.plugins}}
> {{ maven-surefire-plugin}}
> {{ }}
> {{ }}
> {{ **/*Test.class}}
> {{ **/*Tests.class}}
> {{ }}
> {{ }}
> {{ 1C}}
> {{ false}}
> {{ }}
> {{ }}
> [The complete pom.xml is attached.]
> This problem is not always present. On our build machine, I've seen the
> problem appear 6 out of 10 times when running the above mvn command. There is
> (apparently) little that seems to influence whether the build will succeed or
> fail.
> [I've attached the complete output from running the above mvn command, both
> the normal output and including the -e -X options.]
> The problem seems to appear only on machines with a "large" number of cores.
> Our build machine has 24 cores, and I've seen a report of a similar problem
> where building dCache on a 48 core machine. On the other side, I have been
> unable to reproduce the problem with my desktop machine (8 core) or on my
> laptop (4 cores).
> What seems to matter is the number of actually running JVM instances.
> I have not been able to reproduce the problem by increasing the forkCount on
> a machine with a small number of cores. However, I've noticed that, on an 8
> core machine, increasing the forkCount does not actually result in that many
> more JVM instances running.
> Similarly, experience shows that reducing the number of concurrent JVM
> instances "fixes" the problem. A forkCount of 6 seems to bring the likelihood
> of a problem below 10% (0 failures with 10 builds) on our build machine. On
> this machine, the default configuration would try to run 24 JVM instances
> concurrently (forkCount of "1C" on a 24 core machine).
> The problem appears to have been introduced in surefire v2.20. When building
> with surefire v2.19.1, the above mvn command is always successful on our
> build machine. Building with surefire v2.20 results in intermittent failures
> (~60% failure rate).
> Using git bisection (and with the criterion for "good" as zero failures in 10
> build attempts), I was able to determine that commit da7ff6aa2 "SUREFIRE-1342
> Acknowledge normal exit of JVM and drain shared memory between processes" is
> the first commit where surefire has this intermittent failure behaviour.
> From a causal scan through the patch, my guess is that the BYE_ACK support it
> introduces is somehow racy (for example, reading or updating a field-member
> outside of a monitor) and
[jira] [Issue Comment Deleted] (MNG-6613) Mirror matching ignores closest/nearest definition
[
https://issues.apache.org/jira/browse/MNG-6613?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated MNG-6613:
Comment: was deleted
(was: I have looked into again and I still think that this is a bug in Maven.
This is what I get:
No mirror:
{noformat}
[DEBUG] Repositories (dependencies): [central (file:target/null, default,
releases), maven-core-it
(file:///D:/Entwicklung/Projekte/maven-integration-testing/core-it-suite/target/test-classes/mng-3461/test-3/repo,
default, releases)]
[DEBUG] Repositories (plugins) : [central (file:target/null, default,
releases+snapshots)]
{noformat}
With mirror, named central:
{noformat}
[DEBUG] Repositories (dependencies): [central (http://maven.apache.org/null,
default, releases), maven-core-it
(file:///D:/Entwicklung/Projekte/maven-integration-testing/core-it-suite/target/test-classes/mng-3461/test-3/repo,
default, releases)]
[DEBUG] Repositories (plugins) : [central (http://maven.apache.org/null,
default, releases+snapshots)]
{noformat}
With mirror, named centraaal:
{noformat}
[DEBUG] Using mirror centraaal (http://maven.apache.org/null) for central
(file:target/null).
...
[DEBUG] Using transporter WagonTransporter with priority -1.0 for
http://maven.apache.org/null
[INFO] Downloading from centraaal:
http://maven.apache.org/null/org/apache/maven/its/plugins/maven-it-plugin-dependency-resolution/2.1-SNAPSHOT/maven-metadata.xml
[DEBUG] Could not find metadata
org.apache.maven.its.plugins:maven-it-plugin-dependency-resolution:2.1-SNAPSHOT/maven-metadata.xml
in centraaal (http://maven.apache.org/null)
[DEBUG] Failure to find
org.apache.maven.its.plugins:maven-it-plugin-dependency-resolution:2.1-SNAPSHOT/maven-metadata.xml
in http://maven.apache.org/null was cached in the local repository, resolution
will not be reattempted until the update interval of centraaal has elapsed or
updates are forced
[DEBUG] Using transporter WagonTransporter with priority -1.0 for
http://maven.apache.org/null
[INFO] Downloading from centraaal:
http://maven.apache.org/null/org/apache/maven/its/plugins/maven-it-plugins/2.1-SNAPSHOT/maven-metadata.xml
[DEBUG] Could not find metadata
org.apache.maven.its.plugins:maven-it-plugins:2.1-SNAPSHOT/maven-metadata.xml
in centraaal (http://maven.apache.org/null)
[DEBUG] Using transporter WagonTransporter with priority -1.0 for
http://maven.apache.org/null
[INFO] Downloading from centraaal:
http://maven.apache.org/null/org/apache/maven/its/core-it-support/2.1-SNAPSHOT/maven-metadata.xml
[DEBUG] Could not find metadata
org.apache.maven.its:core-it-support:2.1-SNAPSHOT/maven-metadata.xml in
centraaal (http://maven.apache.org/null)
[DEBUG] Using transporter WagonTransporter with priority -1.0 for
http://maven.apache.org/null
[INFO] Downloading from centraaal:
http://maven.apache.org/null/org/apache/maven/its/core-its/2.1-SNAPSHOT/maven-metadata.xml
[DEBUG] Could not find metadata
org.apache.maven.its:core-its:2.1-SNAPSHOT/maven-metadata.xml in centraaal
(http://maven.apache.org/null)
[DEBUG] Using transporter WagonTransporter with priority -1.0 for
http://maven.apache.org/null
[INFO] Downloading from centraaal:
http://maven.apache.org/null/org/apache/maven/maven-parent/33/maven-parent-33.pom
{noformat}
Why don't I see {{centraal}} in the repo listing? why is there no repo listing
at all? I will debug.)
> Mirror matching ignores closest/nearest definition
> --
>
> Key: MNG-6613
> URL: https://issues.apache.org/jira/browse/MNG-6613
> Project: Maven
> Issue Type: Bug
> Components: Artifacts and Repositories
>Affects Versions: 3.5.4, 3.6.1
> Environment: Java 8u202, Java11u2
>Reporter: Michael Osipov
>Assignee: Michael Osipov
>Priority: Critical
> Attachments: log.txt
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Ran our IT suite in a locked down environment at work, w/o direct internet
> access. IT {{mng3461MirrorMatching(itNonGreedyWildcard)}} blocks forever
> because the mirror exclude does not work: {{*,!maven-core-it}}.
> It still tries to download via mirror instead of ignoring it. See attached
> log file. Even switching {{!maven-core-it,*}} makes no difference.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (MSHARED-872) Embedded3xLauncher cannot be initialized
[ https://issues.apache.org/jira/browse/MSHARED-872?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Scholte closed MSHARED-872. -- Fix Version/s: maven-verifier-1.7.1 Resolution: Fixed Fixed in [80903310d2f94d9aa6d9a0af44676757ad85d588|https://gitbox.apache.org/repos/asf?p=maven-verifier.git;a=commit;h=80903310d2f94d9aa6d9a0af44676757ad85d588] > Embedded3xLauncher cannot be initialized > > > Key: MSHARED-872 > URL: https://issues.apache.org/jira/browse/MSHARED-872 > Project: Maven Shared Components > Issue Type: Bug > Components: maven-verifier >Affects Versions: maven-verifier-1.7.0 >Reporter: Robert Scholte >Assignee: Robert Scholte >Priority: Major > Fix For: maven-verifier-1.7.1 > > > [cc4d1cb0d20ba9c7e019c47790eec63106775424|https://gitbox.apache.org/repos/asf?p=maven-verifier.git;a=commit;h=cc4d1cb0d20ba9c7e019c47790eec63106775424] > introduced a bug: by casting the null-value, it is considered as an > argument, whereas null is not. > The nulls shouldn't be here, since the method don't have arguments. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-6613) Mirror matching ignores closest/nearest definition
[
https://issues.apache.org/jira/browse/MNG-6613?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17074805#comment-17074805
]
Michael Osipov commented on MNG-6613:
-
So here it is:
No mirrors:
{noformat}
[DEBUG] Repositories (dependencies): [central (file:target/null, default,
releases), maven-core-it
(file:///D:/Entwicklung/Projekte/maven-integration-testing/core-it-suite/target/test-classes/mng-3461/test-3/repo,
default, releases)]
[DEBUG] Repositories (plugins) : [central (file:target/null, default,
releases+snapshots)]
{noformat}
Mirror: central
{noformat}
[DEBUG] Using mirror central (http://maven.apache.org/null) for central
(file:target/null).
...
[DEBUG] Repositories (dependencies): [central (http://maven.apache.org/null,
default, releases), maven-core-it
(file:///D:/Entwicklung/Projekte/maven-integration-testing/core-it-suite/target/test-classes/mng-3461/test-3/repo,
default, releases)]
[DEBUG] Repositories (plugins) : [central (http://maven.apache.org/null,
default, releases+snapshots)]
{noformat}
Mirror: centraal
{noformat}
[DEBUG] Using mirror centraal (http://maven.apache.org/null) for central
(file:target/null).
...
Exceptions that files are not found
{noformat}
Why the failure? The problem is actually not the the test per-se and not the
outbound access. Reviewing MNG-3461 and as mentioned by Robert in the mini
guide, {{*}} matches all repos, even local ones as you can see for both
{{central}} and {{centraal}} (the Dutch version).
Now the problems:
* Test should not rely on outbound access to mute a non-existing local repo
with another repo non-existing repo. This could be simply done by another local
non-existing local repo.
* The mirror is called {{central}} which is not a problem. Why does not
{{centraal}} fail? {{central}} implicitly relies on the fact that
{{_remote.properties}} will contain {{${filename}>central=}} and central has
been used previously to download all artifacts. We modify with
{{maven.it.central}} and Bootstrap for that.
Now what I need to figure out what artifacts from pulled from non-existing
mirror and why they are not pulled from {{maven-core-it}}.
> Mirror matching ignores closest/nearest definition
> --
>
> Key: MNG-6613
> URL: https://issues.apache.org/jira/browse/MNG-6613
> Project: Maven
> Issue Type: Bug
> Components: Artifacts and Repositories
>Affects Versions: 3.5.4, 3.6.1
> Environment: Java 8u202, Java11u2
>Reporter: Michael Osipov
>Assignee: Michael Osipov
>Priority: Critical
> Attachments: log.txt
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Ran our IT suite in a locked down environment at work, w/o direct internet
> access. IT {{mng3461MirrorMatching(itNonGreedyWildcard)}} blocks forever
> because the mirror exclude does not work: {{*,!maven-core-it}}.
> It still tries to download via mirror instead of ignoring it. See attached
> log file. Even switching {{!maven-core-it,*}} makes no difference.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (SUREFIRE-1719) Race condition results in "VM crash or System.exit called?" failure
[
https://issues.apache.org/jira/browse/SUREFIRE-1719?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17074820#comment-17074820
]
Tibor Digana commented on SUREFIRE-1719:
[~tigran]
99% of these logs are useless. You can simply call {{System.exit(0)}} in your
test and you get the same logs many other people have on this planet with
totally different root cause.
So you should checkout the
[commit|https://issues.apache.org/jira/browse/SUREFIRE-1719?focusedCommentId=17004616=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17004616]
and build the plugin locally using {{mvn install -DskipTests}} and run your
tests in your project in offline mode {{mvn -o test}}.
Again you may have error but root cause is maybe different from what
[~paulmillar] had. How can you prove that you have his root cause?
> Race condition results in "VM crash or System.exit called?" failure
> ---
>
> Key: SUREFIRE-1719
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1719
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Surefire Plugin
>Affects Versions: 2.20, 2.20.1, 2.21.0, 2.22.0, 2.22.1, 2.22.2, 3.0.0-M2,
> 3.0.0-M1, 3.0.0-M3
>Reporter: Paul Millar
>Assignee: Tibor Digana
>Priority: Major
> Fix For: 3.0.0-M5
>
> Attachments: build-error-debug.out, build.out, pom.xml
>
>
> After upgrading surefire in our project (dCache) from 2.19.1 to 3.0.0-M3,
> unit tests started to fail with the message "ExecutionException The forked VM
> terminated without properly saying goodbye. VM crash or System.exit called?"
> For reference, the command I am using to verify this problem is "mvn -am -pl
> modules/common clean package" and the surefire configuration is:
> {{}}
> {{ org.apache.maven.plugins}}
> {{ maven-surefire-plugin}}
> {{ }}
> {{ }}
> {{ **/*Test.class}}
> {{ **/*Tests.class}}
> {{ }}
> {{ }}
> {{ 1C}}
> {{ false}}
> {{ }}
> {{ }}
> [The complete pom.xml is attached.]
> This problem is not always present. On our build machine, I've seen the
> problem appear 6 out of 10 times when running the above mvn command. There is
> (apparently) little that seems to influence whether the build will succeed or
> fail.
> [I've attached the complete output from running the above mvn command, both
> the normal output and including the -e -X options.]
> The problem seems to appear only on machines with a "large" number of cores.
> Our build machine has 24 cores, and I've seen a report of a similar problem
> where building dCache on a 48 core machine. On the other side, I have been
> unable to reproduce the problem with my desktop machine (8 core) or on my
> laptop (4 cores).
> What seems to matter is the number of actually running JVM instances.
> I have not been able to reproduce the problem by increasing the forkCount on
> a machine with a small number of cores. However, I've noticed that, on an 8
> core machine, increasing the forkCount does not actually result in that many
> more JVM instances running.
> Similarly, experience shows that reducing the number of concurrent JVM
> instances "fixes" the problem. A forkCount of 6 seems to bring the likelihood
> of a problem below 10% (0 failures with 10 builds) on our build machine. On
> this machine, the default configuration would try to run 24 JVM instances
> concurrently (forkCount of "1C" on a 24 core machine).
> The problem appears to have been introduced in surefire v2.20. When building
> with surefire v2.19.1, the above mvn command is always successful on our
> build machine. Building with surefire v2.20 results in intermittent failures
> (~60% failure rate).
> Using git bisection (and with the criterion for "good" as zero failures in 10
> build attempts), I was able to determine that commit da7ff6aa2 "SUREFIRE-1342
> Acknowledge normal exit of JVM and drain shared memory between processes" is
> the first commit where surefire has this intermittent failure behaviour.
> From a causal scan through the patch, my guess is that the BYE_ACK support it
> introduces is somehow racy (for example, reading or updating a field-member
> outside of a monitor) and problems are triggered if there are a large number
> of JVMs exiting concurrently. So, with increased number of concurrent JVMs
> there is an increased risk of a thread loosing the race, and so triggering
> this error.
> Such a problem would be consistent with observed behaviour. However, I don't
> have any strong evidence that this is what is happening.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-6613) Mirror matching ignores closest/nearest definition
[
https://issues.apache.org/jira/browse/MNG-6613?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17074864#comment-17074864
]
Michael Osipov commented on MNG-6613:
-
My initial description is wrong because I have analyzed the issue now properly.
While our network has changed and surprisingly now works w/o a proxy, you can
still setp an IP address which does not exist, e.g,, {{192.168.0.1}} and it
will block. On Windows, the block is released quickly, on my corporate server
with FreeBSD it takes as long as the Wagon read timeout of 180 s. Will work on
a better test.
> Mirror matching ignores closest/nearest definition
> --
>
> Key: MNG-6613
> URL: https://issues.apache.org/jira/browse/MNG-6613
> Project: Maven
> Issue Type: Bug
> Components: Artifacts and Repositories
>Affects Versions: 3.5.4, 3.6.1
> Environment: Java 8u202, Java11u2
>Reporter: Michael Osipov
>Assignee: Michael Osipov
>Priority: Critical
> Attachments: log.txt
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Ran our IT suite in a locked down environment at work, w/o direct internet
> access. IT {{mng3461MirrorMatching(itNonGreedyWildcard)}} blocks forever
> because the mirror exclude does not work: {{*,!maven-core-it}}.
> It still tries to download via mirror instead of ignoring it. See attached
> log file. Even switching {{!maven-core-it,*}} makes no difference.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (ARCHETYPE-556) Property in default-value is not replaced when using automated mode
[
https://issues.apache.org/jira/browse/ARCHETYPE-556?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte closed ARCHETYPE-556.
Assignee: Robert Scholte
Resolution: Cannot Reproduce
> Property in default-value is not replaced when using automated mode
> ---
>
> Key: ARCHETYPE-556
> URL: https://issues.apache.org/jira/browse/ARCHETYPE-556
> Project: Maven Archetype
> Issue Type: Bug
>Reporter: Olivier Cailloux
>Assignee: Robert Scholte
>Priority: Major
>
> In {{archetype-metadata.xml}} I have:
> {code:xml}
>
> ${groupId}.${artifactId}
>
> {code}
> This default value is used correctly when using mvn archetype in interactive
> mode, but it is used incorrectly when using mvn archetype -B. In that case,
> the value of package is literally ${groupId}.${artifactId} with no
> replacement.
> To reproduce, type:
> {code:java}
> mvn -B archetype:generate -DarchetypeGroupId=io.github.oliviercailloux
> -DarchetypeArtifactId=java-se-1.8-archetype -DgroupId=mygroupid
> -DartifactId=myartifactid
> {code}
> then {{ls a/src/main/java/}}. Observe that the directory is literally
> {{$\{groupId}}} instead of the expected {{mygroupid}}.
> This archetype is published to Maven Central and its source code is
> [here|https://github.com/oliviercailloux/java-se-1.8-archetype].
> Possibly related: 490, comment of 397.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (MPLUGIN-360) generated plugin-help.xml ignores descriptor mojo outputDirectory
Dariusz Kuc created MPLUGIN-360:
---
Summary: generated plugin-help.xml ignores descriptor mojo
outputDirectory
Key: MPLUGIN-360
URL: https://issues.apache.org/jira/browse/MPLUGIN-360
Project: Maven Plugin Tools
Issue Type: Bug
Components: Plugin Plugin
Affects Versions: 3.6.0
Reporter: Dariusz Kuc
_maven-plugin-plugin:descriptor_ mojo supports specifying custom output
directory
([https://maven.apache.org/components/plugin-tools-archives/plugin-tools-3.5/maven-plugin-plugin/descriptor-mojo.html#outputDirectory])
but it is only used for generation of *_plugin.xml_*, *__* *_plugin-help.xml_*
is always generated under default build directory.
In code:
* plugin.xml uses correct directory ->
[https://github.com/apache/maven-plugin-tools/blob/master/maven-plugin-tools-generators/src/main/java/org/apache/maven/tools/plugin/generator/PluginDescriptorGenerator.java#L77
]
{code:java}
File f = new File( destinationDirectory, "plugin.xml" );{code}
* plugin-help.xml uses default build directory ->
[https://github.com/apache/maven-plugin-tools/blob/master/maven-plugin-tools-generators/src/main/java/org/apache/maven/tools/plugin/generator/PluginDescriptorGenerator.java#L83]
{code:java}
f = new File( mavenProject.getBuild().getOutputDirectory(),
PluginHelpGenerator.getPluginHelpPath( mavenProject ) );{code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (MPLUGIN-360) generated plugin-help.xml ignores descriptor mojo outputDirectory
[
https://issues.apache.org/jira/browse/MPLUGIN-360?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dariusz Kuc updated MPLUGIN-360:
Description:
_maven-plugin-plugin:descriptor_ mojo supports specifying custom output
directory
([https://maven.apache.org/components/plugin-tools-archives/plugin-tools-3.5/maven-plugin-plugin/descriptor-mojo.html#outputDirectory])
but it is only used for generation of *_plugin.xml_*, *_* _*_plugin-help.xml*_
is always generated under default build directory.
In code:
* plugin.xml uses correct directory ->
[[https://github.com/apache/maven-plugin-tools/blob/master/maven-plugin-tools-generators/src/main/java/org/apache/maven/tools/plugin/generator/PluginDescriptorGenerator.java#L77]
{code:java}
File f = new File( destinationDirectory, "plugin.xml" );{code}
* plugin-help.xml uses default build directory ->
[https://github.com/apache/maven-plugin-tools/blob/master/maven-plugin-tools-generators/src/main/java/org/apache/maven/tools/plugin/generator/PluginDescriptorGenerator.java#L83]
{code:java}
f = new File( mavenProject.getBuild().getOutputDirectory(),
PluginHelpGenerator.getPluginHelpPath( mavenProject ) );{code}
was:
_maven-plugin-plugin:descriptor_ mojo supports specifying custom output
directory
([https://maven.apache.org/components/plugin-tools-archives/plugin-tools-3.5/maven-plugin-plugin/descriptor-mojo.html#outputDirectory])
but it is only used for generation of *_plugin.xml_*, *__* *_plugin-help.xml_*
is always generated under default build directory.
In code:
* plugin.xml uses correct directory ->
[https://github.com/apache/maven-plugin-tools/blob/master/maven-plugin-tools-generators/src/main/java/org/apache/maven/tools/plugin/generator/PluginDescriptorGenerator.java#L77
]
{code:java}
File f = new File( destinationDirectory, "plugin.xml" );{code}
* plugin-help.xml uses default build directory ->
[https://github.com/apache/maven-plugin-tools/blob/master/maven-plugin-tools-generators/src/main/java/org/apache/maven/tools/plugin/generator/PluginDescriptorGenerator.java#L83]
{code:java}
f = new File( mavenProject.getBuild().getOutputDirectory(),
PluginHelpGenerator.getPluginHelpPath( mavenProject ) );{code}
> generated plugin-help.xml ignores descriptor mojo outputDirectory
> -
>
> Key: MPLUGIN-360
> URL: https://issues.apache.org/jira/browse/MPLUGIN-360
> Project: Maven Plugin Tools
> Issue Type: Bug
> Components: Plugin Plugin
>Affects Versions: 3.6.0
>Reporter: Dariusz Kuc
>Priority: Minor
>
> _maven-plugin-plugin:descriptor_ mojo supports specifying custom output
> directory
> ([https://maven.apache.org/components/plugin-tools-archives/plugin-tools-3.5/maven-plugin-plugin/descriptor-mojo.html#outputDirectory])
> but it is only used for generation of *_plugin.xml_*, *_*
> _*_plugin-help.xml*_ is always generated under default build directory.
>
> In code:
> * plugin.xml uses correct directory ->
> [[https://github.com/apache/maven-plugin-tools/blob/master/maven-plugin-tools-generators/src/main/java/org/apache/maven/tools/plugin/generator/PluginDescriptorGenerator.java#L77]
>
> {code:java}
> File f = new File( destinationDirectory, "plugin.xml" );{code}
> * plugin-help.xml uses default build directory ->
> [https://github.com/apache/maven-plugin-tools/blob/master/maven-plugin-tools-generators/src/main/java/org/apache/maven/tools/plugin/generator/PluginDescriptorGenerator.java#L83]
>
> {code:java}
> f = new File( mavenProject.getBuild().getOutputDirectory(),
> PluginHelpGenerator.getPluginHelpPath( mavenProject ) );{code}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (MNG-6613) Mirror matching ignores closest/nearest definition
[
https://issues.apache.org/jira/browse/MNG-6613?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov closed MNG-6613.
---
Resolution: Fixed
Fixed with 76c80f1dfeaca8d14a09e80193e1c45bfb42f777 in integration tests.
> Mirror matching ignores closest/nearest definition
> --
>
> Key: MNG-6613
> URL: https://issues.apache.org/jira/browse/MNG-6613
> Project: Maven
> Issue Type: Bug
> Components: Artifacts and Repositories, Integration Tests
>Affects Versions: 3.5.4, 3.6.1
> Environment: Java 8u202, Java11u2
>Reporter: Michael Osipov
>Assignee: Michael Osipov
>Priority: Critical
> Attachments: log.txt
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Ran our IT suite in a locked down environment at work, w/o direct internet
> access. IT {{mng3461MirrorMatching(itNonGreedyWildcard)}} blocks forever
> because the mirror exclude does not work: {{*,!maven-core-it}}.
> It still tries to download via mirror instead of ignoring it. See attached
> log file. Even switching {{!maven-core-it,*}} makes no difference.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (SUREFIRE-1719) Race condition results in "VM crash or System.exit called?" failure
[
https://issues.apache.org/jira/browse/SUREFIRE-1719?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17074932#comment-17074932
]
Tigran Mkrtchyan commented on SUREFIRE-1719:
Well, as Paul and I working together and on the same project I am pretty sure
that this is the same issue.
> Race condition results in "VM crash or System.exit called?" failure
> ---
>
> Key: SUREFIRE-1719
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1719
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Surefire Plugin
>Affects Versions: 2.20, 2.20.1, 2.21.0, 2.22.0, 2.22.1, 2.22.2, 3.0.0-M2,
> 3.0.0-M1, 3.0.0-M3
>Reporter: Paul Millar
>Assignee: Tibor Digana
>Priority: Major
> Fix For: 3.0.0-M5
>
> Attachments: build-error-debug.out, build.out, pom.xml
>
>
> After upgrading surefire in our project (dCache) from 2.19.1 to 3.0.0-M3,
> unit tests started to fail with the message "ExecutionException The forked VM
> terminated without properly saying goodbye. VM crash or System.exit called?"
> For reference, the command I am using to verify this problem is "mvn -am -pl
> modules/common clean package" and the surefire configuration is:
> {{}}
> {{ org.apache.maven.plugins}}
> {{ maven-surefire-plugin}}
> {{ }}
> {{ }}
> {{ **/*Test.class}}
> {{ **/*Tests.class}}
> {{ }}
> {{ }}
> {{ 1C}}
> {{ false}}
> {{ }}
> {{ }}
> [The complete pom.xml is attached.]
> This problem is not always present. On our build machine, I've seen the
> problem appear 6 out of 10 times when running the above mvn command. There is
> (apparently) little that seems to influence whether the build will succeed or
> fail.
> [I've attached the complete output from running the above mvn command, both
> the normal output and including the -e -X options.]
> The problem seems to appear only on machines with a "large" number of cores.
> Our build machine has 24 cores, and I've seen a report of a similar problem
> where building dCache on a 48 core machine. On the other side, I have been
> unable to reproduce the problem with my desktop machine (8 core) or on my
> laptop (4 cores).
> What seems to matter is the number of actually running JVM instances.
> I have not been able to reproduce the problem by increasing the forkCount on
> a machine with a small number of cores. However, I've noticed that, on an 8
> core machine, increasing the forkCount does not actually result in that many
> more JVM instances running.
> Similarly, experience shows that reducing the number of concurrent JVM
> instances "fixes" the problem. A forkCount of 6 seems to bring the likelihood
> of a problem below 10% (0 failures with 10 builds) on our build machine. On
> this machine, the default configuration would try to run 24 JVM instances
> concurrently (forkCount of "1C" on a 24 core machine).
> The problem appears to have been introduced in surefire v2.20. When building
> with surefire v2.19.1, the above mvn command is always successful on our
> build machine. Building with surefire v2.20 results in intermittent failures
> (~60% failure rate).
> Using git bisection (and with the criterion for "good" as zero failures in 10
> build attempts), I was able to determine that commit da7ff6aa2 "SUREFIRE-1342
> Acknowledge normal exit of JVM and drain shared memory between processes" is
> the first commit where surefire has this intermittent failure behaviour.
> From a causal scan through the patch, my guess is that the BYE_ACK support it
> introduces is somehow racy (for example, reading or updating a field-member
> outside of a monitor) and problems are triggered if there are a large number
> of JVMs exiting concurrently. So, with increased number of concurrent JVMs
> there is an increased risk of a thread loosing the race, and so triggering
> this error.
> Such a problem would be consistent with observed behaviour. However, I don't
> have any strong evidence that this is what is happening.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (SUREFIRE-1768) Main classes not included in classpath when using Java Modules
[
https://issues.apache.org/jira/browse/SUREFIRE-1768?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17074883#comment-17074883
]
László Stahorszki commented on SUREFIRE-1768:
-
[~rfscholte]
I tried the code snippet you provided, however, it doesn't solve the problem if
the package I'm looking for exists in both test and main source. I only get the
URL for the package in the test source set
> Main classes not included in classpath when using Java Modules
> --
>
> Key: SUREFIRE-1768
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1768
> Project: Maven Surefire
> Issue Type: Bug
> Components: classloading
>Affects Versions: 3.0.0-M4
> Environment: Windows 10, JDK 11
>Reporter: László Stahorszki
>Assignee: Robert Scholte
>Priority: Major
>
> According to the
> [documentation|http://maven.apache.org/surefire/maven-surefire-plugin/examples/configuring-classpath.html],
> the `classes` directory should be put on the classpath by default.
> In this case, given that I have a `demo` package in both my main sources and
> my test source, the enumeration
> `classLoader.getResources({color:#6a8759}"demo"{color})` should have 2 URLs
> in it. One for the package in the test sources and one for the main sources.
> When using the Java Module System, this is not the case. Instead, I get two
> URLs, both for the test sources. This error does not occur when not using the
> module system.
> I created a repository, which can reproduce this error. It can be found
> [here|https://github.com/rolaca11/test-classpath-demo]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (MNG-6613) Mirror matching ignores closest/nearest definition
[
https://issues.apache.org/jira/browse/MNG-6613?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated MNG-6613:
Component/s: Integration Tests
> Mirror matching ignores closest/nearest definition
> --
>
> Key: MNG-6613
> URL: https://issues.apache.org/jira/browse/MNG-6613
> Project: Maven
> Issue Type: Bug
> Components: Artifacts and Repositories, Integration Tests
>Affects Versions: 3.5.4, 3.6.1
> Environment: Java 8u202, Java11u2
>Reporter: Michael Osipov
>Assignee: Michael Osipov
>Priority: Critical
> Attachments: log.txt
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Ran our IT suite in a locked down environment at work, w/o direct internet
> access. IT {{mng3461MirrorMatching(itNonGreedyWildcard)}} blocks forever
> because the mirror exclude does not work: {{*,!maven-core-it}}.
> It still tries to download via mirror instead of ignoring it. See attached
> log file. Even switching {{!maven-core-it,*}} makes no difference.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (MNG-6744) Some ITs test with SNAPSHOT versions
[
https://issues.apache.org/jira/browse/MNG-6744?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov reassigned MNG-6744:
---
Assignee: Michael Osipov
> Some ITs test with SNAPSHOT versions
>
>
> Key: MNG-6744
> URL: https://issues.apache.org/jira/browse/MNG-6744
> Project: Maven
> Issue Type: Bug
> Components: Integration Tests
>Reporter: Michael Osipov
>Assignee: Michael Osipov
>Priority: Major
>
> These need to be fixed for a release version:
> {noformat}
> core-it-suite/src/test/java/org/apache/maven/it/MavenITmng3743ForkWithPluginManagementTest.java:
> super( "(2.0.8,3.1-SNAPSHOT)" ); // only test in 2.0.9+
> core-it-suite/src/test/java/org/apache/maven/it/MavenITmng5771CoreExtensionsTest.java:
> requiresMavenVersion( "[3.3.2-SNAPSHOT,)" );
> core-it-suite/src/test/java/org/apache/maven/it/MavenITmng5965ParallelBuildMultipliesWorkTest.java:
> super( "[3.6.1-SNAPSHOT,)" );
> core-it-suite/src/test/java/org/apache/maven/it/MavenITmng6352PrintVersionTest.java:
> super( "[3.5.3-SNAPSHOT,3.5.4-SNAPSHOT]" );
> core-it-suite/src/test/java/org/apache/maven/it/MavenITmng6391PrintVersionTest.java:
> super( "[3.6.0-SNAPSHOT,)" );
> core-it-suite/src/test/java/org/apache/maven/it/MavenITmng6506PackageAnnotationTest.java:
> super( "[3.6.1-SNAPSHOT,)" );
> core-it-suite/src/test/java/org/apache/maven/it/MavenITmng6558ToolchainsBuildingEventTest.java:
> super( "[3.6.1-SNAPSHOT,)" );
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [maven-integration-testing] michael-o closed pull request #57: [MNG-6613] Avoid a connection to apache.org when this test runs.
michael-o closed pull request #57: [MNG-6613] Avoid a connection to apache.org when this test runs. URL: https://github.com/apache/maven-integration-testing/pull/57 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] (SUREFIRE-1339) Forked JVM hangs in FreeBSD when reuseForks=true
[
https://issues.apache.org/jira/browse/SUREFIRE-1339?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov closed SUREFIRE-1339.
Fix Version/s: (was: Backlog)
Resolution: Cannot Reproduce
This works now, I assume it was a faulty server back then. I have some other
failures, but they are probably not related:
{noformat}
[INFO]
[ERROR] Failures:
[ERROR] Surefire772BothReportsIT.testReportGeneration:58 Expecting failsafe
report file
[ERROR] Surefire772BothReportsIT.testSkippedSurefireReportGeneration:88
Expecting failsafe report file
[ERROR]
Surefire772NoSurefireReportsIT.testOptionalSurefireReportGeneration:75
Expecting failsafe report file
[ERROR] Surefire772NoSurefireReportsIT.testReportGeneration:49 Expecting
failsafe report file
[ERROR]
Surefire772NoSurefireReportsIT.testSkipOptionalSurefireReportGeneration:88
Expecting failsafe report file
[ERROR] Surefire772NoSurefireReportsIT.testSkippedSurefireReportGeneration:62
Expecting failsafe report file
[INFO]
[ERROR] Tests run: 926, Failures: 6, Errors: 0, Skipped: 157
{noformat}
> Forked JVM hangs in FreeBSD when reuseForks=true
>
>
> Key: SUREFIRE-1339
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1339
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Failsafe Plugin, Maven Surefire Plugin
> Environment: FreeBSD
>Reporter: Tibor Digana
>Assignee: Tibor Digana
>Priority: Major
>
> The event RUN_CLASS is not received by forked JVM after started.
> The events are received as soon as the JVM exited.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (MNG-6744) Some ITs test with SNAPSHOT versions
[
https://issues.apache.org/jira/browse/MNG-6744?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov closed MNG-6744.
---
Resolution: Fixed
Fixed with 9a8076f392ee817a91be914e08b332a578d51d0f.
> Some ITs test with SNAPSHOT versions
>
>
> Key: MNG-6744
> URL: https://issues.apache.org/jira/browse/MNG-6744
> Project: Maven
> Issue Type: Bug
> Components: Integration Tests
>Reporter: Michael Osipov
>Assignee: Michael Osipov
>Priority: Major
>
> These need to be fixed for a release version:
> {noformat}
> core-it-suite/src/test/java/org/apache/maven/it/MavenITmng3743ForkWithPluginManagementTest.java:
> super( "(2.0.8,3.1-SNAPSHOT)" ); // only test in 2.0.9+
> core-it-suite/src/test/java/org/apache/maven/it/MavenITmng5771CoreExtensionsTest.java:
> requiresMavenVersion( "[3.3.2-SNAPSHOT,)" );
> core-it-suite/src/test/java/org/apache/maven/it/MavenITmng5965ParallelBuildMultipliesWorkTest.java:
> super( "[3.6.1-SNAPSHOT,)" );
> core-it-suite/src/test/java/org/apache/maven/it/MavenITmng6352PrintVersionTest.java:
> super( "[3.5.3-SNAPSHOT,3.5.4-SNAPSHOT]" );
> core-it-suite/src/test/java/org/apache/maven/it/MavenITmng6391PrintVersionTest.java:
> super( "[3.6.0-SNAPSHOT,)" );
> core-it-suite/src/test/java/org/apache/maven/it/MavenITmng6506PackageAnnotationTest.java:
> super( "[3.6.1-SNAPSHOT,)" );
> core-it-suite/src/test/java/org/apache/maven/it/MavenITmng6558ToolchainsBuildingEventTest.java:
> super( "[3.6.1-SNAPSHOT,)" );
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MSHARED-872) Embedded3xLauncher cannot be initialized
[ https://issues.apache.org/jira/browse/MSHARED-872?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17075009#comment-17075009 ] Herve Boutemy commented on MSHARED-872: --- fixed in [ab29a9d823d09b8988b094e6cfb8d2909609fea8|https://gitbox.apache.org/repos/asf?p=maven-verifier.git=commit=ab29a9d823d09b8988b094e6cfb8d2909609fea8] > Embedded3xLauncher cannot be initialized > > > Key: MSHARED-872 > URL: https://issues.apache.org/jira/browse/MSHARED-872 > Project: Maven Shared Components > Issue Type: Bug > Components: maven-verifier >Affects Versions: maven-verifier-1.7.0 >Reporter: Robert Scholte >Assignee: Robert Scholte >Priority: Major > Fix For: maven-verifier-1.7.1 > > > [cc4d1cb0d20ba9c7e019c47790eec63106775424|https://gitbox.apache.org/repos/asf?p=maven-verifier.git;a=commit;h=cc4d1cb0d20ba9c7e019c47790eec63106775424] > introduced a bug: by casting the null-value, it is considered as an > argument, whereas null is not. > The nulls shouldn't be here, since the method don't have arguments. -- This message was sent by Atlassian Jira (v8.3.4#803005)
