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

[Karel Piwko (Assigned) (JIRA)]

     [ https://issues.jboss.org/browse/SHRINKWRAP-344?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Karel Piwko reassigned SHRINKWRAP-344:
--------------------------------------

    Assignee: Karel Piwko

    
> 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
>
> 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 at 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.  

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira