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 <bimargul...@gmail.com>wrote: > 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 > >
