|[stp-dev] IRC log 07jun06|
[16:58] jrohn joined the chat room. [17:04] RobCernich joined the chat room. [17:04] RobCernich: sorry i'm late [17:04] oisin: no prob[17:06] oisin: well guys not much going on at the moment for one reason or another [17:06] oisin: rob: do we have something to put up on the website around the SOAS subproject?
[17:10] oisin: knock knock, rob, hello? [17:11] oisin: get the coffee before the IRC[17:13] oisin: ok, most of the questions I had were for rob, so I guess this will be a short one...
[17:13] oisin: does anyone else want to put anything on the agenda?[17:14] DavidBosschaert: Maybe we should talk a bit about facets, since some links to its docs were posted to the devlist...
[17:14] DavidBosschaert: Did anyone look into them? [17:14] DavidBosschaert: (I did for a bit [17:14] RobCernich: sorry[17:15] oisin: yes the facets stuff is pretty cool and the work done by Philip Dodds for JBI deployment is neat [17:16] oisin: we have a very important task to see how the facets approach and the deploy framework approaches can co-exist
[17:16] RobCernich: i don't see any problems there[17:16] RobCernich: the facets look like a more advanced version of project natures
[17:16] oisin: yes indeed they do[17:17] RobCernich: i don't see them as a requirement for the stp platform
[17:17] RobCernich: although extensions may decide to use them[17:17] RobCernich: as far as integration with the assembly models go, i think the context api's included in the core project are more appropriate [17:18] DavidBosschaert: Would it maybe make sense to use them in the same manner as WTP is using, basically as technology markers... [17:18] RobCernich: since they would have an affect the functionality available within the assembly editor
[17:18] oisin: rob: can you explain a bit more? [17:18] RobCernich: which part[17:19] oisin: the part where you started talking about integration with assembly models
[17:19] RobCernich: i meant with respect to facets[17:20] oisin: still don't understand - bit slow today - let me try to be a bit more accurate [17:21] oisin: are you saying that the core context apis are more appropriate for use than the facets? [17:21] RobCernich: as i understand (from a high level) the context portion of the core project allows extensions to define which sca extensions are available for use within that editing session
[17:21] RobCernich: i think so [17:21] RobCernich: the facets seem useful in the ways wtp uses them [17:22] RobCernich: i don't see a matching use case for stp[17:22] RobCernich: exemplary tools may use them, but i don't see a use for the core platform [17:23] oisin: I'm still struggling a bit but I think what you are saying is that... [17:23] RobCernich: facets affect the project, contexts affect a specific assembly model instance [17:24] oisin: the use of facets in the context of them being an analog of an advanced nature is not necessary for STP [17:24] RobCernich: or the editing session for a particular assembly model
[17:24] RobCernich: at the platform level[17:24] RobCernich: extension developers may choose to use them for their specific service types [17:24] DavidBosschaert: What about requirements that maybe be placed on a target runtime. Could they not be specified as a facet?
[17:24] RobCernich: e.g. EJB services [17:25] RobCernich: they could, but that would affect an entire project [17:25] RobCernich: as opposed to a single assembly model[17:25] RobCernich: which, i think, is what the context api's are for (don't quote me on that) [17:26] RobCernich: the assembly model is the deployable unit, not the project
[17:26] RobCernich: i think that's a basic difference from wtp [17:26] DavidBosschaert: I understand what you mean now.[17:26] oisin: if we take the approach that each service within the assembly is a project in its own right, then facets could be used as markers for those projects, then when we go to deploy the assembly, the actions we need to take could be driven from those facets?
[17:27] oisin: implication that the assembly is a separate project [17:28] RobCernich: that is a possible approach[17:28] RobCernich: i'm not sure i would want to develop using that approach [17:28] RobCernich: my analogy would be a separate project for each java class
[17:28] oisin: ?? [17:28] RobCernich: a single project for every service [17:28] RobCernich: my analogy would be, for a pojo app [17:29] RobCernich: one project for every java file [17:29] RobCernich: one project defining the jar[17:29] oisin: I think your analogy doesn't fit because classes are a much more fine-grained thing than a service [17:29] RobCernich: so, if i had an assembly with 10 services, i'd have 11 projects [17:29] oisin: that being said, multiple services per project is a much better idea
[17:30] RobCernich: that was my point[17:30] oisin: so if you had an assembly with 10 services you could have anything from 2 to 11 projects
[17:30] RobCernich: seems reasonable [17:30] RobCernich: my preference would be to have a single project[17:30] oisin: I think you will need project per service if they are heterogenous -- e.g. different languages or different runtimes [17:31] oisin: I think it's useful to decouple the service implementation projects from the assembly project [17:31] oisin: My reasoning is that this allows your developers to construct services without having to deal with the assembly project (where practical of course) [17:32] RobCernich: i think that is useful, i also think it's useful to have them colocated
[17:32] RobCernich: depending on how big the project or organization is [17:33] oisin: yes, and how you want to reuse services [17:33] RobCernich: right [17:33] DavidBosschaert: Freedom of choice for the developers is good[17:33] RobCernich: with respect to that, you may have services referencing a common interface
[17:33] oisin: enough freedom, just not too much [17:33] RobCernich: aye[17:34] RobCernich: so, now you have possible three artifact types that you are referencing [17:34] oisin: note that the services that reference a common interface can also reference a common implementation
[17:34] RobCernich: assembly references components (services)[17:34] RobCernich: a service may reference/make use of service interfaces [17:35] RobCernich: that interface would be implemented by another service
[17:35] RobCernich: the assembly hooks them together [17:35] RobCernich: so if we have multiple projects[17:35] RobCernich: we need to figure out this bit of simply referencing an interface
[17:36] RobCernich: would this be another project type? [17:36] oisin: i have an example in my head and here it is:[17:37] oisin: somehow you have contrived to have a number of projects that implement services you wish to assemble [17:37] oisin: so you make a new assembly project and you enter a wizard dialog... [17:38] oisin: (actually, scratch the wizard bit, I was getting ahead of myself) [17:38] oisin: you want to add a component to the assembly - it's this bit that has a wizard [17:38] oisin: you can choose to import a component from an existing project [17:39] oisin: your registered introspectors scan the project you choose to see if they can find anything they can use as the interface and the binding [17:39] oisin: then you pick the ones you want and they are added to the assembly [17:40] oisin: there is a cross-project reference here that might be a problem I am not sure [17:40] DavidBosschaert: Additionally, I think you should be able to refer (or wire) to an External Service (outside of your control) without creating a project. You simply refer to them from the assembly project.
[17:40] oisin: (since it's in my head the edges are already all smooth [17:41] RobCernich: seems reasonable[17:41] oisin: this looks very like http://wiki.eclipse.org/ index.php/Enterprise_SOA_Developer_Scenario
[17:41] oisin: on our scenarios page[17:42] RobCernich: i'm still curious about references below the component level
[17:43] RobCernich: e.g. service a uses interface b [17:43] RobCernich: service c implements interface b [17:43] RobCernich: service a is added to assembly x[17:43] RobCernich: assembly x needs to define a component implementing b
[17:43] oisin: a--wire-->b--impl by-->c[17:44] RobCernich: user (perhaps with some help) finds service c, wires them together
[17:44] RobCernich: where does interface b live? [17:45] oisin: I think it lives in a number of places [17:45] RobCernich: assuming service a and c reside in separate projects [17:45] RobCernich: shouldn't there be a single reference?[17:45] oisin: ok -- what's the reality of where it lives in a multi- project scenario, right?
[17:45] RobCernich: i see three possibilities....[17:46] RobCernich: it lives in the project by itself with projects a and c referencing it
[17:46] RobCernich: it lives in project c with project a referencing it [17:46] RobCernich: it lives in project a with c referencing it [17:46] RobCernich: sorry four, they are all colocated [17:47] DavidBosschaert: yep, I think these are the possibilities[17:47] RobCernich: i think the decision depends on your usage of the interface
[17:47] RobCernich: and your assembly [17:48] oisin: and of course your development history[17:48] RobCernich: from here you can start looking at permutations within the assembly model...e.g. different instances or impl's for qos, security, etc. [17:49] oisin: if you have developed all this guys separately, then you may be constrained by your initial choice
[17:50] adisakala joined the chat room.[17:51] oisin: i think we are having a useful discussion here - would you be in favor of continuing on the mailing list Rob
[17:51] RobCernich: maybe [17:51] RobCernich: sure [17:52] adisakala left the chat room. [17:52] oisin: whew! didn't know where the maybe fitted in there [17:52] RobCernich: do you want me to write something up [17:52] oisin: yes please! [17:52] RobCernich: ok [17:52] RobCernich: i'll have something out by cob tomorrow [17:52] oisin: that would be great. [17:52] RobCernich: but i'll try for later today [17:53] oisin: that would be very great[17:53] oisin: one more question for you: have you got any feedback on you CQ from the EMO
[17:53] RobCernich: yes [17:54] RobCernich: i should be committing the code today or tomorrow[17:54] RobCernich: i still need to get in contact with Naci about the build system [17:54] oisin: excellent - I must catch up with Dan and the guys about their outstanding CQs [17:55] oisin: when you contact naci will you keep adrian in the loop too - he's not here right now - he's going to take some of the buildmaster load [17:55] RobCernich: do i need to do anything for the ip log for this (e.g. re. the approval from the emo)
[17:55] RobCernich: i will do that [17:56] oisin: yes an entry will be required in the IP log [17:56] oisin: http://www.eclipse.org/stp/development/ip_log.php [17:56] oisin: I can add you in if you like [17:57] RobCernich: ok[17:57] RobCernich: do i need to do anything with the approval confirmation email i got from the emo, or is this tracked directly by them?
[17:57] RobCernich: i.e. do you need anything from a project perspective[17:58] oisin: it would be useful to keep it on file as it were - would be a good plan to add it as a comment to the bugzilla entry before closing
[17:58] RobCernich: will do [17:58] oisin: yes it is tracked directly by them too[17:59] oisin: will you move any doco over to the SOAS subproject page too Rob when you get the chance - it's bare!
[18:00] oisin: sorry rob seems I am dumping stuff on you here [18:00] RobCernich: i am a committer; should earn my keep [18:01] oisin: there is advice there for us all... [18:04] oisin: one more topic before we go...[18:05] oisin: there was a mail on stp-dev about changing the time of this IRC to mondays at something like 1200 EST
[18:05] RobCernich: works for me[18:05] oisin: there was a huge response to the question and the mail server was totally swamped
[18:05] oisin: *not* [18:05] oisin:[18:06] oisin: ok we will move our irc for next week to Monday at 1200 EST]
[18:06] oisin: will send out notice.[18:07] oisin: we are not at the watershed - thanks guys for an interesting discussion and see you on the list
Back to the top