I've only been using maven a short while now, but I agree whole heartedly. There is no simply overlaying of properties.
Typically, in an ant based build, you have three levels of overlayment - 1 - build.properties next to the build.xml, all standard installations of 3rd party tools, schema names, etc. go here. 2 - build.properties in ${user.home}, this one contains custom installations of various products, user names/passwords to things like perforce, etc 3 - ${branch.name}.properties, again in the ${user.home} directory, but used to override things that are changing per branch (say you want to test a new version of an appserver jar in one branch but don't want to interrupt your work in another). People can tell me about settings.xml and profiles.xml until my inbox bursts, but there is no way to simply have these things work as they do in ant. In ant, with out the user having to activate a profile, the above property files are read in (if they don't exist there aren't any errors, they simply aren't loaded). >From the get go, there are TWO very large sticking points - 1 - User configurability (as mentioned above) 2 - Maven 2 still crawls across the internet for some maven-plugin pom files (there's supposedly a jira bug against this). Since we've committed ourselves to moving forward with maven 2, we plan on work arounds for the above mentioned things (dns server entry to point at an internal repository, user education on how to use profiles, etc). I'm not thrilled about the solutions (in addition to the duplication of some jars on the local systems), but what can you do? -----Original Message----- From: Jan Willems [mailto:[EMAIL PROTECTED] Sent: Sunday, April 30, 2006 12:21 PM To: users@maven.apache.org Subject: [m2] [2.0.4] Property Management Hello there, I am working on Maven 2 for quite a while now. I like the tool a lot, it helps the developers -and- the project leads. It is a real gift. I feel however that there is a (major?) issue with the propery management in Maven. In both the concept and the implementation. {settings.xml} The settings.xml seems to be the perfect place to put certain values specificly for one (single) user for several projects. Examples of such a settings would be a SUbversion username or a database password. Also the settings.xml could contain specific proxy host and port values (and authentication data for that single user). {profiles.xml} It is obvious that the settings.xml can not contain data for one single project. I feel that there must be specific file containing the different values per project. Indeed, the profiles.xml can be used to specify project specific properties. Sadly one can not use: myproperty = abc=def The the model parser will throw exceptions. One has to use the <myproperty><![CDATA[abc=def]]></myproperty> in stead. This is not a good way to specify properties, I believe. Also, property handling is not very powerful. When specifying 4 properties: <database-type>mysql</database-type> <database-host>localhost</database-host> <database-port>3306</database-port> <database-name>foobar</database-name> And trying to use these properties in the same profile: <database-url> jdbc:${database-type}://${database-host}:${database-port}/${database-nam e} </databse-url> The ${database-url} would return jdbc:null://null:null/null {model needs improvement} Also the profile.xml model is tiny. A profile only contains properties and activation elements (and reposiotories - but they do not take part in this property handling topic). This is far too little: it would be good to be able to specify much more in a profile (almost as much as in a regular om model, I would assume). Also conditional execution would be handy in the profile.xml. Say we are building a war that should run on several application servers. One could specify several plugins to start|stop|deploy|undeploy the web server or activate or deactivate the built application in the pom.xml. This would result in a pom.xml that is too big and incomplete. It would be much nicer to be able to add plugins when certain properties are set. For example, one could specify webserver.name = jetty6x in a ${project.name}.properties file (or in the upgraded profile.xml). When such a file read by Maven (before processing the pom.xml) the pom could be filled with extra (conditional) plugins following the guidelines in the ${project.name}.properties (or profiles.xml) file. The same example can be given regarding database access. [I know some issues could arrise as specified in http://maven.apache.org/guides/introduction/introduction-to-profiles.htm l, at the 'profile pitfalls' section. Solution can be found for this.] Many property handling issues (related to this rant) can be found: http://www.nabble.com/-m2-property-filtering-at-runtime-question-t129636 4.html#a3451790 http://www.nabble.com/conditionally-loading-property-files-t1412492.html #a3806540 http://www.nabble.com/Maven-2.0.4-problem-with-properties-t1445796.html# a3905175 http://www.nabble.com/maven-2-specify-properties-file-t461893.html#a1260 787 http://www.nabble.com/Maven-properties-inside-java-code-t209452.html#a58 4456 Maven 2 is indeed much cleaner, more elegant and more powerful, but Ant's property management is plainly better designed and implemented, I believe. Any remarks on this? I might be totally of mark. Am I? Jan -- View this message in context: http://www.nabble.com/-m2-2.0.4-Property-Management-t1533316.html#a41655 56 Sent from the Maven - Users forum at Nabble.com. --------------------------------------------------------------------- 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]