But in my oppinion the plugin shouln't be part of the SDK as the SDK isn't a maven project itself. It would be a nightmare to setup a build for all. I would sort of see it as a separate project with a dependency on the Flex SDK which is converted using my Generator.
But setting up a github project sounds good. As I'm not a committer, I would probably stetup a repo and as soon as I have something we could work with, I could push everything to any repo you like. But I doubt that I'll be able to have result in the next weeks. My work on the Generator and Flexmojos has allready had a very bad impact on some "commercial deadlines" I had. As I don't want to lose those customers, I'll have to Do a little for them first ;-) Chris -----Ursprüngliche Nachricht----- Von: omup...@gmail.com [mailto:omup...@gmail.com] Im Auftrag von Om Gesendet: Donnerstag, 8. November 2012 00:45 An: flex-dev@incubator.apache.org Betreff: Re: [Discussion] Implementing a dedicated maven-flex-plugin On Wed, Nov 7, 2012 at 3:40 PM, Dasa Paddock <dpadd...@esri.com> wrote: > This is the repo that's been getting updates: > https://github.com/apache/flex-sdk > > You are right. And to be precise, it is the develop branch where stuff gets checked in: https://github.com/apache/flex-sdk/tree/develop And it does not support pull requests. > On Nov 7, 2012, at 3:32 PM, Om <bigosma...@gmail.com> wrote: > > > On Wed, Nov 7, 2012 at 3:29 PM, Eugene Krevenets (aka Hyzhak) < > > hyz...@yandex.com> wrote: > > > >> It's good news. Where you plan to share New Maven Plugin sources? > >> As i mentioned before, it's better be a github, because it's easy > >> to pull request to it. Thank you for your contribution to community. > >> > >> > > It would be best if the source code is directly contributed to the > > main Apache Flex repo. > > > > There is a github mirror for Apache Flex here: > > https://github.com/apache/flex for those who are interested in using > > github. > > > > Thanks, > > Om > > > > > > > >> 07.11.2012, 20:32, "christofer.d...@c-ware.de" < > christofer.d...@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 > >> > >> -- > >> Best regards. > >> > >> Eugene Krevenets. Software Engineer of Realaxy. > >> > >> Blog: http://anykeytocreate.blogspot.com > >> Code: http://hyzhak.github.com > >> linkedIn: http://me.linkedin.com/in/eugenekrevenets > >> > >
