[jira] (MRELEASE-881) mvn release:branch fails on Windows to commit changed pom in branch

2014-07-09 Thread Thomas Wabner (JIRA)
Thomas Wabner created MRELEASE-881:
--

 Summary: mvn release:branch fails on Windows to commit changed pom 
in branch
 Key: MRELEASE-881
 URL: https://jira.codehaus.org/browse/MRELEASE-881
 Project: Maven Release Plugin
  Issue Type: Bug
  Components: branch
Affects Versions: 2.5, 2.3.2
 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
Priority: Blocker


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.

Following command fails to commit the next pom into the branch:

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] 



--
This message was sent by Atlassian JIRA
(v6.1.6#6162)


[jira] (MRELEASE-881) mvn release:branch fails on Windows to commit changed pom in branch

2014-07-09 Thread Thomas Wabner (JIRA)

 [ 
https://jira.codehaus.org/browse/MRELEASE-881?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Thomas Wabner updated MRELEASE-881:
---

Description: 
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:

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] 

  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.

Following command fails to commit the next pom into the branch:

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 

[jira] (MRELEASE-881) mvn release:branch fails on Windows to commit changed pom in branch

2014-07-09 Thread Thomas Wabner (JIRA)

 [ 
https://jira.codehaus.org/browse/MRELEASE-881?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Thomas Wabner updated MRELEASE-881:
---

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

  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-881
 URL: https://jira.codehaus.org/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
Priority: Blocker

 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:
 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] 
 

[jira] (SCM-764) username and credentials shown as INFO on commadline

2014-07-09 Thread Thomas Wabner (JIRA)
Thomas Wabner created SCM-764:
-

 Summary: username and credentials shown as INFO on commadline
 Key: SCM-764
 URL: https://jira.codehaus.org/browse/SCM-764
 Project: Maven SCM
  Issue Type: Bug
  Components: maven-scm-provider-git
 Environment: Apache Maven 3.2.1 
(ea8b2b07643dbb1b84b6d16e1f08391b666bc1e9; 2014-02-14T18:37:52+01:00)
Maven home: D:\Dev\maven\apache-maven-3.2.1
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


Using git repository with gitblit on HTTPS.

Every git command which involve the remote repository (like fetch, pull, push 
and so on) showing the username and credentials on the commandline like this:

[INFO] Executing: cmd.exe /X /C git push 
https://user:secret@devserver/gitblit//r/waffel/devopts.git test-branch

It should be avoided to ever print out passwords on the command line. I have 
encrypted the password in maven settings.xml ... but now it comes back and 
anybody can see them (also on a continues build server which should push with a 
dedicated user to a central repo).



--
This message was sent by Atlassian JIRA
(v6.1.6#6162)


[jira] (MCHANGES-308) Support filters when using REST API / JQL

2014-07-09 Thread Bruno Marti (JIRA)

[ 
https://jira.codehaus.org/browse/MCHANGES-308?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=349354#comment-349354
 ] 

Bruno Marti commented on MCHANGES-308:
--

current patch does not honor maven variables.
this *works*:
  {code}filterlabels=my-custom-label/filter{code}
this *doesn't work*:
  {code}filterlabels=${project_specification_title}/filter{code}

 Support filters when using REST API / JQL
 -

 Key: MCHANGES-308
 URL: https://jira.codehaus.org/browse/MCHANGES-308
 Project: Maven Changes Plugin
  Issue Type: Wish
  Components: jira
Affects Versions: 2.8, 2.9
Reporter: Johannes Odland
 Attachments: 
 MCHANGES-308__Support_filters_when_using_REST_API___JQL.patch


 The original JiraDownloader supported a custom filter for downloading issues.
 After migrating to REST, the 
 JiraDownloader/ClassicDownloader/RestJiraDownloader does not support this 
 filter.
 Can you reintroduce support for custom filter?



--
This message was sent by Atlassian JIRA
(v6.1.6#6162)


[jira] (MCHANGES-308) Support filters when using REST API / JQL

2014-07-09 Thread Bruno Marti (JIRA)

 [ 
https://jira.codehaus.org/browse/MCHANGES-308?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Bruno Marti updated MCHANGES-308:
-

Comment: was deleted

(was: current patch does not honor maven variables.
this *works*:
  {code}filterlabels=my-custom-label/filter{code}
this *doesn't work*:
  {code}filterlabels=${project_specification_title}/filter{code})

 Support filters when using REST API / JQL
 -

 Key: MCHANGES-308
 URL: https://jira.codehaus.org/browse/MCHANGES-308
 Project: Maven Changes Plugin
  Issue Type: Wish
  Components: jira
Affects Versions: 2.8, 2.9
Reporter: Johannes Odland
 Attachments: 
 MCHANGES-308__Support_filters_when_using_REST_API___JQL.patch


 The original JiraDownloader supported a custom filter for downloading issues.
 After migrating to REST, the 
 JiraDownloader/ClassicDownloader/RestJiraDownloader does not support this 
 filter.
 Can you reintroduce support for custom filter?



--
This message was sent by Atlassian JIRA
(v6.1.6#6162)


[jira] (MNG-5662) org.apache.maven.profiles.activation.JdkPrefixProfileActivator misuses String.replaceAll

2014-07-09 Thread JIRA
Gábor Lipták created MNG-5662:
-

 Summary: 
org.apache.maven.profiles.activation.JdkPrefixProfileActivator misuses 
String.replaceAll
 Key: MNG-5662
 URL: https://jira.codehaus.org/browse/MNG-5662
 Project: Maven
  Issue Type: Improvement
  Components: Profiles
Reporter: Gábor Lipták
Priority: Minor


Instead of this:
{code:java}
private String convertJdkToMavenVersion( String jdk )
{
return jdk.replaceAll( _, - );
}
{code}

It should look like this:
{code:java}
private String convertJdkToMavenVersion( String jdk )
{
return jdk.replace( '_', '-' );
}

This would save the CPU from recompiling a regex in vain. Could make a 
performance improvement for projects using that profile activator massively.



--
This message was sent by Atlassian JIRA
(v6.1.6#6162)


[jira] (MNG-5662) org.apache.maven.profiles.activation.JdkPrefixProfileActivator misuses String.replaceAll

2014-07-09 Thread JIRA

 [ 
https://jira.codehaus.org/browse/MNG-5662?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gábor Lipták updated MNG-5662:
--

Complexity: Novice  (was: Intermediate)

 org.apache.maven.profiles.activation.JdkPrefixProfileActivator misuses 
 String.replaceAll
 

 Key: MNG-5662
 URL: https://jira.codehaus.org/browse/MNG-5662
 Project: Maven
  Issue Type: Improvement
  Components: Profiles
Reporter: Gábor Lipták
Priority: Minor

 Instead of this:
 {code:java}
 private String convertJdkToMavenVersion( String jdk )
 {
 return jdk.replaceAll( _, - );
 }
 {code}
 It should look like this:
 {code:java}
 private String convertJdkToMavenVersion( String jdk )
 {
 return jdk.replace( '_', '-' );
 }
 This would save the CPU from recompiling a regex in vain. Could make a 
 performance improvement for projects using that profile activator massively.



--
This message was sent by Atlassian JIRA
(v6.1.6#6162)


[jira] (MNG-5662) org.apache.maven.profiles.activation.JdkPrefixProfileActivator misuses String.replaceAll

2014-07-09 Thread JIRA

 [ 
https://jira.codehaus.org/browse/MNG-5662?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gábor Lipták updated MNG-5662:
--

Description: 
Instead of this:
{code:java}
private String convertJdkToMavenVersion( String jdk )
{
return jdk.replaceAll( _, - );
}
{code}

It should look like this:
{code:java}
private String convertJdkToMavenVersion( String jdk )
{
return jdk.replace( '_', '-' );
}
{code}

This would save the CPU from recompiling a regex in vain. Could make a 
performance improvement for projects using that profile activator massively.

  was:
Instead of this:
{code:java}
private String convertJdkToMavenVersion( String jdk )
{
return jdk.replaceAll( _, - );
}
{code}

It should look like this:
{code:java}
private String convertJdkToMavenVersion( String jdk )
{
return jdk.replace( '_', '-' );
}

This would save the CPU from recompiling a regex in vain. Could make a 
performance improvement for projects using that profile activator massively.


 org.apache.maven.profiles.activation.JdkPrefixProfileActivator misuses 
 String.replaceAll
 

 Key: MNG-5662
 URL: https://jira.codehaus.org/browse/MNG-5662
 Project: Maven
  Issue Type: Improvement
  Components: Profiles
Reporter: Gábor Lipták
Priority: Minor

 Instead of this:
 {code:java}
 private String convertJdkToMavenVersion( String jdk )
 {
 return jdk.replaceAll( _, - );
 }
 {code}
 It should look like this:
 {code:java}
 private String convertJdkToMavenVersion( String jdk )
 {
 return jdk.replace( '_', '-' );
 }
 {code}
 This would save the CPU from recompiling a regex in vain. Could make a 
 performance improvement for projects using that profile activator massively.



--
This message was sent by Atlassian JIRA
(v6.1.6#6162)


[jira] (MDEPLOY-184) Sources and Javadoc are not added when deploying

2014-07-09 Thread David Hladky (JIRA)
David Hladky created MDEPLOY-184:


 Summary: Sources and Javadoc are not added when deploying
 Key: MDEPLOY-184
 URL: https://jira.codehaus.org/browse/MDEPLOY-184
 Project: Maven Deploy Plugin
  Issue Type: Bug
  Components: deploy:deploy-file
Affects Versions: 2.8.1
 Environment: Apache Maven 3.1.1 
(NON-CANONICAL_2013-11-08_14-32_mockbuild; 2013-11-08 15:32:41+0100)

Fedora 20

Reporter: David Hladky


Based on the documentation adding -Dsources=somefile and -Djavadoc=somefile the 
files should be added to the target reposiotry based on the documentation. 
While deploy:deploy deploys the sources and javadoc properly, deploy-file 
ignores the sources. 

Someone complained about this problem here as well: 
http://stackoverflow.com/questions/7487130/deploying-an-artifact-its-sources-and-javadoc-using-mavens-deploydeploy-file



--
This message was sent by Atlassian JIRA
(v6.1.6#6162)


[jira] (MJAVADOC-398) Classes from build output directory can cause failure

2014-07-09 Thread Michael Osipov (JIRA)

[ 
https://jira.codehaus.org/browse/MJAVADOC-398?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=349380#comment-349380
 ] 

Michael Osipov commented on MJAVADOC-398:
-

Michal, I am about to commit your change. One more thing, where is the point of 
including the built class files to the classpath of javadoc if you already 
provide the sources anyway?

 Classes from build output directory can cause failure
 -

 Key: MJAVADOC-398
 URL: https://jira.codehaus.org/browse/MJAVADOC-398
 Project: Maven Javadoc Plugin
  Issue Type: Bug
Affects Versions: 2.9.1
Reporter: Michal Srb

 maven-javadoc-plugin adds compiled classes from build output directory to 
 javadoc's classpath. There are certain cases when this can lead to either 
 incorrect serialized-form.html page or failure (in case of jdk8). See [1] for 
 more details. I think that having classes from build output directory on 
 javadoc's classpath is not necessary. It may cause only problems and user can 
 call javadoc:javadoc before actual build anyway.
 [1]: https://bugzilla.redhat.com/show_bug.cgi?id=1113877



--
This message was sent by Atlassian JIRA
(v6.1.6#6162)


[jira] (MJAVADOC-398) Classes from build output directory can cause failure

2014-07-09 Thread Michael Osipov (JIRA)

 [ 
https://jira.codehaus.org/browse/MJAVADOC-398?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Michael Osipov reassigned MJAVADOC-398:
---

Assignee: Michael Osipov

 Classes from build output directory can cause failure
 -

 Key: MJAVADOC-398
 URL: https://jira.codehaus.org/browse/MJAVADOC-398
 Project: Maven Javadoc Plugin
  Issue Type: Bug
Affects Versions: 2.9.1
Reporter: Michal Srb
Assignee: Michael Osipov

 maven-javadoc-plugin adds compiled classes from build output directory to 
 javadoc's classpath. There are certain cases when this can lead to either 
 incorrect serialized-form.html page or failure (in case of jdk8). See [1] for 
 more details. I think that having classes from build output directory on 
 javadoc's classpath is not necessary. It may cause only problems and user can 
 call javadoc:javadoc before actual build anyway.
 [1]: https://bugzilla.redhat.com/show_bug.cgi?id=1113877



--
This message was sent by Atlassian JIRA
(v6.1.6#6162)


[jira] (MJAVADOC-344) -Dfooter doesn't set the Javadoc footer.

2014-07-09 Thread Michael Osipov (JIRA)

[ 
https://jira.codehaus.org/browse/MJAVADOC-344?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=349382#comment-349382
 ] 

Michael Osipov commented on MJAVADOC-344:
-

Where is the difference to bottom? Isn't is the same?

 -Dfooter doesn't set the Javadoc footer.
 

 Key: MJAVADOC-344
 URL: https://jira.codehaus.org/browse/MJAVADOC-344
 Project: Maven Javadoc Plugin
  Issue Type: Bug
Reporter: Ondrej Zizka
 Fix For: 2.9.2


 This 
 http://maven.apache.org/plugins/maven-javadoc-plugin/javadoc-mojo.html#footer
 says that the footer property has expression {code}$\{footer}{code}.
 However, if I try
 {code}
 mvn javadoc:aggregate -PjavadocDist -Ddoctitle='FOO' -Dfooter='BAR'
 {code}
 I get 
 {code}
 -doctitle
 'FOO'
 -footer
 'bTest project: Build 1.0-SNAPSHOT/b'
 {code}
 Setting {{footer}} in pom.xml works.



--
This message was sent by Atlassian JIRA
(v6.1.6#6162)


[jira] (MJAVADOC-398) Classes from build output directory can cause failure

2014-07-09 Thread Michael Osipov (JIRA)

 [ 
https://jira.codehaus.org/browse/MJAVADOC-398?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Michael Osipov updated MJAVADOC-398:


Fix Version/s: 2.9.2

 Classes from build output directory can cause failure
 -

 Key: MJAVADOC-398
 URL: https://jira.codehaus.org/browse/MJAVADOC-398
 Project: Maven Javadoc Plugin
  Issue Type: Bug
Affects Versions: 2.9.1
Reporter: Michal Srb
Assignee: Michael Osipov
 Fix For: 2.9.2


 maven-javadoc-plugin adds compiled classes from build output directory to 
 javadoc's classpath. There are certain cases when this can lead to either 
 incorrect serialized-form.html page or failure (in case of jdk8). See [1] for 
 more details. I think that having classes from build output directory on 
 javadoc's classpath is not necessary. It may cause only problems and user can 
 call javadoc:javadoc before actual build anyway.
 [1]: https://bugzilla.redhat.com/show_bug.cgi?id=1113877



--
This message was sent by Atlassian JIRA
(v6.1.6#6162)


[jira] (MJAVADOC-393) -link option values have their trailing slash removed; breaks javadoc 8

2014-07-09 Thread Michael Osipov (JIRA)

[ 
https://jira.codehaus.org/browse/MJAVADOC-393?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=349381#comment-349381
 ] 

Michael Osipov commented on MJAVADOC-393:
-

I would rather close as wontfix.

 -link option values have their trailing slash removed; breaks javadoc 8
 ---

 Key: MJAVADOC-393
 URL: https://jira.codehaus.org/browse/MJAVADOC-393
 Project: Maven Javadoc Plugin
  Issue Type: Bug
Affects Versions: 2.9.1
Reporter: Laird Nelson
 Fix For: 2.9.2

 Attachments: AbstractJavadocMojo.java.MJAVADOC-393.patch


 The version of {{javadoc}} that ships with Java 8 has changed such that any 
 value supplied to the {{-link}} option must have a trailing slash (at least 
 on my Mac).
 Line 2932 of {{AbstractJavadocMojo.java}} programmatically strips the 
 trailing slashes from the {{links}} property elements, ensuring that 
 {{javadoc}} version 8 cannot process its {{-link}} options properly.



--
This message was sent by Atlassian JIRA
(v6.1.6#6162)


[jira] (MJAVADOC-398) Classes from build output directory can cause failure

2014-07-09 Thread Michael Osipov (JIRA)

 [ 
https://jira.codehaus.org/browse/MJAVADOC-398?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Michael Osipov closed MJAVADOC-398.
---

Resolution: Fixed

Fixed with r1609274.

 Classes from build output directory can cause failure
 -

 Key: MJAVADOC-398
 URL: https://jira.codehaus.org/browse/MJAVADOC-398
 Project: Maven Javadoc Plugin
  Issue Type: Bug
Affects Versions: 2.9.1
Reporter: Michal Srb
Assignee: Michael Osipov
 Fix For: 2.9.2


 maven-javadoc-plugin adds compiled classes from build output directory to 
 javadoc's classpath. There are certain cases when this can lead to either 
 incorrect serialized-form.html page or failure (in case of jdk8). See [1] for 
 more details. I think that having classes from build output directory on 
 javadoc's classpath is not necessary. It may cause only problems and user can 
 call javadoc:javadoc before actual build anyway.
 [1]: https://bugzilla.redhat.com/show_bug.cgi?id=1113877



--
This message was sent by Atlassian JIRA
(v6.1.6#6162)


[jira] (MDEPLOY-184) Sources and Javadoc are not added when deploying

2014-07-09 Thread Robert Scholte (JIRA)

 [ 
https://jira.codehaus.org/browse/MDEPLOY-184?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Robert Scholte closed MDEPLOY-184.
--

Resolution: Cannot Reproduce
  Assignee: Robert Scholte

I've created an integration-test( [rev.r1609268|http://svn.apache.org/r1609268] 
) matching the [Deploy sources and javadoc 
jars|http://maven.apache.org/plugins/maven-deploy-plugin/examples/deploying-sources-javadoc.html]-page
 and it works fine.

 Sources and Javadoc are not added when deploying
 

 Key: MDEPLOY-184
 URL: https://jira.codehaus.org/browse/MDEPLOY-184
 Project: Maven Deploy Plugin
  Issue Type: Bug
  Components: deploy:deploy-file
Affects Versions: 2.8.1
 Environment: Apache Maven 3.1.1 
 (NON-CANONICAL_2013-11-08_14-32_mockbuild; 2013-11-08 15:32:41+0100)
 Fedora 20
Reporter: David Hladky
Assignee: Robert Scholte

 Based on the documentation adding -Dsources=somefile and -Djavadoc=somefile 
 the files should be added to the target reposiotry based on the 
 documentation. While deploy:deploy deploys the sources and javadoc properly, 
 deploy-file ignores the sources. 
 Someone complained about this problem here as well: 
 http://stackoverflow.com/questions/7487130/deploying-an-artifact-its-sources-and-javadoc-using-mavens-deploydeploy-file



--
This message was sent by Atlassian JIRA
(v6.1.6#6162)


[jira] (MCHECKSTYLE-236) add Rule name to violation message

2014-07-09 Thread Michael Osipov (JIRA)

 [ 
https://jira.codehaus.org/browse/MCHECKSTYLE-236?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Michael Osipov updated MCHECKSTYLE-236:
---

Fix Version/s: 2.13

 add Rule name to violation message
 --

 Key: MCHECKSTYLE-236
 URL: https://jira.codehaus.org/browse/MCHECKSTYLE-236
 Project: Maven Checkstyle Plugin
  Issue Type: Improvement
Affects Versions: 2.12.1
Reporter: Herve Boutemy
Assignee: Herve Boutemy
 Fix For: 2.13


 having only the violation message without the rule name makes difficult to 
 match rules summary with file details



--
This message was sent by Atlassian JIRA
(v6.1.6#6162)


[jira] (MCHECKSTYLE-236) add Rule name to violation message

2014-07-09 Thread Michael Osipov (JIRA)

 [ 
https://jira.codehaus.org/browse/MCHECKSTYLE-236?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Michael Osipov updated MCHECKSTYLE-236:
---

Assignee: Herve Boutemy

 add Rule name to violation message
 --

 Key: MCHECKSTYLE-236
 URL: https://jira.codehaus.org/browse/MCHECKSTYLE-236
 Project: Maven Checkstyle Plugin
  Issue Type: Improvement
Affects Versions: 2.12.1
Reporter: Herve Boutemy
Assignee: Herve Boutemy
 Fix For: 2.13


 having only the violation message without the rule name makes difficult to 
 match rules summary with file details



--
This message was sent by Atlassian JIRA
(v6.1.6#6162)


[jira] (MCHECKSTYLE-236) add Rule name to violation message

2014-07-09 Thread Michael Osipov (JIRA)

 [ 
https://jira.codehaus.org/browse/MCHECKSTYLE-236?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Michael Osipov closed MCHECKSTYLE-236.
--

Resolution: Fixed

Fixed with r1608114.

 add Rule name to violation message
 --

 Key: MCHECKSTYLE-236
 URL: https://jira.codehaus.org/browse/MCHECKSTYLE-236
 Project: Maven Checkstyle Plugin
  Issue Type: Improvement
Affects Versions: 2.12.1
Reporter: Herve Boutemy
Assignee: Herve Boutemy
 Fix For: 2.13


 having only the violation message without the rule name makes difficult to 
 match rules summary with file details



--
This message was sent by Atlassian JIRA
(v6.1.6#6162)


[jira] (MCHECKSTYLE-237) Changeset 1608113 introduces Line 0 regression

2014-07-09 Thread Michael Osipov (JIRA)

 [ 
https://jira.codehaus.org/browse/MCHECKSTYLE-237?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Michael Osipov updated MCHECKSTYLE-237:
---

Fix Version/s: 2.13

 Changeset 1608113 introduces Line 0 regression
 

 Key: MCHECKSTYLE-237
 URL: https://jira.codehaus.org/browse/MCHECKSTYLE-237
 Project: Maven Checkstyle Plugin
  Issue Type: Bug
Affects Versions: 2.13
Reporter: Michael Osipov
Assignee: Michael Osipov
 Fix For: 2.13


 c1608113 introduced this:
 {code}
 -int line = event.getLine();
  if ( getXrefLocation() != null )
  {
 -sink
 -.link(
 -getXrefLocation() + / + filename.replaceAll( 
 \\.java$, .html ) + #L + line );
 +sink.link( getXrefLocation() + / + filename.replaceAll( 
 \\.java$, .html ) + #L
 ++ event.getLine() );
 +sink.text( String.valueOf( event.getLine() ) );
 +sink.link_();
  }
 -if ( line != 0 )
 +else
  {
  sink.text( String.valueOf( event.getLine() ) );
  }
 -if ( getXrefLocation() != null )
 -{
 -sink.link_();
 -}
 {code}
 I have intentionally added {{if ( line != 0 )}} to avoid useless Line 0 
 links. Moreover, {{int line}} avoids repetitive calls to {{event.getLine()}}.
 That improvement should remain.



--
This message was sent by Atlassian JIRA
(v6.1.6#6162)


[jira] (MEAR-183) Extra 'temp' directory created in wrong place

2014-07-09 Thread Karl-Heinz Marbaise (JIRA)

 [ 
https://jira.codehaus.org/browse/MEAR-183?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Karl-Heinz Marbaise closed MEAR-183.


Resolution: Fixed
  Assignee: Karl-Heinz Marbaise

Fixed in [r1609286|http://svn.apache.org/r1609286].

 Extra 'temp' directory created in wrong place
 -

 Key: MEAR-183
 URL: https://jira.codehaus.org/browse/MEAR-183
 Project: Maven Ear Plugin
  Issue Type: Bug
Affects Versions: 2.8
Reporter: Peter Gabriel
Assignee: Karl-Heinz Marbaise
 Fix For: 2.10

 Attachments: DIR.png, pom.xml


 When
  generatedDescriptorLocationDIR/generatedDescriptorLocation
 is used during maven phase PACKAGE 'temp' dir is created under this dir with 
 fully compiled modules (ear, war)



--
This message was sent by Atlassian JIRA
(v6.1.6#6162)


[jira] (MCHECKSTYLE-237) Changeset 1608113 introduces Line 0 regression

2014-07-09 Thread Michael Osipov (JIRA)

 [ 
https://jira.codehaus.org/browse/MCHECKSTYLE-237?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Michael Osipov reassigned MCHECKSTYLE-237:
--

Assignee: Michael Osipov

 Changeset 1608113 introduces Line 0 regression
 

 Key: MCHECKSTYLE-237
 URL: https://jira.codehaus.org/browse/MCHECKSTYLE-237
 Project: Maven Checkstyle Plugin
  Issue Type: Bug
Affects Versions: 2.13
Reporter: Michael Osipov
Assignee: Michael Osipov
 Fix For: 2.13


 c1608113 introduced this:
 {code}
 -int line = event.getLine();
  if ( getXrefLocation() != null )
  {
 -sink
 -.link(
 -getXrefLocation() + / + filename.replaceAll( 
 \\.java$, .html ) + #L + line );
 +sink.link( getXrefLocation() + / + filename.replaceAll( 
 \\.java$, .html ) + #L
 ++ event.getLine() );
 +sink.text( String.valueOf( event.getLine() ) );
 +sink.link_();
  }
 -if ( line != 0 )
 +else
  {
  sink.text( String.valueOf( event.getLine() ) );
  }
 -if ( getXrefLocation() != null )
 -{
 -sink.link_();
 -}
 {code}
 I have intentionally added {{if ( line != 0 )}} to avoid useless Line 0 
 links. Moreover, {{int line}} avoids repetitive calls to {{event.getLine()}}.
 That improvement should remain.



--
This message was sent by Atlassian JIRA
(v6.1.6#6162)


[jira] (MCHECKSTYLE-237) Changeset 1608113 introduces Line 0 regression

2014-07-09 Thread Michael Osipov (JIRA)

 [ 
https://jira.codehaus.org/browse/MCHECKSTYLE-237?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Michael Osipov closed MCHECKSTYLE-237.
--

Resolution: Fixed

Fixed with r1609288.

 Changeset 1608113 introduces Line 0 regression
 

 Key: MCHECKSTYLE-237
 URL: https://jira.codehaus.org/browse/MCHECKSTYLE-237
 Project: Maven Checkstyle Plugin
  Issue Type: Bug
Affects Versions: 2.13
Reporter: Michael Osipov
Assignee: Michael Osipov
 Fix For: 2.13


 c1608113 introduced this:
 {code}
 -int line = event.getLine();
  if ( getXrefLocation() != null )
  {
 -sink
 -.link(
 -getXrefLocation() + / + filename.replaceAll( 
 \\.java$, .html ) + #L + line );
 +sink.link( getXrefLocation() + / + filename.replaceAll( 
 \\.java$, .html ) + #L
 ++ event.getLine() );
 +sink.text( String.valueOf( event.getLine() ) );
 +sink.link_();
  }
 -if ( line != 0 )
 +else
  {
  sink.text( String.valueOf( event.getLine() ) );
  }
 -if ( getXrefLocation() != null )
 -{
 -sink.link_();
 -}
 {code}
 I have intentionally added {{if ( line != 0 )}} to avoid useless Line 0 
 links. Moreover, {{int line}} avoids repetitive calls to {{event.getLine()}}.
 That improvement should remain.



--
This message was sent by Atlassian JIRA
(v6.1.6#6162)


[jira] (MCHECKSTYLE-217) Add parameter which skips rule rows which do not have any violations

2014-07-09 Thread Michael Osipov (JIRA)

 [ 
https://jira.codehaus.org/browse/MCHECKSTYLE-217?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Michael Osipov reassigned MCHECKSTYLE-217:
--

Assignee: Michael Osipov

 Add parameter which skips rule rows which do not have any violations
 

 Key: MCHECKSTYLE-217
 URL: https://jira.codehaus.org/browse/MCHECKSTYLE-217
 Project: Maven Checkstyle Plugin
  Issue Type: Improvement
Affects Versions: 2.11
Reporter: Michael Osipov
Assignee: Michael Osipov
 Fix For: 2.13


 The rules report shows all available rules even if they do not have any 
 violations. For the sake of conciseness, we should add a parameter (e.g. 
 {{skipEmptyViolationRules}}) we omits them from output.



--
This message was sent by Atlassian JIRA
(v6.1.6#6162)


[jira] (MCHECKSTYLE-217) Add parameter which skips rule rows which do not have any violations

2014-07-09 Thread Michael Osipov (JIRA)

 [ 
https://jira.codehaus.org/browse/MCHECKSTYLE-217?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Michael Osipov updated MCHECKSTYLE-217:
---

Fix Version/s: 2.13

 Add parameter which skips rule rows which do not have any violations
 

 Key: MCHECKSTYLE-217
 URL: https://jira.codehaus.org/browse/MCHECKSTYLE-217
 Project: Maven Checkstyle Plugin
  Issue Type: Improvement
Affects Versions: 2.11
Reporter: Michael Osipov
Assignee: Michael Osipov
 Fix For: 2.13


 The rules report shows all available rules even if they do not have any 
 violations. For the sake of conciseness, we should add a parameter (e.g. 
 {{skipEmptyViolationRules}}) we omits them from output.



--
This message was sent by Atlassian JIRA
(v6.1.6#6162)


[jira] (MCHECKSTYLE-217) Add parameter which skips rule rows which do not have any violations

2014-07-09 Thread Michael Osipov (JIRA)

 [ 
https://jira.codehaus.org/browse/MCHECKSTYLE-217?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Michael Osipov closed MCHECKSTYLE-217.
--

Resolution: Fixed

Fixed with r1609305. Parameter has not been introduced but alle rules w/o 
violations have been omitted. This is the default approach will als checker 
reports like PMD or FindBugs.

 Add parameter which skips rule rows which do not have any violations
 

 Key: MCHECKSTYLE-217
 URL: https://jira.codehaus.org/browse/MCHECKSTYLE-217
 Project: Maven Checkstyle Plugin
  Issue Type: Improvement
Affects Versions: 2.11
Reporter: Michael Osipov
Assignee: Michael Osipov
 Fix For: 2.13


 The rules report shows all available rules even if they do not have any 
 violations. For the sake of conciseness, we should add a parameter (e.g. 
 {{skipEmptyViolationRules}}) we omits them from output.



--
This message was sent by Atlassian JIRA
(v6.1.6#6162)


[jira] (MCHECKSTYLE-235) improve difference between rules with and without violations

2014-07-09 Thread Michael Osipov (JIRA)

[ 
https://jira.codehaus.org/browse/MCHECKSTYLE-235?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=349397#comment-349397
 ] 

Michael Osipov commented on MCHECKSTYLE-235:


Done, output has been skimmed.

 improve difference between rules with and without violations
 

 Key: MCHECKSTYLE-235
 URL: https://jira.codehaus.org/browse/MCHECKSTYLE-235
 Project: Maven Checkstyle Plugin
  Issue Type: Improvement
Affects Versions: 2.12.1
Reporter: Herve Boutemy
Assignee: Herve Boutemy
 Fix For: 2.13

 Attachments: MCHECKSTYLE-235.png


 rules with violations should be more easily seen



--
This message was sent by Atlassian JIRA
(v6.1.6#6162)


[jira] (MCHECKSTYLE-138) Checkstyle plugin is @threadSafe if checkstyle itself is threadsafe

2014-07-09 Thread Michael Osipov (JIRA)

 [ 
https://jira.codehaus.org/browse/MCHECKSTYLE-138?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Michael Osipov updated MCHECKSTYLE-138:
---

Fix Version/s: (was: 2.13)

 Checkstyle plugin is @threadSafe if checkstyle itself is threadsafe
 ---

 Key: MCHECKSTYLE-138
 URL: https://jira.codehaus.org/browse/MCHECKSTYLE-138
 Project: Maven Checkstyle Plugin
  Issue Type: Improvement
Affects Versions: 2.12.1
Reporter: Kristian Rosenvold

 The checkstyle plugin can be marked as threadSafe if checkstyle itself can be 
 verified to be thread safe.
 Someone should ask the checkstyle community if this is the case.



--
This message was sent by Atlassian JIRA
(v6.1.6#6162)


[jira] (MCHECKSTYLE-138) Checkstyle plugin is @threadSafe if checkstyle itself is threadsafe

2014-07-09 Thread Michael Osipov (JIRA)

 [ 
https://jira.codehaus.org/browse/MCHECKSTYLE-138?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Michael Osipov updated MCHECKSTYLE-138:
---

Affects Version/s: 2.12.1

 Checkstyle plugin is @threadSafe if checkstyle itself is threadsafe
 ---

 Key: MCHECKSTYLE-138
 URL: https://jira.codehaus.org/browse/MCHECKSTYLE-138
 Project: Maven Checkstyle Plugin
  Issue Type: Improvement
Affects Versions: 2.12.1
Reporter: Kristian Rosenvold

 The checkstyle plugin can be marked as threadSafe if checkstyle itself can be 
 verified to be thread safe.
 Someone should ask the checkstyle community if this is the case.



--
This message was sent by Atlassian JIRA
(v6.1.6#6162)


[jira] (MCHECKSTYLE-138) Checkstyle plugin is @threadSafe if checkstyle itself is threadsafe

2014-07-09 Thread Michael Osipov (JIRA)

[ 
https://jira.codehaus.org/browse/MCHECKSTYLE-138?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=349398#comment-349398
 ] 

Michael Osipov commented on MCHECKSTYLE-138:


Removed the fix version because we cannot do anything about it but wait for a 
working checkstyle version.

 Checkstyle plugin is @threadSafe if checkstyle itself is threadsafe
 ---

 Key: MCHECKSTYLE-138
 URL: https://jira.codehaus.org/browse/MCHECKSTYLE-138
 Project: Maven Checkstyle Plugin
  Issue Type: Improvement
Affects Versions: 2.12.1
Reporter: Kristian Rosenvold

 The checkstyle plugin can be marked as threadSafe if checkstyle itself can be 
 verified to be thread safe.
 Someone should ask the checkstyle community if this is the case.



--
This message was sent by Atlassian JIRA
(v6.1.6#6162)


[jira] (MDEP-398) Dependency resolution error with Maven 3

2014-07-09 Thread Richard Vowles (JIRA)

[ 
https://jira.codehaus.org/browse/MDEP-398?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=349406#comment-349406
 ] 

Richard Vowles commented on MDEP-398:
-

this issue can close.

 Dependency resolution error with Maven 3 
 -

 Key: MDEP-398
 URL: https://jira.codehaus.org/browse/MDEP-398
 Project: Maven Dependency Plugin
  Issue Type: Bug
 Environment: Maven 3.0.4, Mac OS X 10.8 and Windows 7
Reporter: Richard Vowles
 Attachments: m3-dep2.1-tree-success.pom, m3-dep2.1-tree-success.txt, 
 m3-dep2.6-failed.pom, m3-dep2.6-failed.txt, m3-dep2.6-success.pom, 
 m3-dep2.6-success.txt


 We are encountering an issue with Maven 3 dependency resolution (aether) that 
 does not occur with Maven 2. We need to get this issue resolved so we can use 
 the resolved pom for patch releases. 
 I have attempted to drop the pom.xml size down, but cannot do so too far 
 without the complex dependencies failing, I have spent many hours getting it 
 this small. If there is a member of the Maven team who is able to solve this 
 kind of problem, we can supply access to our Nexus to duplicate the problem. 
 If there is any assistance on turning the log level of Aether up so we could 
 see what it is doing, that would also be appreciated.
 For this particular problem - at least two dependencies that should be there 
 are missing. Excluding the transitive dependencies on one of the dependencies 
 makes them come back, but that is not what should happen - exclusions change 
 versions or remove dependencies - they don't add them.
 We are encountering problems where dependencies that are not there get added, 
 things that should be there disappear and scopes (test - compile) and 
 versions change. 
 Attached are the three scenarios. 
 (1) Maven 3 - Dependency Plugin 2.6 - dep:list - Failure (2 x aspectj is not 
 included)
 (2) Maven 3 - Dep 2.6 - dep:list - Success (2 x aspectj are included - pom is 
 changed to exclude transitive dependencies from one dependency)
 (3) Maven 3 - Dep 2.1 - dep:tree - Success (2 x aspectj are included - pom 
 does not need exclusions to make it work, it behaves as expected).
 Maven is run with -o -e -X 



--
This message was sent by Atlassian JIRA
(v6.1.6#6162)


[jira] (MJAVADOC-398) Classes from build output directory can cause failure

2014-07-09 Thread Michal Srb (JIRA)

[ 
https://jira.codehaus.org/browse/MJAVADOC-398?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=349412#comment-349412
 ] 

Michal Srb commented on MJAVADOC-398:
-

Thanks!

 Classes from build output directory can cause failure
 -

 Key: MJAVADOC-398
 URL: https://jira.codehaus.org/browse/MJAVADOC-398
 Project: Maven Javadoc Plugin
  Issue Type: Bug
Affects Versions: 2.9.1
Reporter: Michal Srb
Assignee: Michael Osipov
 Fix For: 2.9.2


 maven-javadoc-plugin adds compiled classes from build output directory to 
 javadoc's classpath. There are certain cases when this can lead to either 
 incorrect serialized-form.html page or failure (in case of jdk8). See [1] for 
 more details. I think that having classes from build output directory on 
 javadoc's classpath is not necessary. It may cause only problems and user can 
 call javadoc:javadoc before actual build anyway.
 [1]: https://bugzilla.redhat.com/show_bug.cgi?id=1113877



--
This message was sent by Atlassian JIRA
(v6.1.6#6162)