| Re: [m2e-dev] Project refreshes and rebuilds/autobuilds |
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 mavenif(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:I'll try to debug into details and see what causes that.
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 ;-)As I mentioned in another thread, there are two cases that are not
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.
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.javaindex 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
<mailto:danijoh2@xxxxxxxxx> <mailto:danijoh2@xxxxxxxxx<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:igor@xxxxxxxxxxxxxx <mailto:igor@xxxxxxxxxxxxxx>>>
<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>https://bugs.eclipse.org/bugs/__show_bug.cgi?id=433776
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> <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>
_________________________________________________ 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
https://dev.eclipse.org/mailman/listinfo/m2e-dev
_______________________________________________
m2e-dev mailing list
m2e-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/m2e-dev