We already have ant script that creates jar file that can be run, and IMO this jar does not include junit and emma. If release will include only this jar - I guess we are good as is.
On Tue, Dec 4, 2012 at 1:36 PM, Benson Margulies <[email protected]>wrote: > On Tue, Dec 4, 2012 at 12:35 AM, Michael MacFadden > <[email protected]> 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" <[email protected]> wrote: > > > >>On Mon, Dec 3, 2012 at 4:39 PM, Michael MacFadden > >><[email protected]> 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" <[email protected]> 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: [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] > > >
