[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [m2e-dev] m2e-wtp / pomproperties conflict

Igor,

I totally agree on principle, Manifest generation should not be dependent on m2e-wtp and belongs with the pom properties plugin.
But, it's not that simple. JavaEE projects (EAR, WAR, ...) do not deploy that manifest in the same place (target/classes/META-INF).

m2e-wtp needs to either control the generation directory, so it will be deployed by WTP, or it needs to know were the archiver will decide to generate it.
Either way, we need to introduce a dependency between m2e-wtp and the archiver plugin upstream. as we saw it today, dependencies between plugins need to be better addressed.

Also, for the moment, only jar projects that are utility projects (i.e. WTP projects) have the manifest generation enabled. I did this because I was experiencing a nasty bug. I need to look back at it.

Anyway, if the current lifecycle mapping mechanism is unchanged, the only solution I can think of is to add the archiver plugin back to m2e-core.
That way pom / manifests would be generated by default for jar projects, m2e-wtp would provide the manifest configurators implementations that would tell the archiver were to generate the files for WAR, EAR, RARÂ ...

WDYT?

Regards,

Fred Bricon

Â

2011/6/23 Igor Fedorenko <igor@xxxxxxxxxxxxxx>
Is manfiest customization to m2e-wtp integration and/or JEE development?
After looking rather quickly at MECLIPSEWTP-45 and maven archiver
documentation [5], I am tempted to say it is not. I think we should pull
maven-jar-plugin integration out of m2e-wtp to a separate m2e extension
and merge it with pom.properties generation logic. What do you think?

[5] http://maven.apache.org/shared/maven-archiver/

--
Regards,
Igor


On 11-06-23 2:05 PM, Fred Bricon wrote:
Hi,

m2e-wtp 0.13.0 adds support for Manifest generation ([1] [2]). In order
to trigger the manifest configurator for jar projects, a configurator is
mapped to the maven-jar-plugin:jar goal [3].
I only realized yesterday, while trying to release 0.13.0, that it
conflicted with the pomproperties configurator which does exactly the
same thing [4]
If I Declare the manifest configurator as secondary to the pomproperties
one, then it won't be called if pomproperties is not installed.
Which lead me to add a hard dependency from m2e-wtp to pomproperties.
Problem is, if you tried to install m2e-wtp from the discovery
mechanism, then it would fail without giving an explicit reason to the
user, because the pomproperties update site would not be contacted, so
the P2 couldn't resolve that dependency.

The decision was taken to remove both the dependency to pomproperties
and the pomproperties plugin itself from the marketplace, in order to
provide a better user experience.

Adding a dependency to pomproperties was not necessarily a bad decision.
I mean any plugin could depend on another one.
IMHO, the marketplace should contact all the update sites available from
the connector.xml, and of course, the error message in cause of a
dependency issue should be clear.

Anyway, I heartily thank Igor for helping me push m2e-wtp 0.13 out in
the open.

Regards,

Fred Bricon

[1] https://issues.sonatype.org/browse/MECLIPSEWTP-45
[2] http://dev.eclipse.org/mhonarc/lists/m2e-dev/msg00496.html
[3]
https://github.com/sonatype/m2eclipse-wtp/blob/0.13.0.20110622-1130/org.maven.ide.eclipse.wtp/lifecycle-mapping-metadata.xml#L180
[4]
https://github.com/sonatype/m2eclipse-extras/blob/master/org.sonatype.m2e.mavenarchiver.pomproperties/lifecycle-mapping-metadata.xml


--
"Have you tried turning it off and on again" - The IT Crowd



_______________________________________________
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



--
"Have you tried turning it off and on again" - The IT Crowd