I think this is probably the simples path forward. +1
On 12/4/12 11:33 AM, "Upayavira" <[email protected]> wrote: >I think this has hit on something I should have spotted a while back. > >Apache releases source code, it doesn't release compiled code. >Therefore, it doesn't include dependencies. > >So creating a source release should be straight-forward. > >We may choose to produce a convenience binary, but that wouldn't include >junit or emma, as they aren't needed to run the app, so that issue goes >away. > >Maybe we might want Maven or some such to go get junit etc, but as >others have suggested, a bash script and a bat file would suffice if >described in an INSTALL.txt in the source release. > >We could produce a release like this, then maybe folks'll come along and >tell you how crap it is. Great, tell them to improve it! > >Reasonable? > >Upayavira > >On Tue, Dec 4, 2012, at 07:05 PM, Christian Grobmeier wrote: >> On Tue, Dec 4, 2012 at 4:37 PM, Michael MacFadden >> <[email protected]> wrote: >> > 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. >> >> You are distributing the sources of Junit and others? Why? >> I think it would be ok to just distribute Wave sources. Others may use >> maven to build the software, which finally will download the necessary >> things to build >> >> Cheers >> Christian >> >> > ~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] >> >>> > >> >>> >> > >> > >> >> >> >> -- >> http://www.grobmeier.de >> https://www.timeandbill.de
