[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=18042styleName=TextprojectId=11540Create=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
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 ol...@apache.org: Hello, I'd like to release Apache Maven Shade Plugin 1.6. We fixed 6 issues: https://jira.codehaus.org/secure/ReleaseNote.jspa?version=18042styleName=TextprojectId=11540Create=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
Re: Thought: write some doc about how not to use snapshots?
On 15 March 2012 00:55, Paolo Compieta paolocompi...@gmail.com wrote: 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. 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
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: 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 mfriedenha...@gmail.com: 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 - 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=18042styleName=Te xtprojectId=11540Create=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
[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 properties 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=10341filterId=11471
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
