EasyAnt / Auto-audroid

4 views
Skip to first unread message

jeanloui...@gmail.com

unread,
Mar 28, 2009, 1:14:41 PM3/28/09
to Auto-android
Hi there,

I'm the lead developper of EasyAnt (http://www.easyant.org)

Easyant is a build system, that is based on Apache Ant and Apache Ivy.

Our goals are :

* to leverage popularity and flexibility of Ant.
* to integrate Apache Ivy, such that the build system combines a
ready-to-use dependency manager.
* to simplify standard build types, such as building web
applications, JARs etc, by providing ready to use builds.
* to provide conventions and guidelines.
* to make plugging-in of fresh functionalities easy as writing
simple Ant scripts as Easyant plugins.

To still remain adaptable,

* Though Easyant comes with a lot of conventions, we never lock
you in.
* Easyant allows you to easily extend existing modules or create
and use your own modules.
* Easyant makes migration from Ant very simple. Your legacy Ant
scripts could still be leveraged with Easyant.

I think it could be cool for us to provide support for android
projects based on what you have done.

Let me know if you are intested to work together on this.

Cheers,
Jean Louis Boudart

phil.h.smith

unread,
Mar 28, 2009, 8:46:29 PM3/28/09
to Auto-android
Hi, Jean

Sounds like fun; what did you have in mind?

One point that may be relevant: The 'magic' for calling the android
tools such as the emulator and adb reside in the "autoandroidlib" sub-
project. The ant sub-project uses it, wrapping them in an ant lib.
Depending on your goals you may find it easier to consume
autoandroidlib directly.

On Mar 28, 10:14 am, "jeanlouis.boud...@gmail.com"

Jean-Louis BOUDART

unread,
Mar 29, 2009, 7:29:34 AM3/29/09
to autoa...@googlegroups.com
I think we can provide a new "build type" for android projects.

Build types are intended to provide a full build for a particular type of project (simple java, war, ear, ...). EasyAnt comes with a set of build types modules, but users could extend/replace these types as they want. Then in most cases they could simply define which build type to import for each module (either standard or custom), and that's pretty much all. Hence you usually import only one build type module at a time.

So my idea is to write a plugin based on conventions that uses autoandroidlib tasks (and why not positron as an additional plugin) to provide the common tasks needed in an android project.

I notice that Android-ant does not (yet) provide tasks with attributes and nested elements customized to specific tasks. Are you planing to introduce it soon?


2009/3/29 phil.h.smith <phil.h...@gmail.com>

phil.h.smith

unread,
Mar 29, 2009, 2:29:31 PM3/29/09
to Auto-android


On Mar 29, 4:29 am, Jean-Louis BOUDART <jeanlouis.boud...@gmail.com>
wrote:
> I think we can provide a new "build type" for android projects.
>
> Build types are intended to provide a full build for a particular type of
> project (simple java, war, ear, ...). EasyAnt comes with a set of build
> types modules, but users could extend/replace these types as they want. Then
> in most cases they could simply define which build type to import for each
> module (either standard or custom), and that's pretty much all. Hence you
> usually import only one build type module at a time.
>
> So my idea is to write a plugin based on conventions that uses
> autoandroidlib tasks (and why not positron as an additional plugin) to
> provide the common tasks needed in an android project.

Groovy.

> I notice that Android-ant does not (yet) provide tasks with attributes and
> nested elements customized to specific tasks. Are you planing to introduce
> it soon?

My general stance is it isn't broken enough to fix. The existing
convention is to pass a nested block of ant command line argument
tags, which are delegated to a <java> tag (inside a macrodef) that
invokes autoandroidlib. These are in turn passed through to
ProcessBuilder when it shells out.

As such it's expressive enough for most uses (with one notable
exception: the <dx> tag takes an inputref attribute to process
collections of files, since ant makes converting such collection to
command line args somewhat convoluted.) If it is ugly, it is at least
fairly clear how to take most arbitrary invocations of the tools and
script them up. The 'openness' of this approach seems valuable: if
google releases a new 'killer feature' option to adb, for example,
this approach allows users to take advantage of it immediately, rather
than to wait for me to incorporate it.

> 2009/3/29 phil.h.smith <phil.h.sm...@gmail.com>
Reply all
Reply to author
Forward
0 new messages