You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@maven.apache.org by "Sander Verhagen (JIRA)" <ji...@codehaus.org> on 2008/10/04 17:02:08 UTC

[jira] Commented: (MASSEMBLY-167) Property Expansion/Filtering does not always work for System.properties

    [ http://jira.codehaus.org/browse/MASSEMBLY-167?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=149883#action_149883 ] 

Sander Verhagen commented on MASSEMBLY-167:
-------------------------------------------

Probably suffering from the same problem.

We have a file called assembly.properties with a.o. the following lines in it:
	package-description: ${project.name}
	package-machine: ${os.name} ${os.version} ${os.arch}
	package-user: ${user.name}

This is resolved as follows:
	package-description: myprojectname
	package-machine: myprojectname 0.0.6 ${os.arch}
	package-user: myprojectname

It appears that ${xx.name} is interpreted as ${project.name} etc.

Workaround: make sure the Assembly Plugin's configuration points to a properties/filter file. A literally empty one is just fine for this.

	<plugin>
		<groupId>org.apache.maven.plugins</groupId>
		<artifactId>maven-assembly-plugin</artifactId>
		<version>2.2-beta-2</version>
		<configuration>
			<filters>
                        	<filter>${basedir}/assembly.properties</filter>
			</filters>
		...

> Property Expansion/Filtering does not always work for System.properties
> -----------------------------------------------------------------------
>
>                 Key: MASSEMBLY-167
>                 URL: http://jira.codehaus.org/browse/MASSEMBLY-167
>             Project: Maven 2.x Assembly Plugin
>          Issue Type: Bug
>    Affects Versions: 2.2
>         Environment: JDK 1.5.0_10, Maven 2.1-SNAPSHOT, Linux 2.6.18
>            Reporter: Daniel Krisher
>            Priority: Minor
>             Fix For: 2.2
>
>
> When using filtering for a file element in an assembly descriptor, System properties (e.g. java.version) are not always available (and do not get replaced in the filtered file).
> For example, my assembly descriptor contains:
> {noformat} 
>  <file>
>             <source>src/main/files/config/splash.xml</source>
>             <outputDirectory>/config</outputDirectory>
>             <filtered>true</filtered>
>  </file>
> {noformat} 
> and splash.xml (pre-filtering): 
> {noformat} 
> <properties>
>     <entry key="title">${project.name}</entry>
>     <entry key="Version">${project.version}</entry>
>     <entry key="Compiled with Java ">${java.version}</entry>
> </properties>
> {noformat} 
> Which results in a post-filtered splash.xml:
> {noformat} 
> <properties>
>     <entry key="title">ACES Viewer</entry>
>     <entry key="Version">0.7-SNAPSHOT</entry>
>     <entry key="Compiled with Java ">${java.version}</entry>
> </properties>
> {noformat} 
> The problem appears to be in the 'initializeFiltering()' method of the FileFormatter class.  The filter properties are initialized using:
> filterProperties = new Properties(System.getProperties());
> Changing this to:
> filterProperties = new Properties();
> filterProperties.putAll(System.getProperties());
> Seems to fix the problem.
> The Properties javadocs are a little vague on the constructor parameter:
> public Properties(Properties defaults)
>     Creates an empty property list with the specified defaults.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira