Re: Should a plugin appear in pluginManagement if it already appears in build/plugins?
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 CLI invocation of report plugins? Can they inherit from anywhere? 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. And some people like defining the version of plugins in the pluginMgmt section but not in build/plugins. Then you define this in a parent and only have one place to change when new versions are released. This is how I do it. Yes, that is mainly how it is being used. /Anders Thanks! On Sat, Sep 10, 2011 at 02:14, sebb seb...@gmail.com wrote: AIUI, both build/plugins and build/pluginManagement are inherited by child projects, the difference being that plugiManagement entries are only used if the child project references the plugin in its build/plugins section. That being the case, if a plugin is defined in build/plugins, is there any point also including it in the build/pluginManagement/plugins section? - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Doxia APT - possible to reference Maven properties?
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 reference Maven properties in APT documents? or environment variables? - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Should a plugin appear in pluginManagement if it already appears in build/plugins?
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 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 execution declaration. /Anders And some people like defining the version of plugins in the pluginMgmt section but not in build/plugins. Then you define this in a parent and only have one place to change when new versions are released. This is how I do it. Yes, that is mainly how it is being used. /Anders Thanks! On Sat, Sep 10, 2011 at 02:14, sebb seb...@gmail.com wrote: AIUI, both build/plugins and build/pluginManagement are inherited by child projects, the difference being that plugiManagement entries are only used if the child project references the plugin in its build/plugins section. That being the case, if a plugin is defined in build/plugins, is there any point also including it in the build/pluginManagement/plugins section? - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Should a plugin appear in pluginManagement if it already appears in build/plugins?
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 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 execution declaration. Sorry, what do you mean by that? Are you saying that there are parts of the pluginManagement definitions that are not applied to build/plugins? If so, is there any point in having the execution declaration in the pluginManagement section? /Anders And some people like defining the version of plugins in the pluginMgmt section but not in build/plugins. Then you define this in a parent and only have one place to change when new versions are released. This is how I do it. Yes, that is mainly how it is being used. /Anders Thanks! On Sat, Sep 10, 2011 at 02:14, sebb seb...@gmail.com wrote: AIUI, both build/plugins and build/pluginManagement are inherited by child projects, the difference being that plugiManagement entries are only used if the child project references the plugin in its build/plugins section. That being the case, if a plugin is defined in build/plugins, is there any point also including it in the build/pluginManagement/plugins section? - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Should a plugin appear in pluginManagement if it already appears in build/plugins?
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 execution declaration. Sorry, what do you mean by that? Are you saying that there are parts of the pluginManagement definitions that are not applied to build/plugins? If so, is there any point in having the execution declaration in the pluginManagement section? Ok, now we're talking advanced stuff. I would only put the execution declaration in the pluginMgmt section if it would be something that is to be reused by several children projects. Otherwise I would put the declaration in build/plugins/plugin in the project it belongs. But there are exceptions to this of course. One would be if you want to configure the default execution (the one from CLI) differently than the one(s) bound to the lifecycle. Then you need to re-define the default execution (which is the one from CLI) in pluginMgmt and for that execution add the configuration you want (thus, within the execution section, not on plugin level). But this is me. Others may very well have a different opinion. /Anders /Anders And some people like defining the version of plugins in the pluginMgmt section but not in build/plugins. Then you define this in a parent and only have one place to change when new versions are released. This is how I do it. Yes, that is mainly how it is being used. /Anders Thanks! On Sat, Sep 10, 2011 at 02:14, sebb seb...@gmail.com wrote: AIUI, both build/plugins and build/pluginManagement are inherited by child projects, the difference being that plugiManagement entries are only used if the child project references the plugin in its build/plugins section. That being the case, if a plugin is defined in build/plugins, is there any point also including it in the build/pluginManagement/plugins section? - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Should a plugin appear in pluginManagement if it already appears in build/plugins?
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 group. The distinction is important. For instance, if I have a tree of projects starting with the parent, I might want a plugin to be configured in only one place, but only invoked on a random subset of the children. In this case, defining the *template* is the way to go (i.e. pluginMgmt), but if I want the plugin to be used everywhere (maven-source-plugin comes to mind), I define that in the plugins section of the parent project. In the case of maven-source-plugin, if I did it as a pluginMgmt, I'd still have to *instantiate* the plugin in each build, creating four extra lines of XML in each POM (and the opportunity for someone to forget those four lines in new projects). By putting it in build/plugins, it is instantiated for *every* child build. Note there are also some pretty cool rules for defining plugins in a parent but then merging additional configuration in children. I don't remember them all, but this can be done to great effect, allowing a plugin defined in a parent to have different/additional configuration in a child. $0.02 Brian On Sep 10, 2011, at 8:19 AM, Anders Hammar 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 build/plugins would then just contain the groupId/artifactId. Yes, and the execution declaration. Sorry, what do you mean by that? Are you saying that there are parts of the pluginManagement definitions that are not applied to build/plugins? If so, is there any point in having the execution declaration in the pluginManagement section? Ok, now we're talking advanced stuff. I would only put the execution declaration in the pluginMgmt section if it would be something that is to be reused by several children projects. Otherwise I would put the declaration in build/plugins/plugin in the project it belongs. But there are exceptions to this of course. One would be if you want to configure the default execution (the one from CLI) differently than the one(s) bound to the lifecycle. Then you need to re-define the default execution (which is the one from CLI) in pluginMgmt and for that execution add the configuration you want (thus, within the execution section, not on plugin level). But this is me. Others may very well have a different opinion. /Anders /Anders And some people like defining the version of plugins in the pluginMgmt section but not in build/plugins. Then you define this in a parent and only have one place to change when new versions are released. This is how I do it. Yes, that is mainly how it is being used. /Anders Thanks! On Sat, Sep 10, 2011 at 02:14, sebb seb...@gmail.com wrote: AIUI, both build/plugins and build/pluginManagement are inherited by child projects, the difference being that plugiManagement entries are only used if the child project references the plugin in its build/plugins section. That being the case, if a plugin is defined in build/plugins, is there any point also including it in the build/pluginManagement/plugins section? - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Should a plugin appear in pluginManagement if it already appears in build/plugins?
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 build/plugins would then just contain the groupId/artifactId. Yes, and the execution declaration. Sorry, what do you mean by that? Are you saying that there are parts of the pluginManagement definitions that are not applied to build/plugins? If so, is there any point in having the execution declaration in the pluginManagement section? Ok, now we're talking advanced stuff. I would only put the execution declaration in the pluginMgmt section if it would be something that is to be reused by several children projects. Otherwise I would put the declaration in build/plugins/plugin in the project it belongs. But there are exceptions to this of course. One would be if you want to configure the default execution (the one from CLI) differently than the one(s) bound to the lifecycle. Then you need to re-define the default execution (which is the one from CLI) in pluginMgmt and for that execution add the configuration you want (thus, within the execution section, not on plugin level). So what you appear to be saying is that the pluginManagement execution configuration *is* inherited? But that you might not want to provide the execution config there if it is not generic. If I understand correctly, then supposing I want the same config (execution and all) everywhere it is used, then I can use pluginManagement in the parent to define everything. If parent and all its children use the plugin, then reference the bare plugin (no config) in the parent/build/plugins. Otherwise reference it (no config) in the child/build/plugins The pluginManagement settings will I assume apply to all CLI (i.e. goal) invocations. This is presumably because individual goal invocation is not part of a phase and so ignores what is in build/plugins But this is me. Others may very well have a different opinion. /Anders /Anders And some people like defining the version of plugins in the pluginMgmt section but not in build/plugins. Then you define this in a parent and only have one place to change when new versions are released. This is how I do it. Yes, that is mainly how it is being used. /Anders Thanks! On Sat, Sep 10, 2011 at 02:14, sebb seb...@gmail.com wrote: AIUI, both build/plugins and build/pluginManagement are inherited by child projects, the difference being that plugiManagement entries are only used if the child project references the plugin in its build/plugins section. That being the case, if a plugin is defined in build/plugins, is there any point also including it in the build/pluginManagement/plugins section? - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
reports inheritance - parent can disinherit, can child refuse to inherit?
[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 child reporting plugin refuse to inherit from its parent? For example, if the parent and most children need the same set of reports, but one child does not need some of the reports. This does not appear to be possible except by defining the required set of reports in each project, parent included. The parent config has to disinherit the children, otherwise they will all get the full set of reports. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: reports inheritance - parent can disinherit, can child refuse to inherit?
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... Regards, Hervé Le samedi 10 septembre 2011, sebb a écrit : [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 child reporting plugin refuse to inherit from its parent? For example, if the parent and most children need the same set of reports, but one child does not need some of the reports. This does not appear to be possible except by defining the required set of reports in each project, parent included. The parent config has to disinherit the children, otherwise they will all get the full set of reports. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Doxia APT - possible to reference Maven properties?
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é [1] http://maven.apache.org/doxia/doxia-sitetools/index.html Le samedi 10 septembre 2011, sebb a écrit : On 10 September 2011 05:01, Lukas Theussl ltheu...@apache.org wrote: http://maven.apache.org/plugins/maven-site-plugin/examples/creating-conte nt.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 reference Maven properties in APT documents? or environment variables? - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Doxia APT - possible to reference Maven properties?
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] means. if you have an idea of the way to document it in a way that people will find... I did a search for APT, and found [2] and [3]; also looked at macros [4] (I'd hoped there would be a property or variable macro) The general format page [5] might also be a good place. Perhaps add a line ot each to say that the file can be pre-processed by velocity (and link to the page about that) before it is handed to the specific input processor. [2] http://maven.apache.org/doxia/references/apt-format.html [3] http://maven.apache.org/doxia/references/doxia-apt.html [4] http://maven.apache.org/doxia/macros/index.html [5] http://maven.apache.org/doxia/references/index.html Regards, Hervé [1] http://maven.apache.org/doxia/doxia-sitetools/index.html Le samedi 10 septembre 2011, sebb a écrit : On 10 September 2011 05:01, Lukas Theussl ltheu...@apache.org wrote: http://maven.apache.org/plugins/maven-site-plugin/examples/creating-conte nt.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 reference Maven properties in APT documents? or environment variables? - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Should a plugin appear in pluginManagement if it already appears in build/plugins?
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 supposing I want the same config (execution and all) everywhere it is used, then I can use pluginManagement in the parent to define everything. Yes. I believe Brian explained this very well. If parent and all its children use the plugin, then reference the bare plugin (no config) in the parent/build/plugins. Otherwise reference it (no config) in the child/build/plugins Yes, I guess. But, I wouldn't make it more complicated than it is. If you're adding the binding in the parent, then I would define everything (possibly except the version) in parent/build/plugins. No need to split it between pluginMgmt and plugin. It would just make the pom harder to read. The pluginManagement settings will I assume apply to all CLI (i.e. goal) invocations. Yes, if you add the config on the plugin level and not on a specific execution. This is presumably because individual goal invocation is not part of a phase and so ignores what is in build/plugins Right, and this has tricked a lot of new Maven users. /Anders But this is me. Others may very well have a different opinion. /Anders /Anders And some people like defining the version of plugins in the pluginMgmt section but not in build/plugins. Then you define this in a parent and only have one place to change when new versions are released. This is how I do it. Yes, that is mainly how it is being used. /Anders Thanks! On Sat, Sep 10, 2011 at 02:14, sebb seb...@gmail.com wrote: AIUI, both build/plugins and build/pluginManagement are inherited by child projects, the difference being that plugiManagement entries are only used if the child project references the plugin in its build/plugins section. That being the case, if a plugin is defined in build/plugins, is there any point also including it in the build/pluginManagement/plugins section? - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: reports inheritance - parent can disinherit, can child refuse to inherit?
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 many elements of the pom. If you have an idea about something easyto understand from a user perspective... The parent can currently do the following to prevent all inheritance reporting plugins plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-project-info-reports-plugin/artifactId inheritedfalse/inherited reportSets However, that does not allow some reports to apply to the parent only; it is all or nothing. Although the inherited element is also allowed within a reportSet, that does not seem to prevent the reports from being generated in Maven 2.2.1. [seems to work in M303, provided that the id is omiitted or has the value default (which is the default) ] There ought to be a way for the parent to specify its own private reports separately from the reports that should be inherited. If the reportSet/inherited element worked properly, that would solve the issue for the parent. Being able to configure the parent to pass on some reports but not others would be helpful in many cases, but equally, its children should be able to refuse reports specified by the parent. Perhaps the combine.children/combine.self configuration attribute could be extended to reportSet? S P.S. Unfortunately, the word inherited is ambiguous; in this case it means will it be inherited, rather than the usual spoken meaning as in the child inherited from its parent. It would perhaps have been clearer if the element was called inheritable; the child version could then be called inherit. But I think that would be too confusing now. Regards, Hervé Le samedi 10 septembre 2011, sebb a écrit : [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 child reporting plugin refuse to inherit from its parent? For example, if the parent and most children need the same set of reports, but one child does not need some of the reports. This does not appear to be possible except by defining the required set of reports in each project, parent included. The parent config has to disinherit the children, otherwise they will all get the full set of reports. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Should a plugin appear in pluginManagement if it already appears in build/plugins?
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 generic for all children, then yes. Yes. If I understand correctly, then supposing I want the same config (execution and all) everywhere it is used, then I can use pluginManagement in the parent to define everything. Yes. I believe Brian explained this very well. Yes. If parent and all its children use the plugin, then reference the bare plugin (no config) in the parent/build/plugins. Otherwise reference it (no config) in the child/build/plugins Yes, I guess. But, I wouldn't make it more complicated than it is. If you're adding the binding in the parent, then I would define everything (possibly except the version) in parent/build/plugins. No need to split it between pluginMgmt and plugin. It would just make the pom harder to read. Now you're confusing me again. You say - below - that CLI (goal) invocations ignore the build/plugins settings. If so, then surely it's better to define everything in pluginMgmt, and just leave the build/plugins section to reference the plugin? In which case both goal and phase invocations share the settings. Otherwise CLI(goal) invocations might not be fully configured. The pluginManagement settings will I assume apply to all CLI (i.e. goal) invocations. Yes, if you add the config on the plugin level and not on a specific execution. This is presumably because individual goal invocation is not part of a phase and so ignores what is in build/plugins Right, and this has tricked a lot of new Maven users. /Anders But this is me. Others may very well have a different opinion. /Anders /Anders And some people like defining the version of plugins in the pluginMgmt section but not in build/plugins. Then you define this in a parent and only have one place to change when new versions are released. This is how I do it. Yes, that is mainly how it is being used. /Anders Thanks! On Sat, Sep 10, 2011 at 02:14, sebb seb...@gmail.com wrote: AIUI, both build/plugins and build/pluginManagement are inherited by child projects, the difference being that plugiManagement entries are only used if the child project references the plugin in its build/plugins section. That being the case, if a plugin is defined in build/plugins, is there any point also including it in the build/pluginManagement/plugins section? - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Doxia APT - possible to reference Maven properties?
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 doxia-site-renderer [6] and doxia-doc-renderer [7], which are only *using* Doxia core: other tools can integrate Doxia core, without this Velocity feature Explaining Velocity feature in Doxia core means pointing to a specific use case. I'll see how to do that Regards, Hervé [6] http://maven.apache.org/doxia/doxia-sitetools/doxia-site- renderer/xref/org/apache/maven/doxia/siterenderer/DefaultSiteRenderer.html#105 [7] http://maven.apache.org/doxia/doxia-sitetools/doxia-doc- renderer/xref/org/apache/maven/doxia/docrenderer/AbstractDocumentRenderer.html#82 Le samedi 10 septembre 2011, sebb a écrit : 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] means. if you have an idea of the way to document it in a way that people will find... I did a search for APT, and found [2] and [3]; also looked at macros [4] (I'd hoped there would be a property or variable macro) The general format page [5] might also be a good place. Perhaps add a line ot each to say that the file can be pre-processed by velocity (and link to the page about that) before it is handed to the specific input processor. [2] http://maven.apache.org/doxia/references/apt-format.html [3] http://maven.apache.org/doxia/references/doxia-apt.html [4] http://maven.apache.org/doxia/macros/index.html [5] http://maven.apache.org/doxia/references/index.html Regards, Hervé [1] http://maven.apache.org/doxia/doxia-sitetools/index.html Le samedi 10 septembre 2011, sebb a écrit : On 10 September 2011 05:01, Lukas Theussl ltheu...@apache.org wrote: http://maven.apache.org/plugins/maven-site-plugin/examples/creating-co nte nt.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 reference Maven properties in APT documents? or environment variables? - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Auto building parent and sibling projects as needed
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? Could I be missing a concept on maven usage? I have a project which has a very large set of parent/child/sibling dependencies I am migrating from our ant build system. When an engineer needs to make changes on their part it would be best for them to execute mvn from that parts directory. -Jason -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- - - - Jason Pyeron PD Inc. http://www.pdinc.us - - Principal Consultant 10 West 24th Street #100- - +1 (443) 269-1555 x333Baltimore, Maryland 21218 - - - -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- This message is copyright PD Inc, subject to license 20080407P00. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
