(08:30:32 AM) Mike_Edwards: Hello
(08:30:38 AM) ant_: hi there
(08:30:50 AM) rfeng: hi
(08:30:54 AM) jsdelfino: hi
(08:31:25 AM) ant_: cr22rc? jboynes?
(08:31:44 AM) cr22rc: hello
(08:32:39 AM) ant_: shall we start or wait a bit longer to see if
jboynes or jmarino turn up?
(08:33:03 AM) jmarino [EMAIL PROTECTED] entered the room.
(08:33:09 AM) jsdelfino: hi jim
(08:33:12 AM) jmarino: hi
(08:33:19 AM) jmarino: ssh works :)
(08:33:22 AM) jsdelfino: cool
(08:34:00 AM) jsdelfino: agenda for today: I was thinking about 2 things.
(08:34:04 AM) jsdelfino: 1. distribution build
(08:34:12 AM) jsdelfino: 2. hot jira issues
(08:34:30 AM) jsdelfino: anything else?
(08:34:41 AM) dkulp [EMAIL PROTECTED] entered the room.
(08:34:48 AM) jsdelfino: hi dan
(08:34:56 AM) dkulp: Good morning.
(08:35:33 AM) jsdelfino: I'm proposing and agenda for today's chat:
distribution build, then hot jira issues
(08:35:47 AM) dkulp: OK. I'm adding a jira issue.
(08:35:53 AM) jsdelfino: anything else, please speak up
(08:36:04 AM) dkulp: We're releasing 1.0 of Celtix today (if ObjectWeb's
servers ever come back)
(08:36:29 AM) jsdelfino: ok
(08:36:33 AM) ant_: dist build is assigned to jboynes, so don't we need
him here to talk about it
(08:36:41 AM) jsdelfino: yes
(08:36:45 AM) paulfremantle [EMAIL PROTECTED]
entered the room.
(08:36:46 AM) jsdelfino: jboynes, are u here?
(08:36:51 AM) ant_: hi paul!
(08:37:02 AM) jboynes: jsdelfino, kind of
(08:37:11 AM) ant_: oh, the other thing was the groovy container
(08:37:16 AM) paulfremantle: hi
(08:37:26 AM) jsdelfino: ok item number 3 == groovy then
(08:37:29 AM) jsdelfino: hi paul
(08:37:57 AM) ant_: how about doing 3. first
(08:38:52 AM) ant_: it probbaly doesn't have as much the test coverage
as some would like. so where can we put it?
(08:39:45 AM) ant_: (for those that don't know, someone submitted a
patch for a new container to run groovy scripts)
(08:39:56 AM) jsdelfino: ant_, is there a maven build for it?
(08:39:57 AM) paulfremantle: pretty cool
(08:40:11 AM) ant_: jsdelfino, no i don't think so
(08:40:24 AM) jsdelfino: can u give us a quick summary of what it
contains? any big limitations? any samples?
(08:40:40 AM) ant_: there's a helloworld type sample yes
(08:40:43 AM) ant_: not much else
(08:40:47 AM) isilval [EMAIL PROTECTED] entered
the room.
(08:40:59 AM) ant_: doesn't support properties or references
(08:41:12 AM) jsdelfino: ok, we could put it in the sandbox for now,
under sandbox/groovy
(08:41:14 AM) Mike_Edwards: hmm, pretty basic in that case
(08:41:37 AM) jsdelfino: so that people can take a look
(08:41:45 AM) ant_: yes but its a start and if we show interest it may
get developed further
(08:42:05 AM) ant_: the javascript one was fairly simplistic to start
with as well
(08:42:06 AM) Mike_Edwards: sure, that's fair
(08:42:13 AM) dkulp: I think it should be treated same as Celtix:
sandbox until tests and builds work.... then migrate to trunk.
(08:42:29 AM) jsdelfino: yes exactly, +1 from me
(08:42:35 AM) ant_: ok, +1
(08:42:41 AM) dkulp: +1
(08:43:16 AM) jsdelfino: ok then if there's no objection, that's what
we'll do, the jira is assigned to me now, I'll check it in
(08:43:30 AM) ant_: while celtix was in the sandbox we tried to keep it
inline with refactors so can we do the same with groovy?
(08:43:37 AM) jsdelfino: under sandbox/container.groovy
(08:43:48 AM) jsdelfino: next item?
(08:44:02 AM) jsdelfino: our distribution build
(08:44:22 AM) jsdelfino: we had a proposal on the dev list which seemed
reasonable
(08:45:03 AM) rfeng: Does it define the folder structure?
(08:45:25 AM) jsdelfino: not in details
(08:45:49 AM) jsdelfino: the jira to set up the distribution build is
assigned to jeremy, who is also our maven expert
(08:45:54 AM) rfeng: It's easy to get all dependency jars collected for
a given module, but not sure how we are going to present the whole thing
(08:46:12 AM) jsdelfino: jboynes, can you give us an update on where you
are with the distro build?
(08:46:13 AM) ant_: anyone have the link to the proposal email?
(08:47:17 AM) jsdelfino: http://issues.apache.org/jira/browse/TUSCANY-282
(08:47:22 AM) jsdelfino: link is in there
(08:47:26 AM) ant_: thx
(08:48:50 AM) jsdelfino: if I understand the proposal correctly:
(08:49:00 AM) jsdelfino: 1 binary download
(08:49:13 AM) jsdelfino: with a pre-configured tomcat embedded in it
(08:49:29 AM) jsdelfino: 1 download for each technology sample set
(08:49:37 AM) jsdelfino: 1 download for the bigbank scenario
(08:50:13 AM) jsdelfino: the samples and scenarios only contain source
and instructions and/or scripts to build them
(08:50:34 AM) jsdelfino: jboynes, rick, is that it?
(08:50:53 AM) ant_: so no samples in the pre-conf binary download?
(08:51:02 AM) cr22rc: about what I remembered
(08:51:15 AM) jsdelfino: that's the proposal, ant, I have the same
question as you
(08:51:18 AM) jmarino: that was my understanding
(08:51:18 AM) rfeng: why 3 packages? can we do 1?
(08:51:20 AM) cr22rc: right... maybe a very basic smoke test
(08:52:30 AM) jsdelfino: maybe we can simplify and have just one
package, with the samples pre-installed?
(08:52:38 AM) jmarino: no I don't like that
(08:52:42 AM) ant_: thats what i was thinking
(08:52:54 AM) jsdelfino: the user experience would be, download, run the
samples, look at the source
(08:52:56 AM) Mike_Edwards: what's the problem with pre-installed samp,es?
(08:53:02 AM) cr22rc: actually it could be as much as 6 core source,
core binary, bigbank, sca_samples, sdo_samples, das_samples
(08:53:03 AM) jmarino: we could have one distro with all in but we need
a separate binary dowlnaod for the core
(08:53:14 AM) jsdelfino: why?
(08:53:23 AM) jsdelfino: who needs that?
(08:53:25 AM) jmarino: because people may not want the samples
(08:53:35 AM) jmarino: for example I would do that if I were embedding
(08:53:44 AM) Mike_Edwards: Well they can just throw them away...
(08:53:51 AM) ant_: its only an M1 release, and they;re easy to remove
(08:53:56 AM) jsdelfino: what does tomcat do for example?
(08:54:10 AM) jmarino: Tomcat I believe has separate samples
(08:54:22 AM) cr22rc: so that would be pretty much testing/tomcat
(08:54:28 AM) jmarino: Eclipse I believe is separate as well right?
(08:54:31 AM) dkulp: Right, but tomcat has a longer history and not just
one week before it has to be released.
(08:54:32 AM) jsdelfino: you believe or you're sure?
(08:54:52 AM) jmarino: I beleive. I don't really care though. Package as
you want
(08:55:14 AM) dkulp: Also, I think "embedders" should be encouraged to
use maven and get the artifacts they wan that way. (IMO)
(08:55:15 AM) ant_: looking in the dir of our testing/tomcat there's
jsp-examples and servlets-examples
(08:55:27 AM) ant_: pre installed
(08:55:48 AM) jsdelfino: jmarino, I'm just looking for the simplest
option at this point :)
(08:55:49 AM) jmarino: that's stuff that comes with tomcat
(08:56:11 AM) jmarino: yea liek I said I don't really care
(08:56:18 AM) jmarino: package however you want
(08:56:38 AM) ant_: jmarino's right, lets just get something, is anyone
actually working on making the distribution
(08:57:17 AM) cr22rc: if it's just one that its adding a few more lines
to testing\tomcat\build.xml
(08:57:43 AM) jsdelfino: before we get into the "how" we do it, can we
get some consensus on what it's gonna look like?
(08:58:12 AM) jsdelfino: let's see who would like 1 package with the
samples or multiple packages
(08:58:35 AM) jsdelfino: can u guys speak up, we do a quick poll and
move on?
(08:58:43 AM) rfeng: 1 pkg for me
(08:58:55 AM) ant_: for this M1 i prefer including the samples but if
anyones feels strongly that they should be seperate i'm fine with that
(08:58:57 AM) jmarino: i think this should be for m1 only. later we need
to work out a more adequate package story
(08:59:09 AM) ant_: jmarino, +1
(08:59:21 AM) jsdelfino: 1 pkg for me as well
(08:59:23 AM) jmarino: more like -0
(08:59:34 AM) Mike_Edwards: +1
(08:59:40 AM) dkulp: +0 for me, I prefer a single package, but it
doesn't really matter.
(08:59:49 AM) cr22rc: 0
(08:59:57 AM) jboynes: -0 but someone else does it
(08:59:58 AM) jsdelfino: k, if there's no strong objection we'll go with
one package then
(09:00:31 AM) jsdelfino: so looks like we're getting into the how and
who already :) I have another quick question first...
(09:00:42 AM) jboynes: I have to go - bye
(09:01:00 AM) ant_: LOL
(09:01:25 AM) jsdelfino: I am assuming that the package will include, in
addition to a configured tomcat, a directory with the jars required for
running in a j2se environment
(09:01:31 AM) jsdelfino: does that make sense?
(09:01:55 AM) ant_: yes
(09:02:00 AM) dkulp: Q: what about Celtix?
(09:02:03 AM) cr22rc: yup testing/tomcat/build.xml has that
(09:02:15 AM) dkulp: Should there be a "j2se-celtix" dir for running the
celtix version stuff?
(09:02:22 AM) rfeng: for the jars, I have a question
(09:02:38 AM) ant_: dkulp, ok
(09:03:05 AM) rfeng: we now partition things by module, how do we want
to present all the jars for all the modules?
(09:03:08 AM) kg [EMAIL PROTECTED] entered the room.
(09:03:24 AM) kg is now known as kgoodson
(09:04:03 AM) ant_: for J2SE we need everytihng in a single flat
directory to make it easy to add to java as an EXT dir right?
(09:04:20 AM) dkulp: Either that or a manifest jar.
(09:04:28 AM) rfeng: ok
(09:04:49 AM) ant_: dkupl, can you explain?
(09:05:10 AM) rfeng: setting the classpath in MANIFEST.MF?
(09:05:15 AM) dkulp: Right.
(09:05:29 AM) dkulp: Thus, it's just a single jar on the classpath. We
use it for celtix.
(09:06:15 AM) rfeng: for m1, maybe a flat dir is simpler :-)
(09:06:49 AM) dkulp: Agreed.
(09:06:59 AM) dkulp: Although maven can do it for you..... :-)
(09:07:41 AM) rfeng: some developers don't understand MANIFEST.MF very
well, make it low-bar for now
(09:09:32 AM) dkulp: For M1, I would say flat dirs. There will be some
duplication between the j2se and j2se-celtix stuff (and tomcat).
(09:09:48 AM) dkulp: We can sort some of that out for M2.
(09:10:10 AM) ant_: +1
(09:10:54 AM) cr22rc_ [EMAIL PROTECTED] entered
the room.
(09:11:15 AM) jsdelfino: sorry I got distracted
(09:11:20 AM) jsdelfino: back now
(09:12:17 AM) jsdelfino: +1 from me, a flat dir for M1
(09:12:39 AM) jsdelfino: dan had a question on celtix I believe
(09:13:20 AM) jsdelfino: how do we package the celtix binding?
(09:15:24 AM) dkulp: I think just another directory (like j2se-celtix)
(09:15:37 AM) dkulp: It would contain all the stuff needed for celtix
(serverside and client side)
(09:16:07 AM) dkulp: Most of that is already in the tomcat/build.xml
(09:19:15 AM) jsdelfino: ok, so we'll have a j2se-celtix directory?
(09:19:18 AM) jsdelfino: +1 from me
(09:20:44 AM) ant_: +1from me (again)
(09:20:50 AM) cr22rc_: I got disc so maybe i missed ... any config need
in TC for celtix ?
(09:20:53 AM) Mike_Edwards: why J2SE-celtix, btw ?
(09:21:30 AM) dkulp: I actually think maybe "tuscany-celtix" instead of j2se
(09:22:32 AM) ant_: i have to go in 10 minutes sorry. Can i have a quick
question to jmarino about the extension APIs in
http://issues.apache.org/jira/browse/TUSCANY-329?
(09:23:17 AM) jmarino: yes?
(09:23:20 AM) ant_: are the ones you're talking about just the ones in
org.apache.tuscany.core.extension or are there others somewhere?
(09:24:04 AM) jmarino: core extensions but yes I am working on
improvements to the extension api elsewhere so as not to disrupt m1
(09:24:53 AM) ant_: so you don't plan on chnaging whats there at the
moment for M1? Its just tidying up the javascript container i'm
duplicating a lot of code from the java container
(09:25:42 AM) jmarino: I'm happy to discuss changing what's there but
that is not what I'd prefer
(09:26:34 AM) ant_: wasn't part of M1 supposed to be a easy and stable
extension API?
(09:27:12 AM) jmarino: I think it is "easy" but we need it easier. Yes
it will be "stable" but it will also evolve, particularly to account for
spec changes
(09:28:09 AM) ant_: ok, but right now a implementing a container
requires things like ContextFactory, ComponentContext, and TargetInvoker
which require a lot of tuscany specific code
(09:28:35 AM) jmarino: I think the extension API will always require
Tuscany code until there is an SCA spec on it
(09:28:50 AM) Mike_Edwards: Yeah - we need to start some work on that
spec, Jim
(09:28:53 AM) jmarino: we'll also always require a TargetInvoker or
something similar
(09:28:56 AM) jmarino: yes :)
(09:28:57 AM) Mike_Edwards: I'll email the collab about it
(09:29:03 AM) jsdelfino: ok, can we close the discussion on the
distribution?
(09:29:27 AM) ant_: yes but can't there be support classes in core fore
this just like for the othr support clasess in the core extensions pkg?
(09:30:02 AM) jmarino: there are support classes already right?
(09:30:29 AM) ant_: yes, some, but it doesn't appear a complete set yet
(09:30:31 AM) cr22rc left the room (quit: Read error: 110 (Connection
timed out)).
(09:30:52 AM) jmarino: that is related to some of the changes I'm making now
(09:31:05 AM) jmarino: it will be simpler but it will require a spec change
(09:31:49 AM) ant_: but for M1 would could add some more support classes
ot make it easier
(09:32:18 AM) jmarino: sure - can you post to the list and we can
discuss? I don't think we need to go into detail here
(09:32:51 AM) ant_: well thats what JIRA 329 is for and assigned to you :)
(09:33:18 AM) ant_: i'm just tryingto find if it will actually happen
for M1 or if i need to go write them myself for the javascript container
(09:33:45 AM) jsdelfino: ok, here's what I suggest for M1, I think we
should have an extremely simple sample container or binding extension
(nothing complicated in terms of the container and binding
implementation itself), and have people on the team review it, and raise
JIRAs for any issues, if any.
(09:34:21 AM) jsdelfino: does that make sense?
(09:34:24 AM) ant_: javascript and jsonrpc will be those if TUSCANY-329
is resolved
(09:34:43 AM) jmarino: what do you mean by "resolved"?
(09:34:58 AM) ant_: support classes provided for ContextFactory,
ComponentContext, and TargetInvoker
(09:35:36 AM) jmarino: context factory is pretty simple we can look at
it again but I don't think too much can be done there
(09:35:42 AM) jmarino: didin't you do TargetInvoker?
(09:36:05 AM) jsdelfino: ant_, ok I didn't realize you had just created
the JIRA issue already :)
(09:36:44 AM) ant_: i did an externalservicetargetinvoker but components
also need one which is almost identical
(09:36:50 AM) ant_: i have to go sorry
(09:36:52 AM) ant_: bye
(09:36:57 AM) ant_ is now known as ant_away
(09:36:57 AM) jsdelfino: k, no problem
(09:37:09 AM) jsdelfino: can we close the distribution question?
(09:37:31 AM) jsdelfino: here's what I understood:
(09:37:43 AM) jsdelfino: one dir containing the JARs for use in J2SE
(09:38:17 AM) jsdelfino: another dir containing the JARs for use in
J2SE, when Celtix is used
(09:39:18 AM) jsdelfino: I was thinking about tuscany-lib,
tuscany-lib-celtix, do u guys like that?
(09:39:40 AM) kgoodson is now known as kgoodson_away
(09:40:39 AM) jsdelfino: can u say something :) IRC does not transcript
nods, smiles, or frowns
(09:41:05 AM) dkulp: +1
(09:41:05 AM) cr22rc_: the intersection of those can be zero right? you
can have more than one directory for extdirs
(09:41:24 AM) jsdelfino: ah good point...
(09:41:34 AM) dkulp: Then you would need three, tuscany-lib,
tuscany-lib-axis2, tuscany-lib-celtix
(09:41:52 AM) jsdelfino: yes! that would be better I think
(09:42:02 AM) dkulp: Or: tuscany-lib, tuscany-lib/axis2,
tuscany-lib/celtix
(09:42:11 AM) dkulp: (subdirs in tuscany-lib)
(09:42:34 AM) jsdelfino: makes sense, then we need subdirs as well for
rhino and jsonrpc
(09:42:39 AM) Mike_Edwards: where will javascript etc go?
(09:42:49 AM) dkulp: Just in tuscany-lib.
(09:43:00 AM) dkulp: The only things that cannot-coexist are the axis2
and celtix things.
(09:43:07 AM) jsdelfino: or tuscany-rhino
(09:43:50 AM) cr22rc_: and then tuscany-groovy ... this could get crazy
(09:43:59 AM) jsdelfino: I have an updated proposal then... tuscany-lib,
tuscany-lib/axis2, tuscany-lib/celtix, tuscany-lib/rhino, etc...
(09:44:07 AM) jsdelfino: we're not gonna have the groovy container in
this release
(09:44:13 AM) jsdelfino: yes
(09:44:15 AM) jsdelfino: yet
(09:44:28 AM) jsdelfino: but why are you saying it's crazy?
(09:44:51 AM) cr22rc_: seems as time goes on there could be huge number
(09:44:54 AM) dkulp: You end up with "classpath hell", just with ext
dirs intead of actual classpaths.
(09:44:56 AM) jsdelfino: I think it's simple, not confusing, you just
pick the pieces you need on your classpath
(09:45:29 AM) Mike_Edwards: need a straightforward way of packaging
extensions
(09:45:47 AM) jsdelfino: it'll be hell only if we have too many of
these, how many people will mix all of these in one app?
(09:46:08 AM) cr22rc_: do we test the combos ?
(09:46:21 AM) Mike_Edwards: They may well mix a few impl types and
binding types
(09:46:28 AM) Mike_Edwards: in the future
(09:47:15 AM) paulfremantle left the room.
(09:47:48 AM) jsdelfino: ok... we have 2 trends here:
(09:48:13 AM) jsdelfino: a) everything in one dir, except for
celtix/axis which are incompatible
(09:48:24 AM) jsdelfino: b) one dir per optional package
(09:48:51 AM) jsdelfino: b) means we just have the javascript and
jsonrpc in their own dir
(09:48:58 AM) jsdelfino: we could call this dir ajax :)
(09:49:18 AM) jsdelfino: so t-lib, t-lib/axis2, t-lib/celtix, t-lib/ajax
(09:49:34 AM) cr22rc_: I prefer A... just seems simplier
(09:50:02 AM) dkulp: For M1, I would say A as well. Revist "component
packaging strategy" after javaone.
(09:50:03 AM) jsdelfino: a) == t-lib, t-lib/axis2, t-lib/celtix right?
(09:50:15 AM) cr22rc_: may rethink later
(09:50:43 AM) cr22rc_: ok by me
(09:50:55 AM) Mike_Edwards: ok, fine for now
(09:51:27 AM) jsdelfino: last question then: a == t-lib + t-lib/axis2 +
t-lib/celtix or a' == t-lib, t-lib/celtix
(09:51:46 AM) jsdelfino: dan, do u need axis2 out of the core so u can
exclude it?
(09:52:08 AM) dkulp: Yes. Needs to be out or the core loads the axis2
stuff in addition to celtix, which then confuses things.
(09:52:18 AM) dkulp: (exception thrown as binding.ws is already registered)
(09:52:23 AM) jsdelfino: k
(09:52:26 AM) dkulp: Something about a duplicate name.
(09:52:51 AM) rfeng left the room (quit: Read error: 104 (Connection
reset by peer)).
(09:53:48 AM) Mike_Edwards: Need to be sure that users get one WS
binding by default, I think
(09:54:35 AM) jsdelfino: would you guys be opposed to t-lib,
t-lib/axis2, t-lib/celtix, t-lib/ajax? it feels odd to see axis2 and
celtix look like options, but have jsonrpc and rhino integrated in the
core lib...
(09:54:41 AM) rfeng [EMAIL PROTECTED]
entered the room.
(09:55:53 AM) cr22rc_: -0
(09:56:10 AM) jsdelfino: any other votes? I'm fine if u all say -1 :)
(09:56:44 AM) dkulp: -0 for me too.
(09:57:27 AM) jsdelfino: ok, doesn't look like a good consensus, so
let's keep t-lib, t-lib/axis2, t-lib/celtix then
(09:57:36 AM) jsdelfino: next:
(09:58:02 AM) jsdelfino: how are we going to build this distro and who's
gonna do it?
(09:58:44 AM) cr22rc_: not everyone volunteer at once now
(09:58:56 AM) rfeng: I tried a bit and can get all jars collected by modules
(09:59:05 AM) jsdelfino: with maven?
(09:59:12 AM) rfeng: but a committer is better to handle this
(09:59:12 AM) rfeng: yes
(10:00:14 AM) jsdelfino: I guess we need to do something similar to what
testing/tomcat does, but I'd prefer to see this more maven based
(10:00:21 AM) cr22rc_: I just don't see how maven can sort those
directories out and copy samples/ source etc etc ...
(10:00:46 AM) jsdelfino: to get the dependency jars from the maven
dependencies instead of having them hardcoded in an ant script
(10:01:11 AM) cr22rc_: I agree would be nice
(10:01:11 AM) rfeng: we may need to create a dummy module which depends
on all other modules, so it get all jars collected :-)
(10:01:24 AM) jsdelfino: rick, I don't see it either, but it doesn't
mean that it's not possible, it probably means that I don't know maven
enough
(10:01:35 AM) cr22rc_: same
(10:01:48 AM) cr22rc_: and I don't think I will have that by m1
(10:02:34 AM) dkulp: The SNAPSHOT version of the dependency plubin would
help, but that won't be released this week.
(10:02:53 AM) cr22rc_: do we check in TC ?
(10:03:08 AM) jsdelfino: you mean check into our SVN?
(10:03:13 AM) cr22rc_: we need to modify it's config
(10:03:15 AM) cr22rc_: yes
(10:03:32 AM) cr22rc_: just check in the config files?
(10:03:41 AM) jsdelfino: no it's not checked in, but is that a problem?
(10:03:59 AM) cr22rc_: asking if we should
(10:05:20 AM) jsdelfino: I think it would be better to download it as
part of the distro build, instead of checking in a complete product
install in our SVN
(10:08:00 AM) Mike_Edwards: I'm not sure I understand what that means
(10:09:00 AM) cr22rc_: download := maven download from a maven repo?
(10:09:58 AM) dkulp: I don't think the full tomcat is available in a
maven repo, is it?
(10:10:40 AM) cr22rc_: I think they have jars... but not all the config
stuff
(10:10:42 AM) cr22rc_: afaik
(10:13:12 AM) jsdelfino: download from the apache-tomcat site?
(10:14:05 AM) jsdelfino:
http://www.ibiblio.org/pub/mirrors/apache/tomcat/tomcat-5/v5.5.16/bin/apache-tomcat-5.5.16.zip
(10:14:26 AM) rfeng: are we looking into the possibility to download
tomcat on the flight?
(10:14:41 AM) cr22rc_: or manual like what testing/tomcat does ...
(10:15:20 AM) jsdelfino: I'm ok with a manual download, but I was
wondering if it was really complicated to do an ftp or http download
from a build...
(10:16:04 AM) cr22rc_: http://ant.apache.org/manual/OptionalTasks/ftp.html
(10:16:43 AM) jsdelfino: I think we need to be able to automate this build
(10:16:51 AM) jsdelfino: that's why I'm asking
(10:19:21 AM) jsdelfino: rfeng, do u think you could integrate the
collection of jars using maven and a variation of the
testing/tomcat/build.xml to produce the distribution
(10:19:35 AM) rfeng: yes, I'll give a try
(10:19:41 AM) jsdelfino: I don't think we want to use testing/tomcat
as-is, this is a test build, not a distro build
(10:19:52 AM) rfeng: sure
(10:20:39 AM) cr22rc_: I agree not use as is
(10:21:00 AM) rfeng: I assume it's high priority?
(10:21:25 AM) jsdelfino: yes very high :) higher than any other jira
issue...
(10:21:41 AM) rfeng: ok
(10:22:06 AM) rfeng: the build is broken :-)
(10:22:22 AM) jsdelfino: oops, what's wrong with it?
(10:22:39 AM) rfeng: the SDO code-gen requires some JDT classes
(10:23:38 AM) rfeng: java.lang.NoClassDefFoundError:
org.eclipse.jdt.core.formatter.CodeFormatter
(10:23:38 AM) rfeng: at
java.lang.J9VMInternals.verifyImpl(Native Method)
(10:23:38 AM) rfeng: at
java.lang.J9VMInternals.verify(J9VMInternals.java:55)
(10:23:38 AM) rfeng: at
java.lang.J9VMInternals.verify(J9VMInternals.java:53)
(10:23:38 AM) rfeng: at
java.lang.J9VMInternals.verify(J9VMInternals.java:53)
(10:23:39 AM) rfeng: at
java.lang.J9VMInternals.initialize(J9VMInternals.java:124)
(10:23:41 AM) rfeng: at
org.eclipse.emf.codegen.ecore.genmodel.generator.GenModelGeneratorAda
(10:23:43 AM) rfeng:
pterFactory.createGenModelAdapter(GenModelGeneratorAdapterFactory.java:73)
(10:24:12 AM) jsdelfino: ah ok, just saw on the dev list, looks like the
SDO guys are working on it...
(10:25:01 AM) jsdelfino: if we're done with the distro build discussion,
can we spend a few minutes on some critical JIRA issues?
(10:26:28 AM) jsdelfino: I opened a number of jiras on "in your face"
bugs that I found yesterday
(10:26:44 AM) jsdelfino: the numbers are 319 to 326
(10:27:06 AM) jsdelfino: jmarino, are u there? these are in the core
and/or java container areas
(10:27:51 AM) jmarino: wait there were two that I saw:
(10:27:58 AM) jmarino: @Property and @Reference
(10:28:04 AM) jmarino: @Reference I commented on
(10:28:16 AM) jmarino: @Property I have a fix but am having difficulty
checking in
(10:28:16 AM) jsdelfino: can we go by numbers, it's going to be easier
(10:28:23 AM) jmarino: I have to look them up
(10:28:43 AM) jsdelfino: otherwise we'll end up talking about the first
issue, the second about ref, and this other one about properties etc,
could be confusing :)
(10:28:55 AM) jmarino: yea 324 and 325
(10:29:17 AM) jsdelfino: what about the first one?
http://issues.apache.org/jira/browse/TUSCANY-319
(10:29:56 AM) jsdelfino: <import.sdo> doesn't take an xsd, it only has a
wsdlLocation attribute...
(10:30:12 AM) jmarino: that doesn't look like mine. Maybe Jeremy?
(10:30:50 AM) jsdelfino: ok then, next:
(10:31:07 AM) jsdelfino: http://issues.apache.org/jira/browse/TUSCANY-320
(10:31:25 AM) jsdelfino: ModuleContext.getURI() does not work
(10:31:43 AM) jsdelfino: should be an easy fix
(10:31:51 AM) jmarino: can you do it then?
(10:32:33 AM) jsdelfino: I'm overloaded, samples, packaging, checking
everything for the release, more web services test cases...
(10:32:41 AM) jmarino: fine
(10:32:41 AM) jsdelfino: you don't have time to do it?
(10:32:51 AM) jsdelfino: ok
(10:32:51 AM) jmarino: so am I but I'll do it
(10:33:14 AM) jsdelfino: next:
http://issues.apache.org/jira/browse/TUSCANY-321
(10:33:27 AM) jsdelfino: simple POJO, no annotations
(10:33:39 AM) jsdelfino: references do not work
(10:34:24 AM) jmarino: no that's by design and spec ambiguity per my
comment on 325
(10:34:59 AM) jmarino: there's no way on component info to specify that
something "may be" a property or reference
(10:35:16 AM) jsdelfino: I didn't understand your comment on 325 btw,
why is this by-design, are we saying that it's not possible to use a
POJO without annotations? it used to worked a few weeks ago
(10:35:41 AM) jmarino: with @Reference no. With @Property yes
(10:35:57 AM) jmarino: there's no way to represent that in the component
type
(10:36:09 AM) jmarino: I have a longer term fix to this...
(10:36:20 AM) jmarino: working on now but it will involve changing
component type
(10:36:36 AM) jmarino: I suggest for M1 we require @Reference to be
specified and release note it
(10:37:10 AM) jsdelfino: ok, I just need a clear picture, from a user's
point of view, so you're saying that a @Reference is required, but
@Property is not, correct?
(10:37:16 AM) jmarino: yea
(10:37:27 AM) jmarino: I default things that are "may be" to property
(10:37:53 AM) jsdelfino: you mentioned a spec issue, what's the spec
issue number?
(10:38:13 AM) jmarino: I don't have it logged
(10:38:26 AM) jsdelfino: what would the spec issue say?
(10:39:07 AM) jmarino: I think the spec needs to be clarified about what
happens with Java components re something that may be a property or
reference (I wrote it that part so it's kind of against me ;) )
(10:40:37 AM) jmarino: k next one?
(10:41:03 AM) jsdelfino: wait :) this should work with a .componentType
file right?
(10:41:17 AM) jmarino: yea if the component type is loaded
(10:41:39 AM) jmarino: I think we just say @Ref is temporarily required
(10:41:42 AM) dkulp: Yipee!!! My commit access now works. :-)
(10:41:43 AM) jmarino: it's something people can live with for now
(10:41:49 AM) jmarino: cool!
(10:42:57 AM) jsdelfino: ok, I'm gonna test with a componentType, if it
works with a componentType I'll move the issue to Mx, and we'll document
the workaround
(10:43:42 AM) jsdelfino: the reason why I need to test with a
componentType is that we need know if it's possible at all to use SCA
without annotations, let's say on an existing class
(10:43:58 AM) jsdelfino: dan, cool!
(10:44:11 AM) jsdelfino: waiting to see the celtix binding under the
main tree soon then :)
(10:44:16 AM) jsdelfino: next JIRA
(10:44:34 AM) jsdelfino: http://issues.apache.org/jira/browse/TUSCANY-322
(10:44:57 AM) jmarino: that's a simple fix....
(10:45:10 AM) jmarino: I'm trying to get the other 324 commited first...
(10:45:12 AM) jsdelfino: that's like what you did for references before
(10:45:16 AM) jmarino: having problems with my machine
(10:45:19 AM) jmarino: yes exactly
(10:45:25 AM) jsdelfino: sure, 324 first, but you'll fix 322 right?
(10:45:27 AM) jmarino: an ugly temp fix but it will work
(10:45:28 AM) jmarino: yea
(10:45:34 AM) jsdelfino: ok cool
(10:45:36 AM) jsdelfino: next?
(10:45:40 AM) jmarino: should be a 2min thing
(10:45:52 AM) jsdelfino: http://issues.apache.org/jira/browse/TUSCANY-323
(10:46:21 AM) jmarino: that's not really mine right now. I may be able
to do something later but we could also release note it as a limitation
(10:46:28 AM) jmarino: later tomorrow
(10:47:04 AM) jsdelfino: I'm not sure I'm ready to say that our M1
release does not support wires... I'm not comfortable with that
(10:47:18 AM) jmarino: oh maybe I misread it
(10:47:36 AM) jsdelfino: <wires> are not supported
(10:47:42 AM) jsdelfino: that's basically what this means
(10:48:00 AM) jsdelfino: I think it looks pretty bad for an assembly
kind of programming model :)
(10:48:14 AM) jmarino: ah I thought it was another one...well that's not
an area I worked on by I could take a look starting tomorrow. No
guarantees though
(10:48:53 AM) jsdelfino: it's in the core area, but this is probably
more like a loader problem, maybe jboynes will be able to help
(10:49:37 AM) jsdelfino: sorry jim for giving you the whole JIRA tour
today, Ant got the whole stage for himself last time with the ws related
JIRA issues :)
(10:49:57 AM) jmarino: yea no
(10:49:59 AM) jmarino: np
(10:50:11 AM) jsdelfino: I have more ws test cases in the pipe, so maybe
tomorrow we'll focus back on ws again :)
(10:50:29 AM) jsdelfino: ok so 323 is gonna be either you or jboynes right?
(10:50:33 AM) jmarino: I think that's a great idea ;)
(10:50:39 AM) jmarino: yea
(10:50:39 AM) cr22rc [EMAIL PROTECTED] entered the
room.
(10:51:12 AM) jsdelfino: 324 you're gonna fix it right? just saw your
comment in the JIRA
(10:52:02 AM) jmarino: yea fixed it, need to get a checkin working
(10:52:07 AM) jsdelfino: cool, next:
http://issues.apache.org/jira/browse/TUSCANY-325
(10:52:17 AM) jsdelfino: I didn't understand your comment for this one
(10:53:05 AM) jsdelfino: I understand your comment within the context of
319, but not for 325
(10:53:09 AM) jmarino: ah jeez. That comment was for the other refence
issue. Crossed issues...
(10:53:17 AM) jmarino: this should work. What is the SCDL?
(10:53:26 AM) jsdelfino: here's the source code:
(10:53:28 AM) jsdelfino: private AddService addReference;
(10:53:28 AM) jsdelfino:
(10:53:28 AM) jsdelfino: @Reference
(10:53:28 AM) jsdelfino: public void setAddService(AddService
addService) {
(10:53:28 AM) jsdelfino: this.addReference = addService;
(10:53:28 AM) jsdelfino: }
(10:53:42 AM) jsdelfino: the SCDL is in the test case with the rest
(10:53:52 AM) jsdelfino: it declares reference addService
(10:54:12 AM) jmarino: that should work
(10:54:22 AM) jmarino: I think we need to verify it is a bug first
(10:54:23 AM) Mike_Edwards left the room (quit: Read error: 110
(Connection timed out)).
(10:55:10 AM) jsdelfino: this is a true statement for all JIRA issues
that get opened :)
(10:55:16 AM) jsdelfino: the test case is attached
(10:55:18 AM) jmarino: yea
(10:56:27 AM) jsdelfino: this is really a weird behavior, looks like the
code is trying to go directly to the private field, even though there's
a public setter with an annotation
(10:56:42 AM) jmarino: ah k I know what it is
(10:56:45 AM) jsdelfino: and fails to set the private field
(10:56:46 AM) jmarino: I'll take a look
(10:57:02 AM) jsdelfino: good that you know :) this one was puzzling me
yesterday :)
(10:57:17 AM) jmarino: oh wait ...
(10:57:20 AM) jmarino: yes this is interesting
(10:57:24 AM) jsdelfino: indeed
(10:57:33 AM) jmarino: hold on....
(10:58:47 AM) jmarino: I'll look at it my machine is slow. next one?
(10:59:32 AM) jsdelfino: 326
(10:59:47 AM) jsdelfino: http://issues.apache.org/jira/browse/TUSCANY-326
(10:59:56 AM) jsdelfino: wiring cross fragments does not work
(11:00:02 AM) jsdelfino: I attached a test case
(11:00:14 AM) jsdelfino: this makes fragments pretty unusable
(11:00:25 AM) jmarino: I wouldn't say that....
(11:00:35 AM) jmarino: I think it makes wiring between fragments unsuable
(11:00:56 AM) jmarino: again, not really something I've been involved in
but could look at if I free up tomorrow
(11:01:28 AM) zx|work left the room (quit: Read error: 110 (Connection
timed out)).
(11:01:33 AM) cr22rc_ left the room (quit: Read error: 110 (Connection
timed out)).
(11:01:33 AM) jsdelfino: right, but if you say that you're gonna use
fragments to reuse components, and then you say that you can't wire to
them, where does that leave me?
(11:01:44 AM) jsdelfino: :)
(11:01:56 AM) [1]zx [EMAIL PROTECTED] entered the room.
(11:02:06 AM) jmarino: well two different parts of a module could be in
two different fragments. Still some use there
(11:02:14 AM) jmarino: I think that's actually more common too
(11:02:26 AM) jsdelfino: I think this one is probably a mix of issues in
loader, model and runtime
(11:02:52 AM) jsdelfino: how do you know it's more common?
(11:03:04 AM) jmarino: yea. my guess is it's going to wind up in a rel note
(11:03:11 AM) jmarino: commited fix for 324 now
(11:03:20 AM) simonl left the room (quit: "Bye").
(11:03:25 AM) jsdelfino: I understand the scenario that works,
unrelated, unwired components in fragments
(11:04:22 AM) jmarino: k I've got to run soon. What others?
(11:04:49 AM) jsdelfino: I think 326 is important, let's see if somebody
else on the team can help in the next 2 days
(11:05:27 AM) jsdelfino: there's plenty of others :) but I'm done with
the ones I cared for today...
(11:05:56 AM) jmarino: k cool
(11:07:09 AM) jsdelfino: okay, anything else you guys want to discuss
before we close the IRC for today?
(11:07:16 AM) jsdelfino: I'll send the log to the dev list
(11:07:52 AM) jsdelfino: BTW we have a [email protected] list now
(11:08:30 AM) jsdelfino: thank you all
--
Jean-Sebastien
