[jira] [Commented] (MNG-6735) ArtifactUtils#toSnapshotVersion problem with pinned snapshots
[
https://issues.apache.org/jira/browse/MNG-6735?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16908723#comment-16908723
]
Michael Osipov commented on MNG-6735:
-
First of all, why do you rely on snapshots? The general concept of snapshot
versions are that you can replace one with each other with the same base
version where as release cannot. Regardless of this, it maybe by design what
you observe or just a subtile bug.
> ArtifactUtils#toSnapshotVersion problem with pinned snapshots
> -
>
> Key: MNG-6735
> URL: https://issues.apache.org/jira/browse/MNG-6735
> Project: Maven
> Issue Type: Bug
> Components: Artifacts and Repositories
>Affects Versions: 3.6.1
>Reporter: Laird Nelson
>Priority: Major
>
> I apologize in advance for the vagueness.
> In {{ArtifactUtils}}, there is a method named {{toSnapshotVersion(String)}}.
> I am using a project whose released version depends on a pinned snapshot:
> [https://github.com/jbosstm/narayana/blob/a66d5bd3ebfa96ab7e4142f28960a99b941a30e7/rts/lra/pom.xml#L29]
> This works fine for things like unit tests and so on.
> For various reasons, some of which are good and some of which are bad, we
> need to copy this pinned snapshot using the Maven dependency plugin's
> {{copy-dependencies}} goal. We construct a prefixed classpath entry in a jar
> file's manifest that refers to this pinned snapshot version.
> When we do so, we discover that although this project depends on a pinned
> snapshot, and although the Maven shared archiver constructs the manifest
> {{Class-Path:}} entry properly, i.e. referring to the pinned version, not
> anything ending in {{-SNAPSHOT}}, the {{copy-dependencies}} goal seems to
> infer that the pinned version is in fact a snapshot version, and so when the
> jar file is copied it ends up with a suffix of {{-SNAPSHOT}}. The end result
> is that although the {{Class-Path:}} header is correct, no such pinned
> snapshot version jar file exists. Instead, a jar file with {{-SNAPSHOT}} as
> a suffix is there instead, and we get classloading errors.
> I've traced the problem to {{ArtifactUtils}} where its
> {{toSnapshotVersion(String)}} method appears to recognize this pinned version
> string as a snapshot, and "helpfully" erases it, turning the resulting jar
> file back into a {{-SNAPSHOT}} suffixed jar file.
> I don't see any workaround to this problem. Is there a reason for this
> helpful behavior?
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Commented] (MNG-6735) ArtifactUtils#toSnapshotVersion problem with pinned snapshots
[
https://issues.apache.org/jira/browse/MNG-6735?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16908697#comment-16908697
]
Laird Nelson commented on MNG-6735:
---
After some more research, I see that this may be the very problem that the
inscrutably named {{useBaseVersion}} parameter was invented to solve. I find
that when I set this to {{false}}, the issues go away. I'm not sure what "base
version" is, and if I had to guess based on the English, I would have thought
that given a pinned snapshot version, then I would want that version to be
used, so intuitively I'd expect that {{useBaseVersion}} should be set to
{{true}}. But it appears that I have this exactly backwards!
> ArtifactUtils#toSnapshotVersion problem with pinned snapshots
> -
>
> Key: MNG-6735
> URL: https://issues.apache.org/jira/browse/MNG-6735
> Project: Maven
> Issue Type: Bug
> Components: Artifacts and Repositories
>Affects Versions: 3.6.1
>Reporter: Laird Nelson
>Priority: Major
>
> I apologize in advance for the vagueness.
> In {{ArtifactUtils}}, there is a method named {{toSnapshotVersion(String)}}.
> I am using a project whose released version depends on a pinned snapshot:
> [https://github.com/jbosstm/narayana/blob/a66d5bd3ebfa96ab7e4142f28960a99b941a30e7/rts/lra/pom.xml#L29]
> This works fine for things like unit tests and so on.
> For various reasons, some of which are good and some of which are bad, we
> need to copy this pinned snapshot using the Maven dependency plugin's
> {{copy-dependencies}} goal. We construct a prefixed classpath entry in a jar
> file's manifest that refers to this pinned snapshot version.
> When we do so, we discover that although this project depends on a pinned
> snapshot, and although the Maven shared archiver constructs the manifest
> {{Class-Path:}} entry properly, i.e. referring to the pinned version, not
> anything ending in {{-SNAPSHOT}}, the {{copy-dependencies}} goal seems to
> infer that the pinned version is in fact a snapshot version, and so when the
> jar file is copied it ends up with a suffix of {{-SNAPSHOT}}. The end result
> is that although the {{Class-Path:}} header is correct, no such pinned
> snapshot version jar file exists. Instead, a jar file with {{-SNAPSHOT}} as
> a suffix is there instead, and we get classloading errors.
> I've traced the problem to {{ArtifactUtils}} where its
> {{toSnapshotVersion(String)}} method appears to recognize this pinned version
> string as a snapshot, and "helpfully" erases it, turning the resulting jar
> file back into a {{-SNAPSHOT}} suffixed jar file.
> I don't see any workaround to this problem. Is there a reason for this
> helpful behavior?
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Created] (MNG-6735) ArtifactUtils#toSnapshotVersion problem with pinned snapshots
Laird Nelson created MNG-6735:
-
Summary: ArtifactUtils#toSnapshotVersion problem with pinned
snapshots
Key: MNG-6735
URL: https://issues.apache.org/jira/browse/MNG-6735
Project: Maven
Issue Type: Bug
Components: Artifacts and Repositories
Affects Versions: 3.6.1
Reporter: Laird Nelson
I apologize in advance for the vagueness.
In {{ArtifactUtils}}, there is a method named {{toSnapshotVersion(String)}}.
I am using a project whose released version depends on a pinned snapshot:
[https://github.com/jbosstm/narayana/blob/a66d5bd3ebfa96ab7e4142f28960a99b941a30e7/rts/lra/pom.xml#L29]
This works fine for things like unit tests and so on.
For various reasons, some of which are good and some of which are bad, we need
to copy this pinned snapshot using the Maven dependency plugin's
{{copy-dependencies}} goal. We construct a prefixed classpath entry in a jar
file's manifest that refers to this pinned snapshot version.
When we do so, we discover that although this project depends on a pinned
snapshot, and although the Maven shared archiver constructs the manifest
{{Class-Path:}} entry properly, i.e. referring to the pinned version, not
anything ending in {{-SNAPSHOT}}, the {{copy-dependencies}} goal seems to infer
that the pinned version is in fact a snapshot version, and so when the jar file
is copied it ends up with a suffix of {{-SNAPSHOT}}. The end result is that
although the {{Class-Path:}} header is correct, no such pinned snapshot version
jar file exists. Instead, a jar file with {{-SNAPSHOT}} as a suffix is there
instead, and we get classloading errors.
I've traced the problem to {{ArtifactUtils}} where its
{{toSnapshotVersion(String)}} method appears to recognize this pinned version
string as a snapshot, and "helpfully" erases it, turning the resulting jar file
back into a {{-SNAPSHOT}} suffixed jar file.
I don't see any workaround to this problem. Is there a reason for this helpful
behavior?
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Updated] (MINSTALL-160) generatePom=true with 3.0.0-M1 does not generate minimal POM but copies existing one
[
https://issues.apache.org/jira/browse/MINSTALL-160?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Václav Haisman updated MINSTALL-160:
Issue Type: Bug (was: Wish)
> generatePom=true with 3.0.0-M1 does not generate minimal POM but copies
> existing one
>
>
> Key: MINSTALL-160
> URL: https://issues.apache.org/jira/browse/MINSTALL-160
> Project: Maven Install Plugin
> Issue Type: Bug
> Components: install:install-file
>Affects Versions: 3.0.0-M1
>Reporter: Václav Haisman
>Priority: Major
>
> I am using install:install-file with generatePom=true to install JAR with
> minimal POM file. This has stopped working with 3.0.0-M1. With 3.0.0-M1, it
> copeis existing project pom.xml instead of generating a minimal one.
>
> This is easily reproducible with minimal project:
> {code:java}
>
> http://maven.apache.org/POM/4.0.0;
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
> xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
> http://maven.apache.org/xsd/maven-4.0.0.xsd;>
> 4.0.0
> maven.install.plugin.issue
> maven.install.plugin.issue
> 1.0-SNAPSHOT
> jar
> maven.install.plugin.issue
>
> 1.6
> 1.6
>
>
>
>
>
> maven-install-plugin
>
> 3.0.0-M1
>
>
>
>
>
>
> maven-install-plugin
>
>
> default-install
> none
> install
>
>
> custom-install
> install
>
> install-file
>
>
>
> ${project.build.directory}/${project.artifactId}-${project.version}.${project.packaging}
> true
>
>
>
>
>
>
>
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Updated] (MPLUGINTESTING-62) use maven API 3.6.0 and Plexus 2.0.0
[ https://issues.apache.org/jira/browse/MPLUGINTESTING-62?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Samael Bate updated MPLUGINTESTING-62: -- Description: Along with updating to use Java 7 (MPLUGINTESTING-61) the plugin should use a recent maven API. As there is no 3.6.0 for maven-aether-provider it will need be set to 3.3.9 was:To get this plugin working well with more recent versions of Maven (and Java) it makes sense to do this and MPLUGINTESTING-61 > use maven API 3.6.0 and Plexus 2.0.0 > > > Key: MPLUGINTESTING-62 > URL: https://issues.apache.org/jira/browse/MPLUGINTESTING-62 > Project: Maven Plugin Testing > Issue Type: Improvement >Reporter: Samael Bate >Priority: Major > > Along with updating to use Java 7 (MPLUGINTESTING-61) the plugin should use a > recent maven API. > As there is no 3.6.0 for maven-aether-provider it will need be set to 3.3.9 -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Updated] (MPLUGINTESTING-62) use maven API 3.6.0 and Plexus 2.0.0
[ https://issues.apache.org/jira/browse/MPLUGINTESTING-62?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Samael Bate updated MPLUGINTESTING-62: -- Summary: use maven API 3.6.0 and Plexus 2.0.0 (was: target maven 3.6.0 API) > use maven API 3.6.0 and Plexus 2.0.0 > > > Key: MPLUGINTESTING-62 > URL: https://issues.apache.org/jira/browse/MPLUGINTESTING-62 > Project: Maven Plugin Testing > Issue Type: Improvement >Reporter: Samael Bate >Priority: Major > > To get this plugin working well with more recent versions of Maven (and Java) > it makes sense to do this and MPLUGINTESTING-61 -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[GitHub] [maven-shade-plugin] rmannibucau closed pull request #23: [MSHADE-322] adding properties transformer
rmannibucau closed pull request #23: [MSHADE-322] adding properties transformer URL: https://github.com/apache/maven-shade-plugin/pull/23 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-shade-plugin] rmannibucau closed pull request #24: [MSHADE-322] - fixing windows tests
rmannibucau closed pull request #24: [MSHADE-322] - fixing windows tests URL: https://github.com/apache/maven-shade-plugin/pull/24 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-shade-plugin] Tibor17 edited a comment on issue #24: [MSHADE-322] - fixing windows tests
Tibor17 edited a comment on issue #24: [MSHADE-322] - fixing windows tests URL: https://github.com/apache/maven-shade-plugin/pull/24#issuecomment-521769609 @rmannibucau @eolivelli This has to be closed because the change was squashed to another commit in master. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [maven-shade-plugin] Tibor17 commented on issue #24: [MSHADE-322] - fixing windows tests
Tibor17 commented on issue #24: [MSHADE-322] - fixing windows tests URL: https://github.com/apache/maven-shade-plugin/pull/24#issuecomment-521769609 @rmannibucau @eolivelli This has to be closed because the change was squashed with another commit in master. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Commented] (MSITE-849) Unable to inject MavenProject when using `mvn site:run`
[
https://issues.apache.org/jira/browse/MSITE-849?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16908427#comment-16908427
]
Abel Salgado Romero commented on MSITE-849:
---
Anything I can do to help let me know.
> Unable to inject MavenProject when using `mvn site:run`
> ---
>
> Key: MSITE-849
> URL: https://issues.apache.org/jira/browse/MSITE-849
> Project: Maven Site Plugin
> Issue Type: New Feature
>Affects Versions: 3.7.1, 3.8.2
>Reporter: Abel Salgado Romero
>Assignee: Michael Osipov
>Priority: Major
>
> In https://github.com/asciidoctor/asciidoctor-maven-plugin we inject a
> MavenProject to obtain addition configurations from the pom.xml
> (https://github.com/asciidoctor/asciidoctor-maven-plugin/blob/a4d86a949643ab68c124fd4c1b9b936412637d93/src/main/java/org/asciidoctor/maven/site/AsciidoctorDoxiaParser.java#L54).
> This works fine with {{site:site}}, but when using {{site:run}} and accessing
> one of the Asciidoc generated pages we get the error below.
> I saw that:
> * The error occurs when trying to retrieve the instance of the MavenProject.
> * Behavior is the same if I directly inject the MavenProject instead of using
> a provider. That is, {{site:site}} works, {{site:run}} fails because it
> cannot find the instance.
> {code:java}
> HTTP ERROR 500
> Problem accessing /hello.html. Reason:
> Server Error
> Caused by:
> com.google.inject.ProvisionException: Unable to provision, see the following
> errors:
> 1) Error in custom provider, com.google.inject.OutOfScopeException: Cannot
> access Key[type=org.apache.maven.project.MavenProject, annotation=[none]]
> outside of a scoping block
> at
> org.apache.maven.execution.scope.internal.MojoExecutionScopeModule.configure(MojoExecutionScopeModule.java:55)
> (via modules: org.eclipse.sisu.wire.WireModule ->
> org.apache.maven.execution.scope.internal.MojoExecutionScopeModule)
> while locating org.apache.maven.project.MavenProject
> 1 error
> at
> com.google.inject.internal.InternalProvisionException.toProvisionException(InternalProvisionException.java:226)
> at com.google.inject.internal.InjectorImpl$1.get(InjectorImpl.java:1053)
> at
> org.asciidoctor.maven.site.AsciidoctorDoxiaParser.parse(AsciidoctorDoxiaParser.java:78)
> at org.apache.maven.doxia.DefaultDoxia.parse(DefaultDoxia.java:65)
> {code}
> * How to reproduce:
> # clone https://github.com/asciidoctor/asciidoctor-maven-examples
> # cd asciidoc-maven-site-example
> # mvn site:run
> # Access {{http://localhost:8080/hello.html}}
> * Env:
> {code}
> $ mvn -v
> Apache Maven 3.6.1 (d66c9c0b3152b2e69ee9bac180bb8fcc8e6af555;
> 2019-04-04T21:00:29+02:00)
> Maven home: /home//.sdkman/candidates/maven/current
> Java version: 1.8.0_222, vendor: AdoptOpenJDK, runtime:
> /home/-/.sdkman/candidates/java/8.0.222.hs-adpt/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "linux", version: "5.1.21-1-manjaro", arch: "amd64", family: "unix
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Commented] (MSITE-849) Unable to inject MavenProject when using `mvn site:run`
[
https://issues.apache.org/jira/browse/MSITE-849?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16908418#comment-16908418
]
Michael Osipov commented on MSITE-849:
--
That's an interesting one. I need to see whether I can have a look at this
tomorrow or next week.
> Unable to inject MavenProject when using `mvn site:run`
> ---
>
> Key: MSITE-849
> URL: https://issues.apache.org/jira/browse/MSITE-849
> Project: Maven Site Plugin
> Issue Type: New Feature
>Affects Versions: 3.7.1, 3.8.2
>Reporter: Abel Salgado Romero
>Priority: Major
>
> In https://github.com/asciidoctor/asciidoctor-maven-plugin we inject a
> MavenProject to obtain addition configurations from the pom.xml
> (https://github.com/asciidoctor/asciidoctor-maven-plugin/blob/a4d86a949643ab68c124fd4c1b9b936412637d93/src/main/java/org/asciidoctor/maven/site/AsciidoctorDoxiaParser.java#L54).
> This works fine with {{site:site}}, but when using {{site:run}} and accessing
> one of the Asciidoc generated pages we get the error below.
> I saw that:
> * The error occurs when trying to retrieve the instance of the MavenProject.
> * Behavior is the same if I directly inject the MavenProject instead of using
> a provider. That is, {{site:site}} works, {{site:run}} fails because it
> cannot find the instance.
> {code:java}
> HTTP ERROR 500
> Problem accessing /hello.html. Reason:
> Server Error
> Caused by:
> com.google.inject.ProvisionException: Unable to provision, see the following
> errors:
> 1) Error in custom provider, com.google.inject.OutOfScopeException: Cannot
> access Key[type=org.apache.maven.project.MavenProject, annotation=[none]]
> outside of a scoping block
> at
> org.apache.maven.execution.scope.internal.MojoExecutionScopeModule.configure(MojoExecutionScopeModule.java:55)
> (via modules: org.eclipse.sisu.wire.WireModule ->
> org.apache.maven.execution.scope.internal.MojoExecutionScopeModule)
> while locating org.apache.maven.project.MavenProject
> 1 error
> at
> com.google.inject.internal.InternalProvisionException.toProvisionException(InternalProvisionException.java:226)
> at com.google.inject.internal.InjectorImpl$1.get(InjectorImpl.java:1053)
> at
> org.asciidoctor.maven.site.AsciidoctorDoxiaParser.parse(AsciidoctorDoxiaParser.java:78)
> at org.apache.maven.doxia.DefaultDoxia.parse(DefaultDoxia.java:65)
> {code}
> * How to reproduce:
> # clone https://github.com/asciidoctor/asciidoctor-maven-examples
> # cd asciidoc-maven-site-example
> # mvn site:run
> # Access {{http://localhost:8080/hello.html}}
> * Env:
> {code}
> $ mvn -v
> Apache Maven 3.6.1 (d66c9c0b3152b2e69ee9bac180bb8fcc8e6af555;
> 2019-04-04T21:00:29+02:00)
> Maven home: /home//.sdkman/candidates/maven/current
> Java version: 1.8.0_222, vendor: AdoptOpenJDK, runtime:
> /home/-/.sdkman/candidates/java/8.0.222.hs-adpt/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "linux", version: "5.1.21-1-manjaro", arch: "amd64", family: "unix
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Assigned] (MSITE-849) Unable to inject MavenProject when using `mvn site:run`
[
https://issues.apache.org/jira/browse/MSITE-849?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov reassigned MSITE-849:
Assignee: Michael Osipov
> Unable to inject MavenProject when using `mvn site:run`
> ---
>
> Key: MSITE-849
> URL: https://issues.apache.org/jira/browse/MSITE-849
> Project: Maven Site Plugin
> Issue Type: New Feature
>Affects Versions: 3.7.1, 3.8.2
>Reporter: Abel Salgado Romero
>Assignee: Michael Osipov
>Priority: Major
>
> In https://github.com/asciidoctor/asciidoctor-maven-plugin we inject a
> MavenProject to obtain addition configurations from the pom.xml
> (https://github.com/asciidoctor/asciidoctor-maven-plugin/blob/a4d86a949643ab68c124fd4c1b9b936412637d93/src/main/java/org/asciidoctor/maven/site/AsciidoctorDoxiaParser.java#L54).
> This works fine with {{site:site}}, but when using {{site:run}} and accessing
> one of the Asciidoc generated pages we get the error below.
> I saw that:
> * The error occurs when trying to retrieve the instance of the MavenProject.
> * Behavior is the same if I directly inject the MavenProject instead of using
> a provider. That is, {{site:site}} works, {{site:run}} fails because it
> cannot find the instance.
> {code:java}
> HTTP ERROR 500
> Problem accessing /hello.html. Reason:
> Server Error
> Caused by:
> com.google.inject.ProvisionException: Unable to provision, see the following
> errors:
> 1) Error in custom provider, com.google.inject.OutOfScopeException: Cannot
> access Key[type=org.apache.maven.project.MavenProject, annotation=[none]]
> outside of a scoping block
> at
> org.apache.maven.execution.scope.internal.MojoExecutionScopeModule.configure(MojoExecutionScopeModule.java:55)
> (via modules: org.eclipse.sisu.wire.WireModule ->
> org.apache.maven.execution.scope.internal.MojoExecutionScopeModule)
> while locating org.apache.maven.project.MavenProject
> 1 error
> at
> com.google.inject.internal.InternalProvisionException.toProvisionException(InternalProvisionException.java:226)
> at com.google.inject.internal.InjectorImpl$1.get(InjectorImpl.java:1053)
> at
> org.asciidoctor.maven.site.AsciidoctorDoxiaParser.parse(AsciidoctorDoxiaParser.java:78)
> at org.apache.maven.doxia.DefaultDoxia.parse(DefaultDoxia.java:65)
> {code}
> * How to reproduce:
> # clone https://github.com/asciidoctor/asciidoctor-maven-examples
> # cd asciidoc-maven-site-example
> # mvn site:run
> # Access {{http://localhost:8080/hello.html}}
> * Env:
> {code}
> $ mvn -v
> Apache Maven 3.6.1 (d66c9c0b3152b2e69ee9bac180bb8fcc8e6af555;
> 2019-04-04T21:00:29+02:00)
> Maven home: /home//.sdkman/candidates/maven/current
> Java version: 1.8.0_222, vendor: AdoptOpenJDK, runtime:
> /home/-/.sdkman/candidates/java/8.0.222.hs-adpt/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "linux", version: "5.1.21-1-manjaro", arch: "amd64", family: "unix
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Commented] (MNG-6731) Jetty getLocalPort() returns -1 resulting in build failures
[
https://issues.apache.org/jira/browse/MNG-6731?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16908416#comment-16908416
]
Robert Scholte commented on MNG-6731:
-
I removed the {{fix for versions}}. The release notes should reflect the
changes to Maven (Core)
> Jetty getLocalPort() returns -1 resulting in build failures
> ---
>
> Key: MNG-6731
> URL: https://issues.apache.org/jira/browse/MNG-6731
> Project: Maven
> Issue Type: Bug
> Components: Integration Tests
>Reporter: Tibor Digana
>Assignee: Tibor Digana
>Priority: Major
> Time Spent: 20m
> Remaining Estimate: 0h
>
> We observed sporadic errors [1] fir the project {{core-its}} on Jenkins.
> So I started haveing a look and I say the JavaDoc of the method
> {{getlocalPort}} saying that {{-1}} is returned if the connector is not open.
> So I decided to use [2] and wait until the server is up. This was of course
> wrong because the status of the server is set to {{STARTED}} immediatelly
> after the method {{Server.start()}}. So therefore I was googling a little bit
> and I found that Hadoop [3] had this problem too in 2010. Whole problem was
> with a bug in Jetty server which is {{race condition}}. The article has a
> link to Jetty's Jira with reported bug {{JETTY-748}}. According to the
> annoucements [4] from Eclipse/Jetty, the bug "{{JETTY-748 Prevent race close
> of socket by old acceptor threads}}" was fixed in the version
> {{jetty-7.2.1.v2010}}. So I decided to use that version but I found that
> the class {{HashUserRealm}} was deleted and there is no support and no
> further development of {{org.mortbay}}. Eclipse continues with the
> development of Jerry 9.
> All I did in this issue was to rewrite 38 integration tests to Jetty 9 API
> and the fix for {{JETTY-748}} is right there.
> [1]:
> Error message in logs: [WARNING] Could not transfer metadata
> org.apache.maven.its.mng4554/maven-metadata.xml from/to central
> (http://localhost:-1/repo-1): Connect to localhost:80 [localhost/127.0.0.1,
> localhost/0:0:0:0:0:0:0:1] failed: Connection refused: connect
> [2]:
> {code:java}
> while ( !server.isRunning() || !server.isStarted() )
> {
> if ( server.isFailed() )
> {
> fail( "Couldn't bind the server socket to a free port!" );
> }
> Thread.sleep( 100L );
> }
> {code}
> [3]:
> https://www.bountysource.com/issues/987313-jetty-returns-1-resulting-in-hadoop-masters-slaves-to-fail-during-startup
> [4]:
> https://www.eclipse.org/lists/jetty-dev/msg00537.html
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Updated] (MNG-6731) Jetty getLocalPort() returns -1 resulting in build failures
[
https://issues.apache.org/jira/browse/MNG-6731?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte updated MNG-6731:
Fix Version/s: (was: 3.6.2)
(was: 3.6.x-candidate)
> Jetty getLocalPort() returns -1 resulting in build failures
> ---
>
> Key: MNG-6731
> URL: https://issues.apache.org/jira/browse/MNG-6731
> Project: Maven
> Issue Type: Bug
> Components: Integration Tests
>Reporter: Tibor Digana
>Assignee: Tibor Digana
>Priority: Major
> Time Spent: 20m
> Remaining Estimate: 0h
>
> We observed sporadic errors [1] fir the project {{core-its}} on Jenkins.
> So I started haveing a look and I say the JavaDoc of the method
> {{getlocalPort}} saying that {{-1}} is returned if the connector is not open.
> So I decided to use [2] and wait until the server is up. This was of course
> wrong because the status of the server is set to {{STARTED}} immediatelly
> after the method {{Server.start()}}. So therefore I was googling a little bit
> and I found that Hadoop [3] had this problem too in 2010. Whole problem was
> with a bug in Jetty server which is {{race condition}}. The article has a
> link to Jetty's Jira with reported bug {{JETTY-748}}. According to the
> annoucements [4] from Eclipse/Jetty, the bug "{{JETTY-748 Prevent race close
> of socket by old acceptor threads}}" was fixed in the version
> {{jetty-7.2.1.v2010}}. So I decided to use that version but I found that
> the class {{HashUserRealm}} was deleted and there is no support and no
> further development of {{org.mortbay}}. Eclipse continues with the
> development of Jerry 9.
> All I did in this issue was to rewrite 38 integration tests to Jetty 9 API
> and the fix for {{JETTY-748}} is right there.
> [1]:
> Error message in logs: [WARNING] Could not transfer metadata
> org.apache.maven.its.mng4554/maven-metadata.xml from/to central
> (http://localhost:-1/repo-1): Connect to localhost:80 [localhost/127.0.0.1,
> localhost/0:0:0:0:0:0:0:1] failed: Connection refused: connect
> [2]:
> {code:java}
> while ( !server.isRunning() || !server.isStarted() )
> {
> if ( server.isFailed() )
> {
> fail( "Couldn't bind the server socket to a free port!" );
> }
> Thread.sleep( 100L );
> }
> {code}
> [3]:
> https://www.bountysource.com/issues/987313-jetty-returns-1-resulting-in-hadoop-masters-slaves-to-fail-during-startup
> [4]:
> https://www.eclipse.org/lists/jetty-dev/msg00537.html
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[GitHub] [maven-plugin-testing] rfscholte commented on issue #8: MPLUGINTESTING-61 MPLUGINTESTING-62 target JDK 7 and maven 3.6.0
rfscholte commented on issue #8: MPLUGINTESTING-61 MPLUGINTESTING-62 target JDK 7 and maven 3.6.0 URL: https://github.com/apache/maven-plugin-testing/pull/8#issuecomment-521756916 For this PR I don't see the need for changing the Maven version, it should be picked up by the direct as direct dependency of the plugin you're testing. Bumping `java.version` + some other dependencies is good enough. Add that list to jira and adjust the title, because that's what we use for the release notes. 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-plugin-testing] rfscholte commented on issue #4: Added support for plugins without configuration.
rfscholte commented on issue #4: Added support for plugins without configuration. URL: https://github.com/apache/maven-plugin-testing/pull/4#issuecomment-521754941 @SingingBush the list is long... However, nobody really answered my question. Just a thought: the idea of providing a pom is to provide a configured plugin, otherwise you can do a standard lookup, which is more efficient. This ensures you're using only defaults. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Commented] (MNG-6734) Ability to add Java sources to plugins classpath from .mvn directory
[ https://issues.apache.org/jira/browse/MNG-6734?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16908402#comment-16908402 ] Abel Salgado Romero commented on MNG-6734: -- The requirement could be rephrased indeed, the main idea is to be able to inject classes without needing additional modules like in the example: https://github.com/asciidoctor/asciidoctor-maven-examples/blob/f9580a7b22d015ce3f973099091f73802e867b3f/java-extension-example/asciidoctor-with-extension-example/pom.xml#L39. I understand you mean that a project could have something like a gradle "sourceSet" that is not included in the artifact but can be used by a plugin during it's execution, is that so? If so, it would fit perfectly the need. > Ability to add Java sources to plugins classpath from .mvn directory > > > Key: MNG-6734 > URL: https://issues.apache.org/jira/browse/MNG-6734 > Project: Maven > Issue Type: New Feature > Components: core >Reporter: Abel Salgado Romero >Priority: Minor > > In plugins like > [asciidoctor-maven-plugin|https://github.com/asciidoctor/asciidoctor-maven-plugin] > it is possible to add Java Asciidoctor extensions and other customizations > to the conversion process. > These need to be available to the asciidoctor-maven-plugin classpath and due > to how maven manages plugin's dependencies, this means that users need to > publish these extension in a maven repo or create multi-module projects like > in this example > https://github.com/asciidoctor/asciidoctor-maven-examples/tree/master/java-extension-example. > This is cumbersome and a bit of overkill when some users just want to add a > single class. > So, I wonder if would make sense to be able to add Java sources in the ".mvn" > directory that are compiled and added to the classpath so that maven plugins > can use them. > Ideally, to avoid classpath issues, I'd like to be able to tell which plugins > use the code, maybe with an XML descriptor or some directory convention. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[GitHub] [maven-surefire] Tibor17 commented on issue #244: [SUREFIRE-1679] Prevent classpath caching from causing pollution
Tibor17 commented on issue #244: [SUREFIRE-1679] Prevent classpath caching from causing pollution URL: https://github.com/apache/maven-surefire/pull/244#issuecomment-521745794 LGTM 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] (MPLUGINTESTING-64) broken links on website
Samael Bate created MPLUGINTESTING-64: - Summary: broken links on website Key: MPLUGINTESTING-64 URL: https://issues.apache.org/jira/browse/MPLUGINTESTING-64 Project: Maven Plugin Testing Issue Type: Task Reporter: Samael Bate Some links on [https://maven.apache.org/plugin-testing/maven-plugin-testing-harness/] are invalid. On the [https://maven.apache.org/plugin-testing/maven-plugin-testing-harness/source-repository.html] page the github url is [https://github.com/apache/maven-plugin-testing/maven-plugin-testing-harness/] but it should simply be [https://github.com/apache/maven-plugin-testing/] Also on the [https://maven.apache.org/plugin-testing/maven-plugin-testing-harness/issue-tracking.html] page it has a link to [http://jira.codehaus.org/browse/MPLUGINTESTING] which is wrong as it should point to this Jira -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[GitHub] [maven] suztomo commented on issue #277: [MNG-6732] - DefaultArtifactDescriptorReader.loadPom to check IGNORE_MISSING policy upon ArtifactTransferException
suztomo commented on issue #277: [MNG-6732] - DefaultArtifactDescriptorReader.loadPom to check IGNORE_MISSING policy upon ArtifactTransferException URL: https://github.com/apache/maven/pull/277#issuecomment-521734958 @eolivelli Thank you for question. > Isn't ArtifactTransferException a temporary failure? [ArtifactTransferException](https://maven.apache.org/resolver/apidocs/org/eclipse/aether/transfer/ArtifactTransferException.html) does not specify that. ArtifactTransferException can be a permanent failure from a retired repository (such as http://repository.codehaus.org/ ) as well as a temporary repository failure. > Will this change add unpredictable behavior to builds? No, it does not add unpredictable behavior (as far as I know). Thinking of two cases: - When all Maven repositories involved are alive No error. No unpredictable behavior. - When a Maven repository is temporarily down 1. `DefaultRepositorySystem.collectDependencies` builds a partial dependency graph, rather than failing here (new behavior). 1. The dependency graph is transformed via Maven's dependency mediation (no change) In [my example](https://github.com/suztomo/maven-missing-artifact), `artifact-to-be-removed:1.0` is removed from graph in favor of `artifact-to-be-removed:2.0`. 1. `DefaultRepositorySystem.resolveDependencies` tries to resolve dependencies. (no change) **Maven fails** to resolve dependencies if the graph contains an artifact hosted in the temporarily-down repository. **Maven succeeds** if the graph does not contain missing artifact, resulting in the same graph as the case of "When a live repository is alive" 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-plugin-testing] SingingBush commented on issue #4: Added support for plugins without configuration.
SingingBush commented on issue #4: Added support for plugins without configuration. URL: https://github.com/apache/maven-plugin-testing/pull/4#issuecomment-521730874 Is there a reason this isn't being merged? vadeg is right, configuration is optional 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-plugin-testing] SingingBush commented on issue #8: MPLUGINTESTING-61 MPLUGINTESTING-62 target JDK 7 and maven 3.6.0
SingingBush commented on issue #8: MPLUGINTESTING-61 MPLUGINTESTING-62 target JDK 7 and maven 3.6.0 URL: https://github.com/apache/maven-plugin-testing/pull/8#issuecomment-521729580 the other changes I was looking at doing will be a seperate PR linked to [MPLUGINTESTING-63](https://issues.apache.org/jira/browse/MPLUGINTESTING-63). Is anything else required for this PR? Can it be merged? 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] Tibor17 edited a comment on issue #46: [MNG-6731] Jetty getLocalPort() returns -1 resulting in build failures
Tibor17 edited a comment on issue #46: [MNG-6731] Jetty getLocalPort() returns -1 resulting in build failures URL: https://github.com/apache/maven-integration-testing/pull/46#issuecomment-521707874 @joakime The best idea would be to have a new PR with commits for each problem separately. Would you do that please? This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Updated] (MSITE-849) Unable to inject MavenProject when using `mvn site:run`
[
https://issues.apache.org/jira/browse/MSITE-849?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Abel Salgado Romero updated MSITE-849:
--
Description:
In https://github.com/asciidoctor/asciidoctor-maven-plugin we inject a
MavenProject to obtain addition configurations from the pom.xml
(https://github.com/asciidoctor/asciidoctor-maven-plugin/blob/a4d86a949643ab68c124fd4c1b9b936412637d93/src/main/java/org/asciidoctor/maven/site/AsciidoctorDoxiaParser.java#L54).
This works fine with {{site:site}}, but when using {{site:run}} and accessing
one of the Asciidoc generated pages we get the error below.
I saw that:
* The error occurs when trying to retrieve the instance of the MavenProject.
* Behavior is the same if I directly inject the MavenProject instead of using a
provider. That is, {{site:site}} works, {{site:run}} fails because it cannot
find the instance.
{code:java}
HTTP ERROR 500
Problem accessing /hello.html. Reason:
Server Error
Caused by:
com.google.inject.ProvisionException: Unable to provision, see the following
errors:
1) Error in custom provider, com.google.inject.OutOfScopeException: Cannot
access Key[type=org.apache.maven.project.MavenProject, annotation=[none]]
outside of a scoping block
at
org.apache.maven.execution.scope.internal.MojoExecutionScopeModule.configure(MojoExecutionScopeModule.java:55)
(via modules: org.eclipse.sisu.wire.WireModule ->
org.apache.maven.execution.scope.internal.MojoExecutionScopeModule)
while locating org.apache.maven.project.MavenProject
1 error
at
com.google.inject.internal.InternalProvisionException.toProvisionException(InternalProvisionException.java:226)
at com.google.inject.internal.InjectorImpl$1.get(InjectorImpl.java:1053)
at
org.asciidoctor.maven.site.AsciidoctorDoxiaParser.parse(AsciidoctorDoxiaParser.java:78)
at org.apache.maven.doxia.DefaultDoxia.parse(DefaultDoxia.java:65)
{code}
* How to reproduce:
# clone https://github.com/asciidoctor/asciidoctor-maven-examples
# cd asciidoc-maven-site-example
# mvn site:run
# Access {{http://localhost:8080/hello.html}}
* Env:
{code}
$ mvn -v
Apache Maven 3.6.1 (d66c9c0b3152b2e69ee9bac180bb8fcc8e6af555;
2019-04-04T21:00:29+02:00)
Maven home: /home//.sdkman/candidates/maven/current
Java version: 1.8.0_222, vendor: AdoptOpenJDK, runtime:
/home/-/.sdkman/candidates/java/8.0.222.hs-adpt/jre
Default locale: en_US, platform encoding: UTF-8
OS name: "linux", version: "5.1.21-1-manjaro", arch: "amd64", family: "unix
{code}
was:
In https://github.com/asciidoctor/asciidoctor-maven-plugin we inject a
MavenProject to obtain addition configurations from the pom.xml
(https://github.com/asciidoctor/asciidoctor-maven-plugin/blob/a4d86a949643ab68c124fd4c1b9b936412637d93/src/main/java/org/asciidoctor/maven/site/AsciidoctorDoxiaParser.java#L54).
This works fine with {{site:site}}, but when using {{site:run}} and accessing
one of the Asciidoc generated pages we get the error below.
I saw that:
* The error occurs when trying to retrieve the instance of the MavenProject.
* Behavior is the same if I directly inject the MavenProject instead of using a
provider. That is, {{site:site}} works, {{site:run}} fails because it cannot
find the instance.
{code:java}
HTTP ERROR 500
Problem accessing /hello.html. Reason:
Server Error
Caused by:
com.google.inject.ProvisionException: Unable to provision, see the following
errors:
1) Error in custom provider, com.google.inject.OutOfScopeException: Cannot
access Key[type=org.apache.maven.project.MavenProject, annotation=[none]]
outside of a scoping block
at
org.apache.maven.execution.scope.internal.MojoExecutionScopeModule.configure(MojoExecutionScopeModule.java:55)
(via modules: org.eclipse.sisu.wire.WireModule ->
org.apache.maven.execution.scope.internal.MojoExecutionScopeModule)
while locating org.apache.maven.project.MavenProject
1 error
at
com.google.inject.internal.InternalProvisionException.toProvisionException(InternalProvisionException.java:226)
at com.google.inject.internal.InjectorImpl$1.get(InjectorImpl.java:1053)
at
org.asciidoctor.maven.site.AsciidoctorDoxiaParser.parse(AsciidoctorDoxiaParser.java:78)
at org.apache.maven.doxia.DefaultDoxia.parse(DefaultDoxia.java:65)
{code}
* How to reproduce:
# clone https://github.com/asciidoctor/asciidoctor-maven-examples
# cd asciidoc-maven-site-example
# Access {{http://localhost:8080/hello.html}}
* Env:
{code}
$ mvn -v
Apache Maven 3.6.1 (d66c9c0b3152b2e69ee9bac180bb8fcc8e6af555;
2019-04-04T21:00:29+02:00)
Maven home: /home//.sdkman/candidates/maven/current
Java version: 1.8.0_222, vendor: AdoptOpenJDK, runtime:
/home/-/.sdkman/candidates/java/8.0.222.hs-adpt/jre
Default locale: en_US, platform encoding: UTF-8
OS name: "linux", version: "5.1.21-1-manjaro", arch: "amd64", family: "unix
{code}
> Unable to inject MavenProject
[jira] [Created] (MSITE-849) Unable to inject MavenProject when using `mvn site:run`
Abel Salgado Romero created MSITE-849:
-
Summary: Unable to inject MavenProject when using `mvn site:run`
Key: MSITE-849
URL: https://issues.apache.org/jira/browse/MSITE-849
Project: Maven Site Plugin
Issue Type: New Feature
Affects Versions: 3.8.2, 3.7.1
Reporter: Abel Salgado Romero
In https://github.com/asciidoctor/asciidoctor-maven-plugin we inject a
MavenProject to obtain addition configurations from the pom.xml
(https://github.com/asciidoctor/asciidoctor-maven-plugin/blob/a4d86a949643ab68c124fd4c1b9b936412637d93/src/main/java/org/asciidoctor/maven/site/AsciidoctorDoxiaParser.java#L54).
This works fine with {{site:site}}, but when using {{site:run}} and accessing
one of the Asciidoc generated pages we get the error below.
I saw that:
* The error occurs when trying to retrieve the instance of the MavenProject.
* Behavior is the same if I directly inject the MavenProject instead of using a
provider. That is, {{site:site}} works, {{site:run}} fails because it cannot
find the instance.
{code:java}
HTTP ERROR 500
Problem accessing /hello.html. Reason:
Server Error
Caused by:
com.google.inject.ProvisionException: Unable to provision, see the following
errors:
1) Error in custom provider, com.google.inject.OutOfScopeException: Cannot
access Key[type=org.apache.maven.project.MavenProject, annotation=[none]]
outside of a scoping block
at
org.apache.maven.execution.scope.internal.MojoExecutionScopeModule.configure(MojoExecutionScopeModule.java:55)
(via modules: org.eclipse.sisu.wire.WireModule ->
org.apache.maven.execution.scope.internal.MojoExecutionScopeModule)
while locating org.apache.maven.project.MavenProject
1 error
at
com.google.inject.internal.InternalProvisionException.toProvisionException(InternalProvisionException.java:226)
at com.google.inject.internal.InjectorImpl$1.get(InjectorImpl.java:1053)
at
org.asciidoctor.maven.site.AsciidoctorDoxiaParser.parse(AsciidoctorDoxiaParser.java:78)
at org.apache.maven.doxia.DefaultDoxia.parse(DefaultDoxia.java:65)
{code}
* How to reproduce:
# clone https://github.com/asciidoctor/asciidoctor-maven-examples
# cd asciidoc-maven-site-example
# Access {{http://localhost:8080/hello.html}}
* Env:
{code}
$ mvn -v
Apache Maven 3.6.1 (d66c9c0b3152b2e69ee9bac180bb8fcc8e6af555;
2019-04-04T21:00:29+02:00)
Maven home: /home//.sdkman/candidates/maven/current
Java version: 1.8.0_222, vendor: AdoptOpenJDK, runtime:
/home/-/.sdkman/candidates/java/8.0.222.hs-adpt/jre
Default locale: en_US, platform encoding: UTF-8
OS name: "linux", version: "5.1.21-1-manjaro", arch: "amd64", family: "unix
{code}
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Commented] (MNG-6734) Ability to add Java sources to plugins classpath from .mvn directory
[
https://issues.apache.org/jira/browse/MNG-6734?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16908287#comment-16908287
]
Robert Scholte commented on MNG-6734:
-
I think the title needs to be rephrased, because it is not about sources being
added to the classpath, but some unrelated classes. There are more usecases
where one want to build extra code as part of project.
One of the ideas I have is to allow in {{jar}} and other packaging
projects. These modules won't the distributed (can't install or deploy), but
are there to help the module. It seems like this issue would fit here as well.
> Ability to add Java sources to plugins classpath from .mvn directory
>
>
> Key: MNG-6734
> URL: https://issues.apache.org/jira/browse/MNG-6734
> Project: Maven
> Issue Type: New Feature
> Components: core
>Reporter: Abel Salgado Romero
>Priority: Minor
>
> In plugins like
> [asciidoctor-maven-plugin|https://github.com/asciidoctor/asciidoctor-maven-plugin]
> it is possible to add Java Asciidoctor extensions and other customizations
> to the conversion process.
> These need to be available to the asciidoctor-maven-plugin classpath and due
> to how maven manages plugin's dependencies, this means that users need to
> publish these extension in a maven repo or create multi-module projects like
> in this example
> https://github.com/asciidoctor/asciidoctor-maven-examples/tree/master/java-extension-example.
> This is cumbersome and a bit of overkill when some users just want to add a
> single class.
> So, I wonder if would make sense to be able to add Java sources in the ".mvn"
> directory that are compiled and added to the classpath so that maven plugins
> can use them.
> Ideally, to avoid classpath issues, I'd like to be able to tell which plugins
> use the code, maybe with an XML descriptor or some directory convention.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[GitHub] [maven] rfscholte commented on issue #165: [MNG-6028] Include current goals in resume suggestion
rfscholte commented on issue #165: [MNG-6028] Include current goals in resume suggestion URL: https://github.com/apache/maven/pull/165#issuecomment-52171 `` works for me 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] Tibor17 commented on issue #46: [MNG-6731] Jetty getLocalPort() returns -1 resulting in build failures
Tibor17 commented on issue #46: [MNG-6731] Jetty getLocalPort() returns -1 resulting in build failures URL: https://github.com/apache/maven-integration-testing/pull/46#issuecomment-521707874 @joakime The best idea would to have a new PR with commits for each problem separately. Would you do that? 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] (MNG-6734) Ability to add Java sources to plugins classpath from .mvn directory
Abel Salgado Romero created MNG-6734: Summary: Ability to add Java sources to plugins classpath from .mvn directory Key: MNG-6734 URL: https://issues.apache.org/jira/browse/MNG-6734 Project: Maven Issue Type: New Feature Components: core Reporter: Abel Salgado Romero In plugins like [asciidoctor-maven-plugin|https://github.com/asciidoctor/asciidoctor-maven-plugin] it is possible to add Java Asciidoctor extensions and other customizations to the conversion process. These need to be available to the asciidoctor-maven-plugin classpath and due to how maven manages plugin's dependencies, this means that users need to publish these extension in a maven repo or create multi-module projects like in this example https://github.com/asciidoctor/asciidoctor-maven-examples/tree/master/java-extension-example. This is cumbersome and a bit of overkill when some users just want to add a single class. So, I wonder if would make sense to be able to add Java sources in the ".mvn" directory that are compiled and added to the classpath so that maven plugins can use them. Ideally, to avoid classpath issues, I'd like to be able to tell which plugins use the code, maybe with an XML descriptor or some directory convention. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[GitHub] [maven-integration-testing] joakime commented on a change in pull request #46: [MNG-6731] Jetty getLocalPort() returns -1 resulting in build failures
joakime commented on a change in pull request #46: [MNG-6731] Jetty
getLocalPort() returns -1 resulting in build failures
URL:
https://github.com/apache/maven-integration-testing/pull/46#discussion_r314348659
##
File path:
core-it-suite/src/test/java/org/apache/maven/it/MavenITmng2305MultipleProxiesTest.java
##
@@ -71,20 +78,16 @@ public void testit()
String keyPwd = "key-passwd";
Server server = new Server( 0 );
-server.addConnector( newHttpsConnector( storePath, storePwd, keyPwd )
);
+addHttpsConnector( server, storePath, storePwd, keyPwd );
server.setHandler( new RepoHandler() );
server.start();
-while ( !server.isRunning() || !server.isStarted() )
+if ( server.isFailed() )
{
-if ( server.isFailed() )
-{
-fail( "Couldn't bind the server socket to a free port!" );
-}
-Thread.sleep( 100L );
+fail( "Couldn't bind the server socket to a free port!" );
}
-int httpPort = server.getConnectors()[0].getLocalPort();
+int httpPort = ( (NetworkConnector) server.getConnectors()[0]
).getLocalPort();
System.out.println( "Bound server socket to HTTP port " + httpPort );
-int httpsPort = server.getConnectors()[1].getLocalPort();
+int httpsPort = ( (NetworkConnector) server.getConnectors()[1]
).getLocalPort();
Review comment:
Then your Requests never indicate that they are secure.
The Requests will not contain the security details.
The Requests will not have the javax attributes for the SSL / Certificate
state of the connection.
Nor will you have ability to use the "confidential" constraints.
And usages that redirect from HTTP to HTTPS will also fail. (such as
SecureRedirectHandler)
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] joakime commented on a change in pull request #46: [MNG-6731] Jetty getLocalPort() returns -1 resulting in build failures
joakime commented on a change in pull request #46: [MNG-6731] Jetty getLocalPort() returns -1 resulting in build failures URL: https://github.com/apache/maven-integration-testing/pull/46#discussion_r314347605 ## File path: core-it-suite/src/test/java/org/apache/maven/it/MavenITmng0553SettingsAuthzEncryptionTest.java ## @@ -86,18 +93,13 @@ protected void setUp() handlerList.addHandler( repoHandler ); handlerList.addHandler( new DefaultHandler() ); -server = new Server( 0 ); server.setHandler( handlerList ); server.start(); -while ( !server.isRunning() || !server.isStarted() ) +if ( server.isFailed() ) Review comment: If you have parallel processes sure. But your usages are sequential. If you decided to use something like DeploymentManager to scan for webapps and deploy them, then you would be interested in ThrowUnavailableOnStartup, which waits for initial deployment to report failures to Server.start This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [maven-surefire] Tibor17 edited a comment on issue #244: [SUREFIRE-1679] Prevent classpath caching from causing pollution
Tibor17 edited a comment on issue #244: [SUREFIRE-1679] Prevent classpath caching from causing pollution URL: https://github.com/apache/maven-surefire/pull/244#issuecomment-521649786 it's okay in version 2.x since these tests must be older and different from 3.x. The reason why there is File mock is to simplify the Captures of debug logger because there is no physicla path and creating real Jar files, no troubles with platform and long lines in code. Also it is a signal for us to fail the test if the logic in `AbstractSurefireMojo` would change in the future when the logic would need to have a real paths and real reads/writes. Till that it is just in memory. These tests in `AbstractSurefireMojoTest.java` do not have too much assertion statements. They have more Captures and verifications. And the reason is that the class `AbstractSurefireMojo` was not initially developed with tests. Basically there was no TDD in this class development. If there was, I am sure there could be much more assertions on returned values and less mocking of internal state and captures. This happens when TDD is not applied in the begining. Positive remark is that these tests improve the coverage and give us some feedback when the code is changed together with the experiences of the `AbstractSurefireMojo`. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [maven-surefire] Tibor17 edited a comment on issue #244: [SUREFIRE-1679] Prevent classpath caching from causing pollution
Tibor17 edited a comment on issue #244: [SUREFIRE-1679] Prevent classpath caching from causing pollution URL: https://github.com/apache/maven-surefire/pull/244#issuecomment-521649786 it's okay in version 2.x since these tests must be older and different from 3.x. The reason why there is File mock is to simplify the Captures of debug logger because there is no physicla path and no troubles with platform and long lines in code. Also it is a signal for us to fail the test if the logic in `AbstractSurefireMojo` would change in the future when the logic would need to have a real paths and real reads/writes. Till that it is just in memory. These tests in `AbstractSurefireMojoTest.java` do not have too much assertion statements. They have more Captures and verifications. And the reason is that the class `AbstractSurefireMojo` was not initially developed with tests. Basically there was no TDD in this class development. If there was, I am sure there could be much more assertions on returned values and less mocking of internal state and captures. This happens when TDD is not applied in the begining. Positive remark is that these tests improve the coverage and give us some feedback when the code is changed together with the experiences of the `AbstractSurefireMojo`. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [maven-surefire] Tibor17 edited a comment on issue #244: [SUREFIRE-1679] Prevent classpath caching from causing pollution
Tibor17 edited a comment on issue #244: [SUREFIRE-1679] Prevent classpath caching from causing pollution URL: https://github.com/apache/maven-surefire/pull/244#issuecomment-521649786 it's okay in version 2.x since these tests must be older and different from 3.x. The reason why there is File mock is to simplify the Captures of debug logger because there is no physicla path and no troubles with platform and long lines in code. Also it is a signal for us to fail the test if the logic in `AbstractSurefireMojo` would change in the future when the logic would need to have a real paths and real reads/writes. Till that it is just in memory. These tests in `AbstractSurefireMojoTest.java` do not have too much assertion statements. They have more Captures and verifications. And the reason is that the class `AbstractSurefireMojo` was not developed with tests. Basically there was no TDD in this class development. If there was, I am sure there could be much more assertions on returned values and less mocking of internal state and captures. This happens when TDD is not applied in the begining. Positive remark is that these tests improve the coverage and give us some feedback when the code is changed together with the experiences of the `AbstractSurefireMojo`. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [maven-surefire] Tibor17 edited a comment on issue #244: [SUREFIRE-1679] Prevent classpath caching from causing pollution
Tibor17 edited a comment on issue #244: [SUREFIRE-1679] Prevent classpath caching from causing pollution URL: https://github.com/apache/maven-surefire/pull/244#issuecomment-521649786 it's okay in version 2.x since these tests must be older and different from 3.x. The reason why there is File mock is to simplify the Captures of debug logger because there is no physicla path and no troubles with platform and long lines in code. Also it is a signal for us to fail the test if the logic in `AbstractSurefireMojo` would change in the future when the logic would need to have a real paths and real reds/writes. Till that it is just in memory. These tests in `AbstractSurefireMojoTest.java` do not have too much assertion statements. They have more Captures and verifications. And the reason is that the class `AbstractSurefireMojo` was not developed with tests. Basically there was no TDD in this class development. If there was, I am sure there could be much more assertions on returned values and less mocking of internal state and captures. This happens when TDD is not applied in the begining. Positive remark is that these tests improve the coverage and give us some feedback when the code is changed together with the experiences of the `AbstractSurefireMojo`. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [maven-surefire] Tibor17 edited a comment on issue #244: [SUREFIRE-1679] Prevent classpath caching from causing pollution
Tibor17 edited a comment on issue #244: [SUREFIRE-1679] Prevent classpath caching from causing pollution URL: https://github.com/apache/maven-surefire/pull/244#issuecomment-521649786 it's okay in version 2.x since these tests must be older and different from 3.x. The reason why there is File mock is to simplify the Captures of debug logger because there is no physicla path and no troubles with platform and long lines in code. Also it is a signal for us to fail the test if the logic in `AbstractSurefireMojo` would change in the future when the logic would need to have a real paths and real reds/writes. Till that it is just in memory. These tests in `AbstractSurefireMojoTest.java` do not have too much assertion statements. They have more Captures and verifications. And the reason is that the class `AbstractSurefireMojo` was not developed with tests. Basically there was no TDD in this class development. If there was I wam sure there could be much more assertions on returned values and less mocking of internal state and captures. This happens when TDD is not applied in the begining. Positive remark is that these tests improve the coverage and give us some feedback when the code is changed together with the experiences of the `AbstractSurefireMojo`. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [maven-surefire] Tibor17 commented on issue #244: [SUREFIRE-1679] Prevent classpath caching from causing pollution
Tibor17 commented on issue #244: [SUREFIRE-1679] Prevent classpath caching from causing pollution URL: https://github.com/apache/maven-surefire/pull/244#issuecomment-521649786 it's okay in version 2.x since these tests must be older and different from 3.x. The reason why there is File mock is to simplify the Captures of debug logger because there is no physicla path and no troubles with platform and long lines in code. Also it is a signal for us to fail the test if the logic in `AbstractSurefireMojo` would change in the future when the logic would need to have a real paths and real reds/writes. Till that it is just in memory. These tests in `AbstractSurefireMojoTest.java` do not have too much assertion statements. They have more Captures and verifications. And the reason is that the class `AbstractSurefireMojo` was not developed with tests. Basically there was TDD on this class development. If there was I wam sure there could be much more assertions on returned values and less mocking of internal state and captures. This happens when TDD is not applied in the begining. Positive remark is that these tests improve the coverage and give us some feedback when the code is changed together with the experiences of the `AbstractSurefireMojo`. 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] (MPMD-294) Add support for setting includes/excludes via a user property
Roy Arnon created MPMD-294: -- Summary: Add support for setting includes/excludes via a user property Key: MPMD-294 URL: https://issues.apache.org/jira/browse/MPMD-294 Project: Maven PMD Plugin Issue Type: New Feature Components: CPD, PMD Affects Versions: 3.12.0 Reporter: Roy Arnon I have a use case were I want to execute pmd on a huge monorepo project, but only on the changed files. Getting the changed java files via git is trivial, but it seems that the PMD plugin does not support setting the includes/excludes by user property. Can we look into adding a property like maven surefires includesFile/excludesFile, which will allow us to specify includes/excludes at runtime? I may try to prepare a PR for this feature if I have the time. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[GitHub] [maven-integration-testing] Tibor17 commented on a change in pull request #46: [MNG-6731] Jetty getLocalPort() returns -1 resulting in build failures
Tibor17 commented on a change in pull request #46: [MNG-6731] Jetty
getLocalPort() returns -1 resulting in build failures
URL:
https://github.com/apache/maven-integration-testing/pull/46#discussion_r314309460
##
File path:
core-it-suite/src/test/java/org/apache/maven/it/MavenITmng2305MultipleProxiesTest.java
##
@@ -71,20 +78,16 @@ public void testit()
String keyPwd = "key-passwd";
Server server = new Server( 0 );
-server.addConnector( newHttpsConnector( storePath, storePwd, keyPwd )
);
+addHttpsConnector( server, storePath, storePwd, keyPwd );
server.setHandler( new RepoHandler() );
server.start();
-while ( !server.isRunning() || !server.isStarted() )
+if ( server.isFailed() )
{
-if ( server.isFailed() )
-{
-fail( "Couldn't bind the server socket to a free port!" );
-}
-Thread.sleep( 100L );
+fail( "Couldn't bind the server socket to a free port!" );
}
-int httpPort = server.getConnectors()[0].getLocalPort();
+int httpPort = ( (NetworkConnector) server.getConnectors()[0]
).getLocalPort();
System.out.println( "Bound server socket to HTTP port " + httpPort );
-int httpsPort = server.getConnectors()[1].getLocalPort();
+int httpsPort = ( (NetworkConnector) server.getConnectors()[1]
).getLocalPort();
Review comment:
The thing is that we do not set the port, via
`HttpConfiguration.setSecurePort(int)`, because we do not know it. We can only
read both ports as local ports.
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] Tibor17 commented on a change in pull request #46: [MNG-6731] Jetty getLocalPort() returns -1 resulting in build failures
Tibor17 commented on a change in pull request #46: [MNG-6731] Jetty getLocalPort() returns -1 resulting in build failures URL: https://github.com/apache/maven-integration-testing/pull/46#discussion_r314307488 ## File path: core-it-suite/src/test/java/org/apache/maven/it/MavenITmng0553SettingsAuthzEncryptionTest.java ## @@ -86,18 +93,13 @@ protected void setUp() handlerList.addHandler( repoHandler ); handlerList.addHandler( new DefaultHandler() ); -server = new Server( 0 ); server.setHandler( handlerList ); server.start(); -while ( !server.isRunning() || !server.isStarted() ) +if ( server.isFailed() ) Review comment: I think the purpose of this is to check server's status in a parallel thread. ok, we can avoid the IF statement. 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] Tibor17 commented on a change in pull request #46: [MNG-6731] Jetty getLocalPort() returns -1 resulting in build failures
Tibor17 commented on a change in pull request #46: [MNG-6731] Jetty
getLocalPort() returns -1 resulting in build failures
URL:
https://github.com/apache/maven-integration-testing/pull/46#discussion_r314301738
##
File path:
core-it-suite/src/test/java/org/apache/maven/it/MavenIT0146InstallerSnapshotNaming.java
##
@@ -59,15 +60,11 @@ protected void setUp()
server = new Server( 0 );
server.setHandler( handlers );
server.start();
-while ( !server.isRunning() || !server.isStarted() )
+if ( server.isFailed() )
{
-if ( server.isFailed() )
-{
-fail( "Couldn't bind the server socket to a free port!" );
-}
-Thread.sleep( 100L );
+fail( "Couldn't bind the server socket to a free port!" );
}
-port = server.getConnectors()[0].getLocalPort();
+port = ( (NetworkConnector) server.getConnectors()[0] ).getLocalPort();
Review comment:
I did not want to make the code too much different from what we had before.
I am glad that the version 9.0.4 works. After I changed the version to 9.2.28 I
got HTTP 405 and really did not want to get new arguments from the devs saying
that there is something which broke new version.
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
With regards,
Apache Git Services
[GitHub] [maven-integration-testing] Tibor17 commented on a change in pull request #46: [MNG-6731] Jetty getLocalPort() returns -1 resulting in build failures
Tibor17 commented on a change in pull request #46: [MNG-6731] Jetty
getLocalPort() returns -1 resulting in build failures
URL:
https://github.com/apache/maven-integration-testing/pull/46#discussion_r314304344
##
File path:
core-it-suite/src/test/java/org/apache/maven/it/MavenIT0146InstallerSnapshotNaming.java
##
@@ -59,15 +60,11 @@ protected void setUp()
server = new Server( 0 );
server.setHandler( handlers );
server.start();
-while ( !server.isRunning() || !server.isStarted() )
+if ( server.isFailed() )
{
-if ( server.isFailed() )
-{
-fail( "Couldn't bind the server socket to a free port!" );
-}
-Thread.sleep( 100L );
+fail( "Couldn't bind the server socket to a free port!" );
}
-port = server.getConnectors()[0].getLocalPort();
+port = ( (NetworkConnector) server.getConnectors()[0] ).getLocalPort();
Review comment:
@joakime
Do you see more occurrences of this? Notice that we also have two connectors
in few tests using HTTPS.
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] Tibor17 commented on a change in pull request #46: [MNG-6731] Jetty getLocalPort() returns -1 resulting in build failures
Tibor17 commented on a change in pull request #46: [MNG-6731] Jetty
getLocalPort() returns -1 resulting in build failures
URL:
https://github.com/apache/maven-integration-testing/pull/46#discussion_r314304344
##
File path:
core-it-suite/src/test/java/org/apache/maven/it/MavenIT0146InstallerSnapshotNaming.java
##
@@ -59,15 +60,11 @@ protected void setUp()
server = new Server( 0 );
server.setHandler( handlers );
server.start();
-while ( !server.isRunning() || !server.isStarted() )
+if ( server.isFailed() )
{
-if ( server.isFailed() )
-{
-fail( "Couldn't bind the server socket to a free port!" );
-}
-Thread.sleep( 100L );
+fail( "Couldn't bind the server socket to a free port!" );
}
-port = server.getConnectors()[0].getLocalPort();
+port = ( (NetworkConnector) server.getConnectors()[0] ).getLocalPort();
Review comment:
@joakime
Do you see more occurences of this? Notice that we also have two connectors
in few tests using HTTPS.
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] Tibor17 commented on a change in pull request #46: [MNG-6731] Jetty getLocalPort() returns -1 resulting in build failures
Tibor17 commented on a change in pull request #46: [MNG-6731] Jetty
getLocalPort() returns -1 resulting in build failures
URL:
https://github.com/apache/maven-integration-testing/pull/46#discussion_r314302888
##
File path:
core-it-suite/src/test/java/org/apache/maven/it/MavenIT0146InstallerSnapshotNaming.java
##
@@ -59,15 +60,11 @@ protected void setUp()
server = new Server( 0 );
server.setHandler( handlers );
server.start();
-while ( !server.isRunning() || !server.isStarted() )
+if ( server.isFailed() )
{
-if ( server.isFailed() )
-{
-fail( "Couldn't bind the server socket to a free port!" );
-}
-Thread.sleep( 100L );
+fail( "Couldn't bind the server socket to a free port!" );
}
-port = server.getConnectors()[0].getLocalPort();
+port = ( (NetworkConnector) server.getConnectors()[0] ).getLocalPort();
Review comment:
So I would make a new commit as an improvement of this line.
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] Tibor17 commented on a change in pull request #46: [MNG-6731] Jetty getLocalPort() returns -1 resulting in build failures
Tibor17 commented on a change in pull request #46: [MNG-6731] Jetty
getLocalPort() returns -1 resulting in build failures
URL:
https://github.com/apache/maven-integration-testing/pull/46#discussion_r314302466
##
File path:
core-it-suite/src/test/java/org/apache/maven/it/MavenIT0146InstallerSnapshotNaming.java
##
@@ -59,15 +60,11 @@ protected void setUp()
server = new Server( 0 );
server.setHandler( handlers );
server.start();
-while ( !server.isRunning() || !server.isStarted() )
+if ( server.isFailed() )
{
-if ( server.isFailed() )
-{
-fail( "Couldn't bind the server socket to a free port!" );
-}
-Thread.sleep( 100L );
+fail( "Couldn't bind the server socket to a free port!" );
}
-port = server.getConnectors()[0].getLocalPort();
+port = ( (NetworkConnector) server.getConnectors()[0] ).getLocalPort();
Review comment:
We can improve as always but I spent 3 days with these 38 tests and for me
it is always good to have several smaller changes than one big change. With
small changes/commits we can always test older commits if we find some issue.
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
With regards,
Apache Git Services
[GitHub] [maven-integration-testing] Tibor17 commented on a change in pull request #46: [MNG-6731] Jetty getLocalPort() returns -1 resulting in build failures
Tibor17 commented on a change in pull request #46: [MNG-6731] Jetty
getLocalPort() returns -1 resulting in build failures
URL:
https://github.com/apache/maven-integration-testing/pull/46#discussion_r314302466
##
File path:
core-it-suite/src/test/java/org/apache/maven/it/MavenIT0146InstallerSnapshotNaming.java
##
@@ -59,15 +60,11 @@ protected void setUp()
server = new Server( 0 );
server.setHandler( handlers );
server.start();
-while ( !server.isRunning() || !server.isStarted() )
+if ( server.isFailed() )
{
-if ( server.isFailed() )
-{
-fail( "Couldn't bind the server socket to a free port!" );
-}
-Thread.sleep( 100L );
+fail( "Couldn't bind the server socket to a free port!" );
}
-port = server.getConnectors()[0].getLocalPort();
+port = ( (NetworkConnector) server.getConnectors()[0] ).getLocalPort();
Review comment:
We can improve as always but I spent 3 days with these 38 tests and for me
it is always good to have several smaller changes than one big change. With
small changes/commits we can always find test older commits if we find some
issue.
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
With regards,
Apache Git Services
[GitHub] [maven-integration-testing] Tibor17 commented on a change in pull request #46: [MNG-6731] Jetty getLocalPort() returns -1 resulting in build failures
Tibor17 commented on a change in pull request #46: [MNG-6731] Jetty
getLocalPort() returns -1 resulting in build failures
URL:
https://github.com/apache/maven-integration-testing/pull/46#discussion_r314301738
##
File path:
core-it-suite/src/test/java/org/apache/maven/it/MavenIT0146InstallerSnapshotNaming.java
##
@@ -59,15 +60,11 @@ protected void setUp()
server = new Server( 0 );
server.setHandler( handlers );
server.start();
-while ( !server.isRunning() || !server.isStarted() )
+if ( server.isFailed() )
{
-if ( server.isFailed() )
-{
-fail( "Couldn't bind the server socket to a free port!" );
-}
-Thread.sleep( 100L );
+fail( "Couldn't bind the server socket to a free port!" );
}
-port = server.getConnectors()[0].getLocalPort();
+port = ( (NetworkConnector) server.getConnectors()[0] ).getLocalPort();
Review comment:
I did not want to make the code too much different from what we had before.I
was glad that the version 9.0.4 works. After I changed the version to 9.2.28 I
got HTTP 405 and really did not want to get new arguments from the devs saying
that there is something which broke new version.
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
With regards,
Apache Git Services
[GitHub] [maven-integration-testing] joakime commented on a change in pull request #46: [MNG-6731] Jetty getLocalPort() returns -1 resulting in build failures
joakime commented on a change in pull request #46: [MNG-6731] Jetty
getLocalPort() returns -1 resulting in build failures
URL:
https://github.com/apache/maven-integration-testing/pull/46#discussion_r314287943
##
File path:
core-it-suite/src/test/java/org/apache/maven/it/MavenITmng0768OfflineModeTest.java
##
@@ -103,17 +103,12 @@ else if ( request.getRequestURI().endsWith( ".md5" ) ||
request.getRequestURI().
try
{
server.start();
-while ( !server.isRunning() || !server.isStarted() )
+if ( server.isFailed() )
Review comment:
This line is not possible to reach immediately after `server.start()` in a
Bind failure scenario.
The ServerConnector's doStart will attempt to bind
The BindException gets thrown for failure to bind
A IOException wraps failure to bind during ServerConnector doStart
The Server doStart captures the IOException and adds it to the
MultiException its tracking
At the end of Server doStart the MultiException throws if it has any
exceptions its tracking.
This scenario should result in a IOException or MultiException from
server.start()
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] joakime commented on a change in pull request #46: [MNG-6731] Jetty getLocalPort() returns -1 resulting in build failures
joakime commented on a change in pull request #46: [MNG-6731] Jetty getLocalPort() returns -1 resulting in build failures URL: https://github.com/apache/maven-integration-testing/pull/46#discussion_r314301663 ## File path: core-it-suite/src/test/java/org/apache/maven/it/MavenITmng0553SettingsAuthzEncryptionTest.java ## @@ -86,18 +93,13 @@ protected void setUp() handlerList.addHandler( repoHandler ); handlerList.addHandler( new DefaultHandler() ); -server = new Server( 0 ); server.setHandler( handlerList ); server.start(); -while ( !server.isRunning() || !server.isStarted() ) +if ( server.isFailed() ) Review comment: That is the generic `start()` for `AbstractLifeCycle`. `Server` is a `ContainerLifeCycle` and a special one at that. It's `Server.doStart()` has to do far more then this abstract base behavior simply because it's a combination of a Container (with child lifecycles) and it's the main entry point for external that care about the LifeCycle state. 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] Tibor17 commented on a change in pull request #46: [MNG-6731] Jetty getLocalPort() returns -1 resulting in build failures
Tibor17 commented on a change in pull request #46: [MNG-6731] Jetty
getLocalPort() returns -1 resulting in build failures
URL:
https://github.com/apache/maven-integration-testing/pull/46#discussion_r314300317
##
File path:
core-it-suite/src/test/java/org/apache/maven/it/MavenITmng0553SettingsAuthzEncryptionTest.java
##
@@ -86,18 +93,13 @@ protected void setUp()
handlerList.addHandler( repoHandler );
handlerList.addHandler( new DefaultHandler() );
-server = new Server( 0 );
server.setHandler( handlerList );
server.start();
-while ( !server.isRunning() || !server.isStarted() )
+if ( server.isFailed() )
Review comment:
because this has a purpose. I want to catch all errors. Not only IOException.
```
@Override
public final void start() throws Exception
{
synchronized (_lock)
{
try
{
if (_state == __STARTED || _state == __STARTING)
return;
setStarting();
doStart();
setStarted();
}
catch (Throwable e)
{
setFailed(e);
throw e;
}
}
}
```
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] joakime commented on a change in pull request #46: [MNG-6731] Jetty getLocalPort() returns -1 resulting in build failures
joakime commented on a change in pull request #46: [MNG-6731] Jetty
getLocalPort() returns -1 resulting in build failures
URL:
https://github.com/apache/maven-integration-testing/pull/46#discussion_r314284534
##
File path:
core-it-suite/src/test/java/org/apache/maven/it/MavenIT0146InstallerSnapshotNaming.java
##
@@ -59,15 +60,11 @@ protected void setUp()
server = new Server( 0 );
server.setHandler( handlers );
server.start();
-while ( !server.isRunning() || !server.isStarted() )
+if ( server.isFailed() )
{
-if ( server.isFailed() )
-{
-fail( "Couldn't bind the server socket to a free port!" );
-}
-Thread.sleep( 100L );
+fail( "Couldn't bind the server socket to a free port!" );
}
-port = server.getConnectors()[0].getLocalPort();
+port = ( (NetworkConnector) server.getConnectors()[0] ).getLocalPort();
Review comment:
There's also `server.getURI().getPort()` as a valid option here.
(This will return the URI to the first connector's security scheme (http vs
https) + local host + port + first handler's own context path)
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] joakime commented on a change in pull request #46: [MNG-6731] Jetty getLocalPort() returns -1 resulting in build failures
joakime commented on a change in pull request #46: [MNG-6731] Jetty
getLocalPort() returns -1 resulting in build failures
URL:
https://github.com/apache/maven-integration-testing/pull/46#discussion_r314288543
##
File path:
core-it-suite/src/test/java/org/apache/maven/it/MavenITmng2305MultipleProxiesTest.java
##
@@ -71,20 +78,16 @@ public void testit()
String keyPwd = "key-passwd";
Server server = new Server( 0 );
-server.addConnector( newHttpsConnector( storePath, storePwd, keyPwd )
);
+addHttpsConnector( server, storePath, storePwd, keyPwd );
server.setHandler( new RepoHandler() );
server.start();
-while ( !server.isRunning() || !server.isStarted() )
+if ( server.isFailed() )
{
-if ( server.isFailed() )
-{
-fail( "Couldn't bind the server socket to a free port!" );
-}
-Thread.sleep( 100L );
+fail( "Couldn't bind the server socket to a free port!" );
}
-int httpPort = server.getConnectors()[0].getLocalPort();
+int httpPort = ( (NetworkConnector) server.getConnectors()[0]
).getLocalPort();
System.out.println( "Bound server socket to HTTP port " + httpPort );
-int httpsPort = server.getConnectors()[1].getLocalPort();
+int httpsPort = ( (NetworkConnector) server.getConnectors()[1]
).getLocalPort();
Review comment:
The `HttpConfiguration` belonging to Connector[0] needs to have its
`HttpConfiguration.setSecurePort(int)` set for the port that this HTTPS
connector.
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] joakime commented on a change in pull request #46: [MNG-6731] Jetty getLocalPort() returns -1 resulting in build failures
joakime commented on a change in pull request #46: [MNG-6731] Jetty
getLocalPort() returns -1 resulting in build failures
URL:
https://github.com/apache/maven-integration-testing/pull/46#discussion_r314287943
##
File path:
core-it-suite/src/test/java/org/apache/maven/it/MavenITmng0768OfflineModeTest.java
##
@@ -103,17 +103,12 @@ else if ( request.getRequestURI().endsWith( ".md5" ) ||
request.getRequestURI().
try
{
server.start();
-while ( !server.isRunning() || !server.isStarted() )
+if ( server.isFailed() )
Review comment:
This state is not possible to reach immediately after `server.start()` in a
Bind failure scenario.
The ServerConnector's doStart will attempt to bind
The BindException gets thrown for failure to bind
A IOException wraps failure to bind during ServerConnector doStart
The Server doStart captures the IOException and adds it to the
MultiException its tracking
At the end of Server doStart the MultiException throws if it has any
exceptions its tracking.
This scenario should result in a IOException or MultiException from
server.start()
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] joakime commented on a change in pull request #46: [MNG-6731] Jetty getLocalPort() returns -1 resulting in build failures
joakime commented on a change in pull request #46: [MNG-6731] Jetty getLocalPort() returns -1 resulting in build failures URL: https://github.com/apache/maven-integration-testing/pull/46#discussion_r314284936 ## File path: core-it-suite/src/test/java/org/apache/maven/it/MavenITmng0553SettingsAuthzEncryptionTest.java ## @@ -86,18 +93,13 @@ protected void setUp() handlerList.addHandler( repoHandler ); handlerList.addHandler( new DefaultHandler() ); -server = new Server( 0 ); server.setHandler( handlerList ); server.start(); -while ( !server.isRunning() || !server.isStarted() ) +if ( server.isFailed() ) Review comment: Server could have successfully started up, and then be successfully stopped, before this line hits. In this scenario, the server LifeCycle state is STOPPED, not FAILED. 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] joakime commented on a change in pull request #46: [MNG-6731] Jetty getLocalPort() returns -1 resulting in build failures
joakime commented on a change in pull request #46: [MNG-6731] Jetty
getLocalPort() returns -1 resulting in build failures
URL:
https://github.com/apache/maven-integration-testing/pull/46#discussion_r314284534
##
File path:
core-it-suite/src/test/java/org/apache/maven/it/MavenIT0146InstallerSnapshotNaming.java
##
@@ -59,15 +60,11 @@ protected void setUp()
server = new Server( 0 );
server.setHandler( handlers );
server.start();
-while ( !server.isRunning() || !server.isStarted() )
+if ( server.isFailed() )
{
-if ( server.isFailed() )
-{
-fail( "Couldn't bind the server socket to a free port!" );
-}
-Thread.sleep( 100L );
+fail( "Couldn't bind the server socket to a free port!" );
}
-port = server.getConnectors()[0].getLocalPort();
+port = ( (NetworkConnector) server.getConnectors()[0] ).getLocalPort();
Review comment:
There's also `server.getURI().getPort()` as a valid option here.
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] joakime commented on a change in pull request #46: [MNG-6731] Jetty getLocalPort() returns -1 resulting in build failures
joakime commented on a change in pull request #46: [MNG-6731] Jetty
getLocalPort() returns -1 resulting in build failures
URL:
https://github.com/apache/maven-integration-testing/pull/46#discussion_r314284271
##
File path: core-it-suite/src/test/java/org/apache/maven/it/HttpServer.java
##
@@ -66,21 +68,20 @@ public void stop()
public int port()
{
-return ( (ServerConnector) server.getConnectors()[0] ).getLocalPort();
+return ( (NetworkConnector) server.getConnectors()[0] ).getLocalPort();
}
private Server server( int port )
{
-
QueuedThreadPool threadPool = new QueuedThreadPool();
threadPool.setMaxThreads( 500 );
Server server = new Server( threadPool );
+server.setConnectors( new Connector[]{ new ServerConnector( server ) }
);
server.addBean( new ScheduledExecutorScheduler() );
-ServerConnector http = new ServerConnector( server );
-http.setPort( port );
-http.setIdleTimeout( 3 );
-server.addConnector( http );
+ServerConnector connector = (ServerConnector)
server.getConnectors()[0];
+connector.setIdleTimeout( 30_000L );
+connector.setPort( port );
Review comment:
Why not just do this instead ?
``` java
ServerConnector connector = new ServerConnector( server );
connector.setIdleTimeout( 30_000L );
connector.setPort( port );
server.addConnector( connector );
```
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
With regards,
Apache Git Services
[GitHub] [maven-surefire] wilkinsona opened a new pull request #244: [SUREFIRE-1679] Prevent classpath caching from causing pollution
wilkinsona opened a new pull request #244: [SUREFIRE-1679] Prevent classpath caching from causing pollution URL: https://github.com/apache/maven-surefire/pull/244 This pull request backports the changes made in https://github.com/apache/maven-surefire/pull/243 to 2.22.x. The main source changes are the same. The test has be modified to align with the small differences in the implementation. Most notably, I have introduced the use of `TemporaryFolder` as the use of a mocked `File` resulted in an NPE as the `path` field of the mocked `File` was `null`. I hope that's OK. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [maven-surefire] wilkinsona commented on issue #243: [SUREFIRE-1679] Prevent classpath caching from causing pollution
wilkinsona commented on issue #243: [SUREFIRE-1679] Prevent classpath caching from causing pollution URL: https://github.com/apache/maven-surefire/pull/243#issuecomment-521604924 Thanks, @sormuras. I've opened a PR using that branch as its base: https://github.com/apache/maven-surefire/pull/244. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [maven-surefire] sormuras commented on issue #243: [SUREFIRE-1679] Prevent classpath caching from causing pollution
sormuras commented on issue #243: [SUREFIRE-1679] Prevent classpath caching from causing pollution URL: https://github.com/apache/maven-surefire/pull/243#issuecomment-521581930 iirc, it's this branch https://github.com/apache/maven-surefire/tree/release/2.22.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] [Commented] (MDEP-579) Regression: get goal does not pass server credentials to BasicRepositoryConnector
[
https://issues.apache.org/jira/browse/MDEP-579?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16907957#comment-16907957
]
Kent Granström commented on MDEP-579:
-
Apologies [~pmoerenhout]. I made a typo and testing it after that it seems to
work just fine. I can now use the "get" and it passes the creds nicely. I would
concider this as solved, at least for me :). Perhaps a few testcases ought to
be written for this, and similar, scenarios.
Many many thanks [~pmoerenhout]
> Regression: get goal does not pass server credentials to
> BasicRepositoryConnector
> -
>
> Key: MDEP-579
> URL: https://issues.apache.org/jira/browse/MDEP-579
> Project: Maven Dependency Plugin
> Issue Type: Bug
> Components: get
>Affects Versions: 3.0.0, 3.0.1
>Reporter: Richard W. Eggert II
>Priority: Critical
> Labels: credentials
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The {{get}} goal does not pass the server credentials from {{settings.xml}}
> to the {{BasicRepositoryConnector}} in version 3.0.1 (and, presumably 3.0.0),
> resulting in {{NotAuthorized}} errors when resolving artifacts against
> repositories that require authentication. It works correctly in version 2.9.
> Background: I discovered this in the course of debugging a Jenkins job in
> which I'm using the {{get}} and {{copy}} goals from the command line (with no
> POM) to download artifacts to deploy. After spending several hours thinking
> that Jenkins was not properly configuring {{settings.xml}}, I noticed from
> the Maven debug output that the credentials were being passed when resolving
> the maven-dependency-plugin and its dependencies, but not being passed when
> resolving the artifact I requested. On a hunch I downgraded from
> maven-dependency-plugin version 3.0.1 to 2.9, and suddenly everything
> magically worked.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[GitHub] [maven-surefire] wilkinsona commented on issue #243: [SUREFIRE-1679] Prevent classpath caching from causing pollution
wilkinsona commented on issue #243: [SUREFIRE-1679] Prevent classpath caching from causing pollution URL: https://github.com/apache/maven-surefire/pull/243#issuecomment-521577398 My pleasure. Thanks for the review and merge. I'd like to work on an equivalent 2.22.x fix now. What branch should I use as the base for that? 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] (MDEP-579) Regression: get goal does not pass server credentials to BasicRepositoryConnector
[
https://issues.apache.org/jira/browse/MDEP-579?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16907849#comment-16907849
]
Pim Moerenhout commented on MDEP-579:
-
Hi [~kentgran],
I have setup the setup you've described, using a Nexus docker image as mirror
of public with authentication, together with a private repository. However, I
did change the mirrorOf property of the nexus mirror to *,!internal-repo-id, as
this property must contain the id. See [Settings
reference|https://maven.apache.org/settings.html#Mirrors].
With the setup described, the artifact could be get, from the internal
repository, with the correct authentication. Before the get, I delete the
artifact from the local repository in the .m2/repo folder.
In the failure log, the message is _Could not find artifact
com.test.note:note-docker:zip:4.1 in nexus_. It's not mentioning that the
authentication failed.
Could you verify in the real setup how the mirrorOf is specified ?
If it still fails, I could setup the docker image to hold the 2 repositories,
as next step.
> Regression: get goal does not pass server credentials to
> BasicRepositoryConnector
> -
>
> Key: MDEP-579
> URL: https://issues.apache.org/jira/browse/MDEP-579
> Project: Maven Dependency Plugin
> Issue Type: Bug
> Components: get
>Affects Versions: 3.0.0, 3.0.1
>Reporter: Richard W. Eggert II
>Priority: Critical
> Labels: credentials
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The {{get}} goal does not pass the server credentials from {{settings.xml}}
> to the {{BasicRepositoryConnector}} in version 3.0.1 (and, presumably 3.0.0),
> resulting in {{NotAuthorized}} errors when resolving artifacts against
> repositories that require authentication. It works correctly in version 2.9.
> Background: I discovered this in the course of debugging a Jenkins job in
> which I'm using the {{get}} and {{copy}} goals from the command line (with no
> POM) to download artifacts to deploy. After spending several hours thinking
> that Jenkins was not properly configuring {{settings.xml}}, I noticed from
> the Maven debug output that the credentials were being passed when resolving
> the maven-dependency-plugin and its dependencies, but not being passed when
> resolving the artifact I requested. On a hunch I downgraded from
> maven-dependency-plugin version 3.0.1 to 2.9, and suddenly everything
> magically worked.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
