On 10 September 2011 06:51, Anders Hammar and...@hammar.net wrote:
It all depends on what you want to accomplish.
Configuration in pluginMgmt will be used if you execute the plugin
goal specifically from CLI (like mvn plugin:goal).
So the CLI case ignores anything in build/plugins?
What about
On 10 September 2011 05:01, Lukas Theussl ltheu...@apache.org wrote:
http://maven.apache.org/plugins/maven-site-plugin/examples/creating-content.html#Filtering
I see, thanks.
Perhaps there should be a link to that from the Doxia Plugin site ...
HTH,
-Lukas
sebb wrote:
Is it possible to
So the CLI case ignores anything in build/plugins?
Yes.
What about CLI invocation of report plugins?
Can they inherit from anywhere?
I don't think so. This has been one of the limitations wrt reporting plugins.
So one use case to have move the configuration to the pluginMgmt
section would
On 10 September 2011 12:10, Anders Hammar and...@hammar.net wrote:
So the CLI case ignores anything in build/plugins?
Yes.
What about CLI invocation of report plugins?
Can they inherit from anywhere?
I don't think so. This has been one of the limitations wrt reporting plugins.
So one use
So one use case to have move the configuration to the pluginMgmt
section would be if you want to have some config for the build AND for
when executing the plugin goal directly.
I take it you mean the plugin entry in build/plugins would then just
contain the groupId/artifactId.
Yes, and the
If I may compliment what Anders has said already...
One of the distinctions I make between putting a plugin declaration in a parent
POM versus a pluginMgmt is whether I want a plugin to be defined as a template
for a given group of inherited projects or invoked for every child of that same
On 10 September 2011 13:19, Anders Hammar and...@hammar.net wrote:
So one use case to have move the configuration to the pluginMgmt
section would be if you want to have some config for the build AND for
when executing the plugin goal directly.
I take it you mean the plugin entry in
[This mainly applies to the project-info-reports plugin]
The reporting/plugins/plugin entries support the inherited element;
if set to false, child projects don't inherit the plugin settings,
i.e. the parent can disinherit the child.
Is the reverse also possible, i.e. given a parent pom, can a
no, the child can override, that's all
see MNG-2807 for the same about CI management, or MNG-3124 for mailing lists
there is an inheritance configuration pattern to find then apply on many
elements of the pom.
If you have an idea about something easyto understand from a user
perspective...
yes, there should be some documentation in Doxia site
the Velocity templating feature is in Doxia Site Tools (doxia-site-renderer
and doxia-doc-renderer), not Doxia Core: the doc should go in [1]
if you have an idea of the way to document it in a way that people will find...
Regards,
Hervé
On 10 September 2011 15:49, Hervé BOUTEMY herve.bout...@free.fr wrote:
yes, there should be some documentation in Doxia site
the Velocity templating feature is in Doxia Site Tools (doxia-site-renderer
and doxia-doc-renderer), not Doxia Core: the doc should go in [1]
I've no idea what [1]
So what you appear to be saying is that the pluginManagement execution
configuration *is* inherited?
Yes, as pluginMgmt.
But that you might not want to provide the execution config there if
it is not generic.
If you mean generic for all children, then yes.
If I understand correctly, then
On 10 September 2011 15:39, Hervé BOUTEMY herve.bout...@free.fr wrote:
no, the child can override, that's all
Don't understand what you mean by that.
see MNG-2807 for the same about CI management, or MNG-3124 for mailing lists
there is an inheritance configuration pattern to find then apply
On 10 September 2011 19:35, Anders Hammar and...@hammar.net wrote:
So what you appear to be saying is that the pluginManagement execution
configuration *is* inherited?
Yes, as pluginMgmt.
But that you might not want to provide the execution config there if
it is not generic.
If you mean
ok, [1] is not easy to understand (I know I need to improve the doc, it took
me a long time to understand, now I need to explain it better)
the point is that:
1. code handling variable substitution is in fact not only variable
substitution but full Velocity power
2. it is in
I am trying to understand why maven's reactor would not add a parent and a
parent's children to the build when it is detected that the dependency is not in
the repository.
Is there a use case to NOT auto build? Or is there a technical hurdle to
overcome to accomplish this in the reactor design?
16 matches
Mail list logo
