I think almost of the required functionality of this proposal can be achieved using the latest enforcer release. The requireProperty[1] rule can check if a property is set and optionally regex the value. There is also a beanShell[2] rule that allows similar checks.
The same reasons[3] we decided to make a plugin instead of modifying the <prerequisites> tag apply here. [1] http://maven.apache.org/plugins/maven-enforcer-plugin/rules/requirePrope rty.html [2] http://maven.apache.org/plugins/maven-enforcer-plugin/rules/evaluateBean shell.html [3] http://www.nabble.com/Control-of-maven-using-prerequisites-tf3231437s177 .html#a8979318 -----Original Message----- From: news [mailto:[EMAIL PROTECTED] On Behalf Of Jochen Kuhnle Sent: Thursday, July 12, 2007 5:57 AM To: dev@maven.apache.org Subject: Re: Proposal: Required declaration of properties in pom.xml On 2007-07-10 13:04:50 +0200, Kenney Westerhof <[EMAIL PROTECTED]> said: > >>> currently, Maven does not require declaration of properties used in the >>> pom, you just use them anywhere you like. Usually, if a property is >>> missing, bad things tend to happen because it is replaced with the >>> string "null". On a good day, resources from "translations-null-null" > > When/where is it null? Just an example. What I was trying to say is that if a required property is missing, and the developer forgot to set a default, the build will do unexpected things. Mostly happens to me though when build paths depend on properties. > >>> aren't included in the build, on bad days it's worse... And when you >>> find the missing property in a pom you haven't written, you have to >>> figure out what "${lopt}" means and what its legal values are... > > True, but proper defaults should be specified in the pom itself using > the normal properties tag. Commandline, profiles, and settings > can override these. A pom should just work out of the box. If you > want to customize it you'll have to read the pom to see what can be customized; > there should be a readme or documentation in the pom for that. It may not be possible to set a proper default in the pom, because the property depends on the user's system or organization. Examples are a deployment location or the local company repository. I think it is better to specify that such a value is required (and tell the user about this) than to put a default in there that the user surely cannot work with. I first proposed to make the declaration mandatory, so the specification of proper defaults would be required, instead of optional and error-prone. I forgot about plugins... So the proposal should be downscaled to "required specification if the property is referenced in the pom.xml in any way". This would enforce the "working out of the box" of the pom, and people know where to look for the property documentation. In addition, having a property specification allows for additional nice things, e.g. "mvn -interactive", promping you for the options. Commandline, profiles and settings still can override these, but if the property is fully specified, only legal values can be used, preventing unexpected behaviour. > > There's lots of cases where properties are used - pom interpolation, > plugin configuration, filtering.. which one are you talking about? All properties referenced in the pom.xml > > For pom interpolation, you may not always want properties evaluated. > In any case, if the property can't be evaluated, the ${expression} is > left intact. So the null case doesn't apply here.. > > For plugin configuration, you cannot possibly list all properties for all > plugins out there. > > For filtering, you may just want to print a warning or fail; this could > be configured in the resources plugin. > > So how/when do you get the 'translations-null-null' problem exactly? > > I don't like the proposal as it's way too verbose The minimal specification would only be <property> <name>xyz</name> <value>123</value> </property> It's a bit more verbose than the current form, but all in all, poms are not known for their brevity ;-) > and as others have said > only fixes a small set of problems you may have, but doesn't cover all > cases. In my experience, this these are the problems that occur the most. Of course, this observation is not gerneralizable. However, I think that specifying what you use is a good principle, and property handling seems an odd case in the "formalize-everything-you-can" pom format. True, the plugin case cannot be handled, since you never know what a plugin does, so this should be outside of the scope of the proposal. If a plugin is missing a required property, it would be the job of the plugin to complain. As a sidetrack, maybe there is a better way to configure plugins than properties. From a plugin developer standpoint, it seems a bit redundant to do @parameter expression="${myproperty}" in many places just to make a plugin parameter configurable from the command line or settings.xml. From a user standpoint "--test:skip" would be nicer than "-Dmaven.test.skip" (although I guess that every Maven user can type the latter very fast :-). > > There's an issue out there to make all property references/declarations > in the pom the same, preferrably <propname>value</propname>. > Perhaps a '<propertyManagement>' section is more appropriate? :) I'll update the proposal. Thanks for the comments. Regards, Jochen > >>> >>> So instead typing >>> >>> <properties> >>> <lopt>en_US</lopt> >>> </properties> >>> >>> this proposal wants you to write >>> >>> <properties> >>> <property> >>> <name>lopt</name> >>> <defaultValue>en_US</defaultValue> >>> <required>true</required> >>> <description>Locale to use</description> >>> <options> >>> <option> >>> <value>de_DE</value> >>> <description>Use German locale</description> >>> </option> >>> </options> >>> </property> >>> </properties> > > This is rather verbose. Do you really want to list all locales in this case? > >>> >>> Of course, Maven should display an error if a required variable is >>> missing. And it would be nice to have "help:describe-properties"... > > -- Kenney > > >>> >>> Regards, >>> Jochen >>> >>> >>> >>> --------------------------------------------------------------------- >>> 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]
