[shrinkwrap-issues] [JBoss JIRA] (SHRINKWRAP-344) MavenDependencyResolver.loadMetadataFromPom should descend into a lower-level object

MavenDependencyResolver.loadMetadataFromPom should descend into a lower-level object ------------------------------------------------------------------------------------ Key: SHRINKWRAP-344 URL: https://issues.jboss.org/browse/SHRINKWRAP-344 Project: ShrinkWrap Issue Type: Task Components: ext-resolver Reporter: Andrew Rubinger Assignee: Karel Piwko Fix For: resolver-2.0.0-alpha-1 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(a)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/j... (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.