And you can just stick the "file" with the list of allowed dependencies in the repo and pass it as a dependency to your plugin in the config. Nobody can fool with it there so its better than putting it in the source repository (e.g. SVN, CVS). And its easier than trying to put it on a whole 'nother web location.
Thanks. -- Lee On Tue, Jul 1, 2008 at 3:27 AM, Ishaaq Chandy <[EMAIL PROTECTED]> wrote: > doh! I should have thought of that. :) > > Thanks > > 2008/7/1 Minto van der Sluis <[EMAIL PROTECTED]>: > > > > > Hi Ishaaq, > > > > I am not sure but it seems like the dependency plugin is a good candidate > > to > > look at. Looking at the output of dependency:tree it shows scope > informatie > > as well. > > > > regards, > > > > Minto van der Sluis > > > > > > Ishaaq Chandy wrote: > > > > > > ok, will give it a go - any pointers on the API I should be looking at > in > > > order to determine an artifact's scope? I'm not scared of trawling > > through > > > maven's source code myself, but a helpful pointer in the general > > direction > > > would be appreciated. > > > > > > Thanks, > > > Ishaaq > > > > > > 2008/7/1 Stephen Connolly <[EMAIL PROTECTED]>: > > > > > >> I would think that you should be able to do that from an enforcer > > rule... > > >> > > >> Of course I have not tried... > > >> > > >> But if you need those kind of changes in enforcer, that would be a lot > > >> quicker to get than changes to Maven's core... > > >> > > >> Plus, such a custom rule would be of use to not just commercial > > >> projects, but also open source projects > > >> > > >> On Tue, Jul 1, 2008 at 8:19 AM, Ishaaq Chandy <[EMAIL PROTECTED]> > wrote: > > >> > 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] > > >> >> > > >> >> > > >> > > > >> > > >> --------------------------------------------------------------------- > > >> To unsubscribe, e-mail: [EMAIL PROTECTED] > > >> For additional commands, e-mail: [EMAIL PROTECTED] > > >> > > >> > > > > > > > > > > -- > > View this message in context: > > > http://www.nabble.com/fatal-dependency-management-flaw-in-maven--tp18188983p18211522.html > > Sent from the Maven - Users mailing list archive at Nabble.com. > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > -- -- Lee Meador Sent from gmail. My real email address is lee AT leemeador.com
