On 20/04/15 21:57, Bruno P. Kinoshita wrote:
  I used to add information in the project pom, but some OSS projects didn't 
allow adding IDE specific options in the project settings.
Now, after I import a Maven project into Eclipse, whenever I find messages like this, I 
simply choose the Quick-Fix option "Mark goal $GOAL as ignored in Eclipse build in 
Eclipse preferences (experimental)" and this removes the problems in Eclipse without 
changing pom.xml.
The downside is that I have to do that whenever I import that project in some 
other computer :-(

Hi Bruno,

At least that confirms my experience.

I was using the "experimental" option as well (or so I though) for the m2e warnings but "something changed"(tm)

I made a change to an unrelated project in the same workspace that caused some massive rebuild - my only guess something cached flushed through. That was an inconvenient downside when it was warnings but it is now errors.

So it seems to be a choice - M2E free-POM vs simple setup. We already had some m2e lifecycle control in jena-parent - I added the RAT to the existing exclusions.

        Andy



       From: Andy Seaborne <a...@apache.org>
  To: dev@jena.apache.org
  Sent: Tuesday, April 21, 2015 4:35 AM
  Subject: RAT and m2e

All of a sudden, I seeing m2e problems with the RAT plugin on several
machines.  It's causing an Eclipse error "Plugin execution not covered
by lifecycle configuration".

I don't understand why this has started happening to me because I don't
see any changes that are relevant.

In an attempt to stabilise m2e I've added to jena-parent/pom.xml:

<pluginExecution>
   <!--
     Error:
     Plugin execution not covered by lifecycle configuration
   -->
   <pluginExecutionFilter>
     <groupId>org.apache.rat</groupId>
     <artifactId>apache-rat-plugin</artifactId>
     <versionRange>[0.11,)</versionRange>
     <goals>
       <goal>check</goal>
     </goals>
   </pluginExecutionFilter>
   <action>
     <ignore />
   </action>
</pluginExecution>

which (1) seems the right thing to do and (2) fixes what I'm seeing.

Has anyone else seen this recently?

Is there a better way?

     Mystified,
     Andy





Reply via email to