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.
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?
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]
