On Tue, Oct 6, 2015 at 4:39 AM, xor <[email protected]> wrote:

> [Sorted/trimmed/amended the quotes for readability]
>
> On Monday, October 05, 2015 12:52:08 PM Ian Clarke wrote:
> > On Mon, Oct 5, 2015 at 12:57 AM, xor <[email protected]> wrote:
> > Right, but it appears that solutions exist for this with Gradle.
>
> "Apache Ant" = 1 320 000 Google hits
> "Gradle" = 957 000 Google hits
>

That's a terribly unscientific way to assess the popularity of a tool.  As
a professional Java developer please take my word for it when I say that
Apache Ant is an outdated tool, it has been replaced by Maven, and Maven is
in the process of being replaced by Gradle (although we're early in that
process).  If you don't believe me just ask Google, they selected Gradle as
the standard build tool for Android.  Or failing that just ask almost any
other professional Java developer, they'll tell you the same thing.


> > > 2) What can Maven do which Ant cannot do? Do we need those features?
> >
> > Dependency management
>
> By that, do you merely mean downloading some JARs from a fixed URI and
> putting
> them into the current directory; or is it actually even able to install
> current versions of stuff on the system's package manager?
>
> IIRC, our fred Ant builder used to download a fixed freenet-ext.jar to the
> current directory on its own, so that's not a Maven seller yet.
>

No, Gradle does dependency resolution, it would automatically download and
assemble all of the components of freenet-ext.jar, while making it
trivially easy to update to more recent versions of dependencies.

Think of Gradle and Maven as being similar to apt-get on Debian.

But if Maven is indeed capable of using the package manager, I would
> actually
> get VERY hungry for it :)
> I prefer installing binaries from the package manager instead of having
> Maven
> shove truckloads of them into some backyard directory, as only by using the
> package manager I get automated security updates.
>

Maven can assemble everything into a single .jar file.


> > By not using a modern dependency management
> > system we're creating a significant barrier to entry for new contributors
> > to the code.
>
> I speculate you conclude that from at least one of those assumptions:
> The assumption that someone who first wants to compile a project is
> incapable
> or unwilling to install software (such as Ant) to do so.
>

No, I conclude that a modern Java developer will want to use build tools
that have been more-or-less standard for the last decade, instead of an
outdated tool like ant that almost no actively developed Java project uses
any more.


> @Unwilling: I don't know how it works for other people, but whenever I
> compile
> a new piece of software, I already am 100% expecting to have to install a
> TRUCKLOAD of stuff. Almost every software needs some kind of library.
> Ant is just one of them. And there are Ubuntu etc. packages, so people can
> get
> it easily.
>

That is because you are apparently unfamiliar with modern Java build tools
which have proper dependency management.


> > If someone wants to use both Freenet and Tor then they can download them
> > individually, but I see no good reason to bundle two independent pieces
> of
> > software just because they both solve related (but different) problems.
>
> Well, the question is if the user's care about the difference:
>

That seems like a very peculiar criteria with which to decide to bundle any
two projects.  If a user didn't care about the difference between Freenet
and Angry Birds, should we bundle it with Angry Birds?

The only good criteria for bundling two pieces of software is that the
combination is dramatically more useful than either individually (eg. if
one depends on the other).  That wouldn't be the case here, it would just
be two somewhat related pieces of software glued together for no good
reason.

Ian.

-- 
Ian Clarke
Founder, The Freenet Project
Email: [email protected]
_______________________________________________
Devl mailing list
[email protected]
https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl

Reply via email to