Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [m2e-users] Maven plugin and calling buildContext.refresh(File)

Hi

Some more questions below.

Regards
Grzegorz

On 2014-02-17 18:40, Igor Fedorenko wrote:
>
>
> On 2/17/2014, 11:24, Grzegorz Słowikowski wrote:
>> Hi All
>>
>> I have Maven plugin defining custom "play" packaging (for Play!
>> Framework 1.x http://www.playframework.com/) applications.
>> In latest release I added M2Eclipse integration
>> (see
>> http://maven-play-plugin.googlecode.com/svn/tags/plugin-1.0.0-beta7/play-maven-plugin/src/main/resources/META-INF/m2e/lifecycle-mapping-metadata.xml)
>>
>> I've read about BuildContext usage here:
>> https://wiki.eclipse.org/M2E_compatible_maven_plugins , but I have some
>> questions related to this functionality.
>>
>> 1. I wanted to test/debug "buildContext.refresh( someFile )" so I ran
>> Maven builds inside Eclipse, but I've always had the default
>> "org.sonatype.plexus.build.incremental.DefaultBuildContext"
>> implementation when I've debugged my code.
>> What should I do to get M2Eclipse implementation of BuildContext
>> interface:
>> org.eclipse.m2e.core.internal.builder.EclipseBuildContext
>> org.eclipse.m2e.core.internal.builder.EclipseIncrementalBuildContext
>> ?
>
> How do you inject BuildContext instance in your mojo? Using plugin-tools
> @Component, plexus @Requirement or jsr330 @Inject all should inject
> instance of EclipseBuildContext inside m2e.
>
>> 2. Sources and resources are processed by M2E completely differently. Is
>> calling "refresh" important for sources, resources or both, and why
>> (why not calling "refresh()" can lead to infinite rebuilds)?
>
> During project import and configuration update m2e needs to configure
> workspace project sources and resources folders. To do this, m2e runs
> maven build with empty resource delta and expects mojos do not produce
> any outputs. If your mojo does not properly use BuildContext API it will
> do more work than necessary, will create filesystem resources that may
> confuse other Eclipse workspace builders. Mojo execution may actually
> fail if it depends on outputs of other mojo executions.
I've made some import test. There are two builds during import: one
incremental
and one full. The first one is the one you wrote about above, I think.
Can you write, why there are two builds? What is the first one for? Should I
ignore the first one (incremental), because my mojos are bound to full
builds
only:
        <execute>
          <runOnIncremental>false</runOnIncremental>
          <runOnConfiguration>true</runOnConfiguration>
        </execute>
If so, why are they called at all? Or, amybe, should I do something special
in incremental build anyway?

>
> During workspace build mojo needs to check if its inputs have changed.
> Eclipse runs build on every workspace file modification, so if the mojo
> generates its outputs unconditionally, this will trigger new build,
> which will result in unconditional generation of mojo outputs and so on.
>
> Calling "refresh" also makes mojo outputs visible to eclipse workspace
> and other builders. Eclipse java compiler, for example, will not see
> sources generated by the mojo if they are not refreshed in the workspace.
>
> -- 
> Regards,
> Igor
>
>
>
>> I have some more questions, but I would like to receive responses for
>> the above two first. Thank you in advance.
>>
>> Regards
>>
>> Grzegorz Slowikowski
>> _______________________________________________
>> m2e-users mailing list
>> m2e-users@xxxxxxxxxxx
>> https://dev.eclipse.org/mailman/listinfo/m2e-users
>>
> _______________________________________________
> m2e-users mailing list
> m2e-users@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/m2e-users



Back to the top