+1 Sorry for all the confusion guys! Thanks Angus Turner [email protected]
On Wed, Dec 5, 2012 at 6:35 AM, Michael MacFadden < [email protected]> wrote: > 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 > > >
