Yuri, That is probably correct, however we still need to take care of the source distribution. If these are Category B artifacts I think we are ok for the source release as well. I will research, and report back.
~Michael On 12/4/12 4:33 AM, "Yuri Z" <[email protected]> wrote: >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] >> > >>
