Would it be possible to write an enforcer plugin rule that checks the licenses of the dependencies?
regards, Wim 2008/6/30 Jörg Schaible <[EMAIL PROTECTED]>: > Hi Ishaaq, > > Ishaaq Chandy wrote: > > Well, not knowing who else uses maven out there I have no > > reasonable way to > > verify or deny your claim that this is not useful for 95%. I > > can only say > > that I find it hard to believe that only 5% of maven users > > would conform to > > both of the following criteria > > Maybe those users simply use Maven in a different way? ;-) > > > - but then again, I don't really know: > > > > 1. You're writing a commercial app (or any app for that > > matter which has a > > potentially incompatible license with some or all of its > > dependencies, so, for e.g. a BSD app with a GPL dependency). > > > > and > > > > 2. If said app is supposed to be redistributable (or, in some > > other way, > > violate the license agreement with its dependencies). > > > > > > If you are in the unfortunate situation of satisfying both > > criteria then you > > only have 3 options w.r.t. implementing your build system with maven: > > > > 1. Just continue to use the standard maven dependency system > > and don't worry > > about dependencies with incompatible licenses and hope that no lawyer > > notices. Possibly works for a lot of small projects, not > > really an option > > for me - and I'm sure not a practice that Apache or Maven would be > > officially encouraging. > > > > 2. Same as 1 above, but have a post-build manual process to > > make sure that > > no incompatible dependencies have crept in. > > How should an incompatible dependency have "crept" in? If someone on your > side add a new dep, it is his repsonsibility to clear up the dep and its > transitive deps also. Since a released artifact never changes, its deps will > also never change. > > > The problem with > > this approach > > is that you have to make sure you catch these incompatible > > dependencies early on else it may be hard to fix your source code > > after-the-fact. Note > > also that incompatible dependencies can creep in due to an updated > > transitive dependency, not just a dependency explicitly > > listed in your own > > pom.xml. > > Even an update of a dependency must have been done by someone on your side. > Same responsibilities apply. > > > 3. Lock down your repository completely so that all > > dependencies will have > > to be vetted - a bit over the top IMHO - considering that in > > reality you > > only need to vet the compile/run-time scope dependencies - > > and certainly not > > the test-scope and the plugin dependencies (along with their > > respective transitive dependencies). > > This is *exaclty* what we do. Simply use a company POM where you declare > your versions in the dependencyManagement (and lockdown the versions of the > plugins). Remember that those versions will talke precedence about the > versions of the transitive deps. You may even declare dependencies with > "unwanted licenses for product" with test scope. And you should really lock > down plugins, otherwise a release is not repeatable in a defined way. > > > As for your solution of setting up multiple environments, I > > am not sure that > > it is practical - I have a large multi-project build that I > > need to be able > > to run in one go using my continuous build environment. That > > build not only > > compiles the projects but also runs tests, check coverage, metrics, > > publishes site info etc. It would be really hard and > > cumbersome to have to > > split this out into multiple environments. In short, I'd have > > to do this in > > at least two passes - one pass would compile the build and > > the second pass > > would run tests etc. However, even this is problematic as the > > first pass > > still requires plugins (for e.g. the Antlr plugin) whose transitive > > dependencies would leak across into the non-plugin repository (as > > mentioned in my previous post). > > > > Am still happy for someone to tell me I am being an idiot and > > that this is > > really simple to setup with maven (that would solve a number > > of issues for > > me), but I fear this is not the case. > > If somebody want to break the rules, he will find a way. If you do not want > your ordinary devs to take the responsibility for the transitive deps, you > may setup a company wide repo with approved artifacts and force everyone to > use that repo as mirror of central. Then you'll need a specialized team to > approve and upload new artifacts manually like it is done for MAVENUPLOAD. > > - Jörg > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
