Hi Ishaaq, Ishaaq Chandy wrote:
> 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. You might take a different approach using two different settings.xml and a internal-test profile (name it whatever you like). You can specify the settings file on the command line for maven. settings-product.xml: - define an own location for the local repo - define the approved company repo as remote repo - set the approved company repo as mirror for anything settings-internal.xml: - define an own location for the local repo - define the approved company repo as remote repo - activate profile "internal-test" by default If you run CI with settings-product.xml, you ensure that nothing has crept in. You may even run Ci twice, once for each setting to ensure no breakage. Your devs may choose also between the two settings, but they will have to put anything into the internal-test profile (deps, plugins, includes/excludes for the compiler, javadoc and surefire plugin) that depends on "unapproved" artifacts. - Jörg --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
