[jira] Commented: (MNG-2173) support in plugins
[ http://jira.codehaus.org/browse/MNG-2173?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=138307#action_138307 ] Pavel Muller commented on MNG-2173: --- I use the following approach and it works fine: cz.aspectworks cz.aspectworks.build 0.2.0 [SNIP] I've got my PMD and checkstyle config files on classpath. > support in plugins > - > > Key: MNG-2173 > URL: http://jira.codehaus.org/browse/MNG-2173 > Project: Maven 2 > Issue Type: Bug > Components: Plugins and Lifecycle >Reporter: John Allen >Assignee: Brett Porter > > Inconsistency with rest of design. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MPMD-22) PMD plugin should accept dependency entries
[
http://jira.codehaus.org/browse/MPMD-22?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=138308#action_138308
]
Pavel Muller commented on MPMD-22:
--
I use the following approach and it works fine:
cz.aspectworks
cz.aspectworks.build
0.2.0
[SNIP]
I've got my PMD and checkstyle config files on classpath.
> PMD plugin should accept dependency entries
> ---
>
> Key: MPMD-22
> URL: http://jira.codehaus.org/browse/MPMD-22
> Project: Maven 2.x PMD Plugin
> Issue Type: New Feature
>Reporter: Subhash Chandran
>
> As described here:
> http://maven.apache.org/plugins/maven-pmd-plugin/howto.html
> The PMD plugin supports configuration of custom ruleset XML files. But in our
> organization, we have written custom ruleset XMLs that refer Java classes
> (our PMD extension dependencies). The configuration of the PMD plugin should
> allow these dependencies to be specified.
> Since we do not have this feature in the current release, we at our
> organization are forced to maintain a fork of the PMD plugin with the
> necessary dependencies added.
> A suggested format:
>
>
> /rulesets/basic.xml
> /rulesets/controversial.xml
> d:\rulesets\strings.xml
> http://localhost/design.xml
>
> {color:red}
>
> junit
> junit
> 4.0
> test
>
> {color}
> xml
> true
> utf-8
> 100
>
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-2971) Variables are not replaced into installed pom file
[
http://jira.codehaus.org/browse/MNG-2971?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_125431
]
Pavel Muller commented on MNG-2971:
---
So, what is a best practice? I've got the same problem. Managing versions in a
large multi-module project is really time consuming. I'd like to have just one
place to change the version and not to change all poms in my project to modify
parent links.
> Variables are not replaced into installed pom file
> --
>
> Key: MNG-2971
> URL: http://jira.codehaus.org/browse/MNG-2971
> Project: Maven 2
> Issue Type: Bug
> Components: Deployment, Inheritance and Interpolation
> Environment: Windows, Solaris
> Maven version 2.0.4
>Reporter: Laurent Dauvilaire
> Fix For: 2.0.x
>
>
> Variables are not replaced into installed pom file.
> Here is a sample pom file
> http://maven.apache.org/POM/4.0.0";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
> xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
> http://maven.apache.org/maven-v4_0_0.xsd";>
> 4.0.0
> com.xxx.root
> root
> pom
> ${prop.version}
> My Project
> ...
>
> 3.0.20
>
>
> The installed pom is into
> ${localRepository}/com/xxx/root/root/3.0.20/root-3.0.20.pom
> is the same as the project pom file but the version referenced into the
> installed pom file is ${prop.version} instead of 3.0.20
> which creates problem to artifacts depending of this one.
> 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] Commented: (MRELEASE-322) Unable to set the working directory for projects where the master pom isn't at the root of the project
[
http://jira.codehaus.org/browse/MRELEASE-322?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_125568
]
Pavel Muller commented on MRELEASE-322:
---
I've got the same problem. Real blocker for our project.
> Unable to set the working directory for projects where the master pom isn't
> at the root of the project
> --
>
> Key: MRELEASE-322
> URL: http://jira.codehaus.org/browse/MRELEASE-322
> Project: Maven 2.x Release Plugin
> Issue Type: Bug
> Components: scm
>Affects Versions: 2.0-beta-7
>Reporter: Christian Nelson
>Priority: Blocker
>
> Branches and Tags are created from the current working directory, which isn't
> always correct and there isn't a way to override the working directory.
> For example, we have the following directory structure:
> ${root}/master/pom.xml - The modules section include relative paths to
> modules a, b, and c.
> ${root}/module-a/pom.xml
> ${root}/module-b/pom.xml
> ${root}/module-c/pom.xml
> All subversion copies (via branch or prepare) originate from ${root}/master.
> As a result, they are incomplete; we really want to create copies from
> ${root} not ${root}/master. Here's the subversion command that I think is
> the problem:
> {noformat}
> [INFO] Working directory: C:\devsys\repos\trunk\master
> [INFO] Branching release with the label release-1.0...
> [INFO] Executing: svn --non-interactive copy --file
> C:\Users\cnelson\AppData\Local\Temp\maven-scm-1179760787.commit .
> http://hostname/svn/dev/branches/release-1.0
> {noformat}
> The period after the filename is what's indicating to subversion to create
> the copy from master instead of ${root}. Note: the working directory is
> derived from the basedir and I couldn't find a way to override the basedir.
> While not having the master pom at the root of the project may be a little
> uncommon, it doesn't seem unreasonable. Can we add a configuration option to
> handle these cases?
--
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
