[jira] [Created] (MCOMPILER-457) Change showWarnings to true by default
Thomas Broyer created MCOMPILER-457:
---
Summary: Change showWarnings to true by default
Key: MCOMPILER-457
URL: https://issues.apache.org/jira/browse/MCOMPILER-457
Project: Maven Compiler Plugin
Issue Type: Improvement
Reporter: Thomas Broyer
I see no reason to hide warnings by default, and setting {{failOnWarning}} to
{{true}} will be useless without also setting {{showWarnings}} to {{true}}; but
you'll actually never know until you *actually* expect a warning (and build
failure) and doesn't see it. Setting {{failOnWarning}} preventively without
also setting {{showWarnings}} thus won't prevent anything; even if you also
pass a strict {{-Xlint:all}} (because {{-nowarn}} has precedence apparently).
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MCOMPILER-235) duplicate classes due to MCOMPILER-157 when compiler is called twice or more
[
https://issues.apache.org/jira/browse/MCOMPILER-235?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15114259#comment-15114259
]
Thomas Broyer commented on MCOMPILER-235:
-
The source code changes look good, but wouldn't it be somewhat easier to just
defer adding the generatedSourcesDirectory to the compileSourceRoots to after
the actual compilation (or use of the compileSourceRoots) ? (accounting for the
early exits when everything's up-to-date and compilation is skipped entirely)
Also tried it and it appears to work OK (would be even better to ensure
non-regression in the future with an integration test if you ask me, just have
the `invoker.properties` do the build twice)
> duplicate classes due to MCOMPILER-157 when compiler is called twice or more
>
>
> Key: MCOMPILER-235
> URL: https://issues.apache.org/jira/browse/MCOMPILER-235
> Project: Maven Compiler Plugin
> Issue Type: Bug
>Affects Versions: 3.2
> Environment: Maven 3.2.3
>Reporter: Arnaud HERITIER
>Assignee: Andreas Gudian
> Attachments: MCOMPILER-235.zip
>
>
> I tried to upgrade our projects to use the compiler 3.2 and instead of 3.1
> Classical builds are ok but site builds are KO because for various reasons
> (reports) the lifecycle is forked and thus the compiler is called twice (or
> more) and fails because it finds duplicated classes
> Example :
> {code}
> [INFO]
>
> [INFO] Building eXo Commons - Common Services 4.1.x-SNAPSHOT
> [INFO]
>
> [INFO]
> [INFO] --- maven-enforcer-plugin:1.3.1:enforce (enforce-java-version) @
> commons-component-common ---
> [INFO]
> [INFO] --- maven-enforcer-plugin:1.3.1:enforce (enforce-maven-version) @
> commons-component-common ---
> [INFO]
> [INFO] --- buildnumber-maven-plugin:1.3:create (default) @
> commons-component-common ---
> [INFO]
> [INFO] --- jacoco-maven-plugin:0.7.2.201409121644:prepare-agent
> (prepare-ut-agent) @ commons-component-common ---
> [INFO] argLine set to
> -javaagent:/srv/ciagent/workspace/commons-master-site/.repository/org/jacoco/org.jacoco.agent/0.7.2.201409121644/org.jacoco.agent-0.7.2.201409121644-runtime.jar=destfile=/srv/ciagent/workspace/commons-master-site/sources/commons-component-common/target/jacoco.exec,append=true
> [INFO]
> [INFO] --- maven-resources-plugin:2.7:resources (default-resources) @
> commons-component-common ---
> [INFO] Using 'UTF-8' encoding to copy filtered resources.
> [INFO] Copying 0 resource
> [INFO] Copying 5 resources
> [INFO]
> [INFO] --- maven-compiler-plugin:3.2:compile (default-compile) @
> commons-component-common ---
> [INFO] Changes detected - recompiling the module!
> [INFO] Compiling 97 source files to
> /srv/ciagent/workspace/commons-master-site/sources/commons-component-common/target/classes
> [WARNING] Supported source version 'RELEASE_5' from annotation processor
> 'org.chromattic.apt.ChromatticProcessor' less than -source '1.7'
> [INFO] About to process the type
> org.exoplatform.settings.chromattic.SettingsRoot
> [INFO] About to process the type
> org.exoplatform.settings.chromattic.SubContextEntity
> [INFO] About to process the type
> org.exoplatform.settings.chromattic.SimpleContextEntity
> [INFO] About to process the type
> org.exoplatform.settings.chromattic.ScopeEntity
> [INFO] About to process the type
> org.exoplatform.settings.chromattic.ContextEntity
> [INFO] Processing node type package org.exoplatform.settings.chromattic
> [INFO]
> /srv/ciagent/workspace/commons-master-site/sources/commons-component-common/src/main/java/org/exoplatform/services/user/UserStateService.java:
> Some input files use unchecked or unsafe operations.
> [INFO]
> /srv/ciagent/workspace/commons-master-site/sources/commons-component-common/src/main/java/org/exoplatform/services/user/UserStateService.java:
> Recompile with -Xlint:unchecked for details.
> [INFO]
> [INFO] --- maven-resources-plugin:2.7:testResources (default-testResources) @
> commons-component-common ---
> [INFO] Using 'UTF-8' encoding to copy filtered resources.
> [INFO] Copying 19 resources
> [INFO]
> [INFO] --- maven-compiler-plugin:3.2:testCompile (default-testCompile) @
> commons-component-common ---
> [INFO] Changes detected - recompiling the module!
> [INFO] Compiling 32 source files to
> /srv/ciagent/workspace/commons-master-site/sources/commons-component-common/target/test-classes
> [WARNING]
> /srv/ciagent/workspace/commons-master-site/sources/commons-component-common/src/test/java/org/exoplatform/commons/event/TestEventManager.java:[29,23]
> junit.framework.Assert in junit.framework has been deprecated
> [WARNING] Supported source version
[jira] [Commented] (MCOMPILER-203) Allow compiler-plugin to specify annotation processor dependencies
[
https://issues.apache.org/jira/browse/MCOMPILER-203?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15114055#comment-15114055
]
Thomas Broyer commented on MCOMPILER-203:
-
FWIW, one big issue with this (but which is not imputable to the plugin, but to
Maven's design), is that dependencies declared in the
`annotationProcessorPaths` don't participate in the Maven execution graph
analysis, such that Maven cannot guarantee that within a reactor build
annotation processors will actually be built before the modules that use them.
> Allow compiler-plugin to specify annotation processor dependencies
> --
>
> Key: MCOMPILER-203
> URL: https://issues.apache.org/jira/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
>Assignee: Andreas Gudian
> Fix For: 3.5
>
>
> 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.3.4#6332)
[jira] (MCOMPILER-122) -sourcepath shall include resources
[ https://jira.codehaus.org/browse/MCOMPILER-122?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=363753#comment-363753 ] Thomas Broyer commented on MCOMPILER-122: - How about resource filtering? relocation? includes/excludes patterns? or just more resources root directory than just the default src/main/resources? cf. https://maven.apache.org/pom.html#Resources -sourcepath shall include resources --- Key: MCOMPILER-122 URL: https://jira.codehaus.org/browse/MCOMPILER-122 Project: Maven Compiler Plugin Issue Type: Bug Affects Versions: 2.1 Reporter: Milos Kleint annotation processors which load non-Java resources from the sourcepath, will currently get only the src/main/java folder. Unfortunately just adding src/main/resources to -sourcepath does not suffice, due to a bug in javac: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6929404 see MCOMPILER-98 for more -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MCOMPILER-174) Maven compiler plugin excludes doesn't work all the time
[ https://jira.codehaus.org/browse/MCOMPILER-174?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=363716#comment-363716 ] Thomas Broyer commented on MCOMPILER-174: - MCOMPILER-26 got it right, but this was later reverted in MCOMPILER-98. Maven compiler plugin excludes doesn't work all the time -- Key: MCOMPILER-174 URL: https://jira.codehaus.org/browse/MCOMPILER-174 Project: Maven Compiler Plugin Issue Type: Bug Affects Versions: 2.4, 2.5 Environment: N/A Reporter: Matthew Lavin When you set a source file as configuration excludes excludecom/you/example.java/exclude /excludes /configuration it doesn't pass the file in with the list of .java files to javac. However, it still passes in the ./src/ directory under the -sourcepath option to the javac command. Thus, javac still knows that the file exists and can try to compile it anyways under certain circumstances. The passing of ./src/ under -sourcepath is redundant anyways, as every single file to be compiled is passed (in my case, all 391 source files) to javac. The only possible result from passing ./src/ (or at least the only one I can think of) is that a file which is in your ./src/ directory yet excluded by the maven-compiler-plugin can still be seen (and compiled) by javac. This can cause inexplicable results and a lot of confusion since it operates in a counter-intuitive way. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MCOMPILER-122) -sourcepath shall include resources
[ https://jira.codehaus.org/browse/MCOMPILER-122?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=363715#comment-363715 ] Thomas Broyer commented on MCOMPILER-122: - This is a bad idea IMO. First, annotation processors shouldn't depend on non-java inputs, because JSR-269 doesn't allow you to track dependencies of generated sources/classes/resources to anything else than elements: http://docs.oracle.com/javase/7/docs/api/javax/annotation/processing/Filer.html (File#getResource is rather meant to read resources that were previously generated by File#createResource, but should still be used with care). Also, including target/classes to sourcepath could lead to classes being compiled or recompiled when they shouldn't (when you have *.java files as resources but not sources). Fortunately, there'd be an easy workaround here: exclude *.java files from project.build.resources and use resources:copy-resources after the compile phase to copy the *.java files; that'd still be a hack if you ask me. -sourcepath shall include resources --- Key: MCOMPILER-122 URL: https://jira.codehaus.org/browse/MCOMPILER-122 Project: Maven Compiler Plugin Issue Type: Bug Affects Versions: 2.1 Reporter: Milos Kleint annotation processors which load non-Java resources from the sourcepath, will currently get only the src/main/java folder. Unfortunately just adding src/main/resources to -sourcepath does not suffice, due to a bug in javac: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6929404 see MCOMPILER-98 for more -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MCOMPILER-202) Plugin dependencies not added to compiler classpath with javax.tools.Compiler
[
https://jira.codehaus.org/browse/MCOMPILER-202?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=322737#comment-322737
]
Thomas Broyer commented on MCOMPILER-202:
-
I just tried with {{-Dmaven.compiler.fork}} and annotations aren't processed,
with either 2.5 or 3.0, so it looks like using plugin dependencies never was a
supported use-case.
See also https://github.com/square/dagger/issues/194 (using 3.0 with
{{forceJavacCompilerUse}} doesn't work on OSX, with Apple's JDK 6, so we'll
revert the change in Dagger to use a provided or optional project dependency)
Plugin dependencies not added to compiler classpath with javax.tools.Compiler
-
Key: MCOMPILER-202
URL: https://jira.codehaus.org/browse/MCOMPILER-202
Project: Maven 2.x Compiler Plugin
Issue Type: Bug
Affects Versions: 3.0
Environment: Maven 3.0.4, Ubuntu 12.10, OpenJDK 6u27 (Ubuntu
package), OpenJDK 7u15 (Ubuntu package), Oracle JDK 6u27, Oracle JDK 8
(1.8.0-ea-b81)
Reporter: Thomas Broyer
Dependencies added to the maven-compiler-plugin used to be added to the
compiler classpath with previous versions (tested with 2.4, 2.5 and 2.5.1)
but no longer are with 3.0. This was very useful for annotation processors,
that shouldn't affect dependency mediation in downstream projects.
This seems to be due to the switch to {{javax.tools}} as setting
{{forceJavacCompilerUse}} to {{true}} works around the issue.
To reproduce:
1. clone https://github.com/square/dagger/
2. edit examples/simple/pom.xml and move the {{dagger-compiler}} dependency
into the {{maven-compiler-plugin}}, and set the m-c-p version to 3.0
3. {{mvn package}}
*Expected behavior:*
sources should be generated into {{target/generated-sources/annotations}} and
there should be {{xxx$InjectAdapter}} and {{xxx$ModuleAdapter}} classes in
{{target/classes}}.
Now change the m-c-p version to 2.5.1 or set {{forceJavacCompilerUse}} to
{{true}}: behavior is as expected.
Ideally, we'd want MCOMPILER-134 with an explicit {{processorpath}}.
See also the discussion at https://github.com/square/dagger/pull/182 which
lead me to create this issue.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MCOMPILER-202) Plugin dependencies not added to compiler classpath with javax.tools.Compiler
[
https://jira.codehaus.org/browse/MCOMPILER-202?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=322547#comment-322547
]
Thomas Broyer commented on MCOMPILER-202:
-
Note: Dagger now workarounds the issue:
https://github.com/square/dagger/pull/190
The steps to reproduce thus become:
1. clone https://github.com/square/dagger/
2. edit {{examples/simple/pom.xml}} and remove {{forceJavacCompilerUse}} (or
set it to {{false}})
3. {{mvn package}}
Plugin dependencies not added to compiler classpath with javax.tools.Compiler
-
Key: MCOMPILER-202
URL: https://jira.codehaus.org/browse/MCOMPILER-202
Project: Maven 2.x Compiler Plugin
Issue Type: Bug
Affects Versions: 3.0
Environment: Maven 3.0.4, Ubuntu 12.10, OpenJDK 6u27 (Ubuntu
package), OpenJDK 7u15 (Ubuntu package), Oracle JDK 6u27, Oracle JDK 8
(1.8.0-ea-b81)
Reporter: Thomas Broyer
Dependencies added to the maven-compiler-plugin used to be added to the
compiler classpath with previous versions (tested with 2.4, 2.5 and 2.5.1)
but no longer are with 3.0. This was very useful for annotation processors,
that shouldn't affect dependency mediation in downstream projects.
This seems to be due to the switch to {{javax.tools}} as setting
{{forceJavacCompilerUse}} to {{true}} works around the issue.
To reproduce:
1. clone https://github.com/square/dagger/
2. edit examples/simple/pom.xml and move the {{dagger-compiler}} dependency
into the {{maven-compiler-plugin}}, and set the m-c-p version to 3.0
3. {{mvn package}}
*Expected behavior:*
sources should be generated into {{target/generated-sources/annotations}} and
there should be {{xxx$InjectAdapter}} and {{xxx$ModuleAdapter}} classes in
{{target/classes}}.
Now change the m-c-p version to 2.5.1 or set {{forceJavacCompilerUse}} to
{{true}}: behavior is as expected.
Ideally, we'd want MCOMPILER-134 with an explicit {{processorpath}}.
See also the discussion at https://github.com/square/dagger/pull/182 which
lead me to create this issue.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MCOMPILER-202) Plugin dependencies not added to compiler classpath with javax.tools.Compiler
Thomas Broyer created MCOMPILER-202:
---
Summary: Plugin dependencies not added to compiler classpath with
javax.tools.Compiler
Key: MCOMPILER-202
URL: https://jira.codehaus.org/browse/MCOMPILER-202
Project: Maven 2.x Compiler Plugin
Issue Type: Bug
Affects Versions: 3.0
Environment: Maven 3.0.4, Ubuntu 12.10, OpenJDK 6u27 (Ubuntu package),
OpenJDK 7u15 (Ubuntu package), Oracle JDK 6u27, Oracle JDK 8 (1.8.0-ea-b81)
Reporter: Thomas Broyer
Dependencies added to the maven-compiler-plugin used to be added to the
compiler classpath with previous versions (tested with 2.4, 2.5 and 2.5.1) but
no longer are with 3.0. This was very useful for annotation processors, that
shouldn't affect dependency mediation in downstream projects.
This seems to be due to the switch to {{javax.tools}} as setting
{{forceJavacCompilerUse}} to {{true}} works around the issue.
To reproduce:
1. clone https://github.com/square/dagger/
2. edit examples/simple/pom.xml and move the {{dagger-compiler}} dependency
into the {{maven-compiler-plugin}}, and set the m-c-p version to 3.0
3. {{mvn package}}
*Expected behavior:*
sources should be generated into {{target/generated-sources/annotations}} and
there should be {{xxx$InjectAdapter}} and {{xxx$ModuleAdapter}} classes in
{{target/classes}}.
Now change the m-c-p version to 2.5.1 or set {{forceJavacCompilerUse}} to
{{true}}: behavior is as expected.
Ideally, we'd want MCOMPILER-134 with an explicit {{processorpath}}.
See also the discussion at https://github.com/square/dagger/pull/182 which lead
me to create this issue.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (SUREFIRE-450) Verification test failure: Invalid mavenProfile entry. Missing one or more fields: {localRepository}
[
https://jira.codehaus.org/browse/SUREFIRE-450?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=312591#comment-312591
]
Thomas Broyer commented on SUREFIRE-450:
I faced this issue recently and although it's an issue in MVERIFIER and not
surefire, I'll add some info here.
The problem was that my settings.xml contained an empty {{localRepository/}}
element. A minimal settings.xml that would reproduce the issue would probably
be:
{code}
settings xmlns=http://maven.apache.org/SETTINGS/1.0.0;
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xsi:schemaLocation=http://maven.apache.org/SETTINGS/1.0.0
http://maven.apache.org/xsd/settings-1.0.0.xsd;
localRepository/
/settings
{code}
MVERIFIER, when processing that element ({{Verifier.java}} line 1883 in
MVERIFIER 1.3) throws that {{SAXException}}. It should probably use the default
value instead of throwing, as Maven otherwise has no problem with the empty
element (and uses the default value).
Verification test failure: Invalid mavenProfile entry. Missing one or more
fields: {localRepository}
Key: SUREFIRE-450
URL: https://jira.codehaus.org/browse/SUREFIRE-450
Project: Maven Surefire
Issue Type: Bug
Affects Versions: Backlog
Environment: java version 1.5.0_13
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_13-b05-241)
Java HotSpot(TM) Client VM (build 1.5.0_13-121, mixed mode, sharing)
Reporter: Graham Leggett
All tests in surefire-integration-tests fail like so:
testTwoTestCases(org.apache.maven.surefire.its.TwoTestCasesTest) Time
elapsed: 0.011 sec ERROR!
org.apache.maven.it.VerificationException: org.xml.sax.SAXException: Invalid
mavenProfile entry. Missing one or more fields: {localRepository}.
at
org.apache.maven.it.Verifier$UserModelReader.parse(Verifier.java:1269)
at org.apache.maven.it.Verifier.retrieveLocalRepo(Verifier.java:557)
at org.apache.maven.it.Verifier.findLocalRepo(Verifier.java:1178)
at org.apache.maven.it.Verifier.init(Verifier.java:101)
at org.apache.maven.it.Verifier.init(Verifier.java:80)
at org.apache.maven.it.Verifier.init(Verifier.java:107)
at
org.apache.maven.surefire.its.TwoTestCasesTest.testTwoTestCases(TwoTestCasesTest.java:27)
It looks like the localRepository setting is missing from a pom or config
file somewhere.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (SUREFIRE-450) Verification test failure: Invalid mavenProfile entry. Missing one or more fields: {localRepository}
[
https://jira.codehaus.org/browse/SUREFIRE-450?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=312591#comment-312591
]
Thomas Broyer edited comment on SUREFIRE-450 at 10/30/12 5:12 AM:
--
I faced this issue recently and although it's an issue in MVERIFIER and not
surefire, I'll add some info here.
The problem was that my settings.xml contained an empty {{localRepository/}}
element. A minimal settings.xml that would reproduce the issue would probably
be:
{code}
settings xmlns=http://maven.apache.org/SETTINGS/1.0.0;
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xsi:schemaLocation=http://maven.apache.org/SETTINGS/1.0.0
http://maven.apache.org/xsd/settings-1.0.0.xsd;
localRepository/
/settings
{code}
MVERIFIER, when processing that element ({{Verifier.java}} line 1883 in
MVERIFIER 1.3) throws that {{SAXException}}. It should probably use the default
value instead of throwing, as Maven otherwise has no problem with the empty
element (and uses the default value).
A related issue on MVERIFIER side: MVERIFIER-10
was (Author: t.broyer):
I faced this issue recently and although it's an issue in MVERIFIER and not
surefire, I'll add some info here.
The problem was that my settings.xml contained an empty {{localRepository/}}
element. A minimal settings.xml that would reproduce the issue would probably
be:
{code}
settings xmlns=http://maven.apache.org/SETTINGS/1.0.0;
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xsi:schemaLocation=http://maven.apache.org/SETTINGS/1.0.0
http://maven.apache.org/xsd/settings-1.0.0.xsd;
localRepository/
/settings
{code}
MVERIFIER, when processing that element ({{Verifier.java}} line 1883 in
MVERIFIER 1.3) throws that {{SAXException}}. It should probably use the default
value instead of throwing, as Maven otherwise has no problem with the empty
element (and uses the default value).
Verification test failure: Invalid mavenProfile entry. Missing one or more
fields: {localRepository}
Key: SUREFIRE-450
URL: https://jira.codehaus.org/browse/SUREFIRE-450
Project: Maven Surefire
Issue Type: Bug
Affects Versions: Backlog
Environment: java version 1.5.0_13
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_13-b05-241)
Java HotSpot(TM) Client VM (build 1.5.0_13-121, mixed mode, sharing)
Reporter: Graham Leggett
All tests in surefire-integration-tests fail like so:
testTwoTestCases(org.apache.maven.surefire.its.TwoTestCasesTest) Time
elapsed: 0.011 sec ERROR!
org.apache.maven.it.VerificationException: org.xml.sax.SAXException: Invalid
mavenProfile entry. Missing one or more fields: {localRepository}.
at
org.apache.maven.it.Verifier$UserModelReader.parse(Verifier.java:1269)
at org.apache.maven.it.Verifier.retrieveLocalRepo(Verifier.java:557)
at org.apache.maven.it.Verifier.findLocalRepo(Verifier.java:1178)
at org.apache.maven.it.Verifier.init(Verifier.java:101)
at org.apache.maven.it.Verifier.init(Verifier.java:80)
at org.apache.maven.it.Verifier.init(Verifier.java:107)
at
org.apache.maven.surefire.its.TwoTestCasesTest.testTwoTestCases(TwoTestCasesTest.java:27)
It looks like the localRepository setting is missing from a pom or config
file somewhere.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MVERIFIER-10) Print the absolute path to the input file when verification fails
[
https://jira.codehaus.org/browse/MVERIFIER-10?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=312596#comment-312596
]
Thomas Broyer commented on MVERIFIER-10:
I faced this issue recently with 1.3.
The problem was that my settings.xml contained an empty {{localRepository/}}
element. A minimal settings.xml that would reproduce the issue would probably
be:
{code}
settings xmlns=http://maven.apache.org/SETTINGS/1.0.0;
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xsi:schemaLocation=http://maven.apache.org/SETTINGS/1.0.0
http://maven.apache.org/xsd/settings-1.0.0.xsd;
localRepository/
/settings
{code}
MVERIFIER, when processing that element ({{Verifier.java}} line 1883 in
MVERIFIER 1.3) throws a {{SAXException}}. It should probably use the default
value instead of throwing, as Maven otherwise has no problem with the empty
element (and uses the default value).
Print the absolute path to the input file when verification fails
-
Key: MVERIFIER-10
URL: https://jira.codehaus.org/browse/MVERIFIER-10
Project: Maven 2.x Verifier Plugin
Issue Type: New Feature
Affects Versions: 1.1
Reporter: Aaron Digulla
Assignee: Olivier Lamy
Fix For: 1.1
While building Tycho, I had this exception:
{{org.apache.maven.it.VerificationException: org.xml.sax.SAXException: Invalid
mavenProfile entry. Missing one or more fields: {localRepository}.}}
The error message was useless for me because I have no idea which file caused
the error.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MWAR-269) war fails to build while using m2e in workspace resolution mode
[ https://jira.codehaus.org/browse/MWAR-269?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=300828#comment-300828 ] Thomas Broyer commented on MWAR-269: Isn't that a manifestation of MNG-5214? war fails to build while using m2e in workspace resolution mode --- Key: MWAR-269 URL: https://jira.codehaus.org/browse/MWAR-269 Project: Maven 2.x WAR Plugin Issue Type: Improvement Affects Versions: 2.1.1 Reporter: Chris Gamache Attachments: maven-war-plugin.patch, screenshot-1.png This is my first time for an issue/patch submission. Apologies if I'm doing it wrong When building in Eclipse using m2e in workspace resolution mode, the maven-war-plugin is not prepared for a dependency which isn't an assembly but is instead a folder containing the compiled classes from within the local workspace. I propose that if the incoming dependency happens to be a directory that it get packaged up and copied to the destination instead of blowing up with an exception. See attached patch for your review... -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MWAR-269) war fails to build while using m2e in workspace resolution mode
[
https://jira.codehaus.org/browse/MWAR-269?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=300832#comment-300832
]
Thomas Broyer commented on MWAR-269:
Ah, you're right. The issue seems to actually be that the war plugin doesn't
support artifacts coming from the reactor, when they haven't been packaged,
when using Maven 3.
To reproduce outside Eclipse: have a module B with packaging=war depends on a
module A with packaging=jar; configure the war plugin to execute
{{war:exploded}} in the {{prepare-package}} phase, then run {{mvn
prepare-package}} at the reactor level. Building project B will fail when it'll
try to copy project A, because it expects a packaged JAR, but the JAR wasn't
created as the {{package}} phase wasn't executed, so Maven 3 gives the
{{project.build.outputDirectory}} ({{target/classes}}) instead.
FYI, the Tomcat plugin has a special step using
{{MavenProject#getCompileClasspathElements}} (the war plugin could use
{{getRuntimeClasspathElements}}) and then only {{getDependencies}} (where the
war plugin uses {{getArtifacts}}), skipping those that are part of
{{getProjectReferences}}.
I'm afraid it would require an important refactoring of the war plugin though.
See
https://github.com/apache/tomcat-maven-plugin/blob/trunk/common-tomcat-maven-plugin/src/main/java/org/apache/tomcat/maven/common/run/DefaultClassLoaderEntriesCalculator.java
war fails to build while using m2e in workspace resolution mode
---
Key: MWAR-269
URL: https://jira.codehaus.org/browse/MWAR-269
Project: Maven 2.x WAR Plugin
Issue Type: Improvement
Affects Versions: 2.1.1
Reporter: Chris Gamache
Attachments: maven-war-plugin.patch, screenshot-1.png
This is my first time for an issue/patch submission. Apologies if I'm doing
it wrong
When building in Eclipse using m2e in workspace resolution mode, the
maven-war-plugin is not prepared for a dependency which isn't an assembly
but is instead a folder containing the compiled classes from within the local
workspace. I propose that if the incoming dependency happens to be a
directory that it get packaged up and copied to the destination instead of
blowing up with an exception.
See attached patch for your review...
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
