[jira] (MCHECKSTYLE-242) fine grained ignore of violations
[
https://jira.codehaus.org/browse/MCHECKSTYLE-242?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=350547#comment-350547
]
Herve Boutemy edited comment on MCHECKSTYLE-242 at 10/11/14 1:55 AM:
-
done in [r1614200|http://svn.apache.org/r1614200]
now we can ignore a rule or a category with checkstyle.violation.ignore property
{code:xml}
AvoidStaticImport,design
{code}
was (Author: hboutemy):
done in [r1614200|http://svn.apache.org/r1614200]
> fine grained ignore of violations
> -
>
> Key: MCHECKSTYLE-242
> URL: https://jira.codehaus.org/browse/MCHECKSTYLE-242
> Project: Maven Checkstyle Plugin
> Issue Type: New Feature
>Affects Versions: 2.12.1
>Reporter: Herve Boutemy
>Assignee: Herve Boutemy
> Fix For: 2.13
>
>
> checkstyle:check defines a violation by a minimum severity
> then if a rule cause unwanted violation, you can only either fix it or
> completely disable all checks
> being able to ignore some rules or rule categories would permit more fine
> grained disabling
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (SUREFIRE-1080) Use parallel and fork together run some tests multiple times
[ https://jira.codehaus.org/browse/SUREFIRE-1080?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=354207#comment-354207 ] Tibor Digana commented on SUREFIRE-1080: Fixed in https://github.com/apache/maven-surefire/pull/56 > Use parallel and fork together run some tests multiple times > > > Key: SUREFIRE-1080 > URL: https://jira.codehaus.org/browse/SUREFIRE-1080 > Project: Maven Surefire > Issue Type: Bug > Environment: Apache Maven 3.2.2-SNAPSHOT > Surefire 2.18-SNAPSHOT > JUnit 4.11 >Reporter: Qingzhou Luo >Assignee: Tibor Digana > Fix For: 2.18 > > Attachments: test.tgz > > > There are 9 tests in total in the attached project, and mvn test will show 9 > tests run. When I use the command " mvn test -Dparallel=classes > -DforkCount=2 -DuseUnlimitedThreads=true", it shows 13 tests run (and > sometimes 16), and some tests are run more than once. > If I remove forkCount, or parallel, everything will be fine. But it is > problematic when combining together. > Apache Maven 3.2.2-SNAPSHOT > Surefire 2.18-SNAPSHOT > JUnit 4.11 > Thanks! -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MJAVADOC-310) compiler plugin settings aren't inherited from parent tor linking Java API links
[
https://jira.codehaus.org/browse/MJAVADOC-310?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=354203#comment-354203
]
Michael Osipov edited comment on MJAVADOC-310 at 10/10/14 2:30 PM:
---
If so, we should rework
[this|http://maven.apache.org/plugins/maven-javadoc-plugin/xref/org/apache/maven/plugin/javadoc/AbstractJavadocMojo.html#L5506]
and remove that call from all plugins. {{JavadocVersion}} should be set to
{{maven.compiler.source}}. What do you think?
was (Author: michael-o):
If so, we should rework
[this|http://maven.apache.org/plugins/maven-javadoc-plugin/xref/org/apache/maven/plugin/javadoc/AbstractJavadocMojo.html#L5506]
and remove that call from all plugins. JavadocVersion should be set to
{{maven.compiler.source}}. What do you think?
> compiler plugin settings aren't inherited from parent tor linking Java API
> links
>
>
> Key: MJAVADOC-310
> URL: https://jira.codehaus.org/browse/MJAVADOC-310
> Project: Maven Javadoc Plugin
> Issue Type: Bug
>Affects Versions: 2.7
> Environment: Maven 2.2.1, maven-compiler-plugin 2.3.2
>Reporter: Michael Osipov
>
> I set my m-c-p version in my parent's pluginManagement section but did not
> alter source and target because I am fine with 1.5.
> Now another project references it and complains that the above setting is not
> available:
> {noformat}
> [INFO] Generating "JavaDocs" report.
> [DEBUG] No maven-compiler-plugin defined in ${build.plugins} or in
> ${project.build.pluginManagement} for the
> :url-provider-api:jar:0.1-SNAPSHOT. Added Javadoc API link according
> the javadoc executable version i.e.: 1.6
> [DEBUG] Found Java API link: http://java.sun.com/javase/6/docs/api/
> [DEBUG] Try to add links for dependencies...
> {noformat}
> The behavior is incorrect. Either m-javadoc-p ignores the plugin's default
> settings or it does not merge the model.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MJAVADOC-310) compiler plugin settings aren't inherited from parent tor linking Java API links
[
https://jira.codehaus.org/browse/MJAVADOC-310?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=354203#comment-354203
]
Michael Osipov commented on MJAVADOC-310:
-
If so, we should rework
[this|http://maven.apache.org/plugins/maven-javadoc-plugin/xref/org/apache/maven/plugin/javadoc/AbstractJavadocMojo.html#L5506]
and remove that call from all plugins. JavadocVersion should be set to
{{maven.compiler.source}}. What do you think?
> compiler plugin settings aren't inherited from parent tor linking Java API
> links
>
>
> Key: MJAVADOC-310
> URL: https://jira.codehaus.org/browse/MJAVADOC-310
> Project: Maven Javadoc Plugin
> Issue Type: Bug
>Affects Versions: 2.7
> Environment: Maven 2.2.1, maven-compiler-plugin 2.3.2
>Reporter: Michael Osipov
>
> I set my m-c-p version in my parent's pluginManagement section but did not
> alter source and target because I am fine with 1.5.
> Now another project references it and complains that the above setting is not
> available:
> {noformat}
> [INFO] Generating "JavaDocs" report.
> [DEBUG] No maven-compiler-plugin defined in ${build.plugins} or in
> ${project.build.pluginManagement} for the
> :url-provider-api:jar:0.1-SNAPSHOT. Added Javadoc API link according
> the javadoc executable version i.e.: 1.6
> [DEBUG] Found Java API link: http://java.sun.com/javase/6/docs/api/
> [DEBUG] Try to add links for dependencies...
> {noformat}
> The behavior is incorrect. Either m-javadoc-p ignores the plugin's default
> settings or it does not merge the model.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MJAVADOC-384) Allow whitespace in javadoc exclude list
[ https://jira.codehaus.org/browse/MJAVADOC-384?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Scholte updated MJAVADOC-384: Issue Type: Improvement (was: Bug) > Allow whitespace in javadoc exclude list > > > Key: MJAVADOC-384 > URL: https://jira.codehaus.org/browse/MJAVADOC-384 > Project: Maven Javadoc Plugin > Issue Type: Improvement >Affects Versions: 2.9.1 >Reporter: Omair Majid >Priority: Minor > Attachments: spaces-for-javadoc-exclude-list > > > One of the projects that I am working on has a fairly large exclude list for > javadoc packages. maven-javadoc-plugin requires me to put this in on line in > the pom, which makes it very hard to read. I think it would > be nicer to allow separating the items in the list with newlines and other > whitespace characters. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MJAVADOC-384) Allow whitespace in javadoc exclude list
[ https://jira.codehaus.org/browse/MJAVADOC-384?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=354202#comment-354202 ] Robert Scholte commented on MJAVADOC-384: - I'd prefer to have a mechanism which works for field (in general for Maven configurations), including those which have spaces. Instead I'd suggest to split by comma and trim those values. I think that will have the same result. > Allow whitespace in javadoc exclude list > > > Key: MJAVADOC-384 > URL: https://jira.codehaus.org/browse/MJAVADOC-384 > Project: Maven Javadoc Plugin > Issue Type: Bug >Affects Versions: 2.9.1 >Reporter: Omair Majid >Priority: Minor > Attachments: spaces-for-javadoc-exclude-list > > > One of the projects that I am working on has a fairly large exclude list for > javadoc packages. maven-javadoc-plugin requires me to put this in on line in > the pom, which makes it very hard to read. I think it would > be nicer to allow separating the items in the list with newlines and other > whitespace characters. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MJAVADOC-357) Error Generating Javadoc with javadoc:fix.
[
https://jira.codehaus.org/browse/MJAVADOC-357?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte updated MJAVADOC-357:
Description:
I found a problem creating javadoc comments with goal javadoc:fix when I
execute this goal multiple times on the same project. Comment for some
constructor parameter are duplicated during different execution. Following the
constructor:
{code}
public AnagraficaIstituto(String codice, String descrizione, String codiceAbi,
String siglaIstituto, Date dataOraInizioValidita, Date dataOraFineValidita,
Date dataOraImmissione,
String terminaleImmissione, String operatoreImmissione,
String enteImmissione, String ufficioImmissione, String sezioneImmissione,
String canaleImmissione, Date dataOraCancellazione,
String terminaleCancellazione, String
operatoreCancellazione, String enteCancellazione, String ufficioCancellazione,
String sezioneCancellazione, String canaleCancellazione,
Set
storicoDatiAggiuntiviDatoElementareProdottos, Set
anagraficaVistas,
Set anagraficaQualificatores,
Set anagraficaDatiAggiuntiviTemplates,
Set anagraficaImmaginis,
Set anagraficaProdottos,
Set anagraficaCollegamentoProdottos,
Set anagraficaContatoreProdottis,
Set anagraficaEventis,
Set anagraficaTipologiaModulos,
Set anagraficaCapitolos,
Set
anagraficaRegoleVendibilitas, Set anagraficaAllegatos,
Set anagraficaTipoProdottos,
Set anagraficaFornitores,
Set anagraficaModulos, Set
anagraficaDatiAggiuntiviGruppos,
Set anagraficaPromoziones,
Set anagraficaDatiAggiuntiviAttributos,
Set anagraficaListinos,
Set
anagraficaDatiAggiuntiviDatoElementares,
Set anagraficaDatiAggiuntiviSottogruppos) {
{code}
On first execution javadoc comments are generated correctly, but during
subsequent executions the "codiceAbi" parameter is generated over and over
(second execution 2 times, third execution 6 times etc.)
was:
I found a problem creating javadoc comments with goal javadoc:fix when I
execute this goal multiple times on the same project. Comment for some
constructor parameter are duplicated during different execution. Following the
constructor:
public AnagraficaIstituto(String codice, String descrizione, String codiceAbi,
String siglaIstituto, Date dataOraInizioValidita, Date dataOraFineValidita,
Date dataOraImmissione,
String terminaleImmissione, String operatoreImmissione,
String enteImmissione, String ufficioImmissione, String sezioneImmissione,
String canaleImmissione, Date dataOraCancellazione,
String terminaleCancellazione, String
operatoreCancellazione, String enteCancellazione, String ufficioCancellazione,
String sezioneCancellazione, String canaleCancellazione,
Set
storicoDatiAggiuntiviDatoElementareProdottos, Set
anagraficaVistas,
Set anagraficaQualificatores,
Set anagraficaDatiAggiuntiviTemplates,
Set anagraficaImmaginis,
Set anagraficaProdottos,
Set anagraficaCollegamentoProdottos,
Set anagraficaContatoreProdottis,
Set anagraficaEventis,
Set anagraficaTipologiaModulos,
Set anagraficaCapitolos,
Set
anagraficaRegoleVendibilitas, Set anagraficaAllegatos,
Set anagraficaTipoProdottos,
Set anagraficaFornitores,
Set anagraficaModulos, Set
anagraficaDatiAggiuntiviGruppos,
Set anagraficaPromoziones,
Set anagraficaDatiAggiuntiviAttributos,
Set anagraficaListinos,
Set
anagraficaDatiAggiuntiviDatoElementares,
Set anagraficaDatiAggiuntiviSottogruppos) {
On first execution javadoc comments are generated correctly, but during
subsequent executions the "codiceAbi" parameter is generated over and over
(second execution 2 times, third execution 6 times etc.)
> Error Generating Javadoc with javadoc:fix.
> --
>
> Key: MJAVADOC-357
> URL: https://jira.codehaus.org/browse/MJAVADOC-357
> Project: Maven Javadoc Plugin
> Issue Type: Bug
>Affects Versions: 2.7, 2.8, 2.9
>Reporter: Massimo Albertin
>
> I found a problem creating javadoc comments with goal javadoc:fix when I
> execute this goal multiple times on the same project. Comment for some
> constructor parameter are duplicated during different execution. Following
> the constructor:
> {code}
> public AnagraficaIstituto(String codice, String descrizione, String
> codiceAbi, String siglaIstituto, Date dataOraInizioValidita, Date
> dataOraFineValidita, Date dataOraImmissione,
> String terminaleImmissione, String operatoreImmissione,
[jira] (MJAVADOC-324) Dependency sources support appears to require javadoc-resources
[ https://jira.codehaus.org/browse/MJAVADOC-324?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Scholte closed MJAVADOC-324. --- Resolution: Incomplete Assignee: Robert Scholte > Dependency sources support appears to require javadoc-resources > --- > > Key: MJAVADOC-324 > URL: https://jira.codehaus.org/browse/MJAVADOC-324 > Project: Maven Javadoc Plugin > Issue Type: Bug >Affects Versions: 2.8 > Environment: Win 7 >Reporter: Brian Albers >Assignee: Robert Scholte > > I cannot seem to get the support to work. Although > I have scoped the dependencies down using various combinations of > and , as well as > setting to false, no iteration ever > succeeds. > Instead, the javadoc:jar goal complains of being unable to find the > "javadoc-resources" for a whole slew of dependencies. > None of my projects or dependencies use javadoc-resources. They are all very > basic Javascript JARs with minimal configuration. > I noticed that part of the 2.7 release (revision 933380) added support for > javadoc-resource bundle aggregation, as well. Is the javadoc-resources search > not scoped to the include/exclude list? -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MJAVADOC-253) Http proxy does not work any more
[ https://jira.codehaus.org/browse/MJAVADOC-253?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Scholte closed MJAVADOC-253. --- Resolution: Won't Fix Assignee: Robert Scholte Assuming this works with Maven-2.2.1, which is the current prerequisite for the plugin. > Http proxy does not work any more > - > > Key: MJAVADOC-253 > URL: https://jira.codehaus.org/browse/MJAVADOC-253 > Project: Maven Javadoc Plugin > Issue Type: Bug >Affects Versions: 2.6, 2.7 > Environment: Maven 2.0.9 > JDK5 (Sun) >Reporter: Mohan K >Assignee: Robert Scholte > > It appears the update of Wagon Provider in 2.6 is not compatible with Maven > 2.0.x. Here is the > email snippet as posted to maven users group (no responses) > I am using Maven 2.0.9 and maven-javadoc-plugin 2.6. I have the "links" > configured in my > plugin config. Now all resolution of external links fail (we are behind a > proxy *not* NTLM) > with this: > Aug 12, 2009 12:02:31 AM > org.apache.commons.httpclient.auth.AuthChallengeProcessor selectAuthScheme > INFO: ntlm authentication scheme selected > Aug 12, 2009 12:02:31 AM org.apache.commons.httpclient.HttpMethodDirector > authenticate > The wagon provider appears to have been upgraded to 1.0-beta-6 in the > maven-javadoc-plugin 2.6 > (as opposed to 1.0-beta-2 in 2.5). I seem to remember that (maybe it is > wrong) that wagon 1.0-beta-6 > requires Maven 2.1.x and above? If that is the case, I don't understand how > the plugin was released with > prerequisite of 2.0.9? > Is there a workaround to disable the default ntlm auth scheme via a magical > system property? TIA -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MJAVADOC-310) compiler plugin settings aren't inherited from parent tor linking Java API links
[
https://jira.codehaus.org/browse/MJAVADOC-310?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=354200#comment-354200
]
Robert Scholte commented on MJAVADOC-310:
-
In one of the Maven Hangouts we spent some time on this issue. Jason is very
clear about this: plugins should have *no* knowledge about each other. If there
are shared configuration-elements amongst plugins, then the pom.xml might need
to be enriched for such elements.
> compiler plugin settings aren't inherited from parent tor linking Java API
> links
>
>
> Key: MJAVADOC-310
> URL: https://jira.codehaus.org/browse/MJAVADOC-310
> Project: Maven Javadoc Plugin
> Issue Type: Bug
>Affects Versions: 2.7
> Environment: Maven 2.2.1, maven-compiler-plugin 2.3.2
>Reporter: Michael Osipov
>
> I set my m-c-p version in my parent's pluginManagement section but did not
> alter source and target because I am fine with 1.5.
> Now another project references it and complains that the above setting is not
> available:
> {noformat}
> [INFO] Generating "JavaDocs" report.
> [DEBUG] No maven-compiler-plugin defined in ${build.plugins} or in
> ${project.build.pluginManagement} for the
> :url-provider-api:jar:0.1-SNAPSHOT. Added Javadoc API link according
> the javadoc executable version i.e.: 1.6
> [DEBUG] Found Java API link: http://java.sun.com/javase/6/docs/api/
> [DEBUG] Try to add links for dependencies...
> {noformat}
> The behavior is incorrect. Either m-javadoc-p ignores the plugin's default
> settings or it does not merge the model.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MJAVADOC-375) Required class missing: org/apache/http/HttpRequest
[
https://jira.codehaus.org/browse/MJAVADOC-375?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=354199#comment-354199
]
Robert Scholte commented on MJAVADOC-375:
-
I cannot reproduce it. However, I see a potential problem: you're explicitly
settings {{M2_HOME}}. Please don't do that, the {{mvn}} executable already does
that for you.
> Required class missing: org/apache/http/HttpRequest
> ---
>
> Key: MJAVADOC-375
> URL: https://jira.codehaus.org/browse/MJAVADOC-375
> Project: Maven Javadoc Plugin
> Issue Type: Bug
>Affects Versions: 2.9.1
>Reporter: Ollie Robertshaw
>Priority: Blocker
> Attachments: Test.zip, tmp
>
>
> I cannot run Javadoc plugin 2.9.1 against _any_ Maven project. It fails with
> the following error:
> {{Failed to execute goal
> org.apache.maven.plugins:maven-javadoc-plugin:2.9.1:javadoc \(default-cli\)
> on project Test: Execution default-cli of goal
> org.apache.maven.plugins:maven-javadoc-plugin:2.9.1:javadoc failed: A
> required class was missing while executing
> org.apache.maven.plugins:maven-javadoc-plugin:2.9.1:javadoc:
> org/apache/http/HttpRequest}}
> Attached is a full Maven debug output, and an empty Maven project - with no
> dependencies - that the goal {{mvn javadoc:javadoc}} and {{mvn
> org.apache.maven.plugins:maven-javadoc-plugin:2.9.1:javadoc}} both fail
> against (though {{mvn
> org.apache.maven.plugins:maven-javadoc-plugin:2.8.1:javadoc}} succeeds).
> This looks to me like something (Plexus?) is dependent on HttpClient 3, and
> your recent upgrade to use HttpClient 4 has caused this to break.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MSITE-604) Properties from settings.xml are not recognized in site distribution management
[
https://jira.codehaus.org/browse/MSITE-604?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jörg Schaible updated MSITE-604:
Attachment: MSITE-604-it.patch
Gotcha! The problem occurs if the pom has a parent with substitutions. The
attempt to calculate a relative URL for the child fails badly. Patch for IT
updated.
> Properties from settings.xml are not recognized in site distribution
> management
>
>
> Key: MSITE-604
> URL: https://jira.codehaus.org/browse/MSITE-604
> Project: Maven Site Plugin
> Issue Type: Bug
> Components: site:deploy
>Affects Versions: 3.0
> Environment: Apache Maven 2.2.1 and 3.0.3
>Reporter: Marcin Kuthan
> Fix For: backlog
>
> Attachments: MSITE-604-it.patch, MSITE-604-it.patch,
> MSITE-604-it.patch, MSITE-604-maven3-2.patch, MSITE-604-maven3.patch,
> MSITE-604.tgz
>
>
> My distribution management section looks like:
> {code}
>
>
>${acme-corporate-pom.siteRepositoryId}
>${acme-corporate-pom.siteRepositoryUrl}
>
>
> {code}
> Where the default property values are defined in the pom:
> {code}
>
>
> acme-site
>
> scp://sites.intranet.acme.com/var/www
>
> {code}
> I'm able redefine properties from command line, the provided repository is
> used instead default one:
> {code}
> mvn site:site site:deploy
> -Dacme-corporate-pom.siteRepositoryUrl=scp://somehost/var/www/sites
> -Dacme-corporate-pom.siteRepositoryId=somehost
> {code}
> But when I redefine properties in the profile in {{settings.xml}}, they are
> ignored. The profile is activated in {{ It looks, than only m-site-p ignores properties defined in the
> {{settings.xml}} file. m-deploy-p recognizes properties as I expected
> (distribution management section for articats deployment is configured in
> similar way to site deployment).
> --
> Marcin Kuthan
> Maven For Enterprise - http://code.google.com/p/m4enterprise/
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MCOMPILER-203) Allow compiler-plugin to specify annotation processor dependencies
[
https://jira.codehaus.org/browse/MCOMPILER-203?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David M. Lloyd updated MCOMPILER-203:
-
Affects Version/s: 3.1
> Allow compiler-plugin to specify annotation processor dependencies
> --
>
> Key: MCOMPILER-203
> URL: https://jira.codehaus.org/browse/MCOMPILER-203
> Project: Maven Compiler Plugin
> Issue Type: New Feature
>Affects Versions: 2.3.2, 3.1
> Environment: Java 6+
>Reporter: David M. Lloyd
>
> Right now the status quo for annotation processor artifacts requires one of
> two actions:
> # Use an external plugin for annotation processing
> # Put the annotation processor in as a dependency with {{provided}} scope
> The former is suboptimal because the external plugins are clunky and
> ill-supported, and inflexible/hard to use. The latter is suboptimal because
> it is often the case that you do not want to leak annotation processor
> classes on to the application class path.
> It should be possible to add annotation processor dependency artifacts to the
> compiler plugin configuration such that they are recognized by the annotation
> processing search algorithm of the compiler, but they do not actually appear
> on the compilation class path. Ideally they would also be isolated from one
> another (dependency graphs and all), but that's more of a "nice to have".
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MASSEMBLY-673) Add support for "delimiters" and "useDefaultDelimiters" like the maven-resources-plugin 2.4 has
[
https://jira.codehaus.org/browse/MASSEMBLY-673?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl-Heinz Marbaise reassigned MASSEMBLY-673:
-
Assignee: Karl-Heinz Marbaise
> Add support for "delimiters" and "useDefaultDelimiters" like the
> maven-resources-plugin 2.4 has
> ---
>
> Key: MASSEMBLY-673
> URL: https://jira.codehaus.org/browse/MASSEMBLY-673
> Project: Maven Assembly Plugin
> Issue Type: Improvement
> Components: filtering
>Affects Versions: 2.4
>Reporter: Iain Coulter
>Assignee: Karl-Heinz Marbaise
> Fix For: 2.5
>
> Attachments: MASSEMBLY-673-patch.txt, MASSEMBLY-673.zip
>
>
> The maven-resources-plugin 2.4 added "delimiters" and "useDefaultDelimiters"
> which allows the default delimiter strings to be disabled and allows custom
> delimiters to be used.
> In a project which is packaging ant files or other files which use a lot of
> ${*} type variables specifying a custom delimiter and disabling the defaults
> would be more more usefull than the other option at present "escapeString"
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MASSEMBLY-673) Add support for "delimiters" and "useDefaultDelimiters" like the maven-resources-plugin 2.4 has
[
https://jira.codehaus.org/browse/MASSEMBLY-673?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=354191#comment-354191
]
Karl-Heinz Marbaise commented on MASSEMBLY-673:
---
Patch applied in [r1630908|http://svn.apache.org/r1630908].
> Add support for "delimiters" and "useDefaultDelimiters" like the
> maven-resources-plugin 2.4 has
> ---
>
> Key: MASSEMBLY-673
> URL: https://jira.codehaus.org/browse/MASSEMBLY-673
> Project: Maven Assembly Plugin
> Issue Type: Improvement
> Components: filtering
>Affects Versions: 2.4
>Reporter: Iain Coulter
>Assignee: Karl-Heinz Marbaise
> Fix For: 2.5
>
> Attachments: MASSEMBLY-673-patch.txt, MASSEMBLY-673.zip
>
>
> The maven-resources-plugin 2.4 added "delimiters" and "useDefaultDelimiters"
> which allows the default delimiter strings to be disabled and allows custom
> delimiters to be used.
> In a project which is packaging ant files or other files which use a lot of
> ${*} type variables specifying a custom delimiter and disabling the defaults
> would be more more usefull than the other option at present "escapeString"
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MASSEMBLY-673) Add support for "delimiters" and "useDefaultDelimiters" like the maven-resources-plugin 2.4 has
[
https://jira.codehaus.org/browse/MASSEMBLY-673?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=354191#comment-354191
]
Karl-Heinz Marbaise edited comment on MASSEMBLY-673 at 10/10/14 9:26 AM:
-
Patch applied in [r1630908|http://svn.apache.org/r1630908]. I need to create
integration tests for this.
was (Author: khmarbaise):
Patch applied in [r1630908|http://svn.apache.org/r1630908].
> Add support for "delimiters" and "useDefaultDelimiters" like the
> maven-resources-plugin 2.4 has
> ---
>
> Key: MASSEMBLY-673
> URL: https://jira.codehaus.org/browse/MASSEMBLY-673
> Project: Maven Assembly Plugin
> Issue Type: Improvement
> Components: filtering
>Affects Versions: 2.4
>Reporter: Iain Coulter
>Assignee: Karl-Heinz Marbaise
> Fix For: 2.5
>
> Attachments: MASSEMBLY-673-patch.txt, MASSEMBLY-673.zip
>
>
> The maven-resources-plugin 2.4 added "delimiters" and "useDefaultDelimiters"
> which allows the default delimiter strings to be disabled and allows custom
> delimiters to be used.
> In a project which is packaging ant files or other files which use a lot of
> ${*} type variables specifying a custom delimiter and disabling the defaults
> would be more more usefull than the other option at present "escapeString"
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MSKINS-94) Left margin on p elements leads to rugged indentation
Tobias Oberlies created MSKINS-94:
-
Summary: Left margin on p elements leads to rugged indentation
Key: MSKINS-94
URL: https://jira.codehaus.org/browse/MSKINS-94
Project: Maven Skins
Issue Type: Bug
Components: Fluido Skin
Environment: maven-fluido-skin 1.3.1
Reporter: Tobias Oberlies
The {{margin-left}} on {{p}} elements in the Fluido skin leads to a rugged
indentation, and there is no way to avoid it in a typical Mojo site doc page.
Consider for example the
[test-mojo|http://maven.apache.org/surefire/maven-surefire-plugin/test-mojo.html]
page: On this page, each of the parameter descriptions is not enclosed in
{{p}} elements. In the overview table this leads to a proper alignment with the
"User property" and "Default value" lines because they are also not enclosed in
paragraphs.
In the "Parameter Details" section however, the parameter names are enclosed in
{{p}} elements, making the parameter descriptions look as if they have a
negative indentation.
Enclosing the parameter descriptions in {{p}} elements (in the Mojo sources)
would help for the parameter details section, but this then leads to a rugged
indentation in the overview table.
So, since it cannot be ensured that {{p}} elements are used everywhere, Fluido
should not assing a left margin to them.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MJAR-135) encoding problem with folder-names
[
https://jira.codehaus.org/browse/MJAR-135?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=354182#comment-354182
]
Kristian Rosenvold commented on MJAR-135:
-
The *only* way this can happen with recent versions of JarArchiver is if
someone calls setEncoding() with null or a specific character set value on the
achiver instance. setEncoding(null) will revert the jar archiver to platform
specific encoding.
> encoding problem with folder-names
> --
>
> Key: MJAR-135
> URL: https://jira.codehaus.org/browse/MJAR-135
> Project: Maven JAR Plugin
> Issue Type: Bug
>Affects Versions: 2.3
> Environment: Windows XP, java6, running maven via cygwin or windows
> console
>Reporter: Karsten Fehre
> Fix For: 2.5.1
>
> Attachments: sample-project.tar.gz
>
>
> Resources folder containing german umlauts are not copied correctly to a
> created jar.
> For packaging into a jar, i copied folders/subfolders (with german umlauts)
> via maven-resources-plugin to target folder. This works fine.
> A simple '{{mvn jar:jar}}' creates a jar, containing the resources, but
> folders with german umlauts are not correctly represented inside of the jar.
> I tried to set the encoding via
> {code:xml}
>
> org.apache.maven.plugins
> maven-jar-plugin
> 2.3
>
> UTF-8
>
>
> {code}
> as like the other maven plugins, but it does not work.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MPLUGIN-269) maven-plugin-tools-annotations does not work in builds which don't package
[
https://jira.codehaus.org/browse/MPLUGIN-269?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Igor Fedorenko updated MPLUGIN-269:
---
Summary: maven-plugin-tools-annotations does not work in builds which don't
package (was: "ArchiverException: The source must not be a directory" inside
m2e workspace)
> maven-plugin-tools-annotations does not work in builds which don't package
> --
>
> Key: MPLUGIN-269
> URL: https://jira.codehaus.org/browse/MPLUGIN-269
> Project: Maven Plugin Tools
> Issue Type: Bug
> Components: maven-plugin-tools-annotations
>Reporter: Igor Fedorenko
>
> When running descriptor goal inside m2e workspace, I get the following
> exception for plugin projects that depend on other plugin projects.
> {code}
> org.apache.maven.plugin.PluginExecutionException: Execution
> default-descriptor of goal
> org.apache.maven.plugins:maven-plugin-plugin:3.3:descriptor failed: The
> source must not be a directory.
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:143)
> at
> org.eclipse.m2e.core.internal.embedder.MavenImpl.execute(MavenImpl.java:328)
> at
> org.eclipse.m2e.core.internal.embedder.MavenImpl$10.call(MavenImpl.java:1355)
> at
> org.eclipse.m2e.core.internal.embedder.MavenImpl$10.call(MavenImpl.java:1)
> at
> org.eclipse.m2e.core.internal.embedder.MavenExecutionContext.executeBare(MavenExecutionContext.java:174)
> at
> org.eclipse.m2e.core.internal.embedder.MavenExecutionContext.execute(MavenExecutionContext.java:110)
> at
> org.eclipse.m2e.core.internal.embedder.MavenImpl.execute(MavenImpl.java:1353)
> at
> org.eclipse.m2e.core.project.configurator.MojoExecutionBuildParticipant.build(MojoExecutionBuildParticipant.java:52)
> at
> org.eclipse.m2e.core.internal.builder.MavenBuilderImpl.build(MavenBuilderImpl.java:132)
> at
> org.eclipse.m2e.core.internal.builder.MavenBuilder$1.method(MavenBuilder.java:172)
> at
> org.eclipse.m2e.core.internal.builder.MavenBuilder$1.method(MavenBuilder.java:1)
> at
> org.eclipse.m2e.core.internal.builder.MavenBuilder$BuildMethod$1$1.call(MavenBuilder.java:115)
> at
> org.eclipse.m2e.core.internal.embedder.MavenExecutionContext.executeBare(MavenExecutionContext.java:174)
> at
> org.eclipse.m2e.core.internal.embedder.MavenExecutionContext.execute(MavenExecutionContext.java:110)
> at
> org.eclipse.m2e.core.internal.builder.MavenBuilder$BuildMethod$1.call(MavenBuilder.java:105)
> at
> org.eclipse.m2e.core.internal.embedder.MavenExecutionContext.executeBare(MavenExecutionContext.java:174)
> at
> org.eclipse.m2e.core.internal.embedder.MavenExecutionContext.execute(MavenExecutionContext.java:149)
> at
> org.eclipse.m2e.core.internal.embedder.MavenExecutionContext.execute(MavenExecutionContext.java:97)
> at
> org.eclipse.m2e.core.internal.builder.MavenBuilder$BuildMethod.execute(MavenBuilder.java:86)
> at
> org.eclipse.m2e.core.internal.builder.MavenBuilder.build(MavenBuilder.java:200)
> at
> org.eclipse.core.internal.events.BuildManager$2.run(BuildManager.java:734)
> at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42)
> at
> org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:206)
> at
> org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:246)
> at
> org.eclipse.core.internal.events.BuildManager$1.run(BuildManager.java:299)
> at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42)
> at
> org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:302)
> at
> org.eclipse.core.internal.events.BuildManager.basicBuildLoop(BuildManager.java:358)
> at
> org.eclipse.core.internal.events.BuildManager.build(BuildManager.java:381)
> at
> org.eclipse.core.internal.events.AutoBuildJob.doBuild(AutoBuildJob.java:143)
> at
> org.eclipse.core.internal.events.AutoBuildJob.run(AutoBuildJob.java:241)
> at org.eclipse.core.internal.jobs.Worker.run(Worker.java:54)
> Caused by: org.codehaus.plexus.archiver.ArchiverException: The source must
> not be a directory.
> at
> org.codehaus.plexus.archiver.AbstractUnArchiver.validate(AbstractUnArchiver.java:185)
> at
> org.codehaus.plexus.archiver.AbstractUnArchiver.extract(AbstractUnArchiver.java:118)
> at
> org.apache.maven.tools.plugin.annotations.JavaAnnotationsMojoDescriptorExtractor.discoverClassesFromSourcesJar(JavaAnnotationsMojoDescriptorExtractor.java:220)
> at
> org.apache.maven.tools.plugin.annotations.JavaAnnotationsMojoDescriptorExtractor.scanJavadoc(JavaAnnotationsMojoDescriptorExtractor.java:172)
> at
> org.apache.maven.tools.plugin.annota
[jira] (MPLUGIN-269) "ArchiverException: The source must not be a directory" inside m2e workspace
[
https://jira.codehaus.org/browse/MPLUGIN-269?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=354173#comment-354173
]
Tobias Oberlies commented on MPLUGIN-269:
-
I don't seem to have permission for this, but the title should be
"maven-plugin-tools-annotations does not work in builds which don't package".
> "ArchiverException: The source must not be a directory" inside m2e workspace
>
>
> Key: MPLUGIN-269
> URL: https://jira.codehaus.org/browse/MPLUGIN-269
> Project: Maven Plugin Tools
> Issue Type: Bug
> Components: maven-plugin-tools-annotations
>Reporter: Igor Fedorenko
>
> When running descriptor goal inside m2e workspace, I get the following
> exception for plugin projects that depend on other plugin projects.
> {code}
> org.apache.maven.plugin.PluginExecutionException: Execution
> default-descriptor of goal
> org.apache.maven.plugins:maven-plugin-plugin:3.3:descriptor failed: The
> source must not be a directory.
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:143)
> at
> org.eclipse.m2e.core.internal.embedder.MavenImpl.execute(MavenImpl.java:328)
> at
> org.eclipse.m2e.core.internal.embedder.MavenImpl$10.call(MavenImpl.java:1355)
> at
> org.eclipse.m2e.core.internal.embedder.MavenImpl$10.call(MavenImpl.java:1)
> at
> org.eclipse.m2e.core.internal.embedder.MavenExecutionContext.executeBare(MavenExecutionContext.java:174)
> at
> org.eclipse.m2e.core.internal.embedder.MavenExecutionContext.execute(MavenExecutionContext.java:110)
> at
> org.eclipse.m2e.core.internal.embedder.MavenImpl.execute(MavenImpl.java:1353)
> at
> org.eclipse.m2e.core.project.configurator.MojoExecutionBuildParticipant.build(MojoExecutionBuildParticipant.java:52)
> at
> org.eclipse.m2e.core.internal.builder.MavenBuilderImpl.build(MavenBuilderImpl.java:132)
> at
> org.eclipse.m2e.core.internal.builder.MavenBuilder$1.method(MavenBuilder.java:172)
> at
> org.eclipse.m2e.core.internal.builder.MavenBuilder$1.method(MavenBuilder.java:1)
> at
> org.eclipse.m2e.core.internal.builder.MavenBuilder$BuildMethod$1$1.call(MavenBuilder.java:115)
> at
> org.eclipse.m2e.core.internal.embedder.MavenExecutionContext.executeBare(MavenExecutionContext.java:174)
> at
> org.eclipse.m2e.core.internal.embedder.MavenExecutionContext.execute(MavenExecutionContext.java:110)
> at
> org.eclipse.m2e.core.internal.builder.MavenBuilder$BuildMethod$1.call(MavenBuilder.java:105)
> at
> org.eclipse.m2e.core.internal.embedder.MavenExecutionContext.executeBare(MavenExecutionContext.java:174)
> at
> org.eclipse.m2e.core.internal.embedder.MavenExecutionContext.execute(MavenExecutionContext.java:149)
> at
> org.eclipse.m2e.core.internal.embedder.MavenExecutionContext.execute(MavenExecutionContext.java:97)
> at
> org.eclipse.m2e.core.internal.builder.MavenBuilder$BuildMethod.execute(MavenBuilder.java:86)
> at
> org.eclipse.m2e.core.internal.builder.MavenBuilder.build(MavenBuilder.java:200)
> at
> org.eclipse.core.internal.events.BuildManager$2.run(BuildManager.java:734)
> at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42)
> at
> org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:206)
> at
> org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:246)
> at
> org.eclipse.core.internal.events.BuildManager$1.run(BuildManager.java:299)
> at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42)
> at
> org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:302)
> at
> org.eclipse.core.internal.events.BuildManager.basicBuildLoop(BuildManager.java:358)
> at
> org.eclipse.core.internal.events.BuildManager.build(BuildManager.java:381)
> at
> org.eclipse.core.internal.events.AutoBuildJob.doBuild(AutoBuildJob.java:143)
> at
> org.eclipse.core.internal.events.AutoBuildJob.run(AutoBuildJob.java:241)
> at org.eclipse.core.internal.jobs.Worker.run(Worker.java:54)
> Caused by: org.codehaus.plexus.archiver.ArchiverException: The source must
> not be a directory.
> at
> org.codehaus.plexus.archiver.AbstractUnArchiver.validate(AbstractUnArchiver.java:185)
> at
> org.codehaus.plexus.archiver.AbstractUnArchiver.extract(AbstractUnArchiver.java:118)
> at
> org.apache.maven.tools.plugin.annotations.JavaAnnotationsMojoDescriptorExtractor.discoverClassesFromSourcesJar(JavaAnnotationsMojoDescriptorExtractor.java:220)
> at
> org.apache.maven.tools.plugin.annotations.JavaAnnotationsMojoDescriptorExtractor.scanJavadoc(JavaAnnotationsMojoDescriptorExtractor.java:172)
> at
> org.apa
[jira] (MPLUGIN-269) "ArchiverException: The source must not be a directory" inside m2e workspace
[
https://jira.codehaus.org/browse/MPLUGIN-269?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=354172#comment-354172
]
Tobias Oberlies commented on MPLUGIN-269:
-
However the question is why {{getFromProjectReferences}} is attempted at all.
After failing to match the above IDs, {{discoverClassesFromSourcesJar}}
correctly finds the {{tycho-packaging-plugin}} in the reactor. It only fails to
check the type of {{sourcesArtifact.getFile()}} but blindly assumes that the
method returns a jar. However this is not the case if the build is started with
a phase which does not include {{package}}.
So really this bug should be easy to fix with a few lines of code change.
> "ArchiverException: The source must not be a directory" inside m2e workspace
>
>
> Key: MPLUGIN-269
> URL: https://jira.codehaus.org/browse/MPLUGIN-269
> Project: Maven Plugin Tools
> Issue Type: Bug
> Components: maven-plugin-tools-annotations
>Reporter: Igor Fedorenko
>
> When running descriptor goal inside m2e workspace, I get the following
> exception for plugin projects that depend on other plugin projects.
> {code}
> org.apache.maven.plugin.PluginExecutionException: Execution
> default-descriptor of goal
> org.apache.maven.plugins:maven-plugin-plugin:3.3:descriptor failed: The
> source must not be a directory.
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:143)
> at
> org.eclipse.m2e.core.internal.embedder.MavenImpl.execute(MavenImpl.java:328)
> at
> org.eclipse.m2e.core.internal.embedder.MavenImpl$10.call(MavenImpl.java:1355)
> at
> org.eclipse.m2e.core.internal.embedder.MavenImpl$10.call(MavenImpl.java:1)
> at
> org.eclipse.m2e.core.internal.embedder.MavenExecutionContext.executeBare(MavenExecutionContext.java:174)
> at
> org.eclipse.m2e.core.internal.embedder.MavenExecutionContext.execute(MavenExecutionContext.java:110)
> at
> org.eclipse.m2e.core.internal.embedder.MavenImpl.execute(MavenImpl.java:1353)
> at
> org.eclipse.m2e.core.project.configurator.MojoExecutionBuildParticipant.build(MojoExecutionBuildParticipant.java:52)
> at
> org.eclipse.m2e.core.internal.builder.MavenBuilderImpl.build(MavenBuilderImpl.java:132)
> at
> org.eclipse.m2e.core.internal.builder.MavenBuilder$1.method(MavenBuilder.java:172)
> at
> org.eclipse.m2e.core.internal.builder.MavenBuilder$1.method(MavenBuilder.java:1)
> at
> org.eclipse.m2e.core.internal.builder.MavenBuilder$BuildMethod$1$1.call(MavenBuilder.java:115)
> at
> org.eclipse.m2e.core.internal.embedder.MavenExecutionContext.executeBare(MavenExecutionContext.java:174)
> at
> org.eclipse.m2e.core.internal.embedder.MavenExecutionContext.execute(MavenExecutionContext.java:110)
> at
> org.eclipse.m2e.core.internal.builder.MavenBuilder$BuildMethod$1.call(MavenBuilder.java:105)
> at
> org.eclipse.m2e.core.internal.embedder.MavenExecutionContext.executeBare(MavenExecutionContext.java:174)
> at
> org.eclipse.m2e.core.internal.embedder.MavenExecutionContext.execute(MavenExecutionContext.java:149)
> at
> org.eclipse.m2e.core.internal.embedder.MavenExecutionContext.execute(MavenExecutionContext.java:97)
> at
> org.eclipse.m2e.core.internal.builder.MavenBuilder$BuildMethod.execute(MavenBuilder.java:86)
> at
> org.eclipse.m2e.core.internal.builder.MavenBuilder.build(MavenBuilder.java:200)
> at
> org.eclipse.core.internal.events.BuildManager$2.run(BuildManager.java:734)
> at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42)
> at
> org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:206)
> at
> org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:246)
> at
> org.eclipse.core.internal.events.BuildManager$1.run(BuildManager.java:299)
> at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42)
> at
> org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:302)
> at
> org.eclipse.core.internal.events.BuildManager.basicBuildLoop(BuildManager.java:358)
> at
> org.eclipse.core.internal.events.BuildManager.build(BuildManager.java:381)
> at
> org.eclipse.core.internal.events.AutoBuildJob.doBuild(AutoBuildJob.java:143)
> at
> org.eclipse.core.internal.events.AutoBuildJob.run(AutoBuildJob.java:241)
> at org.eclipse.core.internal.jobs.Worker.run(Worker.java:54)
> Caused by: org.codehaus.plexus.archiver.ArchiverException: The source must
> not be a directory.
> at
> org.codehaus.plexus.archiver.AbstractUnArchiver.validate(AbstractUnArchiver.java:185)
> at
> org.codehaus.plexus.archiver.AbstractUnArchiver.extract(AbstractUnArch
[jira] (MPLUGIN-269) "ArchiverException: The source must not be a directory" inside m2e workspace
[
https://jira.codehaus.org/browse/MPLUGIN-269?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=354170#comment-354170
]
Tobias Oberlies commented on MPLUGIN-269:
-
Sorry, I don't have a minimal project yet, but here is one way to reproduce
this issue:
* Get the Tycho sources from https://git.eclipse.org/r/tycho/org.eclipse.tycho
* Run {{mvn clean process-classes -am -pl tycho-source-plugin}}
I've debugged the code, and found the following code location where
maven-plugin-tools-annotations-3.3 goes wrong: When looking up artifacts from
the reactor at
JavaAnnotationsMojoDescriptorExtractor.getFromProjectReferences(Artifact,
MavenProject) line 716, it compares {{mavenProject.getId()}} (a reactor
artifact) and {{artifact.getId()}}. The artifact should be found in the
reactor, but it isn't because
* the former returns
{{org.eclipse.tycho:tycho-packaging-plugin:maven-plugin:0.22.0-SNAPSHOT}}, and
* the latter returns
{{org.eclipse.tycho:tycho-packaging-plugin:jar:0.22.0-SNAPSHOT}}
> "ArchiverException: The source must not be a directory" inside m2e workspace
>
>
> Key: MPLUGIN-269
> URL: https://jira.codehaus.org/browse/MPLUGIN-269
> Project: Maven Plugin Tools
> Issue Type: Bug
> Components: maven-plugin-tools-annotations
>Reporter: Igor Fedorenko
>
> When running descriptor goal inside m2e workspace, I get the following
> exception for plugin projects that depend on other plugin projects.
> {code}
> org.apache.maven.plugin.PluginExecutionException: Execution
> default-descriptor of goal
> org.apache.maven.plugins:maven-plugin-plugin:3.3:descriptor failed: The
> source must not be a directory.
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:143)
> at
> org.eclipse.m2e.core.internal.embedder.MavenImpl.execute(MavenImpl.java:328)
> at
> org.eclipse.m2e.core.internal.embedder.MavenImpl$10.call(MavenImpl.java:1355)
> at
> org.eclipse.m2e.core.internal.embedder.MavenImpl$10.call(MavenImpl.java:1)
> at
> org.eclipse.m2e.core.internal.embedder.MavenExecutionContext.executeBare(MavenExecutionContext.java:174)
> at
> org.eclipse.m2e.core.internal.embedder.MavenExecutionContext.execute(MavenExecutionContext.java:110)
> at
> org.eclipse.m2e.core.internal.embedder.MavenImpl.execute(MavenImpl.java:1353)
> at
> org.eclipse.m2e.core.project.configurator.MojoExecutionBuildParticipant.build(MojoExecutionBuildParticipant.java:52)
> at
> org.eclipse.m2e.core.internal.builder.MavenBuilderImpl.build(MavenBuilderImpl.java:132)
> at
> org.eclipse.m2e.core.internal.builder.MavenBuilder$1.method(MavenBuilder.java:172)
> at
> org.eclipse.m2e.core.internal.builder.MavenBuilder$1.method(MavenBuilder.java:1)
> at
> org.eclipse.m2e.core.internal.builder.MavenBuilder$BuildMethod$1$1.call(MavenBuilder.java:115)
> at
> org.eclipse.m2e.core.internal.embedder.MavenExecutionContext.executeBare(MavenExecutionContext.java:174)
> at
> org.eclipse.m2e.core.internal.embedder.MavenExecutionContext.execute(MavenExecutionContext.java:110)
> at
> org.eclipse.m2e.core.internal.builder.MavenBuilder$BuildMethod$1.call(MavenBuilder.java:105)
> at
> org.eclipse.m2e.core.internal.embedder.MavenExecutionContext.executeBare(MavenExecutionContext.java:174)
> at
> org.eclipse.m2e.core.internal.embedder.MavenExecutionContext.execute(MavenExecutionContext.java:149)
> at
> org.eclipse.m2e.core.internal.embedder.MavenExecutionContext.execute(MavenExecutionContext.java:97)
> at
> org.eclipse.m2e.core.internal.builder.MavenBuilder$BuildMethod.execute(MavenBuilder.java:86)
> at
> org.eclipse.m2e.core.internal.builder.MavenBuilder.build(MavenBuilder.java:200)
> at
> org.eclipse.core.internal.events.BuildManager$2.run(BuildManager.java:734)
> at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42)
> at
> org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:206)
> at
> org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:246)
> at
> org.eclipse.core.internal.events.BuildManager$1.run(BuildManager.java:299)
> at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42)
> at
> org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:302)
> at
> org.eclipse.core.internal.events.BuildManager.basicBuildLoop(BuildManager.java:358)
> at
> org.eclipse.core.internal.events.BuildManager.build(BuildManager.java:381)
> at
> org.eclipse.core.internal.events.AutoBuildJob.doBuild(AutoBuildJob.java:143)
> at
> org.eclipse.core.internal.events.AutoBuildJob.run(AutoBuildJob.java:241)
> at org.eclipse.cor
[jira] (SCM-764) username and credentials shown as INFO on commadline
[ https://jira.codehaus.org/browse/SCM-764?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=354168#comment-354168 ] Ludovic Lebègue commented on SCM-764: - I have provided a patch for this one associated with a pull request on github : https://github.com/apache/maven-scm/pull/22 > username and credentials shown as INFO on commadline > > > Key: SCM-764 > URL: https://jira.codehaus.org/browse/SCM-764 > Project: Maven SCM > Issue Type: Bug > Components: maven-scm-provider-git > Environment: Apache Maven 3.2.1 > (ea8b2b07643dbb1b84b6d16e1f08391b666bc1e9; 2014-02-14T18:37:52+01:00) > Maven home: D:\Dev\maven\apache-maven-3.2.1 > Java version: 1.7.0_51, vendor: Oracle Corporation > Java home: D:\Dev\Java\jdk7_51_x64\jre > Default locale: de_DE, platform encoding: Cp1252 > OS name: "windows 7", version: "6.1", arch: "amd64", family: "windows" >Reporter: Thomas Wabner > > Using git repository with gitblit on HTTPS. > Every git command which involve the remote repository (like fetch, pull, push > and so on) showing the username and credentials on the commandline like this: > [INFO] Executing: cmd.exe /X /C "git push > https://user:secret@devserver/gitblit//r/waffel/devopts.git test-branch" > It should be avoided to ever print out passwords on the command line. I have > encrypted the password in maven settings.xml ... but now it comes back and > anybody can see them (also on a continues build server which should push with > a dedicated user to a central repo). -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MSITE-604) Properties from settings.xml are not recognized in site distribution management
[
https://jira.codehaus.org/browse/MSITE-604?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jörg Schaible updated MSITE-604:
Attachment: MSITE-604-it.patch
New MSITE-604-it.patch against svn rev 1630660. IT executed with:
{noformat}
rm -rf target/it
mvn integration-test -Prun-its -Dinvoker.test=MSITE-604
{noformat}
The patch modifies the IT to reflect my local setup. However, the embarrassing
part is, that it succeeds. My setup:
{noformat}
$ mvn -version
Apache Maven 3.2.3 (33f8c3e1027c3ddde99d3cdebad2656a31e8fdf4;
2014-08-11T22:58:10+02:00)
Maven home: /usr/share/maven-bin-3.2
Java version: 1.7.0_67, vendor: Oracle Corporation
Java home: /opt/oracle-jdk-bin-1.7.0.67/jre
Default locale: en_US, platform encoding: UTF-8
OS name: "linux", version: "3.14.14-gentoo", arch: "amd64", family: "unix"
{noformat}
Nevertheless, I still have this error in my real projects:
{noformat}
[INFO] --- maven-site-plugin:3.4:deploy (default-cli) @ scalaris-commons-xam ---
[INFO] Parent project loaded from repository:
com.scalaris.buildsystem.maven2:master:pom:273
[INFO]
[INFO] BUILD FAILURE
[INFO]
[INFO] Total time: 25.222 s
[INFO] Finished at: 2014-10-10T14:07:46+02:00
[INFO] Final Memory: 61M/603M
[INFO]
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-site-plugin:3.4:deploy (default-cli) on project
scalaris-commons-xam: Execution default-cli of goal
org.apache.maven.plugins:maven-site-plugin:3.4:deploy failed: Base URI is not
absolute: $%7bscalaris.site.url.base%7d -> [Help 1]
{noformat}
In contrast to the IT, the site plugin generated some real reports before.
Maybe the classpath is poluted with an old version of the component handling
the substitutions in the URL? Can someone tell me, which component is
internally actual responsible for it?
> Properties from settings.xml are not recognized in site distribution
> management
>
>
> Key: MSITE-604
> URL: https://jira.codehaus.org/browse/MSITE-604
> Project: Maven Site Plugin
> Issue Type: Bug
> Components: site:deploy
>Affects Versions: 3.0
> Environment: Apache Maven 2.2.1 and 3.0.3
>Reporter: Marcin Kuthan
> Fix For: backlog
>
> Attachments: MSITE-604-it.patch, MSITE-604-it.patch,
> MSITE-604-maven3-2.patch, MSITE-604-maven3.patch, MSITE-604.tgz
>
>
> My distribution management section looks like:
> {code}
>
>
>${acme-corporate-pom.siteRepositoryId}
>${acme-corporate-pom.siteRepositoryUrl}
>
>
> {code}
> Where the default property values are defined in the pom:
> {code}
>
>
> acme-site
>
> scp://sites.intranet.acme.com/var/www
>
> {code}
> I'm able redefine properties from command line, the provided repository is
> used instead default one:
> {code}
> mvn site:site site:deploy
> -Dacme-corporate-pom.siteRepositoryUrl=scp://somehost/var/www/sites
> -Dacme-corporate-pom.siteRepositoryId=somehost
> {code}
> But when I redefine properties in the profile in {{settings.xml}}, they are
> ignored. The profile is activated in {{ It looks, than only m-site-p ignores properties defined in the
> {{settings.xml}} file. m-deploy-p recognizes properties as I expected
> (distribution management section for articats deployment is configured in
> similar way to site deployment).
> --
> Marcin Kuthan
> Maven For Enterprise - http://code.google.com/p/m4enterprise/
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MSITE-604) Properties from settings.xml are not recognized in site distribution management
[
https://jira.codehaus.org/browse/MSITE-604?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jörg Schaible updated MSITE-604:
Comment: was deleted
(was: {color:red}
Sorry, forget this, the error is in the path. I'll try to build another one.
{color}
New MSITE-604-it.patch against svn rev 1630660. IT executed with:
rm -rf target/it
mvn integration-test -Prun-its -Dinvoker.test=MSITE-604
Build fails, extract from build.log:
{noformat}
[INFO] --- maven-site-plugin:3.4.1-SNAPSHOT:deploy (default-cli) @ MSITE-604 ---
[DEBUG] Configuring mojo
org.apache.maven.plugins:maven-site-plugin:3.4.1-SNAPSHOT:deploy from plugin
realm
ClassRealm[plugin>org.apache.maven.plugins:maven-site-plugin:3.4.1-SNAPSHOT,
parent: sun.misc.Launcher$AppClassLoader@2bb0bf9a]
[DEBUG] Configuring mojo
'org.apache.maven.plugins:maven-site-plugin:3.4.1-SNAPSHOT:deploy' with basic
configurator -->
[DEBUG] (f) chmod = true
[DEBUG] (f) chmodMode = g+w,a+rX
[DEBUG] (f) chmodOptions = -Rf
[DEBUG] (f) inputDirectory =
/home/jos/src/Apache/Maven/Plugins/maven-site-plugin/target/it/MSITE-604/target/site
[DEBUG] (f) inputEncoding = UTF-8
[DEBUG] (f) localRepository = id: local
url:
file:///home/jos/src/Apache/Maven/Plugins/maven-site-plugin/target/local-repo/
layout: default
snapshots: [enabled => true, update => always]
releases: [enabled => true, update => always]
[DEBUG] (f) mavenSession = org.apache.maven.execution.MavenSession@75f3e0c5
[DEBUG] (f) project = MavenProject:
org.apache.maven.plugins.site.its:MSITE-604:1.0-SNAPSHOT @
/home/jos/src/Apache/Maven/Plugins/maven-site-plugin/target/it/MSITE-604/pom.xml
[DEBUG] (f) reactorProjects = [MavenProject:
org.apache.maven.plugins.site.its:MSITE-604:1.0-SNAPSHOT @
/home/jos/src/Apache/Maven/Plugins/maven-site-plugin/target/it/MSITE-604/pom.xml]
[DEBUG] (f) settings = org.apache.maven.execution.SettingsAdapter@7233d91f
[DEBUG] (f) siteDirectory =
/home/jos/src/Apache/Maven/Plugins/maven-site-plugin/target/it/MSITE-604/src/site
[DEBUG] (f) skipDeploy = false
[DEBUG] -- end configuration --
[DEBUG] Deploying to '${msite604.siteRepository.Root}/settingsRepositoryUrl/',
Using credentials from server id 'settingsId'
[INFO]
[INFO] BUILD FAILURE
[INFO]
[INFO] Total time: 2.506 s
[INFO] Finished at: 2014-10-10T13:26:43+02:00
[INFO] Final Memory: 19M/214M
[INFO]
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-site-plugin:3.4.1-SNAPSHOT:deploy (default-cli)
on project MSITE-604: Wagon protocol '' doesn't support directory copying ->
[Help 1]
{noformat}
As you can see, one of the properties of settings.xml has been substituted, the
other one (containing the protocol) has not.
{noformat}
$ mvn -version
Apache Maven 3.2.3 (33f8c3e1027c3ddde99d3cdebad2656a31e8fdf4;
2014-08-11T22:58:10+02:00)
Maven home: /usr/share/maven-bin-3.2
Java version: 1.7.0_67, vendor: Oracle Corporation
Java home: /opt/oracle-jdk-bin-1.7.0.67/jre
Default locale: en_US, platform encoding: UTF-8
OS name: "linux", version: "3.14.14-gentoo", arch: "amd64", family: "unix"
{noformat})
> Properties from settings.xml are not recognized in site distribution
> management
>
>
> Key: MSITE-604
> URL: https://jira.codehaus.org/browse/MSITE-604
> Project: Maven Site Plugin
> Issue Type: Bug
> Components: site:deploy
>Affects Versions: 3.0
> Environment: Apache Maven 2.2.1 and 3.0.3
>Reporter: Marcin Kuthan
> Fix For: backlog
>
> Attachments: MSITE-604-it.patch, MSITE-604-maven3-2.patch,
> MSITE-604-maven3.patch, MSITE-604.tgz
>
>
> My distribution management section looks like:
> {code}
>
>
>${acme-corporate-pom.siteRepositoryId}
>${acme-corporate-pom.siteRepositoryUrl}
>
>
> {code}
> Where the default property values are defined in the pom:
> {code}
>
>
> acme-site
>
> scp://sites.intranet.acme.com/var/www
>
> {code}
> I'm able redefine properties from command line, the provided repository is
> used instead default one:
> {code}
> mvn site:site site:deploy
> -Dacme-corporate-pom.siteRepositoryUrl=scp://somehost/var/www/sites
> -Dacme-corporate-pom.siteRepositoryId=somehost
> {code}
> But when I redefine properties in the profile in {{settings.xml}}, they are
> ignored. The profile is activated in {{ It looks, than only m-site-p ignores properties defined in the
> {{settings.xml}} file. m-deploy-p recognizes properties as I expected
> (distribution management section for articats deployment is configured in
> similar way to site deployment).
> --
> Marcin
[jira] (MSITE-604) Properties from settings.xml are not recognized in site distribution management
[
https://jira.codehaus.org/browse/MSITE-604?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jörg Schaible updated MSITE-604:
Attachment: (was: MSITE-604-it.patch)
> Properties from settings.xml are not recognized in site distribution
> management
>
>
> Key: MSITE-604
> URL: https://jira.codehaus.org/browse/MSITE-604
> Project: Maven Site Plugin
> Issue Type: Bug
> Components: site:deploy
>Affects Versions: 3.0
> Environment: Apache Maven 2.2.1 and 3.0.3
>Reporter: Marcin Kuthan
> Fix For: backlog
>
> Attachments: MSITE-604-it.patch, MSITE-604-maven3-2.patch,
> MSITE-604-maven3.patch, MSITE-604.tgz
>
>
> My distribution management section looks like:
> {code}
>
>
>${acme-corporate-pom.siteRepositoryId}
>${acme-corporate-pom.siteRepositoryUrl}
>
>
> {code}
> Where the default property values are defined in the pom:
> {code}
>
>
> acme-site
>
> scp://sites.intranet.acme.com/var/www
>
> {code}
> I'm able redefine properties from command line, the provided repository is
> used instead default one:
> {code}
> mvn site:site site:deploy
> -Dacme-corporate-pom.siteRepositoryUrl=scp://somehost/var/www/sites
> -Dacme-corporate-pom.siteRepositoryId=somehost
> {code}
> But when I redefine properties in the profile in {{settings.xml}}, they are
> ignored. The profile is activated in {{ It looks, than only m-site-p ignores properties defined in the
> {{settings.xml}} file. m-deploy-p recognizes properties as I expected
> (distribution management section for articats deployment is configured in
> similar way to site deployment).
> --
> Marcin Kuthan
> Maven For Enterprise - http://code.google.com/p/m4enterprise/
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MRESOURCES-171) ISO8859-1 properties files get changed into UTF-8 when filtered
[ https://jira.codehaus.org/browse/MRESOURCES-171?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=354160#comment-354160 ] Aaron Digulla commented on MRESOURCES-171: -- @Karl-Heinz Marbaise: What would be a correct/working POM which just applied this encoding to property files and use the default encoding for everything else? I'd suggest to use the encoding iso-8859-1 for copying and resource filtering since it's a 1:1 encoding (each byte just passes through) but that doesn't work when the resource plugin expands a variable with a value that contains Unicode characters (code point > 256) since those can't be mapped to iso-8859-1 anymore. So we would have a situation where most parts of a file would make it into the target folder unscathed but in some corner cases, it would fail. > ISO8859-1 properties files get changed into UTF-8 when filtered > --- > > Key: MRESOURCES-171 > URL: https://jira.codehaus.org/browse/MRESOURCES-171 > Project: Maven Resources Plugin > Issue Type: Bug > Components: filtering >Reporter: Alex Collins >Priority: Minor > Fix For: backlog > > Attachments: filtering-bug.zip > > > Create: > src/main/resources/test.properties > And add a ISO8859-1 character that is not ASCII or UTF-8, do not use \u > formatting. > When adding this line: > src/main/resourcestrue > Expected: > ISO8859-1 encoded file in jar. > Actual: > UTF-8 encoded file in jar. > --- > If there are any property files (which can only be ISO8859-1) they appear to > be converted into UTF-8 in the jar. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MSITE-604) Properties from settings.xml are not recognized in site distribution management
[
https://jira.codehaus.org/browse/MSITE-604?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=354159#comment-354159
]
Jörg Schaible edited comment on MSITE-604 at 10/10/14 6:44 AM:
---
{color:red}
Sorry, forget this, the error is in the path. I'll try to build another one.
{color}
New MSITE-604-it.patch against svn rev 1630660. IT executed with:
rm -rf target/it
mvn integration-test -Prun-its -Dinvoker.test=MSITE-604
Build fails, extract from build.log:
{noformat}
[INFO] --- maven-site-plugin:3.4.1-SNAPSHOT:deploy (default-cli) @ MSITE-604 ---
[DEBUG] Configuring mojo
org.apache.maven.plugins:maven-site-plugin:3.4.1-SNAPSHOT:deploy from plugin
realm
ClassRealm[plugin>org.apache.maven.plugins:maven-site-plugin:3.4.1-SNAPSHOT,
parent: sun.misc.Launcher$AppClassLoader@2bb0bf9a]
[DEBUG] Configuring mojo
'org.apache.maven.plugins:maven-site-plugin:3.4.1-SNAPSHOT:deploy' with basic
configurator -->
[DEBUG] (f) chmod = true
[DEBUG] (f) chmodMode = g+w,a+rX
[DEBUG] (f) chmodOptions = -Rf
[DEBUG] (f) inputDirectory =
/home/jos/src/Apache/Maven/Plugins/maven-site-plugin/target/it/MSITE-604/target/site
[DEBUG] (f) inputEncoding = UTF-8
[DEBUG] (f) localRepository = id: local
url:
file:///home/jos/src/Apache/Maven/Plugins/maven-site-plugin/target/local-repo/
layout: default
snapshots: [enabled => true, update => always]
releases: [enabled => true, update => always]
[DEBUG] (f) mavenSession = org.apache.maven.execution.MavenSession@75f3e0c5
[DEBUG] (f) project = MavenProject:
org.apache.maven.plugins.site.its:MSITE-604:1.0-SNAPSHOT @
/home/jos/src/Apache/Maven/Plugins/maven-site-plugin/target/it/MSITE-604/pom.xml
[DEBUG] (f) reactorProjects = [MavenProject:
org.apache.maven.plugins.site.its:MSITE-604:1.0-SNAPSHOT @
/home/jos/src/Apache/Maven/Plugins/maven-site-plugin/target/it/MSITE-604/pom.xml]
[DEBUG] (f) settings = org.apache.maven.execution.SettingsAdapter@7233d91f
[DEBUG] (f) siteDirectory =
/home/jos/src/Apache/Maven/Plugins/maven-site-plugin/target/it/MSITE-604/src/site
[DEBUG] (f) skipDeploy = false
[DEBUG] -- end configuration --
[DEBUG] Deploying to '${msite604.siteRepository.Root}/settingsRepositoryUrl/',
Using credentials from server id 'settingsId'
[INFO]
[INFO] BUILD FAILURE
[INFO]
[INFO] Total time: 2.506 s
[INFO] Finished at: 2014-10-10T13:26:43+02:00
[INFO] Final Memory: 19M/214M
[INFO]
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-site-plugin:3.4.1-SNAPSHOT:deploy (default-cli)
on project MSITE-604: Wagon protocol '' doesn't support directory copying ->
[Help 1]
{noformat}
As you can see, one of the properties of settings.xml has been substituted, the
other one (containing the protocol) has not.
{noformat}
$ mvn -version
Apache Maven 3.2.3 (33f8c3e1027c3ddde99d3cdebad2656a31e8fdf4;
2014-08-11T22:58:10+02:00)
Maven home: /usr/share/maven-bin-3.2
Java version: 1.7.0_67, vendor: Oracle Corporation
Java home: /opt/oracle-jdk-bin-1.7.0.67/jre
Default locale: en_US, platform encoding: UTF-8
OS name: "linux", version: "3.14.14-gentoo", arch: "amd64", family: "unix"
{noformat}
was (Author: joehni):
New MSITE-604-it.patch against svn rev 1630660. IT executed with:
rm -rf target/it
mvn integration-test -Prun-its -Dinvoker.test=MSITE-604
Build fails, extract from build.log:
{noformat}
[INFO] --- maven-site-plugin:3.4.1-SNAPSHOT:deploy (default-cli) @ MSITE-604 ---
[DEBUG] Configuring mojo
org.apache.maven.plugins:maven-site-plugin:3.4.1-SNAPSHOT:deploy from plugin
realm
ClassRealm[plugin>org.apache.maven.plugins:maven-site-plugin:3.4.1-SNAPSHOT,
parent: sun.misc.Launcher$AppClassLoader@2bb0bf9a]
[DEBUG] Configuring mojo
'org.apache.maven.plugins:maven-site-plugin:3.4.1-SNAPSHOT:deploy' with basic
configurator -->
[DEBUG] (f) chmod = true
[DEBUG] (f) chmodMode = g+w,a+rX
[DEBUG] (f) chmodOptions = -Rf
[DEBUG] (f) inputDirectory =
/home/jos/src/Apache/Maven/Plugins/maven-site-plugin/target/it/MSITE-604/target/site
[DEBUG] (f) inputEncoding = UTF-8
[DEBUG] (f) localRepository = id: local
url:
file:///home/jos/src/Apache/Maven/Plugins/maven-site-plugin/target/local-repo/
layout: default
snapshots: [enabled => true, update => always]
releases: [enabled => true, update => always]
[DEBUG] (f) mavenSession = org.apache.maven.execution.MavenSession@75f3e0c5
[DEBUG] (f) project = MavenProject:
org.apache.maven.plugins.site.its:MSITE-604:1.0-SNAPSHOT @
/home/jos/src/Apache/Maven/Plugins/maven-site-plugin/target/it/MSITE-604/pom.xml
[DEBUG] (f) reactorProjects = [MavenProject:
org.apache.maven.plugins.site.its:MSITE-604:1.0-SNAPSHOT @
/home/jos/src/Apache/Maven/Plu
[jira] (MSITE-604) Properties from settings.xml are not recognized in site distribution management
[
https://jira.codehaus.org/browse/MSITE-604?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jörg Schaible updated MSITE-604:
Attachment: MSITE-604-it.patch
New MSITE-604-it.patch against svn rev 1630660. IT executed with:
rm -rf target/it
mvn integration-test -Prun-its -Dinvoker.test=MSITE-604
Build fails, extract from build.log:
{noformat}
[INFO] --- maven-site-plugin:3.4.1-SNAPSHOT:deploy (default-cli) @ MSITE-604 ---
[DEBUG] Configuring mojo
org.apache.maven.plugins:maven-site-plugin:3.4.1-SNAPSHOT:deploy from plugin
realm
ClassRealm[plugin>org.apache.maven.plugins:maven-site-plugin:3.4.1-SNAPSHOT,
parent: sun.misc.Launcher$AppClassLoader@2bb0bf9a]
[DEBUG] Configuring mojo
'org.apache.maven.plugins:maven-site-plugin:3.4.1-SNAPSHOT:deploy' with basic
configurator -->
[DEBUG] (f) chmod = true
[DEBUG] (f) chmodMode = g+w,a+rX
[DEBUG] (f) chmodOptions = -Rf
[DEBUG] (f) inputDirectory =
/home/jos/src/Apache/Maven/Plugins/maven-site-plugin/target/it/MSITE-604/target/site
[DEBUG] (f) inputEncoding = UTF-8
[DEBUG] (f) localRepository = id: local
url:
file:///home/jos/src/Apache/Maven/Plugins/maven-site-plugin/target/local-repo/
layout: default
snapshots: [enabled => true, update => always]
releases: [enabled => true, update => always]
[DEBUG] (f) mavenSession = org.apache.maven.execution.MavenSession@75f3e0c5
[DEBUG] (f) project = MavenProject:
org.apache.maven.plugins.site.its:MSITE-604:1.0-SNAPSHOT @
/home/jos/src/Apache/Maven/Plugins/maven-site-plugin/target/it/MSITE-604/pom.xml
[DEBUG] (f) reactorProjects = [MavenProject:
org.apache.maven.plugins.site.its:MSITE-604:1.0-SNAPSHOT @
/home/jos/src/Apache/Maven/Plugins/maven-site-plugin/target/it/MSITE-604/pom.xml]
[DEBUG] (f) settings = org.apache.maven.execution.SettingsAdapter@7233d91f
[DEBUG] (f) siteDirectory =
/home/jos/src/Apache/Maven/Plugins/maven-site-plugin/target/it/MSITE-604/src/site
[DEBUG] (f) skipDeploy = false
[DEBUG] -- end configuration --
[DEBUG] Deploying to '${msite604.siteRepository.Root}/settingsRepositoryUrl/',
Using credentials from server id 'settingsId'
[INFO]
[INFO] BUILD FAILURE
[INFO]
[INFO] Total time: 2.506 s
[INFO] Finished at: 2014-10-10T13:26:43+02:00
[INFO] Final Memory: 19M/214M
[INFO]
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-site-plugin:3.4.1-SNAPSHOT:deploy (default-cli)
on project MSITE-604: Wagon protocol '' doesn't support directory copying ->
[Help 1]
{noformat}
As you can see, one of the properties of settings.xml has been substituted, the
other one (containing the protocol) has not.
{noformat}
$ mvn -version
Apache Maven 3.2.3 (33f8c3e1027c3ddde99d3cdebad2656a31e8fdf4;
2014-08-11T22:58:10+02:00)
Maven home: /usr/share/maven-bin-3.2
Java version: 1.7.0_67, vendor: Oracle Corporation
Java home: /opt/oracle-jdk-bin-1.7.0.67/jre
Default locale: en_US, platform encoding: UTF-8
OS name: "linux", version: "3.14.14-gentoo", arch: "amd64", family: "unix"
{noformat}
> Properties from settings.xml are not recognized in site distribution
> management
>
>
> Key: MSITE-604
> URL: https://jira.codehaus.org/browse/MSITE-604
> Project: Maven Site Plugin
> Issue Type: Bug
> Components: site:deploy
>Affects Versions: 3.0
> Environment: Apache Maven 2.2.1 and 3.0.3
>Reporter: Marcin Kuthan
> Fix For: backlog
>
> Attachments: MSITE-604-it.patch, MSITE-604-it.patch,
> MSITE-604-maven3-2.patch, MSITE-604-maven3.patch, MSITE-604.tgz
>
>
> My distribution management section looks like:
> {code}
>
>
>${acme-corporate-pom.siteRepositoryId}
>${acme-corporate-pom.siteRepositoryUrl}
>
>
> {code}
> Where the default property values are defined in the pom:
> {code}
>
>
> acme-site
>
> scp://sites.intranet.acme.com/var/www
>
> {code}
> I'm able redefine properties from command line, the provided repository is
> used instead default one:
> {code}
> mvn site:site site:deploy
> -Dacme-corporate-pom.siteRepositoryUrl=scp://somehost/var/www/sites
> -Dacme-corporate-pom.siteRepositoryId=somehost
> {code}
> But when I redefine properties in the profile in {{settings.xml}}, they are
> ignored. The profile is activated in {{ It looks, than only m-site-p ignores properties defined in the
> {{settings.xml}} file. m-deploy-p recognizes properties as I expected
> (distribution management section for articats deployment is configured in
> similar way to site deployment).
> --
> Marcin Kuthan
> Maven For Enterprise - http://code.google.com/p/m4enterprise/
-
[jira] (MPMD-174) Using a permalink from sonar as a ruleset does not work
[ https://jira.codehaus.org/browse/MPMD-174?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=354150#comment-354150 ] Marek Å iller commented on MPMD-174: I can confirm this issue as well. Everything is working fine as long as you use a local ruleset. As soon as you switch to ruleset from SonarQube, it doesn't work. Essentially what happens is following: maven-pmd-plugin calls PMD -> it creates new instance of RuleSetReferenceId. In the constructor, several assumptions are made, so eventually it strips everything after the last "/" from the URL (in case of SonarQube http://sonar-instance/profiles). This URL gets passed back to maven-pmd-plugin for download. It downloads a HTML page and stores it in a temporary file. This file gets passed to PMD as a ruleset and you get an exception, because the downloaded HTML page is not a PMD ruleset. The problem can be solved in three ways: * in maven-pmd-plugin: see attached patch file. If a http or https URL is specified, it just downloads the ruleset and doesn't parse the URL using RuleSetReferenceId constructor. * as a workaround: just add ".xml" to your profiles' names in SonarQube * in PMD: fix the constructor of RuleSetReferenceId so that it can handle HTTP URLs I currently use a patched version of maven-pmd-plugin as I don't want to rename my profiles in SonarQube. > Using a permalink from sonar as a ruleset does not work > --- > > Key: MPMD-174 > URL: https://jira.codehaus.org/browse/MPMD-174 > Project: Maven PMD Plugin > Issue Type: Bug >Reporter: Cremers stijn > Attachments: MPMD-174.patch > > > I am trying to use a permalink from sonar with the pmd configuration from > sonar as a rulest in the maven-pmd-plugin. > This is my maven configuration: > > org.apache.maven.plugins > maven-pmd-plugin > 3.0.1 > > > > http://my-tools.mycompany.com/sonar/profiles/export?format=pmd&language=java&name=MyProfile > > > > > pmd > check > > > > But i get the following error when i run "mvn clean install": > [ERROR] Failed to execute goal > org.apache.maven.plugins:maven-pmd-plugin:3.0.1:pmd (pmd) on project my-pmd: > An error has occurred in PMD Report report generation. Could not find > resource 'rulesets/http://my/tools.mycompany.com/sonar/profiles.xml'. -> > [Help 1] > I have tried to use the link from the sonar demo site: > > org.apache.maven.plugins > maven-pmd-plugin > 3.0.1 > > > > http://nemo.sonarqube.org/profiles/export?format=pmd&language=java&name=Nemo > > > > > pmd > check > > > > But then i get the following error: > [INFO] --- maven-pmd-plugin:3.0.1:pmd (pmd) @ my-pmd --- > [WARNING] Unable to locate Source XRef to link to - DISABLED > [WARNING] Failure executing PMD: Couldn't find the class White spaces are > required between publicId and systemId. > java.lang.RuntimeException: Couldn't find the class White spaces are required > between publicId and systemId. > at > net.sourceforge.pmd.RuleSetFactory.classNotFoundProblem(RuleSetFactory.java:244) > at > net.sourceforge.pmd.RuleSetFactory.parseRuleSetNode(RuleSetFactory.java:238) > at > net.sourceforge.pmd.RuleSetFactory.createRuleSet(RuleSetFactory.java:161) > at > net.sourceforge.pmd.RuleSetFactory.createRuleSets(RuleSetFactory.java:126) > at > net.sourceforge.pmd.RuleSetFactory.createRuleSets(RuleSetFactory.java:111) > at > net.sourceforge.pmd.processor.AbstractPMDProcessor.createRuleSets(AbstractPMDProcessor.java:56) > at > net.sourceforge.pmd.processor.MonoThreadProcessor.processFiles(MonoThreadProcessor.java:41) > at net.sourceforge.pmd.PMD.processFiles(PMD.java:271) > at > org.apache.maven.plugin.pmd.PmdReport.generateReport(PmdReport.java:296) > at org.apache.maven.plugin.pmd.PmdReport.execute(PmdReport.java:194) > at > org.apache.maven.plugin.pmd.PmdReport.executeReport(PmdReport.java:168) > at > org.apache.maven.reporting.AbstractMavenReport.generate(AbstractMavenReport.java:190) > at > org.apache.maven.reporting.AbstractMavenReport.execute(AbstractMavenReport.java:99) > at > org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:106) > at > org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208) > 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.MojoExecutor.executeForkedExecutions(MojoExecutor.java:364) > at
[jira] (MPMD-174) Using a permalink from sonar as a ruleset does not work
[ https://jira.codehaus.org/browse/MPMD-174?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marek Å iller updated MPMD-174: --- Attachment: MPMD-174.patch > Using a permalink from sonar as a ruleset does not work > --- > > Key: MPMD-174 > URL: https://jira.codehaus.org/browse/MPMD-174 > Project: Maven PMD Plugin > Issue Type: Bug >Reporter: Cremers stijn > Attachments: MPMD-174.patch > > > I am trying to use a permalink from sonar with the pmd configuration from > sonar as a rulest in the maven-pmd-plugin. > This is my maven configuration: > > org.apache.maven.plugins > maven-pmd-plugin > 3.0.1 > > > > http://my-tools.mycompany.com/sonar/profiles/export?format=pmd&language=java&name=MyProfile > > > > > pmd > check > > > > But i get the following error when i run "mvn clean install": > [ERROR] Failed to execute goal > org.apache.maven.plugins:maven-pmd-plugin:3.0.1:pmd (pmd) on project my-pmd: > An error has occurred in PMD Report report generation. Could not find > resource 'rulesets/http://my/tools.mycompany.com/sonar/profiles.xml'. -> > [Help 1] > I have tried to use the link from the sonar demo site: > > org.apache.maven.plugins > maven-pmd-plugin > 3.0.1 > > > > http://nemo.sonarqube.org/profiles/export?format=pmd&language=java&name=Nemo > > > > > pmd > check > > > > But then i get the following error: > [INFO] --- maven-pmd-plugin:3.0.1:pmd (pmd) @ my-pmd --- > [WARNING] Unable to locate Source XRef to link to - DISABLED > [WARNING] Failure executing PMD: Couldn't find the class White spaces are > required between publicId and systemId. > java.lang.RuntimeException: Couldn't find the class White spaces are required > between publicId and systemId. > at > net.sourceforge.pmd.RuleSetFactory.classNotFoundProblem(RuleSetFactory.java:244) > at > net.sourceforge.pmd.RuleSetFactory.parseRuleSetNode(RuleSetFactory.java:238) > at > net.sourceforge.pmd.RuleSetFactory.createRuleSet(RuleSetFactory.java:161) > at > net.sourceforge.pmd.RuleSetFactory.createRuleSets(RuleSetFactory.java:126) > at > net.sourceforge.pmd.RuleSetFactory.createRuleSets(RuleSetFactory.java:111) > at > net.sourceforge.pmd.processor.AbstractPMDProcessor.createRuleSets(AbstractPMDProcessor.java:56) > at > net.sourceforge.pmd.processor.MonoThreadProcessor.processFiles(MonoThreadProcessor.java:41) > at net.sourceforge.pmd.PMD.processFiles(PMD.java:271) > at > org.apache.maven.plugin.pmd.PmdReport.generateReport(PmdReport.java:296) > at org.apache.maven.plugin.pmd.PmdReport.execute(PmdReport.java:194) > at > org.apache.maven.plugin.pmd.PmdReport.executeReport(PmdReport.java:168) > at > org.apache.maven.reporting.AbstractMavenReport.generate(AbstractMavenReport.java:190) > at > org.apache.maven.reporting.AbstractMavenReport.execute(AbstractMavenReport.java:99) > at > org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:106) > at > org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208) > 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.MojoExecutor.executeForkedExecutions(MojoExecutor.java:364) > at > org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:198) > 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:84) > at > org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59) > at > org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183) > at > org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161) > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:318) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:153) > at org.apache.maven.cli.MavenCli.execute(MavenCli.java:555) > at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:214) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:158) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAcces
