On Tue, Dec 4, 2012 at 12:35 AM, Michael MacFadden <michael.macfad...@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" <bimargul...@gmail.com> wrote: > >>On Mon, Dec 3, 2012 at 4:39 PM, Michael MacFadden >><michael.macfad...@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" <bimargul...@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-unsubscr...@incubator.apache.org >>>>For additional commands, e-mail: general-h...@incubator.apache.org >>>> >>> >>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org >>> For additional commands, e-mail: general-h...@incubator.apache.org >>> >> >>--------------------------------------------------------------------- >>To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org >>For additional commands, e-mail: general-h...@incubator.apache.org >> > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
