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