Re: [m2e-dev] Scanning for changed files in a m2e compatible Maven plugi

[Igor Fedorenko <igor@xxxxxxxxxxxxxx>]

On 12-08-02 11:59 AM, Anders Hammar wrote:
> Ok, thanks guys. Just as I thought.
> I know of the Tesla build-avoidance stuff and I can now map what
> Jason's been talking about to my own recent experience.
>
> But checking on BuildContext.isIncremental() is ok for deciding on
> when to use BuildContext vs other solution?

BuildContext.isIncremental is really about incremental-vs-full build, so
it will be false for full workspace build. I think instanceof
DefaultBuildContext is more reliable way to tell
workspace-vs-commandline build.

> It would be awesome to get one single solution in place. But I guess
> there could be some tricky things to fix for a command-line solution?
> (the current stale check in the Mojo JAXB Maven plugin has some
> deficiencies)

I think current build-avoidance API already does pretty good job at
tracking source and output resources and detecting when something needs
to be regenerated or deleted when each target resource is generated from
one source only.

It does not help for the case when single output resource is generated
from multiple sources, like plexus component.xml or maven plugin.xml
descriptors for example. We had some ideas how to implement this but did
not really tried any of them.

We also did not find a nice way to incorporate build avoidance in maven
without making changes to maven core. This was my biggest concern as I
was not sure how many maven plugin developers will be willing to use
APIs only compatible with say maven 3.0.5.

--
Regards,
Igor


> /Anders
>
> On Thu, Aug 2, 2012 at 5:47 PM, Igor Fedorenko <igor@xxxxxxxxxxxxxx> wrote:
> > No, you are not missing anything. Currently BuildContext only allows
> > optimization of in-workspace build and you need to code out-of-workspace
> > optimization separately.
> >
> > We looked at providing more general build avoidance solution that would
> > work both at command line and inside m2e [1] we never really finished this.
> >
> > [1] https://github.com/etesla/tesla-build-avoidance
> >
> > --
> > Regards,
> > Igor
> >
> >
> > On 12-08-02 11:39 AM, Anders Hammar wrote:
> > > But the problem is that when building from command-line,
> > > DefaultBuildContext will not help me optimize the build so the plugin
> > > is only executed when there have been changes to the sources since the
> > > last CLI execution. The end result will be that the maven plugin is
> > > fully executed for every CLI build. Not good if it takes a long time
> > > to execute and there is no need to execute it.
> > > Or am I missing something?
> > >
> > > /Anders
> > >
> > > On Thu, Aug 2, 2012 at 5:34 PM, Igor Fedorenko <igor@xxxxxxxxxxxxxx>
> > > wrote:
> > > > No, you just use BuildContext. DefaultBuildContext is used when the
> > > > build runs on command line and m2e will inject workspace-aware
> > > > implementation when the build is invoked as part of workspace build.
> > > >
> > > > --
> > > > Regards,
> > > > Igor
> > > >
> > > >
> > > > On 12-08-02 11:22 AM, Anders Hammar wrote:
> > > > > I'm trying to make the JAXB Maven Plugin of Codehaus Mojo compatible
> > > > > with m2e as outlined in [1].
> > > > >
> > > > > I'd like the plugin to skip execution when there are no changes to the
> > > > > sources even when run from command-line (which there is already
> > > > > support). Hoping to be able to use the BuildContext features for this,
> > > > > I see that the DefaultBuildContext implementation does not support
> > > > > this (it will always say all files are newly created).
> > > > >
> > > > > So, my question is, do I need to implement two different code logics
> > > > > to decide if the sources have changed? I.e., when
> > > > > BuildContext.isIncremental() returns true I can use BuildContext, but
> > > > > when it returns false I have to implement some other logic.
> > > > >
> > > > > /Anders
> > > > >
> > > > > [1] http://wiki.eclipse.org/M2E_compatible_maven_plugins
> > > > > _______________________________________________
> > > > > m2e-dev mailing list
> > > > > m2e-dev@xxxxxxxxxxx
> > > > > https://dev.eclipse.org/mailman/listinfo/m2e-dev
> > > > _______________________________________________
> > > > m2e-dev mailing list
> > > > m2e-dev@xxxxxxxxxxx
> > > > https://dev.eclipse.org/mailman/listinfo/m2e-dev
> > >
> > > _______________________________________________
> > > m2e-dev mailing list
> > > m2e-dev@xxxxxxxxxxx
> > > https://dev.eclipse.org/mailman/listinfo/m2e-dev
> > _______________________________________________
> > m2e-dev mailing list
> > m2e-dev@xxxxxxxxxxx
> > https://dev.eclipse.org/mailman/listinfo/m2e-dev
> _______________________________________________
> m2e-dev mailing list
> m2e-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/m2e-dev