Which build tool to build the Apache Flex SDK(was: Ant vs. Maven vs. Gradle)

[Yennick Trevels <ye...@gmail.com>]

I'm splitting up the previous thread because there was imo too much
confusion between which build tool to use for the Flex SDK and which build
tools we should support (aka create artifacts for). These are two totally
different discussions.

This thread can be used to discuss which build tool we should use to build
to Flex SDK.

Re: Which build tool to build the Apache Flex SDK(was: Ant vs. Maven vs. Gradle)

[Yennick Trevels <ye...@gmail.com>]

>
> Can't we stick with ant and deploy the resulting
> artefacts (.swc etc) with maven ant plugin in a public maven repo?
>
> Seems that people want the sdk available via maven that doesn't mean it
> has to be build by maven itself


+1

Re: Which build tool to build the Apache Flex SDK(was: Ant vs. Maven vs. Gradle)

[Roland Zwaga <ro...@stackandheap.com>]

>
> Can't we stick with ant and deploy the resulting
> artefacts (.swc etc) with maven ant plugin in a public maven repo?
>
> Seems that people want the sdk available via maven that doesn't mean it
> has to be build by maven itself
>

+1

Re: Which build tool to build the Apache Flex SDK(was: Ant vs. Maven vs. Gradle)

[Arnoud Bos <ar...@artim-interactive.nl>]

Can't we stick with ant and deploy the resulting 
artefacts (.swc etc) with maven ant plugin in a public maven repo?

Seems that people want the sdk available via maven that doesn't mean it has to be build by maven itself

On Feb 28, 2012, at 12:03 PM, Yennick Trevels wrote:

> I'm splitting up the previous thread because there was imo too much
> confusion between which build tool to use for the Flex SDK and which build
> tools we should support (aka create artifacts for). These are two totally
> different discussions.
> 
> This thread can be used to discuss which build tool we should use to build
> to Flex SDK.

Re: Which build tool to build the Apache Flex SDK(was: Ant vs. Maven vs. Gradle)

[Left Right <ol...@gmail.com>]

> Seems that people want the sdk available via maven that doesn't mean it
has to be build by maven itself
This has my vote too! :)
If we are to vote on tools, then Ant, scons, Make in this particular order.

Re: Which build tool to build the Apache Flex SDK(was: Ant vs. Maven vs. Gradle)

[Bryan Hunt <se...@gmail.com>]

On Tue, 28 Feb 2012 22:33:35 +0200, Left Right <ol...@gmail.com> wrote:
Non-text part: multipart/alternative
> 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

I read your entire email. Just one question, does Scons store the
dependent jar files, and their dependencies, outside the VCS (currently
Subversion), or do you think it would be a good idea to Version Control
the Apache Commons libraries alongside the Flex SDK source code?

Regards,

Bryan Hunt

Re: Which build tool to build the Apache Flex SDK(was: Ant vs. Maven vs. Gradle)

[Left Right <ol...@gmail.com>]

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

Re: Which build tool to build the Apache Flex SDK(was: Ant vs. Maven vs. Gradle)

[Bryan Hunt <br...@sentimentmetrics.com>]

On Tue, 28 Feb 2012 12:13:14 -0500, Michel Boudreau <mi...@gmail.com> wrote:
Non-text part: multipart/alternative
> I'd agree with the comment about it doesn't matter what we build Flex with
> as long as it's available on the maven repo.  I haven't looked at the build
> script just yet, but as long as it doesn't have external dependencies that
> needs to be added to the codebase, I don't have any issue with using Ant.
> 
> However, I do think it would be nice to have a more separated build
> process.  Think about it, just because we are building some new flex code
> doesn't mean the compiler necessarily changes or any other piece within the
> framework.   One of the main problems I've found with the Flex framework
> when using Maven is that Adobe never considered how it does things and
> keeps using Ant standards.  This normally results in weird configurations
> when it comes to setting up flex-mojos.

>From conversations with Marvin Froever of Flex-Mojos, my understanding
was that the biggest problem was that the Flex SDK contained
non-standard versions of Apache Commons lang, etc. 

The lack of disciplined dependency management with an eye towards the
larger eco-system was the most significant problem.

Ant is fine for small projects, I used to use it myself back in 2003 or
thereabouts but for larger stuff, with big teams it sucks.

Regards,

Bryan Hunt

Re: Which build tool to build the Apache Flex SDK(was: Ant vs. Maven vs. Gradle)

[Michel Boudreau <mi...@gmail.com>]

I'd agree with the comment about it doesn't matter what we build Flex with
as long as it's available on the maven repo.  I haven't looked at the build
script just yet, but as long as it doesn't have external dependencies that
needs to be added to the codebase, I don't have any issue with using Ant.

However, I do think it would be nice to have a more separated build
process.  Think about it, just because we are building some new flex code
doesn't mean the compiler necessarily changes or any other piece within the
framework.   One of the main problems I've found with the Flex framework
when using Maven is that Adobe never considered how it does things and
keeps using Ant standards.  This normally results in weird configurations
when it comes to setting up flex-mojos.

If we can remove that barrier, it would be pretty awesome.

M

On Tue, Feb 28, 2012 at 8:04 AM, Nicholas Kwiatkowski <ni...@spoon.as>wrote:

> Agreed.
>
> One thing to note -- not very many of the IDEs have good support for
> anything other than ANT.  Additionally, for those not using
> Eclipse/IntelliJ, Maven is pretty much locked away.  ANT has really good
> support on command line and is well understood by most developers.  That
> being said, I like Maven and what it can do for us, but I'm not for raising
> the barrier to entry.
>
> Create patch, and attach it to the JIRA ticket with your build script.
>  That is all that has to happen :)
>
> -Nick
>
>
> On Tue, Feb 28, 2012 at 6:50 AM, Justin Mclean <justin@classsoftware.com
> >wrote:
>
> > Hi,
> >
> > My personal opinion but I'm not sure this  discussion is really getting
> us
> > anywhere.
> >
> > If someone would like to submit patches/code to the SDK to make it work
> > under another build system please do so. Until then the question of which
> > build system we use is not really an issue as we have an Ant build system
> > that works.
> >
> > Thanks,
> > Justin
> >
> >
>



-- 
Michel Boudreau

"If at first you don't succeed, use a bigger hammer." - Unofficial motto of
the Royal Electrical and Mechanical Engineers

Re: Which build tool to build the Apache Flex SDK(was: Ant vs. Maven vs. Gradle)

[Nicholas Kwiatkowski <ni...@spoon.as>]

Agreed.

One thing to note -- not very many of the IDEs have good support for
anything other than ANT.  Additionally, for those not using
Eclipse/IntelliJ, Maven is pretty much locked away.  ANT has really good
support on command line and is well understood by most developers.  That
being said, I like Maven and what it can do for us, but I'm not for raising
the barrier to entry.

Create patch, and attach it to the JIRA ticket with your build script.
 That is all that has to happen :)

-Nick


On Tue, Feb 28, 2012 at 6:50 AM, Justin Mclean <ju...@classsoftware.com>wrote:

> Hi,
>
> My personal opinion but I'm not sure this  discussion is really getting us
> anywhere.
>
> If someone would like to submit patches/code to the SDK to make it work
> under another build system please do so. Until then the question of which
> build system we use is not really an issue as we have an Ant build system
> that works.
>
> Thanks,
> Justin
>
>

Re: Which build tool to build the Apache Flex SDK(was: Ant vs. Maven vs. Gradle)

[Justin Mclean <ju...@classsoftware.com>]

Hi,

My personal opinion but I'm not sure this  discussion is really getting us anywhere.

If someone would like to submit patches/code to the SDK to make it work under another build system please do so. Until then the question of which build system we use is not really an issue as we have an Ant build system that works. 

Thanks,
Justin

Re: Which build tool to build the Apache Flex SDK(was: Ant vs. Maven vs. Gradle)

[Bryan Hunt <br...@sentimentmetrics.com>]

On Tue, 28 Feb 2012 12:03:34 +0100, Yennick Trevels <ye...@gmail.com> wrote:
Non-text part: multipart/alternative
> I'm splitting up the previous thread because there was imo too much
> confusion between which build tool to use for the Flex SDK and which build
> tools we should support (aka create artifacts for). These are two totally
> different discussions.
> 
> This thread can be used to discuss which build tool we should use to build
> to Flex SDK.

Maven, Ant or Make.

Regards,

Bryan Hunt