Is there any documentation on the details of context resolution? > -----Original Message----- > From: Eric Giguere [mailto:[EMAIL PROTECTED] > Sent: Thursday, June 03, 2004 11:50 AM > To: Maven Users List > Subject: Re: Jelly variables > > > Hi Chuck > > Chuck Daniels wrote: > > >This leads me to another question, as I am relatively new to > Maven. I have > >also noticed expressions like ${context.getVariable('some.variable')}. I > >assume this retrieves the value of the variable in the current context > >versus what > >${pom.getPluginContext('plugin-context').getVariable('some.variab > le')} does. > >However, how does ${context.getVariable('some.variable')} differ from the > >simpler expression ${some.variable}? > > > > > I would say (not 100% sure though) that the same principle applies. If > you call this from one of your project goals, it shouldn't do a > difference at all. If you write some jelly code in a plugin though, that > may be a different issue. And even then, I'm not 100% sure that it will > change something since the plugin context get initialized (for maven > variables anyway) with values that are supplied by the project itself > (like basedir, maven.build.dest and others). > > Context resolution is more an issue if you to play with plugin's > variables or properties in you project or even in another plugin. > > The issue can become even more interesting in a multi-project build. > When running a maven build on multiple projects, all "standard" maven > properties and variables get new values (new contexts) for every single > project, even if its built in one shot. > > Quite powerfull indeed. > > Eric. > > > > > > >>-----Original Message----- > >>From: Eric Giguere [mailto:[EMAIL PROTECTED] > >>Sent: Wednesday, June 02, 2004 7:22 AM > >>To: Maven Users List > >>Subject: Re: Jelly variables > >> > >> > >>Hi > >> > >>Chuck Daniels wrote: > >> > >> > >> > >>>I see > ${pom.getPluginContext('plugin-name').getVariable('variable')} used > >>>frequently. However, I also see that Project.getPluginContext is > >>>deprecated. I believe that the pom bean is a Project, right? > >>> > >>> > >>> > >>Right, pom is the Project bean. > >> > >> > >> > >>> If so, what > >>>should be used in place of pom.getPluginContext? > >>> > >>> > >>> > >>Yep, you're absolutely right. The new tag is : > >> > >><maven:pluginVar /> > >> > >>But it seems that this will also be deprecated (maybe already is) > >>and replace by :get/:set type. > >>This replacement was suppose to take effect in RC3... > >> > >> > >> > >> > >>>The javadoc for the method > >>>says to use the tag instead, but doesn't say which tag. > >>> > >>> > >>Further, there are > >> > >> > >>>cases where using a tag is not possible because an expression is > >>> > >>> > >>required. > >> > >> > >>>Anybody know what should be done or should we simply continue using > >>>pom.getPluginContext? > >>> > >>> > >>> > >>> > >>I personnaly continue to use it until the tag issue is resolved once and > >>for all. Deprecation should live for at least one version, so I think we > >>may be ok for a while. > >> > >>Eric. > >> > >> > >> > >>> > >>> > >>>>-----Original Message----- > >>>>From: Eric Giguere [mailto:[EMAIL PROTECTED] > >>>>Sent: Tuesday, June 01, 2004 2:03 PM > >>>>To: Maven Users List > >>>>Subject: Re: Jelly variables > >>>> > >>>> > >>>>Hi Jon > >>>> > >>>>I'll give a try to explain the behavior. > >>>> > >>>>Plugins.. When executing, all of them have a context that is built up > >>>>live on a specific project. For every property or variable > that a plugin > >>>>declares, you must call a method of the pom bean to get the > actual value > >>>>for the property (or variable) that the plugin uses while > executing. My > >>>>guess with maven.final.name, since its a project variable, is set to > >>>>snapshotSignature only in the plugin's context. So its never > really set > >>>>back to the original value, it just didn't ever change, in your > >>>>project's context anyway. > >>>> > >>>>Did you try using this snapshotSignature value directly in > your project? > >>>>If its empty, ask the plugin for its value, maybe it'll be > available in > >>>>your post goal using this call: > >>>>${pom.getPluginContext('plugin-name').getVariable('variable') > >>>> > >>>>just guessing here... > >>>> > >>>>Hope it helps > >>>>Eric. > >>>> > >>>> > >>>>STRAYER, JON (SBCSI) wrote: > >>>> > >>>> > >>>> > >>>> > >>>> > >>>>>I have a deploy goal in my maven.xml that uses the artifact > >>>>> > >>>>> > >>>>> > >>>>> > >>>>plugin. When I > >>>> > >>>> > >>>> > >>>> > >>>>>use it to deploy the results of a jar:jar everything works fine. > >>>>> > >>>>> > >>>>> > >>>>> > >>>>When I use > >>>> > >>>> > >>>> > >>>> > >>>>>it to deploy a snapshot jar it tries to deploy the normal jar. > >>>>> > >>>>>My goal is here: > >>>>> <goal name="deploy"> > >>>>> <artifact:deploy > >>>>> artifact="${maven.build.dir}/${maven.final.name}.jar" > >>>>> type="jar" > >>>>> project="${pom}" > >>>>> /> > >>>>> </goal> > >>>>> > >>>>>As you can see, I'm using maven.final.name for the name of the > >>>>> > >>>>> > >>jar. The > >> > >> > >>>>>jar:snapshot goal sets this varaiable to ${snapshotSignature}. > >>>>> > >>>>> > >>>>> > >>>>> > >>>>But by the > >>>> > >>>> > >>>> > >>>> > >>>>>time my postGoal executes it's back to the name of the normal jar. > >>>>> > >>>>>My questions are: > >>>>>1. Is there a variable that will be available during the post > >>>>> > >>>>> > >>goal that > >> > >> > >>>>>contains the name of the jar? > >>>>>2. What is setting maven.final.name back to the default value? > >>>>> > >>>>>--------------------------------------------------------------------- > >>>>>To unsubscribe, e-mail: [EMAIL PROTECTED] > >>>>>For additional commands, e-mail: [EMAIL PROTECTED] > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>--------------------------------------------------------------------- > >>>>To unsubscribe, e-mail: [EMAIL PROTECTED] > >>>>For additional commands, e-mail: [EMAIL PROTECTED] > >>>> > >>>> > >>>> > >>>> > >>>--------------------------------------------------------------------- > >>>To unsubscribe, e-mail: [EMAIL PROTECTED] > >>>For additional commands, e-mail: [EMAIL PROTECTED] > >>> > >>> > >>> > >>> > >>> > >>> > >> > >>--------------------------------------------------------------------- > >>To unsubscribe, e-mail: [EMAIL PROTECTED] > >>For additional commands, e-mail: [EMAIL PROTECTED] > >> > >> > > > > > >--------------------------------------------------------------------- > >To unsubscribe, e-mail: [EMAIL PROTECTED] > >For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > >
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
