Argh .. I think I finally get it - thanks Igor.
On Sat, May 24, 2014 at 11:03 AM, William Ferguson
william.fergu...@xandar.com.au wrote:
Thanks Igor.
A correct LifeCycleParticipant implementation should always scope
component lookups to the current project's classloader and should use
Github user asfgit closed the pull request at:
https://github.com/apache/maven/pull/14
---
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
Hi,
does it take special permissions on Github to process pull requests?
Neither am I allowed to perform the merge from the website directly, nor
does it display the command line steps as described in the GH help.
Close is not available to me too.
I simply pulled (PL 14) into my local repo
LifeCycleParticipant#afterProjectsRead is called after projects pom.xml
are read and MavenProject instances created but *before* actual build
starts. It is called for entire session and not any reactor project in
particular.
--
Regards,
Igor
On 2014-05-23, 21:03, William Ferguson wrote:
Thanks
Yes, I'm interested as well.
On May 24, 2014, at 9:33 AM, Michael Osipov micha...@apache.org wrote:
Hi,
does it take special permissions on Github to process pull requests?
Neither am I allowed to perform the merge from the website directly, nor does
it display the command line steps
Does this help?
https://help.github.com/articles/using-pull-requests
--
Alexander Kriegisch
Am 24.05.2014 um 16:07 schrieb Jason van Zyl ja...@takari.io:
Yes, I'm interested as well.
On May 24, 2014, at 9:33 AM, Michael Osipov micha...@apache.org wrote:
Hi,
does it take special
Le samedi 24 mai 2014 11:10:04 William Ferguson a écrit :
parameters and local variables are not considered final: there is nothing
wrong
with modifying their value, and nothing good to get by forcing them to be
final
But there *is* value is defining them to be final.
If you as
Le samedi 24 mai 2014 05:15:31 Manfred Moser a écrit :
I totally agree with William here. I also think that any standard that is
not enforced easily is pointless.
+1
I measure it every time I take time to run the Checkstyle report and fix every
little inconsistency we made over time
Thats why
As for necessary permissions:
https://help.github.com/articles/what-are-the-different-access-permissions
--
Alexander Kriegisch
Am 24.05.2014 um 17:09 schrieb Alexander Kriegisch alexan...@kriegisch.name:
Does this help?
https://help.github.com/articles/using-pull-requests
--
Alexander
The mechanics of processing PRs from repos we have access to is all good. But
the Apache repos on Github I'm not sure who actually owns them, I assume ASF
infra. For any moderately sized PR I add the PR as a remote and process it
locally. But for simple patches I really would just like to hit
Am 2014-05-24 17:09, schrieb Alexander Kriegisch:
Does this help?
https://help.github.com/articles/using-pull-requests
This can't help becuase the repos aren't located at github but at apache.
-
To unsubscribe, e-mail:
Am 2014-05-24 17:38, schrieb Alexander Kriegisch:
As for necessary permissions:
https://help.github.com/articles/what-are-the-different-access-permissions
That's good but how does one know whether he as Write Access Teams
Repository Access' or not. Especially for mirrored repos.
Am 2014-05-24 18:39, schrieb Jason van Zyl:
The mechanics of processing PRs from repos we have access to is all good. But
the Apache repos on Github I'm not sure who actually owns them, I assume ASF
infra. For any moderately sized PR I add the PR as a remote and process it
locally. But for
I am not a Maven or other Apache committer. I just wanted to help and saw the
initial question about GitHub PRs which I have answered. I really cannot say
anything intelligent about the follow-up questions though, only one general
thing: Now you know what type of access right you need for
Please don't use Github PL merge functionality. This will create merge
commits... and I seriously dislike merge commits, hate them, actually.
--
Regards,
Igor
On 2014-05-24, 12:39, Jason van Zyl wrote:
The mechanics of processing PRs from repos we have access to is all
good. But the Apache
Am 2014-05-24 18:57, schrieb Igor Fedorenko:
Please don't use Github PL merge functionality. This will create merge
commits... and I seriously dislike merge commits, hate them, actually.
Are you able to share your experience by improving the Git Convention on
the Maven website? Me and others
I don't know what git issues you mean, but I can explain why I dislike
github pull requests.
My problem with pull-requests is two-fold.
First, they create merge commits, which pollute commit history and make
it much harder to comprehend. I've seen projects with tens of parallel
commit lanes
GitHub user OhadR opened a pull request:
https://github.com/apache/maven-scm/pull/14
Update tfs.apt
working with check-in policies:
---
scm:tfs:https://tlvtfsnlbprd:8080:True:ohad:$/path/to/project
---
You can merge this pull request into a Git repository by
Am Sat, 24 May 2014 19:06:24 +0200
schrieb Michael Osipov micha...@apache.org:
Am 2014-05-24 18:57, schrieb Igor Fedorenko:
Please don't use Github PL merge functionality. This will create
merge commits... and I seriously dislike merge commits, hate them,
actually.
Are you able to share
Am Sat, 24 May 2014 13:46:42 -0400
schrieb Igor Fedorenko i...@ifedorenko.com:
Second, pull-requests encourage multiple commits, when in most cases
each pull-request corresponds to single logic change. This, too, makes
commit history harder to comprehend for no good reason.
That is actually
20 matches
Mail list logo