[jira] Commented: (DOXIA-208) change the default link from an anchor to a relative page in the apt format
[
http://jira.codehaus.org/browse/DOXIA-208?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_121625
]
Lukas Theussl commented on DOXIA-208:
-
viz changing apt: this was already proposed (and rejected) at DOXIA-47. Even
though we are now discussing changes to the original apt format
(http://docs.codehaus.org/display/DOXIA/Proposed+Changes+to+the+APT+Format) I'm
not in favor of this particular change, because it's not motivated by a
necessary bug fix or missing feature. IMO we risk more by confusing users and
breaking things than we gain by a more intuitive behavior.
viz. xhtml sink: there is an issue to discuss I think, eg I don't see why one
should be forced to use {{href="./other.html"}} instead of just
{{href="other.html"}} in an xdoc document (in apt you have to because there is
no other way to distinguish internal from external links).
I think we can easily define how parsers should emit link events {{link( String
name )}} : if name starts with # it's an internal link and the receiving sink
can decide what to do with it. The StructureSink.isExternalLink method is apt
specific, it should not be used by other sinks.
> change the default link from an anchor to a relative page in the apt format
> ---
>
> Key: DOXIA-208
> URL: http://jira.codehaus.org/browse/DOXIA-208
> Project: Maven Doxia
> Issue Type: Improvement
> Components: Module - Xhtml
>Affects Versions: 1.0-alpha-10
>Reporter: Andrew Williams
>
> To be inline with wikis and other formats the APT link "MyLink" should be a
> relative link whereas "#MyLink" would link to an anchor.
> This is a deviation from the apt format, but would remove confusion for new
> users and those working on supporting multiple formats.
> Edit: this is an issue with the XHTML sink, not the apt parser - anything
> link "MyLink" will be spat out as "#MyLink"
--
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: (SUREFIRE-445) Surefire-Booter Manifest not correct
Surefire-Booter Manifest not correct Key: SUREFIRE-445 URL: http://jira.codehaus.org/browse/SUREFIRE-445 Project: Maven Surefire Issue Type: Bug Affects Versions: 2.4 Reporter: Joerg Lauer Attachments: sources.zip, surefire-booter-patch.diff The manifest of the jar file created by the surefire-booter seems to be written incorrectly. For one, it is missing the Manifest-Version, which according to the spec is required. I noticed because some tests were failing to be executed only for specific users. I have so far been unable to find the exact problem. But after patching the ManifestWriter to use the java.util.jar packages and the ForkConfiguration and ManifestWriterTest to set the Manifest-Version it seems to work fine. I have attached the diff and the complete source code for the three patched classes to this issue. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (WAGONHTTP-17) Use standalone version of httpclient
[ http://jira.codehaus.org/browse/WAGONHTTP-17?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_121631 ] Don Brown commented on WAGONHTTP-17: The diff fixes the pom.xml to use the new standalone version of httpclient. The jar is the standalone version that would need to be deployed to a repo somewhere. The build.xml is what I used to create the standalone version. > Use standalone version of httpclient > > > Key: WAGONHTTP-17 > URL: http://jira.codehaus.org/browse/WAGONHTTP-17 > Project: wagon-http > Issue Type: Improvement >Reporter: Don Brown > Attachments: build.xml, commons-httpclient-3.1-standalone.jar, > httpclient-standalone.diff > > > The current dependency on httpclient brings in commons-logging and > commons-codec, the former of which causes all sorts of problems with plugins > when bundled in the maven uber jar as the default http wagon implementation. > I created a jarjar version of commons-httpclient 3.1, which includes the two > dependencies but renamed so they don't conflict with 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: (WAGONHTTP-17) Use standalone version of httpclient
[ http://jira.codehaus.org/browse/WAGONHTTP-17?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Don Brown updated WAGONHTTP-17: --- Attachment: httpclient-standalone.diff > Use standalone version of httpclient > > > Key: WAGONHTTP-17 > URL: http://jira.codehaus.org/browse/WAGONHTTP-17 > Project: wagon-http > Issue Type: Improvement >Reporter: Don Brown > Attachments: build.xml, commons-httpclient-3.1-standalone.jar, > httpclient-standalone.diff > > > The current dependency on httpclient brings in commons-logging and > commons-codec, the former of which causes all sorts of problems with plugins > when bundled in the maven uber jar as the default http wagon implementation. > I created a jarjar version of commons-httpclient 3.1, which includes the two > dependencies but renamed so they don't conflict with 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: (WAGONHTTP-17) Use standalone version of httpclient
[ http://jira.codehaus.org/browse/WAGONHTTP-17?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Don Brown updated WAGONHTTP-17: --- Attachment: commons-httpclient-3.1-standalone.jar > Use standalone version of httpclient > > > Key: WAGONHTTP-17 > URL: http://jira.codehaus.org/browse/WAGONHTTP-17 > Project: wagon-http > Issue Type: Improvement >Reporter: Don Brown > Attachments: build.xml, commons-httpclient-3.1-standalone.jar, > httpclient-standalone.diff > > > The current dependency on httpclient brings in commons-logging and > commons-codec, the former of which causes all sorts of problems with plugins > when bundled in the maven uber jar as the default http wagon implementation. > I created a jarjar version of commons-httpclient 3.1, which includes the two > dependencies but renamed so they don't conflict with 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] Created: (WAGONHTTP-17) Use standalone version of httpclient
Use standalone version of httpclient Key: WAGONHTTP-17 URL: http://jira.codehaus.org/browse/WAGONHTTP-17 Project: wagon-http Issue Type: Improvement Reporter: Don Brown The current dependency on httpclient brings in commons-logging and commons-codec, the former of which causes all sorts of problems with plugins when bundled in the maven uber jar as the default http wagon implementation. I created a jarjar version of commons-httpclient 3.1, which includes the two dependencies but renamed so they don't conflict with 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-3379) Parallel resolution of artifacts
[ http://jira.codehaus.org/browse/MNG-3379?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Don Brown updated MNG-3379: --- Attachment: parallel-resolution-3.diff Updated patch (version 3) that works with Java 1.4 and eliminates problem with commons-logging (depends on WAGONHTTP-17) > Parallel resolution of artifacts > > > Key: MNG-3379 > URL: http://jira.codehaus.org/browse/MNG-3379 > Project: Maven 2 > Issue Type: New Feature > Components: Artifacts and Repositories >Affects Versions: 2.0.8 >Reporter: Don Brown > Attachments: parallel-resolution-2.diff, parallel-resolution-3.diff, > parallel-resolution.diff > > > Artifacts should be resolved in parallel, grouped by group id's to get around > the lack of synchronization in the local repository. The patch does the > following: > * Use a ThreadPoolExecutor to parallelize artifact resolution, but takes care > not to resolve multiple artifacts from the same group id simultaneously. > (requires Java 5) > * Makes the http wagon the default instead of the poor performing http-client > Disadvantages: > * Requires Java 5, but the backport jars could be substituted pretty easily > * Breaks some plugins due to commons-logging being in the Maven uber jar > (required by commons-httpclient), notably the apt plugin (maybe more should > use the isolatedRealm setting?) > * Screws up the progress monitor as multiple threads are updating it > Advantages: > * Much faster when combined with the http wagon (WAGON-98). I was seeing 40% > improvement on some test builds. -- 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: (WAGONHTTP-17) Use standalone version of httpclient
[ http://jira.codehaus.org/browse/WAGONHTTP-17?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Don Brown updated WAGONHTTP-17: --- Attachment: build.xml > Use standalone version of httpclient > > > Key: WAGONHTTP-17 > URL: http://jira.codehaus.org/browse/WAGONHTTP-17 > Project: wagon-http > Issue Type: Improvement >Reporter: Don Brown > Attachments: build.xml, commons-httpclient-3.1-standalone.jar, > httpclient-standalone.diff > > > The current dependency on httpclient brings in commons-logging and > commons-codec, the former of which causes all sorts of problems with plugins > when bundled in the maven uber jar as the default http wagon implementation. > I created a jarjar version of commons-httpclient 3.1, which includes the two > dependencies but renamed so they don't conflict with 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] Commented: (MCOMPILER-10) display summary information including number of compiler errors when compiler plugin fails.
[ http://jira.codehaus.org/browse/MCOMPILER-10?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_121660 ] Ron Wheeler commented on MCOMPILER-10: -- It would seem that this is something everyone needs fixed and the fix is so small, it is hard to understand why it is not resolved at this time. What is the hang-up? Is there any disagreement about the severity, the nature of the problem or the applicability or robustness of the patch provided? > display summary information including number of compiler errors when compiler > plugin fails. > --- > > Key: MCOMPILER-10 > URL: http://jira.codehaus.org/browse/MCOMPILER-10 > Project: Maven 2.x Compiler Plugin > Issue Type: Bug >Reporter: John Casey >Priority: Minor > Attachments: logExample.bmp, 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] Created: (MECLIPSE-376) Project site documentation is wrong
Project site documentation is wrong --- Key: MECLIPSE-376 URL: http://jira.codehaus.org/browse/MECLIPSE-376 Project: Maven 2.x Eclipse Plugin Issue Type: Bug Components: Documentation Affects Versions: 2.4 Reporter: TJ Herring The public documentation site contains the documentation for version 2.5 which has not been released. Since 2.4 is current, should you revert the site to 2.4? When is 2.5 going to be released? -- 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-3379) Parallel resolution of artifacts
[ http://jira.codehaus.org/browse/MNG-3379?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_121656 ] Chris Custine commented on MNG-3379: Hey Don, you are right, it isn't your patch that broke this. I was testing this patch against 2.0.9-SNAPSHOT from SVN and got your changes intermingled with some recent updates from SVN which broke maven.repo.local setting. > Parallel resolution of artifacts > > > Key: MNG-3379 > URL: http://jira.codehaus.org/browse/MNG-3379 > Project: Maven 2 > Issue Type: New Feature > Components: Artifacts and Repositories >Affects Versions: 2.0.8 >Reporter: Don Brown > Attachments: parallel-resolution-2.diff, parallel-resolution-3.diff, > parallel-resolution.diff > > > Artifacts should be resolved in parallel, grouped by group id's to get around > the lack of synchronization in the local repository. The patch does the > following: > * Use a ThreadPoolExecutor to parallelize artifact resolution, but takes care > not to resolve multiple artifacts from the same group id simultaneously. > (requires Java 5) > * Makes the http wagon the default instead of the poor performing http-client > Disadvantages: > * Requires Java 5, but the backport jars could be substituted pretty easily > * Breaks some plugins due to commons-logging being in the Maven uber jar > (required by commons-httpclient), notably the apt plugin (maybe more should > use the isolatedRealm setting?) > * Screws up the progress monitor as multiple threads are updating it > Advantages: > * Much faster when combined with the http wagon (WAGON-98). I was seeing 40% > improvement on some test builds. -- 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: (MRELEASE-318) Release plugin throws NullPointerException when using version range for dependency
[ http://jira.codehaus.org/browse/MRELEASE-318?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_121645 ] David Hoffer commented on MRELEASE-318: --- Mark, Yes, I prefer the latter secenario as well. It seems this is dependent on MNG-3092, how do we proceed to get resolution? What is the normal maven proceedure to do this? If I can assist in any way, let me know. -Dave > Release plugin throws NullPointerException when using version range for > dependency > -- > > Key: MRELEASE-318 > URL: http://jira.codehaus.org/browse/MRELEASE-318 > Project: Maven 2.x Release Plugin > Issue Type: Bug >Affects Versions: 2.0-beta-7 >Reporter: David Hoffer >Priority: Blocker > Attachments: MNG-3351-unittest.patch, MNG-3351.zip, > MNG-3351_dependency_poms.zip, simple-test-case-console-log.txt, > simple-testcase.zip > > > After upgrading to 2.0.8 I find that the release plugin throws NPE if any > dependency uses version range. > I have one dependency with version range [1.0,2.0) the > rest are test scope with fixed version. > Here is the crash stack trace: > java.lang.NullPointerException: version was null for > com.xrite:xrite-colorlib-api > [13:42:05]: at > org.apache.maven.artifact.DefaultArtifact.getBaseVersion(DefaultArtifact.java:362) > [13:42:05]: at > org.apache.maven.artifact.DefaultArtifact.isSnapshot(DefaultArtifact.java:557) > [13:42:05]: at > org.apache.maven.shared.release.phase.CheckDependencySnapshotsPhase.checkArtifact(CheckDependencySnapshotsPhase.java:252) > [13:42:05]: at > org.apache.maven.shared.release.phase.CheckDependencySnapshotsPhase.checkProject(CheckDependencySnapshotsPhase.java:138) > [13:42:05]: at > org.apache.maven.shared.release.phase.CheckDependencySnapshotsPhase.execute(CheckDependencySnapshotsPhase.java:106) > [13:42:05]: at > org.apache.maven.shared.release.DefaultReleaseManager.prepare(DefaultReleaseManager.java:194) > [13:42:05]: at > org.apache.maven.shared.release.DefaultReleaseManager.prepare(DefaultReleaseManager.java:131) > [13:42:05]: at > org.apache.maven.shared.release.DefaultReleaseManager.prepare(DefaultReleaseManager.java:94) > [13:42:05]: at > org.apache.maven.plugins.release.PrepareReleaseMojo.execute(PrepareReleaseMojo.java:127) > [13:42:05]: at > org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:447) > [13:42:05]: at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:559) > [13:42:05]: at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:513) > [13:42:05]: at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:483) > [13:42:05]: at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:331) > [13:42:05]: at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:228) > [13:42:05]: at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:143) > [13:42:05]: at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:333) > [13:42:05]: at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:126) > [13:42:05]: at org.apache.maven.cli.MavenCli.main(MavenCli.java:282) > [13:42:05]: at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > [13:42:05]: at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > [13:42:05]: at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > [13:42:05]: at java.lang.reflect.Method.invoke(Method.java:597) > [13:42:05]: at > org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) > [13:42:05]: at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) > [13:42:05]: at > org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) > [13:42:05]: at org.codehaus.classworlds.Launcher.main(Launcher.java:375) > It seems the reason version is null is that the call to > selectVersionFromNewRangeIfAvailable() assumes that > versionRange.getRecommendedVersion() will always return non-null, else it > sets the version to null! However during the release:prepare phase this is > not true, see the output: > [13:42:04]: [INFO] [release:prepare] > [13:42:04]: [INFO] Verifying that there are no local modifications... > [13:42:04]: [INFO] Executing: svn --non-interactive status > [13:42:04]: [INFO] Working directory: C:\BuildAgent\work\23044d751bcc9843 > [13:42:05]: [INFO] Checking dependencies and plugins for snapshots ... > [13:42:05]: TEST!!! version=null > [13:42:05]: TEST!!! versionRange=[1.0,2.0) > [13:42:05]: TEST!!! getRecommendedVersion=null > TEST!!! Lines are my tes
[jira] Commented: (MNG-3372) dependency:tree throws exception
[ http://jira.codehaus.org/browse/MNG-3372?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_121643 ] Simon Kitching commented on MNG-3372: - Re provided pom not being usable for testing due to references to non-public jars: I will try to find time to replace the unavailable dependencies with public ones. Sorry, had disabled the ref to our private repo, and removed the obvious references to our private jars but forgot that maven would still pick things up from my local repo dir. I was surprised how many of these jars (40!) are not available; this does show how many OSS projects still do not have jars in the main maven repos! > dependency:tree throws exception > > > Key: MNG-3372 > URL: http://jira.codehaus.org/browse/MNG-3372 > Project: Maven 2 > Issue Type: Bug > Components: Artifacts and Repositories >Affects Versions: 2.0.8 >Reporter: Simon Kitching >Assignee: Brian Fox > Fix For: 2.0.9 > > Attachments: pom.xml > > > Running >mvn -Papache > org.apache.maven.plugins:maven-dependency-plugin:2.0-alpha-5-SNAPSHOT:tree > on a pom containing the following entry throws an exception, unless an > exclusion is applied as shown below. > > jasperreports > jasperreports > 2.0.0 > compile > > > > commons-digester > > commons-digester > > > xml-apis > xml-apis > > > eclipse > jdtcore > > > > > commons-digester > commons-digester > 1.8 > compile > > Exception: > [ERROR] FATAL ERROR > [INFO] > > [INFO] version was null for commons-digester:commons-digester > [INFO] > > [INFO] Trace > java.lang.NullPointerException: version was null for > commons-digester:commons-digester > at > org.apache.maven.artifact.DefaultArtifact.getBaseVersion(DefaultArtifact.java:362) > at > org.apache.maven.artifact.DefaultArtifact.getId(DefaultArtifact.java:225) > at > org.apache.maven.shared.dependency.tree.DependencyTreeResolutionListener.flushDependencyManagement(DependencyTreeResolutionListener.java:524) > at > org.apache.maven.shared.dependency.tree.DependencyTreeResolutionListener.omitForNearer(DependencyTreeResolutionListener.java:209) > at > org.apache.maven.artifact.resolver.DefaultArtifactCollector.fireEvent(DefaultArtifactCollector.java:487) > at > org.apache.maven.artifact.resolver.DefaultArtifactCollector.fireEvent(DefaultArtifactCollector.java:462) > at > org.apache.maven.artifact.resolver.DefaultArtifactCollector.recurse(DefaultArtifactCollector.java:234) > at > org.apache.maven.artifact.resolver.DefaultArtifactCollector.recurse(DefaultArtifactCollector.java:370) > at > org.apache.maven.artifact.resolver.DefaultArtifactCollector.recurse(DefaultArtifactCollector.java:370) > at > org.apache.maven.artifact.resolver.DefaultArtifactCollector.collect(DefaultArtifactCollector.java:76) > at > org.apache.maven.shared.dependency.tree.DefaultDependencyTreeBuilder.buildDependencyTree(DefaultDependencyTreeBuilder.java:102) > at > org.apache.maven.plugin.dependency.TreeMojo.execute(TreeMojo.java:218) > My uneducated guess is that for that particular version of the dependency, > neither the dependency's pom nor any parent pom defines a version for > commons-digester. > PS: dependency:tree rocks! -- 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-3372) dependency:tree throws exception
[ http://jira.codehaus.org/browse/MNG-3372?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_121642 ] Mark Hobson commented on MNG-3372: -- I don't believe that this is a duplicate of MRELEASE-318 (was MNG-3351) since that is an issue in the release manager code. This could certainly be an issue regarding exclusions; I'd suggest trying to replicate the error by adding another unit test to DefaultDependencyTreeBuilderTest in maven-dependency-tree. > dependency:tree throws exception > > > Key: MNG-3372 > URL: http://jira.codehaus.org/browse/MNG-3372 > Project: Maven 2 > Issue Type: Bug > Components: Artifacts and Repositories >Affects Versions: 2.0.8 >Reporter: Simon Kitching >Assignee: Brian Fox > Fix For: 2.0.9 > > Attachments: pom.xml > > > Running >mvn -Papache > org.apache.maven.plugins:maven-dependency-plugin:2.0-alpha-5-SNAPSHOT:tree > on a pom containing the following entry throws an exception, unless an > exclusion is applied as shown below. > > jasperreports > jasperreports > 2.0.0 > compile > > > > commons-digester > > commons-digester > > > xml-apis > xml-apis > > > eclipse > jdtcore > > > > > commons-digester > commons-digester > 1.8 > compile > > Exception: > [ERROR] FATAL ERROR > [INFO] > > [INFO] version was null for commons-digester:commons-digester > [INFO] > > [INFO] Trace > java.lang.NullPointerException: version was null for > commons-digester:commons-digester > at > org.apache.maven.artifact.DefaultArtifact.getBaseVersion(DefaultArtifact.java:362) > at > org.apache.maven.artifact.DefaultArtifact.getId(DefaultArtifact.java:225) > at > org.apache.maven.shared.dependency.tree.DependencyTreeResolutionListener.flushDependencyManagement(DependencyTreeResolutionListener.java:524) > at > org.apache.maven.shared.dependency.tree.DependencyTreeResolutionListener.omitForNearer(DependencyTreeResolutionListener.java:209) > at > org.apache.maven.artifact.resolver.DefaultArtifactCollector.fireEvent(DefaultArtifactCollector.java:487) > at > org.apache.maven.artifact.resolver.DefaultArtifactCollector.fireEvent(DefaultArtifactCollector.java:462) > at > org.apache.maven.artifact.resolver.DefaultArtifactCollector.recurse(DefaultArtifactCollector.java:234) > at > org.apache.maven.artifact.resolver.DefaultArtifactCollector.recurse(DefaultArtifactCollector.java:370) > at > org.apache.maven.artifact.resolver.DefaultArtifactCollector.recurse(DefaultArtifactCollector.java:370) > at > org.apache.maven.artifact.resolver.DefaultArtifactCollector.collect(DefaultArtifactCollector.java:76) > at > org.apache.maven.shared.dependency.tree.DefaultDependencyTreeBuilder.buildDependencyTree(DefaultDependencyTreeBuilder.java:102) > at > org.apache.maven.plugin.dependency.TreeMojo.execute(TreeMojo.java:218) > My uneducated guess is that for that particular version of the dependency, > neither the dependency's pom nor any parent pom defines a version for > commons-digester. > PS: dependency:tree rocks! -- 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-3381) Create a mojo Log to accumulate warning (and higher log-level) messages per project, and output them like error reports in the summary.
Create a mojo Log to accumulate warning (and higher log-level) messages per project, and output them like error reports in the summary. --- Key: MNG-3381 URL: http://jira.codehaus.org/browse/MNG-3381 Project: Maven 2 Issue Type: Improvement Components: Plugins and Lifecycle Affects Versions: 2.0.8, 2.1-alpha-1 Reporter: John Casey currently, it's a mojo's choice whether to throw a MojoExecutionException or MojoFailureException and stop the build when something comes up during its own execution. In many cases, mojos choose to output ERROR or WARNING messages, but these often are drowned in the sheer volume of INFO output to the console. Look into modifying the default mojo Log class to record anything above INFO for recovery later by the CLI reporter methods, so ERROR and WARNING output can be added to the summary for that project. Possibly even a good idea to adjust the summary pronouncement (BUILD SUCCESSFUL, BUILD FAILED) to reflect the presence of this sort of output: BUILD SUCCESSFUL, with warnings or something similar. -- 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: (MRELEASE-318) Release plugin throws NullPointerException when using version range for dependency
[ http://jira.codehaus.org/browse/MRELEASE-318?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Hobson moved MNG-3351 to MRELEASE-318: --- Affects Version/s: (was: 2.0.9) 2.0-beta-7 Key: MRELEASE-318 (was: MNG-3351) Project: Maven 2.x Release Plugin (was: Maven 2) > Release plugin throws NullPointerException when using version range for > dependency > -- > > Key: MRELEASE-318 > URL: http://jira.codehaus.org/browse/MRELEASE-318 > Project: Maven 2.x Release Plugin > Issue Type: Bug >Affects Versions: 2.0-beta-7 >Reporter: David Hoffer >Priority: Blocker > Attachments: MNG-3351.zip, MNG-3351_dependency_poms.zip, > simple-test-case-console-log.txt, simple-testcase.zip > > > After upgrading to 2.0.8 I find that the release plugin throws NPE if any > dependency uses version range. > I have one dependency with version range [1.0,2.0) the > rest are test scope with fixed version. > Here is the crash stack trace: > java.lang.NullPointerException: version was null for > com.xrite:xrite-colorlib-api > [13:42:05]: at > org.apache.maven.artifact.DefaultArtifact.getBaseVersion(DefaultArtifact.java:362) > [13:42:05]: at > org.apache.maven.artifact.DefaultArtifact.isSnapshot(DefaultArtifact.java:557) > [13:42:05]: at > org.apache.maven.shared.release.phase.CheckDependencySnapshotsPhase.checkArtifact(CheckDependencySnapshotsPhase.java:252) > [13:42:05]: at > org.apache.maven.shared.release.phase.CheckDependencySnapshotsPhase.checkProject(CheckDependencySnapshotsPhase.java:138) > [13:42:05]: at > org.apache.maven.shared.release.phase.CheckDependencySnapshotsPhase.execute(CheckDependencySnapshotsPhase.java:106) > [13:42:05]: at > org.apache.maven.shared.release.DefaultReleaseManager.prepare(DefaultReleaseManager.java:194) > [13:42:05]: at > org.apache.maven.shared.release.DefaultReleaseManager.prepare(DefaultReleaseManager.java:131) > [13:42:05]: at > org.apache.maven.shared.release.DefaultReleaseManager.prepare(DefaultReleaseManager.java:94) > [13:42:05]: at > org.apache.maven.plugins.release.PrepareReleaseMojo.execute(PrepareReleaseMojo.java:127) > [13:42:05]: at > org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:447) > [13:42:05]: at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:559) > [13:42:05]: at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:513) > [13:42:05]: at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:483) > [13:42:05]: at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:331) > [13:42:05]: at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:228) > [13:42:05]: at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:143) > [13:42:05]: at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:333) > [13:42:05]: at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:126) > [13:42:05]: at org.apache.maven.cli.MavenCli.main(MavenCli.java:282) > [13:42:05]: at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > [13:42:05]: at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > [13:42:05]: at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > [13:42:05]: at java.lang.reflect.Method.invoke(Method.java:597) > [13:42:05]: at > org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) > [13:42:05]: at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) > [13:42:05]: at > org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) > [13:42:05]: at org.codehaus.classworlds.Launcher.main(Launcher.java:375) > It seems the reason version is null is that the call to > selectVersionFromNewRangeIfAvailable() assumes that > versionRange.getRecommendedVersion() will always return non-null, else it > sets the version to null! However during the release:prepare phase this is > not true, see the output: > [13:42:04]: [INFO] [release:prepare] > [13:42:04]: [INFO] Verifying that there are no local modifications... > [13:42:04]: [INFO] Executing: svn --non-interactive status > [13:42:04]: [INFO] Working directory: C:\BuildAgent\work\23044d751bcc9843 > [13:42:05]: [INFO] Checking dependencies and plugins for snapshots ... > [13:42:05]: TEST!!! version=null > [13:42:05]: TEST!!! versionRange=[1.0,2.0) > [13:42:05]: TEST!!! getRecommendedVersion=null > TEST!!! Lines are my test code so I could see what is going on here. -- This message is automatica
[jira] Created: (MAVENUPLOAD-1913) backport-util-concurrent for Java 1.2 and 1.3
backport-util-concurrent for Java 1.2 and 1.3 - Key: MAVENUPLOAD-1913 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1913 Project: maven-upload-requests Issue Type: Wish Reporter: Taras Puchko http://tarasp.fileave.com/maven2/backport-util-concurrent-java12-3.1-bundle.jar http://backport-jsr166.sourceforge.net/ This package is the backport of java.util.concurrent API, introduced in Java 5.0, to Java 1.2 and 1.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] Updated: (MRELEASE-318) Release plugin throws NullPointerException when using version range for dependency
[ http://jira.codehaus.org/browse/MRELEASE-318?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Hobson updated MRELEASE-318: - Attachment: MNG-3351-unittest.patch This is a problem with the release manager not coping with version ranges when prompting to resolve snapshots. See MNG-3351-unittest.patch to reproduce the problem. To fix this we need to decide what the expected behaviour should be, which really depends on the outcome of MNG-3092. For example, the unit test tries to release a project with a dependency version of [1.0,1.1) when versions 1.0-SNAPSHOT, 1.0 and 1.1-SNAPSHOT are available. If MNG-3092 is not applied, then the range contains 1.1-SNAPSHOT and the user is prompted to set the dependency to the release version. Now do we replace the range with 1.1 for releasing and then reinstate the range for further development? If so, we lose the range information in the released pom (which is the purpose of release-pom.xml) and how do we then increment the range to the next development version? If MNG-3092 is applied, then the range resolves to 1.0, the user is not prompted and release poms will provide the resolved version. In this scenario we would have to extend the prompting code to cater for ranges with snapshot boundaries, for example [1.0,1.1-SNAPSHOT]. Here we would derive the release version to be [1.0,1.1] and proceed with the release. Personally I'm in favour of the latter scenario. > Release plugin throws NullPointerException when using version range for > dependency > -- > > Key: MRELEASE-318 > URL: http://jira.codehaus.org/browse/MRELEASE-318 > Project: Maven 2.x Release Plugin > Issue Type: Bug >Affects Versions: 2.0-beta-7 >Reporter: David Hoffer >Priority: Blocker > Attachments: MNG-3351-unittest.patch, MNG-3351.zip, > MNG-3351_dependency_poms.zip, simple-test-case-console-log.txt, > simple-testcase.zip > > > After upgrading to 2.0.8 I find that the release plugin throws NPE if any > dependency uses version range. > I have one dependency with version range [1.0,2.0) the > rest are test scope with fixed version. > Here is the crash stack trace: > java.lang.NullPointerException: version was null for > com.xrite:xrite-colorlib-api > [13:42:05]: at > org.apache.maven.artifact.DefaultArtifact.getBaseVersion(DefaultArtifact.java:362) > [13:42:05]: at > org.apache.maven.artifact.DefaultArtifact.isSnapshot(DefaultArtifact.java:557) > [13:42:05]: at > org.apache.maven.shared.release.phase.CheckDependencySnapshotsPhase.checkArtifact(CheckDependencySnapshotsPhase.java:252) > [13:42:05]: at > org.apache.maven.shared.release.phase.CheckDependencySnapshotsPhase.checkProject(CheckDependencySnapshotsPhase.java:138) > [13:42:05]: at > org.apache.maven.shared.release.phase.CheckDependencySnapshotsPhase.execute(CheckDependencySnapshotsPhase.java:106) > [13:42:05]: at > org.apache.maven.shared.release.DefaultReleaseManager.prepare(DefaultReleaseManager.java:194) > [13:42:05]: at > org.apache.maven.shared.release.DefaultReleaseManager.prepare(DefaultReleaseManager.java:131) > [13:42:05]: at > org.apache.maven.shared.release.DefaultReleaseManager.prepare(DefaultReleaseManager.java:94) > [13:42:05]: at > org.apache.maven.plugins.release.PrepareReleaseMojo.execute(PrepareReleaseMojo.java:127) > [13:42:05]: at > org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:447) > [13:42:05]: at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:559) > [13:42:05]: at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:513) > [13:42:05]: at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:483) > [13:42:05]: at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:331) > [13:42:05]: at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:228) > [13:42:05]: at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:143) > [13:42:05]: at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:333) > [13:42:05]: at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:126) > [13:42:05]: at org.apache.maven.cli.MavenCli.main(MavenCli.java:282) > [13:42:05]: at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > [13:42:05]: at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > [13:42:05]: at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > [13:42:05]: at java.lang.reflect.Method.invoke(Method.java:597) > [13:42:05]: at > org.codehaus.classw
[jira] Commented: (MRELEASE-318) Release plugin throws NullPointerException when using version range for dependency
[ http://jira.codehaus.org/browse/MRELEASE-318?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_121666 ] Mark Hobson commented on MRELEASE-318: -- David, by carrying on the lengthy discussion on maven-dev I believe.. > Release plugin throws NullPointerException when using version range for > dependency > -- > > Key: MRELEASE-318 > URL: http://jira.codehaus.org/browse/MRELEASE-318 > Project: Maven 2.x Release Plugin > Issue Type: Bug >Affects Versions: 2.0-beta-7 >Reporter: David Hoffer >Priority: Blocker > Attachments: MNG-3351-unittest.patch, MNG-3351.zip, > MNG-3351_dependency_poms.zip, simple-test-case-console-log.txt, > simple-testcase.zip > > > After upgrading to 2.0.8 I find that the release plugin throws NPE if any > dependency uses version range. > I have one dependency with version range [1.0,2.0) the > rest are test scope with fixed version. > Here is the crash stack trace: > java.lang.NullPointerException: version was null for > com.xrite:xrite-colorlib-api > [13:42:05]: at > org.apache.maven.artifact.DefaultArtifact.getBaseVersion(DefaultArtifact.java:362) > [13:42:05]: at > org.apache.maven.artifact.DefaultArtifact.isSnapshot(DefaultArtifact.java:557) > [13:42:05]: at > org.apache.maven.shared.release.phase.CheckDependencySnapshotsPhase.checkArtifact(CheckDependencySnapshotsPhase.java:252) > [13:42:05]: at > org.apache.maven.shared.release.phase.CheckDependencySnapshotsPhase.checkProject(CheckDependencySnapshotsPhase.java:138) > [13:42:05]: at > org.apache.maven.shared.release.phase.CheckDependencySnapshotsPhase.execute(CheckDependencySnapshotsPhase.java:106) > [13:42:05]: at > org.apache.maven.shared.release.DefaultReleaseManager.prepare(DefaultReleaseManager.java:194) > [13:42:05]: at > org.apache.maven.shared.release.DefaultReleaseManager.prepare(DefaultReleaseManager.java:131) > [13:42:05]: at > org.apache.maven.shared.release.DefaultReleaseManager.prepare(DefaultReleaseManager.java:94) > [13:42:05]: at > org.apache.maven.plugins.release.PrepareReleaseMojo.execute(PrepareReleaseMojo.java:127) > [13:42:05]: at > org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:447) > [13:42:05]: at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:559) > [13:42:05]: at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:513) > [13:42:05]: at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:483) > [13:42:05]: at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:331) > [13:42:05]: at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:228) > [13:42:05]: at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:143) > [13:42:05]: at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:333) > [13:42:05]: at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:126) > [13:42:05]: at org.apache.maven.cli.MavenCli.main(MavenCli.java:282) > [13:42:05]: at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > [13:42:05]: at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > [13:42:05]: at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > [13:42:05]: at java.lang.reflect.Method.invoke(Method.java:597) > [13:42:05]: at > org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) > [13:42:05]: at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) > [13:42:05]: at > org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) > [13:42:05]: at org.codehaus.classworlds.Launcher.main(Launcher.java:375) > It seems the reason version is null is that the call to > selectVersionFromNewRangeIfAvailable() assumes that > versionRange.getRecommendedVersion() will always return non-null, else it > sets the version to null! However during the release:prepare phase this is > not true, see the output: > [13:42:04]: [INFO] [release:prepare] > [13:42:04]: [INFO] Verifying that there are no local modifications... > [13:42:04]: [INFO] Executing: svn --non-interactive status > [13:42:04]: [INFO] Working directory: C:\BuildAgent\work\23044d751bcc9843 > [13:42:05]: [INFO] Checking dependencies and plugins for snapshots ... > [13:42:05]: TEST!!! version=null > [13:42:05]: TEST!!! versionRange=[1.0,2.0) > [13:42:05]: TEST!!! getRecommendedVersion=null > TEST!!! Lines are my test code so I could see what is going on here. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the admi
[jira] Created: (MRM-675) Problem with version ranges: "no versions are present in the repository for the artifact with a range"
Problem with version ranges: "no versions are present in the repository for the artifact with a range" -- Key: MRM-675 URL: http://jira.codehaus.org/browse/MRM-675 Project: Archiva Issue Type: Bug Components: build Affects Versions: 1.0 Environment: Linux-x86-32; maven 2.0.8 Reporter: Chris Bonami When I run for example 'mvn package', there's a (indirect) dependency that cannot be resolved; This the part of the pom that causes the problem: commons-beanutils commons-beanutils [1.4,) compile This results in the following error issued by Maven: No versions are present in the repository for the artifact with a range [1.4,) commons-beanutils:commons-beanutils:jar:null from the specified remote repositories: central (http://repo1.maven.org/maven2) If I browse the repository http://repo1.maven.org/maven2, the commons-beanutils jars (several versions) are present. So I assume Archiva cannot handle the range. -- 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: (WAGON-99) Make webdav support automatic
Make webdav support automatic - Key: WAGON-99 URL: http://jira.codehaus.org/browse/WAGON-99 Project: wagon Issue Type: Improvement Components: wagon-webdav Reporter: Paul Gier It would be helpful if projects could be deployed over webdav without requiring the build extensions. What is the reason why the deploy plugin can't automatically use webdav? -- 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: (SUREFIRE-446) Surefire fails to capture TestNG results when forkMode=always
Surefire fails to capture TestNG results when forkMode=always
-
Key: SUREFIRE-446
URL: http://jira.codehaus.org/browse/SUREFIRE-446
Project: Maven Surefire
Issue Type: Bug
Components: process forking
Affects Versions: 2.4
Environment: Maven 2.0.8, JDK 1.5.0_12, WinXP
Reporter: Benjamin Bentmann
Attachments: testng-fork-mode-it.patch
The interplay between {{surefire.Surefire}} and
{{testng.TestNGDirectoryTestSuite}} does not properly notify the ReportManager
such that it reports 0 executed tests after the end of the day. IT to reproduce
attached.
Also confirmed against 2.5-SNAPSHOT.
--
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: (MRM-671) Can't untar archiva with cygwin tar 1.18
[ http://jira.codehaus.org/browse/MRM-671?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_121681 ] Max Bowsher commented on MRM-671: - IIUC, "A lone zero block " is merely a warning, not an error. See PLXCOMP-38 for the bug in plexus-archiver which generates very slightly malformed tar files. > Can't untar archiva with cygwin tar 1.18 > > > Key: MRM-671 > URL: http://jira.codehaus.org/browse/MRM-671 > Project: Archiva > Issue Type: Bug > Components: build >Affects Versions: 1.0 > Environment: Windows XP, cygwin tar 1.18 >Reporter: Dan Fabulich > > When I try to untar archiva on Windows XP with cygwin tar 1.18, I get "tar: A > lone zero block at 49260". Not sure if anything can be done about this bug, > (tar just isn't very standardized across various OSes) but I figured I'd file > it anyway for the record. -- 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: (MCOMPILER-10) display summary information including number of compiler errors when compiler plugin fails.
[ http://jira.codehaus.org/browse/MCOMPILER-10?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy closed MCOMPILER-10. - Resolution: Fixed Fix Version/s: 2.1 fixed in rev 616544. > display summary information including number of compiler errors when compiler > plugin fails. > --- > > Key: MCOMPILER-10 > URL: http://jira.codehaus.org/browse/MCOMPILER-10 > Project: Maven 2.x Compiler Plugin > Issue Type: Bug >Reporter: John Casey >Assignee: Olivier Lamy >Priority: Minor > Fix For: 2.1 > > Attachments: logExample.bmp, 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] Commented: (MNG-3301) is there any problems with proxy i tried every thing with settings.xml i dont why it happening like this we have to fix this issue
[ http://jira.codehaus.org/browse/MNG-3301?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_121699 ] Henri Tremblay commented on MNG-3301: - I had the exact same result and know how to reproduce. I can't tell Vincent is having the same issue. My setup: * settings.xml is in M2_HOME/conf and not in my user profile * I have a proxy defined and a repository mirroring central * antrun plugin is used * antrun is calling the task aiming to a ant file somewhere else >From there, when compiling the project, maven stops using what's in the >settings.xml and * try to download directly from central * don't use the proxy * doesn't use the correct local repository path (so I guess it's using the default) > is there any problems with proxy i tried every thing with settings.xml i dont > why it happening like this we have to fix this issue > -- > > Key: MNG-3301 > URL: http://jira.codehaus.org/browse/MNG-3301 > Project: Maven 2 > Issue Type: Task > Components: Command Line >Affects Versions: 2.0.7 >Reporter: vamsikrishna > > org.apache.maven.lifecycle.LifecycleExecutionException: Missing: > -- > 1) org.apache.maven.wagon:wagon-webdav:jar:1.0-beta-2 > Try downloading the file manually from the project website. > Then, install it using the command: > mvn install:install-file -DgroupId=org.apache.maven.wagon > -DartifactId=wagon-webdav \ > -Dversion=1.0-beta-2 -Dpackaging=jar -Dfile=/path/to/file > Alternatively, if you host your own repository you can deploy the file there: > mvn deploy:deploy-file -DgroupId=org.apache.maven.wagon > -DartifactId=wagon-webdav \ > -Dversion=1.0-beta-2 -Dpackaging=jar -Dfile=/path/to/file \ >-Durl=[url] -DrepositoryId=[id] > Path to dependency: > 1) com.intralinks.qa:qc-super-pom:pom:1.2-SNAPSHOT > 2) org.apache.maven.wagon:wagon-webdav:jar:1.0-beta-2 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MPIR-82) Clarify usage of outputDirectory parameter
[ http://jira.codehaus.org/browse/MPIR-82?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vincent Siveton updated MPIR-82: Assignee: Vincent Siveton patch applied Thanks! > Clarify usage of outputDirectory parameter > -- > > Key: MPIR-82 > URL: http://jira.codehaus.org/browse/MPIR-82 > Project: Maven 2.x Project Info Reports Plugin > Issue Type: Improvement >Affects Versions: 2.0.1 >Reporter: Benjamin Bentmann >Assignee: Vincent Siveton >Priority: Trivial > Fix For: 2.1 > > Attachments: output-directory.patch > > > The plugin's documentation should state that the parameter "outputDirectory" > is ONLY evaluated for standalone runs of a mojo and is ignored when run > during a site generation. Otherwise, confusion is likely. -- 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: (MPIR-82) Clarify usage of outputDirectory parameter
[ http://jira.codehaus.org/browse/MPIR-82?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vincent Siveton closed MPIR-82. --- Resolution: Fixed Fix Version/s: 2.1 > Clarify usage of outputDirectory parameter > -- > > Key: MPIR-82 > URL: http://jira.codehaus.org/browse/MPIR-82 > Project: Maven 2.x Project Info Reports Plugin > Issue Type: Improvement >Affects Versions: 2.0.1 >Reporter: Benjamin Bentmann >Priority: Trivial > Fix For: 2.1 > > Attachments: output-directory.patch > > > The plugin's documentation should state that the parameter "outputDirectory" > is ONLY evaluated for standalone runs of a mojo and is ignored when run > during a site generation. Otherwise, confusion is likely. -- 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: (MRM-676) Provide 302 redirect for latest SNAPSHOT
Provide 302 redirect for latest SNAPSHOT Key: MRM-676 URL: http://jira.codehaus.org/browse/MRM-676 Project: Archiva Issue Type: New Feature Reporter: Dan Fabulich It would be very useful to have a single link that would always give you the latest snapshot jar, e.g.: http://archiva./repository/snapshots/com/my-company/my-app/1.0-SNAPSHOT/my-app-1.0-SNAPSHOT.jar Right now this is 404 because there's no file called -SNAPSHOT.jar; instead, it has a specific jar file with a versioned name, e.g. my-app-20071130.231146-44.jar. It would be handy if Archiva recognized the URL above and provided a 302 redirect to the current latest deployed snapshot. -- 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: (MPIR-80) Add Java requirements to the Dependency Report
[ http://jira.codehaus.org/browse/MPIR-80?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_121700 ] Vincent Siveton commented on MPIR-80: - Your idea is good addon but your path proposes two features: * Java Version * Dependency Repository Locations Create a new issue for the second one. For the first point, IMHO the patch should be against the project-summary.html after the build section. > Add Java requirements to the Dependency Report > -- > > Key: MPIR-80 > URL: http://jira.codehaus.org/browse/MPIR-80 > Project: Maven 2.x Project Info Reports Plugin > Issue Type: New Feature >Affects Versions: 2.0.1 >Reporter: Niall Pemberton > Attachments: maven-projectinfo-dependency-java.patch > > > It would be nice to add a section to the dependency report showing the java > version requirements. > Attaching a patch which discovers the java version and compiler options from > the java-compiler-plugin configuration and outputs a "Java Version" section. > Has an option to configure whether or not this section is shown (default to > false). -- 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: (MPIR-73) Error when running task deploy en maven2.x
[ http://jira.codehaus.org/browse/MPIR-73?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vincent Siveton closed MPIR-73. --- Assignee: Vincent Siveton Resolution: Fixed should be fixed with MPIR-79 > Error when running task deploy en maven2.x > -- > > Key: MPIR-73 > URL: http://jira.codehaus.org/browse/MPIR-73 > Project: Maven 2.x Project Info Reports Plugin > Issue Type: Bug >Reporter: Luiz Alberto da Cruz Rangel Junior >Assignee: Vincent Siveton > > java.lang.NullPointerException > at org.codehaus.plexus.i18n.DefaultI18N.getBundle(DefaultI18N.java:141) > at > org.apache.maven.plugins.site.AbstractSiteMojo.getAvailableLocales(AbstractSiteMojo.java:166) > at > org.apache.maven.plugins.site.SiteDescriptorAttachMojo.execute(SiteDescriptorAttachMojo.java:67) > at > org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:412) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:534) > 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) -- 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: (MPIR-81) DependenciesRenderer logs Exception when it can't find the artifact being built!!!
[ http://jira.codehaus.org/browse/MPIR-81?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vincent Siveton closed MPIR-81. --- Assignee: Vincent Siveton Resolution: Fixed Fix Version/s: 2.1 log a warning instead of error > DependenciesRenderer logs Exception when it can't find the artifact being > built!!! > -- > > Key: MPIR-81 > URL: http://jira.codehaus.org/browse/MPIR-81 > Project: Maven 2.x Project Info Reports Plugin > Issue Type: Bug >Affects Versions: 2.1 >Reporter: Niall Pemberton >Assignee: Vincent Siveton > Fix For: 2.1 > > > Using a version of "Project Info Reports Plugin" built from the current svn > repo produces the following exception stack trace in the output when using > "mvn site" on commons-chain-1.2-SNAPSHOT when that snapshot version isn't in > my local repository. If I do "mvn install" first and then run it works OK. In > both scenarios though the dependecies report is produced OK - seems strange > through to be throuwing an exception when the artifact being built can't be > found! > [ERROR] Artifact: commons-chain:commons-chain:jar:1.2-SNAPSHOT has no file. > org.apache.maven.artifact.resolver.ArtifactNotFoundException: Unable to > download the artifact from any repository > Try downloading the file manually from the project website. > Then, install it using the command: > mvn install:install-file -DgroupId=commons-chain > -DartifactId=commons-chain \ > -Dversion=1.2-SNAPSHOT -Dpackaging=jar -Dfile=/path/to/file > Alternatively, if you host your own repository you can deploy the file there: > mvn deploy:deploy-file -DgroupId=commons-chain -DartifactId=commons-chain > \ > -Dversion=1.2-SNAPSHOT -Dpackaging=jar -Dfile=/path/to/file \ > -Durl=[url] -DrepositoryId=[id] > commons-chain:commons-chain:jar:1.2-SNAPSHOT > from the specified remote repositories: > central (http://repo1.maven.org/maven2) > at > org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:197) > at > org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:73) > at > org.apache.maven.report.projectinfo.dependencies.RepositoryUtils.resolve(RepositoryUtils.java:114) > at > org.apache.maven.report.projectinfo.dependencies.renderer.DependenciesRenderer.renderSectionDependencyFileDetails(DependenciesRenderer.java:339) > at > org.apache.maven.report.projectinfo.dependencies.renderer.DependenciesRenderer.renderBody(DependenciesRenderer.java:176) > at > org.apache.maven.reporting.AbstractMavenReportRenderer.render(AbstractMavenReportRenderer.java:65) > at > org.apache.maven.report.projectinfo.DependenciesReport.executeReport(DependenciesReport.java:158) > at > org.apache.maven.reporting.AbstractMavenReport.generate(AbstractMavenReport.java:101) > at > org.apache.maven.plugins.site.ReportDocumentRenderer.renderDocument(ReportDocumentRenderer.java:139) > at > org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.renderModule(DefaultSiteRenderer.java:269) > at > org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.render(DefaultSiteRenderer.java:101) > at > org.apache.maven.plugins.site.SiteMojo.renderLocale(SiteMojo.java:129) > at org.apache.maven.plugins.site.SiteMojo.execute(SiteMojo.java:96) > at > org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:443) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:539) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:480) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:459) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:311) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:278) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:143) > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:334) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:125) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:280) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) > at java.lang.reflect.Method.invoke(Unknown Source) > at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) > at o
[jira] Commented: (MDEPLOY-52) deploy-file doesn't support updateReleaseInfo
[ http://jira.codehaus.org/browse/MDEPLOY-52?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_121709 ] nadias commented on MDEPLOY-52: --- In the meantime, is there a work around? If so, what is it? > deploy-file doesn't support updateReleaseInfo > - > > Key: MDEPLOY-52 > URL: http://jira.codehaus.org/browse/MDEPLOY-52 > Project: Maven 2.x Deploy Plugin > Issue Type: Improvement >Affects Versions: 2.3 >Reporter: Bernhard Mähr >Priority: Minor > > Hello! > If I deploy a file with deploy-file I would expect the metadata in the > repository is updated. At least it should be possible setting the value > updateReleaseInfo to true (like in deploy). > Greetings > Bernhard Mähr -- 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: (MWAR-116) The outputFileNameMapping config creates bad dependency files in WEB-INF/lib
[
http://jira.codehaus.org/browse/MWAR-116?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_121705
]
Olivier Lamy commented on MWAR-116:
---
we have to change the expressions in this mojo field to something lile @{ }.
Because it won't work. Maven always interpolate expressions like ${} in the pom.
MappingUtils must be changed too because currently it use
RegexBasedInterpolator from p-u because it use only expression like ${ }.
WDYT ?
> The outputFileNameMapping config creates bad dependency files in WEB-INF/lib
>
>
> Key: MWAR-116
> URL: http://jira.codehaus.org/browse/MWAR-116
> Project: Maven 2.x War Plugin
> Issue Type: Bug
>Affects Versions: 2.1-alpha-1
>Reporter: Chris Moesel
>Assignee: Stephane Nicoll
> Fix For: 2.1-alpha-2
>
> Attachments: mwar_93_webapp.zip
>
>
> I've tried using the new outputFileNameMapping feature (MWAR-93) by adding
> the following to my POM:
>
> org.apache.maven.plugins
> maven-war-plugin
> 2.1-alpha-1-SNAPSHOT
>
> ${artifactId}.${extension}
>
>
> This results in really oddly named files in my web-inf/lib now. A typical
> example:
> org.springframework-mywebapp.null
> So, the resulting files are really mapped more like: ${groupId of the
> dependency}-${artifactId of my war module}.null
> I've attached an example Maven 2 project that demonstrates this. Just run
> "mvn package" and look at the result in target.
--
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: (MPIR-83) Include reports for DependencyManagement and PluginManagement
[ http://jira.codehaus.org/browse/MPIR-83?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vincent Siveton closed MPIR-83. --- Assignee: Vincent Siveton Resolution: Fixed Patch applied in r616568. Thanks a lot for this feature and to respect our code style :) FYI I renamed goals to be consistent. > Include reports for DependencyManagement and PluginManagement > - > > Key: MPIR-83 > URL: http://jira.codehaus.org/browse/MPIR-83 > Project: Maven 2.x Project Info Reports Plugin > Issue Type: New Feature >Affects Versions: 2.0.1 >Reporter: Nick Stolwijk >Assignee: Vincent Siveton > Fix For: 2.1 > > Attachments: management-reports.patch, management-reports.zip > > > Create a report for the DependencyManagement and PluginManagement sections of > the 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] Updated: (MPIR-83) Include reports for DependencyManagement and PluginManagement
[ http://jira.codehaus.org/browse/MPIR-83?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vincent Siveton updated MPIR-83: Affects Version/s: 2.0.1 Fix Version/s: 2.1 > Include reports for DependencyManagement and PluginManagement > - > > Key: MPIR-83 > URL: http://jira.codehaus.org/browse/MPIR-83 > Project: Maven 2.x Project Info Reports Plugin > Issue Type: New Feature >Affects Versions: 2.0.1 >Reporter: Nick Stolwijk > Fix For: 2.1 > > Attachments: management-reports.patch, management-reports.zip > > > Create a report for the DependencyManagement and PluginManagement sections of > the 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] Issue Comment Edited: (MPIR-80) Add Java requirements to the Dependency Report
[ http://jira.codehaus.org/browse/MPIR-80?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_121700 ] siveton edited comment on MPIR-80 at 1/29/08 6:08 PM: -- Your idea is a good addon but your patch proposes two features: * Java Version * Dependency Repository Locations So, create a new issue for the second one. For the Java Version point, IMHO the patch should be against the project-summary.html after the build section. Could send us a new patch? was (Author: siveton): Your idea is good addon but your path proposes two features: * Java Version * Dependency Repository Locations Create a new issue for the second one. For the first point, IMHO the patch should be against the project-summary.html after the build section. > Add Java requirements to the Dependency Report > -- > > Key: MPIR-80 > URL: http://jira.codehaus.org/browse/MPIR-80 > Project: Maven 2.x Project Info Reports Plugin > Issue Type: New Feature >Affects Versions: 2.0.1 >Reporter: Niall Pemberton > Attachments: maven-projectinfo-dependency-java.patch > > > It would be nice to add a section to the dependency report showing the java > version requirements. > Attaching a patch which discovers the java version and compiler options from > the java-compiler-plugin configuration and outputs a "Java Version" section. > Has an option to configure whether or not this section is shown (default to > false). -- 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: (MJAVADOC-169) Add support for i18n
[ http://jira.codehaus.org/browse/MJAVADOC-169?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vincent Siveton closed MJAVADOC-169. Assignee: Vincent Siveton Resolution: Fixed Fix Version/s: 2.4 patch applied Thanks Benjamin! > Add support for i18n > > > Key: MJAVADOC-169 > URL: http://jira.codehaus.org/browse/MJAVADOC-169 > Project: Maven 2.x Javadoc Plugin > Issue Type: Improvement >Affects Versions: 2.3 >Reporter: Benjamin Bentmann >Assignee: Vincent Siveton >Priority: Minor > Fix For: 2.4 > > Attachments: i18n.patch > > > Good reporting plugins support i18n and this is a good report plugin, isn't > it? > As for the existing mojo parameters "name" and "description", well, we > already talked about such non-i18n things at SUREFIRE-267. -- 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: (MJAVADOC-138) javadoc:test-javadoc failed if target/classes not already created
[
http://jira.codehaus.org/browse/MJAVADOC-138?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_121712
]
Vincent Siveton commented on MJAVADOC-138:
--
Benjamin, it is not *so* urgent, I am happy to waiting for it :)
> javadoc:test-javadoc failed if target/classes not already created
> -
>
> Key: MJAVADOC-138
> URL: http://jira.codehaus.org/browse/MJAVADOC-138
> Project: Maven 2.x Javadoc Plugin
> Issue Type: Bug
>Affects Versions: 2.3
>Reporter: Vincent Siveton
>
> Using
> {noformat}
> mvn clean javadoc:test-javadoc
> {noformat}
> it could produce unsuccessful build or warning (depending the javadoc version
> used, i.e 1.4 vs 1.5)
> The options file contains:
> {noformat}
> -classpath '[SNIP]/target/classes;[SNIP]/target/tests-classes;...'
> {noformat}
> The explanation is that no target\classes was created before executing
> test-javadoc
--
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-2535) Maven and Continuum sites both list the wrong Continuous Integration server URL
[ http://jira.codehaus.org/browse/MNG-2535?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Fox closed MNG-2535. -- Resolution: Won't Fix This is the correct url > Maven and Continuum sites both list the wrong Continuous Integration server > URL > --- > > Key: MNG-2535 > URL: http://jira.codehaus.org/browse/MNG-2535 > Project: Maven 2 > Issue Type: Bug > Components: Sites & Reporting >Affects Versions: 2.0.4 >Reporter: Binyan > Fix For: Reviewed Pending Version Assignment > > > The url for the continuous integration server for Maven and Continuum is > dead. The presented url is http://maven.zones.apache.org:8080/continuum. -- 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-3369) Improve documentation for AbstractMavenReport.getOutputDirectory()
[ http://jira.codehaus.org/browse/MNG-3369?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Fox closed MNG-3369. -- Assignee: Brian Fox Resolution: Fixed Fix Version/s: Documentation Deficit Patches applied. In the future, try to create the patches from the project level, it makes it easier to locate where the patch belongs. > Improve documentation for AbstractMavenReport.getOutputDirectory() > -- > > Key: MNG-3369 > URL: http://jira.codehaus.org/browse/MNG-3369 > Project: Maven 2 > Issue Type: Improvement > Components: Sites & Reporting >Affects Versions: 2.0.8 >Reporter: Benjamin Bentmann >Assignee: Brian Fox > Fix For: Documentation Deficit > > Attachments: report-output-directory.patch, suite-guide.patch > > > I discovered reporting plugins that struggle to run properly both during a > site generation and during a standalone run because of their wrong usage of > the outputDirectory parameter. A proper documentation of the API could have > prevented that so I tried to add some explaining words to the Javadoc. -- 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: (MASSEMBLY-272) getDescriptor and getDescriptorId should be deprecated.
getDescriptor and getDescriptorId should be deprecated. --- Key: MASSEMBLY-272 URL: http://jira.codehaus.org/browse/MASSEMBLY-272 Project: Maven 2.x Assembly Plugin Issue Type: Improvement Affects Versions: 2.2-beta-1 Reporter: Paul Gier Priority: Minor Attachments: maven-assembly-plugin-deprecation-r616611.patch The instance variables descriptor and descriptorId are deprecated. The matching getter and setter methods should also be deprecated with a comment about replacement. -- 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: (MASSEMBLY-273) Redirect surefire test output to file
Redirect surefire test output to file - Key: MASSEMBLY-273 URL: http://jira.codehaus.org/browse/MASSEMBLY-273 Project: Maven 2.x Assembly Plugin Issue Type: Improvement Environment: Maven 2.0.8 Reporter: Paul Gier Priority: Trivial Attachments: maven-assembly-plugin-test-output-r616613.patch There is a significant amount of debug output being printed to the console during the surefire tests. It might be better to have surefire redirect this to a file. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MASSEMBLY-273) Redirect surefire test output to file
[ http://jira.codehaus.org/browse/MASSEMBLY-273?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Gier closed MASSEMBLY-273. --- Resolution: Duplicate Oops, sorry I didn't realize I already submitted this issue in MASSEMBLY-267 > Redirect surefire test output to file > - > > Key: MASSEMBLY-273 > URL: http://jira.codehaus.org/browse/MASSEMBLY-273 > Project: Maven 2.x Assembly Plugin > Issue Type: Improvement > Environment: Maven 2.0.8 >Reporter: Paul Gier >Priority: Trivial > Attachments: maven-assembly-plugin-test-output-r616613.patch > > > There is a significant amount of debug output being printed to the console > during the surefire tests. It might be better to have surefire redirect this > to a 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] Created: (MAVENUPLOAD-1914) upload xSocket V2.0-alpha-2 & http, multiplexed
upload xSocket V2.0-alpha-2 & http, multiplexed --- Key: MAVENUPLOAD-1914 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1914 Project: maven-upload-requests Issue Type: Wish Reporter: greg please upload all 3 bundles. Thanks -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MASSEMBLY-274) descriptorSourceDirectory should only scan for xml files.
[ http://jira.codehaus.org/browse/MASSEMBLY-274?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Gier updated MASSEMBLY-274: Attachment: maven-assembly-plugin-directoryScan.patch Attaching one line patch to scan only for .xml files. > descriptorSourceDirectory should only scan for xml files. > - > > Key: MASSEMBLY-274 > URL: http://jira.codehaus.org/browse/MASSEMBLY-274 > Project: Maven 2.x Assembly Plugin > Issue Type: Improvement >Reporter: Paul Gier > Attachments: maven-assembly-plugin-directoryScan-it.patch, > maven-assembly-plugin-directoryScan.patch > > > The descriptorSourceDirectory parameter currently treats all files in the > directory like assembly descriptors. Only files ending with .xml should be > picked up as descriptors. I noticed this because the assembly plugin keeps > trying to use files from my .svn directory as assembly descriptors. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MASSEMBLY-274) descriptorSourceDirectory should only scan for xml files.
descriptorSourceDirectory should only scan for xml files. - Key: MASSEMBLY-274 URL: http://jira.codehaus.org/browse/MASSEMBLY-274 Project: Maven 2.x Assembly Plugin Issue Type: Improvement Reporter: Paul Gier Attachments: maven-assembly-plugin-directoryScan-it.patch The descriptorSourceDirectory parameter currently treats all files in the directory like assembly descriptors. Only files ending with .xml should be picked up as descriptors. I noticed this because the assembly plugin keeps trying to use files from my .svn directory as assembly descriptors. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
