[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
[stp-dev] IRC log 17may06
|
(no chat topic is set)
[16:59] RobCernich joined the chat room.
[16:59] pombred1 left the chat room. (Read error: 110 (Connection
timed out))
[17:01] oisin: hi all
[17:03] oisin: for a change, I don't have a laundry list of stuff today
[17:04] oisin: there are still some outstanding bugs wrt website content
[17:04] oisin: michael, can I get you to confirm or deny that https://
bugs.eclipse.org/bugs/show_bug.cgi?id=138155 has been addressed and I
will close it?
[17:05] oisin: rob can I give you a hint for https://bugs.eclipse.org/
bugs/show_bug.cgi?id=136552
[17:05] oisin:
[17:06] cctrieloff joined the chat room.
[17:06] oisin: I can put content on the site in moderately short
order should it be required
[17:06] cctrieloff: hi
[17:06] oisin: hi carl
[17:06] cctrieloff: are we in the middle of a topic?
[17:07] oisin: just finishing up on some outstanding web site bugs
[17:07] cctrieloff: ok -
[17:08] cctrieloff: I would like to get from feedback from someone
who knows how the Tuscany session went at JavaOne - as that will
directly impact STP
[17:09] oisin: I can send a mail to Jim Marino and get this info
[17:10] oisin: in other news we are looking at defining the content
of M1
[17:11] oisin: we think that a milestone drop that contains all the
relevant models could serve as a seed for feedback from runtime
providers and others
[17:12] oisin: with the proviso that we have all our outstanding
issues that relate to the models resolved
[17:13] oisin: ideally we would be in a position to do this milestone
in June
[17:16] oisin: another date is eclipse world 2006 in boston in
september: http://www.eclipseworld.net/
[17:17] oisin: where we have a session on Thursday afternoon
[17:18] oisin: [was just checking the schedule :)]
[17:18] oisin: ok - let's have an open session from this point.
[17:19] cctrieloff: I have ideas on that but no resources yet - so
[17:19] cctrieloff: if you want me to sign you up for stuff I will start
[17:19] cctrieloff:
[17:19] oisin: let us have the benefit of your ideas at least Carl
[17:20] cctrieloff: M1 should be a build of core with one or two
extensions so that the group as a whole can get a handle on it
[17:21] cctrieloff: there are some REALLY cool pieces in core
[17:21] cctrieloff: I would then also like to see one (randomly)
selected use case being framed out for M1
[17:21] mdelder: Sorry for the dealy. bug 138155 has not been
addressed yet. I'm going to make another pass over the doc and take
care of that sometime today I think. We're waiting for approval for
our CQs for the Java contribution
[17:22] cctrieloff: np
[17:23] oisin: carl: having a really compelling use case in M1 would
be mighty, but I think we need to get something out to the public for
a good look earlier and then we can apply a use case run for M2 six
weeks later
[17:23] mdelder: Are we going to use the STP wiki to define our
scenarios?
[17:24] oisin: michael: when did you send in the CQ? I will get in
touch with EMO to see what stage in the process it is at.
[17:25] oisin: michael: yes by all means let's put some scenarios on
the wiki - a rich choice of scenarios would be very healthy
[17:25] mdelder: We've been sending notes back and forth. I opened it
about two weeks back. There are two CQs; one for a contribution that
has no Tuscany contributions, one to reship the Tuscany contribution
so that we can depend on it for the Java annotations piece.
[17:25] oisin: what are the blockers?
[17:26] mdelder: Once both are approved, we will submit a third CQ
for the block of code that has Tuscany dependencies (on to the
already approved redistribution of Tuscany -- maybe structured as a
plugin that exposes the Tuscany annotations model on its runtime
classpath)
[17:26] mdelder: I think the Tuscany redistribution just requires
more hoops and they are also swamped with Callisto
[17:26] oisin: yes, callisto is really taking everyone's cycles
[17:26] mdelder: I would recommend maybe planning our milestone to
end after Callisto has shutdown; perhaps in mid to the end of July.
[17:27] mdelder: I think Callisto is scheduled for sometime mid-to-
late June.
[17:27] oisin: sounds like a practical approach
[17:29] oisin: in the meantime, there is the opportunity for us all
to get very very familiar with the core code
[17:30] mdelder: ... and scenario definition.
[17:30] oisin: carl: if we move M1 to apres Callisto, there may be
some time for a small use case to go in the bag, but I would be
hesitant to commit to delivering it yet
[17:31] mdelder: The wiki is now open to everyone; committers and
public alike so there's lots of room to get plenty of community
feedback.
[17:32] oisin: One still must log in to write it, correct?
[17:32] mdelder: Correct; but anyone can sign up for an account.
[17:33] mdelder: The other issue I'm curious about is the deployment
framework. I haven't heard much on collaborating to work through
requirements. Is there any new progress here?
[17:33] oisin: I will take an action item to put a banner on the home
page directing people towards a scenario definition section of the wiki.
[17:34] oisin: the are a set of requirements at http://
wiki.eclipse.org/index.php/STP_Deployment_Framework_Requirements with
some discussion
[17:34] mdelder: Also, I think there are some misunderstandings
perhaps on the WTP/DTP adoption. I don't think the section note on
the WTP 2.0 site is meant to imply that DTP will replace the current
Project Facet/WTP Server Tools API. I think the comments are only in
the context of replacing the DTP functionality; all the feedback I've
gotten from the WTP Archicture committee is that DTP and WTP will be
siblings
[17:34] oisin: (the discussion is accessed from a tiny little tab at
top of page)
[17:34] oisin: that is the same impression that i have michael
[17:35] oisin: they will be siblings
[17:36] oisin: so I think it's not an either-or question for STP - we
adopt the DTP/WTP deploy/connect 'family': does this make sense?
[17:37] mdelder: I think STP should be position on top of DTP and
WTP; but without new server integration API or concepts. I think
Enterprise Service Buses should be defined as WTP Application
Servers. Instead of a new "technology type" concept; we should just
use Project Facets.
[17:38] mdelder: Any limitations in the WTP or DTP API should be
driven back as requirements to those projects in the next release.
[17:38] RobCernich: i would disagree with that first comment
[17:39] RobCernich: i don't think there is enough capability within
the servers framework
[17:39] RobCernich: e.g. displaying content not associated with a
particular project
[17:39] RobCernich: this may be a problem with my understanding of
the framework and how it works (i'm not a wtp expert by any stretch)
[17:40] mdelder: So here's where the discussion around requirements
and involving the appropriate people from WTP/DTP who are experts in
this field.
[17:40] RobCernich: but it my testing, it seemed the only content
within the servers view was related to the projects i had associated
with the server
[17:40] mdelder: What other content would you like to show?
[17:40] RobCernich: other elements installed on the server
[17:40] RobCernich: i can add this to the deploy requirements
[17:41] RobCernich: e.g. if i have other web services installed on a
server, i think those services should be exposed to the tooling
[17:41] mdelder: That would be great. If there's no collaboration on
these points early, STP will experience the same pain that WTP
experienced.
[17:41] RobCernich: not specific to web services mind you
[17:41] RobCernich: using that as an example
[17:42] mdelder: If you build an API that is different or more
expansive than WTP or DTP supports, then eventually there will be
pushback to either (1) not make that more expansive implementation
formal API in the first release or to outright port it down to oneo f
those two projects.
[17:42] mdelder: I've seen this once with WTP; I'd rather not see the
same results in STP
[17:43] RobCernich: i'm not proposing any new api
[17:43] RobCernich: i'm just stating a requirement
[17:44] RobCernich: i will add this to the wiki
[17:44] mdelder: Excellent
[17:44] mdelder: So Oisin, are you going to take the lead to drive
out maybe three scenarios? Something high level enough that it
doesn't take long to define it, but with enough detail to get a
vision for what STP is trying to accomplish?
[17:45] oisin: yes I will do that
[17:46] mdelder: So for the scenario topics -- what do we have?
[17:46] oisin: I will set up the scenarios focus and the page -- my
expectation is plenty contribs
[17:47] mdelder: (1) Creating services? (2) Deploying Services? What
else?
[17:47] oisin: let's take a developer viewpoint
[17:47] oisin: we create a service from scratch and deploy it...
[17:47] mdelder: Do we anticipate using the XML editor as our primary
editor for SCA models? What wizards would be useful? New Module
Project? New Shared Project?
[17:48] oisin: we import a set of pre-existing source, mark it up
appropriately and deploy it
[17:48] mdelder: Okay. How far along would each subproject need to be
to implement a scenario? Do we anticipate a user-consumeable working
scenario for the end of Milestone 1 (I tend to think this is not
viable -- other opinions?)
[17:49] oisin: my anticipation is that each technology that provides
SOA infrastructure will provide an appropriate, most likely visual,
metaphor for editor
[17:49] oisin: of assemblies
[17:49] oisin: but - we have to start somewhere, so an XML editor
would be a start
[17:50] oisin: an end-to-end working scenario is not viable for M1 imho
[17:51] oisin: of course, things may pan out differently, but as I
mentioned before I would not like to commit to that publicly
[17:52] oisin: it may be the case that with some judicious reuse of
pre-existing elements from different projects that we could achieve much
[17:52] mdelder: So for now we're going to continue the discussion
around requirements for the deployment framework -- with more
involvement from the SOAS guys on that; and begin formulating
scenarios? Perhaps two types: M1 scenario "fragments" of things that
we'd like to see done each project and then maybe Release 1 scenarios
that are end to end?
[17:53] oisin: Yes on the first question.
[17:53] oisin: On the second, I think we should solicit R1 scenarios
and then decompose them for more manageable M1 scenarios
[17:54] oisin: This will give us a roadmap as a side-effect
[17:54] oisin: what do you think?
[17:54] mdelder: I think that will be fine
[17:54] mdelder: Is there anything else we'd like to cover today?
[17:54] cctrieloff: yip
[17:55] oisin: go for it carl
[17:56] cctrieloff: I said yes to that will be fine, and not that I
had another topic
[17:56] oisin: apologies -- no message correlation
[17:56] cctrieloff: seems like we might be done
[17:56] oisin: ok, if that is it, we will close for today, I will
kick off the scenarios effort
[17:56] mdelder: Okay. Sounds good. Thanks Oisin.
[17:56] oisin: rob, if you will put your requirement on the wiki...
[17:57] oisin: thank you all.
