Thanks for the reply.
When you say "system properties" I think Java System properties, but I'm
going to assume you mean operating system environment variables.
Actually, I have been using environment variables to help _enable_ the
portability of Ant scripts. We have developers that work on Linux, Mac,
and Windows. We sign JARs and WARs when we build and each developer has
their own keystore for building locally on their computer. When we
release the product to the customer, we sign using a company keystore.
We allow the developers to specify their own keystore, password, and
alias via environment variables on their computer, and Ant uses those
values for signing.
In Maven, I would like to be able to do something like this:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-jar-plugin</artifactId>
<executions>
<execution>
<goals>
<goal>sign</goal>
</goals>
</execution>
</executions>
<configuration>
<keystore>$KEYSTORE_FILE</keystore>
<storepass>$KEYSTORE_PASS</storepass>
<alias>$KEYSTORE_ALIAS</alias>
<jarPath>${project.build.directory}/${project.build.finalName}.jar</jarPath>
</configuration>
</plugin>
and have $KEYSTORE_FILE, $KEYSTORE_PASS, and $KEYSTORE_ALIAS read as
environment variables. But Maven doesn't support this, so I had to
create a settings.xml file with a profile that defined the three
properties. This means that all of my developers will have to create a
settings.xml of their own instead of just simply setting three
environment variables.
Another benefit of using environment variables is that I can use the
enironment variable to specify a value that will be used both in the
Maven build process and in some other way that doesn't involve Maven.
For example, another environment variable that I use in the current Ant
build process is $CATALINA_BASE for configuring Tomcat. This environment
variable is used by both Tomcat and the build process (for deployment of
a generated WAR). Using an environment variable and Ant, I only have to
specify this value once. If I use Maven, I have to specify this value
twice, as an environment variable, and in a profile in settings.xml,
because properties specified in settings.xml can only be used in Maven.
I don't think that incorporating environment variables in Maven hinders
portability. It just depends on how people use the environment variables
in the build process. There are certainly things that I could put in my
pom.xml right now that would hinder portability. At some point you have
to leave those decisions up to the developer trying to use Maven. Build
processes can be widely different from one project to another. Adding
support for environment variables in Maven just makes it more flexible,
which means more developers will be inclined to use it.
If you are worried that environment variables would clash with
properties, then why not make the environment variables use a different
syntax than the ${property} syntax?
I'll look to see if there is a JIRA issue related to this topic.
Thanks,
Richard Allen
John Casey wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
I don't think filtering currently handles resolving system properties,
but it's likely there is a jira issue for that already. If not, would
you like to file one? I agree that this is important for filtering.
As for POM values, allowing interpolation with system properties/envars
is dangerous, and can easily make the build result non-portable. For
example, if your environment defines -Dfoo=bar, and you have ${foo} for
your project's version, you're artifact version would be 'bar'. If I ran
the same build (not knowing about the environmental configuration
requirements), my resulting version would be '${foo}'...even though it's
the same project. You could have similar problems with groupId, or
artifactId, or...
One of the main goals of Maven is to provide build portability, so
project builds don't depend on environmental configuration of the build
manager's machine (at least, no more than is absolutely necessary).
Cheers,
john
Richard Allen wrote:
| How do you reference environment variables in your build, for
filtering,
| settings in pom.xml, etc.? It seems as though you can't, which is
| significantly limiting. Environment variables are widely used across
| platforms.
|
| Thanks,
| Richard Allen
|
| ---------------------------------------------------------------------
| To unsubscribe, e-mail: [EMAIL PROTECTED]
| For additional commands, e-mail: [EMAIL PROTECTED]
|
|
|
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)
iD8DBQFDdMeFK3h2CZwO/4URAsdqAJ0UrtawSKHxCBaKTjQjPMYlTZ6TeACcD7UK
WjM0RiIkpi7LEKV5ZzvnjT8=
=Gk5r
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
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]
