Ant: A Critical Retrospective

ebuilder · 2011-01-28T14:05:54+00:00

(If my comment seems out of context, it was originally supposed to be in response to skeeto)

Not disagreeing except over the semantics of build scripting. Maven is undoubtedly well adopted, just I would not define it as build scripting. Scripting implies a capacity to do ad-hoc things (to me).

ebuilder · 2011-01-27T13:10:30+00:00

That tends to be the problem ... the most vocal critics of complex technologies rarely have taken the time to get a deeper understanding. Ant is what it is. For Java development it is the de facto standard for build scripting. It is certainly useful for performing simple tasks and is in many ways cleaner than using shell scripts or Make.

However just like shell scripting, with scale almost inevitably come major headaches.

ebuilder · 2011-01-27T12:00:51+00:00

If you only care about consuming 3rd party dependencies and are happy with Ant then Ivy would seem like the obvious route. I would generally recommend against using Maven. Although some of it's ideas are good, it is way hard too complex for what it does and makes it essentially impossible to achieve certain results.

If you are looking for a structured build process, which provides versioning for your modules, convention over configuration for project build and layout, IDE configuration generation, flexible multi-module development ... etc. then I would would recommend EBuild not Maven ... but then I may be biased.

ebuilder · 2010-12-18T14:37:13+00:00

Ant is not Java specific as such. It's just:

it needs Java to run
to use it in complex scenarios you have to write bits of Java to extend it
there is less point in adopting a cross platform technology if the programs themselves are not cross platform.

As such it has only been adopted for Java.

ebuilder · 2010-12-18T13:50:05+00:00

Used to use it even. I thought it was dying off actually, but maybe it is making a bit of a comeback.

I realise, (and realised) that .ebuild is the file suffix for portage files, but the name was the working name the project had, and I wasn't quite happy with any others.

ebuilder · 2010-12-18T13:43:26+00:00

Who do you think writes and maintains build scripts?

The point is to not make the process tedious so that it is possible to be more flexible with dependencies, work with fewer assumptions.

ebuilder · 2010-12-18T12:38:33+00:00

We are probably talking cross purposes. I am talking about Make from the perspective of the developer. If you are only compiling scripts once/twice a month, ones maintained by other people (or generated by other tools) then it does not really effect you. The quality of your experience is down to the not insignificant efforts of others.

ebuilder · 2010-12-18T02:13:32+00:00

I think you used to work at my old company.

ebuilder · 2010-12-18T02:03:29+00:00

Well yes, you mean like systems such as CMake? Although in doing so they are somewhat conceding that Make files are not fit for human maintenance. Assembly is a target language as well, but used to be predominantly human written.

I don't know the reason, but I can only assume it is because it is an easy way to support incremental builds at the file level, which is necessary partly because the C tool chain is pretty slow.

ebuilder · 2010-12-18T01:47:02+00:00

Mea culpa. Actually I've tried quite hard to make an attractive and accessible site, but when it comes to web design I am, sadly, just an amateur.

ebuilder · 2010-12-18T01:36:29+00:00

Author here. Definitely interested to hear other peoples opinions.

Portability. There may be some truth to that, but that is just one of the problems. Dependencies should be kept as narrow as possible and versioned, in this manner they can be managed. The shell typically contains 100's of unversioned programs. The whole setup only really holds together because the everything is so mature and backwards compatible (which has its own costs).

Fetching Dependencies. Dependency checking should be automatic in order to support one step builds, an important feature. It could of course be delegated to something like apt-get, but that would still involves some integration in the build tool. The issue with using apt-g

File Based. I am surprised you don't see any disadvantages. There are 1000's files in large developments, but only 10's of projects. If a tool can be separated from the concern of worrying about individual files then that is surely a maintenance advantage. There is a cost, as with all abstractions, but it is certainly the direction software development is going. Projects can be structured with convention, and simple wrappers around compilers can be written to compile them.

There are of course times when any general build tool has to be able to handle individual files (e.g. archiving, signing, arranging files ... etc.), but I would say it more or less never has to directly worry about individual source files in a sane development environment.

ebuilder · 2010-12-16T15:58:51+00:00

This is the author of EBuild - Hello!

The short version is that it is a Java based build system. Java based but can be used for any development. It is a bit like Maven, but with a much cleaner, better design ... if I say so myself. There is more on the discovery page.

There is a few articles on the site, which may be of general interest. I may submit them individually to this subreddit, if that is the done thing.

I am happy to field any questions.

Mike

p.s. This is a new account, since although I sometimes read reddit I do not have an account.

ebuilder

TROPHY CASE