You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@maven.apache.org by Steinar Bang <sb...@dod.no> on 2007/03/13 21:44:41 UTC
Activating profile in child POM
I've been reading
http://maven.apache.org/guides/introduction/introduction-to-profiles.html
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: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Activating profile in child POM
Posted by Steinar Bang <sb...@dod.no>.
>>>>> "Brian E. Fox" <br...@reply.infinity.nu>:
> Yes. I looked into the plexus-archiver component and it doesn't
> appear to support symlinks. I filed a request and then linked the
> MDEP one to it. Your best bet at this point is to create a patch for
> the archiver support and then we can add it to maven-dependency once
> that is applied and released. I don't really have any other
> suggestions right now.
What I'm doing right now, is to just copy the tgz in the correct spot,
and let the native tar untar it before running. That's in the script
that starts the Java program (and sets LD_LIBRARY_PATH before firing
up the VM).
But I'm not sure how I'll handle unpacking for surefire
tests... suggestions welcome.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
RE: Re: Activating profile in child POM
Posted by "Brian E. Fox" <br...@reply.infinity.nu>.
>>(btw you've probably guessed that this is a workaround for
>>dependency:unpack not preserving symlinks...? However, I still would
>>like to see that JIRA feature request... removes kludges and
>>workarounds...;-) )
Yes. I looked into the plexus-archiver component and it doesn't appear
to support symlinks. I filed a request and then linked the MDEP one to
it. Your best bet at this point is to create a patch for the archiver
support and then we can add it to maven-dependency once that is applied
and released. I don't really have any other suggestions right now.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Activating profile in child POM
Posted by Steinar Bang <sb...@dod.no>.
>>>>> "Brian E. Fox" <br...@reply.infinity.nu>:
> 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
> ou change it right?
Yup. That's what I figured.
> It should work using -D or even -P to specify the profile.
It did.
However, I ended up activating profiles based on os.family for chosing
between dependency:copy or dependency:unpack, and that works fine.
(btw you've probably guessed that this is a workaround for
dependency:unpack not preserving symlinks...? However, I still would
like to see that JIRA feature request... removes kludges and
workarounds...;-) )
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
RE: Activating profile in child POM
Posted by "Brian E. Fox" <br...@reply.infinity.nu>.
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:news@sea.gmane.org] On Behalf Of Steinar Bang
Sent: Tuesday, March 13, 2007 4:45 PM
To: users@maven.apache.org
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: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org