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]
