[jira] Subscription: Design & Best Practices
Issue Subscription Filter: Design & Best Practices (24 issues) Subscriber: mavendevlist Key Summary MNG-2184Possible problem with @aggregator and forked lifecycles https://jira.codehaus.org/browse/MNG-2184 MNG-612 implement conflict resolution techniques https://jira.codehaus.org/browse/MNG-612 MNG-1563how to write integration tests https://jira.codehaus.org/browse/MNG-1563 MNG-474 performance improvement for forked lifecycles https://jira.codehaus.org/browse/MNG-474 MNG-4656Declarative plugins similar to "jsp tags" or "jsf composites" https://jira.codehaus.org/browse/MNG-4656 MNG-139 server definitions should be reusable - review use of repository IDs https://jira.codehaus.org/browse/MNG-139 MNG-1381best practices: testing strategies https://jira.codehaus.org/browse/MNG-1381 MNG-1950Ability to introduce new lifecycles phases https://jira.codehaus.org/browse/MNG-1950 MNG-2125[doc] when and how to define plugins in a pom https://jira.codehaus.org/browse/MNG-2125 MNG-2381improved control over the repositories in the POM https://jira.codehaus.org/browse/MNG-2381 MNG-4713${basedir} variable makes portable builds overly difficult https://jira.codehaus.org/browse/MNG-4713 MNG-367 best practices: multi-user installation https://jira.codehaus.org/browse/MNG-367 MNG-41 best practices: site management https://jira.codehaus.org/browse/MNG-41 MNG-868 Use uniform format for and other tags https://jira.codehaus.org/browse/MNG-868 MNG-1425best practices: the location of configuration files vs resources https://jira.codehaus.org/browse/MNG-1425 MNG-1463best practices: plugin inheritance for a multi project build https://jira.codehaus.org/browse/MNG-1463 MNG-125 guarded mojo execution https://jira.codehaus.org/browse/MNG-125 MNG-416 best practices: multiple profile deployments https://jira.codehaus.org/browse/MNG-416 MNG-657 possible chicken and egg problem with extensions https://jira.codehaus.org/browse/MNG-657 MNG-1441Starting thinking about a proper distributed repository mechanism a la CPAN https://jira.codehaus.org/browse/MNG-1441 MNG-1569Make build process info read-only to mojos, and provide mechanism for explicit out-params for mojos to declare https://jira.codehaus.org/browse/MNG-1569 MNG-1867deprecate system scope, analyse other use cases https://jira.codehaus.org/browse/MNG-1867 MNG-1423best practices: setting up multi-module build https://jira.codehaus.org/browse/MNG-1423 MNG-1468best practices: version management in multi project builds https://jira.codehaus.org/browse/MNG-1468 You may edit this subscription at: https://jira.codehaus.org/secure/FilterSubscription!default.jspa?subId=10341&filterId=11471 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Apache Maven Shade Plugin 1.6
+1 Hervé Le jeudi 15 mars 2012 10:56:34 Olivier Lamy a écrit : > Hello, > I'd like to release Apache Maven Shade Plugin 1.6. > > We fixed 6 issues: > > https://jira.codehaus.org/secure/ReleaseNote.jspa?version=18042&styleName=Te > xt&projectId=11540&Create=Create > > Staging repo: https://repository.apache.org/content/repositories/maven-078/ > Staged site: http://maven.apache.org/plugins/maven-shade-plugin-1.6 > > [-1] > [0] > [+1] > > > > Thanks, - 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
Hi Mirko, I'd prefer to fix your pain in the rule itself, for example by adding the dependency-scope (if that would help). About the release: it's already a critical process, so to add suddenly extra rules could be quite annoying. Anyhow, you'll need to use a release-profile here, you're free to add extra enforcer rules there. So I'm still not convinced. -Robert [1] http://jira.codehaus.org/browse/MENFORCER-118 Op Wed, 14 Mar 2012 20:58:36 +0100 schreef Mirko Friedenhagen : 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 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 : 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 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 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
RPMs for Maven 3?
Hi, I'm trying to install Maven 3 in automatically generated CentOS VM images, and having Maven 3 and plugins available as RPMs would help greatly with this effort. How hard would it be to augment the CI setup that creates the Maven packages today to also generate RPMs for RHEL/CentOS? Perhaps the Maven RPM plugin (http://mojo.codehaus.org/rpm-maven-plugin/) can be used for this purpose? I looked at jpackage.org but the latest Maven version there is too old (2.0.7). Thanks, Jos -- Jos Backus jos at catnook.com - 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 15 March 2012 00:55, Paolo Compieta wrote: > On Thu, Aug 25, 2011 at 3:40 PM, Benson Margulies > wrote: > >> On Thu, Aug 25, 2011 at 8:59 AM, Jesse Glick >> 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. What I tend to favour is never publishing -SNAPSHOTs to remote repositories... on the basis that if it is good enough to be pushed to a remote repo, it is good enough to release ;-) I normally check out all the projects I am working on, create a local "aggregator" pom that just pulls all the different projects into one build. I then use a prototype extension I have for the versions maven plugin (*not released yet* as you really need to know its limits) mvn versions:link-from-reactor from that aggregator pom and that associates all the dependencies to the version in the reactor. Then "mvn clean install" and I am good to go with everything using the code I checked out. One of these days I will iron out the bugs in versions:link-from-reactor and release the code for it... but until then you will just have to dream! ;-) -Stephen - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Apache Maven Shade Plugin 1.6
Oups, I missed few things in this mail. Guide to testing staged releases: http://maven.apache.org/guides/development/guide-testing-releases.html Vote open for 72 hours. 2012/3/15 Olivier Lamy : > Hello, > I'd like to release Apache Maven Shade Plugin 1.6. > > We fixed 6 issues: > > https://jira.codehaus.org/secure/ReleaseNote.jspa?version=18042&styleName=Text&projectId=11540&Create=Create > > Staging repo: https://repository.apache.org/content/repositories/maven-078/ > Staged site: http://maven.apache.org/plugins/maven-shade-plugin-1.6 > > [-1] > [0] > [+1] > > > > Thanks, > -- > Olivier Lamy > Talend: http://coders.talend.com > http://twitter.com/olamy | http://linkedin.com/in/olamy -- Olivier Lamy Talend: http://coders.talend.com http://twitter.com/olamy | http://linkedin.com/in/olamy - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
[VOTE] Apache Maven Shade Plugin 1.6
Hello, I'd like to release Apache Maven Shade Plugin 1.6. We fixed 6 issues: https://jira.codehaus.org/secure/ReleaseNote.jspa?version=18042&styleName=Text&projectId=11540&Create=Create Staging repo: https://repository.apache.org/content/repositories/maven-078/ Staged site: http://maven.apache.org/plugins/maven-shade-plugin-1.6 [-1] [0] [+1] Thanks, -- Olivier Lamy Talend: http://coders.talend.com http://twitter.com/olamy | http://linkedin.com/in/olamy - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org