[jira] (MENFORCER-159) Add goal recommend which will only warn but never fail a build
[
https://jira.codehaus.org/browse/MENFORCER-159?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Heinz Marbaise updated MENFORCER-159:
--
Fix Version/s: (was: 1.4)
> Add goal recommend which will only warn but never fail a build
> --
>
> Key: MENFORCER-159
> URL: https://jira.codehaus.org/browse/MENFORCER-159
> Project: Maven Enforcer Plugin
> Issue Type: New Feature
> Components: Plugin
>Affects Versions: 1.3
>Reporter: Mirko Friedenhagen
>Assignee: Robert Scholte
> Attachments: recommend-mojo.patch
>
>
> In our company's parent POM we define a lot of rules, some of which are
> controversial or may not be easily fulfilled. The patch I attach defines a
> new goal "recommend" which will always warn but never fail. It's
> configuration is done by a new element {{recommendations}} which just holds a
> sequence of rules.
> I extracted most of EnforceMojo to AbstractEnforceMojo to avoid code
> duplication. I added an invoker test and all tests ran successfully.
> See https://github.com/apache/maven-enforcer/pull/4 as well for easier review.
--
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] (MENFORCER-160) Add levels ERROR and WARN to enforcer rules
[ https://jira.codehaus.org/browse/MENFORCER-160?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mirko Friedenhagen updated MENFORCER-160: - Issue Type: New Feature (was: Bug) > Add levels ERROR and WARN to enforcer rules > --- > > Key: MENFORCER-160 > URL: https://jira.codehaus.org/browse/MENFORCER-160 > Project: Maven Enforcer Plugin > Issue Type: New Feature > Components: Plugin, Rule API, Standard Rules >Affects Versions: 1.3.1 >Reporter: Mirko Friedenhagen >Assignee: Olivier Lamy > Fix For: 1.3.2 > > Attachments: enable-level.patch > > > As suggested in MENFORCER-159, it would be more feasible just have one goal > but be able to differentiate via a level between rules which should fail the > build and ones which only warn. I tried to be backwards compatible. > See https://github.com/apache/maven-enforcer/pull/5 as well, sample > configuration for WARN can be seen at > https://github.com/mfriedenhagen/maven-enforcer/blob/6482333e64e67031e19cb5b928d5ad2ce896f38a/maven-enforcer-plugin/src/it/projects/always-fail-warn/pom.xml -- 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] (SCM-740) Maven Release Plugin releases SNAPSHOT instead of STABLE version
[ https://jira.codehaus.org/browse/SCM-740?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jan Novotný updated SCM-740: Attachment: Wrong_base_directory_used1.patch Test added + slightly modified patch implementation. Document the usecase with deeper project structure. If you have any questions I will gladly answer them ;) > Maven Release Plugin releases SNAPSHOT instead of STABLE version > > > Key: SCM-740 > URL: https://jira.codehaus.org/browse/SCM-740 > Project: Maven SCM > Issue Type: Bug > Components: maven-scm-provider-git > Environment: Everywhere with maven-scm-provider-gitexe of version 1.9 > (and maybe older) >Reporter: Jan Novotný > Attachments: Wrong_base_directory_used1.patch > > > If you have following project structure: > - superproject [Git repository root] > - projectA [release target] > - projectB [release target] > in other words you release subproject of a larger Git repository separately, > you probably run at the same issue as we did. No recipe from above mentioned > sources solves your problems and during release:prepare phase still no commit > of stable pom.xml occurs. There is another bug in GitStatusConsumer class > that checks output of the git status --porcelain command and verifies > existency of the mentioned files on local filesystem. Regretfully it uses > working directory instead of git repository root as the base folder and thus > it constructs invalid path to the file where project folder directory is > duplicated. > Problem is better described here: > http://blog.novoj.net/2014/01/24/maven-release-plugin-releases-snapshot-instead-of-stable-version -- 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] (SCM-740) Maven Release Plugin releases SNAPSHOT instead of STABLE version
[ https://jira.codehaus.org/browse/SCM-740?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jan Novotný updated SCM-740: Attachment: (was: Wrong_base_directory_used.patch) > Maven Release Plugin releases SNAPSHOT instead of STABLE version > > > Key: SCM-740 > URL: https://jira.codehaus.org/browse/SCM-740 > Project: Maven SCM > Issue Type: Bug > Components: maven-scm-provider-git > Environment: Everywhere with maven-scm-provider-gitexe of version 1.9 > (and maybe older) >Reporter: Jan Novotný > > If you have following project structure: > - superproject [Git repository root] > - projectA [release target] > - projectB [release target] > in other words you release subproject of a larger Git repository separately, > you probably run at the same issue as we did. No recipe from above mentioned > sources solves your problems and during release:prepare phase still no commit > of stable pom.xml occurs. There is another bug in GitStatusConsumer class > that checks output of the git status --porcelain command and verifies > existency of the mentioned files on local filesystem. Regretfully it uses > working directory instead of git repository root as the base folder and thus > it constructs invalid path to the file where project folder directory is > duplicated. > Problem is better described here: > http://blog.novoj.net/2014/01/24/maven-release-plugin-releases-snapshot-instead-of-stable-version -- 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] (MASSEMBLY-613) assembly.xml in final build
[
https://jira.codehaus.org/browse/MASSEMBLY-613?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=340010#comment-340010
]
Karl Heinz Marbaise commented on MASSEMBLY-613:
---
I will close the issue. If you have objections don't hesitate to reopen the
issue and describe more in detail what you have tried and what you expect.
> assembly.xml in final build
> ---
>
> Key: MASSEMBLY-613
> URL: https://jira.codehaus.org/browse/MASSEMBLY-613
> Project: Maven Assembly Plugin
> Issue Type: Improvement
>Reporter: jacques
>
> See
> http://maven.apache.org/plugins/maven-assembly-plugin/examples/sharing-descriptors.html
> It says:Your assembly descriptors MUST be in the directory
> /src/main/resources/assemblies to be available to the Assembly Plugin.
> I did.
> I run "mvn clean package assembly:single"
> And now I have a assemblies.xml in my jar.
> here my assemblies file (pretty much default):
> {code:xml}
> xmlns="http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.2";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
>
> xsi:schemaLocation="http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.2
> http://maven.apache.org/xsd/assembly-1.1.2.xsd";>
> final
> true
>
> zip
>
>
>
> ${project.build.outputDirectory}
> /
>
>
>
>
> runtime
> true
> /lib
>
>
>
> {code}
--
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] (MASSEMBLY-613) assembly.xml in final build
[
https://jira.codehaus.org/browse/MASSEMBLY-613?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Heinz Marbaise closed MASSEMBLY-613.
-
Resolution: Not A Bug
> assembly.xml in final build
> ---
>
> Key: MASSEMBLY-613
> URL: https://jira.codehaus.org/browse/MASSEMBLY-613
> Project: Maven Assembly Plugin
> Issue Type: Improvement
>Reporter: jacques
>
> See
> http://maven.apache.org/plugins/maven-assembly-plugin/examples/sharing-descriptors.html
> It says:Your assembly descriptors MUST be in the directory
> /src/main/resources/assemblies to be available to the Assembly Plugin.
> I did.
> I run "mvn clean package assembly:single"
> And now I have a assemblies.xml in my jar.
> here my assemblies file (pretty much default):
> {code:xml}
> xmlns="http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.2";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
>
> xsi:schemaLocation="http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.2
> http://maven.apache.org/xsd/assembly-1.1.2.xsd";>
> final
> true
>
> zip
>
>
>
> ${project.build.outputDirectory}
> /
>
>
>
>
> runtime
> true
> /lib
>
>
>
> {code}
--
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] (MASSEMBLY-612) Documentation improvements: Assembly page
[ https://jira.codehaus.org/browse/MASSEMBLY-612?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=340009#comment-340009 ] Karl Heinz Marbaise commented on MASSEMBLY-612: --- To answer the question *Where are these ..descriptors?* just take a look at the first line of the [web site for predefined descriptors|http://maven.apache.org/plugins/maven-assembly-plugin/descriptor-refs.html]: excerpt: As of version 2.2, there are four predefined descriptor formats available for reuse, **packaged within the Assembly Plugin**, instead of the original three. This means in other words they are part of the maven-assembly-plugin itself. I will close the issue if you have no ebjections otherwise please don't hesitate to reopen the issue and elaborate what exactly the problem is. > Documentation improvements: Assembly page > - > > Key: MASSEMBLY-612 > URL: https://jira.codehaus.org/browse/MASSEMBLY-612 > Project: Maven Assembly Plugin > Issue Type: Improvement >Reporter: jacques > > "Although there are already prefabricated descriptors available for use, they > can only suffice some of the common assembly requirements." > Where are these plura of prefabricated descriptors? -- 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] (MASSEMBLY-612) Documentation improvements: Assembly page
[ https://jira.codehaus.org/browse/MASSEMBLY-612?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Heinz Marbaise closed MASSEMBLY-612. - Resolution: Not A Bug > Documentation improvements: Assembly page > - > > Key: MASSEMBLY-612 > URL: https://jira.codehaus.org/browse/MASSEMBLY-612 > Project: Maven Assembly Plugin > Issue Type: Improvement >Reporter: jacques > > "Although there are already prefabricated descriptors available for use, they > can only suffice some of the common assembly requirements." > Where are these plura of prefabricated descriptors? -- 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] (MASSEMBLY-681) plugin ignores empty finalName and uses default value
[
https://jira.codehaus.org/browse/MASSEMBLY-681?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=340008#comment-340008
]
Karl Heinz Marbaise commented on MASSEMBLY-681:
---
If you take a look at the docs. The finalName is mentioned having a default
value of {{$\{project.build.finalName\}}} which means if no finalName is
defined the default will be used.
The result of the above is to make a difference between an empty tag
{{}} and a non existing tag at all. This will lead to a
contracdiction with the injected values in the Mojo.
This sounds to me we should go for an other way. May we have to introduce a
flag like {{noFinalName}} to suppress the finalName part but only in
relationship with {{formats: dir}}.
> plugin ignores empty finalName and uses default value
> -
>
> Key: MASSEMBLY-681
> URL: https://jira.codehaus.org/browse/MASSEMBLY-681
> Project: Maven Assembly Plugin
> Issue Type: Bug
>Affects Versions: 2.4
>Reporter: Paul Millar
>Priority: Minor
>
> When used in the 'dir' format, I would argue that an empty finalName is
> reasonable.
> For example, I would expect the following configuration, with the 'dir'
> format, to output the assembled files in ${foo.baseDirectory}
>
>
> src/main/assembly/foo.xml
>
> ${foo.baseDirectory}
>
>
> The actual behaviour is to silently ignore the configured empty finalName and
> use the default finalName value, which is append this to the outputDirectory.
> Arguably there are two bugs here:
> finalName is silently ignored (if this is invalid, it should report an
> error)
> the empty finalName is not honoured.
> Specify '.' as the finalName (.) seems to work as a
> work-around, at least for unix-like systems.
--
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] (MASSEMBLY-681) plugin ignores empty finalName and uses default value
[
https://jira.codehaus.org/browse/MASSEMBLY-681?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Heinz Marbaise updated MASSEMBLY-681:
--
Issue Type: Wish (was: Bug)
> plugin ignores empty finalName and uses default value
> -
>
> Key: MASSEMBLY-681
> URL: https://jira.codehaus.org/browse/MASSEMBLY-681
> Project: Maven Assembly Plugin
> Issue Type: Wish
>Affects Versions: 2.4
>Reporter: Paul Millar
>Priority: Minor
>
> When used in the 'dir' format, I would argue that an empty finalName is
> reasonable.
> For example, I would expect the following configuration, with the 'dir'
> format, to output the assembled files in ${foo.baseDirectory}
>
>
> src/main/assembly/foo.xml
>
> ${foo.baseDirectory}
>
>
> The actual behaviour is to silently ignore the configured empty finalName and
> use the default finalName value, which is append this to the outputDirectory.
> Arguably there are two bugs here:
> finalName is silently ignored (if this is invalid, it should report an
> error)
> the empty finalName is not honoured.
> Specify '.' as the finalName (.) seems to work as a
> work-around, at least for unix-like systems.
--
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] (MNG-5293) Maven 3.0.4 crashes when "-Djava.net.useSystemProxies=true" added.
[
https://jira.codehaus.org/browse/MNG-5293?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
denixx baykin closed MNG-5293.
--
Resolution: Won't Fix
Closed as not needed.
> Maven 3.0.4 crashes when "-Djava.net.useSystemProxies=true" added.
> --
>
> Key: MNG-5293
> URL: https://jira.codehaus.org/browse/MNG-5293
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: Bootstrap & Build
>Affects Versions: 3.0.4
> Environment: openSUSE 12.1 x64
> -=-=-
> denixx@denixxwork:~> java -version
> java version "1.6.0_32"
> Java(TM) SE Runtime Environment (build 1.6.0_32-b05)
> Java HotSpot(TM) 64-Bit Server VM (build 20.7-b02, mixed mode)
> -=-=-
> additionnaly: NetBeans 7.1.2 uses this flag by default (this flag can be
> erased in options).
>Reporter: denixx baykin
> Attachments: hs_err_pid9618.log, hs_err_pid9918.log, maven java
> netbeans libdbus crash2.txt
>
>
> I have localized the issue: it's a Maven issue.
> Maven, started with flag "-Djava.net.useSystemProxies=true" crashes because
> it somehow use libdbus in openSUSE 12.1 x64 in wrong way.
> Here is a console output:
> denixx@denixxwork:~/NetBeansProjects/FinMonitor_server_boevoy_20120517_Qualifier>
> /home/denixx/soft/apache-maven-3.0.4/bin/mvn
> -Djava.net.useSystemProxies=true clean install
> [INFO] Scanning for projects...
> [WARNING]
> [WARNING] Some problems were encountered while building the effective model
> for com.pb:finmonitor:war:0.0.1-SNAPSHOT
> [WARNING] 'dependencies.dependency.systemPath' for
> com.enterprisedt:edtftp:jar should not point at files within the project
> directory, ${basedir}/src/main/webapp/WEB-INF/lib/edtftpj.jar will be
> unresolvable by dependent projects @ line 53, column 25
> [WARNING] 'dependencies.dependency.systemPath' for com.sun:jna:jar should not
> point at files within the project directory,
> ${basedir}/src/main/webapp/WEB-INF/lib/jna.jar will be unresolvable by
> dependent projects @ line 61, column 25
> [WARNING]
> [WARNING] It is highly recommended to fix these problems because they
> threaten the stability of your build.
> [WARNING]
> [WARNING] For this reason, future Maven versions might no longer support
> building such malformed projects.
> [WARNING]
> [INFO]
>
> [INFO]
>
> [INFO] Building FinMonitor 0.0.1-SNAPSHOT
> [INFO]
>
> [INFO]
> [INFO] --- maven-clean-plugin:2.4.1:clean (default-clean) @ finmonitor ---
> [INFO]
> [INFO] --- maven-resources-plugin:2.5:resources (default-resources) @
> finmonitor ---
> Downloading:
> http://repo.maven.apache.org/maven2/commons-cli/commons-cli/1.0/commons-cli-1.0.jar
> Downloading:
> http://repo.maven.apache.org/maven2/org/apache/maven/doxia/doxia-sink-api/1.0-alpha-7/doxia-sink-api-1.0-alpha-7.jar
> Downloading:
> http://repo.maven.apache.org/maven2/junit/junit/3.8.1/junit-3.8.1.jar
> #
> # A fatal error has been detected by the Java Runtime Environment:
> #
> # SIGSEGV (0xb) at pc=0x7f2d14766727, pid=9618, tid=139831727105792
> #
> # JRE version: 6.0_32-b05
> # Java VM: Java HotSpot(TM) 64-Bit Server VM (20.7-b02 mixed mode linux-amd64
> compressed oops)
> # Problematic frame:
> # C [libdbus-1.so.3+0x8727] double+0x67
> #
> (process:9618): GConf-WARNING **: Client failed to connect to the D-BUS
> daemon:
> Failed to connect to socket abstract: Connection refused
> GConf Error: No D-BUS daemon running
> # An error report file with more information is saved as:
> #
> /home/denixx/NetBeansProjects/FinMonitor_server_boevoy_20120517_Qualifier/hs_err_pid9618.log
> #
> # If you would like to submit a bug report, please visit:
> # http://java.sun.com/webapps/bugreport/crash.jsp
> #
> ÐваÑийнÑй оÑÑанов (crash)
> -=-=-
> Another one:
> denixx@denixxwork:~/NetBeansProjects/FinMonitor_server_boevoy_20120517_Qualifier>
> /home/denixx/soft/apache-maven-3.0.4/bin/mvn
> -Djava.net.useSystemProxies=true clean install
> [INFO] Scanning for projects...
> [WARNING]
> [WARNING] Some problems were encountered while building the effective model
> for com.pb:finmonitor:war:0.0.1-SNAPSHOT
> [WARNING] 'dependencies.dependency.systemPath' for
> com.enterprisedt:edtftp:jar should not point at files within the project
> directory, ${basedir}/src/main/webapp/WEB-INF/lib/edtftpj.jar will be
> unresolvable by dependent projects @ line 53, column 25
> [WARNING] 'dependencies.dependency.systemPath' for com.sun:jna:jar should not
> point at files within the project directory,
> ${basedir}/src/main/webapp/WEB-INF/lib/jna.jar will be unresolvable by
> dependent projects @ line 61, column 25
> [
[jira] (MENFORCER-179) Improve documentation for the bannedDependencies
[ https://jira.codehaus.org/browse/MENFORCER-179?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Heinz Marbaise closed MENFORCER-179. - Resolution: Fixed Fixed in [r1561108|http://svn.apache.org/r1561108] > Improve documentation for the bannedDependencies > - > > Key: MENFORCER-179 > URL: https://jira.codehaus.org/browse/MENFORCER-179 > Project: Maven Enforcer Plugin > Issue Type: Improvement > Components: Documentation, Standard Rules >Affects Versions: 1.3.1 >Reporter: Karl Heinz Marbaise >Assignee: Karl Heinz Marbaise >Priority: Minor > Fix For: 1.3.2 > > > The documentation should be improved in particular which parameters a rule > can have and which defaults exists. -- 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] (MENFORCER-180) dependencyConvergence consitenly write the rule name in lower case.
[ https://jira.codehaus.org/browse/MENFORCER-180?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Heinz Marbaise closed MENFORCER-180. - Resolution: Fixed Fixed in [r1561105|http://svn.apache.org/r1561105] > dependencyConvergence consitenly write the rule name in lower case. > --- > > Key: MENFORCER-180 > URL: https://jira.codehaus.org/browse/MENFORCER-180 > Project: Maven Enforcer Plugin > Issue Type: Improvement > Components: Documentation, Standard Rules >Affects Versions: 1.3.1 >Reporter: Karl Heinz Marbaise >Assignee: Karl Heinz Marbaise >Priority: Trivial > Fix For: 1.3.2 > > > All rule names are written with the first letter lowercase so we should do > that on all rules. The documentation for dependencyConvergence does not so. -- 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] (MENFORCER-180) dependencyConvergence consitenly write the rule name in lower case.
[ https://jira.codehaus.org/browse/MENFORCER-180?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Heinz Marbaise updated MENFORCER-180: -- Fix Version/s: 1.3.2 > dependencyConvergence consitenly write the rule name in lower case. > --- > > Key: MENFORCER-180 > URL: https://jira.codehaus.org/browse/MENFORCER-180 > Project: Maven Enforcer Plugin > Issue Type: Improvement > Components: Documentation, Standard Rules >Affects Versions: 1.3.1 >Reporter: Karl Heinz Marbaise >Assignee: Karl Heinz Marbaise >Priority: Trivial > Fix For: 1.3.2 > > > All rule names are written with the first letter lowercase so we should do > that on all rules. The documentation for dependencyConvergence does not so. -- 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] (MENFORCER-180) dependencyConvergence consitenly write the rule name in lower case.
[ https://jira.codehaus.org/browse/MENFORCER-180?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Heinz Marbaise reassigned MENFORCER-180: - Assignee: Karl Heinz Marbaise > dependencyConvergence consitenly write the rule name in lower case. > --- > > Key: MENFORCER-180 > URL: https://jira.codehaus.org/browse/MENFORCER-180 > Project: Maven Enforcer Plugin > Issue Type: Improvement > Components: Documentation, Standard Rules >Affects Versions: 1.3.1 >Reporter: Karl Heinz Marbaise >Assignee: Karl Heinz Marbaise >Priority: Trivial > > All rule names are written with the first letter lowercase so we should do > that on all rules. The documentation for dependencyConvergence does not so. -- 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] (MENFORCER-180) dependencyConvergence consitenly write the rule name in lower case.
Karl Heinz Marbaise created MENFORCER-180: - Summary: dependencyConvergence consitenly write the rule name in lower case. Key: MENFORCER-180 URL: https://jira.codehaus.org/browse/MENFORCER-180 Project: Maven Enforcer Plugin Issue Type: Improvement Components: Documentation, Standard Rules Affects Versions: 1.3.1 Reporter: Karl Heinz Marbaise Priority: Trivial All rule names are written with the first letter lowercase so we should do that on all rules. The documentation for dependencyConvergence does not so. -- 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] (MENFORCER-176) Throws NoSuchMethodError with Maven 2.0.x
[
https://jira.codehaus.org/browse/MENFORCER-176?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=340003#comment-340003
]
Karl Heinz Marbaise commented on MENFORCER-176:
---
I've checked Maven 2.0.11 with the rule without any
problem.
> Throws NoSuchMethodError with Maven 2.0.x
> -
>
> Key: MENFORCER-176
> URL: https://jira.codehaus.org/browse/MENFORCER-176
> Project: Maven Enforcer Plugin
> Issue Type: Bug
> Components: Plugin, Standard Rules
>Affects Versions: 1.3.1
> Environment: Mac OS, JDK 1.7.0
>Reporter: Anders Hammar
> Fix For: 1.3.2
>
>
> Building a Mojo project with Maven 2.0.x using enforcer and some rules I get
> this stacktrace:
> {quote}
> java.lang.NoSuchMethodError:
> org.apache.maven.project.MavenProject.getProjectBuilderConfiguration()Lorg/apache/maven/project/ProjectBuilderConfiguration;
> at
> org.apache.maven.shared.dependency.tree.DefaultDependencyTreeBuilder.buildDependencyTree(DefaultDependencyTreeBuilder.java:139)
> at
> org.apache.maven.shared.dependency.graph.internal.Maven2DependencyGraphBuilder.buildDependencyGraph(Maven2DependencyGraphBuilder.java:55)
> at
> org.apache.maven.plugins.enforcer.AbstractBanDependencies.getDependenciesToCheck(AbstractBanDependencies.java:126)
> at
> org.apache.maven.plugins.enforcer.AbstractBanDependencies.execute(AbstractBanDependencies.java:90)
> at
> org.apache.maven.plugins.enforcer.EnforceMojo.execute(EnforceMojo.java:177)
> at
> org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:454)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:559)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:500)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:479)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:331)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:292)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:142)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:345)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:132)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:290)
> 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.classworlds.Launcher.launchEnhanced(Launcher.java:315)
> at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
> at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
> at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
> {quote}
--
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] (MENFORCER-164) bannedDependencies searchTransitive=false failure
[
https://jira.codehaus.org/browse/MENFORCER-164?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=340001#comment-340001
]
Karl Heinz Marbaise commented on MENFORCER-164:
---
If you put the parameter searchTransitive to the correct location like:
{code}
validate
maven-enforcer-plugin
1.3.1
enforce
commons-lang:commons-lang
false
{code}
It works perfectly. I have to admit the documentation could be improved to make
that more clear (MENFORCER-179). Apart from that i will the issue cause it's no
bug. If you have an other opinion don't hesitate to reopen the issue.
> bannedDependencies searchTransitive=false failure
> -
>
> Key: MENFORCER-164
> URL: https://jira.codehaus.org/browse/MENFORCER-164
> Project: Maven Enforcer Plugin
> Issue Type: Bug
> Components: Standard Rules
>Affects Versions: 1.3.1
>Reporter: jieryn
>Assignee: Karl Heinz Marbaise
> Fix For: 1.3.2
>
>
> The bannedDependencies rule is too aggressive, especially when you have
> searchTransitive=false configured. Here is an example pom.xml which
> demonstrates the problem:
> {code}
> 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/xsd/maven-4.0.0.xsd";>
> 4.0.0
> org.apache.maven.plugins.enforcer
> banned-dependencies
> 1-SNAPSHOT
>
>
> org.springframework.ldap
> spring-ldap-core
> 1.3.2.RELEASE
>
>
>
> validate
>
>
> maven-enforcer-plugin
> 1.3.1
>
>
>
> enforce
>
>
>
>
>
> commons-lang:commons-lang
>
>
>
> false
>
>
>
>
>
>
>
> {code}
--
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] (MENFORCER-164) bannedDependencies searchTransitive=false failure
[
https://jira.codehaus.org/browse/MENFORCER-164?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Heinz Marbaise closed MENFORCER-164.
-
Resolution: Not A Bug
Fix Version/s: (was: 1.3.2)
> bannedDependencies searchTransitive=false failure
> -
>
> Key: MENFORCER-164
> URL: https://jira.codehaus.org/browse/MENFORCER-164
> Project: Maven Enforcer Plugin
> Issue Type: Bug
> Components: Standard Rules
>Affects Versions: 1.3.1
>Reporter: jieryn
>Assignee: Karl Heinz Marbaise
>
> The bannedDependencies rule is too aggressive, especially when you have
> searchTransitive=false configured. Here is an example pom.xml which
> demonstrates the problem:
> {code}
> 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/xsd/maven-4.0.0.xsd";>
> 4.0.0
> org.apache.maven.plugins.enforcer
> banned-dependencies
> 1-SNAPSHOT
>
>
> org.springframework.ldap
> spring-ldap-core
> 1.3.2.RELEASE
>
>
>
> validate
>
>
> maven-enforcer-plugin
> 1.3.1
>
>
>
> enforce
>
>
>
>
>
> commons-lang:commons-lang
>
>
>
> false
>
>
>
>
>
>
>
> {code}
--
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] (MENFORCER-179) Improve documentation for the bannedDependencies
[ https://jira.codehaus.org/browse/MENFORCER-179?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Heinz Marbaise updated MENFORCER-179: -- Fix Version/s: 1.3.2 Assignee: Karl Heinz Marbaise > Improve documentation for the bannedDependencies > - > > Key: MENFORCER-179 > URL: https://jira.codehaus.org/browse/MENFORCER-179 > Project: Maven Enforcer Plugin > Issue Type: Improvement > Components: Documentation, Standard Rules >Affects Versions: 1.3.1 >Reporter: Karl Heinz Marbaise >Assignee: Karl Heinz Marbaise >Priority: Minor > Fix For: 1.3.2 > > > The documentation should be improved in particular which parameters a rule > can have and which defaults exists. -- 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] (MENFORCER-179) Improve documentation for the bannedDependencies
Karl Heinz Marbaise created MENFORCER-179: - Summary: Improve documentation for the bannedDependencies Key: MENFORCER-179 URL: https://jira.codehaus.org/browse/MENFORCER-179 Project: Maven Enforcer Plugin Issue Type: Improvement Components: Documentation, Standard Rules Affects Versions: 1.3.1 Reporter: Karl Heinz Marbaise Priority: Minor The documentation should be improved in particular which parameters a rule can have and which defaults exists. -- 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] (MENFORCER-176) Throws NoSuchMethodError with Maven 2.0.x
[
https://jira.codehaus.org/browse/MENFORCER-176?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=34#comment-34
]
Karl Heinz Marbaise commented on MENFORCER-176:
---
After playing with enforcer i found a way to reproduce the problem.
Maven 2.0.11 and an enforcer rule bannedDependencies. The following pom file:
{code}
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/xsd/maven-4.0.0.xsd";>
4.0.0
com.soebes.smpp
smpp
0.6.2
org.apache.maven.plugins.enforcer
banned-dependencies
1-SNAPSHOT
org.springframework.ldap
spring-ldap-core
1.3.2.RELEASE
validate
maven-enforcer-plugin
1.3.1
enforce
commons-lang:commons-lang
{code}
exactly produces the problem.
> Throws NoSuchMethodError with Maven 2.0.x
> -
>
> Key: MENFORCER-176
> URL: https://jira.codehaus.org/browse/MENFORCER-176
> Project: Maven Enforcer Plugin
> Issue Type: Bug
> Components: Plugin, Standard Rules
>Affects Versions: 1.3.1
> Environment: Mac OS, JDK 1.7.0
>Reporter: Anders Hammar
> Fix For: 1.3.2
>
>
> Building a Mojo project with Maven 2.0.x using enforcer and some rules I get
> this stacktrace:
> {quote}
> java.lang.NoSuchMethodError:
> org.apache.maven.project.MavenProject.getProjectBuilderConfiguration()Lorg/apache/maven/project/ProjectBuilderConfiguration;
> at
> org.apache.maven.shared.dependency.tree.DefaultDependencyTreeBuilder.buildDependencyTree(DefaultDependencyTreeBuilder.java:139)
> at
> org.apache.maven.shared.dependency.graph.internal.Maven2DependencyGraphBuilder.buildDependencyGraph(Maven2DependencyGraphBuilder.java:55)
> at
> org.apache.maven.plugins.enforcer.AbstractBanDependencies.getDependenciesToCheck(AbstractBanDependencies.java:126)
> at
> org.apache.maven.plugins.enforcer.AbstractBanDependencies.execute(AbstractBanDependencies.java:90)
> at
> org.apache.maven.plugins.enforcer.EnforceMojo.execute(EnforceMojo.java:177)
> at
> org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:454)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:559)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:500)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:479)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:331)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:292)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:142)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:345)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:132)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:290)
> 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.classworlds.Launcher.launchEnhanced(Launcher.java:315)
> at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
> at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
> at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
> {quote}
--
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] (MENFORCER-176) Throws NoSuchMethodError with Maven 2.0.x
[
https://jira.codehaus.org/browse/MENFORCER-176?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Heinz Marbaise updated MENFORCER-176:
--
Comment: was deleted
(was: Hi Anders,
can you give a more detailed example, cause I've tried it with Maven 2.0.11.
Which version did you used? Which version of maven-enforcer-plugin 1.3.1 or
trunk SNAPSHOT version?
{code}
Apache Maven 2.0.11 (r909250; 2010-02-12 06:55:50+0100)
Java version: 1.7.0_21
Java home: /Library/Java/JavaVirtualMachines/jdk1.7.0_21.jdk/Contents/Home/jre
Default locale: en_US, platform encoding: UTF-8
OS name: "mac os x" version: "10.8.5" arch: "x86_64" Family: "mac"
{code}
With the version 1.3.1 of maven-enforcer-plugin it works.
{code}
Karl-Heinzs-MacBook-Pro:enforcer-test kama$ mvn clean package
[INFO] Scanning for projects...
[INFO]
[INFO] Building Unnamed -
com.soebes.maven.plugins.test:enforcer:jar:0.1-SNAPSHOT
[INFO]task-segment: [clean, package]
[INFO]
[INFO] [clean:clean]
[INFO] [enforcer:enforce {execution: enforce-maven}]
[WARNING] Rule 0: org.apache.maven.plugins.enforcer.RequireMavenVersion failed
with message:
Detected Maven Version: 2.0.11 is not in the allowed range 3.0.0.
[WARNING] Rule 1: org.apache.maven.plugins.enforcer.RequireEnvironmentVariable
failed with message:
Environment variable "that" is required for this build.
[INFO]
[ERROR] BUILD ERROR
[INFO]
[INFO] Some Enforcer rules have failed. Look above for specific messages
explaining why the rule failed.
[INFO]
[INFO] For more information, run Maven with the -e switch
[INFO]
[INFO] Total time: 1 second
[INFO] Finished at: Tue Jan 21 19:14:54 CET 2014
[INFO] Final Memory: 17M/981M
[INFO]
{code}
Furthermore i've checked an other setup which works well also...
)
> Throws NoSuchMethodError with Maven 2.0.x
> -
>
> Key: MENFORCER-176
> URL: https://jira.codehaus.org/browse/MENFORCER-176
> Project: Maven Enforcer Plugin
> Issue Type: Bug
> Components: Plugin, Standard Rules
>Affects Versions: 1.3.1
> Environment: Mac OS, JDK 1.7.0
>Reporter: Anders Hammar
> Fix For: 1.3.2
>
>
> Building a Mojo project with Maven 2.0.x using enforcer and some rules I get
> this stacktrace:
> {quote}
> java.lang.NoSuchMethodError:
> org.apache.maven.project.MavenProject.getProjectBuilderConfiguration()Lorg/apache/maven/project/ProjectBuilderConfiguration;
> at
> org.apache.maven.shared.dependency.tree.DefaultDependencyTreeBuilder.buildDependencyTree(DefaultDependencyTreeBuilder.java:139)
> at
> org.apache.maven.shared.dependency.graph.internal.Maven2DependencyGraphBuilder.buildDependencyGraph(Maven2DependencyGraphBuilder.java:55)
> at
> org.apache.maven.plugins.enforcer.AbstractBanDependencies.getDependenciesToCheck(AbstractBanDependencies.java:126)
> at
> org.apache.maven.plugins.enforcer.AbstractBanDependencies.execute(AbstractBanDependencies.java:90)
> at
> org.apache.maven.plugins.enforcer.EnforceMojo.execute(EnforceMojo.java:177)
> at
> org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:454)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:559)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:500)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:479)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:331)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:292)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:142)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:345)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:132)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:290)
> 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.Met
[jira] (SCM-740) Maven Release Plugin releases SNAPSHOT instead of STABLE version
[ https://jira.codehaus.org/browse/SCM-740?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=339998#comment-339998 ] Robert Scholte commented on SCM-740: Would be nice if this could be confirmed with a unittest. > Maven Release Plugin releases SNAPSHOT instead of STABLE version > > > Key: SCM-740 > URL: https://jira.codehaus.org/browse/SCM-740 > Project: Maven SCM > Issue Type: Bug > Components: maven-scm-provider-git > Environment: Everywhere with maven-scm-provider-gitexe of version 1.9 > (and maybe older) >Reporter: Jan Novotný > Attachments: Wrong_base_directory_used.patch > > > If you have following project structure: > - superproject [Git repository root] > - projectA [release target] > - projectB [release target] > in other words you release subproject of a larger Git repository separately, > you probably run at the same issue as we did. No recipe from above mentioned > sources solves your problems and during release:prepare phase still no commit > of stable pom.xml occurs. There is another bug in GitStatusConsumer class > that checks output of the git status --porcelain command and verifies > existency of the mentioned files on local filesystem. Regretfully it uses > working directory instead of git repository root as the base folder and thus > it constructs invalid path to the file where project folder directory is > duplicated. > Problem is better described here: > http://blog.novoj.net/2014/01/24/maven-release-plugin-releases-snapshot-instead-of-stable-version -- 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] (WAGON-405) Preemptive authentication still not working with Maven 3.0.4+
[ https://jira.codehaus.org/browse/WAGON-405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=339993#comment-339993 ] Mirko Friedenhagen commented on WAGON-405: -- [~kwin], my guess: * On central AKA repo1.maven.org, anyone is allowed to download stuff, so GET defaults to using no authentication. * On the other hand, for uploading, PUTting new stuff, you do not want this to be done anonymously. I am with you, that the documentation should be updated. > Preemptive authentication still not working with Maven 3.0.4+ > - > > Key: WAGON-405 > URL: https://jira.codehaus.org/browse/WAGON-405 > Project: Maven Wagon > Issue Type: Bug >Reporter: Konrad Windszus > Attachments: WAGON-405-MVN3.1.1.log > > > Although by default the preemptive authentication should work now with Maven > 3.0.4, a wireshare dump exposes, that each request for downloading a new > dependency does not initially come with the authentication header. Only after > Nexus replied with a 401 the right credentials are set in the authentication > header. According to [1], since Maven 3.0.4 the default HTTP wagon uses > preemptive authentication which cannot be disabled [2]. Even with Maven 3.1.1 > it does not work. > [1] - http://maven.apache.org/guides/mini/guide-http-settings.html#Maven_3.0.4 > [2] - > http://maven.40175.n5.nabble.com/Maven-3-0-4-preemptive-auth-problem-tt5470892.html#none -- 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] (MENFORCER-162) maven-enforcer-plugin 1.3.1 no longer fails when duplicate classes are found
[ https://jira.codehaus.org/browse/MENFORCER-162?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Scholte closed MENFORCER-162. Resolution: Not A Bug Assignee: Robert Scholte Has been fixed with MOJO-1949 as part of the extra-enforcer-rules, so it wasn't a maven-enforcer-plugin bug. > maven-enforcer-plugin 1.3.1 no longer fails when duplicate classes are found > > > Key: MENFORCER-162 > URL: https://jira.codehaus.org/browse/MENFORCER-162 > Project: Maven Enforcer Plugin > Issue Type: Bug > Components: Plugin >Reporter: David Boden >Assignee: Robert Scholte >Priority: Critical > > I'll provide more details if this proves difficult to recreate. For now, I > just wanted to log my observation that 1.3.1 does not find duplicate classes > on the classpath whereas 1.3 does. -- 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] (MGPG-29) Allow options to be passed to gpg
[
https://jira.codehaus.org/browse/MGPG-29?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=339991#comment-339991
]
Dmitry Katsubo commented on MGPG-29:
Just a note for those who will find this issue searching for the possibility to
add extra options to GPG command line:
One can probably workaround using {{~/.gnupg/gpg.conf}} (location can be
overridden). In my case I had the following trouble: gpg keys are available on
read-only mount, thus gpg was failing:
{code}
[INFO] --- maven-gpg-plugin:1.4:sign (default-cli) @ jaxb-xew-plugin ---
gpg: failed to create temporary file
`/mount/gpg/.#lk0x7f4cd1f1fe80.localhost.284': Permission denied
gpg: fatal: can't create lock for `/mount/gpg/trustdb.gpg'
{code}
Just create {{gpg.conf}} with option {{lock-never}} and here we are.
> Allow options to be passed to gpg
> -
>
> Key: MGPG-29
> URL: https://jira.codehaus.org/browse/MGPG-29
> Project: Maven GPG Plugin
> Issue Type: Improvement
>Affects Versions: 1.1
>Reporter: SebbASF
>Assignee: Benjamin Bentmann
>
> It would sometimes be useful to be able to pass additional command-line
> options to the gpg executable.
> For example, if the secret key is stored on a removable medium the
> --secret-key option is needed.
> Changing the home directory to the removable medium can cause problems with
> the gpg2 agent.
> There may be other options that are needed on occasion.
--
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] (SCM-740) Maven Release Plugin releases SNAPSHOT instead of STABLE version
[ https://jira.codehaus.org/browse/SCM-740?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Scholte moved MRELEASE-864 to SCM-740: - Complexity: Intermediate Component/s: (was: Git) maven-scm-provider-git Key: SCM-740 (was: MRELEASE-864) Project: Maven SCM (was: Maven Release Plugin) > Maven Release Plugin releases SNAPSHOT instead of STABLE version > > > Key: SCM-740 > URL: https://jira.codehaus.org/browse/SCM-740 > Project: Maven SCM > Issue Type: Bug > Components: maven-scm-provider-git > Environment: Everywhere with maven-scm-provider-gitexe of version 1.9 > (and maybe older) >Reporter: Jan Novotný > Attachments: Wrong_base_directory_used.patch > > > If you have following project structure: > - superproject [Git repository root] > - projectA [release target] > - projectB [release target] > in other words you release subproject of a larger Git repository separately, > you probably run at the same issue as we did. No recipe from above mentioned > sources solves your problems and during release:prepare phase still no commit > of stable pom.xml occurs. There is another bug in GitStatusConsumer class > that checks output of the git status --porcelain command and verifies > existency of the mentioned files on local filesystem. Regretfully it uses > working directory instead of git repository root as the base folder and thus > it constructs invalid path to the file where project folder directory is > duplicated. > Problem is better described here: > http://blog.novoj.net/2014/01/24/maven-release-plugin-releases-snapshot-instead-of-stable-version -- 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] (MRELEASE-812) "prepare" does not commit before tagging and therefore deploys snapshot instead of release
[ https://jira.codehaus.org/browse/MRELEASE-812?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=339985#comment-339985 ] Jan Novotný commented on MRELEASE-812: -- You can also run into the issues with deep folder structure here - another bug filled is here #MRELEASE-864 Details here: http://blog.novoj.net/2014/01/24/maven-release-plugin-releases-snapshot-instead-of-stable-version/ > "prepare" does not commit before tagging and therefore deploys snapshot > instead of release > -- > > Key: MRELEASE-812 > URL: https://jira.codehaus.org/browse/MRELEASE-812 > Project: Maven Release Plugin > Issue Type: Bug > Components: Git >Affects Versions: 2.4 >Reporter: Andrei Pozolotin >Assignee: Robert Scholte >Priority: Critical > Fix For: 2.5 > > Attachments: mvn-2.3.2.txt, mvn-2.4.0.txt > > > thank you very much for new release! > http://mail-archives.apache.org/mod_mbox/maven-announce/201212.mbox/%3Cop.wpjbptp1kdkhrr@columbia%3E > it seems we need an emergency fix: > attached are 2 logs: > 1) mvn-2.3.2.txt invocation that works fine with 2.3.2 > 2) mvn-2.4.0.txt invocation that fails with 2.4 > problem: > "perform" does not commit tags, deploys snapshot instead of release > here is project parent: > http://search.maven.org/remotecontent?filepath=com/barchart/base/barchart-archon/2.3.6/barchart-archon-2.3.6.pom > build is invoked both times with this: > mvn --define resume=false release:prepare > mvn --define resume=false release:perform -- 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] (MNG-1388) Transitive Dependencies in a profile are not used
[ https://jira.codehaus.org/browse/MNG-1388?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=339984#comment-339984 ] Iain Coulter commented on MNG-1388: --- Want to also add a request to reopen this issue, we have to use various workarounds to pull the correct native dependencies without a solution to the above problem. In some cases we upload a different pom to that used during compile, in other cases we end up downloading all dependencies across every platform even though we may only need say windows-x86-32 components. > Transitive Dependencies in a profile are not used > - > > Key: MNG-1388 > URL: https://jira.codehaus.org/browse/MNG-1388 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Plugins and Lifecycle >Affects Versions: 2.0 > Environment: Windows XP using Maven 2.0. >Reporter: Damian Bradicich > Fix For: Issues to be reviewed for 3.x > > > I have a jar project file that defines a dependency inside a certain profile. > If I then include that project inside of another war project, the > dependencies defined in the jar project's profile isn't getting transferred > over to the war. > Ie we have this: > A depends on SQL or Oracle depending on profile > B depends on A. > If sql profile is active, I would expect that when I build B, it pulls > the transitive dependancy on sql from A. -- 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] (MNG-3169) Dependency-Resolution Bug (Resolved too early / at wrong point)
[ https://jira.codehaus.org/browse/MNG-3169?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=339983#comment-339983 ] Jörg Hohwiller commented on MNG-3169: - Indeed my description was insufficient to reproduce the issue. This is also ages ago so it is safe to close this issue as e.g. cannot reproduce. Either this has already been fixed or I found a workaround. > Dependency-Resolution Bug (Resolved too early / at wrong point) > --- > > Key: MNG-3169 > URL: https://jira.codehaus.org/browse/MNG-3169 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Dependencies >Affects Versions: 2.0.6, 2.0.7 >Reporter: Jörg Hohwiller > Fix For: Issues to be reviewed for 3.x > > > I have a maven project with a 2 level deep module structure. > The toplevel POM has two modules A and B that themselves have packaging pom > and have several modules. > The reactor build order is strict for A and B meaning that A and B are > completely independent. So first A is build with all its modules and then B. > If I do an 'mvn install' on the top-level project with a clean local > repository the build fails because during the install of a module of A some > artifact of B is resolved, even though it is NOT referenced anywhere in a POM > in A or below! > If I do a mvn install in A it works fine. > If I do a mvn install in B it works fine. > After B is installed with all its modules, then the mvn install on the > top-level project also works fine. > The module in B that was missing first (B1) is required by another module of > B (B2) that defines the dependency (on B1) twice, once regularly and a second > time with classifier 'sources' since the sources are required for the > GWT-Compiler to run. > I tried to do a mvn -X install when the problem occurs but the log did NOT > enlighten me anyhow. I only gave me the impression that the dependency > resolution in maven is completely insane cycling around into the same things > again and again and again and however ending without an infinity-loop in this > strange bug. > What should '(selected for null)' say? > Why doesnt the MavenProject declare a useable toString() method? I can not > read stuff like 'org.apache.maven.project.MavenProject@fa682130' > Maven in general is really cool. But if something goes wrong you are so very > lost with 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] (MENFORCER-116) Require property rule interpolation does not work like profile activation
[
https://jira.codehaus.org/browse/MENFORCER-116?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=339978#comment-339978
]
Karl Heinz Marbaise commented on MENFORCER-116:
---
NP. Take your time.
> Require property rule interpolation does not work like profile activation
> -
>
> Key: MENFORCER-116
> URL: https://jira.codehaus.org/browse/MENFORCER-116
> Project: Maven Enforcer Plugin
> Issue Type: Bug
> Components: Standard Rules
>Affects Versions: 1.0
>Reporter: Michael Osipov
>Priority: Critical
>
> The main benefit of profile activation is that a profile is activated by a
> property set *outside* of maven. It does not make any sense to active by a
> property if it is defined in the POM.
> If I set the following in my properties section:
> {noformat}
>
>
>
> {noformat}
> This would evaluate the property to "true" and pass the enforcer rule. It
> makes absolutely no sense. Properties should be evaluated the same way as in
> the profile activation. POM properties are always present, thus making the
> hole enforcer thing obsolete.
> This issue is related to MENFORCER-115.
--
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] (MENFORCER-176) Throws NoSuchMethodError with Maven 2.0.x
[
https://jira.codehaus.org/browse/MENFORCER-176?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Heinz Marbaise updated MENFORCER-176:
--
Fix Version/s: 1.3.2
> Throws NoSuchMethodError with Maven 2.0.x
> -
>
> Key: MENFORCER-176
> URL: https://jira.codehaus.org/browse/MENFORCER-176
> Project: Maven Enforcer Plugin
> Issue Type: Bug
> Components: Plugin, Standard Rules
>Affects Versions: 1.3.1
> Environment: Mac OS, JDK 1.7.0
>Reporter: Anders Hammar
> Fix For: 1.3.2
>
>
> Building a Mojo project with Maven 2.0.x using enforcer and some rules I get
> this stacktrace:
> {quote}
> java.lang.NoSuchMethodError:
> org.apache.maven.project.MavenProject.getProjectBuilderConfiguration()Lorg/apache/maven/project/ProjectBuilderConfiguration;
> at
> org.apache.maven.shared.dependency.tree.DefaultDependencyTreeBuilder.buildDependencyTree(DefaultDependencyTreeBuilder.java:139)
> at
> org.apache.maven.shared.dependency.graph.internal.Maven2DependencyGraphBuilder.buildDependencyGraph(Maven2DependencyGraphBuilder.java:55)
> at
> org.apache.maven.plugins.enforcer.AbstractBanDependencies.getDependenciesToCheck(AbstractBanDependencies.java:126)
> at
> org.apache.maven.plugins.enforcer.AbstractBanDependencies.execute(AbstractBanDependencies.java:90)
> at
> org.apache.maven.plugins.enforcer.EnforceMojo.execute(EnforceMojo.java:177)
> at
> org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:454)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:559)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:500)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:479)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:331)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:292)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:142)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:345)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:132)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:290)
> 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.classworlds.Launcher.launchEnhanced(Launcher.java:315)
> at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
> at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
> at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
> {quote}
--
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] (MNG-3959) Per-execution inherited flag ignored
[
https://jira.codehaus.org/browse/MNG-3959?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov reopened MNG-3959:
-
> Per-execution inherited flag ignored
>
>
> Key: MNG-3959
> URL: https://jira.codehaus.org/browse/MNG-3959
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: Inheritance and Interpolation
>Reporter: Dave Syer
>
> Per-execution inherited flag ignored. E.g.
> {code}
>
> org.apache.maven.plugins
> maven-antrun-plugin
>
>
> test
> initialize
> false
> ...
> {code}
> If you move the inherited element up to the plugin level it works, but then
> that applies to all executions, which isn't what is needed.
--
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] (MNG-3959) Per-execution inherited flag ignored
[
https://jira.codehaus.org/browse/MNG-3959?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov closed MNG-3959.
---
Resolution: Won't Fix
Won't fix for Maven 2.2.x, works in Maven 3.x
> Per-execution inherited flag ignored
>
>
> Key: MNG-3959
> URL: https://jira.codehaus.org/browse/MNG-3959
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: Inheritance and Interpolation
>Reporter: Dave Syer
>
> Per-execution inherited flag ignored. E.g.
> {code}
>
> org.apache.maven.plugins
> maven-antrun-plugin
>
>
> test
> initialize
> false
> ...
> {code}
> If you move the inherited element up to the plugin level it works, but then
> that applies to all executions, which isn't what is needed.
--
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] (MENFORCER-116) Require property rule interpolation does not work like profile activation
[
https://jira.codehaus.org/browse/MENFORCER-116?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=339977#comment-339977
]
Michael Osipov commented on MENFORCER-116:
--
Karl, give me a few days to re-evaluate the issue.
> Require property rule interpolation does not work like profile activation
> -
>
> Key: MENFORCER-116
> URL: https://jira.codehaus.org/browse/MENFORCER-116
> Project: Maven Enforcer Plugin
> Issue Type: Bug
> Components: Standard Rules
>Affects Versions: 1.0
>Reporter: Michael Osipov
>Priority: Critical
>
> The main benefit of profile activation is that a profile is activated by a
> property set *outside* of maven. It does not make any sense to active by a
> property if it is defined in the POM.
> If I set the following in my properties section:
> {noformat}
>
>
>
> {noformat}
> This would evaluate the property to "true" and pass the enforcer rule. It
> makes absolutely no sense. Properties should be evaluated the same way as in
> the profile activation. POM properties are always present, thus making the
> hole enforcer thing obsolete.
> This issue is related to MENFORCER-115.
--
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] (MNG-3959) Per-execution inherited flag ignored
[
https://jira.codehaus.org/browse/MNG-3959?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated MNG-3959:
Fix Version/s: (was: Issues to be reviewed for 3.x)
> Per-execution inherited flag ignored
>
>
> Key: MNG-3959
> URL: https://jira.codehaus.org/browse/MNG-3959
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: Inheritance and Interpolation
>Reporter: Dave Syer
>
> Per-execution inherited flag ignored. E.g.
> {code}
>
> org.apache.maven.plugins
> maven-antrun-plugin
>
>
> test
> initialize
> false
> ...
> {code}
> If you move the inherited element up to the plugin level it works, but then
> that applies to all executions, which isn't what is needed.
--
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] (MRELEASE-864) Maven Release Plugin releases SNAPSHOT instead of STABLE version
Jan Novotný created MRELEASE-864: Summary: Maven Release Plugin releases SNAPSHOT instead of STABLE version Key: MRELEASE-864 URL: https://jira.codehaus.org/browse/MRELEASE-864 Project: Maven Release Plugin Issue Type: Bug Components: Git Environment: Everywhere with maven-scm-provider-gitexe of version 1.9 (and maybe older) Reporter: Jan Novotný Attachments: Wrong_base_directory_used.patch If you have following project structure: - superproject [Git repository root] - projectA [release target] - projectB [release target] in other words you release subproject of a larger Git repository separately, you probably run at the same issue as we did. No recipe from above mentioned sources solves your problems and during release:prepare phase still no commit of stable pom.xml occurs. There is another bug in GitStatusConsumer class that checks output of the git status --porcelain command and verifies existency of the mentioned files on local filesystem. Regretfully it uses working directory instead of git repository root as the base folder and thus it constructs invalid path to the file where project folder directory is duplicated. Problem is better described here: http://blog.novoj.net/2014/01/24/maven-release-plugin-releases-snapshot-instead-of-stable-version -- 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] (MENFORCER-164) bannedDependencies searchTransitive=false failure
[
https://jira.codehaus.org/browse/MENFORCER-164?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Heinz Marbaise updated MENFORCER-164:
--
Fix Version/s: 1.3.2
> bannedDependencies searchTransitive=false failure
> -
>
> Key: MENFORCER-164
> URL: https://jira.codehaus.org/browse/MENFORCER-164
> Project: Maven Enforcer Plugin
> Issue Type: Bug
> Components: Standard Rules
>Affects Versions: 1.3.1
>Reporter: jieryn
>Assignee: Karl Heinz Marbaise
> Fix For: 1.3.2
>
>
> The bannedDependencies rule is too aggressive, especially when you have
> searchTransitive=false configured. Here is an example pom.xml which
> demonstrates the problem:
> {code}
> 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/xsd/maven-4.0.0.xsd";>
> 4.0.0
> org.apache.maven.plugins.enforcer
> banned-dependencies
> 1-SNAPSHOT
>
>
> org.springframework.ldap
> spring-ldap-core
> 1.3.2.RELEASE
>
>
>
> validate
>
>
> maven-enforcer-plugin
> 1.3.1
>
>
>
> enforce
>
>
>
>
>
> commons-lang:commons-lang
>
>
>
> false
>
>
>
>
>
>
>
> {code}
--
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] (MENFORCER-177) Support packagings for RequirePrerequisite rule, always ignore pom.
[ https://jira.codehaus.org/browse/MENFORCER-177?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Heinz Marbaise updated MENFORCER-177: -- Fix Version/s: (was: 1.4) 1.3.2 > Support packagings for RequirePrerequisite rule, always ignore pom. > --- > > Key: MENFORCER-177 > URL: https://jira.codehaus.org/browse/MENFORCER-177 > Project: Maven Enforcer Plugin > Issue Type: Improvement > Components: Standard Rules >Affects Versions: 1.3, 1.3.1 >Reporter: Robert Scholte >Assignee: Robert Scholte > Fix For: 1.3.2 > > > When developing a maven-plugin you can control which version should at least > be *used* by defining the prerequisite for Maven. For all packaging types it > specifies which version is required to *build* the project. > Since prerequisites aren't inherited and pom projects only generate a pom, > this type should always be ignored. > In general you probably only want to enforce this for maven-plugins. -- 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] (MENFORCER-164) bannedDependencies searchTransitive=false failure
[
https://jira.codehaus.org/browse/MENFORCER-164?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Heinz Marbaise reassigned MENFORCER-164:
-
Assignee: Karl Heinz Marbaise
> bannedDependencies searchTransitive=false failure
> -
>
> Key: MENFORCER-164
> URL: https://jira.codehaus.org/browse/MENFORCER-164
> Project: Maven Enforcer Plugin
> Issue Type: Bug
> Components: Standard Rules
>Affects Versions: 1.3.1
>Reporter: jieryn
>Assignee: Karl Heinz Marbaise
>
> The bannedDependencies rule is too aggressive, especially when you have
> searchTransitive=false configured. Here is an example pom.xml which
> demonstrates the problem:
> {code}
> 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/xsd/maven-4.0.0.xsd";>
> 4.0.0
> org.apache.maven.plugins.enforcer
> banned-dependencies
> 1-SNAPSHOT
>
>
> org.springframework.ldap
> spring-ldap-core
> 1.3.2.RELEASE
>
>
>
> validate
>
>
> maven-enforcer-plugin
> 1.3.1
>
>
>
> enforce
>
>
>
>
>
> commons-lang:commons-lang
>
>
>
> false
>
>
>
>
>
>
>
> {code}
--
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] (MENFORCER-116) Require property rule interpolation does not work like profile activation
[
https://jira.codehaus.org/browse/MENFORCER-116?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Heinz Marbaise closed MENFORCER-116.
-
Resolution: Not A Bug
Is this the case with 1.3.1? Or can we leave this closed? If not please reopen
the issue.
> Require property rule interpolation does not work like profile activation
> -
>
> Key: MENFORCER-116
> URL: https://jira.codehaus.org/browse/MENFORCER-116
> Project: Maven Enforcer Plugin
> Issue Type: Bug
> Components: Standard Rules
>Affects Versions: 1.0
>Reporter: Michael Osipov
>Priority: Critical
>
> The main benefit of profile activation is that a profile is activated by a
> property set *outside* of maven. It does not make any sense to active by a
> property if it is defined in the POM.
> If I set the following in my properties section:
> {noformat}
>
>
>
> {noformat}
> This would evaluate the property to "true" and pass the enforcer rule. It
> makes absolutely no sense. Properties should be evaluated the same way as in
> the profile activation. POM properties are always present, thus making the
> hole enforcer thing obsolete.
> This issue is related to MENFORCER-115.
--
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] (MENFORCER-178) Two rules are missing from doc links
[ https://jira.codehaus.org/browse/MENFORCER-178?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Heinz Marbaise closed MENFORCER-178. - Resolution: Duplicate Both are already fixed. > Two rules are missing from doc links > > > Key: MENFORCER-178 > URL: https://jira.codehaus.org/browse/MENFORCER-178 > Project: Maven Enforcer Plugin > Issue Type: Bug >Reporter: Benson Margulies > > These two aren't links. > requireActiveProfile - enforces one or more active profiles. > requireEnvironmentVariable - enforces the existence of an environment variable -- 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
