Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [m2e-dev] On the topic of errors and warnings for m2e

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

_______________________________________________
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