Re: [m2e-dev] On the topic of errors and warnings for m2e

["Daniel Johnson (danijoh2)" <danijoh2@xxxxxxxxx>]

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