[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[stp-dev] STP IRC log 5 April 06

[17:03] oisin: hi all
[17:03] oisin: karl - i see you have got around your firewall
[17:04] Karlr: the easy way - I am at home
[17:05] Karlr: So whats on the agenda for today ?
[17:06] oisin: the agenda is open today - so let me know what you would like to talk about. I have some topics....
[17:06] oisin: 1. volunteers to be buildmasters, lack thereof
[17:07] oisin: 2. our choices for runtimes as part of deployment support
[17:07] oisin: 3. what requirements for project layouts
[17:08] oisin: 4. what choices around 'introspectors' for extending the STP assembly model
[17:08] oisin: anything from anyone else?
[17:08] DavidBosschaert: Just wondering about the ALF demo after this IRC, is there a voice connection with that too?
[17:09] DavidBosschaert: (Not mentioned in the email)
[17:10] oisin: I don't see one in the email, I will send Tim a message to confirm
[17:10] DavidBosschaert: We could use our IONA bridge, if needed.
[17:12] oisin: any other items?
[17:12] oisin: seeing non...
[17:12] oisin: Item 1
[17:13] oisin: again I say - volunteer to be a buildmaster to get this stuff off the ground
[17:13] oisin: Naci and his guys have done great work in getting the WTP system going on their local machine
[17:13] oisin: and they deserve our support
[17:14] askehill: if people are fairly patient I can help out in this space and use it to come up to speed with the CVS repository and build system
[17:14] RobCernich: i'm willing to volunteer once i've met my current obligations
[17:14] oisin: adrian and rob truly you are both gentlemen
[17:14] oisin: adrian: naci is a very patient guy and I will put you in contact
[17:15] oisin: rob: tell us about your current obligations....
[17:15] RobCernich: i'm working on our deployment contribution at the moment
[17:15] RobCernich: in addition to dtp and internal tasks
[17:16] RobCernich: i'm spread pretty thin at the moment
[17:16] oisin: great - how is the deployment contrib looking? This is closely related to #2 in my list. Can you give us a quick outline of the current capabilities, i.e. what runtimes it can connect/deploy to?
[17:16] RobCernich: (i feel like the last human in that new episode of dr who :-))
[17:17] RobCernich: i'm in the process of refactoring at the moment
[17:17] RobCernich: the contribution provides a framework for building deployment capabilities into eclipse
[17:18] RobCernich: it provides extension points for identifying packages within the workspace
[17:18] RobCernich: packages may be "physical" or "logical" (for lack of better terms)
[17:19] RobCernich: a logical package can be thought of as a resource defining a package, e.g. an sca assembly model instance
[17:19] oisin: right rob will get back to us I'm sure
[17:20] RobCernich: the framework also provides an extension point for adding deployment capabilities to a connection profile (dtp connectivity)
[17:21] RobCernich: this extension point can include a package builder that is used to build one of these logical packages for deployment to the targeted server
[17:22] DavidBosschaert: Could the connection profile be an appserver (as opposed to database) or other type of container?
[17:22] RobCernich: from a supported runtime perspective, we would need to implement these extensions for the servers we decide to support "out of the box"
[17:22] RobCernich: yes
[17:22] RobCernich: a connection profile can be used to represent any type of server
[17:22] oisin: We're looking at 'ESB's being our runtimes
[17:23] RobCernich: this should be possible
[17:23] oisin: So - here's some of the options: Tuscany, Celtix, JBI, JBoss ESB
[17:23] Karlr: this is possible as we have implemented a connection profile to out own 'ESB'
[17:25] RobCernich: is there a question in there oisin
[17:27] oisin: i guess that it is not possible to have an 'exemplar' ESB as part of the framework contrib...because there is no standard
[17:28] oisin: so we will need to drill down real quickly on some exemplars to understand how it hangs together
[17:28] RobCernich: i think we can provide an example
[17:29] oisin: which strongly indicates a good need for documentation -- although an example is good
[17:29] RobCernich: from a design perspective
[17:30] RobCernich: we should define a package artifact. i think we've already decided this would be the sca assembly model
[17:30] RobCernich: i think it would be beneficial to have this example built atop a base implementation that could be reused for other containers
[17:30] oisin: I'm not sure that the assembly model is exactly suitable as a package artifact, although I don't know what your package model requires
[17:31] RobCernich: not as an artifact, but as the input to a package builder
[17:31] oisin: that makes sense
[17:31] RobCernich: these will probably need to be customized for particular containers
[17:31] oisin: yes, I imagine that there will be some kind of model visitation and reforming for particular container requirements
[17:31] RobCernich: however, there is the possibility for reuse for containers that specify a package artifact
[17:32] oisin: example?
[17:32] RobCernich: jbi
[17:32] RobCernich: same would go for deployment api's
[17:32] RobCernich: e.g. app servers
[17:32] dparikh joined the chat room.
[17:33] RobCernich: base impl's can/should be provided for reuse in these cases (note app servers, just given as an example of a container with a specified deployment api)
[17:33] oisin: of course, again that seems sensible
[17:34] oisin: hi devang: thank you for posting that UML diagram yesterday
[17:34] dparikh: no problem
[17:35] oisin: we were just discussion deployment runtimes
[17:37] oisin: so we have introspector --> assembly model --> package builder --> deployment framework --> connection profile --> runtime
[17:38] oisin: has everyone read the assembly code contrib and know what an introspector is?
[17:38] oisin: say no now
[17:38] oisin: if you haven't
[17:39] askehill: I haven't
[17:39] davidbrpr joined the chat room.
[17:39] oisin: adrian: https://bugs.eclipse.org/bugs/show_bug.cgi? id=132747
[17:40] askehill: ok, I'll follow up on this later on. thanks.
[17:40] oisin: an introspector has the responsibility for visiting potential model contributors and extracting relevant information, for example looking over a .java file and obtaining model elements based upon annotations
[17:42] oisin: in the contribution, there is a test introspector and a .module file introspector
[17:42] oisin: there is a java introspector in the works as a further contribution
[17:42] oisin: devang: perhaps you would like to tell us more about that?
[17:43] dparikh: yes example java implementation with introspection framework is in works for contribution
[17:44] oisin: ballpark arrival time?
[17:44] dparikh: I will get back and post on mailing list for that one
[17:45] oisin: many thanks! I for one am very keen to see a full example of how to implement one of these guys
[17:46] oisin: devang: are you guys considering contributing a WSDL introspector?
[17:48] dparikh: WSDL introspector ? not sure what you mean. Introspection produces ComponentType from various implementation e.g Java, BPEL, C++ ...
[17:49] dparikh: short answer no we are not currently considering WSDL introspector
[17:51] oisin: just probing a bit here -- a ComponentType needs to refer to an interface so I guess that something needs to be done to get that information in there
[17:52] oisin: so if the only way to construct a ComponentType is thru introspectors, then there will be some requirement to do it for WSDL definitions
[17:52] oisin: or to find some out-of-band approach
[17:52] oisin: would this be a fair comment? or am I making an error?
[17:53] dparikh: Specification also talks about standalone resource .componenttype file to describe ComponentType
[17:54] oisin: yes
[17:55] oisin: so basically if you are doing WSDL-first then you are required to do your WSDL separately, then make a .componenttype file and manually put in a pointer to your WSDL in there?
[17:56] dparikh: So in componenttype file you will describe Services, References and properties
[17:57] dparikh: In Service definition you will refere to WSDL for interface
[17:57] dparikh: here is the example for java
[17:57] dparikh: <service name="MyValueService"> <interface.java interface="services.myvalue.MyValueService"/> </service>
[17:58] dparikh: and for WSDL <service name="MyValueService"> <interface.wsdl porttype="..."/> </service>
[17:59] askehill left the chat room.
[17:59] oisin: ok -- so it's clear that we need to provide some tooling that means that developers can create wsdl interfaces, then connect up to the model through the .componenttype introspection
[18:00] dparikh: I think WTP has tooling for WSDL interface creation
[18:00] oisin: BTW -- I've mailed the call-in phone number for the ALF presentation to the dev list
[18:00] oisin: a reminder: https://serena.webex.com/serena/j.php? S=571917605
[18:00] oisin: a reminder: Meeting password: alfdev
[18:01] oisin: a reminder: Phone +1-303-928-3232 ID: 6053141#
[18:01] oisin: yes WTP does have such a tool
[18:02] oisin: on an organizational note -- the ALF webex is starting now, so we will have to leave this discussion for the moment and take anything we need to the dev list.
[18:02] oisin: thanks for coming online all
[18:02] dparikh: thanks