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
