[GitHub] maven pull request: [MNG-5640] Change order to make sure participa...
GitHub user cstamas opened a pull request: https://github.com/apache/maven/pull/18 [MNG-5640] Change order to make sure participants are called Even in case of failing build. As currently, in case of failed build (`session.getResult().hasExceptions()` return `true`), return statement stops and execution never reaches participants for `afterSessionEnd`. You can merge this pull request into a Git repository by running: $ git pull https://github.com/cstamas/maven mng-5640 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/maven/pull/18.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #18 commit ab164dc41878b13013b5bf89b337aa990f0686e8 Author: Tamas Cservenak ta...@cservenak.net Date: 2014-05-30T13:26:54Z [MNG-5640] Change order to make sure participants are called Even in case of failing build. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. --- - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
[GitHub] maven pull request: [MNG-5640] Make sure participants are called a...
Github user jvanzyl commented on the pull request: https://github.com/apache/maven/pull/18#issuecomment-44653025 Can you squash this please. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. --- - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
[GitHub] maven pull request: [MNG-5640] Make sure participants are called a...
Github user cstamas commented on the pull request: https://github.com/apache/maven/pull/18#issuecomment-44653198 Done --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. --- - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Github pull requests for Maven Core
I'm happy to look at pull requests but in the future can anyone making a pull request please squash your commits before making the pull request. Eventually I want to use Gerrit and create a mechanism where pull requests can be tested against the ITs to make it easier for contributors to know they haven't broken anything. Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl http://twitter.com/takari_io - We know what we are, but know not what we may be. -- Shakespeare
Re: Github pull requests for Maven Core
Am 2014-05-30 15:57, schrieb Jason van Zyl: I'm happy to look at pull requests but in the future can anyone making a pull request please squash your commits before making the pull request. Eventually I want to use Gerrit and create a mechanism where pull requests can be tested against the ITs to make it easier for contributors to know they haven't broken anything. I am about to open an issue with INFRA to inquire how a default PR procedure should look like with the mirrored repos at Github. I think we need a common approach for the entire ASF. Michael - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Github pull requests for Maven Core
On 30 May 2014 14:57, Jason van Zyl ja...@takari.io wrote: I'm happy to look at pull requests but in the future can anyone making a pull request please squash your commits before making the pull request. Eventually I want to use Gerrit and create a mechanism where pull requests can be tested against the ITs to make it N not Gerrit. If they are pull requests in github then use github tooling to interact with them. A pull request builder on our CI system will be sufficient (once I get the build isolation plugin for Jenkins so that we don't risk drive-by hacking of ASF hardware). Alternatively I am sure I could get my employers to donate some build minutes on our hardware to do the pull request building right now. easier for contributors to know they haven't broken anything. Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl http://twitter.com/takari_io - We know what we are, but know not what we may be. -- Shakespeare
Re: Github pull requests for Maven Core
On May 30, 2014, at 10:42 AM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: On 30 May 2014 14:57, Jason van Zyl ja...@takari.io wrote: I'm happy to look at pull requests but in the future can anyone making a pull request please squash your commits before making the pull request. Eventually I want to use Gerrit and create a mechanism where pull requests can be tested against the ITs to make it N not Gerrit. If they are pull requests in github then use github tooling to interact with them. I'm going to use whatever is most effective for me trying to work with someone else. If I'm going to try and teach new people about the core and have longer term dialogs over changes I will use whatever I think works best for the work at hand. For smaller things squashed pull-request are fine, for larger more significant changes I'm going to try Gerrit. I'm not forcing my workflow on you. A pull request builder on our CI system will be sufficient (once I get the build isolation plugin for Jenkins so that we don't risk drive-by hacking of ASF hardware). Alternatively I am sure I could get my employers to donate some build minutes on our hardware to do the pull request building right now. easier for contributors to know they haven't broken anything. Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl http://twitter.com/takari_io - We know what we are, but know not what we may be. -- Shakespeare Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl http://twitter.com/takari_io - happiness is like a butterfly: the more you chase it, the more it will elude you, but if you turn your attention to other things, it will come and sit softly on your shoulder ... -- Thoreau
Re: Github pull requests for Maven Core
Am 2014-05-30 15:57, schrieb Jason van Zyl: I'm happy to look at pull requests but in the future can anyone making a pull request please squash your commits before making the pull request. Eventually I want to use Gerrit and create a mechanism where pull requests can be tested against the ITs to make it easier for contributors to know they haven't broken anything. Issue created: https://issues.apache.org/jira/browse/INFRA-7836 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [GitHub] maven-enforcer pull request: [MENFORCER-193]: Add new rule: Banned...
Hi Simon, so after checking it i found the point... I have defined mirrorOf * as usual in case of using a repository manager...in my settings.xml which looks like the following: mirrors mirror idnexus/id mirrorOf*/mirrorOf urlhttp://.../nexus/../url /mirror /mirrors So with the above i can add as much repository entries in my settings as well as in my pom.xml and the rule will NOT warning/break my build with it...except if i explicitly exclude them in the mirrorOf via things like this: mirrorOf*,!WhatEver/mirrorOf This brings me to two points: First: It would be nice if you could add an appropriate documentation (enforcer-rules/src/site/apt/) which exactly describes the differences to the requireNoRepository rule and give a good examples of the use cases which means not using mirrorOf as above etc. After this enhancement of the patch (? submission to large for patch) i would appreciate to pick up your patch(?) and add it to extra-enforcer-rules (this will get a release faster i think) or may be the default rules (after discussion on the dev list with the other dev's) I don't know the exact procedure with such kind of submissions without paper Apart from the above you might can check if it's possible to enhance the rule in that way to identify the repository entries in settings.xml/pom independent of the mirrorOf settings (may be via an option). Kind regards Karl-Heinz Marbaise PS.: It's not necessary to quote the answers of the others here on the dev list to posts cause obviously I'm subscribed on the dev list and I'm following the discussion. On 5/29/14 1:52 PM, Wang, Simon wrote: Hi, Karl, Thanks for your comments. I did dig into requireNoRepositories.html, the purpose for that rule is: detect whether pom and pom’s parents contains repositories definition. That make sense to guide users to use correct convention (not define repositories in pom files). But “BannedRepositories” is different purpose, it’s just like “BannedDependencies”. This rule is major for those “maven repository migration” case. Some users used to have old repositories, those repositories might be defined in pom.xml or settings.xml. This rule could benefit on these cases a lot. It will detect banned repositories from maven session context instead of only pom.xml and parents. After all, requireNoRepositories.html is trying to help users to follow correct maven convention. but “BannedRepositories” is trying to avoid misuse incorrect repositories. Especially in enterprise environment. Regards Simon On May 29, 2014, at 7:21 PM, Karl Heinz Marbaise khmarba...@gmx.de wrote: Hi Simon, I have taken a look into your suggestions I have a couple of thoughts about it ... First there exists already a rule to avoid repositories (http://maven.apache.org/enforcer/enforcer-rules/requireNoRepositories.html) which can be used and is has an option to allow particular repositories by using a white-list of allowed repository based on the repository id. like this: requireNoRepositories allowedRepositories allowedRepositorycodehausSnapshots/allowedRepository /allowedRepositories ... /requireNoRepositories So the question is why adding a complete new rule instead of enhancing the existing by your idea using the url as identification for the repository which i think is a really good idea...so users are not able to forge the repository they use by using a different id only the url is used to identify the allowed repositories. Kind regards Karl-Heinz Marbaise - 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
