[jira] Commented: (CONTINUUM-629) disable icons instead of hiding them
[ http://jira.codehaus.org/browse/CONTINUUM-629?page=comments#action_61147 ] Brett Porter commented on CONTINUUM-629: this can be bumped if there isn't time > disable icons instead of hiding them > > > Key: CONTINUUM-629 > URL: http://jira.codehaus.org/browse/CONTINUUM-629 > Project: Continuum > Type: Improvement > Components: Web interface > Reporter: Brett Porter > Priority: Minor > Fix For: 1.0.3 > > > it would be nice to have greyscale versions of the icons in the 4 right hand > columns to use when the icons are disabled instead of removing them. -- 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-629) disable icons instead of hiding them
[ http://jira.codehaus.org/browse/CONTINUUM-629?page=comments#action_61150 ] Brett Porter commented on CONTINUUM-629: added some icons to svn to use for this > disable icons instead of hiding them > > > Key: CONTINUUM-629 > URL: http://jira.codehaus.org/browse/CONTINUUM-629 > Project: Continuum > Type: Improvement > Components: Web interface > Reporter: Brett Porter > Priority: Minor > Fix For: 1.0.3 > > > it would be nice to have greyscale versions of the icons in the 4 right hand > columns to use when the icons are disabled instead of removing them. -- 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-630) keep previous state in left most column on summary, even when build is queued
keep previous state in left most column on summary, even when build is queued - Key: CONTINUUM-630 URL: http://jira.codehaus.org/browse/CONTINUUM-630 Project: Continuum Type: Improvement Components: Web interface Reporter: Brett Porter Fix For: 1.0.3 -- 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-631) summary column misalignment
summary column misalignment --- Key: CONTINUUM-631 URL: http://jira.codehaus.org/browse/CONTINUUM-631 Project: Continuum Type: Bug Components: Web interface Reporter: Brett Porter Priority: Trivial Fix For: 1.0.3 the first two are left aligned, the others centred -- 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-632) additional images should be cleaned up
additional images should be cleaned up -- Key: CONTINUUM-632 URL: http://jira.codehaus.org/browse/CONTINUUM-632 Project: Continuum Type: Task Components: Web interface Reporter: Brett Porter Fix For: 1.0.3 there are a lot of old images in the webapp (eg collabnet ones, presumably from the tigris css). Can these be pruned back to just those in use? -- 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-78) forkMode=once or pertest does not work on windows
[ http://jira.codehaus.org/browse/MSUREFIRE-78?page=comments#action_61177 ] Brett Porter commented on MSUREFIRE-78: --- It requires 2.2-SNAPSHOT of the surefire plugin. Instructions were details on the [EMAIL PROTECTED] list if that's necessary. > forkMode=once or pertest does not work on windows > - > > Key: MSUREFIRE-78 > URL: http://jira.codehaus.org/browse/MSUREFIRE-78 > Project: Maven 2.x Surefire Plugin > Type: Bug > Environment: Win Xp > Reporter: Anita Kulshreshtha > Assignee: Brett Porter > > > I am building a simple HelloWorldTest.java. The test builds fine with 'mvn > test'. When I use 'mvn -DforkMode=once test', > I get BUILD ERROR. The surefire-reports directory is not created. One of the > 3 files left behind in the target directory is > surefire-classloader.properties. Its contents are : > #classpath entries > #Wed Mar 15 08:09:47 EST 2006 > childDelegation=true > classpath=D\:\\x\\geronimo\\build\\geronimo-m2\\modules\\kernel\\target\\test-classes\:D\:\\x\\geronimo\\build\\geronimo-m2\\modules\\kernel\\target\\classes\:C\:\\Documents > and > Settings\\User\\.m2\\repository\\junit\\junit\\3.8.1\\junit-3.8.1.jar\:C\:\\Documents > and > Settings\\User\\.m2\\repository\\org\\apache\\maven\\maven-plugin-api\\2.0\\maven-plugin-api-2.0.jar\:C\:\\Documents > and > Settings\\User\\.m2\\repository\\org\\apache\\maven\\surefire\\surefire\\1.5.3-SNAPSHOT\\surefire-1.5.3-SNAPSHOT.jar >It uses ':' as a path separator. This issue was discusses earlier in > Msurefire-76 and closed. -- 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: (SUREFIRE-25) surefire property droppings in fork mode
[ http://jira.codehaus.org/browse/SUREFIRE-25?page=all ] Brett Porter closed SUREFIRE-25: Assign To: Brett Porter Resolution: Fixed Fix Version: (was: 1.5.2) 2.0 I ended up fixing it in 2.0-SNAPSHOT > surefire property droppings in fork mode > > > Key: SUREFIRE-25 > URL: http://jira.codehaus.org/browse/SUREFIRE-25 > Project: surefire > Type: Bug > Versions: 1.5.2 > Reporter: Brett Porter > Assignee: Brett Porter > Fix For: 2.0 > > > when running surefire in fork mode (specifically, I'm using cobertura), the > surefire.properties, surefire-classloader.properties and sometimes a file > called "null" get left behind. I believe this might be when the tests fail > but haven't investigated. > I think these files should either be created in the tmpdir (preferred) or > target, and set to delete on exit rather than delete on success. -- 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-105) No line number for Doxia barfs makes using APT to write site documentation all but impossible
[ http://jira.codehaus.org/browse/MSITE-105?page=all ] Brett Porter updated MSITE-105: --- Fix Version: 2.0 > No line number for Doxia barfs makes using APT to write site documentation > all but impossible > - > > Key: MSITE-105 > URL: http://jira.codehaus.org/browse/MSITE-105 > Project: Maven 2.x Site Plugin > Type: New Feature > Versions: 2.0-beta-4 > Environment: all > Reporter: Greg Luck > Priority: Critical > Fix For: 2.0 > > > The following is a typical error message complaining about the lack of a > closing > tag. Also happens regularly with missing } tags when you are doing > links. Getting a message like that in a 1000 line document is impossible to > debug. > It should specify the line number. and ideally the column number. > [ERROR] Error rendering > /Users/gluck/work/ehcache/src/site/apt/documentation/logging.apt: missing '>' > org.codehaus.doxia.module.apt.AptParseException: missing '>' > at > org.codehaus.doxia.module.apt.AptParser.doTraverseText(AptParser.java:1011) > at > org.codehaus.doxia.module.apt.AptParser.access$500(AptParser.java:27) > at > org.codehaus.doxia.module.apt.AptParser$Block.traverseText(AptParser.java:1211) > at > org.codehaus.doxia.module.apt.AptParser$Block.traverseText(AptParser.java:1206) > at > org.codehaus.doxia.module.apt.AptParser$Paragraph.traverse(AptParser.java:1484) > at > org.codehaus.doxia.module.apt.AptParser.traverseSectionBlocks(AptParser.java:238) > at > org.codehaus.doxia.module.apt.AptParser.traverseBody(AptParser.java:148) > at org.codehaus.doxia.module.apt.AptParser.parse(AptParser.java:110) > at org.codehaus.doxia.DefaultDoxia.parse(DefaultDoxia.java:65) > at > org.codehaus.plexus.siterenderer.DefaultSiteRenderer.render(DefaultSiteRenderer.java:221) > at > org.codehaus.plexus.siterenderer.DefaultSiteRenderer.render(DefaultSiteRenderer.java:173) > at > org.codehaus.plexus.siterenderer.DefaultSiteRenderer.render(DefaultSiteRenderer.java:152) > at org.apache.maven.plugins.site.SiteMojo.execute(SiteMojo.java:340) > 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.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.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) > Try parsing the following snippet to get the above error: > +--+ >class="net.sf.ehcache.distribution.RMICacheManagerPeerProviderFactory" > properties="peerDiscovery=manual, > rmiUrls=//server2:40001/sampleCache11|//server2:40001/sampleCache12"/> > +--+ -- 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-80) systemProperties and NPE
[ http://jira.codehaus.org/browse/MSUREFIRE-80?page=all ]
Brett Porter updated MSUREFIRE-80:
--
Fix Version: 2.2
> systemProperties and NPE
>
>
> Key: MSUREFIRE-80
> URL: http://jira.codehaus.org/browse/MSUREFIRE-80
> Project: Maven 2.x Surefire Plugin
> Type: Bug
> Reporter: Jason Dillon
> Priority: Blocker
> Fix For: 2.2
>
>
> I've got in my pom:
> {code}
>
>
>
> {code}
> And then configured the surefire plugin to set a system property:
> {code}
>
> org.apache.maven.plugins
> maven-surefire-plugin
>
>
>
> ${jdbc.schema}
>
>
>
> {code}
> Which ends up resulting in:
> {noformat}
> [DEBUG] (f) systemProperties = {dbunit.connection.schema=null}
> ...
> [DEBUG] Trace
> java.lang.NullPointerException
> at java.util.Hashtable.put(Hashtable.java:393)
> at java.util.Properties.setProperty(Properties.java:102)
> at java.lang.System.setProperty(System.java:656)
> at
> org.apache.maven.test.SurefirePlugin.processSystemProperties(SurefirePlugin.java:408)
> at
> org.apache.maven.test.SurefirePlugin.execute(SurefirePlugin.java:335)
> 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: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)
> {noformat}
> If I put any value into the property, like
> {code}
>
> foo
>
> {code}
> Then it works as expected, no NPE and the property gets set.
> But I need to set the property to an empty string... why on earth does this
> get turned into a null?
--
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-79) Docs for systemProperties on website are wrong
[ http://jira.codehaus.org/browse/MSUREFIRE-79?page=all ]
Brett Porter updated MSUREFIRE-79:
--
Fix Version: 2.2
> Docs for systemProperties on website are wrong
> --
>
> Key: MSUREFIRE-79
> URL: http://jira.codehaus.org/browse/MSUREFIRE-79
> Project: Maven 2.x Surefire Plugin
> Type: Bug
> Reporter: Jason Dillon
> Priority: Critical
> Fix For: 2.2
>
>
> Site says:
> {code}
>
> ...
>
> ...
>
> org.apache.maven.plugins
> maven-surefire-plugin
>
>
>
> propertyName
> propertyValue
>
>
>
>
> ...
>
> ...
>
> {code}
> Should be:
> {code}
>
> ...
>
> ...
>
> org.apache.maven.plugins
> maven-surefire-plugin
>
>
> propertyValue
>
>
>
> ...
>
> ...
>
> {code}
--
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: (ARCHETYPE-27) create simpler site archetype
[ http://jira.codehaus.org/browse/ARCHETYPE-27?page=all ] Brett Porter closed ARCHETYPE-27: - Resolution: Fixed > create simpler site archetype > - > > Key: ARCHETYPE-27 > URL: http://jira.codehaus.org/browse/ARCHETYPE-27 > Project: Maven Archetype > Type: New Feature > Components: maven-archetype-plugin > Reporter: Brett Porter > Assignee: Brett Porter > > > the current archetpye sets up dummy content for each type, and a pair of > locales. This is more like an example than an archetype. I'd like a simple > one that just establishes the structure, a default APT document and site.xml -- 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: (ARCHETYPE-28) when creating a new module inside a directory with a pom that has , update
[ http://jira.codehaus.org/browse/ARCHETYPE-28?page=all ] Brett Porter closed ARCHETYPE-28: - Resolution: Fixed Fix Version: 0.7 > when creating a new module inside a directory with a pom that has , > update > - > > Key: ARCHETYPE-28 > URL: http://jira.codehaus.org/browse/ARCHETYPE-28 > Project: Maven Archetype > Type: New Feature > Components: maven-archetype-plugin > Reporter: Brett Porter > Assignee: Brett Porter > Fix For: 0.7 > > -- 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: (MWAR-23) war plugin doesn't copy dependencies with system scope
[ http://jira.codehaus.org/browse/MWAR-23?page=all ] Brett Porter updated MWAR-23: - Fix Version: (was: 2.0) I don't like either of those solutions :( We should tihnk about this some more. I'm not that happy about including system scope dependencies in the JAR based on what they were intended to be used for, so maybe Dan's use case should be addressed differently. > war plugin doesn't copy dependencies with system scope > -- > > Key: MWAR-23 > URL: http://jira.codehaus.org/browse/MWAR-23 > Project: Maven 2.x War Plugin > Type: Bug > Versions: 2.0 > Reporter: Dan Diephouse > Assignee: John Tolentino > Priority: Minor > > Time Spent: 3 hours >Remaining: 0 minutes > > I set about trying to include a jar that is not in the repository (either > local or remote) and I ended up using the element with a scope > of system for the dependency. Unfortunately the maven war plugin doesn't copy > the jar to the war. I see two solutions: > 1. Change the war plugin so it is included > 2. Provide some mechanism to include jars on the filesystem in arbitrary > places without a scope of system -- 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: (MWAR-12) Add resource filtering to war plugin
[ http://jira.codehaus.org/browse/MWAR-12?page=all ] Brett Porter updated MWAR-12: - Fix Version: 2.0 > Add resource filtering to war plugin > > > Key: MWAR-12 > URL: http://jira.codehaus.org/browse/MWAR-12 > Project: Maven 2.x War Plugin > Type: Improvement > Reporter: Mark Hobson > Assignee: Brett Porter > Fix For: 2.0 > Attachments: AbstractWarMojo.patch, MWAR-12.patch, ResourcesMojo.patch, > test.zip > > Original Estimate: 15 minutes > Remaining: 15 minutes > > I'd like to patch the war plugin to perform resource filtering as per the > resources plugin. This is a trivial patch but would duplicate the following > code from the resources plugin: > PropertyUtils > ReflectionProperties > ResourcesMojo.copyFile(File, File) > These look like handy util methods that could be incorporated into > plexus-utils - what do the developers think? > Also not sure how resource filtering will be affected by MNG-788. -- 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: (MPMD-20) PMD plugin should use latest PMD release
[ http://jira.codehaus.org/browse/MPMD-20?page=all ] Brett Porter closed MPMD-20: Resolution: Duplicate Fix Version: (was: 2.0-beta-1) dupe of MPMD-12. It's 3.5 in the next release. > PMD plugin should use latest PMD release > > > Key: MPMD-20 > URL: http://jira.codehaus.org/browse/MPMD-20 > Project: Maven 2.x Pmd Plugin > Type: Improvement > Reporter: Christopher G. Stach II > Assignee: Carlos Sanchez > > > Currently, the PMD plugin uses 3.0 release of PMD. This should be upgraded to > latest (3.4) release. -- 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: (MSUREFIRE-69) stop output to test-output directory
[ http://jira.codehaus.org/browse/MSUREFIRE-69?page=all ] Brett Porter closed MSUREFIRE-69: - Assign To: Brett Porter Resolution: Fixed > stop output to test-output directory > > > Key: MSUREFIRE-69 > URL: http://jira.codehaus.org/browse/MSUREFIRE-69 > Project: Maven 2.x Surefire Plugin > Type: Sub-task > Reporter: Brett Porter > Assignee: Brett Porter > Fix For: 2.2 > Attachments: pom.xml, surefire-patch.txt, surefire-patch.txt > > -- 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: (SUREFIRE-37) System properties not working during forking [surefire-testng branch, patch attached]
[ http://jira.codehaus.org/browse/SUREFIRE-37?page=all ] Brett Porter updated SUREFIRE-37: - Fix Version: 2.0 > System properties not working during forking [surefire-testng branch, patch > attached] > - > > Key: SUREFIRE-37 > URL: http://jira.codehaus.org/browse/SUREFIRE-37 > Project: surefire > Type: Bug > Reporter: Christian Schulte > Assignee: Jason van Zyl > Fix For: 2.0 > Attachments: systemproperties.patch > > > Hi, > just started to try the surefire-testng branch and the maven-surefire-testng > plugin. When setting system properties to the ForkConfiguration a new > Properties instance is created taking the properties as the defaults. When > this properties are written to disk using properties.store() the defaults are > not written to disk. The attached patch changes > ForkConfiguration.setSystemProperties( systemProperties) from > this.systemProperties = new Properties( systemProperties ) to > this.systemProperties = (Properties) systemProperties.clone() and makes > system properties work during forking. -- 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: (MSUREFIRE-67) Correct call to getMethod().getExtraOutput in reporter
[ http://jira.codehaus.org/browse/MSUREFIRE-67?page=all ] Brett Porter closed MSUREFIRE-67: - Assign To: Brett Porter Resolution: Fixed > Correct call to getMethod().getExtraOutput in reporter > -- > > Key: MSUREFIRE-67 > URL: http://jira.codehaus.org/browse/MSUREFIRE-67 > Project: Maven 2.x Surefire Plugin > Type: Sub-task > Reporter: Brett Porter > Assignee: Brett Porter > Fix For: 2.2 > > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MSITE-106) site:stage does not work
[ http://jira.codehaus.org/browse/MSITE-106?page=all ] Brett Porter closed MSITE-106: -- Assign To: Brett Porter Resolution: Won't Fix it's only available in 2.0-SNAPSHOT, in SVN. The doc seems to have snuck live again. I've documented when it is available. > site:stage does not work > > > Key: MSITE-106 > URL: http://jira.codehaus.org/browse/MSITE-106 > Project: Maven 2.x Site Plugin > Type: Bug > Versions: 2.0-beta-4 > Environment: http://maven.apache.org/plugins/maven-site-plugin/howto.html > Reporter: Archimedes Trajano > Assignee: Brett Porter > > > When doing mvn site:stage -D... according to > http://maven.apache.org/plugins/maven-site-plugin/howto.html > I get the following error > [ERROR] BUILD FAILURE > [INFO] -- > [INFO] Required goal not found: site:stage -- 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-2171) uninstantiable expressions fail, even if not required
uninstantiable expressions fail, even if not required
-
Key: MNG-2171
URL: http://jira.codehaus.org/browse/MNG-2171
Project: Maven 2
Type: Bug
Components: Plugins and Lifecycle
Versions: 2.0.3
Reporter: Brett Porter
I tihnk this is actually in plexus' configurator. Try these:
@parameter expression="${executedProject}"
or
@parameter default-value="${executedProject}"
In a mojo with no @execute tag.
The first gives:
[INFO]
[ERROR] BUILD ERROR
[INFO]
[INFO] Failed to configure plugin parameters for:
org.codehaus.mojo:cobertura-maven-plugin:2.0-SNAPSHOT
on the command line, specify: '-DexecutedProject=VALUE'
Cause: Class 'org.apache.maven.project.MavenProject' cannot be instantiated
[INFO]
[INFO] Trace
org.apache.maven.lifecycle.LifecycleExecutionException: Error getting reports
from the plugin 'org.codehaus.mojo:cobertura-maven-plugin'
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.getReports(DefaultLifecycleExecutor.java:694)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.getReports(DefaultLifecycleExecutor.java:637)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:512)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:475)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:454)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:306)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:273)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.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(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.PluginConfigurationException: Error
configuring: org.codehaus.mojo:cobertura-maven-plugin. Reason: Unable to parse
the created DOM for plugi
n configuration
at
org.apache.maven.plugin.DefaultPluginManager.populatePluginFields(DefaultPluginManager.java:1036)
at
org.apache.maven.plugin.DefaultPluginManager.getConfiguredMojo(DefaultPluginManager.java:576)
at
org.apache.maven.plugin.DefaultPluginManager.getReport(DefaultPluginManager.java:462)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.getReports(DefaultLifecycleExecutor.java:678)
... 18 more
Caused by:
org.codehaus.plexus.component.configurator.ComponentConfigurationException:
Class 'org.apache.maven.project.MavenProject' cannot be instantiated
at
org.codehaus.plexus.component.configurator.converters.AbstractConfigurationConverter.instantiateObject(AbstractConfigurationConverter.java:121)
at
org.codehaus.plexus.component.configurator.converters.composite.ObjectWithFieldsConverter.fromConfiguration(ObjectWithFieldsConverter.java:88)
at
org.codehaus.plexus.component.configurator.converters.ComponentValueSetter.configure(ComponentValueSetter.java:247)
at
org.codehaus.plexus.component.configurator.converters.composite.ObjectWithFieldsConverter.processConfiguration(ObjectWithFieldsConverter.java:137)
at
org.codehaus.plexus.component.configurator.BasicComponentConfigurator.configureComponent(BasicComponentConfigurator.java:56)
at
org.apache.maven.plugin.DefaultPluginManager.populatePluginFields(DefaultPluginManager.java:1030)
... 21 more
Caused by: java.lang.InstantiationException:
org.apache.maven.project.MavenProject
at java.lang.Class.newInstance0(Class.java:335)
at java.lang.Class.newInstance(Class.java:303)
at
org.codehaus.plexus.component.configurator.converters.AbstractConfigurationConverter.instantiateObject(AbstractConfigurationConverter.java:111)
... 26 more
The second instead evaluat
[jira] Closed: (MJAVADOC-33) Provide new javadoc:aggregate goal to perform javadoc operation on project and subprojects.
[ http://jira.codehaus.org/browse/MJAVADOC-33?page=all ] Brett Porter closed MJAVADOC-33: Resolution: Fixed > Provide new javadoc:aggregate goal to perform javadoc operation on project > and subprojects. > --- > > Key: MJAVADOC-33 > URL: http://jira.codehaus.org/browse/MJAVADOC-33 > Project: Maven 2.x Javadoc Plugin > Type: Improvement > Reporter: John Allen > Assignee: Brett Porter > Priority: Minor > Fix For: 2.0-beta-4 > > Original Estimate: 4 hours > Remaining: 4 hours > > Provide new javadoc:aggregate goal to perform javadoc operation on a project > and its subprojects, idea being that aggregate pulls together the classpath > and sourcepath for all the project and subprojects and then churns out normal > javadoc. > i.e. projects:- > /root/ > /root/a/src/... > /root/a/b/src/... > /root/a/b/c/src/... > /root/a/d/src/... > /root/a/e/src/... > @ /root/a-> m2 javadoc:aggregate > generates javadoc in /root/a/target/javadoc for src contained within projects > a, b, c, d, and e. > Note, javadoc does not currently provide support for this kind of aggregation > and so people have traditionally written their own specialised tasks/scripts > (in ant land say) to handle it. sun do refer to the idea of an incremental > build in their FAQ which they say they are considering for the future (fat > chance) (http://java.sun.com/j2se/javadoc/faq/#incrementalbuild) but that is > about generating aggregate docs from already existing javadocs. -- 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] Reopened: (MSUREFIRE-59) JUnitBattery dies when TestSuite has an anonymous inner class
[ http://jira.codehaus.org/browse/MSUREFIRE-59?page=all ]
Brett Porter reopened MSUREFIRE-59:
---
> JUnitBattery dies when TestSuite has an anonymous inner class
> -
>
> Key: MSUREFIRE-59
> URL: http://jira.codehaus.org/browse/MSUREFIRE-59
> Project: Maven 2.x Surefire Plugin
> Type: Bug
> Versions: 2.1.2
> Reporter: Mike Perham
> Assignee: Brett Porter
> Fix For: 2.1.3
> Attachments: SimpleTestSuite.java, SurefireTest.java
>
>
> I have this method in my test suite:
> {code}
> private static File[] getWSDLFiles() {
> URL directoryURL =
> WSDLImportTestSuite.class.getResource("/com/webify/wsf/studio/core/wsdl/wsdls");
> if (directoryURL != null) {
> File directory = new File(directoryURL.getPath());
> FilenameFilter filter = new FilenameFilter() {
> public boolean accept(File dir, String name) {
> return name.endsWith(".wsdl");
> }
> };
> return directory.listFiles(filter);
> }
> else {
> return null;
> }
> }
> {code}
> And surefire fails with this exception:
> java.lang.NoSuchMethodException:
> com.webify.wsf.studio.core.wsdl.WSDLImportTestSuite$1.()
> at java.lang.Class.getConstructor0(Class.java:1937)
> at java.lang.Class.getConstructor(Class.java:1027)
> at
> org.apache.maven.surefire.battery.JUnitBattery.getTestConstructor(JUnitBattery.java:307)
> at
> org.apache.maven.surefire.battery.JUnitBattery.processTestClass(JUnitBattery.java:150)
> at
> org.apache.maven.surefire.battery.JUnitBattery.(JUnitBattery.java:81)
> at
> org.apache.maven.surefire.SurefireUtils.instantiateBattery(SurefireUtils.java:63)
> at
> org.apache.maven.surefire.Surefire.instantiateBatteries(Surefire.java:262)
> at org.apache.maven.surefire.Surefire.run(Surefire.java:140)
> at org.apache.maven.surefire.Surefire.run(Surefire.java:87)
--
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: (MDEPLOY-27) Improper build number after deploying a snapshot of maven-javadoc-plugin
[ http://jira.codehaus.org/browse/MDEPLOY-27?page=comments#action_61819 ] Brett Porter commented on MDEPLOY-27: - are you using the latest SVN version? Pretty sure this is fixed... > Improper build number after deploying a snapshot of maven-javadoc-plugin > > > Key: MDEPLOY-27 > URL: http://jira.codehaus.org/browse/MDEPLOY-27 > Project: Maven 2.x Deploy Plugin > Type: Bug > Versions: 2.2 > Environment: Windows XP > JDK 1.5.0_06 > Cygwin environment installed > Reporter: Thorsten Heit > Priority: Minor > > > I'm trying to use the beta-4 snapshot of the maven-javadoc-plugin and wanted > to deploy it on my local maven proxy. The plugin is deployed via: > $ mvn compile jar:jar > (lots of messages) > $ cd target > $ mvn deploy:deploy-file -DrepositoryId=bender > -Durl=file://H:/maven-proxy/target/repo-local -DpomFile=exported-pom.xml > -Dfile=maven-javadoc-plugin-2.0-beta-4-SNAPSHOT.jar > (lots of messages) > The plugin jar gets copied to the proxy, and so far everything seems to be > fine. In another project, I added the following lines to my pom.xml: > > > > org.apache.maven.plugins > maven-javadoc-plugin > 2.0-beta-4-SNAPSHOT > > created > 256m > > > ... > > > Unfortunately the plugin cannot be downloaded from my proxy: > $ mvn clean > [INFO] Scanning for projects... > [INFO] > > [INFO] Building base Repository > [INFO]task-segment: [clean] > [INFO] > > Downloading: > http://bender:/repository/org/apache/maven/plugins/maven-javadoc-plugin/2.0-beta-4-SNAPSHOT/maven-javadoc-plugin-2.0-beta-4-20060322.180042-2.jar > [INFO] > > [ERROR] BUILD ERROR > [INFO] > > [INFO] Failed to resolve artifact. > GroupId: org.apache.maven.plugins > ArtifactId: maven-javadoc-plugin > Version: 2.0-beta-4-20060322.180042-2 > Reason: Unable to locate resource in repository > org.apache.maven.plugins:maven-javadoc-plugin:maven-plugin:2.0-beta-4-20060322.180042-2 > from the specified remote repositories: > central (http://repo1.maven.org/maven2), > bender (http://bender:/repository), > snapshots-codehaus-org (http://snapshots.maven.codehaus.org/maven2) > which is strange because I just deployed it. I looked into the proxy > directories and wondered that the files are named differently: > * maven-javadoc-plugin-2.0-beta-4-20060322.180042-1.jar > * maven-javadoc-plugin-2.0-beta-4-20060322.180042-1.jar.md5 > * maven-javadoc-plugin-2.0-beta-4-20060322.180042-1.jar.sha1 > * maven-javadoc-plugin-2.0-beta-4-20060322.180042-2.pom > * maven-javadoc-plugin-2.0-beta-4-20060322.180042-2.pom.md5 > * maven-javadoc-plugin-2.0-beta-4-20060322.180042-2.pom.sha1 > When I manually rename the -1.jar* files to -2.jar* the plugin is > downloadable, and "mvn clean" above will work... > To check the above behaviour I removed the deployed files/directories from my > maven proxy and redeployed the javadoc plugin: > $ mvn -X deploy:deploy-file -DrepositoryId=bender > -Durl=file://H:/maven-proxy/target/repo-local -DpomFile=exported-pom.xml > -Dfile=maven-javadoc-plugin-2.0-beta-4-SNAPSHOT.jar > + Error stacktraces are turned on. > [DEBUG] Building Maven user-level plugin registry from: 'C:\Dokumente und > Einstellungen\heit\.m2\plugin-registry.xml' > [DEBUG] Building Maven global-level plugin registry from: > 'c:\Programme\Apache\maven-2.0.2\conf\plugin-registry.xml' > [INFO] Scanning for projects... > [INFO] Searching repository for plugin with prefix: 'deploy'. > [DEBUG] maven-deploy-plugin: resolved to version 2.2 from repository central > [DEBUG] Retrieving parent-POM from the repository for project: > null:maven-deploy-plugin:maven-plugin:2.2 > [INFO] > > [INFO] Building Maven Default Project > [INFO]task-segment: [deploy:deploy-file] (aggregator-style) > [INFO] > > [DEBUG] org.apache.maven.plugins:maven-deploy-plugin:maven-plugin:2.2 > (selected for runtime) > [DEBUG] Retrieving parent-POM from the repository for project: > null:maven-project:jar:2.0.1 > [DEBUG] org.apache.maven:maven-project:jar:2.0.1 (selected for runtime) > [DEBUG] Retrieving parent-POM from the repository for project: > org.apache.maven:maven-model:jar:2.0.1 > [DEBUG] org.apache.maven:maven-model:jar:2.0.1 (selected for runtime) > [DEBUG] Retrieving parent-POM from the repository for project: > null:plexus-utils:jar:1.0.5 > [DEBUG] org.codehaus.ple
[jira] Closed: (MDEPLOY-27) Improper build number after deploying a snapshot of maven-javadoc-plugin
[ http://jira.codehaus.org/browse/MDEPLOY-27?page=all ] Brett Porter closed MDEPLOY-27: --- Assign To: Brett Porter Resolution: Fixed Fix Version: 2.3 I see you were using 2.2 > Improper build number after deploying a snapshot of maven-javadoc-plugin > > > Key: MDEPLOY-27 > URL: http://jira.codehaus.org/browse/MDEPLOY-27 > Project: Maven 2.x Deploy Plugin > Type: Bug > Versions: 2.2 > Environment: Windows XP > JDK 1.5.0_06 > Cygwin environment installed > Reporter: Thorsten Heit > Assignee: Brett Porter > Priority: Minor > Fix For: 2.3 > > > I'm trying to use the beta-4 snapshot of the maven-javadoc-plugin and wanted > to deploy it on my local maven proxy. The plugin is deployed via: > $ mvn compile jar:jar > (lots of messages) > $ cd target > $ mvn deploy:deploy-file -DrepositoryId=bender > -Durl=file://H:/maven-proxy/target/repo-local -DpomFile=exported-pom.xml > -Dfile=maven-javadoc-plugin-2.0-beta-4-SNAPSHOT.jar > (lots of messages) > The plugin jar gets copied to the proxy, and so far everything seems to be > fine. In another project, I added the following lines to my pom.xml: > > > > org.apache.maven.plugins > maven-javadoc-plugin > 2.0-beta-4-SNAPSHOT > > created > 256m > > > ... > > > Unfortunately the plugin cannot be downloaded from my proxy: > $ mvn clean > [INFO] Scanning for projects... > [INFO] > > [INFO] Building base Repository > [INFO]task-segment: [clean] > [INFO] > > Downloading: > http://bender:/repository/org/apache/maven/plugins/maven-javadoc-plugin/2.0-beta-4-SNAPSHOT/maven-javadoc-plugin-2.0-beta-4-20060322.180042-2.jar > [INFO] > > [ERROR] BUILD ERROR > [INFO] > > [INFO] Failed to resolve artifact. > GroupId: org.apache.maven.plugins > ArtifactId: maven-javadoc-plugin > Version: 2.0-beta-4-20060322.180042-2 > Reason: Unable to locate resource in repository > org.apache.maven.plugins:maven-javadoc-plugin:maven-plugin:2.0-beta-4-20060322.180042-2 > from the specified remote repositories: > central (http://repo1.maven.org/maven2), > bender (http://bender:/repository), > snapshots-codehaus-org (http://snapshots.maven.codehaus.org/maven2) > which is strange because I just deployed it. I looked into the proxy > directories and wondered that the files are named differently: > * maven-javadoc-plugin-2.0-beta-4-20060322.180042-1.jar > * maven-javadoc-plugin-2.0-beta-4-20060322.180042-1.jar.md5 > * maven-javadoc-plugin-2.0-beta-4-20060322.180042-1.jar.sha1 > * maven-javadoc-plugin-2.0-beta-4-20060322.180042-2.pom > * maven-javadoc-plugin-2.0-beta-4-20060322.180042-2.pom.md5 > * maven-javadoc-plugin-2.0-beta-4-20060322.180042-2.pom.sha1 > When I manually rename the -1.jar* files to -2.jar* the plugin is > downloadable, and "mvn clean" above will work... > To check the above behaviour I removed the deployed files/directories from my > maven proxy and redeployed the javadoc plugin: > $ mvn -X deploy:deploy-file -DrepositoryId=bender > -Durl=file://H:/maven-proxy/target/repo-local -DpomFile=exported-pom.xml > -Dfile=maven-javadoc-plugin-2.0-beta-4-SNAPSHOT.jar > + Error stacktraces are turned on. > [DEBUG] Building Maven user-level plugin registry from: 'C:\Dokumente und > Einstellungen\heit\.m2\plugin-registry.xml' > [DEBUG] Building Maven global-level plugin registry from: > 'c:\Programme\Apache\maven-2.0.2\conf\plugin-registry.xml' > [INFO] Scanning for projects... > [INFO] Searching repository for plugin with prefix: 'deploy'. > [DEBUG] maven-deploy-plugin: resolved to version 2.2 from repository central > [DEBUG] Retrieving parent-POM from the repository for project: > null:maven-deploy-plugin:maven-plugin:2.2 > [INFO] > > [INFO] Building Maven Default Project > [INFO]task-segment: [deploy:deploy-file] (aggregator-style) > [INFO] > > [DEBUG] org.apache.maven.plugins:maven-deploy-plugin:maven-plugin:2.2 > (selected for runtime) > [DEBUG] Retrieving parent-POM from the repository for project: > null:maven-project:jar:2.0.1 > [DEBUG] org.apache.maven:maven-project:jar:2.0.1 (selected for runtime) > [DEBUG] Retrieving parent-POM from the repository for project: > org.apache.maven:maven-model:jar:2.0.1 > [DEBUG] org.apache.maven:maven-model:jar:2.0.1 (selected for runtime) > [DEBUG] Retrieving parent-POM from the repository for project: > nul
[jira] Closed: (MNG-32) Plugin test harness
[ http://jira.codehaus.org/browse/MNG-32?page=all ] Brett Porter closed MNG-32: --- Resolution: Fixed imported to sandbox > Plugin test harness > --- > > Key: MNG-32 > URL: http://jira.codehaus.org/browse/MNG-32 > Project: Maven 2 > Type: Task > Components: Sandbox, Plugin API, Design, Patterns & Best Practices > Reporter: Jason van Zyl > Assignee: Jesse McConnell > Priority: Blocker > Attachments: compiler-harness.patch, jar-harness.patch, > maven-compiler-plugin.jar, maven-jar-plugin.jar, maven-project.patch > > -- 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: (MCHECKSTYLE-35) move rules summary to the bottom
[ http://jira.codehaus.org/browse/MCHECKSTYLE-35?page=all ] Brett Porter updated MCHECKSTYLE-35: Fix Version: (was: 2.0) 2.1 > move rules summary to the bottom > > > Key: MCHECKSTYLE-35 > URL: http://jira.codehaus.org/browse/MCHECKSTYLE-35 > Project: Maven 2.x Checkstyle Plugin > Type: Improvement > Reporter: Brett Porter > 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] Updated: (MCHECKSTYLE-34) automatically detect linkXref and default to on
[ http://jira.codehaus.org/browse/MCHECKSTYLE-34?page=all ] Brett Porter updated MCHECKSTYLE-34: Fix Version: (was: 2.0) 2.1 > automatically detect linkXref and default to on > --- > > Key: MCHECKSTYLE-34 > URL: http://jira.codehaus.org/browse/MCHECKSTYLE-34 > Project: Maven 2.x Checkstyle Plugin > Type: Improvement > Reporter: Brett Porter > 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] Updated: (MCHECKSTYLE-31) Multi-module reports do not support custom classpath configurations
[ http://jira.codehaus.org/browse/MCHECKSTYLE-31?page=all ]
Brett Porter updated MCHECKSTYLE-31:
Fix Version: (was: 2.0)
2.1
> Multi-module reports do not support custom classpath configurations
> ---
>
> Key: MCHECKSTYLE-31
> URL: http://jira.codehaus.org/browse/MCHECKSTYLE-31
> Project: Maven 2.x Checkstyle Plugin
> Type: Bug
> Versions: 2.0-beta-1
> Reporter: Mike Perham
> Assignee: fabrizio giustina
> Priority: Critical
> Fix For: 2.1
>
>
> The latest multi-module tip shows the following:
> {noformat}
>
>
>
> org.apache.maven.plugins
> maven-checkstyle-plugin
>
> whizbang/checkstyle.xml
> whizbang/LICENSE.txt
>
>
>
> com.example.whizbang
> build-tools
> 1.0
>
>
>
>
>
> {noformat}
> This is invalid according to the latest 2.0.2 POM schema. is
> not supported in reporting plugins.
> So it seems impossible to provide a custom config in a multi-module build
> without using a network URL as we cannot use File or classpath.
--
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: (MCHECKSTYLE-30) checkstyle ignores cacheFile
[ http://jira.codehaus.org/browse/MCHECKSTYLE-30?page=all ] Brett Porter updated MCHECKSTYLE-30: Fix Version: 2.0.1 > checkstyle ignores cacheFile > > > Key: MCHECKSTYLE-30 > URL: http://jira.codehaus.org/browse/MCHECKSTYLE-30 > Project: Maven 2.x Checkstyle Plugin > Type: Bug > Reporter: Brian Fox > Fix For: 2.0.1 > > > I'm using a version of checkstyle from svn so I can get custom configuration. > The cacheFile seems to be ignored. I tried setting it even though it has a > default value, but I nver see the checkstyle-cachefile get created. -- 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: (MCHECKSTYLE-27) checktyle:check does not use custom checkstyle xml files when used in a multiproject mode with a build-tools project passed as a plugin dependency
[ http://jira.codehaus.org/browse/MCHECKSTYLE-27?page=all ]
Brett Porter updated MCHECKSTYLE-27:
Fix Version: 2.0.1
> checktyle:check does not use custom checkstyle xml files when used in a
> multiproject mode with a build-tools project passed as a plugin dependency
> --
>
> Key: MCHECKSTYLE-27
> URL: http://jira.codehaus.org/browse/MCHECKSTYLE-27
> Project: Maven 2.x Checkstyle Plugin
> Type: Bug
> Reporter: Vincent Massol
> Fix For: 2.0.1
>
>
> Here's the config I have:
> {code:xml}
>
>
>
> maven-checkstyle-plugin
>
>
> org.codehaus.cargo
> cargo-build-tools
> 0.8-SNAPSHOT
>
>
>
>
>
> build-tools/checkstyle.xml
> build-tools/checkstyle.license
>
> build-tools/checkstyle-suppressions.xml
>
>
> check
>
>
>
>
>
>
> {code}
> When i run the project I get lots of checkstyle errors due to the fact that
> checkstyle is using the default rules and not my projcect's.
> Note that I have created a build-tools project as defined in tips.apt.
--
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: (MCHECKSTYLE-34) automatically detect linkXref and default to on
[ http://jira.codehaus.org/browse/MCHECKSTYLE-34?page=all ] Brett Porter updated MCHECKSTYLE-34: Fix Version: (was: 2.1) 2.0.1 > automatically detect linkXref and default to on > --- > > Key: MCHECKSTYLE-34 > URL: http://jira.codehaus.org/browse/MCHECKSTYLE-34 > Project: Maven 2.x Checkstyle Plugin > Type: Improvement > Reporter: Brett Porter > Fix For: 2.0.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] Updated: (MCHECKSTYLE-33) Patch provides ability to control whether check MOJO violations cause build failure (inline with pmd:check)
[ http://jira.codehaus.org/browse/MCHECKSTYLE-33?page=all ] Brett Porter updated MCHECKSTYLE-33: Fix Version: 2.0.1 > Patch provides ability to control whether check MOJO violations cause build > failure (inline with pmd:check) > --- > > Key: MCHECKSTYLE-33 > URL: http://jira.codehaus.org/browse/MCHECKSTYLE-33 > Project: Maven 2.x Checkstyle Plugin > Type: Improvement > Reporter: John Allen > Fix For: 2.0.1 > Attachments: CheckstyleViolationCheckMojo.diff > > > Example: > mvn -Dcheckstyle.failOnViolation=false checkstyle:check > Use case: > In the same way that test failures can be prevented from failing the buyild > via a CLI arg, builds that enforce governance standards and policies such as > no checkstyle violations, no PMD violations, at least XX% of test coverage, > no javadoc warnings are more useful if they can also be deactivated via a CLI > arg. > Note, my previous PMD:check mojo patch already provides support for this > violation override. -- 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: (MPMD-22) PMD plugin should accept dependency entries
[ http://jira.codehaus.org/browse/MPMD-22?page=comments#action_61840 ]
Brett Porter commented on MPMD-22:
--
one workaround to try is putting the dependency on the site plugin in the build
section.
> PMD plugin should accept dependency entries
> ---
>
> Key: MPMD-22
> URL: http://jira.codehaus.org/browse/MPMD-22
> Project: Maven 2.x Pmd Plugin
> Type: New Feature
> Reporter: Subhash Chandran
>
>
> As described here:
> http://maven.apache.org/plugins/maven-pmd-plugin/howto.html
> The PMD plugin supports configuration of custom ruleset XML files. But in our
> organization, we have written custom ruleset XMLs that refer Java classes
> (our PMD extension dependencies). The configuration of the PMD plugin should
> allow these dependencies to be specified.
> Since we do not have this feature in the current release, we at our
> organization are forced to maintain a fork of the PMD plugin with the
> necessary dependencies added.
> A suggested format:
>
>
> /rulesets/basic.xml
> /rulesets/controversial.xml
> d:\rulesets\strings.xml
> http://localhost/design.xml
>
> {color:red}
>
> junit
> junit
> 4.0
> test
>
> {color}
> xml
> true
> utf-8
> 100
>
--
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: (MPMD-22) PMD plugin should accept dependency entries
[ http://jira.codehaus.org/browse/MPMD-22?page=comments#action_61839 ]
Brett Porter commented on MPMD-22:
--
It's a known issue that doesn't. The bug is in core, and checkstyle
has a similar issue.
> PMD plugin should accept dependency entries
> ---
>
> Key: MPMD-22
> URL: http://jira.codehaus.org/browse/MPMD-22
> Project: Maven 2.x Pmd Plugin
> Type: New Feature
> Reporter: Subhash Chandran
>
>
> As described here:
> http://maven.apache.org/plugins/maven-pmd-plugin/howto.html
> The PMD plugin supports configuration of custom ruleset XML files. But in our
> organization, we have written custom ruleset XMLs that refer Java classes
> (our PMD extension dependencies). The configuration of the PMD plugin should
> allow these dependencies to be specified.
> Since we do not have this feature in the current release, we at our
> organization are forced to maintain a fork of the PMD plugin with the
> necessary dependencies added.
> A suggested format:
>
>
> /rulesets/basic.xml
> /rulesets/controversial.xml
> d:\rulesets\strings.xml
> http://localhost/design.xml
>
> {color:red}
>
> junit
> junit
> 4.0
> test
>
> {color}
> xml
> true
> utf-8
> 100
>
--
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: (MSUREFIREREP-12) Links (anchors) are not well formed in html reports
[ http://jira.codehaus.org/browse/MSUREFIREREP-12?page=all ] Brett Porter closed MSUREFIREREP-12: Assign To: Brett Porter Resolution: Duplicate Fix Version: (was: 2.0) this purely relies on the version of the site plugin being used. works in SVN. > Links (anchors) are not well formed in html reports > --- > > Key: MSUREFIREREP-12 > URL: http://jira.codehaus.org/browse/MSUREFIREREP-12 > Project: Maven 2.x Surefire report Plugin > Type: Bug > Environment: all > Reporter: Olivier Lamy > Assignee: Brett Porter > > > Anchor are not well formed. > Relative to http://jira.codehaus.org/browse/MNG-2099 > Olivier -- 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-50) Allow configuration for whether images and css are copied to destDir
[ http://jira.codehaus.org/browse/MJAVADOC-50?page=all ] Brett Porter updated MJAVADOC-50: - Version: 2.0-beta-3 Fix Version: (was: 2.0-beta-4) > Allow configuration for whether images and css are copied to destDir > > > Key: MJAVADOC-50 > URL: http://jira.codehaus.org/browse/MJAVADOC-50 > Project: Maven 2.x Javadoc Plugin > Type: New Feature > Versions: 2.0-beta-3 > Reporter: Wendy Smoak > Assignee: Maria Odea Ching > Priority: Minor > > Original Estimate: 3 hours > Remaining: 3 hours > > Not all doclets produce HTML output, so copying the css and images should be > configurable. For example, the UMLGraph doclet produces ".dot" files which > can be transformed into images. > In addition, the plugin behaves differently when configured in the > and sections: > * When run with 'mvn javadoc:javadoc' from the section, > stylesheet.css, the 'images' directory and the 'css' directory are copied to > . > * When run with 'mvn site' from the section, only stylesheet.css > is copied in (and is ignored, see MJAVADOC-47). -- 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-2176) Properties interpolation in settings.xml
[ http://jira.codehaus.org/browse/MNG-2176?page=all ]
Brett Porter closed MNG-2176:
-
Assign To: Brett Porter
Resolution: Duplicate
> Properties interpolation in settings.xml
>
>
> Key: MNG-2176
> URL: http://jira.codehaus.org/browse/MNG-2176
> Project: Maven 2
> Type: Bug
> Components: Inheritence and Interpolation
> Versions: 2.0.2
> Reporter: nicolas de loof
> Assignee: Brett Porter
> Priority: Minor
>
>
> I've set my settings.xml to set repository in M2_HOME :
> ${maven.home}/repository
>
> The property ${maven.home} is not interpollated and my repository is created
> on root filesystem.
--
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: (MCLEAN-8) conversion of the existing unit tests to use the AbstractMojoTestCase from the plugin testing harness
[ http://jira.codehaus.org/browse/MCLEAN-8?page=comments#action_61871 ] Brett Porter commented on MCLEAN-8: --- can you please fix this so that it works in hte reactor first. Easy way to check, from parent directory: mvn -f maven-clean-plugin/pom.xml clean test > conversion of the existing unit tests to use the AbstractMojoTestCase from > the plugin testing harness > - > > Key: MCLEAN-8 > URL: http://jira.codehaus.org/browse/MCLEAN-8 > Project: Maven 2.x Clean Plugin > Type: Improvement > Reporter: Jesse McConnell > Attachments: maven-clean-harness.patch > > > This is the patch for that I am hoping are best practices in using the plugin > testing harness as mentioned in MNG-32 -- 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: (MCLEAN-7) empty removes the directory of the fileset
[ http://jira.codehaus.org/browse/MCLEAN-7?page=comments#action_61873 ]
Brett Porter commented on MCLEAN-7:
---
I think we should scratch this issue. To me ==
== null, that is, exclude nothing.
The bug should be filed against plexus-utils / file management API (if
appropriate). Perhaps we should rebase DirectoryScanner against the latest from
Ant to see if such bugs have been fixed. Anyway, not a big issue.
> empty removes the directory of the fileset
> --
>
> Key: MCLEAN-7
> URL: http://jira.codehaus.org/browse/MCLEAN-7
> Project: Maven 2.x Clean Plugin
> Type: Bug
> Reporter: Jesse McConnell
>
>
> I was shifting the unit tests over to use the plugin harness and noticed a
> test case failing.
> if you look at the test case for the fileset test case, the second fileset
> test has an addFileset(dir, "**", "");
> this unit test works fine, but when you try and actually do this behavior
> using the plugin configuration it brings up an error
>
>
> ${basedir}/target/test-classes/fileset-clean-test/buildOutputDirectory
>
> **
>
>
> that would be the plugin configuration of the same deal.
> ( results in a stack trace)
> In this case the directory is getting deleted when configured. You can
> exhibit the same behavior with the existing test case if you try and pass
> null into the addFileset signature...
> this would be the failing test case using the existing plugin, note the null
> in the second addFileset()
> --
> public void testFilesets()
> throws Exception
> {
> String base = TARGET_TEST_DIR + "/target";
> CleanMojo mojo = new CleanMojo();
> mojo.addFileset( createFileset( base, "**/file.txt", "**/subdir/**" )
> );
> String outputDirectory = TARGET_TEST_DIR + "/buildOutputDirectory";
> mojo.addFileset( createFileset( outputDirectory, "**", null ) );
> mojo.execute();
> // fileset 1
> assertTrue( checkExists( base ) );
> assertTrue( checkExists( base + "/classes" ) );
> assertFalse( checkExists( base + "/classes/file.txt" ) );
> /* TODO: looks like a bug in the file-management library
> assertTrue( FileUtils.fileExists( base + "/subdir/file.txt" ) );
> */
> // fileset 2
> assertTrue( checkExists( outputDirectory ) );
> assertFalse( checkExists( outputDirectory + "/file.txt" ) );
> System.exit(-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] Updated: (MSOURCES-2) Maven Sources Plugin should be able to distribute test sources as well as main sources
[ http://jira.codehaus.org/browse/MSOURCES-2?page=all ] Brett Porter updated MSOURCES-2: Fix Version: 2.0.1 > Maven Sources Plugin should be able to distribute test sources as well as > main sources > -- > > Key: MSOURCES-2 > URL: http://jira.codehaus.org/browse/MSOURCES-2 > Project: Maven 2.x Sources Plugin > Type: Improvement > Environment: all > Reporter: Dan Fabulich > Fix For: 2.0.1 > > > The Maven Sources Plugin doesn't appear to have a way to distribute the test > sources along with the actual product sources. Since automated tests can > serve as good examples/working documentation, it would be nice to be able to > distribute these in my build. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MNG-967) maven.mdo, settings.mdo, and generated-sources
[ http://jira.codehaus.org/browse/MNG-967?page=all ] Brett Porter updated MNG-967: - Reporter: Jesse McConnell (was: Jesse McConnell) > maven.mdo, settings.mdo, and generated-sources > -- > > Key: MNG-967 > URL: http://jira.codehaus.org/browse/MNG-967 > Project: Maven 2 > Type: Bug > Components: POM > Reporter: Jesse McConnell > Priority: Trivial > Fix For: 2.0.4 > > > a nice trivial issue... > maven-components/maven-settings/settings.mdo > maven-components/maven-model/maven.mdo > those ought to be in src/main/modello > and they ought to be generating their source to > target/generated-sources/modello > they are currently generating to > target/generated-sources -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MNG-756) error updating poms that should exist in the project hierarchy
[ http://jira.codehaus.org/browse/MNG-756?page=all ] Brett Porter updated MNG-756: - Reporter: Jesse McConnell (was: Jesse McConnell) > error updating poms that should exist in the project hierarchy > -- > > Key: MNG-756 > URL: http://jira.codehaus.org/browse/MNG-756 > Project: Maven 2 > Type: Bug > Components: Inheritence and Interpolation > Reporter: Jesse McConnell > > > I noticed this the other day and brett mentioned he saw it from time to time > as well. > basically, I start a process in a subproject first thing in the morning and I > start getting exceptions in trying to find POM files from repositories when > it is not a pom that _will_ be anywhere other then in the existing project > hierarchy. > my setup that is triggering this is: > root/pom > root/cli/pom > root/core/pom > subpoms both have the root pom as the parent. > I'll note that I did include the exception from not being able to find the > maven-execute-plugin from anywhere since that isn't in either of the places > and I generally ignore it, but it I figured I would add it to this in case it > was related in anyway. halfway through you'll see the reference to the > gallup:g:1.0 artifact which is the interesting one. How can a child _not_ > know that the parent isn't going to be on a webserver but locally? I would > think this kinda stuff will generate a substantial amount of bad traffic to > the main repos. > This is what my logs show: (-X didn't yield anything different) > ideation]g-maven/g-cli>m2 -Dexecute.class="com.gallup.net.URLTester" > -Dexecute.args="https://svn.gallup.com/svn/g-maven/trunk/pom.xml"; > execute:resources > [INFO] Retrieving plugins.xml (plugin mappings) for group: > 'org.apache.maven.plugins' > [INFO] Retrieving plugins.xml (plugin mappings) for group: > 'org.apache.maven.plugins' > [INFO] Refreshing plugin mapping metadata; looking for plugin with prefix: > 'execute'. > [INFO] Refreshing plugin-mapping metadata... > [INFO] maven-execute-plugin: updating metadata due to status of 'deployed' > Downloading: > http://maven.gallup.com/plugins-repository/org/apache/maven/plugins/maven-execute-plugin/0.1/maven-execute-plugin-0.1.pom > [WARNING] Unable to get resource from repository > http://maven.gallup.com/plugins-repository > Downloading: > http://repo1.maven.org/maven2/plugins/org/apache/maven/plugins/maven-execute-plugin/0.1/maven-execute-plugin-0.1.pom > [WARNING] Unable to get resource from repository > http://repo1.maven.org/maven2/plugins > [WARNING] Error updating POM - using existing version > org.apache.maven.artifact.resolver.ArtifactResolutionException: Unable to > download the artifact from any repository > org.apache.maven.plugins:maven-execute-plugin:0.1:pom > from the specified remote repositories: > http://maven.gallup.com/plugins-repository, > http://repo1.maven.org/maven2/plugins > at > org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:132) > at > org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveAlways(DefaultArtifactResolver.java:69) > at > org.apache.maven.project.DefaultMavenProjectBuilder.findModelFromRepository(DefaultMavenProjectBuilder.java:348) > at > org.apache.maven.project.DefaultMavenProjectBuilder.buildFromRepository(DefaultMavenProjectBuilder.java:303) > at > org.apache.maven.plugin.DefaultPluginManager.checkRequiredMavenVersion(DefaultPluginManager.java:252) > at > org.apache.maven.plugin.DefaultPluginManager.verifyPlugin(DefaultPluginManager.java:198) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.getMojoDescriptor(DefaultLifecycleExecutor.java:986) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.segmentTaskListByAggregationNeeds(DefaultLifecycleExecutor.java:366) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:108) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:186) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:316) > 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.wagon.ResourceDoesNotExistException: Unable to > download the artifact from any repository >
[jira] Updated: (MNG-772) maven-eclipse-plugin NPE during writing setting file.
[ http://jira.codehaus.org/browse/MNG-772?page=all ] Brett Porter updated MNG-772: - Reporter: Jesse McConnell (was: Jesse McConnell) > maven-eclipse-plugin NPE during writing setting file. > - > > Key: MNG-772 > URL: http://jira.codehaus.org/browse/MNG-772 > Project: Maven 2 > Type: Bug > Reporter: Jesse McConnell > Assignee: Kenney Westerhof > Fix For: 2.0-beta-1 > Attachments: eclipse-plugin.patch > > > the maven eclipse plugin was certain that if the maven-compiler-plugin was > mentioned in the artifacts list that it would have source and target values > defined. > > maven-compiler-plugin > >iso-8859-1 > > > I don't and the eclipse plugin was blowing up with a NPE for this. > I patched it to check for the child Xpp3Dom objects to actually exist before > trying to get their values, which was the cause of the NPE. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MNG-681) Plugin Utility Class
[ http://jira.codehaus.org/browse/MNG-681?page=all ] Brett Porter updated MNG-681: - Reporter: Jesse McConnell (was: Jesse McConnell) > Plugin Utility Class > > > Key: MNG-681 > URL: http://jira.codehaus.org/browse/MNG-681 > Project: Maven 2 > Type: New Feature > Components: Plugin API > Versions: 2.0-alpha-3 > Reporter: Jesse McConnell > Priority: Minor > > > Tryg mentioned that we might want to make a plugins utility class for some of > the issues I ran into implementing a mess of a plugin. > the plugin was pinned into the process-classes phase and generated a source > file which needed to be compiled > 1) I needed to have the classes that were compiled in the compile phase in my > classpath for the plugin. my way around this was to make a URLClassLoader > pointed at the compiled classes. The classes I was processing all used one > of two interfaces and it would have been nice to have those interfaces > available to cast the new instances of the classes and call a method > directly. reflection served the purpose though > 2) I needed to compile the freshly generated source file, so I ripped a mess > of code from the maven compiler plugin to achieve this > two examples of things that would be nice to have a cleaner method of > achieving the same results..if you think it is a good idea I can generalize > what I did into a couple of api's I think. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MNG-603) sablecc plugin
[ http://jira.codehaus.org/browse/MNG-603?page=all ] Brett Porter updated MNG-603: - Reporter: Jesse McConnell (was: Jesse McConnell) > sablecc plugin > -- > > Key: MNG-603 > URL: http://jira.codehaus.org/browse/MNG-603 > Project: Maven 2 > Type: Improvement > Reporter: Jesse McConnell > Attachments: maven-sablecc-plugin.tar, maven-sablecc-plugin.v2.tar, > maven-sablecc-plugin.v3.tar > > > added a sablecc plugin which can be used like this: > > maven-sablecc-plugin > 1.0-SNAPSHOT > >expressions.grammar, aicc.grammar > > > > generate-sources > > generate > > > > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MNG-602) tweak MojoExecutionException to use Throwable as opposed to Exception
[ http://jira.codehaus.org/browse/MNG-602?page=all ] Brett Porter updated MNG-602: - Reporter: Jesse McConnell (was: Jesse McConnell) > tweak MojoExecutionException to use Throwable as opposed to Exception > - > > Key: MNG-602 > URL: http://jira.codehaus.org/browse/MNG-602 > Project: Maven 2 > Type: Bug > Reporter: Jesse McConnell > Fix For: 2.0-beta-1 > Attachments: throwable.patch > > > some unfortunate things like sablecc toss Throwable so we need a clean way to > catching those and returning the MojoExecutionException in plugins -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MNG-849) plugins that add source roots ignored under certain circumstances
[ http://jira.codehaus.org/browse/MNG-849?page=all ] Brett Porter updated MNG-849: - Reporter: Jesse McConnell (was: Jesse McConnell) > plugins that add source roots ignored under certain circumstances > - > > Key: MNG-849 > URL: http://jira.codehaus.org/browse/MNG-849 > Project: Maven 2 > Type: Bug > Reporter: Jesse McConnell > Assignee: Brett Porter > > > kenney and I talked about this on irc for a while...here is a rundown.. > Use Case 1: > when working on my file activator for profiles I use the idea of checking for > a file that is missing and if it is missing then activate the profile, which > contains a plugin that generates the source file I want to > compile...originally I was pointing at the generated java file > so for the initial execution the profile is activated and the compile source > root is added to the mix of things to compile > however, after that should the build have failed and that file not have been > compiled it will not be compiled from that point forward since that the file > the profile was checking for did exist, just not the compiled class file > version of it. > so I switched it over to activate if the classfile didn't exist. > well at that point I was just running > m2 compiler:compile which ends up > bypassing the profile activation and not adding the compile source > rootand since the original source files require that generated class to > compile against the build is broken until there is a clean:clean and that > profile is activated again. > Use Case 2: > this cropped up right after the discussion on the profile activation...dozer > was using >m2 javadoc:javadoc to generate javadocs for a mess of generated > classes but they were not getting picked up...since that generated source > root was not readily apparent to the javadoc plugin when it was executed > directly outside of the context of the normal lifecycle where such things > ought to be set in the normal course of events. > Breakdown: > the thought here is that when a plugin is executed outside of the normal > lifecycle it doesn't have the full context of the lifecycle in terms of > compile source roots > now it could be that this isn't something that m2 should deal with, instead > leaving the onus onto the plugin writers to provide configuration options to > the plugins to support the users mentioning what source roots to use here and > there...and at least in the example of the profile there are lots of > different ways I could have done it...I chose that route to give profiles a > bit of a workout. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MNG-821) file existence profile activation patch
[ http://jira.codehaus.org/browse/MNG-821?page=all ] Brett Porter updated MNG-821: - Reporter: Jesse McConnell (was: Jesse McConnell) > file existence profile activation patch > --- > > Key: MNG-821 > URL: http://jira.codehaus.org/browse/MNG-821 > Project: Maven 2 > Type: New Feature > Components: Inheritence and Interpolation, POM > Versions: 2.0-beta-1 > Reporter: Jesse McConnell > Assignee: Brett Porter > Fix For: 2.0-beta-1 > Attachments: file-existence-profile-activation.patch, > file-profile-activation.patch > > > > classnames > > > > target/generated-sources/classname-generator/com/stuff/util/GClassnameProvider.java > > > > also is a valid tag inside that as well. > The problem with this patch atm is that it ceases to work outside of the > context of the subproject it exists in.. > this is because in the FileExistenceProfileActivator we have no mechanism of > getting the absolute path for that file string. > I looked into BuildBase object that you can get from the Profile passed in > but it is empty (null) and the string doesn't resolve expressions either... > so...if I can get pointed in the right direction for adding that expression > resolution in there I'll put that in...talked to kenney about this a bit on > irc this morning as well and he seemed to think that was probably the way to > go. -- 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: (CONTINUUM-258) https:// doesn't seem to be a supported mechanism for referencing a pom
[ http://jira.codehaus.org/browse/CONTINUUM-258?page=all ] Brett Porter updated CONTINUUM-258: --- Reporter: Jesse McConnell (was: Jesse McConnell) > https:// doesn't seem to be a supported mechanism for referencing a pom > --- > > Key: CONTINUUM-258 > URL: http://jira.codehaus.org/browse/CONTINUUM-258 > Project: Continuum > Type: Bug > Components: Web interface > Reporter: Jesse McConnell > Fix For: 1.0-alpha-4 > Attachments: MungedHttpsURL.java, secure-url-continuum-api.patch, > secure-url-continuum-core.patch, secure-url-continuum-pre.patch, > secure-url-plexus.patch, secure-url-validation.patch > > > I have a svn repository setup with https:// certificate and AD LDAP password > authentication... > would be real nice to be able to point to a pom with > https://svn.company.com/svn/g-maven-plugins/trunk/pom.xml > and have it picked up. > right now it just grumbles about > Enter the URL to the Maven 2 POM[ The URL you provided doesn't exist ] > (in red even :) -- 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: (MAVENUPLOAD-720) JavaCC 4.0
[ http://jira.codehaus.org/browse/MAVENUPLOAD-720?page=all ] Brett Porter updated MAVENUPLOAD-720: - Reporter: Jesse McConnell (was: Jesse McConnell) > JavaCC 4.0 > -- > > Key: MAVENUPLOAD-720 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-720 > Project: maven-upload-requests > Type: Task > Reporter: Jesse McConnell > Assignee: Carlos Sanchez > > > http://www.perendengue.com/stuff/javacc-4.0-bundle.jar > https://javacc.dev.java.net > javacc 4.0 release needed for updated javacc-maven-plugin to support java 5 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MNG-595) patch for adding -encoding X to the javac
[ http://jira.codehaus.org/browse/MNG-595?page=all ] Brett Porter updated MNG-595: - Reporter: Jesse McConnell (was: Jesse McConnell) > patch for adding -encoding X to the javac > - > > Key: MNG-595 > URL: http://jira.codehaus.org/browse/MNG-595 > Project: Maven 2 > Type: Improvement > Reporter: Jesse McConnell > Assignee: Brett Porter > Fix For: 2.0-beta-1 > Attachments: patch > > > for maven-compiler-plugin > supports this now: > > > > maven-compiler-plugin > >utf8 > > > > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MNG-725) pom dependencies not added to compile Classpath
[ http://jira.codehaus.org/browse/MNG-725?page=all ] Brett Porter updated MNG-725: - Reporter: Jesse McConnell (was: Jesse McConnell) > pom dependencies not added to compile Classpath > --- > > Key: MNG-725 > URL: http://jira.codehaus.org/browse/MNG-725 > Project: Maven 2 > Type: Bug > Components: Artifacts and Repositories > Reporter: Jesse McConnell > Assignee: Brett Porter > > > I am trying to use a meta dependency pom file to lump several dependencies > together into one unit. > on the webserver I have > >4.0.0 >meta-dependency >oracle >pom >1.0 >oracle meta dependencies list > > > oracle > oracle > 9201 > provided > > > oracle > oracle_nls_charset > 9201.12 > provided > > > > in the local pom I have: > > meta-dependency > oracle > 1.0 > pom > > Note: I had to specify pom here otherwise it defaulted to trying to > find a .jar file for it even though the pom was specified in > the remote pom...this seemed redundent and unnecessary. In this case the > DEBUG showed it as oracle:jar:1.0 even though the remote pom was clearly in > my local repo and was the one from the server, not a default one like kenney > had mentioned might be the case on irc. > [DEBUG] xml-apis:xml-apis:jar:2.0.2 (selected for provided) > [DEBUG] meta-dependency:oracle:pom:1.0 (selected for compile) > [DEBUG] jclass:pagelayout:jar:5.0 (selected for provided) > that is the debug output from the compiler, I would expect to see the > dependencies in the remote pom listed just below the pom declaration. > I initially tried this with the subproject pom, and that was the same deal. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MNG-1390) @requiresDependencyResolution in process-classes post compile
[ http://jira.codehaus.org/browse/MNG-1390?page=all ]
Brett Porter updated MNG-1390:
--
Reporter: Jesse McConnell (was: Jesse McConnell)
> @requiresDependencyResolution in process-classes post compile
> -
>
> Key: MNG-1390
> URL: http://jira.codehaus.org/browse/MNG-1390
> Project: Maven 2
> Type: Bug
> Components: Inheritence and Interpolation
> Versions: 2.0
> Reporter: Jesse McConnell
> Fix For: 2.0.4
>
> Original Estimate: 3 hours
> Remaining: 3 hours
>
> I was looking back into some plugins I had written a while back and ran
> across an oddity.
> it appears that when using a plugin in the process-classes phase, after the
> compiler plugin has done its thing, the @requiresDependencyResolution javadoc
> flag will toggle the presense of dependencies that are scoped to provided in
> the dependencies section when calling project.getCompileClasspathElements();
> (a difference of 80 vs 24 when not using the flag and then using it)
> ---
> this are two snippits of code from the plugin
> /**
> * A plugin for generating * java file containing all the classes in a src
> tree.
> *
> * @goal generate
> * @requiresDependencyResolution
> * @description Functions Generator plugin
> * @author jesse <[EMAIL PROTECTED]>
> */
>
>
>
> List classpathFiles = project.getCompileClasspathElements();
>
> URL[] urls = new URL[classpathFiles.size() + 1];
>
> getLog().debug("" + classpathFiles.size());
>
> for (int i = 0; i < classpathFiles.size(); ++i) {
> getLog().debug((String)classpathFiles.get(i));
> urls[i] = new File((String)classpathFiles.get(i)).toURL();
> }
>
> urls[classpathFiles.size()] = new File( buildDirectory + "/classes"
> ).toURL();
>
> URLClassLoader ucl = new URLClassLoader(urls,
> Thread.currentThread().getContextClassLoader());
> being used with the following plugin declaration:
>
> gallup.maven
> services-provider-maven-plugin
> 1.0.1
>
>
> com/g/util/ServiceProvider.java
>
>
>
> process-classes
>
> generate
>
>
>
>
>
> analyzing the debug output when I run the plugin without the
> @requiresDependencyResolution I get 80 dependencies and it builds out the
> classloader correctly..
> but if I add the @requiresDependencyResolution statement I go down to 24
> dependencies being put into the classloader...and the discrepency corresponds
> to the presense of the provided statement.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Updated: (MNG-741) new method: addResource( String directory, String includes, String excludes ) on MavenProject
[ http://jira.codehaus.org/browse/MNG-741?page=all ] Brett Porter updated MNG-741: - Reporter: Jesse McConnell (was: Jesse McConnell) > new method: addResource( String directory, String includes, String excludes ) > on MavenProject > - > > Key: MNG-741 > URL: http://jira.codehaus.org/browse/MNG-741 > Project: Maven 2 > Type: Improvement > Reporter: Jesse McConnell > Attachments: add_resource_maven_project.patch > > > in the sablecc plugin I have a case of *.dat files getting created that need > to get jared up with the actual project so I needed to add them as a resource > to the project...since the plugin developers should have to have a minimal > exposure to internals of maven I added this method to MavenProject as a > convience method...also means I have one less dependency that the plugin > itself needs to reference...whichever one model is a part of. -- 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: (SUREFIRE-19) default excludes prevents inner class test cases
[ http://jira.codehaus.org/browse/SUREFIRE-19?page=all ] Brett Porter updated SUREFIRE-19: - Reporter: Jesse McConnell (was: Jesse McConnell) > default excludes prevents inner class test cases > > > Key: SUREFIRE-19 > URL: http://jira.codehaus.org/browse/SUREFIRE-19 > Project: surefire > Type: Bug > Versions: 1.4 > Reporter: Jesse McConnell > Assignee: Carlos Sanchez > Fix For: 1.5.2 > Attachments: maven-surefire-plugin.patch, surefire.patch > > > some people use inner classes for junit tests since they have access to > private variables in the unit tests. > for my particular case we have all unit tests called Foo$TEST > in the DirectoryBattery there was a default excludes that was _always_ > getting added to exclude inner classes...so the patch attached moves this > default exclusion to the listing of default excluders in the > maven-surefire-plugin and removed the forced exclusion. -- 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: (ARCHETYPE-8) example maven project architecture (jars, wars, ejbs, and an ear)
[ http://jira.codehaus.org/browse/ARCHETYPE-8?page=all ] Brett Porter updated ARCHETYPE-8: - Reporter: Jesse McConnell (was: Jesse McConnell) > example maven project architecture (jars, wars, ejbs, and an ear) > - > > Key: ARCHETYPE-8 > URL: http://jira.codehaus.org/browse/ARCHETYPE-8 > Project: Maven Archetype > Type: Improvement > Reporter: Jesse McConnell > Priority: Minor > Fix For: 2.0.1 > Attachments: maven-archetype-j2ee.jar, sample-m2-project.jar > > > someone on the mailing lists asked me for a working sample layout for a > project containing muliple source directories, nesting subprojects, servlets > in war files, ejbs, and ultimately into a ear file. > this is a small sample project, no source but it builds out all the > artifacts. also includes an example of dependencyManagement of versions at > the root pom file. > post comments and I'll make the changes if you want. anyway, on irc I said I > would make it and post it in an issue for review so here it is. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MNG-727) missing dependency version error is vague
[ http://jira.codehaus.org/browse/MNG-727?page=all ] Brett Porter updated MNG-727: - Reporter: Jesse McConnell (was: Jesse McConnell) > missing dependency version error is vague > - > > Key: MNG-727 > URL: http://jira.codehaus.org/browse/MNG-727 > Project: Maven 2 > Type: Improvement > Reporter: Jesse McConnell > > > [INFO] Reason: Failed to validate POM for > '/home/jesse/src/g-maven/g-app/pom.xml'. > Reason(s): > [0] 'dependencies.dependency.version' is missing. > [1] 'dependencies.dependency.version' is missing. > [2] 'dependencies.dependency.version' is missing. > [3] 'dependencies.dependency.version' is missing. > [4] 'dependencies.dependency.version' is missing. > [5] 'dependencies.dependency.version' is missing. > [INFO] > > [INFO] Total time: < 1 second > [INFO] Finished at: Fri Aug 12 15:38:30 CDT 2005 > [INFO] Final Memory: 2M/41M > [INFO] > It would be really nice if this message told you the actual dependency that > was missing. -- 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: (MWAR-27) It should be possible to exclude the META-INF/maven directory from produced WARs
[ http://jira.codehaus.org/browse/MWAR-27?page=all ] Brett Porter updated MWAR-27: - Assign To: John Tolentino Fix Version: 2.0 this should follow the same convention as the jar plugin > It should be possible to exclude the META-INF/maven directory from produced > WARs > > > Key: MWAR-27 > URL: http://jira.codehaus.org/browse/MWAR-27 > Project: Maven 2.x War Plugin > Type: Improvement > Reporter: Mang Lau > Assignee: John Tolentino > Priority: Minor > Fix For: 2.0 > > > Just like the maven-ear-plugin and the maven-jar-plugin, the maven-war-plugin > should allow users to exclude the META-INF/maven directory from the produced > WARs. -- 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-11) ViewCVS links are incorrect.
[ http://jira.codehaus.org/browse/MCHANGELOG-11?page=all ]
Brett Porter updated MCHANGELOG-11:
---
Assign To: Edwin Punzalan
Fix Version: 2.0
is this a duplicate?
> ViewCVS links are incorrect.
> -
>
> Key: MCHANGELOG-11
> URL: http://jira.codehaus.org/browse/MCHANGELOG-11
> Project: Maven 2.x Changelog Plugin
> Type: Bug
> Versions: 2.0
> Reporter: Martin Johannesen
> Assignee: Edwin Punzalan
> Fix For: 2.0
>
>
> My ViewCVS links are incorrect . Example of link:
> SCM Url not inherited and ending with /:
> Incorrect: http://./viewcvs/viewcvs.cgi/common/om.xml
> Correct: http://./viewcvs/viewcvs.cgi/common/pom.xml
> SCM Url inherited and ending with /:
> Incorrect: http://./viewcvs/viewcvs.cgi/common/oioom.xml
> Correct: http://./viewcvs/viewcvs.cgi/common/oio/pom.xml
> The problem is in org.apache.maven.changelog.ChangeLogReport:
> {{
> private String getAbsolutePath( final String base, final String target )
> {
>
>
> return absPath + target.substring( 1 );
> }
> }}
> It always cuts of the first character of the target, maybe because it assumes
> that the first character is a /.
> The next problem is that when using an inherited scm url, it doesnt get a "/"
> appended to the absPath, so a solution to this problem could be:
> {{
> private String getAbsolutePath( final String base, final String target )
> {
>
>
>if(!absPath.endsWith("/")) absPath+="/";
> String newTarget=target;
> if(newTarget.startsWith("/")) newTarget=newTarget.substring(1);
> return absPath + newTarget;
> }
> }}
--
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: (MCHANGELOG-10) Download of changelog plugin fails due to unresolved artifact
[ http://jira.codehaus.org/browse/MCHANGELOG-10?page=all ] Brett Porter closed MCHANGELOG-10: -- Assign To: Brett Porter Resolution: Won't Fix please post more details to users@maven.apache.org (what the actual failure is). It appears to be a problem on your end. > Download of changelog plugin fails due to unresolved artifact > - > > Key: MCHANGELOG-10 > URL: http://jira.codehaus.org/browse/MCHANGELOG-10 > Project: Maven 2.x Changelog Plugin > Type: Bug > Reporter: Markus Klink > Assignee: Brett Porter > > > I have configured changelog as follows: > > > > org.codehaus.mojo > changelog-maven-plugin > 2.0-beta-1 > > range > 30 > -MM-dd > > > When trying to generate the site I get an error that it failed to resolve > artifact org.netbeans:lib:jar:3.6 Before I got a warning that this artifact > had been relocated from netbeans:cvslib:3.6 > Trying with 2.0-beta-2-SNAPSHOT did not help either. Thanks for taking care. -- 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: (MCHANGELOG-3) Links in File Activity Report can be wrong when using subversion, after a copy command has been issued
[ http://jira.codehaus.org/browse/MCHANGELOG-3?page=comments#action_62000 ] Brett Porter commented on MCHANGELOG-3: --- Julian - any update? > Links in File Activity Report can be wrong when using subversion, after a > copy command has been issued > -- > > Key: MCHANGELOG-3 > URL: http://jira.codehaus.org/browse/MCHANGELOG-3 > Project: Maven 2.x Changelog Plugin > Type: Bug > Environment: OSX 10.4.3, java 1.4.2_09 > Reporter: Julian Wood > Assignee: Edwin Punzalan > Priority: Minor > Fix For: 2.0 > Attachments: MOJO-216-changelog-maven-plugin-1a.patch, > MOJO-216-changelog-maven-plugin.patch, changelog.xml, svnlog2.txt > > > When you do a subversion copy command, the list of files produced by svn log > often have additional information that is part of the filename: > R /tags/prt-1.3/prt-admin/pom.xml (from /trunk/prt-admin/pom.xml:128) > In SvnChangeLogParser.java, the file name is parsed as > /tags/prt-1.3/prt-admin/pom.xml (from /trunk/prt-admin/pom.xml:128) when of > course it should be /tags/prt-1.3/prt-admin/pom.xml. This is most > significantly manifested when a link is generated, such as in the File > Activity Report. > http://...?repname=prt&sc=0&path=/tags/prt-1.3/pom.xml%20(from%20/trunk/pom.xml:128) > I can see two approaches to the problem. The simplest is to add a regular > expression which deletes the extraneous data, but then you lose that > potentially valuable information. Maybe ChangeLogFile should keep track of a > file (path) and a name, rather than just a name, so that the link can be made > properly. -- 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: (MSUREFIREREP-4) encoding trouble on solaris system
[ http://jira.codehaus.org/browse/MSUREFIREREP-4?page=all ] Brett Porter updated MSUREFIREREP-4: Fix Version: (was: 2.0) > encoding trouble on solaris system > -- > > Key: MSUREFIREREP-4 > URL: http://jira.codehaus.org/browse/MSUREFIREREP-4 > Project: Maven 2.x Surefire report Plugin > Type: Bug > Environment: solaris > LANG=en_US.ISO8859-15 > export LANG > Reporter: Olivier Lamy > Assignee: Allan Ramirez > > > [INFO] Generate "Maven Surefire Report" report. > org.xml.sax.SAXParseException: Character conversion error: "Malformed UTF-8 > char -- is an XML encodi > ng declaration missing?" (line number may be too low). > at org.apache.crimson.parser.InputEntity.fatal(InputEntity.java:1100) > at > org.apache.crimson.parser.InputEntity.fillbuf(InputEntity.java:1072) > at org.apache.crimson.parser.InputEntity.isEOF(InputEntity.java:262) > at > org.apache.crimson.parser.InputEntity.parsedContent(InputEntity.java:472) > at org.apache.crimson.parser.Parser2.content(Parser2.java:2010) > at org.apache.crimson.parser.Parser2.maybeElement(Parser2.java:1691) > at org.apache.crimson.parser.Parser2.content(Parser2.java:1963) > at org.apache.crimson.parser.Parser2.maybeElement(Parser2.java:1691) > at org.apache.crimson.parser.Parser2.content(Parser2.java:1963) > at org.apache.crimson.parser.Parser2.maybeElement(Parser2.java:1691) > at org.apache.crimson.parser.Parser2.parseInternal(Parser2.java:667) > at org.apache.crimson.parser.Parser2.parse(Parser2.java:337) > at > org.apache.crimson.parser.XMLReaderImpl.parse(XMLReaderImpl.java:448) > at javax.xml.parsers.SAXParser.parse(SAXParser.java:345) > at javax.xml.parsers.SAXParser.parse(SAXParser.java:281) > at > org.codehaus.mojo.surefire.ReportTestSuite.(ReportTestSuite.java:59) -- 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-34) Add resources to source folders instead of module libraries
[ http://jira.codehaus.org/browse/MIDEA-34?page=all ] Brett Porter updated MIDEA-34: -- Fix Version: 2.0 > Add resources to source folders instead of module libraries > --- > > Key: MIDEA-34 > URL: http://jira.codehaus.org/browse/MIDEA-34 > Project: Maven 2.x Idea Plugin > Type: Bug > Versions: 2.0 > Reporter: Manfred Geiler > Priority: Critical > Fix For: 2.0 > Attachments: idea-1.patch > > > Having the resources as module libraries does not make much sense. > Instead the resources dir(s) should be added as normal idea source folders, > so that editing of properties files, xml files, etc. is possible. > see applied patch > 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] Closed: (MIDEA-36) Multi-module vs. Single-module projects
[ http://jira.codehaus.org/browse/MIDEA-36?page=all ] Brett Porter closed MIDEA-36: - Assign To: Brett Porter Resolution: Won't Fix > Multi-module vs. Single-module projects > --- > > Key: MIDEA-36 > URL: http://jira.codehaus.org/browse/MIDEA-36 > Project: Maven 2.x Idea Plugin > Type: Bug > Reporter: Aleksandr Tarutin > Assignee: Brett Porter > > > In IDEA's single module project the module files (.iml) are created at the > same level that the project file (.ipr). > For multi-mudile projects the directory containing the project file does not > contain module files but rather contains module subdirectories each > containing the module 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: (MIDEA-39) In a multi-module project, idea plugin should generate module dependencies instead of creating libs with references to the repository
[ http://jira.codehaus.org/browse/MIDEA-39?page=all ] Brett Porter closed MIDEA-39: - Assign To: Brett Porter Resolution: Won't Fix if you generate everything togehter, they get linked. > In a multi-module project, idea plugin should generate module dependencies > instead of creating libs with references to the repository > - > > Key: MIDEA-39 > URL: http://jira.codehaus.org/browse/MIDEA-39 > Project: Maven 2.x Idea Plugin > Type: Improvement > Versions: 2.0 > Environment: Windows XP, IntelliJ 5.1, JDK 1.5.0_06, Maven 2.0.2 > Reporter: Vikash Ramanlal > Assignee: Brett Porter > Priority: Minor > > > When I generate my idea files using "mvn idea:idea", all works fine. > However if I have module a and module b (both jar packaging) and b depends on > a, then I expected the idea plugin to generate the project files such that > for module b, a is a dependent module. However what I get is a library entry > for a that points to a jar in the local repository. > Maven 1.0.2 idea plugin did not work this way. I created the module > dependencies in correctly in the idea 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] Created: (MPA-54) create account for Brian Fox
create account for Brian Fox Key: MPA-54 URL: http://jira.codehaus.org/browse/MPA-54 Project: Maven Project Administration Type: Task Components: New Committers Reporter: Brett Porter Assigned to: Brett Porter Fix For: 2006-q1 adding for the records -- 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: (MPA-55) add committer Chris Stevenson
add committer Chris Stevenson - Key: MPA-55 URL: http://jira.codehaus.org/browse/MPA-55 Project: Maven Project Administration Type: Task Components: New Committers Reporter: Brett Porter Assigned to: Jason van Zyl Fix For: 2006-q1 -- 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: (MPA-55) add committer Chris Stevenson
[ http://jira.codehaus.org/browse/MPA-55?page=all ] Brett Porter closed MPA-55: --- Assign To: Brett Porter (was: Jason van Zyl) Resolution: Fixed > add committer Chris Stevenson > - > > Key: MPA-55 > URL: http://jira.codehaus.org/browse/MPA-55 > Project: Maven Project Administration > Type: Task > Components: New Committers > Reporter: Brett Porter > Assignee: Brett Porter > Fix For: 2006-q1 > > -- 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: (MPA-56) Process Fabrice Bellingard
Process Fabrice Bellingard -- Key: MPA-56 URL: http://jira.codehaus.org/browse/MPA-56 Project: Maven Project Administration Type: Task Components: New Committers Reporter: Brett Porter Assigned to: Jason van Zyl Fix For: 2006-q1 -- 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: (MPA-20) create release issues for each plugin to track votes and preparedness
[ http://jira.codehaus.org/browse/MPA-20?page=all ] Brett Porter closed MPA-20: --- Assign To: Brett Porter Resolution: Won't Fix Fix Version: (was: 2006-q1) > create release issues for each plugin to track votes and preparedness > - > > Key: MPA-20 > URL: http://jira.codehaus.org/browse/MPA-20 > Project: Maven Project Administration > Type: Task > Components: Issue Management > Reporter: John Casey > Assignee: Brett Porter > Priority: Blocker > > > should be specific to one release of one plugin, and should incorporate links > to all outstanding issues for that release. -- 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: (MPA-57) migrate all Maven projects to the Basic Issue Creation Scheme in JIRA
migrate all Maven projects to the Basic Issue Creation Scheme in JIRA - Key: MPA-57 URL: http://jira.codehaus.org/browse/MPA-57 Project: Maven Project Administration Type: Task Components: Issue Management Reporter: Brett Porter Assigned to: Jason van Zyl Fix For: 2006-q1 -- 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: (MPA-48) migrate all maven, mojo, mrm, continuum, etc projects to the new workflow where closed issues can be edited.
[ http://jira.codehaus.org/browse/MPA-48?page=all ] Brett Porter closed MPA-48: --- Assign To: Brett Porter (was: Jason van Zyl) Resolution: Fixed > migrate all maven, mojo, mrm, continuum, etc projects to the new workflow > where closed issues can be edited. > > > Key: MPA-48 > URL: http://jira.codehaus.org/browse/MPA-48 > Project: Maven Project Administration > Type: Task > Components: Issue Management > Reporter: Brett Porter > Assignee: Brett Porter > Fix For: 2006-q1 > > -- 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-641) stopping continuum when builds are in progress /queued causes duplicates on restart
stopping continuum when builds are in progress /queued causes duplicates on restart --- Key: CONTINUUM-641 URL: http://jira.codehaus.org/browse/CONTINUUM-641 Project: Continuum Type: Task Components: Core system Versions: 1.0.3 Reporter: Brett Porter Priority: Blocker Fix For: 1.0.3 I was able to reliably reproduce this. -- 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: (WAGONHTTP-9) unable to use wagon-http-lightweight with maven deploy and release plugins
[ http://jira.codehaus.org/browse/WAGONHTTP-9?page=all ] Brett Porter closed WAGONHTTP-9: Assign To: Brett Porter Resolution: Fixed Fix Version: 1.0-alpha-7 applied, thanks > unable to use wagon-http-lightweight with maven deploy and release plugins > -- > > Key: WAGONHTTP-9 > URL: http://jira.codehaus.org/browse/WAGONHTTP-9 > Project: wagon-http > Type: Bug > Versions: 1.0-alpha-6 > Environment: maven 2.0.2 on windows xp. > Reporter: ysoonleo > Assignee: Brett Porter > Fix For: 1.0-alpha-7 > Attachments: wagon-http-lightweight.patch > > > The wagon-http-lightweight fails with response 201 and 204 when using maven > deploy and release:perform plugins. > The error messages are: > [INFO] Error deploying artifact: Unable to transfer file. HttpURLConnection > returned the response code: 201 > [INFO] Error deploying artifact: Unable to transfer file. HttpURLConnection > returned the response code: 204 > The wagon-http-lightweight fails because it only handles response code 200 > and flags the rest as errors. > The attached patch file should address this problem as it uses the same code > handling mechanism from wagon-http. This patch can also be used to address > the WAGONHTTP-7 issue for wagon-http. > With this patch, the wagon-http and wagon-http-lightweight.will work with > webdav for the deploy and release 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: (CONTINUUM-641) stopping continuum when builds are in progress /queued causes duplicates on restart
[ http://jira.codehaus.org/browse/CONTINUUM-641?page=comments#action_62176 ] Brett Porter commented on CONTINUUM-641: There seems to be a couple of things. I can't find what led to the problem on the one I tried to reproduce it on - it was in fact just the "in progress" one. Steps to reproduce (on ubuntu breezy VMWare machine running on windows): - fresh install - add a bunch of projects, wait for checkout - build all - kill the app (not Ctrl-C, just a normal kill that got trapped by JSW and Continuum shutdown) - restart Continuum - one dupe, building projects does not cause a dupe For cheddar, I got more information yesterday. It's not an addProject call - it seems a problem with JDO when it tries to get the project for building the next time. This might just be that the original database was corrupted, so I'm not really concerned about it. > stopping continuum when builds are in progress /queued causes duplicates on > restart > --- > > Key: CONTINUUM-641 > URL: http://jira.codehaus.org/browse/CONTINUUM-641 > Project: Continuum > Type: Task > Components: Core system > Versions: 1.0.3 > Reporter: Brett Porter > Priority: Blocker > Fix For: 1.0.3 > > > I was able to reliably reproduce this. -- 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-85) Dependency report broken if M1 artifacts referenced
[ http://jira.codehaus.org/browse/MSITE-85?page=all ] Brett Porter closed MSITE-85: - Resolution: Duplicate this is a duplicate. And no, it's not fixed in 2.0.3, because the code is in a plugin. That plugin is not released yet. > Dependency report broken if M1 artifacts referenced > --- > > Key: MSITE-85 > URL: http://jira.codehaus.org/browse/MSITE-85 > Project: Maven 2.x Site Plugin > Type: Bug > Reporter: Nigel Magnay > Assignee: Brett Porter > > > Workaround is : > true in reporting to disable the default > project-info reports. > Otherwise you get > [INFO] Generate "Dependencies" report. > [INFO] > > [ERROR] FATAL ERROR > [INFO] > > [INFO] Can't find a valid Maven project in the repository for the artifact > [kernel:framework:1.0(8)]. > [INFO] > > [INFO] Trace -- 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-85) Dependency report broken if M1 artifacts referenced
[ http://jira.codehaus.org/browse/MSITE-85?page=comments#action_62195 ] Brett Porter commented on MSITE-85: --- you can only reopen what you created. the subversion commits don't always show (it depends on whether the fixer recorded the issue in the commit log). It says it was fixed in "2.0", which means when that release comes out, it will be there. > Dependency report broken if M1 artifacts referenced > --- > > Key: MSITE-85 > URL: http://jira.codehaus.org/browse/MSITE-85 > Project: Maven 2.x Site Plugin > Type: Bug > Reporter: Nigel Magnay > Assignee: Brett Porter > > > Workaround is : > true in reporting to disable the default > project-info reports. > Otherwise you get > [INFO] Generate "Dependencies" report. > [INFO] > > [ERROR] FATAL ERROR > [INFO] > > [INFO] Can't find a valid Maven project in the repository for the artifact > [kernel:framework:1.0(8)]. > [INFO] > > [INFO] Trace -- 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] Moved: (MCHANGES-1) Annoucement generates announcement for wrong type of package
[ http://jira.codehaus.org/browse/MCHANGES-1?page=all ] Brett Porter moved MOJO-111 to MCHANGES-1: -- Fix Version: (was: 2.1) 2.0 Component: (was: changes) Complexity: (was: Intermediate) Workflow: jira (was: Maven New) Key: MCHANGES-1 (was: MOJO-111) Project: Maven 2.x Changes Plugin (was: Mojo) > Annoucement generates announcement for wrong type of package > > > Key: MCHANGES-1 > URL: http://jira.codehaus.org/browse/MCHANGES-1 > Project: Maven 2.x Changes Plugin > Type: Bug > Reporter: Tony Steele > Assignee: Allan Ramirez > Priority: Minor > Fix For: 2.0 > > Original Estimate: 1 hour > Remaining: 1 hour > > The announcement was geterated for a jar generated : > --- > The maven2-team is pleased to announce the maven2-1.0.jar release! > http://javateam.tv.bbc.co.uk/home/javateam/html/projects/maven2 > Changes in this version include: > .. > --- > even when the package was a pom in the pom.xml: > javateam > maven2 > Javateam Maven 2 Configuration > pom -- 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-2159) [patch] Update the docs for the Ant tasks for Maven
[ http://jira.codehaus.org/browse/MNG-2159?page=all ] Brett Porter closed MNG-2159: - Assign To: Brett Porter Resolution: Fixed Fix Version: documentation > [patch] Update the docs for the Ant tasks for Maven > --- > > Key: MNG-2159 > URL: http://jira.codehaus.org/browse/MNG-2159 > Project: Maven 2 > Type: Bug > Components: Documentation: General > Reporter: Dennis Lundberg > Assignee: Brett Porter > Priority: Minor > Fix For: documentation > Attachments: antlib-docs-update.patch > > > Here are some updates to the documentation for Ant tasks for Maven. > This is what is included in the patch: > - Use the latest released jar for maven-artifact-ant in the example for > "Declaring a typedef" > - Use the artifact prefix for the dependencies tags under "Declaring > Dependencies" > - Make "snapshots, releases" one level smaller, as it is a subsection to > "remoteRepository" > - Fix copy-and-paste error in the second Ant properties example under "Using > a Maven POM File" > - Various small spelling fixes -- 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-2054) Multiple Inheritence causes plugin executions to run multiple times (Test Case Attached)
[ http://jira.codehaus.org/browse/MNG-2054?page=comments#action_62215 ]
Brett Porter commented on MNG-2054:
---
Brian, also please detail exactly which RC you are using (time/date). I don't
believe anything was changed between the last one and the release.
> Multiple Inheritence causes plugin executions to run multiple times (Test
> Case Attached)
>
>
> Key: MNG-2054
> URL: http://jira.codehaus.org/browse/MNG-2054
> Project: Maven 2
> Type: Bug
> Components: Inheritence and Interpolation
> Versions: 2.0.2
> Environment: WinXp
> Reporter: Brian Fox
> Assignee: John Casey
> Priority: Critical
> Fix For: 2.0.3
> Attachments: sample.zip
>
>
> See the attached sample. If a plugin execution is set in a parent of a
> parent, when the child is built from either aggregator, the plugin execution
> runs multiple times. In my sample, I set the sources to be generated, but
> when run, see that the sources are generated and installed 2x.
> [INFO] Building jar:
> E:\STC\sample\sample-parent2\sample-jar\target\sample-jar-SNAPSHOT-tests.jar
> [INFO] [install:install]
> [INFO] Installing
> E:\STC\sample\sample-parent2\sample-jar\target\sample-jar-SNAPSHOT.jar to
> f:\mavenRepo\sampl
> e-project\sample-jar\SNAPSHOT\sample-jar-SNAPSHOT.jar
> [INFO] Installing
> E:\STC\sample\sample-parent2\sample-jar\target\sample-jar-SNAPSHOT-sources.jar
> to f:\mavenRe
> po\sample-project\sample-jar\SNAPSHOT\sample-jar-SNAPSHOT-sources.jar
> [INFO] Installing
> E:\STC\sample\sample-parent2\sample-jar\target\sample-jar-SNAPSHOT-sources.jar
> to f:\mavenRe
> po\sample-project\sample-jar\SNAPSHOT\sample-jar-SNAPSHOT-sources.jar
> [INFO] Installing
> E:\STC\sample\sample-parent2\sample-jar\target\sample-jar-SNAPSHOT-tests.jar
> to f:\mavenRepo
> \sample-project\sample-jar\SNAPSHOT\sample-jar-SNAPSHOT-tests.jar
> [INFO]
> If run directly from the child build, the sources are only built 1x:
> [INFO] [jar:jar]
> [INFO] Building jar:
> E:\STC\sample\sample-parent2\sample-jar\target\sample-jar-SNAPSHOT.jar
> [INFO] [source:jar {execution: attach-source}]
> [INFO] Building jar:
> E:\STC\sample\sample-parent2\sample-jar\target\sample-jar-SNAPSHOT-sources.jar
> [INFO] [jar:test-jar {execution: default}]
> [INFO] Building jar:
> E:\STC\sample\sample-parent2\sample-jar\target\sample-jar-SNAPSHOT-tests.jar
> [INFO] [install:install]
> [INFO] Installing
> E:\STC\sample\sample-parent2\sample-jar\target\sample-jar-SNAPSHOT.jar to
> f:\mavenRepo\sampl
> e-project\sample-jar\SNAPSHOT\sample-jar-SNAPSHOT.jar
> [INFO] Installing
> E:\STC\sample\sample-parent2\sample-jar\target\sample-jar-SNAPSHOT-sources.jar
> to f:\mavenRe
> po\sample-project\sample-jar\SNAPSHOT\sample-jar-SNAPSHOT-sources.jar
> [INFO] Installing
> E:\STC\sample\sample-parent2\sample-jar\target\sample-jar-SNAPSHOT-tests.jar
> to f:\mavenRepo
> \sample-project\sample-jar\SNAPSHOT\sample-jar-SNAPSHOT-tests.jar
--
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-2160) Access Problem with viewcvs
[ http://jira.codehaus.org/browse/MNG-2160?page=all ] Brett Porter closed MNG-2160: - Resolution: Won't Fix its a problem with the viewcvs installation at Apache, not with Maven. I'll follow up, but I think it has always been this way. > Access Problem with viewcvs > --- > > Key: MNG-2160 > URL: http://jira.codehaus.org/browse/MNG-2160 > Project: Maven 2 > Type: Wish > Components: Sites & Reporting > Reporter: Rainer Wasserfuhr > Priority: Trivial > > > currently > http://svn.apache.org/viewcvs.cgi/maven/components/trunk/maven-core/ gives: > An Exception Has Occurred > Access to "maven/components/trunk/maven-core" is forbidden. > HTTP Response Status > 403 Forbidden > Python Traceback > Traceback (most recent call last): > File "/usr/local/viewcvs-1.0-dev/lib/viewcvs.py", line 3351, in main > request.run_viewcvs() > File "/usr/local/viewcvs-1.0-dev/lib/viewcvs.py", line 228, in run_viewcvs > % self.where, '403 Forbidden') > ViewCVSException: 403 Forbidden: Access to > "maven/components/trunk/maven-core" is forbidden. -- 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-2169) Want to contribute: Contributing Maven 2 refcard
[ http://jira.codehaus.org/browse/MNG-2169?page=comments#action_62219 ] Brett Porter commented on MNG-2169: --- Hans? Can you address Carlos' concerns? > Want to contribute: Contributing Maven 2 refcard > > > Key: MNG-2169 > URL: http://jira.codehaus.org/browse/MNG-2169 > Project: Maven 2 > Type: New Feature > Components: Documentation: General > Environment: All > Reporter: Hans Baier > Attachments: MavenQuickReference.pdf, MavenQuickReference.tex > > > Hello, I want to contribute a refcard for maven, > the one I desperately wanted when I started -- 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-83) Tests run with Surefire are not able to make remote calls to an RMI server of an EJB server
[ http://jira.codehaus.org/browse/MSUREFIRE-83?page=all ] Brett Porter updated MSUREFIRE-83: -- Fix Version: 2.2 > Tests run with Surefire are not able to make remote calls to an RMI server of > an EJB server > --- > > Key: MSUREFIRE-83 > URL: http://jira.codehaus.org/browse/MSUREFIRE-83 > Project: Maven 2.x Surefire Plugin > Type: Bug > Versions: 2.1.2 > Environment: Windows 2000, Java JDK 1.4 > Reporter: Todd Nine > Priority: Blocker > Fix For: 2.2 > Attachments: verbose_app_ output.txt > > > I am unable run any unit tests that connect to a remote RMI server. This > includes vanilla RMI, or JBoss remote connections. I can however use the > same classpath set by maven with the maven 2 eclipse plugin, and all tests > execute successfully. I always receive a socket timeout, which seems to be > the root cause of the remote connectivity issues, but I only receive them > when running the tests from within surefire. I have attached a stack trace > and verbose output. -- 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-2179) wrong property evaluation for project.organisation.name
[ http://jira.codehaus.org/browse/MNG-2179?page=all ]
Brett Porter closed MNG-2179:
-
Assign To: Brett Porter
Resolution: Duplicate
> wrong property evaluation for project.organisation.name
> ---
>
> Key: MNG-2179
> URL: http://jira.codehaus.org/browse/MNG-2179
> Project: Maven 2
> Type: Bug
> Components: POM
> Versions: 2.0.2
> Environment: SuSE linux 10.0 kernel 2.6.13-15.8-smp
> Reporter: Frank Seidinger
> Assignee: Brett Porter
>
>
> If you define a name and an organisation in a pom like:
>
> ...
> my project name
> ...
>
> my organization name
>
> ...
>
> and later use the organisation name, e.g. to include it in a manifest with:
> ...
>
> org.apache.maven.plugins
> maven-jar-plugin
>
>
>
> ${project.organization.name}
>
>
>
>
> ...
> the property reference is evaluated to the project name. You will find in the
> manifest:
> MIDlet-Vendor: my project name
--
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: (MCHANGELOG-10) Download of changelog plugin fails due to unresolved artifact
[ http://jira.codehaus.org/browse/MCHANGELOG-10?page=comments#action_6 ] Brett Porter commented on MCHANGELOG-10: my bad, there was a problem, and the local repository just needed to be flushed. This has been addressed in an MEV jira ticket. > Download of changelog plugin fails due to unresolved artifact > - > > Key: MCHANGELOG-10 > URL: http://jira.codehaus.org/browse/MCHANGELOG-10 > Project: Maven 2.x Changelog Plugin > Type: Bug > Reporter: Markus Klink > Assignee: Brett Porter > > > I have configured changelog as follows: > > > > org.codehaus.mojo > changelog-maven-plugin > 2.0-beta-1 > > range > 30 > -MM-dd > > > When trying to generate the site I get an error that it failed to resolve > artifact org.netbeans:lib:jar:3.6 Before I got a warning that this artifact > had been relocated from netbeans:cvslib:3.6 > Trying with 2.0-beta-2-SNAPSHOT did not help either. Thanks for taking care. -- 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] Reopened: (MIDEA-39) In a multi-module project, idea plugin should generate module dependencies instead of creating libs with references to the repository
[ http://jira.codehaus.org/browse/MIDEA-39?page=all ] Brett Porter reopened MIDEA-39: --- ok, perhaps we could do a USD-ish thing, but not for 2.0. > In a multi-module project, idea plugin should generate module dependencies > instead of creating libs with references to the repository > - > > Key: MIDEA-39 > URL: http://jira.codehaus.org/browse/MIDEA-39 > Project: Maven 2.x Idea Plugin > Type: Improvement > Versions: 2.0 > Environment: Windows XP, IntelliJ 5.1, JDK 1.5.0_06, Maven 2.0.2 > Reporter: Vikash Ramanlal > Assignee: Brett Porter > Priority: Minor > > > When I generate my idea files using "mvn idea:idea", all works fine. > However if I have module a and module b (both jar packaging) and b depends on > a, then I expected the idea plugin to generate the project files such that > for module b, a is a dependent module. However what I get is a library entry > for a that points to a jar in the local repository. > Maven 1.0.2 idea plugin did not work this way. I created the module > dependencies in correctly in the idea 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] Closed: (MNG-2182) site:deploy will fail if site url is file:// and directory is non-empty
[ http://jira.codehaus.org/browse/MNG-2182?page=all ] Brett Porter closed MNG-2182: - Assign To: Brett Porter Resolution: Duplicate fixed in 2.0.3 > site:deploy will fail if site url is file:// and directory is non-empty > --- > > Key: MNG-2182 > URL: http://jira.codehaus.org/browse/MNG-2182 > Project: Maven 2 > Type: Bug > Components: Sites & Reporting > Versions: 2.0.2 > Environment: win2k > Reporter: Matt Munz > Assignee: Brett Porter > > > The first time I run site:deploy, all is fine. The second time, I get the > following error. > Embedded error: Could not make directory > '\\myFileServer\path\to\project\website\.'. > If I delete this directory, site:deploy works as expected. > My POM contains this fragment. > > > website > my project website > > file:myFileServer/path/to/project/website/ > > -- 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-3) site adds relative paths to css, etc, but doesn't work for error documents
[ http://jira.codehaus.org/browse/MSITE-3?page=comments#action_62227 ] Brett Porter commented on MSITE-3: -- [EMAIL PROTECTED] ~/scm/maven/site $ cat src/site/resources/.htaccess ErrorDocument 404 /errors/404.html I think certain pages need absolute URLs. I'm not sure how best to specify it, though. I wouldn't want them for all, as it is prohibitive to viewing locally. > site adds relative paths to css, etc, but doesn't work for error documents > -- > > Key: MSITE-3 > URL: http://jira.codehaus.org/browse/MSITE-3 > Project: Maven 2.x Site Plugin > Type: Bug > Reporter: Brett Porter > Fix For: 2.0 > > > we should possibly use the absolute urls for these anyway. -- 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: (SUREFIRE-38) Surefire Maven2 Plugin fails to run EJB3 Embeddable Container (but mvn eclipse:eclipse succeeds)
[ http://jira.codehaus.org/browse/SUREFIRE-38?page=all ] Brett Porter updated SUREFIRE-38: - Fix Version: 2.0 > Surefire Maven2 Plugin fails to run EJB3 Embeddable Container (but mvn > eclipse:eclipse succeeds) > > > Key: SUREFIRE-38 > URL: http://jira.codehaus.org/browse/SUREFIRE-38 > Project: surefire > Type: Bug > Versions: 1.5.2 > Environment: maven 2.0.3 > Reporter: Dan Greening > Assignee: Jason van Zyl > Priority: Critical > Fix For: 2.0 > Attachments: jboss-ejb3-embeddable-test-with-junit.tar.gz > > > JBoss's EJB3 embeddable container, which is very handy for unit testing EJB's > without using an application server, will not work under surefire in Maven2. > It works fine under Maven1. Furthermore, it ALSO works using the Maven2 > eclipse-plugin generated .project/.classpath in Eclipse. > Here's a complete set of instruction to reproduce it. > This is a test showing that surefire does not properly handle the JBoss EJB3 > embeddable container. > The instructions are a bit complex, because you have to download a package of > JARs from JBoss. (They make the test file too big to attach in JIRA.) > To confirm, > 1. cd /tmp > 2. Surf to > http://sourceforge.net/project/showfiles.php?group_id=22866&package_id=132063 > 3. Download jboss-EJB-3.0_Embeddable_ALPHA_5.zip. Put it in /tmp. This is >the latest EJB3 embeddable system. > 4. unzip jboss-EJB-3.0_Embeddable_ALPHA_5.zip > 5. Download jboss-ejb3-embeddable-test-with-junit.tar.gz (it is an attachment >to this JIRA ticket). > 6. tar xvfz jboss-ejb3-embeddable-test-with-junit.tar.gz > 7. cd jboss-ejb3-embeddable-test-with-junit > 8. cp -pR ../jboss-EJB-3.0_Embeddable_ALPHA_5/lib lib > 9. ./deploy-jars.perl > 10. type "mvn test". > 11. Note that the test fails. > 12. Type "mvn eclipse:eclipse" > 13. Import the jboss-ejb3-embeddable-test-with-junit directory into Eclipse > as an "existing project". > 14. Set M2_REPO build variable to your .m2/repository folder. > 15. Run the EmbeddedEjb3TestCase as a JUnit test in Eclipse. It works. -- 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-108) problem with nav generation (collapse = true) snapshot used 20060315.092459-4.jar (same trouble doxia trunk)
[ http://jira.codehaus.org/browse/MSITE-108?page=all ] Brett Porter updated MSITE-108: --- Version: 2.0 Fix Version: 2.0 > problem with nav generation (collapse = true) snapshot used > 20060315.092459-4.jar (same trouble doxia trunk) > -- > > Key: MSITE-108 > URL: http://jira.codehaus.org/browse/MSITE-108 > Project: Maven 2.x Site Plugin > Type: Bug > Versions: 2.0 > Environment: cygwin and solaris > Reporter: Olivier Lamy > Fix For: 2.0 > Attachments: MSITE-108.tar > > > Look at the attached test case, two problems > - click on Xdoc2 (the item Xdoc3 is not displayed) > - click on Xdoc Example then Xdoc2 the menu Xdoc is closed. -- 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-2185) Could not access both "maven-core" and "maven-archetype-core" through ViewCVS
[ http://jira.codehaus.org/browse/MNG-2185?page=all ] Brett Porter closed MNG-2185: - Assign To: Brett Porter Resolution: Duplicate fixed in apache's svn, waiting for it to go live > Could not access both "maven-core" and "maven-archetype-core" through ViewCVS > - > > Key: MNG-2185 > URL: http://jira.codehaus.org/browse/MNG-2185 > Project: Maven 2 > Type: Bug > Components: Bootstrap & Build > Environment: Windows XP, both IE6 and FireFox 1.5 Browsers > Reporter: Jian Wu > Assignee: Brett Porter > > > When accessing maven2 source code through ViewCVS ( > http://svn.apache.org/viewcvs.cgi/maven/components/trunk/ ), accessing > maven-core got the following ViewCVS Exception: > ~~~ > An Exception Has Occurred > Access to "maven/components/trunk/maven-core" is forbidden. > HTTP Response Status > 403 Forbidden > > Python Traceback > Traceback (most recent call last): > File "/usr/local/viewcvs-1.0-dev/lib/viewcvs.py", line 3351, in main > request.run_viewcvs() > File "/usr/local/viewcvs-1.0-dev/lib/viewcvs.py", line 228, in run_viewcvs > % self.where, '403 Forbidden') > ViewCVSException: 403 Forbidden: Access to > "maven/components/trunk/maven-core" is forbidden. > ~~ > The similar exception also occurred when accessing maven-archetype-core: > ~~ > An Exception Has Occurred > Access to "maven/archetype/trunk/maven-archetype-core" is forbidden. > HTTP Response Status > 403 Forbidden > > Python Traceback > Traceback (most recent call last): > File "/usr/local/viewcvs-1.0-dev/lib/viewcvs.py", line 3351, in main > request.run_viewcvs() > File "/usr/local/viewcvs-1.0-dev/lib/viewcvs.py", line 228, in run_viewcvs > % self.where, '403 Forbidden') > ViewCVSException: 403 Forbidden: Access to > "maven/archetype/trunk/maven-archetype-core" is forbidden. > ~~ -- 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-42) Maven IDEA Plugin does not respect dependency exclusions
[ http://jira.codehaus.org/browse/MIDEA-42?page=all ] Brett Porter updated MIDEA-42: -- Fix Version: 2.0 > Maven IDEA Plugin does not respect dependency exclusions > > > Key: MIDEA-42 > URL: http://jira.codehaus.org/browse/MIDEA-42 > Project: Maven 2.x Idea Plugin > Type: Bug > Environment: WinXP, JDK 1.5, IDEA 5.1, Maven 2.0.3, maven-idea-plugin > 2.0-beta-2-SNAPSHOT (built from source) > Reporter: Wendy Smoak > Fix For: 2.0 > > > To reproduce, use the archetype plugin to create a sample app, then add the > following dependency to pom.xml: > > htmlunit > htmlunit > 1.8 > > > javax.xml > jsr173 > > > > Assuming you do *not* have javax.xml:jsr173:jar:1.0 in your local repo, > 'mvn install' will work fine, but 'mvn idea:idea' will show this: > $ mvn idea:idea > [INFO] Scanning for projects... > [INFO] Searching repository for plugin with prefix: 'idea'. > [INFO] > - > --- > [INFO] Building Maven Quick Start Archetype > [INFO]task-segment: [idea:idea] > [INFO] > - > --- > [INFO] Preparing idea:idea > [INFO] No goals needed for project - skipping > [INFO] [idea:idea] > [WARNING] > Artifact junit:junit:jar:3.8.1:test retains local scope 'test' > overriding broader scope 'compile' > given by a dependency. If this is not intended, modify or remove the > local scope. > Downloading: http://repo1.maven.org/maven2/javax/xml/jsr173/1.0/jsr173-1.0.jar > [WARNING] Unable to get resource from repository central > (http://repo1.maven.org/maven2) > [WARNING] An error occurred during dependency resolution of the following > artifact: > com.example:myapp1.0-SNAPSHOT > Caused by: Missing: > -- > 1) javax.xml:jsr173:jar:1.0 > Try downloading the file manually from: > http://java.sun.com/webservices/downloads/webservicespack.html > Then, install it using the command: > mvn install:install-file -DgroupId=javax.xml -DartifactId=jsr173 \ > -Dversion=1.0 -Dpackaging=jar -Dfile=/path/to/file > Path to dependency: > 1) com.example:myapp:jar:1.0-SNAPSHOT > 2) htmlunit:htmlunit:jar:1.8 > 3) dom4j:dom4j:jar:1.5 > 4) javax.xml:jsr173:jar:1.0 > -- > 1 required artifact is missing. > for artifact: > com.example:myapp:jar:1.0-SNAPSHOT > from the specified remote repositories: > central (http://repo1.maven.org/maven2), > Apache Snapshots (http://cvs.apache.org/maven-snapshot-repository/) > [INFO] Adding resource directory: c:\temp\myapp\src\main\resources > [INFO] jdkName is not set, using [java version1.5.0_06] as default. > [INFO] > > [INFO] BUILD SUCCESSFUL > [INFO] > > [INFO] Total time: 3 seconds > [INFO] Finished at: Tue Mar 28 18:15:59 MST 2006 > [INFO] Final Memory: 3M/6M > [INFO] > > The IDEA config files that are created have no libraries: Settings -> > Modules -> Classpath (Libraries) lists only src/main/resources. -- 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] Moved: (MSUREFIREREP-18) test working with surefire:test generate java.lang.ClassNotFoundException with mvn surefire-report:report
[ http://jira.codehaus.org/browse/MSUREFIREREP-18?page=all ] Brett Porter moved MOJO-121 to MSUREFIREREP-18: --- Key: MSUREFIREREP-18 (was: MOJO-121) Project: Maven 2.x Surefire report Plugin (was: Mojo) > test working with surefire:test generate java.lang.ClassNotFoundException > with mvn surefire-report:report > - > > Key: MSUREFIREREP-18 > URL: http://jira.codehaus.org/browse/MSUREFIREREP-18 > Project: Maven 2.x Surefire report Plugin > Type: Bug > Reporter: Olivier Lamy > > > mvn -Dtest=TestWhirlyWrapper surefire:test works fine > Launch the exception : > 2005-11-14 23:33:01,902 WARN cache.CacheFactory : Exception > java.lang.ClassNotFoundException pour la création du cache de > com.accor.commons.cache.samples.SimpleBeanCachable avec le type de cache > java.lang.ClassNotFoundException: > at java.lang.Class.forName0(Native Method) > at java.lang.Class.forName(Class.java:141) > at > com.accor.commons.cache.CacheFactory.getClassCache(CacheFactory.java:139) > at > com.accor.commons.cache.CacheFactory.reloadCache(CacheFactory.java:111) > at com.accor.TestWhirlyWrapper.testcleanall(TestWhirlyWrapper.java:194) > 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:324) > at junit.framework.TestCase.runTest(TestCase.java:154) > at junit.framework.TestCase.runBare(TestCase.java:127) > at junit.framework.TestResult$1.protect(TestResult.java:106) > at junit.framework.TestResult.runProtected(TestResult.java:124) > at junit.framework.TestResult.run(TestResult.java:109) > at junit.framework.TestCase.run(TestCase.java:118) > at junit.framework.TestSuite.runTest(TestSuite.java:208) > at junit.framework.TestSuite.run(TestSuite.java:203) > 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:324) > at > org.codehaus.surefire.battery.JUnitBattery.executeJUnit(JUnitBattery.java:246) > at > org.codehaus.surefire.battery.JUnitBattery.execute(JUnitBattery.java:220) > at org.codehaus.surefire.Surefire.executeBattery(Surefire.java:204) > at org.codehaus.surefire.Surefire.run(Surefire.java:153) > at org.codehaus.surefire.Surefire.run(Surefire.java:77) > 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:324) > at org.codehaus.surefire.SurefireBooter.run(SurefireBooter.java:104) > at org.apache.maven.test.SurefirePlugin.execute(SurefirePlugin.java:303) > at > org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:399) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:519) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:469) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.forkProjectLifecycle(DefaultLifecycleExecutor.java:789) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.forkLifecycle(DefaultLifecycleExecutor.java:718) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:496) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:482) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:452) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:301) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:268) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:137) > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:316) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:113) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:249) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.Nati
[jira] Moved: (MSUREFIREREP-19) Add i18n functionalities to surefire report plugin
[ http://jira.codehaus.org/browse/MSUREFIREREP-19?page=all ] Brett Porter moved MOJO-21 to MSUREFIREREP-19: -- Key: MSUREFIREREP-19 (was: MOJO-21) Project: Maven 2.x Surefire report Plugin (was: Mojo) > Add i18n functionalities to surefire report plugin > --- > > Key: MSUREFIREREP-19 > URL: http://jira.codehaus.org/browse/MSUREFIREREP-19 > Project: Maven 2.x Surefire report Plugin > Type: Improvement > Reporter: Johnny R. Ruiz III > Assignee: Johnny R. Ruiz III > > Original Estimate: 5 hours >Time Spent: 5 hours > Remaining: 0 minutes > > - Add i18n functionalities to surefire report plugin > - Add javadoc comments -- 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] Moved: (MCHANGELOG-19) The time in the timestamp of the changelog report is always 00:00:00
[ http://jira.codehaus.org/browse/MCHANGELOG-19?page=all ] Brett Porter moved MOJO-153 to MCHANGELOG-19: - Key: MCHANGELOG-19 (was: MOJO-153) Project: Maven 2.x Changelog Plugin (was: Mojo) > The time in the timestamp of the changelog report is always 00:00:00 > > > Key: MCHANGELOG-19 > URL: http://jira.codehaus.org/browse/MCHANGELOG-19 > Project: Maven 2.x Changelog Plugin > Type: Bug > Environment: OSX 10.4.3, java 1.4.2_09 > Reporter: Julian Wood > Assignee: Edwin Punzalan > Priority: Minor > Attachments: MNG-78-changelog-maven-plugin.patch, > MOJO-153-changelog-maven-plugin.patch > > > The time in the timestamp of the changelog report is always 00:00:00 > The ChangeLogHandler ignores the time element in changelog.xml. One solution > is to handle that element, as in the attached patch. -- 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] Moved: (MCHANGELOG-20) You must use the id tag when listing developers in your POM, otherwise NPE if using the changelog plugin
[ http://jira.codehaus.org/browse/MCHANGELOG-20?page=all ]
Brett Porter moved MOJO-149 to MCHANGELOG-20:
-
Key: MCHANGELOG-20 (was: MOJO-149)
Project: Maven 2.x Changelog Plugin (was: Mojo)
> You must use the id tag when listing developers in your POM, otherwise NPE if
> using the changelog plugin
>
>
> Key: MCHANGELOG-20
> URL: http://jira.codehaus.org/browse/MCHANGELOG-20
> Project: Maven 2.x Changelog Plugin
> Type: Bug
> Environment: OSX 10.4.3, java 1.4.2._09,
> changelog-maven-plugin-2.0-beta-2-SNAPSHOT
> Reporter: Julian Wood
> Assignee: Edwin Punzalan
>
>
> If you don't add an id tag to your developer in your pom (which is not
> required), and you configure a changelog report, then this piece of code will
> generate an NPE, because you can't add a null key to a Hashtable:
> ChangeLog.java
> --
> private Properties getUserList()
> {
> Properties userList = new Properties();
>
> Developer developer = null;
> for (Iterator i = getDevelopers().iterator(); i.hasNext();)
> {
> developer = (Developer) i.next();
> userList.put(developer.getId(), developer.getName());
> }
>
> return userList;
> }
> --
> [INFO] Generate "changelog" report.
> [INFO] Generating changed sets xml to:
> /Volumes/Jaguar/Users/woodj/Documents/pmgt/pmgt/trunk/pmgt-jar/target/changelog.xml
> [INFO] SCM Working Directory:
> /Volumes/Jaguar/Users/woodj/Documents/pmgt/pmgt/trunk/pmgt-jar/src/main/java
> [INFO] SCM Command Line[0]: svn
> [INFO] SCM Command Line[1]: log
> [INFO] SCM Command Line[2]: -v
> [INFO] SCM Command Line[3]: -r{2005-11-29}:{2005-10-29}
> [INFO] ChangeSet between 2005-10-29 and 2005-11-29: 14 entries
> [INFO]
>
> [ERROR] FATAL ERROR
> [INFO]
>
> [INFO] null
> [INFO]
>
> [DEBUG] Trace
> java.lang.NullPointerException
> at java.util.Hashtable.put(Hashtable.java:398)
> at
> org.apache.maven.changelog.ChangeLog.getUserList(ChangeLog.java:530)
> at
> org.apache.maven.changelog.ChangeLog.replaceAuthorIdWithName(ChangeLog.java:541)
> at org.apache.maven.changelog.ChangeLog.doExecute(ChangeLog.java:370)
> at
> org.apache.maven.changelog.ChangeLogReport.getChangeLog(ChangeLogReport.java:263)
> at
> org.apache.maven.changelog.ChangeLogReport.generateChangeSetsFromSCM(ChangeLogReport.java:218)
> at
> org.apache.maven.changelog.ChangeLogReport.getChangedSets(ChangeLogReport.java:198)
> at
> org.apache.maven.changelog.ChangeLogReport.executeReport(ChangeLogReport.java:173)
> at
> org.apache.maven.reporting.AbstractMavenReport.generate(AbstractMavenReport.java:117)
> at
> org.apache.maven.plugins.site.SiteMojo.generateReportsPages(SiteMojo.java:802)
> at org.apache.maven.plugins.site.SiteMojo.execute(SiteMojo.java:301)
> at
> org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:412)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:519)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:469)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:448)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:301)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:268)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:137)
> 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: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)
> [INFO]
>
[jira] Moved: (MCHANGES-3) Improve the documentation such that the location of changes.xml and report types are apparent.
[ http://jira.codehaus.org/browse/MCHANGES-3?page=all ] Brett Porter moved MOJO-156 to MCHANGES-3: -- Workflow: jira (was: Maven New) Key: MCHANGES-3 (was: MOJO-156) Project: Maven 2.x Changes Plugin (was: Mojo) > Improve the documentation such that the location of changes.xml and report > types are apparent. > -- > > Key: MCHANGES-3 > URL: http://jira.codehaus.org/browse/MCHANGES-3 > Project: Maven 2.x Changes Plugin > Type: Improvement > Environment: osx 10.4.3, java 1.4.2_09 > Reporter: Julian Wood > Assignee: Corridor Software Developer > Priority: Minor > Attachments: MNG-28-changes-maven-plugin.patch > > > Documentation currently states that changes.xml must be in your xdoc folder. > I think it should be in the site folder. > There should also be some report configuration examples so that you can see > how to run only changes or jira. -- 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] Moved: (MCHANGES-2) default xmlPath should be the same in changes-report and announcement-generate
[ http://jira.codehaus.org/browse/MCHANGES-2?page=all ]
Brett Porter moved MOJO-125 to MCHANGES-2:
--
Workflow: jira (was: Maven New)
Key: MCHANGES-2 (was: MOJO-125)
Project: Maven 2.x Changes Plugin (was: Mojo)
> default xmlPath should be the same in changes-report and announcement-generate
> --
>
> Key: MCHANGES-2
> URL: http://jira.codehaus.org/browse/MCHANGES-2
> Project: Maven 2.x Changes Plugin
> Type: Improvement
> Reporter: Yann Le Du
>
>
> changes-maven-plugin 2.0-beta-1
> Default xmlPath is
>* in changes-report : ${basedir}/src/changes/changes.xml
>* in announcement-generate : ${basedir}/src/main/changes.xml
> It would be nice they be the same.
--
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] Moved: (MCHANGELOG-22) dev-activity report returns changelog report instead
[ http://jira.codehaus.org/browse/MCHANGELOG-22?page=all ] Brett Porter moved MOJO-37 to MCHANGELOG-22: Fix Version: (was: 2.0) 2.0 Component: (was: changelog) Key: MCHANGELOG-22 (was: MOJO-37) Project: Maven 2.x Changelog Plugin (was: Mojo) > dev-activity report returns changelog report instead > > > Key: MCHANGELOG-22 > URL: http://jira.codehaus.org/browse/MCHANGELOG-22 > Project: Maven 2.x Changelog Plugin > Type: Bug > Reporter: Brett Porter > Assignee: Edwin Punzalan > Fix For: 2.0 > > Time Spent: 15 minutes >Remaining: 0 minutes > > m2 clean:clean changelog:dev-activity > gives me the changelog report, not the developer activity 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] Moved: (MCHANGELOG-21) dev-activity report return with a NPE
[ http://jira.codehaus.org/browse/MCHANGELOG-21?page=all ] Brett Porter moved MOJO-42 to MCHANGELOG-21: Fix Version: (was: 2.0) 2.0 Component: (was: changelog) Key: MCHANGELOG-21 (was: MOJO-42) Project: Maven 2.x Changelog Plugin (was: Mojo) > dev-activity report return with a NPE > - > > Key: MCHANGELOG-21 > URL: http://jira.codehaus.org/browse/MCHANGELOG-21 > Project: Maven 2.x Changelog Plugin > Type: Bug > Reporter: Edwin Punzalan > Fix For: 2.0 > > Time Spent: 5 minutes >Remaining: 0 minutes > > Even with the correct scm and developer pom.xml sections -- 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
