[jira] Created: (MDEP-320) Maven Dependency Plugin should provide an option to download components in parallel
Maven Dependency Plugin should provide an option to download components in parallel --- Key: MDEP-320 URL: https://jira.codehaus.org/browse/MDEP-320 Project: Maven 2.x Dependency Plugin Issue Type: Improvement Reporter: Siddharth Shankar Assignee: Brian Fox Priority: Minor In an environment constrained by network speed, or for a server which allocates lower priority to nexus; the download speed is quite slow. This can be quicker by starting the download of artifacts in parallel. I have written a plugin (which provides a goal) to achieve this functionality and I wish to know if I can contribute it for adoption and if so, how? -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MWAR-225) Add support for customizing filtering delimiters like the resources plugin
[
https://jira.codehaus.org/browse/MWAR-225?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=276326#comment-276326
]
philippe tseyen commented on MWAR-225:
--
Same here.
I need to be able to filter with {}, because flex forces me to use that
notation.
Does anyone have a workaround for this?
> Add support for customizing filtering delimiters like the resources plugin
> --
>
> Key: MWAR-225
> URL: https://jira.codehaus.org/browse/MWAR-225
> Project: Maven 2.x WAR Plugin
> Issue Type: Improvement
>Affects Versions: 2.1-beta-1
>Reporter: Peter Runge
>Priority: Minor
>
> After recently upgrading to Maven3 beta1 from alpha7 I noticed that our
> filters were not taking effect any more. We were using '@' for creating
> filer tokens, which used to work alpha7 but no more with beta1.
> In any case, looking at the resources plugin, it has a delimiters property
> that can be used to customize the delimiters when filtering. As suggested by
> http://stackoverflow.com/questions/2315009/override-mavens-default-resource-filter-replacement-pattern
> I set an appropriate property on the resources plugin, but no such property
> exists for the WAR plugin at the moment which means I am stuck. I need to
> keep the delimiter token as '@' because we need to maintain Ant compatibility
> for the time being.
> It would be nice if this property also existed on the WAR plugin so that
> filtering delimiters could be customized.
> The code in the resources plugin that does the job:
> http://maven.apache.org/plugins/maven-resources-plugin/xref/org/apache/maven/plugin/resources/ResourcesMojo.html#233
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MINDEXER-39) study how to have maven-indexer non plexus/sisu dependant
study how to have maven-indexer non plexus/sisu dependant - Key: MINDEXER-39 URL: https://jira.codehaus.org/browse/MINDEXER-39 Project: Maven Indexer Issue Type: Improvement Reporter: Olivier Lamy The current impl is heavy container dependant (plexus/sisu). It could be nice to have something using pure/standard injection (@Inject). As it will be easy reusable in other DI container -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MSHARED-202) Upgrade to plexus-archiver 2.0.1 to get java7 file attribute support
Upgrade to plexus-archiver 2.0.1 to get java7 file attribute support Key: MSHARED-202 URL: https://jira.codehaus.org/browse/MSHARED-202 Project: Maven Shared Components Issue Type: Improvement Reporter: Kristian Rosenvold And get significant performance improvemens for all posix platforms -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MSHARED-202) Upgrade to plexus-archiver 2.0.1 to get java7 file attribute support
[ https://jira.codehaus.org/browse/MSHARED-202?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kristian Rosenvold updated MSHARED-202: --- Fix Version/s: maven-archiver-2.5 Assignee: Kristian Rosenvold > Upgrade to plexus-archiver 2.0.1 to get java7 file attribute support > > > Key: MSHARED-202 > URL: https://jira.codehaus.org/browse/MSHARED-202 > Project: Maven Shared Components > Issue Type: Improvement >Reporter: Kristian Rosenvold >Assignee: Kristian Rosenvold > Fix For: maven-archiver-2.5 > > > And get significant performance improvemens for all posix platforms -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MRELEASE-704) Perform doesn't use developerConnection from the scm tag
Perform doesn't use developerConnection from the scm tag Key: MRELEASE-704 URL: https://jira.codehaus.org/browse/MRELEASE-704 Project: Maven 2.x Release Plugin Issue Type: Bug Components: perform Affects Versions: 2.2.1 Environment: Tried on windows XP, Sun JDK6, maven 3.0.3 Reporter: Mickaël Leduque Priority: Minor The SCM (developer) location is already configured in the project scm tag. The release plugin could allow to use it by default if it is here and no other configuration overrides it. According to MRELEASE-103, it was once the case (after 2.0-beta-5), but it doesn't seem to work anymore. With a pom like http://maven.apache.org/POM/4.0.0"; xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd";> 4.0.0 toto parent pom 1.0-SNAPSHOT scm:svn:http:///test/parent/trunk scm:svn:http:///test/parent/trunk http:///test/parent/trunk maven-release-plugin 2.2.1 I get [ERROR] Failed to execute goal org.apache.maven.plugins:maven-release-plugin:2.2.1:perform (default-cli) on project parent: No SCM URL was provided to perform the release from -> [Help 1] org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal org.apache.maven.plugins:maven-release-plugin:2.2.1:perform (default-cli) on project parent: No SCM URL was provided to perform the release from at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:213) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145) at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84) at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59) at org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183) at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:319) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156) at org.apache.maven.cli.MavenCli.execute(MavenCli.java:534) at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196) at org.apache.maven.cli.MavenCli.main(MavenCli.java:141) 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:597) at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290) at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230) at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409) at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352) Caused by: org.apache.maven.plugin.MojoFailureException: No SCM URL was provided to perform the release from at org.apache.maven.plugins.release.PerformReleaseMojo.execute(PerformReleaseMojo.java:140) at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:107) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209) ... 19 more Caused by: org.apache.maven.shared.release.ReleaseFailureException: No SCM URL was provided to perform the release from at org.apache.maven.shared.release.phase.CheckCompletedPreparePhasesPhase.execute(CheckCompletedPreparePhasesPhase.java:68) at org.apache.maven.shared.release.DefaultReleaseManager.perform(DefaultReleaseManager.java:346) at org.apache.maven.shared.release.DefaultReleaseManager.perform(DefaultReleaseManager.java:293) at org.apache.maven.shared.release.DefaultReleaseManager.perform(DefaultReleaseManager.java:272) at org.apache.maven.plugins.release.PerformReleaseMojo.execute(PerformReleaseMojo.java:132) ... 21 more -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MSHARED-202) Upgrade to plexus-archiver 2.0.1 to get java7 file attribute support
[ https://jira.codehaus.org/browse/MSHARED-202?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kristian Rosenvold closed MSHARED-202. -- Resolution: Fixed > Upgrade to plexus-archiver 2.0.1 to get java7 file attribute support > > > Key: MSHARED-202 > URL: https://jira.codehaus.org/browse/MSHARED-202 > Project: Maven Shared Components > Issue Type: Improvement >Reporter: Kristian Rosenvold >Assignee: Kristian Rosenvold > Fix For: maven-archiver-2.5 > > > And get significant performance improvemens for all posix platforms -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MPMD-127) Report cannot correctly handle external PMD ruleset as exported by Sonar QA Dashboard
[
https://jira.codehaus.org/browse/MPMD-127?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Olivier Lamy closed MPMD-127.
-
Resolution: Fixed
Fix Version/s: 2.6
fixed [rev 1159144|http://svn.apache.org/viewvc?rev=1159144&view=rev]
Thanks !
> Report cannot correctly handle external PMD ruleset as exported by Sonar QA
> Dashboard
> -
>
> Key: MPMD-127
> URL: https://jira.codehaus.org/browse/MPMD-127
> Project: Maven 2.x PMD Plugin
> Issue Type: Bug
> Components: PMD
>Affects Versions: 2.5
> Environment: OS: Microsoft Windows 7 Professional x86 64-bit NL
> Java: JDK 1.6.0_22 64-bit
> Maven: 2.2.1
> Eclipse:
> Maven cmd: clean deploy site:site site:deploy
>Reporter: Tjerk Stroband
>Assignee: Olivier Lamy
> Fix For: 2.6
>
> Attachments: MPMD-127.patch
>
>
> Sonar (http://www.sonarsource.org/) offers a way to centrally manage the PMD
> ruleset configuration and publish the specified configuration on a URL.
> The url takes the following form:
> http://nemo.sonarsource.org/profiles/export?format=pmd&language=java&name=Nemo%2520rules%2520with%2520findbugs
> Plugin config:
> {code:xml}
>
> org.apache.maven.plugins
> maven-pmd-plugin
> 2.5
>
> true
> utf-8
> 1.6
>
>
> http://nemo.sonarsource.org/profiles/export?format=pmd&language=java&name=Nemo%2520rules%2520with%2520findbugs
>
>
>
> {code}
> When generating a PMD report (as part of site:site) the plugin fails (on
> specified environment) with the following error:
> {code}
> [INFO] Generating "PMD Report" report.
> [DEBUG] Preparing ruleset:
> http://nemo.sonarsource.org/profiles/export?format=pmd&language=java&name=Nemo%2520rules%2520with%2520findbugs
> [DEBUG] Before:
> http://nemo.sonarsource.org/profiles/export?format=pmd&language=java&name=Nemo%2520rules%2520with%2520findbugs
> After:
> export?format=pmd&language=java&name=Nemo%2520rules%2520with%2520findbugs
> ..
> [INFO]
>
> [ERROR] BUILD ERROR
> [INFO]
>
> [INFO] Error during page generation
> Embedded error: Error rendering Maven report: Cannot create file-based
> resource:\\\target\export?format=pmd&language=java&name=Nemo%2520rules%2520with%2520findbugs
> (De syntaxis van de bestandsnaam, mapnaam of volumenaam is onjuist)
> [INFO]
>
> [DEBUG] Trace
> org.apache.maven.lifecycle.LifecycleExecutionException: Error during page
> generation
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:719)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:556)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:535)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:387)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:348)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:180)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:328)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:138)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:362)
> at
> org.apache.maven.cli.compat.CompatibleMain.main(CompatibleMain.java:60)
> 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:597)
> at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
> at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
> at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
> at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
> Caused by: org.apache.maven.plugin.MojoExecutionException: Error during page
> generation
> at org.apache.maven.plugins.site.SiteMojo.execute(SiteMojo.java:105)
> at
> org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:490)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:694)
> ... 17 more
> Caused by: org.apache.maven.doxia.siteren
[jira] Commented: (MNG-5087) Maven 3 dependency resolution fails until maven-metadata-local.xml files (created by maven-invoker-plugin) are deleted
[
https://jira.codehaus.org/browse/MNG-5087?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=276343#comment-276343
]
Chas Emerick commented on MNG-5087:
---
Confirmed using aether 1.12 with Maven 3.0.3 resolves this issue.
FYI for others hitting this, the only place I could find aether binaries was
[central|http://repo1.maven.org/maven2/org/sonatype/aether/]. The artifacts in
question are -api, -connector-wagon, -impl, -spi, and -util.
It looks like aether 1.12 was released on 5/30, and other notes around on the
'nets seem to indicate that aether 1.12 fixes a number of problems with maven
3.0.3. Anything that can be done to get a v3.0.4 maven release out that
includes aether 1.12 would be greatly appreciated.
Thanks :-)
> Maven 3 dependency resolution fails until maven-metadata-local.xml files
> (created by maven-invoker-plugin) are deleted
> --
>
> Key: MNG-5087
> URL: https://jira.codehaus.org/browse/MNG-5087
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: Dependencies, Integration Tests
>Affects Versions: 3.0.2, 3.0.3
> Environment: Mac OS X 10.6.x, Java 1.6.0_24
>Reporter: Chas Emerick
>
> In one of my Maven projects, dependency resolution will succeed once, then
> fail for later build attempts:
> {code}
> [WARNING] The POM for commons-logging:commons-logging:jar:1.1.1 is missing,
> no dependency information available
> [WARNING] The POM for commons-httpclient:commons-httpclient:jar:3.1 is
> missing, no dependency information available
> [WARNING] The POM for javax.mail:mail:jar:1.4.4 is missing, no dependency
> information available
> {code}
> ...and so on, until I delete the {{maven-metadata-local.xml}} files
> corresponding to the failing artifacts (e.g.
> {{~/.m2/repository/commons-logging/commons-logging/maven-metadata-local.xml}}),
> which appear to be created by maven-invoker-plugin:install. After those
> files are deleted, the next {{mvn}} invocation proceeds properly; the
> metadata files are restored by that invocation (presumably as part of the
> process of checking my upstream repositories/mirrors for updated artifacts),
> and I am again presented with the above errors until I again delete the
> metadata files.
> This is repeatable, even after starting with a completely fresh local
> repository. Note that Maven 2.2.1 does *NOT* exhibit this problem.
> FYI, I'm not using an integration-testing-only local repo
> [http://maven.apache.org/plugins/maven-invoker-plugin/install-mojo.html#localRepositoryPath|as
> described here], simply because doing so causes the re-downloading of all
> transitive dependencies
> ([http://maven.apache.org/plugins/maven-invoker-plugin/examples/fast-use.html|unless
> you want to maintain an integration-specific settings.xml file!!!]). I've
> used the invoker plugin with a variety of other projects in this way with
> good results ([http://github.com/clojure/tools.nrepl|example]) -- certainly
> never encountering a borked local repository in the process like this.
> Here's an affected project:
> [https://github.com/cemerick/rummage/tree/1.3.0-compat|the 1.3.0-compat
> branch of rummage]. To reproduce, just clone that repo, checkout
> {{1.3.0-compat}}, and:
> {code}
> > mvn clean test
> # no error -- can run this and other builds that don't involve
> maven-invoker-plugin all day w/o problems
> > mvn clean integration-test
> # FAIL: "Could not resolve dependencies", with warnings as noted above
> > mvn clean test
> # FAIL: "Could not resolve dependencies", with warnings as noted above
> {code}
> Once the local repository is broken (by the generation of the
> {{maven-metadata-local.xml}} files, AFAICT), no builds will get past the
> dependency resolution stage.
> Running mvn -X reveals lines like this for each artifact that is later
> apparently not found:
> {code}
> [DEBUG] Verifying availability of
> /Users/chas/.m2/repository/javax/mail/mail/1.4.4/mail-1.4.4.jar from []
> {code}
> Of course,
> {{/Users/chas/.m2/repository/javax/mail/mail/1.4.4/mail-1.4.4.jar}} et al.
> does exist, as does
> {{/Users/chas/.m2/repository/javax/mail/mail/1.4.4/mail-1.4.4.pom}}.
> I'm assuming this is a bug in Maven 3's core dependency resolution mechanisms
> (as opposed to maven-invoker-plugin) since Maven 2.2.1 doesn't exhibit the
> behaviour.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MNG-5087) Maven 3 dependency resolution fails until maven-metadata-local.xml files (created by maven-invoker-plugin) are deleted
[
https://jira.codehaus.org/browse/MNG-5087?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chas Emerick closed MNG-5087.
-
Resolution: Duplicate
Fixed in aether 1.12, will be fixed in maven when a new release is cut that
includes 1.12.
> Maven 3 dependency resolution fails until maven-metadata-local.xml files
> (created by maven-invoker-plugin) are deleted
> --
>
> Key: MNG-5087
> URL: https://jira.codehaus.org/browse/MNG-5087
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: Dependencies, Integration Tests
>Affects Versions: 3.0.2, 3.0.3
> Environment: Mac OS X 10.6.x, Java 1.6.0_24
>Reporter: Chas Emerick
>
> In one of my Maven projects, dependency resolution will succeed once, then
> fail for later build attempts:
> {code}
> [WARNING] The POM for commons-logging:commons-logging:jar:1.1.1 is missing,
> no dependency information available
> [WARNING] The POM for commons-httpclient:commons-httpclient:jar:3.1 is
> missing, no dependency information available
> [WARNING] The POM for javax.mail:mail:jar:1.4.4 is missing, no dependency
> information available
> {code}
> ...and so on, until I delete the {{maven-metadata-local.xml}} files
> corresponding to the failing artifacts (e.g.
> {{~/.m2/repository/commons-logging/commons-logging/maven-metadata-local.xml}}),
> which appear to be created by maven-invoker-plugin:install. After those
> files are deleted, the next {{mvn}} invocation proceeds properly; the
> metadata files are restored by that invocation (presumably as part of the
> process of checking my upstream repositories/mirrors for updated artifacts),
> and I am again presented with the above errors until I again delete the
> metadata files.
> This is repeatable, even after starting with a completely fresh local
> repository. Note that Maven 2.2.1 does *NOT* exhibit this problem.
> FYI, I'm not using an integration-testing-only local repo
> [http://maven.apache.org/plugins/maven-invoker-plugin/install-mojo.html#localRepositoryPath|as
> described here], simply because doing so causes the re-downloading of all
> transitive dependencies
> ([http://maven.apache.org/plugins/maven-invoker-plugin/examples/fast-use.html|unless
> you want to maintain an integration-specific settings.xml file!!!]). I've
> used the invoker plugin with a variety of other projects in this way with
> good results ([http://github.com/clojure/tools.nrepl|example]) -- certainly
> never encountering a borked local repository in the process like this.
> Here's an affected project:
> [https://github.com/cemerick/rummage/tree/1.3.0-compat|the 1.3.0-compat
> branch of rummage]. To reproduce, just clone that repo, checkout
> {{1.3.0-compat}}, and:
> {code}
> > mvn clean test
> # no error -- can run this and other builds that don't involve
> maven-invoker-plugin all day w/o problems
> > mvn clean integration-test
> # FAIL: "Could not resolve dependencies", with warnings as noted above
> > mvn clean test
> # FAIL: "Could not resolve dependencies", with warnings as noted above
> {code}
> Once the local repository is broken (by the generation of the
> {{maven-metadata-local.xml}} files, AFAICT), no builds will get past the
> dependency resolution stage.
> Running mvn -X reveals lines like this for each artifact that is later
> apparently not found:
> {code}
> [DEBUG] Verifying availability of
> /Users/chas/.m2/repository/javax/mail/mail/1.4.4/mail-1.4.4.jar from []
> {code}
> Of course,
> {{/Users/chas/.m2/repository/javax/mail/mail/1.4.4/mail-1.4.4.jar}} et al.
> does exist, as does
> {{/Users/chas/.m2/repository/javax/mail/mail/1.4.4/mail-1.4.4.pom}}.
> I'm assuming this is a bug in Maven 3's core dependency resolution mechanisms
> (as opposed to maven-invoker-plugin) since Maven 2.2.1 doesn't exhibit the
> behaviour.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Reopened: (MNG-5087) Maven 3 dependency resolution fails until maven-metadata-local.xml files (created by maven-invoker-plugin) are deleted
[
https://jira.codehaus.org/browse/MNG-5087?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Bentmann reopened MNG-5087:
And until aether:1.12 is actually included, this issue remains unresolved.
> Maven 3 dependency resolution fails until maven-metadata-local.xml files
> (created by maven-invoker-plugin) are deleted
> --
>
> Key: MNG-5087
> URL: https://jira.codehaus.org/browse/MNG-5087
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: Dependencies, Integration Tests
>Affects Versions: 3.0.2, 3.0.3
> Environment: Mac OS X 10.6.x, Java 1.6.0_24
>Reporter: Chas Emerick
>
> In one of my Maven projects, dependency resolution will succeed once, then
> fail for later build attempts:
> {code}
> [WARNING] The POM for commons-logging:commons-logging:jar:1.1.1 is missing,
> no dependency information available
> [WARNING] The POM for commons-httpclient:commons-httpclient:jar:3.1 is
> missing, no dependency information available
> [WARNING] The POM for javax.mail:mail:jar:1.4.4 is missing, no dependency
> information available
> {code}
> ...and so on, until I delete the {{maven-metadata-local.xml}} files
> corresponding to the failing artifacts (e.g.
> {{~/.m2/repository/commons-logging/commons-logging/maven-metadata-local.xml}}),
> which appear to be created by maven-invoker-plugin:install. After those
> files are deleted, the next {{mvn}} invocation proceeds properly; the
> metadata files are restored by that invocation (presumably as part of the
> process of checking my upstream repositories/mirrors for updated artifacts),
> and I am again presented with the above errors until I again delete the
> metadata files.
> This is repeatable, even after starting with a completely fresh local
> repository. Note that Maven 2.2.1 does *NOT* exhibit this problem.
> FYI, I'm not using an integration-testing-only local repo
> [http://maven.apache.org/plugins/maven-invoker-plugin/install-mojo.html#localRepositoryPath|as
> described here], simply because doing so causes the re-downloading of all
> transitive dependencies
> ([http://maven.apache.org/plugins/maven-invoker-plugin/examples/fast-use.html|unless
> you want to maintain an integration-specific settings.xml file!!!]). I've
> used the invoker plugin with a variety of other projects in this way with
> good results ([http://github.com/clojure/tools.nrepl|example]) -- certainly
> never encountering a borked local repository in the process like this.
> Here's an affected project:
> [https://github.com/cemerick/rummage/tree/1.3.0-compat|the 1.3.0-compat
> branch of rummage]. To reproduce, just clone that repo, checkout
> {{1.3.0-compat}}, and:
> {code}
> > mvn clean test
> # no error -- can run this and other builds that don't involve
> maven-invoker-plugin all day w/o problems
> > mvn clean integration-test
> # FAIL: "Could not resolve dependencies", with warnings as noted above
> > mvn clean test
> # FAIL: "Could not resolve dependencies", with warnings as noted above
> {code}
> Once the local repository is broken (by the generation of the
> {{maven-metadata-local.xml}} files, AFAICT), no builds will get past the
> dependency resolution stage.
> Running mvn -X reveals lines like this for each artifact that is later
> apparently not found:
> {code}
> [DEBUG] Verifying availability of
> /Users/chas/.m2/repository/javax/mail/mail/1.4.4/mail-1.4.4.jar from []
> {code}
> Of course,
> {{/Users/chas/.m2/repository/javax/mail/mail/1.4.4/mail-1.4.4.jar}} et al.
> does exist, as does
> {{/Users/chas/.m2/repository/javax/mail/mail/1.4.4/mail-1.4.4.pom}}.
> I'm assuming this is a bug in Maven 3's core dependency resolution mechanisms
> (as opposed to maven-invoker-plugin) since Maven 2.2.1 doesn't exhibit the
> behaviour.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MSITE-608) aggregating breadcrumb behavior disappears in the presence of a menu in the parent
[
https://jira.codehaus.org/browse/MSITE-608?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=276349#comment-276349
]
Benson Margulies commented on MSITE-608:
Hmm. For me, with the menu, I get one breadcrumb to '.' in the child:
{code}
Version: 1-SNAPSHOT
| http://maven.apache.org";
class="externalLink" title="Maven">Maven
>
Breadcrumb TC Module
>
About
{code}
and without the menu, I get an additional one for the parent.
> aggregating breadcrumb behavior disappears in the presence of a menu in the
> parent
> --
>
> Key: MSITE-608
> URL: https://jira.codehaus.org/browse/MSITE-608
> Project: Maven 2.x and 3.x Site Plugin
> Issue Type: Bug
> Components: multi module
>Affects Versions: 3.0
>Reporter: Benson Margulies
> Attachments: site-breadcrumb-inheritance.jar
>
>
> This may turn out to belong in Doxia. I don't know.
> The attached project consists of an aggregating project and its module. The
> breadcrumbs in the module are, I claim, wrong -- they lack the breadcrumb to
> visit the parent.
> If you remove this menu:
> {code}
>
>
>
> {code}
> from the parent's src/site/site.xml, all is well. Once it's here, the
> parent-level breadcrumb is omitted.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Issue Comment Edited: (MSITE-608) aggregating breadcrumb behavior disappears in the presence of a menu in the parent
[
https://jira.codehaus.org/browse/MSITE-608?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=276349#comment-276349
]
Benson Margulies edited comment on MSITE-608 at 8/18/11 7:26 AM:
-
THis morning, adding and subtracting the menu has no effect, but I still don't
have enough breadcrumbs.
Let me try again to explain what I think I'm complaining about:
PARENT: site.xml defines one breadcrumb.
CHILD: site.xml defines no breadcrumbs.
What I expect in breadcrumbs.
PARENT: defined breadcrumb plus local project name.
CHILD: defined breadcrumb from parent site.xml, another breadcrumb for the
parent, local project tag ('About') as static text.
What I get:
CHILD: defined breadcrumb from parent site, local project tag as static text.
I'm sure that, with some variation on this stuff, I got what I expected in the
test case.
{code}
Version: 1-SNAPSHOT
| http://maven.apache.org";
class="externalLink" title="Maven">Maven
>
Breadcrumb TC Module
>
About
{code}
and without the menu, I get an additional one for the parent.
was (Author: bmargulies):
Hmm. For me, with the menu, I get one breadcrumb to '.' in the child:
{code}
Version: 1-SNAPSHOT
| http://maven.apache.org";
class="externalLink" title="Maven">Maven
>
Breadcrumb TC Module
>
About
{code}
and without the menu, I get an additional one for the parent.
> aggregating breadcrumb behavior disappears in the presence of a menu in the
> parent
> --
>
> Key: MSITE-608
> URL: https://jira.codehaus.org/browse/MSITE-608
> Project: Maven 2.x and 3.x Site Plugin
> Issue Type: Bug
> Components: multi module
>Affects Versions: 3.0
>Reporter: Benson Margulies
> Attachments: site-breadcrumb-inheritance.jar
>
>
> This may turn out to belong in Doxia. I don't know.
> The attached project consists of an aggregating project and its module. The
> breadcrumbs in the module are, I claim, wrong -- they lack the breadcrumb to
> visit the parent.
> If you remove this menu:
> {code}
>
>
>
> {code}
> from the parent's src/site/site.xml, all is well. Once it's here, the
> parent-level breadcrumb is omitted.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MSITE-609) site:deploy is broken
site:deploy is broken
-
Key: MSITE-609
URL: https://jira.codehaus.org/browse/MSITE-609
Project: Maven 2.x and 3.x Site Plugin
Issue Type: Bug
Components: site:deploy
Affects Versions: 3.0
Environment: mvn -version
Apache Maven 2.2.1 (r801777; 2009-08-06 21:16:01+0200)
Java version: 1.6.0_22
Java home: c:\Programme\Java\jdk1.6.0_22\jre
Default locale: de_DE, platform encoding: Cp1252
OS name: "windows xp" version: "5.1" arch: "x86" Family: "windows"
Reporter: Christian M.
Attachments: pom.xml, settings.xml, site_deploy_broken_output.txt
With Maven 2.2.1 and the maven-site-plugin 3.0, site:deploy is not working
anymore. This can be reproduced with the simplest empty project, see attached
pom.xml
The error that occurs is:
java.lang.NoSuchMethodError:
org.codehaus.plexus.PlexusContainer.getContainerRealm()Lorg/codehaus/plexus/classworlds/realm/ClassRealm;
(complete stacktrace attached)
This is in reference to this mail thread:
http://markmail.org/message/ilfbqb2vhiyo5os4
Attached are:
- pom.xml (simple empty project)
- settings.xml (minimal config necessary for deploy)
- output from "mvn -X site:deploy" ("mvn site" was run before)
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MSITE-608) aggregating breadcrumb behavior disappears in the presence of a menu in the parent
[
https://jira.codehaus.org/browse/MSITE-608?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=276353#comment-276353
]
Benson Margulies commented on MSITE-608:
Herve,
I think, in the first place, that I was just working too late last night and
got turned around, since I now see what you see.
I'll work on doc. I guess I'd like to also propose a feature for an addition to
site.xml:
What if:
{code}
{code}
should have the effect in an aggregate project of adding the obvious breadcrumb
to href=".".
> aggregating breadcrumb behavior disappears in the presence of a menu in the
> parent
> --
>
> Key: MSITE-608
> URL: https://jira.codehaus.org/browse/MSITE-608
> Project: Maven 2.x and 3.x Site Plugin
> Issue Type: Bug
> Components: multi module
>Affects Versions: 3.0
>Reporter: Benson Margulies
> Attachments: site-breadcrumb-inheritance.jar
>
>
> This may turn out to belong in Doxia. I don't know.
> The attached project consists of an aggregating project and its module. The
> breadcrumbs in the module are, I claim, wrong -- they lack the breadcrumb to
> visit the parent.
> If you remove this menu:
> {code}
>
>
>
> {code}
> from the parent's src/site/site.xml, all is well. Once it's here, the
> parent-level breadcrumb is omitted.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MSITE-608) aggregating breadcrumb behavior disappears in the presence of a menu in the parent
[
https://jira.codehaus.org/browse/MSITE-608?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benson Margulies updated MSITE-608:
---
Comment: was deleted
(was: THis morning, adding and subtracting the menu has no effect, but I still
don't have enough breadcrumbs.
Let me try again to explain what I think I'm complaining about:
PARENT: site.xml defines one breadcrumb.
CHILD: site.xml defines no breadcrumbs.
What I expect in breadcrumbs.
PARENT: defined breadcrumb plus local project name.
CHILD: defined breadcrumb from parent site.xml, another breadcrumb for the
parent, local project tag ('About') as static text.
What I get:
CHILD: defined breadcrumb from parent site, local project tag as static text.
I'm sure that, with some variation on this stuff, I got what I expected in the
test case.
{code}
Version: 1-SNAPSHOT
| http://maven.apache.org";
class="externalLink" title="Maven">Maven
>
Breadcrumb TC Module
>
About
{code}
and without the menu, I get an additional one for the parent.
)
> aggregating breadcrumb behavior disappears in the presence of a menu in the
> parent
> --
>
> Key: MSITE-608
> URL: https://jira.codehaus.org/browse/MSITE-608
> Project: Maven 2.x and 3.x Site Plugin
> Issue Type: Bug
> Components: multi module
>Affects Versions: 3.0
>Reporter: Benson Margulies
> Attachments: site-breadcrumb-inheritance.jar
>
>
> This may turn out to belong in Doxia. I don't know.
> The attached project consists of an aggregating project and its module. The
> breadcrumbs in the module are, I claim, wrong -- they lack the breadcrumb to
> visit the parent.
> If you remove this menu:
> {code}
>
>
>
> {code}
> from the parent's src/site/site.xml, all is well. Once it's here, the
> parent-level breadcrumb is omitted.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MSITE-607) no documentation for breadcrumbs in the doc of site.xml
[ https://jira.codehaus.org/browse/MSITE-607?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=276354#comment-276354 ] Benson Margulies commented on MSITE-607: This seems cruel to the users. They don't know that we happen to implement the site plugin with doxia, and shoudn't need to follow an additional link. I wonder if I can come up with a cute way to share the content and have it just show up in both places. > no documentation for breadcrumbs in the doc of site.xml > --- > > Key: MSITE-607 > URL: https://jira.codehaus.org/browse/MSITE-607 > Project: Maven 2.x and 3.x Site Plugin > Issue Type: Bug > Components: documentation >Affects Versions: 3.0 >Reporter: Benson Margulies > > Some information from > http://www.sonatype.com/books/mvnref-book/reference/site-generation-sect-tips-tricks.html#site-generation-add-breadcumbs > should be on > http://maven.apache.org/plugins/maven-site-plugin/examples/sitedescriptor.html. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MJAR-140) Performance degredation
[
https://jira.codehaus.org/browse/MJAR-140?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kristian Rosenvold closed MJAR-140.
---
Resolution: Fixed
Fix Version/s: 2.4
Assignee: Kristian Rosenvold
I'm closing this as fixed with the 2.4 release. It is not /as/ fast as 2.3
(unless you use java7), but it's at least better. And correctnes is better than
fast.
> Performance degredation
>
>
> Key: MJAR-140
> URL: https://jira.codehaus.org/browse/MJAR-140
> Project: Maven 2.x JAR Plugin
> Issue Type: Bug
>Affects Versions: 2.3, 2.3.1
>Reporter: Eran Harel
>Assignee: Kristian Rosenvold
> Fix For: 2.4
>
>
> I migrated maven to version 3.0.1 in order to utilize the parallel build
> experimental feature.
> As a result I get the following warning:
> {code}
> [WARNING] *
> [WARNING] * Your build is requesting parallel execution, but project *
> [WARNING] * contains the following plugin(s) that are not marked as *
> [WARNING] * @threadSafe to support parallel building. *
> [WARNING] * While this /may/ work fine, please look for plugin updates*
> [WARNING] * and/or request plugins be made thread-safe. *
> [WARNING] * If reporting an issue, report it against the plugin in*
> [WARNING] * question, not against maven-core *
> [WARNING] *
> [WARNING] The following plugins are not marked @threadSafe in DataBuilder:
> [WARNING] org.apache.maven.plugins:maven-eclipse-plugin:2.8
> [WARNING] org.apache.maven.plugins:maven-jar-plugin:2.2
> [WARNING] *
> {code}
> I upgraded the maven-jar-plugin to the latest version (2.3.1), and the
> message is gone, but now the builds take much longer: minutes added!!!
> The build takes about x 1.5 longer now.
> I also compared the maven 3 parallel build time with the new jar-plugin VS a
> serial build with the old 2.2 plugin version I had. The results are that
> same, while when using the parallel build with the 2.2 plugin I see a
> significant ~30% performance boost.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MJAR-144) need to update dependency of maven-archiver to 2.5
[ https://jira.codehaus.org/browse/MJAR-144?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kristian Rosenvold closed MJAR-144. --- Resolution: Fixed Fix Version/s: 2.4 > need to update dependency of maven-archiver to 2.5 > -- > > Key: MJAR-144 > URL: https://jira.codehaus.org/browse/MJAR-144 > Project: Maven 2.x JAR Plugin > Issue Type: Bug >Affects Versions: 2.3.1 >Reporter: Peter B. > Fix For: 2.4 > > > due to: http://jira.codehaus.org/browse/MSHARED-131 > there is a need up update dependencies to maven-archiver-2.5 > otherwise incorrect META-INF/MANIFEST.MF files are generated, currently I'm > forced to use old 2.2 version of maven-jar-plugin as a workaround. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Reopened: (MJAVADOC-171) Modules in multi-module projects are "built" too often
[ https://jira.codehaus.org/browse/MJAVADOC-171?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Seidel reopened MJAVADOC-171: How many times ... Sorry, but saying it's fixed doesn't mean it is. Why can you not just add a unit test? Here's an addition to the list: 2.8: 26 Sorry to be a nuisance, but what can I do to finally get my site build run properly? Especially since 2.2 or 2.4 do not work with the maven-site-plugin:3.0? > Modules in multi-module projects are "built" too often > -- > > Key: MJAVADOC-171 > URL: https://jira.codehaus.org/browse/MJAVADOC-171 > Project: Maven 2.x Javadoc Plugin > Issue Type: Bug >Affects Versions: 2.3 > Environment: Maven 2.0.8, Linux >Reporter: Stefan Seidel >Assignee: Herve Boutemy >Priority: Critical > Fix For: 2.8 > > Attachments: 2.2.log, 2.3.log, mjavadoc171.patch, mvnexec.zip > > > In a multi-module project, all modules are "built" twice for each module. > This leads to huge performance problems when many modules are in a project. > In the attached sample project, the xmlbeans plugin is executed 27 times for > a project with one parent module and two submodules. 18 of these executions > can be attributed to the javadoc plugin. With version 2.2, only 3 invocations > (once for each project) are caused by the javadoc plugin. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (JXR-87) Change line number anchor name pattern
[
https://jira.codehaus.org/browse/JXR-87?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=276375#comment-276375
]
Neeme Praks commented on JXR-87:
Your patch will break all the links out there that rely on the current format.
I would suggest to include a configuration option to restore the old behavior
for people that cannot update all the other systems that rely on the old
format. But new format should be default as the current format is broken (see
also
http://stackoverflow.com/questions/7110556/is-it-valid-to-use-only-digits-as-uri-fragment-identifier)
> Change line number anchor name pattern
> --
>
> Key: JXR-87
> URL: https://jira.codehaus.org/browse/JXR-87
> Project: Maven JXR
> Issue Type: Improvement
> Components: jxr
>Affects Versions: 2.2
> Environment: Site plugin 2.2
>Reporter: Michael Osipov
> Attachments: JXR-87.patch
>
>
> Linenumber achor anames are solely the line number but this brings problems.
> Then linking in APT to source code, it complains:
> {noformat}
> [WARNING] [APT Parser] Modified invalid link: '77' to
> '../kcc-core/xref/package/Object.html#a77'
> {noformat}
> This means that I am not able to link to lines anymore. Change the anchor
> name pattern to L\d+
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (JXR-87) Change line number anchor name pattern
[
https://jira.codehaus.org/browse/JXR-87?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=276382#comment-276382
]
Michael Osipov commented on JXR-87:
---
True, but it was broken anyway. Doxia was broken too before Maven 2.2.x. That's
the reason I created this patch. Btw, for those who upgrade from Maven 2.0 to
2.2 they see broken links too. So in my opinion there is little harm.
> Change line number anchor name pattern
> --
>
> Key: JXR-87
> URL: https://jira.codehaus.org/browse/JXR-87
> Project: Maven JXR
> Issue Type: Improvement
> Components: jxr
>Affects Versions: 2.2
> Environment: Site plugin 2.2
>Reporter: Michael Osipov
> Attachments: JXR-87.patch
>
>
> Linenumber achor anames are solely the line number but this brings problems.
> Then linking in APT to source code, it complains:
> {noformat}
> [WARNING] [APT Parser] Modified invalid link: '77' to
> '../kcc-core/xref/package/Object.html#a77'
> {noformat}
> This means that I am not able to link to lines anymore. Change the anchor
> name pattern to L\d+
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MJAVADOC-171) Modules in multi-module projects are "built" too often
[ https://jira.codehaus.org/browse/MJAVADOC-171?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Herve Boutemy closed MJAVADOC-171. -- Resolution: Fixed sorry to repeat myself too: if you're still having problems, please open another Jira issue with a link to this one then, please help us make a repeatable IT you're giving numbers I can't calculate myself No doubt you're facing something please help us learn how to calculate same numbers as you: a grep command to show precisely what you are counting, for example but please don't reopen this issue 4 months after we tried to work with you: I don't care if the issue is not really resolved, the new issue is needed just to let us work together at reproducing what you are facing > Modules in multi-module projects are "built" too often > -- > > Key: MJAVADOC-171 > URL: https://jira.codehaus.org/browse/MJAVADOC-171 > Project: Maven 2.x Javadoc Plugin > Issue Type: Bug >Affects Versions: 2.3 > Environment: Maven 2.0.8, Linux >Reporter: Stefan Seidel >Assignee: Herve Boutemy >Priority: Critical > Fix For: 2.8 > > Attachments: 2.2.log, 2.3.log, mjavadoc171.patch, mvnexec.zip > > > In a multi-module project, all modules are "built" twice for each module. > This leads to huge performance problems when many modules are in a project. > In the attached sample project, the xmlbeans plugin is executed 27 times for > a project with one parent module and two submodules. 18 of these executions > can be attributed to the javadoc plugin. With version 2.2, only 3 invocations > (once for each project) are caused by the javadoc plugin. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MJAVADOC-171) Modules in multi-module projects are "built" too often
[ https://jira.codehaus.org/browse/MJAVADOC-171?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Herve Boutemy closed MJAVADOC-171. -- Resolution: Cannot Reproduce > Modules in multi-module projects are "built" too often > -- > > Key: MJAVADOC-171 > URL: https://jira.codehaus.org/browse/MJAVADOC-171 > Project: Maven 2.x Javadoc Plugin > Issue Type: Bug >Affects Versions: 2.3 > Environment: Maven 2.0.8, Linux >Reporter: Stefan Seidel >Assignee: Herve Boutemy >Priority: Critical > Fix For: 2.8 > > Attachments: 2.2.log, 2.3.log, mjavadoc171.patch, mvnexec.zip > > > In a multi-module project, all modules are "built" twice for each module. > This leads to huge performance problems when many modules are in a project. > In the attached sample project, the xmlbeans plugin is executed 27 times for > a project with one parent module and two submodules. 18 of these executions > can be attributed to the javadoc plugin. With version 2.2, only 3 invocations > (once for each project) are caused by the javadoc plugin. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Work started: (MJAVADOC-171) Modules in multi-module projects are "built" too often
[ https://jira.codehaus.org/browse/MJAVADOC-171?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on MJAVADOC-171 started by Herve Boutemy. > Modules in multi-module projects are "built" too often > -- > > Key: MJAVADOC-171 > URL: https://jira.codehaus.org/browse/MJAVADOC-171 > Project: Maven 2.x Javadoc Plugin > Issue Type: Bug >Affects Versions: 2.3 > Environment: Maven 2.0.8, Linux >Reporter: Stefan Seidel >Assignee: Herve Boutemy >Priority: Critical > Fix For: 2.8 > > Attachments: 2.2.log, 2.3.log, mjavadoc171.patch, mvnexec.zip > > > In a multi-module project, all modules are "built" twice for each module. > This leads to huge performance problems when many modules are in a project. > In the attached sample project, the xmlbeans plugin is executed 27 times for > a project with one parent module and two submodules. 18 of these executions > can be attributed to the javadoc plugin. With version 2.2, only 3 invocations > (once for each project) are caused by the javadoc plugin. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Reopened: (MJAVADOC-171) Modules in multi-module projects are "built" too often
[ https://jira.codehaus.org/browse/MJAVADOC-171?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Herve Boutemy reopened MJAVADOC-171: > Modules in multi-module projects are "built" too often > -- > > Key: MJAVADOC-171 > URL: https://jira.codehaus.org/browse/MJAVADOC-171 > Project: Maven 2.x Javadoc Plugin > Issue Type: Bug >Affects Versions: 2.3 > Environment: Maven 2.0.8, Linux >Reporter: Stefan Seidel >Assignee: Herve Boutemy >Priority: Critical > Fix For: 2.8 > > Attachments: 2.2.log, 2.3.log, mjavadoc171.patch, mvnexec.zip > > > In a multi-module project, all modules are "built" twice for each module. > This leads to huge performance problems when many modules are in a project. > In the attached sample project, the xmlbeans plugin is executed 27 times for > a project with one parent module and two submodules. 18 of these executions > can be attributed to the javadoc plugin. With version 2.2, only 3 invocations > (once for each project) are caused by the javadoc plugin. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Work stopped: (MJAVADOC-171) Modules in multi-module projects are "built" too often
[ https://jira.codehaus.org/browse/MJAVADOC-171?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on MJAVADOC-171 stopped by Herve Boutemy. > Modules in multi-module projects are "built" too often > -- > > Key: MJAVADOC-171 > URL: https://jira.codehaus.org/browse/MJAVADOC-171 > Project: Maven 2.x Javadoc Plugin > Issue Type: Bug >Affects Versions: 2.3 > Environment: Maven 2.0.8, Linux >Reporter: Stefan Seidel >Assignee: Herve Boutemy >Priority: Critical > Fix For: 2.8 > > Attachments: 2.2.log, 2.3.log, mjavadoc171.patch, mvnexec.zip > > > In a multi-module project, all modules are "built" twice for each module. > This leads to huge performance problems when many modules are in a project. > In the attached sample project, the xmlbeans plugin is executed 27 times for > a project with one parent module and two submodules. 18 of these executions > can be attributed to the javadoc plugin. With version 2.2, only 3 invocations > (once for each project) are caused by the javadoc plugin. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MJAVADOC-171) Modules in multi-module projects are "built" too often
[ https://jira.codehaus.org/browse/MJAVADOC-171?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=276411#comment-276411 ] Herve Boutemy commented on MJAVADOC-171: I marked the resolution as "Cannot Reproduce" if it helps understanding the effective definitive status of this issue (that effectively seems to not be fixed for you, who are the only guy able to be able to say if it is fixed or not) > Modules in multi-module projects are "built" too often > -- > > Key: MJAVADOC-171 > URL: https://jira.codehaus.org/browse/MJAVADOC-171 > Project: Maven 2.x Javadoc Plugin > Issue Type: Bug >Affects Versions: 2.3 > Environment: Maven 2.0.8, Linux >Reporter: Stefan Seidel >Assignee: Herve Boutemy >Priority: Critical > Fix For: 2.8 > > Attachments: 2.2.log, 2.3.log, mjavadoc171.patch, mvnexec.zip > > > In a multi-module project, all modules are "built" twice for each module. > This leads to huge performance problems when many modules are in a project. > In the attached sample project, the xmlbeans plugin is executed 27 times for > a project with one parent module and two submodules. 18 of these executions > can be attributed to the javadoc plugin. With version 2.2, only 3 invocations > (once for each project) are caused by the javadoc plugin. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-4802) Maven should by default use the environment defined proxy settings
[
https://jira.codehaus.org/browse/MNG-4802?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=276415#comment-276415
]
Christian Schulte commented on MNG-4802:
There is this section in the ${java.home}/jre/lib/net.properties file since JDK
1.5:
{noformat}
# Whether or not the DefaultProxySelector will default to System Proxy
# settings when they do exist.
# Set it to 'true' to enable this feature and check for platform
# specific proxy settings
# Note that the system properties that do explicitely set proxies
# (like http.proxyHost) do take precedence over the system settings
# even if java.net.useSystemProxies is set to true.
java.net.useSystemProxies=false
{noformat}
Setting this property to true should do exactly this.
> Maven should by default use the environment defined proxy settings
> --
>
> Key: MNG-4802
> URL: https://jira.codehaus.org/browse/MNG-4802
> Project: Maven 2 & 3
> Issue Type: New Feature
> Components: Settings
>Affects Versions: 2.2.1
>Reporter: Hugo Palma
>
> For people that constantly change places of work it's very annoying having to
> edit the settings.xml files every time.
> It would be great if the environment proxy settings were used when no proxy
> settings were defined in settings.xml.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (ARCHETYPE-193) Description of requiredProperty
[ https://jira.codehaus.org/browse/ARCHETYPE-193?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Herve Boutemy updated ARCHETYPE-193: Fix Version/s: (was: 2.1) 2.x > Description of requiredProperty > --- > > Key: ARCHETYPE-193 > URL: https://jira.codehaus.org/browse/ARCHETYPE-193 > Project: Maven Archetype > Issue Type: New Feature > Components: Generator >Affects Versions: 2.0-alpha-3 > Environment: windows xp sp2; java sun 1.6.0_07; maven 2.0.9 >Reporter: Marcelo Romulo Fernandes > Fix For: 2.x > > > Could we show a description of the requiredProperty to the user instead of > their name at generator prompt? > I think it could be more user friendly! I have to provide an extra readme.txt > to explain how to use the requiredProperties. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (ARCHETYPE-334) Run a build on generated project during integration test
[
https://jira.codehaus.org/browse/ARCHETYPE-334?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Herve Boutemy updated ARCHETYPE-334:
Fix Version/s: (was: 2.1)
2.x
> Run a build on generated project during integration test
>
>
> Key: ARCHETYPE-334
> URL: https://jira.codehaus.org/browse/ARCHETYPE-334
> Project: Maven Archetype
> Issue Type: New Feature
> Components: Plugin
>Affects Versions: 2.0-alpha-5
>Reporter: Jesse Glick
>Priority: Minor
> Fix For: 2.x
>
>
> Currently it seems that {{archetype:integration-test}} just creates some
> projects from the archetype with defined parameters and compares their
> contents to "golden" copies. (By the way
> http://maven.apache.org/archetype/maven-archetype-plugin/integration-test-mojo.html
> does not document this in any way; I had to read {{IntegrationTestMojo}}
> source to find this out.)
> While that might be useful if you happen to have very complex Velocity
> templates and need to test that property substitution works the right way
> with different inputs, most archetypes have rather simple templates that just
> substitute {{artifactId}} and the like, in which case verifying that the
> created POM matches some fixed text is worse than useless: if you make any
> changes to the archetype, you are simply going to make identical changes to
> the test's golden files.
> What would be much more useful in my experience is to check that the newly
> generated project actually builds. For example, run {{mvn post-clean verify}}
> and check that at a minimum the build completes normally. This would catch
> common mistakes you might make when editing archetypes: mistyping a plugin or
> dependency name, introducing compilation errors into Java sources, etc. It
> would also be valuable to check that no warnings are emitted - such as the
> infamous {{File encoding has not been set...}} message when
> {{project.build.sourceEncoding}} has been forgotten.
> (You could also run {{mvn post-site}}, checking for warnings/errors, and
> compare {{target/site}} to a golden copy.)
> CI builders running integration tests might also do so with a pristine local
> repository (plus cache manager mirroring official public repos), which would
> catch accidental references to unreleased plugin/dependency versions that the
> archetype developer happened to have in their local repo.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MJAVADOC-324) Dependency sources support appears to require javadoc-resources
Dependency sources support appears to require javadoc-resources --- Key: MJAVADOC-324 URL: https://jira.codehaus.org/browse/MJAVADOC-324 Project: Maven 2.x Javadoc Plugin Issue Type: Bug Affects Versions: 2.8 Environment: Win 7 Reporter: Brian Albers Priority: Critical I cannot seem to get the support to work. Although I have scoped the dependencies down using various combinations of and , as well as setting to false, no iteration ever succeeds. Instead, the javadoc:jar goal complains of being unable to find the "javadoc-resources" for a whole slew of dependencies. None of my projects or dependencies use javadoc-resources. They are all very basic Javascript JARs with minimal configuration. I noticed that part of the 2.7 release (revision 933380) added support for javadoc-resource bundle aggregation, as well. Is the javadoc-resources search not scoped to the include/exclude list? -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MSITE-609) site:deploy is broken
[
https://jira.codehaus.org/browse/MSITE-609?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=276430#comment-276430
]
Lukas Theussl commented on MSITE-609:
-
The problem is the empty element in your settings.xml, remove
that line and it works. I thought this was fixed with MSITE-546, but the error
is different and it only happens with maven 2.
> site:deploy is broken
> -
>
> Key: MSITE-609
> URL: https://jira.codehaus.org/browse/MSITE-609
> Project: Maven 2.x and 3.x Site Plugin
> Issue Type: Bug
> Components: site:deploy
>Affects Versions: 3.0
> Environment: mvn -version
> Apache Maven 2.2.1 (r801777; 2009-08-06 21:16:01+0200)
> Java version: 1.6.0_22
> Java home: c:\Programme\Java\jdk1.6.0_22\jre
> Default locale: de_DE, platform encoding: Cp1252
> OS name: "windows xp" version: "5.1" arch: "x86" Family: "windows"
>Reporter: Christian M.
> Attachments: pom.xml, settings.xml, site_deploy_broken_output.txt
>
>
> With Maven 2.2.1 and the maven-site-plugin 3.0, site:deploy is not working
> anymore. This can be reproduced with the simplest empty project, see attached
> pom.xml
> The error that occurs is:
> java.lang.NoSuchMethodError:
> org.codehaus.plexus.PlexusContainer.getContainerRealm()Lorg/codehaus/plexus/classworlds/realm/ClassRealm;
> (complete stacktrace attached)
> This is in reference to this mail thread:
> http://markmail.org/message/ilfbqb2vhiyo5os4
> Attached are:
> - pom.xml (simple empty project)
> - settings.xml (minimal config necessary for deploy)
> - output from "mvn -X site:deploy" ("mvn site" was run before)
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MSITE-609) site:deploy is broken
[
https://jira.codehaus.org/browse/MSITE-609?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=276434#comment-276434
]
Olivier Lamy commented on MSITE-609:
Sir, Yes Sir.
I will :-)
> site:deploy is broken
> -
>
> Key: MSITE-609
> URL: https://jira.codehaus.org/browse/MSITE-609
> Project: Maven 2.x and 3.x Site Plugin
> Issue Type: Bug
> Components: site:deploy
>Affects Versions: 3.0
> Environment: mvn -version
> Apache Maven 2.2.1 (r801777; 2009-08-06 21:16:01+0200)
> Java version: 1.6.0_22
> Java home: c:\Programme\Java\jdk1.6.0_22\jre
> Default locale: de_DE, platform encoding: Cp1252
> OS name: "windows xp" version: "5.1" arch: "x86" Family: "windows"
>Reporter: Christian M.
>Assignee: Olivier Lamy
> Attachments: pom.xml, settings.xml, site_deploy_broken_output.txt
>
>
> With Maven 2.2.1 and the maven-site-plugin 3.0, site:deploy is not working
> anymore. This can be reproduced with the simplest empty project, see attached
> pom.xml
> The error that occurs is:
> java.lang.NoSuchMethodError:
> org.codehaus.plexus.PlexusContainer.getContainerRealm()Lorg/codehaus/plexus/classworlds/realm/ClassRealm;
> (complete stacktrace attached)
> This is in reference to this mail thread:
> http://markmail.org/message/ilfbqb2vhiyo5os4
> Attached are:
> - pom.xml (simple empty project)
> - settings.xml (minimal config necessary for deploy)
> - output from "mvn -X site:deploy" ("mvn site" was run before)
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MSITE-609) site:deploy is broken
[
https://jira.codehaus.org/browse/MSITE-609?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=276436#comment-276436
]
Christian M. commented on MSITE-609:
thank you so much for your quick investigation, I can confirm that Lucas'
suggestion (remove the empty element) is fixing the problem
indeed!
> site:deploy is broken
> -
>
> Key: MSITE-609
> URL: https://jira.codehaus.org/browse/MSITE-609
> Project: Maven 2.x and 3.x Site Plugin
> Issue Type: Bug
> Components: site:deploy
>Affects Versions: 3.0
> Environment: mvn -version
> Apache Maven 2.2.1 (r801777; 2009-08-06 21:16:01+0200)
> Java version: 1.6.0_22
> Java home: c:\Programme\Java\jdk1.6.0_22\jre
> Default locale: de_DE, platform encoding: Cp1252
> OS name: "windows xp" version: "5.1" arch: "x86" Family: "windows"
>Reporter: Christian M.
>Assignee: Olivier Lamy
> Attachments: pom.xml, settings.xml, site_deploy_broken_output.txt
>
>
> With Maven 2.2.1 and the maven-site-plugin 3.0, site:deploy is not working
> anymore. This can be reproduced with the simplest empty project, see attached
> pom.xml
> The error that occurs is:
> java.lang.NoSuchMethodError:
> org.codehaus.plexus.PlexusContainer.getContainerRealm()Lorg/codehaus/plexus/classworlds/realm/ClassRealm;
> (complete stacktrace attached)
> This is in reference to this mail thread:
> http://markmail.org/message/ilfbqb2vhiyo5os4
> Attached are:
> - pom.xml (simple empty project)
> - settings.xml (minimal config necessary for deploy)
> - output from "mvn -X site:deploy" ("mvn site" was run before)
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
