[ http://issues.apache.org/jira/browse/TUSCANY-639?page=comments#action_12428586 ] Jeremy Boynes commented on TUSCANY-639: ---------------------------------------
Another place where this applies is on <include> eg: <include name="foo" group="org.bar" version="1.0"/> > 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]
