no, extension are not loaded on this precise method: there is a TODO in the
interface about this, and when you read DefaultMaven, you see the reason why
this method can't have extensions = too early = the TODO comment
Regards,
Hervé
Le mardi 20 mai 2014 21:20:36 Igor Fedorenko a écrit :
> Mave
Le mercredi 21 mai 2014 11:14:05 William Ferguson a écrit :
> Yes immutable objects are the big plus.
>
> But I also find that final locals vastly improve code structure. IME the
> vast majority of objects are set once and never modified. Any attempt to do
> so is generally a sign of a bug. Having
GitHub user william-ferguson-au opened a pull request:
https://github.com/apache/maven-shared/pull/7
Ensuring that the multi-module-plugin is built before the multi-module-test
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/will
+1
On Tue, May 20, 2014 at 7:56 PM, Olivier Lamy wrote:
> +1
>
> On 19 May 2014 06:54, Hervé BOUTEMY wrote:
> > Hi,
> >
> > We solved 3 issues:
> >
> http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=12730&styleName=Html&version=20027
> >
> > There are still a couple of issues left in
MavenLifecycleParticipant comes from a build extension, so build
extensions are loaded for sure.
Most likely the problem has to do with thread context classloader, you
need to set it to project extensions realm (as returned by
MavenProject.getClassRealm) to be able to lookup project build
extensi
Yes immutable objects are the big plus.
But I also find that final locals vastly improve code structure. IME the
vast majority of objects are set once and never modified. Any attempt to do
so is generally a sign of a bug. Having the compiler catch that is a real
boon.
On Wed, May 21, 2014 at 9:4
Yes, you could set a low but effective bar and enforce that via build.
And in fact checkstyle can be used to enforce licence so it becomes a
superset of rat.
On Wed, May 21, 2014 at 9:49 AM, Hervé BOUTEMY wrote:
> Le mardi 20 mai 2014 09:52:26 William Ferguson a écrit :
> > On Tue, May 20, 2014
Hi Herve,
I am using MLCP#afterProjectsRead.
Unfortunately the extensions don't seem to be loaded at that point either.
William
On Wed, May 21, 2014 at 10:03 AM, Hervé BOUTEMY wrote:
> if you look at AbstractMavenLifecycleParticipant source file:
>
> /**
> * Invoked after MavenSession
if you look at AbstractMavenLifecycleParticipant source file:
/**
* Invoked after MavenSession instance has been created.
*
* This callback is intended to allow extensions to inject execution
properties,
* activate profiles and perform similar tasks that affect MavenProjec
+1
On 19 May 2014 06:54, Hervé BOUTEMY wrote:
> Hi,
>
> We solved 3 issues:
> http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=12730&styleName=Html&version=20027
>
> There are still a couple of issues left in JIRA:
> http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=true&pid=127
Le mardi 20 mai 2014 09:52:26 William Ferguson a écrit :
> On Tue, May 20, 2014 at 5:47 AM, Hervé BOUTEMY wrote:
> > > 1) Is there no automatic checkstyle verification as part of the build?
> > > We
> > > use it in the android-maven-plugin and I though it was standard practice
> > > across the Mave
Le mardi 20 mai 2014 09:59:24 Jason van Zyl a écrit :
> On May 19, 2014, at 7:52 PM, William Ferguson
wrote:
> > One of the Maven Java code conventions (listed on that page) is to
> >
> >- Avoid using final modifier on all member variables and arguments.
> >
> > I was just querying the sani
On May 19, 2014, at 7:52 PM, William Ferguson
wrote:
>
> One of the Maven Java code conventions (listed on that page) is to
>
>- Avoid using final modifier on all member variables and arguments.
>
> I was just querying the sanity of that. All the other code conventions
> either make sens
13 matches
Mail list logo
