[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-tabpanelfocusedCommentId=274799#comment-274799
]
Lukas Theussl commented on MSITE-601:
-
See linked issues and discussion at
http://maven.40175.n5.nabble.com/How-to-avoid-part-of-URL-during-site-deployment-td3307034.html.
As I said there, a dot component is a valid part of a URL, I see no reason for
a repo or server to throw a 404.
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}distributionManagement
!--Site deploy repository--
site
idMYPROJECT.googlecode.com/id
urlscm:hg:https://code.google.com/p/MYPROJECT.site//url
/site
/distributionManagement{code}
And a standard server in settings.xml
{code:xml}servers
server
idMYPROJECT.googlecode.com/id
usernameUSERNAME/username
passwordPASSWORD/password
/server
/servers{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] 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-tabpanelfocusedCommentId=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}distributionManagement
!--Site deploy repository--
site
idMYPROJECT.googlecode.com/id
urlscm:hg:https://code.google.com/p/MYPROJECT.site//url
/site
/distributionManagement{code}
And a standard server in settings.xml
{code:xml}servers
server
idMYPROJECT.googlecode.com/id
usernameUSERNAME/username
passwordPASSWORD/password
/server
/servers{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}
configuration
filters
filtersrc/main/filters/filter.properties/filter
/filters
/configuration
{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}
configuration
filters
filter${basedir}/src/main/filters/filter.properties/filter
/filters
/configuration
{code}
What is confusing is that the first configuration works fine in the global
filter definition:
{code:xml}
build
filters
filtersrc/main/filters/filter.properties/filter
/filters
/build
{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-tabpanelfocusedCommentId=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}project.build.sourceEncodingISO-8859-1/project.build.sourceEncoding{code}
I have written a custom assembly file and I am using resource filtering.
{code}...
fileSet
directory${project.basedir}/src/main/resources//directory
outputDirectory//outputDirectory
filteredtrue/filtered
/fileSet
...{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-tabpanelfocusedCommentId=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-parentmvn 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-tabpanelfocusedCommentId=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: groupIdjavax/groupId artifactIdjavaee-api/artifactId version5.0/version 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: faceted-project fixed facet=jst.ear/ installed facet=jst.ear version=5/ /faceted-project The correct content should be: faceted-project fixed facet=jst.ear/ installed facet=jst.ear version=5.0/ /faceted-project 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-tabpanelfocusedCommentId=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:
module name=Checker
[...]
module name=TreeWalker
property name=cacheFile value=${cacheFile}/
[...]
/module
[...]
/module
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:
module name=Checker
[...]
module name=TreeWalker
property name=cacheFile value=$\{cachefile\}/
[...]
/module
[...]
/module
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 configuration/-Entry
propertyExpansion
cacheFile=${project.build.directory}/checkstyle-cachefile
/propertyExpansion
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-tabpanelfocusedCommentId=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-tabpanelfocusedCommentId=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 scopetest/scope 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
scopetest/scope 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:
dependency
groupIdjunit/groupId
artifactIdjunit/artifactId
version${junit.version}/version
scopetest/scope
/dependency
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}dependency
groupIdcom.almerys.pec/groupId
artifactIdws-ag2r-client/artifactId
version2.2.0.0.0/version
classifier${env}/classifier
/dependency{code}
and $env define as empty like that
env/env or env/
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
dependency
groupIdcom.almerys.pec/groupId
artifactIdws-ag2r-client/artifactId
version2.2.0.0.0/version
classifier${env}/classifier
/dependency
and $env define as empty like that
env/env or env/
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}dependency
groupIdcom.almerys.pec/groupId
artifactIdws-ag2r-client/artifactId
version2.2.0.0.0/version
classifier${env}/classifier
/dependency{code}
and $env define as empty like that
env/env or env/
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-tabpanelfocusedCommentId=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
