[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [m2e-dev] Lifecycle mapping issue
|
On 11-10-09 10:54 PM, Ian Robertson wrote:
I'm attempting to write a project configurator for Jamon
(www.jamon.org), a templating engine which generates java code from
template sources. Jamon has a maven plugin whose mojo binds to the
generate-sources phase, but it also has an eclipse plugin, so the
project configurator, upon detecting the jamon-maven-plugin, should add
the Jamon nature to the eclipse project.
The problem is that the Jamon nature requires javanature to be on the
project. It needs to add the generated sources directory to the eclipse
project's classpath. However, because the jamon-maven-plugin's mojo
binds to the generate-sources-phase, the Jamon project configurator is
run prior to the java configurator
(org.eclipse.m2e.jdt.javaconfigurator). Thus, when trying to add
"jamonnature" to the project, eclipse complains that jamonnature is
missing the prerequisite javanature.
Is there a recommended way to handle this sort of situation? The only
thing I can think of at the moment is to create two configurators. One
would be a dummy configurator attached to the Jamon mojo; this would
keep m2e from complaining about the jamon plugin execution not being
covered. Then attach the "real" Jamon configurator to the
maven-compiler-plugin as a secondary configurator. While this might
work, it doesn't feel particularly clean, and I wouldn't be surprised to
see a kludge like that break in a future release of m2e.
This is supported and is expected to work both with current and future
versions of m2e (unless we break it, of course :-) ). You don't need a
dummy configurator for jamon-maven-plugin, mapping it to <ignore/>
should work.
As for "not particularly clean" part, I am not sure there is a better
way to support such implicit dependencies between different project
configurators. The only downside of the current implementation is that
jamon configurator will be activated and executed for all java projects,
regardless if they use jamon or not. Although this is certainly not
nice, I do not believe this justifies introduction of more complex
mapping conditions, i.e. "map as secondary to jdt configurator, when
both jamon and java compiler are present".
--
Regards,
Igor
