support for dependencies when referencing artifacts
---------------------------------------------------

                 Key: TUSCANY-639
                 URL: http://issues.apache.org/jira/browse/TUSCANY-639
             Project: Tuscany
          Issue Type: New Feature
          Components: Java SCA Core
            Reporter: Jervis Liu


support for dependencies when referencing artifacts, for example, . 
<implementation.composite name="foo" group="org.bar" version="1.0"/>. In this 
case, we can probably use some maven APIs to access the repo to resolve 
dependencies. See ArtifactRepository and it's implementation as a starting 
point.

Enclosed below is IRC chat related to this topic.

(01:55:14) jervisliu: I dont quite understand what you mean by  "I think this 
can be handled by the <dependency> mechanism and the use of the applicable 
location attributes e.g. wsdlLocation"
(01:55:35) jervisliu: what kind of <dependency> mechanism are you refering to?
(01:56:08) jboynes: the ability to add <dependency> elements into SCDL to 
extend the classpath for the composite
(01:56:55) jervisliu: this is not part of spec, right?
(01:57:07) jboynes: no, it's a tuscany feature
(01:57:33) jboynes: given the spec doesn't talk about packaging yet :-(
(01:58:19) jervisliu: see. but it looks like there is an easier way to achieve 
same result. for example, the celtix-binding.jar can have a default.scdl
(01:58:31) jboynes: sure
(01:58:34) jboynes: you can do both
(01:58:37) jervisliu: and the dependency of celtix-binding.jar can be specified 
in MANIFEST
(01:58:48) jboynes: ah, no not really
(01:59:09) jboynes: people hate manifest Class-Paths
(01:59:19) jboynes: they still work and can be used
(01:59:24) jervisliu: this can be done very easily in maven, and is a well 
understood way to resolve classpath dependencies
(01:59:31) jboynes: yes
(01:59:53) jboynes: <dependency> is quite maven friendly ;-)
(02:00:36) jboynes: I also mentioned having the implementation use maven 
metadata if present in the jar
(02:00:48) jervisliu: sure. I remember there was talk about a maven like 
dependency element.
(02:00:58) jboynes: yep - - I just went and did it
(02:01:19) jboynes: see ArtifactRepository and it's implementation
(02:01:54) jboynes: having an implementation that used maven itself to locate 
the artifacts would be real cool
(02:01:54) jervisliu: oh, i dont know its done already. ;-)
(02:03:57) jervisliu: cool. so the scdl file under ext dir (using <dependency>) 
can only used for one binding implementation. right?
(02:04:32) jboynes: well, it's a composite so it could contain components 
implemented by other nested composites
(02:05:35) jervisliu: but then all dependencies will be merged to compose a 
classpath,
(02:05:50) jboynes: no, the composite classloader is hierarchical
(02:06:20) jboynes: the nested composites would be in child classloades
(02:06:40) jervisliu: ok....lets have a concrete example.
(02:07:08) jervisliu: how to write this scdl if we have both axis and celtix 
libraries under ext?
(02:07:27) jboynes: well, you could just put them both in the ext directory
(02:07:43) jboynes: then you wouldn't need any scdl
(02:07:54) jboynes: s/libraries/bindings
(02:08:41) jboynes: i.e put binding-axis.jar and binding-celtix.jar in ext
(02:08:56) jervisliu: then when using <binding.ws>, which one is actually being 
used?
(02:09:07) jboynes: why does it matter?
(02:09:24) jervisliu: well, i just sent out an email to discuss this.
(02:09:24) jboynes: it could be either but they both impl the spec
(02:09:43) jboynes: by saying <binding.ws> the user us saying they don't care
(02:10:01) jervisliu: maybe it does not matter. but users still wants to know 
whichi implementation they are actually using
(02:10:41) jboynes: why?
(02:10:56) jervisliu: and in the real world, it still matters. for example, 
both axis2 and celtix have their own configuration files, the default config 
file shipped with binding probably works for 99% situations
(02:11:12) jervisliu: but it might be the case that they need to modify the 
config file.
(02:11:29) jboynes: so in the "real" world how many users will actually use 
both concurrently?
(02:11:32) jervisliu: in this case, they do need to know which implementation 
is loaded by tuscany
(02:11:35) jboynes: no
(02:11:48) jboynes: they need to make sure that they use the implementation 
they modified
(02:12:05) jboynes: so if they modified celtix they should use binding.celtix.ws
(02:12:21) jboynes: as that application will not work on a runtime that only 
has axis
(02:12:59) jervisliu: ok. i think i m convinced on this.
(02:14:06) jervisliu: the reason why i came out with this question is that i 
had thought we ship Tuscany kit with a default ext dir, which contains 
probabaly all binding availbe in tuscany. It is not users reponsibility to 
create the ext dir
(02:15:00) jboynes: I'm writing a note on this atm (just keep ending up on irc 
:-) )
(02:15:28) jboynes: I'm not sure we should ship a distro with everything
(02:15:56) jboynes: i think that will confuse users with things like this
(02:16:02) jboynes: and I don't think it will scale
(02:16:15) jervisliu: is that the reason why u removed axis binding from 
standalone distribution?
(02:16:22) jboynes: as we will never be able to goatherd all the extensions 
into releasability at the same time
(02:16:52) jboynes: partly yes, but mostly becuase I'm in the middle of a bunch 
of classloader changes
(02:17:04) jboynes: and I wanted to keep things simple
(02:17:21) jervisliu: ok. as  i mentioned in my email, it makes sense to me to 
have a distribution for each bindings
(02:17:24) jboynes: it might be better to rename standalone to "minimal"
(02:17:46) jboynes: I think each extension should be a separately releasable 
plugin
(02:17:48) lresende [EMAIL PROTECTED] entered the room.
(02:17:53) jboynes: like eclipse/maven/httpd/...
(02:18:16) jboynes: and on occasion we release know-good bundles
(02:18:34) jboynes: i.e. minimal + a set of useful extensions that work together
(02:18:47) jervisliu: sounds good
(02:19:02) jboynes: e.g. the "celtix" pack, or the "JSONREST" pack
(02:19:32) rfeng: jeremy?
(02:19:57) jboynes: I think another thing we could do for the binding.ws thing 
is have an option on the loader that says whether it should register for the 
technology default
(02:20:09) rfeng: Is ServletLauncherListener supposed to set the launcher or 
the composite to the servlet context?
(02:20:23) jboynes: so the Axis binding would always register to handle 
binding.axis
(02:20:36) jboynes: but could be configured to handle binding.ws or not
(02:20:52) jervisliu: yep
(02:21:09) jboynes: this is set with a property on it's composite to allow an 
admin to choose the default if both happen to be installed
(02:21:28) jboynes: and then the user "knows" - at least, if they talk to their 
admin :-)
(02:22:00) jervisliu: yes, this way actually we can load an bin‌ding 
implementation explicitly
(02:22:26) jboynes: and we give control to the admin and the developer
(02:23:22) jervisliu: but then how about both celtix and axis say they r 
default for binding.ws?
(02:23:43) jervisliu: is this considered a user configuration error? ;-)
(02:23:49) jboynes: then the policy is set by the LoaderRegistry - first, last 
or error
(02:24:51) jboynes: and an extension should always do it's own + the tech 
default
(02:25:01) jervisliu: wel, the first or last doesnt make much sense anyway. u 
never knows which binding get loads first on different os and platform
(02:25:34) jboynes: well you want one :-)
(02:25:49) jboynes: and "first" is really "first succeeds , others are ignored"
(02:26:09) jboynes: vs "first suceed, all others get an error"
(02:26:19) jervisliu: but anyway, its much clear to me now.
(02:26:41) jboynes: there's also the case where the celtix binding is deployed 
twice ;-)
(02:26:41) jervisliu: as a action item, beside the support of <binding.celtix>
(02:27:20) jervisliu: any other tasks left to do, for example, in the 
<depedency> area?
(02:27:46) jboynes: doing what we talked about in both celtix and axis would be 
good
(02:28:17) jervisliu: ok. so also the support for <binding.axis>.
(02:28:17) jboynes: in the dependency area, getting it to use some real maven 
api to access the repo would be real cool
(02:28:44) jboynes: so we get transitive dependencies and remote downloads as 
well
(02:29:17) jervisliu: i will create a jira for the support of <binding.axis>. < 
binding.celtix>.
(02:29:23) jboynes: thank
(02:29:43) jboynes: and support for dependencies when referencing artifacts
(02:29:45) jervisliu: is there already a jira for <dependency> using maven?
(02:30:04) jboynes: e.g. <implementation.composite name="foo" group="org.bar" 
version="1.0"/>

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira



---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to