Stephane Nicoll wrote:
Hi,
On 1/13/07, Kenney Westerhof <[EMAIL PROTECTED]> wrote:
The last solution i can think of is to specify
<classifier>${obfuscate}</classifier>
on all deps (in project A and B ) that can have an obfuscated attachment.
You could use a profile or -Dobfuscate=obfuscated. You just have to
make sure
that not specifying to obfuscate will set the obfuscate property to
the empty string,
and that maven can handle empty classifier strings (like it does null
classifiers).
Yeah it's running fine but I am facing a very annoying problem and I'd
like to know if there is a workaround.
Here is a snippet used to handle the obfuscated thingy:
<dependency>
<groupId>com.foo</groupId>
<artifactId>bar</artifactId>
<version>5.8.2-SNAPSHOT</version>
<classifier>${obfuscated}</classifier>
</dependency>
<properties>
<obfuscated></obfuscated>
</properties>
<profiles>
<profile>
<id>obfuscation</id>
<activation>
<property>
<name>obfuscated</name>
<value>obfuscated</value>
</property>
</activation>
<properties>
<obfuscated>obfuscated</obfuscated>
</properties>
</profile>
</profiles>
This is running fine if I do mvn -Dobfuscated=obfuscated. However,
activating the profile, that is mvn -Pobfuscated does not have the
expected behavior. I assume that the properties are resolved "too
late" to alter the dependencies. Is there a workaround to this?
I think that's a bug - the properties aren't overwritten.
Try this:
add another profile with <activeByDefault>true</activeByDefault>,
and move the <properties><obfuscated/></properties> inside that profile.
If you don't activate the profile, that default profile should be enabled.
If you activate the obfuscation profile, then the default profile
shouldn't be activated.
BTW, will maven resolve the property (${obfuscated}) when the POM is
released?
Sure it will resolve it. What you could do is name the profile different,
there's a special profile for releases (maybe it's called 'release', not sure),
so it'll be automatically enabled when releasing (that's what you're after,
right?)
If so, this solution is kinda useless right?
I'm not following...
-- Kenney
Regards,
Stéphane
HTH,
-- Kenney
Stephane Nicoll wrote:
> Hi,
>
> I already discussed this with brett and Dan and I would like to see if
> anyone here has more insight about how to handle obfuscated jars.
>
> The basic use case I have is to be able to specify whether I want the
> standard jars or the obfuscated jars for a particular project.
> Obfuscated jars are handled as attached artifacts w/ the "obfuscated"
> classifier.
>
> If a particular project does not rely on any other lib that needs to
> be obfuscated, everything is ok, we just depend on it with the
> obfuscated classifier. The harder part is when a particular project
> depends on other components that need to be obfuscated. In dev phase
> it might be easier to use non obfuscated jars (as stacktraces are a
> bit complex to read when something goes wrong :)
>
> Let's say we have 3 components A, B, C. A depends on B and B depends
> on C. I would like to find a way to specify "bring me everything
> obfuscated" for A (something like intelligent classifier).
>
> Is there anything we can do about this? The other solution is to have
> a separate project for each component with the obfuscated dep, which
> sounds not good at all.
>
> Thanks,
> Stéphane
>
> ---------------------------------------------------------------------
> 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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
