14:01:52 <gastaldi> #startmeeting
14:01:52 <jbott> Meeting started Tue Jun 30 14:01:52 2015 UTC.  The chair is gastaldi. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:01:52 <jbott> Useful Commands: #action #agreed #help #info #idea #link #topic.
14:01:54 <jbossbot> Title:3 MeetBot - Debian Wiki
14:02:00 <gastaldi> #chair lincolnthree agoncal
14:02:00 <jbott> Current chairs: agoncal gastaldi lincolnthree
14:02:16 <gastaldi> #addtopic Status updates
14:02:16 <agoncal> Hello everybody
14:02:21 <gastaldi> Hi agoncal, welcome
14:02:33 <gastaldi> #addtopic Priorities
14:02:40 <gastaldi> #addtopic GSoC
14:02:40 <lincolnthree> hey agoncal!
14:02:50 <lincolnthree> #addtopic website status
14:02:54 <gastaldi> anything else that doesn't fit in the above topics?
14:03:10 <soro> hey agoncal :)
14:03:14 <soro> hi folks. :)
14:03:16 <gastaldi> hi soro
14:03:27 <lincolnthree> hey soro
14:03:27 <agoncal> Yes : addons, stacks, firing event on Facet and raoster
14:03:29 <agoncal> ;o)
14:03:55 <lincolnthree> #addtopic stacks, addons, firing events on facets, and roaster
14:03:59 <lincolnthree> ;
14:04:01 <gastaldi> sweet
14:04:01 <lincolnthree> ;)
14:04:20 <gastaldi> let's proceed, we can add topics during the meeting
14:04:23 <gastaldi> #nexttopic
14:04:23 <jbott> #topic Status updates
14:05:18 <gastaldi> #info last week I was on DevNation/RH Summit and released Forge 2.17.0.Alpha2 with some awesome fixes (this release was not published in the website)
14:06:00 <gastaldi> mainly to address some JBDS issues and also with some features that I thought it would be useful during our talk
14:06:17 <gastaldi> one of them is firing events on facets ;)
14:06:28 <agoncal> #info I had my talk on Forge at #DevoxxUK in front of lot of people who were very interested and gave me nice feedback
14:06:38 <gastaldi> awesome!! :D
14:06:58 <agoncal> #info Antoine Sabot Durant wants to join us to the Hands on Lab for Devoxx Marocco
14:07:14 <gastaldi> agoncal, btw, the HoL was fantastic. Although we had a few participants in our lab, everybody managed to finish the lab
14:07:18 <lincolnthree> agoncal: very cool
14:07:23 <agoncal> #info I've submitted the Forge Hands on Lab for Devoxx BE (adding soro and koen without asking ;o)
14:07:34 <gastaldi> lol, good one
14:07:42 <lincolnthree> #info Last week I was with gastaldi at RHSummit and DevNation presenting forge at a session and a lab
14:07:53 <gastaldi> yeah! we have pictures to prove that! :)
14:08:08 <lincolnthree> #the both went well, and the talk was recorded, so we should have that on youtube in a few weeks
14:09:53 <gastaldi> yeah, it was really great
14:11:39 <gastaldi> #info we're resuming to our normal duties today, we apologize for being absent in the past week
14:12:18 <gastaldi> actually it was yesterday, but w/e :)
14:12:22 <gastaldi> #nexttopic
14:12:22 <jbott> #topic Priorities
14:13:21 <gastaldi> ok, now that the Website is live, what should we focus on next?
14:13:28 <lincolnthree> I think that we should finish the website, maybe 1 more week of work? then call it done.
14:13:41 <lincolnthree> there are some things that still need to be implemented, like the advanced search on a few pages.
14:13:50 <agoncal> Well, it's the topics I've added to the meeting
14:13:51 <gastaldi> ah yes, I forgot completely about that
14:13:52 <lincolnthree> and the addons should be moved to their own pages (not a modal)
14:13:58 <gastaldi> +1
14:14:11 <agoncal> I think we should focus on stacks (implies Roaster) and also addons
14:14:49 <lincolnthree> agoncal: do we have time constraints on stacks, btw?
14:15:15 <gastaldi> #info Website: We'll remove the addon modal and move to their own pages
14:15:30 <gastaldi> #info Website: we need to implement Advanced Search
14:15:30 <agoncal> lincolnthree Depends on the priorities ;o)
14:15:50 <gastaldi> I personally think that polishing the Website is a priority now
14:16:01 <gastaldi> but I may be wrong
14:16:16 <lincolnthree> agoncal: i really want to get the website done
14:16:19 <lincolnthree> agoncal: it's almost there
14:16:43 <lincolnthree> agoncal: we've been working on it for a "year"
14:16:43 <lincolnthree> agoncal: i want it behind us
14:16:43 <agoncal> Yes, I agree : website is priority one
14:16:48 <agoncal> (I was just talking of priority 2)
14:16:56 <lincolnthree> agoncal: ok, I think we agree :)
14:17:21 <gastaldi> lincolnthree, I want it done, not behind us :)
14:17:55 <gastaldi> hi ivannov
14:17:57 <lincolnthree> gastaldi: well, if we could have it behind us it would be pretty sweet. we would be on a website!
14:17:59 <lincolnthree> hey ivannov!
14:18:04 <gastaldi> welcome!
14:18:07 <ivannov> hi everybody :)
14:18:16 <ivannov> thanks, gastaldi
14:19:44 <lincolnthree> brb, docking laptiop
14:19:48 <gastaldi> ok
14:20:21 <gastaldi> #info we'll focus on finishing the Website this week
14:20:42 <gastaldi> #nexttopic
14:20:42 <jbott> #topic GSoC
14:21:59 <gastaldi> #info This week is GSoC Midterm evaluation time. We'll see what our fellow students Devanshu and addonis1990 did and based on their work will decide if they pass it or not
14:22:38 <gastaldi> #info The Forge GSoC projects this year are: Docker and Database Migration addons
14:23:01 <gastaldi> https://github.com/forge/docker-addon and https://github.com/forge/db-migration-addon respectively
14:23:55 <gastaldi> Devanshu, want to say anything before we move on to the next topic?
14:24:37 <Devanshu> No, not much thoughts atm.
14:24:46 <Devanshu> I’ll be presenting the demo soon.
14:24:53 <gastaldi> sweet, looking forward to it :)
14:24:53 <lincolnthree> Devanshu: awesome!
14:25:17 <gastaldi> #nexttopic
14:25:17 <jbott> #topic website status
14:25:39 <gastaldi> 'nuf said about the website I guess
14:26:07 <lincolnthree> gastaldi: yeah. i think so.
14:26:23 <gastaldi> I have one thing left to say: It's faster and better than the previous one
14:26:43 <gastaldi> ok, moving on
14:26:45 <gastaldi> #nexttopic
14:26:45 <jbott> #topic stacks, addons, firing events on facets, and roaster
14:27:06 <gastaldi> #info Facet Events are already implemented in Forge 2.17.0.Alpha2
14:27:12 <agoncal> Well, it's 4 different topics....
14:27:18 <gastaldi> lol
14:27:34 <gastaldi> I think we can discuss in a single one anyway :)
14:27:41 <agoncal> gastaldi Good. Did you use it for the asciidoc thing ?
14:28:07 <gastaldi> agoncal, I had it ready, but we decided on another strategy in our demo
14:28:28 <gastaldi> an addon that generates GoF DESIGN PATTERNS: http://github.com/gastaldi/design-patterns
14:28:34 <gastaldi> how cool is that?? :D
14:29:17 <lincolnthree> gastaldi: pretty cool :)
14:29:20 <gastaldi> well, this is not an addon per se, but a library that was added as a dependency to our addon :)
14:29:26 <lincolnthree> gastaldi: i think the audience enjoyed that
14:29:31 <gastaldi> definitely :)
14:29:36 <gastaldi> I enjoyed writing it
14:29:54 <lincolnthree> gastaldi: and that's am important test of forge development. is it fun?
14:30:05 <gastaldi> yeah
14:30:32 <gastaldi> it's interesting that we found some room for improvement in the Roaster API
14:30:48 <gastaldi> like, copying methods and parameters to a different class
14:31:01 <agoncal> gastaldi Well, that brings me to the "stack" and "roaster" topic
14:31:21 <agoncal> Stacks will bring Java EE 7, Java EE 8.... with Java SE 7 and Java SE 8 syntax
14:31:41 <agoncal> At the moment Roaster generates Java SE 6 syntax (ex. no diamond)
14:31:57 <agoncal> The other day we talked about ROASTER-4
14:31:57 <jbossbot> jira [3ROASTER-4] Having Parameterize interface bit more typed [10Open (Unresolved) Feature Request,7 Major,6 Unassigned] https://issues.jboss.org/browse/ROASTER-4
14:32:14 <gastaldi> agoncal, yeah, that would introduce some API changes to Roaster
14:32:14 <lincolnthree> agoncal: yeah, this will require quite a bit of effort to update, but is something I agree we should work on.
14:32:23 <agoncal> And it looks like doing this will break compatibility in the API
14:32:45 <lincolnthree> agoncal: it does? we could always introduce a new API next to this and deprecate this API
14:32:59 <gastaldi> yeah
14:33:02 <agoncal> So my question is : What about thinking of Roaster 3 (Java SE 7 / 8) support which will break compatibility with Roaster 2 ?
14:33:12 <gastaldi> that's a good idea
14:33:22 <lincolnthree> im gonna be the stick in the mud and say I dunno
14:33:27 <lincolnthree> a lot of people use roaster 2 atm
14:33:38 <lincolnthree> and it would break all of their code if we had to break backwards compatibility
14:33:47 <agoncal> I even though of calling it Roaster 7 (for SE 7 syntax) and Roaster 8 (for SE 8) but the community might not like it
14:33:52 <gastaldi> lincolnthree, we could work on Roaster 3 in a different branch
14:34:39 <ivannov> gastaldi, are you sure you want to go in that direction?
14:34:48 <agoncal> Roaster is an API to generate Java, so it could follow the Java version number
14:34:49 <gastaldi> ivannov, no, I just threw the idea in the air :)
14:35:06 <gastaldi> ivannov, hoping that someone would assume it :)
14:35:09 <gastaldi> lol
14:35:09 <ivannov> maintaining and devloping two parallel releases of a same product
14:35:23 <agoncal> It could also be a nice branding "wanna generate Java SE 8 code ? Use Roaster 8 !"
14:35:49 <lincolnthree> until im convinced we need to break backwards compatability, im not even sure a new naming convention is worth discussing ;)
14:35:49 <gastaldi> agoncal, or maybe we could have a separate library with those changes
14:36:02 <agoncal> ivannov Take the diamond example. Something simple but implemented in 2 different ways.
14:36:23 <ivannov> maybe make roaster 8 (or whichever version you pick) backward compatible. but two parallel releases - that's a nono
14:36:50 <gastaldi> yeah, I think we already have enough work
14:38:01 <gastaldi> agoncal, how do you generate non-diamond code in Roaster?
14:38:15 <ivannov> what's the problem of making roaster support different versions of Java SE? if I remember correctly, Roaster uses CDI. and CDI is quite flexible in that direction. but even if it doesn't use CDI, it can still be made flexible to give you the impl for the Java SE version you require
14:38:29 <gastaldi> Roaster does NOT use CDI
14:38:45 <agoncal> Well, if we can find a "common" ground (ex creating a class) and then, have seperate functionnalities per version (ex diamond), that would be ideal. I just think it could get messy
14:39:08 <ivannov> OK, even without CDI, you can still tell it somehow elegantly which Java SE you target
14:39:10 <gastaldi> agoncal, the diamond code you mention is being generated by "setLiteralValue" ?
14:39:29 <agoncal> gastaldi can't remember now, let me have a look...
14:40:45 <gastaldi> I believe that supporting different Java SE versions is part of the statement generation feature
14:41:07 <gastaldi> the structure haven't changed between versions, well, except for default methods
14:41:12 <gastaldi> *hasn't
14:41:29 <agoncal> gastaldi FieldSource  : setType("java.util.List<String>").setLiteralInitializer("new java.util.ArrayList<>()");
14:42:22 <gastaldi> agoncal, yes, that's a diamond notation, right?
14:42:33 <agoncal> gastaldi Yes. Done by hand ;o)
14:42:46 <gastaldi> I think it's the only way in Roaster to do that :)
14:42:47 <agoncal> gastaldi That goes with ROASTER-4
14:42:48 <jbossbot> jira [3ROASTER-4] Having Parameterize interface bit more typed [10Open (Unresolved) Feature Request,7 Major,6 Unassigned] https://issues.jboss.org/browse/ROASTER-4
14:43:24 <agoncal> If Roaster needs to break backward compatibilty to support all this, why not Roaster 3 ?
14:44:11 <lincolnthree> agoncal: i agree that *if* we need to break compatability, then sure, but im not convinced we need to
14:44:25 <lincolnthree> agoncal: i don't consider adding new methods and types breaking backwards compatibility
14:44:31 <lincolnthree> agoncal: that's just progress
14:44:51 <agoncal> lincolnthree Maybe we don't. I don't know Roaster enough. I was just concerned with not evolving for an API incompatibility
14:44:57 <gastaldi> +1, we can deprecate the current functionality if justified
14:45:11 <agoncal> Good. So everybody is in sync ;o)
14:45:14 <gastaldi> mbenson did a great job in the last refactoring. Any thoughts?
14:45:17 <lincolnthree> agoncal: nah, we'll make it happen
14:45:26 <lincolnthree> gastaldi: agreed
14:45:34 <lincolnthree> gastaldi: matt did a fantastic job
14:45:49 <agoncal> gastaldi Are you talking about the method generation support ?
14:46:04 <gastaldi> no, about the *Source classes
14:46:11 <gastaldi> he knows Roaster A LOT
14:46:28 <agoncal> gastaldi No, didn't have a look at it. Will chek
14:46:29 <agoncal> check
14:47:18 <agoncal> Because, coming back to stacks, for the Java EE 7 stack, it would be good to *easily* generate Java SE 7 syntax
14:47:26 <gastaldi> I understand
14:47:51 <agoncal> Last topic I wanted to share with you
14:47:53 <agoncal> Addons
14:48:06 <agoncal> I started to write something here : FORGE-2380
14:48:06 <jbossbot> jira [3FORGE-2380] Brainstorming on Addon Management [10Open (Unresolved) Task,7 Major,6 Unassigned] https://issues.jboss.org/browse/FORGE-2380
14:48:24 <agoncal> As we all know, addons are very important (the more, the better)
14:48:41 <agoncal> But at the moment they are spread throughout people repos
14:48:43 <lincolnthree> agoncal: YES, this is really important.
14:48:52 <agoncal> It would be good if :
14:48:59 <gastaldi> right, I don't remember the reason why the Deltaspike is not on the website
14:49:09 <agoncal> 1) The Forge website could reference them all
14:49:12 <lincolnthree> gastaldi: because it doesn't do anything
14:49:21 <gastaldi> lincolnthree, it adds the necessary deps afaik
14:49:27 <lincolnthree> gastaldi: and because nobody in the community wanted us to improve it. and even the deltaspike team
14:49:28 <agoncal> 2) That each addon would be tested with the latest Forge version
14:49:29 <lincolnthree> didn't care
14:49:34 <gastaldi> ah sure
14:49:38 <lincolnthree> gastaldi: we spoke to rafael about this
14:49:44 <gastaldi> that makes sense
14:50:06 <agoncal> I know this is a *huge* effort, but would be great
14:50:11 <lincolnthree> agoncal: yeah it is a big deal
14:50:17 <gastaldi> agoncal, yeah, that would be a good idea. We could make Travis CI to do that for us
14:50:19 <agoncal> I don't know what travis is capable of dong ;o)
14:50:28 <agoncal> doing
14:50:28 <lincolnthree> gastaldi: not sure we could make travis do that
14:50:36 <lincolnthree> gastaldi: we'd have to test with updated addons
14:50:49 <lincolnthree> gastaldi: that means a custom build somehow
14:50:53 <gastaldi> we just need to set the version.forge property when starting the build
14:50:58 <lincolnthree> gastaldi: ehhh… not exactly
14:51:07 <gastaldi> why not?
14:51:09 <agoncal> gastaldi yes, that's what I thougth
14:51:11 <lincolnthree> gastaldi: that will handle core forge addons
14:51:18 <gastaldi> version.forge and version.furnace ?
14:51:19 <lincolnthree> gastaldi: but not other addons that are not core
14:51:24 <lincolnthree> gastaldi: i guess tha tmight be enough
14:52:01 <gastaldi> lincolnthree, that would need to be built separately, we can't cover every addon dep during build
14:52:13 <lincolnthree> gastaldi: right
14:52:49 <lincolnthree> gastaldi: one thing i think we'd need to fix is a test harness version override. i don't think that the test harness would honor the forge version selected during the build
14:52:58 <lincolnthree> gastaldi: unless the versions were set dynamically in the pom
14:53:01 <agoncal> Just before releasing a new version of Forge (or maybe just 2.x versions, not minors)
14:53:03 <lincolnthree> gastaldi: and we can't guarantee that
14:53:33 <agoncal> lincolnthree Well, when creating a addon with Forge, we make sure the propertie is set (if not, we don't build)
14:53:45 <gastaldi> agoncal, we have a list of the addons in a YAML file. We could write a script that takes that YAML file and run builds against a provided version
14:54:04 <lincolnthree> agoncal: right, but that's not something we can actually enforce, really.
14:54:05 <agoncal> gastaldi Good. Didn't know there was a yaml file
14:54:27 <gastaldi> agoncal, they are the addons-community.yaml in https://github.com/forge/website-data
14:54:37 <mbriskar> lincolnthree, gastaldi I'd like to extend FurnaceDeploymentScenarioGenerator functionality to deploy default addons
14:54:38 <gastaldi> *are in the..
14:54:53 <gastaldi> mbriskar, default addons? what do you mean?
14:55:43 <mbriskar> gastaldi, we have such rexster addon that is useful in tests by default
14:55:56 <gastaldi> mbriskar, just add it in the pom.xml as a test scope
14:56:16 <gastaldi> and use @AddonDependencies only
14:56:46 <gastaldi> we'll need to get that CDI Extension bug fixed
14:57:07 <agoncal> The idea also is to update the status on the website. Example "This addon has been tested with the latest Forge version"
14:57:23 <mbriskar> gastaldi, I wanted to deploy it only if -Dmaven.surefire.debug property is on.. Otherwise it may slow down the tests
14:57:24 <gastaldi> agoncal, +1
14:57:27 <lincolnthree> agoncal: +1
14:57:42 <gastaldi> agoncal, please add this idea as an issue in the Github Issue in forge/website
14:57:43 <lincolnthree> mbriskar: that's an interesting idea, and relates somewhat to what we are discussing now
14:57:46 <agoncal> This way the website has *all* the addons, and we quickly know which one work or not (very useful)
14:58:19 <gastaldi> mbriskar, add it to a maven profile?
14:59:14 <gastaldi> btw, I would like to clarify why we use JIRA and Github issues in our development process
14:59:58 <jbossbot> git issue opened [12website] (7open) 6agoncal Having addon compatibilty status11 https://github.com/forge/website/issues/23
15:00:01 <gastaldi> JIRA is used for our products and core projects. Github issues for community projects (addons, website, etc).
15:00:09 <agoncal> gastaldi Done : https://github.com/forge/website/issues/23
15:00:17 <jbossbot> git issue [12website] (7open) 6agoncal Having addon compatibilty status11 https://github.com/forge/website/issues/23
15:00:25 <gastaldi> thank you! jbossbot already warned us :)
15:00:37 <agoncal> gastaldi He is fast ;o)
15:00:43 <gastaldi> indeed ;)
15:00:47 <lincolnthree> gastaldi: that's not exactly accurate afaik? but im not really sure of the official stance on that
15:00:53 <lincolnthree> gastaldi: unless you know that for sure
15:01:10 <gastaldi> I don't, I am asking if that is the official statement
15:01:31 <lincolnthree> gastaldi: what does the project governance rules state? aren't you involved in that? :)
15:01:44 <mbriskar> lincolnthree, is the profile solution to that problem?
15:02:01 <gastaldi> GoldenGate requires that JIRA must be used. Some projects use Github issues, so that is a bit unclear
15:02:32 <lincolnthree> gastaldi: then I think JIRA is the requirement
15:02:47 <lincolnthree> mbriskar: you mean using a POM profile?
15:03:00 <mbriskar> lincolnthree, to deploy rexster addon only if debugging
15:03:35 <lincolnthree> mbriskar: a profile can be used to activate on a system parameter, yes, but as gastaldi said, that will only work if we are using @AddonDependencies, bare, without specifying the exact addons in the test case
15:03:46 <lincolnthree> mbriskar: if that is good enough, then yes.
15:03:49 <lincolnthree> mbriskar: that would solve the problem
15:04:01 <gastaldi> I am so smart :)
15:04:05 <gastaldi> lol
15:04:10 <gastaldi> am not
15:04:31 <mbriskar> lincolnthree, I don't like that conditions :-) I want it to be deployed everytime
15:05:41 <gastaldi> mbriskar, so what's the problem in declaring it in the pom.xml without profiles?
15:06:06 <mbriskar> gastaldi, graph is deleted after execution so rexster is useless when not in debug mode
15:06:19 <lincolnthree> mbriskar: don't like which conditions?
15:06:29 <mbriskar> lincolnthree, to specify bare @AddonDependencies
15:06:34 <gastaldi> so you don't want it to be deployed everytime? I am confused
15:06:58 <mbriskar> gastaldi, everytime when debug mode is present. But in every test regardless of @AddonDependencies
15:07:25 <mbriskar> gastaldi, every furnace-arquillian test
15:07:40 <gastaldi> why so?
15:07:51 <gastaldi> what's the problem in using base @AddonDependencies?
15:07:55 <lincolnthree> gastaldi: because some tests have @AddonDependencies with specific deps
15:07:58 <gastaldi> s/base/bare
15:08:03 <gastaldi> ah-ha
15:08:03 <lincolnthree> gastaldi: and it's not useful when you are not running in debug mode
15:08:28 <gastaldi> lincolnthree, maybe add a if="" in the @AddonDependency ?
15:08:34 <mbriskar> yes it is basically to provide helping hand to everybody debugging the graph state in windup with rexster running along
15:08:49 <mbriskar> gastaldi, but then I would need to alter all of the tests we have in windup
15:09:27 <gastaldi> hmm, maybe implement a org.jboss.forge.arquillian.DeploymentListener  ?
15:09:40 <lincolnthree> gastaldi: does that API exist?
15:09:47 <gastaldi> lincolnthree, you wrote it! :)
15:09:59 <lincolnthree> gastaldi: lol
15:10:02 <gastaldi> org.jboss.forge.arquillian.AddonDeployment.listener()
15:10:55 <gastaldi> ok, let's wrap up
15:10:59 <gastaldi> #nexttopic
15:10:59 <jbott> No next topic. Use #addtopic to add topics.
15:11:06 <lincolnthree> gastaldi: so I did
15:11:10 <gastaldi> #endmeeting