That's what I understand from the code, correct me if I'm wrong:
Whenever project's A pom.xml changes:
1. If its GAV changed and/or parent GAV changed, then all dependents
irregardless of version are also refreshed
2. If any of its dependencies changed, then all dependents irregardless
of version are also refreshed
(1) covers cases when project A becomes part of range/comes out of range.
I guess (2) can be modified to include:
a. Dependents that have _resolved_ dependency to project A with the same
version
b. Dependents with unresolved dependencies to project A (extension
plugins and missing dependencies) irregardless of version
So basically resolved dependencies could be safely matched against
current projects version.
On Thu, May 1, 2014 at 4:01 PM, Igor Fedorenko <igor@xxxxxxxxxxxxxx
<mailto:igor@xxxxxxxxxxxxxx>> wrote:
This look for affected projects and needs to handle cases when a project
becomes part of a version range and comes out of a range.
--
Regards,
Igor
On 2014-05-01, 8:33, Anton Tanasenko wrote:
Aren't those resolved dependencies? There shouldn't be any ranges at
this time.
If I understand correctly.
On Thu, May 1, 2014 at 3:04 PM, Igor Fedorenko
<igor@xxxxxxxxxxxxxx <mailto:igor@xxxxxxxxxxxxxx>
<mailto:igor@xxxxxxxxxxxxxx <mailto:igor@xxxxxxxxxxxxxx>>> wrote:
What about version ranges? I don't think Maven resolver
provides enough
information to be able to distinguish between "depend on
this specific
version" vs "depend on these version ranges".
--
Regards,
Igor
On 2014-05-01, 6:15, Anton Tanasenko 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
<mailto:atg.sleepless@xxxxxxxxx>
<mailto:atg.sleepless@gmail.__com <mailto:atg.sleepless@xxxxxxxxx>>
<mailto:atg.sleepless@gmail.
<mailto:atg.sleepless@gmail.>____com
<mailto:atg.sleepless@gmail.__com
<mailto:atg.sleepless@xxxxxxxxx>>>> wrote:
On Thu, May 1, 2014 at 2:14 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:
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>>
<mailto:igor@xxxxxxxxxxxxxx
<mailto:igor@xxxxxxxxxxxxxx> <mailto:igor@xxxxxxxxxxxxxx
<mailto:igor@xxxxxxxxxxxxxx>>>
<mailto:igor@xxxxxxxxxxxxxx
<mailto:igor@xxxxxxxxxxxxxx>
<mailto:igor@xxxxxxxxxxxxxx
<mailto:igor@xxxxxxxxxxxxxx>> <mailto: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>>>
<mailto:danijoh2@xxxxxxxxx
<mailto:danijoh2@xxxxxxxxx>
<mailto:danijoh2@xxxxxxxxx <mailto:danijoh2@xxxxxxxxx>>
<mailto:danijoh2@xxxxxxxxx
<mailto:danijoh2@xxxxxxxxx>
<mailto:danijoh2@xxxxxxxxx
<mailto:danijoh2@xxxxxxxxx>>>> <mailto:danijoh2@xxxxxxxxx
<mailto:danijoh2@xxxxxxxxx>
<mailto:danijoh2@xxxxxxxxx <mailto:danijoh2@xxxxxxxxx>>
<mailto:danijoh2@xxxxxxxxx
<mailto:danijoh2@xxxxxxxxx> <mailto:danijoh2@xxxxxxxxx
<mailto:danijoh2@xxxxxxxxx>>>
<mailto: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>>>
<mailto:igor@xxxxxxxxxxxxxx
<mailto:igor@xxxxxxxxxxxxxx>
<mailto:igor@xxxxxxxxxxxxxx <mailto:igor@xxxxxxxxxxxxxx>>
<mailto:igor@xxxxxxxxxxxxxx
<mailto:igor@xxxxxxxxxxxxxx>
<mailto:igor@xxxxxxxxxxxxxx <mailto:igor@xxxxxxxxxxxxxx>>>>
<mailto:igor@xxxxxxxxxxxxxx
<mailto:igor@xxxxxxxxxxxxxx>
<mailto:igor@xxxxxxxxxxxxxx <mailto:igor@xxxxxxxxxxxxxx>>
<mailto:igor@xxxxxxxxxxxxxx
<mailto:igor@xxxxxxxxxxxxxx>
<mailto:igor@xxxxxxxxxxxxxx
<mailto:igor@xxxxxxxxxxxxxx>>> <mailto: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>>>
<mailto:igor@xxxxxxxxxxxxxx
<mailto:igor@xxxxxxxxxxxxxx>
<mailto:igor@xxxxxxxxxxxxxx
<mailto:igor@xxxxxxxxxxxxxx>> <mailto:igor@xxxxxxxxxxxxxx
<mailto:igor@xxxxxxxxxxxxxx>
<mailto:igor@xxxxxxxxxxxxxx <mailto:igor@xxxxxxxxxxxxxx>>>>
<mailto:igor@xxxxxxxxxxxxxx
<mailto:igor@xxxxxxxxxxxxxx>
<mailto:igor@xxxxxxxxxxxxxx <mailto:igor@xxxxxxxxxxxxxx>>
<mailto:igor@xxxxxxxxxxxxxx
<mailto:igor@xxxxxxxxxxxxxx>
<mailto:igor@xxxxxxxxxxxxxx
<mailto:igor@xxxxxxxxxxxxxx>>> <mailto: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>>>
<mailto:igor@xxxxxxxxxxxxxx
<mailto:igor@xxxxxxxxxxxxxx>
<mailto:igor@xxxxxxxxxxxxxx
<mailto:igor@xxxxxxxxxxxxxx>> <mailto:igor@xxxxxxxxxxxxxx
<mailto:igor@xxxxxxxxxxxxxx>
<mailto:igor@xxxxxxxxxxxxxx <mailto:igor@xxxxxxxxxxxxxx>>>>
<mailto:igor@xxxxxxxxxxxxxx
<mailto:igor@xxxxxxxxxxxxxx>
<mailto:igor@xxxxxxxxxxxxxx <mailto:igor@xxxxxxxxxxxxxx>>
<mailto:igor@xxxxxxxxxxxxxx
<mailto:igor@xxxxxxxxxxxxxx>
<mailto:igor@xxxxxxxxxxxxxx
<mailto:igor@xxxxxxxxxxxxxx>>> <mailto: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>>
<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>>__>
<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>>
<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>>>
<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
<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>
<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
<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>
<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>>
<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>>>
<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
<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>
<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
<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>
<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>>
<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>>>
<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
<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>
<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
<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>
<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>>
<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>>>
<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
<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>
<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
<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>
<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