[
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