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]
