Furnace addon-manager should include optional non-addon dependencies as if they were not optional ------------------------------------------------------------------------------------------------- Key: FORGE-1823 URL: https://issues.jboss.org/browse/FORGE-1823 Project: Forge Issue Type: Enhancement Components: Furnace (Container) Affects Versions: 2.5.0.Final Reporter: Lincoln Baxter III Assignee: Lincoln Baxter III Priority: Blocker Fix For: 2.5.1.Final {code} jsightler 5:10 lincolnthree: Could "optional" dependencies help here as well? jsightler 5:10 http://maven.apache.org/guides/introduction/introduction-to-optional-and-... 5:10 sbryzak left the room (quit: Ping timeout: 264 seconds). lincolnthree 5:11 jsightler: possible actually..... 5:11 jsightler: actualllyyyyyyyy 5:11 jsightler: if the runtime scoped non-addon dependency were marked as optional, we could just decide to include that 5:11 jsightler: as a one-off case jsightler 5:12 lincolnthree: fwiw, this definition of "optional" is not what I would have thought it to be. but it sounds like it could be useful for this scenario. :) lincolnthree 5:12 yeah, we already slightly hijacked optional 5:13 jsightler: given that it would be impossible for addons to consume optional dependencies provided by addons that included them, this would technically work - if not be slightly confusing gastaldi 5:13 I think using the BOM is the best way to go lincolnthree 5:13 gastaldi: im not sure about that gastaldi 5:13 why not? lincolnthree 5:14 gastaldi: that requires that people actually use the bom, which is a good idea, but it doesn't solve the problem for 3rd party addons gastaldi 5:14 it worked here lincolnthree 5:14 gastaldi: it works for us, not for everyone else gastaldi 5:14 3rd party addons could have a BOM too... lincolnthree 5:14 gastaldi: we can't expect everyone to require that people use boms or dependencyManagement to control this. 5:15 gastaldi: i think a runtime/optional non-addon dependency would be fine to include in the addon deployment 5:15 gastaldi: we already changed the way poms are handled for forge-addon classified elements 5:15 gastaldi: now we're changing how those addons include deps as well, but only in forge-addon classified deps 5:15 gastaldi: i think this works 5:16 jsightler: yes, this does what we want 5:17 gastaldi: it would look like this: http://paste2.org/0UVzK6jL 5:17 gastaldi: im not a fan of the syntax.....but.... given the options 5:17 gastaldi: using this as a hack/toggle seems tolerable to me jsightler 5:17 lincolnthree: Nice. :) 5:18 lincolnthree: Mostly I just think maven chose an awful word for this. lincolnthree 5:18 jsightler: yeah they did... jsightler 5:18 lincolnthree: Optional=="ignore me transitively in every case" lincolnthree 5:18 jsightler: right 5:19 gastaldi: at which point, it wouldn't matter what scope the optional dependency is... 5:19 gastaldi: think about it 5:19 gastaldi: when would you ever want an "optional" library in an addon 5:19 gastaldi: never 5:19 gastaldi: there's no situation where it makes sense gastaldi 5:19 right... lincolnthree 5:19 gastaldi: because the classpath is isolated from things that depend on it 5:20 gastaldi: so nothing could *ever* provide the optional dependency except itself 5:20 gastaldi: it would be like writing classes that can never be classloaded ever 5:20 gastaldi: lol 5:20 gastaldi: like a dog chasing its tail {code}