Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [m2e-dev] Project refreshes and rebuilds/autobuilds 


On 2014-05-03, 12:43, Anton Tanasenko wrote:




On Sat, May 3, 2014 at 6:13 PM, Igor Fedorenko <igor@xxxxxxxxxxxxxx
<mailto:igor@xxxxxxxxxxxxxx>> wrote:

    This is the part that might be tricky. Like I said, there are two
    interesting cases, when projects are closed or removed and when
    individual projects are built explicitly with workspace autobuild off.
    In both cases, some other projects may be affected and require
    resolution and rebuild when autobuild is turned on.


Sorry, I'm confused, I meant to leave the code that handles those cases
intact. There is actually a third case in there that handles newly
created projects.
I only propose to skip reaction to pom file changes, which will be
reacted upon during next build.


I am not sure not reacting to pom file changes is sufficient, see below.


    One way to achieve this is to touch affected projects' pom.xml files
    during resolution. This I believe will create pending resource change
    events that'll trigger build of the corresponding projects when
    autobuild is turned on.


There would be nothing to touch in case of a closed project.


Closed projects may affect resolution of other projects. For example, if
project A depends on B and B is closed while autobuild is off, A should
be rebuild when autobuild is turned back on.

Manual rebuild can have the same result. If B/pom.xml changes while
autobuild is off and B is rebuilt manually, A should be rebuilt when
autobuild is turned on. This is where I think your proposal does not
work because workspace change will be "consumed" by manual build.

But I think this is easy to solve. When B is built, m2e should resolve B
and all other projects that depend on B. This is the same as the current
implementation, only without dedicated background job.

So I think closed/removed projects is the only problem left before we
can get rid of background refresh job.

--
Regards,
Igor





    Another possibility is to maintain "pending update" queue somewhere in
    m2e and act on these updates when autobuild is turned on.


There is a PRE_BUILD workspace event broadcast prior to every build,
which could trigger refresh of the queued projects.
The listeners part of ProjectRegistryRefreshJob could then manage that
queue.
But this change will required a more thorough testing.

Talking of which, m2e-core-tests currently run with autobuild disabled,
there is an explicit call in AbstractMavenProjectTestCase. I guess this
is for performance reasons.
ProjectRegistryManagerTest would result in a lot of fails in particular.



    There are probably other ways to do this, I am not attached to
    particular approach at the moment, as long as the final solution works
    reliably and does not introduce any performance regressions.

    If we can figure out how to make this work, however, I think we will be
    able to remove ProjectRegistryRefreshJob and do all resolution as part
    of project build or configuration update.

    --
    Regards,
    Igor


    On 2014-05-03, 9:38, Anton Tanasenko wrote:

        When autobuild is on, ProjectRegistryRefreshJob doesn't actually
        react
        to file changes at all (only to project open/close/delete,
        comments at
        around line 156 also reflect that), refresh in this case happens
        as part
        of MavenBuilder invocation.
        If we make the same when autobuild is off, MavenBuilder (along
        with the
        refresh) will be invoked as soon as autobuild gets turned on.


        On Sat, May 3, 2014 at 2:28 PM, Igor Fedorenko
        <igor@xxxxxxxxxxxxxx <mailto:igor@xxxxxxxxxxxxxx>
        <mailto:igor@xxxxxxxxxxxxxx <mailto:igor@xxxxxxxxxxxxxx>>> wrote:



             On 2014-05-03, 5:52, Anton Tanasenko wrote:

                 And what about your stance on project refreshes with
        autobuild
                 off? Can
                 it be some option, that allows projects to become
        out-of-date on pom
                 changes until autobuild is turned back on?


             It really depends on how complicated the implementation
        will get. I like
             the idea in general, but I think reconciliation of the out
        of sync state
             when autobuild is turned on might be tricky. Haven't
        thought much about
             it though, so maybe I am wrong and there isn't much to it.

             --
             Regards,
             Igor

Back to the top