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 <mailto:atg.sleepless@xxxxxxxxx>> wrote:
On Thu, May 1, 2014 at 2:14 AM, Igor Fedorenko <igor@xxxxxxxxxxxxxx
<mailto: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>
<mailto: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>> <mailto: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>>
<mailto: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>>
<mailto: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>>
<mailto: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>
<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>> <mailto: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>
<mailto:m2e-dev@xxxxxxxxxxx
<mailto:m2e-dev@xxxxxxxxxxx>> <mailto: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>
<mailto:m2e-dev@xxxxxxxxxxx
<mailto:m2e-dev@xxxxxxxxxxx>> <mailto: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>
<mailto:m2e-dev@xxxxxxxxxxx
<mailto:m2e-dev@xxxxxxxxxxx>> <mailto: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>
<mailto:m2e-dev@xxxxxxxxxxx
<mailto:m2e-dev@xxxxxxxxxxx>> <mailto: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>
<mailto:m2e-dev@xxxxxxxxxxx
<mailto:m2e-dev@xxxxxxxxxxx>> <mailto: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>
<mailto:m2e-dev@xxxxxxxxxxx
<mailto:m2e-dev@xxxxxxxxxxx>> <mailto: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>
<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>
<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
