On 06/10/15 15:10, Ian Clarke wrote: > On Tue, Oct 6, 2015 at 4:39 AM, xor <[email protected]> wrote: > >>>> 2) What can Maven do which Ant cannot do? Do we need those features? >>> Dependency management There is a lot of important context being missed in this discussion, in particular what our needs are and what our current set-up actually involves.
There are 2 sets of dependencies here: 1. Run-time dependencies 2. Build-time dependencies Run-time dependencies we have to include in the deployed Freenet, and we now deploy them as separate jar files. Some of them (notably Bouncy Castle) have to be signed by their upstream authors, but in any case we keep track of versions, hashes etc in the file dependencies.properties. We need to keep them up to date ourselves for auto-update to work. Some of the files are included in freenet-ext.jar but the idea is to transition to each of the dependencies being deployed separately. This allows cheaper, faster updating, and makes packaging easier. In other words, we *already have the infrastructure* for run-time dependencies, and we could easily arrange to download them - the only reason this doesn't happen automatically is that we'd like to have anonymous developers - and traceably downloading files during a normal build is not acceptable in that case. Note that there are indeed active anonymous developers, notably Eleriseth, and the hope is we will have more in future. What we could do is have the build script ask the user whether they want us to download the files from the web, and possibly whether they want to use Tor to do so etc - or even Freenet (we have the CHK's!). At the moment, there is an over-long error message to this effect, and the user needs to either download the files themselves or edit override.properties. Arguably this is yet another case of a clash between security and convenience. But it could be fixed with a build.sh script (AFAICS it's better that ant itself doesn't ask questions?). Build-time dependencies should generally be packaged on the user's Linux distribution. We need to provide a script which searches for them and automatically updates override.properties. And if they are not present, it offers to install them, if possible via the package manager using sudo. For the minority of Windows/Mac developers, we should of course make it easy - e.g. build.sh/build.cmd could install them via Maven/Gradle. Deploying build-time dependencies via Gradle is not appropriate IMHO: It means updating them is *our* responsibility, and it increases our maintenance overheads as a result, and reduces the end-user's security. Updating JUnit etc is the distribution's responsibility, not ours. And anything that doesn't get updated is a security risk. Of course, we could generate the run-time dependencies and build.properties via Gradle. That would require more work.
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Devl mailing list [email protected] https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
