Re: Moving ServiceDiscovery and related classes to tuscany-util
On Fri, Feb 29, 2008 at 8:51 AM, Simon Laws [EMAIL PROTECTED] wrote: On Fri, Feb 29, 2008 at 7:34 AM, Venkata Krishnan [EMAIL PROTECTED] wrote: Hi, I find that ServiceDiscovery is getting to be used widely and want to move it out of Contribution module to a separate module like Utils. The immediate benefit I see from this is some relief from cyclic dependencies. For example, I am trying to use the ServiceDiscovery in the 'definitions' module and to do that I'd need the 'contribution' module. But the 'contribution' already has dependency on 'definitions'. I agree that 'contibutions' could be cleaned up a bit so as to not depend on 'definitions' but I wish to deal with that separately and not as an alternative. Thoughts ? - Venkat +1, It's used from lots of places, contribution, core, databinding etc. and doesn't seem to be intrinsically related to the process of contribution. How about tuscany-extensibility as an alternative to tuscany-util though as util could end up being a bucket for all sorts of things. Simon Agree about moving it out of contributions but how about to avoid another new module just to a .utils package in the spi module? I think everything that needs this would already be including the tuscany-core-spi module. ..ant
Re: Moving ServiceDiscovery and related classes to tuscany-util
On Fri, Feb 29, 2008 at 7:34 AM, Venkata Krishnan [EMAIL PROTECTED] wrote: Hi, I find that ServiceDiscovery is getting to be used widely and want to move it out of Contribution module to a separate module like Utils. The immediate benefit I see from this is some relief from cyclic dependencies. For example, I am trying to use the ServiceDiscovery in the 'definitions' module and to do that I'd need the 'contribution' module. But the 'contribution' already has dependency on 'definitions'. I agree that 'contibutions' could be cleaned up a bit so as to not depend on 'definitions' but I wish to deal with that separately and not as an alternative. Thoughts ? - Venkat +1, It's used from lots of places, contribution, core, databinding etc. and doesn't seem to be intrinsically related to the process of contribution. How about tuscany-extensibility as an alternative to tuscany-util though as util could end up being a bucket for all sorts of things. Simon
Re: Moving ServiceDiscovery and related classes to tuscany-util
Alright, I am going to create a new module named tuscany-extensibility. The reason I suggested 'util' was that there are a few more things like the 'getQName' method that is being copied over in several places. I'd like to move these things as well into this module. So lets start with 'extensibility' now. Thanks - Venkat On Fri, Feb 29, 2008 at 9:57 PM, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Venkata Krishnan wrote: I find that ServiceDiscovery is getting to be used widely and want to move it out of Contribution module to a separate module like Utils. The immediate benefit I see from this is some relief from cyclic dependencies. For example, I am trying to use the ServiceDiscovery in the 'definitions' module and to do that I'd need the 'contribution' module. But the 'contribution' already has dependency on 'definitions'. I agree that 'contibutions' could be cleaned up a bit so as to not depend on 'definitions' but I wish to deal with that separately and not as an alternative. Thoughts ? Simon Laws wrote: +1, It's used from lots of places, contribution, core, databinding etc. and doesn't seem to be intrinsically related to the process of contribution. How about tuscany-extensibility as an alternative to tuscany-util though as util could end up being a bucket for all sorts of things. +1 Good idea, I also like tuscany-extensibility better than a general tuscany-util bucket. ant elder wrote: Agree about moving it out of contributions but how about to avoid another new module just to a .utils package in the spi module? I think everything that needs this would already be including the tuscany-core-spi module. Please, let's not make all these modules depend on core-spi with is really a 'runtime' SPI module. This won't help anyway with circular dependencies (just make it worse) as core-spi depends on assembly, policy, contribution etc. We need to move ServiceDiscovery down one layer, not up... -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Moving ServiceDiscovery and related classes to tuscany-util
Hi, I find that ServiceDiscovery is getting to be used widely and want to move it out of Contribution module to a separate module like Utils. The immediate benefit I see from this is some relief from cyclic dependencies. For example, I am trying to use the ServiceDiscovery in the 'definitions' module and to do that I'd need the 'contribution' module. But the 'contribution' already has dependency on 'definitions'. I agree that 'contibutions' could be cleaned up a bit so as to not depend on 'definitions' but I wish to deal with that separately and not as an alternative. Thoughts ? - Venkat
