You are viewing a plain text version of this content. The canonical link for it is here.
Posted to general@incubator.apache.org by Benson Margulies <bi...@gmail.com> on 2012/12/03 21:54:28 UTC
"Obfuscating' 3rd party jars
Dear Wave,
I don't understand the remark in your report about the need to
'obfuscate' third party jar files. Could you please elaborate? Do you
have problems with dependencies with incompatible licenses, or
something else?
Thanks,
Benson
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: "Obfuscating' 3rd party jars
Posted by dsh <da...@gmail.com>.
If Emma "enacts" your bytecode like Cobertura does for instance, you may
consider not shipping such bytecode as well. Instead ship the one without
debug symbols and the one which hasn't been "enacted" to be consumed by
code coverage tools et al.
Cheers
Daniel
On Tue, Dec 4, 2012 at 12:36 PM, Benson Margulies <bi...@gmail.com>wrote:
> On Tue, Dec 4, 2012 at 12:35 AM, Michael MacFadden
> <mi...@gmail.com> wrote:
> > Benson,
> >
> > I agree. There was some progress in mavenizing the build. I suspect
> that
> > that solution will take some time. The build process is somewhat
> > complicated at the moment, if this is the long term solution, we may need
> > to do something simpler to start off with.
> >
> > In the case of Junit, we should probably be able to remove it from a
> > binary release. There is no reason to include it in my mind since it's
> > only used during the build. Not sure on emma. Regardless a temporary
> > work around would be to remove them and simply required the users to
> > download them. We could even provide a simple script to do that.
>
> Now you are thinking in the usual ASF terms. Use a build tool, or tell
> users to download.
>
> Emma is a code coverage tool, so it should just be like junit:
> certainly not in a runtime package, and, if not at least 'category b',
> 'download it yourself' in the source release.
>
>
> >
> > ~Michael
> >
> >
> >
> > On 12/3/12 3:45 PM, "Benson Margulies" <bi...@gmail.com> wrote:
> >
> >>On Mon, Dec 3, 2012 at 4:39 PM, Michael MacFadden
> >><mi...@gmail.com> wrote:
> >>> Benson,
> >>>
> >>> Yes, Angus had been working this issue for us and found a few third
> >>>party
> >>> Jars. Here is an extract from his email:
> >>>
> >>> ----------
> >>> There's a couple of things going on at once at the moment:
> >>> -i'm in contact with the libIDN author, who is happy to release the
> >>> software under the Apache license, which means we can keep using that
> >>>once
> >>> a new release comes out
> >>> -the other two libraries junit and emma both think the best option is
> to
> >>> obfuscate the code somehow like ant, if anyone has any experience in
> >>>doing
> >>> it speaking up would be greatly appreciated
> >>> -----------
> >>>
> >>>
> >>> Apparently, there is some precedent for obfuscating third party jars.
> >>>My
> >>> assumption is that something about the license views distributing Java
> >>> jars as being akin to a source distribution do to the ease of
> >>> decompilation.
> >>
> >>I cannot think of any reason why any Apache project should be
> >>concerned with obfuscation or decompilation. We are open source, and
> >>our dependencies are open source. Junit is a testing tool, so you
> >>should never need to redistribute it, just arrange to have it
> >>available for builds, and maven or ant/ivy will do that, and the same
> >>with emma, which is another development tool.
> >>
> >>There are many examples of this at other project. If it would be
> >>helpful, I could join the dev list to help with the discussion here.
> >>
> >>
> >>
> >>>
> >>> Angus,
> >>>
> >>> Can you she some light on this?
> >>>
> >>> ~Michael
> >>>
> >>> On 12/3/12 12:54 PM, "Benson Margulies" <bi...@gmail.com> wrote:
> >>>
> >>>>Dear Wave,
> >>>>
> >>>>I don't understand the remark in your report about the need to
> >>>>'obfuscate' third party jar files. Could you please elaborate? Do you
> >>>>have problems with dependencies with incompatible licenses, or
> >>>>something else?
> >>>>
> >>>>Thanks,
> >>>>Benson
> >>>>
> >>>>---------------------------------------------------------------------
> >>>>To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> >>>>For additional commands, e-mail: general-help@incubator.apache.org
> >>>>
> >>>
> >>>
> >>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> >>> For additional commands, e-mail: general-help@incubator.apache.org
> >>>
> >>
> >>---------------------------------------------------------------------
> >>To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> >>For additional commands, e-mail: general-help@incubator.apache.org
> >>
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> > For additional commands, e-mail: general-help@incubator.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>
Re: "Obfuscating' 3rd party jars
Posted by Benson Margulies <bi...@gmail.com>.
On Tue, Dec 4, 2012 at 12:35 AM, Michael MacFadden
<mi...@gmail.com> wrote:
> Benson,
>
> I agree. There was some progress in mavenizing the build. I suspect that
> that solution will take some time. The build process is somewhat
> complicated at the moment, if this is the long term solution, we may need
> to do something simpler to start off with.
>
> In the case of Junit, we should probably be able to remove it from a
> binary release. There is no reason to include it in my mind since it's
> only used during the build. Not sure on emma. Regardless a temporary
> work around would be to remove them and simply required the users to
> download them. We could even provide a simple script to do that.
Now you are thinking in the usual ASF terms. Use a build tool, or tell
users to download.
Emma is a code coverage tool, so it should just be like junit:
certainly not in a runtime package, and, if not at least 'category b',
'download it yourself' in the source release.
>
> ~Michael
>
>
>
> On 12/3/12 3:45 PM, "Benson Margulies" <bi...@gmail.com> wrote:
>
>>On Mon, Dec 3, 2012 at 4:39 PM, Michael MacFadden
>><mi...@gmail.com> wrote:
>>> Benson,
>>>
>>> Yes, Angus had been working this issue for us and found a few third
>>>party
>>> Jars. Here is an extract from his email:
>>>
>>> ----------
>>> There's a couple of things going on at once at the moment:
>>> -i'm in contact with the libIDN author, who is happy to release the
>>> software under the Apache license, which means we can keep using that
>>>once
>>> a new release comes out
>>> -the other two libraries junit and emma both think the best option is to
>>> obfuscate the code somehow like ant, if anyone has any experience in
>>>doing
>>> it speaking up would be greatly appreciated
>>> -----------
>>>
>>>
>>> Apparently, there is some precedent for obfuscating third party jars.
>>>My
>>> assumption is that something about the license views distributing Java
>>> jars as being akin to a source distribution do to the ease of
>>> decompilation.
>>
>>I cannot think of any reason why any Apache project should be
>>concerned with obfuscation or decompilation. We are open source, and
>>our dependencies are open source. Junit is a testing tool, so you
>>should never need to redistribute it, just arrange to have it
>>available for builds, and maven or ant/ivy will do that, and the same
>>with emma, which is another development tool.
>>
>>There are many examples of this at other project. If it would be
>>helpful, I could join the dev list to help with the discussion here.
>>
>>
>>
>>>
>>> Angus,
>>>
>>> Can you she some light on this?
>>>
>>> ~Michael
>>>
>>> On 12/3/12 12:54 PM, "Benson Margulies" <bi...@gmail.com> wrote:
>>>
>>>>Dear Wave,
>>>>
>>>>I don't understand the remark in your report about the need to
>>>>'obfuscate' third party jar files. Could you please elaborate? Do you
>>>>have problems with dependencies with incompatible licenses, or
>>>>something else?
>>>>
>>>>Thanks,
>>>>Benson
>>>>
>>>>---------------------------------------------------------------------
>>>>To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>>>>For additional commands, e-mail: general-help@incubator.apache.org
>>>>
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>>> For additional commands, e-mail: general-help@incubator.apache.org
>>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>>For additional commands, e-mail: general-help@incubator.apache.org
>>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: "Obfuscating' 3rd party jars
Posted by Branko Čibej <br...@apache.org>.
On 04.12.2012 06:35, Michael MacFadden wrote:
> Benson,
>
> I agree. There was some progress in mavenizing the build. I suspect that
> that solution will take some time. The build process is somewhat
> complicated at the moment, if this is the long term solution, we may need
> to do something simpler to start off with.
The "something simpler" is called an INSTALL(.txt) file, in which you
write that the project depends on Junit and emma, which can be
downloaded from so-and-so and placed over-there in the source tree.
> In the case of Junit, we should probably be able to remove it from a
> binary release. There is no reason to include it in my mind since it's
> only used during the build. Not sure on emma.
I notice that Junit and emma are both category-B per
http://www.apache.org/legal/resolved.html
so you can use them (given the restrictions in that resolution), but if
you're worried about obfuscation then do not include them in your
release tarball.
> Regardless a temporary
> work around would be to remove them and simply required the users to
> download them. We could even provide a simple script to do that.
Or that, yes.
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: "Obfuscating' 3rd party jars
Posted by Paulo Pires <pj...@ubiwhere.com>.
On 04/12/12 05:35, Michael MacFadden wrote:
> Benson,
>
> I agree. There was some progress in mavenizing the build. I suspect that
> that solution will take some time.
For now it's working, though more recent commits are not merged, but
without community input, it's hard to keep up, though.
> The build process is somewhat
> complicated at the moment, if this is the long term solution, we may need
> to do something simpler to start off with.
>
> In the case of Junit, we should probably be able to remove it from a
> binary release. There is no reason to include it in my mind since it's
> only used during the build. Not sure on emma. Regardless a temporary
> work around would be to remove them and simply required the users to
> download them. We could even provide a simple script to do that.
Maven or something similar are mostly known because they can handle the
burden of downloading dependencies based on their scope.
>
> ~Michael
>
>
>
> On 12/3/12 3:45 PM, "Benson Margulies" <bi...@gmail.com> wrote:
>
>> On Mon, Dec 3, 2012 at 4:39 PM, Michael MacFadden
>> <mi...@gmail.com> wrote:
>>> Benson,
>>>
>>> Yes, Angus had been working this issue for us and found a few third
>>> party
>>> Jars. Here is an extract from his email:
>>>
>>> ----------
>>> There's a couple of things going on at once at the moment:
>>> -i'm in contact with the libIDN author, who is happy to release the
>>> software under the Apache license, which means we can keep using that
>>> once
>>> a new release comes out
>>> -the other two libraries junit and emma both think the best option is to
>>> obfuscate the code somehow like ant, if anyone has any experience in
>>> doing
>>> it speaking up would be greatly appreciated
>>> -----------
>>>
>>>
>>> Apparently, there is some precedent for obfuscating third party jars.
>>> My
>>> assumption is that something about the license views distributing Java
>>> jars as being akin to a source distribution do to the ease of
>>> decompilation.
>> I cannot think of any reason why any Apache project should be
>> concerned with obfuscation or decompilation. We are open source, and
>> our dependencies are open source. Junit is a testing tool, so you
>> should never need to redistribute it, just arrange to have it
>> available for builds, and maven or ant/ivy will do that, and the same
>> with emma, which is another development tool.
>>
>> There are many examples of this at other project. If it would be
>> helpful, I could join the dev list to help with the discussion here.
>>
>>
>>
>>> Angus,
>>>
>>> Can you she some light on this?
>>>
>>> ~Michael
>>>
>>> On 12/3/12 12:54 PM, "Benson Margulies" <bi...@gmail.com> wrote:
>>>
>>>> Dear Wave,
>>>>
>>>> I don't understand the remark in your report about the need to
>>>> 'obfuscate' third party jar files. Could you please elaborate? Do you
>>>> have problems with dependencies with incompatible licenses, or
>>>> something else?
>>>>
>>>> Thanks,
>>>> Benson
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>>>> For additional commands, e-mail: general-help@incubator.apache.org
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>>> For additional commands, e-mail: general-help@incubator.apache.org
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>> For additional commands, e-mail: general-help@incubator.apache.org
>>
>
--
Paulo Pires
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: "Obfuscating' 3rd party jars
Posted by Michael MacFadden <mi...@gmail.com>.
Benson,
I agree. There was some progress in mavenizing the build. I suspect that
that solution will take some time. The build process is somewhat
complicated at the moment, if this is the long term solution, we may need
to do something simpler to start off with.
In the case of Junit, we should probably be able to remove it from a
binary release. There is no reason to include it in my mind since it's
only used during the build. Not sure on emma. Regardless a temporary
work around would be to remove them and simply required the users to
download them. We could even provide a simple script to do that.
~Michael
On 12/3/12 3:45 PM, "Benson Margulies" <bi...@gmail.com> wrote:
>On Mon, Dec 3, 2012 at 4:39 PM, Michael MacFadden
><mi...@gmail.com> wrote:
>> Benson,
>>
>> Yes, Angus had been working this issue for us and found a few third
>>party
>> Jars. Here is an extract from his email:
>>
>> ----------
>> There's a couple of things going on at once at the moment:
>> -i'm in contact with the libIDN author, who is happy to release the
>> software under the Apache license, which means we can keep using that
>>once
>> a new release comes out
>> -the other two libraries junit and emma both think the best option is to
>> obfuscate the code somehow like ant, if anyone has any experience in
>>doing
>> it speaking up would be greatly appreciated
>> -----------
>>
>>
>> Apparently, there is some precedent for obfuscating third party jars.
>>My
>> assumption is that something about the license views distributing Java
>> jars as being akin to a source distribution do to the ease of
>> decompilation.
>
>I cannot think of any reason why any Apache project should be
>concerned with obfuscation or decompilation. We are open source, and
>our dependencies are open source. Junit is a testing tool, so you
>should never need to redistribute it, just arrange to have it
>available for builds, and maven or ant/ivy will do that, and the same
>with emma, which is another development tool.
>
>There are many examples of this at other project. If it would be
>helpful, I could join the dev list to help with the discussion here.
>
>
>
>>
>> Angus,
>>
>> Can you she some light on this?
>>
>> ~Michael
>>
>> On 12/3/12 12:54 PM, "Benson Margulies" <bi...@gmail.com> wrote:
>>
>>>Dear Wave,
>>>
>>>I don't understand the remark in your report about the need to
>>>'obfuscate' third party jar files. Could you please elaborate? Do you
>>>have problems with dependencies with incompatible licenses, or
>>>something else?
>>>
>>>Thanks,
>>>Benson
>>>
>>>---------------------------------------------------------------------
>>>To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>>>For additional commands, e-mail: general-help@incubator.apache.org
>>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>> For additional commands, e-mail: general-help@incubator.apache.org
>>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>For additional commands, e-mail: general-help@incubator.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: "Obfuscating' 3rd party jars
Posted by Benson Margulies <bi...@gmail.com>.
On Mon, Dec 3, 2012 at 4:39 PM, Michael MacFadden
<mi...@gmail.com> wrote:
> Benson,
>
> Yes, Angus had been working this issue for us and found a few third party
> Jars. Here is an extract from his email:
>
> ----------
> There's a couple of things going on at once at the moment:
> -i'm in contact with the libIDN author, who is happy to release the
> software under the Apache license, which means we can keep using that once
> a new release comes out
> -the other two libraries junit and emma both think the best option is to
> obfuscate the code somehow like ant, if anyone has any experience in doing
> it speaking up would be greatly appreciated
> -----------
>
>
> Apparently, there is some precedent for obfuscating third party jars. My
> assumption is that something about the license views distributing Java
> jars as being akin to a source distribution do to the ease of
> decompilation.
I cannot think of any reason why any Apache project should be
concerned with obfuscation or decompilation. We are open source, and
our dependencies are open source. Junit is a testing tool, so you
should never need to redistribute it, just arrange to have it
available for builds, and maven or ant/ivy will do that, and the same
with emma, which is another development tool.
There are many examples of this at other project. If it would be
helpful, I could join the dev list to help with the discussion here.
>
> Angus,
>
> Can you she some light on this?
>
> ~Michael
>
> On 12/3/12 12:54 PM, "Benson Margulies" <bi...@gmail.com> wrote:
>
>>Dear Wave,
>>
>>I don't understand the remark in your report about the need to
>>'obfuscate' third party jar files. Could you please elaborate? Do you
>>have problems with dependencies with incompatible licenses, or
>>something else?
>>
>>Thanks,
>>Benson
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>>For additional commands, e-mail: general-help@incubator.apache.org
>>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: "Obfuscating' 3rd party jars
Posted by Michael MacFadden <mi...@gmail.com>.
Benson,
Yes, Angus had been working this issue for us and found a few third party
Jars. Here is an extract from his email:
----------
There's a couple of things going on at once at the moment:
-i'm in contact with the libIDN author, who is happy to release the
software under the Apache license, which means we can keep using that once
a new release comes out
-the other two libraries junit and emma both think the best option is to
obfuscate the code somehow like ant, if anyone has any experience in doing
it speaking up would be greatly appreciated
-----------
Apparently, there is some precedent for obfuscating third party jars. My
assumption is that something about the license views distributing Java
jars as being akin to a source distribution do to the ease of
decompilation.
Angus,
Can you she some light on this?
~Michael
On 12/3/12 12:54 PM, "Benson Margulies" <bi...@gmail.com> wrote:
>Dear Wave,
>
>I don't understand the remark in your report about the need to
>'obfuscate' third party jar files. Could you please elaborate? Do you
>have problems with dependencies with incompatible licenses, or
>something else?
>
>Thanks,
>Benson
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>For additional commands, e-mail: general-help@incubator.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org