Aha! I think I see now why you think I have a special case, I think its a simple case of misunderstanding - for which I'll assume all fault is mine :)
Locked down versioning is not really the point. Even if we had a locked versions of the test (in fact we do lock the test dependency versions) and plugin artifacts that does not really resolve my issue: 1. I need to ensure that the build only uses legally vetted versions of compile/runtime dependencies. 2. On the other hand I can also have test and plugin deps (whether or not I lock down their versions is immaterial) but my vetting process over them are negligible and in fact, in the case of metrics gathering (for e.g. code coverage etc) developers are actively encouraged to be on the lookout for new tools that can improve the build process and QA. It is quite possible and permissible that the latter actually have licenses that forbid redistribution. The easiest way to implement the latter is to point the build to the maven central repo or an internal proxy of it. The correct way to implement the former is via a restricted-access internally managed repo. It turns out the two are incompatible because of maven's inability to differentiate between the sources for differing-scoped artifacts. However, I still do not think that these are niche, edge-case requirements, I think they are quite reasonable. It just so happens that I do not lock down plugin versions, but even if I did do so the problem does not go away. The crux of the problem is that I want to proxy to maven central for some types of artifacts and to my private repo for other types of artifacts and I don't want maven to bleed dependency resolution from one repo to the other. Oh, and as I mentioned in passing in a previous post, we don't really need long-term repeatability of the build - once it is released, an old version of our product rarely needs to be checked out of source-control and rebuilt from scratch. In the short term it is less likely that our build will break because a plugin got upgraded - and even if it did, because we use continuous integration it would quickly be caught and fixed. However, this is really a side issue, if I had to lock down the versions of the plugins to resolve my problem, I'd happily do that, but I don't think that solves the problem. Regards, Ishaaq 2008/6/30 Jörg Schaible <[EMAIL PROTECTED]>: > Ishaaq Chandy wrote: > > Hmm, so in short you're telling me that I should completely > > lock down my > > build process simply because maven can't differentiate > > between plugin deps, > > test deps and compile/runtime deps. > > > > 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: > > > > 1. Legally, it makes sense to vet all the compile-time and runtime > > dependencies of a distributable product (commercial or otherwise). > > > > 2. The build processes, the tests, the metrics are all > > internal processes > > and are not part of the distributable product, in some scenarios the > > restriction on the artifacts used to produce these can be > > different from > > those on the compile/runtime deps. In my commercial scenario, > > having to > > process, lock-down and manage each of these deps using the > > same stringent > > procedures used to vet normal compile/runtime deps is just needless > > make-work - there is no legal requirement to subject my dev > > team to this. > > > > Now, it would be perfectly reasonable to state that maven > > does not do what I > > need it to do, that the maven developers are not interested > > in solving this > > scenario and that I should look elsewhere. > > Well, your scenario is somewhat strange. In such an environment one major > QA goal is normally the reproducability of a release. Without the locking > down your build environment can change even for tagged and released code > arbitrarily and the result of a repeated build is no longer deterministic. > > > 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. > > For me is does simply not make sense to have the repo requirement without > the locked versions. Maybe that's the reason why your use case is unique, > nobody has asked for it yet and Maven only supports the scenario in > combination with the locked versions. > > - Jörg > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
