On Fri, Nov 20, 2009 at 10:10 AM, Simon Laws <[email protected]> wrote: >> >> A comment on that is that if there are different configurations for >> releases and regular builds then theres a good chance they will get >> out of sync and we dont notice the difference until a release is being >> reviewed so we lose a lot of the point of testing the distribution. >> Thats exactly what used to happen and its one of the reasons we're now >> doing it the way it is. It does seem a waste to be building the src >> distro and then not testing it though, so if there is a way of only >> doing the binary one and using the same bin.xml file that would be >> good. > > I think there is a difference between three different scenarios we > have mentioned. > > 1/ no automatic testing of distribution and samples. - the very > painful 1.x scenario > 2/ automatic testing of the distribution and samples including > building all the archive formats - the current 2.x scenario > 3/ automatic testing of the distribution and samples including > building building only the zip archive format that is actually tests - > my proposal. > > I believe there is a huge value of 3 over 1 > I believe there is no value of 2 over 3 (other than, in 3 we > demonstrate that the tools are able to build tar.gz, -src.tar.gz, > -srz.zip. Big deal as we don't actually test those archives) >
Yep I agree with you (if that wasnt clear from my previous reply). I was just adding that it would be good to try to find a way that uses the same assembly plugin bin.xml file for both. >> >> A question is should we bother building the distribution as part of >> the build? The original reason for that was so all the samples could >> be tested from the distribution, but samples being added now are not >> getting associated distribution itests so maybe we shouldnt bother. >> >> ...ant >> > > I think we should fix the fact that the samples aren't included. IMHO > any time we loose during the build (assuming we can get it under > control) would be less that the time we take fixing the build up for > each release. Originally when we set off down this path we have the > assembly plugin configured to just generate the distro in directory > form without building any archives. I'd be happy with that. If we find > a problem related to building the archive and then unpacking it again > it is unlikely to need a Tuscany fix. > And I agree with all that too. The itest\distribution\bin-distro-unzip unzips the zip anyway so it would be simpler to just replace that itest with <format>dir</format>. Where it starts to go wrong though is if there is separate assembly plugin bin.xml files, one for just the dir and another for dir, zip, tar. A way around that would be changing the <componentDescriptors> element to have a single generic componentDescriptor that both bin.xmls could share. ...ant
