[jira] Created: (MASSEMBLY-95) Support unpacking of tar.gz, tgz, tar.bz2, and tbz2 archivers
Support unpacking of tar.gz, tgz, tar.bz2, and tbz2 archivers - Key: MASSEMBLY-95 URL: http://jira.codehaus.org/browse/MASSEMBLY-95 Project: Maven 2.x Assembly Plugin Type: New Feature Versions: 2.1 Environment: xp Reporter: Dan Tran I submitted PLX-216's patch to support this issue. Once PLX-216 is committed, i will send in the patch for this issue -- 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: (MSUREFIRE-103) Test failures in
Test failures in - Key: MSUREFIRE-103 URL: http://jira.codehaus.org/browse/MSUREFIRE-103 Project: Maven 2.x Surefire Plugin Type: Bug Versions: 2.1.3 Environment: j2sdk1.4.2_06 Reporter: Alexey Popov After an update the following error always occurs [INFO] [compiler:testCompile] Compiling 1 source file to ...\target\test-classes [INFO] [surefire:test] [INFO] Setting reports dir: ...\target/surefire-reports java.lang.NoSuchMethodError at org.apache.maven.surefire.SurefireBooter.createForkingClassLoader(SurefireBooter.java:291) at org.apache.maven.surefire.SurefireBooter.main(SurefireBooter.java:680) Exception in thread "main" [INFO] [ERROR] BUILD ERROR [INFO] [INFO] There are test failures. [INFO] [INFO] Trace org.apache.maven.lifecycle.LifecycleExecutionException: There are test failures. at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:556) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:47 2) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:451) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.jav a:303) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:270) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:139) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:322) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115) at org.apache.maven.cli.MavenCli.main(MavenCli.java:249) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) Caused by: org.apache.maven.plugin.MojoExecutionException: There are test failures. at org.apache.maven.test.SurefirePlugin.execute(SurefirePlugin.java:389) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:415) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:531) ... 16 more -- 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: (MDEP-4) Add support of unpack types tar.gz, tgz
[ http://jira.codehaus.org/browse/MDEP-4?page=all ] Dan Tran updated MDEP-4: Assign To: (was: Brian Fox) Description: plexus-archiver supports these types, i little more work to do the unpack for these special types (was: plexus-archiver supports these types, i little more work to do the unpack for these special type) Summary: Add support of unpack types tar.gz, tgz (was: [dependency-maven-plugin] Add support of unpack types tar.gz, tgz) > Add support of unpack types tar.gz, tgz > --- > > Key: MDEP-4 > URL: http://jira.codehaus.org/browse/MDEP-4 > Project: Maven 2.x Dependency Plugin > Type: Improvement > Environment: xp > Reporter: Dan Tran > > > plexus-archiver supports these types, i little more work to do the unpack for > these special types -- 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: (MDEP-4) [dependency-maven-plugin] Add support of unpack types tar.gz, tgz
[ http://jira.codehaus.org/browse/MDEP-4?page=comments#action_64782 ] Dan Tran commented on MDEP-4: - patch submitted to PLX-216 to support this issue > [dependency-maven-plugin] Add support of unpack types tar.gz, tgz > - > > Key: MDEP-4 > URL: http://jira.codehaus.org/browse/MDEP-4 > Project: Maven 2.x Dependency Plugin > Type: Improvement > Environment: xp > Reporter: Dan Tran > Assignee: Brian Fox > > > plexus-archiver supports these types, i little more work to do the unpack for > these special type -- 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-2274) error in depth handling of dependency tree
error in depth handling of dependency tree -- Key: MNG-2274 URL: http://jira.codehaus.org/browse/MNG-2274 Project: Maven 2 Type: Bug Components: Artifacts Versions: 2.0.4 Reporter: Brett Porter see r399960 of the assembly plugin for a pom that showed this Basically what happened was: 1) maven-archiver brought in plexus-archiver which brought in plexus-container-default (depth 2) 2) plugin-test-harness brought in a newer plexus-container-default (depth 1), scope test 3) newer one is selected, but changes in 2.0.4 means that it keeps the first node and applies the version 4) plexus-archiver (newer version) didn't bring in plexus-container-default, but previous one is disabled, along with its children we can't shift dependencies here - the setting of the version on the farthest node should be changed so that the nearest one is selected and any dependencies from the farthest one that apply (because of the stronger scope) are dragged in. -- 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: (CONTINUUM-681) CLONE -Added notifiers from web interface are removed after a new build
CLONE -Added notifiers from web interface are removed after a new build --- Key: CONTINUUM-681 URL: http://jira.codehaus.org/browse/CONTINUUM-681 Project: Continuum Type: Bug Components: Web interface Versions: 1.0-alpha-4 Reporter: Raul Cuesta Assigned to: Emmanuel Venisse Fix For: 1.0-alpha-4 -- 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: (CONTINUUM-681) CLONE -Added notifiers from web interface are removed after a new build
[ http://jira.codehaus.org/browse/CONTINUUM-681?page=comments#action_64788 ] Raul Cuesta commented on CONTINUUM-681: --- The same problem occurs in version 1.0.3 > CLONE -Added notifiers from web interface are removed after a new build > --- > > Key: CONTINUUM-681 > URL: http://jira.codehaus.org/browse/CONTINUUM-681 > Project: Continuum > Type: Bug > Components: Web interface > Versions: 1.0-alpha-4 > Reporter: Raul Cuesta > Assignee: Emmanuel Venisse > Fix For: 1.0-alpha-4 > > Original Estimate: 4 hours > Remaining: 4 hours > -- 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: (CONTINUUM-682) Builds that are only On Demand, not scheduled
Builds that are only On Demand, not scheduled - Key: CONTINUUM-682 URL: http://jira.codehaus.org/browse/CONTINUUM-682 Project: Continuum Type: Improvement Components: Core system Versions: 1.0.3 Reporter: David Eric Pugh I would like to be able to have a build that is purely on demand, without editing build targets. For example, I want to run a build that deploys my applciation to test, but I dont' want it scheduled. Or runs our Selenium tests, but again, only on demand. Currently you must pick a schedule. I tried setting a schedule for 1970, so it would never run automatically, but Continuum prevented me by saying it would never run. While that was nice, i would rather have a warning then be prevented! -- 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: (CONTINUUM-682) Builds that are only On Demand, not scheduled
[ http://jira.codehaus.org/browse/CONTINUUM-682?page=comments#action_64792 ] David Eric Pugh commented on CONTINUUM-682: --- Update: I got an exception, but the schedule was added. I could also try a build in year 2020 and see... > Builds that are only On Demand, not scheduled > - > > Key: CONTINUUM-682 > URL: http://jira.codehaus.org/browse/CONTINUUM-682 > Project: Continuum > Type: Improvement > Components: Core system > Versions: 1.0.3 > Reporter: David Eric Pugh > > > I would like to be able to have a build that is purely on demand, without > editing build targets. For example, I want to run a build that deploys my > applciation to test, but I dont' want it scheduled. Or runs our Selenium > tests, but again, only on demand. Currently you must pick a schedule. I > tried setting a schedule for 1970, so it would never run automatically, but > Continuum prevented me by saying it would never run. While that was nice, i > would rather have a warning then be prevented! -- 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: (MPXDOC-196) Tables with a width of 100% are incorrectly displayed in IE 5
Tables with a width of 100% are incorrectly displayed in IE 5 - Key: MPXDOC-196 URL: http://jira.codehaus.org/browse/MPXDOC-196 Project: maven-xdoc-plugin Type: Bug Versions: 1.9.2 Environment: Win2K Pro + IE5 Reporter: Arnaud Heritier Priority: Minor Using the maven-stylus style, the width of the table is 100% of the screen and not 100% of the available space. Thus the content of the page is moved after the menu. -- 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: (MPXDOC-196) Tables with a width of 100% are incorrectly displayed in IE 5
[ http://jira.codehaus.org/browse/MPXDOC-196?page=all ] Arnaud Heritier updated MPXDOC-196: --- Attachment: screenshot-1.jpg > Tables with a width of 100% are incorrectly displayed in IE 5 > - > > Key: MPXDOC-196 > URL: http://jira.codehaus.org/browse/MPXDOC-196 > Project: maven-xdoc-plugin > Type: Bug > Versions: 1.9.2 > Environment: Win2K Pro + IE5 > Reporter: Arnaud Heritier > Priority: Minor > Attachments: screenshot-1.jpg > > > Using the maven-stylus style, the width of the table is 100% of the screen > and not 100% of the available space. > Thus the content of the page is moved after the menu. -- 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-2275) profiles should be merged when inherited
profiles should be merged when inherited
Key: MNG-2275
URL: http://jira.codehaus.org/browse/MNG-2275
Project: Maven 2
Type: Bug
Components: Inheritence and Interpolation
Versions: 2.0.4
Reporter: Brian Fox
I have some default profiles setup in a super parent pom that all projects
inherit from. In some projects I want to change the active profile, but not
from the CLI because other projects running in the same multi-project build
need to have the normal default. I attempted to work around this by setting the
profile to be active on a property in the child pom. See below for parent and
child. It appears that when I do this, the child profile replaces the parent.
It should be merged so that the properties are pulled from the parent and uses
the activation from the child.
parent:
dev
src/main/filters/dev-default.values
auto-test
src/main/filters/auto-test-default.values
man-test
src/main/filters/man-test-default.values
prod
src/main/filters/prod-default.values
child pom..
${user.default.values}
${profile-default.values}
${user.default.values}
${client-ct-package.values}
src/main/resources
true
prod
deploy-ct
--
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-2276) profile activation by property doesn't work with properties defined in settings.
profile activation by property doesn't work with properties defined in settings. Key: MNG-2276 URL: http://jira.codehaus.org/browse/MNG-2276 Project: Maven 2 Type: Bug Components: POM Versions: 2.0.4 Reporter: Brian Fox Activating a profile like below doesn't get activated unless the property is set on the CLI. I need to have the property defined in the settings.xml so it's always set. prod deploy-ct Further, I noticed that if I set it so that the activation is like: deploy-cttrue The profile is triggered just by setting the cli like "mvn -Ddeploy-ct" It is not active if I use "-Ddeploy-ct=false" but the settings descriptor says that the existence of the property is only used if value is not set. -- 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: (MNGECLIPSE-120) Missing libraries in eclipse classpath
Missing libraries in eclipse classpath -- Key: MNGECLIPSE-120 URL: http://jira.codehaus.org/browse/MNGECLIPSE-120 Project: Maven 2.x Extension for Eclipse Type: Bug Components: Dependency Resolver Versions: 0.0.7 Environment: I Reporter: Dominic Zaza Assigned to: Eugene Kuleshov When I run update source folders, my libraries are not being set in the eclipse classpath. The only entry in my classpath is JRE. Also, I updated my plugin to version 0.0.7 from http://m2eclipse.codehaus.org/. Is this a released version? -- 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-27) ejbModules not included in application.xml
[ http://jira.codehaus.org/browse/MEAR-27?page=comments#action_64798 ] Stephane Nicoll commented on MEAR-27: - As I already said, this is impossible if you are using the standard lifecycle. The two application.xmls here have different version (1.3 and 1.4). Version 1.3 is the default (the one that looks okay). The 1.4 version has *NOT* been generated by the EAR plugin because it contains a description and a display name. Your POM does not contain those information. Please do the following: * Attach your project * Do mvn clean * Do mvn -X install and attach the debug output to the issue > ejbModules not included in application.xml > -- > > Key: MEAR-27 > URL: http://jira.codehaus.org/browse/MEAR-27 > Project: Maven 2.x Ear Plugin > Type: Bug > Environment: Windows XP > Reporter: Tom Cunningham > > > The problem I'm seeing is that the plugin is generating two different > application.xml's and the one that gets stuck into the ear doesn't seem > correct.The one that gets stuck into the ear doesn't give any entries for > the ejbModules I have defined. > My project has three dependencies and each should be a module in the > application.xml.Here's what I have defined in my pom.xml : > > > vfa > facility-war > 8.0 > war > > > vfa > persistence > provided > 8.0 > ejb > > > vfa > facility > 8.0 > ejb > > > > > > org.apache.maven.plugins > maven-ear-plugin > > > > vfa > facility > / > > > vfa > facility-war > vfa > > > vfa > persistence > / > > > > > > When I run "maven install", I find an application.xml in the target directory > that looks okay to me: > > "-//Sun Microsystems, Inc.//DTD J2EE Application 1.3//EN" > "http://java.sun.com/dtd/application_1_3.dtd";> > > facility-ear > > facility-8.0.jar > > > > facility-war-8.0.war > vfa > > > > persistence-8.0.jar > > > However, this isn't the application.xml that gets into the ear.The one > going into the ear > has no ejb modules defined. > > http://java.sun.com/xml/ns/j2ee"; > xmlns:xsi="ht > tp://www.w3.org/2001/XMLSchema-instance" > xsi:schemaLocation="http://java.sun.com > /xml/ns/j2ee http://java.sun.com/xml/ns/j2ee/application_1_4.xsd";> > Facility Prototype > Facility Prototype > > > facility-war-8.0.war > /vfa > > > -- 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-28) Patch to support JEE5 application.xml format
[ http://jira.codehaus.org/browse/MEAR-28?page=all ] Stephane Nicoll updated MEAR-28: Fix Version: 2.2 very kwel, thanks. > Patch to support JEE5 application.xml format > > > Key: MEAR-28 > URL: http://jira.codehaus.org/browse/MEAR-28 > Project: Maven 2.x Ear Plugin > Type: Improvement > Reporter: Stefan Arentz > Assignee: Stephane Nicoll > Fix For: 2.2 > Attachments: MEAR-28.patch > > > The attached patch adds support for version 5 style application.xml > descriptors. -- 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-2277) aggregating plugins in submodules of the reactor return all projects causing a chicken/egg issue
aggregating plugins in submodules of the reactor return all projects causing a chicken/egg issue Key: MNG-2277 URL: http://jira.codehaus.org/browse/MNG-2277 Project: Maven 2 Type: Bug Components: Reactor and workspace, Plugins and Lifecycle, Plugin API Versions: 2.0.4 Reporter: Brett Porter eg, assembly:attached when this is put in maven-core, and a build is run from the root project with a clean repo, it fails, as the original project sorter doesn't consider the dependencies, building plugin-tools after maven-core. However, hitting the aggregator when building maven-core then tries to resolve all of the projects as dependencies. -- 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: (MPTEST-62) -Dmaven.test.failure.ignore=true has no effect on test failures in second test dir added by
-Dmaven.test.failure.ignore=true has no effect on test failures in second test dir added by - Key: MPTEST-62 URL: http://jira.codehaus.org/browse/MPTEST-62 Project: maven-test-plugin Type: Bug Versions: 1.8 Environment: Windows, Maven 1.1 beta 3, test plugin 1.8-snapshot Reporter: Jeff Jensen When adding a second source dir of tests in M1 by adding this to maven.xml: if one of those tests fails, the build fails even with maven.test.failure.ignore=true. -- 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: (WAGONSSH-47) Add support for uploading file with server-side umask setting
Add support for uploading file with server-side umask setting - Key: WAGONSSH-47 URL: http://jira.codehaus.org/browse/WAGONSSH-47 Project: wagon-ssh Type: Improvement Versions: 1.0-alpha-7 Reporter: Jun Futagawa Attachments: ScpWagon-server_side_umask.patch Here's a patch for wagon-ssh that uploads a file according to a set value of umask on the server side. In our project, the project member uploads the file to the directory that directory mode is 2775. And, umask 002 is set to all the user accounts. However, wagon-ssh always up-loads the file by 644 permission when there is no filePermissions setting in the Maven's setting.xml file. -- 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] Closed: (MASSEMBLY-29) Possibility to aggrates sources from other modules
[ http://jira.codehaus.org/browse/MASSEMBLY-29?page=all ] John Casey closed MASSEMBLY-29: --- Resolution: Fixed see src/site/apt/examples/* for more information on how to use. also, see src/it/basic-features/** for tests. > Possibility to aggrates sources from other modules > -- > > Key: MASSEMBLY-29 > URL: http://jira.codehaus.org/browse/MASSEMBLY-29 > Project: Maven 2.x Assembly Plugin > Type: Bug > Reporter: Alexandre Poitras > Assignee: John Casey > Fix For: 2.1 > > Original Estimate: 5 hours >Time Spent: 10 hours > Remaining: 0 minutes > > It would be nice if it was possible to aggregate the sources of the other > sibling modules instead of having to archive different jar files containing > the sources. I would like also to be able to do that with Javadoc but I think > it's already in the scope of the javadoc 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] Commented: (WAGONSSH-19) make SingleKnownHostProvider configurable
[ http://jira.codehaus.org/browse/WAGONSSH-19?page=comments#action_64813 ] Juan F. Codagnone commented on WAGONSSH-19: --- sure, the idea of this issue is to be able to inject diferent implementations of classes that know how to resolv the host's public keys. if you want (and you know what you are doing) you even can turn off the public key validation. > make SingleKnownHostProvider configurable > -- > > Key: WAGONSSH-19 > URL: http://jira.codehaus.org/browse/WAGONSSH-19 > Project: wagon-ssh > Type: Task > Reporter: Juan F. Codagnone > Priority: Minor > Attachments: WAGONSSH-19.diff > > > Make org.apache.maven.wagon.providers.ssh.knownhost.SingleKnownHostProvider > configurable like > > test-private-repo > > > > implementation="org.apache.maven.wagon.providers.ssh.knownhos > t.SingleKnownHostProvider"> >localhost > > B3NzaC1yc2EBIwAAAIEAwps9EL+UKFG6Fb9spvV6YSOi > yLFwVGAgtyQ5r6xdADZRw0AdcCE87uwlVgUgMjGm0D/kifVEYFZu1DQUaKfg+6B3LEz7Dgq5Ir8eJJXq > 62mIVqHnXKPOqGIp1TPrtc2BMhSHk5z+4puun6Nbi0hw+g7b0/ywHVbs+7wb01SMREU= > > > > -- 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: (MSUREFIREREP-6) surefire-report reruns tests
[ http://jira.codehaus.org/browse/MSUREFIREREP-6?page=comments#action_64816 ] Dan Fabulich commented on MSUREFIREREP-6: - Is there any workaround for this? Is there some way I can skip the first test run and just let surefire-report run the tests for me or something? > surefire-report reruns tests > > > Key: MSUREFIREREP-6 > URL: http://jira.codehaus.org/browse/MSUREFIREREP-6 > Project: Maven 2.x Surefire report Plugin > Type: Bug > Environment: maven 2.0 > Reporter: Dirk Sturzebecher > > > surefire-report reruns the tests. In my case this is not just annoying, but > leads to a failure, as the VM (probably) is reused and leftovers from the > first tests are (definitly) still present. > I run maven with: clean package site -- 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: (MANTRUN-37) Antrun breaks on multi-module builds
[ http://jira.codehaus.org/browse/MANTRUN-37?page=comments#action_64818 ]
John Worrell commented on MANTRUN-37:
-
I'm also getting this same problem using Maven 2.04 and antrun 1.1.
The problem seems to be quite subtle and to depend quite subtly on the project
structure - I had no problem with one project but when I made relatively
innocuous looking changes I got the problem.
I'll look into sending up the POMs
> Antrun breaks on multi-module builds
>
>
> Key: MANTRUN-37
> URL: http://jira.codehaus.org/browse/MANTRUN-37
> Project: Maven 2.x Antrun Plugin
> Type: Bug
> Versions: 1.1
> Environment: Maven 2.0.1
> Reporter: Mike Perham
> Assignee: Carlos Sanchez
> Priority: Critical
>
>
> I just updated to antrun v1.1 (which needs to be marked as released in jira
> BTW) and find that my multimodule build is now breaking. Running the build
> in the child module itself works fine but if I build the parent, it fails
> when it gets to the child with the antrun task. Here's part of the debug
> output. Note it says 1.1 in the dependency tree but 1.0 further down.
> {noformat}
> [DEBUG] org.apache.maven.plugins:maven-antrun-plugin:maven-plugin:1.1
> (selected for runtime)
> [DEBUG] org.apache.maven:maven-project:jar:2.0.1 (selected for runtime)
> [DEBUG] org.apache.maven:maven-model:jar:2.0.1 (selected for runtime)
> [DEBUG] org.codehaus.plexus:plexus-utils:jar:1.0.5 (selected for
> runtime)
> [DEBUG] classworlds:classworlds:jar:1.1-alpha-2 (selected for runtime)
> [DEBUG] org.apache.maven:maven-profile:jar:2.0.1 (selected for runtime)
> [DEBUG] org.codehaus.plexus:plexus-container-default:jar:1.0-alpha-9
> (selected for runtime)
> [DEBUG] org.codehaus.plexus:plexus-utils:jar:1.0.4 (removed - nearer
> found: 1.0.5)
> [DEBUG] junit:junit:jar:3.8.1 (selected for runtime)
> [DEBUG] org.codehaus.plexus:plexus-container-default:jar:1.0-alpha-9
> (selected for runtime)
> [DEBUG] org.codehaus.plexus:plexus-utils:jar:1.0.4 (removed - nearer
> found: 1.0.5)
> [DEBUG] classworlds:classworlds:jar:1.1-alpha-2 (selected for runtime)
> [DEBUG] junit:junit:jar:3.8.1 (selected for runtime)
> [DEBUG] org.codehaus.plexus:plexus-utils:jar:1.0.5 (selected for runtime)
> [DEBUG] org.apache.maven:maven-artifact-manager:jar:2.0.1 (selected for
> runtime)
> [DEBUG] org.apache.maven:maven-repository-metadata:jar:2.0.1 (selected
> for runtime)
> [DEBUG] org.apache.maven.wagon:wagon-provider-api:jar:1.0-alpha-5
> (selected for runtime)
> [DEBUG] org.codehaus.plexus:plexus-utils:jar:1.0.4 (removed - nearer
> found: 1.0.5)
> [DEBUG] org.apache.maven:maven-artifact:jar:2.0.1 (selected for runtime)
> [DEBUG] org.apache.maven:maven-artifact:jar:2.0.1 (selected for runtime)
> [DEBUG] org.apache.maven:maven-plugin-api:jar:2.0.1 (selected for runtime)
> [DEBUG] ant:ant:jar:1.6.5 (selected for runtime)
> [DEBUG] ant:ant-launcher:jar:1.6.5 (selected for runtime)
> [INFO]
>
> [ERROR] BUILD ERROR
> [INFO]
>
> [INFO] Internal error in the plugin manager executing goal
> 'org.apache.maven.plugins:maven-antrun-plugin:1.0:run': Unable to find the
> mojo 'org.apache.maven.plugins:maven-antrun-plugin:1.0:run' in the plugin
> 'org.apache.maven.plugins:maven-antrun-plugin'
> Component descriptor cannot be found in the component repository:
> org.apache.maven.plugin.Mojoorg.apache.maven.plugins:maven-antrun-plugin:1.0:run.
> [INFO]
>
> [DEBUG] Trace
> org.apache.maven.lifecycle.LifecycleExecutionException: Internal error in the
> plugin manager executing goal
> 'org.apache.maven.plugins:maven-antrun-plugin:1.0:run': Unable to find the
> mojo 'org.apache.maven.plugins:maven-antrun-plugin:1.0:run' in the plugin
> 'org.apache.maven.plugins:maven-antrun-plugin'
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:534)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:472)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:451)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:303)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:270)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:139)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:322)
> at org.apache.maven.DefaultMave
[jira] Created: (MCHANGELOG-36) Tests fail on build
Tests fail on build --- Key: MCHANGELOG-36 URL: http://jira.codehaus.org/browse/MCHANGELOG-36 Project: Maven 2.x Changelog Plugin Type: Bug Versions: 2.0 Environment: osx 10.4.6, java 1.4.2_06 Reporter: Julian Wood The date test assertions all fail: junit.framework.AssertionFailedError: Test changelog 1 set 1 date/time expected:<23963580> but was:< 23971500 > at org.apache.maven.changelog.ChangeLogTest.testReadFile(ChangeLogTest.java:50) assertEquals( "Test changelog 1 set 1 date/time", 23963580L, changeSet.getDate().getTime() ); They just have the wrong date, and they are offset by the timezone ( 7 hours, in my case - I'm MST -0700) -- 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: (MCHANGELOG-36) Tests fail on build
[ http://jira.codehaus.org/browse/MCHANGELOG-36?page=all ] Julian Wood updated MCHANGELOG-36: -- Attachment: MCHANGELOG-36.patch > Tests fail on build > --- > > Key: MCHANGELOG-36 > URL: http://jira.codehaus.org/browse/MCHANGELOG-36 > Project: Maven 2.x Changelog Plugin > Type: Bug > Versions: 2.0 > Environment: osx 10.4.6, java 1.4.2_06 > Reporter: Julian Wood > Attachments: MCHANGELOG-36.patch > > > The date test assertions all fail: > junit.framework.AssertionFailedError: Test changelog 1 set 1 date/time > expected:<23963580> but was:< 23971500 > > at > org.apache.maven.changelog.ChangeLogTest.testReadFile(ChangeLogTest.java:50) > assertEquals( "Test changelog 1 set 1 date/time", 23963580L, > changeSet.getDate().getTime() ); > They just have the wrong date, and they are offset by the timezone ( 7 hours, > in my case - I'm MST -0700) -- 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] Closed: (MPCRUISECONTROL-32) Generated config.xml used deprecated and
[ http://jira.codehaus.org/browse/MPCRUISECONTROL-32?page=all ] Lukas Theussl closed MPCRUISECONTROL-32: Assign To: Lukas Theussl Resolution: Fixed > Generated config.xml used deprecated and > > --- > > Key: MPCRUISECONTROL-32 > URL: http://jira.codehaus.org/browse/MPCRUISECONTROL-32 > Project: maven-cruisecontrol-plugin > Type: Improvement > Versions: 1.7 > Reporter: Jamie Bisotti > Assignee: Lukas Theussl > Fix For: 1.8 > > > Should remove the deprecated tags and use > instead. -- 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: (MPCRUISECONTROL-24) Corrected the baseUrl
[ http://jira.codehaus.org/browse/MPCRUISECONTROL-24?page=all ]
Lukas Theussl updated MPCRUISECONTROL-24:
-
Fix Version: (was: 1.8)
> Corrected the baseUrl
> -
>
> Key: MPCRUISECONTROL-24
> URL: http://jira.codehaus.org/browse/MPCRUISECONTROL-24
> Project: maven-cruisecontrol-plugin
> Type: New Feature
> Versions: 1.6
> Environment: Subversion FC3
> Reporter: Philip Dodds
> Priority: Minor
> Attachments: cruisecontrol.diff, cruisecontrol.diff
>
>
> Here is the additional setting for the baseUrl, simply allows you to
> override the ${url} for the subversion repository so that modifications that
> are in subjects that are at the same level as the master project can be pick
> up.
> Attached in the SVN diff, hopefully I got it right this time. Sorry about
> the previous RAR file.
--
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: (ARCHETYPE-32) including png in site resources breaks an archetype (stacktrace+archetype.xml included)
[ http://jira.codehaus.org/browse/ARCHETYPE-32?page=comments#action_64820 ] Julian Wood commented on ARCHETYPE-32: -- No, I'm using alpha-3. Is alpha-4 going to be released anytime soon? It looks like it has been about 7 months since alpha-3 was released. > including png in site resources breaks an archetype (stacktrace+archetype.xml > included) > --- > > Key: ARCHETYPE-32 > URL: http://jira.codehaus.org/browse/ARCHETYPE-32 > Project: Maven Archetype > Type: Bug > Components: Plugin > Reporter: Jurgen De Landsheer > Assignee: Jason van Zyl > > > if I drop the png: creation is correct but it seems it wants to parse a png > or something? > > maven-ugent-plugin-archetype > > > src/main/java/org/codehaus/mojo/test/TestMojo.java > > > > > > src/test/java/org/codehaus/mojo/test/TestMojoTestSuite.java > > > > src/main/resources/jalopy.xml > src/main/resources/plugin.properties > > > src/test/resources/test.properties > > > src/site/site.xml > src/site/apt/usage.apt > > src/site/resources/images/logobalk_small.png > > > C:\JAVA\maven-plugins>mvn -e archetype:create > -DarchetypeGroupId=be.ugent.dict > -DarchetypeArtifactId=maven-ugent-plugin-archetype -DgroupId= > -DartifactId=test > C:\JAVA\maven-plugins>set MAVEN_OPTS=-Xmx32m -Xmx200m > + Error stacktraces are turned on. > [INFO] Scanning for projects... > [INFO] Reactor build order: > [INFO] maven-ugent-plugin-archetype > [INFO] maven-mojo-report-plugin > [INFO] maven-lint4j-plugin > [INFO] maven-juge-plugin > [INFO] maven-project-info-plugin > [INFO] maven-spring-beandoc-plugin > [INFO] maven-linguine-maps-plugin > [INFO] maven-hibernate-tools-plugin > [INFO] Searching repository for plugin with prefix: 'archetype'. > [INFO] org.apache.maven.plugins: checking for updates from missing-plugins > [INFO] org.apache.maven.plugins: checking for updates from ugent-plugins > [INFO] org.codehaus.mojo: checking for updates from missing-plugins > [INFO] org.codehaus.mojo: checking for updates from ugent-plugins > [INFO] artifact org.apache.maven.plugins:maven-compiler-plugin: checking for > updates from missing-plugins > [INFO] artifact org.apache.maven.plugins:maven-compiler-plugin: checking for > updates from ugent-plugins > [INFO] artifact org.apache.maven.plugins:maven-site-plugin: checking for > updates from missing-plugins > [INFO] artifact org.apache.maven.plugins:maven-site-plugin: checking for > updates from ugent-plugins > [INFO] artifact org.apache.maven.plugins:maven-surefire-plugin: checking for > updates from missing-plugins > [INFO] artifact org.apache.maven.plugins:maven-surefire-plugin: checking for > updates from ugent-plugins > [INFO] artifact org.apache.maven.plugins:maven-archetype-plugin: checking for > updates from missing-plugins > [INFO] artifact org.apache.maven.plugins:maven-archetype-plugin: checking for > updates from ugent-plugins > [INFO] > > [INFO] Building maven-mojo-report-plugin > [INFO]task-segment: [archetype:create] (aggregator-style) > [INFO] > > [INFO] Setting property: classpath.resource.loader.class => > 'org.codehaus.plexus.velocity.ContextClassLoaderResourceLoader'. > [INFO] Setting property: resource.loader => 'classpath'. > [INFO] ** > [INFO] Starting Jakarta Velocity v1.4 > [INFO] RuntimeInstance initializing. > [INFO] Default Properties File: > org\apache\velocity\runtime\defaults\velocity.properties > [INFO] Default ResourceManager initializing. (class > org.apache.velocity.runtime.resource.ResourceManagerImpl) > [INFO] Resource Loader Instantiated: > org.codehaus.plexus.velocity.ContextClassLoaderResourceLoader > [INFO] ClasspathResourceLoader : initialization starting. > [INFO] ClasspathResourceLoader : initialization complete. > [INFO] ResourceCache : initialized. (class > org.apache.velocity.runtime.resource.ResourceCacheImpl) > [INFO] Default ResourceManager initialization complete. > [INFO] Loaded System Directive: org.apache.velocity.runtime.directive.Literal > [INFO] Loaded System Directive: org.apache.velocity.runtime.directive.Macro > [INFO] Loaded System Directive: org.apache.velocity.runtime.directive.Parse > [INFO] Loaded System Directive: org.apache.velocity.runtime.directive.Include > [INFO] Loaded System Directive: org.apache.velocity.runtime.directive.Foreach > [INFO] Created: 20 parsers. > [INFO] Velocimacro : initializ
[jira] Commented: (MEJB-6) Make the ejb-jar.xml deployment descriptor optional
[ http://jira.codehaus.org/browse/MEJB-6?page=comments#action_64822 ] Tim McCune commented on MEJB-6: --- Thanks for the patch Dan. This was exactly what I needed to get Maven 2 to be able to build my project. Sure would be nice if someone would apply it. > Make the ejb-jar.xml deployment descriptor optional > --- > > Key: MEJB-6 > URL: http://jira.codehaus.org/browse/MEJB-6 > Project: Maven 2.x Ejb Plugin > Type: Improvement > Reporter: Tim Kettler > Priority: Trivial > Attachments: MEJB-4-maven-ejb-plugin.patch, MEJB-6-maven-ejb-plugin.patch > > > In the now near final EJB3 specification the use of deployment descripors is > optional. It would be nice if the maven-ejb-plugin wouldn't bump out with an > error if no descriptor is present. > The attached patch introduces a new boolean configuration option > 'enforceDeploymentDescriptor' which defaults to true so that the default > behavior is not changed. Feel free to change the name of the property if > appropriate. -- 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] Closed: (MNG-1181) MavenEmbedder.execute() doesn't run reactor modules
[ http://jira.codehaus.org/browse/MNG-1181?page=all ] Jason van Zyl closed MNG-1181: -- Resolution: Fixed The command line and embedder now work identically when executing. > MavenEmbedder.execute() doesn't run reactor modules > --- > > Key: MNG-1181 > URL: http://jira.codehaus.org/browse/MNG-1181 > Project: Maven 2 > Type: Bug > Components: Embedding > Reporter: Eugene Kuleshov > Assignee: Jason van Zyl > Priority: Blocker > Fix For: 2.0.5 > Attachments: MNG-1181.tar.gz, MavenEmbedder2.java, MavenEmbedder2.java > > > MavenEmbedder.execute() doesn't run reactor modules. > I've been trying to run it with "generate-sources" goal, but it only build > the root project. -- 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-1181) MavenEmbedder.execute() doesn't run reactor modules
[ http://jira.codehaus.org/browse/MNG-1181?page=comments#action_64824 ] Eugene Kuleshov commented on MNG-1181: -- Jason, what embedder version or snapshot I could use? > MavenEmbedder.execute() doesn't run reactor modules > --- > > Key: MNG-1181 > URL: http://jira.codehaus.org/browse/MNG-1181 > Project: Maven 2 > Type: Bug > Components: Embedding > Reporter: Eugene Kuleshov > Assignee: Jason van Zyl > Priority: Blocker > Fix For: 2.0.5 > Attachments: MNG-1181.tar.gz, MavenEmbedder2.java, MavenEmbedder2.java > > > MavenEmbedder.execute() doesn't run reactor modules. > I've been trying to run it with "generate-sources" goal, but it only build > the root project. -- 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: (MSUREFIREREP-6) surefire-report reruns tests
[ http://jira.codehaus.org/browse/MSUREFIREREP-6?page=comments#action_64825 ] Brett Porter commented on MSUREFIREREP-6: - you can try putting into the section. However, this will always skip tests during build (but still run them through site). > surefire-report reruns tests > > > Key: MSUREFIREREP-6 > URL: http://jira.codehaus.org/browse/MSUREFIREREP-6 > Project: Maven 2.x Surefire report Plugin > Type: Bug > Environment: maven 2.0 > Reporter: Dirk Sturzebecher > > > surefire-report reruns the tests. In my case this is not just annoying, but > leads to a failure, as the VM (probably) is reused and leftovers from the > first tests are (definitly) still present. > I run maven with: clean package site -- 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] Closed: (MNGECLIPSE-120) Missing libraries in eclipse classpath
[ http://jira.codehaus.org/browse/MNGECLIPSE-120?page=all ] Eugene Kuleshov closed MNGECLIPSE-120: -- Resolution: Incomplete We can't reproduce this with information provided. Please make sure that M2 console does not show any errors when you run Project / Clean... If there is no errors, feel free to reopen this issue but make sure you attached project that we can use to reproduce this. Thanks > Missing libraries in eclipse classpath > -- > > Key: MNGECLIPSE-120 > URL: http://jira.codehaus.org/browse/MNGECLIPSE-120 > Project: Maven 2.x Extension for Eclipse > Type: Bug > Components: Dependency Resolver > Versions: 0.0.7 > Environment: I > Reporter: Dominic Zaza > Assignee: Eugene Kuleshov > > > When I run update source folders, my libraries are not being set in the > eclipse classpath. The only entry in my classpath is JRE. > Also, I updated my plugin to version 0.0.7 from > http://m2eclipse.codehaus.org/. Is this a released version? -- 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: (MNGECLIPSE-116) 0.0.7 plugin will not load. Embedder related exception
[ http://jira.codehaus.org/browse/MNGECLIPSE-116?page=all ] Eugene Kuleshov updated MNGECLIPSE-116: --- Fix Version: (was: 0.0.7) > 0.0.7 plugin will not load. Embedder related exception > -- > > Key: MNGECLIPSE-116 > URL: http://jira.codehaus.org/browse/MNGECLIPSE-116 > Project: Maven 2.x Extension for Eclipse > Type: Bug > Versions: 0.0.7 > Environment: WinXP, Eclipse 3.1.2, Maven2.0.4 > Reporter: Cliff Resnick > Assignee: Eugene Kuleshov > > > I upgraded from 0.0.5 to 0.0.7 and the plugin fails to load. > Below is output from the workspace log file: > !MESSAGE An error occurred while automatically activating bundle > org.maven.ide.eclipse (443). > !STACK 0 > org.osgi.framework.BundleException: Exception in > org.maven.ide.eclipse.Maven2Plugin.start() of bundle org.maven.ide.eclipse. > at > org.eclipse.osgi.framework.internal.core.BundleContextImpl.startActivator(BundleContextImpl.java:1013) > at > org.eclipse.osgi.framework.internal.core.BundleContextImpl.start(BundleContextImpl.java:969) > at > org.eclipse.osgi.framework.internal.core.BundleHost.startWorker(BundleHost.java:316) > at > org.eclipse.osgi.framework.internal.core.AbstractBundle.start(AbstractBundle.java:264) > at > org.eclipse.core.runtime.adaptor.EclipseClassLoader.findLocalClass(EclipseClassLoader.java:116) > at > org.eclipse.osgi.framework.internal.core.BundleLoader.findLocalClass(BundleLoader.java:337) > at > org.eclipse.osgi.framework.internal.core.BundleLoader.findClass(BundleLoader.java:389) > at > org.eclipse.osgi.framework.internal.core.BundleLoader.findClass(BundleLoader.java:350) > at > org.eclipse.osgi.framework.adaptor.core.AbstractClassLoader.loadClass(AbstractClassLoader.java:78) > at java.lang.ClassLoader.loadClass(ClassLoader.java:235) > at > org.eclipse.osgi.framework.internal.core.BundleLoader.loadClass(BundleLoader.java:275) > at > org.eclipse.osgi.framework.internal.core.BundleHost.loadClass(BundleHost.java:227) > at > org.eclipse.osgi.framework.internal.core.AbstractBundle.loadClass(AbstractBundle.java:1248) > at > org.eclipse.core.internal.registry.ConfigurationElement.createExecutableExtension(ConfigurationElement.java:152) > at > org.eclipse.core.internal.registry.ConfigurationElement.createExecutableExtension(ConfigurationElement.java:142) > at > org.eclipse.core.internal.registry.ConfigurationElement.createExecutableExtension(ConfigurationElement.java:129) > at > org.eclipse.core.internal.registry.ConfigurationElementHandle.createExecutableExtension(ConfigurationElementHandle.java:48) > at > org.eclipse.ui.internal.WorkbenchPlugin$1.run(WorkbenchPlugin.java:240) > at org.eclipse.swt.custom.BusyIndicator.showWhile(BusyIndicator.java:69) > at > org.eclipse.ui.internal.WorkbenchPlugin.createExtension(WorkbenchPlugin.java:236) > at > org.eclipse.ui.internal.dialogs.WorkbenchPreferenceNode.createPage(WorkbenchPreferenceNode.java:46) > at > org.eclipse.jface.preference.PreferenceDialog.createPage(PreferenceDialog.java:1211) > at > org.eclipse.ui.internal.dialogs.FilteredPreferenceDialog.createPage(FilteredPreferenceDialog.java:238) > at > org.eclipse.jface.preference.PreferenceDialog.showPage(PreferenceDialog.java:1114) > at > org.eclipse.ui.internal.dialogs.FilteredPreferenceDialog.showPage(FilteredPreferenceDialog.java:351) > at > org.eclipse.jface.preference.PreferenceDialog$8.selectionChanged(PreferenceDialog.java:638) > at > org.eclipse.jface.viewers.StructuredViewer$3.run(StructuredViewer.java:763) > at > org.eclipse.core.internal.runtime.InternalPlatform.run(InternalPlatform.java:1044) > at org.eclipse.core.runtime.Platform.run(Platform.java:783) > at org.eclipse.ui.internal.JFaceUtil$1.run(JFaceUtil.java:44) > at org.eclipse.jface.util.SafeRunnable.run(SafeRunnable.java:148) > at > org.eclipse.jface.viewers.StructuredViewer.firePostSelectionChanged(StructuredViewer.java:761) > at > org.eclipse.jface.viewers.StructuredViewer.setSelection(StructuredViewer.java:1453) > at > org.eclipse.jface.preference.PreferenceDialog.selectSavedItem(PreferenceDialog.java:925) > at > org.eclipse.ui.internal.dialogs.FilteredPreferenceDialog.selectSavedItem(FilteredPreferenceDialog.java:394) > at > org.eclipse.jface.preference.PreferenceDialog$3.run(PreferenceDialog.java:342) > at org.eclipse.swt.custom.BusyIndicator.showWhile(BusyIndicator.java:69) > at > org.eclipse.jface.preference.PreferenceDialog.createContents(PreferenceDialog.java:338) > at org.eclipse.jface.window.Window.create(Window.java:418) > at org.eclipse.jface.dialogs.Dialog.create(Dialog.java:996) > at > org.eclipse.ui.internal.dialogs.Workbenc
[jira] Updated: (MJAVADOC-69) javadoc plugin install fails when running "mvn install" from plugins dir
[ http://jira.codehaus.org/browse/MJAVADOC-69?page=all ] Brett Porter updated MJAVADOC-69: - Fix Version: 2.0 > javadoc plugin install fails when running "mvn install" from plugins dir > > > Key: MJAVADOC-69 > URL: http://jira.codehaus.org/browse/MJAVADOC-69 > Project: Maven 2.x Javadoc Plugin > Type: Bug > Environment: fedora core 5, jdk 1.5.0_06, x86 > Reporter: Arik Kfir > Fix For: 2.0 > > > When running "mvn clean install" from the plugins dir (above the > maven-javadoc-plugin dir) the plugin fails to build. Running the same command > from inside the javadoc dir works fine. -- 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: (MJAVADOC-68) Paths with quotes cause error in Javadoc plugin
[ http://jira.codehaus.org/browse/MJAVADOC-68?page=all ]
Brett Porter updated MJAVADOC-68:
-
Fix Version: 2.0
> Paths with quotes cause error in Javadoc plugin
> ---
>
> Key: MJAVADOC-68
> URL: http://jira.codehaus.org/browse/MJAVADOC-68
> Project: Maven 2.x Javadoc Plugin
> Type: Bug
> Versions: 2.0-beta-3
> Reporter: Tim O'Brien
> Fix For: 2.0
>
>
> On Windows, my Maven 2 repository is in "C:\Program Files\Tim
> O'Brien\.m2.repository". Because of the way that quotedPathArgument
> generates a path on Windows, the classpath is invalid. Causes Javadoc
> plugin to fail for Windows users with apostrophes in last name.
> From:
> http://svn.apache.org/viewcvs.cgi/maven/plugins/trunk/maven-javadoc-plugin/src/main/java/org/apache/maven/plugin/javadoc/AbstractJavadocMojo.java?rev=392516&view=markup
> private String quotedPathArgument( String value )
> {
> String path = value;
> if ( !StringUtils.isEmpty( path ) )
> {
> path = "'" + path.replace( '\\', '/' ) + "'";
> }
> return path;
> }
--
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: (MJXR-11) long/complex destination directories for site cause a "String index out of range" error
[ http://jira.codehaus.org/browse/MJXR-11?page=all ]
Brett Porter updated MJXR-11:
-
Fix Version: 2.0
> long/complex destination directories for site cause a "String index out of
> range" error
> ---
>
> Key: MJXR-11
> URL: http://jira.codehaus.org/browse/MJXR-11
> Project: Maven 2.x JXR Plugin
> Type: Bug
> Environment: windows xp
> Reporter: rudi grasmuck
> Fix For: 2.0
>
>
> If I setup the plugin as follows
>
> org.codehaus.mojo
>jxr-maven-plugin
>
>${workspace.dir}/site/${project.artifactId}/xref
>
>
> where the destDir variables resolve to
> "C:\projects\FNBTestAgain3\site\rasonlineswift\xref"
> I get
> Embedded error: Error while generating the HTML source code of the projet.
> String index out of range: -3
> If i use relative indicators
> ../../site/${project.artifactId}/xref which in effect
> points to the same directory it works fine
> full exception below:
> [INFO] Trace
> org.apache.maven.lifecycle.LifecycleExecutionException: Error during report
> gene
> ration
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(Defa
> ultLifecycleExecutor.java:559)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLi
> fecycle(DefaultLifecycleExecutor.java:475)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(Defau
> ltLifecycleExecutor.java:454)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHan
> dleFailures(DefaultLifecycleExecutor.java:306)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegmen
> ts(DefaultLifecycleExecutor.java:273)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLi
> fecycleExecutor.java:140)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:322)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:256)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.
> java:39)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
> sorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:324)
> at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
> at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
> at
> org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
> at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
> Caused by: org.apache.maven.plugin.MojoExecutionException: Error during
> report g
> eneration
> at org.apache.maven.plugins.site.SiteMojo.execute(SiteMojo.java:389)
> at
> org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPlugi
> nManager.java:412)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(Defa
> ultLifecycleExecutor.java:534)
> ... 16 more
> Caused by: org.apache.maven.reporting.MavenReportException: Error while
> generati
> ng the HTML source code of the projet.
> at
> org.apache.maven.plugin.jxr.JxrReport.generateXrefForSources(JxrRepor
> t.java:202)
> at
> org.apache.maven.plugin.jxr.JxrReport.executeReport(JxrReport.java:16
> 5)
> at
> org.apache.maven.reporting.AbstractMavenReport.generate(AbstractMaven
> Report.java:117)
> at
> org.apache.maven.plugins.site.SiteMojo.generateReportsPages(SiteMojo.
> java:802)
> at org.apache.maven.plugins.site.SiteMojo.execute(SiteMojo.java:301)
> ... 18 more
> Caused by: java.lang.StringIndexOutOfBoundsException: String index out of
> range:
> -3
> at java.lang.String.substring(String.java:1444)
> at java.lang.String.substring(String.java:1411)
> at
> org.apache.maven.plugin.jxr.JxrReport.generateXrefForSources(JxrRepor
> t.java:195)
--
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: (MSUREFIRE-97) TestNG tests are not executed if invoked by */*Test.java naming pattern
[ http://jira.codehaus.org/browse/MSUREFIRE-97?page=all ] Brett Porter updated MSUREFIRE-97: -- Fix Version: 2.2 > TestNG tests are not executed if invoked by */*Test.java naming pattern > --- > > Key: MSUREFIRE-97 > URL: http://jira.codehaus.org/browse/MSUREFIRE-97 > Project: Maven 2.x Surefire Plugin > Type: Bug > Environment: Windows XP, Maven 2.0.4, Surefire from snapshot server > Reporter: Andreas Guther > Fix For: 2.2 > Attachments: my-app-2.zip > > > I created an example project and added two testng tests, one ending with > *Test.java, one with a not Test containing name. Surefire seems to be able > to find the test but does not execute the tests inside the class (one should > succeed, one should fail). The console output is below. I will attach my > example project in zip format to the issue report. > C:\workspace\my-app>mvn test > [INFO] Scanning for projects... > [INFO] > > [INFO] Building Maven Quick Start Archetype > [INFO]task-segment: [test] > [INFO] > > [INFO] [resources:resources] > [INFO] Using default encoding to copy filtered resources. > [INFO] [compiler:compile] > [INFO] Nothing to compile - all classes are up to date > [INFO] [resources:testResources] > [INFO] Using default encoding to copy filtered resources. > [INFO] [compiler:testCompile] > Compiling 2 source files to C:\workspace\my-app\target\test-classes > [INFO] [surefire:test] > [INFO] Surefire report directory: C:\workspace\my-app\target\surefire-reports > --- > T E S T S > --- > Running com.mycompany.app.AppTest > Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.015 sec > Running com.mycompany.app.TestNgJavaOneTngTest > Tests run: 0, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.016 sec > Results : > Tests run: 1, Failures: 0, Errors: 0, Skipped: 0 > [INFO] > > [INFO] BUILD SUCCESSFUL > [INFO] > > [INFO] Total time: 2 seconds > [INFO] Finished at: Tue May 02 07:14:11 PDT 2006 > [INFO] Final Memory: 4M/508M > [INFO] > -- 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: (MSUREFIRE-103) Test failures in
[ http://jira.codehaus.org/browse/MSUREFIRE-103?page=comments#action_64827 ] Brett Porter commented on MSUREFIRE-103: "after an update" - how did you get the update? > Test failures in > - > > Key: MSUREFIRE-103 > URL: http://jira.codehaus.org/browse/MSUREFIRE-103 > Project: Maven 2.x Surefire Plugin > Type: Bug > Versions: 2.1.3 > Environment: j2sdk1.4.2_06 > Reporter: Alexey Popov > > Original Estimate: 2 hours > Remaining: 2 hours > > After an update the following error always occurs > [INFO] [compiler:testCompile] > Compiling 1 source file to ...\target\test-classes > [INFO] [surefire:test] > [INFO] Setting reports dir: ...\target/surefire-reports > java.lang.NoSuchMethodError > at > org.apache.maven.surefire.SurefireBooter.createForkingClassLoader(SurefireBooter.java:291) > at > org.apache.maven.surefire.SurefireBooter.main(SurefireBooter.java:680) > Exception in thread "main" > [INFO] > > [ERROR] BUILD ERROR > [INFO] > > [INFO] There are test failures. > [INFO] > > [INFO] Trace > org.apache.maven.lifecycle.LifecycleExecutionException: There are test > failures. > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:556) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:47 > 2) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:451) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.jav > a:303) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:270) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:139) > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:322) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:249) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:585) > at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) > at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) > at > org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) > at org.codehaus.classworlds.Launcher.main(Launcher.java:375) > Caused by: org.apache.maven.plugin.MojoExecutionException: There are test > failures. > at > org.apache.maven.test.SurefirePlugin.execute(SurefirePlugin.java:389) > at > org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:415) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:531) > ... 16 more -- 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: (MSUREFIRE-98) JUnit Tests are not executed if TestNG configuration file is used to invoke TestNG tests
[ http://jira.codehaus.org/browse/MSUREFIRE-98?page=all ] Brett Porter updated MSUREFIRE-98: -- Fix Version: 2.2 > JUnit Tests are not executed if TestNG configuration file is used to invoke > TestNG tests > > > Key: MSUREFIRE-98 > URL: http://jira.codehaus.org/browse/MSUREFIRE-98 > Project: Maven 2.x Surefire Plugin > Type: Bug > Environment: Windows XP, Maven 2.0.4, Java 1.4, Surefire from Snapshot server > Reporter: Andreas Guther > Fix For: 2.2 > Attachments: my-app.zip > > > I have JUnit tests and TestNG unit tests in the same project. If I use a > TestNG XML configurartion file only the files (TestNG) listed in the > configuration file are executed. JUnit test files are ignored. TestNG > allows to include JUnit tests in the configuration, but I would expect that > JUnit tests should be found based on the standard naming pattern and in > addition TestNG classes as listed in the TestNG XML config file are executed > as well. > Expected that JUnit files are executed and in addition TestNG files. It > should be possible to use different test frameworks in the same project. > I will attach the example project. > Output: > C:\workspace\my-app>mvn test > [INFO] Scanning for projects... > [INFO] > > [INFO] Building Are JUnit Tests Ignored if TestNG Config XML is used? > [INFO]task-segment: [test] > [INFO] > > [INFO] [resources:resources] > [INFO] Using default encoding to copy filtered resources. > [INFO] [compiler:compile] > [INFO] Nothing to compile - all classes are up to date > [INFO] [resources:testResources] > [INFO] Using default encoding to copy filtered resources. > [INFO] [compiler:testCompile] > [INFO] Nothing to compile - all classes are up to date > [INFO] [surefire:test] > [INFO] Surefire report directory: C:\workspace\my-app\target\surefire-reports > --- > T E S T S > --- > Running Test with JavaDoc Annotations under Java 1.4 > com.mycompany.app.JavaOneFourTngSample: beforeClass > com.mycompany.app.JavaOneFourTngSample: beforeMethod > com.mycompany.app.JavaOneFourTngSample: someTestMethod > com.mycompany.app.JavaOneFourTngSample: beforeMethod > Tests run: 2, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.078 sec <<< > FAILURE! > Results : > Tests run: 2, Failures: 1, Errors: 0, Skipped: 0 > [ERROR] There are test failures. > [INFO] > > [INFO] BUILD SUCCESSFUL > [INFO] > > [INFO] Total time: 3 seconds > [INFO] Finished at: Tue May 02 09:38:59 PDT 2006 > [INFO] Final Memory: 4M/508M > [INFO] > -- 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: (MRESOURCES-12) Wrog filtering after at symbol using profiles
[ http://jira.codehaus.org/browse/MRESOURCES-12?page=comments#action_64833 ] Brett Porter commented on MRESOURCES-12: do you have an example of this? > Wrog filtering after at symbol using profiles > - > > Key: MRESOURCES-12 > URL: http://jira.codehaus.org/browse/MRESOURCES-12 > Project: Maven 2.x Resources Plugin > Type: Bug > Environment: All platforms > Reporter: Motxilo > Priority: Minor > > > Using profiles, when a resource -for instance, a Spring XML context file- > needs to be filtered before being deployed, it seems that after an at > character (@) included in a comment in the middle of the file, properties > aren't filtered at all, while others before the aforementioned comment are. -- 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] Closed: (MRESOURCES-13) Problem with filtering Unicode-Files
[ http://jira.codehaus.org/browse/MRESOURCES-13?page=all ]
Brett Porter closed MRESOURCES-13:
--
Assign To: Brett Porter
Resolution: Cannot Reproduce
> Problem with filtering Unicode-Files
>
>
> Key: MRESOURCES-13
> URL: http://jira.codehaus.org/browse/MRESOURCES-13
> Project: Maven 2.x Resources Plugin
> Type: Bug
> Environment: Maven 2.0.2
> Reporter: Fabian Bauschulte
> Assignee: Brett Porter
>
>
> When filtering an unicode file all filters (e.g. ${SCHEMA}) are ignored in
> during filtering without messages. After converting the file to ASCII or
> UTF-8 the filtering works fine.
--
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: (MRESOURCES-10) Filtering should handle java.io.File values
[ http://jira.codehaus.org/browse/MRESOURCES-10?page=all ]
Brett Porter updated MRESOURCES-10:
---
Fix Version: 2.2
> Filtering should handle java.io.File values
> ---
>
> Key: MRESOURCES-10
> URL: http://jira.codehaus.org/browse/MRESOURCES-10
> Project: Maven 2.x Resources Plugin
> Type: Improvement
> Reporter: Mike Perham
> Fix For: 2.2
>
>
> I'm trying to use filters along with ${basedir} to setup my unit test Derby
> database. Derby must have a unique directory to build its database in and
> this becomes a problem in multi-module builds.
> Currently I'm doing this:
> {code:xml}
> class="org.apache.commons.dbcp.BasicDataSource">
>name="driverClassName">org.apache.derby.jdbc.EmbeddedDriver
>name="url">jdbc:derby:target/test/testdb/${pom.artifactId};create=true
>
> {code}
> But I'd like to do this:
> {code:xml}
> class="org.apache.commons.dbcp.BasicDataSource">
>name="driverClassName">org.apache.derby.jdbc.EmbeddedDriver
>name="url">jdbc:derby:${basedir}/target/test/testdb;create=true
>
> {code}
> When I try to do the latter, I get this:
> java.lang.ClassCastException: java.io.File
> at
> org.codehaus.plexus.util.InterpolationFilterReader.read(InterpolationFilterReader.java:269)
> at
> org.codehaus.plexus.util.InterpolationFilterReader.read(InterpolationFilterReader.java:162)
> at java.io.Reader.read(Reader.java:100)
> at org.codehaus.plexus.util.IOUtil.copy(IOUtil.java:212)
> at org.codehaus.plexus.util.IOUtil.copy(IOUtil.java:200)
> at
> org.apache.maven.plugin.resources.ResourcesMojo.copyFile(ResourcesMojo.java:249)
> at
> org.apache.maven.plugin.resources.ResourcesMojo.copyResources(ResourcesMojo.java:172)
> at
> org.apache.maven.plugin.resources.TestResourcesMojo.execute(TestResourcesMojo.java:53)
> at
> org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:415)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:531)
--
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: (MRESOURCES-11) Module doesn't depend on commons-io - remove dependency from pom
[ http://jira.codehaus.org/browse/MRESOURCES-11?page=all ] Brett Porter updated MRESOURCES-11: --- Fix Version: 2.2 > Module doesn't depend on commons-io - remove dependency from pom > > > Key: MRESOURCES-11 > URL: http://jira.codehaus.org/browse/MRESOURCES-11 > Project: Maven 2.x Resources Plugin > Type: Improvement > Reporter: Grzegorz Slowikowski > Priority: Trivial > Fix For: 2.2 > > > commons-io dependency should be removed -- 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: (MSITE-123) Output encoding is UTF-8 despite outputEncoding is set to ISO-8859-1
[ http://jira.codehaus.org/browse/MSITE-123?page=comments#action_64834 ] Brett Porter commented on MSITE-123: have you set in the site plugin configuration? > Output encoding is UTF-8 despite outputEncoding is set to ISO-8859-1 > > > Key: MSITE-123 > URL: http://jira.codehaus.org/browse/MSITE-123 > Project: Maven 2.x Site Plugin > Type: Bug > Environment: SuSE Linux 10.0. LANG=sv_SE.ISO-8859-1 > Reporter: Anders Heintz > Priority: Minor > > > When I generate the site containing xdocs with swedish characters (åäö), the > browser shows corrupted characters, and after investigation I found that the > output HTML-files are actually encoded using UTF-8. > If I change the outputEncoding to UTF-8, it works ok. Since all documentation > states that default encoding for everything(?) is ISO-8859-1, it should > perhaps be corrected. -- 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] Closed: (MSITE-87) Provide mechanism to change names of project (and possibly other) reports, etc. in site
[ http://jira.codehaus.org/browse/MSITE-87?page=all ] Brett Porter closed MSITE-87: - Assign To: Brett Porter Resolution: Duplicate assuming this is sufficient - duplicate of other issue where this was implemented > Provide mechanism to change names of project (and possibly other) reports, > etc. in site > --- > > Key: MSITE-87 > URL: http://jira.codehaus.org/browse/MSITE-87 > Project: Maven 2.x Site Plugin > Type: New Feature > Versions: 2.0-beta-4 > Environment: Windows/XP, Maven2 > Reporter: Chris Markle > Assignee: Brett Porter > > > Assume that I have a set of Project Reports such as: > # Project Reports > * Changes Report Plugin > * JavaDocs > * Maven Surefire Report > * Source Xref > I would like to have a way to change the names of these in the resulting > site... For example if I wanted "Maven Surefire Report" to be "Unit Test > Report", is that possible? > Why you ask? Two reasons... The first one is that I was trying to make a > Maven2-generated site look "close" to a Maven1-generated site and these > reports had different names between 1 and 2. The second is that there is a > lot of inconsistency between the names and if you're an anal perfectionist > (like I can be at times), you'd want more consistency. Just consider these > names below: > >> # Project Reports > >> * Changes Report Plugin > Says "plug-in"... only one that does... > >> * JavaDocs > >> * Maven Surefire Report > Says "report"... only one that does... redundant with "Reports" in "Project > Reports" > >> * Source Xref > I've also seen other report titles that are in lower case also, while these > above are in upper case. > Brett pointed out in an email the following: "This isn't easily possible at > the moment. The report names are defined > in the report code itself, and often internationalised. I think a good > general solution would be to allow you to feed overriding resources to the > site plugin, and to document the properties used to internationalise the > various pieces of text so that you can customise the site via that. Please > make a feature request for this feature." > So here you go with the feature request... -- 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: (MSITE-119) Use of position attribute causes publishedDate and version to disappear
[ http://jira.codehaus.org/browse/MSITE-119?page=all ] Brett Porter updated MSITE-119: --- Version: (was: 2.0) 2.0-beta-5 Fix Version: 2.0-beta-5 > Use of position attribute causes publishedDate and version to disappear > --- > > Key: MSITE-119 > URL: http://jira.codehaus.org/browse/MSITE-119 > Project: Maven 2.x Site Plugin > Type: Bug > Versions: 2.0-beta-5 > Environment: maven-site-plugin 2.0-SNAPSHOT built from svn > Reporter: Wendy Smoak > Priority: Minor > Fix For: 2.0-beta-5 > > > In site.xml, > > > > ... > results in neither the date nor the version appearing in the site. (The area > below the logo where they normally appear is blank.) > It works fine without the position attribute. > See: > http://www.nabble.com/Re%3A-m2-Adding-the-project-version-number-to-the-website-p4075502.html -- 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: (MPIR-44) No reports are generated when executing the plugins on CLI instead of "mvn site"
[ http://jira.codehaus.org/browse/MPIR-44?page=all ] Brett Porter updated MPIR-44: - Fix Version: 2.0 > No reports are generated when executing the plugins on CLI instead of "mvn > site" > > > Key: MPIR-44 > URL: http://jira.codehaus.org/browse/MPIR-44 > Project: Maven 2.x Project Info Reports Plugin > Type: Bug > Reporter: Edwin Punzalan > Assignee: Brett Porter > Priority: Critical > Fix For: 2.0 > > > Currently, doing project-info-reports: does not generate a report. -- 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: (MIDEA-50) StringIndexOutOfBoundsException when adding a resource to the pom
[ http://jira.codehaus.org/browse/MIDEA-50?page=all ] Brett Porter updated MIDEA-50: -- Fix Version: 2.0 > StringIndexOutOfBoundsException when adding a resource to the pom > - > > Key: MIDEA-50 > URL: http://jira.codehaus.org/browse/MIDEA-50 > Project: Maven 2.x Idea Plugin > Type: Bug > Reporter: Tim Kettler > Fix For: 2.0 > Attachments: testprj.zip > > > When running 'mvn idea:idea' on the attached test project the plugin fails > with the following exception: > [ERROR] FATAL ERROR > [INFO] > > [INFO] String index out of range: -1 > [INFO] > > [INFO] Trace > java.lang.StringIndexOutOfBoundsException: String index out of range: -1 > at java.lang.String.substring(String.java:1768) > at java.lang.String.substring(String.java:1735) > at org.apache.maven.plugin.idea.IdeaMojo.toRelative(IdeaMojo.java:395) > at > org.apache.maven.plugin.idea.IdeaMojo.getModuleFileUrl(IdeaMojo.java:409) > at > org.apache.maven.plugin.idea.IdeaMojo.addSourceFolder(IdeaMojo.java:382) > at > org.apache.maven.plugin.idea.IdeaMojo.rewriteModule(IdeaMojo.java:255) > at org.apache.maven.plugin.idea.IdeaMojo.execute(IdeaMojo.java:79) > at > org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:415) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:531) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:485) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:455) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:303) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:270) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:139) > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:322) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:249) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:585) > at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) > at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) > at > org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) > at org.codehaus.classworlds.Launcher.main(Launcher.java:375) > [INFO] > > [INFO] Total time: 1 second > [INFO] Finished at: Fri Apr 14 10:46:22 CEST 2006 > [INFO] Final Memory: 1M/4M > [INFO] > -- 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: (MIDEA-46) Macros in reactor projects aren't added to the IDEA project
[ http://jira.codehaus.org/browse/MIDEA-46?page=all ] Brett Porter updated MIDEA-46: -- Priority: Minor (was: Major) > Macros in reactor projects aren't added to the IDEA project > --- > > Key: MIDEA-46 > URL: http://jira.codehaus.org/browse/MIDEA-46 > Project: Maven 2.x Idea Plugin > Type: Bug > Reporter: Patrick Lightbody > Priority: Minor > > > This is a bug in a previous patch I supplied. Basically, the feature that > lets you define a Library source dir works great for single-project maven > builds, but for reactor builds there is a small bug. > Basically, there is a Set that is passed in to the IdeaModuleMojo that gets > populated with names of path mappings when any source dir contains the > pattern $foo$. That Set is then used to populate the ipr file like so: > > > > The problem with my implementation is multiple macro Sets are created, one > for each module that gets build. Except for the root maven project, that Set > is immediately discarded since the project file is only built once. I don't > have a patch for this because I don't have a good suggested fix. > On the plus side, it's not a critical issue. The only problem is that IDEA > won't prompt the user to provide path mappings for those macros. Instead, you > have to do them by hand. -- 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] Closed: (MIDEA-52) Add paramater idea:isJava5, and scope jdkName to idea:jdkName
[ http://jira.codehaus.org/browse/MIDEA-52?page=all ] Brett Porter closed MIDEA-52: - Assign To: Brett Porter Resolution: Won't Fix this is unnecessary. There is a jdkLevel parameter for setting this. > Add paramater idea:isJava5, and scope jdkName to idea:jdkName > - > > Key: MIDEA-52 > URL: http://jira.codehaus.org/browse/MIDEA-52 > Project: Maven 2.x Idea Plugin > Type: New Feature > Reporter: Danie Roux > Assignee: Brett Porter > Priority: Minor > Attachments: jdkName_and_java5.patch > > > IDEA does not default to a JDK 5 source level compiler. By using > -Didea:isJava5=true, the generated projects files will have the flag set, > with the patch attached. > I also scoped the jdkName parameter to idea:jdkName -- 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: (MIDEA-49) WebModuleProperties reactor modules: adding with method 5 not compatible with /WEB-INF/classes
[ http://jira.codehaus.org/browse/MIDEA-49?page=all ]
Brett Porter updated MIDEA-49:
--
Fix Version: 2.0
> WebModuleProperties reactor modules: adding with method 5 not compatible with
> /WEB-INF/classes
> --
>
> Key: MIDEA-49
> URL: http://jira.codehaus.org/browse/MIDEA-49
> Project: Maven 2.x Idea Plugin
> Type: Bug
> Versions: 2.0
> Reporter: Manfred Geiler
> Fix For: 2.0
> Attachments: MIDEA-49-1.patch, MIDEA-49-2.patch
>
>
> Currently reactor project modules are added with method "5":
> if ( linkModules && isReactorProject( artifact.getGroupId(),
> artifact.getArtifactId() ) )
> {
> containerElement.addAttribute( "type", "module" );
> containerElement.addAttribute( "name",
> artifact.getArtifactId() );
> Element methodAttribute = createElement( containerElement,
> "attribute" );
> methodAttribute.addAttribute( "name", "method" );
> methodAttribute.addAttribute( "value", "5" );
> <
> Element uriAttribute = createElement( containerElement,
> "attribute" );
> uriAttribute.addAttribute( "name", "URI" );
> uriAttribute.addAttribute( "value", "/WEB-INF/classes" );
> }
> Well, method "5" seems to be "JAR module output and copy file to" in IDEA.
> This method is not compatible with the given URI attribute, which should
> rather be something like "/WEB-INF/lib/foobar.jar".
> So, one way to fix this is to use method "1" ("Copy module output to")
> instead, then the used URI is correct. -->See patch 1.
> Another (more maven-style way) is to fix the URI to be "/WEB-INF/lib/" +
> artifact.getArtifactId() + "-" + artifact.getVersion() + ".jar". -->See patch
> 2.
> Regards,
> Manfred
--
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: (MCHANGELOG-36) Tests fail on build
[ http://jira.codehaus.org/browse/MCHANGELOG-36?page=all ] Brett Porter updated MCHANGELOG-36: --- Fix Version: 2.0 > Tests fail on build > --- > > Key: MCHANGELOG-36 > URL: http://jira.codehaus.org/browse/MCHANGELOG-36 > Project: Maven 2.x Changelog Plugin > Type: Bug > Versions: 2.0 > Environment: osx 10.4.6, java 1.4.2_06 > Reporter: Julian Wood > Fix For: 2.0 > Attachments: MCHANGELOG-36.patch > > > The date test assertions all fail: > junit.framework.AssertionFailedError: Test changelog 1 set 1 date/time > expected:<23963580> but was:< 23971500 > > at > org.apache.maven.changelog.ChangeLogTest.testReadFile(ChangeLogTest.java:50) > assertEquals( "Test changelog 1 set 1 date/time", 23963580L, > changeSet.getDate().getTime() ); > They just have the wrong date, and they are offset by the timezone ( 7 hours, > in my case - I'm MST -0700) -- 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: (MPMD-19) Update PMD plugin docs
[ http://jira.codehaus.org/browse/MPMD-19?page=all ] Brett Porter updated MPMD-19: - Fix Version: 2.0 Remaining Estimate: (was: 10 minutes) Original Estimate: (was: 10 minutes) > Update PMD plugin docs > -- > > Key: MPMD-19 > URL: http://jira.codehaus.org/browse/MPMD-19 > Project: Maven 2.x Pmd Plugin > Type: Improvement > Versions: 2.0-alpha-2 > Environment: docs > Reporter: Dave Sag > Fix For: 2.0 > > > The docs for the PMD plugin are lacking. > see http://maven.apache.org/plugins/maven-pmd-plugin/cpd-mojo.html > could you list html as the default in the default column of the format row, > and fill out the rest of the docs please -- 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: (MASSEMBLY-85) Parent POMs are not pulled down into the assembled repository
[ http://jira.codehaus.org/browse/MASSEMBLY-85?page=all ] Brett Porter updated MASSEMBLY-85: -- Fix Version: 2.1 > Parent POMs are not pulled down into the assembled repository > - > > Key: MASSEMBLY-85 > URL: http://jira.codehaus.org/browse/MASSEMBLY-85 > Project: Maven 2.x Assembly Plugin > Type: Bug > Versions: 2.1 > Reporter: Jason van Zyl > Fix For: 2.1 > > -- 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] Closed: (MASSEMBLY-78) Update docs and tag for the 2.0.1 release
[ http://jira.codehaus.org/browse/MASSEMBLY-78?page=all ] Brett Porter closed MASSEMBLY-78: - Assign To: Brett Porter Resolution: Won't Fix the tag wound up in http://svn.apache.org/repos/asf/maven/components/tags/ all this wll be straightened out for the 2.1 release that is coming up > Update docs and tag for the 2.0.1 release > - > > Key: MASSEMBLY-78 > URL: http://jira.codehaus.org/browse/MASSEMBLY-78 > Project: Maven 2.x Assembly Plugin > Type: Wish > Versions: 2.0.1 > Reporter: Wendy Smoak > Assignee: Brett Porter > Priority: Minor > > > Please update the website, the docs for maven-assembly-plugin were last > published in October 2005. > * http://maven.apache.org/plugins/maven-assembly-plugin/index.html > There was a 2.0.1 release in January according to ibiblio... > * > http://www.ibiblio.org/maven2/org/apache/maven/plugins/maven-assembly-plugin/2.0.1/ > ... but there is no tag for it: > * http://svn.apache.org/repos/asf/maven/plugins/tags/ > Thanks! -- 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-79) Unable to generate modello:xdoc for the assembly plugin
[ http://jira.codehaus.org/browse/MASSEMBLY-79?page=comments#action_64838 ] Brett Porter commented on MASSEMBLY-79: --- this is because there are now two, I think. We need to get that into a report format instead. > Unable to generate modello:xdoc for the assembly plugin > --- > > Key: MASSEMBLY-79 > URL: http://jira.codehaus.org/browse/MASSEMBLY-79 > Project: Maven 2.x Assembly Plugin > Type: Bug > Versions: 2.1 > Environment: Maven 2.0.4-SNAPSHOT, maven-assembly-plugin 2.1-SNAPSHOT > Reporter: Wendy Smoak > > > I found that 'mvn site' for maven-assembly-plugin does not generate > assembly.html > Brett suggested 'mvn modello:xdoc site' (and mentioned that he thought this > should be done automatically since maven 2.0.3.) > See: > http://www.nabble.com/Re%3A-Please-update-assembly-plugin-docs-p3813075.html > ~/svn/maven/plugins/maven-assembly-plugin > $ mvn modello:xdoc -e > + Error stacktraces are turned on. > [INFO] Scanning for projects... > [INFO] Searching repository for plugin with prefix: 'modello'. > [INFO] > - > --- > [INFO] Building Maven Assembly Plugin > [INFO]task-segment: [modello:xdoc] > [INFO] > - > --- > [INFO] Setting property: classpath.resource.loader.class => > 'org.codehaus.plexus > .velocity.ContextClassLoaderResourceLoader'. > [INFO] Setting property: velocimacro.messages.on => 'false'. > [INFO] Setting property: resource.loader => 'classpath'. > [INFO] Setting property: resource.manager.logwhenfound => 'false'. > [INFO] ** > [INFO] Starting Jakarta Velocity v1.4 > [INFO] RuntimeInstance initializing. > [INFO] Default Properties File: > org\apache\velocity\runtime\defaults\velocity.properties > [INFO] Default ResourceManager initializing. (class > org.apache.velocity.runtime.resource.ResourceManagerImpl) > [INFO] Resource Loader Instantiated: > org.codehaus.plexus.velocity.ContextClassLoaderResourceLoader > [INFO] ClasspathResourceLoader : initialization starting. > [INFO] ClasspathResourceLoader : initialization complete. > [INFO] ResourceCache : initialized. (class > org.apache.velocity.runtime.resource.ResourceCacheImpl) > [INFO] Default ResourceManager initialization complete. > [INFO] Loaded System Directive: org.apache.velocity.runtime.directive.Literal > [INFO] Loaded System Directive: org.apache.velocity.runtime.directive.Macro > [INFO] Loaded System Directive: org.apache.velocity.runtime.directive.Parse > [INFO] Loaded System Directive: org.apache.velocity.runtime.directive.Include > [INFO] Loaded System Directive: org.apache.velocity.runtime.directive.Foreach > [INFO] Created: 20 parsers. > [INFO] Velocimacro : initialization starting. > [INFO] Velocimacro : adding VMs from VM library template : > VM_global_library.vm > [ERROR] ResourceManager : unable to find resource 'VM_global_library.vm' in > any resource loader. > [INFO] Velocimacro : error using VM library template VM_global_library.vm : > org.apache.velocity.exception.ResourceNotFoundException: Unable to find > resource 'VM_global_library.vm' > [INFO] Velocimacro : VM library template macro registration complete. > [INFO] Velocimacro : allowInline = true : VMs can be defined inline in > templates > [INFO] Velocimacro : allowInlineToOverride = false : VMs defined inline may > NOT replace previous VM definitions > [INFO] Velocimacro : allowInlineLocal = false : VMs defined inline will be > global in scope if allowed. > [INFO] Velocimacro : initialization complete. > [INFO] Velocity successfully started. > [INFO] > > [ERROR] BUILD ERROR > [INFO] > > [INFO] One or more required plugin parameters are invalid/missing for > 'modello:x > doc' > [0] inside the definition for plugin: 'modello-maven-plugin'specify the > following: > > ... > VALUE > > -OR- > on the command line, specify: '-Dmodel=VALUE' > [1] inside the definition for plugin: 'modello-maven-plugin'specify the > following: > > ... > VALUE > > -OR- > on the command line, specify: '-Dversion=VALUE' > [INFO] > > [INFO] Trace > org.apache.maven.lifecycle.LifecycleExecutionException: Error configuring: > org.c > odehaus.modello:modello-maven-plugin. Reason: Invalid or missing parameters: > [Mo > jo parameter [name: 'model'; alias: 'null'], Mojo parameter [name: 'version'; > al > ias: 'null']] for mojo: > org.codehaus.modello:modello-maven-plugin:1.0-alpha-8:xdoc > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java
[jira] Updated: (MASSEMBLY-92) Assembly plugin fails with fatal error if a particular fileset directory does not exist
[ http://jira.codehaus.org/browse/MASSEMBLY-92?page=all ] Brett Porter updated MASSEMBLY-92: -- Fix Version: 2.1 > Assembly plugin fails with fatal error if a particular fileset directory does > not exist > --- > > Key: MASSEMBLY-92 > URL: http://jira.codehaus.org/browse/MASSEMBLY-92 > Project: Maven 2.x Assembly Plugin > Type: Bug > Reporter: Jason Chaffee > Priority: Critical > Fix For: 2.1 > > > It would be nice if it could output a warn message when a directory > configured in a fileset of the assembly descriptor xml does not exist and > continue to assemble what does exist. Here is a use case. Create an > assembly descriptor that will be reused for many products, some may have > certain directories and some may not...and sometimes it may only depend on > the release. Currently, there it is not possible to reuse the same > descriptor. I have to be cut and paste a very length assembly descriptor > about 10 times to make only one change directory name change in each file. > It seems unnecessary and it is a nightmare to maintain. Here is the error > output: > [INFO] > > [ERROR] FATAL ERROR > [INFO] > > [INFO] basedir C:\workspace\installs\installers\components\src\assembly does > not > exist > [INFO] > > [INFO] Trace > java.lang.IllegalStateException: basedir > C:\workspace\installs\installers\compon > ents\src\assembly does not exist > at > org.codehaus.plexus.util.DirectoryScanner.scan(DirectoryScanner.java: > 542) > at > org.apache.maven.plugin.assembly.AbstractAssemblyMojo.copySetReplacin > gLineEndings(AbstractAssemblyMojo.java:1353) > at > org.apache.maven.plugin.assembly.AbstractAssemblyMojo.processFileSets > (AbstractAssemblyMojo.java:1075) > at > org.apache.maven.plugin.assembly.AbstractAssemblyMojo.createArchive(A > bstractAssemblyMojo.java:356) > at > org.apache.maven.plugin.assembly.AbstractAssemblyMojo.createAssembly( > AbstractAssemblyMojo.java:285) > at > org.apache.maven.plugin.assembly.AbstractAssemblyMojo.execute(Abstrac > tAssemblyMojo.java:265) > at > org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPlugi > nManager.java:412) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(Defa > ultLifecycleExecutor.java:534) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLi > fecycle(DefaultLifecycleExecutor.java:475) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(Defau > ltLifecycleExecutor.java:454) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHan > dleFailures(DefaultLifecycleExecutor.java:306) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegmen > ts(DefaultLifecycleExecutor.java:273) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLi > fecycleExecutor.java:140) > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:322) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:256) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl. > java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces > sorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:585) > at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) > at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) > at > org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) > at org.codehaus.classworlds.Launcher.main(Launcher.java:375) -- 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] Closed: (MASSEMBLY-91) Currently the assembly plugin renames SNAPSHOT dependencies to a date stamp ex. api-authorisation-4.00-20060502.150651-20.jar
[ http://jira.codehaus.org/browse/MASSEMBLY-91?page=all ] Brett Porter closed MASSEMBLY-91: - Assign To: Brett Porter Resolution: Duplicate > Currently the assembly plugin renames SNAPSHOT dependencies to a date stamp > ex. api-authorisation-4.00-20060502.150651-20.jar > - > > Key: MASSEMBLY-91 > URL: http://jira.codehaus.org/browse/MASSEMBLY-91 > Project: Maven 2.x Assembly Plugin > Type: New Feature > Versions: 2.0.1 > Environment: Win XP, Java 1.5 > Reporter: Chris Stevenson > Assignee: Brett Porter > > > Currently the assembly plugin renames SNAPSHOT dependencies to a date stamp > ex. api-authorisation-4.00-20060502.150651-20.jar. Would it be possible to > offer a flag on the plugin so that this behaviour could be turned off and the > file could remain as api-authorisation-SNAPSHOT.jar? > The renaming of the files causes the files to become invalid when compiling > native or CSharp binaries inside of maven. > Thanks, > Chris Stevenson -- 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: (MSUREFIRE-104) classpath line is too long in fork mode
classpath line is too long in fork mode --- Key: MSUREFIRE-104 URL: http://jira.codehaus.org/browse/MSUREFIRE-104 Project: Maven 2.x Surefire Plugin Type: Bug Reporter: Brett Porter Assigned to: Brett Porter Fix For: 2.2 since we started putting the whole set of jars on the classpath, this has become a problem. It can probably be avoided. -- 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: (MPTEST-62) -Dmaven.test.failure.ignore=true has no effect on test failures in second test dir added by
[ http://jira.codehaus.org/browse/MPTEST-62?page=comments#action_64839 ]
Jeff Jensen commented on MPTEST-62:
---
Using maven.test.error.ignore=true with maven.test.failure.ignore=true
prevented the build failure. maven.test.error.ignore is an undocumented
property that Lukas Theussl shared with me (thanks Lukas!). The error property
is needed due to db connection problems and the failure property is needed
because of the dbunit test failing without the connection.
We need test problems to not fail the build for the nightly site gen -
regardless of what happens, we want the site generated for the team to use the
next day.
The salient point is it is coincidence that the failing test was in the
additional source directory.
> -Dmaven.test.failure.ignore=true has no effect on test failures in second
> test dir added by
> -
>
> Key: MPTEST-62
> URL: http://jira.codehaus.org/browse/MPTEST-62
> Project: maven-test-plugin
> Type: Bug
> Versions: 1.8
> Environment: Windows, Maven 1.1 beta 3, test plugin 1.8-snapshot
> Reporter: Jeff Jensen
>
>
> When adding a second source dir of tests in M1 by adding this to maven.xml:
>
>id="xxx.dbunit.src.dir"
> location="${basedir}/src/javatest/db"/>
>id="maven.test.compile.src.set"
> refid="xxx.dbunit.src.dir"/>
>
> if one of those tests fails, the build fails even with
> maven.test.failure.ignore=true.
--
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] Closed: (MNG-1876) exception coming from the embedder prohibits modifying the pom file.
[ http://jira.codehaus.org/browse/MNG-1876?page=all ] Milos Kleint closed MNG-1876: - Resolution: Fixed Fix Version: 2.1 was fixed in embedder refactor branch and is now in trunk. > exception coming from the embedder prohibits modifying the pom file. > - > > Key: MNG-1876 > URL: http://jira.codehaus.org/browse/MNG-1876 > Project: Maven 2 > Type: Bug > Components: Embedding > Versions: 2.0.1 > Environment: maven embedder 2.0.1, netbeans mevenide2 source snapshot. > Reporter: Milos Kleint > Assignee: Milos Kleint > Priority: Blocker > Fix For: 2.1 > Attachments: duplicates.patch, newversion.patch > > > the embedder is seriously broken when it has to reload the project > definition. When I open a project and the embedder reads it's structures for > teh first time, it's fine, but when the user changes the pom.xml, I need to > reload the data. reusing the same embedder instance, > I get this strange exception and the whole project/IDE is mainly unusable > because of reoccuring exceptions. That's a showstpper for any serious IDE > integration. > org.apache.maven.project.ProjectBuildingException: Duplicate project ID found > in /home/mkleint/src/mevenide/mevenide2/netbeans/libs/embedder/pom.xml > at > org.apache.maven.project.DefaultMavenProjectBuilder.buildFromSourceFile(DefaultMavenProjectBuilder.java:298) > at > org.apache.maven.project.DefaultMavenProjectBuilder.build(DefaultMavenProjectBuilder.java:274) > at > org.apache.maven.project.DefaultMavenProjectBuilder.buildWithDependencies(DefaultMavenProjectBuilder.java:169) > at > org.apache.maven.project.DefaultMavenProjectBuilder.buildWithDependencies(DefaultMavenProjectBuilder.java:159) > at > org.apache.maven.embedder.MavenEmbedder.readProjectWithDependencies(MavenEmbedder.java:307) > at > org.codehaus.mevenide.netbeans.NbMavenProject.getOriginalMavenProject(NbMavenProject.java:131) > -- 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: (MPMD-28) Support for multi-projects poms
Support for multi-projects poms --- Key: MPMD-28 URL: http://jira.codehaus.org/browse/MPMD-28 Project: Maven 2.x Pmd Plugin Type: Improvement Reporter: Torsten Curdt Attachments: multiproject.diff Added support for multi-projects so if you set "aggregate" to "true" the parent project will generate the report and the childs will not execute it anymore -- 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
