Here's the IRC log from yesterdays scheduled chat. The main things talked about were:
- various problems with implementing extensions such as the Axis2 binding. - how to handle extension dependencies. Suggestion were for a new dependency element in the scdl, having an ArtifactRepository and an impl of that using maven repos, and a suggestion of web app style .sar or .scab files (I'll send a separate mail about that) - -Psourcecheck came up, most didn't want it required before commits - how to use JIRAs more effectively was discussed, we should try to use them more to track what we're working on ...ant * Now talking in #tuscany * sykesm has joined #tuscany * Looking up sykesm user info... * dkulp has joined #tuscany * lresende has joined #tuscany * bhdaniel has joined #tuscany * jsdelfino has joined #tuscany * bertlamb has quit IRC (Read error: 104 (Connection reset by peer)) * kgoodson has joined #Tuscany * kgoodson has quit IRC (Client Quit) * kgoodson has joined #Tuscany * kgoodson_away has left #Tuscany <ant> Hi guys * dwheeler has joined #tuscany <kgoodson> hi <jboynes> howdy <lresende> hi <dwheeler> hi <cr22rc> hi * jervisliu has joined #tuscany * jervisliu has left #tuscany <ant> So i'd suggestted talking about writing extensions, but with Jim not here maybe that wont work <jboynes> given the recent changes to all the wiring that's probably true * jervisliu has joined #tuscany <jboynes> we can talk general things though if there are high level questions <cr22rc> I posted a message about loading a reference directly .. if that should work <jboynes> it should <jboynes> I didn't really understand the question * Venkat has joined #tuscany <cr22rc> I now altered the sampe to load a java component that references the binding.. but have run in that my axis binding builder get loaded but no build method gets called. <jervisliu> i think the problem for axis2 binding is that there still some parts not implemented yet <jervisliu> we used to have a class called TomcatHost or sth like that * kevin__ has joined #tuscany <cr22rc> wasn't that on the server? <jboynes> that was only used for the service side <jboynes> references should not need it <jervisliu> which is used to boot strap servlet container, register axis2 servlet etct. but we dont have equal class at the moment <jboynes> I think that is why cr22rc was starting with references <jervisliu> oh, yes, thats only for service, for the server side <Venkat> has the SystemCompositeBuilder a role to play here... <Venkat> in that I see that there are components and services added... but not references <jboynes> that could be <jervisliu> also the question Venkat asked last week, how to setup inboundWire, i didnt see the answer yet. <jboynes> Venkat: but the CompositeBuilder does <jboynes> and we should be building an application composite here <cr22rc> here is a high level question ... what to do about extension dependencies jars <jboynes> :-) <jboynes> there's a higher level question: what to do about dependency jars in genera <jboynes> in general <jboynes> e.g. if I deploy a bare XML file, where do implementation artifacts come from? <cr22rc> right now spliting them to the boot directory and the extension jar in the extension directory kinda breaks the distribution/asembly that puts them together <jboynes> yes they should not be in the boot directory <jboynes> that should just contain the stuff needed to boot the runtime <jboynes> i was thinking of using the dependency information maven adds to the jar <jboynes> so we can read the maven metadata, find the dependencies and add them to the classpath from a maven repo <cr22rc> are we then commiting extension developers to using maven ? or until some other tooling does that too? <jboynes> I would say we are /enabling/ developers to use maven <jboynes> and not just extensions, application composites as well <jboynes> just like we allow people to use Class-Path jars as well <jboynes> (from the manifest) <jboynes> I think Jim has some ideas here on supporting OSGi dependencies as well <jboynes> I'd also suggested supporting a <dependencies> element in the SCDL as well <jboynes> for those cases where you did not have a jar file <cr22rc> our loader would handle that .. right? <jboynes> between the loader and the composite builder yes <Venkat> Jboynes: I do not find any wire creation in CompositeBuilder <Venkat> ok... lets take that later.. carry on with dependecies <jboynes> yeah - that's better directed at jmarino anyway <cr22rc> if in the scdl ... where phyically would it be looked for ? <jboynes> not sure what you mean <cr22rc> well mabye I need to see more details of it would be specified in the scdl <jboynes> maybe, but I don't understand the question you were asking <Venkat> and we are talking about scdls that define extension as well as those that are application assemblies .. right <jboynes> yes (I think they should be the same) <jboynes> cr22rc: do you mean, where physically would I get a dependency jar from? <cr22rc> yes <jboynes> ok <jboynes> like this ... <cr22rc> are you thinking the local repo? <jboynes> you specify dependency info in the scdl <jboynes> that is actually independent of the way the runtime locates the artifact <jboynes> you just declare what you need (name, version, type etc.) <jboynes> the loader converts that to an Artifact description <jboynes> and calls an ArtifactRepository to get physical URLs for it <jboynes> one implementation of ArtifactRepository is based on Maven and resolves using Maven repos <jboynes> the most basic form just looks for the artifact in your local repo cache (~/.m2/repository) <jboynes> more sophisticated implementations may also fetch artifacts from remote maven repos <Venkat> jboynes: are we saying that maven repos will be the most natural env. for developers.. <jboynes> no <Venkat> can a developer thrive here with no knowledge of maven or maven repos <Venkat> what will be the options in that case <jboynes> this is one solution - there could be others * halehM has joined #tuscany <jboynes> hence the abstraction behind ArtifactReposiotry <jboynes> I think jmarino had ideas based on OSGi <Venkat> isn't this something that should also feed back into the specs... <jboynes> yes <jboynes> given the amount of open source stuff published to maven repos then this seems like a good thing to do anyway * jliu has quit IRC (Read error: 104 (Connection reset by peer)) <jboynes> agreed? <Venkat> am not sure how the ArtifactRepository is going to be designed... but expect that having Maven should not influence its abstraction <Venkat> meaning... working its design bottom up from Maven <jboynes> I posted a proposal to the list a while ago <jboynes> Jim seemed to think it would work for both maven and osgi <cr22rc> maybe we should review and come back to this .. have a url? <jboynes> if you can think of other features the abstraction needs that input would be valuable <Venkat> jboynes: could you please help with a pointer to that thread <cr22rc> BTW shouldn't we be putting these things in Jira? I'm mean once we start getting serious doing someting about it? <jboynes> https://svn.apache.org/repos/asf/incubator/tuscany/java/sca/spi/src/main/java/org/apache/tuscany/spi/services/artifact <cr22rc> Jira's are for featurs too AFAIK <jboynes> so anyway, if we continue with this <jboynes> then the dependencies for a extension would be fetched from the artifact repo <jboynes> with the dependencies being declared either in the composite's scdl, in maven metadata in the jar, or through some osgi bundle resolution mechanism <jboynes> cr22rc, does that solve your original problem <jboynes> ? <cr22rc> probably... the devil is in the details and will it be checked in tonight :-) * robbinspg has joined #tuscany <jboynes> what will be checked in? <cr22rc> this solution <jboynes> sorry, read "it will" instead of "will it" :-) <jboynes> I think I can add support for <dependency> elements by then sure <cr22rc> :-) <jboynes> using the maven metadata might take a bit longer <jboynes> (need to parse the pom that is inside the jar - I would want to reuse maven's own functions for that) <jboynes> (as in, I don't think we should have a pom parser) <ant> so is this saying if I want to insatll a webapp in tomcat that uses tuscany I need to set up a maven repos? <cr22rc> would it be too hard with this an implementation that dependencies couldn't be just picked up in the same directory that the extension jar <jboynes> ant: no, it is saying that if you have maven repos you can use them <ant> how does it work if I don't want to use a maven repos? <cr22rc> will need another artifactrepository implemented... I think <jboynes> you could put all your classes in your webapp as usual <jboynes> or that <Venkat> I have the same question as cr22rc <jervisliu> We used to have a testing\tomcat directory in M1, that can generate a list of <jervisliu> tuscany jars needed in Tomcat. <jervisliu> are we going to do the same thing? <jboynes> we have a webapp distro that contains all the jars <jboynes> cr22rc: if I have composites and libraries in the same directory, how do I tell them apart? <jboynes> and if I have multiple composites in the same directory, how do I separate their classpaths? <cr22rc> libraries don't have meta-inf/sca/default.sca <jboynes> what if I have a library jar that doe? <cr22rc> you see that as likely? <jboynes> I see it as possible <ant> how about sub dirs for each extension along the way webapps work, eg: <ant> extensions/javascript <ant> extensions/javascript/classes <ant> extensions/javascript/lib * robbinspg has quit IRC (Read error: 104 (Connection reset by peer)) <jboynes> that would work * kgoodson has quit IRC ("Chatzilla 0.9.73 [Firefox 1.5.0.6/2006072814]") <jboynes> you could also support "packed" versions (like war files) <jboynes> where the extension jar contained a "lib" directory inside it <cr22rc> do you expect to load two different versions of a dependent library for different extensions? <ant> like sar files for sca archive :) <jboynes> yes (except the jboss folks would probably sue us :-) <jboynes> how about a "scar" file <jboynes> (just kidding) <dwheeler> I definitley think supporting such a ".scar" file is a good way to go though. <dwheeler> Makes life easier on the user <cr22rc> SCAB file Sca binary <Venkat> and that is something that the specs can comfortably address <dwheeler> even if you start to have archives with multiple copies of the same libraries. <jboynes> ant: can you post a proposal for a "sar", "scar or "scab" file layout to the wiki? <jboynes> that would also be the directory layout in the unpacked case you mentioned <ant> knew i should have kept quiet <ant> ok <jboynes> thanks :-) <jboynes> I'll work on the <dependency> stuff for tonight <jboynes> and cr22rc can keep us honest :-) <cr22rc> to support multiple implementations loaded at the same time don't each need to have their own classloader ? <jboynes> yes <jboynes> each composite has it's own classloader <jboynes> which is a child of the classloader of it's parent <cr22rc> then there is more issues if the objects they create get shared ? IMO things really go weird when same objects but loaded by different classloaders interact <jboynes> what do they share? <ant> you mean you'll code the <dependency> stuff? Should I just try coding the sar dir layout stuff as well then? <jboynes> there had been some discussion of the dependency stuff on the list <cr22rc> data ? wouldn't one binding for example create objects that would themselves in a component and another binding create them too from a different version and also be referenced from the same component? * kevin__ has quit IRC <jboynes> it might be an idea to capture the layout thing on the list or wiki as well <ant> ok <jboynes> but if you want to do that in code it works for me :-) <ant> i'll at least post a mail 1st <jboynes> cr22rc: bindings would be the thing converting between classloaders <jboynes> e.g. serializing in app1's classloader and deserializing in app2's classloader <jboynes> the binding itself will in in yet another classloader (some systemy one) <cr22rc> hmm won't that be quite a performance hit? <jboynes> in general yes <jboynes> it is one of the things we would look to optimize <ant> On a new topic, Can I ask if it was just me that didn't know -Psourcecheck was required now? <cr22rc> I seen several "warnings" from jim <cr22rc> I like to also ask after this ... what is our view of JIRAs ? <jervisliu> i think once we resolve current checkstyle warnings, we should switch on -Psourcecheck by default. so that ppl cant get mvn built if their code dont comply <ant> thats kind of where I was going to ask next. Is that the intention? Is everyone happy with that? It seems a bit harsh to me <cr22rc> Is there really that much of a benefit to be so strict? <jboynes> i think it is too harsh by default and adds too much overhead if done on every compile <jboynes> I was happy with a rule that it should be done before a commit <jboynes> s/rule/guideline/ <jboynes> or something <ant> but thats never been suggested as a rule has it? <ant> ok, guideline I'm fine with <cr22rc> This sounds perfect if we get an independent continuous build to give a seperate report on this daily <ant> well 'fine' may be a bit strong <jboynes> I thought that is where the original discussion ended up (back in April or somewhen) * BaconLewis has joined #tuscany <jboynes> cr22rc: that would be ok if committers consider a sourcecheck problem the same as a build break <ant> i didnt think it was that clear, but i'd have to go re read all the mails <jboynes> and if you treat it as a build break IMO you would want to check it before committign <ant> i'm going to have to go soon. is there something else we could discuss in 10 minutes? <cr22rc> how we should be using Jira? <ant> you mean should we raise JIRA's for the function we're working on or want someone else to work on? <jboynes> one for ant before he goes - are you happy with the interface.wsdlstuff now? * pombreda has quit IRC (No route to host) <ant> notihng has happened there has it? <cr22rc> ant: yes <jboynes> ant: you had questions on wsdlLocation and stuff that you were going to clarify <ant> i thought we left it at you were going to propose something? <cr22rc> (why we need jiras) <cr22rc> :-) <jboynes> nope <ant> cr22rc, I guess I'm fine with using JIRAs like that, but I'm not sure if everyone will do it * sykesm has quit IRC ("ircII EPIC4-2.2 -- Are we there yet?") <cr22rc> well that's why I'm asking what is our position on his? <cr22rc> this <jboynes> cr22rc: I have a concern that all discussion will move into JIRA comments that are harder for people to follow <ant> i agree discussion should be on the devlist not in JIRA comments <cr22rc> but once something is decided and being worked on would it not make sense to copy the comments to a jira to track the activity and status of it ? <jboynes> it might but as ant says I'm not sure everyone will <ant> jboynes, are don't understand how wsdl is supposed to work or what wsdlLocation will do so I can't propose something <ant> (...I don't ...) <jboynes> it's duplication and people don't tend to do things twice :-) <jboynes> ant: i thought you were going to figure out what wsdlLocation and stuff did <ant> could put a link in the JIRA to the mail on the list? <jboynes> i do think we should have jiras for anything non-committers are doing <jboynes> so that we can track the patches and make sure they don't get dropped <ant> there isn't really any code for it yet is there? Just the attribute being read thats in the interface wsdl loader <jboynes> we also get the IP grant tracked in the jira entry * pombreda has joined #tuscany * jervisliu has left #tuscany * Looking up BaconLewis user info... <cr22rc> ok seems odd to me we can have such a strong desire for source checking but not use a system to track progress for all. I'm of the opinion that svn should bounce the commit if there is no jira with it ... but I guess I'm alone on this. <halehM> Isn't it easier to use list of completed JIRAs at the end of a milestone to determine what went into that release? <Venkat> from my perspective it sometimes does make sense to have a Jira in place... take the case of the dicussion on the wiring.. AFAIK there are three mailing threads on it... if Jim were to answer which one would he do... <jboynes> any of them in preference to just adding jira comments <ant> cr22rc, I agree with the agree sentiment, but bouncing a commit is way harsh IMHO <jboynes> back to the "discussion on the list" thing <jboynes> cr22rc: I agree with ant on that <cr22rc> I was going to the extreme there ... but close to it. <cr22rc> if you put just the jira in the top comment you can even go to the jira and see the commits for it. <jboynes> cr22rc: I think if you go too detailed then stuff gets lost in the noise <cr22rc> rather nice <ant> jboynes, if I stick around here for a bit do you think we could make some progress on the WSDL issues? <jboynes> how about later - I have calls for the next 3 hours <Venkat> a more trivial request :-) that I have is ... one of you folks please have a look at the website patch I submitted today... Jira-601 <Venkat> just an update to the documentation site <Venkat> and let me know if that is ok... <Venkat> sorry documenation page and not documentation site <ant> I've just had a quick look Venkat - looks great to me. I don't know how to build the website now that its on the new system. cr22rc, is there any doc or old emails saying this works now? <Venkat> oops.. I just did a build.bat... has that changed now? <cr22rc> to build just run build afaik <ant> i've never even looked so I've no idea <Venkat> all that I did is pulled down the site-author directory and then executed build.bat (there is a readme there which talked about this) <Venkat> and then the site-publish has all the htmls for checking out locally <Venkat> ok.. I'll bow out now... its late.. thanks Ant for checking the website stuff out .. jboynes & cr22rc let me know your opinions over mails ... * Venkat has quit IRC <ant> I'll make sure someone gets to it <cr22rc> hold .. on for a sec venkat.. can you? <ant> i have to go as well. ttyal... * ant is now known as ant_away
