Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [m2e-dev] Scanning for modified resources (BuildContext vs other means) 


On 2014-03-11, 2:40, Anders Hammar wrote:

Thanks Igor! I've mailed you my personal info privately.

The new incremental build API is very interesting. I've updated a few
Mojo plugins in the past with m2e support and the biggest issue I've
seen so far is the DefaultBuildContext implementation (used for
command-line executions) which effectively says everything has always
changed. Which has forced me to implemented separate detection in the
plugin depending on the BuildContext impl.
Are there any plans on providing a better BuildContext for command-line
executions?


Yes, our goal is to have incremental build API that works consistently
during command line build and inside IDE. Our primary targets are Maven
and m2e, but with little extra effort the API can be used from other
build tools or from plain main().



Also, looking into adding m2e compliance to the java.net
<http://java.net> jaxws-maven-plugin I've found an edge case. That
plugin supports specifying an external wsdl as the resource (by an URL).
Typically I would strongly argue against having external resources like
this, but it's a live case which I'm not sure how to handle with
incremental support. Any thoughts on this?


There is no built-in support, at least not yet, but the API allows
custom resource types, so you should be able to use it with URLs.
Up-to-date check is kinda tricky with remote resources, but maybe we'll
be able to come up with common solution that works for all/many usecases.

You should be all setup with takari-dev google group, so lets continue
this discussion there.

--
Regards,
Igor




/Anders


On Mon, Mar 10, 2014 at 7:22 PM, Igor Fedorenko <igor@xxxxxxxxxxxxxx
<mailto:igor@xxxxxxxxxxxxxx>> wrote:

    Cool. Can you email me your github userid and the email address you want
    me to subscribe to our dev google group?

    Just to give you quick overview of what you are signing up for ;-)

    We plan to release this in several stages.

    First we'll provide new version of BuildContext API, which we call
    "incremental build API" and also some high-level overview what it does.
    The main target audience here are Maven developers but other build tool
    authors may also be interested. Then we'll open (fully and properly)
    incremental Maven java compiler plugin. Last, but not least of course,
    will be m2e integration.

    Right now we are looking for feedback on incremental build API. Does the
    API work for your usecases? Do names make sense? Anything looks odd or
    unnecessary complicated? And so on.

    --
    Regards,
    Igor


    On 2014-03-09, 14:10, Anders Hammar wrote:

        Thanks for the very informative clarification, Igor!

        And yes, I would absolutely be interested in becoming an early
        adopter
        of the new version of the BuildContext API.

        /Anders


        On Fri, Mar 7, 2014 at 2:28 PM, Igor Fedorenko
        <igor@xxxxxxxxxxxxxx <mailto:igor@xxxxxxxxxxxxxx>
        <mailto:igor@xxxxxxxxxxxxxx <mailto:igor@xxxxxxxxxxxxxx>>> wrote:



             On 2014-03-07, 7:42, Anders Hammar wrote:

                 According to [1], it says that a maven plugin "MUST use
                 BuildContext to
                 skip execution when there none of relevant workspace
        resources
                 changed".

                 Is it required to use BuildContext, or can I use some
        other means to
                 determine if the plugin should skip execution? I'm
        asking as several
                 plugin already has a similar functionality through a
        stale file. I
                 appreciate that it might not be 100% the same, but
        close enough
                 IMHO.

                 So, bottom line, it the requirement to skip execution
        when there
                 hasn't
                 been any relevant resource changes or is the
        requirement to use
                 BuildContext to determine that?


             tl;dr yes, correct mojo implementation requires use of
        BuildContext

             All this applies to mojos that modify filesystem, i.e.
        create, modify or
             delete files. Mojos that only modify MavenProject state
        should be safe
             to run without any checks and m2e is expected to maintain
        consistent
             MavenProject.

             For mojos that do modify filesystem need to be aware of
        there build
             types

             * Configuration build is performed during project import and
             configuration update. Mojos are not expected to do any resource
             processing during configuration build and Eclipse/m2e use empty
             BuildContext to make mojos skip execution. Project is not
        fully setup at
             this point and mojo execution is likely to fail, because
        dependency
             classes are not available yet, for example. Even if
        execution does not
             fail, it will unnecessary slow down project import and
        configuration
             update.

             * Full build is performed when user selects
        "Project/Clean..." action
             and BuildContext provided by m2e will list all resources as
        modified.

             * Incremental build is performed on each workspace resource
             modification. To avoid endless workspace builds it is
        absolutely
             essential to to skip mojo execution if there are no
        relevant changes.
             Mojo execution may use other means to do that, I suppose,
        but you I'd
             still use BuildContext to make it easier to reason about mojo
             implementation.

             Btw, we are working on new version of BuildContext API that
        will provide
             proper incremental build behaviour during command line
        build too, so
             mojos will not need to implement custom stale file
        detection logic
             (which is pretty tricky to implement correctly). I may be
        able to give
             you access to the code if you are interested to become an
        early adopter.


             --
             Regards,
             Igor

                 /Anders

                 [1]
        http://wiki.eclipse.org/M2E_____compatible_maven_plugins
        <http://wiki.eclipse.org/M2E___compatible_maven_plugins>
                 <http://wiki.eclipse.org/M2E___compatible_maven_plugins
        <http://wiki.eclipse.org/M2E_compatible_maven_plugins>>

             ___________________________________________________
             m2e-dev mailing list
        m2e-dev@xxxxxxxxxxx <mailto:m2e-dev@xxxxxxxxxxx>
        <mailto:m2e-dev@xxxxxxxxxxx <mailto:m2e-dev@xxxxxxxxxxx>>
        https://dev.eclipse.org/____mailman/listinfo/m2e-dev
        <https://dev.eclipse.org/__mailman/listinfo/m2e-dev>
             <https://dev.eclipse.org/__mailman/listinfo/m2e-dev
        <https://dev.eclipse.org/mailman/listinfo/m2e-dev>>





        _________________________________________________
        m2e-dev mailing list
        m2e-dev@xxxxxxxxxxx <mailto:m2e-dev@xxxxxxxxxxx>
        https://dev.eclipse.org/__mailman/listinfo/m2e-dev
        <https://dev.eclipse.org/mailman/listinfo/m2e-dev>

    _________________________________________________
    m2e-dev mailing list
    m2e-dev@xxxxxxxxxxx <mailto:m2e-dev@xxxxxxxxxxx>
    https://dev.eclipse.org/__mailman/listinfo/m2e-dev
    <https://dev.eclipse.org/mailman/listinfo/m2e-dev>




_______________________________________________
m2e-dev mailing list
m2e-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/m2e-dev

Back to the top