[ http://jira.codehaus.org/browse/MAVEN-1656?page=comments#action_43970 ]
Brett Porter commented on MAVEN-1656: ------------------------------------- explanation I gave Andy. To date I haven't been able to distill this into a user readable form: Variables in a plugin are in its own, separate, jelly context. However, this context is only created when the plugin is first loaded, which is when it is first used. Unfortunately, maven:set does not initialise the plugin context. It was intended to, but caused some other problems that are documented in the JIRA issue. So, you cannot use maven:set (or get) before the plugin context is initialised. When the plugin context is initialised, it uses the variables from the current context, so anything set with j:set (no scope) is added. So using this before the plugin gets used works, but not afterwards. Using scope="parent" always works, as it puts it into the root context, shared by all - as long as the plugin has not overridden the variable in its own context. The plugin is initialised when: a) the goal you are in has a preGoal on a goal from that plugin b) attainGoal has been called for that plugin c) you have a namespace dependency on the plugin (This seems to have been unreliable and only work if you actually use a tag from the plugin though - hence the dependency handle) It is much better to use a or b if possible, then use maven:set/get exclusively. If you know the plugin has not been initialised and need to set a var, you must use j:set without a scope. j:set with a scope of parent is a last resort that will work in most but not all situations. It's a mess, and that's why m2 was a rewrite :) > Doco that explains the protocols required to allow maven.xml or any > plugin.jelly to inject values into or retrieve values from another plugin > --------------------------------------------------------------------------------------------------------------------------------------------- > > Key: MAVEN-1656 > URL: http://jira.codehaus.org/browse/MAVEN-1656 > Project: maven > Type: Bug > Components: documentation > Versions: 1.1-beta-1 > Environment: All > Reporter: Andy Glick > > > Brett recently posted a suggestion to someone who asked how to access the > contents of "plugin a" from the context of "plugin b" or from maven.xml. > Brett stated that "plugin a" would have to be initialized before it could be > accessed, and that from what I could understand he recommended 1 or 2 ways to > do that: > 1) reference the artifact plugin's namespace in the project tag > 2) specify <j:set target="plugin-name" scope="parent" var="some.plugin.var" > value="some.value"/> (I think that this is the proper syntax, but I'm not > sure :-). > Thierry Lach, who asked the question this time around, reported that using > the artifact namespace didn't work in his instance, but that setting the > scope to parent did. I'm hoping that we can put together a fairly > comprehensive explanation about what is going on here, and if that means > explaining why the project gave up on Jelly and switched to M2, then so be it. > See http://news.gmane.org/gmane.comp.jakarta.turbine.maven.user for the > postings > Given that during the last couple of months Vincent Massol recommended that > people use the now deprecated <dependency-handle> mechanism on the > mavenbook.org site (see Tip #2), I should think that there ought to be a > priority on documenting this issue in an obvious place, probably the FAQ, but > also on the Maven Jelly tags get and set entries. > If this is actually explicitly documented somewhere, I'm sorry to have wasted > anyone's time. I have seen several plugins that have successfully used the > artifact namespace tag, so there must be some way that people have learned > this. I simply wish that I knew how they had done so. ;-) > I'm willing to write the doco if someone would explain the details. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
