Re: handling obfuscated jars
I think that's a bug - the properties aren't overwritten.
Mmm all right.
Try this:
add another profile with true,
and move the 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.
I don't follow but I'll try monday and I'll let you know.
> 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...
What I was afraid is that the released pom did not contain the
${obfuscated} string but the resolved classifier (that is the empty
string or the obfuscated string) but I think it will work properly.
I'll try your suggestion and I'll let you know. Regarding the
properties overwriting, do you want me to open an issue in Jira?
Thanks,
Stéphane
-- 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]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: handling obfuscated jars
Stephane Nicoll wrote:
Hi,
On 1/13/07, Kenney Westerhof <[EMAIL PROTECTED]> wrote:
The last solution i can think of is to specify
${obfuscate}
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:
com.foo
bar
5.8.2-SNAPSHOT
${obfuscated}
obfuscation
obfuscated
obfuscated
obfuscated
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 true,
and move the 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]
Re: handling obfuscated jars
Hi,
On 1/13/07, Kenney Westerhof <[EMAIL PROTECTED]> wrote:
The last solution i can think of is to specify
${obfuscate}
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:
com.foo
bar
5.8.2-SNAPSHOT
${obfuscated}
obfuscation
obfuscated
obfuscated
obfuscated
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?
BTW, will maven resolve the property (${obfuscated}) when the POM is
released? If so, this solution is kinda useless right?
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]
Re: handling obfuscated jars
On 1/13/07, Kenney Westerhof <[EMAIL PROTECTED]> wrote:
Obfuscated jars are usually only needed for binary distributions (assemblies).
A simple solution would be to have a distribution assembly project that directly
depends on all obfuscated jars.
Yeah that's one idea and I actually like it. The only problem is that
one of my use case is to use some components in a training session and
I need to be able to say at some point "Use components A and get it
obfuscated as well as its dependent components". Since the training
sessions cover almost everything, It would be better to be able to
handle that on a per-component basis.
The problem also I have with this is that if I get project A with the
obfuscated classifier (and B and C directly like you said) I'll still
get the transitive deps on A and B which are not obfuscated according
to the POM. And I can't disable transitive deps since it needs third
party libs
Second solution is to obfuscate the jars in the assembly. This has the advantage
that the obfuscator can obfuscate more since less public api's have to be
exposed in order to have inter-jar operability.
Same as above.
The last solution i can think of is to specify
${obfuscate}
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).
I thought about this solution very quickly and I was wondering if it
was possible. Mmmm, let's have a try then. I had a hard time with
profiles so far (the help:active-profiles might be broken by the way,
I'll try to confirm that).
HTH,
Of course it does. Thanks a lot for your input.
Stéphane
-- 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]
Re: handling obfuscated jars
Hi,
I don't know what your usecases are, but here are some ideas:
Obfuscated jars are usually only needed for binary distributions (assemblies).
A simple solution would be to have a distribution assembly project that directly
depends on all obfuscated jars.
Second solution is to obfuscate the jars in the assembly. This has the advantage
that the obfuscator can obfuscate more since less public api's have to be
exposed in order to have inter-jar operability.
The last solution i can think of is to specify
${obfuscate}
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).
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]
