[jbosstools-dev] m2e and new execution plugins?

[Brian Fitzpatrick]

Thanks Fred!

We'll explore some options and see what door we choose to open. :)

--Fitz

On Thu, May 5, 2016 at 1:23 PM, Fred Bricon <fbricon at redhat.com> wrote:

> Hi Brian,
>
> sooo, m2e doesn't know if it's safe to execute a 3rd party plugin or not,
> during an Eclipse build[1]. It needs hints whether to ignore or execute
> this maven plugin or maybe delegate its execution to some eclipse plugin
> adapter.
>
> So the very first question you need to answer is : does the maven plugin
> need to be invoked during an eclipse (incremental or full) build, or can it
> be safely ignored?
> I'm guessing (but you prolly want to ask the exoerts):
> - cxf-java2wadl-plugin:parsejavadoc: probably ignored
> - cxf-java2wadl-plugin: java2wadl: probably executed on full builds only
> (you don't want to regenerate the wadl every time you save a file in your
> project)
> - fabric-cxf-plugins: java2swagger: probably executed on full builds only
>
> Once you have the answer to that question, the next step is to declare a
> lifecycle mapping (LM), which can be done in several ways, depending on
> your use case:
>
> 1 - add a LM descriptor within the maven plugin itself:
>      * this only affects consumers of the new maven plugin version
> containing the LM. For older versions, see #2-#3
>      * if must be executed, need to ensure this is done in an optimal way
> by using the incremental build API [2], to at least automatically refresh
> resources modified by the plugin execution
> 2 - define m2e LM in pom.xml
>      * define it once in a common parent pom to avoid xml bloat, that
> should be easy to do for new example projects, won't work for previous
> example releases
> 3 - create an m2e configurator (eclipse plugin) [3]
>     * can simply define the LM. Can also enhance eclipse integration by
> configuring some eclipse specific configuration
>     * the eclipse plugin needs to be added to the m2e discovery catalog [4]
>
> You could reach out to the fabric8 team and ask them if they're willing
> to make their plugins incremental-build friendly. For Apache CXF, that
> might be a bit more tricky, bit doesn't hurt to ask.
>
> Chances are though, it'll be faster/easier to create an m2e eclipse plugin
> for that (#3). I have commit access to the m2e discovery repo, so it'll be
> easy to get in. Now, the m2e project is not responsible for providing LMs
> for 3rd party maven plugins. So I'd suggest you open JBIDE issues for
> each of your problems.
>
> Fred
>
>
> [1]
> https://www.eclipse.org/m2e/documentation/m2e-execution-not-covered.html
> [2]
> https://www.eclipse.org/m2e/documentation/m2e-making-maven-plugins-compat.html
> [3]
> https://www.eclipse.org/m2e/documentation/m2e-extension-development.html
> [4] https://github.com/takari/m2e-discovery-catalog#m2e-discovery-catalog
>
>
> On Thu, May 5, 2016 at 10:49 AM, Brian Fitzpatrick <bfitzpat at redhat.com>
> wrote:
>
>> Hey guys,
>>
>> We've hit some maven plug-ins that aren't supported yet by m2e that we
>> use in the Fuse world... if I was to log a feature request for some of
>> these, should I put it in Eclipse? or in JBIDE?
>>
>> Or a better question, what is the policy for additions to m2e? How do we
>> petition to have plug-ins added or contribute back? These may not be
>> broadly applicable to other projects, so less apt to be pushed upstream.
>>
>> Thanks in advance.
>>
>> --Fitz
>>
>> p.s. For a bit more detail about what we're looking for...
>>
>> Importing the camel-cxf example (
>> https://github.com/jboss-fuse/quickstarts/tree/master/cxf/rest) we hit
>> three issues.
>>
>> We have an org.apache.cxf plug-ins that isn't supported yet...
>>
>>       <plugin>
>>         <groupId>org.apache.cxf</groupId>
>>         <artifactId>cxf-java2wadl-plugin</artifactId>
>>         <version>3.0.4.redhat-621084</version>
>>         <executions>
>>           <execution>
>>             <id>parsejavadoc</id>
>>             <phase>generate-sources</phase>
>>             <goals>
>>               <goal>parsejavadoc</goal>
>>             </goals>
>>           </execution>
>>           <execution>
>>             <id>process-classes</id>
>>             <phase>process-classes</phase>
>>             <goals>
>>               <goal>java2wadl</goal>
>>             </goals>
>>             <configuration>
>>               <classResourceNames>
>>
>> <classResourceName>io.fabric8.quickstarts.rest.CustomerService</classResourceName>
>>               </classResourceNames>
>>
>> <docProvider>org.apache.cxf.maven_plugin.javatowadl.ResourceMapJavaDocProvider</docProvider>
>>               <attachWadl>false</attachWadl>
>>             </configuration>
>>           </execution>
>>         </executions>
>>       </plugin>
>>
>> And a fabric8 plug-in that isn't supported yet.
>>
>>       <plugin>
>>         <groupId>io.fabric8</groupId>
>>         <artifactId>fabric-cxf-plugins</artifactId>
>>         <version>1.2.0.redhat-621084</version>
>>         <executions>
>>           <execution>
>>             <id>process-classes</id>
>>             <phase>process-classes</phase>
>>             <goals>
>>               <goal>java2swagger</goal>
>>             </goals>
>>             <configuration>
>>               <classResourceNames>
>>
>> <classResourceName>io.fabric8.quickstarts.rest.CustomerService</classResourceName>
>>               </classResourceNames>
>>               <attachSwagger>false</attachSwagger>
>>             </configuration>
>>           </execution>
>>         </executions>
>>       </plugin>
>>
>>
>> _______________________________________________
>> jbosstools-dev mailing list
>> jbosstools-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/jbosstools-dev
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jbosstools-dev/attachments/20160505/1c74cd56/attachment.html