I like the idea of providing a simple script that downloads and installs the dependancies. Surely this can then be run during the ant build? Thanks Angus Turner [email protected]
On Tue, Dec 4, 2012 at 5:34 PM, Yuri Z <[email protected]> wrote: > Emma is only used with junit to generate code coverage reports, so I guess > we don't need it for binary release as well. > > > On Tue, Dec 4, 2012 at 7: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. > > > > ~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] > > > > > > > > > >
