First of all, the text below is purely informational. If you are passionate
about the subject - save that for the time you have the time to read. This
is not an argument in favor of any particular technology, since you will
see that I'm preaching one thing, but I'm voting here for entirely
different thing :)
I.e. I'm for the least changes (stay with Ant), and whoever wants - let
them do whichever they like, so long they don't limit the others by what
they do.
I did this once for the class to, sort of, explain the evolution in the
engineering thought on how to build the project. And I used the below for
the purposes of explanation (I actually had more examples, such as Lisp
system and some pom file, but you wouldn't know what to do with the first,
and the second is just too long):
==================================================== GNU Make
# Builds the tld.assignments.KantantanimDao
# and tld.assignments.KantantanimStore
# classes for the assignment 12, course 20478, Java basics
SHELL := /usr/bin/env bash
LIB = $(PWD)/lib/mysql-connector-java-5.1.18-bin.jar
BARE_BIN = bin
BIN = $(PWD)/$(BARE_BIN)
SRC = $(BIN):$(PWD)/src/tld/assignments:$(LIB):$(CLASSPATH)
JFLAGS = -g -d "$(BIN)" -cp "$(SRC)"
JC = javac
JAR = jar
JRFLAGS = cf $(BARE_BIN)/kantantanim.jar -C "$(PWD)/classes" tld -m
manifest.mf
.SUFFIXES: .java .class
.java.class:
$(JC) $(JFLAGS) $*.java
CLASSES = src/tld/assignments/KantantanimDao.java \
src/tld/assignments/KantantanimStore.java
default: classes
$(JAR) $(JRFLAGS)
$(shell ./generate_mock_data)
classes: $(CLASSES:.java=.class)
clean:
$(RM) -r $(BIN)/*
$(RM) -r $(PWD)/classes/*
=========================================================== Ant
<project name="Kantantanim Store"
basedir="."
default="all"
>
<target name="all"
description=
"Builds the tld.assignments.KantantanimDao
and tld.assignments.KantantanimStore
classes for the assignment 12, course 20478, Java basics">
<javac srcdir="${basedir}/src"
destdir="${basedir}/classes"
classpath="${basedir}/lib/mysql-connector-java-5.1.18-bin.jar"
debug="on"
/>
<exec executable="generate_mock_data"/>
<jar destfile="${basedir}/bin/kantantanim.jar"
basedir="${build}/classes"
>
<manifest file="manifest.mf"/>
</jar>
</target>
</project>
=========================================================== scons
# Builds the tld.assignments.KantantanimDao
# and tld.assignments.KantantanimStore
# classes for the assignment 12, course 20478, Java basics
from subprocess import call
call('./generate_mock_data')
env = Environment(JARCHDIR = 'classes')
Java('classes', 'src')
env.Jar(target = 'bin/kantantanim.jar', source = ['classes/tld',
'manifest.mf'])
These aren't necessarily the perfect examples, but they were made to
illustrate how the programmers used to approach the same problems, and how
this changed with the time.
1. Make: It was quite disorganized, a lot of manual, repetitive work, a
very primitive language.
2. Programmers realized that there are certain problems such as lack of
organization and code reuse. Tools like Ant and Maven appeared. Ant and
Maven were inspired by the "cure of all things" at that time - XML - which
is, frankly, not the cure of all things and when used as a programming
language performs extremely bad. However, the advantage of organizating the
code allowed an abstraction into groups (goals in Maven) and thus certain
workflows appeared and were hardcoded into Maven behavior. Ideologically,
Maven is superior to Ant as it offers an added value of the discipline. It
tells what to do and what is necessary to do during the build. But there is
also a bunch of problem that Maven introduced. People, who planned it
didn't know what actual requirements will be like, and so they built the
system to be too rigid where it shouldn't. The assumption that XML will
provide a good language to write complex builds appeared to be false. In a
certain sense Maven allowed creation and maintenance of more complex
projects, but it leaves a lot to wish for. Worst yet, it failed to provide
all the same flexibility available in Ant or Make. So, if you happened to
have a very experienced person to build the system for your project, they
will prefer Ant or Make or (later on that) scons :) because they have more
options.
So, at some point programmers realized that using XML to write programs
(and build scripts *are* programs!) is not going to succeed. Pre-defining
and pre-configuring part of the program and exposing them in XML creates
arbitrary limitations, complicates debugging, obscures the purpose of the
program.
3. And this is how I see scons. It is for a change written in a very good
programming language. In fact, the build scripts are for all intents and
purposes Python programs! (If you didn't know, the first two lines in the
build script, which are not comments, aren't actually any special scons
code, it's plain Python code to perform a system call.
Since Python is a real programming language, contrary to XML, all
programming concepts apply. You can build real programs! You wanted to
design your build in a way it has graphical interface with buttons and
pop-ups? - you can! You wanted to play music when certain events in the
build occur - absolutely! Whatever Python can do, you can do just as well
in your build script. Debugging? - you have a real debugger!
Autocompletion? - Of course there is! And it's not like in Ant or Maven for
the known tasks and DTD only - you write a function, an it will pop up in
the autocompletion just the same.
However, there are enterprises, who don't really care about quality, or
about easiness or about perfection of their tools or products. Because the
main ideology in that sector is profit, and best is not the most
profitable, because solid good is much cheaper. And so long certain
solutions work for them, they don't want to change, because their goal is
to apply as little effort as possible and to use the solution that
restricts their personnel as much as possible, because hiring high quality
personal, who could possibly make use of advanced tools, isn't in their
best interests.
>From my few stabs at Google, it appears that not a single person had ever
before tried to use scons for compiling ActionScript. So, I can feel
innovating! :) And I'm now trying to learn the system in more details, to
understand how the existing functions behave and so on :)
Best.
wvxvw
