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]

Reply via email to