You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@uima.apache.org by Marshall Schor <ms...@schor.com> on 2012/07/02 18:02:17 UTC
testing Eclipse 4.2 with included m2e
I'm trying this out - with a new Eclipse 4.2 install, and the version of m2e
that comes with Eclipse 4.2 also installed.
Some issues I've found and their workarounds:
1) I only had Java 7 in the list of installed JREs in Eclipse. This made some
compiles fail which referred to an imported class named "Type" but where for
some unknown reason, even though there was an import for this, it was associated
to a different Type class that's available in Java 7.
Adding other JREs (java 5 and 6) fixed this.
2) m2e attempts to get identical builds between Eclipse and Maven. To that end,
for the Eclipse builds it runs more of the maven builds, and needs some bridging
to do that. The bridging is supplied by connectors and some maven plugins we
use don't have those. The solution is to skip that part of the Maven build.
The Eclipse plugin projects are affected by this, and some of the other
packaging is also affected.
The skipping is configured by a new element in the pom (eventually this will be
in a top-level pom, and inherited). For now, I'm putting the configuration in
the xxx-parent pom associated with major component (with a plan to promote this
to the common UIMA-wide pom with this info when we get it all figured out).
The updates for this I let Eclipse do automatically (there's some "quick-fix"
things that do it). The result is this additional stanza in the <build> element:
<pluginManagement>
<plugins>
<!--This plugin's configuration is used to store Eclipse m2e
settings only. It has no influence on the Maven build itself.-->
<plugin>
<groupId>org.eclipse.m2e</groupId>
<artifactId>lifecycle-mapping</artifactId>
<version>1.0.0</version>
<configuration>
<lifecycleMappingMetadata>
<pluginExecutions>
<pluginExecution>
<pluginExecutionFilter>
<groupId>org.apache.uima</groupId>
<artifactId>
uima-build-helper-maven-plugin
</artifactId>
<versionRange>[2,)</versionRange>
<goals>
<goal>parse-date-time</goal>
</goals>
</pluginExecutionFilter>
<action>
<ignore></ignore>
</action>
</pluginExecution>
<pluginExecution>
<pluginExecutionFilter>
<groupId>
org.apache.felix
</groupId>
<artifactId>
maven-bundle-plugin
</artifactId>
<versionRange>
[2.3.4,)
</versionRange>
<goals>
<goal>manifest</goal>
</goals>
</pluginExecutionFilter>
<action>
<ignore></ignore>
</action>
</pluginExecution>
<pluginExecution>
<pluginExecutionFilter>
<groupId>
org.apache.maven.plugins
</groupId>
<artifactId>
maven-dependency-plugin
</artifactId>
<versionRange>
[2.3,)
</versionRange>
<goals>
<goal>unpack</goal>
<goal>
unpack-dependencies
</goal>
</goals>
</pluginExecutionFilter>
<action>
<ignore></ignore>
</action>
</pluginExecution>
</pluginExecutions>
</lifecycleMappingMetadata>
</configuration>
</plugin>
</plugins>
</pluginManagement>
-Marshall
Re: testing Eclipse 4.2 with included m2e
Posted by Marshall Schor <ms...@schor.com>.
On 7/4/2012 11:30 AM, Peter Klügl wrote:
> Thanks for your answer.
>
> Did you deactivate "Build Automatically" in your workspace to avoid 1) ?
no, I let Eclipse build things - mostly it just compiles sources into class
files in the target/classes directory, I think.
It doesn't build the longer, more-involved building stuff, like running the
docbook maven plugin to build the docbooks, or the "assembly" plugin to build
the binary assemblies, but that's fine with me, I don't want those built by
Eclipse, anyways...
>
> I am always a bit anxious when eclipse wants to build, for example,
> uimaj-ep-runtime for some reason. Due to the lifecycle mapping, the goal
> unpack-dependencies is not executed resulting in a useless jar. At least, this
> is what I think happens.
Right - this is what I think too. So for those, I build them using method 2 or 3.
-Marshall
>
> Peter
>
>
>
> On 04.07.2012 17:07, Marshall Schor wrote:
>> On 7/3/2012 5:01 AM, Peter Klügl wrote:
>>> Hi Marshall,
>>>
>>> thanks for the information.
>>>
>>> Just a short question so that I might understand the maven stuff a bit more.
>>>
>>> This lifecylce mapping deactivates the mentioned goals and therefore some
>>> projects cannot be built with m2e, e.g., the runtime plugin because of the
>>> inclusion of the other projects, right?
>> Hmm, I don't quite understand what you're saying. But I think there are maybe 3
>> styles of building:
>>
>> 1) The "automatic" build of the Eclipse workspace, or the build that happens
>> when you pick Eclipse's menu -> project -> clean.
>> 2) The build that happens (with or without Eclipse running) when you use the
>> "mvn" command from a command line.
>> 3) The build that happens when you right-click a project and select Run and then
>> pick a maven build action.
>>
>> #2 and #3 I think run essentially outside of Eclipse using the normal maven
>> infrastructure and maven plugins.
>> #1 is the only one that m2e is affecting.
>>
>> Now, the way m2e does various actions when building seems to be to call the
>> underlying maven plugin (except perhaps sometimes, when the m2e developers
>> determined that the plugin was too buggy). See
>> http://wiki.eclipse.org/M2E_Extension_Development for an example.
>>
>> In my building of things, the Eclipse plugin projects are not built in style
>> #1. When I need to build them, I use #2 or #3. I don't think there's a
>> connector bridge (yet) for the felix bundle plugin.
>>> I observe this when I build UIMA and was wondering if this is normal to add
>>> the mapping in order to get rid of the (m2e) problems. I did this in my
>>> workspace, but haven't seen any comments on the webpage about that. However,
>>> all works fine when I build the projects directly with "run as maven build...
>>> package". Please correct me, if I got something wrong.
>> I think you are correct. "run as maven build... package" is the style #3 above.
>>
>> -Marshall
>
>
Re: testing Eclipse 4.2 with included m2e
Posted by Peter Klügl <pk...@uni-wuerzburg.de>.
Thanks for your answer.
Did you deactivate "Build Automatically" in your workspace to avoid 1) ?
I am always a bit anxious when eclipse wants to build, for example,
uimaj-ep-runtime for some reason. Due to the lifecycle mapping, the goal
unpack-dependencies is not executed resulting in a useless jar. At
least, this is what I think happens.
Peter
On 04.07.2012 17:07, Marshall Schor wrote:
> On 7/3/2012 5:01 AM, Peter Klügl wrote:
>> Hi Marshall,
>>
>> thanks for the information.
>>
>> Just a short question so that I might understand the maven stuff a bit more.
>>
>> This lifecylce mapping deactivates the mentioned goals and therefore some
>> projects cannot be built with m2e, e.g., the runtime plugin because of the
>> inclusion of the other projects, right?
> Hmm, I don't quite understand what you're saying. But I think there are maybe 3
> styles of building:
>
> 1) The "automatic" build of the Eclipse workspace, or the build that happens
> when you pick Eclipse's menu -> project -> clean.
> 2) The build that happens (with or without Eclipse running) when you use the
> "mvn" command from a command line.
> 3) The build that happens when you right-click a project and select Run and then
> pick a maven build action.
>
> #2 and #3 I think run essentially outside of Eclipse using the normal maven
> infrastructure and maven plugins.
> #1 is the only one that m2e is affecting.
>
> Now, the way m2e does various actions when building seems to be to call the
> underlying maven plugin (except perhaps sometimes, when the m2e developers
> determined that the plugin was too buggy). See
> http://wiki.eclipse.org/M2E_Extension_Development for an example.
>
> In my building of things, the Eclipse plugin projects are not built in style
> #1. When I need to build them, I use #2 or #3. I don't think there's a
> connector bridge (yet) for the felix bundle plugin.
>> I observe this when I build UIMA and was wondering if this is normal to add
>> the mapping in order to get rid of the (m2e) problems. I did this in my
>> workspace, but haven't seen any comments on the webpage about that. However,
>> all works fine when I build the projects directly with "run as maven build...
>> package". Please correct me, if I got something wrong.
> I think you are correct. "run as maven build... package" is the style #3 above.
>
> -Marshall
--
---------------------------------------------------------------------
Dipl.-Inf. Peter Klügl
Universität Würzburg Tel.: +49-(0)931-31-86741
Am Hubland Fax.: +49-(0)931-31-86732
97074 Würzburg mail: pkluegl@informatik.uni-wuerzburg.de
http://www.is.informatik.uni-wuerzburg.de/en/staff/kluegl_peter/
---------------------------------------------------------------------
Re: testing Eclipse 4.2 with included m2e
Posted by Marshall Schor <ms...@schor.com>.
On 7/3/2012 5:01 AM, Peter Klügl wrote:
> Hi Marshall,
>
> thanks for the information.
>
> Just a short question so that I might understand the maven stuff a bit more.
>
> This lifecylce mapping deactivates the mentioned goals and therefore some
> projects cannot be built with m2e, e.g., the runtime plugin because of the
> inclusion of the other projects, right?
Hmm, I don't quite understand what you're saying. But I think there are maybe 3
styles of building:
1) The "automatic" build of the Eclipse workspace, or the build that happens
when you pick Eclipse's menu -> project -> clean.
2) The build that happens (with or without Eclipse running) when you use the
"mvn" command from a command line.
3) The build that happens when you right-click a project and select Run and then
pick a maven build action.
#2 and #3 I think run essentially outside of Eclipse using the normal maven
infrastructure and maven plugins.
#1 is the only one that m2e is affecting.
Now, the way m2e does various actions when building seems to be to call the
underlying maven plugin (except perhaps sometimes, when the m2e developers
determined that the plugin was too buggy). See
http://wiki.eclipse.org/M2E_Extension_Development for an example.
In my building of things, the Eclipse plugin projects are not built in style
#1. When I need to build them, I use #2 or #3. I don't think there's a
connector bridge (yet) for the felix bundle plugin.
>
> I observe this when I build UIMA and was wondering if this is normal to add
> the mapping in order to get rid of the (m2e) problems. I did this in my
> workspace, but haven't seen any comments on the webpage about that. However,
> all works fine when I build the projects directly with "run as maven build...
> package". Please correct me, if I got something wrong.
I think you are correct. "run as maven build... package" is the style #3 above.
-Marshall
Re: testing Eclipse 4.2 with included m2e
Posted by Peter Klügl <pk...@uni-wuerzburg.de>.
Hi Marshall,
thanks for the information.
Just a short question so that I might understand the maven stuff a bit more.
This lifecylce mapping deactivates the mentioned goals and therefore
some projects cannot be built with m2e, e.g., the runtime plugin because
of the inclusion of the other projects, right?
I observe this when I build UIMA and was wondering if this is normal to
add the mapping in order to get rid of the (m2e) problems. I did this in
my workspace, but haven't seen any comments on the webpage about that.
However, all works fine when I build the projects directly with "run as
maven build... package". Please correct me, if I got something wrong.
Best,
Peter
On 02.07.2012 18:02, Marshall Schor wrote:
> I'm trying this out - with a new Eclipse 4.2 install, and the version of m2e
> that comes with Eclipse 4.2 also installed.
>
> Some issues I've found and their workarounds:
>
> 1) I only had Java 7 in the list of installed JREs in Eclipse. This made some
> compiles fail which referred to an imported class named "Type" but where for
> some unknown reason, even though there was an import for this, it was associated
> to a different Type class that's available in Java 7.
>
> Adding other JREs (java 5 and 6) fixed this.
>
> 2) m2e attempts to get identical builds between Eclipse and Maven. To that end,
> for the Eclipse builds it runs more of the maven builds, and needs some bridging
> to do that. The bridging is supplied by connectors and some maven plugins we
> use don't have those. The solution is to skip that part of the Maven build.
>
> The Eclipse plugin projects are affected by this, and some of the other
> packaging is also affected.
>
> The skipping is configured by a new element in the pom (eventually this will be
> in a top-level pom, and inherited). For now, I'm putting the configuration in
> the xxx-parent pom associated with major component (with a plan to promote this
> to the common UIMA-wide pom with this info when we get it all figured out).
>
> The updates for this I let Eclipse do automatically (there's some "quick-fix"
> things that do it). The result is this additional stanza in the<build> element:
>
> <pluginManagement>
> <plugins>
> <!--This plugin's configuration is used to store Eclipse m2e
> settings only. It has no influence on the Maven build itself.-->
> <plugin>
> <groupId>org.eclipse.m2e</groupId>
> <artifactId>lifecycle-mapping</artifactId>
> <version>1.0.0</version>
> <configuration>
> <lifecycleMappingMetadata>
> <pluginExecutions>
> <pluginExecution>
> <pluginExecutionFilter>
> <groupId>org.apache.uima</groupId>
> <artifactId>
> uima-build-helper-maven-plugin
> </artifactId>
> <versionRange>[2,)</versionRange>
> <goals>
> <goal>parse-date-time</goal>
> </goals>
> </pluginExecutionFilter>
> <action>
> <ignore></ignore>
> </action>
> </pluginExecution>
> <pluginExecution>
> <pluginExecutionFilter>
> <groupId>
> org.apache.felix
> </groupId>
> <artifactId>
> maven-bundle-plugin
> </artifactId>
> <versionRange>
> [2.3.4,)
> </versionRange>
> <goals>
> <goal>manifest</goal>
> </goals>
> </pluginExecutionFilter>
> <action>
> <ignore></ignore>
> </action>
> </pluginExecution>
> <pluginExecution>
> <pluginExecutionFilter>
> <groupId>
> org.apache.maven.plugins
> </groupId>
> <artifactId>
> maven-dependency-plugin
> </artifactId>
> <versionRange>
> [2.3,)
> </versionRange>
> <goals>
> <goal>unpack</goal>
> <goal>
> unpack-dependencies
> </goal>
> </goals>
> </pluginExecutionFilter>
> <action>
> <ignore></ignore>
> </action>
> </pluginExecution>
> </pluginExecutions>
> </lifecycleMappingMetadata>
> </configuration>
> </plugin>
> </plugins>
> </pluginManagement>
>
> -Marshall
--
---------------------------------------------------------------------
Dipl.-Inf. Peter Klügl
Universität Würzburg Tel.: +49-(0)931-31-86741
Am Hubland Fax.: +49-(0)931-31-86732
97074 Würzburg mail: pkluegl@informatik.uni-wuerzburg.de
http://www.is.informatik.uni-wuerzburg.de/en/staff/kluegl_peter/
---------------------------------------------------------------------