12:17:38 PM) kpiwko: 3/ as what I call "void" method
(12:17:42 PM) kpiwko: I gave you the example
(12:17:44 PM) ALR: kpiwko: What's the void method in that line?
(12:17:58 PM) ALR: "Prepares something for a different method"?
(12:17:59 PM) kpiwko: the point is that loadEffectivePom does actually nothing
(12:18:50 PM) kpiwko: if you don't call importXYZ() afterwards, internal state of the object is modified but you'll still get packaged nothing at all
(12:20:08 PM) kpiwko: so, MavenDepedencyResolver.loadMetadataFromPom() is almost a "void" method as well
(12:20:26 PM) kpiwko: I think we should support "void" methods
(12:20:37 PM) kpiwko: and we should make their usage broader
(12:20:41 PM) pil is now known as pil-dinner
(12:22:47 PM) ALR: So just a terminology mismatch
(12:22:51 PM) kpiwko: e.g. instead of having MavenDepedencyResolver.loadMetadataFrom() and MavenDepedencyResolver.loadDepedenciesFromPom() we should have a single "void" method and its call will expose a different interface which will allow user to includeLoadedDependencies() or activateLoadedRepositories(), method names are subject to change
(12:22:52 PM) ALR: "void" methods return void.
(12:22:58 PM) kpiwko: yep, I know
(12:23:07 PM) ALR: So you wanna drill into something else.
(12:23:18 PM) kpiwko: I was searching for better word but in vain
(12:23:20 PM) ALR: HOw do you get back up to the MavenDependencyResolver level?
(12:23:30 PM) ALR: In Descriptors it's "up"
(12:23:40 PM) jose_freitas josefreit@189.101.213.101 entered the room.
(12:23:52 PM) kpiwko: interesting
(12:24:00 PM) kpiwko: there is no up concept in swr
(12:24:10 PM) kpiwko: do you think it will help users?
(12:24:36 PM) kpiwko: I don't think it is really needed
(12:24:59 PM) ALR: kpiwko: Well, then you kinda break fluency.
(12:25:07 PM) kpiwko: so user is not able to loadPom->includeAdditionalArtifacts->loadAnotherPom
(12:25:21 PM) ALR: By drilling down into another object you then can't get back up to MavenDependencyResolver to continue messing w/ its properties.
(12:25:38 PM) kpiwko: he has to loadPom->loadAnotherPom->addAdditionalArtifacts
(12:25:41 PM) ALR: What's the motivation for this new level object then?
(12:26:09 PM) jose_freitas: good afternoon guys. I'm ashamed for being late.
(12:26:10 PM) kpiwko: reducing number of methods exposed to user
(12:26:20 PM) ALR: Just to reflect that you need to call loadMetadataFromPom just before includeLoadedDependencies ?
(12:26:21 PM) kpiwko: jose_freitas: welcome!
Jaikiran jamezp jbossbot jbott jdlee jeand_ jhuska jose_freitas
(12:26:27 PM) ALR: jose_freitas: Welcome, don't be ashamed.
(12:26:32 PM) kpiwko: ALR: basically yes
(12:26:34 PM) ALR: Grab the log and read along to catch up
(12:27:16 PM) ALR: kpiwko: It's elegant so long as you can get back up IMO
(12:27:35 PM) ALR: It's better than throwing IllegalStateException for not loading metadata from POM first
(12:28:01 PM) jose_freitas: (just had a 4h hours meeting with an angry client.)
(12:28:02 PM) ALR: kpiwko: OT: Be sure to "Like" facebook.com/arquillian
(12:28:25 PM) kpiwko: how do you get an IDE to correctly resolve type with up()?
(12:28:36 PM) kpiwko: if there are multiple entry points?
(12:31:03 PM) ALR: <T>
(12:31:40 PM) ALR: https://github.com/shrinkwrap/descriptors/blob/master/api-base/src/main/java/org/jboss/shrinkwrap/descriptor/api/Child.java
(12:32:02 PM) ALR: Then let each entry point define its own impl
(12:33:12 PM) kpiwko: both in api-maven and impl-maven?
(12:33:23 PM) ***kpiwko hard stop in one hour
(12:33:50 PM) ALR: I'd have to see the cases further for all entry points
(12:34:10 PM) ALR: But you could have N interfaces extending Child which supply T as well in api
(12:34:22 PM) kpiwko: well, I think it is doable
(12:34:31 PM) ALR: I suspect we're getting too fine-grained at this point.
(12:34:37 PM) kpiwko: possibly
(12:34:39 PM) ALR: Do we have enough to write up a JIRA a move on?
(12:35:06 PM) kpiwko: I guess so
(12:35:27 PM) ALR: OKee. So action item is a task to rework this.