[00:01:46] *** aslak has quit IRC
[00:35:22] *** antollinim_lunch is now known as antollinim
[00:51:22] *** lanceball has quit IRC
[01:13:20] *** bfitzpat has quit IRC
[02:43:14] *** rcernich has quit IRC
[02:50:15] *** ldimaggi has joined #switchyard
[03:07:42] *** antollinim has quit IRC
[04:01:34] *** kcbabo has joined #switchyard
[05:39:52] *** ldimaggi has quit IRC
[05:43:55] *** tcunning has quit IRC
[06:10:52] *** kcbabo has quit IRC
[06:18:57] *** dbevenius has joined #switchyard
[06:41:14] *** magesh has joined #switchyard
[07:40:52] *** rbalent has joined #switchyard
[07:48:16] *** javahorn has joined #switchyard
[08:35:18] *** aslak has joined #switchyard
[10:08:33] *** dbevenius has left #switchyard
[11:17:02] *** mriet has joined #switchyard
[11:17:24] *** mriet has quit IRC
[12:33:23] *** ldimaggi has joined #switchyard
[12:40:57] *** magesh1 has joined #switchyard
[12:43:01] *** magesh has quit IRC
[12:46:11] *** dbevenius has joined #switchyard
[13:37:21] *** tcunning has joined #switchyard
[13:56:16] *** magesh1 has quit IRC
[14:02:29] *** ldimaggi has quit IRC
[14:13:02] *** igarashitm has joined #switchyard
[14:20:37] *** magesh has joined #switchyard
[14:20:53] *** kcbabo has joined #switchyard
[14:53:20] *** lanceball has joined #switchyard
[15:01:08] *** antollinim has joined #switchyard
[15:22:06] *** rbalent has quit IRC
[15:24:12] *** rbalent has joined #switchyard
[15:24:12] *** rbalent has joined #switchyard
[15:29:23] <antollinim> kcbabo: hi Keith, have a minute?
[15:30:23] <kcbabo> antollinim:  sure, what's up?
[15:30:41] *** aslak has quit IRC
[15:30:56] <antollinim> kcbabo: hi, I might be facing a bug, but not sure.
[15:31:20] <antollinim> kcbabo: the forge tests work on a temp dir created by File.createTempFile
[15:32:57] <antollinim> kcbabo: that dir has "weird" characters (the problematic one is "+"). After packaging, the ClasspathScanner cannot work inside that dir, because it does a URLDecoder.decode(urlPath, "UTF-8") and the "+" is replaced by " "
[15:33:18] <antollinim> kcbabo: and the test fails.
[15:34:25] *** ldimaggi has joined #switchyard
[15:34:31] *** tcunning has quit IRC
[15:34:44] <antollinim> kcbabo: I am in a mac now? do you think that this a specific encoding issue in this environment that can be solved by configuring either maven or java?
[15:35:32] <kcbabo> antollinim:  hmm ? not sure
[15:36:12] <kcbabo> antollinim:  so the file creation is done within Forge itself?
[15:37:05] <antollinim> kcbabo: yes, in a class that forge tests must use
[15:37:27] <kcbabo> antollinim:  I'm surprised that "+" is replaced with " ", I would expect it to be %2B or something
[15:37:53] <antollinim> kcbabo: yes, that what is happening
[15:38:00] <antollinim> kcbabo: do you want me to create a jira for now?
[15:38:30] *** rbalent has quit IRC
[15:39:05] <kcbabo> antollinim:  what I would do is create a unit test which demonstrates the problem
[15:39:18] <kcbabo> antollinim:  just a simple stand-alone one that doesn't involve forge
[15:39:29] <kcbabo> antollinim:  post that in a remote branch and link to it in a JIRA
[15:40:00] <antollinim> kcbabo: ok, good, will do that then. Thanks
[15:40:45] <kcbabo> antollinim:  thanks mario
[15:41:03] <antollinim> kcbabo: BTW, I will be in Raleigh on 30/Aug and 31/Aug. I'll send you an email, ok?
[15:41:13] <kcbabo> antollinim:  sounds great!
[15:41:38] <antollinim> kcbabo: :)
[15:41:58] *** tcunning has joined #switchyard
[15:42:31] *** mriet has joined #switchyard
[15:46:00] *** mriet has quit IRC
[16:19:46] <kcbabo> igarashitm:  hey tomo
[16:19:52] <kcbabo> igarashitm:  want to pick up a quick JIRA for 0.2 ?
[16:19:53] *** jgraham_ has joined #switchyard
[16:20:02] <igarashitm> kcbabo: sure!
[16:20:08] <kcbabo> igarashitm:  coming your way ;-)
[16:20:56] *** magesh has left #switchyard
[16:21:56] *** rcernich has joined #switchyard
[16:24:50] <igarashitm> kcbabo: any task is ok.. it's time to get familier with switchyard for me right now :)
[16:25:12] <kcbabo> igarashitm:  your last pull request was perfect
[16:25:46] <igarashitm> kcbabo: thanks!
[16:26:33] *** bfitzpat has joined #switchyard
[16:32:42] <igarashitm> kcbabo: BTW, do you use Eclipse ? or IntelliJ IDEA? or another?
[16:32:49] <kcbabo> igarashitm:  eclipse for me
[16:33:05] <kcbabo> igarashitm:  indigo at the moment
[16:33:34] <igarashitm> kcbabo: ok.. works fine with maven multi-module project?
[16:33:58] <kcbabo> igarashitm:  I rarely build from inside eclipse, so I can't say for sure
[16:34:07] <kcbabo> igarashitm:  but seems to hang together ok
[16:35:52] <igarashitm> kcbabo: when I create a switchyard project in Eclipse, it doesn't resolve the dependencies which is in the pom.xml of sub-modules
[16:36:23] <igarashitm> kcbabo: so many dependency errors
[16:36:32] <kcbabo> igarashitm:  when you say "create a switchyard project", do you mean a new application project?
[16:36:47] <kcbabo> igarashitm:  or just importing an existing project (e.g. switchyard-config) ?
[16:36:50] <igarashitm> no, just import the switchyard source code
[16:37:05] <kcbabo> igarashitm:  with m2eclipse and Import->Maven Project , I've had no issues
[16:38:19] <igarashitm> kcbabo: oh really? that's good news... so you've installed the m2eclipse instead of indigo build-in maven function?
[16:38:54] <kcbabo> igarashitm:  actually, I think it's included by default, isn't it?
[16:40:19] <igarashitm> kcbabo: hmm... so we are using same maven function... something strange in my env...
[16:40:27] <igarashitm> kcbabo: ok, thanks, try again it later
[16:40:34] <kcbabo> igarashitm:  sure thing
[16:57:23] <rcernich> igarashitm: make sure you've set it to resolve workspace dependencies
[16:57:28] <rcernich> igarashitm: that may help
[16:58:15] <rcernich> igarashitm: you may also try,, Project->Update All Maven Dependencies
[16:59:09] <igarashitm> rcernich: thanks! I'll check it
[17:22:36] <rcernich> kcbabo: hey keith, could you point me to that sca spec you were talking about on monday's call (contributions or something)
[17:57:03] *** errantepiphany has joined #switchyard
[18:13:48] <errantepiphany> kcbabo: Have you seen this when building quickstarts? The project org.switchyard.quickstarts:switchyard-quickstart-bean-service:0.2.0-SNAPSHOT (/data/dev/github/errantepiphany/switchyard-quickstarts/bean-service/pom.xml) has 1 error
[18:13:48] <errantepiphany> [ERROR]     Non-resolvable parent POM: Could not find artifact org.switchyard.quickstarts:switchyard-quickstarts-parent:pom:0.2.0-SNAPSHOT and 'parent.relativePath' points at wrong local POM @ line 24, column 11 -> [Help 2]
[18:14:31] <errantepiphany> kcbabo: it's obvious what the problem is, but I'm wondering how this passes for anyone.
[18:15:09] <errantepiphany> kcbabo: (../pom.xml instead of ../../pom.xml)
[18:27:41] <kcbabo> kcbabo:  sure thing, one sec
[18:27:46] <kcbabo> rcernich:  ^ whoops
[18:28:05] <rcernich> kcbabo: no worries
[18:28:14] <kcbabo> errantepiphany:  it's likely that won't fail if the parent pom is already in the local repo
[18:28:21] <kcbabo> errantepiphany:  if it's not though, then it won't resolve
[18:28:50] <errantepiphany> kcbabo: well I regularly clean out ~/.m2/repository/org/switchyard and build clean, which is why I see it.
[18:29:07] <errantepiphany> kcbabo: I guess my point is we should fix it 'cause anyone who builds truly fresh will hit this.
[18:30:23] <kcbabo> errantepiphany:  yeah, of course
[18:30:56] <kcbabo> errantepiphany:  just sayin' that's probably why other people aren't hitting it
[18:31:01] <errantepiphany> kcbabo: right on.
[18:31:46] <kcbabo> errantepiphany:  I'll push a fix direct to the jboss-switchyard repo
[18:31:48] <kcbabo> errantepiphany:  one sec
[18:38:27] <igarashitm> my eclipse env looks fine now after clean checkout & import all Maven projects... anyway, thanks kcbabo, rcernich
[18:38:37] <kcbabo> igarashitm:  cool
[18:39:18] <kcbabo> errantepiphany:  huh ? despite an empty repository and that bad path, my quickstarts repo still builds
[18:39:21] <kcbabo> errantepiphany:  weird
[18:39:34] <kcbabo> errantepiphany:  anyway, the relative path is wrong, so I'll fix it
[18:40:22] <errantepiphany> kcbabo: that is weird.
[18:40:32] <kcbabo> errantepiphany:  yeah, no doubt
[18:44:13] *** GitHub101 has joined #switchyard
[18:44:13] <GitHub101> [quickstarts] kcbabo pushed 1 new commit to master: http://git.io/3yVCEA
[18:44:13] <GitHub101> [quickstarts/master] fixed relativePath of parent pom in bean-service quickstart - Keith Babo
[18:44:13] *** GitHub101 has left #switchyard
[18:44:19] <kcbabo> rcernich:  it's the SCA assembly spec here:
[18:44:20] <kcbabo> http://docs.oasis-open.org/opencsa/sca-assembly/sca-assembly-1.1-spec.pdf
[18:48:22] <rcernich> kcbabo: thanks
[18:48:55] <rcernich> kcbabo: i must not have read it very carefully;)
[18:49:06] <kcbabo> rcernich:  I wouldn't get lost in that spec language
[18:49:45] <kcbabo> rcernich:  the important bit is just the general concept
[18:49:51] <rcernich> kcbabo: sure
[18:53:19] <kcbabo> rcernich:  also interesting to see the relationship between that, a drools package defnition, and the drools changeset configuration syntax
[18:53:36] <kcbabo> rcernich:  I point this out because the latter bits already interoperate with Guvnor
[18:54:02] <kcbabo> rcernich:  you can point a knowledge agent at Guvnor to pull down resources
[19:01:00] *** lanceball has quit IRC
[19:06:24] *** lanceball has joined #switchyard
[19:08:17] *** igarashitm is now known as igatm_lunch
[19:09:15] <kcbabo> rcernich errantepiphany : would you mind picking up tomo's pull request?
[19:09:22] <kcbabo> https://github.com/jboss-switchyard/components/pull/218
[19:09:35] <errantepiphany> kcbabo: I can get it.
[19:09:41] <kcbabo> errantepiphany:  gracias
[19:09:46] <errantepiphany> kcbabo:  de nada
[19:13:19] *** GitHub76 has joined #switchyard
[19:13:19] <GitHub76> [components] errantepiphany pushed 1 new commit to master: http://git.io/Pwf_XA
[19:13:19] <GitHub76> [components/master] SWITCHYARD-422: SOAPFacet should depends on SwitchYardFacet - Tomohisa Igarashi
[19:13:19] *** GitHub76 has left #switchyard
[19:13:59] <kcbabo> errantepiphany:  uncovered an interesting issue with merged config just now
[19:14:13] <errantepiphany> kcbabo: just what I wanted to hear.
[19:15:28] <kcbabo> errantepiphany:  let's say I have an auto-generated config from a Camel Java DSL route that produces the following config:
[19:15:30] <kcbabo> <composite xmlns="http://docs.oasis-open.org/ns/opencsa/sca/200912" name="soapcamel" targetNamespace="urn:switchyard:application:soapcamel">
[19:15:30] <kcbabo>         <service name="MyTest" promote="MyTest">
[19:15:30] <kcbabo>             <binding.soap xmlns="urn:switchyard-component-soap:config:1.0">
[19:15:30] <kcbabo>                 <wsdl>wsdl/Test.wsdl</wsdl>
[19:15:30] <kcbabo>                 <serverPort>18000</serverPort>
[19:15:31] <kcbabo>             </binding.soap>
[19:15:31] <kcbabo>         </service>
[19:15:32] <kcbabo>         <component name="MyTestBuilder">
[19:15:32] <kcbabo>             <implementation.camel xmlns="urn:switchyard-component-camel:config:1.0">
[19:15:33] <kcbabo>                 <java class="org.soapcamel.MyTestBuilder"/>
[19:15:33] <kcbabo>             </implementation.camel>
[19:15:34] <kcbabo>             <service name="MyTest">
[19:15:34] <kcbabo>                 <interface.java interface="org.soapcamel.MyTest"/>
[19:15:35] <kcbabo>             </service>
[19:15:53] <kcbabo> errantepiphany:  but I want to add a reference to that generated config
[19:16:04] *** lanceball is now known as lancelunch
[19:16:13] <kcbabo> errantepiphany:  the user's switchyard.xml just looks like this at first:
[19:16:14] <kcbabo> <composite xmlns="http://docs.oasis-open.org/ns/opencsa/sca/200912" name="soapcamel" targetNamespace="urn:switchyard:application:soapcamel">
[19:16:14] <kcbabo>         <service name="MyTest" promote="MyTest">
[19:16:14] <kcbabo>             <binding.soap xmlns="urn:switchyard-component-soap:config:1.0">
[19:16:14] <kcbabo>                 <wsdl>wsdl/Test.wsdl</wsdl>
[19:16:14] <kcbabo>                 <serverPort>18000</serverPort>
[19:16:15] <kcbabo>             </binding.soap>
[19:16:15] <kcbabo>         </service>
[19:16:16] <kcbabo>     </composite>
[19:16:28] <kcbabo> errantepiphany:  so I add this:
[19:16:39] <kcbabo>     <component name="MyTestBuilder">
[19:16:39] <kcbabo>             <reference name="AnotherEndpoint"/>
[19:16:39] <kcbabo>         </component>
[19:16:55] *** jgraham_ has quit IRC
[19:17:00] <kcbabo> errantepiphany:  the merged config picks up the reference correctly, along with the other stufff
[19:17:03] <kcbabo> errantepiphany:  so that's all good
[19:17:09] <kcbabo> errantepiphany:  but the merged config is not schema valid
[19:17:49] <errantepiphany> kcbabo: what does the merged config look like?
[19:17:57] <kcbabo> <component name="MyTestBuilder">
[19:17:57] <kcbabo>             <reference name="AnotherEndpoint"/>
[19:17:57] <kcbabo>             <implementation.camel xmlns="urn:switchyard-component-camel:config:1.0">
[19:17:57] <kcbabo>                 <java class="org.soapcamel.MyTestBuilder"/>
[19:17:57] <kcbabo>             </implementation.camel>
[19:17:57] <kcbabo>             <service name="MyTest">
[19:17:58] <kcbabo>                 <interface.java interface="org.soapcamel.MyTest"/>
[19:17:58] <kcbabo>             </service>
[19:17:59] <kcbabo>         </component>
[19:18:09] <kcbabo> errantepiphany:  so reference is in the wrong spot
[19:18:25] <errantepiphany> kcbabo: ah.
[19:18:33] <kcbabo> errantepiphany:  nothing critical for now cause I can work around it another way, but something to keep in mind
[19:18:38] <kcbabo> errantepiphany:  I will file a JIA
[19:18:39] <kcbabo> JIRA
[19:18:40] <errantepiphany> kcbabo: yeah I probably need to do another ordering call after the merge.
[19:19:09] <errantepiphany> kcbabo: set it to 0.2 - I can fix it quick. I *thought* this might be possible, but hadn't come up with a test case.
[19:19:19] <kcbabo> errantepiphany:  cool
[19:19:19] <errantepiphany> kcbabo: I know right where the fix needs to be.
[19:21:58] <kcbabo> errantepiphany:  created and assigned
[19:22:06] <kcbabo> errantepiphany:  attached the app so it will be easy to reproduce
[19:22:42] <errantepiphany> kcbabo: thx
[19:25:46] <rcernich> kcbabo: so, do you envision deployment resolving and publishing artifacts?
[19:26:01] <rcernich> kcbabo: e.g. pulling in rules or a business process?
[19:26:22] <rcernich> kcbabo: or pushing out a service details?
[19:30:40] <kcbabo> rcernich:  I think we're going to have to play with it, tbh
[19:30:51] <rcernich> kcbabo: sure
[19:30:55] <kcbabo> rcernich:  but yes, deployer pulling in stuff from the repo is a definite candidate
[19:31:25] <kcbabo> rcernich:  the workflow will have to be smoothed out a bit, but taking it from the beginning
[19:31:49] <kcbabo> rcernich:  user creates a project which creates artifact [a] and imports artifact [b] from the repo
[19:32:11] <kcbabo> rcernich:  they are going to want to publish [a] in the repository at some point during the development process
[19:32:28] <kcbabo> rcernich:  they are also going to need to import [b] into their workspace to develop against it during development
[19:32:49] <kcbabo> rcernich:  when the app is ready to deploy, they need to put the artifacts into the appropriate state in the repository and deploy the application
[19:33:08] <rcernich> kcbabo: sure, but, so far, i don't see anything specific to switchyard in that use case
[19:33:15] <kcbabo> rcernich:  my guess right now is that the runtime and/or a deployment parameter will indicate which version/location of the artifacts to use
[19:33:29] <rcernich> kcbabo: and there it is :)
[19:33:43] <kcbabo> rcernich:  no, that's just plain jane repository workflow
[19:34:01] <kcbabo> rcernich:  except we need the ability for our configuration to reflect the fact that an artifact is in the repository
[19:34:10] <rcernich> kcbabo: yep
[19:34:15] <kcbabo> rcernich:  so for example, you wouldn't deploy these things with your application
[19:34:24] <rcernich> kcbabo: yep
[19:34:30] <kcbabo> rcernich:  so that takes some build-time and configuration syntax work
[19:34:38] <kcbabo> rcernich:  and then the deployer work at runtime
[19:34:43] <rcernich> kcbabo: yep
[19:34:49] <kcbabo> rcernich:  the raw materials should be there though
[19:34:59] <kcbabo> rcernich:  and I *think* we can kick some ass with that contribution stuff
[19:35:14] <kcbabo> rcernich:  the contribution could be the key to managing the resolution of these artifacts
[19:35:23] <kcbabo> rcernich:  so the application code just says "give me [a]"
[19:35:32] <kcbabo> rcernich:  but it has no idea where that's coming from
[19:35:36] <rcernich> kcbabo: yes
[19:35:39] <kcbabo> rcernich:  no paths or anything like that
[19:35:56] <kcbabo> rcernich:  the contribution contains the paths and mapping logic to make that resolution happen
[19:36:10] <kcbabo> rcernich:  sounds good in theory anyway
[19:36:22] <rcernich> kcbabo: cdi in a distributed environment
[19:37:03] <rcernich> kcbabo: in talking with the repo guys, i think there will eventually be a management component
[19:37:12] <rcernich> kcbabo: e.g. a tie in with jon/jopr
[19:37:16] <kcbabo> rcernich:  I think we can get something basic just with WSDLs, XSDs, and Java interfaces which should be possible with today's Guvnor and should be independently valuable ? i.e. it's not just a silly feature
[19:37:26] <rcernich> kcbabo: for staging and wiring
[19:37:40] <kcbabo> rcernich:  perhaps ? I want to let them work all that out :-)
[19:37:46] <kcbabo> rcernich:  my thing is let's use what's there
[19:37:47] <rcernich> kcbabo: most definitely
[19:38:12] <rcernich> kcbabo: so, how 'bout if i look at publishing something during deployment
[19:38:34] <rcernich> kcbabo: then circle back to get stuff pulled in for design
[19:38:47] <kcbabo> rcernich:  I wonder how useful publishing during deployment will be
[19:38:54] <rcernich> kcbabo: or not:)
[19:38:59] <kcbabo> rcernich:  :-)
[19:39:17] <kcbabo> rcernich:  not saying we shouldn't do it, just wondering how that all ties together
[19:39:19] <rcernich> kcbabo: i was thinking mostly of getting my hands dirty with the guvnor apis
[19:39:58] <rcernich> kcbabo: but i'm game for a more ambitious (and useful) goal
[19:40:00] <kcbabo> rcernich:  I think the most direct way to do it is to look at pulling stuff in during deployment
[19:40:12] <kcbabo> rcernich:  well, I think the pull in deployment goal is actually the easiest
[19:40:27] <kcbabo> rcernich:  and most consistent with the eventual workflow we want to encourage
[19:40:50] <kcbabo> rcernich:  so look at this way - we can narrow down the steps involved to the minimum required
[19:41:11] <kcbabo> rcernich:  user creates the artifact on their own and then publishes to guvnor independently
[19:41:34] <kcbabo> rcernich:  application contains a pointer to that artifact rather than the artifact itself (WSDL would be a good candidate for this)
[19:41:50] <kcbabo> rcernich:  the deployer picks that up and goes to Guvnor to pull it in
[19:42:04] <rcernich> kcbabo: yeah
[19:42:22] <rcernich> kcbabo: seems really trivial
[19:42:34] <rcernich> kcbabo: what would be the purpose of pulling the wsdl in from the repo?
[19:42:50] <rcernich> kcbabo: would we, eventually, validate the deployment against the imported artifact?
[19:43:27] <kcbabo> rcernich:  it's used by our runtime
[19:43:39] <kcbabo> rcernich:  we load the interface definition from the WSDL
[19:43:47] <kcbabo> rcernich:  the SOAP binding uses the WSDL to throw up the SOAP endpoint
[19:43:55] <rcernich> kcbabo: right
[19:44:07] <rcernich> kcbabo: but what if it doesn't match with the implementation?
[19:44:21] <kcbabo> rcernich:  not sure I get it
[19:44:35] <kcbabo> rcernich:  you could have the same problem with a WSDL that was packaged with your application
[19:45:01] <kcbabo> rcernich:  so next step is getting this thing pulled down at design-time into the developer workspace
[19:45:08] <kcbabo> rcernich:  like I was talking about above
[19:45:16] <kcbabo> rcernich:  so there are two benefits here:
[19:45:35] <kcbabo> 1) someone else might have created the WSDL - perhaps it's an organization thing, or there's a COE that creates them
[19:45:52] <rcernich> kcbabo: sorry, what is the difference between downloading it from the repo during development and including it in the package versus omitting it from the package and getting it during deployment?
[19:45:57] <kcbabo> 2) if you are publishing the WSDL, it's there for other people to drag down at design-time to consume your application's services
[19:46:42] <kcbabo> rcernich:  mainly that the packaging code can choose to use different versions of the artifact without replacing bits of the application package
[19:46:56] <kcbabo> rcernich:  or I should say packaging definition
[19:47:11] <rcernich> kcbabo: ok, but doesn't that imply some sort of validation during deployment?
[19:47:35] <rcernich> kcbabo: e.g. if a message type changes, wouldn't that potentially break the deployment?
[19:48:01] <rcernich> kcbabo: (just shoot me if i'm being dense here)
[19:48:37] <kcbabo> rcernich:  well, really that's not supposed to change
[19:48:53] <kcbabo> rcernich:  you are setting the version of an artifact and saying "use version x.y"
[19:48:54] <rcernich> kcbabo: sure, but that would be one reason why it might be versioned
[19:49:19] <kcbabo> rcernich:  and the version is in the definition of which artifact you are using
[19:49:39] <kcbabo> rcernich:  in Guvnor, I think this simply resolves to a unique URL for the package
[19:49:42] <kcbabo> rcernich:  IIRC
[19:50:03] <rcernich> kcbabo: ok, but i still don't see a reason why it would make a difference whether or not it is included in the package or downloaded during deployment
[19:50:25] <kcbabo> rcernich:  let's use your use case of an incompatible change
[19:50:31] <kcbabo> rcernich:  let's say it's a compatible change
[19:50:32] <rcernich> kcbabo: i do see where it would be important to know what the artifact is so that it can be linked with the repository
[19:50:48] <kcbabo> rcernich:  you need to extend the order schema definition to include an optional element
[19:50:51] <rcernich> kcbabo: e.g. orders uses order ack
[19:51:01] <rcernich> kcbabo:  v 1.0
[19:51:01] <kcbabo> rcernich:  you need to do this across all services which use orders
[19:51:15] <rcernich> kcbabo: ahh
[19:51:27] <kcbabo> rcernich:  so how do you this if you've included the orders schema in every single app?
[19:51:32] <rcernich> kcbabo: so, you'd like to update your dev, see what breaks, fix it and deploy
[19:51:35] <rcernich> kcbabo: ?
[19:51:36] <kcbabo> rcernich:  as tfennelly would say - PITA
[19:51:55] <kcbabo> rcernich:  if I have a standard definition of order, I want to change that in one place
[19:52:08] <kcbabo> rcernich:  I also want to track how that artifact has changed
[19:52:20] <rcernich> kcbabo: sure, i'm not saying you wouldn't.
[19:52:46] <rcernich> kcbabo: but, if you're pulling it from the repo, and it's in your workspace, what's the harm of including it in the package?
[19:53:00] <kcbabo> rcernich:  what's it doing in there?
[19:53:06] <kcbabo> rcernich:  what purpose does it serve?
[19:53:37] <rcernich> kcbabo: you tell me? why would we be fetching it from the repo during deployment?
[19:54:23] <kcbabo> rcernich:  you asked why don't we include it in the application package
[19:54:25] <rcernich> kcbabo: i don't mean to be thickheaded
[19:54:40] <kcbabo> rcernich:  and I gave an example above w/r/t change management of shared artifacts (like an orders schema)
[19:54:47] <kcbabo> rcernich:  so that's why we would want to pull it in
[19:54:54] <rcernich> kcbabo: sure, and that makes sense
[19:55:06] <kcbabo> rcernich:  so then the question is why not also include it in the application itself
[19:55:07] <rcernich> kcbabo: but, if you need it during design, you have it already
[19:55:19] <rcernich> kcbabo: the important thing is that the project knows where it came from
[19:55:37] <rcernich> kcbabo: and the deployment knows so it can publish it's reference to that artifact
[19:55:49] <rcernich> kcbabo: for things like impact analysis
[19:56:13] <rcernich> kcbabo: sorry, yes, why not just include it since you already have a handle to it
[19:56:27] <kcbabo> rcernich:  how are you going to get impact analysis if each app publishes it's included version of an artifact on deployment?
[19:56:49] <rcernich> kcbabo: sorry, it's not publishing the artifact itself, just that it references said artifact
[19:57:02] <rcernich> kcbabo: e.g....
[19:57:17] <rcernich> kcbabo: we add some contributions document to the package
[19:57:26] <kcbabo> rcernich:  sure, that's right
[19:57:27] <rcernich> kcbabo: it includes details about what we're importing
[19:57:34] <kcbabo> rcernich:  but why include the artifact itself?
[19:57:37] <rcernich> kcbabo: in our example, said wsdl
[19:58:02] <rcernich> kcbabo: it shouldn't matter whether we include said wsdl in the package or pull it down after deployment
[19:58:24] <rcernich> kcbabo: we would include the wsdl because it's required by the runtime
[19:58:48] <rcernich> kcbabo: i guess it doesn't really matter
[19:59:40] <kcbabo> rcernich:  let's say that I can tokenize the artifact id to include a deployment profile
[19:59:50] <kcbabo> rcernich:  {dev, qe, stage, prod}
[20:00:06] <kcbabo> rcernich:  each of these will resolve to a unique artifact I've published in my enterprise repository
[20:00:49] <rcernich> kcbabo: and that token would be defined on your server
[20:00:53] <kcbabo> rcernich:  if I make it so that the packaging definition can import these based on an environmental parameter (perhaps directly in the contribution, perhaps a property of the deployer/runtime), then I'm good to go
[20:00:57] <rcernich> kcbabo: e.g. deploy to prod, get the prod version?
[20:01:19] <kcbabo> rcernich:  but if I'm packaging the WSDL on my own, then I need to create a different package for each enviroment
[20:02:57] <rcernich> kcbabo: but then, aren't we back to compatibility?
[20:03:00] <rcernich> kcbabo: what am i missing?
[20:03:12] <kcbabo> rcernich:  I'm not sure :-)
[20:03:13] <rcernich> kcbabo: if the wsdl are different, then they may be different
[20:03:33] <rcernich> kcbabo: and what if somebody changed something in dev, but not qa?
[20:03:46] <rcernich> kcbabo: now i deploy to qa and it breaks
[20:03:53] <rcernich> kcbabo: but when do i find out about it?
[20:04:02] <rcernich> kcbabo: during deployment or when the first test fails?
[20:04:29] <kcbabo> rcernich:  which test are you referring to?
[20:04:37] <rcernich> kcbabo: the test in the qa env
[20:04:55] <rcernich> kcbabo: ok, maybe a java analogy
[20:05:18] <rcernich> kcbabo: i write a java application
[20:05:24] <rcernich> kcbabo: i package it up
[20:05:40] <rcernich> kcbabo: i deploy it on another machine
[20:05:53] <rcernich> kcbabo: my application references code from other libraries
[20:06:07] <rcernich> kcbabo: i have a couple ways of dealing with this
[20:06:12] <kcbabo> rcernich:  like from a Maven repository by chance?
[20:06:24] <rcernich> kcbabo: lol
[20:06:39] <rcernich> kcbabo: i can deploy the dependencies with my jar
[20:06:52] <rcernich> kcbabo: or i can require the user pull them down before running the app
[20:07:20] <rcernich> kcbabo: in the latter case, the user needs to ensure the dependencies are compatible
[20:07:54] <rcernich> kcbabo: and, since they should be using the same jars i used to compile, it shouldn't matter whether they pull them in or not
[20:07:58] <rcernich> kcbabo: however...
[20:08:07] <rcernich> kcbabo: say there was a bug in one of the dependencies
[20:08:40] <rcernich> kcbabo: since the fix did not modify any external api, they can get the benefit of the fix by downloading the updated dependency
[20:09:55] <rcernich> kcbabo: as we're talking mainly of interfaces in our case (xsd, wsdl), it seems dangerous to be using different versions without some sort of check on the back end
[20:10:17] <rcernich> kcbabo: but, like i said above, it doesn't really matter
[20:10:19] <kcbabo> rcernich:  what's the check on the "back end" in this case?
[20:10:31] <rcernich> kcbabo: i just think it complicates deployment without any real benefit
[20:11:10] <kcbabo> rcernich:  I'm not getting what the additional check is in your example
[20:11:12] <rcernich> kcbabo: the server, i.e. validating that what we deployed is compatible with what the rest of the world is using
[20:11:25] <kcbabo> rcernich:  how does it do that?
[20:11:26] <rcernich> kcbabo: there is no analogy in my java example
[20:11:36] <kcbabo> rcernich:  ok, forget the java bit then
[20:11:39] <rcernich> kcbabo: we would just see some obscure exception
[20:11:49] <rcernich> kcbabo: i.e. "the first test fails"
[20:11:55] <kcbabo> rcernich:  but explain how the server validates that what's deployed is compatible
[20:12:10] <rcernich> kcbabo: well, that's something i think we should have
[20:12:20] <kcbabo> rcernich:  but what does that mean?
[20:12:26] <rcernich> kcbabo: i.e. it's not there today, but should be
[20:12:46] <rcernich> kcbabo: obviously, that's easier said than done
[20:12:58] <kcbabo> rcernich: hmm ? I'm a bit confused now, because it seems like we've changed topics :-)
[20:13:20] <kcbabo> rcernich:  we always include the artifact today
[20:13:47] <rcernich> kcbabo: to summarize, i think it just complicates deployment to pull the artifact in during deployment versus including the artifact during packaging
[20:14:05] <rcernich> kcbabo: your dev/qa/stage/prod example excluded
[20:14:16] <kcbabo> rcernich:  I agree, there's more work to do
[20:14:31] <kcbabo> rcernich:  but the dev/qa/stage/prod example is how repositories work
[20:14:55] <kcbabo> rcernich:  having developers repackage applications as the move across environments has been a significant pain point in the past
[20:15:17] <rcernich> kcbabo: how are those artifacts changing?
[20:15:23] <rcernich> kcbabo: i guess that's what i'm missing
[20:15:37] <kcbabo> rcernich:  in the case of a WSDL, it's more than just interface details
[20:15:48] <rcernich> kcbabo: sure
[20:16:00] <kcbabo> rcernich:  potentially, pieces of configuration can reflect a runtime environment
[20:16:07] <kcbabo> rcernich:  file system location, HTTP endpoint address, etc.
[20:16:25] <rcernich> kcbabo: ok, i'm with you now
[20:16:45] <rcernich> kcbabo: i was stuck on the service implementation, ignoring references
[20:19:18] <kcbabo> rcernich:  I think we are going to have to work through a number of scenarios here
[20:19:29] <rcernich> kcbabo: yep
[20:19:32] <kcbabo> rcernich:  to be honest, the case you outlined is actually maybe the best starting point
[20:19:42] <kcbabo> rcernich:  cause it really requires no changes in anything :-)
[20:19:52] *** lancelunch is now known as lanceball
[20:20:02] <kcbabo> rcernich:  but it would change your behavior as a user, which might give us some ideas
[20:20:05] <rcernich> kcbabo: how about modifying the orders demo by splitting out the inventory service
[20:20:18] <kcbabo> rcernich:  I don't think we need to even split anything out yet
[20:20:28] <rcernich> kcbabo: we'd have both sides covered there: consumer and provider
[20:20:32] <kcbabo> rcernich:  take the orders demo (or more likely the bean-service qs now)
[20:20:57] <kcbabo> rcernich:  or sure, split it into two apps
[20:21:00] <rcernich> kcbabo: i'd like to think about how references play a part
[20:21:04] <kcbabo> rcernich:  inventory and orders
[20:21:30] <kcbabo> rcernich:  anyway, what I was gonna say is that you take that app
[20:21:52] <rcernich> kcbabo: i'm going by the spec here, but i think we should use the domain concept in wiring
[20:21:55] <kcbabo> rcernich:  and look inside and ask "which parts of this application would benefit from being in a repository?"
[20:22:22] <kcbabo> rcernich:  for orders app as it exists today, that would probably be the WSDL
[20:22:43] <kcbabo> rcernich:  if you split the app in two, and inventory app had a promoted service with a java interface, then that interface would also be a candidate
[20:22:58] <rcernich> kcbabo: that's what i was thinking
[20:23:09] <kcbabo> rcernich:  so you take that there, with no changes required to our runtime and it's already interesting
[20:23:24] <kcbabo> rcernich:  how is the WSDL stored in the first place when manually done by the user
[20:24:06] <kcbabo> rcernich:  when you go to import it into your workspace in another app (that wants to call orders via it's soap binding) - how does that work (again manually)
[20:24:21] <kcbabo> rcernich:  when we package up a Java interface, what does that look like in the repo?
[20:24:58] <kcbabo> rcernich:  so then we take the answers to those questions and map them onto how we would reference the artifacts in our packaging
[20:25:07] <rcernich> kcbabo: great example
[20:25:22] <rcernich> kcbabo: thanks for coming up with something concrete
[20:25:34] <kcbabo> rcernich:  not sure it's the best, but a place to start for sure
[20:25:42] <kcbabo> rcernich:  always good to work through an example
[20:26:20] <rcernich> kcbabo: well, it has the right ingredients
[20:27:39] <kcbabo> rcernich:  beginning of any good meal :-)
[20:27:55] <rcernich> kcbabo: ...starts with the right ingredients;)
[20:38:43] *** igatm_lunch is now known as igarashitm
[21:25:20] *** dbevenius has quit IRC
[21:41:13] *** ldimaggi has quit IRC
[22:00:55] *** kcbabo has quit IRC
[22:03:53] *** kcbabo has joined #switchyard
[22:18:44] *** bfitzpat is now known as bfitzpat_brb
[22:45:11] *** bfitzpat_brb is now known as bfitzpat
[22:59:54] *** igarashitm has quit IRC
[23:08:45] *** kcbabo has quit IRC
[23:36:15] *** rcernich is now known as rcernich_away
[23:41:31] *** lanceball has quit IRC





top