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

Hm, no, removing getVersionlessKey() doesn't help due to the fact that, counterintuitively, VersionRange.createFromVersionSpec("1.0").containsVersion(...) will return true for any version passed.


On Thu, May 1, 2014 at 1:15 PM, Anton Tanasenko <atg.sleepless@xxxxxxxxx> wrote:
Ok, there is a code at the end of ProjectRegistryManager.refreshPhase2() which triggers update of all projects that depend on _versionless_ artifact:

    // if our dependencies changed, recalculate everyone who depends on us
    // this is needed to deal with transitive dependency resolution in maven
    if(oldCapabilities != null && hasDiff(oldRequirements, requirements)) {
      for(Capability capability : oldCapabilities) {
        context.forcePomFiles(newState.getDependents(capability.getVersionlessKey(), true));
      }
    }

Can it be safely changed to getDependents(capability, true), which does an additional version check? I'm concerned about the 'transitive dependency' part of comment: dependent artifacts might potentially have the current project's version in omitted/excluded state somewhere in dependency tree. Do they still need to be refreshed in such case?


On Thu, May 1, 2014 at 12:46 PM, Anton Tanasenko <atg.sleepless@xxxxxxxxx> wrote:

On Thu, May 1, 2014 at 2:14 AM, Igor Fedorenko <igor@xxxxxxxxxxxxxx> wrote:


On 2014-04-30, 12:49, Anton Tanasenko wrote:
Hi,

I'll pop a separate thread on this topic.

It seems to me that m2e, when it sees a change in project A, tries to
build any project that has A as a dependency irregardless of version of
project A.
So if I have 10 projects that have A:1.0 as a dependency and I make a
change in project A:1.1-SNAPSHOT, all those projects get rebuild.
Is that an intended behaviour?


No, this is not expected. Please open a bug with example projects and
exact steps to reproduce the problem. Patch to fix the problem is also
welcome ;-) 

I'll try to debug into details and see what causes that.
 
 


I also observed that, if workspace autobuild is enabled, project A
refresh happens as MavenBuilder tries to obtain MavenProjectFacade, and
if autobuild is disabled, it is refreshed
as ProjectRegistryRefreshJob.resourceChange() gets notified.

I went as far as to add a dirty if clause, which excludes pom.xml from
the list of meta_data files to which ProjectRegistryRefreshJob reacts,
and it effectively did what I really wanted: project gets rebuilt as
soon as autobuild gets enabled (or any other event which will try to
refresh maven project). But I don't know of any side-effects this might
cause.

As I mentioned in another thread, there are two cases that are not
covered by builder

* closed and removed projects. Say you have projects A and B, A depends
on B. Workspace autobuild is off and B is removed from workspace.
Project A needs to be rebuild next time autobuild is enabled.

* Project->Build_Project action when autobuild is off. Say you have
projects A and B, A depends on B. Workspace autobuild is off. User makes
change to B/pom.xml then calls Project->Build_Project for B. This will
build B, resolve B/pom.xml and invalidate any A's project registry
entries. Project A needs to be rebuild next time autobuild is enabled.
 
This hack didn't affect PRE_CLOSE and POST_DELETE events, so those still do trigger dependency updates when autobuild is off.
I'll install this in my eclipse and see if it brings any problems with it.
Inline patch:

diff --git a/org.eclipse.m2e.core/src/org/eclipse/m2e/core/internal/project/registry/ProjectRegistryRefreshJob.java b/org.eclipse.m2e.core/src/org/eclipse/m2e/core/internal/project/registry/ProjectRegistryRefreshJob.java
index faa0704..0a2b121 100644
--- a/org.eclipse.m2e.core/src/org/eclipse/m2e/core/internal/project/registry/ProjectRegistryRefreshJob.java
+++ b/org.eclipse.m2e.core/src/org/eclipse/m2e/core/internal/project/registry/ProjectRegistryRefreshJob.java
@@ -31,2 +31,3 @@
 import org.eclipse.core.runtime.OperationCanceledException;
+import org.eclipse.core.runtime.Path;
 import org.eclipse.core.runtime.Status;
@@ -195,2 +196,4 @@
     for(IPath path : ProjectRegistryManager.METADATA_PATH) {
+      if(path.equals(new Path("pom.xml")))
+        continue;
       IResourceDelta delta = projectDelta.findMember(path); 

--
Regards,
Igor



On Wed, Apr 30, 2014 at 2:28 PM, Igor Fedorenko <igor@xxxxxxxxxxxxxx
<mailto:igor@xxxxxxxxxxxxxx>> wrote:

    If dependency resolution performance in m2e is slower compared to
    command line build, this is a bug. Please open a bug report and provide
    example project and steps to reproduce the problem.

    I think you are looking to introduce a preference to honour workspace
    autobuild state. When enabled, which I think should be the new default,
    m2e will only perform dependency resolution workspace build. Current
    behaviour is implemented in ProjectRegistryManager and
    ProjectRegistryRefreshJob and the idea is to always keep project
    registry in sync with pom.xml files. The proper implementation of the
    new resolution mode should allow temporary inconsistencies in the
    project registry, which are reconciled during the next build. This is
    actually pretty significant change to m2e, but I don't know how much
    code will have to change without trying.

    Couple of interesting scenarios to consider. Project is closed or
    deleted from the workspace. Projects that depend on the closed/removed
    projects will need to be re-resolved during the next build. Another
    interesting scenario is when the user builds individual projects when
    autobuild is off. Projects that depend on the projects being built may
    need to be re-resolved when their are built the next time.

    --
    Regards,
    Igor


    On 2014-04-30, 4:34, Anton Tanasenko wrote:

        Hi,
        I'm not sure if it's on the same topic, but at least it definitely
        affects performance part. So here goes:
        Another great feature would be (and I think it was mentioned on
        m2e-dev
        or m2e-users a couple of times) is to temporarily disable dependency
        updates on pom modifications.
        We have a lot of smaller dependency artifacts, and when changing
        version
        of one of them, I have to wait a considerable amount of time
        before I
        can do anything to other files in the workspace, be it switching
        branches, or updating poms.
        Disabling Project -> Build automatically doesn't disable dependency
        updates. It's a huge paint to switch releases of 5-6 projects.
        Better
        way would be disabling m2e doing anything, make any workspace
        modifications, optionally check something using faster cmd-line
        builds
        and turing m2e back on, triggering single rebuilt of all changed
        projects.
        I would gladly help with implementing such thing, given it doesn't
        require huge changes to core m2e, and I'd definitely need
        directions.


        On Wed, Apr 30, 2014 at 4:01 AM, Daniel Johnson (danijoh2)
        <danijoh2@xxxxxxxxx
        <mailto:danijoh2@xxxxxxxxx> <mailto:danijoh2@xxxxxxxxx

        <mailto:danijoh2@xxxxxxxxx>>> wrote:

             Yep. To be honest I haven’t spent much time to figure out
        what is
             offered
             by build lifecycle integration, but in our current state we
        do not
             use it.

             Thanks,
             Daniel

             On 4/29/14, 4:05 PM, "Igor Fedorenko" <igor@xxxxxxxxxxxxxx
        <mailto:igor@xxxxxxxxxxxxxx>
             <mailto:igor@xxxxxxxxxxxxxx <mailto:igor@xxxxxxxxxxxxxx>>>

        wrote:

              >So, in other words, you only use m2e dependency
        management and are not
              >interested in build lifecycle integration, did I get this
        right?
              >
              >--
              >Regards,
              >Igor
              >
              >On 2014-04-29, 18:04, Daniel Johnson (danijoh2) wrote:
              >> Hey Igor,
              >>
              >> Sorry, I guess the class path is rebuilt automatically.
        For some
             reason
              >>I
              >> thought this is what updating the project configuration
        was for.
             I will
              >> have to watch carefully to see what changes cause the
        project
              >> configuration out of date error, stay tuned.
              >>
              >> As for plugins I ignore, I ignore any that cause an
        error on the
              >>project!
              >> However, I always add it to my Eclipse preferences
        instead of to the
              >> project POM. We have hundreds of components that point
        to a common
              >>parent
              >> but are not part of a multi-module build. If we add the
        rules to the
              >> parent we have to go through and update all projects to
        use the new
              >>parent
              >> version, this is certainly something we will consider
        doing.
             That said,
              >>I
              >> agree with you that a user should be warned, hence why
        I support
              >>changing
              >> it from an error to a warning.
              >>
              >> As for the list of plugins, pretty much all the tycho
        plugins,
              >> maven-dependency-plugin, maven-help-plugin,
        maven-enforcer-plugin,
              >> codehaus's exec-maven-plugin, docbkx-maven-plugin,
             maven-antrun-plugin,
              >> maven-clean-plugin, many more.
              >>
              >> Cheers,
              >> Daniel
              >>
              >> On 4/29/14, 12:50 PM, "Igor Fedorenko"
        <igor@xxxxxxxxxxxxxx <mailto:igor@xxxxxxxxxxxxxx>
             <mailto:igor@xxxxxxxxxxxxxx <mailto:igor@xxxxxxxxxxxxxx>>>

        wrote:
              >>
              >>> See inline
              >>>
              >>> --
              >>> Regards,
              >>> Igor
              >>>
              >>> On 2014-04-29, 14:06, Daniel Johnson (danijoh2) wrote:
              >>>> Hello Igor, Max,
              >>>>
              >>>> I agree it will be nice to have these markers
        configurable.
              >>>>
              >>>> Igor, as for the examples you are looking for:
              >>>>
              >>>> 1. In my experience it is nice to have the project
        marked in error
              >>>>when
              >>>> the POM configuration changes and the class path
        needs to be
             re-built,
              >>>> better yet would be an option in preferences to
        automatically
             update
              >>>> project configuration when the POM configuration
        changes. I
             don¹t have
              >>>> any
              >>>> example where I don¹t want this flagged in error, so
        maybe
             others can
              >>>> speak up here. I certainly don¹t want to commit a POM
        change
             without
              >>>> being
              >>>> sure the code still compiles, and I also don¹t want
        to have to
             do a
              >>>> command line build to confirm it.
              >>>>
              >>>
              >>> Can you elaborate on "the class path needs to be re-built"
             part? m2e is
              >>> supposed to update project classpath automatically. If
        you have
             to run
              >>> project configuration update to get classpath in sync
        with pom.xml
              >>> changes, this may indicate a bug and I'd like to
        understand
             better when
              >>> this happens.
              >>>
              >>>
              >>>> 2. As for plugins that are ³not covered², this has
        been an ongoing
              >>>>issue
              >>>> for me. I manage our Eclipse install for 200+
        developers as
             well as
              >>>> being
              >>>> a developer myself. I would like to see that at the
        very least
             when a
              >>>> plugin execution is not covered that we have the
        option to
             flag it as
              >>>>a
              >>>> Œwarning¹, or better yet a preference to
        automatically ignore ³not
              >>>> covered² plugins. Several developers are not Maven
        savvy, so
             when they
              >>>> check out a project and it immediately goes in error
        because
             some of
              >>>>the
              >>>> plugins are not covered they worry that the project
        is in an
             unstable
              >>>> state and they get confused when the command line
        build works
             fine but
              >>>> Eclipse shows errors.
              >>>
              >>>
              >>> This is counter-intuitive. I can understand how
        experienced
             Maven user
              >>> can decide that some plugins are not relevant inside m2e
             workspace, but
              >>> I always assumed that it is better to warn novice
        users about any
              >>> potential problems.
              >>>
              >>> Can you give examples of maven plugins that you
        commonly need to
              >>>ignore?
              >>>
              >>> Any reason you don't have these plugins ignored in
        parent pom.xml?
              >>>
              >>>
              >>>
              >>>> I hope some of this will be helpful to you.
              >>>>
              >>>> Regards,
              >>>> Daniel
              >>>>
              >>>>
              >>>> On 4/29/14, 10:46 AM, "Igor Fedorenko"
        <igor@xxxxxxxxxxxxxx <mailto:igor@xxxxxxxxxxxxxx>
             <mailto:igor@xxxxxxxxxxxxxx <mailto:igor@xxxxxxxxxxxxxx>>>

        wrote:
              >>>>
              >>>>> Unfortunately, performance improvement in m2e 1.5 do
        not get
             Eclipse
              >>>>> IDE
              >>>>> anywhere close to performance parity with command
        line build,
              >>>>> especially
              >>>>> if you consider modern multi-core hardware and
        multi-threaded
              >>>>>builds. I
              >>>>> believe fundamental changes to m2e and eclipse in
        general will be
              >>>>> required to close the performance gap.
              >>>>>
              >>>>> I am fine making m2e markers levels configurable. We'll
             probably need
              >>>>> to
              >>>>> provide ability to export/import workspace-level
        preferences, but
              >>>>>lets
              >>>>> wait for somebody to ask for this first.
              >>>>>
              >>>>> Can you give a couple of examples when it is safe and
             desirable to
              >>>>> ignore out-of-date project configuration?
              >>>>>
              >>>>> Can you give a couple of examples when it is safe and
             desirable to
              >>>>> ignore "not covered" maven plugins?
              >>>>>
              >>>>> --
              >>>>> Regards,
              >>>>> Igor
              >>>>>
              >>>>>
              >>>>>
              >>>>>
              >>>>> On 2014-04-29, 13:11, Max Rydahl Andersen wrote:
              >>>>>> Hey,
              >>>>>>
              >>>>>> Over the last few years of maven in eclipse I've
        noticed two
              >>>>>>repeating
              >>>>>> complaints being raised.
              >>>>>>
              >>>>>> Those two boils down to:
              >>>>>>
              >>>>>> 1) maven in eclipse is slow
              >>>>>>
              >>>>>> 2) when I import into eclipse my project has
        errors, that
             does not
              >>>>>> happen in "name your favourite IDE"
              >>>>>>
              >>>>>> #1 the memory fixes in m2e 1.5 and some of the
        wizard workflow
              >>>>>>changes
              >>>>>> have helped greatly on - we still can do
              >>>>>> better there but that is for a separate thread.
              >>>>>>
              >>>>>> #2 is where I would like to suggest that we:
              >>>>>>
              >>>>>> A) Makes the level of markers in m2e configurable
        (Error,
             Warning,
              >>>>>> Ignore)
              >>>>>>
              >>>>>> B) Consider the default level of the markers.
              >>>>>>
              >>>>>>        - "Project Configuration is not uptodate"
        should IMO be a
              >>>>>> Warning
              >>>>>> since it is really often that a change in POM actually
             requires a
              >>>>>>full
              >>>>>> project update.
              >>>>>>        - "Plugin execution not covered by
        lifecycle" I think
             should
              >>>>>>be
              >>>>>> a
              >>>>>> Warning too since again most often you will not
        need to do much.
              >>>>>>
              >>>>>> We (or rather Fred :) already started some of this
        work on
              >>>>>>
        https://bugs.eclipse.org/bugs/__show_bug.cgi?id=433776

        <https://bugs.eclipse.org/bugs/show_bug.cgi?id=433776> - where
             he also
              >>>>>> made the handling of the existing warning/errors more
             aligned with
              >>>>>> standard eclipse warning/error handling.
              >>>>>>
              >>>>>> For now this one just deals with A from above.
              >>>>>>
              >>>>>> What do you think about that ?
              >>>>>>
              >>>>>> and is some combination of B something you like or just
             completely
              >>>>>> opposed ?
              >>>>>>
              >>>>>> /max
              >>>>>> http://about.me/maxandersen
              >>>>>> _________________________________________________
              >>>>>> 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>
              >>>>>>
              >>>>> _________________________________________________
              >>>>> 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>
              >>>>
              >>>> _________________________________________________
              >>>> 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>
              >>>>
              >>> _________________________________________________
              >>> 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>
              >>
              >> _________________________________________________
              >> 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>
              >>
              >_________________________________________________
              >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>

             _________________________________________________
             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>




        _________________________________________________

        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

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




Back to the top