[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&focusedCommentId=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 ve
[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&focusedCommentId=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-tabpanel&focusedCommentId=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 doesn't work all the time
[ https://jira.codehaus.org/browse/MCOMPILER-174?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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 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 > > > com/you/example.java > > > 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-tabpanel&focusedCommentId=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-tabpanel&focusedCommentId=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-tabpanel&focusedCommentId=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] (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-tabpanel&focusedCommentId=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 {{}} element. A minimal settings.xml that would reproduce the issue would probably be: {code} 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";> {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] (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-tabpanel&focusedCommentId=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 {{}} element. A minimal settings.xml that would reproduce the issue would probably be: {code} 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";> {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 {{}} element. A minimal settings.xml that would reproduce the issue would probably be: {code} 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";> {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.(Verifier.java:101) > at org.apache.maven.it.Verifier.(Verifier.java:80) > at org.apache.maven.it.Verifier.(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-tabpanel&focusedCommentId=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 {{}} element. A minimal settings.xml that would reproduce the issue would probably be: {code} 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";> {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.(Verifier.java:101) > at org.apache.maven.it.Verifier.(Verifier.java:80) > at org.apache.maven.it.Verifier.(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] (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-tabpanel&focusedCommentId=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
[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-tabpanel&focusedCommentId=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