[jira] Commented: (MSITE-601) Period added to URL prevents proper cloning with Mercurial
[
https://jira.codehaus.org/browse/MSITE-601?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=274806#comment-274806
]
Leon Blakey commented on MSITE-601:
---
This is an issue with Google's new namespace overlap though. A projects new
main repo and main site are at the exact same URL. Its also an issue with
Google seeing . or / or any extra character for that matter as a separate file
or mode.
BTW, tried to get that fixed, got denied:
http://code.google.com/p/support/issues/detail?id=5628
It seems like it would be a lot easier to normalize URL's in the site plugin
than to convince Google to handle extra character's in a URL.
More importantly: Why does the site plugin *need* to add a /./ to the URL? I
can't think of a use case for that.
> Period added to URL prevents proper cloning with Mercurial
> --
>
> Key: MSITE-601
> URL: https://jira.codehaus.org/browse/MSITE-601
> Project: Maven 2.x and 3.x Site Plugin
> Issue Type: Bug
> Components: site:deploy
>Affects Versions: 3.0-beta-3
> Environment: Javac 7 on Fedora Linux 15, Mercurial 1.9
>Reporter: Leon Blakey
>Priority: Critical
>
> I deploy my Maven site over Mercurial on Google Code. I use this configuration
> {code:xml}
>
>
> MYPROJECT.googlecode.com
> scm:hg:https://code.google.com/p/MYPROJECT.site/
>
> {code}
> And a standard in settings.xml
> {code:xml}
>
> MYPROJECT.googlecode.com
> USERNAME
> PASSWORD
>
> {code}
> However when running site:deploy it decides that it should add a dot to the
> URL, meaning it tries to execute this command
> EXECUTING: /bin/sh -c cd /tmp && hg clone -r tip
> https://USERNAME:passw...@code.google.com/p/MYPROJECT.site//.
> /tmp/wagon-scm1348091978.checkout
> Which on Google and other repositories gives a 404 since the file . (look at
> the end of the URL) doesn't exist. Why is that period there? Is it coming
> from Maven Site or the Mercurial plugin (I'm assuming here)? Can it get
> removed>
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MRESOURCES-151) Path for "filters" parameter is relative to the place from where the build was run
Path for "filters" parameter is relative to the place from where the build was
run
--
Key: MRESOURCES-151
URL: https://jira.codehaus.org/browse/MRESOURCES-151
Project: Maven 2.x Resources Plugin
Issue Type: Bug
Components: filtering
Affects Versions: 2.5
Reporter: Julien HENRY
Priority: Minor
I am using copy-resources goal in a multi-module project with the following
configuration in a child module:
{code:xml}
src/main/filters/filter.properties
{code}
The filter path is resolved differently depending on the place from where I run
the build (root aggregator project or child module).
The workaround is to always give absolute path using basedir property:
{code:xml}
${basedir}/src/main/filters/filter.properties
{code}
What is confusing is that the first configuration works fine in the global
filter definition:
{code:xml}
src/main/filters/filter.properties
{code}
Could you please make the behavior more consistent or at least put a warning in
documentation of the "filters" parameter.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MASSEMBLY-561) Encoding is broken when filtering is enabled
[
https://jira.codehaus.org/browse/MASSEMBLY-561?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=274811#comment-274811
]
Julien HENRY commented on MASSEMBLY-561:
Hi John,
Did you have a chance to complete the review of my patch? Do you still have
issue with the integration test?
Thanks
Julien
> Encoding is broken when filtering is enabled
>
>
> Key: MASSEMBLY-561
> URL: https://jira.codehaus.org/browse/MASSEMBLY-561
> Project: Maven 2.x Assembly Plugin
> Issue Type: Bug
>Affects Versions: 2.2.1
>Reporter: Julien HENRY
>Priority: Critical
> Attachments: MASSEMBLY-561.patch
>
>
> My resources are encoded in ISO-8859-1. I have specified encoding in the pom:
> {code}ISO-8859-1{code}
> I have written a custom assembly file and I am using resource filtering.
> {code}...
>
> ${project.basedir}/src/main/resources/
> /
> true
>
> ...{code}
> As a result all the french characters are broken in the resulting zip
> assembly. My platform is Linux so the default platform encoding is UTF-8.
> I have checked plugin code and I think I found the issue. This is in
> FileFormatter.java, method doFileFilter():
> {code}
> configSource.getMavenFileFilter().copyFile( source, target, true,
> configSource.getProject(),
> configSource.getFilters(), isPropertiesFile, null,
> configSource.getMavenSession() );
> {code}
> You can see that enconding is set to null, so I think it means using default
> platform encoding... Would it be possible to use value of
> project.build.sourceEncoding instead?
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (SCM-508) Wrong scm url validation for mercurial provider
[
https://jira.codehaus.org/browse/SCM-508?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=274812#comment-274812
]
Lóránt Pintér commented on SCM-508:
---
Using http://localhost:8000 is not a solution when you want to use the release
pluign's localCheckout feature. It produces this error on Windows:
{code}
C:\Workspaces\Eclipse\Test-TOPclipse-3.7\tis-parent>mvn release:perform
-DlocalCheckout=true
[INFO] Scanning for projects...
[INFO]
[INFO]
[INFO] Building TIS Parent 3.1-SNAPSHOT
[INFO]
[INFO]
[INFO] --- maven-release-plugin:2.2.1:perform (default-cli) @ tis-parent ---
[INFO] Checking out the project to perform the release ...
[INFO] Performing a LOCAL checkout from
scm:hg:file://C:\Workspaces\Eclipse\Test-TOPclipse-3.7\tis-parent
[ERROR] The scm url is invalid.
[INFO]
[INFO] BUILD FAILURE
[INFO]
[INFO] Total time: 2.325s
[INFO] Finished at: Tue Aug 02 14:34:57 CEST 2011
[INFO] Final Memory: 7M/105M
[INFO]
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-release-plugin:2.2.1:perform (default-cli) on
project tis-parent:
The scm url is invalid.
[ERROR] - An hg 'file' url must be on the form 'file:///' or
'file://localhost/'.
[ERROR] -> [Help 1]
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e
switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the errors and possible solutions, please
read the following articles:
[ERROR] [Help 1]
http://cwiki.apache.org/confluence/display/MAVEN/MojoFailureException
{code}
> Wrong scm url validation for mercurial provider
> ---
>
> Key: SCM-508
> URL: https://jira.codehaus.org/browse/SCM-508
> Project: Maven SCM
> Issue Type: Bug
> Components: maven-scm-provider-mercurial (hg)
>Reporter: Alexander Nemish
> Fix For: 1.x
>
> Attachments: SCM-508-maven-scm-provider-hg.patch
>
>
> According to documentation (http://maven.apache.org/scm/mercurial.html) scm
> url can be of this form:
> scm:hg:file://C:/dev/project/v3
> but it doesn't work due to a bug in
> https://svn.apache.org/repos/asf/maven/scm/tags/maven-scm-1.2/maven-scm-providers/maven-scm-provider-hg/src/main/java/org/apache/maven/scm/provider/hg/HgScmProvider.java
> private HgUrlParserResult parseScmUrl( String scmSpecificUrl )
> line 104: if ( !url.startsWith( "file:///" ) && !url.startsWith(
> "file://localhost/" ) )
> The fix might be the following (like in svn provider)
> line 104: if ( !url.startsWith( "file://" ) && !url.startsWith(
> "file://localhost/" ) )
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MECLIPSE-587) maven-eclipse-plugin creates wrong org.eclipse.wst.common.project.facet.core.xml for ear-projects when javaee:javaee-api s used
[ https://jira.codehaus.org/browse/MECLIPSE-587?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=274813#comment-274813 ] Nadeem M Nayeck commented on MECLIPSE-587: -- This issue is quite important, I wonder why this patch hasn't been applied yet. The issue is not only with javaee:javaee-api but also with this: javax javaee-api 5.0 > maven-eclipse-plugin creates wrong > org.eclipse.wst.common.project.facet.core.xml for ear-projects when > javaee:javaee-api s used > --- > > Key: MECLIPSE-587 > URL: https://jira.codehaus.org/browse/MECLIPSE-587 > Project: Maven 2.x Eclipse Plugin > Issue Type: Bug > Components: WTP support >Affects Versions: 2.7, 2.8 > Environment: Linux SLES10, java 1.5, Eclipse 3.4 >Reporter: Gilbert Blom > Attachments: maven-eclipse-plugin.patch > > > When creating an ear-project with maven-eclipse-plugin 2.7, the created file > .settings/org.eclipse.wst.common.project.facet.core.xml is incorrect. > This is the content of the generated file: > > > > > The correct content should be: > > > > > So version should be '5.0', not '5'. > Investigation of the code showed that the way the plugin detects the version > is flawed. When dependency javaee:javaee-api with version 5 is used, this 5 > is put in the file. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MASSEMBLY-568) Dependency missing in assembled archive in multi-project build for certain scope combination
Dependency missing in assembled archive in multi-project build for certain scope combination Key: MASSEMBLY-568 URL: https://jira.codehaus.org/browse/MASSEMBLY-568 Project: Maven 2.x Assembly Plugin Issue Type: Bug Affects Versions: 2.2.1, 2.2 Environment: maven 3.0.3, mac osx or windows 7 Reporter: Stefan Leistenschneider Given a multi module build parent project with module A, module B and module C. Module C is used just for the assembly of module A. Module A depends on module B. Module A has a dependancy X set to scope compile, module B has the same dependancy X set to scope test. It is expected, that because dependancy X is set to scope compile in module A, that the dependancy is included in the final archive, no matter what scope the same dependency has in module B. When assembling, dependancy X is missing in the final archive. When setting the scope of the dependancy in module B to compile, dependancy X is included. Building the same project with 2.2 beta 5 and having the assembly directly in the parent project (so without module c) works. Building the same project with 2.2.1 or 2.2 and having the assembly directly in the parent project does not work. Best regards, Stefan -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MCHECKSTYLE-159) Optional treeWalker.cacheFile property must not be required
[
https://jira.codehaus.org/browse/MCHECKSTYLE-159?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=274817#comment-274817
]
Filip van Laenen commented on MCHECKSTYLE-159:
--
There's a small type in the Checkstyle configuration: the value of the property
should have a capital F like this in order for the work-around to work:
[...]
[...]
[...]
> Optional treeWalker.cacheFile property must not be required
> ---
>
> Key: MCHECKSTYLE-159
> URL: https://jira.codehaus.org/browse/MCHECKSTYLE-159
> Project: Maven 2.x Checkstyle Plugin
> Issue Type: Bug
>Affects Versions: 2.6, 2.7
>Reporter: Karsten Tinnefeld
>
> Given a custom checkstyle configuration, checkstyle requires the property
> cacheFile to the TreeWalker module be configured, thus, the following
> configuration cannot go without the property line:
>
> [...]
>
>
> [...]
>
> [...]
>
> In case it is omitted, the tool exits with the following stack trace
> (shortened, regarding version 2.6):
> [INFO] Error during page generation
> Embedded error: Error rendering Maven report: Failed during checkstyle
> execution
> missing key 'cacheFile' in TreeWalker
> [INFO]
>
> [DEBUG] Trace
> org.apache.maven.lifecycle.LifecycleExecutionException: Error during page
> generation
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:719)
> at
> [...]
> Caused by: com.puppycrawl.tools.checkstyle.api.CheckstyleException: missing
> key 'cacheFile' in TreeWalker
> at
> com.puppycrawl.tools.checkstyle.DefaultConfiguration.getAttribute(DefaultConfiguration.java:74)
> at
> org.apache.maven.plugin.checkstyle.DefaultCheckstyleExecutor.getConfiguration(DefaultCheckstyleExecutor.java:270)
> ... 28 more
> Due to checkstyle documentation, the property is optional, and no cachefile
> will be used in case it is not specified (cf.
> http://checkstyle.sourceforge.net/config.html#TreeWalker). Also, cacheFile
> can be specified in the pom, thus it should be substituted anyway.
> Workaround:
> Add -Entry
>
> cacheFile=${project.build.directory}/checkstyle-cachefile
>
> and use the above property line and a special maven build version of the
> checkstyle configuration file.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MCOMPILER-87) Compiler errors display as INFO level messages
[ https://jira.codehaus.org/browse/MCOMPILER-87?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Struberg closed MCOMPILER-87. -- Resolution: Cannot Reproduce I tried that out today and I clearly get compilation errors reported as [ERROR] in my log. Even if using --quiet. > Compiler errors display as INFO level messages > -- > > Key: MCOMPILER-87 > URL: https://jira.codehaus.org/browse/MCOMPILER-87 > Project: Maven 2.x Compiler Plugin > Issue Type: Bug > Environment: Ubuntu 8.04 64-bit, Maven version: 2.0.8, Java version: > 1.6.0_10 > OS name: "linux" version: "2.6.21.7-2.fc8xen" arch: "amd64" Family: "unix" >Reporter: Dang Nguyen >Assignee: Mark Struberg > > When a compile failure occurs, the exception(s) that causes the compile > failure is displayed as an INFO level message. Only the final message that > reads "BUILD FAILURE" is displayed as an ERROR level message. The exception > stack should also be ERROR level messages. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MPMD-86) Using JDK 1.5 causes ParseException: Can't use generics unless running in JDK 1.5 mode!
[ https://jira.codehaus.org/browse/MPMD-86?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=274821#comment-274821 ] Scott MacDonald commented on MPMD-86: - How is this closed as "Not a bug" while simultaneously providing a work around for "the bug"? This is still an issue in maven 3.03 PMD 2.4. > Using JDK 1.5 causes ParseException: Can't use generics unless running in JDK > 1.5 mode! > --- > > Key: MPMD-86 > URL: https://jira.codehaus.org/browse/MPMD-86 > Project: Maven 2.x PMD Plugin > Issue Type: Bug > Components: PMD >Affects Versions: 2.4 > Environment: JAVA 1.5, Maven 2.0.9 >Reporter: Debabrat Panda >Assignee: Benjamin Bentmann > > While running PMD with Maven i am getting parsing error "Error while parsing > ../../../java file" > The errors are > 1. Can't use generics unless running in JDK 1.5 mode! > 2. Can't use static imports when running in JDK 1.4 mode! > Can't use annotations when running in JDK 1.4 mode! > Any help will be appreciated. > Thanks in advance. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MCHECKSTYLE-163) Test classpath resolution fails in mvn check:check when includeTestSourceDirectory = true
[
https://jira.codehaus.org/browse/MCHECKSTYLE-163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=274842#comment-274842
]
Olivier Lamy commented on MCHECKSTYLE-163:
--
could you please provide a sample project in a zip file ?
> Test classpath resolution fails in mvn check:check when
> includeTestSourceDirectory = true
> -
>
> Key: MCHECKSTYLE-163
> URL: https://jira.codehaus.org/browse/MCHECKSTYLE-163
> Project: Maven 2.x Checkstyle Plugin
> Issue Type: Bug
>Affects Versions: 2.7
>Reporter: Chris Whelan
> Attachments: resolveTestClasspath.patch
>
>
> When includeTestSourceDirectory=true is set for maven-checkstyle-plugin, the
> full test classpath should be made available to checkstyle. Patch included
> to resolve issue by setting @requiresDependencyResolution to test.
> In DefaultCheckstyleExecutor.java the checker.setClassLoader() is configured
> using the classpath string from
> request.getProject().getTestClasspathElements() (see
> DefaultCheckstyleExecutor line 114).
> However, the CheckstyleViolationCheckMojo only has
> @requiresDependencyResolution compile which means that pom dependencies which
> have been declared as test are not returned by
> project.getTestClasspathElements().
> This is a particular issue for the checkstyle RedundantThrows check
> (http://checkstyle.sourceforge.net/config_coding.html#RedundantThrows) as it
> requires all Exceptions to be available on it's classpath.
> If code throws an Exception which has been imported from a maven
> test dependency, the exception will not be available on the
> classpath and this checkstyle check will fail.
> Example:
> Include junit as a test scope dependency in the project POM:
>
> junit
> junit
> ${junit.version}
> test
>
> Throw any junit exception within project test code, e.g.:
> public class MyCustomTestRunner extends BlockJUnit4ClassRunner {
> public MyCustomTestRunner(final Class klass) throws
> InitializationError {
> If RedundantThrows check is enabled, the following error will be thrown:
> [INFO] --- maven-checkstyle-plugin:2.7-SNAPSHOT:check (checkstyle-verify) @
> sample-project ---
> [INFO] Starting audit...
> C:\Working\hg\sample-project\src\test\java\com\sample\support\junit\MyCustomTestRunner.java:28:72:
> warning: Unable to get class information for InitializationError.
> Audit done.
> [ERROR] MyCustomTestRunner.java[28:72] Unable to get class information for
> InitializationError.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MSITE-602) The staged site is deployed to the wrong place
The staged site is deployed to the wrong place
--
Key: MSITE-602
URL: https://jira.codehaus.org/browse/MSITE-602
Project: Maven 2.x and 3.x Site Plugin
Issue Type: Bug
Components: site:stage(-deploy)
Affects Versions: 3.0, 2.3
Reporter: Dennis Lundberg
When running 'mvn site:stage-deploy' the site is deployed to the wrong place.
Below is the output from a test run performed on the Checkstyle Plugin project.
{noformat}
[INFO] --- maven-site-plugin:3.0:stage-deploy (default-cli) @
maven-checkstyle-plugin ---
[INFO] Using this server ID for stage deploy: apache.website
[INFO] Using this base URL for stage deploy:
scp://people.apache.org/www/maven.apache.org/plugins/maven-checkstyle-plugin-2.7-SNAPSHOT
[INFO] Parent project loaded from repository:
org.apache.maven.plugins:maven-plugins:pom:21
[INFO] Parent project loaded from repository:
org.apache.maven:maven-parent:pom:20
[INFO] Parent project loaded from repository: org.apache:apache:pom:9
: Keyboard interactive required, supplied password is ignored
Password: :
scp://people.apache.org/www/maven.apache.org/plugins/maven-checkstyle-plugin-2.7-SNAPSHOT/
- Session: Opened
[INFO] Pushing
G:\apache\maven\trunks\plugins\maven-checkstyle-plugin\target\site
[INFO]>>> to
scp://people.apache.org/www/maven.apache.org/plugins/maven-checkstyle-plugin-2.7-SNAPSHOT/plugins/maven-checkstyle-plugin
Executing command: mkdir -p
/www/maven.apache.org/plugins/maven-checkstyle-plugin-2.7-SNAPSHOT/plugins/maven-checkstyle-plugin
Executing command: mkdir -p
/www/maven.apache.org/plugins/maven-checkstyle-plugin-2.7-SNAPSHOT/plugins/maven-checkstyle-plugin
Executing command: scp -t
"/www/maven.apache.org/plugins/maven-checkstyle-plugin-2.7-SNAPSHOT/plugins/maven-checkstyle-plugin/wagon592489540427231356.zip"
Uploading: plugins/maven-checkstyle-plugin/wagon592489540427231356.zip to
scp://people.apache.org/www/maven.apache.org/plugins/maven-checkstyle-plugin-2.7-SNAPSHOT/
###
Transfer finished. 224640 bytes copied in 1.699 seconds
Executing command: cd
/www/maven.apache.org/plugins/maven-checkstyle-plugin-2.7-SNAPSHOT/plugins/maven-checkstyle-plugin;
unzip -q -o wagon592489540427231356.zip; rm -f wagon592489540427231356.zip
Executing command: chmod -Rf g+w,a+rX
/www/maven.apache.org/plugins/maven-checkstyle-plugin-2.7-SNAPSHOT/
scp://people.apache.org/www/maven.apache.org/plugins/maven-checkstyle-plugin-2.7-SNAPSHOT/
- Session: Disconnecting
scp://people.apache.org/www/maven.apache.org/plugins/maven-checkstyle-plugin-2.7-SNAPSHOT/
- Session: Disconnected
{noformat}
Notice how it gets deployed to
{noformat}
/plugins/maven-checkstyle-plugin-2.7-SNAPSHOT/plugins/maven-checkstyle-plugin/
{noformat}
instead of
{noformat}
/plugins/maven-checkstyle-plugin-2.7-SNAPSHOT/
{noformat}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (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:all-tabpanel
]
Herve Boutemy updated MVERIFIER-10:
---
Affects Version/s: 1.3
Fix Version/s: 1.4
> 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.3
>Reporter: Aaron Digulla
>Assignee: Olivier Lamy
> Fix For: 1.4
>
>
> 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.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MSHARED-131) Maven archiver does not manage empty classifier correctly in manifest.mf classpath
[
https://jira.codehaus.org/browse/MSHARED-131?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Herve Boutemy updated MSHARED-131:
--
Description:
When I have a dependency
{code:xml}
com.almerys.pec
ws-ag2r-client
2.2.0.0.0
${env}
{code}
and $env define as empty like that
or
Maven download the correct dependency without classifier but in the manifest.mf
I have in the classpath : ws-ag2r-client-2.2.0.0.0-.jar
'-' is not correct !!
Fabrice
was:
When I have a dependency
com.almerys.pec
ws-ag2r-client
2.2.0.0.0
${env}
and $env define as empty like that
or
Maven download the correct dependency without classifier but in the manifest.mf
I have in the classpath : ws-ag2r-client-2.2.0.0.0-.jar
'-' is not correct !!
Fabrice
> Maven archiver does not manage empty classifier correctly in manifest.mf
> classpath
> --
>
> Key: MSHARED-131
> URL: https://jira.codehaus.org/browse/MSHARED-131
> Project: Maven Shared Components
> Issue Type: Bug
> Components: maven-archiver
>Reporter: fabrice
>Assignee: Dennis Lundberg
> Fix For: maven-archiver-2.5
>
>
> When I have a dependency
> {code:xml}
> com.almerys.pec
> ws-ag2r-client
> 2.2.0.0.0
> ${env}
> {code}
> and $env define as empty like that
> or
> Maven download the correct dependency without classifier but in the
> manifest.mf I have in the classpath : ws-ag2r-client-2.2.0.0.0-.jar
> '-' is not correct !!
> Fabrice
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MDOCCK-23) Invocation fails with "com.thoughtworks.qdox.parser.ParseException: syntax error"
Invocation fails with "com.thoughtworks.qdox.parser.ParseException: syntax
error"
-
Key: MDOCCK-23
URL: https://jira.codehaus.org/browse/MDOCCK-23
Project: Maven 2.x Documentation Checker Plugin
Issue Type: Bug
Environment: Apache Maven 2.2.1 (r801777; 2009-08-06 21:16:01+0200)
Java version: 1.6.0_26
Java home: /System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Home
Default locale: en_US, platform encoding: UTF-8
OS name: "mac os x" version: "10.6.8" arch: "x86_64" Family: "mac"
Reporter: Siegfried Goeschl
Attachments: AbstractWebtestMojo.java
When checking the webtest-maven-plugin project
(https://svn.codehaus.org/mojo/trunk/mojo/webtest-maven-plugin/) I get the
following result
webtest-maven-plugin> mvn docck:check
[INFO] Scanning for projects...
[INFO] Searching repository for plugin with prefix: 'docck'.
[INFO]
[INFO] Building Canoo WebTest Maven Plugin
[INFO]task-segment: [docck:check] (aggregator-style)
[INFO]
[INFO] [docck:check {execution: default-cli}]
[INFO] Checking project: Canoo WebTest Maven Plugin
[INFO] Using 2 extractors.
[INFO] Applying extractor for language: java
[INFO]
[ERROR] FATAL ERROR
[INFO]
[INFO] syntax error @[424,9] in
file:/Users/sgoeschl/work/codehaus/mojo/webtest-maven-plugin/src/main/java/org/codehaus/mojo/webtest/AbstractWebtestMojo.java
[INFO]
[INFO] Trace
com.thoughtworks.qdox.parser.ParseException: syntax error @[424,9] in
file:/Users/sgoeschl/work/codehaus/mojo/webtest-maven-plugin/src/main/java/org/codehaus/mojo/webtest/AbstractWebtestMojo.java
at com.thoughtworks.qdox.parser.impl.Parser.yyerror(Parser.java:504)
at com.thoughtworks.qdox.parser.impl.Parser.yyparse(Parser.java:610)
at com.thoughtworks.qdox.parser.impl.Parser.parse(Parser.java:488)
at
com.thoughtworks.qdox.JavaDocBuilder.addSource(JavaDocBuilder.java:296)
at
com.thoughtworks.qdox.JavaDocBuilder.addSource(JavaDocBuilder.java:312)
at
com.thoughtworks.qdox.JavaDocBuilder.addSource(JavaDocBuilder.java:308)
at
com.thoughtworks.qdox.JavaDocBuilder$1.visitFile(JavaDocBuilder.java:365)
Maybe the problem is the private class which overwrites the existing
"Properties" class
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MCHECKSTYLE-111) More information on issue: "Got an exception - java.lang.RuntimeException: Unable to get class information for [exception]"
[
https://jira.codehaus.org/browse/MCHECKSTYLE-111?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=274861#comment-274861
]
Niraj Tolia commented on MCHECKSTYLE-111:
-
We ran into this at work too. Evidently checkstyle, if run on uncompiled code,
will not be able to find your custom exceptions. With compiled code (what we
usually do), it looks like things should be OK unless your error originates
from a dependency that is marked with a test scope. In our project, junit
currently is marked as being in the test scope but that is where the
InitializationError Exception comes from and what triggered the bug for us. It
should be possible to fix this by pointing checkstyle to the right dependency
but I am not completely sure how.
> More information on issue: "Got an exception - java.lang.RuntimeException:
> Unable to get class information for [exception]"
> ---
>
> Key: MCHECKSTYLE-111
> URL: https://jira.codehaus.org/browse/MCHECKSTYLE-111
> Project: Maven 2.x Checkstyle Plugin
> Issue Type: Bug
>Affects Versions: 2.2
> Environment: Windows Vista Business (x64), Windows XP (x86), Windows
> 2003 Server (x86)
> Apache Maven 2.1.0 (r755702; 2009-03-18 20:10:27+0100) and Maven 2.0.10
> Java version: 1.6.0_13
>Reporter: Michael Grossniklaus
>Priority: Blocker
> Attachments: maven-checkstyle-plugin.zip, output.txt
>
>
> This bug report provides more insight on the situations in which the
> maven-checkstyle-plugin is unable to get the class information for exceptions
> that are declared by the project. This report is, therefore, a refinement of
> prior bug reports such as MPCHECKSTYLE-1, MPCHECKSTYLE-20, or MCHECKSTYLE-54.
> We believe, however, that through a more in-depth study of the problem we can
> provide a narrower definition of the problem that, hopefully, will result in
> it resolution.
> Our experiments have shown that the maven-checkstyle-plugin fails for classes
> or interfaces that contain method signatures with a "throws" clause pointing
> to exception defined by both the project and elsewhere. This is demonstrated
> by the interface "ch.ethz.globis.demo.Demo" contained in the attached demo
> project.
> {{
> public interface Demo {
>void foo() throws DemoException, IOException, FileNotFoundException;
>void foofoo() throws DemoException;
>void bar() throws IOException, FileNotFoundException,
> IllegalArgumentException;
> }
> }}
> If the command "mvn checkstyle:check" is executed in the project, it will
> fail with one checkstyle violation. If, however, the method "foo()" is
> commented (or removed), everything works fine. Note that method "foofoo()"
> which *only* declares "ch.ethz.globis.demo.DemoException" is unproblematic as
> well as method "bar()" which declares a set of exceptions that are declared
> outside the project. Hence, the conclusion is that it is the combination of
> *both* project and outside-project exceptions that make the
> maven-checkstyle-plugin fail. Note that we have run maven on clean
> installation (where the local repository has been removed first) to produce a
> reproducible error.
> The attached zip file contains both the demo project that can be used to
> reproduce the error as well as the output of the "mvn checkstyle:check"
> command under "target". We also provide the file "output.txt" that documents
> the console output of the command. If further documentation is required, do
> not hesitate to contact me. We hope that by providing this information we can
> contribute to the resolution of said issue, once and for all.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MCOMPILER-158) Symbol name should be displayed during compiler error using Java 7
Symbol name should be displayed during compiler error using Java 7
--
Key: MCOMPILER-158
URL: https://jira.codehaus.org/browse/MCOMPILER-158
Project: Maven 2.x Compiler Plugin
Issue Type: Improvement
Affects Versions: 2.3.2
Reporter: Raghuram
Got to install Java 7. Tried it out on some of our source code which uses
maven. Worked fine till there was a compilation error.
{code}
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-compiler-plugin:2.3.2:compile (default-compile)
on project my-app: Compilation failure
[ERROR] \work\my-app\src\main\java\com\mycompany\app\App.java:[11,45] error:
cannot find symbol
[ERROR] -> [Help 1]
{code}
I am ok with the error, but which _symbol_ does it fail to find? Tried the
same thing with Java 6.
{code}
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-compiler-plugin:2.3.2:compile (default-compile)
on project my-app: Compilation failure
[ERROR] \work\my-app\src\main\java\com\mycompany\app\App.java:[11,45] cannot
find symbol
[ERROR] symbol : variable Dummy
[ERROR] location: class com.mycompany.app.App
[ERROR] -> [Help 1]
{code}
I can clearly see which variable is not found. So what has changed?
Tried *javac* on the class. Output with java 7.
{code}
javac App.java
App.java:11: error: cannot find symbol
System.out.println( "Hello World!" + Dummy);
^
symbol: variable Dummy
location: class App
1 error
{code}
Output with java 6.
{code}
javac App.java
App.java:11: cannot find symbol
symbol : variable Dummy
location: class com.mycompany.app.App
System.out.println( "Hello World!" + Dummy);
^
1 error
{code}
We can see a couple of differences with Java 7 compiler compared to Java 6.
* Location does not show complete package, just the class
* Symbol and location now come after the line which has the error, instead of
before.
* An additional "error" word comes before the error message
Essentially there is a change in compiler output in case of errors, which I
guess needs a corresponding maven compiler change.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MCHECKSTYLE-163) Test classpath resolution fails in mvn check:check when includeTestSourceDirectory = true
[
https://jira.codehaus.org/browse/MCHECKSTYLE-163?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chris Whelan updated MCHECKSTYLE-163:
-
Attachment: MCHECKSTYLE-163.zip
Attaching an example project
> Test classpath resolution fails in mvn check:check when
> includeTestSourceDirectory = true
> -
>
> Key: MCHECKSTYLE-163
> URL: https://jira.codehaus.org/browse/MCHECKSTYLE-163
> Project: Maven 2.x Checkstyle Plugin
> Issue Type: Bug
>Affects Versions: 2.7
>Reporter: Chris Whelan
> Attachments: MCHECKSTYLE-163.zip, resolveTestClasspath.patch
>
>
> When includeTestSourceDirectory=true is set for maven-checkstyle-plugin, the
> full test classpath should be made available to checkstyle. Patch included
> to resolve issue by setting @requiresDependencyResolution to test.
> In DefaultCheckstyleExecutor.java the checker.setClassLoader() is configured
> using the classpath string from
> request.getProject().getTestClasspathElements() (see
> DefaultCheckstyleExecutor line 114).
> However, the CheckstyleViolationCheckMojo only has
> @requiresDependencyResolution compile which means that pom dependencies which
> have been declared as test are not returned by
> project.getTestClasspathElements().
> This is a particular issue for the checkstyle RedundantThrows check
> (http://checkstyle.sourceforge.net/config_coding.html#RedundantThrows) as it
> requires all Exceptions to be available on it's classpath.
> If code throws an Exception which has been imported from a maven
> test dependency, the exception will not be available on the
> classpath and this checkstyle check will fail.
> Example:
> Include junit as a test scope dependency in the project POM:
>
> junit
> junit
> ${junit.version}
> test
>
> Throw any junit exception within project test code, e.g.:
> public class MyCustomTestRunner extends BlockJUnit4ClassRunner {
> public MyCustomTestRunner(final Class klass) throws
> InitializationError {
> If RedundantThrows check is enabled, the following error will be thrown:
> [INFO] --- maven-checkstyle-plugin:2.7-SNAPSHOT:check (checkstyle-verify) @
> sample-project ---
> [INFO] Starting audit...
> C:\Working\hg\sample-project\src\test\java\com\sample\support\junit\MyCustomTestRunner.java:28:72:
> warning: Unable to get class information for InitializationError.
> Audit done.
> [ERROR] MyCustomTestRunner.java[28:72] Unable to get class information for
> InitializationError.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MCHECKSTYLE-163) Test classpath resolution fails in mvn check:check when includeTestSourceDirectory = true
[ https://jira.codehaus.org/browse/MCHECKSTYLE-163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=274866#comment-274866 ] Chris Whelan commented on MCHECKSTYLE-163: -- Example log running attached project without patch. Note the 'unable to get class information' errors: C:\Working\MCHECKSTYLE-163>mvn clean verify [INFO] Scanning for projects... [WARNING] [WARNING] Some problems were encountered while building the effective model for sample:sample:pom:1.0-SNAPSHOT [WARNING] 'build.plugins.plugin.version' for org.apache.maven.plugins:maven-compiler-plugin is missing. @ line 47, column 12 [WARNING] [WARNING] It is highly recommended to fix these problems because they threaten the stability of your build. [WARNING] [WARNING] For this reason, future Maven versions might no longer support building such malformed projects. [WARNING] [INFO] [INFO] [INFO] Building Example project 1.0-SNAPSHOT [INFO] [INFO] [INFO] --- maven-clean-plugin:2.4.1:clean (default-clean) @ sample --- [INFO] Deleting C:\Working\MCHECKSTYLE-163\target [INFO] [INFO] --- maven-checkstyle-plugin:2.7-SNAPSHOT:check (checkstyle-verify) @ sample --- [WARNING] File encoding has not been set, using platform encoding Cp1252, i.e. build is platform dependent! [INFO] Starting audit... C:\Working\MCHECKSTYLE-163\src\test\java\sample\Example.java:7:59: warning: Unable to get class information for InitializationError. C:\Working\MCHECKSTYLE-163\src\test\java\sample\Example.java:9:62: warning: Unable to get class information for InitializationError. C:\Working\MCHECKSTYLE-163\src\test\java\sample\Example.java:11:60: warning: Redundant throws: 'IllegalArgumentException' is subclass of 'Exception'. C:\Working\MCHECKSTYLE-163\src\test\java\sample\Example.java:11:60: warning: Redundant throws: 'IllegalArgumentException' is unchecked exception. C:\Working\MCHECKSTYLE-163\src\test\java\sample\Example.java:13:74: warning: Redundant throws: 'IllegalArgumentException' is unchecked exception. Audit done. [ERROR] Example.java[7:59] Unable to get class information for InitializationError. [ERROR] Example.java[9:62] Unable to get class information for InitializationError. [ERROR] Example.java[11:60] Redundant throws: 'IllegalArgumentException' is subclass of 'Exception'. [ERROR] Example.java[11:60] Redundant throws: 'IllegalArgumentException' is unchecked exception. [ERROR] Example.java[13:74] Redundant throws: 'IllegalArgumentException' is unchecked exception. [INFO] [INFO] BUILD FAILURE [INFO] [INFO] Total time: 2.406s [INFO] Finished at: Wed Aug 03 13:57:37 SGT 2011 [INFO] Final Memory: 4M/15M [INFO] [ERROR] Failed to execute goal org.apache.maven.plugins:maven-checkstyle-plugin:2.7-SNAPSHOT:check (checkstyle-verify) on project sample: You have 5 Checkstyle violations. -> [Help 1] [ERROR] [ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch. [ERROR] Re-run Maven using the -X switch to enable full debug logging. [ERROR] [ERROR] For more information about the errors and possible solutions, please read the following articles: [ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/MojoFailureException > Test classpath resolution fails in mvn check:check when > includeTestSourceDirectory = true > - > > Key: MCHECKSTYLE-163 > URL: https://jira.codehaus.org/browse/MCHECKSTYLE-163 > Project: Maven 2.x Checkstyle Plugin > Issue Type: Bug >Affects Versions: 2.7 >Reporter: Chris Whelan > Attachments: MCHECKSTYLE-163.zip, resolveTestClasspath.patch > > > When includeTestSourceDirectory=true is set for maven-checkstyle-plugin, the > full test classpath should be made available to checkstyle. Patch included > to resolve issue by setting @requiresDependencyResolution to test. > In DefaultCheckstyleExecutor.java the checker.setClassLoader() is configured > using the classpath string from > request.getProject().getTestClasspathElements() (see > DefaultCheckstyleExecutor line 114). > However, the CheckstyleViolationCheckMojo only has > @requiresDependencyResolution compile which means that pom dependencies which > have been declared as test are not returned by > project.getTestClasspathElements(). > This is a particular issue for the checkstyle RedundantThrows check > (http://checkstyle.sourceforge.net/config_coding.html#RedundantThrows) as it > requires all Exceptions to be available on it's clas
[jira] Commented: (MCHECKSTYLE-163) Test classpath resolution fails in mvn check:check when includeTestSourceDirectory = true
[ https://jira.codehaus.org/browse/MCHECKSTYLE-163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=274868#comment-274868 ] Chris Whelan commented on MCHECKSTYLE-163: -- Example log with patch applied. Note that build now fails for the correct reason and all four Redundant throws errors are shown in the console. C:\Working\MCHECKSTYLE-163>mvn clean verify [INFO] Scanning for projects... [WARNING] [WARNING] Some problems were encountered while building the effective model for sample:sample:pom:1.0-SNAPSHOT [WARNING] 'build.plugins.plugin.version' for org.apache.maven.plugins:maven-compiler-plugin is missing. @ line 47, column 12 [WARNING] [WARNING] It is highly recommended to fix these problems because they threaten the stability of your build. [WARNING] [WARNING] For this reason, future Maven versions might no longer support building such malformed projects. [WARNING] [INFO] [INFO] [INFO] Building Example project 1.0-SNAPSHOT [INFO] [INFO] [INFO] --- maven-clean-plugin:2.4.1:clean (default-clean) @ sample --- [INFO] Deleting C:\Working\MCHECKSTYLE-163\target [INFO] [INFO] --- maven-checkstyle-plugin:2.7-SNAPSHOT:check (checkstyle-verify) @ sample --- [WARNING] File encoding has not been set, using platform encoding Cp1252, i.e. build is platform dependent! [INFO] Starting audit... C:\Working\MCHECKSTYLE-163\src\test\java\sample\Example.java:7:59: warning: Redundant throws: 'InitializationError' is subclass of 'Exception'. C:\Working\MCHECKSTYLE-163\src\test\java\sample\Example.java:11:60: warning: Redundant throws: 'IllegalArgumentException' is subclass of 'Exception'. C:\Working\MCHECKSTYLE-163\src\test\java\sample\Example.java:11:60: warning: Redundant throws: 'IllegalArgumentException' is unchecked exception. C:\Working\MCHECKSTYLE-163\src\test\java\sample\Example.java:13:74: warning: Redundant throws: 'IllegalArgumentException' is unchecked exception. Audit done. [ERROR] Example.java[7:59] Redundant throws: 'InitializationError' is subclass of 'Exception'. [ERROR] Example.java[11:60] Redundant throws: 'IllegalArgumentException' is subclass of 'Exception'. [ERROR] Example.java[11:60] Redundant throws: 'IllegalArgumentException' is unchecked exception. [ERROR] Example.java[13:74] Redundant throws: 'IllegalArgumentException' is unchecked exception. [INFO] [INFO] BUILD FAILURE [INFO] [INFO] Total time: 2.500s [INFO] Finished at: Wed Aug 03 13:58:55 SGT 2011 [INFO] Final Memory: 4M/15M [INFO] [ERROR] Failed to execute goal org.apache.maven.plugins:maven-checkstyle-plugin:2.7-SNAPSHOT:check (checkstyle-verify) on project sample: You have 4 Checkstyle violations. -> [Help 1] [ERROR] [ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch. [ERROR] Re-run Maven using the -X switch to enable full debug logging. [ERROR] [ERROR] For more information about the errors and possible solutions, please read the following articles: [ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/MojoFailureException > Test classpath resolution fails in mvn check:check when > includeTestSourceDirectory = true > - > > Key: MCHECKSTYLE-163 > URL: https://jira.codehaus.org/browse/MCHECKSTYLE-163 > Project: Maven 2.x Checkstyle Plugin > Issue Type: Bug >Affects Versions: 2.7 >Reporter: Chris Whelan > Attachments: MCHECKSTYLE-163.zip, resolveTestClasspath.patch > > > When includeTestSourceDirectory=true is set for maven-checkstyle-plugin, the > full test classpath should be made available to checkstyle. Patch included > to resolve issue by setting @requiresDependencyResolution to test. > In DefaultCheckstyleExecutor.java the checker.setClassLoader() is configured > using the classpath string from > request.getProject().getTestClasspathElements() (see > DefaultCheckstyleExecutor line 114). > However, the CheckstyleViolationCheckMojo only has > @requiresDependencyResolution compile which means that pom dependencies which > have been declared as test are not returned by > project.getTestClasspathElements(). > This is a particular issue for the checkstyle RedundantThrows check > (http://checkstyle.sourceforge.net/config_coding.html#RedundantThrows) as it > requires all Exceptions to be available on it's classpath. > If code throws an Exception which has been imported from a maven > test dependency, the exception will not be available on the > classpath and th
