2008/7/1 Stuart McCulloch <[EMAIL PROTECTED]>: > > my perspective (as a maven user) is that if I was concerned > about dragging in artifacts with certain licenses then I'd want > to be 100% sure I had everything locked down build-wise. > > that seems easier to defend (legally-speaking) than relying > on scopes, where you could drag in something accidentally > and may only find out when it's too late >
Well, assuming that a hypothetical implementation of maven only downloads compile/runtime deps from the repo that we actively control and restrict access to, wouldn't that be safe enough? I can't think of a scenario where this would lead to accidents unless someone somehow "accidently" got the permission to deploy to this restricted repo and then "accidently" deployed an unvetted artifact to it. Even if you mark something as a compile-scope dep when it should really have been a test-scope dep you would immediately hit a problem because then this hypothetical implementation of maven would abort because the artifact would not be in the vetted repo (even though it may legitimately exist in the test/plugin repo). Of course, I admit that just because I can't see a way for this to reasonably "accidently" happen does not mean that it is impossible. > > Look, I know I'm starting to sound like a whining complainer and I wouldn't > > blame you if you got annoyed, but look at it from my perspective: put > aside > > for a moment what maven can and can't do, and how it implements > dependency > > management. Now consider this: > > > > FYI, I'm not a core Maven developer so I won't get annoyed ;) > > Phew!! Was holding my breath there :) > > > 1. Legally, it makes sense to vet all the compile-time and runtime > > dependencies of a distributable product (commercial or otherwise). > > > > agreed - some people vet at release time, others all the time > Vetting at release time is one possibility I considered initially but it would be too costly to do it so late, I'd rather know immediately when an incompatible dep is about to be added - that way there is no need to rewrite source code to remove all links to the dependency in question. > > I guess it depends on your company - where I used to work > they were just as strict with build and test artifacts because > it's then easier to maintain a "cleanroom" status > And if that works for you then great - but for us it looks like needless work - given that the only reason we're locking down is for legal reasons and there are no such reasons to lock down on build and test artifacts. even if it's possible technically, I think it's valid to ask whether > this is the right thing to do - of course that's just my opinion > ( i.e. not everything that can be implemented should be ;) > > Amen, brother > > I guess that what I was just hoping for was that these would in fact be > > considered reasonable requirements; not as niche as, it turns out, you > > obviously think they are and that, on the contrary, there is a way to > solve > > this using maven. Unfortunately, given your answers, it seems to be that > > this is not the case. A pity. > > > > imho, discussion helps everyone, and presenting a counterpoint is > usually a good way to check requirements - so even if you decide > to look elsewhere, I hope this has been semi-helpful > It has.
