[jira] [Created] (MPLUGIN-505) helpmojo: does not respect nested list in javadoc
Ernst Reissner created MPLUGIN-505: -- Summary: helpmojo: does not respect nested list in javadoc Key: MPLUGIN-505 URL: https://issues.apache.org/jira/browse/MPLUGIN-505 Project: Maven Plugin Tools Issue Type: Bug Affects Versions: 3.11.0 Reporter: Ernst Reissner In https://github.com/Reissner/latex-maven-plugin/blob/master/maven-latex-plugin/src/main/java/eu/simuline/m2latex/mojo/InjectionMojo.java there is an example of a parameter with documentation containing nested lists. I create the help with goal `helpmojo`. I display this with `mvn latex:help -Ddetail -Dgoal=inj` but this yields a list with one layer only. Obviously a bug. In the api doc, all is ok. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MNG-7927) nested setting of plugin ignored if empty
Ernst Reissner created MNG-7927: --- Summary: nested setting of plugin ignored if empty Key: MNG-7927 URL: https://issues.apache.org/jira/browse/MNG-7927 Project: Maven Issue Type: Bug Affects Versions: 3.9.4 Reporter: Ernst Reissner I have written a plugin, https://github.com/Reissner/latex-maven-plugin/, which uses nested configuration. ``` eu.simuline.m2latex latex-maven-plugin 2.0-SNAPSHOT ``` If as in the example a setting is really empty, its default is not changed. Instead, the default is obtained. This rarely becomes visible but is really difficult to find. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MSITE-989) Documentation for plugins in general: Goals comprises more than that.
Ernst Reissner created MSITE-989: Summary: Documentation for plugins in general: Goals comprises more than that. Key: MSITE-989 URL: https://issues.apache.org/jira/browse/MSITE-989 Project: Maven Site Plugin Issue Type: Bug Components: documentation Affects Versions: 4.0.0-M11 Reporter: Ernst Reissner In the `site.xml` of all plugins, there is an entry ``` ``` leading to an according entry in the sidebar menu. The item name is misleading: it should be Plugin Info or Plugin Documentation, because it is more than just Goals. Interesting enough, the goals do not have a separate subsection. Or it is called Goals and related.. I dont know. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MSITE-988) Documentation
Ernst Reissner created MSITE-988: Summary: Documentation Key: MSITE-988 URL: https://issues.apache.org/jira/browse/MSITE-988 Project: Maven Site Plugin Issue Type: Bug Components: documentation Affects Versions: 4.0.0-M9 Reporter: Ernst Reissner Create old pre-version 2.0.0 model. If using newer versions, 4.0.0-M9 to the current M11, then an error occurs: ``` Site model of 'eu.simuline.m2latex:latex-maven-plugin:maven-plugin:2.0-SNAPSHOT' for locale 'en' is still using the old pre-version 2.0.0 model. You MUST migrate to the new model as soon as possible otherwise your build will break in the future! ``` This is due to an old form of `site.xml` The first problem is the documentation, `https://maven.apache.org/plugins/maven-site-plugin/examples/sitedescriptor.html` which describes the old form and refers to the new one only in a link. What would be needed is a clear statement on the mapping of the version to the form. Also the new form is not completely supported: ``` http://maven.apache.org/SITE/2.0.0"; xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; xsi:schemaLocation="http://maven.apache.org/SITE/2.0.0 https://maven.apache.org/xsd/site-2.0.0.xsd";> ... ``` well, the link `https://maven.apache.org/xsd/site-2.0.0.xsd` does not exist, resulting in a warning in my IDE. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MPH-208) display leaf parameters if a parameter is a complex object
Ernst Reissner created MPH-208: -- Summary: display leaf parameters if a parameter is a complex object Key: MPH-208 URL: https://issues.apache.org/jira/browse/MPH-208 Project: Maven Help Plugin Issue Type: New Feature Components: describe Affects Versions: 3.4.0 Reporter: Ernst Reissner In my configuration I have a @Parameter named `settings` which is an object with fields again @Parameters. This is because I have a lot of parameters and this is a way to structure the parameters. The problem is, that `mvn latex:help -Ddetail=true` (`latex-maven-plugin` is my plugin) tells me only that `settings` is a parameter without displaying the parameters nested inside. Maybe I dont use this plugin properly, but then maybe some improvement in the documentation would be helpful. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MRESOURCES-300) filter with properties file and with pom properties
Ernst Reissner created MRESOURCES-300: - Summary: filter with properties file and with pom properties Key: MRESOURCES-300 URL: https://issues.apache.org/jira/browse/MRESOURCES-300 Project: Maven Resources Plugin Issue Type: New Feature Components: filtering Affects Versions: 3.3.1 Reporter: Ernst Reissner My intention is to filter with a filter properties file and with the properties from pom. The properties file was for the defaults and the pom to override. To that end, I wanted to filter with pom first, i.e. without properties file to an intermediate place and then further with a properties file. If a property occurs in the pom, then the first filter step yields the right value and is not affected by the second step. If it does not occur in the pom then only the second step, applying the properties file affects it. Now I found out, that seemingly, even in presence of a properties file the pom affects filtering. Fortunately, the pom seems to be applied first so i do not need a second step. My problem is just that I use an undocumented feature. Also it worked a bit by accident. I would suggest to offer a way to configure when the pom is applied, first or last, or to document, that the pom is always applied first, which means that it overwrites other occurance. I feel also that this mechanism is worth being mentioned: if one and the same property occurs several times, the first occurance overwrites the ohers. Some suggestion to improve usability is to add an example of filtering with properties file in goal copy-resouces, as it is really different from goal resources. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MDEP-878) Unexpected failure in mappers: no empty replacement or extension possible
Ernst Reissner created MDEP-878:
---
Summary: Unexpected failure in mappers: no empty replacement or
extension possible
Key: MDEP-878
URL: https://issues.apache.org/jira/browse/MDEP-878
Project: Maven Dependency Plugin
Issue Type: New Feature
Reporter: Ernst Reissner
I have the following configuration:
```
eu.simuline.m2latex
latex-maven-plugin
${versionLatexPlugin}
jar
true
src/main/resources
.latexmkrc.raw
c.raw$
c
```
As you can see, I tricked.
i wanted just to replace `.raw` by the empty string.
This was not possible and I think, an empty replacement is fully valid.
Also I would have used the `FileExtensionMapper`, but also this does not accept
an empty extension.
Analogously I think, this should be allowed.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (MDEP-877) goal unpack: ignores path in includes/excludes
Ernst Reissner created MDEP-877:
---
Summary: goal unpack: ignores path in includes/excludes
Key: MDEP-877
URL: https://issues.apache.org/jira/browse/MDEP-877
Project: Maven Dependency Plugin
Issue Type: New Feature
Components: unpack
Affects Versions: 3.6.0
Reporter: Ernst Reissner
in my jar i have files
- .latexmkrc and
- raw/.latexmkrc
I want to extract only .latexmkrc
So I configure:
```
eu.simuline.m2latex
latex-maven-plugin
${versionLatexPlugin}
jar
true
${latexDir}
.latexmkrc,
.chktexrc
```
But what is extracted is still raw/.latexmkrc.
Even if i add `raw/.latexmkrc` this does not help.
I have the impression, the config just ignores all but the file name.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (MPLUGIN-476) Cannot invoke "com.thoughtworks.qdox.model.JavaField.getName()" because "field" is null
Ernst Reissner created MPLUGIN-476:
--
Summary: Cannot invoke
"com.thoughtworks.qdox.model.JavaField.getName()" because "field" is null
Key: MPLUGIN-476
URL: https://issues.apache.org/jira/browse/MPLUGIN-476
Project: Maven Plugin Tools
Issue Type: New Feature
Components: Plugin Plugin
Affects Versions: 3.9.0
Reporter: Ernst Reissner
I write a plugin (https://github.com/Reissner/latex-maven-plugin)
and `mvn clean deploy` results in following message:
```
[INFO] --- plugin:3.9.0:descriptor (default-descriptor) @ latex-maven-plugin ---
[INFO] Using 'UTF-8' encoding to read mojo source files.
[INFO]
[INFO] BUILD FAILURE
[INFO]
[INFO] Total time: 14.056 s
[INFO] Finished at: 2023-06-22T09:29:29+02:00
[INFO]
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-plugin-plugin:3.9.0:descriptor
(default-descriptor) on project latex-maven-plugin: Execution
default-descriptor of goal
org.apache.maven.plugins:maven-plugin-plugin:3.9.0:descriptor failed: Cannot
invoke "com.thoughtworks.qdox.model.JavaField.getName()" because "field" is
null -> [Help 1]
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e
switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[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/PluginExecutionException
```
After long search (1 night) I found the following 'reason':
```
package eu.simuline.m2latex.core;
public enum Target {
txt() {
private final String TXT_OUTPUT_FILES = "^T$T\\.txt$";
// may throw BuildFailureException TEX01
public void processSource(LatexProcessor latexProcessor,
LatexMainDesc desc) throws
BuildFailureException {
latexProcessor.processLatex2txt(desc);
}
public String getPatternOutputFiles(Settings settings) {
return "^T$T\\.txt$";
}
}, ...;
...
}
```
Removing the line
```
private final String TXT_OUTPUT_FILES = "^T$T\\.txt$";
```
'resolves' the problem.
I feel this could indicate not just a bug but a conceptual flaw.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MINSTALL-170) more control over what artifacts to be installed.
[ https://issues.apache.org/jira/browse/MINSTALL-170?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17629276#comment-17629276 ] Ernst Reissner commented on MINSTALL-170: - @KHM: yes! i managed far later and it works... Still I would be curious about how the install plugin determines what in fact to install. I cannot figure out the mechanism and there is no documentation, well I found no documentation on this subject at all. Maybe a good idea just to add documentation. @SJ: which feedback you need from me? > more control over what artifacts to be installed. > -- > > Key: MINSTALL-170 > URL: https://issues.apache.org/jira/browse/MINSTALL-170 > Project: Maven Install Plugin > Issue Type: Improvement > Components: install:install >Affects Versions: 3.0.0-M1 >Reporter: Ernst Reissner >Priority: Major > Fix For: waiting-for-feedback > > > Maybe it is the wrong way to file a feature request but maybe this is the > best way to come into contact with the development team. > My problem is that I want to deploy both a jar and a tar.gz file. > The latter I create with an assembly plugin. > Unfortunately, the assembly plugin forces the name > `artifact-version-assId.tar.gz` > and offers no way to have empty assId. > The tar.gz is used in another software which strictly speaking requires > `artifact-version.tar.gz`. > So I had the simple idea to just move `artifact-version-assId.tar.gz` to > `artifact-version.tar.gz` > using exec plugin in a phase before install. > Well of course i want the install plugin to install now > `artifact-version.tar.gz` instead of `artifact-version-assId.tar.gz`. > But the install plugin still wants to use the original artifact. > My somehow academical question would be how install plugin determines the > artifact to be installed and to modify that info appropriately. > It seems to have nothing to do with the packaging as the original tar.gz is > installed also. > If I need to define another kind of packaging installing other kinds of > artifacts, > may I reuse the install plugin > Help very much appreciated. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MRELEASE-1092) Synch with changes plugin
Ernst Reissner created MRELEASE-1092: Summary: Synch with changes plugin Key: MRELEASE-1092 URL: https://issues.apache.org/jira/browse/MRELEASE-1092 Project: Maven Release Plugin Issue Type: New Feature Components: prepare Affects Versions: 3.0.0-M5 Reporter: Ernst Reissner the changes plugin is based on the file changes.xml. It is a sequence of releases each covering the changes made in the current release. The form is ```[xml] ... ``` I suggest, that the release plugin shall check whether - the version is the version to be - the date is the current date - the description is not empty. If all this is true, on can assume that the release element is maintained. One should advise to start with empty version and empty date and empty description. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (MJAVADOC-699) mathjax based on dependency
[
https://issues.apache.org/jira/browse/MJAVADOC-699?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ernst Reissner updated MJAVADOC-699:
Description:
For including math in api docs I use mathjax.
To that end i configure the javadoc plugin as follows:
{noformat}
-Xdoclint:all
-Xdoclint:-missing
--allow-script-in-comments
{noformat}
you can see that I download the config from
{noformat}
https://www.simuline.eu/MathJax/config/myDefault.js
{noformat}
I think this is not what I want to do, because it is public and unversioned.
Have a look at
https://maven.apache.org/plugins/maven-javadoc-plugin/examples/help-configuration.html
describing javadoc plugins concept for helpfiles:
it is based on dependencies.
This is a quite general solution also other plugins make use of
as summarized in https://adangel.org/2016/02/22/sharing-pmd-rulesets/:
It is on
- Checkstyle configuration
- PMD configuration
- FindBugs configuration
- Code-Formatting configuration for IDEs
- ...
My suggestion is to use that also for mathjax config and maybe also for the
converter
which is http://cdn.mathjax.org/mathjax/latest/MathJax.js?config=TeX-AMS_HTML
in my case but I would also prefer a local solution with specified version (in
my case 'latest').
The suggestion is to make the javadoc configurable in the following way:
```
org.apache.maven.plugins
maven-javadoc-plugin
3.4.0
path to rendererin dependency/myrenderer.txt
path to config in dependency/myconfig.js
com.mycompany.project
configs
0.0.1-SNAPSHOT
```
This is much like the javadoc plugin allows for helpfiles.
The project in the dependency looks like so:
```
config-
|- pom.xml
|- src-main-resources-com-mycompany-project-configs
|- myrenderer.txt
|- myconfig.js
```
Here myconfig contains the config of mathjax in javascript
and myrenderer contains the url of the renderer.
To implement that, the javadoc plugin must only create two
[jira] [Created] (MJAVADOC-699) mathjax based on dependency
Ernst Reissner created MJAVADOC-699: --- Summary: mathjax based on dependency Key: MJAVADOC-699 URL: https://issues.apache.org/jira/browse/MJAVADOC-699 Project: Maven Javadoc Plugin Issue Type: New Feature Components: javadoc Affects Versions: next-release Reporter: Ernst Reissner For including math in api docs I use mathjax. To that end i configure the javadoc plugin as follows: ``` -Xdoclint:all -Xdoclint:-missing --allow-script-in-comments ``` you can see that I download the config from ``` https://www.simuline.eu/MathJax/config/myDefault.js ``` I think this is not what I want to do, because it is public and unversioned. Have a look at https://maven.apache.org/plugins/maven-javadoc-plugin/examples/help-configuration.html describing javadoc plugins concept for helpfiles: it is based on dependencies. This is a quite general solution also other plugins make use of as summarized in https://adangel.org/2016/02/22/sharing-pmd-rulesets/: It is on - Checkstyle configuration - PMD configuration - FindBugs configuration - Code-Formatting configuration for IDEs - ... My suggestion is to use that also for mathjax config and maybe also for the converter which is http://cdn.mathjax.org/mathjax/latest/MathJax.js?config=TeX-AMS_HTML in my case but I would also prefer a local solution with specified version (in my case 'latest'). -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (MASSEMBLY-950) assemblies without identifier
Ernst Reissner created MASSEMBLY-950: Summary: assemblies without identifier Key: MASSEMBLY-950 URL: https://issues.apache.org/jira/browse/MASSEMBLY-950 Project: Maven Assembly Plugin Issue Type: Improvement Components: component descriptor Affects Versions: 3.3.0 Reporter: Ernst Reissner I have an application where I use the assembly plugin to create a package file for computation software called octave. It is just a file artifactId-version.tar.gz with a predefined folder structure. The problem is that the assembly plugin doesnt do without an assembly identifier. Then the result is something like artifactId-version-assId.tar.gz. Strictly speaking, octave needs the first kind of name without assId. My workaround is to copy xxx-assId.tar.gz to xxx.tar.gz but then the install plugin fails expecting still xxx-assId.tar.gz. My question is now whether it is possible to allow empty assid in case there is a single assembly only. This would solve my problem. The other way to solve is, maybe to understand how the install plugin finds out what to install. Does the assembly plugin pass any kind of information?? I cannot imagine. Help, in any way, very much appreciated. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (MINSTALL-170) more control over what artifacts to be installed.
Ernst Reissner created MINSTALL-170: --- Summary: more control over what artifacts to be installed. Key: MINSTALL-170 URL: https://issues.apache.org/jira/browse/MINSTALL-170 Project: Maven Install Plugin Issue Type: Improvement Components: install:install Affects Versions: 3.0.0-M1 Reporter: Ernst Reissner Maybe it is the wrong way to file a feature request but maybe this is the best way to come into contact with the development team. My problem is that I want to deploy both a jar and a tar.gz file. The latter I create with an assembly plugin. Unfortunately, the assembly plugin forces the name `artifact-version-assId.tar.gz` and offers no way to have empty assId. The tar.gz is used in another software which strictly speaking requires `artifact-version.tar.gz`. So I had the simple idea to just move `artifact-version-assId.tar.gz` to `artifact-version.tar.gz` using exec plugin in a phase before install. Well of course i want the install plugin to install now `artifact-version.tar.gz` instead of `artifact-version-assId.tar.gz`. But the install plugin still wants to use the original artifact. My somehow academical question would be how install plugin determines the artifact to be installed and to modify that info appropriately. It seems to have nothing to do with the packaging as the original tar.gz is installed also. If I need to define another kind of packaging installing other kinds of artifacts, may I reuse the install plugin Help very much appreciated. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (MJAVADOC-672) misleading Exit code: 2 - javadoc: error - No source files for package jopas
Ernst Reissner created MJAVADOC-672:
---
Summary: misleading Exit code: 2 - javadoc: error - No source
files for package jopas
Key: MJAVADOC-672
URL: https://issues.apache.org/jira/browse/MJAVADOC-672
Project: Maven Javadoc Plugin
Issue Type: Improvement
Components: javadoc
Affects Versions: 3.1.1
Reporter: Ernst Reissner
Configuration is done as follows:
{code:java}
// code
org.apache.maven.plugins
maven-javadoc-plugin
3.1.1
src/main/java:src/test/java
todo
a
what is to be done in the present code fragment;
jopas only
To.Do
a
ToDo:
...
{code}
The outcoming when doing mvn javadoc:test-javadoc is as follows:
ERROR] Failed to execute goal
org.apache.maven.plugins:maven-javadoc-plugin:3.1.1:test-javadoc (default-cli)
on project l2r: An error has occurred in Test Javadoc report generation:
[ERROR] Exit code: 2 - javadoc: error - No source files for package jopas
[ERROR]
[ERROR] Command line was: /usr/lib64/jvm/java/bin/javadoc @options @argfile
[ERROR]
[ERROR] Refer to the generated Javadoc files in
'/home/ernst/Software/target/site/testapidocs' dir.
Note that the package is not org.jopas, but just jopas.
In the tag definition, there is a line break just before jopas.
If I remove that line break, all works fine.
I think this gives indication to very gragilepom reading.. either this plugin
or maven.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (SUREFIRE-1861) failsafe shall use jar
[
https://issues.apache.org/jira/browse/SUREFIRE-1861?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17238665#comment-17238665
]
Ernst Reissner commented on SUREFIRE-1861:
--
I give you my config:
```
org.apache.maven.plugins
maven-failsafe-plugin
3.0.0-M5
true
false
true
TestVersion.java
run-tests
integration-test
integration-test
verify
```
so you see i did what you say.
then i commanded `{color:#00}mvn failsafe:integration-test{color}`
but the result was just
```
{color:#00}[{color}{color:#5454ff}INFO{color}{color:#00}] Running
eu.simuline.octave.{color}{color:#00}TestVersion{color}
[{color:#ff5454}ERROR{color}{color:#00}] {color}{color:#ff5454}Tests
{color}{color:#00}run: 4{color}{color:#00},
{color}{color:#ff5454}Failures: 1{color}{color:#00}, Errors: 0, Skipped: 0,
Time elapsed: 1.589 s{color}{color:#ff5454} <<< FAILURE!{color}{color:#00}
- in eu.simuline.octave.{color}{color:#00}TestVersion{color}
[{color:#ff5454}ERROR{color}{color:#00}]
eu.simuline.octave.TestVersion.testOctaveJavaVersion Time elapsed: 0.142 s
<<< FAILURE! {color}
java.lang.AssertionError: wrong version of octavejava expected:<0.7-SNAPSHOT>
but was:
at
eu.simuline.octave.TestVersion.testOctaveJavaVersion(TestVersion.java:58)
```
coming from the following piece of code:
```
@Test public void testOctaveJavaVersion() {
final OctaveEngine octave = new OctaveEngineFactory().getScriptEngine();
assertEquals("wrong version of octavejava",
"0.7-SNAPSHOT",
octave.getOctaveInJavaVersion());
}
```
with both variants of
```
public String getOctaveInJavaVersion() {
//System.out.println("MANIFEST_INFO: "+MANIFEST_INFO);
//return MANIFEST_INFO.getImplVersion();
return
eu.simuline.octave.OctaveEngine.class.getPackage().getImplementationVersion();
}
```
I want to say something on the documentation
[https://maven.apache.org/surefire/maven-failsafe-plugin/examples/class-loading.html]
It seems only to be on two internal strategies to build a classpath.
I never bring this in a relation to properties in the manifest of a jar file.
Also I dont have problems loading any classes, they load just fine.
The problem is, that the manifest does not 'load'.
A word on debugging output:
I was wrong, yes test classes are a directory always,
but the debug output does not show the jar loaded either.
I think that shall be part of the output in debugging mode.
> failsafe shall use jar
> --
>
> Key: SUREFIRE-1861
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1861
> Project: Maven Surefire
> Issue Type: Improvement
> Components: Maven Failsafe Plugin
>Affects Versions: 3.0.0-M5
> Environment: all
>Reporter: Ernst Reissner
>Priority: Critical
> Original Estimate: 24h
> Remaining Estimate: 24h
>
> To run tests based on information stored in jar only but not in
> testClassesDirectory,
> the plugin shall load classes from the jar instead.
> That way, one could check also presence of vendor information,
> or versions, or git state or whatsoever meta information
> to be supplied to the user and stored in the jar.
>
> The jar is always available though since we are in a late lifecycle phase.
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (SUREFIRE-1861) failsafe shall use jar
[
https://issues.apache.org/jira/browse/SUREFIRE-1861?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17237692#comment-17237692
]
Ernst Reissner commented on SUREFIRE-1861:
--
You wont believe: I found this site before but to be honest: cannot understand
it really.
It seems as if it talks about technical realization.
It is not a user documentation, is it?
I tried several configurations also with system class loader.. No success.
I tried also
```
mvn -X integraton-test
```
and the debugging looks as follows:
```
{color:#00}[{color}{color:#54}DEBUG{color}{color:#00}] Configuring
mojo org.apache.maven.plugins:maven-failsafe-plugin:3.0.0-M5:verify from plugin
realm ClassRealm[plugin>org.apach{color}
e.maven.plugins:maven-failsafe-plugin:3.0.0-M5, parent:
jdk.internal.loader.ClassLoaders$AppClassLoader@277050dc]
[{color:#54}DEBUG{color}{color:#00}] Configuring mojo
'org.apache.maven.plugins:maven-failsafe-plugin:3.0.0-M5:verify' with basic
configurator --> {color}
[{color:#54}DEBUG{color}{color:#00}] (s) basedir =
/home/ernst/OpenSource/OctaveInJavaGit/octaveInJava/javaoctave {color}
[{color:#54}DEBUG{color}{color:#00}] (s) reportsDirectory =
/home/ernst/OpenSource/OctaveInJavaGit/octaveInJava/javaoctave/target/failsafe-reports
{color}
[{color:#54}DEBUG{color}{color:#00}] (f) session =
org.apache.maven.execution.MavenSession@7df76d99 {color}
[{color:#54}DEBUG{color}{color:#00}] (s) skip = false {color}
[{color:#54}DEBUG{color}{color:#00}] (f) summaryFile =
/home/ernst/OpenSource/OctaveInJavaGit/octaveInJava/javaoctave/target/failsafe-reports/failsafe-summary.x{color}
ml
[{color:#54}DEBUG{color}{color:#00}] (s) testClassesDirectory =
/home/ernst/OpenSource/OctaveInJavaGit/octaveInJava/javaoctave/target/test-classes
{color}
[{color:#54}DEBUG{color}{color:#00}] (s) testFailureIgnore = false
{color}
[{color:#54}DEBUG{color}{color:#00}] -- end configuration -- {color}
[{color:#54}DEBUG{color}{color:#00}] Failsafe report directory:
/home/ernst/OpenSource/OctaveInJavaGit/octaveInJava/javaoctave/target/failsafe-reports
{color}
```
The point isthat the `testClassesDirectory` is not the jar which has been
created.
But this I would expect
> failsafe shall use jar
> --
>
> Key: SUREFIRE-1861
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1861
> Project: Maven Surefire
> Issue Type: Improvement
> Components: Maven Failsafe Plugin
>Affects Versions: 3.0.0-M5
> Environment: all
>Reporter: Ernst Reissner
>Priority: Critical
> Original Estimate: 24h
> Remaining Estimate: 24h
>
> To run tests based on information stored in jar only but not in
> testClassesDirectory,
> the plugin shall load classes from the jar instead.
> That way, one could check also presence of vendor information,
> or versions, or git state or whatsoever meta information
> to be supplied to the user and stored in the jar.
>
> The jar is always available though since we are in a late lifecycle phase.
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (SUREFIRE-1861) failsafe shall use jar
[
https://issues.apache.org/jira/browse/SUREFIRE-1861?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17236237#comment-17236237
]
Ernst Reissner commented on SUREFIRE-1861:
--
Maybe it is ok to give less than a whole project.
Assume there is a method
```
public String getOctaveInJavaVersion() {
return this.getClass().getPackage().getImplementationVersion();
}
```
This returns the implementation version,
but only, if the jar from which this class is loaded
contains some file `META-INF/MANIFEST.MF`
which has a section which looks somehow like that:
```
Name: eu/simuline/octave/
Extension-name: eu.simuline.octave
Specification-Version: 0.7
Implementation-Version: 0.7.1-SNAPSHOT
```
Here, eu.simuline.octave is the package of the above class.
As said, this works fine but cannot be tested:
with surefire plugin, it cannot be tested because it runs in phase test
where no jar is created yet.
In contrast, failsafe plugin, testing in phase integration-test has a jar
available.
Nevertheless, it uses still the unpackaged classes to load.
Thus a test on the version does not work in any test plugin.
I would suggest to at least allow test based on the jar created.
> failsafe shall use jar
> --
>
> Key: SUREFIRE-1861
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1861
> Project: Maven Surefire
> Issue Type: Improvement
> Components: Maven Failsafe Plugin
>Affects Versions: 3.0.0-M5
> Environment: all
>Reporter: Ernst Reissner
>Priority: Critical
> Original Estimate: 24h
> Remaining Estimate: 24h
>
> To run tests based on information stored in jar only but not in
> testClassesDirectory,
> the plugin shall load classes from the jar instead.
> That way, one could check also presence of vendor information,
> or versions, or git state or whatsoever meta information
> to be supplied to the user and stored in the jar.
>
> The jar is always available though since we are in a late lifecycle phase.
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (SUREFIRE-1861) failsafe shall use jar
Ernst Reissner created SUREFIRE-1861: Summary: failsafe shall use jar Key: SUREFIRE-1861 URL: https://issues.apache.org/jira/browse/SUREFIRE-1861 Project: Maven Surefire Issue Type: Improvement Components: Maven Failsafe Plugin Affects Versions: 3.0.0-M5 Environment: all Reporter: Ernst Reissner To run tests based on information stored in jar only but not in testClassesDirectory, the plugin shall load classes from the jar instead. That way, one could check also presence of vendor information, or versions, or git state or whatsoever meta information to be supplied to the user and stored in the jar. The jar is always available though since we are in a late lifecycle phase. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (SUREFIRE-1838) Ability to run an inner class or a method within
Ernst Reissner created SUREFIRE-1838: Summary: Ability to run an inner class or a method within Key: SUREFIRE-1838 URL: https://issues.apache.org/jira/browse/SUREFIRE-1838 Project: Maven Surefire Issue Type: Bug Components: Junit 4.x support Affects Versions: 3.0.0-M5 Reporter: Ernst Reissner invocations like ``` mvn surefire:test -Dtest=XFPNumberTest$AxField$AddGroup ``` do not restrict to inner classes as expected. The same with methods within. In fact, this prevents single methods from being invoked individually, if test classes are nested like in ``` mvn surefire:test -Dtest=XFPNumberTest$AxField$AddGroup.testXXX ``` -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (MNG-6356) property from list element in pom model
[
https://issues.apache.org/jira/browse/MNG-6356?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ernst Reissner updated MNG-6356:
Description:
I tried to filter $\{project.developers[0].email}
Although mvn help:evaluate finds the correct answer, filtering does not work
else.
Even if i havein the properties section of the pom one of the three
ernst.reiss...@simuline.eu
${project.organization.name}
$\{project.developers[0].email}
the latter is not replaced and just comes litterally.
Update: I added a minimal project
comprising a pom and some resource to be filtered.
What we see is, that ${project.organization.name} is filtered,
whereas $\{project.developers[0].email} is not: remains literal.
Also I think, better than developers[0] would be a way to use a label,
e.g. a key, like an identifier. (but this is a feature request. )
was:
I tried to filter ${project.developers[0].email}
Although mvn help:evaluate finds the correct answer, filtering does not work
else.
Even if i havein the properties section of the pom one of the three
ernst.reiss...@simuline.eu
${project.organization.name}
${project.developers[0].email}
the latter is not replaced and just comes litterally.
> property from list element in pom model
> ---
>
> Key: MNG-6356
> URL: https://issues.apache.org/jira/browse/MNG-6356
> Project: Maven
> Issue Type: Bug
>Affects Versions: 3.5.2
> Environment: linux
>Reporter: Ernst Reissner
>Priority: Major
> Fix For: waiting-for-feedback, wontfix-candidate
>
> Attachments: project.tar
>
>
> I tried to filter $\{project.developers[0].email}
> Although mvn help:evaluate finds the correct answer, filtering does not work
> else.
> Even if i havein the properties section of the pom one of the three
> ernst.reiss...@simuline.eu
> ${project.organization.name}
> $\{project.developers[0].email}
> the latter is not replaced and just comes litterally.
>
> Update: I added a minimal project
> comprising a pom and some resource to be filtered.
> What we see is, that ${project.organization.name} is filtered,
> whereas $\{project.developers[0].email} is not: remains literal.
>
> Also I think, better than developers[0] would be a way to use a label,
> e.g. a key, like an identifier. (but this is a feature request. )
>
>
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Updated] (MNG-6356) property from list element in pom model
[
https://issues.apache.org/jira/browse/MNG-6356?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ernst Reissner updated MNG-6356:
Attachment: project.tar
> property from list element in pom model
> ---
>
> Key: MNG-6356
> URL: https://issues.apache.org/jira/browse/MNG-6356
> Project: Maven
> Issue Type: Bug
>Affects Versions: 3.5.2
> Environment: linux
>Reporter: Ernst Reissner
>Priority: Major
> Fix For: waiting-for-feedback, wontfix-candidate
>
> Attachments: project.tar
>
>
> I tried to filter ${project.developers[0].email}
> Although mvn help:evaluate finds the correct answer, filtering does not work
> else.
> Even if i havein the properties section of the pom one of the three
> ernst.reiss...@simuline.eu
> ${project.organization.name}
> ${project.developers[0].email}
> the latter is not replaced and just comes litterally.
>
>
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Created] (MPMD-289) check: unable to find pmd.xml
Ernst Reissner created MPMD-289:
---
Summary: check: unable to find pmd.xml
Key: MPMD-289
URL: https://issues.apache.org/jira/browse/MPMD-289
Project: Maven PMD Plugin
Issue Type: Bug
Affects Versions: 3.12.0
Reporter: Ernst Reissner
With format html, the pmd.xml seems not to be generated.
Consequently, check whether there are no failures fails.
This problem does not occur when format is pmd.
Below i showed my pom.
org.apache.maven.plugins
maven-pmd-plugin
${versionPmdMvnPlugin}
net.sourceforge.pmd
pmd-core
${versionPmd}
net.sourceforge.pmd
pmd-java
${versionPmd}
true
${project.build.sourceEncoding}
100
false
false
html
check
cpd-check
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (MCHANGES-399) change report: add further column: date
Ernst Reissner created MCHANGES-399: --- Summary: change report: add further column: date Key: MCHANGES-399 URL: https://issues.apache.org/jira/browse/MCHANGES-399 Project: Maven Changes Plugin Issue Type: New Feature Reporter: Ernst Reissner As an action in a changes file has the attributes dev, type, date and allows for description text, would be nice if for all of that there were a column in the changes report. Only the date is missing. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (MCHANGES-398) link to developer (by column) broken
Ernst Reissner created MCHANGES-398: --- Summary: link to developer (by column) broken Key: MCHANGES-398 URL: https://issues.apache.org/jira/browse/MCHANGES-398 Project: Maven Changes Plugin Issue Type: Bug Affects Versions: 2.12.1 Reporter: Ernst Reissner In the changes-report still links to team-list.html, instead of team.html. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (MSOURCES-107) documentation of configuration
Ernst Reissner created MSOURCES-107: --- Summary: documentation of configuration Key: MSOURCES-107 URL: https://issues.apache.org/jira/browse/MSOURCES-107 Project: Maven Source Plugin Issue Type: Bug Affects Versions: 3.0.1 Reporter: Ernst Reissner Seems as if includes also work. So the documentation for the plugin is incomplete. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (MJAR-245) Additional attached jar: role of classifyer
Ernst Reissner created MJAR-245: --- Summary: Additional attached jar: role of classifyer Key: MJAR-245 URL: https://issues.apache.org/jira/browse/MJAR-245 Project: Maven JAR Plugin Issue Type: Bug Components: site Affects Versions: 3.0.2 Reporter: Ernst Reissner On [https://maven.apache.org/plugins/maven-jar-plugin/examples/attached-jar.html,] a classifier is given. Missing information: creates a jar file: project-version-classifier.jar. This is vital. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (MJAR-244) Missing documentation: unsatisfied link
Ernst Reissner created MJAR-244: --- Summary: Missing documentation: unsatisfied link Key: MJAR-244 URL: https://issues.apache.org/jira/browse/MJAR-244 Project: Maven JAR Plugin Issue Type: Bug Components: site Affects Versions: 3.0.2 Reporter: Ernst Reissner On homepage [https://maven.apache.org/plugins/maven-jar-plugin/] the link "Creating an executable jar file" is not satisfied. Is this no longer possible? Then this has to be removed. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (MNG-6356) property from list element in pom model
Ernst Reissner created MNG-6356:
---
Summary: property from list element in pom model
Key: MNG-6356
URL: https://issues.apache.org/jira/browse/MNG-6356
Project: Maven
Issue Type: Bug
Affects Versions: 3.5.2
Environment: linux
Reporter: Ernst Reissner
I tried to filter ${project.developers[0].email}
Although mvn help:evaluate finds the correct answer, filtering does not work
else.
Even if i havein the properties section of the pom one of the three
ernst.reiss...@simuline.eu
${project.organization.name}
${project.developers[0].email}
the latter is not replaced and just comes litterally.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (MJAVADOC-503) link from package-info.java to classes do no longer work
Ernst Reissner created MJAVADOC-503:
---
Summary: link from package-info.java to classes do no longer work
Key: MJAVADOC-503
URL: https://issues.apache.org/jira/browse/MJAVADOC-503
Project: Maven Javadoc Plugin
Issue Type: Bug
Components: javadoc
Affects Versions: 3.0.0
Environment: linux
Reporter: Ernst Reissner
This bug has been introduced in version 3.0.0, definitively not present in
3.0;0.-M1:
{@link ClassName} within package-info.java no longer works for ClassName in the
same package.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (MSITE-803) checkstyle version 8.4 not accessible.
[ https://issues.apache.org/jira/browse/MSITE-803?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ernst Reissner updated MSITE-803: - Description: One may use checkstyle plugin for various versions of checkstyle e.g. 8.4 specifying com.puppycrawl.tools checkstyle 8.4 e.g. in the pluginManagement. In contrast, it is not possible to specify this in the reporting section. As a workaround, i would prefer adding a checkstyleVersion property in the configuration. Not that by default the plugin used checkstyle 6.11.2 whereas the current is 8.4. An even less expensive workaround would be to deliver the plugin invoking a more recent version of checkstyle. I would prefer at least 7.2. It is bad that so various features are not accessible, as e.g. designforextension is not reported if @Override found. was: One may use checkstyle plugin for various versions of checkstyle e.g. 8.4 specifying com.puppycrawl.tools checkstyle 8.4 e.g. in the pluginManagement. In contrast, it is not possible to specify this in the reporting section. As a workaround, i would prefer adding a checkstyleVersion property in the configuration. Not that by default the plugin used checkstyle 6.11.2 whereas the current is 8.4. It is bad that so various features are not accessible, as e.g. designforextension is not reported if @Override found. > checkstyle version 8.4 not accessible. > --- > > Key: MSITE-803 > URL: https://issues.apache.org/jira/browse/MSITE-803 > Project: Maven Site Plugin > Issue Type: Wish >Reporter: Ernst Reissner > > One may use checkstyle plugin for various versions of checkstyle e.g. 8.4 > specifying > > com.puppycrawl.tools > checkstyle > 8.4 > > e.g. in the pluginManagement. > In contrast, it is not possible to specify this in the reporting section. > As a workaround, i would prefer adding a checkstyleVersion property > in the configuration. > Not that by default the plugin used checkstyle 6.11.2 > whereas the current is 8.4. > An even less expensive workaround would be to deliver the plugin > invoking a more recent version of checkstyle. > I would prefer at least 7.2. > It is bad that so various features are not accessible, as e.g. > designforextension > is not reported if @Override found. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (MSITE-803) checkstyle version 8.4 not accessible.
[ https://issues.apache.org/jira/browse/MSITE-803?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ernst Reissner updated MSITE-803: - Description: One may use checkstyle plugin for various versions of checkstyle e.g. 8.4 specifying com.puppycrawl.tools checkstyle 8.4 e.g. in the pluginManagement. In contrast, it is not possible to specify this in the reporting section. As a workaround, i would prefer adding a checkstyleVersion property in the configuration. Not that by default the plugin used checkstyle 6.11.2 whereas the current is 8.4. It is bad that so various features are not accessible, as e.g. designforextension is not reported if @Override found. was: One may use checkstyle plugin for various versions of checkstyle e.g. 8.4 specifying com.puppycrawl.tools checkstyle 8.4 e.g. in the pluginManagement. In contrast, it is not possible to specify this in the reporting section. As a workaround, i would prefer adding a checkstyleVersion property in the configuration. Not that by default the plugin used checkstyle 6.11.2 whereas the current is 8.4. Description > checkstyle version 8.4 not accessible. > --- > > Key: MSITE-803 > URL: https://issues.apache.org/jira/browse/MSITE-803 > Project: Maven Site Plugin > Issue Type: Wish >Reporter: Ernst Reissner > > One may use checkstyle plugin for various versions of checkstyle e.g. 8.4 > specifying > > com.puppycrawl.tools > checkstyle > 8.4 > > e.g. in the pluginManagement. > In contrast, it is not possible to specify this in the reporting section. > As a workaround, i would prefer adding a checkstyleVersion property > in the configuration. > Not that by default the plugin used checkstyle 6.11.2 > whereas the current is 8.4. > It is bad that so various features are not accessible, as e.g. > designforextension > is not reported if @Override found. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (MSITE-803) checkstyle version 8.4 not accessible.
[ https://issues.apache.org/jira/browse/MSITE-803?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ernst Reissner updated MSITE-803: - Environment: (was: One may use checkstyle plugin for various versions of checkstyle e.g. 8.4 specifying com.puppycrawl.tools checkstyle 8.4 e.g. in the pluginManagement. In contrast, it is not possible to specify this in the reporting section. As a workaround, i would prefer adding a checkstyleVersion property in the configuration. Not that by default the plugin used checkstyle 6.11.2 whereas the current is 8.4. ) > checkstyle version 8.4 not accessible. > --- > > Key: MSITE-803 > URL: https://issues.apache.org/jira/browse/MSITE-803 > Project: Maven Site Plugin > Issue Type: Wish >Reporter: Ernst Reissner > > One may use checkstyle plugin for various versions of checkstyle e.g. 8.4 > specifying > > com.puppycrawl.tools > checkstyle > 8.4 > > e.g. in the pluginManagement. > In contrast, it is not possible to specify this in the reporting section. > As a workaround, i would prefer adding a checkstyleVersion property > in the configuration. > Not that by default the plugin used checkstyle 6.11.2 > whereas the current is 8.4. > Description -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (MSITE-803) checkstyle version 8.4 not accessible.
[ https://issues.apache.org/jira/browse/MSITE-803?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ernst Reissner updated MSITE-803: - Description: One may use checkstyle plugin for various versions of checkstyle e.g. 8.4 specifying com.puppycrawl.tools checkstyle 8.4 e.g. in the pluginManagement. In contrast, it is not possible to specify this in the reporting section. As a workaround, i would prefer adding a checkstyleVersion property in the configuration. Not that by default the plugin used checkstyle 6.11.2 whereas the current is 8.4. Description > checkstyle version 8.4 not accessible. > --- > > Key: MSITE-803 > URL: https://issues.apache.org/jira/browse/MSITE-803 > Project: Maven Site Plugin > Issue Type: Wish > Environment: One may use checkstyle plugin for various versions of > checkstyle e.g. 8.4 > specifying > > com.puppycrawl.tools > checkstyle > 8.4 > > e.g. in the pluginManagement. > In contrast, it is not possible to specify this in the reporting section. > As a workaround, i would prefer adding a checkstyleVersion property > in the configuration. > Not that by default the plugin used checkstyle 6.11.2 > whereas the current is 8.4. >Reporter: Ernst Reissner > > One may use checkstyle plugin for various versions of checkstyle e.g. 8.4 > specifying > > com.puppycrawl.tools > checkstyle > 8.4 > > e.g. in the pluginManagement. > In contrast, it is not possible to specify this in the reporting section. > As a workaround, i would prefer adding a checkstyleVersion property > in the configuration. > Not that by default the plugin used checkstyle 6.11.2 > whereas the current is 8.4. > Description -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (MSITE-803) checkstyle version 8.4 not accessible.
Ernst Reissner created MSITE-803: Summary: checkstyle version 8.4 not accessible. Key: MSITE-803 URL: https://issues.apache.org/jira/browse/MSITE-803 Project: Maven Site Plugin Issue Type: Wish Environment: One may use checkstyle plugin for various versions of checkstyle e.g. 8.4 specifying com.puppycrawl.tools checkstyle 8.4 e.g. in the pluginManagement. In contrast, it is not possible to specify this in the reporting section. As a workaround, i would prefer adding a checkstyleVersion property in the configuration. Not that by default the plugin used checkstyle 6.11.2 whereas the current is 8.4. Reporter: Ernst Reissner -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (SUREFIRE-1442) report icons missing
Ernst Reissner created SUREFIRE-1442: Summary: report icons missing Key: SUREFIRE-1442 URL: https://issues.apache.org/jira/browse/SUREFIRE-1442 Project: Maven Surefire Issue Type: Bug Components: Maven Surefire Report Plugin Affects Versions: 2.20.1 Environment: linux Reporter: Ernst Reissner pom: org.apache.maven.plugins maven-surefire-report-plugin 2.20.1 false mvn surefire-report:report Then in reports the icons which can be seen in the docs are missing. I suspect, that in the docs one must add the information how to add the icons. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (SUREFIRE-1443) surefire report: broken links with inner classes
Ernst Reissner created SUREFIRE-1443: Summary: surefire report: broken links with inner classes Key: SUREFIRE-1443 URL: https://issues.apache.org/jira/browse/SUREFIRE-1443 Project: Maven Surefire Issue Type: Bug Components: Maven Surefire Report Plugin Affects Versions: 2.20.1 Environment: linux Reporter: Ernst Reissner Attachments: RelanaTest.java, surefire-report.html pom: org.apache.maven.plugins maven-surefire-report-plugin 2.20.1 false testclass as attached. Then tying mvn surefire-report:report yields waning [warn] [XHTML Sink] Modified invalid anchor name: 'eu.simuline.relana.sysRelanaTest$TestAll' to 'eu.simuline.relana.sysRelanaTestTestAll' and in the created html this can be seen: dot between sys and RelanaTest missing. Partially with $ , partially without so that links are broken I attached also the hmtl. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (MENFORCER-285) error parameters 'rules' are missing or invalid
Ernst Reissner created MENFORCER-285: Summary: error parameters 'rules' are missing or invalid Key: MENFORCER-285 URL: https://issues.apache.org/jira/browse/MENFORCER-285 Project: Maven Enforcer Plugin Issue Type: Bug Components: Plugin Affects Versions: 3.0.0-M1 Environment: linux Reporter: Ernst Reissner I have the following config under build.plugins: org.apache.maven.plugins maven-enforcer-plugin 3.0.0-M1 enforce enforce 3.5.0 true true Then mvn enforcer:enforce yields [ERROR] Failed to execute goal org.apache.maven.plugins:maven-enforcer-plugin:3.0.0-M1:enforce (default-cli) on project Relana: The parameters 'rules' for goal org.apache.maven.plugins:maven-enforcer-plugin:3.0.0-M1:enforce are missing or invalid -> [Help 1] org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal org.apache.maven.plugins:maven-enforcer-plugin:3.0.0-M1:enforce (default-cli) on project Relana: The parameters 'rules' for goal org.apache.maven.plugins:maven-enforcer-plugin:3.0.0-M1:enforce are missing or invalid at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:213) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:154) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:146) at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:117) at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:81) 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:309) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:194) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:107) at org.apache.maven.cli.MavenCli.execute(MavenCli.java:993) at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:345) at org.apache.maven.cli.MavenCli.main(MavenCli.java:191) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) 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.PluginParameterException: The parameters 'rules' for goal org.apache.maven.plugins:maven-enforcer-plugin:3.0.0-M1:enforce are missing or invalid at org.apache.maven.plugin.internal.DefaultMavenPluginManager.populatePluginFields(DefaultMavenPluginManager.java:643) at org.apache.maven.plugin.internal.DefaultMavenPluginManager.getConfiguredMojo(DefaultMavenPluginManager.java:596) at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:121) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208) ... 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/PluginParameterException -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (MSITE-800) site:deploy
Ernst Reissner created MSITE-800: Summary: site:deploy Key: MSITE-800 URL: https://issues.apache.org/jira/browse/MSITE-800 Project: Maven Site Plugin Issue Type: Bug Environment: any Reporter: Ernst Reissner Lack in documentation: for goal site:deploy one needs in distributionManagement of the pom somenthing like fileSite file:///home/ernst/Software/RepositoryTarget/Site instead of fileRepository file:///home/ernst/Software/RepositoryTarget This shall be documented on teh site. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Closed] (MPMD-222) ruleset via rulesetfile does not work
[
https://issues.apache.org/jira/browse/MPMD-222?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ernst Reissner closed MPMD-222.
---
Resolution: Won't Fix
Fix Version/s: 3.6
It turned out to be a bug in pmd.
I will file a bug report at proper place.
In addition I posted a simple workaround.
> ruleset via rulesetfile does not work
> -
>
> Key: MPMD-222
> URL: https://issues.apache.org/jira/browse/MPMD-222
> Project: Maven PMD Plugin
> Issue Type: Bug
> Components: PMD
>Affects Versions: 3.6
> Environment: uname -a
> Linux linux-tanr.site 4.1.21-14-default #1 SMP PREEMPT Sun Apr 17 07:27:45
> UTC 2016 (fc187c1) x86_64 x86_64 x86_64 GNU/Linux
>Reporter: Ernst Reissner
> Labels: patch
> Fix For: 3.6
>
>
> in my pom i wrote
>
> org.apache.maven.plugins
> maven-pmd-plugin
> 3.6
>
> false
>
> ${maven.pmd.rulesetfiles}
>
> and maven.pmd.rulesetfiles is defined as
> maven.pmd.rulesetfiles>${basedir}/config/myruleset.xml
> which in turn looks like this:
>
> xmlns="http://pmd.sourceforge.net/ruleset/2.0.0";
>xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
>xsi:schemaLocation="http://pmd.sourceforge.net/ruleset/2.0.0
> http://pmd.sourceforge.net/ruleset_2_0_0.xsd";>
>
>
> Then a violation of SignatureDeclareThrowsException is not detected,
> whereas if directly specifying
>
> org.apache.maven.plugins
> maven-pmd-plugin
> 3.6
>
> false
>
>
> rulesets/java/typeresolution.xml/SignatureDeclareThrowsException
> it works fine.
> So I think it is not a problem with pmd but with the plugin.
>
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MPMD-222) ruleset via rulesetfile does not work
[
https://issues.apache.org/jira/browse/MPMD-222?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15324062#comment-15324062
]
Ernst Reissner commented on MPMD-222:
-
Hi,
I found the solution for me: the name
SignatureDeclareThrowsException comes twice and implements not exactly the same
rule.
If I write:
http://pmd.sourceforge.net/ruleset/2.0.0";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
xsi:schemaLocation="http://pmd.sourceforge.net/ruleset/2.0.0
http://pmd.sourceforge.net/ruleset_2_0_0.xsd";>
including the wanted rule only, then it works.
With both rules, one overwrites the other one.
So it is indeed a bug in pmd.
I found out because ant behaves like mvn.
Regards.
> ruleset via rulesetfile does not work
> -
>
> Key: MPMD-222
> URL: https://issues.apache.org/jira/browse/MPMD-222
> Project: Maven PMD Plugin
> Issue Type: Bug
> Components: PMD
>Affects Versions: 3.6
> Environment: uname -a
> Linux linux-tanr.site 4.1.21-14-default #1 SMP PREEMPT Sun Apr 17 07:27:45
> UTC 2016 (fc187c1) x86_64 x86_64 x86_64 GNU/Linux
>Reporter: Ernst Reissner
> Labels: patch
>
> in my pom i wrote
>
> org.apache.maven.plugins
> maven-pmd-plugin
> 3.6
>
> false
>
> ${maven.pmd.rulesetfiles}
>
> and maven.pmd.rulesetfiles is defined as
> maven.pmd.rulesetfiles>${basedir}/config/myruleset.xml
> which in turn looks like this:
>
> xmlns="http://pmd.sourceforge.net/ruleset/2.0.0";
>xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
>xsi:schemaLocation="http://pmd.sourceforge.net/ruleset/2.0.0
> http://pmd.sourceforge.net/ruleset_2_0_0.xsd";>
>
>
> Then a violation of SignatureDeclareThrowsException is not detected,
> whereas if directly specifying
>
> org.apache.maven.plugins
> maven-pmd-plugin
> 3.6
>
> false
>
>
> rulesets/java/typeresolution.xml/SignatureDeclareThrowsException
> it works fine.
> So I think it is not a problem with pmd but with the plugin.
>
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (MPMD-223) compete with ant
Ernst Reissner created MPMD-223: --- Summary: compete with ant Key: MPMD-223 URL: https://issues.apache.org/jira/browse/MPMD-223 Project: Maven PMD Plugin Issue Type: New Feature Components: PMD Affects Versions: 3.6 Environment: all Reporter: Ernst Reissner https://pmd.github.io/pmd-5.4.2/usage/ant-task.html describes the access on pmd via ant. This is about all which is possible via command line. I think, the maven plugin should compete with this. In particular, it is useful to allow to specify the formatter and toFile. Currently, not the file is given but the directory to write the file into. This is not what is needed. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MPMD-222) ruleset via rulesetfile does not work
[
https://issues.apache.org/jira/browse/MPMD-222?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ernst Reissner updated MPMD-222:
Fix Version/s: (was: 3.7)
> ruleset via rulesetfile does not work
> -
>
> Key: MPMD-222
> URL: https://issues.apache.org/jira/browse/MPMD-222
> Project: Maven PMD Plugin
> Issue Type: Bug
> Components: PMD
>Affects Versions: 3.6
> Environment: uname -a
> Linux linux-tanr.site 4.1.21-14-default #1 SMP PREEMPT Sun Apr 17 07:27:45
> UTC 2016 (fc187c1) x86_64 x86_64 x86_64 GNU/Linux
>Reporter: Ernst Reissner
> Labels: patch
>
> in my pom i wrote
>
> org.apache.maven.plugins
> maven-pmd-plugin
> 3.6
>
> false
>
> ${maven.pmd.rulesetfiles}
>
> and maven.pmd.rulesetfiles is defined as
> maven.pmd.rulesetfiles>${basedir}/config/myruleset.xml
> which in turn looks like this:
>
> xmlns="http://pmd.sourceforge.net/ruleset/2.0.0";
>xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
>xsi:schemaLocation="http://pmd.sourceforge.net/ruleset/2.0.0
> http://pmd.sourceforge.net/ruleset_2_0_0.xsd";>
>
>
> Then a violation of SignatureDeclareThrowsException is not detected,
> whereas if directly specifying
>
> org.apache.maven.plugins
> maven-pmd-plugin
> 3.6
>
> false
>
>
> rulesets/java/typeresolution.xml/SignatureDeclareThrowsException
> it works fine.
> So I think it is not a problem with pmd but with the plugin.
>
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MPMD-220) Upgrade to PMD 5.4.1
[ https://issues.apache.org/jira/browse/MPMD-220?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15321551#comment-15321551 ] Ernst Reissner commented on MPMD-220: - This is really important. I wonder whether someone currently works on this plugin.. seem no activity. > Upgrade to PMD 5.4.1 > > > Key: MPMD-220 > URL: https://issues.apache.org/jira/browse/MPMD-220 > Project: Maven PMD Plugin > Issue Type: Task >Reporter: Mathieu BONIFACE > > As 5.4.1 is out and provide some interesting improvements and bugfixes, it > would be great for us to upgrade the maven plugin with this new version of > PMD. > Another important change is pmd > 5.4.0 requires Java >= 1.7.0 (see APi > Changes [here|http://sourceforge.net/projects/pmd/files/pmd/5.4.0/]) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (MPMD-222) ruleset via rulesetfile does not work
Ernst Reissner created MPMD-222:
---
Summary: ruleset via rulesetfile does not work
Key: MPMD-222
URL: https://issues.apache.org/jira/browse/MPMD-222
Project: Maven PMD Plugin
Issue Type: Bug
Components: PMD
Affects Versions: 3.6
Environment: uname -a
Linux linux-tanr.site 4.1.21-14-default #1 SMP PREEMPT Sun Apr 17 07:27:45 UTC
2016 (fc187c1) x86_64 x86_64 x86_64 GNU/Linux
Reporter: Ernst Reissner
Fix For: 3.7
in my pom i wrote
org.apache.maven.plugins
maven-pmd-plugin
3.6
false
${maven.pmd.rulesetfiles}
and maven.pmd.rulesetfiles is defined as
maven.pmd.rulesetfiles>${basedir}/config/myruleset.xml
which in turn looks like this:
http://pmd.sourceforge.net/ruleset/2.0.0";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
xsi:schemaLocation="http://pmd.sourceforge.net/ruleset/2.0.0
http://pmd.sourceforge.net/ruleset_2_0_0.xsd";>
Then a violation of SignatureDeclareThrowsException is not detected,
whereas if directly specifying
org.apache.maven.plugins
maven-pmd-plugin
3.6
false
rulesets/java/typeresolution.xml/SignatureDeclareThrowsException
it works fine.
So I think it is not a problem with pmd but with the plugin.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
