[jira] [Created] (MPH-207) Exercise output of an expression returning a null object.
Vincent Latombe created MPH-207:
---
Summary: Exercise output of an expression returning a null object.
Key: MPH-207
URL: https://issues.apache.org/jira/browse/MPH-207
Project: Maven Help Plugin
Issue Type: Test
Components: evaluate
Reporter: Vincent Latombe
There is no direct way to check for existence of an expression, so I'm
comparing the output of an expression I expect to find (or not) with the output
of an expression I know doesn't exist.
The output of {{help:evaluate}} in case of a missing property is {{null object
or invalid expression}} but it is not exercised via tests so it could
potentially regress if someone decides to change the output one day.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MCOMPILER-415) NullPointerException from javac when compiling AntlrWorks-Jank
[
https://issues.apache.org/jira/browse/MCOMPILER-415?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17497269#comment-17497269
]
Vincent Latombe commented on MCOMPILER-415:
---
I'm commenting here in the hope that someone from the JDK sees this
I think the problem was introduced in openjdk due to this commit
[https://github.com/openjdk/jdk/commit/e5c81018946876d91f89a10999d3582eb592c340#diff-e4e91210b5366d98b565bcb74c4e7d1ed85adaa5045541822c3bb10589dcR906-R908]
It is closing the JavaCompiler object implicitly once the compilation is done.
However the resulting Diagnostic objects (obtained by
[plexus-compiler-api|https://github.com/codehaus-plexus/plexus-compiler/blob/4291bb706b9e3e27eb0c24cc547f248073e8819a/plexus-compilers/plexus-compiler-javac/src/main/java/org/codehaus/plexus/compiler/javac/JavaxToolsCompiler.java#L116-L138]
legally using what is documented in
[https://docs.oracle.com/javase/8/docs/api/javax/tools/JavaCompiler.html)]
still holds references that can be resolved only once the compilation task is
done.
> NullPointerException from javac when compiling AntlrWorks-Jank
> --
>
> Key: MCOMPILER-415
> URL: https://issues.apache.org/jira/browse/MCOMPILER-415
> Project: Maven Compiler Plugin
> Issue Type: Bug
>Affects Versions: 3.1
> Environment: macOS 10.14.6, iMac Pro, AdoptOpenJDK 9, OpenJDK 11.0.2,
> AdoptOpenJDK 13.0.2
>Reporter: Andrew Janke
>Assignee: Robert Scholte
>Priority: Minor
> Attachments: antlrworks-jank-mvn-compile-NPE-02-debug.log,
> antlrworks-jank-mvn-compile-NPE-02.log,
> antlrworks-jank-mvn-compile-NPE-debug.log, antlrworks-jank-mvn-compile-NPE.log
>
>
> I'm working on a project called AntlrWorks-Jank, an attempt to revive the
> defunct ANTLRWorks application. https://github.com/apjanke/antlrworks2-jank
> When compiling the latest work-in-progress version of my code, I'm getting a
> NullPointerException apparently raised inside the javac code when it's called
> by the Maven Compiler Plugin.
> {code:java}
> [antlrworks-jank] $ mvn -e compile
> [INFO] Error stacktraces are turned on.
> [...]
> [INFO] works-editor-antlr4 FAILURE [ 1.026
> s]
> [INFO] antlr-works-editor . SKIPPED
> [INFO] tvl-editor-whitespace .. SKIPPED
> [INFO] works-editor-antlr3 SKIPPED
> [INFO]
>
> [INFO] BUILD FAILURE
> [INFO]
>
> [INFO] Total time: 2.028 s
> [INFO] Finished at: 2020-05-08T03:01:54-04:00
> [INFO]
>
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-compiler-plugin:3.1:compile (default-compile)
> on project works-editor-antlr4: Fatal error compiling: CompilerException:
> NullPointerException -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal org.apache.maven.plugins:maven-compiler-plugin:3.1:compile
> (default-compile) on project works-editor-antlr4: Fatal error compiling
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:215)
> [...]
> Caused by: java.lang.NullPointerException
> at com.sun.tools.javac.main.JavaCompiler.readSourceFile
> (JavaCompiler.java:825)
> at
> com.sun.tools.javac.processing.JavacProcessingEnvironment$ImplicitCompleter.complete
> (JavacProcessingEnvironment.java:1510)
> at com.sun.tools.javac.code.Symbol.complete (Symbol.java:633)
> at com.sun.tools.javac.code.Symbol$ClassSymbol.complete (Symbol.java:1314)
> at com.sun.tools.javac.code.Type$ClassType.complete (Type.java:1139)
> at com.sun.tools.javac.code.Type$ClassType.getTypeArguments
> (Type.java:1065)
> at com.sun.tools.javac.code.Printer.visitClassType (Printer.java:237)
> at com.sun.tools.javac.code.Printer.visitClassType (Printer.java:52)
> at com.sun.tools.javac.code.Type$ClassType.accept (Type.java:992)
> at com.sun.tools.javac.code.Printer.visit (Printer.java:136)
> at com.sun.tools.javac.util.AbstractDiagnosticFormatter.formatArgument
> (AbstractDiagnosticFormatter.java:197)
> at com.sun.tools.javac.util.AbstractDiagnosticFormatter.formatArguments
> (AbstractDiagnosticFormatter.java:165)
> at com.sun.tools.javac.util.BasicDiagnosticFormatter.formatMessage
> (BasicDiagnosticFormatter.java:111)
> at com.sun.tools.javac.util.BasicDiagnosticFormatter.formatMessage
> (BasicDiagnosticFormatter.java:67)
> at com.sun.tools.javac.util.AbstractDiagnosticFormatter.formatArgument
> (AbstractDiagnosticFormatter.java:183)
> at com.s
[jira] (MCOMPILER-205) maven-compiler-plugin: incremental compilation broken
[
https://jira.codehaus.org/browse/MCOMPILER-205?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=323867#comment-323867
]
Vincent Latombe commented on MCOMPILER-205:
---
xml files are resources, in maven world they should be stored under
src/main/resources...
> maven-compiler-plugin: incremental compilation broken
> -
>
> Key: MCOMPILER-205
> URL: https://jira.codehaus.org/browse/MCOMPILER-205
> Project: Maven 2.x Compiler Plugin
> Issue Type: Bug
>Affects Versions: 3.1
>Reporter: Lukas Fryc
> Attachments: no-class-in-java-file.zip
>
>
> When we do {{clean}} -> {{compile}} -> {{compile}}, all Java sources are
> re-compiled for second compilation steps:
> {code}
> [framework]$ mvn clean
> ...
> [framework]$ mvn compile
> ...
> [INFO] --- maven-compiler-plugin:3.1:compile (precompile-sources-for-cdk) @
> richfaces-framework ---
> [INFO] Changes detected - recompiling the module!
> [INFO] Compiling 915 source files to
> /mnt/workspace/workspaces/richfaces/richfaces5/framework/target/classes
> ...
> [framework]$ mvn compile
> ...
> [INFO] --- maven-compiler-plugin:3.1:compile (precompile-sources-for-cdk) @
> richfaces-framework ---
> [INFO] Changes detected - recompiling the module!
> [INFO] Compiling 915 source files to
> /mnt/workspace/workspaces/richfaces/richfaces5/framework/target/classes
> ...
> {code}
> The source code of the affected project:
> https://github.com/richfaces/richfaces5/tree/077dcfc0a46d03d7ba9a7ac3e701a4adfb834c71
--
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-205) maven-compiler-plugin: incremental compilation broken
[
https://jira.codehaus.org/browse/MCOMPILER-205?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=323835#comment-323835
]
Vincent Latombe commented on MCOMPILER-205:
---
The root cause of this issue seems handling of resources in src/main/java that
do not end up generating a .class file under target/classes.
> maven-compiler-plugin: incremental compilation broken
> -
>
> Key: MCOMPILER-205
> URL: https://jira.codehaus.org/browse/MCOMPILER-205
> Project: Maven 2.x Compiler Plugin
> Issue Type: Bug
>Affects Versions: 3.1
>Reporter: Lukas Fryc
> Attachments: no-class-in-java-file.zip
>
>
> When we do {{clean}} -> {{compile}} -> {{compile}}, all Java sources are
> re-compiled for second compilation steps:
> {code}
> [framework]$ mvn clean
> ...
> [framework]$ mvn compile
> ...
> [INFO] --- maven-compiler-plugin:3.1:compile (precompile-sources-for-cdk) @
> richfaces-framework ---
> [INFO] Changes detected - recompiling the module!
> [INFO] Compiling 915 source files to
> /mnt/workspace/workspaces/richfaces/richfaces5/framework/target/classes
> ...
> [framework]$ mvn compile
> ...
> [INFO] --- maven-compiler-plugin:3.1:compile (precompile-sources-for-cdk) @
> richfaces-framework ---
> [INFO] Changes detected - recompiling the module!
> [INFO] Compiling 915 source files to
> /mnt/workspace/workspaces/richfaces/richfaces5/framework/target/classes
> ...
> {code}
> The source code of the affected project:
> https://github.com/richfaces/richfaces5/tree/077dcfc0a46d03d7ba9a7ac3e701a4adfb834c71
--
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-205) maven-compiler-plugin: incremental compilation broken
[
https://jira.codehaus.org/browse/MCOMPILER-205?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vincent Latombe updated MCOMPILER-205:
--
Attachment: no-class-in-java-file.zip
Attaching the IT from original MCOMPILER-187
> maven-compiler-plugin: incremental compilation broken
> -
>
> Key: MCOMPILER-205
> URL: https://jira.codehaus.org/browse/MCOMPILER-205
> Project: Maven 2.x Compiler Plugin
> Issue Type: Bug
>Affects Versions: 3.1
>Reporter: Lukas Fryc
> Attachments: no-class-in-java-file.zip
>
>
> When we do {{clean}} -> {{compile}} -> {{compile}}, all Java sources are
> re-compiled for second compilation steps:
> {code}
> [framework]$ mvn clean
> ...
> [framework]$ mvn compile
> ...
> [INFO] --- maven-compiler-plugin:3.1:compile (precompile-sources-for-cdk) @
> richfaces-framework ---
> [INFO] Changes detected - recompiling the module!
> [INFO] Compiling 915 source files to
> /mnt/workspace/workspaces/richfaces/richfaces5/framework/target/classes
> ...
> [framework]$ mvn compile
> ...
> [INFO] --- maven-compiler-plugin:3.1:compile (precompile-sources-for-cdk) @
> richfaces-framework ---
> [INFO] Changes detected - recompiling the module!
> [INFO] Compiling 915 source files to
> /mnt/workspace/workspaces/richfaces/richfaces5/framework/target/classes
> ...
> {code}
> The source code of the affected project:
> https://github.com/richfaces/richfaces5/tree/077dcfc0a46d03d7ba9a7ac3e701a4adfb834c71
--
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-187) incremental stuff detect changes even if nothing has changed means too much compilation
[ https://jira.codehaus.org/browse/MCOMPILER-187?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=323536#comment-323536 ] Vincent Latombe commented on MCOMPILER-187: --- Indeed I stepped upon another module that had package-info.java present and is affected by the issue, so this should be fixed. > incremental stuff detect changes even if nothing has changed means too much > compilation > --- > > Key: MCOMPILER-187 > URL: https://jira.codehaus.org/browse/MCOMPILER-187 > Project: Maven 2.x Compiler Plugin > Issue Type: Bug >Affects Versions: 3.0 >Reporter: Olivier Lamy >Assignee: Olivier Lamy >Priority: Critical > Fix For: 3.1 > > Attachments: no-class-in-java-file.zip > > -- 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-187) incremental stuff detect changes even if nothing has changed means too much compilation
[ https://jira.codehaus.org/browse/MCOMPILER-187?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vincent Latombe updated MCOMPILER-187: -- Attachment: no-class-in-java-file.zip > incremental stuff detect changes even if nothing has changed means too much > compilation > --- > > Key: MCOMPILER-187 > URL: https://jira.codehaus.org/browse/MCOMPILER-187 > Project: Maven 2.x Compiler Plugin > Issue Type: Bug >Affects Versions: 3.0 >Reporter: Olivier Lamy >Assignee: Olivier Lamy >Priority: Critical > Fix For: 3.1 > > Attachments: no-class-in-java-file.zip > > -- 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-187) incremental stuff detect changes even if nothing has changed means too much compilation
[ https://jira.codehaus.org/browse/MCOMPILER-187?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=323526#comment-323526 ] Vincent Latombe commented on MCOMPILER-187: --- Hello, I don't know if this a case that you want to fix, but I found in a real world scenario some .java files not containing any class (everything commented out), and these are always accounted as stale so the module is always recompiled. IT attached. > incremental stuff detect changes even if nothing has changed means too much > compilation > --- > > Key: MCOMPILER-187 > URL: https://jira.codehaus.org/browse/MCOMPILER-187 > Project: Maven 2.x Compiler Plugin > Issue Type: Bug >Affects Versions: 3.0 >Reporter: Olivier Lamy >Assignee: Olivier Lamy >Priority: Critical > Fix For: 3.1 > > Attachments: no-class-in-java-file.zip > > -- 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] (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=312602#comment-312602
]
Vincent Latombe commented on MSITE-604:
---
I think according to what Hervé said (I didn't know about the Model
Interpolation link that you provided, thank you!), the property should be
removed from pom.xml to get the property defined in settings.xml picked up
instead. By the way, it is actually what I did in the IT I provided.
> Properties from settings.xml are not recognized in site distribution
> management
>
>
> Key: MSITE-604
> URL: https://jira.codehaus.org/browse/MSITE-604
> Project: Maven 2.x and 3.x 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 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] (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=312291#comment-312291
]
Vincent Latombe commented on MSITE-604:
---
I managed to do some additional tests, and it seems that my patch also fixes
MSITE-632. I'm able to redefine distributionManagement in my child module and
it overrides correctly the entry declared in the parent POM.
> Properties from settings.xml are not recognized in site distribution
> management
>
>
> Key: MSITE-604
> URL: https://jira.codehaus.org/browse/MSITE-604
> Project: Maven 2.x and 3.x 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 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] (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=312289#comment-312289
]
Vincent Latombe edited comment on MSITE-604 at 10/25/12 8:46 AM:
-
I've managed to find some time to reproduce the issue, and I have updated the
IT accordingly (see MSITE-604-it.patch).
This IT fails if MSITE-604-maven3-2.patch isn't applied.
Basically, the build will fail if the site url starts with an expression, which
is only defined in settings.xml (not at pom.xml level). Also, it happens if the
site definition is actually done in a parent pom, not in the pom itself.
was (Author: vlatombe):
I've managed to find some time to reproduce the issue, and I have updated
the IT accordingly.
This IT fails if MSITE-604-maven3-2.patch isn't applied.
Basically, the build will fail if the site url starts with an expression, which
is only defined in settings.xml (not at pom.xml level). Also, it happens if the
site definition is actually done in a parent pom, not in the pom itself.
> Properties from settings.xml are not recognized in site distribution
> management
>
>
> Key: MSITE-604
> URL: https://jira.codehaus.org/browse/MSITE-604
> Project: Maven 2.x and 3.x 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 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] (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=312289#comment-312289
]
Vincent Latombe commented on MSITE-604:
---
I've managed to find some time to reproduce the issue, and I have updated the
IT accordingly.
This IT fails if MSITE-604-maven3-2.patch isn't applied.
Basically, the build will fail if the site url starts with an expression, which
is only defined in settings.xml (not at pom.xml level). Also, it happens if the
site definition is actually done in a parent pom, not in the pom itself.
> Properties from settings.xml are not recognized in site distribution
> management
>
>
> Key: MSITE-604
> URL: https://jira.codehaus.org/browse/MSITE-604
> Project: Maven 2.x and 3.x 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 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] (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
]
Vincent Latombe updated MSITE-604:
--
Attachment: 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 2.x and 3.x 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 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] (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
]
Vincent Latombe updated MSITE-604:
--
Attachment: MSITE-604-maven3-2.patch
Second patch only on site-plugin, still limited to Maven 3
> Properties from settings.xml are not recognized in site distribution
> management
>
>
> Key: MSITE-604
> URL: https://jira.codehaus.org/browse/MSITE-604
> Project: Maven 2.x and 3.x 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: 3.1
>
> Attachments: 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 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] (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
]
Vincent Latombe updated MSITE-604:
--
Attachment: MSITE-604-maven3.patch
Attempt of fix for Maven 3.
> Properties from settings.xml are not recognized in site distribution
> management
>
>
> Key: MSITE-604
> URL: https://jira.codehaus.org/browse/MSITE-604
> Project: Maven 2.x and 3.x 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: 3.1
>
> Attachments: 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 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] (MSITE-632) from child module ignored
[
https://jira.codehaus.org/browse/MSITE-632?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=296975#comment-296975
]
Vincent Latombe commented on MSITE-632:
---
I believe the root cause for this issue is MSITE-604. The root cause is that
references from the parent are not interpolated correctly.
> from child module ignored
>
>
> Key: MSITE-632
> URL: https://jira.codehaus.org/browse/MSITE-632
> Project: Maven 2.x and 3.x Site Plugin
> Issue Type: Bug
> Components: site:deploy
>Affects Versions: 3.0
>Reporter: Kohsuke Kawaguchi
>
> In trying to deploy
> https://github.com/kohsuke/windows-package-checker/tree/4658075119d6ce9e4d6b9975342bbbef477d5f50
> , I noticed that the I specified in this POM is ignored and the one
> specified in the parent is used instead. The same site deploys as expected
> with Maven2 with the site plugin 2.0-beta-7.
> Looking at the source code, I see that
> {{SiteDeployMojo.getDeployRepositoryURL()}} uses {{getRootSite}} to determine
> the site to deploy, which explains why my definition is getting
> ignored.
> I believe the fix is to use the nearest site definition, not the one that's
> closest to the root of the inheritance chain. That is, the {{getRootSite()}}
> should be changed from:
> {code}
> protected Site getRootSite( MavenProject project )
> throws MojoExecutionException
> {
> Site site = getSite( project );
> MavenProject parent = project;
> while ( parent.getParent() != null )
> {
> // MSITE-585, MNG-1943
> parent = siteTool.getParentProject( parent, reactorProjects,
> localRepository );
> try
> {
> site = getSite( parent );
> }
> catch ( MojoExecutionException e )
> {
> break;
> }
> }
> return site;
> }
> {code}
> to
> {code}
> protected Site getRootSite( MavenProject project )
> throws MojoExecutionException
> {
> Site site = getSite( project );
> MavenProject parent = project;
> while ( site ==null && parent.getParent() != null )
> {
> // MSITE-585, MNG-1943
> parent = siteTool.getParentProject( parent, reactorProjects,
> localRepository );
> try
> {
> site = getSite( parent );
> }
> catch ( MojoExecutionException e )
> {
> break;
> }
> }
> return site;
> }
> {code}
--
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] (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=296956#comment-296956
]
Vincent Latombe commented on MSITE-604:
---
It seems like in Doxia's DefaultSite#getParentProject the returned project
isn't interpolated. In Maven 3, MNG-1943 is actually fixed so this method could
return directly the result from MavenProject#getParent and it would solve this
issue, at least in Maven 3 context.
> Properties from settings.xml are not recognized in site distribution
> management
>
>
> Key: MSITE-604
> URL: https://jira.codehaus.org/browse/MSITE-604
> Project: Maven 2.x and 3.x 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: 3.1
>
> Attachments: 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 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] (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=296956#comment-296956
]
Vincent Latombe edited comment on MSITE-604 at 4/22/12 7:09 AM:
It seems like in Doxia's DefaultSiteTool#getParentProject the returned project
isn't interpolated. In Maven 3, MNG-1943 is actually fixed so this method could
return directly the result from MavenProject#getParent and it would solve this
issue, at least in Maven 3 context.
was (Author: vlatombe):
It seems like in Doxia's DefaultSite#getParentProject the returned project
isn't interpolated. In Maven 3, MNG-1943 is actually fixed so this method could
return directly the result from MavenProject#getParent and it would solve this
issue, at least in Maven 3 context.
> Properties from settings.xml are not recognized in site distribution
> management
>
>
> Key: MSITE-604
> URL: https://jira.codehaus.org/browse/MSITE-604
> Project: Maven 2.x and 3.x 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: 3.1
>
> Attachments: 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 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] (MSITE-632) from child module ignored
[
https://jira.codehaus.org/browse/MSITE-632?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=293723#comment-293723
]
Vincent Latombe commented on MSITE-632:
---
Hi,
I tried with the last 3.1-SNAPSHOT, which doesn't work (it still picks up the
url from the parent). With Kohsuke's proposed change, the url that is declared
in the current project is taken, as expected.
> from child module ignored
>
>
> Key: MSITE-632
> URL: https://jira.codehaus.org/browse/MSITE-632
> Project: Maven 2.x and 3.x Site Plugin
> Issue Type: Bug
> Components: site:deploy
>Affects Versions: 3.0
>Reporter: Kohsuke Kawaguchi
>
> In trying to deploy
> https://github.com/kohsuke/windows-package-checker/tree/4658075119d6ce9e4d6b9975342bbbef477d5f50
> , I noticed that the I specified in this POM is ignored and the one
> specified in the parent is used instead. The same site deploys as expected
> with Maven2 with the site plugin 2.0-beta-7.
> Looking at the source code, I see that
> {{SiteDeployMojo.getDeployRepositoryURL()}} uses {{getRootSite}} to determine
> the site to deploy, which explains why my definition is getting
> ignored.
> I believe the fix is to use the nearest site definition, not the one that's
> closest to the root of the inheritance chain. That is, the {{getRootSite()}}
> should be changed from:
> {code}
> protected Site getRootSite( MavenProject project )
> throws MojoExecutionException
> {
> Site site = getSite( project );
> MavenProject parent = project;
> while ( parent.getParent() != null )
> {
> // MSITE-585, MNG-1943
> parent = siteTool.getParentProject( parent, reactorProjects,
> localRepository );
> try
> {
> site = getSite( parent );
> }
> catch ( MojoExecutionException e )
> {
> break;
> }
> }
> return site;
> }
> {code}
> to
> {code}
> protected Site getRootSite( MavenProject project )
> throws MojoExecutionException
> {
> Site site = getSite( project );
> MavenProject parent = project;
> while ( site ==null && parent.getParent() != null )
> {
> // MSITE-585, MNG-1943
> parent = siteTool.getParentProject( parent, reactorProjects,
> localRepository );
> try
> {
> site = getSite( parent );
> }
> catch ( MojoExecutionException e )
> {
> break;
> }
> }
> return site;
> }
> {code}
--
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] Updated: (MSHARED-199) Filtering doesn't work if 2 delimiters are used on the same line, the first one being left open
[ http://jira.codehaus.org/browse/MSHARED-199?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vincent Latombe updated MSHARED-199: Attachment: UnitTest-MRESOURCES-141.patch > Filtering doesn't work if 2 delimiters are used on the same line, the first > one being left open > --- > > Key: MSHARED-199 > URL: http://jira.codehaus.org/browse/MSHARED-199 > Project: Maven Shared Components > Issue Type: Bug >Reporter: Vincent Latombe > Attachments: UnitTest-MRESOURCES-141.patch > > -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MSHARED-199) Filtering doesn't work if 2 delimiters are used on the same line, the first one being left open
Filtering doesn't work if 2 delimiters are used on the same line, the first one being left open --- Key: MSHARED-199 URL: http://jira.codehaus.org/browse/MSHARED-199 Project: Maven Shared Components Issue Type: Bug Reporter: Vincent Latombe Attachments: UnitTest-MRESOURCES-141.patch -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MRESOURCES-141) Filtering doesn't work when there is an odd number of @ in the resource
[ http://jira.codehaus.org/browse/MRESOURCES-141?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vincent Latombe updated MRESOURCES-141: --- Attachment: IT-MRESOURCES-141.patch Here is an IT for this issue > Filtering doesn't work when there is an odd number of @ in the resource > --- > > Key: MRESOURCES-141 > URL: http://jira.codehaus.org/browse/MRESOURCES-141 > Project: Maven 2.x Resources Plugin > Issue Type: Bug > Components: filtering >Affects Versions: 2.4.3, 2.5 >Reporter: Roland Asmann >Assignee: Olivier Lamy > Attachments: IT-MRESOURCES-141.patch, resources-bug.zip > > > When filtering a resource that contains an odd number of @, all variables > after the last @ are not replaced by the defined values. > Attached a project that shows this behavior -- workaround is to uncomment the > configuration for the resources-plugin in the POM. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MSOURCES-30) Should not output INFO message when maven is run in quiet mode
[ http://jira.codehaus.org/browse/MSOURCES-30?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=263137#action_263137 ] Vincent Latombe commented on MSOURCES-30: - Depends on PLXCOMP-129 > Should not output INFO message when maven is run in quiet mode > -- > > Key: MSOURCES-30 > URL: http://jira.codehaus.org/browse/MSOURCES-30 > Project: Maven 2.x Source Plugin > Issue Type: Bug >Affects Versions: 2.0.4 >Reporter: Mauritz Lovgren >Priority: Minor > > Currently, the source plugin produces INFO statement for created source jars > even if maven is run in quite mode. > This produces unwanted output to system.out during build. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-4637) -pl switch negates recursion into sub projects
[ http://jira.codehaus.org/browse/MNG-4637?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=260831#action_260831 ] Vincent Latombe commented on MNG-4637: -- Implemented in https://github.com/Vlatombe/maven-3/commit/c71bb8a418b730ad5ee21119eb6fc5f1789f060d and submitted as pull request. > -pl switch negates recursion into sub projects > -- > > Key: MNG-4637 > URL: http://jira.codehaus.org/browse/MNG-4637 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Bootstrap & Build >Affects Versions: 2.2.1 >Reporter: Ittay Dror > > I have a project with several sub projects, each of which has sub projects. > If I use: >mvn -pl sub1 > I expect sub1 to be built as well as all its sub projects and if I use -am, > all their dependencies. Unfortunately, maven will build only sub1. > When using just -pl, I can instead cd to sub1 and build from there, but when > using -am I can't since any dependencies on projects outside of sub1 will not > be found. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MNG-4849) Use of version ranges triggers download of poms for *every* version
[ http://jira.codehaus.org/browse/MNG-4849?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vincent Latombe updated MNG-4849: - Attachment: pom.xml Simpler with maven-core (for apache-maven, the jar doesn't exist for all versions) > Use of version ranges triggers download of poms for *every* version > --- > > Key: MNG-4849 > URL: http://jira.codehaus.org/browse/MNG-4849 > Project: Maven 2 & 3 > Issue Type: Bug >Affects Versions: 3.0-beta-3 >Reporter: Vincent Latombe >Assignee: Benjamin Bentmann > Attachments: pom.xml, pom.xml > > > With beta-3, the following pom triggers the download of *every* version > between 2.0 and 3.0, whereas with previous version only the relevant version > (3.0-beta-3) was downloaded -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MNG-4849) Use of version ranges triggers download of poms for *every* version
Use of version ranges triggers download of poms for *every* version --- Key: MNG-4849 URL: http://jira.codehaus.org/browse/MNG-4849 Project: Maven 2 & 3 Issue Type: Bug Affects Versions: 3.0-beta-3 Reporter: Vincent Latombe Attachments: pom.xml With beta-3, the following pom triggers the download of *every* version between 2.0 and 3.0, whereas with previous version only the relevant version (3.0-beta-3) was downloaded -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MNG-4786) beta-3 : Getting NPE when using an ant-mojo maven plugin
beta-3 : Getting NPE when using an ant-mojo maven plugin Key: MNG-4786 URL: http://jira.codehaus.org/browse/MNG-4786 Project: Maven 2 & 3 Issue Type: Bug Environment: 3.0-beta-3 (staging) Reporter: Vincent Latombe Attachments: antmojo.zip, NPE.log Testing latest beta-3 available in staging, I get an NPE when calling one of my plugins that use the ant wrapper (described at http://www.sonatype.com/books/mhandbook/reference/ch04s04.html) Here is a sample plugin project that use this feature (I took the one available in Maven book). Compile it, then call mvn org.sonatype.mavenbook.plugins:firstant-maven-plugin:echo -Dmessage=world -e This works with 2.2.1/beta-2 but throws an NPE with beta-3 (see attached logs) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-4755) Version ranges cannot be resolved against mirror if a local artifact is present
[ http://jira.codehaus.org/browse/MNG-4755?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=231329#action_231329 ] Vincent Latombe commented on MNG-4755: -- The same test case seems to work with the aether branch, so it will probably be fixed in beta-3. > Version ranges cannot be resolved against mirror if a local artifact is > present > --- > > Key: MNG-4755 > URL: http://jira.codehaus.org/browse/MNG-4755 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Artifacts and Repositories >Affects Versions: 3.0-beta-1 >Reporter: Vincent Latombe > Attachments: version-range-m3.zip > > > See the attached test case : > 1. > * Files located inside tobedeployed have to be deployed to a remote > repository. > * This remote repository must be declared as mirror in your settings.xml. > * a:1 will be available in the mirror > 2. > * run "mvn clean install" inside tobeinstalled > * it will install a:2 to local repository > * b:1 will fail complaining it cannot find a:1 even though it is on the mirror > 3. > * Clean your local repository com/mycompany/app/a > * run "mvn clean install" inside tobeinstalled/b > * b:1 will retrieve a:1 from mirror and compile correctly > Note that this works correctly with 2.2.1, 3.0-alpha-7. It breaks with beta-1 > and upcoming beta-2. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MNG-4755) Version ranges cannot be resolved against mirror if a local artifact is present
Version ranges cannot be resolved against mirror if a local artifact is present --- Key: MNG-4755 URL: http://jira.codehaus.org/browse/MNG-4755 Project: Maven 2 & 3 Issue Type: Bug Components: Artifacts and Repositories Affects Versions: 3.0-beta-1 Reporter: Vincent Latombe Attachments: version-range-m3.zip See the attached test case : 1. * Files located inside tobedeployed have to be deployed to a remote repository. * This remote repository must be declared as mirror in your settings.xml. * a:1 will be available in the mirror 2. * run "mvn clean install" inside tobeinstalled * it will install a:2 to local repository * b:1 will fail complaining it cannot find a:1 even though it is on the mirror 3. * Clean your local repository com/mycompany/app/a * run "mvn clean install" inside tobeinstalled/b * b:1 will retrieve a:1 from mirror and compile correctly Note that this works correctly with 2.2.1, 3.0-alpha-7. It breaks with beta-1 and upcoming beta-2. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MNG-4740) Maven hangs with big aggregators with lots of inter-modules dependencies
Maven hangs with big aggregators with lots of inter-modules dependencies Key: MNG-4740 URL: http://jira.codehaus.org/browse/MNG-4740 Project: Maven 2 & 3 Issue Type: Bug Components: Bootstrap & Build Affects Versions: 3.0-beta-1 Reporter: Vincent Latombe Attachments: hangs.patch Hello, On my main aggregator (~280 modules, lots of inter-modules dependencies), I noticed that since 3.0-beta-1, maven hangs after displaying the list of modules to build. The problem was not occurring with alpha-7. After investigation, it seems that with the introduction of parallel build in beta-1, the whole list of module dependencies is computed at the beginning of the build (see http://svn.apache.org/viewvc/maven/maven-3/trunk/maven-core/src/main/java/org/apache/maven/lifecycle/internal/ProjectSegment.java?r1=931884&r2=935334&diff_format=h) It turns out that this calculation, done inside DefaultProjectDependencyGraph, is very unefficient : if a module is referenced n times, its dependencies will be computed n times. The attached patch solves the problem by computing the dependency tree for a given projectId only once. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-4637) -pl switch negates recursion into sub projects
[ http://jira.codehaus.org/browse/MNG-4637?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=229035#action_229035 ] Vincent Latombe commented on MNG-4637: -- I'm having the same problem. This is counter-intuitive. The non-recursive behaviour should be achieved using -pl -N combination. > -pl switch negates recursion into sub projects > -- > > Key: MNG-4637 > URL: http://jira.codehaus.org/browse/MNG-4637 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Bootstrap & Build >Affects Versions: 2.2.1 >Reporter: Ittay Dror > > I have a project with several sub projects, each of which has sub projects. > If I use: >mvn -pl sub1 > I expect sub1 to be built as well as all its sub projects and if I use -am, > all their dependencies. Unfortunately, maven will build only sub1. > When using just -pl, I can instead cd to sub1 and build from there, but when > using -am I can't since any dependencies on projects outside of sub1 will not > be found. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MASSEMBLY-470) skipAssembly doesn't work for directory based mojos
[ http://jira.codehaus.org/browse/MASSEMBLY-470?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=220644#action_220644 ] Vincent Latombe commented on MASSEMBLY-470: --- Just bumped into this bug. It is pretty annoying. > skipAssembly doesn't work for directory based mojos > --- > > Key: MASSEMBLY-470 > URL: http://jira.codehaus.org/browse/MASSEMBLY-470 > Project: Maven 2.x Assembly Plugin > Issue Type: Bug >Affects Versions: 2.2-beta-5 >Reporter: Mike Mansell > Attachments: skipAssembly-directory.patch > > > The skipAssembly property is only used within the execute method of the > AbstractAssemblyMojo. However, the AbstractDirectoryMojo overrides (and > doesn't call) the execute. Unfortunately, this overridden execute doesn't > respect the skipAssembly variable. Therefore, the directory based mojos > (directory-inline, directory and directory-single) can't be skipped. > This is a simple fix and the patch is included. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (SCM-388) scm:clearcase:load ..... should support more than one loadrule
[
http://jira.codehaus.org/browse/SCM-388?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=208371#action_208371
]
Vincent Latombe commented on SCM-388:
-
Hello,
Actually, you can already use several load rules. You just have to separate
them with a newline character. At least for me it worked.
For instance (extra lines mustn't be indented for this to work)
scm:clearcase:load /MY_VOB/my/project/dir
load /MY_VOB/my/project/dir2
load /MY_VOB/my/project/dir3:vob_name:stream_selector
> scm:clearcase:load . should support more than one loadrule
> --
>
> Key: SCM-388
> URL: http://jira.codehaus.org/browse/SCM-388
> Project: Maven SCM
> Issue Type: Improvement
> Components: maven-scm-provider-clearcase
>Affects Versions: 1.0-beta-3
> Environment: Windows XP, Maven 2.0.9
>Reporter: Torsten Reinhard
>
> With auto-generated configSpecs actually there is a limitation:
> ...
> Specify one load rule for the project you want to check out within the SCM URL
> ...
> In many cases, more than one loadRule would be very useful - this will also
> prevent from moving modules from one directory to another, just for having
> them all under one parent-directory for scm:goal purposes.
> Therefore specifying
> scm:clearcase:load /MY_VOB/my/project/dir, load /MY_VOB/my/project/dir2, load
> /MY_VOB/my/project/dir3
> could be an idea?
> The fix for that is just a StringTokenizer in the method
> protected String createConfigSpec( String loadDirectory, ScmVersion
> version )
> {
>
> // TODO replace this with a StringTokenizer
> configSpec.append( "load " + loadDirectory + "\n" );
> return configSpec.toString();
> }
> at
> org.apache.maven.scm.provider.clearcase.command.checkout.ClearCaseCheckOutCommand
>
> Can anyone do that little enhancement?
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MEAR-118) Invalid application.xml generated
[ http://jira.codehaus.org/browse/MEAR-118?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=207029#action_207029 ] Vincent Latombe commented on MEAR-118: -- Please check the patch I attached, for me it fixes the problem. > Invalid application.xml generated > - > > Key: MEAR-118 > URL: http://jira.codehaus.org/browse/MEAR-118 > Project: Maven 2.x Ear Plugin > Issue Type: Bug >Affects Versions: 2.4 > Environment: Maven 2.2.1 >Reporter: Stephen Coy >Priority: Critical > Fix For: 2.4.1 > > Attachments: ApplicationXmlWriter.java.patch > > > If a project description is specified in the pom.xml, then the plugin > generates a corresponding description from pom > element in the application.xml file. > Unfortunately, it places it in the wrong location according to the schema > (for both J2EE 1.4 and JEE 5): > artifact name > project description > > ... > instead of: > project description > artifact name > > ... > This results in deployment failure on WebSphere. > Work around is to roll back to version 2.3.2 of the ear plugin. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MEAR-118) Invalid application.xml generated
[ http://jira.codehaus.org/browse/MEAR-118?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vincent Latombe updated MEAR-118: - Attachment: ApplicationXmlWriter.java.patch Regression occured when introducing JEE6 support > Invalid application.xml generated > - > > Key: MEAR-118 > URL: http://jira.codehaus.org/browse/MEAR-118 > Project: Maven 2.x Ear Plugin > Issue Type: Bug >Affects Versions: 2.4 > Environment: Maven 2.2.1 >Reporter: Stephen Coy >Priority: Critical > Fix For: 2.4.1 > > Attachments: ApplicationXmlWriter.java.patch > > > If a project description is specified in the pom.xml, then the plugin > generates a corresponding description from pom > element in the application.xml file. > Unfortunately, it places it in the wrong location according to the schema > (for both J2EE 1.4 and JEE 5): > artifact name > project description > > ... > instead of: > project description > artifact name > > ... > This results in deployment failure on WebSphere. > Work around is to roll back to version 2.3.2 of the ear plugin. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
