[ http://issues.apache.org/jira/browse/TUSCANY-639?page=all ]
ant elder updated TUSCANY-639:
------------------------------
Fix Version/s: Java-M2
Affects Version/s: Java-M2
> 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
> Affects Versions: Java-M2
> Reporter: Jervis Liu
> Fix For: Java-M2
>
>
> 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]
