incubator-flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "christofer.dutz@c-ware.de" <christofer.d...@c-ware.de>
Subject AW: [Discussion] Implementing a dedicated maven-flex-plugin
Date Wed, 07 Nov 2012 20:35:48 GMT
Well this was allways my final goal. But I know that re-implemnting something like Flexmojos
would take quite some time. So my shedule was to fix what was allready available and provide
everyone with a solution that they could use and after that to start working on something
new. I would call my work on the new FDK structure and adjusting FM to is finished and now
I would concentrate on the next generation maven plugin.

Chris 



-----Urspr√ľngliche Nachricht-----
Von: carlos.rovira@gmail.com [mailto:carlos.rovira@gmail.com] Im Auftrag von Carlos Rovira
Gesendet: Mittwoch, 7. November 2012 21:28
An: flex-dev@incubator.apache.org
Betreff: Re: [Discussion] Implementing a dedicated maven-flex-plugin

Hi Chris,

I think you are choosing the right path. People using old SDKs could use old flexmojos dependency...people
using apache flex could use your new version. So I think your plan should be ok for all users
of Flex.




2012/11/7 christofer.dutz@c-ware.de <christofer.dutz@c-ware.de>

> Hi,
>
> 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?
>
> Chris
>



--
Carlos Rovira
Director de Tecnología
M: +34 607 22 60 05
F:  +34 912 35 57 77
http://www.codeoscopic.com
http://www.directwriter.es
http://www.avant2.es

Mime
View raw message