"it elevates ant to a level of a "master build" and anyone doing something
else has to figure out how to make it work."

I think that is the point.  We cannot afford to have more than one 'master'
build mechanism at a time.  People are free to try other ways to build the
Flex SDK - no one is trying to block those efforts.  But right now, Flex is
built using Ant and it just works.  I dont see strong reasons to move to
Maven or any other mechanism other than individuals' personal preferences.
Once an alternate build mechanism is proven to be successful in building
the Flex SDK, we can initiate a thread at that point to get rid of the
older/inferior mechanism(Ant in this case)

Some folks here are swearing by Maven and others abhor it.  It is upon the
folks swearing by Maven to build this mechanism for the Flex SDK and
convince the rest of the folks.  Once that is done, we can take revisit
this issue again and discuss the pros and cons.  We all would be much wiser
at that point.

Om


On Tue, Feb 28, 2012 at 11:37 AM, Greg Reddin <gred...@gmail.com> wrote:

> On Tue, Feb 28, 2012 at 12:57 PM, Alex Harui <aha...@adobe.com> wrote:
> > If I need to change the build, I should only have to change the Ant build
> > script.  If that breaks the Maven or Gradle build scripts, too bad and
> folks
> > who know those build systems will have to react.
> >
> > Official releases would only include the Ant script and require Ant to
> > build, not Maven or Gradle or anything else.  Once a release is approved,
> > Maven folks will have to create whatever Maven users need from the
> release.
>
> That's basically another abstract idea because there is no Maven or
> Gradle build. On the surface I can't really support it because it
> elevates ant to a level of a "master build" and anyone doing something
> else has to figure out how to make it work. If I ever get some time I
> intend to look into what it would take to get the framework to build
> with Maven. Thus far I haven't been able to do it. But when (if) I do
> or someone else does, we can compare the Maven (or Gradle) build with
> the current build and decide if we want to pick one going forward. We
> may decide there's a new model that's far superior to what we have
> now.
>
> Greg
>

Reply via email to