You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Jason van Zyl <jv...@maven.org> on 2003/12/10 17:33:12 UTC
Deprecation of POM interpolation in properties
Howdy,
I'm moving along with the maven-project component and I have arbitrary
levels of inheritance working for properties and the model.
Now I'm starting to look at the property interpolation mechanism and I
would like to propose for 1.1 that values in properties files be
interpolated in the model values but ${pom.foo} values not be
interpolated in properties values.
The first reason is that it makes the process a lot more clear and
second I'm not sure if having model values interpolated in properties
values is really of any use. I think when we have cases like:
maven.xdoc.version = ${pom.currentVersion}
We could really just use the ${pom.currentVersion} directly in the
relevant plugin instead of putting it in a property and then sucking it
back in.
At any rate, to make the project processing in 1.1 highly deterministic
I would like to remove ${pom.foo} value interpolation in properties
files.
--
jvz.
Jason van Zyl
jason@zenplex.com
http://tambora.zenplex.org
In short, man creates for himself a new religion of a rational
and technical order to justify his work and to be justified in it.
-- Jacques Ellul, The Technological Society
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Deprecation of POM interpolation in properties
Posted by Jason van Zyl <jv...@maven.org>.
On Wed, 2003-12-10 at 18:32, matt wrote:
> If I've understood what you're suggesting, we currently depend on this
> feature.
Yes, but I'm asking you to think about why you are and if it would be
possible to achieve what you are after without it.
> As an example, in order to get war:webapp to build to a directory named
> ".war" (which is necessary for in-place deployment), we must override
> maven.war.webapp.dir, and in order to produce versioned war archives
> (which is necessary for managing deployment to system test), we must
> override maven.war.final.name. Both of these need to reference pom
> information, including version and artifact id.
This sounds like a problem with the war plugin. I fairly certainly
anything like this can be corrected.
> We also use this feature to manage generated code (from jspc and xdoclet
> run from maven.xml).
>
> It would be fine if the war plugin handled this more flexibly, which is
> perhaps what you're suggesting,
Exactly.
> but in the event that a plugin author
> did not foresee the consequences of some design decision, this allows
> workarounds until features are implemented in the plugin.
This is why this is a change for 1.1 as there will be no way to work
around it and you'll have to write the plugin in a more conformant
manner in the first place.
> Perhaps, though, the lack of this feature would lead to more flexible
> use of properties in the plugins... and force me to write plugins for
> the maven.xml snippets I use ;-)
Again, bingo!
>
> Matt
>
> Jason van Zyl wrote:
>
> >On Wed, 2003-12-10 at 11:33, Jason van Zyl wrote:
> >
> >
> >>Howdy,
> >>
> >>I'm moving along with the maven-project component and I have arbitrary
> >>levels of inheritance working for properties and the model.
> >>
> >>Now I'm starting to look at the property interpolation mechanism and I
> >>would like to propose for 1.1 that values in properties files be
> >>interpolated in the model values but ${pom.foo} values not be
> >>interpolated in properties values.
> >>
> >>The first reason is that it makes the process a lot more clear and
> >>second I'm not sure if having model values interpolated in properties
> >>values is really of any use. I think when we have cases like:
> >>
> >>maven.xdoc.version = ${pom.currentVersion}
> >>
> >>We could really just use the ${pom.currentVersion} directly in the
> >>relevant plugin instead of putting it in a property and then sucking it
> >>back in.
> >>
> >>At any rate, to make the project processing in 1.1 highly deterministic
> >>I would like to remove ${pom.foo} value interpolation in properties
> >>files.
> >>
> >>
> >
> >Another point that I wanted to raise was that properties may ultimately
> >come from other sources such as database, or ldap and how much sense
> >does it make for those sources to have access to the POM. I honestly
> >don't think a whole lot. I think properties should just be flat
> >name/value pairs with no ${pom} interpolation.
> >
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
--
jvz.
Jason van Zyl
jason@zenplex.com
http://tambora.zenplex.org
In short, man creates for himself a new religion of a rational
and technical order to justify his work and to be justified in it.
-- Jacques Ellul, The Technological Society
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Deprecation of POM interpolation in properties
Posted by matt <jo...@whitesmiths.com.au>.
If I've understood what you're suggesting, we currently depend on this
feature.
As an example, in order to get war:webapp to build to a directory named
".war" (which is necessary for in-place deployment), we must override
maven.war.webapp.dir, and in order to produce versioned war archives
(which is necessary for managing deployment to system test), we must
override maven.war.final.name. Both of these need to reference pom
information, including version and artifact id.
We also use this feature to manage generated code (from jspc and xdoclet
run from maven.xml).
It would be fine if the war plugin handled this more flexibly, which is
perhaps what you're suggesting, but in the event that a plugin author
did not foresee the consequences of some design decision, this allows
workarounds until features are implemented in the plugin.
Perhaps, though, the lack of this feature would lead to more flexible
use of properties in the plugins... and force me to write plugins for
the maven.xml snippets I use ;-)
Matt
Jason van Zyl wrote:
>On Wed, 2003-12-10 at 11:33, Jason van Zyl wrote:
>
>
>>Howdy,
>>
>>I'm moving along with the maven-project component and I have arbitrary
>>levels of inheritance working for properties and the model.
>>
>>Now I'm starting to look at the property interpolation mechanism and I
>>would like to propose for 1.1 that values in properties files be
>>interpolated in the model values but ${pom.foo} values not be
>>interpolated in properties values.
>>
>>The first reason is that it makes the process a lot more clear and
>>second I'm not sure if having model values interpolated in properties
>>values is really of any use. I think when we have cases like:
>>
>>maven.xdoc.version = ${pom.currentVersion}
>>
>>We could really just use the ${pom.currentVersion} directly in the
>>relevant plugin instead of putting it in a property and then sucking it
>>back in.
>>
>>At any rate, to make the project processing in 1.1 highly deterministic
>>I would like to remove ${pom.foo} value interpolation in properties
>>files.
>>
>>
>
>Another point that I wanted to raise was that properties may ultimately
>come from other sources such as database, or ldap and how much sense
>does it make for those sources to have access to the POM. I honestly
>don't think a whole lot. I think properties should just be flat
>name/value pairs with no ${pom} interpolation.
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Deprecation of POM interpolation in properties
Posted by Jason van Zyl <jv...@maven.org>.
On Wed, 2003-12-10 at 11:33, Jason van Zyl wrote:
> Howdy,
>
> I'm moving along with the maven-project component and I have arbitrary
> levels of inheritance working for properties and the model.
>
> Now I'm starting to look at the property interpolation mechanism and I
> would like to propose for 1.1 that values in properties files be
> interpolated in the model values but ${pom.foo} values not be
> interpolated in properties values.
>
> The first reason is that it makes the process a lot more clear and
> second I'm not sure if having model values interpolated in properties
> values is really of any use. I think when we have cases like:
>
> maven.xdoc.version = ${pom.currentVersion}
>
> We could really just use the ${pom.currentVersion} directly in the
> relevant plugin instead of putting it in a property and then sucking it
> back in.
>
> At any rate, to make the project processing in 1.1 highly deterministic
> I would like to remove ${pom.foo} value interpolation in properties
> files.
Another point that I wanted to raise was that properties may ultimately
come from other sources such as database, or ldap and how much sense
does it make for those sources to have access to the POM. I honestly
don't think a whole lot. I think properties should just be flat
name/value pairs with no ${pom} interpolation.
--
jvz.
Jason van Zyl
jason@zenplex.com
http://tambora.zenplex.org
In short, man creates for himself a new religion of a rational
and technical order to justify his work and to be justified in it.
-- Jacques Ellul, The Technological Society
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org