that would possibly work if there is a way for the enforcer to retrieve scope information from the artifact - is this possible?
Is it also possible for transitive dependencies, i.e., will the enforcer let me allow the same artifact to go through when using it as a transitive dep of a test-scope artifact but at the same time disallow the same artifact when it is used as the transitive dep of a compile-scope artifact? I am unfamiliar with the API for custom enforcer rules and the documentation on the maven site does not give me the level of detail I am looking for in order to be able to answer these question easily myself. Ishaaq 2008/7/1 Stephen Connolly <[EMAIL PROTECTED]>: > 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] > >
