[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
[stp-dev] IRC record 12apr06
|
[16:35] askehill joined the chat room.
[16:43] gaelblondelle joined the chat room.
[16:44] gaelblondelle left the chat room. ("Bye.")
[16:45] gaelblondelle joined the chat room.
[16:57] jrohn joined the chat room.
[16:59] mdelder joined the chat room.
[17:00] AMiguel joined the chat room.
[17:02] oisin: morning/afternoon/evening to you all
[17:02] RobCernich joined the chat room.
[17:03] oisin: I'm just IM'ing Naci to sort out some IRC technical
issues that he has and we shall embark soon
[17:04] oisin: today we wanted to get a community feeling for the
build structure proposals outlined on stp-dev [thanks to Michael, Naci
[17:05] oisin: any discussions that we need to have should happen
here and now
[17:05] oisin: when they are complete we will have a straw poll
[17:06] DavidBosschaert: Is WTP the only project using a structure
like Naci has proposed?
[17:06] oisin: the IRC record will be posted to the list and we will
have a deadline for +*'s over the next couple of days
[17:07] oisin: david: you will need to ask Naci
[17:07] mdelder: To my knowledge, that is the case; but I'm not as
familiar with other projects. Perhaps Naci would know of other cases
where this pattern is used?
[17:08] oisin: in Naci's approach, the goal is 'scalability' - which
I take to mean functional isolation of each subproject within
subdirectories
[17:09] mdelder: Scalability is a great goal -- but for each
subproject, the number of plugins is likely to be small; even long-
lived components like JDT have relatively few plugins in all
[17:09] mdelder: For future incubations, these would have a top level
subproject directory anyway
[17:09] cctrieloff joined the chat room.
[17:09] cctrieloff: sorry I'm late - IRC issues
[17:10] mdelder: I can go either way, but just out of experience
working with the WTP structure, you have to expand several nodes into
the structure to get to plugins; And this gets old
[17:10] mdelder: It doesn't take CVS long to respond with 10 folders
instead of 3, but it does take it longer to respond to 3 requests
(due to digging into the directory structure)
[17:10] oisin: guys - Naci is having difficulty getting to the IRC
due to technical issues. We can start a dialup bridge to communicate
- would this suit everyone?
[17:11] oisin: michael: time spent in CVS is something that can be
very annoying for developers, agreed
[17:11] cctrieloff: not ideal to open bridge
[17:12] mdelder: The other issue that the approach has is that's
sometimes not clear where a particular plugin you are looking for is
located, and you have to check several "component" folders for it ...
[17:12] RobCernich: wouldn't that be mitigated through naming convention
[17:13] RobCernich: e.g. i would assume all org.eclipse.stp.soas.*
plugins to be in the org.eclipse.stp.soas subproject folder
[17:14] mdelder: I like the one level for subprojects
[17:15] mdelder: But under the WTP approach it has : <subproject> /
components / <component> / plugins, tests, features
[17:15] mdelder: So I would propose just:
[17:16] mdelder: ... and "plugins" in that example was then:
plugins / <plugin> ...
[17:16] mdelder: But I would propose <subproject> / <plugins>
[17:16] mdelder: And probably put the features/ <features> under the
root of the repo, so that all features are managed from a central
folder.
[17:17] oisin: michael: I am looking at the mail from Naci at http://
dev.eclipse.org/mhonarc/lists/stp-dev/msg00170.html
[17:17] RobCernich: similar to the structure laid out in the top part
of naci's last email?
[17:17] oisin: the 'components/<component>/...' is not in that email
[17:17] oisin: instead it is :
[17:18] RobCernich: i like the structure at the top of that email
[17:18] oisin: <subproject>/{features, plugins,tests}/...
[17:18] RobCernich: yep
[17:18] oisin: so not as deep
[17:18] mdelder: I can go either way on this; it's not a huge deal.
But in general, you should probably always check out plugins and the
related tests -- so this approach requires you to expand plugins and
tests to fetch the plugins.
[17:19] mdelder: I just don't think the number of plugins here is
really going to get unscalable
[17:19] mdelder: A final version of STP 1.0 might have up to 5-6
plugins + 1-2 test plugins for each subproject. Is that worth
grouping plugins/ and tests/ ?
[17:20] oisin: michael: do you think there will be that few plugins?
[17:20] oisin: [retract] sorry I misread your sentence
[17:20] oisin: you mean 6-8 plugins per subproject
[17:20] mdelder: If you look at platform level components, they don't
have large numbers of plugins. The more plugins you expose, the more
plugin loading must take place
[17:21] mdelder: ... per subproject yes
[17:21] mdelder: Sometimes it makes sense to componentize
functionality into one or a small number of plugins (the .core + .ui
pattern for instance).
[17:22] mdelder: WTP has alot of componentization; I don't think that
STP will be large enough to be that fine grained. We should only
group functionality into new plugins if there's a real adopter need
[17:22] mdelder: And in general, I'd anticipate that adopters will
pick up STP by subproject; not by a selection of individual
components in each subproject.
[17:23] mdelder: So there's less need to break it out in many
plugins ...
[17:23] mdelder: But that's my opinion -- what other opinions are out
there?
[17:24] DavidBosschaert: I would probably be in favour of having all
the plugins in the same place and using naming conventions to
identify them. It would just give you a quick'n'easy overview of
what's there...
[17:24] oisin: if you consider the SOAS subproject, there will be one
framework with a number of example plugins for different runtimes and
the chances are adopters will only want to pick up one of these
rather than the whole lot
[17:24] mdelder: ... and naming conventions are required so you'll
always know test plugins by <subproject>.tests.*
[17:25] oisin: I'm channelling for Naci here: [having plugins/tests
in same folder is workable]
[17:25] RobCernich: can't componentization be handled more
effectively through feature definitions, then through cvs structure?
[17:26] mdelder: ... definately .. and this is why I don't think it's
necessary to group components or just plugins/tests in CVS
[17:26] mdelder: There's probably enough on the table now to take a
vote; I don't know that this is worth taking up this meeting
[17:27] oisin: I think we are in a middle ground here, with some
structure from naci's mail earlier, plus some structure from
michael's mail
[17:28] oisin: so it's not either or
[17:29] mdelder: Well how about this:
[17:29] oisin: is there consensus around <subproject>/{features,
plugins}/... with the plugin tests in the plugins dir
[17:29] mdelder: I'm fine with that ... I'd suggest though that there
just be one features/ directory at the root of the repo, and all
features there.
[17:29] RobCernich: i vote +1 for that structure whether or not the
test plugins are grouped separately or not
[17:30] mdelder: As you said oisin, we may have adopters who pick and
choose pieces of subprojects ...
[17:30] mdelder: ... but I'm fine with that approach .. so as an
example we'd have:
[17:30] oisin: michael: can you enlighten me a bit on that one - not
as eclipse experienced as yourself - about why features at top level
good?
[17:30] mdelder: --/org.eclipse.stp.core-feature
[17:31] mdelder: or would we have: /features/org.eclipse.stp.core-
feature ?
[17:31] mdelder: this is working .. just a sec
[17:32] mdelder: /org.eclipse.stp.core
[17:32] mdelder: features/
[17:32] mdelder: org.eclipse.stp.core-feature/
[17:32] mdelder: plugins/
[17:32] mdelder: org.eclipse.stp.core
[17:32] mdelder: org.eclipse.stp.core.tests
[17:32] mdelder: ... is the modified setup as I understand it
[17:32] mdelder: .. which I think is fine
[17:32] oisin: yes - great irc skills btw
[17:33] oisin: just cc'ing to Mr. Dai in Istanbul
[17:33] mdelder: You could also remove "plugins/", and put the
plugins directly under the subproject, and then aggregate all of the
<subproject>/features/ directories into a single <root>/features/
directory
[17:34] mdelder: Where the features are stored isn't really
important; so either approach is fine in my opinion
[17:35] oisin: ok, question from Naci here....
[17:35] mdelder: which would look like:
[17:35] mdelder: /features
[17:35] mdelder: org.eclipse.stp.core-feature/
[17:35] mdelder: org.eclipse.stp.xxx-feature/
[17:35] mdelder: /org.eclipse.stp.core
[17:35] mdelder: org.eclipse.stp.core
[17:35] mdelder: org.eclipse.stp.core.tests
[17:38] oisin: minimalist - but I prefer the former
[17:38] jrohn: I like this last approach, looks clean and easy to
navigate.
[17:38] RobCernich: me too, with or without the plugins folder
[17:38] RobCernich: (to oisin's comment)
[17:39] jrohn: I prefer no "plugins" folder, seems a bit redundant to
me.
[17:40] RobCernich: i agree with that
[17:40] oisin: alright lets do a show of, er, plus-ones....
[17:40] DavidBosschaert: Can we summarize what we are voting on exactly?
[17:40] oisin: yes.....
[17:40] mdelder: Okay
[17:40] mdelder: Option 1:
[17:41] mdelder: /org.eclipse.stp.core
[17:41] mdelder: features/
[17:41] mdelder: org.eclipse.stp.core-feature/
[17:41] mdelder: plugins/
[17:41] mdelder: org.eclipse.stp.core
[17:41] mdelder: org.eclipse.stp.core.tests
[17:41] mdelder: Option 2:
[17:41] mdelder: /features
[17:41] mdelder: org.eclipse.stp.core-feature/
[17:41] mdelder: org.eclipse.stp.xxx-feature/
[17:41] mdelder: /org.eclipse.stp.core
[17:41] mdelder: org.eclipse.stp.core
[17:41] mdelder: org.eclipse.stp.core.tests
[17:41] mdelder: +1 on Option 2
[17:42] oisin: +1 on option 1
[17:42] RobCernich: +1, opt 1
[17:42] askehill: +1 on option 2
[17:42] jrohn: +1 on Option 2
[17:42] DavidBosschaert: I thought the following was also suggested:
[17:42] oisin: [naci does a +1 on option 1, but we're not counting
that one here]
[17:43] DavidBosschaert: (Option 3) /features
[17:43] DavidBosschaert: org.eclipse.stp.core-feature/
[17:43] DavidBosschaert: org.eclipse.stp.xxx-feature/
[17:43] DavidBosschaert: org.eclipse.stp.core
[17:43] DavidBosschaert: org.eclipse.stp.core.tests
[17:43] DavidBosschaert: (So without a plugins or component name
directory)
[17:43] oisin: I don't recall seeing that one...
[17:44] RobCernich: i thought we were talking about opt 1, but
without a plugins folder
[17:44] RobCernich: i'd vote for that too
[17:44] DavidBosschaert: Thats what I was trying to write up..
[17:45] oisin: take a look back at michael's wording earlier this was
not the case
[17:45] RobCernich: i think it was john that brought this up
[17:46] RobCernich: err, jrohn (sorry)
[17:46] oisin: jrohn will confirm?
[17:46] mdelder: Any other votes?
[17:46] oisin: lurkers unite and at least give us a +0
[17:47] DavidBosschaert: +0 I'm easy with either option.
[17:47] oisin: btw we will need to circulate this on the dev list
[17:47] cctrieloff: +1 on option 2
[17:47] oisin: _briefly_
[17:47] cctrieloff: does that help the voting?
[17:47] jrohn: I was actually agreeing with what michael had said,
which is captured in Option 2.
[17:48] oisin: thanks.
[17:48] oisin: naci has a point that he thinks there is something
important that you can't do with option 2
[17:48] oisin: to do with top level reflection of the project
architecture in terms of sub project features
[17:48] oisin: ok.
[17:49] oisin: we have our straw poll complete and the options outlined
[17:49] mdelder: Sounds good
[17:49] oisin: I will email to list and we shall take more comments
over the next couple of days
[17:50] gaelblondelle left the chat room.
[17:50] oisin: then we will engage with the preferred soln
[17:50] oisin: now: is there any other business that is weighing on
anyone's mind
[17:50] mdelder: If we go with Option 2, we just need to add a /
features directory in the root of the repo ...
[17:51] mdelder: I'm also working on the documentation
[17:51] oisin: michael your timing is excellent - you have pre-empted me
[17:51] mdelder: I was planning on popping that out to the website
under a Technical Resources heading or what not
[17:51] mdelder: Hope to have a version ready by the end of the day
which covers some points at a high level, and should provide a
starting point for people to ask questions
[17:51] oisin: the website is being a problem child at the moment -
I'm currently blocked from committing due to a permissions glitch
[17:52] mdelder: I didn't think going into great depth initially made
too much sense, so I'll flush out the depth as questions arise
[17:52] mdelder: Okay, then I can put this under a /doc directory of
org.eclipse.stp.core for now
[17:52] mdelder: We can settle on a home at a later point in time
[17:53] oisin: that will do nicely and I will move it onto a
technical resources for Core when the commit process is working
[17:53] oisin: can you inform stp-dev when this occurs, please?
[17:53] mdelder: Will do
[17:54] AMiguel left the chat room. ("Chatzilla 0.9.70 [Firefox
1.5.0.1/2006011112]")
[17:54] mdelder: Are there any initial thoughts or design proposals
for soas ?
[17:55] oisin: this is a question for rob...
[17:56] mdelder: I'm a little concerned about the talks last week
about using the DTP Connection profiles instead of the WTP Server
Integration pieces. I didn't understand exactly what the real
proposal was for this; but I'd like to be sure that we are using the
WTP Server Integration for any runtime integration in STP
[17:56] RobCernich: karl has posted a presentation which summarizes
our forthcoming contribution
[17:57] mdelder: I must have missed that .. is that on the website
[17:58] RobCernich: it was posted to stp-pmc
[17:58] mdelder: ah
[17:58] mdelder: Will it be open to discussion for stp committers?
[17:58] oisin: michael's concern has been voiced by other WTP
committers, we need to address the situation
[17:59] oisin: michael: karl will be posting it to stp-dev and it
will be going to live on the website in due course
[18:01] mdelder: Okay -- is this a "proposal" or a solidified design
[18:02] cctrieloff: having discussed this in the past with Karl -
there are more than one solution today in eclipse. I was not
convinced that WTP gives us all we need, so I think we need to look
at what Karl has created, get our requirements down and engage WTP
[18:03] cctrieloff: This might be an area where WTP/STP/DTP want to
try unify/resolve
[18:03] mdelder: Which is considered more of our platform? WTP or DTP?
[18:03] oisin: michael: what do you mean by 'more of our platform'
[18:04] cctrieloff: I don't think it matters .. the key is what do we
need to be most successful
[18:04] oisin: STP will be a consumer of technology from WTP/DTP and
others
[18:04] mdelder: I need to see the proposal before I can really make
any comments; I just want to make sure that our server integration
story uses the WTP Facets and Server Tools API
[18:05] cctrieloff: what do we need from the SCA side + our goal. and
then we talk o both and work out what and how best to consume their
peices
[18:05] mdelder: Otherwise when a STP user goes to create an ESB
server (or other runtime), they would have to follow a different
server creation path than they did in WTP. STP servers should look
more like Application Servers than Database Servers
[18:05] cctrieloff: agree - however - SCA is not only about WTP
technologies
[18:06] RobCernich: i should point out that the connectivity
functionality within dtp is _not_ specific to database servers
[18:06] oisin: michael: let's wait for the document -- just because
this technology has roots in DTP does *not* mean it is DB-centric
[18:07] RobCernich: we(dtp) have also been asked to provide an
example jee connection profile implementation
[18:07] cctrieloff: so do we need to provide something under what WTP
has so we can use that for WTP technologies but other cases like BPEL/
SCA java or PHP other issues might exist that WTP does not cover
[18:08] oisin: all - I'd like us to continue this on the list because
I know there are other WTP committers out there that are very interested
[18:09] cctrieloff: the questions is then do we add to it, expand on
it, or complement it... I don't think there is a clear answer yet and
the Sybase guys have done quite a bit of work in this area so we
should take a good look at it
[18:10] oisin: any objections to adjournment at this point?
[18:10] pombreda joined the chat room.
[18:10] cctrieloff: looks like we just did
[18:11] mdelder: I think that's fine; I think we all need to see the
proposal before we can continue
[18:11] mdelder: the discussion
[18:11] cctrieloff: agree
[18:11] mdelder: Thanks guys
[18:11] oisin: ok - thank you all for attending today, I will be
posting mins to the dev list and look forward to further discussions
there.
