incubator-flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "" <>
Subject [Discussion] Implementing a dedicated maven-flex-plugin
Date Wed, 07 Nov 2012 19:27:58 GMT

as most of you probably know, I'm currently working on a tool to generate Mavenized FDKs.
In parallel I am adjusting Flexmojos to support the new Apache FDKs so people can build Flex
applications using Maven.

So far so good. After finishing the Generator and adjusting Flexmojos to all of my changes,
the last step was to generate the 4.8 FDK using the maven group id org.apache.flex instead
of com.adobe.flex.

Now this introduced MAJOR problems. Currently you could use Flexmojos with 4.8, if you compile
the entire Plugin against the group id of apache or you could use the adobe fdks after compiling
it against the adobe group id.
The main reason is that otherwise Maven imports two versions of the jars (the one of the FDK
you want and the one Flexmojos was compiled against).

Sorting this out would be a total nightmare as there are really magical hacks working inside
the build which cause any change in the scopes of dependencies to blow everything up.
I guess this is because Flexmojos includes insanely much code for supporting legacy FDKs (back
to 2.0 FDKs) and a ton of different tools for different parts of the build lifecycle.

My question now would be if it would not be better to officially leave Flexmojos to be compiled
against com.adobe.flex and to include an option in the generator to generate the Apache FDKs
to the Adobe namespace and to let users be happy with that and use it.

In parallel I would volunteer to start work on a new plugin aimed at apache flex, but leaving
away support of the Adobe FDKs. I would suggest to concentrate on the main path, supporting
only apache fdks, only flexunit 4.1 for unit-testing, only the newest granite code generator
and so on. In this case this should be a manageable task, even if it will take a while. As
soon as the Version 1.0 is out we could start extending this to support more stuff our users
would need. I think continuing to add more and more code to Flexmojos will only make it an
unmaintainable monster whith all the problems comming from that.

As I mentioned, I would volunteer to start such a thing and I think using Flexmojos as an
inspiration on how to possibly implement something like that it should be manageable.

What do you think?


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message