[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.