To my mind what you want to do is write an enforcer custom rule that checks all the compile and runtime scoped dependencies against a whitelist server...
I'd have a webserver that can e.g. take a query of the form http://someurl/.../check?groupId=____&artifactId=_____&version=_____&classifier=____ and either returns TRUE or FALSE. Then write an enforcer custom rule, the config provides the base url to check against and specifies the scope to apply the rule to. That way you don't care what repository any dependency came from, and you just maintain your compile and runtime whitelist(s) BTW, you might want different whitelists for compile and runtime scopes! You might compile against a CDDL licensed jar but use a runtime dependency that is commercial -Stephen On Tue, Jul 1, 2008 at 12:07 AM, Ishaaq Chandy <[EMAIL PROTECTED]> wrote: > Well, that could possibly work except that there is no way I can get that > internal locked down build to actually run - remember that maven does > everything via plugins - even the compilation is done using a plugin - so > all the plugins would have to be added to the closed repo - thus polluting > it with potentially legally incompatible artifacts. > > Regards, > Ishaaq > > 2008/7/1 Jörg Schaible <[EMAIL PROTECTED]>: > >> 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] >> >> > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
