[jira] [Commented] (MWRAPPER-11) Could not find artifact org.apache.maven:apache-maven-wrapper:zip:script
[
https://issues.apache.org/jira/browse/MWRAPPER-11?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17283984#comment-17283984
]
Anthony Whitford commented on MWRAPPER-11:
--
Is this a duplicate of MWRAPPER-6?
> Could not find artifact org.apache.maven:apache-maven-wrapper:zip:script
> -
>
> Key: MWRAPPER-11
> URL: https://issues.apache.org/jira/browse/MWRAPPER-11
> Project: Maven Wrapper
> Issue Type: Bug
>Affects Versions: 3.0.1
>Reporter: Caleb Cushing
>Priority: Blocker
>
> trying to upgrade from the original? non apache plugin. I get this stacktrace
> {code}
> ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-wrapper-plugin:3.0.1:wrapper (default-cli) on
> project dex: Could not find artifact org.apache.maven:apache-maven-wrapper:z
> ip:script:3.6.0 in central (https://repo.maven.apache.org/maven2) -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal org.apache.maven.plugins:maven-wrapper-plugin:3.0.1:wrapper
> (default-cli) on project dex: Could not find
> artifact org.apache.maven:apache-maven-wrapper:zip:script:3.6.0 in central
> (https://repo.maven.apache.org/maven2)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:215)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:156)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:148)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:117)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:81)
> at
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build
> (SingleThreadedBuilder.java:56)
> at org.apache.maven.lifecycle.internal.LifecycleStarter.execute
> (LifecycleStarter.java:128)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:305)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:192)
> at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:105)
> at org.apache.maven.cli.MavenCli.execute (MavenCli.java:956)
> at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:288)
> at org.apache.maven.cli.MavenCli.main (MavenCli.java:192)
> at sun.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke
> (NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke
> (DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke (Method.java:498)
> at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced
> (Launcher.java:289)
> at org.codehaus.plexus.classworlds.launcher.Launcher.launch
> (Launcher.java:229)
> at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode
> (Launcher.java:415)
> at org.codehaus.plexus.classworlds.launcher.Launcher.main
> (Launcher.java:356)
> at sun.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke
> (NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke
> (DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke (Method.java:498)
> at org.apache.maven.wrapper.BootstrapMainStarter.start
> (BootstrapMainStarter.java:39)
> at org.apache.maven.wrapper.WrapperExecutor.execute
> (WrapperExecutor.java:122)
> at org.apache.maven.wrapper.MavenWrapperMain.main
> (MavenWrapperMain.java:55)
> Caused by: org.apache.maven.plugin.MojoExecutionException: Could not find
> artifact org.apache.maven:apache-maven-wrapper:zip:script:3.6.0 in central
> (https://repo.maven.apache.org/mave
> n2)
> at org.apache.maven.plugins.wrapper.WrapperMojo.execute
> (WrapperMojo.java:127)
> at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo
> (DefaultBuildPluginManager.java:137)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:210)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:156)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:148)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:117)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:81)
> at
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build
> (SingleThreadedBuilder.java:56)
> at org.apache.maven.lifecycle.internal.LifecycleStarter.execute
> (LifecycleStarter.java:128)
> at
[jira] [Commented] (MRELEASE-1016) mvn release:branch fails on Windows to commit changed pom in branch
[
https://issues.apache.org/jira/browse/MRELEASE-1016?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16661210#comment-16661210
]
Anthony Whitford commented on MRELEASE-1016:
Another observation is that I can see that the local {{pom.xml}} file is being
modified correctly, but then reverting. The modified {{pom.xml}} does not
appear to be committed to Git – each branch simply is a synonym for the tag.
> mvn release:branch fails on Windows to commit changed pom in branch
> ---
>
> Key: MRELEASE-1016
> URL: https://issues.apache.org/jira/browse/MRELEASE-1016
> Project: Maven Release Plugin
> Issue Type: Bug
> Components: branch
>Affects Versions: 2.5.3
> Environment: Apache Maven 3.3.9
> Java version: 1.8.0_60, vendor: Oracle Corporation
> OS name: "windows 7", version: "6.1", arch: "amd64", family: "dos"
> git version 2.16.2.windows.1
>Reporter: Anthony Whitford
>Assignee: Robert Scholte
>Priority: Blocker
>
> I need to create a branch from a tag. Imagine branching from a 1.0 tag, the
> following should work:
> {noformat}
> git checkout project-1.0
> mvn release:branch -DupdateBranchVersions=true
> -DupdateWorkingCopyVersions=false -DautoVersionSubmodules=true
> -DbranchName=1.0.x -DreleaseVersion=1.0.1-SNAPSHOT
> git checkout 1.0.x
> {noformat}
> Alas, the {{pom.xml}} in the new branch still references version 1.0 (not
> 1.0.1-SNAPSHOT), and the {{}} references the tag, not the branch.
> (!) This looks like MRELEASE-881 was simply never resolved.
> If I run a _Dry Run_, like:
> {noformat}
> mvn release:branch -DupdateBranchVersions=true
> -DupdateWorkingCopyVersions=false -DautoVersionSubmodules=true
> -DbranchName=1.0.x -DreleaseVersion=1.0.1-SNAPSHOT -DpushChanges=false
> -DdryRun=true
> {noformat}
> I can see the correct updates in {{pom.xml.branch}}.
> Note that there are no differences between {{pom.xml}} and {{pom.xml.next}}.
> _Why is {{pom.xml.branch}} not being captured in the branch?_
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MRELEASE-1016) mvn release:branch fails on Windows to commit changed pom in branch
[
https://issues.apache.org/jira/browse/MRELEASE-1016?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16661202#comment-16661202
]
Anthony Whitford commented on MRELEASE-1016:
I noticed this output looks odd:
{noformat}
[INFO] Modified POMs are not committed because suppressCommitBeforeTagOrBranch
is set to false.
[INFO] Branching release with the label null...{noformat}
* There is no property for {{suppressCommitBeforeTagOrBranch}} (there is
{{suppressCommitBeforeBranch}}, but setting that to {{true}} has no impact).
* It also reads weird that a {{false}} _suppress_ does _not_ commit.
* Finally, the release label is _null_?
> mvn release:branch fails on Windows to commit changed pom in branch
> ---
>
> Key: MRELEASE-1016
> URL: https://issues.apache.org/jira/browse/MRELEASE-1016
> Project: Maven Release Plugin
> Issue Type: Bug
> Components: branch
>Affects Versions: 2.5.3
> Environment: Apache Maven 3.3.9
> Java version: 1.8.0_60, vendor: Oracle Corporation
> OS name: "windows 7", version: "6.1", arch: "amd64", family: "dos"
> git version 2.16.2.windows.1
>Reporter: Anthony Whitford
>Assignee: Robert Scholte
>Priority: Blocker
>
> I need to create a branch from a tag. Imagine branching from a 1.0 tag, the
> following should work:
> {noformat}
> git checkout project-1.0
> mvn release:branch -DupdateBranchVersions=true
> -DupdateWorkingCopyVersions=false -DautoVersionSubmodules=true
> -DbranchName=1.0.x -DreleaseVersion=1.0.1-SNAPSHOT
> git checkout 1.0.x
> {noformat}
> Alas, the {{pom.xml}} in the new branch still references version 1.0 (not
> 1.0.1-SNAPSHOT), and the {{}} references the tag, not the branch.
> (!) This looks like MRELEASE-881 was simply never resolved.
> If I run a _Dry Run_, like:
> {noformat}
> mvn release:branch -DupdateBranchVersions=true
> -DupdateWorkingCopyVersions=false -DautoVersionSubmodules=true
> -DbranchName=1.0.x -DreleaseVersion=1.0.1-SNAPSHOT -DpushChanges=false
> -DdryRun=true
> {noformat}
> I can see the correct updates in {{pom.xml.branch}}.
> Note that there are no differences between {{pom.xml}} and {{pom.xml.next}}.
> _Why is {{pom.xml.branch}} not being captured in the branch?_
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (MRELEASE-1016) mvn release:branch fails on Windows to commit changed pom in branch
[
https://issues.apache.org/jira/browse/MRELEASE-1016?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anthony Whitford updated MRELEASE-1016:
---
Environment:
Apache Maven 3.3.9
Java version: 1.8.0_60, vendor: Oracle Corporation
OS name: "windows 7", version: "6.1", arch: "amd64", family: "dos"
git version 2.16.2.windows.1
was:
git version 1.9.4.msysgit.0;
Apache Maven 3.2.1 (ea8b2b07643dbb1b84b6d16e1f08391b666bc1e9; 2014-02-14T18:37:5
2+01:00)
Maven home: D:\Dev\maven\apache-maven-3.2.1\bin\..
Java version: 1.7.0_51, vendor: Oracle Corporation
Java home: D:\Dev\Java\jdk7_51_x64\jre
Default locale: de_DE, platform encoding: Cp1252
OS name: "windows 7", version: "6.1", arch: "amd64", family: "windows"
> mvn release:branch fails on Windows to commit changed pom in branch
> ---
>
> Key: MRELEASE-1016
> URL: https://issues.apache.org/jira/browse/MRELEASE-1016
> Project: Maven Release Plugin
> Issue Type: Bug
> Components: branch
>Affects Versions: 2.5.3
> Environment: Apache Maven 3.3.9
> Java version: 1.8.0_60, vendor: Oracle Corporation
> OS name: "windows 7", version: "6.1", arch: "amd64", family: "dos"
> git version 2.16.2.windows.1
>Reporter: Anthony Whitford
>Assignee: Robert Scholte
>Priority: Blocker
> Fix For: 2.5.3
>
>
> I need to create a branch from a tag. Imagine branching from a 1.0 tag, the
> following should work:
> {noformat}
> git checkout project-1.0
> mvn release:branch -DupdateBranchVersions=true
> -DupdateWorkingCopyVersions=false -DautoVersionSubmodules=true
> -DbranchName=1.0.x -DreleaseVersion=1.0.1-SNAPSHOT
> git checkout 1.0.x
> {noformat}
> Alas, the {{pom.xml}} in the new branch still references version 1.0 (not
> 1.0.1-SNAPSHOT), and the {{}} references the tag, not the branch.
> (!) This looks like MRELEASE-881 was simply never resolved.
> If I run a _Dry Run_, like:
> {noformat}
> mvn release:branch -DupdateBranchVersions=true
> -DupdateWorkingCopyVersions=false -DautoVersionSubmodules=true
> -DbranchName=1.0.x -DreleaseVersion=1.0.1-SNAPSHOT -DpushChanges=false
> -DdryRun=true
> {noformat}
> I can see the correct updates in {{pom.xml.branch}}.
> Note that there are no differences between {{pom.xml}} and {{pom.xml.next}}.
> _Why is {{pom.xml.branch}} not being captured in the branch?_
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MRELEASE-1016) mvn release:branch fails on Windows to commit changed pom in branch
[
https://issues.apache.org/jira/browse/MRELEASE-1016?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16661137#comment-16661137
]
Anthony Whitford commented on MRELEASE-1016:
The _Fix Version_ needs to be updated, but I do not have permission.
> mvn release:branch fails on Windows to commit changed pom in branch
> ---
>
> Key: MRELEASE-1016
> URL: https://issues.apache.org/jira/browse/MRELEASE-1016
> Project: Maven Release Plugin
> Issue Type: Bug
> Components: branch
>Affects Versions: 2.5.3
> Environment: git version 1.9.4.msysgit.0;
> Apache Maven 3.2.1 (ea8b2b07643dbb1b84b6d16e1f08391b666bc1e9;
> 2014-02-14T18:37:5
> 2+01:00)
> Maven home: D:\Dev\maven\apache-maven-3.2.1\bin\..
> Java version: 1.7.0_51, vendor: Oracle Corporation
> Java home: D:\Dev\Java\jdk7_51_x64\jre
> Default locale: de_DE, platform encoding: Cp1252
> OS name: "windows 7", version: "6.1", arch: "amd64", family: "windows"
>Reporter: Anthony Whitford
>Assignee: Robert Scholte
>Priority: Blocker
> Fix For: 2.5.3
>
>
> I need to create a branch from a tag. Imagine branching from a 1.0 tag, the
> following should work:
> {noformat}
> git checkout project-1.0
> mvn release:branch -DupdateBranchVersions=true
> -DupdateWorkingCopyVersions=false -DautoVersionSubmodules=true
> -DbranchName=1.0.x -DreleaseVersion=1.0.1-SNAPSHOT
> git checkout 1.0.x
> {noformat}
> Alas, the {{pom.xml}} in the new branch still references version 1.0 (not
> 1.0.1-SNAPSHOT), and the {{}} references the tag, not the branch.
> (!) This looks like MRELEASE-881 was simply never resolved.
> If I run a _Dry Run_, like:
> {noformat}
> mvn release:branch -DupdateBranchVersions=true
> -DupdateWorkingCopyVersions=false -DautoVersionSubmodules=true
> -DbranchName=1.0.x -DreleaseVersion=1.0.1-SNAPSHOT -DpushChanges=false
> -DdryRun=true
> {noformat}
> I can see the correct updates in {{pom.xml.branch}}.
> Note that there are no differences between {{pom.xml}} and {{pom.xml.next}}.
> _Why is {{pom.xml.branch}} not being captured in the branch?_
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (MRELEASE-1016) mvn release:branch fails on Windows to commit changed pom in branch
[
https://issues.apache.org/jira/browse/MRELEASE-1016?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anthony Whitford updated MRELEASE-1016:
---
Description:
I need to create a branch from a tag. Imagine branching from a 1.0 tag, the
following should work:
{noformat}
git checkout project-1.0
mvn release:branch -DupdateBranchVersions=true
-DupdateWorkingCopyVersions=false -DautoVersionSubmodules=true
-DbranchName=1.0.x -DreleaseVersion=1.0.1-SNAPSHOT
git checkout 1.0.x
{noformat}
Alas, the {{pom.xml}} in the new branch still references version 1.0 (not
1.0.1-SNAPSHOT), and the {{}} references the tag, not the branch.
(!) This looks like MRELEASE-881 was simply never resolved.
If I run a _Dry Run_, like:
{noformat}
mvn release:branch -DupdateBranchVersions=true
-DupdateWorkingCopyVersions=false -DautoVersionSubmodules=true
-DbranchName=1.0.x -DreleaseVersion=1.0.1-SNAPSHOT -DpushChanges=false
-DdryRun=true
{noformat}
I can see the correct updates in {{pom.xml.branch}}.
Note that there are no differences between {{pom.xml}} and {{pom.xml.next}}.
_Why is {{pom.xml.branch}} not being captured in the branch?_
was:
I have tried this with 2.5 version ... also with 1.9 git:scm dependency.
I guess it has to do with the WARNINGS shown below. Git itself works without
any problems.
The branch is created, but still has the version 1.0-SNAPSHOT. It should have
the version 1.0-copy-SNAPSHOT. The version was correct updated in the
pom.xml.branch has the correct version information (which I can see with
-DdryRun=true)
Following command fails to commit the "next pom" into the branch:
{noformat}
mvn release:branch -DbranchName=copy-repo-settings -DremoteTagging=false
-DupdateBranchVersions=true -DupdateWorking
CopyVersions=false -DreleaseVersion=1.0-copy-SNAPSHOT
.
[INFO] --- maven-release-plugin:2.5:branch (default-cli) @ monthly-update ---
[INFO] Verifying that there are no local modifications...
[INFO] ignoring changes on: **\release.properties, **\pom.xml.next, **\pom.xml
.releaseBackup, **\pom.xml.backup, **\pom.xml.branch, **\pom.xml.tag
[INFO] Executing: cmd.exe /X /C "git rev-parse --show-toplevel"
[INFO] Working directory: D:\Dev\projects\git\devopts\monthly-update
[INFO] Executing: cmd.exe /X /C "git status --porcelain ."
[INFO] Working directory: D:\Dev\projects\git\devopts\monthly-update
[INFO] Transforming 'montly DevOpts Plugin'...
[INFO] Checking in modified POMs...
[INFO] Executing: cmd.exe /X /C "git add -- pom.xml"
[INFO] Working directory: D:\Dev\projects\git\devopts\monthly-update
[INFO] Executing: cmd.exe /X /C "git rev-parse --show-toplevel"
[INFO] Working directory: D:\Dev\projects\git\devopts\monthly-update
[INFO] Executing: cmd.exe /X /C "git status --porcelain ."
[INFO] Working directory: D:\Dev\projects\git\devopts\monthly-update
[WARNING] Ignoring unrecognized line: ?? monthly-update/pom.xml.releaseBackup
[INFO] Branching release with the label null...
[INFO] Executing: cmd.exe /X /C "git branch copy-repo-settings"
[INFO] Working directory: D:\Dev\projects\git\devopts\monthly-update
[INFO] Executing: cmd.exe /X /C "git push https://user:pass@dev/git/devopts.git
refs/heads/copy-repo-settings"
[INFO] Working directory: D:\Dev\projects\git\devopts\monthly-update
[INFO] Executing: cmd.exe /X /C "git ls-files"
[INFO] Working directory: D:\Dev\projects\git\devopts\monthly-update
[INFO] Transforming 'montly DevOpts Plugin'...
[INFO] Checking in modified POMs...
[INFO] Executing: cmd.exe /X /C "git add -- pom.xml"
[INFO] Working directory: D:\Dev\projects\git\devopts\monthly-update
[INFO] Executing: cmd.exe /X /C "git rev-parse --show-toplevel"
[INFO] Working directory: D:\Dev\projects\git\devopts\monthly-update
[INFO] Executing: cmd.exe /X /C "git status --porcelain ."
[INFO] Working directory: D:\Dev\projects\git\devopts\monthly-update
[WARNING] Ignoring unrecognized line: ?? monthly-update/pom.xml.releaseBackup
[INFO] Release preparation complete.
[INFO] Cleaning up after release...
[INFO]
[INFO] BUILD SUCCESS
[INFO]
[INFO] Total time: 11.853 s
[INFO] Finished at: 2014-07-09T09:03:58+01:00
[INFO] Final Memory: 11M/307M
[INFO]
{noformat}
> mvn release:branch fails on Windows to commit changed pom in branch
> ---
>
> Key: MRELEASE-1016
> URL: https://issues.apache.org/jira/browse/MRELEASE-1016
> Project: Maven Release Plugin
> Issue Type: Bug
> Components: branch
>Affects Versions: 2.5.3
> Environment: git version 1.9.4.msysgit.0;
> Apache Maven 3.2.1 (ea8b2b07643dbb1b84b6d16e1f08391b666bc1e9;
> 2014-02-14T18:37:5
> 2+01:00)
> Maven home:
[jira] [Updated] (MRELEASE-1016) mvn release:branch fails on Windows to commit changed pom in branch
[
https://issues.apache.org/jira/browse/MRELEASE-1016?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anthony Whitford updated MRELEASE-1016:
---
Affects Version/s: (was: 2.5)
(was: 2.3.2)
2.5.3
> mvn release:branch fails on Windows to commit changed pom in branch
> ---
>
> Key: MRELEASE-1016
> URL: https://issues.apache.org/jira/browse/MRELEASE-1016
> Project: Maven Release Plugin
> Issue Type: Bug
> Components: branch
>Affects Versions: 2.5.3
> Environment: git version 1.9.4.msysgit.0;
> Apache Maven 3.2.1 (ea8b2b07643dbb1b84b6d16e1f08391b666bc1e9;
> 2014-02-14T18:37:5
> 2+01:00)
> Maven home: D:\Dev\maven\apache-maven-3.2.1\bin\..
> Java version: 1.7.0_51, vendor: Oracle Corporation
> Java home: D:\Dev\Java\jdk7_51_x64\jre
> Default locale: de_DE, platform encoding: Cp1252
> OS name: "windows 7", version: "6.1", arch: "amd64", family: "windows"
>Reporter: Anthony Whitford
>Assignee: Robert Scholte
>Priority: Blocker
> Fix For: 2.5.3
>
>
> I have tried this with 2.5 version ... also with 1.9 git:scm dependency.
> I guess it has to do with the WARNINGS shown below. Git itself works without
> any problems.
> The branch is created, but still has the version 1.0-SNAPSHOT. It should have
> the version 1.0-copy-SNAPSHOT. The version was correct updated in the
> pom.xml.branch has the correct version information (which I can see with
> -DdryRun=true)
> Following command fails to commit the "next pom" into the branch:
> {noformat}
> mvn release:branch -DbranchName=copy-repo-settings -DremoteTagging=false
> -DupdateBranchVersions=true -DupdateWorking
> CopyVersions=false -DreleaseVersion=1.0-copy-SNAPSHOT
> .
> [INFO] --- maven-release-plugin:2.5:branch (default-cli) @ monthly-update ---
> [INFO] Verifying that there are no local modifications...
> [INFO] ignoring changes on: **\release.properties, **\pom.xml.next,
> **\pom.xml
> .releaseBackup, **\pom.xml.backup, **\pom.xml.branch, **\pom.xml.tag
> [INFO] Executing: cmd.exe /X /C "git rev-parse --show-toplevel"
> [INFO] Working directory: D:\Dev\projects\git\devopts\monthly-update
> [INFO] Executing: cmd.exe /X /C "git status --porcelain ."
> [INFO] Working directory: D:\Dev\projects\git\devopts\monthly-update
> [INFO] Transforming 'montly DevOpts Plugin'...
> [INFO] Checking in modified POMs...
> [INFO] Executing: cmd.exe /X /C "git add -- pom.xml"
> [INFO] Working directory: D:\Dev\projects\git\devopts\monthly-update
> [INFO] Executing: cmd.exe /X /C "git rev-parse --show-toplevel"
> [INFO] Working directory: D:\Dev\projects\git\devopts\monthly-update
> [INFO] Executing: cmd.exe /X /C "git status --porcelain ."
> [INFO] Working directory: D:\Dev\projects\git\devopts\monthly-update
> [WARNING] Ignoring unrecognized line: ?? monthly-update/pom.xml.releaseBackup
> [INFO] Branching release with the label null...
> [INFO] Executing: cmd.exe /X /C "git branch copy-repo-settings"
> [INFO] Working directory: D:\Dev\projects\git\devopts\monthly-update
> [INFO] Executing: cmd.exe /X /C "git push
> https://user:pass@dev/git/devopts.git refs/heads/copy-repo-settings"
> [INFO] Working directory: D:\Dev\projects\git\devopts\monthly-update
> [INFO] Executing: cmd.exe /X /C "git ls-files"
> [INFO] Working directory: D:\Dev\projects\git\devopts\monthly-update
> [INFO] Transforming 'montly DevOpts Plugin'...
> [INFO] Checking in modified POMs...
> [INFO] Executing: cmd.exe /X /C "git add -- pom.xml"
> [INFO] Working directory: D:\Dev\projects\git\devopts\monthly-update
> [INFO] Executing: cmd.exe /X /C "git rev-parse --show-toplevel"
> [INFO] Working directory: D:\Dev\projects\git\devopts\monthly-update
> [INFO] Executing: cmd.exe /X /C "git status --porcelain ."
> [INFO] Working directory: D:\Dev\projects\git\devopts\monthly-update
> [WARNING] Ignoring unrecognized line: ?? monthly-update/pom.xml.releaseBackup
> [INFO] Release preparation complete.
> [INFO] Cleaning up after release...
> [INFO]
>
> [INFO] BUILD SUCCESS
> [INFO]
>
> [INFO] Total time: 11.853 s
> [INFO] Finished at: 2014-07-09T09:03:58+01:00
> [INFO] Final Memory: 11M/307M
> [INFO]
>
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (MRELEASE-1016) mvn release:branch fails on Windows to commit changed pom in branch
Anthony Whitford created MRELEASE-1016:
--
Summary: mvn release:branch fails on Windows to commit changed pom
in branch
Key: MRELEASE-1016
URL: https://issues.apache.org/jira/browse/MRELEASE-1016
Project: Maven Release Plugin
Issue Type: Bug
Components: branch
Affects Versions: 2.3.2, 2.5
Environment: git version 1.9.4.msysgit.0;
Apache Maven 3.2.1 (ea8b2b07643dbb1b84b6d16e1f08391b666bc1e9; 2014-02-14T18:37:5
2+01:00)
Maven home: D:\Dev\maven\apache-maven-3.2.1\bin\..
Java version: 1.7.0_51, vendor: Oracle Corporation
Java home: D:\Dev\Java\jdk7_51_x64\jre
Default locale: de_DE, platform encoding: Cp1252
OS name: "windows 7", version: "6.1", arch: "amd64", family: "windows"
Reporter: Anthony Whitford
Assignee: Robert Scholte
Fix For: 2.5.3
I have tried this with 2.5 version ... also with 1.9 git:scm dependency.
I guess it has to do with the WARNINGS shown below. Git itself works without
any problems.
The branch is created, but still has the version 1.0-SNAPSHOT. It should have
the version 1.0-copy-SNAPSHOT. The version was correct updated in the
pom.xml.branch has the correct version information (which I can see with
-DdryRun=true)
Following command fails to commit the "next pom" into the branch:
{noformat}
mvn release:branch -DbranchName=copy-repo-settings -DremoteTagging=false
-DupdateBranchVersions=true -DupdateWorking
CopyVersions=false -DreleaseVersion=1.0-copy-SNAPSHOT
.
[INFO] --- maven-release-plugin:2.5:branch (default-cli) @ monthly-update ---
[INFO] Verifying that there are no local modifications...
[INFO] ignoring changes on: **\release.properties, **\pom.xml.next, **\pom.xml
.releaseBackup, **\pom.xml.backup, **\pom.xml.branch, **\pom.xml.tag
[INFO] Executing: cmd.exe /X /C "git rev-parse --show-toplevel"
[INFO] Working directory: D:\Dev\projects\git\devopts\monthly-update
[INFO] Executing: cmd.exe /X /C "git status --porcelain ."
[INFO] Working directory: D:\Dev\projects\git\devopts\monthly-update
[INFO] Transforming 'montly DevOpts Plugin'...
[INFO] Checking in modified POMs...
[INFO] Executing: cmd.exe /X /C "git add -- pom.xml"
[INFO] Working directory: D:\Dev\projects\git\devopts\monthly-update
[INFO] Executing: cmd.exe /X /C "git rev-parse --show-toplevel"
[INFO] Working directory: D:\Dev\projects\git\devopts\monthly-update
[INFO] Executing: cmd.exe /X /C "git status --porcelain ."
[INFO] Working directory: D:\Dev\projects\git\devopts\monthly-update
[WARNING] Ignoring unrecognized line: ?? monthly-update/pom.xml.releaseBackup
[INFO] Branching release with the label null...
[INFO] Executing: cmd.exe /X /C "git branch copy-repo-settings"
[INFO] Working directory: D:\Dev\projects\git\devopts\monthly-update
[INFO] Executing: cmd.exe /X /C "git push https://user:pass@dev/git/devopts.git
refs/heads/copy-repo-settings"
[INFO] Working directory: D:\Dev\projects\git\devopts\monthly-update
[INFO] Executing: cmd.exe /X /C "git ls-files"
[INFO] Working directory: D:\Dev\projects\git\devopts\monthly-update
[INFO] Transforming 'montly DevOpts Plugin'...
[INFO] Checking in modified POMs...
[INFO] Executing: cmd.exe /X /C "git add -- pom.xml"
[INFO] Working directory: D:\Dev\projects\git\devopts\monthly-update
[INFO] Executing: cmd.exe /X /C "git rev-parse --show-toplevel"
[INFO] Working directory: D:\Dev\projects\git\devopts\monthly-update
[INFO] Executing: cmd.exe /X /C "git status --porcelain ."
[INFO] Working directory: D:\Dev\projects\git\devopts\monthly-update
[WARNING] Ignoring unrecognized line: ?? monthly-update/pom.xml.releaseBackup
[INFO] Release preparation complete.
[INFO] Cleaning up after release...
[INFO]
[INFO] BUILD SUCCESS
[INFO]
[INFO] Total time: 11.853 s
[INFO] Finished at: 2014-07-09T09:03:58+01:00
[INFO] Final Memory: 11M/307M
[INFO]
{noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MRELEASE-881) mvn release:branch fails on Windows to commit changed pom in branch
[
https://issues.apache.org/jira/browse/MRELEASE-881?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16661117#comment-16661117
]
Anthony Whitford commented on MRELEASE-881:
---
This is not working for me, and I am using version 2.5.3, Maven 3.3.9, and Git
version 2.16.2.windows.1 on Windows 7.
> mvn release:branch fails on Windows to commit changed pom in branch
> ---
>
> Key: MRELEASE-881
> URL: https://issues.apache.org/jira/browse/MRELEASE-881
> Project: Maven Release Plugin
> Issue Type: Bug
> Components: branch
>Affects Versions: 2.3.2, 2.5
> Environment: git version 1.9.4.msysgit.0;
> Apache Maven 3.2.1 (ea8b2b07643dbb1b84b6d16e1f08391b666bc1e9;
> 2014-02-14T18:37:5
> 2+01:00)
> Maven home: D:\Dev\maven\apache-maven-3.2.1\bin\..
> Java version: 1.7.0_51, vendor: Oracle Corporation
> Java home: D:\Dev\Java\jdk7_51_x64\jre
> Default locale: de_DE, platform encoding: Cp1252
> OS name: "windows 7", version: "6.1", arch: "amd64", family: "windows"
>Reporter: Thomas Wabner
>Assignee: Robert Scholte
>Priority: Blocker
> Fix For: 2.5.3
>
>
> I have tried this with 2.5 version ... also with 1.9 git:scm dependency.
> I guess it has to do with the WARNINGS shown below. Git itself works without
> any problems.
> The branch is created, but still has the version 1.0-SNAPSHOT. It should have
> the version 1.0-copy-SNAPSHOT. The version was correct updated in the
> pom.xml.branch has the correct version information (which I can see with
> -DdryRun=true)
> Following command fails to commit the "next pom" into the branch:
> {noformat}
> mvn release:branch -DbranchName=copy-repo-settings -DremoteTagging=false
> -DupdateBranchVersions=true -DupdateWorking
> CopyVersions=false -DreleaseVersion=1.0-copy-SNAPSHOT
> .
> [INFO] --- maven-release-plugin:2.5:branch (default-cli) @ monthly-update ---
> [INFO] Verifying that there are no local modifications...
> [INFO] ignoring changes on: **\release.properties, **\pom.xml.next,
> **\pom.xml
> .releaseBackup, **\pom.xml.backup, **\pom.xml.branch, **\pom.xml.tag
> [INFO] Executing: cmd.exe /X /C "git rev-parse --show-toplevel"
> [INFO] Working directory: D:\Dev\projects\git\devopts\monthly-update
> [INFO] Executing: cmd.exe /X /C "git status --porcelain ."
> [INFO] Working directory: D:\Dev\projects\git\devopts\monthly-update
> [INFO] Transforming 'montly DevOpts Plugin'...
> [INFO] Checking in modified POMs...
> [INFO] Executing: cmd.exe /X /C "git add -- pom.xml"
> [INFO] Working directory: D:\Dev\projects\git\devopts\monthly-update
> [INFO] Executing: cmd.exe /X /C "git rev-parse --show-toplevel"
> [INFO] Working directory: D:\Dev\projects\git\devopts\monthly-update
> [INFO] Executing: cmd.exe /X /C "git status --porcelain ."
> [INFO] Working directory: D:\Dev\projects\git\devopts\monthly-update
> [WARNING] Ignoring unrecognized line: ?? monthly-update/pom.xml.releaseBackup
> [INFO] Branching release with the label null...
> [INFO] Executing: cmd.exe /X /C "git branch copy-repo-settings"
> [INFO] Working directory: D:\Dev\projects\git\devopts\monthly-update
> [INFO] Executing: cmd.exe /X /C "git push
> https://user:pass@dev/git/devopts.git refs/heads/copy-repo-settings"
> [INFO] Working directory: D:\Dev\projects\git\devopts\monthly-update
> [INFO] Executing: cmd.exe /X /C "git ls-files"
> [INFO] Working directory: D:\Dev\projects\git\devopts\monthly-update
> [INFO] Transforming 'montly DevOpts Plugin'...
> [INFO] Checking in modified POMs...
> [INFO] Executing: cmd.exe /X /C "git add -- pom.xml"
> [INFO] Working directory: D:\Dev\projects\git\devopts\monthly-update
> [INFO] Executing: cmd.exe /X /C "git rev-parse --show-toplevel"
> [INFO] Working directory: D:\Dev\projects\git\devopts\monthly-update
> [INFO] Executing: cmd.exe /X /C "git status --porcelain ."
> [INFO] Working directory: D:\Dev\projects\git\devopts\monthly-update
> [WARNING] Ignoring unrecognized line: ?? monthly-update/pom.xml.releaseBackup
> [INFO] Release preparation complete.
> [INFO] Cleaning up after release...
> [INFO]
>
> [INFO] BUILD SUCCESS
> [INFO]
>
> [INFO] Total time: 11.853 s
> [INFO] Finished at: 2014-07-09T09:03:58+01:00
> [INFO] Final Memory: 11M/307M
> [INFO]
>
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (JXR-141) Invalid HTML generation
Anthony Whitford created JXR-141:
Summary: Invalid HTML generation
Key: JXR-141
URL: https://issues.apache.org/jira/browse/JXR-141
Project: Maven JXR
Issue Type: Bug
Components: jxr
Affects Versions: 3.0.0
Environment: Windows 7, Java 8 Update 60, Maven 3.3.9
Reporter: Anthony Whitford
I am getting invalid HTML generated, like:
{code:xml}
51 public TreeNode
(final String text, TreeNode"jxr_keyword">final
Boolean checked, final TreeNode[]
children) {
{code}
Specifically, look at:
{code:xml}
TreeNode"jxr_keyword">final
Boolean checked
{code}
The original Java code is:
{code}
public TreeNode (final String text, final Boolean checked, final TreeNode[]
children) {
{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MSHADE-145) Site not generated correctly when overriding dependencyReducedPomLocation with relocation
[
https://issues.apache.org/jira/browse/MSHADE-145?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16394380#comment-16394380
]
Anthony Whitford commented on MSHADE-145:
-
I think this is still valid.
> Site not generated correctly when overriding dependencyReducedPomLocation
> with relocation
> -
>
> Key: MSHADE-145
> URL: https://issues.apache.org/jira/browse/MSHADE-145
> Project: Maven Shade Plugin
> Issue Type: Bug
>Affects Versions: 2.0
> Environment: Windows XP, Java 6 Update 24, Maven 3.0.4
>Reporter: Anthony Whitford
>Priority: Major
> Attachments: shade-site-bug.zip
>
>
> My release failed because the project uses the {{maven-shade-plugin}} and it
> generated a {{dependency-reduced-pom.xml}} in the {{basedir}}, so the release
> plugin complains that there are local, uncommitted modifications.
> To get my release working, I overrode the {{dependencyReducedPomLocation}}
> configuration parameter to place it in {{project.build.directory}}:
> {code:xml}
>
>
> ${project.build.directory}/dependency-reduced-pom.xml
> ...
>
> {code}
> My release worked, but then I noticed that this had a nasty side effect: my
> site was not generated properly!
> The project has {{src\site}} with a {{site.xml}} and APT pages. Those were
> no longer generated... I have no idea how one thing is connected to the
> other, but I did prove it by creating a sample application that illustrates
> the problem.
> Note that the problem seems to a combination of at least 2 things:
> * {{dependencyReducedPomLocation}}
> * {{relocations}}
> In other words, if you comment out the {{dependencyReducedPomLocation}} or
> the {{relocations}}, you can see the site being generated correctly. But if
> you have these, then the site will NOT generate properly.
> To be clear, the site generation is incorrect if you don't see the menu
> layout like:
> * About
> ** Introduction
> ** Usage
> * Project Documentation
> * Project Information
> A broken site, you will notice that the About menu and Usage page do not
> exist, for example.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MPMD-218) Update to PMD 5.3.5
[ https://issues.apache.org/jira/browse/MPMD-218?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15054036#comment-15054036 ] Anthony Whitford commented on MPMD-218: --- Any chance that this will be released soon? (The false positives from a bug are killing me.) > Update to PMD 5.3.5 > --- > > Key: MPMD-218 > URL: https://issues.apache.org/jira/browse/MPMD-218 > Project: Maven PMD Plugin > Issue Type: Bug >Reporter: Dennis Lundberg >Assignee: Dennis Lundberg > Fix For: 3.6 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (WAGON-413) Private Key authentication is no longer working with wagon-ssh-2.6
[
https://issues.apache.org/jira/browse/WAGON-413?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14721237#comment-14721237
]
Anthony Whitford commented on WAGON-413:
Great to see this fixed... Is there an ETA on the {{wagon-ssh-2.10}} release?
Private Key authentication is no longer working with wagon-ssh-2.6
--
Key: WAGON-413
URL: https://issues.apache.org/jira/browse/WAGON-413
Project: Maven Wagon
Issue Type: Bug
Components: wagon-ssh
Affects Versions: 2.6
Environment: Windows, Maven 3.0.4, Java 7 64-bit
Reporter: Anthony Whitford
Assignee: Dan Tran
Priority: Blocker
Fix For: 2.10
Attachments: maven-wagon-ssh-WAGON-413.patch
I have to provide the {{wagon-ssh}} dependency to the {{maven-site-plugin}}
in order to upload the site via {{scp}}. Authentication for the {{scp}} is
done via an _SSH key_.
Version 2.5 works fine, but when I upgrade to version 2.6, I am now getting a
Password prompt, and then a _Connection Refused_. (The Private Key should
negate a password prompt.)
With version 2.6, I get BUILD FAILURE:
{noformat}
[INFO] --- maven-site-plugin:3.3:deploy (default-deploy) @ project ---
Using private key: C:\Users\BuildAgent\.ssh\id_rsa
Password for buildagent@mvnsitehost:
scp://mvnsitehost/opt/maven/sites/project/3.4-SNAPSHOT/ - Session: Connection
refused
scp://mvnsitehost/opt/maven/sites/project/3.4-SNAPSHOT/ - Session:
Disconnecting
scp://mvnsitehost/opt/maven/sites/project/3.4-SNAPSHOT/ - Session:
Disconnected
[INFO]
[INFO] BUILD FAILURE
{noformat}
With version 2.5, I get BUILD SUCCESS:
{noformat}
[INFO] --- maven-site-plugin:3.3:deploy (default-deploy) @ project ---
Using private key: C:\Users\BuildAgent\.ssh\id_rsa
scp://mvnsitehost/opt/maven/sites/project/3.4-SNAPSHOT/ - Session: Opened
[INFO] Pushing D:\BuildAgent\projects\Project\Build_Snapshot\target\site
[INFO] to scp://mvnsitehost/opt/maven/sites/project/3.4-SNAPSHOT/./
Executing command: mkdir -p /opt/maven/sites/project/3.4-SNAPSHOT/./
Executing command: mkdir -p /opt/maven/sites/project/3.4-SNAPSHOT/.
Executing command: scp -t
/opt/maven/sites/project/3.4-SNAPSHOT/./wagon4279752042048724778.zip
Uploading: ./wagon4279752042048724778.zip to
scp://mvnsitehost/opt/maven/sites/project/3.4-SNAPSHOT/
##
Transfer finished. 316495 bytes copied in 0.031 seconds
Executing command: cd /opt/maven/sites/project/3.4-SNAPSHOT/./; unzip -q
-o wagon4279752042048724778.zip; rm -f wagon4279752042048724778.zip
Executing command: chmod -Rf g+w,a+rX /opt/maven/sites/project/3.4-SNAPSHOT/
scp://mvnsitehost/opt/maven/sites/project/3.4-SNAPSHOT/ - Session:
Disconnecting
scp://mvnsitehost/opt/maven/sites/project/3.4-SNAPSHOT/ - Session:
Disconnected
[INFO]
[INFO] BUILD SUCCESS
{noformat}
So, clearly the _new behavior_ is the _Connection Refused_:
{noformat}
Password for buildagent@mvnsitehost:
scp://mvnsitehost/opt/maven/sites/project/3.4-SNAPSHOT/ - Session: Connection
refused
{noformat}
(?) Could version 2.6 have broken the private key logic?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (WAGON-413) Private Key authentication is no longer working with wagon-ssh-2.6
[
https://issues.apache.org/jira/browse/WAGON-413?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14563776#comment-14563776
]
Anthony Whitford edited comment on WAGON-413 at 5/28/15 10:49 PM:
--
Please note that I also validated the proposed patch, and it was successful.
Since there is a patch, could this please be scheduled for 2.10 (the next
release)?
was (Author: awhitford):
Since there is a patch, could this be scheduled for 2.10?
Private Key authentication is no longer working with wagon-ssh-2.6
--
Key: WAGON-413
URL: https://issues.apache.org/jira/browse/WAGON-413
Project: Maven Wagon
Issue Type: Bug
Components: wagon-ssh
Affects Versions: 2.6
Environment: Windows, Maven 3.0.4, Java 7 64-bit
Reporter: Anthony Whitford
Priority: Blocker
Attachments: maven-wagon-ssh-WAGON-413.patch
I have to provide the {{wagon-ssh}} dependency to the {{maven-site-plugin}}
in order to upload the site via {{scp}}. Authentication for the {{scp}} is
done via an _SSH key_.
Version 2.5 works fine, but when I upgrade to version 2.6, I am now getting a
Password prompt, and then a _Connection Refused_. (The Private Key should
negate a password prompt.)
With version 2.6, I get BUILD FAILURE:
{noformat}
[INFO] --- maven-site-plugin:3.3:deploy (default-deploy) @ project ---
Using private key: C:\Users\BuildAgent\.ssh\id_rsa
Password for buildagent@mvnsitehost:
scp://mvnsitehost/opt/maven/sites/project/3.4-SNAPSHOT/ - Session: Connection
refused
scp://mvnsitehost/opt/maven/sites/project/3.4-SNAPSHOT/ - Session:
Disconnecting
scp://mvnsitehost/opt/maven/sites/project/3.4-SNAPSHOT/ - Session:
Disconnected
[INFO]
[INFO] BUILD FAILURE
{noformat}
With version 2.5, I get BUILD SUCCESS:
{noformat}
[INFO] --- maven-site-plugin:3.3:deploy (default-deploy) @ project ---
Using private key: C:\Users\BuildAgent\.ssh\id_rsa
scp://mvnsitehost/opt/maven/sites/project/3.4-SNAPSHOT/ - Session: Opened
[INFO] Pushing D:\BuildAgent\projects\Project\Build_Snapshot\target\site
[INFO] to scp://mvnsitehost/opt/maven/sites/project/3.4-SNAPSHOT/./
Executing command: mkdir -p /opt/maven/sites/project/3.4-SNAPSHOT/./
Executing command: mkdir -p /opt/maven/sites/project/3.4-SNAPSHOT/.
Executing command: scp -t
/opt/maven/sites/project/3.4-SNAPSHOT/./wagon4279752042048724778.zip
Uploading: ./wagon4279752042048724778.zip to
scp://mvnsitehost/opt/maven/sites/project/3.4-SNAPSHOT/
##
Transfer finished. 316495 bytes copied in 0.031 seconds
Executing command: cd /opt/maven/sites/project/3.4-SNAPSHOT/./; unzip -q
-o wagon4279752042048724778.zip; rm -f wagon4279752042048724778.zip
Executing command: chmod -Rf g+w,a+rX /opt/maven/sites/project/3.4-SNAPSHOT/
scp://mvnsitehost/opt/maven/sites/project/3.4-SNAPSHOT/ - Session:
Disconnecting
scp://mvnsitehost/opt/maven/sites/project/3.4-SNAPSHOT/ - Session:
Disconnected
[INFO]
[INFO] BUILD SUCCESS
{noformat}
So, clearly the _new behavior_ is the _Connection Refused_:
{noformat}
Password for buildagent@mvnsitehost:
scp://mvnsitehost/opt/maven/sites/project/3.4-SNAPSHOT/ - Session: Connection
refused
{noformat}
(?) Could version 2.6 have broken the private key logic?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (WAGON-413) Private Key authentication is no longer working with wagon-ssh-2.6
[
https://issues.apache.org/jira/browse/WAGON-413?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14563776#comment-14563776
]
Anthony Whitford commented on WAGON-413:
Since there is a patch, could this be scheduled for 2.10?
Private Key authentication is no longer working with wagon-ssh-2.6
--
Key: WAGON-413
URL: https://issues.apache.org/jira/browse/WAGON-413
Project: Maven Wagon
Issue Type: Bug
Components: wagon-ssh
Affects Versions: 2.6
Environment: Windows, Maven 3.0.4, Java 7 64-bit
Reporter: Anthony Whitford
Priority: Blocker
Attachments: maven-wagon-ssh-WAGON-413.patch
I have to provide the {{wagon-ssh}} dependency to the {{maven-site-plugin}}
in order to upload the site via {{scp}}. Authentication for the {{scp}} is
done via an _SSH key_.
Version 2.5 works fine, but when I upgrade to version 2.6, I am now getting a
Password prompt, and then a _Connection Refused_. (The Private Key should
negate a password prompt.)
With version 2.6, I get BUILD FAILURE:
{noformat}
[INFO] --- maven-site-plugin:3.3:deploy (default-deploy) @ project ---
Using private key: C:\Users\BuildAgent\.ssh\id_rsa
Password for buildagent@mvnsitehost:
scp://mvnsitehost/opt/maven/sites/project/3.4-SNAPSHOT/ - Session: Connection
refused
scp://mvnsitehost/opt/maven/sites/project/3.4-SNAPSHOT/ - Session:
Disconnecting
scp://mvnsitehost/opt/maven/sites/project/3.4-SNAPSHOT/ - Session:
Disconnected
[INFO]
[INFO] BUILD FAILURE
{noformat}
With version 2.5, I get BUILD SUCCESS:
{noformat}
[INFO] --- maven-site-plugin:3.3:deploy (default-deploy) @ project ---
Using private key: C:\Users\BuildAgent\.ssh\id_rsa
scp://mvnsitehost/opt/maven/sites/project/3.4-SNAPSHOT/ - Session: Opened
[INFO] Pushing D:\BuildAgent\projects\Project\Build_Snapshot\target\site
[INFO] to scp://mvnsitehost/opt/maven/sites/project/3.4-SNAPSHOT/./
Executing command: mkdir -p /opt/maven/sites/project/3.4-SNAPSHOT/./
Executing command: mkdir -p /opt/maven/sites/project/3.4-SNAPSHOT/.
Executing command: scp -t
/opt/maven/sites/project/3.4-SNAPSHOT/./wagon4279752042048724778.zip
Uploading: ./wagon4279752042048724778.zip to
scp://mvnsitehost/opt/maven/sites/project/3.4-SNAPSHOT/
##
Transfer finished. 316495 bytes copied in 0.031 seconds
Executing command: cd /opt/maven/sites/project/3.4-SNAPSHOT/./; unzip -q
-o wagon4279752042048724778.zip; rm -f wagon4279752042048724778.zip
Executing command: chmod -Rf g+w,a+rX /opt/maven/sites/project/3.4-SNAPSHOT/
scp://mvnsitehost/opt/maven/sites/project/3.4-SNAPSHOT/ - Session:
Disconnecting
scp://mvnsitehost/opt/maven/sites/project/3.4-SNAPSHOT/ - Session:
Disconnected
[INFO]
[INFO] BUILD SUCCESS
{noformat}
So, clearly the _new behavior_ is the _Connection Refused_:
{noformat}
Password for buildagent@mvnsitehost:
scp://mvnsitehost/opt/maven/sites/project/3.4-SNAPSHOT/ - Session: Connection
refused
{noformat}
(?) Could version 2.6 have broken the private key logic?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MDOCCK-26) When using Java 5 Annotations, docck incorrectly warns of no mojo descriptors found
[
https://issues.apache.org/jira/browse/MDOCCK-26?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14491105#comment-14491105
]
Anthony Whitford commented on MDOCCK-26:
With the new *Version 1.1* of this plugin, now *my build is broken*:
{noformat}
[ERROR] The following documentation problems were found:
o Lombok Maven Plugin (1 error, 1 warning)
[WARN] pom.xml has no mailingLists/mailingList specified.
[ERROR] Failed to parse mojo descriptors.
Error: No mojo definitions were found for plugin: null:null.
{noformat}
I don't get this... I'm doing things _the new way_ (with Java 5 annotations).
My project can be found here: [https://github.com/awhitford/lombok.maven]
When using Java 5 Annotations, docck incorrectly warns of no mojo descriptors
found
---
Key: MDOCCK-26
URL: https://issues.apache.org/jira/browse/MDOCCK-26
Project: Maven Documentation Checker Plugin
Issue Type: Bug
Affects Versions: 1.0
Reporter: Anthony Whitford
I have a Maven Plugin that uses [Java 5
annotations|http://maven.apache.org/plugin-tools/maven-plugin-tools-annotations/].
The [descriptor is being
generated|http://maven.apache.org/ref/3.0.4/maven-plugin-api/plugin.html],
yet the docck plugin erroneously emits a warning:
{noformat}
[WARNING] ***
[WARNING] Deprecation Alert:
[WARNING] No mojo descriptors were found in this project which has a
packaging type of maven-plugin.
[WARNING] In future versions of the plugin tools, this will fail the build.
[WARNING] If this project is an archetype, change the packaging type from
maven-plugin to maven-archetype.
[WARNING]
{noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] (WAGON-413) Private Key authentication is no longer working with wagon-ssh-2.6
[
https://jira.codehaus.org/browse/WAGON-413?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=356489#comment-356489
]
Anthony Whitford commented on WAGON-413:
Are there any outstanding questions? _(If so, I can try to acquire some more
background data.)_
Can this be scheduled as part of 2.9?
Private Key authentication is no longer working with wagon-ssh-2.6
--
Key: WAGON-413
URL: https://jira.codehaus.org/browse/WAGON-413
Project: Maven Wagon
Issue Type: Bug
Components: wagon-ssh
Affects Versions: 2.6
Environment: Windows, Maven 3.0.4, Java 7 64-bit
Reporter: Anthony Whitford
Priority: Blocker
I have to provide the {{wagon-ssh}} dependency to the {{maven-site-plugin}}
in order to upload the site via {{scp}}. Authentication for the {{scp}} is
done via an _SSH key_.
Version 2.5 works fine, but when I upgrade to version 2.6, I am now getting a
Password prompt, and then a _Connection Refused_. (The Private Key should
negate a password prompt.)
With version 2.6, I get BUILD FAILURE:
{noformat}
[INFO] --- maven-site-plugin:3.3:deploy (default-deploy) @ project ---
Using private key: C:\Users\BuildAgent\.ssh\id_rsa
Password for buildagent@mvnsitehost:
scp://mvnsitehost/opt/maven/sites/project/3.4-SNAPSHOT/ - Session: Connection
refused
scp://mvnsitehost/opt/maven/sites/project/3.4-SNAPSHOT/ - Session:
Disconnecting
scp://mvnsitehost/opt/maven/sites/project/3.4-SNAPSHOT/ - Session:
Disconnected
[INFO]
[INFO] BUILD FAILURE
{noformat}
With version 2.5, I get BUILD SUCCESS:
{noformat}
[INFO] --- maven-site-plugin:3.3:deploy (default-deploy) @ project ---
Using private key: C:\Users\BuildAgent\.ssh\id_rsa
scp://mvnsitehost/opt/maven/sites/project/3.4-SNAPSHOT/ - Session: Opened
[INFO] Pushing D:\BuildAgent\projects\Project\Build_Snapshot\target\site
[INFO] to scp://mvnsitehost/opt/maven/sites/project/3.4-SNAPSHOT/./
Executing command: mkdir -p /opt/maven/sites/project/3.4-SNAPSHOT/./
Executing command: mkdir -p /opt/maven/sites/project/3.4-SNAPSHOT/.
Executing command: scp -t
/opt/maven/sites/project/3.4-SNAPSHOT/./wagon4279752042048724778.zip
Uploading: ./wagon4279752042048724778.zip to
scp://mvnsitehost/opt/maven/sites/project/3.4-SNAPSHOT/
##
Transfer finished. 316495 bytes copied in 0.031 seconds
Executing command: cd /opt/maven/sites/project/3.4-SNAPSHOT/./; unzip -q
-o wagon4279752042048724778.zip; rm -f wagon4279752042048724778.zip
Executing command: chmod -Rf g+w,a+rX /opt/maven/sites/project/3.4-SNAPSHOT/
scp://mvnsitehost/opt/maven/sites/project/3.4-SNAPSHOT/ - Session:
Disconnecting
scp://mvnsitehost/opt/maven/sites/project/3.4-SNAPSHOT/ - Session:
Disconnected
[INFO]
[INFO] BUILD SUCCESS
{noformat}
So, clearly the _new behavior_ is the _Connection Refused_:
{noformat}
Password for buildagent@mvnsitehost:
scp://mvnsitehost/opt/maven/sites/project/3.4-SNAPSHOT/ - Session: Connection
refused
{noformat}
(?) Could version 2.6 have broken the private key logic?
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (WAGON-413) Private Key authentication is no longer working with wagon-ssh-2.6
[
https://jira.codehaus.org/browse/WAGON-413?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=356489#comment-356489
]
Anthony Whitford edited comment on WAGON-413 at 11/20/14 3:04 PM:
--
Are there any outstanding questions? _(If so, I can try to acquire some more
background data.)_
It looks like the code added to
{{wagon-providers/wagon-ssh/src/main/java/org/apache/maven/wagon/providers/ssh/jsch/AbstractJschWagon.java}}
from WAGON-403 just needs to be moved down to be part of the _else_ clause so
that a private key is used if specified.
Can this be scheduled as part of 2.9?
was (Author: awhitford):
Are there any outstanding questions? _(If so, I can try to acquire some more
background data.)_
Can this be scheduled as part of 2.9?
Private Key authentication is no longer working with wagon-ssh-2.6
--
Key: WAGON-413
URL: https://jira.codehaus.org/browse/WAGON-413
Project: Maven Wagon
Issue Type: Bug
Components: wagon-ssh
Affects Versions: 2.6
Environment: Windows, Maven 3.0.4, Java 7 64-bit
Reporter: Anthony Whitford
Priority: Blocker
I have to provide the {{wagon-ssh}} dependency to the {{maven-site-plugin}}
in order to upload the site via {{scp}}. Authentication for the {{scp}} is
done via an _SSH key_.
Version 2.5 works fine, but when I upgrade to version 2.6, I am now getting a
Password prompt, and then a _Connection Refused_. (The Private Key should
negate a password prompt.)
With version 2.6, I get BUILD FAILURE:
{noformat}
[INFO] --- maven-site-plugin:3.3:deploy (default-deploy) @ project ---
Using private key: C:\Users\BuildAgent\.ssh\id_rsa
Password for buildagent@mvnsitehost:
scp://mvnsitehost/opt/maven/sites/project/3.4-SNAPSHOT/ - Session: Connection
refused
scp://mvnsitehost/opt/maven/sites/project/3.4-SNAPSHOT/ - Session:
Disconnecting
scp://mvnsitehost/opt/maven/sites/project/3.4-SNAPSHOT/ - Session:
Disconnected
[INFO]
[INFO] BUILD FAILURE
{noformat}
With version 2.5, I get BUILD SUCCESS:
{noformat}
[INFO] --- maven-site-plugin:3.3:deploy (default-deploy) @ project ---
Using private key: C:\Users\BuildAgent\.ssh\id_rsa
scp://mvnsitehost/opt/maven/sites/project/3.4-SNAPSHOT/ - Session: Opened
[INFO] Pushing D:\BuildAgent\projects\Project\Build_Snapshot\target\site
[INFO] to scp://mvnsitehost/opt/maven/sites/project/3.4-SNAPSHOT/./
Executing command: mkdir -p /opt/maven/sites/project/3.4-SNAPSHOT/./
Executing command: mkdir -p /opt/maven/sites/project/3.4-SNAPSHOT/.
Executing command: scp -t
/opt/maven/sites/project/3.4-SNAPSHOT/./wagon4279752042048724778.zip
Uploading: ./wagon4279752042048724778.zip to
scp://mvnsitehost/opt/maven/sites/project/3.4-SNAPSHOT/
##
Transfer finished. 316495 bytes copied in 0.031 seconds
Executing command: cd /opt/maven/sites/project/3.4-SNAPSHOT/./; unzip -q
-o wagon4279752042048724778.zip; rm -f wagon4279752042048724778.zip
Executing command: chmod -Rf g+w,a+rX /opt/maven/sites/project/3.4-SNAPSHOT/
scp://mvnsitehost/opt/maven/sites/project/3.4-SNAPSHOT/ - Session:
Disconnecting
scp://mvnsitehost/opt/maven/sites/project/3.4-SNAPSHOT/ - Session:
Disconnected
[INFO]
[INFO] BUILD SUCCESS
{noformat}
So, clearly the _new behavior_ is the _Connection Refused_:
{noformat}
Password for buildagent@mvnsitehost:
scp://mvnsitehost/opt/maven/sites/project/3.4-SNAPSHOT/ - Session: Connection
refused
{noformat}
(?) Could version 2.6 have broken the private key logic?
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MSHARED-325) maven-filtering 1.2 throws MavenFilteringException: Mark invalid
[
https://jira.codehaus.org/browse/MSHARED-325?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=354436#comment-354436
]
Anthony Whitford commented on MSHARED-325:
--
I took the liberty of testing this updated {{maven-filtering}} artifact and it
seems to have solved my build problem. Thank you for fixing this.
maven-filtering 1.2 throws MavenFilteringException: Mark invalid
Key: MSHARED-325
URL: https://jira.codehaus.org/browse/MSHARED-325
Project: Maven Shared Components
Issue Type: Bug
Components: maven-filtering
Affects Versions: maven-filtering-1.2
Reporter: Mikolaj Izdebski
Assignee: Kristian Rosenvold
Fix For: maven-filtering-1.3
Attachments: 0001-Add-unit-test-for-MSHARED-325.patch,
MSHARED-325-tests.patch, payload
maven-filtering 1.2 throws MavenFilteringException: Mark invalid on some
resource files, which filtering is successfull with version 1.1.
An example payload is attached. I will attach a reproducer as a unit test
too.
{code}
Caused by: org.apache.maven.shared.filtering.MavenFilteringException: Mark
invalid
at
org.apache.maven.shared.filtering.DefaultMavenFileFilter.copyFile(DefaultMavenFileFilter.java:129)
at
org.apache.maven.shared.filtering.DefaultMavenResourcesFiltering.filterResources(DefaultMavenResourcesFiltering.java:264)
at
org.apache.maven.plugin.resources.ResourcesMojo.execute(ResourcesMojo.java:301)
... 21 more
Caused by: java.io.IOException: Mark invalid
at java.io.BufferedReader.reset(BufferedReader.java:505)
at
org.apache.maven.shared.filtering.MultiDelimiterInterpolatorFilterReaderLineEnding.read(MultiDelimiterInterpolatorFilterReaderLineEnding.java:416)
at
org.apache.maven.shared.filtering.MultiDelimiterInterpolatorFilterReaderLineEnding.read(MultiDelimiterInterpolatorFilterReaderLineEnding.java:205)
at java.io.Reader.read(Reader.java:140)
at org.apache.maven.shared.utils.io.IOUtil.copy(IOUtil.java:181)
at org.apache.maven.shared.utils.io.IOUtil.copy(IOUtil.java:168)
at
org.apache.maven.shared.utils.io.FileUtils.copyFile(FileUtils.java:1856)
at
org.apache.maven.shared.utils.io.FileUtils.copyFile(FileUtils.java:1804)
at
org.apache.maven.shared.filtering.DefaultMavenFileFilter.copyFile(DefaultMavenFileFilter.java:114)
... 23 more
{code}
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MWAR-331) IOException: Mark invalid -- With version 2.5
[
https://jira.codehaus.org/browse/MWAR-331?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=354437#comment-354437
]
Anthony Whitford commented on MWAR-331:
---
My build ends up filtering a large, generated JavaScript file, and the filter
bug is choking on @ symbols. The js content is beyond our control, so it isn't
a trivial fix.
BTW... I can't seem to change the filter delimiters for the war plugin -- that
could be a workaround if I could remove the @ symbol from being a token
delimiter.
IOException: Mark invalid -- With version 2.5
-
Key: MWAR-331
URL: https://jira.codehaus.org/browse/MWAR-331
Project: Maven WAR Plugin
Issue Type: Bug
Components: filtering
Affects Versions: 2.5
Environment: Windows 7, Java 7 Update 25, Maven 3.2.1
Reporter: Anthony Whitford
Priority: Blocker
Upgrading from {{maven-war-plugin}} version 2.4 to 2.5, caused this build
problem:
{noformat}
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-war-plugin:2.5:war (default-war) on project
wam-commons-extjs: Mark invalid - [Help 1]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
goal org.apache.maven.plugins:maven-war-plugin
:2.5:war (default-war) on project wam-commons-extjs: Mark invalid
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:216)
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:108)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:76)
at
org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
at
org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:116)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:361)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:155)
at org.apache.maven.cli.MavenCli.execute(MavenCli.java:584)
at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:213)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:157)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at
org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
at
org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
at
org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
at
org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
Caused by: org.apache.maven.plugin.MojoExecutionException: Mark invalid
at
org.apache.maven.plugin.war.packaging.AbstractWarPackagingTask.copyFilteredFile(AbstractWarPackagingTask.java:248)
at
org.apache.maven.plugin.war.packaging.WarProjectPackagingTask.copyResources(WarProjectPackagingTask.java:317)
at
org.apache.maven.plugin.war.packaging.WarProjectPackagingTask.handleWebResources(WarProjectPackagingTask.java:132)
at
org.apache.maven.plugin.war.packaging.WarProjectPackagingTask.performPackaging(WarProjectPackagingTask.java:83)
at
org.apache.maven.plugin.war.AbstractWarMojo.buildWebapp(AbstractWarMojo.java:483)
at
org.apache.maven.plugin.war.AbstractWarMojo.buildExplodedWebapp(AbstractWarMojo.java:411)
at
org.apache.maven.plugin.war.WarMojo.performPackaging(WarMojo.java:213)
at org.apache.maven.plugin.war.WarMojo.execute(WarMojo.java:176)
at
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:133)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
... 19 more
Caused by: org.apache.maven.shared.filtering.MavenFilteringException: Mark
invalid
at
org.apache.maven.shared.filtering.DefaultMavenFileFilter.copyFile(DefaultMavenFileFilter.java:129)
at
org.apache.maven.shared.filtering.DefaultMavenFileFilter.copyFile(DefaultMavenFileFilter.java:96)
at
org.apache.maven.plugin.war.packaging.AbstractWarPackagingTask.copyFilteredFile(AbstractWarPackagingTask.java:244)
... 28 more
Caused by: java.io.IOException: Mark invalid
at
[jira] (MWAR-331) IOException: Mark invalid -- With version 2.5
Anthony Whitford created MWAR-331:
-
Summary: IOException: Mark invalid -- With version 2.5
Key: MWAR-331
URL: https://jira.codehaus.org/browse/MWAR-331
Project: Maven WAR Plugin
Issue Type: Bug
Components: filtering
Affects Versions: 2.5
Environment: Windows 7, Java 7 Update 25, Maven 3.2.1
Reporter: Anthony Whitford
Priority: Blocker
Upgrading from {{maven-war-plugin}} version 2.4 to 2.5, caused this build
problem:
{noformat}
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-war-plugin:2.5:war (default-war) on project
wam-commons-extjs: Mark invalid - [Help 1]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal
org.apache.maven.plugins:maven-war-plugin
:2.5:war (default-war) on project wam-commons-extjs: Mark invalid
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:216)
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:108)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:76)
at
org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
at
org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:116)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:361)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:155)
at org.apache.maven.cli.MavenCli.execute(MavenCli.java:584)
at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:213)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:157)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at
org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
at
org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
at
org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
at
org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
Caused by: org.apache.maven.plugin.MojoExecutionException: Mark invalid
at
org.apache.maven.plugin.war.packaging.AbstractWarPackagingTask.copyFilteredFile(AbstractWarPackagingTask.java:248)
at
org.apache.maven.plugin.war.packaging.WarProjectPackagingTask.copyResources(WarProjectPackagingTask.java:317)
at
org.apache.maven.plugin.war.packaging.WarProjectPackagingTask.handleWebResources(WarProjectPackagingTask.java:132)
at
org.apache.maven.plugin.war.packaging.WarProjectPackagingTask.performPackaging(WarProjectPackagingTask.java:83)
at
org.apache.maven.plugin.war.AbstractWarMojo.buildWebapp(AbstractWarMojo.java:483)
at
org.apache.maven.plugin.war.AbstractWarMojo.buildExplodedWebapp(AbstractWarMojo.java:411)
at
org.apache.maven.plugin.war.WarMojo.performPackaging(WarMojo.java:213)
at org.apache.maven.plugin.war.WarMojo.execute(WarMojo.java:176)
at
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:133)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
... 19 more
Caused by: org.apache.maven.shared.filtering.MavenFilteringException: Mark
invalid
at
org.apache.maven.shared.filtering.DefaultMavenFileFilter.copyFile(DefaultMavenFileFilter.java:129)
at
org.apache.maven.shared.filtering.DefaultMavenFileFilter.copyFile(DefaultMavenFileFilter.java:96)
at
org.apache.maven.plugin.war.packaging.AbstractWarPackagingTask.copyFilteredFile(AbstractWarPackagingTask.java:244)
... 28 more
Caused by: java.io.IOException: Mark invalid
at java.io.BufferedReader.reset(BufferedReader.java:505)
at
org.apache.maven.shared.filtering.MultiDelimiterInterpolatorFilterReaderLineEnding.read(MultiDelimiterInterpolatorFilterReaderLineEnding.java:416)
at
org.apache.maven.shared.filtering.MultiDelimiterInterpolatorFilterReaderLineEnding.read(MultiDelimiterInterpolatorFilterReaderLineEnding.java:205)
at java.io.Reader.read(Reader.java:140)
at org.apache.maven.shared.utils.io.IOUtil.copy(IOUtil.java:181)
at org.apache.maven.shared.utils.io.IOUtil.copy(IOUtil.java:168)
at
[jira] (MWAR-331) IOException: Mark invalid -- With version 2.5
[
https://jira.codehaus.org/browse/MWAR-331?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anthony Whitford updated MWAR-331:
--
Description:
Upgrading from {{maven-war-plugin}} version 2.4 to 2.5, caused this build
problem:
{noformat}
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-war-plugin:2.5:war (default-war) on project
wam-commons-extjs: Mark invalid - [Help 1]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal
org.apache.maven.plugins:maven-war-plugin
:2.5:war (default-war) on project wam-commons-extjs: Mark invalid
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:216)
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:108)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:76)
at
org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
at
org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:116)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:361)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:155)
at org.apache.maven.cli.MavenCli.execute(MavenCli.java:584)
at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:213)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:157)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at
org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
at
org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
at
org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
at
org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
Caused by: org.apache.maven.plugin.MojoExecutionException: Mark invalid
at
org.apache.maven.plugin.war.packaging.AbstractWarPackagingTask.copyFilteredFile(AbstractWarPackagingTask.java:248)
at
org.apache.maven.plugin.war.packaging.WarProjectPackagingTask.copyResources(WarProjectPackagingTask.java:317)
at
org.apache.maven.plugin.war.packaging.WarProjectPackagingTask.handleWebResources(WarProjectPackagingTask.java:132)
at
org.apache.maven.plugin.war.packaging.WarProjectPackagingTask.performPackaging(WarProjectPackagingTask.java:83)
at
org.apache.maven.plugin.war.AbstractWarMojo.buildWebapp(AbstractWarMojo.java:483)
at
org.apache.maven.plugin.war.AbstractWarMojo.buildExplodedWebapp(AbstractWarMojo.java:411)
at
org.apache.maven.plugin.war.WarMojo.performPackaging(WarMojo.java:213)
at org.apache.maven.plugin.war.WarMojo.execute(WarMojo.java:176)
at
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:133)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
... 19 more
Caused by: org.apache.maven.shared.filtering.MavenFilteringException: Mark
invalid
at
org.apache.maven.shared.filtering.DefaultMavenFileFilter.copyFile(DefaultMavenFileFilter.java:129)
at
org.apache.maven.shared.filtering.DefaultMavenFileFilter.copyFile(DefaultMavenFileFilter.java:96)
at
org.apache.maven.plugin.war.packaging.AbstractWarPackagingTask.copyFilteredFile(AbstractWarPackagingTask.java:244)
... 28 more
Caused by: java.io.IOException: Mark invalid
at java.io.BufferedReader.reset(BufferedReader.java:505)
at
org.apache.maven.shared.filtering.MultiDelimiterInterpolatorFilterReaderLineEnding.read(MultiDelimiterInterpolatorFilterReaderLineEnding.java:416)
at
org.apache.maven.shared.filtering.MultiDelimiterInterpolatorFilterReaderLineEnding.read(MultiDelimiterInterpolatorFilterReaderLineEnding.java:205)
at java.io.Reader.read(Reader.java:140)
at org.apache.maven.shared.utils.io.IOUtil.copy(IOUtil.java:181)
at org.apache.maven.shared.utils.io.IOUtil.copy(IOUtil.java:168)
at
org.apache.maven.shared.utils.io.FileUtils.copyFile(FileUtils.java:1856)
at
org.apache.maven.shared.utils.io.FileUtils.copyFile(FileUtils.java:1804)
at
org.apache.maven.shared.filtering.DefaultMavenFileFilter.copyFile(DefaultMavenFileFilter.java:114)
... 30 more
[ERROR]
[ERROR]
[ERROR] For more information about the errors
[jira] (MSHARED-325) maven-filtering 1.2 throws MavenFilteringException: Mark invalid
[
https://jira.codehaus.org/browse/MSHARED-325?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=354385#comment-354385
]
Anthony Whitford commented on MSHARED-325:
--
Escaping doesn't solve my problem because I need to filter a build derivative
of which I have limited control over its composition... As a result, it would
be great to see this issue part of the Road Map. :)
maven-filtering 1.2 throws MavenFilteringException: Mark invalid
Key: MSHARED-325
URL: https://jira.codehaus.org/browse/MSHARED-325
Project: Maven Shared Components
Issue Type: Bug
Components: maven-filtering
Affects Versions: maven-filtering-1.2
Reporter: Mikolaj Izdebski
Attachments: 0001-Add-unit-test-for-MSHARED-325.patch,
MSHARED-325-tests.patch, payload
maven-filtering 1.2 throws MavenFilteringException: Mark invalid on some
resource files, which filtering is successfull with version 1.1.
An example payload is attached. I will attach a reproducer as a unit test
too.
{code}
Caused by: org.apache.maven.shared.filtering.MavenFilteringException: Mark
invalid
at
org.apache.maven.shared.filtering.DefaultMavenFileFilter.copyFile(DefaultMavenFileFilter.java:129)
at
org.apache.maven.shared.filtering.DefaultMavenResourcesFiltering.filterResources(DefaultMavenResourcesFiltering.java:264)
at
org.apache.maven.plugin.resources.ResourcesMojo.execute(ResourcesMojo.java:301)
... 21 more
Caused by: java.io.IOException: Mark invalid
at java.io.BufferedReader.reset(BufferedReader.java:505)
at
org.apache.maven.shared.filtering.MultiDelimiterInterpolatorFilterReaderLineEnding.read(MultiDelimiterInterpolatorFilterReaderLineEnding.java:416)
at
org.apache.maven.shared.filtering.MultiDelimiterInterpolatorFilterReaderLineEnding.read(MultiDelimiterInterpolatorFilterReaderLineEnding.java:205)
at java.io.Reader.read(Reader.java:140)
at org.apache.maven.shared.utils.io.IOUtil.copy(IOUtil.java:181)
at org.apache.maven.shared.utils.io.IOUtil.copy(IOUtil.java:168)
at
org.apache.maven.shared.utils.io.FileUtils.copyFile(FileUtils.java:1856)
at
org.apache.maven.shared.utils.io.FileUtils.copyFile(FileUtils.java:1804)
at
org.apache.maven.shared.filtering.DefaultMavenFileFilter.copyFile(DefaultMavenFileFilter.java:114)
... 23 more
{code}
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MCHECKSTYLE-70) Support for multiple source folders
[
https://jira.codehaus.org/browse/MCHECKSTYLE-70?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=353837#comment-353837
]
Anthony Whitford commented on MCHECKSTYLE-70:
-
I was able to restore prior functionality with the following configuration:
{code:xml}
configuration
sourceDirectorysrc/main/java/sourceDirectory
testSourceDirectorysrc/test/java/testSourceDirectory
/configuration
{code}
Support for multiple source folders
---
Key: MCHECKSTYLE-70
URL: https://jira.codehaus.org/browse/MCHECKSTYLE-70
Project: Maven Checkstyle Plugin
Issue Type: Improvement
Affects Versions: 2.1
Reporter: Jan Palmquist
Assignee: Robert Scholte
Priority: Minor
Fix For: 2.13
It would be great if this plugin would support multiple source folders added
by http://mojo.codehaus.org/build-helper-maven-plugin/ (or similar), and by
default inspect sources from these folders instead of just
$\{project.build.sourceDirectory}. Correspondingly with respect to test
sources if those are configured to be included.
There are other plugins available solving this problem (somehow), eg:
* http://mojo.codehaus.org/jdepend-maven-plugin/
* http://mojo.codehaus.org/findbugs-maven-plugin/
Maybe they can give some inspiration for how to make this possible?
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (WAGON-413) Private Key authentication is no longer working with wagon-ssh-2.6
[
https://jira.codehaus.org/browse/WAGON-413?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=353705#comment-353705
]
Anthony Whitford commented on WAGON-413:
Please note that {{wagon-ssh-2.7}} has the same issue as version 2.6.
Private Key authentication is no longer working with wagon-ssh-2.6
--
Key: WAGON-413
URL: https://jira.codehaus.org/browse/WAGON-413
Project: Maven Wagon
Issue Type: Bug
Components: wagon-ssh
Affects Versions: 2.6
Environment: Windows, Maven 3.0.4, Java 7 64-bit
Reporter: Anthony Whitford
Priority: Blocker
I have to provide the {{wagon-ssh}} dependency to the {{maven-site-plugin}}
in order to upload the site via {{scp}}. Authentication for the {{scp}} is
done via an _SSH key_.
Version 2.5 works fine, but when I upgrade to version 2.6, I am now getting a
Password prompt, and then a _Connection Refused_. (The Private Key should
negate a password prompt.)
With version 2.6, I get BUILD FAILURE:
{noformat}
[INFO] --- maven-site-plugin:3.3:deploy (default-deploy) @ project ---
Using private key: C:\Users\BuildAgent\.ssh\id_rsa
Password for buildagent@mvnsitehost:
scp://mvnsitehost/opt/maven/sites/project/3.4-SNAPSHOT/ - Session: Connection
refused
scp://mvnsitehost/opt/maven/sites/project/3.4-SNAPSHOT/ - Session:
Disconnecting
scp://mvnsitehost/opt/maven/sites/project/3.4-SNAPSHOT/ - Session:
Disconnected
[INFO]
[INFO] BUILD FAILURE
{noformat}
With version 2.5, I get BUILD SUCCESS:
{noformat}
[INFO] --- maven-site-plugin:3.3:deploy (default-deploy) @ project ---
Using private key: C:\Users\BuildAgent\.ssh\id_rsa
scp://mvnsitehost/opt/maven/sites/project/3.4-SNAPSHOT/ - Session: Opened
[INFO] Pushing D:\BuildAgent\projects\Project\Build_Snapshot\target\site
[INFO] to scp://mvnsitehost/opt/maven/sites/project/3.4-SNAPSHOT/./
Executing command: mkdir -p /opt/maven/sites/project/3.4-SNAPSHOT/./
Executing command: mkdir -p /opt/maven/sites/project/3.4-SNAPSHOT/.
Executing command: scp -t
/opt/maven/sites/project/3.4-SNAPSHOT/./wagon4279752042048724778.zip
Uploading: ./wagon4279752042048724778.zip to
scp://mvnsitehost/opt/maven/sites/project/3.4-SNAPSHOT/
##
Transfer finished. 316495 bytes copied in 0.031 seconds
Executing command: cd /opt/maven/sites/project/3.4-SNAPSHOT/./; unzip -q
-o wagon4279752042048724778.zip; rm -f wagon4279752042048724778.zip
Executing command: chmod -Rf g+w,a+rX /opt/maven/sites/project/3.4-SNAPSHOT/
scp://mvnsitehost/opt/maven/sites/project/3.4-SNAPSHOT/ - Session:
Disconnecting
scp://mvnsitehost/opt/maven/sites/project/3.4-SNAPSHOT/ - Session:
Disconnected
[INFO]
[INFO] BUILD SUCCESS
{noformat}
So, clearly the _new behavior_ is the _Connection Refused_:
{noformat}
Password for buildagent@mvnsitehost:
scp://mvnsitehost/opt/maven/sites/project/3.4-SNAPSHOT/ - Session: Connection
refused
{noformat}
(?) Could version 2.6 have broken the private key logic?
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MCHECKSTYLE-70) Support for multiple source folders
[
https://jira.codehaus.org/browse/MCHECKSTYLE-70?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=353712#comment-353712
]
Anthony Whitford commented on MCHECKSTYLE-70:
-
This change that now applies Checkstyle to generated-source is a major problem
for me too.
I thought that I could work around it by being explicit like:
{code:xml}
configuration
sourceDirectories
sourceDirectory${basedir}/src/main/java/sourceDirectory
/sourceDirectories
testSourceDirectories
testSourceDirectory${basedir}/src/test/java/testSourceDirectory
/testSourceDirectories
/configuration
{code}
but this doesn't seem to make it work.
Note that for the PMD plugin, it appears that it has an
[{{excludeRoots}}|http://maven.apache.org/plugins/maven-pmd-plugin/pmd-mojo.html#excludeRoots]
configuration property, and I use it like:
{code:xml}
compileSourceRoots${project.compileSourceRoots}/compileSourceRoots
excludeRoots
excludeRoottarget/generated-sources/jaxb/excludeRoot
excludeRoottarget/generated-sources/xjc/excludeRoot
excludeRoottarget/generated-sources/wsimport/excludeRoot
/excludeRoots
{code}
Support for multiple source folders
---
Key: MCHECKSTYLE-70
URL: https://jira.codehaus.org/browse/MCHECKSTYLE-70
Project: Maven Checkstyle Plugin
Issue Type: Improvement
Affects Versions: 2.1
Reporter: Jan Palmquist
Assignee: Robert Scholte
Priority: Minor
Fix For: 2.13
It would be great if this plugin would support multiple source folders added
by http://mojo.codehaus.org/build-helper-maven-plugin/ (or similar), and by
default inspect sources from these folders instead of just
$\{project.build.sourceDirectory}. Correspondingly with respect to test
sources if those are configured to be included.
There are other plugins available solving this problem (somehow), eg:
* http://mojo.codehaus.org/jdepend-maven-plugin/
* http://mojo.codehaus.org/findbugs-maven-plugin/
Maybe they can give some inspiration for how to make this possible?
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MJAVADOC-411) Package does not exist warnings
[
https://jira.codehaus.org/browse/MJAVADOC-411?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=353591#comment-353591
]
Anthony Whitford commented on MJAVADOC-411:
---
I confirmed that this issue has been resolved with version 2.10.1.
Package does not exist warnings
---
Key: MJAVADOC-411
URL: https://jira.codehaus.org/browse/MJAVADOC-411
Project: Maven Javadoc Plugin
Issue Type: Bug
Affects Versions: 2.10
Environment: Mac OSX, Java 8 Update 20, Maven 3.2.3
Reporter: Anthony Whitford
Fix For: 2.10.1
Since version 2.10, it appears that Javadoc is warning about missing packages
when generating javadoc.
* For the {{javadoc}} goal, the {{compile}} scope classes should be in scope
* For the {{test-javadoc}} goal, the {{test}} scope classes should be in scope
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MJAVADOC-411) Package does not exist warnings
[
https://jira.codehaus.org/browse/MJAVADOC-411?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anthony Whitford updated MJAVADOC-411:
--
Fix Version/s: 2.10.1
Package does not exist warnings
---
Key: MJAVADOC-411
URL: https://jira.codehaus.org/browse/MJAVADOC-411
Project: Maven Javadoc Plugin
Issue Type: Bug
Affects Versions: 2.10
Environment: Mac OSX, Java 8 Update 20, Maven 3.2.3
Reporter: Anthony Whitford
Fix For: 2.10.1
Since version 2.10, it appears that Javadoc is warning about missing packages
when generating javadoc.
* For the {{javadoc}} goal, the {{compile}} scope classes should be in scope
* For the {{test-javadoc}} goal, the {{test}} scope classes should be in scope
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MJAVADOC-411) Package does not exist warnings
[
https://jira.codehaus.org/browse/MJAVADOC-411?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anthony Whitford closed MJAVADOC-411.
-
Resolution: Duplicate
Package does not exist warnings
---
Key: MJAVADOC-411
URL: https://jira.codehaus.org/browse/MJAVADOC-411
Project: Maven Javadoc Plugin
Issue Type: Bug
Affects Versions: 2.10
Environment: Mac OSX, Java 8 Update 20, Maven 3.2.3
Reporter: Anthony Whitford
Fix For: 2.10.1
Since version 2.10, it appears that Javadoc is warning about missing packages
when generating javadoc.
* For the {{javadoc}} goal, the {{compile}} scope classes should be in scope
* For the {{test-javadoc}} goal, the {{test}} scope classes should be in scope
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MJAVADOC-411) Package does not exist warnings
[
https://jira.codehaus.org/browse/MJAVADOC-411?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=353240#comment-353240
]
Anthony Whitford commented on MJAVADOC-411:
---
I suspect that MJAVADOC-406 (which is essentially applying the proper fix to
MJAVADOC-398) will solve the issue.
Package does not exist warnings
---
Key: MJAVADOC-411
URL: https://jira.codehaus.org/browse/MJAVADOC-411
Project: Maven Javadoc Plugin
Issue Type: Bug
Affects Versions: 2.10
Environment: Mac OSX, Java 8 Update 20, Maven 3.2.3
Reporter: Anthony Whitford
Since version 2.10, it appears that Javadoc is warning about missing packages
when generating javadoc.
* For the {{javadoc}} goal, the {{compile}} scope classes should be in scope
* For the {{test-javadoc}} goal, the {{test}} scope classes should be in scope
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MJAVADOC-411) Package does not exist warnings
[
https://jira.codehaus.org/browse/MJAVADOC-411?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=353171#comment-353171
]
Anthony Whitford commented on MJAVADOC-411:
---
While I suspect the issue is a side effect of MJAVADOC-398, I don't think it is
a duplicate of MJAVADOC-407.
When building, I am now getting warnings such as these. For example:
{noformat}
[WARNING] Javadoc Warnings
[WARNING]
/Users/anthony/Documents/lombok.maven/test-maven-lombok/src/test/java/org/projectlombok/test/AppTest.java:3:
error: package junit.framework does not exist
[WARNING] import junit.framework.Test;
[WARNING] ^
[WARNING]
/Users/anthony/Documents/lombok.maven/test-maven-lombok/src/test/java/org/projectlombok/test/AppTest.java:4:
error: package junit.framework does not exist
[WARNING] import junit.framework.TestCase;
[WARNING] ^
[WARNING]
/Users/anthony/Documents/lombok.maven/test-maven-lombok/src/test/java/org/projectlombok/test/AppTest.java:5:
error: package junit.framework does not exist
[WARNING] import junit.framework.TestSuite;
[WARNING] ^
[WARNING]
/Users/anthony/Documents/lombok.maven/test-maven-lombok/src/test/java/org/projectlombok/test/AppTest.java:10:
error: cannot find symbol
[WARNING] public class AppTest extends TestCase
[WARNING] ^
[WARNING] symbol: class TestCase
[WARNING]
/Users/anthony/Documents/lombok.maven/test-maven-lombok/src/test/java/org/projectlombok/test/AppTest.java:24:
error: cannot find symbol
[WARNING] public static Test suite() {
{noformat}
The above is from the {{test-javadoc}} goal, and it is complaining that it
can't find JUnit classes, yet JUnit is {{test}} dependency.
Package does not exist warnings
---
Key: MJAVADOC-411
URL: https://jira.codehaus.org/browse/MJAVADOC-411
Project: Maven Javadoc Plugin
Issue Type: Bug
Affects Versions: 2.10
Environment: Mac OSX, Java 8 Update 20, Maven 3.2.3
Reporter: Anthony Whitford
Since version 2.10, it appears that Javadoc is warning about missing packages
when generating javadoc.
* For the {{javadoc}} goal, the {{compile}} scope classes should be in scope
* For the {{test-javadoc}} goal, the {{test}} scope classes should be in scope
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MJAVADOC-411) Package does not exist warnings
Anthony Whitford created MJAVADOC-411:
-
Summary: Package does not exist warnings
Key: MJAVADOC-411
URL: https://jira.codehaus.org/browse/MJAVADOC-411
Project: Maven Javadoc Plugin
Issue Type: Bug
Affects Versions: 2.10
Environment: Mac OSX, Java 8 Update 20, Maven 3.2.3
Reporter: Anthony Whitford
Since version 2.10, it appears that Javadoc is warning about missing packages
when generating javadoc.
* For the {{javadoc}} goal, the {{compile}} scope classes should be in scope
* For the {{test-javadoc}} goal, the {{test}} scope classes should be in scope
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MNG-5629) ClosedChannelException from DefaultUpdateCheckManager.read
[
https://jira.codehaus.org/browse/MNG-5629?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=352065#comment-352065
]
Anthony Whitford commented on MNG-5629:
---
Olaf, your idea to check {{lock.isValid()}} might be the _safest_ approach to
keep the finally handler generic in case the try changes over time, so the
[DefaultUpdateCheckManager finally
handler|http://maven.apache.org/ref/3.2.1/apidocs/src-html/org/apache/maven/repository/legacy/DefaultUpdateCheckManager.html#line.392]
could look like:
{code}
if ( lock != null lock.isValid() )
{
try
{
lock.release();
}
catch ( IOException e )
{
getLogger().debug( Error releasing shared lock for resolution tracking
file: + touchfile,
e );
}
}
{code}
[My
comment|https://jira.codehaus.org/browse/MNG-5629?focusedCommentId=349213page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-349213]
is advocating that +the whole _{{finally}}_ handler (lines 390 through to 416)
be removed+ because +it isn't necessary+; the _{{finally}}_ handler on lines
379 through 382 is all the necessary cleanup -- [line
381|http://maven.apache.org/ref/3.2.1/apidocs/src-html/org/apache/maven/repository/legacy/DefaultUpdateCheckManager.html#line.381]
closes everything.
As I mentioned, [my project on
github|https://github.com/awhitford/lombok.maven] demonstrates the problem as
long as you run the {{site}} phase with _debug_ ({{-X}}).
ClosedChannelException from DefaultUpdateCheckManager.read
--
Key: MNG-5629
URL: https://jira.codehaus.org/browse/MNG-5629
Project: Maven
Issue Type: Bug
Affects Versions: 3.2.1
Environment: Windows 7, Java 7 updated 25
Reporter: Anthony Whitford
Attachments: xy.tar.gz
I ran a build in debug mode ({{mvn -X}}) and noticed the following bug
(repeatedly):
{noformat}
[DEBUG] Error releasing shared lock for resolution tracking file:
C:\Users\awhitford\.m2\repository\org\apache\maven\plugins\maven-war-plugin\resolver-status.properties
java.nio.channels.ClosedChannelException
at sun.nio.ch.FileLockImpl.release(FileLockImpl.java:58)
at
org.apache.maven.repository.legacy.DefaultUpdateCheckManager.read(DefaultUpdateCheckManager.java:396)
at
org.apache.maven.repository.legacy.DefaultUpdateCheckManager.readLastUpdated(DefaultUpdateCheckManager.java:323)
at
org.apache.maven.repository.legacy.DefaultUpdateCheckManager.readLastUpdated(DefaultUpdateCheckManager.java:159)
at
org.apache.maven.repository.legacy.DefaultUpdateCheckManager.isUpdateRequired(DefaultUpdateCheckManager.java:148)
at
org.apache.maven.artifact.repository.metadata.DefaultRepositoryMetadataManager.resolve(DefaultRepositoryMetadataManager.java:127)
at
org.apache.maven.project.artifact.MavenMetadataSource.retrieveAvailableVersions(MavenMetadataSource.java:435)
at
org.apache.maven.project.artifact.MavenMetadataSource.retrieveAvailableVersions(MavenMetadataSource.java:425)
at
org.codehaus.mojo.versions.api.DefaultVersionsHelper.lookupArtifactVersions(DefaultVersionsHelper.java:229)
at
org.codehaus.mojo.versions.api.DefaultVersionsHelper.lookupPluginUpdates(DefaultVersionsHelper.java:727)
at
org.codehaus.mojo.versions.api.DefaultVersionsHelper.lookupPluginsUpdates(DefaultVersionsHelper.java:706)
at
org.codehaus.mojo.versions.PluginUpdatesReport.doGenerateReport(PluginUpdatesReport.java:103)
at
org.codehaus.mojo.versions.AbstractVersionsReport.executeReport(AbstractVersionsReport.java:253)
at
org.apache.maven.reporting.AbstractMavenReport.generate(AbstractMavenReport.java:90)
at
org.apache.maven.plugins.site.ReportDocumentRenderer.renderDocument(ReportDocumentRenderer.java:228)
at
org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.renderModule(DefaultSiteRenderer.java:319)
at
org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.render(DefaultSiteRenderer.java:135)
at
org.apache.maven.plugins.site.SiteMojo.renderLocale(SiteMojo.java:175)
at org.apache.maven.plugins.site.SiteMojo.execute(SiteMojo.java:138)
at
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:133)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
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:108)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:76)
[jira] (MNG-5629) ClosedChannelException from DefaultUpdateCheckManager.read
[
https://jira.codehaus.org/browse/MNG-5629?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=349213#comment-349213
]
Anthony Whitford commented on MNG-5629:
---
Who owns
[{{DefaultUpdateCheckManager.java}}|http://maven.apache.org/ref/3.2.1/apidocs/src-html/org/apache/maven/repository/legacy/DefaultUpdateCheckManager.html#line.396]?
Is that not part of Maven?
I'm pretty sure that the issue is that the code is calling {{lock.release()}}
for a lock related to a closed {{FileInputStream}}. It is like a double-close.
The Javadoc for
[{{FileLock.release}}|http://docs.oracle.com/javase/6/docs/api/java/nio/channels/FileLock.html#release()]
states that it will throw a ClosedChannelException if the channel that was
used to acquire this lock is no longer open.
I suspect that lines 390 to 416 are not necessary thanks to lines 379 to 382.
ClosedChannelException from DefaultUpdateCheckManager.read
--
Key: MNG-5629
URL: https://jira.codehaus.org/browse/MNG-5629
Project: Maven
Issue Type: Bug
Affects Versions: 3.2.1
Environment: Windows 7, Java 7 updated 25
Reporter: Anthony Whitford
I ran a build in debug mode ({{mvn -X}}) and noticed the following bug
(repeatedly):
{noformat}
[DEBUG] Error releasing shared lock for resolution tracking file:
C:\Users\awhitford\.m2\repository\org\apache\maven\plugins\maven-war-plugin\resolver-status.properties
java.nio.channels.ClosedChannelException
at sun.nio.ch.FileLockImpl.release(FileLockImpl.java:58)
at
org.apache.maven.repository.legacy.DefaultUpdateCheckManager.read(DefaultUpdateCheckManager.java:396)
at
org.apache.maven.repository.legacy.DefaultUpdateCheckManager.readLastUpdated(DefaultUpdateCheckManager.java:323)
at
org.apache.maven.repository.legacy.DefaultUpdateCheckManager.readLastUpdated(DefaultUpdateCheckManager.java:159)
at
org.apache.maven.repository.legacy.DefaultUpdateCheckManager.isUpdateRequired(DefaultUpdateCheckManager.java:148)
at
org.apache.maven.artifact.repository.metadata.DefaultRepositoryMetadataManager.resolve(DefaultRepositoryMetadataManager.java:127)
at
org.apache.maven.project.artifact.MavenMetadataSource.retrieveAvailableVersions(MavenMetadataSource.java:435)
at
org.apache.maven.project.artifact.MavenMetadataSource.retrieveAvailableVersions(MavenMetadataSource.java:425)
at
org.codehaus.mojo.versions.api.DefaultVersionsHelper.lookupArtifactVersions(DefaultVersionsHelper.java:229)
at
org.codehaus.mojo.versions.api.DefaultVersionsHelper.lookupPluginUpdates(DefaultVersionsHelper.java:727)
at
org.codehaus.mojo.versions.api.DefaultVersionsHelper.lookupPluginsUpdates(DefaultVersionsHelper.java:706)
at
org.codehaus.mojo.versions.PluginUpdatesReport.doGenerateReport(PluginUpdatesReport.java:103)
at
org.codehaus.mojo.versions.AbstractVersionsReport.executeReport(AbstractVersionsReport.java:253)
at
org.apache.maven.reporting.AbstractMavenReport.generate(AbstractMavenReport.java:90)
at
org.apache.maven.plugins.site.ReportDocumentRenderer.renderDocument(ReportDocumentRenderer.java:228)
at
org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.renderModule(DefaultSiteRenderer.java:319)
at
org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.render(DefaultSiteRenderer.java:135)
at
org.apache.maven.plugins.site.SiteMojo.renderLocale(SiteMojo.java:175)
at org.apache.maven.plugins.site.SiteMojo.execute(SiteMojo.java:138)
at
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:133)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
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:108)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:76)
at
org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
at
org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:116)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:361)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:155)
at org.apache.maven.cli.MavenCli.execute(MavenCli.java:584)
at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:213)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:157)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
[jira] (MNG-5629) ClosedChannelException from DefaultUpdateCheckManager.read
[
https://jira.codehaus.org/browse/MNG-5629?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=349214#comment-349214
]
Anthony Whitford commented on MNG-5629:
---
I can recreate with Java 8 Update 5 too. I think this should be reopened.
ClosedChannelException from DefaultUpdateCheckManager.read
--
Key: MNG-5629
URL: https://jira.codehaus.org/browse/MNG-5629
Project: Maven
Issue Type: Bug
Affects Versions: 3.2.1
Environment: Windows 7, Java 7 updated 25
Reporter: Anthony Whitford
I ran a build in debug mode ({{mvn -X}}) and noticed the following bug
(repeatedly):
{noformat}
[DEBUG] Error releasing shared lock for resolution tracking file:
C:\Users\awhitford\.m2\repository\org\apache\maven\plugins\maven-war-plugin\resolver-status.properties
java.nio.channels.ClosedChannelException
at sun.nio.ch.FileLockImpl.release(FileLockImpl.java:58)
at
org.apache.maven.repository.legacy.DefaultUpdateCheckManager.read(DefaultUpdateCheckManager.java:396)
at
org.apache.maven.repository.legacy.DefaultUpdateCheckManager.readLastUpdated(DefaultUpdateCheckManager.java:323)
at
org.apache.maven.repository.legacy.DefaultUpdateCheckManager.readLastUpdated(DefaultUpdateCheckManager.java:159)
at
org.apache.maven.repository.legacy.DefaultUpdateCheckManager.isUpdateRequired(DefaultUpdateCheckManager.java:148)
at
org.apache.maven.artifact.repository.metadata.DefaultRepositoryMetadataManager.resolve(DefaultRepositoryMetadataManager.java:127)
at
org.apache.maven.project.artifact.MavenMetadataSource.retrieveAvailableVersions(MavenMetadataSource.java:435)
at
org.apache.maven.project.artifact.MavenMetadataSource.retrieveAvailableVersions(MavenMetadataSource.java:425)
at
org.codehaus.mojo.versions.api.DefaultVersionsHelper.lookupArtifactVersions(DefaultVersionsHelper.java:229)
at
org.codehaus.mojo.versions.api.DefaultVersionsHelper.lookupPluginUpdates(DefaultVersionsHelper.java:727)
at
org.codehaus.mojo.versions.api.DefaultVersionsHelper.lookupPluginsUpdates(DefaultVersionsHelper.java:706)
at
org.codehaus.mojo.versions.PluginUpdatesReport.doGenerateReport(PluginUpdatesReport.java:103)
at
org.codehaus.mojo.versions.AbstractVersionsReport.executeReport(AbstractVersionsReport.java:253)
at
org.apache.maven.reporting.AbstractMavenReport.generate(AbstractMavenReport.java:90)
at
org.apache.maven.plugins.site.ReportDocumentRenderer.renderDocument(ReportDocumentRenderer.java:228)
at
org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.renderModule(DefaultSiteRenderer.java:319)
at
org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.render(DefaultSiteRenderer.java:135)
at
org.apache.maven.plugins.site.SiteMojo.renderLocale(SiteMojo.java:175)
at org.apache.maven.plugins.site.SiteMojo.execute(SiteMojo.java:138)
at
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:133)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
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:108)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:76)
at
org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
at
org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:116)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:361)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:155)
at org.apache.maven.cli.MavenCli.execute(MavenCli.java:584)
at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:213)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:157)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at
org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
at
org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
at
org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
at
org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
[jira] (MNG-5629) ClosedChannelException from DefaultUpdateCheckManager.read
[
https://jira.codehaus.org/browse/MNG-5629?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anthony Whitford reopened MNG-5629:
---
ClosedChannelException from DefaultUpdateCheckManager.read
--
Key: MNG-5629
URL: https://jira.codehaus.org/browse/MNG-5629
Project: Maven
Issue Type: Bug
Affects Versions: 3.2.1
Environment: Windows 7, Java 7 updated 25
Reporter: Anthony Whitford
I ran a build in debug mode ({{mvn -X}}) and noticed the following bug
(repeatedly):
{noformat}
[DEBUG] Error releasing shared lock for resolution tracking file:
C:\Users\awhitford\.m2\repository\org\apache\maven\plugins\maven-war-plugin\resolver-status.properties
java.nio.channels.ClosedChannelException
at sun.nio.ch.FileLockImpl.release(FileLockImpl.java:58)
at
org.apache.maven.repository.legacy.DefaultUpdateCheckManager.read(DefaultUpdateCheckManager.java:396)
at
org.apache.maven.repository.legacy.DefaultUpdateCheckManager.readLastUpdated(DefaultUpdateCheckManager.java:323)
at
org.apache.maven.repository.legacy.DefaultUpdateCheckManager.readLastUpdated(DefaultUpdateCheckManager.java:159)
at
org.apache.maven.repository.legacy.DefaultUpdateCheckManager.isUpdateRequired(DefaultUpdateCheckManager.java:148)
at
org.apache.maven.artifact.repository.metadata.DefaultRepositoryMetadataManager.resolve(DefaultRepositoryMetadataManager.java:127)
at
org.apache.maven.project.artifact.MavenMetadataSource.retrieveAvailableVersions(MavenMetadataSource.java:435)
at
org.apache.maven.project.artifact.MavenMetadataSource.retrieveAvailableVersions(MavenMetadataSource.java:425)
at
org.codehaus.mojo.versions.api.DefaultVersionsHelper.lookupArtifactVersions(DefaultVersionsHelper.java:229)
at
org.codehaus.mojo.versions.api.DefaultVersionsHelper.lookupPluginUpdates(DefaultVersionsHelper.java:727)
at
org.codehaus.mojo.versions.api.DefaultVersionsHelper.lookupPluginsUpdates(DefaultVersionsHelper.java:706)
at
org.codehaus.mojo.versions.PluginUpdatesReport.doGenerateReport(PluginUpdatesReport.java:103)
at
org.codehaus.mojo.versions.AbstractVersionsReport.executeReport(AbstractVersionsReport.java:253)
at
org.apache.maven.reporting.AbstractMavenReport.generate(AbstractMavenReport.java:90)
at
org.apache.maven.plugins.site.ReportDocumentRenderer.renderDocument(ReportDocumentRenderer.java:228)
at
org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.renderModule(DefaultSiteRenderer.java:319)
at
org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.render(DefaultSiteRenderer.java:135)
at
org.apache.maven.plugins.site.SiteMojo.renderLocale(SiteMojo.java:175)
at org.apache.maven.plugins.site.SiteMojo.execute(SiteMojo.java:138)
at
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:133)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
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:108)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:76)
at
org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
at
org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:116)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:361)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:155)
at org.apache.maven.cli.MavenCli.execute(MavenCli.java:584)
at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:213)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:157)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at
org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
at
org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
at
org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
at
org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
{noformat}
I traced the bug to the {{DefaultUpdateCheckManager.read}} method. [Line
[jira] (MNG-5629) ClosedChannelException from DefaultUpdateCheckManager.read
[
https://jira.codehaus.org/browse/MNG-5629?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=346218#comment-346218
]
Anthony Whitford commented on MNG-5629:
---
It looks like it is the {{site}} phase that causes this error: {{mvn -X site}}
You can use this project to replicate the issue:
[https://github.com/awhitford/lombok.maven]
Also note that I was able to reproduce the issue on a Mac too, so this isn't
limited to Windows.
And I was not able to replicate the issue with Maven 3.0.5, so this seems
limited to 3.2.1.
ClosedChannelException from DefaultUpdateCheckManager.read
--
Key: MNG-5629
URL: https://jira.codehaus.org/browse/MNG-5629
Project: Maven 2 3
Issue Type: Bug
Affects Versions: 3.2.1
Environment: Windows 7, Java 7 updated 25
Reporter: Anthony Whitford
I ran a build in debug mode ({{mvn -X}}) and noticed the following bug
(repeatedly):
{noformat}
[DEBUG] Error releasing shared lock for resolution tracking file:
C:\Users\awhitford\.m2\repository\org\apache\maven\plugins\maven-war-plugin\resolver-status.properties
java.nio.channels.ClosedChannelException
at sun.nio.ch.FileLockImpl.release(FileLockImpl.java:58)
at
org.apache.maven.repository.legacy.DefaultUpdateCheckManager.read(DefaultUpdateCheckManager.java:396)
at
org.apache.maven.repository.legacy.DefaultUpdateCheckManager.readLastUpdated(DefaultUpdateCheckManager.java:323)
at
org.apache.maven.repository.legacy.DefaultUpdateCheckManager.readLastUpdated(DefaultUpdateCheckManager.java:159)
at
org.apache.maven.repository.legacy.DefaultUpdateCheckManager.isUpdateRequired(DefaultUpdateCheckManager.java:148)
at
org.apache.maven.artifact.repository.metadata.DefaultRepositoryMetadataManager.resolve(DefaultRepositoryMetadataManager.java:127)
at
org.apache.maven.project.artifact.MavenMetadataSource.retrieveAvailableVersions(MavenMetadataSource.java:435)
at
org.apache.maven.project.artifact.MavenMetadataSource.retrieveAvailableVersions(MavenMetadataSource.java:425)
at
org.codehaus.mojo.versions.api.DefaultVersionsHelper.lookupArtifactVersions(DefaultVersionsHelper.java:229)
at
org.codehaus.mojo.versions.api.DefaultVersionsHelper.lookupPluginUpdates(DefaultVersionsHelper.java:727)
at
org.codehaus.mojo.versions.api.DefaultVersionsHelper.lookupPluginsUpdates(DefaultVersionsHelper.java:706)
at
org.codehaus.mojo.versions.PluginUpdatesReport.doGenerateReport(PluginUpdatesReport.java:103)
at
org.codehaus.mojo.versions.AbstractVersionsReport.executeReport(AbstractVersionsReport.java:253)
at
org.apache.maven.reporting.AbstractMavenReport.generate(AbstractMavenReport.java:90)
at
org.apache.maven.plugins.site.ReportDocumentRenderer.renderDocument(ReportDocumentRenderer.java:228)
at
org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.renderModule(DefaultSiteRenderer.java:319)
at
org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.render(DefaultSiteRenderer.java:135)
at
org.apache.maven.plugins.site.SiteMojo.renderLocale(SiteMojo.java:175)
at org.apache.maven.plugins.site.SiteMojo.execute(SiteMojo.java:138)
at
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:133)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
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:108)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:76)
at
org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
at
org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:116)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:361)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:155)
at org.apache.maven.cli.MavenCli.execute(MavenCli.java:584)
at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:213)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:157)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at
[jira] (MSHARED-266) run aggregator reports only when current projet is pom packaging and has modules
[ https://jira.codehaus.org/browse/MSHARED-266?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=346082#comment-346082 ] Anthony Whitford commented on MSHARED-266: -- Please accept my sincere appreciation for investigating this; this should positively impact build times. (y) run aggregator reports only when current projet is pom packaging and has modules Key: MSHARED-266 URL: https://jira.codehaus.org/browse/MSHARED-266 Project: Maven Shared Components Issue Type: Improvement Components: maven-reporting-exec Affects Versions: maven-reporting-exec-1.0.2 Reporter: Herve Boutemy Assignee: Herve Boutemy Fix For: maven-reporting-exec-1.2 would fix MSITE-454 simply adding a plugin to reporting section, without defining any reportSets, will avoid running aggregate reports in every module notice: this will work only with Maven 3, since Maven 2 runs reports from core and not from m-site-p/m-reporting-exec -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MNG-5629) ClosedChannelException from DefaultUpdateCheckManager.read
Anthony Whitford created MNG-5629:
-
Summary: ClosedChannelException from DefaultUpdateCheckManager.read
Key: MNG-5629
URL: https://jira.codehaus.org/browse/MNG-5629
Project: Maven 2 3
Issue Type: Bug
Affects Versions: 3.2.1
Environment: Windows 7, Java 7 updated 25
Reporter: Anthony Whitford
I ran a build in debug mode ({{mvn -X}}) and noticed the following bug
(repeatedly):
{noformat}
[DEBUG] Error releasing shared lock for resolution tracking file:
C:\Users\awhitford\.m2\repository\org\apache\maven\plugins\maven-war-plugin\resolver-status.properties
java.nio.channels.ClosedChannelException
at sun.nio.ch.FileLockImpl.release(FileLockImpl.java:58)
at
org.apache.maven.repository.legacy.DefaultUpdateCheckManager.read(DefaultUpdateCheckManager.java:396)
at
org.apache.maven.repository.legacy.DefaultUpdateCheckManager.readLastUpdated(DefaultUpdateCheckManager.java:323)
at
org.apache.maven.repository.legacy.DefaultUpdateCheckManager.readLastUpdated(DefaultUpdateCheckManager.java:159)
at
org.apache.maven.repository.legacy.DefaultUpdateCheckManager.isUpdateRequired(DefaultUpdateCheckManager.java:148)
at
org.apache.maven.artifact.repository.metadata.DefaultRepositoryMetadataManager.resolve(DefaultRepositoryMetadataManager.java:127)
at
org.apache.maven.project.artifact.MavenMetadataSource.retrieveAvailableVersions(MavenMetadataSource.java:435)
at
org.apache.maven.project.artifact.MavenMetadataSource.retrieveAvailableVersions(MavenMetadataSource.java:425)
at
org.codehaus.mojo.versions.api.DefaultVersionsHelper.lookupArtifactVersions(DefaultVersionsHelper.java:229)
at
org.codehaus.mojo.versions.api.DefaultVersionsHelper.lookupPluginUpdates(DefaultVersionsHelper.java:727)
at
org.codehaus.mojo.versions.api.DefaultVersionsHelper.lookupPluginsUpdates(DefaultVersionsHelper.java:706)
at
org.codehaus.mojo.versions.PluginUpdatesReport.doGenerateReport(PluginUpdatesReport.java:103)
at
org.codehaus.mojo.versions.AbstractVersionsReport.executeReport(AbstractVersionsReport.java:253)
at
org.apache.maven.reporting.AbstractMavenReport.generate(AbstractMavenReport.java:90)
at
org.apache.maven.plugins.site.ReportDocumentRenderer.renderDocument(ReportDocumentRenderer.java:228)
at
org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.renderModule(DefaultSiteRenderer.java:319)
at
org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.render(DefaultSiteRenderer.java:135)
at
org.apache.maven.plugins.site.SiteMojo.renderLocale(SiteMojo.java:175)
at org.apache.maven.plugins.site.SiteMojo.execute(SiteMojo.java:138)
at
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:133)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
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:108)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:76)
at
org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
at
org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:116)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:361)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:155)
at org.apache.maven.cli.MavenCli.execute(MavenCli.java:584)
at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:213)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:157)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at
org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
at
org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
at
org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
at
org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
{noformat}
I traced the bug to the {{DefaultUpdateCheckManager.read}} method. [Line
396|http://maven.apache.org/ref/3.2.1/apidocs/src-html/org/apache/maven/repository/legacy/DefaultUpdateCheckManager.html#line.396]
is releasing a FileLock, but the {{FileInputStream}} has
[jira] (WAGON-413) Private Key authentication is no longer working with wagon-ssh-2.6
Anthony Whitford created WAGON-413:
--
Summary: Private Key authentication is no longer working with
wagon-ssh-2.6
Key: WAGON-413
URL: https://jira.codehaus.org/browse/WAGON-413
Project: Maven Wagon
Issue Type: Bug
Components: wagon-ssh
Affects Versions: 2.6
Environment: Windows, Maven 3.0.4, Java 7 64-bit
Reporter: Anthony Whitford
Priority: Blocker
I have to provide the {{wagon-ssh}} dependency to the {{maven-site-plugin}} in
order to upload the site via {{scp}}. Authentication for the {{scp}} is done
via an _SSH key_.
Version 2.5 works fine, but when I upgrade to version 2.6, I am now getting a
Password prompt, and then a _Connection Refused_. (The Private Key should
negate a password prompt.)
With version 2.6, I get BUILD FAILURE:
{noformat}
[INFO] --- maven-site-plugin:3.3:deploy (default-deploy) @ wam-parentpom ---
Using private key: C:\Users\BuildAgent\.ssh\id_rsa
Password for buildagent@mvnsitehost:
scp://mvnsitehost/opt/maven/sites/project/3.4-SNAPSHOT/ - Session: Connection
refused
scp://mvnsitehost/opt/maven/sites/project/3.4-SNAPSHOT/ - Session:
Disconnecting
scp://mvnsitehost/opt/maven/sites/project/3.4-SNAPSHOT/ - Session: Disconnected
[INFO]
[INFO] BUILD FAILURE
{noformat}
With version 2.5, I get BUILD SUCCESS:
{noformat}
[INFO] --- maven-site-plugin:3.3:deploy (default-deploy) @ wam-parentpom ---
Using private key: C:\Users\BuildAgent\.ssh\id_rsa
scp://mvnsitehost/opt/maven/sites/project/3.4-SNAPSHOT/ - Session: Opened
[INFO] Pushing D:\BuildAgent\projects\Project\Build_Snapshot\target\site
[INFO] to scp://mvnsitehost/opt/maven/sites/project/3.4-SNAPSHOT/./
Executing command: mkdir -p /opt/maven/sites/project/3.4-SNAPSHOT/./
Executing command: mkdir -p /opt/maven/sites/project/3.4-SNAPSHOT/.
Executing command: scp -t
/opt/maven/sites/project/3.4-SNAPSHOT/./wagon4279752042048724778.zip
Uploading: ./wagon4279752042048724778.zip to
scp://mvnsitehost/opt/maven/sites/project/3.4-SNAPSHOT/
##
Transfer finished. 316495 bytes copied in 0.031 seconds
Executing command: cd /opt/maven/sites/project/3.4-SNAPSHOT/./; unzip -q -o
wagon4279752042048724778.zip; rm -f wagon4279752042048724778.zip
Executing command: chmod -Rf g+w,a+rX /opt/maven/sites/project/3.4-SNAPSHOT/
scp://mvnsitehost/opt/maven/sites/project/3.4-SNAPSHOT/ - Session:
Disconnecting
scp://mvnsitehost/opt/maven/sites/project/3.4-SNAPSHOT/ - Session: Disconnected
[INFO]
[INFO] BUILD SUCCESS
{noformat}
So, clearly the _new behavior_ is the _Connection Refused_:
{noformat}
Password for buildagent@mvnsitehost:
scp://mvnsitehost/opt/maven/sites/project/3.4-SNAPSHOT/ - Session: Connection
refused
{noformat}
(?) Could version 2.6 have broken the private key logic?
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (WAGON-413) Private Key authentication is no longer working with wagon-ssh-2.6
[
https://jira.codehaus.org/browse/WAGON-413?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anthony Whitford updated WAGON-413:
---
Description:
I have to provide the {{wagon-ssh}} dependency to the {{maven-site-plugin}} in
order to upload the site via {{scp}}. Authentication for the {{scp}} is done
via an _SSH key_.
Version 2.5 works fine, but when I upgrade to version 2.6, I am now getting a
Password prompt, and then a _Connection Refused_. (The Private Key should
negate a password prompt.)
With version 2.6, I get BUILD FAILURE:
{noformat}
[INFO] --- maven-site-plugin:3.3:deploy (default-deploy) @ project ---
Using private key: C:\Users\BuildAgent\.ssh\id_rsa
Password for buildagent@mvnsitehost:
scp://mvnsitehost/opt/maven/sites/project/3.4-SNAPSHOT/ - Session: Connection
refused
scp://mvnsitehost/opt/maven/sites/project/3.4-SNAPSHOT/ - Session:
Disconnecting
scp://mvnsitehost/opt/maven/sites/project/3.4-SNAPSHOT/ - Session: Disconnected
[INFO]
[INFO] BUILD FAILURE
{noformat}
With version 2.5, I get BUILD SUCCESS:
{noformat}
[INFO] --- maven-site-plugin:3.3:deploy (default-deploy) @ project ---
Using private key: C:\Users\BuildAgent\.ssh\id_rsa
scp://mvnsitehost/opt/maven/sites/project/3.4-SNAPSHOT/ - Session: Opened
[INFO] Pushing D:\BuildAgent\projects\Project\Build_Snapshot\target\site
[INFO] to scp://mvnsitehost/opt/maven/sites/project/3.4-SNAPSHOT/./
Executing command: mkdir -p /opt/maven/sites/project/3.4-SNAPSHOT/./
Executing command: mkdir -p /opt/maven/sites/project/3.4-SNAPSHOT/.
Executing command: scp -t
/opt/maven/sites/project/3.4-SNAPSHOT/./wagon4279752042048724778.zip
Uploading: ./wagon4279752042048724778.zip to
scp://mvnsitehost/opt/maven/sites/project/3.4-SNAPSHOT/
##
Transfer finished. 316495 bytes copied in 0.031 seconds
Executing command: cd /opt/maven/sites/project/3.4-SNAPSHOT/./; unzip -q -o
wagon4279752042048724778.zip; rm -f wagon4279752042048724778.zip
Executing command: chmod -Rf g+w,a+rX /opt/maven/sites/project/3.4-SNAPSHOT/
scp://mvnsitehost/opt/maven/sites/project/3.4-SNAPSHOT/ - Session:
Disconnecting
scp://mvnsitehost/opt/maven/sites/project/3.4-SNAPSHOT/ - Session: Disconnected
[INFO]
[INFO] BUILD SUCCESS
{noformat}
So, clearly the _new behavior_ is the _Connection Refused_:
{noformat}
Password for buildagent@mvnsitehost:
scp://mvnsitehost/opt/maven/sites/project/3.4-SNAPSHOT/ - Session: Connection
refused
{noformat}
(?) Could version 2.6 have broken the private key logic?
was:
I have to provide the {{wagon-ssh}} dependency to the {{maven-site-plugin}} in
order to upload the site via {{scp}}. Authentication for the {{scp}} is done
via an _SSH key_.
Version 2.5 works fine, but when I upgrade to version 2.6, I am now getting a
Password prompt, and then a _Connection Refused_. (The Private Key should
negate a password prompt.)
With version 2.6, I get BUILD FAILURE:
{noformat}
[INFO] --- maven-site-plugin:3.3:deploy (default-deploy) @ wam-parentpom ---
Using private key: C:\Users\BuildAgent\.ssh\id_rsa
Password for buildagent@mvnsitehost:
scp://mvnsitehost/opt/maven/sites/project/3.4-SNAPSHOT/ - Session: Connection
refused
scp://mvnsitehost/opt/maven/sites/project/3.4-SNAPSHOT/ - Session:
Disconnecting
scp://mvnsitehost/opt/maven/sites/project/3.4-SNAPSHOT/ - Session: Disconnected
[INFO]
[INFO] BUILD FAILURE
{noformat}
With version 2.5, I get BUILD SUCCESS:
{noformat}
[INFO] --- maven-site-plugin:3.3:deploy (default-deploy) @ wam-parentpom ---
Using private key: C:\Users\BuildAgent\.ssh\id_rsa
scp://mvnsitehost/opt/maven/sites/project/3.4-SNAPSHOT/ - Session: Opened
[INFO] Pushing D:\BuildAgent\projects\Project\Build_Snapshot\target\site
[INFO] to scp://mvnsitehost/opt/maven/sites/project/3.4-SNAPSHOT/./
Executing command: mkdir -p /opt/maven/sites/project/3.4-SNAPSHOT/./
Executing command: mkdir -p /opt/maven/sites/project/3.4-SNAPSHOT/.
Executing command: scp -t
/opt/maven/sites/project/3.4-SNAPSHOT/./wagon4279752042048724778.zip
Uploading: ./wagon4279752042048724778.zip to
scp://mvnsitehost/opt/maven/sites/project/3.4-SNAPSHOT/
##
Transfer finished. 316495 bytes copied in 0.031 seconds
Executing command: cd /opt/maven/sites/project/3.4-SNAPSHOT/./; unzip -q -o
wagon4279752042048724778.zip; rm -f wagon4279752042048724778.zip
Executing command: chmod -Rf g+w,a+rX /opt/maven/sites/project/3.4-SNAPSHOT/
scp://mvnsitehost/opt/maven/sites/project/3.4-SNAPSHOT/ - Session:
Disconnecting
scp://mvnsitehost/opt/maven/sites/project/3.4-SNAPSHOT/
[jira] (MPMD-176) upgrade to last 5.0.5
[ https://jira.codehaus.org/browse/MPMD-176?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=341409#comment-341409 ] Anthony Whitford commented on MPMD-176: --- Looks like [PMD 5.1.0|http://pmd.sourceforge.net/pmd-5.1.0/changelog.html] has been released now... upgrade to last 5.0.5 - Key: MPMD-176 URL: https://jira.codehaus.org/browse/MPMD-176 Project: Maven PMD Plugin Issue Type: Bug Components: PMD Reporter: Olivier Lamy Assignee: Olivier Lamy Fix For: 3.1 need a workaround to a PMD bug. see https://github.com/apache/maven-plugins/pull/16 -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MPMD-181) Add flag to capture Benchmark information
Anthony Whitford created MPMD-181: - Summary: Add flag to capture Benchmark information Key: MPMD-181 URL: https://jira.codehaus.org/browse/MPMD-181 Project: Maven PMD Plugin Issue Type: New Feature Components: PMD Affects Versions: 3.0.1 Reporter: Anthony Whitford PMD 5 has a capability to capture Benchmark information. This information can be useful to diagnose where time is being spent. I would like to see this feature exposed from the plugin. It can be disabled by default, but it would be really handy to diagnose slow runs. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MPMD-181) Add flag to capture Benchmark information
[ https://jira.codehaus.org/browse/MPMD-181?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anthony Whitford updated MPMD-181: -- Attachment: mpmd-181.diff Patch file submitted. Add flag to capture Benchmark information - Key: MPMD-181 URL: https://jira.codehaus.org/browse/MPMD-181 Project: Maven PMD Plugin Issue Type: New Feature Components: PMD Affects Versions: 3.0.1 Reporter: Anthony Whitford Fix For: 3.1 Attachments: mpmd-181.diff PMD 5 has a capability to capture Benchmark information. This information can be useful to diagnose where time is being spent. I would like to see this feature exposed from the plugin. It can be disabled by default, but it would be really handy to diagnose slow runs. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MPMD-181) Add flag to capture Benchmark information
[ https://jira.codehaus.org/browse/MPMD-181?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anthony Whitford updated MPMD-181: -- Fix Version/s: 3.1 Add flag to capture Benchmark information - Key: MPMD-181 URL: https://jira.codehaus.org/browse/MPMD-181 Project: Maven PMD Plugin Issue Type: New Feature Components: PMD Affects Versions: 3.0.1 Reporter: Anthony Whitford Fix For: 3.1 Attachments: mpmd-181.diff PMD 5 has a capability to capture Benchmark information. This information can be useful to diagnose where time is being spent. I would like to see this feature exposed from the plugin. It can be disabled by default, but it would be really handy to diagnose slow runs. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MSCMPUB-4) Need a working example for GitHub/gh-pages, preferably naturally linked to natural site lifecycle, and multi-module
[
https://jira.codehaus.org/browse/MSCMPUB-4?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=340388#comment-340388
]
Anthony Whitford commented on MSCMPUB-4:
For the *Maven Multi Module Configuration* advice, it mentions this command:
{noformat}
mvn -Preporting site site:stage
{noformat}
Is the {{reporting}} profile necessary? (Because it doesn't seem to exist.)
I am able to stage the site just fine, but the next step:
{noformat}
mvn scm-publish:publish-scm
{noformat}
is failing for me with:
{noformat}
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-scm-publish-plugin:1.0-SNAPSHOT:publish-scm
(default-cli)
on project lombok-maven: Execution default-cli of goal
org.apache.maven.plugins:maven-scm-publish-plugin:1.0-SNAPSHOT:
publish-scm failed: The scm url cannot be null. - [Help 1]
{noformat}
The root issue seems to be here:
{noformat}
Caused by: java.lang.NullPointerException: The scm url cannot be null.
at
org.apache.maven.scm.manager.AbstractScmManager.makeScmRepository(AbstractScmManager.java:195)
at
org.apache.maven.shared.release.scm.DefaultScmRepositoryConfigurator.getConfiguredRepository(DefaultScmRepositoryConfigurator.java:78)
at
org.apache.maven.shared.release.scm.DefaultScmRepositoryConfigurator.getConfiguredRepository(DefaultScmRepositoryConfigurator.java:67)
{noformat}
And the debug information for the plugin is:
{noformat}
[DEBUG] Configuring mojo
org.apache.maven.plugins:maven-scm-publish-plugin:1.0-SNAPSHOT:publish-scm from
plugin realm
ClassRealm[pluginorg.apache.maven.plugins:maven-scm-publish-plugin:1.0-SNAPSHOT,
parent: sun.misc.Launcher$AppClassLoader@713c817]
[DEBUG] Configuring mojo
'org.apache.maven.plugins:maven-scm-publish-plugin:1.0-SNAPSHOT:publish-scm'
with basic configurator --
[DEBUG] (f) automaticRemotePathCreation = true
[DEBUG] (f) basedir = /Users/anthony/Documents/lombok.maven
[DEBUG] (f) checkinComment = Site checkin for project Maven Plugin for
Project Lombok
[DEBUG] (f) checkoutDirectory =
/Users/anthony/Documents/lombok.maven/target/scmpublish-checkout
[DEBUG] (f) content = /Users/anthony/Documents/lombok.maven/target/staging
[DEBUG] (f) localCheckout = false
[DEBUG] (s) pubScmUrl = scm:git:g...@github.com:awhitford/lombok.maven.git
[DEBUG] (f) scmBranch = gh-pages
[DEBUG] (f) siteOutputEncoding = UTF-8
[DEBUG] (f) skipDeletedFiles = false
[DEBUG] (f) tryUpdate = false
[DEBUG] (f) project = MavenProject:
org.projectlombok:lombok-maven:1.12.4.0-SNAPSHOT @
/Users/anthony/Documents/lombok.maven/pom.xml
[DEBUG] (f) settings = org.apache.maven.execution.SettingsAdapter@dcd88ea
[DEBUG] -- end configuration --
{noformat}
_Am I doing something wrong?_
Need a working example for GitHub/gh-pages, preferably naturally linked to
natural site lifecycle, and multi-module
---
Key: MSCMPUB-4
URL: https://jira.codehaus.org/browse/MSCMPUB-4
Project: maven-scm-publish-plugin
Issue Type: Story
Environment: Mac OSX 10.8.2, Java 1.6 Update 35, Maven 3.0.4, Maven
Site Plugin 3.2, Maven SCM Plugin 1.8, Git
Reporter: Anthony Whitford
Priority: Critical
I am trying to update my
[lombok-maven-plugin|http://awhitford.github.com/lombok.maven/lombok-maven-plugin/index.html]
project to use this plugin to publish the project to _Github Pages_.
When I try this command:
{noformat}
mvn clean site site:stage-deploy scm-publish:publish-scm
{noformat}
which is outlined
[here|http://maven.apache.org/plugins/maven-scm-publish-plugin/examples/multi-module-configuration.html],
I get this error:
{noformat}
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-scm-publish-plugin:1.0-beta-1:publish-scm
(default-cli) on project lombok-maven: Unable to checkout from SCM
[ERROR] Provider message:
[ERROR] The git-log command failed.
[ERROR] Command output:
[ERROR] fatal: ambiguous argument 'master': unknown revision or path not in
the working tree.
[ERROR] Use '--' to separate paths from revisions
{noformat}
(?) Is there a multi-module project in GitHub that uses this plugin that I
can use as an example?
This is what I did so far...
{code:xml}
properties
siteMainDirectory${user.home}/Sites/lombok.maven/siteMainDirectory
scmPubCheckoutDirectory${user.home}/site-content-scm/lombok.maven/scmPubCheckoutDirectory
/properties
...
pluginManagement
plugins
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-site-plugin/artifactId
version3.2/version
configuration
skipDeploytrue/skipDeploy
stagingSiteURLfile://${siteMainDirectory}/stagingSiteURL
/configuration
/plugin
...
/plugins
/pluginManagement
...
plugins
[jira] (MCHANGES-307) Check for whitespace on fixVersionIds and statusIds
[
https://jira.codehaus.org/browse/MCHANGES-307?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=340433#comment-340433
]
Anthony Whitford commented on MCHANGES-307:
---
I might be getting this issue too with Jira 6.1.5:
{noformat}
[INFO] Generating JIRA Report report--- maven-changes-plugin:2.9
[WARNING]
org.apache.maven.plugin.MojoFailureException: Could not find status Resolved.
at
org.apache.maven.plugin.jira.RestJiraDownloader.resolveOneItem(RestJiraDownloader.java:259)
at
org.apache.maven.plugin.jira.RestJiraDownloader.resolveList(RestJiraDownloader.java:240)
at
org.apache.maven.plugin.jira.RestJiraDownloader.resolveIds(RestJiraDownloader.java:206)
at
org.apache.maven.plugin.jira.RestJiraDownloader.doExecute(RestJiraDownloader.java:128)
at
org.apache.maven.plugin.jira.AdaptiveJiraDownloader.doExecute(AdaptiveJiraDownloader.java:47)
at
org.apache.maven.plugin.jira.JiraMojo.executeReport(JiraMojo.java:367)
at
org.apache.maven.reporting.AbstractMavenReport.generate(AbstractMavenReport.java:190)
at
org.apache.maven.plugins.site.ReportDocumentRenderer.renderDocument(ReportDocumentRenderer.java:219)
at
org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.renderModule(DefaultSiteRenderer.java:319)
at
org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.render(DefaultSiteRenderer.java:135)
at
org.apache.maven.plugins.site.SiteMojo.renderLocale(SiteMojo.java:175)
at org.apache.maven.plugins.site.SiteMojo.execute(SiteMojo.java:138)
at
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)
{noformat}
Note that I don't see the extra space being an issue... My pom configuration
looks like:
{code:xml}
configuration
jiraUserXXX/jiraUser
jiraPassword/jiraPassword
maxEntries500/maxEntries
onlyCurrentVersiontrue/onlyCurrentVersion
statusIdsResolved,Closed/statusIds
useJqltrue/useJql
/configuration
reportSets
reportSet
reports
reportjira-report/report
/reports
/reportSet
/reportSets
{code}
Check for whitespace on fixVersionIds and statusIds
---
Key: MCHANGES-307
URL: https://jira.codehaus.org/browse/MCHANGES-307
Project: Maven Changes Plugin
Issue Type: Bug
Components: jira
Affects Versions: 2.9
Reporter: Tobias Rübner
Attachments: MCHANGES-307.patch
On the configuration of the maven changes plugin for the jira-report there
are some configuration parameters that do not like whitespace.
I think this will include component, fixVersionIds, statusIds, resolutionIds,
typeIds and priorityIds.
The report generation will fail with the follwing error:
{code}
org.apache.maven.plugin.MojoFailureException: Could not find status Closed.
at
org.apache.maven.plugin.jira.RestJiraDownloader.resolveOneItem(RestJiraDownloader.java:268)
at
org.apache.maven.plugin.jira.RestJiraDownloader.resolveList(RestJiraDownloader.java:249)
at
org.apache.maven.plugin.jira.RestJiraDownloader.resolveIds(RestJiraDownloader.java:214)
at
org.apache.maven.plugin.jira.RestJiraDownloader.doExecute(RestJiraDownloader.java:129)
at
org.apache.maven.plugin.jira.AdaptiveJiraDownloader.doExecute(AdaptiveJiraDownloader.java:47)
at
org.apache.maven.plugin.jira.JiraMojo.executeReport(JiraMojo.java:367)
...
{code}
Note the leading whitespace that came through the definition in the pom file.
{code}
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-changes-plugin/artifactId
configuration
useJqltrue/useJql
jiraUser${jira.user}/jiraUser
jiraPassword${jira.password}/jiraPassword
onlyCurrentVersiontrue/onlyCurrentVersion
resolutionIdsFixed/resolutionIds
statusIdsResolved, Closed/statusIds
/configuration
reportSets
reportSet
reports
reportjira-report/report
/reports
/reportSet
/reportSets
/plugin
{code}
I possible solution could be to trim the whitespace.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MCHANGES-324) plugin logs into jira, but doesn't seem to make the status request with the session?
[
https://jira.codehaus.org/browse/MCHANGES-324?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=340434#comment-340434
]
Anthony Whitford commented on MCHANGES-324:
---
This is what I am running into too, and I get the following stack trace:
{noformat}
[INFO] Generating JIRA Report report--- maven-changes-plugin:2.9
[WARNING]
org.apache.maven.plugin.MojoFailureException: Could not find status Closed.
at
org.apache.maven.plugin.jira.RestJiraDownloader.resolveOneItem(RestJiraDownloader.java:259)
at
org.apache.maven.plugin.jira.RestJiraDownloader.resolveList(RestJiraDownloader.java:240)
at
org.apache.maven.plugin.jira.RestJiraDownloader.resolveIds(RestJiraDownloader.java:206)
at
org.apache.maven.plugin.jira.RestJiraDownloader.doExecute(RestJiraDownloader.java:128)
at
org.apache.maven.plugin.jira.AdaptiveJiraDownloader.doExecute(AdaptiveJiraDownloader.java:47)
at
org.apache.maven.plugin.jira.JiraMojo.executeReport(JiraMojo.java:367)
at
org.apache.maven.reporting.AbstractMavenReport.generate(AbstractMavenReport.java:190)
at
org.apache.maven.plugins.site.ReportDocumentRenderer.renderDocument(ReportDocumentRenderer.java:219)
{noformat}
Can this please be placed on the 2.10 Road Map?
plugin logs into jira, but doesn't seem to make the status request with the
session?
Key: MCHANGES-324
URL: https://jira.codehaus.org/browse/MCHANGES-324
Project: Maven Changes Plugin
Issue Type: Bug
Reporter: Antony Stubbs
After successful login, I end up with:
{code}
Nov 11, 2013 5:47:19 PM org.apache.cxf.interceptor.LoggingOutInterceptor
INFO: Outbound Message
---
ID: 3
Address: https://x/rest/api/2/status
Http-Method: GET
Content-Type: application/json
Headers: {Accept=[application/json], Content-Type=[application/json]}
--
Nov 11, 2013 5:47:19 PM org.apache.cxf.interceptor.LoggingInInterceptor
INFO: Inbound Message
ID: 3
Response-Code: 200
Encoding: UTF-8
Content-Type: application/json;charset=UTF-8
Headers: {Cache-Control=[no-cache, no-store, no-transform],
connection=[keep-alive], Content-Length=[2],
content-type=[application/json;charset=UTF-8], Date=[Mon, 11 Nov 2013
22:47:30 GMT], Server=[nginx],
Set-Cookie=[atlassian.xsrf.token=B14E-GL73-6FKZ-OP3B|dd19dbabf6f82c59be235929d3f1ee8d9e41fa4a|lout;
Path=/], Strict-Transport-Security=[max-age=31536;includeSubdomains],
Vary=[Accept-Encoding], X-AREQUESTID=[1067x34467x1], X-ASEN=[SEN-2356824],
X-AUSERNAME=[anonymous]}
Payload: []
{code}
Which returns nothing as you can see. I think that may be because it has
X-AUSERNAME=[anonymous] ? Instead of using the session it created...
After logging into jira in chrome, pasting the just the rest url into the
browser returns all the different status (works as I'd expect).
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MCHANGES-307) Check for whitespace on fixVersionIds and statusIds
[
https://jira.codehaus.org/browse/MCHANGES-307?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anthony Whitford updated MCHANGES-307:
--
Comment: was deleted
(was: I might be getting this issue too with Jira 6.1.5:
{noformat}
[INFO] Generating JIRA Report report--- maven-changes-plugin:2.9
[WARNING]
org.apache.maven.plugin.MojoFailureException: Could not find status Resolved.
at
org.apache.maven.plugin.jira.RestJiraDownloader.resolveOneItem(RestJiraDownloader.java:259)
at
org.apache.maven.plugin.jira.RestJiraDownloader.resolveList(RestJiraDownloader.java:240)
at
org.apache.maven.plugin.jira.RestJiraDownloader.resolveIds(RestJiraDownloader.java:206)
at
org.apache.maven.plugin.jira.RestJiraDownloader.doExecute(RestJiraDownloader.java:128)
at
org.apache.maven.plugin.jira.AdaptiveJiraDownloader.doExecute(AdaptiveJiraDownloader.java:47)
at
org.apache.maven.plugin.jira.JiraMojo.executeReport(JiraMojo.java:367)
at
org.apache.maven.reporting.AbstractMavenReport.generate(AbstractMavenReport.java:190)
at
org.apache.maven.plugins.site.ReportDocumentRenderer.renderDocument(ReportDocumentRenderer.java:219)
at
org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.renderModule(DefaultSiteRenderer.java:319)
at
org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.render(DefaultSiteRenderer.java:135)
at
org.apache.maven.plugins.site.SiteMojo.renderLocale(SiteMojo.java:175)
at org.apache.maven.plugins.site.SiteMojo.execute(SiteMojo.java:138)
at
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)
{noformat}
Note that I don't see the extra space being an issue... My pom configuration
looks like:
{code:xml}
configuration
jiraUserXXX/jiraUser
jiraPassword/jiraPassword
maxEntries500/maxEntries
onlyCurrentVersiontrue/onlyCurrentVersion
statusIdsResolved,Closed/statusIds
useJqltrue/useJql
/configuration
reportSets
reportSet
reports
reportjira-report/report
/reports
/reportSet
/reportSets
{code}
)
Check for whitespace on fixVersionIds and statusIds
---
Key: MCHANGES-307
URL: https://jira.codehaus.org/browse/MCHANGES-307
Project: Maven Changes Plugin
Issue Type: Bug
Components: jira
Affects Versions: 2.9
Reporter: Tobias Rübner
Attachments: MCHANGES-307.patch
On the configuration of the maven changes plugin for the jira-report there
are some configuration parameters that do not like whitespace.
I think this will include component, fixVersionIds, statusIds, resolutionIds,
typeIds and priorityIds.
The report generation will fail with the follwing error:
{code}
org.apache.maven.plugin.MojoFailureException: Could not find status Closed.
at
org.apache.maven.plugin.jira.RestJiraDownloader.resolveOneItem(RestJiraDownloader.java:268)
at
org.apache.maven.plugin.jira.RestJiraDownloader.resolveList(RestJiraDownloader.java:249)
at
org.apache.maven.plugin.jira.RestJiraDownloader.resolveIds(RestJiraDownloader.java:214)
at
org.apache.maven.plugin.jira.RestJiraDownloader.doExecute(RestJiraDownloader.java:129)
at
org.apache.maven.plugin.jira.AdaptiveJiraDownloader.doExecute(AdaptiveJiraDownloader.java:47)
at
org.apache.maven.plugin.jira.JiraMojo.executeReport(JiraMojo.java:367)
...
{code}
Note the leading whitespace that came through the definition in the pom file.
{code}
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-changes-plugin/artifactId
configuration
useJqltrue/useJql
jiraUser${jira.user}/jiraUser
jiraPassword${jira.password}/jiraPassword
onlyCurrentVersiontrue/onlyCurrentVersion
resolutionIdsFixed/resolutionIds
statusIdsResolved, Closed/statusIds
/configuration
reportSets
reportSet
reports
reportjira-report/report
/reports
/reportSet
/reportSets
/plugin
{code}
I possible solution could be to trim the whitespace.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MSCMPUB-4) Need a working example for GitHub/gh-pages, preferably naturally linked to natural site lifecycle, and multi-module
[
https://jira.codehaus.org/browse/MSCMPUB-4?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=340442#comment-340442
]
Anthony Whitford commented on MSCMPUB-4:
Awesome! It looks like it worked:
[lombok.maven|http://awhitford.github.io/lombok.maven/]
Need a working example for GitHub/gh-pages, preferably naturally linked to
natural site lifecycle, and multi-module
---
Key: MSCMPUB-4
URL: https://jira.codehaus.org/browse/MSCMPUB-4
Project: maven-scm-publish-plugin
Issue Type: Story
Environment: Mac OSX 10.8.2, Java 1.6 Update 35, Maven 3.0.4, Maven
Site Plugin 3.2, Maven SCM Plugin 1.8, Git
Reporter: Anthony Whitford
Priority: Critical
I am trying to update my
[lombok-maven-plugin|http://awhitford.github.com/lombok.maven/lombok-maven-plugin/index.html]
project to use this plugin to publish the project to _Github Pages_.
When I try this command:
{noformat}
mvn clean site site:stage-deploy scm-publish:publish-scm
{noformat}
which is outlined
[here|http://maven.apache.org/plugins/maven-scm-publish-plugin/examples/multi-module-configuration.html],
I get this error:
{noformat}
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-scm-publish-plugin:1.0-beta-1:publish-scm
(default-cli) on project lombok-maven: Unable to checkout from SCM
[ERROR] Provider message:
[ERROR] The git-log command failed.
[ERROR] Command output:
[ERROR] fatal: ambiguous argument 'master': unknown revision or path not in
the working tree.
[ERROR] Use '--' to separate paths from revisions
{noformat}
(?) Is there a multi-module project in GitHub that uses this plugin that I
can use as an example?
This is what I did so far...
{code:xml}
properties
siteMainDirectory${user.home}/Sites/lombok.maven/siteMainDirectory
scmPubCheckoutDirectory${user.home}/site-content-scm/lombok.maven/scmPubCheckoutDirectory
/properties
...
pluginManagement
plugins
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-site-plugin/artifactId
version3.2/version
configuration
skipDeploytrue/skipDeploy
stagingSiteURLfile://${siteMainDirectory}/stagingSiteURL
/configuration
/plugin
...
/plugins
/pluginManagement
...
plugins
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-site-plugin/artifactId
executions
execution
idstage-for-scm-publish/id
phasepost-site/phase
goals
goalstage/goal
/goals
/execution
/executions
/plugin
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-scm-publish-plugin/artifactId
version1.0-beta-1/version
configuration
checkoutDirectory${scmPubCheckoutDirectory}/checkoutDirectory
content\${siteMainDirectory}/content
tryUpdatetrue/tryUpdate
scmBranchgh-pages/scmBranch
pubScmUrlscm:git:g...@github.com:awhitford/lombok.maven.git/pubScmUrl
/configuration
executions
execution
idscm-publish/id
phasesite-deploy/phase
goals
goalpublish-scm/goal
/goals
/execution
/executions
/plugin
/plugins
{code}
Finally, I'm really interested in wiring this up so that when I do a normal
{{site-deploy}} or an implicit one through the release process, it gets
published to {{gh-pages}} -- just like I had working with
[wagon-gitsite|https://github.com/awhitford/wagon-gitsite].
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MSCMPUB-4) Need a working example for GitHub/gh-pages, preferably naturally linked to natural site lifecycle, and multi-module
[
https://jira.codehaus.org/browse/MSCMPUB-4?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=340333#comment-340333
]
Anthony Whitford commented on MSCMPUB-4:
I will try...
Need a working example for GitHub/gh-pages, preferably naturally linked to
natural site lifecycle, and multi-module
---
Key: MSCMPUB-4
URL: https://jira.codehaus.org/browse/MSCMPUB-4
Project: maven-scm-publish-plugin
Issue Type: Story
Environment: Mac OSX 10.8.2, Java 1.6 Update 35, Maven 3.0.4, Maven
Site Plugin 3.2, Maven SCM Plugin 1.8, Git
Reporter: Anthony Whitford
Priority: Critical
I am trying to update my
[lombok-maven-plugin|http://awhitford.github.com/lombok.maven/lombok-maven-plugin/index.html]
project to use this plugin to publish the project to _Github Pages_.
When I try this command:
{noformat}
mvn clean site site:stage-deploy scm-publish:publish-scm
{noformat}
which is outlined
[here|http://maven.apache.org/plugins/maven-scm-publish-plugin/examples/multi-module-configuration.html],
I get this error:
{noformat}
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-scm-publish-plugin:1.0-beta-1:publish-scm
(default-cli) on project lombok-maven: Unable to checkout from SCM
[ERROR] Provider message:
[ERROR] The git-log command failed.
[ERROR] Command output:
[ERROR] fatal: ambiguous argument 'master': unknown revision or path not in
the working tree.
[ERROR] Use '--' to separate paths from revisions
{noformat}
(?) Is there a multi-module project in GitHub that uses this plugin that I
can use as an example?
This is what I did so far...
{code:xml}
properties
siteMainDirectory${user.home}/Sites/lombok.maven/siteMainDirectory
scmPubCheckoutDirectory${user.home}/site-content-scm/lombok.maven/scmPubCheckoutDirectory
/properties
...
pluginManagement
plugins
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-site-plugin/artifactId
version3.2/version
configuration
skipDeploytrue/skipDeploy
stagingSiteURLfile://${siteMainDirectory}/stagingSiteURL
/configuration
/plugin
...
/plugins
/pluginManagement
...
plugins
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-site-plugin/artifactId
executions
execution
idstage-for-scm-publish/id
phasepost-site/phase
goals
goalstage/goal
/goals
/execution
/executions
/plugin
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-scm-publish-plugin/artifactId
version1.0-beta-1/version
configuration
checkoutDirectory${scmPubCheckoutDirectory}/checkoutDirectory
content\${siteMainDirectory}/content
tryUpdatetrue/tryUpdate
scmBranchgh-pages/scmBranch
pubScmUrlscm:git:g...@github.com:awhitford/lombok.maven.git/pubScmUrl
/configuration
executions
execution
idscm-publish/id
phasesite-deploy/phase
goals
goalpublish-scm/goal
/goals
/execution
/executions
/plugin
/plugins
{code}
Finally, I'm really interested in wiring this up so that when I do a normal
{{site-deploy}} or an implicit one through the release process, it gets
published to {{gh-pages}} -- just like I had working with
[wagon-gitsite|https://github.com/awhitford/wagon-gitsite].
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MPMD-169) Support multi-threaded mode of PMD 5
[ https://jira.codehaus.org/browse/MPMD-169?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=340385#comment-340385 ] Anthony Whitford commented on MPMD-169: --- I think I desperately need this as I just realized that the PMD report is the slowest component of a seriously long build. Support multi-threaded mode of PMD 5 Key: MPMD-169 URL: https://jira.codehaus.org/browse/MPMD-169 Project: Maven PMD Plugin Issue Type: Improvement Components: PMD Affects Versions: 3.0 Reporter: Andreas Dangel Assignee: Olivier Lamy Priority: Minor Fix For: 3.1 PMD 5 supports executing in multi-threaded mode, which should be a performance improvement in case you have multiple cores. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (WAGON-355) Expose PreferredAuthentications property of jsch in some way
[
https://jira.codehaus.org/browse/WAGON-355?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=337616#comment-337616
]
Anthony Whitford commented on WAGON-355:
Actually, it seems that the default value for {{PreferredAuthentications}} is:
{noformat}gssapi-with-mic,publickey,keyboard-interactive,password{noformat}
The
[logic|http://maven.apache.org/wagon/wagon-providers/wagon-ssh/xref/org/apache/maven/wagon/providers/ssh/jsch/AbstractJschWagon.html#224]
is revising it if a password is detected -- it changes it to:
{noformat}gssapi-with-mic,publickey,password,keyboard-interactive{noformat}
(Now, password is specified before a keyboard prompt.)
Expose PreferredAuthentications property of jsch in some way
Key: WAGON-355
URL: https://jira.codehaus.org/browse/WAGON-355
Project: Maven Wagon
Issue Type: Improvement
Components: wagon-ssh
Affects Versions: 2.0
Environment: Any. I happened to test with Maven 2.2.1 and jdk 1.7
Reporter: Lester Ward
Priority: Minor
Deploy using scp. Under jdk 1.7, support for gssapi-with-mic works
differently than it did under jdk 1.6, to the point where we do not want to
use it. Ultimately, the deploy plugin uses the jsch library to deploy using
scp. This library has an property called PreferredAuthentications which
controls which authentications get used, in which order. The code in
AbstractJschWagon hard-codes
gssapi-with-mic,publickey,password,keyboard-interactive into this property.
I'd like a way to somehow override that, preferably in my project's pom file.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MCHANGES-318) Limit report to only parent for a multi-module
Anthony Whitford created MCHANGES-318: - Summary: Limit report to only parent for a multi-module Key: MCHANGES-318 URL: https://jira.codehaus.org/browse/MCHANGES-318 Project: Maven Changes Plugin Issue Type: Improvement Affects Versions: 2.9 Environment: Windows 7, Java 6, Maven 3.0.4 Reporter: Anthony Whitford When running this report for a multi-module project, it seems repetitive; I only need the report to run once for the top-level... _How can that be done?_ -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MSHADE-145) Site not generated correctly when overriding dependencyReducedPomLocation with relocation
Anthony Whitford created MSHADE-145:
---
Summary: Site not generated correctly when overriding
dependencyReducedPomLocation with relocation
Key: MSHADE-145
URL: https://jira.codehaus.org/browse/MSHADE-145
Project: Maven 2.x Shade Plugin
Issue Type: Bug
Affects Versions: 2.0
Environment: Windows XP, Java 6 Update 24, Maven 3.0.4
Reporter: Anthony Whitford
Attachments: shade-site-bug.zip
My release failed because the project uses the {{maven-shade-plugin}} and it
generated a {{dependency-reduced-pom.xml}} in the {{basedir}}, so the release
plugin complains that there are local, uncommitted modifications.
To get my release working, I overrode the {{dependencyReducedPomLocation}}
configuration parameter to place it in {{project.build.directory}}:
{code:xml}
configuration
dependencyReducedPomLocation${project.build.directory}/dependency-reduced-pom.xml/dependencyReducedPomLocation
...
/configuration
{code}
My release worked, but then I noticed that this had a nasty side effect: my
site was not generated properly!
The project has {{src\site}} with a {{site.xml}} and APT pages. Those were no
longer generated... I have no idea how one thing is connected to the other,
but I did prove it by creating a sample application that illustrates the
problem.
Note that the problem seems to a combination of at least 2 things:
* {{dependencyReducedPomLocation}}
* {{relocations}}
In other words, if you comment out the {{dependencyReducedPomLocation}} or the
{{relocations}}, you can see the site being generated correctly. But if you
have these, then the site will NOT generate properly.
To be clear, the site generation is incorrect if you don't see the menu layout
like:
* About
** Introduction
** Usage
* Project Documentation
* Project Information
A broken site, you will notice that the About menu and Usage page do not exist,
for example.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MSHADE-124) Need better plan for getting dependency-reduced-pom.xml out of basedir
[ https://jira.codehaus.org/browse/MSHADE-124?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=323237#comment-323237 ] Anthony Whitford commented on MSHADE-124: - If this was fixed, why does the documentation still warn about this? See: http://maven.apache.org/plugins/maven-shade-plugin/shade-mojo.html#dependencyReducedPomLocation Need better plan for getting dependency-reduced-pom.xml out of basedir -- Key: MSHADE-124 URL: https://jira.codehaus.org/browse/MSHADE-124 Project: Maven 2.x Shade Plugin Issue Type: Bug Affects Versions: 1.7.1 Reporter: Benson Margulies Assignee: Benson Margulies Fix For: 2.0 MSHADE-123 reported that putting the d-r-p into some location other than 'basedir' causes 'basedir' to follow it around, which can break builds. This is hard to fix, given the core maven definition of basedir as 'the dir containing the pom' with no option to change it. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MSHADE-124) Need better plan for getting dependency-reduced-pom.xml out of basedir
[
https://jira.codehaus.org/browse/MSHADE-124?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=323238#comment-323238
]
Anthony Whitford commented on MSHADE-124:
-
And shouldn't the default location be under {{project.build.directory}} instead
of {{basedir}}? Then {{mvn clean}} would be more effective, and the _Maven
Release_ plugin wouldn't give an error saying, _Cannot prepare the release
because you have local modifications._
Need better plan for getting dependency-reduced-pom.xml out of basedir
--
Key: MSHADE-124
URL: https://jira.codehaus.org/browse/MSHADE-124
Project: Maven 2.x Shade Plugin
Issue Type: Bug
Affects Versions: 1.7.1
Reporter: Benson Margulies
Assignee: Benson Margulies
Fix For: 2.0
MSHADE-123 reported that putting the d-r-p into some location other
than 'basedir' causes 'basedir' to follow it around, which can break builds.
This is hard to fix, given the core maven definition of basedir as 'the dir
containing the pom' with no option to change it.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MPLUGIN-237) JavaDoc WARNING on generated HelpMojo class.
[
https://jira.codehaus.org/browse/MPLUGIN-237?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=318600#comment-318600
]
Anthony Whitford commented on MPLUGIN-237:
--
Yes, this bugs me too. I'm OK with dropping {{@author}} and {{@version}}
altogether from the HelpMojo's javadoc. I don't really see how {{@author}}
applies to something generated. And who cares about {{@version}} for a _help
mojo_?
JavaDoc WARNING on generated HelpMojo class.
Key: MPLUGIN-237
URL: https://jira.codehaus.org/browse/MPLUGIN-237
Project: Maven 2.x Plugin Tools
Issue Type: Improvement
Components: Plugin Plugin
Affects Versions: 3.2
Reporter: Karl Heinz Marbaise
Priority: Minor
During the site generation of a maven-plugin i got the following warning in
the builds:
{code}
2 warnings
[WARNING] Javadoc Warnings
[WARNING] /opt/.../plugin/.../HelpMojo.java:30: warning - @author tag has no
arguments.
[WARNING] /opt/.../plugin/.../HelpMojo.java:30: warning - @version tag has no
arguments.
[INFO] Generating Test JavaDocs report--- maven-javadoc-plugin:2.9
{code}
The question is: Can this be automatically be generated by the
maven-plugin-plugin from the original Mojo Class to avoid this WARNING?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MPLUGIN-237) JavaDoc WARNING on generated HelpMojo class.
[
https://jira.codehaus.org/browse/MPLUGIN-237?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=318602#comment-318602
]
Anthony Whitford commented on MPLUGIN-237:
--
Here is an example link suggesting that the {{@author}} tag should be avoided
because it is usually inaccurate (see your revision history instead):
* http://www.databasesandlife.com/dont-use-the-author-javadoc-tag/
JavaDoc WARNING on generated HelpMojo class.
Key: MPLUGIN-237
URL: https://jira.codehaus.org/browse/MPLUGIN-237
Project: Maven 2.x Plugin Tools
Issue Type: Improvement
Components: Plugin Plugin
Affects Versions: 3.2
Reporter: Karl Heinz Marbaise
Priority: Minor
During the site generation of a maven-plugin i got the following warning in
the builds:
{code}
2 warnings
[WARNING] Javadoc Warnings
[WARNING] /opt/.../plugin/.../HelpMojo.java:30: warning - @author tag has no
arguments.
[WARNING] /opt/.../plugin/.../HelpMojo.java:30: warning - @version tag has no
arguments.
[INFO] Generating Test JavaDocs report--- maven-javadoc-plugin:2.9
{code}
The question is: Can this be automatically be generated by the
maven-plugin-plugin from the original Mojo Class to avoid this WARNING?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-5369) Inconsistent interaction between activeProfiles and activeByDefault
[
https://jira.codehaus.org/browse/MNG-5369?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=317593#comment-317593
]
Anthony Whitford commented on MNG-5369:
---
I think I just stumbled on this bug too... I have a profile defined in the
{{settings.xml}} with an {{activeByDefault}} set to {{true}}, then the profile
also has some definition in my corporate parent pom. Despite the
{{activeByDefault}}, the profile was not being activated. I had to add an
explicit {{active-profiles}} section to make it work. But I do think this is a
bug because the documentation suggests that {{activeByDefault}} should work
fine, {{mvn help:active-profiles}} also reported the profile as active, and
this was working fine with Maven 2.2.1.
Inconsistent interaction between activeProfiles and activeByDefault
---
Key: MNG-5369
URL: https://jira.codehaus.org/browse/MNG-5369
Project: Maven 2 3
Issue Type: Bug
Components: Profiles, Settings
Affects Versions: 3.0.4
Environment: Apache Maven 3.0.4 (r1232337; 2012-01-17 00:44:56-0800)
Maven home: /home/rchen/dev/tools/apache-maven-3.0.4
Java version: 1.6.0_26, vendor: Sun Microsystems Inc.
Java home: /home/rchen/dev/tools/jdk1.6.0_26/jre
Default locale: en_CA, platform encoding: UTF-8
OS name: linux, version: 2.6.36-020636-generic, arch: amd64, family:
unix
Reporter: Ronald Chen
Attachments: maven-active-by-default-parent.tar.gz,
maven-profiles-bug.png
I have two profiles. One is activated by activeProfiles in settings.xml and
the other is activeByDefault = true
They are both expected to be active as I am not using -P in my commands.
The bug is there are some cases in which the activeByDefault profile is not
active.
It seems like whenever both profiles are located in the same pom, the
activeByDefault profile is no longer active. But moving the activeProfiles
profile up into a parent pom or moving the activeByDefault profile down to a
module both seems to work.
Its a rather complicated to describe, so I have attached 6 sample projects
which illustrates various scenarios. I've summarized the results in the
attached image.
You can also run all the projects with the command:
ls -1 | xargs --verbose -I CASE mvn -f CASE/sub-parent/project/pom.xml
validate -s CASE/settings.xml |grep -vP '^\[INFO\]'
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MSCMPUB-4) Need a working example for GitHub/gh-pages, preferably naturally linked to natural site lifecycle, and multi-module
Anthony Whitford created MSCMPUB-4:
--
Summary: Need a working example for GitHub/gh-pages, preferably
naturally linked to natural site lifecycle, and multi-module
Key: MSCMPUB-4
URL: https://jira.codehaus.org/browse/MSCMPUB-4
Project: maven-scm-publish-plugin
Issue Type: Story
Environment: Mac OSX 10.8.2, Java 1.6 Update 35, Maven 3.0.4, Maven
Site Plugin 3.2, Maven SCM Plugin 1.8, Git
Reporter: Anthony Whitford
Priority: Critical
I am trying to update my
[lombok-maven-plugin|http://awhitford.github.com/lombok.maven/lombok-maven-plugin/index.html]
project to use this plugin to publish the project to _Github Pages_.
When I try this command:
{noformat}
mvn clean site site:stage-deploy scm-publish:publish-scm
{noformat}
which is outlined
[here|http://maven.apache.org/plugins/maven-scm-publish-plugin/examples/multi-module-configuration.html],
I get this error:
{noformat}
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-scm-publish-plugin:1.0-beta-1:publish-scm
(default-cli) on project lombok-maven: Unable to checkout from SCM
[ERROR] Provider message:
[ERROR] The git-log command failed.
[ERROR] Command output:
[ERROR] fatal: ambiguous argument 'master': unknown revision or path not in the
working tree.
[ERROR] Use '--' to separate paths from revisions
{noformat}
(?) Is there a multi-module project in GitHub that uses this plugin that I can
use as an example?
This is what I did so far...
{code:xml}
properties
siteMainDirectory${user.home}/Sites/lombok.maven/siteMainDirectory
scmPubCheckoutDirectory${user.home}/site-content-scm/lombok.maven/scmPubCheckoutDirectory
/properties
...
pluginManagement
plugins
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-site-plugin/artifactId
version3.2/version
configuration
skipDeploytrue/skipDeploy
stagingSiteURLfile://${siteMainDirectory}/stagingSiteURL
/configuration
/plugin
...
/plugins
/pluginManagement
...
plugins
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-site-plugin/artifactId
executions
execution
idstage-for-scm-publish/id
phasepost-site/phase
goals
goalstage/goal
/goals
/execution
/executions
/plugin
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-scm-publish-plugin/artifactId
version1.0-beta-1/version
configuration
checkoutDirectory${scmPubCheckoutDirectory}/checkoutDirectory
content\${siteMainDirectory}/content
tryUpdatetrue/tryUpdate
scmBranchgh-pages/scmBranch
pubScmUrlscm:git:g...@github.com:awhitford/lombok.maven.git/pubScmUrl
/configuration
executions
execution
idscm-publish/id
phasesite-deploy/phase
goals
goalpublish-scm/goal
/goals
/execution
/executions
/plugin
/plugins
{code}
Finally, I'm really interested in wiring this up so that when I do a normal
{{site-deploy}} or an implicit one through the release process, it gets
published to {{gh-pages}} -- just like I had working with
[wagon-gitsite|https://github.com/awhitford/wagon-gitsite].
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MSCMPUB-5) Need a working example for GitHub/gh-pages, preferably naturally linked to natural site lifecycle, and multi-module
Anthony Whitford created MSCMPUB-5:
--
Summary: Need a working example for GitHub/gh-pages, preferably
naturally linked to natural site lifecycle, and multi-module
Key: MSCMPUB-5
URL: https://jira.codehaus.org/browse/MSCMPUB-5
Project: maven-scm-publish-plugin
Issue Type: Story
Environment: Mac OSX 10.8.2, Java 1.6 Update 35, Maven 3.0.4, Maven
Site Plugin 3.2, Maven SCM Plugin 1.8, Git
Reporter: Anthony Whitford
Priority: Critical
I am trying to update my
[lombok-maven-plugin|http://awhitford.github.com/lombok.maven/lombok-maven-plugin/index.html]
project to use this plugin to publish the project to _Github Pages_.
When I try this command:
{noformat}
mvn clean site site:stage-deploy scm-publish:publish-scm
{noformat}
which is outlined
[here|http://maven.apache.org/plugins/maven-scm-publish-plugin/examples/multi-module-configuration.html],
I get this error:
{noformat}
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-scm-publish-plugin:1.0-beta-1:publish-scm
(default-cli) on project lombok-maven: Unable to checkout from SCM
[ERROR] Provider message:
[ERROR] The git-log command failed.
[ERROR] Command output:
[ERROR] fatal: ambiguous argument 'master': unknown revision or path not in the
working tree.
[ERROR] Use '--' to separate paths from revisions
{noformat}
(?) Is there a multi-module project in GitHub that uses this plugin that I can
use as an example?
This is what I did so far...
{code:xml}
properties
siteMainDirectory${user.home}/Sites/lombok.maven/siteMainDirectory
scmPubCheckoutDirectory${user.home}/site-content-scm/lombok.maven/scmPubCheckoutDirectory
/properties
...
pluginManagement
plugins
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-site-plugin/artifactId
version3.2/version
configuration
skipDeploytrue/skipDeploy
stagingSiteURLfile://${siteMainDirectory}/stagingSiteURL
/configuration
/plugin
...
/plugins
/pluginManagement
...
plugins
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-site-plugin/artifactId
executions
execution
idstage-for-scm-publish/id
phasepost-site/phase
goals
goalstage/goal
/goals
/execution
/executions
/plugin
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-scm-publish-plugin/artifactId
version1.0-beta-1/version
configuration
checkoutDirectory${scmPubCheckoutDirectory}/checkoutDirectory
content\${siteMainDirectory}/content
tryUpdatetrue/tryUpdate
scmBranchgh-pages/scmBranch
pubScmUrlscm:git:g...@github.com:awhitford/lombok.maven.git/pubScmUrl
/configuration
executions
execution
idscm-publish/id
phasesite-deploy/phase
goals
goalpublish-scm/goal
/goals
/execution
/executions
/plugin
/plugins
{code}
Finally, I'm really interested in wiring this up so that when I do a normal
{{site-deploy}} or an implicit one through the release process, it gets
published to {{gh-pages}} -- just like I had working with
[wagon-gitsite|https://github.com/awhitford/wagon-gitsite].
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MSCMPUB-5) Need a working example for GitHub/gh-pages, preferably naturally linked to natural site lifecycle, and multi-module
[
https://jira.codehaus.org/browse/MSCMPUB-5?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anthony Whitford closed MSCMPUB-5.
--
Resolution: Duplicate
See MSCMPUB-4.
Need a working example for GitHub/gh-pages, preferably naturally linked to
natural site lifecycle, and multi-module
---
Key: MSCMPUB-5
URL: https://jira.codehaus.org/browse/MSCMPUB-5
Project: maven-scm-publish-plugin
Issue Type: Story
Environment: Mac OSX 10.8.2, Java 1.6 Update 35, Maven 3.0.4, Maven
Site Plugin 3.2, Maven SCM Plugin 1.8, Git
Reporter: Anthony Whitford
Priority: Critical
I am trying to update my
[lombok-maven-plugin|http://awhitford.github.com/lombok.maven/lombok-maven-plugin/index.html]
project to use this plugin to publish the project to _Github Pages_.
When I try this command:
{noformat}
mvn clean site site:stage-deploy scm-publish:publish-scm
{noformat}
which is outlined
[here|http://maven.apache.org/plugins/maven-scm-publish-plugin/examples/multi-module-configuration.html],
I get this error:
{noformat}
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-scm-publish-plugin:1.0-beta-1:publish-scm
(default-cli) on project lombok-maven: Unable to checkout from SCM
[ERROR] Provider message:
[ERROR] The git-log command failed.
[ERROR] Command output:
[ERROR] fatal: ambiguous argument 'master': unknown revision or path not in
the working tree.
[ERROR] Use '--' to separate paths from revisions
{noformat}
(?) Is there a multi-module project in GitHub that uses this plugin that I
can use as an example?
This is what I did so far...
{code:xml}
properties
siteMainDirectory${user.home}/Sites/lombok.maven/siteMainDirectory
scmPubCheckoutDirectory${user.home}/site-content-scm/lombok.maven/scmPubCheckoutDirectory
/properties
...
pluginManagement
plugins
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-site-plugin/artifactId
version3.2/version
configuration
skipDeploytrue/skipDeploy
stagingSiteURLfile://${siteMainDirectory}/stagingSiteURL
/configuration
/plugin
...
/plugins
/pluginManagement
...
plugins
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-site-plugin/artifactId
executions
execution
idstage-for-scm-publish/id
phasepost-site/phase
goals
goalstage/goal
/goals
/execution
/executions
/plugin
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-scm-publish-plugin/artifactId
version1.0-beta-1/version
configuration
checkoutDirectory${scmPubCheckoutDirectory}/checkoutDirectory
content\${siteMainDirectory}/content
tryUpdatetrue/tryUpdate
scmBranchgh-pages/scmBranch
pubScmUrlscm:git:g...@github.com:awhitford/lombok.maven.git/pubScmUrl
/configuration
executions
execution
idscm-publish/id
phasesite-deploy/phase
goals
goalpublish-scm/goal
/goals
/execution
/executions
/plugin
/plugins
{code}
Finally, I'm really interested in wiring this up so that when I do a normal
{{site-deploy}} or an implicit one through the release process, it gets
published to {{gh-pages}} -- just like I had working with
[wagon-gitsite|https://github.com/awhitford/wagon-gitsite].
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MSCMPUB-4) Need a working example for GitHub/gh-pages, preferably naturally linked to natural site lifecycle, and multi-module
[
https://jira.codehaus.org/browse/MSCMPUB-4?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=311910#comment-311910
]
Anthony Whitford commented on MSCMPUB-4:
I took a closer look at
[tomcat-foo-artifact|https://github.com/olamy/tomcat-foo-artifact/blob/master/pom.xml],
and made a couple of adjustments to be consistent... But now I am getting
this problem:
{noformat}
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-scm-publish-plugin:1.0-beta-1:publish-scm
(default-cli) on project lombok-maven: Failed to checkin files: The git-commit
command failed. warning: CRLF will be replaced by LF in checkstyle.rss.
[ERROR] The file will have its original line endings in your working directory.
[ERROR] warning: CRLF will be replaced by LF in
lombok-maven-plugin/checkstyle.rss.
[ERROR] The file will have its original line endings in your working directory.
[ERROR] warning: CRLF will be replaced by LF in
test-maven-lombok/checkstyle.rss.
[ERROR] The file will have its original line endings in your working directory.
[ERROR] - [Help 1]
{noformat}
Note that I am no longer using the {{tryUpdate}} feature (which I would think
would be more efficient).
(?) Are these _real_ errors? Or are the warnings be incorrectly translated as
an error?
Need a working example for GitHub/gh-pages, preferably naturally linked to
natural site lifecycle, and multi-module
---
Key: MSCMPUB-4
URL: https://jira.codehaus.org/browse/MSCMPUB-4
Project: maven-scm-publish-plugin
Issue Type: Story
Environment: Mac OSX 10.8.2, Java 1.6 Update 35, Maven 3.0.4, Maven
Site Plugin 3.2, Maven SCM Plugin 1.8, Git
Reporter: Anthony Whitford
Priority: Critical
I am trying to update my
[lombok-maven-plugin|http://awhitford.github.com/lombok.maven/lombok-maven-plugin/index.html]
project to use this plugin to publish the project to _Github Pages_.
When I try this command:
{noformat}
mvn clean site site:stage-deploy scm-publish:publish-scm
{noformat}
which is outlined
[here|http://maven.apache.org/plugins/maven-scm-publish-plugin/examples/multi-module-configuration.html],
I get this error:
{noformat}
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-scm-publish-plugin:1.0-beta-1:publish-scm
(default-cli) on project lombok-maven: Unable to checkout from SCM
[ERROR] Provider message:
[ERROR] The git-log command failed.
[ERROR] Command output:
[ERROR] fatal: ambiguous argument 'master': unknown revision or path not in
the working tree.
[ERROR] Use '--' to separate paths from revisions
{noformat}
(?) Is there a multi-module project in GitHub that uses this plugin that I
can use as an example?
This is what I did so far...
{code:xml}
properties
siteMainDirectory${user.home}/Sites/lombok.maven/siteMainDirectory
scmPubCheckoutDirectory${user.home}/site-content-scm/lombok.maven/scmPubCheckoutDirectory
/properties
...
pluginManagement
plugins
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-site-plugin/artifactId
version3.2/version
configuration
skipDeploytrue/skipDeploy
stagingSiteURLfile://${siteMainDirectory}/stagingSiteURL
/configuration
/plugin
...
/plugins
/pluginManagement
...
plugins
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-site-plugin/artifactId
executions
execution
idstage-for-scm-publish/id
phasepost-site/phase
goals
goalstage/goal
/goals
/execution
/executions
/plugin
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-scm-publish-plugin/artifactId
version1.0-beta-1/version
configuration
checkoutDirectory${scmPubCheckoutDirectory}/checkoutDirectory
content\${siteMainDirectory}/content
tryUpdatetrue/tryUpdate
scmBranchgh-pages/scmBranch
pubScmUrlscm:git:g...@github.com:awhitford/lombok.maven.git/pubScmUrl
/configuration
executions
execution
idscm-publish/id
phasesite-deploy/phase
goals
goalpublish-scm/goal
/goals
/execution
/executions
/plugin
/plugins
{code}
Finally, I'm really interested in wiring this up so that when I do a normal
{{site-deploy}} or an implicit one through the release process, it gets
published to {{gh-pages}} -- just like I had working with
[wagon-gitsite|https://github.com/awhitford/wagon-gitsite].
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more
[jira] (MSCMPUB-4) Need a working example for GitHub/gh-pages, preferably naturally linked to natural site lifecycle, and multi-module
[
https://jira.codehaus.org/browse/MSCMPUB-4?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=311910#comment-311910
]
Anthony Whitford edited comment on MSCMPUB-4 at 10/21/12 12:57 AM:
---
I took a closer look at
[tomcat-foo-artifact|https://github.com/olamy/tomcat-foo-artifact/blob/master/pom.xml],
and made a couple of adjustments to be consistent... But now I am getting
this problem:
{noformat}
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-scm-publish-plugin:1.0-beta-1:publish-scm
(default-cli) on project lombok-maven: Failed to checkin files: The git-commit
command failed. warning: CRLF will be replaced by LF in checkstyle.rss.
[ERROR] The file will have its original line endings in your working directory.
[ERROR] warning: CRLF will be replaced by LF in
lombok-maven-plugin/checkstyle.rss.
[ERROR] The file will have its original line endings in your working directory.
[ERROR] warning: CRLF will be replaced by LF in
test-maven-lombok/checkstyle.rss.
[ERROR] The file will have its original line endings in your working directory.
[ERROR] - [Help 1]
{noformat}
Note that I am no longer using the {{tryUpdate}} feature (which I would think
would be more efficient).
(?) Are these _real_ errors? Or are the warnings being incorrectly translated
as an error?
was (Author: awhitford):
I took a closer look at
[tomcat-foo-artifact|https://github.com/olamy/tomcat-foo-artifact/blob/master/pom.xml],
and made a couple of adjustments to be consistent... But now I am getting
this problem:
{noformat}
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-scm-publish-plugin:1.0-beta-1:publish-scm
(default-cli) on project lombok-maven: Failed to checkin files: The git-commit
command failed. warning: CRLF will be replaced by LF in checkstyle.rss.
[ERROR] The file will have its original line endings in your working directory.
[ERROR] warning: CRLF will be replaced by LF in
lombok-maven-plugin/checkstyle.rss.
[ERROR] The file will have its original line endings in your working directory.
[ERROR] warning: CRLF will be replaced by LF in
test-maven-lombok/checkstyle.rss.
[ERROR] The file will have its original line endings in your working directory.
[ERROR] - [Help 1]
{noformat}
Note that I am no longer using the {{tryUpdate}} feature (which I would think
would be more efficient).
(?) Are these _real_ errors? Or are the warnings be incorrectly translated as
an error?
Need a working example for GitHub/gh-pages, preferably naturally linked to
natural site lifecycle, and multi-module
---
Key: MSCMPUB-4
URL: https://jira.codehaus.org/browse/MSCMPUB-4
Project: maven-scm-publish-plugin
Issue Type: Story
Environment: Mac OSX 10.8.2, Java 1.6 Update 35, Maven 3.0.4, Maven
Site Plugin 3.2, Maven SCM Plugin 1.8, Git
Reporter: Anthony Whitford
Priority: Critical
I am trying to update my
[lombok-maven-plugin|http://awhitford.github.com/lombok.maven/lombok-maven-plugin/index.html]
project to use this plugin to publish the project to _Github Pages_.
When I try this command:
{noformat}
mvn clean site site:stage-deploy scm-publish:publish-scm
{noformat}
which is outlined
[here|http://maven.apache.org/plugins/maven-scm-publish-plugin/examples/multi-module-configuration.html],
I get this error:
{noformat}
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-scm-publish-plugin:1.0-beta-1:publish-scm
(default-cli) on project lombok-maven: Unable to checkout from SCM
[ERROR] Provider message:
[ERROR] The git-log command failed.
[ERROR] Command output:
[ERROR] fatal: ambiguous argument 'master': unknown revision or path not in
the working tree.
[ERROR] Use '--' to separate paths from revisions
{noformat}
(?) Is there a multi-module project in GitHub that uses this plugin that I
can use as an example?
This is what I did so far...
{code:xml}
properties
siteMainDirectory${user.home}/Sites/lombok.maven/siteMainDirectory
scmPubCheckoutDirectory${user.home}/site-content-scm/lombok.maven/scmPubCheckoutDirectory
/properties
...
pluginManagement
plugins
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-site-plugin/artifactId
version3.2/version
configuration
skipDeploytrue/skipDeploy
stagingSiteURLfile://${siteMainDirectory}/stagingSiteURL
/configuration
/plugin
...
/plugins
/pluginManagement
...
plugins
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-site-plugin/artifactId
executions
execution
idstage-for-scm-publish/id
phasepost-site/phase
goals
[jira] (MPLUGIN-226) Plugin documentation suggests an incorrect goal for generating descriptor
[
https://jira.codehaus.org/browse/MPLUGIN-226?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=309746#comment-309746
]
Anthony Whitford commented on MPLUGIN-226:
--
I think I made a mistake... I thought that I was looking at something like
this:
{code:xml}
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-plugin-plugin/artifactId
version3.1/version
executions
execution
idgenerate-mojo-descriptors/id
goals
goaldescriptor/goal
/goals
/execution
/executions
/plugin
{code}
I don't understand why one needs to specify the goalPrefix (as long as you are
following the maven plugin naming convention).
Plugin documentation suggests an incorrect goal for generating descriptor
-
Key: MPLUGIN-226
URL: https://jira.codehaus.org/browse/MPLUGIN-226
Project: Maven 2.x Plugin Tools
Issue Type: Bug
Affects Versions: 3.1
Reporter: Anthony Whitford
Priority: Minor
On this
[page|http://maven.apache.org/plugin-tools/maven-plugin-plugin/examples/generate-descriptor.html],
the goal says {{plugin}} instead of {{descriptor}}.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MPLUGIN-226) Plugin documentation suggests an incorrect goal for generating descriptor
[
https://jira.codehaus.org/browse/MPLUGIN-226?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anthony Whitford closed MPLUGIN-226.
Resolution: Not A Bug
My bad...
Plugin documentation suggests an incorrect goal for generating descriptor
-
Key: MPLUGIN-226
URL: https://jira.codehaus.org/browse/MPLUGIN-226
Project: Maven 2.x Plugin Tools
Issue Type: Bug
Affects Versions: 3.1
Reporter: Anthony Whitford
Priority: Minor
On this
[page|http://maven.apache.org/plugin-tools/maven-plugin-plugin/examples/generate-descriptor.html],
the goal says {{plugin}} instead of {{descriptor}}.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MPLUGIN-223) HelpMojo is not extracted when using java-annotations extractor
[
https://jira.codehaus.org/browse/MPLUGIN-223?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=308642#comment-308642
]
Anthony Whitford commented on MPLUGIN-223:
--
I too would like the option to go with the Java5 Annotations. Presently, I see
3 issues:
# The @Property annotations are commented out.
# The @Mojo annotation is missing.
# The legacy Javadoc style annotations should be removed (Java 5 or legacy, not
both).
HelpMojo is not extracted when using java-annotations extractor
---
Key: MPLUGIN-223
URL: https://jira.codehaus.org/browse/MPLUGIN-223
Project: Maven 2.x Plugin Tools
Issue Type: Bug
Affects Versions: 3.1
Reporter: Martin Ellis
The generated HelpMojo uses javadoc tags rather than Java annotations.
If the plugin is only configured to use only the java-annotations extractor,
then it does not recognise the HelpMojo as a valid mojo:
{noformat}
extractors
extractorjava-annotations/extractor
/extractors
{noformat}
In this case, the plugin will silently fail to include the 'help' goal in the
plugin descriptor.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MDOCCK-26) When using Java 5 Annotations, docck incorrectly warns of no mojo descriptors found
Anthony Whitford created MDOCCK-26:
--
Summary: When using Java 5 Annotations, docck incorrectly warns of
no mojo descriptors found
Key: MDOCCK-26
URL: https://jira.codehaus.org/browse/MDOCCK-26
Project: Maven 2.x Documentation Checker Plugin
Issue Type: Bug
Affects Versions: 1.0
Reporter: Anthony Whitford
I have a Maven Plugin that uses [Java 5
annotations|http://maven.apache.org/plugin-tools/maven-plugin-tools-annotations/].
The [descriptor is being
generated|http://maven.apache.org/ref/3.0.4/maven-plugin-api/plugin.html], yet
the docck plugin erroneously emits a warning:
{noformat}
[WARNING] ***
[WARNING] Deprecation Alert:
[WARNING] No mojo descriptors were found in this project which has a packaging
type of maven-plugin.
[WARNING] In future versions of the plugin tools, this will fail the build.
[WARNING] If this project is an archetype, change the packaging type from
maven-plugin to maven-archetype.
[WARNING]
{noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MPLUGIN-226) Plugin documentation suggests an incorrect goal for generating descriptor
Anthony Whitford created MPLUGIN-226:
Summary: Plugin documentation suggests an incorrect goal for
generating descriptor
Key: MPLUGIN-226
URL: https://jira.codehaus.org/browse/MPLUGIN-226
Project: Maven 2.x Plugin Tools
Issue Type: Bug
Affects Versions: 3.1
Reporter: Anthony Whitford
Priority: Minor
On this
[page|http://maven.apache.org/plugin-tools/maven-plugin-plugin/examples/generate-descriptor.html],
the goal says {{plugin}} instead of {{descriptor}}.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-5101) Declare artifact is a replacement to avoid excessive exclusions
[
https://jira.codehaus.org/browse/MNG-5101?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=283344#comment-283344
]
Anthony Whitford commented on MNG-5101:
---
Noting this workaround: http://www.slf4j.org/faq.html#excludingJCL
and: http://day-to-day-stuff.blogspot.com/2007/07/no-more-commons-logging.html
Declare artifact is a replacement to avoid excessive exclusions
---
Key: MNG-5101
URL: https://jira.codehaus.org/browse/MNG-5101
Project: Maven 2 3
Issue Type: Wish
Components: Dependencies
Affects Versions: 2.2.1
Reporter: Anthony Whitford
Priority: Minor
For those of us using something like [SLF4J|http://slf4j.org/] and including
a [legacy API bridge|http://slf4j.org/legacy.html] like {{jcl-over-slf4j}}
as a replacement to {{commons-logging}}, it would be nice to be able to have
the {{jcl-over-slf4j}} artifact declare in its POM that it is a logical
replacement to {{commons-logging}}, so that one can avoid the excessive
{{exclusions}} for the numerous artifacts that still reference the legacy
api:
{code}
exclusions
exclusion
groupIdcommons-logging/groupId
artifactIdcommons-logging/artifactId
/exclusion
/exclusions
{code}
One work-around that one can use is to declare {{commons-logging}} as
{{provided}} in a project's pom -- but then it appears in the dependency
tree, which is not really nice.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (WAGON-355) Expose PreferredAuthentications property of jsch in some way
[
https://jira.codehaus.org/browse/WAGON-355?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=283156#comment-283156
]
Anthony Whitford commented on WAGON-355:
We seem to think that Java 7 changed some behavior in JCE to cause this
problem. There is a workaround to this problem: add
{{-Djava.security.auth.login.config=ignoreMe.conf}} to {{MAVEN_OPTS}}. Note
that {{ignoreMe.conf}} is a non-existent file.
Expose PreferredAuthentications property of jsch in some way
Key: WAGON-355
URL: https://jira.codehaus.org/browse/WAGON-355
Project: Maven Wagon
Issue Type: Improvement
Components: wagon-ssh
Affects Versions: 2.0
Environment: Any. I happened to test with Maven 2.2.1 and jdk 1.7
Reporter: Lester Ward
Priority: Minor
Deploy using scp. Under jdk 1.7, support for gssapi-with-mic works
differently than it did under jdk 1.6, to the point where we do not want to
use it. Ultimately, the deploy plugin uses the jsch library to deploy using
scp. This library has an property called PreferredAuthentications which
controls which authentications get used, in which order. The code in
AbstractJschWagon hard-codes
gssapi-with-mic,publickey,password,keyboard-interactive into this property.
I'd like a way to somehow override that, preferably in my project's pom file.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MDEP-306) 2.2 unpack does not handle space in includes
[ https://jira.codehaus.org/browse/MDEP-306?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=279131#comment-279131 ] Anthony Whitford commented on MDEP-306: --- Just want to add that this remains a problem with version 2.3 too. 2.2 unpack does not handle space in includes Key: MDEP-306 URL: https://jira.codehaus.org/browse/MDEP-306 Project: Maven 2.x Dependency Plugin Issue Type: Bug Components: unpack Affects Versions: 2.2 Environment: Windows XP, Java 6 Reporter: Anthony Whitford Assignee: Brian Fox Priority: Critical Upgrading to 2.2 broke my build and I traced the root cause to the fact that I am calling unpack against a zip file and my includes specifies a filename pattern with a space in the directory name. This works fine if I roll back to version 2.1, but 2.2 doesn't do anything (presumably nothing is matching the includes spec). -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MDEP-306) 2.2 unpack does not handle space in includes
[
https://jira.codehaus.org/browse/MDEP-306?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=279134#comment-279134
]
Anthony Whitford commented on MDEP-306:
---
I think the problem is this code found in
[DependencyUtil.java|http://svn.apache.org/repos/asf/maven/plugins/trunk/maven-dependency-plugin/src/main/java/org/apache/maven/plugin/dependency/utils/DependencyUtil.java]:{code}
//
// clean up configuration string before it can be tokenized
//
public static String cleanToBeTokenizedString( String str )
{
String ret = ;
if ( !StringUtils.isEmpty( str ) )
{
ret = StringUtils.join( StringUtils.split( str ), , );
}
return ret;
}
{code} I believe the split needs a separator specified (comma) otherwise it
splits on whitespace:{code}
//
// clean up configuration string before it can be tokenized
//
public static String cleanToBeTokenizedString( String str )
{
String ret = ;
if ( !StringUtils.isEmpty( str ) )
{
ret = StringUtils.join( StringUtils.split( str, , ), , );
}
return ret;
}
{code}
See
[StringUtils.java|http://plexus.codehaus.org/plexus-utils/apidocs/org/codehaus/plexus/util/StringUtils.html#split(java.lang.String,
java.lang.String)] for more information.
2.2 unpack does not handle space in includes
Key: MDEP-306
URL: https://jira.codehaus.org/browse/MDEP-306
Project: Maven 2.x Dependency Plugin
Issue Type: Bug
Components: unpack
Affects Versions: 2.2
Environment: Windows XP, Java 6
Reporter: Anthony Whitford
Assignee: Brian Fox
Priority: Critical
Upgrading to 2.2 broke my build and I traced the root cause to the fact that
I am calling unpack against a zip file and my includes specifies a filename
pattern with a space in the directory name. This works fine if I roll back
to version 2.1, but 2.2 doesn't do anything (presumably nothing is matching
the includes spec).
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MCHECKSTYLE-70) Support for multiple source folders
[
https://jira.codehaus.org/browse/MCHECKSTYLE-70?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=277250#comment-277250
]
Anthony Whitford commented on MCHECKSTYLE-70:
-
No, I don't see this solved... I think the Checkstyle plugin should ask the
MavenProject for its compileSourceRoots. See:
http://maven.apache.org/ref/3.0.3/maven-core/apidocs/org/apache/maven/project/MavenProject.html#getCompileSourceRoots()
Support for multiple source folders
---
Key: MCHECKSTYLE-70
URL: https://jira.codehaus.org/browse/MCHECKSTYLE-70
Project: Maven 2.x Checkstyle Plugin
Issue Type: Improvement
Affects Versions: 2.1
Reporter: Jan Palmquist
Priority: Minor
It would be great if this plugin would support multiple source folders added
by http://mojo.codehaus.org/build-helper-maven-plugin/ (or similar), and by
default inspect sources from these folders instead of just
${project.build.sourceDirectory}. Correspondingly with respect to test
sources if those are configured to be included.
There are other plugins available solving this problem (somehow), eg:
* http://mojo.codehaus.org/jdepend-maven-plugin/
* http://mojo.codehaus.org/findbugs-maven-plugin/
Maybe they can give some inspiration for how to make this possible?
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (DOXIA-440) Unable to place XML in source in FML
Unable to place XML in source in FML
--
Key: DOXIA-440
URL: https://jira.codehaus.org/browse/DOXIA-440
Project: Maven Doxia
Issue Type: Bug
Components: Module - Fml
Environment: maven-site-plugin 3.0
Mac OS X Lion
Java 6 Update 26, Maven 3.0.3
Reporter: Anthony Whitford
I have a {{faq.fml.vm}} file that has XML embedded in a source tag like this:
{code:xml}
?xml version=1.0 encoding=UTF-8?
faqs id=FAQ title=Frequently Asked Questions
part id=General
titleGeneral/title
faq id=needed
questionIs the question important?/question
answer
pNo. I am merely trying to illustrate that I can't render XML
correctly as part of the emsource/em tag./p
source
dependencies
dependency
groupIdorg.projectlombok/groupId
artifactIdlombok/artifactId
version${LombokVersion}/version
scopeprovided/scope
/dependency
/dependencies
/source
/answer
/faq
/part
/faqs
{code}
Note that this used to display correctly with Maven2/Site2.x... (I haven't
isolated precisely what was changed to break this.)
If there is a bug in my FML, then I suggest tweaking the documentation to
include this case as I could not find documentation explaining how to do this.
Thanks!
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (DOXIA-440) Unable to place XML in source in FML
[
https://jira.codehaus.org/browse/DOXIA-440?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anthony Whitford closed DOXIA-440.
--
Resolution: Not A Bug
This problem is resolved by wrapping the {{source}} contents in CDATA.
Unable to place XML in source in FML
--
Key: DOXIA-440
URL: https://jira.codehaus.org/browse/DOXIA-440
Project: Maven Doxia
Issue Type: Bug
Components: Module - Fml
Environment: maven-site-plugin 3.0
Mac OS X Lion
Java 6 Update 26, Maven 3.0.3
Reporter: Anthony Whitford
I have a {{faq.fml.vm}} file that has XML embedded in a source tag like
this:
{code:xml}
?xml version=1.0 encoding=UTF-8?
faqs id=FAQ title=Frequently Asked Questions
part id=General
titleGeneral/title
faq id=needed
questionIs the question important?/question
answer
pNo. I am merely trying to illustrate that I can't render XML
correctly as part of the emsource/em tag./p
source
dependencies
dependency
groupIdorg.projectlombok/groupId
artifactIdlombok/artifactId
version${LombokVersion}/version
scopeprovided/scope
/dependency
/dependencies
/source
/answer
/faq
/part
/faqs
{code}
Note that this used to display correctly with Maven2/Site2.x... (I haven't
isolated precisely what was changed to break this.)
If there is a bug in my FML, then I suggest tweaking the documentation to
include this case as I could not find documentation explaining how to do this.
Thanks!
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MSITE-443) add a reportingManagement section
[
https://jira.codehaus.org/browse/MSITE-443?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=274696#comment-274696
]
Anthony Whitford commented on MSITE-443:
I like Sven's idea. Ultimately, I am looking for a way to say, Use javadoc
2.8 _once_ -- this should affect both the build and reporting sections,
otherwise my pom violates the DRY principle.
add a reportingManagement section
-
Key: MSITE-443
URL: https://jira.codehaus.org/browse/MSITE-443
Project: Maven 2.x and 3.x Site Plugin
Issue Type: Bug
Environment: maven-site-plugin 2.0-beta-3-SNAPSHOT
Reporter: Indrajit Raychaudhuri
Consider the following POM:
{code:xml}
!-- ... ... --
!-- ... ... --
build
pluginManagement
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-javadoc-plugin/artifactId
configuration
authorfalse/author
/configuration
/plugin
/pluginManagement
/build
!-- ... ... --
!-- ... ... --
reporting
plugins
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-javadoc-plugin/artifactId
/plugin
/plugins
/reporting
!-- ... ... --
{code}
{{mvn site:site}} doesn't honor the javadoc configuration specified in the
{{pluginManagement/}} section.
However, {{mvn javadoc:javadoc}} honors them.
This is true not just for javadoc but other plugins like checkstyle as well.
I guess, the {{reporting/}} section doesn't use the {{pluginManagement/}}
section at all.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MNG-5101) Declare artifact is a replacement to avoid excessive exclusions
Declare artifact is a replacement to avoid excessive exclusions
---
Key: MNG-5101
URL: http://jira.codehaus.org/browse/MNG-5101
Project: Maven 2 3
Issue Type: Wish
Components: Dependencies
Affects Versions: 2.2.1
Reporter: Anthony Whitford
Priority: Minor
For those of us using something like [SLF4J|http://slf4j.org/] and including a
[legacy API bridge|http://slf4j.org/legacy.html] like {{jcl-over-slf4j}} as a
replacement to {{commons-logging}}, it would be nice to be able to have the
{{jcl-over-slf4j}} artifact declare in its POM that it is a logical replacement
to {{commons-logging}}, so that one can avoid the excessive {{exclusions}}
for the numerous artifacts that still reference the legacy api:
{code}
exclusions
exclusion
groupIdcommons-logging/groupId
artifactIdcommons-logging/artifactId
/exclusion
/exclusions
{code}
One work-around that one can use is to declare {{commons-logging}} as
{{provided}} in a project's pom -- but then it appears in the dependency tree,
which is not really nice.
--
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-5102) Mixin POM fragments
Mixin POM fragments --- Key: MNG-5102 URL: http://jira.codehaus.org/browse/MNG-5102 Project: Maven 2 3 Issue Type: Wish Components: POM Affects Versions: 2.2.1 Reporter: Anthony Whitford I am looking for a way to _mixin_ POM fragments into POMs. Note that this idea is beyond parent pom inheritance because all projects inherit from a corporate parent pom. The problem that I am running into is that the corporate parent pom is turning into an _everything but the kitchen sink_ POM and I'd like to dissect it into POM fragments relevant for individual modules. For example, I would like to have mixins for: * Java projects (that include static code analysis plugins, javadoc, etc.) * JPA projects (that include DDL generation) * Flex projects (that include flexmojos, asdoc, etc.) * Scala projects (that include the maven-scala-compiler plugin, scaladoc, etc.) * JavaScript projects (that include build plugins like maven-yuicompressor-plugin with jslint and compress goals) Hopefully, you get the idea. Without the ability to factor pom logic, we are left with two symptoms: # copy/paste duplication # complex _it does it all_ parent poms (which slow down builds because more plugins are loaded even though they might not do anything material) Note that a project may include multiple mixins as I could have a project that contains Java code, Scala code, and JavaScript. Another idea is that the mixins could be parameterized, so that the ultimate pom can be customized based on the parameters (like tokens). I recall reading about Mixins coming in Maven 3.1, but could not find any such issue to watch, so am creating one. -- 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: (MDEP-306) 2.2 unpack does not handle space in includes
2.2 unpack does not handle space in includes Key: MDEP-306 URL: http://jira.codehaus.org/browse/MDEP-306 Project: Maven 2.x Dependency Plugin Issue Type: Bug Components: unpack Affects Versions: 2.2 Environment: Windows XP, Java 6 Reporter: Anthony Whitford Assignee: Brian Fox Priority: Critical Upgrading to 2.2 broke my build and I traced the root cause to the fact that I am calling unpack against a zip file and my includes specifies a filename pattern with a space in the directory name. This works fine if I roll back to version 2.1, but 2.2 doesn't do anything (presumably nothing is matching the includes spec). -- 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-128) SCM properties being replaced during release:perform
[
http://jira.codehaus.org/browse/MRELEASE-128?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=250913#action_250913
]
Anthony Whitford commented on MRELEASE-128:
---
*Has this issue really been open for more than _4 years_?*
This is a critical one for me; I am unable to adopt the latest release plugin
until this is resolved.
I think this also impairs my progress towards Maven 3.
*I'd really appreciate this being resolved!* Thanks!
SCM properties being replaced during release:perform
Key: MRELEASE-128
URL: http://jira.codehaus.org/browse/MRELEASE-128
Project: Maven 2.x Release Plugin
Issue Type: Bug
Components: prepare
Environment: Windows XP client, Linux repo, CVS, Maven 2.0.4
Reporter: Craig Dickson
Assignee: Brett Porter
Priority: Critical
Fix For: 2.2
Attachments: after-release-perform-pom.xml,
after-release-prepre-pom.xml, MNG-128-maven-release-manager.patch,
MRELEASE-128_cvs_hack_RewritePomsForDevelopmentPhase.java.patch,
original-pom.xml
The scm section of a pom in CVS for a pom archetype project looks like this
prior to executing release:prepare :
scm
connection${base.cvs.url}:commons-maven/uber-pom/connection
developerConnection${base.cvs.url}:commons-maven/uber-pom/developerConnection
url${base.viewcvs.url}/commons-maven/uber-pom/url
/scm
Then after executing release:prepare, the pom in CVS looks like this (new
tag tag is only difference):
scm
connection${base.cvs.url}:commons-maven/uber-pom/connection
developerConnection${base.cvs.url}:commons-maven/uber-pom/developerConnection
url${base.viewcvs.url}/commons-maven/uber-pom/url
tagR-1_7/tag
/scm
Then after executing release:perform, the pom looks like this in CVS:
scm
connectionscm:cvs:pserver:behrcvs.masco-coatings.com:/usr/cvsroot:commons-maven/uber-pom/connection
developerConnectionscm:cvs:pserver:behrcvs.masco-coatings.com:/usr/cvsroot:commons-maven/uber-pom/developerConnection
urlhttp://behrcvs.masco-coatings.com/cgi-bin/viewcvs.cgi/commons-maven/uber-pom/url
/scm
Notice that the properties that were there for the base URLs for CVS and
ViewCVS have been replaced with literal values.
No other properties in the POM are being replaced
--
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-171) support TimeZones as a timezone
[
http://jira.codehaus.org/browse/MPIR-171?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=234307#action_234307
]
Anthony Whitford commented on MPIR-171:
---
I second the idea of using
[TimeZone|http://download.oracle.com/javase/6/docs/api/java/util/TimeZone.html]
values instead of an integer offset. The offset idea is flawed because it does
not account for daylight savings. For example, consider the TimeZone
{{America/Los_Angeles}}: Los Angeles is in the Pacific Time Zone, which is
GMT-8 during Standard Time and GMT-7 during Daylight Saving Time. Some time
zones will not adjust for daylight savings. Finally, countries will change
their time zone rules, specifically adjusting when they start and end daylight
savings.
support TimeZones as a timezone
-
Key: MPIR-171
URL: http://jira.codehaus.org/browse/MPIR-171
Project: Maven 2.x Project Info Reports Plugin
Issue Type: Improvement
Affects Versions: 2.1.2
Reporter: James Nord
Priority: Trivial
The POM XSD defiens the TimeZone as an xs:string (although the descriptions
says an integer between -11 and 12)
If the desctription is enforced you can not be in a timezone that is not a
multiple of 1 hour away from UTC (e.g. certain parts of india)
So the description is wrong and it's just a String.
So why not support a full formatted timezone such as Europe/London, then the
mpir can use funky javascript to show your actual time including any daylight
saving offset. (as opposed to a fixed offset from GMT ignoring DST changes)
e.g. support
{code:xml}developers
developer
idbob/id
nameBob Hacker/name
emailb...@example.com/email
timezoneEurope/London/timezone
roles
roledeveloper/role
/roles
/developer
/developers{code}
Currently the site shows NaN for the Current time.
--
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: (MREPOSITORY-25) bundle-create creates jar making a preceding gpg:sign step invalid
bundle-create creates jar making a preceding gpg:sign step invalid
--
Key: MREPOSITORY-25
URL: http://jira.codehaus.org/browse/MREPOSITORY-25
Project: Maven 2.x Repository Plugin
Issue Type: Bug
Affects Versions: 2.3.1
Environment: Ubuntu 10.4, Sun Java 1.6.0_20, Maven 2.2.1
Reporter: Anthony Whitford
Despite following instructions found here:
https://docs.sonatype.org/display/Repository/Uploading+3rd-party+Artifacts+to+Maven+Central
I ran into a problem uploading the bundle to Sonatype's Staging area.
Specifically, I received an *Invalid Signature* error for the main jar
artifact.
Sure enough, I ran the following: {noformat}gpg --verify foo.jar.asc{noformat}
and it confirmed that the signature was BAD.
Upon further investigation, it would seem that the problem is that the
repository:bundle-create goal is recreating the jar file, so the
command:{noformat}mvn source:jar javadoc:jar package gpg:sign
repository:bundle-create -Dgpg.passphrase=xx{noformat}
seems to be creating the jar, signing it, and then creating the jar again --
resulting in an invalid gpg signature for the jar.
Note that my pom does not include a gpg signing step -- that is why it is part
of the command line. My guess is that configuring the maven-gpg-plugin in the
project pom may make this work -- but I did not have the luxury of being able
to do that this time.
The bundle-create goal needs to not recreate the jar file -- just make the
bundle. Or clarify the documentation.
--
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: (WAGON-303) Make wagon-scm work better with git
[ http://jira.codehaus.org/browse/WAGON-303?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=233218#action_233218 ] Anthony Whitford commented on WAGON-303: I would very much like improved git compatibility and agree that the current implementation is basically making an assumption about tagging conventions that is true for cvs and svn, but is not true for git... Personally, rather than leverage settings.xml as Kathryn suggests, I think I would rather see improved url parsing/handling. Why can't .../project.git/dir mean what we think it should mean, but beneath the covers is translated to the appropriate multiple steps by the git provider? Make wagon-scm work better with git --- Key: WAGON-303 URL: http://jira.codehaus.org/browse/WAGON-303 Project: Maven Wagon Issue Type: Improvement Components: wagon-scm Affects Versions: 1.0-beta-6 Reporter: Kathryn Huxtable Attachments: wagon-scm.patch Using wagon-scm with site:deploy doesn't work with git because the wagon appends the current target to the repository name. This only works with subversion. I have added a mechanism to supply a branch or tag in settings.xml and use it for non-git repositories. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MSITE-250) Allow cleaning of the remote area or staging site
[
http://jira.codehaus.org/browse/MSITE-250?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=215307#action_215307
]
Anthony Whitford commented on MSITE-250:
My use case is that I deploy the site files to a file share: {{\\server\sites}}
The sites are organized by project and version:
{{\\server\sites\project\version}}
The CI server will build the site, let's say for {{1.0-SNAPSHOT}}:
{{\\server\sites\project\1.0-SNAPSHOT\}}
Then, I will release this project, and I get a site for {{1.0}}:
{{\\server\sites\project\1.0\}}
My issue is that I am getting _toxic waste buildup_ by not removing the old
{{1.0-SNAPSHOT}} directory.
If I had a {{site:clean}} goal, I could build it into my release workflow.
Better yet, the release plugin could leverage it and automatically purge the
old snapshot files.
Allow cleaning of the remote area or staging site
-
Key: MSITE-250
URL: http://jira.codehaus.org/browse/MSITE-250
Project: Maven 2.x Site Plugin
Issue Type: New Feature
Reporter: Wim Deblauwe
When files have been removed, they are not removed from the remote deploy
area or the staging site. A new goal to clean the staging or the final deploy
area would be a nice addon to this plugin.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MSITE-459) Fatal Error on site:deploy
[
http://jira.codehaus.org/browse/MSITE-459?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=215187#action_215187
]
Anthony Whitford commented on MSITE-459:
The root issue may be related to doxia, because we think we can work around
this bug doing something like:
{code:xml}
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-site-plugin/artifactId
version2.1/version
configuration
inputEncodingUTF-8/inputEncoding
outputEncodingUTF-8/outputEncoding
/configuration
!-- Need to exclude commons-logging due to bug.
See: http://jira.codehaus.org/browse/MSITE-459 --
dependencies
dependency
groupIdorg.apache.maven.doxia/groupId
artifactIddoxia-module-xhtml/artifactId
version1.1.2/version
exclusions
exclusion
groupIdcommons-logging/groupId
artifactIdcommons-logging/artifactId
/exclusion
/exclusions
/dependency
/dependencies
/plugin
{code}
Fatal Error on site:deploy
--
Key: MSITE-459
URL: http://jira.codehaus.org/browse/MSITE-459
Project: Maven 2.x Site Plugin
Issue Type: Bug
Components: site:deploy
Affects Versions: 2.1
Environment: Apache Maven 2.2.1 (r801777; 2009-08-06 21:16:01+0200)
Java version: 1.6.0_17
OS name: mac os x version: 10.6.2 arch: x86_64 Family: mac
Reporter: Lorenzo Bigagli
Priority: Blocker
Attachments: lablib-checkboxtree.zip
site:deploy fails as follows (related to wagon-webdav dependencies?
Commons-logging?).
Reverting to maven-site-plugin:2.0.x works around the issue.
I attach the project zip (appropriate server/dav configuration needed to
reproduce the problem).
[INFO] Scanning for projects...
[INFO] Searching repository for plugin with prefix: 'site'.
[INFO] org.apache.maven.plugins: checking for updates from
maven2-repo-dev-java-net
[INFO] org.apache.maven.plugins: checking for updates from
maven-repository.dev.java.net
[INFO] org.apache.maven.plugins: checking for updates from hosted.repos
[INFO] org.codehaus.mojo: checking for updates from maven2-repo-dev-java-net
[INFO] org.codehaus.mojo: checking for updates from
maven-repository.dev.java.net
[INFO] org.codehaus.mojo: checking for updates from hosted.repos
[INFO]
[INFO] Building CheckboxTree
[INFO]task-segment: [site:deploy]
[INFO]
[INFO] [site:deploy {execution: default-cli}]
WAGON_VERSION: 1.0-beta-2
http://zeus.pin.unifi.it/projectsSites/lablib-checkboxtree_snap - Session:
Disconnecting
http://zeus.pin.unifi.it/projectsSites/lablib-checkboxtree_snap - Session:
Disconnected
[FATAL ERROR] org.apache.maven.plugins.site.SiteDeployMojo#execute() caused a
linkage error (java.lang.ExceptionInInitializerError) and may be out-of-date.
Check the realms:
[FATAL ERROR] Plugin realm =
app0.child-container[org.apache.maven.plugins:maven-site-plugin:2.1]
urls[0] =
file:/Users/bigagli/.m2/repository/org/apache/maven/plugins/maven-site-plugin/2.1/maven-site-plugin-2.1.jar
urls[1] =
file:/Users/bigagli/.m2/repository/org/codehaus/plexus/plexus-utils/1.5.1/plexus-utils-1.5.1.jar
urls[2] =
file:/Users/bigagli/.m2/repository/org/apache/maven/doxia/doxia-module-xhtml/1.1.2/doxia-module-xhtml-1.1.2.jar
urls[3] =
file:/Users/bigagli/.m2/repository/org/apache/maven/doxia/doxia-core/1.1.2/doxia-core-1.1.2.jar
urls[4] =
file:/Users/bigagli/.m2/repository/xerces/xercesImpl/2.8.1/xercesImpl-2.8.1.jar
urls[5] =
file:/Users/bigagli/.m2/repository/xml-apis/xml-apis/1.3.03/xml-apis-1.3.03.jar
urls[6] =
file:/Users/bigagli/.m2/repository/commons-lang/commons-lang/2.1/commons-lang-2.1.jar
urls[7] =
file:/Users/bigagli/.m2/repository/commons-httpclient/commons-httpclient/3.1/commons-httpclient-3.1.jar
urls[8] =
file:/Users/bigagli/.m2/repository/commons-logging/commons-logging/1.0.4/commons-logging-1.0.4.jar
urls[9] =
file:/Users/bigagli/.m2/repository/commons-codec/commons-codec/1.2/commons-codec-1.2.jar
urls[10] =
file:/Users/bigagli/.m2/repository/org/apache/maven/doxia/doxia-module-apt/1.1.2/doxia-module-apt-1.1.2.jar
urls[11] =
file:/Users/bigagli/.m2/repository/org/apache/maven/doxia/doxia-module-xdoc/1.1.2/doxia-module-xdoc-1.1.2.jar
urls[12] =
file:/Users/bigagli/.m2/repository/org/apache/maven/doxia/doxia-module-fml/1.1.2/doxia-module-fml-1.1.2.jar
urls[13] =
file:/Users/bigagli/.m2/repository/org/apache/maven/doxia/doxia-decoration-model/1.1.2/doxia-decoration-model-1.1.2.jar
urls[14] =
[jira] Created: (MPATCH-12) Full Cross platform support
Full Cross platform support --- Key: MPATCH-12 URL: http://jira.codehaus.org/browse/MPATCH-12 Project: Maven 2.x Patch Plugin Issue Type: Improvement Affects Versions: 1.1.1 Environment: Windows Reporter: Anthony Whitford Your [FAQ|http://maven.apache.org/plugins/maven-patch-plugin/faq.html#Why_doesnt_this_work_on_Windows] explains why this plugin won't work on Windows: it depends on the _GNU patch tool_. Why not use a patch library so that you don't rely on the GNU patch tool and then you will get full cross platform compatibility? Perhaps this: http://code.google.com/p/google-diff-match-patch/ -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MPATCH-13) diff goal
diff goal
-
Key: MPATCH-13
URL: http://jira.codehaus.org/browse/MPATCH-13
Project: Maven 2.x Patch Plugin
Issue Type: Wish
Affects Versions: 1.1.1
Reporter: Anthony Whitford
It would be great to have a {{diff}} goal in addition to the {{patch}}. The
{{diff}} goal would be useful for creating a patch 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: (MJAVADOC-276) Initial builds of a multi-module project fail
Initial builds of a multi-module project fail
-
Key: MJAVADOC-276
URL: http://jira.codehaus.org/browse/MJAVADOC-276
Project: Maven 2.x Javadoc Plugin
Issue Type: Bug
Affects Versions: 2.6.1
Environment: Java jdk1.6.0_16, Maven 2.2.1, Windows Vista 64-bit
Java jdk1.6.0_05, Maven 2.0.9, Windows XP 32-bit
Reporter: Anthony Whitford
Priority: Blocker
Attachments: bug.zip
I ran into a problem using Maven Javadoc Plugin 2.6.1 right after I released...
I went from version 1.15 to 1.16-SNAPSHOT, and my 1.16-SNAPSHOT build failed
({{mvn clean install site}}) because Javadoc fails when run from the top-level
parent. When it is building _module A_, the javadoc complains that _module B_
and _module C_ are missing -- of course they are, they haven't been built yet.
Note that running {{mvn clean install}} from _module A_ works fine -- the
behavior is limited to running from the top-level parent -- AND, if you run a
{{mvn install}} for _module B_ and _module C_, then you have given it what it
needs and so you won't see the error.
The attached example exhibits the problem. It was created from the
_j2ee-simple_ archetype -- I only added the explicit javadoc plugin declaration
to the top level pom to control the version being used. To recreate the
problem, unzip and simply: {{mvn clean install site}}. You will get an error
message like:
{noformat}
[INFO] Unable to find resource 'root.project.projects:logging:jar:1.0' in
repository central (http://repo1.maven.org/maven2)
[INFO]
[ERROR] BUILD ERROR
[INFO]
[INFO] Failed to resolve artifact.
Missing:
--
1) root.project.projects:logging:jar:1.0
Try downloading the file manually from the project website.
Then, install it using the command:
mvn install:install-file -DgroupId=root.project.projects
-DartifactId=logging -Dversion=1.0 -Dpackaging=jar -Dfile=/path/to/file
Alternatively, if you host your own repository you can deploy the file there:
mvn deploy:deploy-file -DgroupId=root.project.projects
-DartifactId=logging -Dversion=1.0 -Dpackaging=jar -Dfile=/path/to/file
-Durl=[url] -DrepositoryId=
[id]
Path to dependency:
1) root.project:primary-source:jar:1.0
2) root.project.projects:logging:jar:1.0
--
1 required artifact is missing.
for artifact:
root.project:primary-source:jar:1.0
from the specified remote repositories:
central (http://repo1.maven.org/maven2)
{noformat}
As you can see, it seems to think that a submodule (in this case
{{root.project.projects:logging:jar:1.0}}) is necessary to build the javadoc
for the project... Since this is the first time that this is being built, the
submodule does not exist (yet).
I have replicated this problem on two different computing environments, so I'm
convinced that the Maven version is not relevant.
(It is unclear to me if this problem also existed with Javadoc 2.6, but I don't
think so.)
--
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-276) Initial builds of a multi-module project fail
[
http://jira.codehaus.org/browse/MJAVADOC-276?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=199687#action_199687
]
Anthony Whitford commented on MJAVADOC-276:
---
Is this related to MNG-3685 or MJAVADOC-116?
Initial builds of a multi-module project fail
-
Key: MJAVADOC-276
URL: http://jira.codehaus.org/browse/MJAVADOC-276
Project: Maven 2.x Javadoc Plugin
Issue Type: Bug
Affects Versions: 2.6.1
Environment: Java jdk1.6.0_16, Maven 2.2.1, Windows Vista 64-bit
Java jdk1.6.0_05, Maven 2.0.9, Windows XP 32-bit
Reporter: Anthony Whitford
Priority: Blocker
Attachments: bug.zip
I ran into a problem using Maven Javadoc Plugin 2.6.1 right after I
released... I went from version 1.15 to 1.16-SNAPSHOT, and my 1.16-SNAPSHOT
build failed ({{mvn clean install site}}) because Javadoc fails when run from
the top-level parent. When it is building _module A_, the javadoc complains
that _module B_ and _module C_ are missing -- of course they are, they
haven't been built yet. Note that running {{mvn clean install}} from _module
A_ works fine -- the behavior is limited to running from the top-level parent
-- AND, if you run a {{mvn install}} for _module B_ and _module C_, then you
have given it what it needs and so you won't see the error.
The attached example exhibits the problem. It was created from the
_j2ee-simple_ archetype -- I only added the explicit javadoc plugin
declaration to the top level pom to control the version being used. To
recreate the problem, unzip and simply: {{mvn clean install site}}. You
will get an error message like:
{noformat}
[INFO] Unable to find resource 'root.project.projects:logging:jar:1.0' in
repository central (http://repo1.maven.org/maven2)
[INFO]
[ERROR] BUILD ERROR
[INFO]
[INFO] Failed to resolve artifact.
Missing:
--
1) root.project.projects:logging:jar:1.0
Try downloading the file manually from the project website.
Then, install it using the command:
mvn install:install-file -DgroupId=root.project.projects
-DartifactId=logging -Dversion=1.0 -Dpackaging=jar -Dfile=/path/to/file
Alternatively, if you host your own repository you can deploy the file
there:
mvn deploy:deploy-file -DgroupId=root.project.projects
-DartifactId=logging -Dversion=1.0 -Dpackaging=jar -Dfile=/path/to/file
-Durl=[url] -DrepositoryId=
[id]
Path to dependency:
1) root.project:primary-source:jar:1.0
2) root.project.projects:logging:jar:1.0
--
1 required artifact is missing.
for artifact:
root.project:primary-source:jar:1.0
from the specified remote repositories:
central (http://repo1.maven.org/maven2)
{noformat}
As you can see, it seems to think that a submodule (in this case
{{root.project.projects:logging:jar:1.0}}) is necessary to build the javadoc
for the project... Since this is the first time that this is being built,
the submodule does not exist (yet).
I have replicated this problem on two different computing environments, so
I'm convinced that the Maven version is not relevant.
(It is unclear to me if this problem also existed with Javadoc 2.6, but I
don't think so.)
--
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-3685) Dependency can't be resolved but has been found in the reactor.
[ http://jira.codehaus.org/browse/MNG-3685?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=199689#action_199689 ] Anthony Whitford commented on MNG-3685: --- I seem to be experiencing this problem with the latest Javadoc plugin. I would characterize the issue as a *Blocker*! Dependency can't be resolved but has been found in the reactor. --- Key: MNG-3685 URL: http://jira.codehaus.org/browse/MNG-3685 Project: Maven 2 Issue Type: Bug Affects Versions: 2.0.9 Reporter: Jörg Hohwiller Fix For: 2.2.2 Attachments: sample-MNG-3685.tgz Since I upgraded maven to 2.0.9, I get messages like the following endlessly: Downloading: http://m-m-m.sourceforge.net/repository/net/sf/m-m-m/mmm-util-core/1.0.2-SNAPSHOT/mmm-util-core-1.0.2-SNAPSHOT.jar [WARNING] The dependency: net.sf.m-m-m:mmm-util-core:jar:1.0.2-SNAPSHOT can't be resolved but has been found in the reactor. This dependency has been excluded from the plugin execution. You should rerun this mojo after executing mvn install. This also happens, if someone checks out the project and does mvn eclipse:eclipse. The process still works but takes extraordinary long to proceed because it scales about n^2 with n beiing the number of modules in your reactor. You should also take into account that mvn install aborts if some tests fail. Sorry to say so, but this behaviour of maven is absolutely inacceptable. I hope there is a chance to fix this in the next release(s). 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] Created: (MEV-646) FindBugs-Annotations 1.3.8 pom is not for annotations
FindBugs-Annotations 1.3.8 pom is not for annotations
-
Key: MEV-646
URL: http://jira.codehaus.org/browse/MEV-646
Project: Maven Evangelism
Issue Type: Bug
Components: Invalid POM
Reporter: Anthony Whitford
This POM:
http://repo1.maven.org/maven2/com/google/code/findbugs/annotations/1.3.8/annotations-1.3.8.pom
is for a different artifact ({{findbugs}}, not {{annotations}}). It should be
similar to:
http://repo1.maven.org/maven2/com/google/code/findbugs/annotations/1.3.9/annotations-1.3.9.pom
or this:
http://repo1.maven.org/maven2/com/google/code/findbugs/annotations/1.3.7/annotations-1.3.7.pom
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MAVENUPLOAD-2455) Upload oval-1.32
[ http://jira.codehaus.org/browse/MAVENUPLOAD-2455?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=180132#action_180132 ] Anthony Whitford commented on MAVENUPLOAD-2455: --- How can this get some attention? It has been over a month... Upload oval-1.32 Key: MAVENUPLOAD-2455 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2455 Project: Maven Upload Requests Issue Type: Task Reporter: Sebastian T OVal is a pragmatic and extensible validation framework for any kind of Java objects (not only JavaBeans). Constraints can be configured with annotations, POJOs or XML. Custom constraints can be expressed in pure Java or by using scripting languages such as JavaScript, Groovy, BeanShell, OGNL, MVEL or Ruby. Besides simple object validation OVal implements Programming by Contract features by utilizing AspectJ based aspects. This program and the accompanying materials are made available under the terms of the Eclipse Public License v1.0 which accompanies this distribution, and is available at http://www.eclipse.org/legal/epl-v10.html Thanks in advance! -- 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-2441) rsync part of the scala-tools.org repository - not working
rsync part of the scala-tools.org repository - not working -- Key: MAVENUPLOAD-2441 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2441 Project: Maven Upload Requests Issue Type: Bug Reporter: Anthony Whitford I don't think the rsync for the Scala-Tools.org, requested by issue MAVENUPLOAD-2344, is working. I say this because version 2.7.4 (for example) is available at: http://scala-tools.org/repo-releases/org/scala-lang/scala-library/ but this version is not available on central: http://repo1.maven.org/maven2/org/scala-lang/scala-library/ There is a subtle error on the original issue that I think might be intefering with the rsync... http://scala-tools.org/repo-releases does not work, but http://scala-tools.org/repo-releases/ does work. (The trailing slash is required.) -- 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: (MSITE-398) Menus from the parent pom should not be inherited
Menus from the parent pom should not be inherited
-
Key: MSITE-398
URL: http://jira.codehaus.org/browse/MSITE-398
Project: Maven 2.x Site Plugin
Issue Type: Bug
Components: site descriptor
Affects Versions: 2.0, 2.0-beta-7, 2.0-beta-6
Environment: Windows, Java 6, Maven 2.09
Reporter: Anthony Whitford
Priority: Blocker
Attachments: maven-site-plugin-bug.zip
According to the *Inheritance* section from:
[http://maven.apache.org/plugins/maven-site-plugin/examples/sitedescriptor.html]
it says,
bq. By default, only the basic settings are inherited. From the body, only the
links are inherited, and these accumulate to contain all the parents' site
descriptor links.
Alas, this is not the case and this is a major problem. If I downgrade to
2.0-beta-5, the behavior is as expected. Using 2.0-beta-6, 2.0-beta-7, or 2.0,
makes the menus from the parent pom trickle into the inheriting project.
I have attached a sample project to illustrate this problem. The attached zip
contains 2 simple maven projects:
* parentpom -- represents a corporate parent pom with some site documentation
* multiproj -- represents a multiproject that inherits the parentpom.
If you edit _parentpom\pom.xml_ and change the version of the site plugin to
*2.0-beta-5*, then run {{mvn clean install site}} for both the {{parentpom}}
and then {{multiproj}}, you will see a fine site generated for _multiproj_.
Then, if you edit _parentpom\pom.xml_ and change the version of the site plugin
to *2.0* (the latest), then run {{mvn clean install site}} for both the
{{parentpom}} and then {{multiproj}}, you will see the site generated for
_multiproj_ contains menu links from the parent pom which should not have been
inherited.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MSITE-293) Submodule inherit menu but this should not happend
[
http://jira.codehaus.org/browse/MSITE-293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=171662#action_171662
]
Anthony Whitford commented on MSITE-293:
This needs to be in the pipeline to be fixed, otherwise we can't upgrade!
Pretty please... :D
Submodule inherit menu but this should not happend
--
Key: MSITE-293
URL: http://jira.codehaus.org/browse/MSITE-293
Project: Maven 2.x Site Plugin
Issue Type: Bug
Components: inheritance, site descriptor
Affects Versions: 2.0-beta-6
Environment: maven 2.0.8
jdk 1.6
windows
Reporter: Andreas Höhmann
Priority: Critical
Attachments: MSITE-293.zip
Projectstructur:
{noformat}
modul
| pom.xml
| src/site/site.xml
| src/site/xdoc/index.xml
+-- submodul 1
| pom.xml
| src/site/xdoc/index.xml
+-- submodul 2
| pom.xml
| src/site/xdoc/index.xml
{noformat}
modul :: site.xml
{code}
...
body
menu ref=parent /
menu name=Overview inherit=top
item name=Introduction href=index.html/
/menu
menu name=Maven
item name=FAQ href=faq.html/
item name=Profiles href=maven_profiles.html/
/menu
links
item name=Maven Repository
href=http://lp2p067c:82/maven2/repositories/; /
/links
menu ref=modules inherit=bottom /
menu ref=reports inherit=bottom /
/body
...
{code}
after mvn clean install site each submodules has a menu Maven ... but i
want this only for the main-modul.
whats wrong?
http://maven.apache.org/plugins/maven-site-plugin/examples/sitedescriptor.html
... Inheritance ... By default, only the basic settings are inherited. From
the body, only the links are inherited, and these accumulate to contain all
the parents' site descriptor links.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Reopened: (MNG-4001) Unable to resolve Dashboard mojo from Central
[
http://jira.codehaus.org/browse/MNG-4001?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anthony Whitford reopened MNG-4001:
---
I am looking at
[http://repo2.maven.org/maven2/org/codehaus/mojo/maven-metadata.xml] and I
clearly see:{code:xml}
plugin
nameMaven Dashboard Report Plugin/name
prefixdashboard/prefix
artifactIddashboard-maven-plugin/artifactId
/plugin
{code}
So why are you saying it isn't there?
Unable to resolve Dashboard mojo from Central
-
Key: MNG-4001
URL: http://jira.codehaus.org/browse/MNG-4001
Project: Maven 2
Issue Type: Bug
Components: Sites Reporting
Affects Versions: 2.0.9
Environment: Windows, JDK 1.6
Reporter: Anthony Whitford
Assignee: Brett Porter
Attachments: dashbug.zip
I have a simple test project that declares the dashboard-maven-plugin (see
http://mojo.codehaus.org/dashboard-maven-plugin/usage.html ).
Note that the usage does explicitly state that the Codehaus repository must
be specified as a plugin repository...
However, according to:
http://maven.apache.org/guides/introduction/introduction-to-plugin-prefix-mapping.html
I'm pretty sure that Maven should be able to resolve the
dashboard-maven-plugin from the central repo.
I validated that the [dashboard-maven-plugin residing in
central|http://repo1.maven.org/maven2/org/codehaus/mojo/dashboard-maven-plugin/1.0.0-beta-1/]
is indeed the same artifact as that which lives at the [codehaus
repository|http://repository.codehaus.org/org/codehaus/mojo/dashboard-maven-plugin/1.0.0-beta-1/].
But as you can see from my attached test case, the codehaus mojo is NOT being
resolved without the special plugin repository defined. When running
{noformat}mvn dashboard:dashboard{noformat}, I get the following error
message:
{noformat}
[INFO] Scanning for projects...
[INFO] Searching repository for plugin with prefix: 'dashboard'.
[INFO]
[ERROR] BUILD ERROR
[INFO]
[INFO] The plugin 'org.apache.maven.plugins:maven-dashboard-plugin' does not
exist or no valid version could be found
[INFO]
[INFO] For more information, run Maven with the -e switch
[INFO]
[INFO] Total time: 1 second
[INFO] Finished at: Sat Jan 24 12:40:55 PST 2009
[INFO] Final Memory: 1M/254M
[INFO]
{noformat}
If you edit the pom.xml to uncomment out the plugin repository declaration
for codehaus, it works as one would expect.
My understanding is that the only reason why the Dashboard Usage mentions
their plugin repository is because the artifact was not available on the
central repository -- but it certainly is today.
I also thought that perhaps the maven-metadata.xml might be incorrect
(perhaps the dashboard plugin prefix is missing or different). I checked:
* http://repo1.maven.org/maven2/org/codehaus/mojo/maven-metadata.xml
* http://repository.codehaus.org/org/codehaus/mojo/maven-metadata.xml
and they both look OK to me... I clearly see:{code:xml}
plugin
nameMaven Dashboard Report Plugin/name
prefixdashboard/prefix
artifactIddashboard-maven-plugin/artifactId
/plugin
{code}
And I don't see any plugin with a dashboard prefix specified as an Apache
Maven Plugin here:
* http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-metadata.xml
If I explicitly specify the dashboard plugin like: {noformat}mvn
org.codehaus.mojo:dashboard-maven-plugin:dashboard{noformat}
that works...
Overall, I am recording a bug because the
[documentation|http://maven.apache.org/guides/introduction/introduction-to-plugin-prefix-mapping.html]
states:{quote}
Maven will always search the following groupId's after searching any plugin
groups specified in the user's settings:
* org.apache.maven.plugins
* org.codehaus.mojo
{quote}
I don't see this being done.
Finally, I even tried adding a {{pluginGroups}} to my
{{settings.xml}}:{code:xml}
pluginGroups
pluginGrouporg.codehaus.mojo/pluginGroup
/pluginGroups
{code}
But that did not work either...
--
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-4001) Unable to resolve Dashboard mojo from Central
[
http://jira.codehaus.org/browse/MNG-4001?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=162471#action_162471
]
Anthony Whitford commented on MNG-4001:
---
OK, I traced the problem due to:
* {{.m2\repository\org\codehaus\mojo\maven-metadata-central.xml}}
I had to nuke my local repo's mojo directory to force a re-download.
So while I agree there was a metadata problem in my local repository, I still
think there is a TODO for Maven because there isn't really a command to force
an update of this file (and even detection that it is out of date). (Or is
there?) I tried {{mvn -cpu}}, but that doesn't refresh the bad
{{maven-metadata-central.xml}} file.
Unable to resolve Dashboard mojo from Central
-
Key: MNG-4001
URL: http://jira.codehaus.org/browse/MNG-4001
Project: Maven 2
Issue Type: Bug
Components: Sites Reporting
Affects Versions: 2.0.9
Environment: Windows, JDK 1.6
Reporter: Anthony Whitford
Assignee: Brett Porter
Attachments: dashbug.zip
I have a simple test project that declares the dashboard-maven-plugin (see
http://mojo.codehaus.org/dashboard-maven-plugin/usage.html ).
Note that the usage does explicitly state that the Codehaus repository must
be specified as a plugin repository...
However, according to:
http://maven.apache.org/guides/introduction/introduction-to-plugin-prefix-mapping.html
I'm pretty sure that Maven should be able to resolve the
dashboard-maven-plugin from the central repo.
I validated that the [dashboard-maven-plugin residing in
central|http://repo1.maven.org/maven2/org/codehaus/mojo/dashboard-maven-plugin/1.0.0-beta-1/]
is indeed the same artifact as that which lives at the [codehaus
repository|http://repository.codehaus.org/org/codehaus/mojo/dashboard-maven-plugin/1.0.0-beta-1/].
But as you can see from my attached test case, the codehaus mojo is NOT being
resolved without the special plugin repository defined. When running
{noformat}mvn dashboard:dashboard{noformat}, I get the following error
message:
{noformat}
[INFO] Scanning for projects...
[INFO] Searching repository for plugin with prefix: 'dashboard'.
[INFO]
[ERROR] BUILD ERROR
[INFO]
[INFO] The plugin 'org.apache.maven.plugins:maven-dashboard-plugin' does not
exist or no valid version could be found
[INFO]
[INFO] For more information, run Maven with the -e switch
[INFO]
[INFO] Total time: 1 second
[INFO] Finished at: Sat Jan 24 12:40:55 PST 2009
[INFO] Final Memory: 1M/254M
[INFO]
{noformat}
If you edit the pom.xml to uncomment out the plugin repository declaration
for codehaus, it works as one would expect.
My understanding is that the only reason why the Dashboard Usage mentions
their plugin repository is because the artifact was not available on the
central repository -- but it certainly is today.
I also thought that perhaps the maven-metadata.xml might be incorrect
(perhaps the dashboard plugin prefix is missing or different). I checked:
* http://repo1.maven.org/maven2/org/codehaus/mojo/maven-metadata.xml
* http://repository.codehaus.org/org/codehaus/mojo/maven-metadata.xml
and they both look OK to me... I clearly see:{code:xml}
plugin
nameMaven Dashboard Report Plugin/name
prefixdashboard/prefix
artifactIddashboard-maven-plugin/artifactId
/plugin
{code}
And I don't see any plugin with a dashboard prefix specified as an Apache
Maven Plugin here:
* http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-metadata.xml
If I explicitly specify the dashboard plugin like: {noformat}mvn
org.codehaus.mojo:dashboard-maven-plugin:dashboard{noformat}
that works...
Overall, I am recording a bug because the
[documentation|http://maven.apache.org/guides/introduction/introduction-to-plugin-prefix-mapping.html]
states:{quote}
Maven will always search the following groupId's after searching any plugin
groups specified in the user's settings:
* org.apache.maven.plugins
* org.codehaus.mojo
{quote}
I don't see this being done.
Finally, I even tried adding a {{pluginGroups}} to my
{{settings.xml}}:{code:xml}
pluginGroups
pluginGrouporg.codehaus.mojo/pluginGroup
/pluginGroups
{code}
But that did not work either...
--
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
[jira] Created: (MNG-4001) Unable to resolve Dashboard mojo from Central
Unable to resolve Dashboard mojo from Central
-
Key: MNG-4001
URL: http://jira.codehaus.org/browse/MNG-4001
Project: Maven 2
Issue Type: Bug
Components: Sites Reporting
Affects Versions: 2.0.9
Environment: Windows, JDK 1.6
Reporter: Anthony Whitford
Attachments: dashbug.zip
I have a simple test project that declares the dashboard-maven-plugin (see
http://mojo.codehaus.org/dashboard-maven-plugin/usage.html ).
Note that the usage does explicitly state that the Codehaus repository must be
specified as a plugin repository...
However, according to:
http://maven.apache.org/guides/introduction/introduction-to-plugin-prefix-mapping.html
I'm pretty sure that Maven should be able to resolve the dashboard-maven-plugin
from the central repo.
I validated that the [dashboard-maven-plugin residing in
central|http://repo1.maven.org/maven2/org/codehaus/mojo/dashboard-maven-plugin/1.0.0-beta-1/]
is indeed the same artifact as that which lives at the [codehaus
repository|http://repository.codehaus.org/org/codehaus/mojo/dashboard-maven-plugin/1.0.0-beta-1/].
But as you can see from my attached test case, the codehaus mojo is NOT being
resolved without the special plugin repository defined. When running
{noformat}mvn dashboard:dashboard{noformat}, I get the following error message:
{noformat}
[INFO] Scanning for projects...
[INFO] Searching repository for plugin with prefix: 'dashboard'.
[INFO]
[ERROR] BUILD ERROR
[INFO]
[INFO] The plugin 'org.apache.maven.plugins:maven-dashboard-plugin' does not
exist or no valid version could be found
[INFO]
[INFO] For more information, run Maven with the -e switch
[INFO]
[INFO] Total time: 1 second
[INFO] Finished at: Sat Jan 24 12:40:55 PST 2009
[INFO] Final Memory: 1M/254M
[INFO]
{noformat}
If you edit the pom.xml to uncomment out the plugin repository declaration for
codehaus, it works as one would expect.
My understanding is that the only reason why the Dashboard Usage mentions their
plugin repository is because the artifact was not available on the central
repository -- but it certainly is today.
I also thought that perhaps the maven-metadata.xml might be incorrect (perhaps
the dashboard plugin prefix is missing or different). I checked:
* http://repo1.maven.org/maven2/org/codehaus/mojo/maven-metadata.xml
* http://repository.codehaus.org/org/codehaus/mojo/maven-metadata.xml
and they both look OK to me... I clearly see:{code:xml}
plugin
nameMaven Dashboard Report Plugin/name
prefixdashboard/prefix
artifactIddashboard-maven-plugin/artifactId
/plugin
{code}
And I don't see any plugin with a dashboard prefix specified as an Apache Maven
Plugin here:
* http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-metadata.xml
If I explicitly specify the dashboard plugin like: {noformat}mvn
org.codehaus.mojo:dashboard-maven-plugin:dashboard{noformat}
that works...
Overall, I am recording a bug because the
[documentation|http://maven.apache.org/guides/introduction/introduction-to-plugin-prefix-mapping.html]
states:{quote}
Maven will always search the following groupId's after searching any plugin
groups specified in the user's settings:
* org.apache.maven.plugins
* org.codehaus.mojo
{quote}
I don't see this being done.
Finally, I even tried adding a {{pluginGroups}} to my
{{settings.xml}}:{code:xml}
pluginGroups
pluginGrouporg.codehaus.mojo/pluginGroup
/pluginGroups
{code}
But that did not work either...
--
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
