You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Karl Heinz Marbaise <kh...@gmx.de> on 2016/05/01 14:10:53 UTC
[RFC] MJAR-193
Hi,
currently there are some requirements to allow other mojo's to
contribute to MANIFEST.MF which is used during the package of for
example of maven-jar-plugin...
The question is:
o Does someone has a good idea to solve such things ?
Or what might be a good direction to go?
o Let other mojo's / tools write a partial MANIFEST.MF
(to a special location?) and let for example maven-jar-plugin
pick this up and merge this with other information into
the final MANIFEST.MF file?
o Or should we allow to transfer such information via
the project context in Maven itself ? (which might
not be a good idea cause it might influence other
mojo's?)
o Or might it be worth thinking of a special Maven
plugin which handles such things in general and
all other packaging plugins (just pick the resulting
MANFIFEST.MF) and package it into jar, war, ear, rar etc.
(Hm..i'm not sure if this is a good idea, cause it might
cause problems with putting classpath information into
MANIFEST.MF ?) but if we are in prepare-package phase?
...
prepare-package: maven-manifest-plugin (?)
package: maven-jar-plugin
...
This would result in removing all MANIFEST related
parts from packaging plugins ? into a single location.
One thing might be a problem if artifacts are signed and
the information should be put into MANIFEST ? (Not sure)..
cause in the prepare-package phase the artifacts are
not yet packaged....
But based on things like moving the life cycle definitions
into the plugins it could be configured to bind two plugins
to the package phase like this:
<package>
org.apache.maven.plugins:maven-manifest-plugin:..:jar,
org.apache.maven.plugins:maven-plugin-jar-plugin:..:jar
</package>
Could that work?
WDYT ?
Kind regards
Karl Heinz Marbaise
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [RFC] MJAR-193
Posted by Tibor Digana <ti...@apache.org>.
Hi,
Package binding together with m-manifest-p sound like a bit of packaging,
it could be m-shade-p then there as well.
But I understand that you want to provide a bigger comfort to the users.
Having m-manifest-p would force creation of Manifest and the other like BND
plugins to merge the content instead of creating it from scratch or the
m-manifest-p would have to perform merge.
Instead the *ManifestResourceTransformer *looks like fine solution to me in
standard Maven plugins.
It seems you want to extend other non-standard plugins as well and then
*m-manifest-p* would be necessary to have but I guess we will receive new
feature requests in it.
Cheers
Tibor
On Sun, May 1, 2016 at 5:54 PM, Robert Scholte-6 [via Maven] <
ml-node+s40175n5866744h4@n5.nabble.com> wrote:
> Hi,
>
> I'm not into OSGi, so I don't fully understand the requirement.
> But what I can say is that one of the principals of Maven is that
> maven-plugins don't depend on each other.
> Regarding the MANIFEST.MF file, I think that both the maven-ear-plugin and
>
> the maven-shade-plugin are good examples of how this should work.
> The maven-ear-plugin is capable to transform a common war to a skinny war
>
> and change the wars classpath in the MANIFEST file.
> The maven-shade-plugin has a ManifestResourceTransformer which does its
> job fine.
> Can this plugin help for the mentioned problem?
>
> my 2 cents,
> Robert
>
> On Sun, 01 May 2016 14:10:53 +0200, Karl Heinz Marbaise
> <[hidden email] <http:///user/SendEmail.jtp?type=node&node=5866744&i=0>>
> wrote:
>
> > Hi,
> >
> > currently there are some requirements to allow other mojo's to
> > contribute to MANIFEST.MF which is used during the package of for
> > example of maven-jar-plugin...
> >
> > The question is:
> > o Does someone has a good idea to solve such things ?
> > Or what might be a good direction to go?
> >
> > o Let other mojo's / tools write a partial MANIFEST.MF
> > (to a special location?) and let for example maven-jar-plugin
> > pick this up and merge this with other information into
> > the final MANIFEST.MF file?
> >
> > o Or should we allow to transfer such information via
> > the project context in Maven itself ? (which might
> > not be a good idea cause it might influence other
> > mojo's?)
> >
> > o Or might it be worth thinking of a special Maven
> > plugin which handles such things in general and
> > all other packaging plugins (just pick the resulting
> > MANFIFEST.MF) and package it into jar, war, ear, rar etc.
> > (Hm..i'm not sure if this is a good idea, cause it might
> > cause problems with putting classpath information into
> > MANIFEST.MF ?) but if we are in prepare-package phase?
> >
> >
> > ...
> > prepare-package: maven-manifest-plugin (?)
> > package: maven-jar-plugin
> > ...
> >
> > This would result in removing all MANIFEST related
> > parts from packaging plugins ? into a single location.
> >
> > One thing might be a problem if artifacts are signed and
> > the information should be put into MANIFEST ? (Not sure)..
> > cause in the prepare-package phase the artifacts are
> > not yet packaged....
> >
> > But based on things like moving the life cycle definitions
> > into the plugins it could be configured to bind two plugins
> > to the package phase like this:
> >
> > <package>
> > org.apache.maven.plugins:maven-manifest-plugin:..:jar,
> > org.apache.maven.plugins:maven-plugin-jar-plugin:..:jar
> > </package>
> >
> > Could that work?
> >
> >
> >
> > WDYT ?
> >
> > Kind regards
> > Karl Heinz Marbaise
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [hidden email]
> <http:///user/SendEmail.jtp?type=node&node=5866744&i=1>
> > For additional commands, e-mail: [hidden email]
> <http:///user/SendEmail.jtp?type=node&node=5866744&i=2>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> <http:///user/SendEmail.jtp?type=node&node=5866744&i=3>
> For additional commands, e-mail: [hidden email]
> <http:///user/SendEmail.jtp?type=node&node=5866744&i=4>
>
>
>
> ------------------------------
> If you reply to this email, your message will be added to the discussion
> below:
> http://maven.40175.n5.nabble.com/RFC-MJAR-193-tp5866710p5866744.html
> To start a new topic under Maven Developers, email
> ml-node+s40175n142166h86@n5.nabble.com
> To unsubscribe from Maven Developers, click here
> <http://maven.40175.n5.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=142166&code=dGlib3JkaWdhbmFAYXBhY2hlLm9yZ3wxNDIxNjZ8LTI4OTQ5MjEwMg==>
> .
> NAML
> <http://maven.40175.n5.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>
>
--
View this message in context: http://maven.40175.n5.nabble.com/RFC-MJAR-193-tp5866710p5866779.html
Sent from the Maven Developers mailing list archive at Nabble.com.
Re: [RFC] MJAR-193
Posted by Robert Scholte <rf...@apache.org>.
Hi,
I'm not into OSGi, so I don't fully understand the requirement.
But what I can say is that one of the principals of Maven is that
maven-plugins don't depend on each other.
Regarding the MANIFEST.MF file, I think that both the maven-ear-plugin and
the maven-shade-plugin are good examples of how this should work.
The maven-ear-plugin is capable to transform a common war to a skinny war
and change the wars classpath in the MANIFEST file.
The maven-shade-plugin has a ManifestResourceTransformer which does its
job fine.
Can this plugin help for the mentioned problem?
my 2 cents,
Robert
On Sun, 01 May 2016 14:10:53 +0200, Karl Heinz Marbaise
<kh...@gmx.de> wrote:
> Hi,
>
> currently there are some requirements to allow other mojo's to
> contribute to MANIFEST.MF which is used during the package of for
> example of maven-jar-plugin...
>
> The question is:
> o Does someone has a good idea to solve such things ?
> Or what might be a good direction to go?
>
> o Let other mojo's / tools write a partial MANIFEST.MF
> (to a special location?) and let for example maven-jar-plugin
> pick this up and merge this with other information into
> the final MANIFEST.MF file?
>
> o Or should we allow to transfer such information via
> the project context in Maven itself ? (which might
> not be a good idea cause it might influence other
> mojo's?)
>
> o Or might it be worth thinking of a special Maven
> plugin which handles such things in general and
> all other packaging plugins (just pick the resulting
> MANFIFEST.MF) and package it into jar, war, ear, rar etc.
> (Hm..i'm not sure if this is a good idea, cause it might
> cause problems with putting classpath information into
> MANIFEST.MF ?) but if we are in prepare-package phase?
>
>
> ...
> prepare-package: maven-manifest-plugin (?)
> package: maven-jar-plugin
> ...
>
> This would result in removing all MANIFEST related
> parts from packaging plugins ? into a single location.
>
> One thing might be a problem if artifacts are signed and
> the information should be put into MANIFEST ? (Not sure)..
> cause in the prepare-package phase the artifacts are
> not yet packaged....
>
> But based on things like moving the life cycle definitions
> into the plugins it could be configured to bind two plugins
> to the package phase like this:
>
> <package>
> org.apache.maven.plugins:maven-manifest-plugin:..:jar,
> org.apache.maven.plugins:maven-plugin-jar-plugin:..:jar
> </package>
>
> Could that work?
>
>
>
> WDYT ?
>
> Kind regards
> Karl Heinz Marbaise
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org