incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Benson Margulies <>
Subject Re: "Obfuscating' 3rd party jars
Date Tue, 04 Dec 2012 11:36:23 GMT
On Tue, Dec 4, 2012 at 12:35 AM, 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.
> 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" <> wrote:
>>On Mon, Dec 3, 2012 at 4:39 PM, Michael MacFadden
>><> wrote:
>>> Benson,
>>> Yes, Angus had been working this issue for us and found a few third
>>> 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
>>> 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
>>> it speaking up would be greatly appreciated
>>> -----------
>>> Apparently, there is some precedent for obfuscating third party jars.
>>> 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" <> 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?
>>>>To unsubscribe, e-mail:
>>>>For additional commands, e-mail:
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail:
>>> For additional commands, e-mail:
>>To unsubscribe, e-mail:
>>For additional commands, e-mail:
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message