Re: enforcer: Differentiate between INFO, WARNING and ERROR per rule
Hi Mirko, So if I understand you correctly you want to specify if a rule should be considered as a warning or an error. And you want to specify if the enforcer-plugin should failOnError(default) or failOnWarning. IMHO enforcer rules should always succeed. Looking at the standard rules[1] I don't see one which should just warn. Which use case did you have in mind? -Robert [1] http://maven.apache.org/enforcer/enforcer-rules/index.html Op Tue, 13 Mar 2012 21:31:12 +0100 schreef Mirko Friedenhagen mfriedenha...@gmail.com: No thoughts about this? Should I just create a new ticket for this :-)? Regards Mirko On Wed, Mar 7, 2012 at 21:16, Mirko Friedenhagen mfriedenha...@gmail.com wrote: Hello, http://jira.codehaus.org/browse/MENFORCER-124 suggests a Rule-scoped fail property as feature. My suggestion would be something like this: - Add an optional qualifier per rule which differentiates between INFO, WARNING and ERROR (same as the loglevels) and - Make the rules log with this level on the console and - Make the build optionally fail only if there were violations with log level ERROR. For backward compatibility when no qualifier is given, rules will default to ERROR. What do you think? Regards Mirko -- http://illegalstateexception.blogspot.com/ https://github.com/mfriedenhagen/ https://bitbucket.org/mfriedenhagen/ - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: enforcer: Differentiate between INFO, WARNING and ERROR per rule
Hello Robert, yes, the failOnError(default=true) and failOnWarning(default=warn) is what I had in mind. E.g. http://maven.apache.org/enforcer/enforcer-rules/dependencyConvergence.html is making me headaches. While I see ideally maven should fail if dependencies diverge especially for libraries, having unittests all over the place for an application is often sufficient and applications integrating loads of dependencies by default, failing in the case of successful unit and integration tests would be a bit heavy IMO. And maybe while releasing I want to enforce stricter rules than during development. On a side note: the requireProperty rule would become more handy, when I could specify that projects inheriting from a global company parent pom had to define a differing value from that set in the company pom to enforce a policy that the pom url is pointing to another wiki page, e.g. Regards Mirko On Wed, Mar 14, 2012 at 18:28, Robert Scholte apa...@sourcegrounds.com wrote: Hi Mirko, So if I understand you correctly you want to specify if a rule should be considered as a warning or an error. And you want to specify if the enforcer-plugin should failOnError(default) or failOnWarning. IMHO enforcer rules should always succeed. Looking at the standard rules[1] I don't see one which should just warn. Which use case did you have in mind? -Robert [1] http://maven.apache.org/enforcer/enforcer-rules/index.html Op Tue, 13 Mar 2012 21:31:12 +0100 schreef Mirko Friedenhagen mfriedenha...@gmail.com: No thoughts about this? Should I just create a new ticket for this :-)? Regards Mirko On Wed, Mar 7, 2012 at 21:16, Mirko Friedenhagen mfriedenha...@gmail.com wrote: Hello, http://jira.codehaus.org/browse/MENFORCER-124 suggests a Rule-scoped fail property as feature. My suggestion would be something like this: - Add an optional qualifier per rule which differentiates between INFO, WARNING and ERROR (same as the loglevels) and - Make the rules log with this level on the console and - Make the build optionally fail only if there were violations with log level ERROR. For backward compatibility when no qualifier is given, rules will default to ERROR. What do you think? Regards Mirko -- http://illegalstateexception.blogspot.com/ https://github.com/mfriedenhagen/ https://bitbucket.org/mfriedenhagen/ - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Maven logger at warn level
Hello committers, As no one complains, I would like to know if someone can apply the patch and close http://jira.codehaus.org/browse/MNG-2570 Thank you Le 06/03/2012 01:51, Patrick GARCIA a écrit : Hello all, One moth ago, I have attach a maven patch to the jira MNG-2570 http://jira.codehaus.org/browse/MNG-2570 This patch add a new maven option -w --warinig to set the log level to LOGGING_LEVEL_WARN. With this patch any possible log level values will be accessible to users. Patrick -- - PaDy (Patrick Dany) - - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Thought: write some doc about how not to use snapshots?
On Thu, Aug 25, 2011 at 3:40 PM, Benson Margulies bimargul...@gmail.comwrote: On Thu, Aug 25, 2011 at 8:59 AM, Jesse Glick jesse.gl...@oracle.com wrote: On 08/25/2011 07:34 AM, Benson Margulies wrote: I discovered yesterday that one team had taken this idea to its local extreme, and were just using release versions, no -SNAPSHOTS at all. I can confirm this: we are using snapshot version (but i could also say no snapshot at all) during development; while publishing only non-snapshots. In fact, I spent 6 months training up collegues on maven's way of development.. and the only thing they couldn't really digest was publishing/downloading SNAPSHOT version to share things (and waiting for maven to check for the latest SNAPSHOT on the company's repo): they went simply SCM-updating and rebuilding (once) all those 5/10/15 upstream modules when they needed to be working on the very latest. To a certain extent, this could be a good simplification: when using SNAPSHOTS from a mainstream project, some degree of synchronization emerges between different teams to choose between using the last stable, the last snapshot or even a few-days-old version; whilst publishing SNAPs only allow to share the very-last. Using the company repo to share snapshots costs (pom configuration, ci, update checks during builds, disk space, etc.), and could be not always necessary or justified with respect to a rough/simplier build unstables, download stables approach. By the way it would seem safer if Maven refused to overwrite an artifact in the local repository that had been retrieved from a remote repository (as recorded by _maven.repositories), or conversely to download even an apparently newer remote update when there was already a locally built artifact. However this would prevent you from running e.g. 'svn co http://svn.apache.org/repos/asf/maven/maven-3/tags/maven-3.0.3 . mvn install' if you already happened to have ~/.m2/repository/org/apache/maven/maven-plugin-api/3.0.3/maven-plugin-api-3.0.3.jar for unrelated reasons. Perhaps a nonfatal warning could be issued when it looks like locally built and remotely downloaded artifacts might be colliding. +1 for the warning it'd help discover locally forgotten overwrites A published best practices document on this topic would be very much appreciated, The conversation is already a bit aged - has anything been created since then? Is any help needed? A small real example or even notes in the main documentation could be not so hard to write, based on current experiences. since the existing references leave this to your imagination. Can you point to the exact page(s) in maven doc? PC
