I would prefer to keep CTS as a top level in tuscany if possible. One of the goals was to avoid implying that the cts was endorsing tuscany's implementation so moving into the main tuscany space might confuse people... also I guess if it were to move to testing, it might confuse people more 'cos isn't testing used by SCA (as opposed to SDO) ?
Having said this, we also should stop CTS from being built/run automatically when building tuscany (if this is possibl) since there will be (and as see with the current build) when CTS identifies issues/difference with Tuscany's SDO - ie a load of test cases fail or error becuase tuscany isn't behaving how CTS thinks SDO impliementations should... as is the case at the moment... any advice on how to deal with this appreciated.... currently a mvn of sdo2.1-tuscany executes the tests against tuscany... perhaps the simpliest fix would be just to stop this from happening by default... On 02/02/07, Meeraj Kunnumpurath <[EMAIL PROTECTED]> wrote:
Ant, Discovery is used for the federated assembly stuff. The abstractions are defined in SPI. The JXTA and bonjour implementations used to be under services, which I moved to runtime/services, in line with moving the core services like maven from services to runtime/services. They don't get loaded in the way other extensions like AXIS get loaded on demand. Rather, the discovery service is eagerly auto-wired into other core services like assembly service and federated deployer. Thanks Meeraj -----Original Message----- From: ant elder [mailto:[EMAIL PROTECTED] Sent: Friday, February 02, 2007 11:41 AM To: [email protected] Subject: Re: Moving modules around in trunk I haven't been paying really close attention to whats been going on with the discovery stuff so could you explain that a bit more? I'm not suggesting keeping it in services is wrong I'd just like to understand why this is more a core thing than say a WS extension? I guess i'd assumed the discovery SPIs and any helpers etc would be in the kernel and actual impls like JXTA would be an extension. ...ant On 2/2/07, Meeraj Kunnumpurath <[EMAIL PROTECTED]> wrote: > > Hi, > > The JPA stuff vcan definitely move to extensions, I can move it > tomorrow. The JXTA stuff is core runtime service, though, the actual > abstraction is in SPI. I am not sure whether it should stay in > runtime/services or move to extensions. My first inkling would be to > leave it in runtime/services. > > Ta > Meeraj > > -----Original Message----- > From: Jim Marino [mailto:[EMAIL PROTECTED] > Sent: Friday, February 02, 2007 9:06 AM > To: [email protected] > Subject: Re: Moving modules around in trunk > > > On Feb 2, 2007, at 12:49 AM, ant elder wrote: > > > OK I'm going to start doing all these things, I'm away for a week > > after today so it wont all happen immediately...feel free to help > > while I'm out :) > > > > Another thing I wondered about is if some of the things like JPA and > > JXTA should also be moved out into the extensions folder? > I think the JPA stuff should be moved out. Not sure about JXTA - > Meeraj what do you think? If you don't have time to move JPA I can > deal with it in a few days after I finish my core refactors. > > Jim > > > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > This message has been checked for all email viruses by MessageLabs. > > > ***************************************************** > > You can find us at www.voca.com > > ***************************************************** > This communication is confidential and intended for the exclusive use > of the addressee only. You should not disclose its contents to any > other person. > If you are not the intended recipient please notify the sender named > above immediately. > > Registered in England, No 1023742, > Registered Office: Voca Limited > Drake House, Three Rivers Court, > Homestead Road, Rickmansworth, > Hertfordshire, WD3 1FX > > > This message has been checked for all email viruses by MessageLabs. > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > This message has been checked for all email viruses by MessageLabs. This message has been checked for all email viruses by MessageLabs. --------------------------------------------------------------------- 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]
