[31/05/2005 00:45:48] brett: this one is what we didn't agree on previously, and is in the same vein [31/05/2005 00:46:02] *** evenisse has signed off IRC (Ping timeout). [31/05/2005 00:46:05] *** evenisse_ is now known as evenisse. [31/05/2005 00:46:26] brett: some way to give the endpom the ability to take control of its dependencies [31/05/2005 00:46:49] jdcasey: I think this is more of a fleshing-out-of-DependencyManagement thing [31/05/2005 00:47:09] jdcasey: let's keep the dep specifications clean so it's not confusing about what's transitive and what's not [31/05/2005 00:47:34] jdcasey: we could have a section inside [31/05/2005 00:47:43] jdcasey: and suppress for that project only [31/05/2005 00:48:05] jason: so using that jdbc example, when would you want to do that? [31/05/2005 00:48:48] jdcasey: if my project uses velocity, which has a bad jdbc reference, I'd (a) log a MEV issue against velocity, and (b) add an entry for jdbc3 in in MY pom. [31/05/2005 00:49:02] jdcasey: one is a long-term fix, the other is a stop-gap [31/05/2005 00:49:33] jdcasey: IMO this shouldn't be easy to use. [31/05/2005 00:49:50] brett: well, that's not really fair :) [31/05/2005 00:50:02] jdcasey: what I mean is that it shouldn't be transitive [31/05/2005 00:50:13] brett: I need to use one class from commons-foo [31/05/2005 00:50:30] jason: that would be the peanut [31/05/2005 00:50:31] jdcasey: and every project that encounters this (even down the food chain) should be aware and be warned to vote for the velocity fix... [31/05/2005 00:50:34] jdcasey: just my 2c [31/05/2005 00:51:11] brett: but commons-foo actually depends on commons-kitchensink, commons-furniture and commons-shed to compile [31/05/2005 00:51:26] jdcasey: maybe my POM can declare a warning on the offending upstream project, so anyone who uses my POM will have the warning printed out [31/05/2005 00:51:37] brett: their design is rather coupled, so they can't split commons-foo [31/05/2005 00:51:54] brett: but I really don't want commons-kitchensink because it is a 1gb dependency [31/05/2005 00:52:00] jdcasey: hehhe [31/05/2005 00:52:06] brett: I just need to use Couch.class from commons-furniture [31/05/2005 00:52:58] brett: I'm also using elements of commons-foo that extend couch [31/05/2005 00:53:07] brett: so I want to depend on foo, but exclude the shed and the kitchen sink [31/05/2005 00:53:16] jdcasey: brett: so you'd filter commons-kitchensink and commons-shed, with warnings that these filters are for commons-foo [31/05/2005 00:53:33] brett: I don't know where the warnings come from [31/05/2005 00:53:35] jdcasey: anyone using your project as a dep would have warnings printed that you've opted to filter these... [31/05/2005 00:53:48] brett: so they get the two deps or not? [31/05/2005 00:53:58] jdcasey: they'd have to re-filter those. [31/05/2005 00:54:16] brett: not sure [31/05/2005 00:54:24] jdcasey: dunno...but this seems like we're compensating for poorly-defined dependencies [31/05/2005 00:54:29] brett: we are [31/05/2005 00:54:38] brett: but not everyone even uses maven [31/05/2005 00:54:41] jdcasey: and IMO that shouldn't be something we do systematically [31/05/2005 00:54:44] jdcasey: true [31/05/2005 00:54:59] jdcasey: and not everyone's project is fit for use...for a variety of reasons [31/05/2005 00:55:18] brett: yeah, I don't want to cripple Maven users from using poorly designed stuff [31/05/2005 00:55:23] jdcasey: but if I can block a dep from an upstream project, then people downstream from me might have failures without knowing why [31/05/2005 00:56:10] brett: yes, you're right [31/05/2005 00:56:20] jdcasey: (though I suppose if you adhere to the idea of declaring the dependencies you actually use, that should be less of an issue) [31/05/2005 00:56:43] jdcasey: the problem is this: we're editing someone else's definition of what their project needs [31/05/2005 00:56:47] brett: but its even more cryptic otherwise [31/05/2005 00:56:52] jdcasey: and they're in more of a position to know [31/05/2005 00:57:00] brett: they can always add it back (going to the resolution of the last point) [31/05/2005 00:57:12] brett: so if you depend on plexus-velcoity, would you expect to have to exclude jdbc [31/05/2005 00:57:16] jdcasey: right, by declaring an explicit dep at their level, yes? [31/05/2005 00:57:30] jason: this specific case is to say prevent jdbc from ending up in a dist? [31/05/2005 00:57:32] jason: yes? [31/05/2005 00:57:32] jdcasey: I would, even though that's not exactly intuitive [31/05/2005 00:57:40] jdcasey: it's a product of the troubleshooting process [31/05/2005 00:58:11] jdcasey: what does jdbc3 actually do to the velocity dependency? what's the issue with jdbc3 wrt velocity? [31/05/2005 00:58:11] brett: jdcasey: I just worry that pollutes a grater number of poms [31/05/2005 00:58:21] brett: it doesn't exist for one [31/05/2005 00:58:37] jason: what if we said that scope=none is only for endpoms? [31/05/2005 00:58:51] brett: I think that's what jdcasey is sayingh [31/05/2005 00:58:53] jason: and the deploy would choke it saw that scope [31/05/2005 00:58:55] jdcasey: brett: you're right, but it'll go dormant as soon as the upstream POM is fixed...then it's just verbosity. like a spleen or something for your POM [31/05/2005 00:59:03] jason: hehe [31/05/2005 00:59:23] brett: [31/05/2005 00:59:35] jdcasey: jason: yes, except I'd propose to keep endpom-only info out of deps at all costs [31/05/2005 00:59:45] jason: so spleen, tosils, and appendix scopes [31/05/2005 00:59:45] brett: jdcasey: upstream pom doesn't get fixed until next release [31/05/2005 00:59:46] jdcasey: it confuses what it transitive and what's not [31/05/2005 00:59:48] jason: that won't be confusing [31/05/2005 00:59:49] brett: though ranges muddy that too [31/05/2005 01:00:16] jdcasey: brett: ranges will remove any protection that offers... [31/05/2005 01:00:34] brett: verbosity is definitely passive though. IT's not going to start eliminating from other deps [31/05/2005 01:00:40] brett: if you go to the endpom it could [31/05/2005 01:00:52] jdcasey: this seems like a housekeeping task related to dependencies...isn't that the meaning of the element dependencyManagement? [31/05/2005 01:01:22] brett: yes, which to this point hasn't been transitive [31/05/2005 01:01:26] brett: so that would be more consistent [31/05/2005 01:02:08] jdcasey: and you don't need the full dependency to exclude...only g:a, right? [31/05/2005 01:02:26] brett: in dep mgmt it would be a dep element [31/05/2005 01:02:39] brett: I don't know, we're not up to syntax yet [31/05/2005 01:02:53] jdcasey: I guess what I'm saying is that this should be in but not inside [31/05/2005 01:03:08] brett: let's wait and see [31/05/2005 01:03:12] jdcasey: ok [31/05/2005 01:03:34] *** hohi has joined #maven. [31/05/2005 01:04:09] brett: alright, what do we agree on? [31/05/2005 01:04:16] brett: - need for filtering at some level? [31/05/2005 01:04:19] jdcasey: one more comment and I'm done: the whole point of using dependencyManagement instead of managedDependencies or whatever is that we could add other things besides inside of it... [31/05/2005 01:04:46] jason: i agree [31/05/2005 01:04:54] jdcasey: brett: +1 [31/05/2005 01:05:05] jason: +1 [31/05/2005 01:05:14] evenisse: ok [31/05/2005 01:05:31] brett: ok, so filtering from the current pom: [31/05/2005 01:05:42] brett: - knock out selected dependencies from down the chain, or, [31/05/2005 01:05:55] brett: - turn off transitivity for poms you declare and add back missing stuff? [31/05/2005 01:06:07] brett: (turn off transitivity for selected deps you declare) [31/05/2005 01:07:26] jason: i think the first option [31/05/2005 01:07:28] jdcasey: (got confused by those last two points) [31/05/2005 01:08:05] brett: jdcasey: do you say "velocity is not transitive. I'll pretend I'm using m1 and specify its dependencies manually because I don't trust it" [31/05/2005 01:08:24] brett: (that was option 2) [31/05/2005 01:08:32] jdcasey: oh, definitely option 1 then [31/05/2005 01:08:39] brett: ok [31/05/2005 01:08:40] jdcasey: damn, talk about punishing the user :) [31/05/2005 01:09:06] brett: so we are down to whether such exclusions are transitive [31/05/2005 01:09:14] brett: benefits of transitivity: [31/05/2005 01:09:40] brett: - defaults more likely to be correct [31/05/2005 01:10:22] brett: - if a different dependency of the endpom later introduced the same dependency, it would be included instead of being missed [31/05/2005 01:10:27] brett: downsides: [31/05/2005 01:10:40] brett: - less authoratative (though endpom still has that option) [31/05/2005 01:11:42] brett: - not sure where to put it [31/05/2005 01:11:45] brett: did I miss anything? [31/05/2005 01:12:28] jdcasey: sorry, not sure where to put what? [31/05/2005 01:12:53] brett: syntax is less clear, because all transitive stuff is currently in dependencies proper [31/05/2005 01:12:59] jdcasey: ah [31/05/2005 01:13:22] brett: taking the earlier example [31/05/2005 01:13:34] brett: say plexus-velocity depended on velocity, and blocked jdbc [31/05/2005 01:13:51] jdcasey: well, I think my position on this is clear... :) [31/05/2005 01:14:04] brett: that means plexus velocity says "I don't need jdbc" [31/05/2005 01:14:31] jdcasey: brett: if it's transitive, does that mean that merely fixing the velocity pom isn't enough anymore? now the intermediary pom must be fixed as well? [31/05/2005 01:14:31] brett: anyone dependening on plexus-velocity and only that says "I need plexus-v and what it needs" [31/05/2005 01:14:34] jason: i don't think i would put that in the plexus-velocity pom but would filter it out in an app say [31/05/2005 01:14:53] brett: jason: but every app using p-v directly needs to give it [31/05/2005 01:15:03] brett: and if velocity, gets fixed, every app is now "wrong" [31/05/2005 01:15:03] jdcasey: I tend to think those types of modifications should be between the offending POM and the user's POM... [31/05/2005 01:15:24] jdcasey: not "wrong" just redundantly specified [31/05/2005 01:15:28] brett: right [31/05/2005 01:15:32] jason: i agree with john here [31/05/2005 01:15:47] jason: the POMs need to be fix and the user should control how they deal with the crap POM [31/05/2005 01:16:02] jason: s/fix/fixed/ [31/05/2005 01:16:10] jdcasey: one thing though: we should make an effort to warn the user about upstream exclusions like this... [31/05/2005 01:16:15] brett: jason: there are cases it can't be fixed. see commons-foo :) [31/05/2005 01:16:32] brett: jdcasey: I thought you were against upstream exclusions [31/05/2005 01:16:33] jdcasey: brett: you mean design-time things? [31/05/2005 01:16:40] brett: yes [31/05/2005 01:16:45] brett: metadata is correct, just bad [31/05/2005 01:16:49] jdcasey: the upstream exclusions can still exist, they just won't propagate [31/05/2005 01:17:15] brett: but why would p-v even bother specifying it? [31/05/2005 01:17:18] brett: its not an app [31/05/2005 01:17:27] jdcasey: I mean, we all know that commons-logging has some design issues, right? if that's the problem, and it's a big enough problem, maybe people should find an alternative... [31/05/2005 01:17:38] jdcasey: hmm [31/05/2005 01:18:07] jdcasey: well, in the case of jdbc3 p-v cannot build because of the missing artifact, no? [31/05/2005 01:18:19] brett: I'm all for fixing bad data. But let's not cripple our user and send them flocking to other Maven alternatives because it doesn't do what they want [31/05/2005 01:18:41] jason: jdcasey, p-v would build fine [31/05/2005 01:18:42] brett: wherever it is, we can grep the repo and chase them down [31/05/2005 01:18:58] jdcasey: I agree. but I also feel like shielding users from upstream problems will only ensure that those problems remain in place... [31/05/2005 01:18:59] brett: p-v would have to exclude jdbc to build [31/05/2005 01:19:06] jdcasey: it's a balancing act, no doubt [31/05/2005 01:19:16] brett: as would every single artifact using velocity, or p-v [31/05/2005 01:19:22] jdcasey: what if we DO propagate the exclusion, but warn the user of that? [31/05/2005 01:19:23] brett: until you downloaded it [31/05/2005 01:19:30] jason: i'll post something to the velocity list and see if they will fix the build [31/05/2005 01:19:33] brett: yes, that I think is the way to go [31/05/2005 01:19:51] brett: jason: +1, but velocity is just a great example. There are plenty of others. [31/05/2005 01:19:51] jdcasey: brett: I can live with that... [31/05/2005 01:20:05] jdcasey: right [31/05/2005 01:20:29] brett: imo, you have to trust the dep that what it is telling you about itself is right [31/05/2005 01:20:29] jason: i definitely don't want to become like the gump harassment team [31/05/2005 01:20:36] brett: lol [31/05/2005 01:20:41] jason: an RSS feed people can opt into would be good [31/05/2005 01:20:45] jdcasey: but it's not enough to simply exclude the offending artifact...we need to attach some pointer to the project that references that artifact, too [31/05/2005 01:21:09] brett: jdcasey: yes, transitive dep reporting improvements will have to come about for a few such reasons [31/05/2005 01:21:27] jdcasey: ok [31/05/2005 01:21:47] brett: so have I won you over or am I being placated ;) [31/05/2005 01:21:50] jdcasey: actually, that solution will produce the fewest reactionary poms... [31/05/2005 01:22:00] jdcasey: you've won me over, provided the reporting is good [31/05/2005 01:22:00] brett: yes, you get hotspots to fix [31/05/2005 01:22:30] jdcasey: (sorry jason ;) [31/05/2005 01:25:46] brett: jason: what are you thinking? can you think of a counter example where it would be bad for the dep to block one of its own deps? as in legitimate bad, not malicious bad [31/05/2005 01:26:52] brett: I think we're done after this. I don't have the energy for subversion and releases. [31/05/2005 01:30:44] jason: for "a dep to block one of its own deps" ? [31/05/2005 01:30:54] jason: not sure what you mean there [31/05/2005 01:31:39] brett: jason: if p-v swallows jdbc because it doesn't use that part of velocity - any harm for something using p-v? [31/05/2005 01:31:57] jdcasey: jason: propagate exclusions [31/05/2005 01:32:21] brett: because theoretically, if p-v claims not to touch it, and your project needs it, it should depend on v/jdbc itself [31/05/2005 01:33:16] jason: i probably wouldn't try to exclude it in p-v [31/05/2005 01:33:25] jason: yes, it could harm someone using the jdbc resource loader [31/05/2005 01:33:35] jason: would fail at runtime [31/05/2005 01:33:42] brett: so its a runtime dep? [31/05/2005 01:33:47] jason: yes [31/05/2005 01:34:01] jason: unless you extend the jdbc resource loader in your project [31/05/2005 01:34:05] jdcasey: seems like there's a good chance we're arguing over something that will rarely, if ever, be used. [31/05/2005 01:34:27] brett: in this example, but in practice I think it happens a bit, judging by the complaints [31/05/2005 01:34:31] jdcasey: ok [31/05/2005 01:34:39] jdcasey: but I mean wrt propagation [31/05/2005 01:34:43] jdcasey: not specification itself. [31/05/2005 01:34:52] jason: maybe just exclusions in all the packaging plugins and in most cases they won't get used [31/05/2005 01:35:16] jason: 95% of the time it wouldn't be utilized but could be in these cases like velocity [31/05/2005 01:35:32] jason: packaging/assembly stuff [31/05/2005 01:35:44] jason: base class to deal with excludes for the weirdo POM cases [31/05/2005 01:35:50] jason: instead of scope=none [31/05/2005 01:35:53] brett: so when you say you wouldn't filter it out from p-v, you're happy to require jdbc to build p-v? because you expect p-v to expose all functionality that v does? [31/05/2005 01:36:38] brett: conversly, if velocity was split properly, would p-v depend on all the extras? [31/05/2005 01:36:46] jason: nope [31/05/2005 01:36:51] brett: this is wanted for the artifact ant tasks too, so we can't really isolate it to plugins [31/05/2005 01:37:14] jason: if vel was split property the jdbc resource loader would be in its own build [31/05/2005 01:37:31] jason: i'm not going to limit anything in p-v, i would leave that to the user [31/05/2005 01:37:39] brett: right, and anyone wanting to use it would have to pull it in themselves [31/05/2005 01:38:13] brett: but limiting it in p-v just means the user gives it themselves if they want the jdbc resource loader (they add back jdbc, which they can) [31/05/2005 01:38:45] jdcasey: so it works for the 80% case as-is, and the other 20% can specify the extra jdbc-ish stuff themselves? [31/05/2005 01:39:35] brett: right, and the risk they bear is identical to the proper solution where they have to know their runtime deps. it's not quite as good, but its closer [31/05/2005 01:40:24] brett: then we get a short list of duds in the repo we can go after, rather than a cast of thousands (admittedly pointing to a short list, but it should be easier to adjust when things get fixed) [31/05/2005 01:40:28] jdcasey: brett: when you said it happens a bit in practice, were you referring to the need to propagate these exclusions, or merely the need to exclude at the endpom? [31/05/2005 01:40:53] brett: was just referring to exclusion in general [31/05/2005 01:41:07] brett: apart from missing deps, there isn't a lot of benefit to excluding if not for bundling [31/05/2005 01:41:11] jdcasey: ok, so propagation is probably more a point of maintainability than anything... [31/05/2005 01:41:14] brett: yes [31/05/2005 01:41:38] brett: but it would mean non-app stuff like -pv could build out of the box without hacking the v pom [31/05/2005 01:41:45] brett: because of the missing dep [31/05/2005 01:42:03] jdcasey: in principle I agree with jason that my library shouldn't provide a transitive dep set that could break a person's app, but I also agree that the end user should take on more responsibility for optional deps like jdbc [31/05/2005 01:42:37] brett: I don't see it as breaking an app though [31/05/2005 01:42:54] brett: the man in the middle only declares what it needs [31/05/2005 01:43:05] jdcasey: it does if the user intends to use the jdbc functionality of velocity, and reading the velocity pom expects the jdbc stuff to be there. [31/05/2005 01:43:08] brett: depending on that shouldn't assume you get anything more than that [31/05/2005 01:43:33] brett: but the user doesn't need velocity. [31/05/2005 01:43:37] brett: they need p-v :) [31/05/2005 01:43:42] jdcasey: :) [31/05/2005 01:43:44] brett: if they needed v, they'd depend on it [31/05/2005 01:44:16] jdcasey: I'm not qualified to determine the difference between the two...just assumed one was a plexus wrapper for the other [31/05/2005 01:44:29] brett: oh, I'm not talking specifics [31/05/2005 01:44:46] brett: just saying if your sole dependency is A, the fact it uses B shouldn't matter [31/05/2005 01:45:00] jdcasey: but politically, it makes sense for a project to be able to shield its users from something Really Bad until it gets fixed... [31/05/2005 01:45:10] jdcasey: not that it'll happen that often [31/05/2005 01:45:11] brett: because next week it might reimplement velocity as C and still do everything it said it would [31/05/2005 01:45:33] brett: jdcasey: that's my line anyway [31/05/2005 01:46:10] jdcasey: I know, and that's what I agree with, from a practicality POV...but not from a principals POV [31/05/2005 01:46:14] jdcasey: :) [31/05/2005 01:46:34] jdcasey: I think brett's soln is more maintainable and repo-friendly for fixing those problems [31/05/2005 01:48:16] brett: ok, so what remains is how to block it out. we can think over the cases and see what we can come up with there