-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Ok, I'm starting to see what you mean. There is a subtle difference
between POM interpolation and plugin parameter expression evaluation.
What you seem to be talking about here is the latter.
Currently, we support evaluation of plugin parameters using system
properties, so if you had -Dkeystore=/path/to/keystore and referenced it
via ${keystore} in the plugin configuration, it would work.
However, it looks like you'd want to take this a step further, but
allowing users to do something like: export KEYSTORE=/path/to/keystore
in their .bashrc or somesuch, and have that used for evaluation
purposes. This seems like a reasonable request, but it's not currently
supported. Would you like to file a jira issue to get it on the radar
for a future release?
cheers,
john
Richard Allen wrote:
| 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:
|
| 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]
| |
| |
| |
|>
- ---------------------------------------------------------------------
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]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)
iD8DBQFDdNj/K3h2CZwO/4URAqr+AJwKGwzAEpNmVKYWmwKhmaS7RXppTQCaAtHX
BioO7a+otTl/1xrmf5nq+cI=
=PzTN
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
