I don't think you can activate based on a property set in a parent. Normally this wouldn't make sense because it's always the same until you change it right? It should work using -D or even -P to specify the profile.
-----Original Message----- From: news [mailto:[EMAIL PROTECTED] On Behalf Of Steinar Bang Sent: Tuesday, March 13, 2007 4:45 PM To: [email protected] Subject: Activating profile in child POM I've been reading http://maven.apache.org/guides/introduction/introduction-to-profiles.htm l and trying to understand how profiles should be used What I'm trying to do, is: 1. download, and install the appropriate shared lib/DLL for different platforms, for use with JNI wrappers 2. use dependency:copy for unixoid platforms, and dependency:unpack for Win32 (the reason for using dependency:copy is that dependency:unpack, is that the latter currently doesn't support symlinks, and the symlinks between different versions of a shared lib are lost. The reason for using dependency:unpack for win32, is that as a result of the build system, Win32 DLLs will be tgz'ed instead of zipped, and tar and gzip won't be available on the machines being unpacked on, and besides unpacking would be hard to automate with what's available on the Win32 machines running the goal What I've succeeded in, so far, is to set properties depending on the os, in <profile> elements, in a <profiles> element in the top level POM, and have a dependenc:unpack goal in a <plugins> <execution> in a child pom, pick up these properties. What I so far haven't succeded in, is to set a property in the top pom, and use that property to activate a dependency:copy goal in the child POM. Is this the correct way to do actication in the child POM? I guess I could use the os.family trigging directly in the child POM, but I was aiming for single-point-of-change for the activation criteria for that behaviour. Here's what I've done in the top pom ... <profiles> <profile> <!-- This profile is used to differentiate between unixens, which has to use native tar, to preserve symlinks, when unpacking shared libs used for JNI, and windows systems where it's possible to use dependency:unpack to unpack the DLLs used for JNI. What's used from this profile is the <id>, in <plugin> activations --> <id>unix-generic</id> <activation> <os> <family>unix</family> </os> </activation> <properties> <unix-generic-activate>true</unix-generic-activate> </properties> </profile> ... </profiles> ... Here's what I've done in the child POM: ... <profiles> <profile> <activation> <property> <name>unix-generic-activate</name> </property> </activation> <id>unix-generic-copy-mylib</id> <build> <plugins> <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-dependency-plugin</artifactId> <executions> <execution> <id>unpackmylib</id> <phase>install</phase> <goals> <goal>copy</goal> </goals> <configuration> <artifactItems> <artifactItem> <groupId>com.somecompany.mylib</groupId> <artifactId>mylib-${jni.os.name}-${jni.os.arch}</artifactId> <version>0.0</version> <type>tgz</type> </artifactItem> </artifactItems> <outputDirectory>${target.platform.dir}/lib</outputDirectory> </configuration> </execution> </executions> </plugin> </plugins> </build> </profile> </profiles> ... When I run "mvn help:active-profiles" from the top POM or from this POM directly, the profile doesn't show as activated. When I run "mvn help:active-profiles -Dunix-generic-activate" in either place, it shows up as activated. So I guess perhaps the unix-generic-activate property isn't set when the child pom's profile activation is done...? I'm guessing the property values are seen, because jni.os.name and jni.os.arch used in <artifactId> are set in a profile activated in the top pom. And they seem to work if I run with -Dunix-generic-activate. So what's the proper approach? Put the unix-generic profile into a profiles.xml file in the top level directory (and having essential build information outside of the POM, which appearently isn't recommended)? Or don't attempt single-point-of-change for this, and just use os.family activation? Thanx! - Steinar --------------------------------------------------------------------- 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]
