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] > >
