[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [m2e-dev] Manifest generation support in m2e(clipse-wtp)
|
There is a chance the version of embedded archiver and used by the
project generate significantly different manifest, so I think you should
try to avoid embedding anything.
I wonder if using reflection is a better approach in this
particular case. I have not looked at the code, but I wonder if you can
get instance of acrhiver and invoke operations on it.
--
Regards,
Igor
On 11-05-30 6:54 PM, Fred Bricon wrote:
Hi,
there is currently one open issue concerning Manifest.mf generation in
m2eclipse-wtp (https://issues.sonatype.org/browse/MECLIPSEWTP-45).
This issue concerns Manifest generation for jar projects, but the
problem can be extended to any other package.
Wars and Ears being the most common other packages -I can think of-
I started to look at the manifest generation for wars. There is a
war:manifest goal, we can call on updateProject (if the dependencies or
the manifest configuration have changed) and tell it to (re)generate a
Manifest wherever we want (say target/m2e-wtp/web-resources/META-INF)
Unfortunately, maven-jar-plugin and maven-ear-plugin plugins don't offer
such goal. So, correct me if I'm wrong, the only way to generate the
manifest would be to embed the maven-archiver plugin and all its
dependencies.
The way I see things, we could have a m2eclipse-manifest (or
m2eclipse-archive) plugin, in m2e-extras, along with a maven-archiver
embedder plugin (similar to what's done for archetypes and the core
embedder). m2eclipse-manifest would provide a
(Abstract)ManifestConfigurator and an implementation for jar projects
(JarConfigurator ?), m2eclipse-wtp would provide implementations for war
and ear packages, secondary to the WTPProjectConfigurator.
The Manifest would have to be generated in a dynamically added classpath
or web source folder, so that Eclipse could access it (to support skinny
wars, for instance, but that could be reworked)
I believe such Manifest configurators would have to "manually"
deserialize Xpp3 configurations to instantiate everything required to
use the maven-archiver API.
I dunno if an automatic deserialization is possible, but that would be
more prone to "serialization mismatches" between the eclipse embedded
maven-archiver jar and the classes loaded in the maven session.
The best solution would probably be to have maven-jar-plugin and
maven-ear-plugin provide the same "manifest" goal as the
maven-war-plugin, but I'm afraid that'd take too long.
I dunno if/how Webby tackles this issue.
If you have any comments, ideas, I'd like to hear them. I'm a bit too
focussed on JavaEE stuff so it's probable I fail to see the big picture
here.
regards,
Fred Bricon
--
"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
