Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[m2e-dev] Project refreshes and rebuilds/autobuilds
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?

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.


On Wed, Apr 30, 2014 at 2:28 PM, Igor Fedorenko <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>> 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>> 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>> 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>> 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 - 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>

     >>>>>> 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
     >>>>
     >>>> _______________________________________________
     >>>> m2e-dev mailing list
     >>>> m2e-dev@xxxxxxxxxxx <mailto:m2e-dev@xxxxxxxxxxx>

     >>>> 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
     >>
     >> _______________________________________________
     >> m2e-dev mailing list
     >> m2e-dev@xxxxxxxxxxx <mailto:m2e-dev@xxxxxxxxxxx>

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

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

Back to the top