[jira] [Commented] (SUREFIRE-1390) maven-failsafe-plugin:2.20:verify classNotFound (spring autowired service) testNg
[ https://issues.apache.org/jira/browse/SUREFIRE-1390?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16299210#comment-16299210 ] Sebastien Dubois commented on SUREFIRE-1390: Just for the record, if anyone else in the same situation as me ends up here: I faced this issue and then realized that it was because the Spring Boot executable jar was being used, the issue being that in that JAR my own classes are under BOOT-INF\classes and not at the usual location... The clean solution in that case seems to be to split the code in different modules so that you can have it as a dependency. A simpler approach (though less clean) is to use the solution described here to create the special Spring Boot jar in a separate file and thus have a normal one usable with Surefire/Failsafe: https://docs.spring.io/spring-boot/docs/current-SNAPSHOT/reference/htmlsingle/#howto-create-an-additional-executable-jar > maven-failsafe-plugin:2.20:verify classNotFound (spring autowired service) > testNg > - > > Key: SUREFIRE-1390 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1390 > Project: Maven Surefire > Issue Type: Bug > Components: Maven Failsafe Plugin, TestNG support >Affects Versions: 2.19, 2.19.1, 2.20 > Environment: Win 10; terminal: MINGW64; Spring boot starter [1.5.3, > 1.5.4] >Reporter: hhwebdev >Assignee: Tibor Digana > Labels: build, test > Fix For: Backlog > > Attachments: 2017-07-12T09-45-33_517-jvmRun1.dump, > cmd_mvn_install_X.txt, failsafe-summary.xml > > > Apologies in advance if duplicate or needs to be in Failsafe specific > project, am new to jira, tried searching, but couldn't find match. Not sure > if bug in plugin, but couldn't find anything on google/SO based on failsafe > stacktrace. > Upgrading failsafe versions to [2.19, 2.20] causes unexpected failure during > integration test run of spring-based testNg tests. > However, remaining on current failsafe version, 2.18.1, works as expected. > See attachments for more details. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (MNG-6323) Deadlock in multithreaded dependency resolution
[
https://issues.apache.org/jira/browse/MNG-6323?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16298998#comment-16298998
]
Robert Scholte commented on MNG-6323:
-
MNG-6324 seems to have a reproducable project. Then it is a matter of
git-bisect to find the trouble making commit.
> Deadlock in multithreaded dependency resolution
> ---
>
> Key: MNG-6323
> URL: https://issues.apache.org/jira/browse/MNG-6323
> Project: Maven
> Issue Type: Bug
>Affects Versions: 3.5.2
>Reporter: Ben Caradoc-Davies
> Attachments: geoserver-community-maven-hang-jstack-2.txt,
> geoserver-community-maven-hang-jstack.txt
>
>
> Maven 3.5.2 multithreaded builds experience a deadlock not seen with Maven
> 3.5.0.
> To reproduce the issue, clone GeoServer:
> {noformat}
> git clone https://github.com/geoserver/geoserver.git
> cd geoserver
> {noformat}
> Build GeoServer community modules with:
> {noformat}
> mvn -f src/community/pom.xml -B -T4 -U -Prelease -PcommunityRelease
> -DskipTests clean install
> {noformat}
> Builds that normally take 2-4 minutes instead experience long hangs.
> {{jstack}} output (attached) suggests a deadlock (two different hangs
> attached). Some of the locks are in {{TIME_WAIT}} and eventually the build
> completes after 30-45 minutes, but this is enough to cause builds on Travis
> to be killed for their failure to output for ten minutes. (Travis upgraded to
> Maven 3.5.2 a week ago.)
> I have only seen the failures with -U. The hang does not occur in
> single-threaded builds. There are no "*.lock" files in the local repository
> during the hang so the deadlocks are not mediated by the filesystem. CPU
> utilisation is zero suggesting a deadlock not a livelock.
> See also discussion on the geoserver-devel mailing list:
> http://osgeo-org.1560.x6.nabble.com/Travis-failures-started-with-new-trusty-images-td5346836.html
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (MNG-6323) Deadlock in multithreaded dependency resolution
[
https://issues.apache.org/jira/browse/MNG-6323?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16298993#comment-16298993
]
Ben Caradoc-Davies commented on MNG-6323:
-
Another Travis user reports that they were also affected by this bug and able
to work around it by downgrading to Maven 3.5.0:
https://github.com/travis-ci/travis-ci/issues/8932
> Deadlock in multithreaded dependency resolution
> ---
>
> Key: MNG-6323
> URL: https://issues.apache.org/jira/browse/MNG-6323
> Project: Maven
> Issue Type: Bug
>Affects Versions: 3.5.2
>Reporter: Ben Caradoc-Davies
> Attachments: geoserver-community-maven-hang-jstack-2.txt,
> geoserver-community-maven-hang-jstack.txt
>
>
> Maven 3.5.2 multithreaded builds experience a deadlock not seen with Maven
> 3.5.0.
> To reproduce the issue, clone GeoServer:
> {noformat}
> git clone https://github.com/geoserver/geoserver.git
> cd geoserver
> {noformat}
> Build GeoServer community modules with:
> {noformat}
> mvn -f src/community/pom.xml -B -T4 -U -Prelease -PcommunityRelease
> -DskipTests clean install
> {noformat}
> Builds that normally take 2-4 minutes instead experience long hangs.
> {{jstack}} output (attached) suggests a deadlock (two different hangs
> attached). Some of the locks are in {{TIME_WAIT}} and eventually the build
> completes after 30-45 minutes, but this is enough to cause builds on Travis
> to be killed for their failure to output for ten minutes. (Travis upgraded to
> Maven 3.5.2 a week ago.)
> I have only seen the failures with -U. The hang does not occur in
> single-threaded builds. There are no "*.lock" files in the local repository
> during the hang so the deadlocks are not mediated by the filesystem. CPU
> utilisation is zero suggesting a deadlock not a livelock.
> See also discussion on the geoserver-devel mailing list:
> http://osgeo-org.1560.x6.nabble.com/Travis-failures-started-with-new-trusty-images-td5346836.html
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Closed] (MCOMPILER-316) maven should *always* print classpath used to compile the java files
[
https://issues.apache.org/jira/browse/MCOMPILER-316?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte closed MCOMPILER-316.
Resolution: Not A Problem
Assignee: Robert Scholte
> maven should *always* print classpath used to compile the java files
>
>
> Key: MCOMPILER-316
> URL: https://issues.apache.org/jira/browse/MCOMPILER-316
> Project: Maven Compiler Plugin
> Issue Type: Improvement
> Environment: ALL
>Reporter: Vimal
>Assignee: Robert Scholte
>
> mostly i use "{{maven clean install}}" to build my packages
> by default maven doesnt print the classpath used to compile java files. It
> should.
> it prints information like which jars it is downloading. thats fine.
> but it should *always* print the classpath used.
> there is a "-X" option which prints classpath , but it prints TONS and TONS
> of information which i think no one is interested in (except perhaps the
> maven developers)
> so there is no easy way to get the classpath used.
> Please make maven to print classpath for each java file compiled, by default.
> OR give a easy option to enable it along with other options.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (MCOMPILER-317) Plugin generates wrong modulepath (dependencies listed in wrong order)
[
https://issues.apache.org/jira/browse/MCOMPILER-317?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16298962#comment-16298962
]
Robert Scholte commented on MCOMPILER-317:
--
That's kind of what I meant with "There might be a deeper problem here ..." I
am really surprised if the order on the classpath is different to how we
explain it to the world. Requires further investigation.
> Plugin generates wrong modulepath (dependencies listed in wrong order)
> --
>
> Key: MCOMPILER-317
> URL: https://issues.apache.org/jira/browse/MCOMPILER-317
> Project: Maven Compiler Plugin
> Issue Type: Bug
>Affects Versions: 3.7.0
> Environment: Apache Maven 3.5.2
> (138edd61fd100ec658bfa2d307c43b76940a5d7d; 2017-10-18T03:58:13-04:00)
> Maven home: C:\Program Files\apache-maven-3.5.2\bin\..
> Java version: 9.0.1, vendor: Oracle Corporation
> Java home: C:\Program Files\Java\jdk-9.0.1
> Default locale: en_CA, platform encoding: Cp1252
> OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"
>Reporter: Gili
>
> Testcase: https://github.com/cowwoc/maven-java9-class-shadowing
> If a project contains dependencies with the same module name (which is valid
> according to https://stackoverflow.com/a/46573805/14731) then
> maven-compile-plugin invokes {{javac}} with a modulepath containing
> dependencies in an (apparently) arbitrary order. If I place the project in
> one directory, I get one order. If I place the project in another directory,
> I get another order. This is 100% reproducible across multiple runs, across
> different computers.
> I suspect that somewhere deep inside the code someone is using {{HashMap}}
> which is leading to undefined iteration order depending on the path being
> used.
> Expected behavior: dependencies should be listed in the same order as
> declared in pom.xml (see https://stackoverflow.com/a/793193/14731)
> Actual behavior: regardless of whether I list {{ExtensionPresent}} before or
> after {{MyLibrary}}, the wrong order gets passed to {{javac}}.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Assigned] (MPMD-243) excludeFromFailureFile configuration does not work
[
https://issues.apache.org/jira/browse/MPMD-243?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andreas Dangel reassigned MPMD-243:
---
Assignee: Andreas Dangel
> excludeFromFailureFile configuration does not work
> --
>
> Key: MPMD-243
> URL: https://issues.apache.org/jira/browse/MPMD-243
> Project: Maven PMD Plugin
> Issue Type: Bug
> Components: PMD
>Affects Versions: 3.2, 3.5, 3.7, 3.8
>Reporter: Benedikt Ritter
>Assignee: Andreas Dangel
>
> The excludeFromFailureFile configruation is ignored since version 3.1 of
> Maven PMD plugin. Here is my plugin configuration:
> {code}
>
> maven-pmd-plugin
>
> 3.8
>
> true
>
>
>
>
> check
>
>
>
> ${basedir}/config/pmd/pmd-exclude.properties
>
>
>
>
> {code}
> The pmd-exclude.properties file has the following content:
> {code}
> com.example.ClassWithLotsOfStaticImports=TooManyStaticImports
> {code}
> When I execude mvn clean pmd:check, I get a violation for
> ClassWithLotsOfStaticImports. It works with 3.0 and 3.1. I've testet several
> version above 3.1.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Comment Edited] (MNG-2751) Resource inheritance isn't additive
[
https://issues.apache.org/jira/browse/MNG-2751?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16298795#comment-16298795
]
Ohad Kravchick edited comment on MNG-2751 at 12/20/17 5:41 PM:
---
My [private] projects has a similar need. I am using the [jacoco code coverage
plugin|http://www.eclemma.org/jacoco/trunk/doc/maven.html] in a parent pom and
want to specify some default exclusions there (for example, {{**/Test*.java}}),
but to allow individual child project poms to *add* exclusions of their own.
was (Author: myok12):
My [private] projects has a similar need. I am using the
[http://www.eclemma.org/jacoco/trunk/doc/maven.html jacoco code coverage
plugin] in a parent pom and want to specify some default exclusions there (for
example, {{**/Test*.java}}), but to allow individual child project poms to
*add* exclusions of their own.
> Resource inheritance isn't additive
> ---
>
> Key: MNG-2751
> URL: https://issues.apache.org/jira/browse/MNG-2751
> Project: Maven
> Issue Type: Bug
> Components: Inheritance and Interpolation
>Affects Versions: 2.0.4
> Environment: All
>Reporter: Jason Melnick
>
> I have an inheritance model as such:
> Parent_POM (General dependencyManagement, pluginManagement, etc)
> |-->Base_POM (global dependency inclusion, default goal, default plugins, etc)
> |-->Artifact_POM (declares specific artifact type functionality,
> resources, profiles, etc)
> |-->Project_POM (project specific dependencies, resources, etc)
> I am attempting to create an hierarchy that will enable a new project to get
> up and running with very little modification. The issue I am having is if
> build.resources are declared in the Project_POM they are wiping the
> Artifact_POM's declarations.
> I think that resources should always be additive. If nothing else add an
> tag a la the plugin element's tag. In lieu of that
> perhaps a resourceManagement section that exposes resource id's that could be
> selectively added by the child...
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Comment Edited] (MNG-2751) Resource inheritance isn't additive
[
https://issues.apache.org/jira/browse/MNG-2751?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16298795#comment-16298795
]
Ohad Kravchick edited comment on MNG-2751 at 12/20/17 5:42 PM:
---
My [private] projects has a similar need. I am using the [jacoco code coverage
plugin|http://www.eclemma.org/jacoco/trunk/doc/maven.html] in a parent pom and
want to specify some default exclusions there (for example, {{**/Test*.java}}),
but to allow individual child project poms to *add* exclusions of their own.
Currently specifying exclusions in the child pom *overrides* the parent
exclusions and there's no workaround but to copy-paste the parent exclusions
into the child.
was (Author: myok12):
My [private] projects has a similar need. I am using the [jacoco code coverage
plugin|http://www.eclemma.org/jacoco/trunk/doc/maven.html] in a parent pom and
want to specify some default exclusions there (for example, {{**/Test*.java}}),
but to allow individual child project poms to *add* exclusions of their own.
> Resource inheritance isn't additive
> ---
>
> Key: MNG-2751
> URL: https://issues.apache.org/jira/browse/MNG-2751
> Project: Maven
> Issue Type: Bug
> Components: Inheritance and Interpolation
>Affects Versions: 2.0.4
> Environment: All
>Reporter: Jason Melnick
>
> I have an inheritance model as such:
> Parent_POM (General dependencyManagement, pluginManagement, etc)
> |-->Base_POM (global dependency inclusion, default goal, default plugins, etc)
> |-->Artifact_POM (declares specific artifact type functionality,
> resources, profiles, etc)
> |-->Project_POM (project specific dependencies, resources, etc)
> I am attempting to create an hierarchy that will enable a new project to get
> up and running with very little modification. The issue I am having is if
> build.resources are declared in the Project_POM they are wiping the
> Artifact_POM's declarations.
> I think that resources should always be additive. If nothing else add an
> tag a la the plugin element's tag. In lieu of that
> perhaps a resourceManagement section that exposes resource id's that could be
> selectively added by the child...
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Comment Edited] (MNG-2751) Resource inheritance isn't additive
[
https://issues.apache.org/jira/browse/MNG-2751?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16298795#comment-16298795
]
Ohad Kravchick edited comment on MNG-2751 at 12/20/17 5:40 PM:
---
My [private] projects has a similar need. I am using the
[http://www.eclemma.org/jacoco/trunk/doc/maven.html jacoco code coverage
plugin] in a parent pom and want to specify some default exclusions there (for
example, {{**/Test*.java}}), but to allow individual child project poms to
*add* exclusions of their own.
was (Author: myok12):
My [private] projects has a similar need. I am using the jacoco code coverage
plugin (http://www.eclemma.org/jacoco/trunk/doc/maven.html) in a parent pom and
want to specify some default exclusions there (for example, {{**/Test*.java}}),
but to allow individual child project poms to *add* exclusions of their own.
> Resource inheritance isn't additive
> ---
>
> Key: MNG-2751
> URL: https://issues.apache.org/jira/browse/MNG-2751
> Project: Maven
> Issue Type: Bug
> Components: Inheritance and Interpolation
>Affects Versions: 2.0.4
> Environment: All
>Reporter: Jason Melnick
>
> I have an inheritance model as such:
> Parent_POM (General dependencyManagement, pluginManagement, etc)
> |-->Base_POM (global dependency inclusion, default goal, default plugins, etc)
> |-->Artifact_POM (declares specific artifact type functionality,
> resources, profiles, etc)
> |-->Project_POM (project specific dependencies, resources, etc)
> I am attempting to create an hierarchy that will enable a new project to get
> up and running with very little modification. The issue I am having is if
> build.resources are declared in the Project_POM they are wiping the
> Artifact_POM's declarations.
> I think that resources should always be additive. If nothing else add an
> tag a la the plugin element's tag. In lieu of that
> perhaps a resourceManagement section that exposes resource id's that could be
> selectively added by the child...
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (MNG-2751) Resource inheritance isn't additive
[
https://issues.apache.org/jira/browse/MNG-2751?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16298795#comment-16298795
]
Ohad Kravchick commented on MNG-2751:
-
My [private] projects has a similar need. I am using the jacoco code coverage
plugin (http://www.eclemma.org/jacoco/trunk/doc/maven.html) in a parent pom and
want to specify some default exclusions there (for example, {{**/Test*.java}}),
but to allow individual child project poms to *add* exclusions of their own.
> Resource inheritance isn't additive
> ---
>
> Key: MNG-2751
> URL: https://issues.apache.org/jira/browse/MNG-2751
> Project: Maven
> Issue Type: Bug
> Components: Inheritance and Interpolation
>Affects Versions: 2.0.4
> Environment: All
>Reporter: Jason Melnick
>
> I have an inheritance model as such:
> Parent_POM (General dependencyManagement, pluginManagement, etc)
> |-->Base_POM (global dependency inclusion, default goal, default plugins, etc)
> |-->Artifact_POM (declares specific artifact type functionality,
> resources, profiles, etc)
> |-->Project_POM (project specific dependencies, resources, etc)
> I am attempting to create an hierarchy that will enable a new project to get
> up and running with very little modification. The issue I am having is if
> build.resources are declared in the Project_POM they are wiping the
> Artifact_POM's declarations.
> I think that resources should always be additive. If nothing else add an
> tag a la the plugin element's tag. In lieu of that
> perhaps a resourceManagement section that exposes resource id's that could be
> selectively added by the child...
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (MCOMPILER-317) Plugin generates wrong modulepath (dependencies listed in wrong order)
[
https://issues.apache.org/jira/browse/MCOMPILER-317?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16298413#comment-16298413
]
Gili commented on MCOMPILER-317:
[~rfscholte] It looks like the bug is in maven-project. See the comment I just
posted:
https://github.com/mojohaus/exec-maven-plugin/issues/91#issuecomment-353052306
> Plugin generates wrong modulepath (dependencies listed in wrong order)
> --
>
> Key: MCOMPILER-317
> URL: https://issues.apache.org/jira/browse/MCOMPILER-317
> Project: Maven Compiler Plugin
> Issue Type: Bug
>Affects Versions: 3.7.0
> Environment: Apache Maven 3.5.2
> (138edd61fd100ec658bfa2d307c43b76940a5d7d; 2017-10-18T03:58:13-04:00)
> Maven home: C:\Program Files\apache-maven-3.5.2\bin\..
> Java version: 9.0.1, vendor: Oracle Corporation
> Java home: C:\Program Files\Java\jdk-9.0.1
> Default locale: en_CA, platform encoding: Cp1252
> OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"
>Reporter: Gili
>
> Testcase: https://github.com/cowwoc/maven-java9-class-shadowing
> If a project contains dependencies with the same module name (which is valid
> according to https://stackoverflow.com/a/46573805/14731) then
> maven-compile-plugin invokes {{javac}} with a modulepath containing
> dependencies in an (apparently) arbitrary order. If I place the project in
> one directory, I get one order. If I place the project in another directory,
> I get another order. This is 100% reproducible across multiple runs, across
> different computers.
> I suspect that somewhere deep inside the code someone is using {{HashMap}}
> which is leading to undefined iteration order depending on the path being
> used.
> Expected behavior: dependencies should be listed in the same order as
> declared in pom.xml (see https://stackoverflow.com/a/793193/14731)
> Actual behavior: regardless of whether I list {{ExtensionPresent}} before or
> after {{MyLibrary}}, the wrong order gets passed to {{javac}}.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (MJAVADOC-507) -linkoffline rejects valid package-list files because of SSL problems
[
https://issues.apache.org/jira/browse/MJAVADOC-507?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hervé Boutemy updated MJAVADOC-507:
---
Description:
For weird reasons, we're trying to use rather than for
some of our links. Our configuration includes:
{code:xml}
https://checkerframework.org/api
https://checkerframework.org/api
{code}
If I run javadoc with -linkoffline set to this URL and location, I get links in
the resulting docs. However, if I run maven-javadoc-plugin, I get an error:
{noformat}[ERROR] Error fetching link:
https://checkerframework.org/api/package-list. Ignored it.{noformat}
Since javadoc can load the package-list fine and so can my browser, there seems
to be something wrong in maven-javadoc-plugin. To debug, I built my own
maven-javadoc-plugin, modified to display the full error that caused the
failure. It showed this:
{noformat}javax.net.ssl.SSLException: Certificate for
doesn't match any of the subject alternative names: [*.cs.washington.edu]
at
org.apache.http.conn.ssl.AbstractVerifier.verify(AbstractVerifier.java:165)
at
org.apache.http.conn.ssl.BrowserCompatHostnameVerifier.verify(BrowserCompatHostnameVerifier.java:61)
at
org.apache.http.conn.ssl.AbstractVerifier.verify(AbstractVerifier.java:141)
at
org.apache.http.conn.ssl.AbstractVerifier.verify(AbstractVerifier.java:114)
at
org.apache.http.conn.ssl.SSLSocketFactory.verifyHostname(SSLSocketFactory.java:580)
at
org.apache.http.conn.ssl.SSLSocketFactory.connectSocket(SSLSocketFactory.java:554)
at
org.apache.http.conn.ssl.SSLSocketFactory.connectSocket(SSLSocketFactory.java:412)
at
org.apache.http.impl.conn.DefaultClientConnectionOperator.openConnection(DefaultClientConnectionOperator.java:179)
at
org.apache.http.impl.conn.ManagedClientConnectionImpl.open(ManagedClientConnectionImpl.java:328)
at
org.apache.http.impl.client.DefaultRequestDirector.tryConnect(DefaultRequestDirector.java:612)
at
org.apache.http.impl.client.DefaultRequestDirector.execute(DefaultRequestDirector.java:447)
at
org.apache.http.impl.client.AbstractHttpClient.doExecute(AbstractHttpClient.java:884)
at
org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:82)
at
org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:107)
at
org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:55)
at
org.apache.maven.plugins.javadoc.JavadocUtil.isValidPackageList(JavadocUtil.java:1666){noformat}
Now, I *don't* see this error if I run with Java 9. This suggests to me that
each copy of Java has its own certificate list/logic. That means that the
problem isn't in maven-javadoc-plugin per se.
However, it seems inevitable that the built-in Java list will go out of date
again, and maven-javadoc-plugin will fail again for some other site.
One solution would be for maven-javadoc-plugin to do whatever it is that
Javadoc itself does to recognize more certificates. However, this sounds
complicated.
The simple solution would be for maven-javadoc-plugin to stop pre-validating
package-list files altogether (since Javadoc will ignore them if they're truly
missing). But, if you want to keep the validation, then I'd suggest passing all
URLs to Javadoc, even the ones that fail validation. That way, users still get
a loud, red/yellow Maven error/warning for real problems, but false problems
like the one here don't keep Javadoc links from working.
was:
For weird reasons, we're trying to use rather than for
some of our links. Our configuration includes:
https://checkerframework.org/api
https://checkerframework.org/api
If I run javadoc with -linkoffline set to this URL and location, I get links in
the resulting docs. However, if I run maven-javadoc-plugin, I get an error:
[ERROR] Error fetching link: https://checkerframework.org/api/package-list.
Ignored it.
Since javadoc can load the package-list fine and so can my browser, there seems
to be something wrong in maven-javadoc-plugin. To debug, I built my own
maven-javadoc-plugin, modified to display the full error that caused the
failure. It showed this:
javax.net.ssl.SSLException: Certificate for doesn't
match any of the subject alternative names: [*.cs.washington.edu]
at
org.apache.http.conn.ssl.AbstractVerifier.verify(AbstractVerifier.java:165)
at
org.apache.http.conn.ssl.BrowserCompatHostnameVerifier.verify(BrowserCompatHostnameVerifier.java:61)
at
org.apache.http.conn.ssl.AbstractVerifier.verify(AbstractVerifier.java:141)
at
org.apache.http.conn.ssl.AbstractVerifier.verify(AbstractVerifier.java:114)
at
org.apache.http.conn.ssl.SSLSocketFactory.verifyHostname(SSLSock
[jira] [Commented] (MPDF-84) display pdf generated file location
[ https://issues.apache.org/jira/browse/MPDF-84?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16298184#comment-16298184 ] Hudson commented on MPDF-84: Build succeeded in Jenkins: Maven TLP » maven-pdf-plugin » master #2 See https://builds.apache.org/job/maven-box/job/maven-pdf-plugin/job/master/2/ > display pdf generated file location > --- > > Key: MPDF-84 > URL: https://issues.apache.org/jira/browse/MPDF-84 > Project: Maven PDF Plugin > Issue Type: Improvement >Affects Versions: 1.3 >Reporter: Hervé Boutemy >Assignee: Hervé Boutemy > Fix For: 1.4 > > > just to help end users who don't know where to look in pom.xml, and in fact > should not need to look in pom.xml to get the resulting pdf -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (MCOMPILER-316) maven should *always* print classpath used to compile the java files
[
https://issues.apache.org/jira/browse/MCOMPILER-316?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16298174#comment-16298174
]
Vimal commented on MCOMPILER-316:
-
sorry, after compiling with -X, i dont see any {{javac.*}} files generated in
the {{target/classes}} folder.
although there is a generated {{target/ecj/log.xml}} file which contains all
the command line arguments to the {{Eclipse Java Compiler}} , including the
{{-classpath}} arguments.
This file is generated even without using the {{-X}} option.
perhaps this is what i was looking for.
you can close the issue. Thanks a lot for your support :) !!!
> maven should *always* print classpath used to compile the java files
>
>
> Key: MCOMPILER-316
> URL: https://issues.apache.org/jira/browse/MCOMPILER-316
> Project: Maven Compiler Plugin
> Issue Type: Improvement
> Environment: ALL
>Reporter: Vimal
>
> mostly i use "{{maven clean install}}" to build my packages
> by default maven doesnt print the classpath used to compile java files. It
> should.
> it prints information like which jars it is downloading. thats fine.
> but it should *always* print the classpath used.
> there is a "-X" option which prints classpath , but it prints TONS and TONS
> of information which i think no one is interested in (except perhaps the
> maven developers)
> so there is no easy way to get the classpath used.
> Please make maven to print classpath for each java file compiled, by default.
> OR give a easy option to enable it along with other options.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (MCOMPILER-318) Groovy files not been compiled when used with java9 spring boot
[
https://issues.apache.org/jira/browse/MCOMPILER-318?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16298152#comment-16298152
]
Yugant H Shah commented on MCOMPILER-318:
-
Getting below error :
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-compiler-plugin:3.7.0:compile (default-compile)
on project j9: Compilation failure -> [Help 1]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal
org.apache.maven.plugins:maven-compiler-plugin:3.7.0:compile (default-compile)
on project j9: Compilation failure
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:212)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:116)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:80)
at
org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
at
org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:128)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:307)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:193)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:106)
at org.apache.maven.cli.MavenCli.execute(MavenCli.java:863)
at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:288)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:199)
at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:564)
at
org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
at
org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
at
org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
at
org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
Caused by: org.apache.maven.plugin.compiler.CompilationFailureException:
Compilation failure
at
org.apache.maven.plugin.compiler.AbstractCompilerMojo.execute(AbstractCompilerMojo.java:1165)
at
org.apache.maven.plugin.compiler.CompilerMojo.execute(CompilerMojo.java:168)
at
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:134)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:207)
... 20 more
[ERROR]
[ERROR]
[ERROR] For more information about the errors and possible solutions, please
read the following articles:
[ERROR] [Help 1]
http://cwiki.apache.org/confluence/display/MAVEN/MojoFailureException
> Groovy files not been compiled when used with java9 spring boot
> ---
>
> Key: MCOMPILER-318
> URL: https://issues.apache.org/jira/browse/MCOMPILER-318
> Project: Maven Compiler Plugin
> Issue Type: Bug
>Affects Versions: 3.6.2, 3.7.0
>Reporter: Yugant H Shah
>Assignee: Robert Scholte
>Priority: Critical
> Attachments: JigsawTest-cleanup.zip, JigsawTest.zip, a.txt
>
>
> Compiling java9+ groovy + maven code base does not compile groovy files.
> Attached is the sample project
> {noformat}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-compiler-plugin:3.7.0:compile
> (default-compile) on project api: Compilation failure: Compilation failure:
> [ERROR] lombok/dummy/ForceNewRound0.java:[1,1] file should be on source path,
> or on patch path for module
> [ERROR]
> /Users/yushah/home/git/JigsawTest/com.allstate.jigsaw.api/src/main/java/com/allstate/jigsaw/ServiceA.java:[24,32]
> cannot find symbol
> [ERROR] symbol: class GroovyService
> [ERROR] location: package com.allstate.jigsaw
> [ERROR] -> [Help 1]
> [ERROR]
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
