[stp-dev] STP IRC log 5 April 06

[Oisin Hurley <ohurley@xxxxxxxx>]

[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