Jeremy, thanks for your reply. A key time when this has become an issue for me is when applying patches. My general process has been to ensure I have a complete clean svn extraction, build it to see if there are any current issues in the trunk, inspect and apply the patch and build it again. If there are deltas in the error sets (hopefully the initial build's error set was empty) then there's an issue with the patch. This has meant in the past often even small patches still take an hour or so to apply. Now that the trunk has significantly less chance of being stable this has become unworkable.
BTW, I saw that you posted a new snapshot of SDO a couple of days ago. I wasn't sure how best to choose when to post a new snapshot or how to communicate an imminent update. Is there a best practice for choosing when and how to deploy new snapshots? Best Regards, Kelvin. On 30/01/07, Jeremy Boynes <[EMAIL PROTECTED]> wrote:
Rick just about covers it. The key thing is that downstream dependencies should be depending on SDO's published APIs and to avoid disruption to users you really don't want to be making incompatible changes to those APIs. Ideally there would be tests that exercised those APIs and you could rely on those to catch changes that break things.
I don't think that my concern was with instability with the SDO API, but rather the implementation. It was the execution of the dependent project's test cases that were adding information. The 2.1 API has been in place for a while and unchanging, but some of the features not implemented. We are expanding the test set within the build, and of course the community test suite is developing well, but neither are yet at a stage where they give me full confidence changes to the implementation don't cause adverse effects. Relying on other modules in Tuscany to do this is a bad idea as they
are likely only to exercise part of the SDO APIs. Even if they do break and you fix them, what about other code outside Tuscany?
Indeed, that's why I said that running a full build gave me a "warm feeling". Running the tests alone is clearly a prereq, but there was additional benefit in running the full build. Agreed there's lots of code running outside the Tuscany build, but its not low hanging fruit for increasing my state of confidence that a change has not introduced a bug. Regarding the tools, there was talk in the past about moving them to
SDO as they actually don't have anything to do with SCA. Doing that would mean they could easily be tested in conjunction with any SDO changes and released with SDO. Should we go ahead and do that? -- Jeremy On Jan 30, 2007, at 5:39 AM, Rick wrote: > Kevin, > Be forewarned, I'm slightly fuzzy about how some things have been > separated out in the SCA build, but I'll try to answer. First of - > Pall from java root seems to be bad way to go all around. The > split in between the core(kernel) SCA and other extensions and > samples. Nothing in the kernel I'm pretty sure has any SDO > dependencies so you really don't need to test against the very HEAD > of those parts. The core is in two directories under java/sca > runtime and kernel. > These are published and like I said you don't need to test SDO > against them. > > For non core parts the are what is left in java\sca extensions, > plugins, services, and test. The theory is they should be using > the published (stable) kernel. These do have some SDO > dependencies, like the SDO databinding, and the maven tools that > help generate SDOs for wsdl2java. There is also samples that is > still in sampleapps which have SDO dependencies. As of right now I > think you have to manually issue a mvn build for these in each of > their respective directories. > > > kelvin goodson wrote: >> I've probably missed something in the mailing list here. Since >> profiles >> appeared in the top level pom the way I have been ensuring a >> change in SDO >> doesn't break modules that have dependencies on SDO is to run a >> mvn -Pall. >> I've done a bit of mailing list searching to find posts related to >> how these >> dependencies now work, but I haven't found anything definitive. I >> know we >> now have deployed snapshot versions of SDO and other modules. >> Whilst the >> set of SDO tests is building up, I don't yet have confidence that >> they will >> catch potential build breaks, so a full build of the trunk gave >> me a warm >> feeling that I wasn't going to break anything, but clearly this >> doesn't >> work any more. If I only run the SDO build and rely on the fact that >> upstream modules are insulated by depending on the snapshot then >> I'm just >> storing up troubles for the next time we post an SDO snapshot. >> Can someone >> help me to understand how I can change my build process to retain >> this level >> of confidence please? >> Regards, Kelvin. >> On 29/01/07, Jeremy Boynes <[EMAIL PROTECTED]> wrote: >>> >>> On Jan 29, 2007, at 6:14 AM, Rick wrote: >>> >>> > Just want to make sure I understand the consequences of compiling >>> > from the java root with -Pall. >>> >>> As I understand it, there is no guarantee that that will work. If >>> you >>> do that you are trying to build using current SVN head from >>> independent modules - not only within SCA but also SDO and DAS. >>> >>> > As I understand it this shouldn't be an issue and all should >>> > compile and test. The only consequence now is that the projects >>> > under sca/kernel will not be used by the other projects for the >>> > build and mvn unit test. >>> >>> This is true at a module level but in a reactor build if two >>> versions >>> of a module exist then mvn will resolve to the latest one. Because >>> you include everything with -Pall, everything will resolve to the >>> latest unstable trunk and downstream modules are likely to fail. >>> >>> > >>> > If working on the kernel I need to really do nothing different for >>> > eclipse, except that it probable makes sense to have a separate >>> > workspace for the kernel if I'm also working on some of the other >>> > Tuscany parts. >>> > >>> > Working on components other than the kernel, I need to import into >>> > Eclipse only those projects not under sca/kernel and to debug the >>> > kernel code import the code under branches\pre-spec-changes. >>> >>> I have no idea what you need to do in Eclipse, but in general you >>> should be referencing the snapshot binaries of SDO, DAS, SCA Kernel >>> and such as defined by the dependency version, associating the >>> appropriate source code with those binaries. >>> >>> -- >>> Jeremy >>> >>> >>> -------------------------------------------------------------------- >>> - >>> 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]
