On Thu, Mar 4, 2010 at 2:27 AM, Simon Laws <[email protected]> wrote: > The feels like the sort of thing we need. A couple of points. > > - we need the project(s) you used to package the resources as we will > have to republish the artifacts relatively regularly (maybe they > should be in a more generally accessible area than your p.a.o site)
So far I just do it manually, so zip up all the contributions created in otests\sca-assembly, otests\sca-java-caa, otests\sca-java-ci, otests\sca-policy, and the test runner jar is really just the jar created in the Test_Client module of those projects. Those are pretty stable now so don't often change and if they do it would be good if we have to manually update to the newer release so we don't have breaks like has just happened with the RuntimeBridge changes. I think the p.a.o is ok for now but if anyone feels strongly could move it to the svn repo, i didn't want to put it in our svn repo till its stable but if we were to include this in a Tuscany released and OASIS weren't publishing themselves I guess our svn repo is where it would have to go. > - we should talk with the OASIS folks to see what they have in mind > re. packaging. We can probably help them along the way and get them > publishing these artifacts sooner rather than later Yes absolutely, we need to help and encourage them to publish proper snapshot and released artifacts, and I'll be talking to Mike about that. > > Speed will be a problem with Assembly/CAA/CII/Policy hooked up. An > extra 16 mins on the build. Then we'll have the otests starting to > come in from the extensions. > > I think we need to get back to this idea about having profiles. I'e a > core profile that does include these compliance tests. Never got round > to doing anything about it as other improvements go my build down to > the 15 minute mark. Creeping back up again now though even without the > otests. > I don't disagree with that and adding 16 minutes to the build may help it happen. I don't think profiles are a pre-req to including these in the trunk build though, we need to get these run in the full build ASAP to stop the regressions that keep happening. We may be able to remove some of the existing tests we have though that are duplicating whats in the compliance tests and that may reduce the time a bit so at some point we could look at doing that, eg when theres JMS binding conformance test probably most of the existing JMS itests could go. ...ant
