from what I know of the process: -Velo needs to sign an ICLA -Code can be donated as a JIRA issue, but it can also just be sent to one of the committers who puts it in SVN -When the source is actually released by Apache Flex I believe the headers and packages need to be in order, bot for the inital donation this isn't required (please correct me if I'm wrong anyone)
Oh, and I'm not sure if the current open source license if compatible with the Apache license, so how that would work exactly I don't know either. Please, people who are in the know, comment on this :) cheers, Roland On 24 January 2013 13:12, christofer.d...@c-ware.de < christofer.d...@c-ware.de> wrote: > Yeah ... the problem is ... could someone please write down what would be > needed? > - Which agreements have to be signed? > - How is the code actually donated? (Jira Issue with 60MB attachment?) > - What steps have to be done before the code is allowed to be added to the > Apache code repo (Headers, Package Names, Artifact IDs? And does his have > to happen also for "scratchpad code"?) > > Chris > > -----Ursprüngliche Nachricht----- > Von: Roland Zwaga [mailto:rol...@stackandheap.com] > Gesendet: Donnerstag, 24. Januar 2013 12:57 > An: dev@flex.apache.org > Betreff: Re: Donation of Flexmojos > > I think you you make a very clear and sensible case. > +1 to accepting Velo's donation. > > On 24 January 2013 12:22, christofer.d...@c-ware.de < > christofer.d...@c-ware.de> wrote: > > > Hi, > > > > after me telling the other Flexmojos users on the FM Mailinglist that > > we are working on a brand-new flex plugin for maven. Velo said that he > > would be willing to donate Flexmojos to Apache. We just should tell > > him where to sign and what to do (Even if the "doing" would be > > something that would have to be done by me) > > > > I think it would be a good idea to take this offer. But I wouldn't > > recommend directly using this code as a directly as the official Flex > > Plugin. More I would like to add it as some sort of scratchpad project > > and use the existing parts to build a new plugin and to do things > > differently where things aren't solved ideally. > > > > The reason for this is that Flexmojos has become a beast to maintain, > > as it supports Adobe Flex 2 up to 4.6 and with my changes in the > > Flexmojos 6.x branch it even supports Apache Flex 4.8 and 4.9. > > Currently you need about 8 complete FDKs to have the Testsuite working > > and the mixing of group-Ids (com.adobe.flex and org.apache.flex) has > made everything even worse. > > > > The testsuite is full of tests which made sense once, but today it > > seems impossible to find out what they were initially meant to test. > > Usually when adding support for a new FDK the testsuite had errors and > > I simply made them pass again. I would like to setup a clean testsuite > > that has a more clean structure AND has documented Tests to avoid > > problems like this in the future. > > > > Flexmojos has grown more and more over the years making it one > > monolithic plugin. Everybody using IntelliJ will probably have noticed > > one problem that is related to this ... IntelliJ keeps on complaining > > about no storagePass property being configured. This property is > > mandatory for creating signed Air application, and therefore is a > > required property, but for normal Flex application it is optional. > > Splitting up everything into separate mojos would make a lot of stuff > easier. > > > > The next thing is that I would like to completely overwork the > > Test-support. Currently Flexmojos opens a set of sockets and compiles > > a dedicated testrunner SWF to connect to these sockets. There have > > been quite some problems with this. I would therefore like to change > > this that the swf is served by a mini-webserver (20 LOC) and simply > > communicates with a rudimentary webservice on the same port. > > > > In the TestSupport I am also thinking about using the Flex > > Log-Framework to support several concurrent streams of log-data and > > provide the means to save the log output together with the > > test-results. Currently debugging tests is pretty nasty. > > > > Last not Least I think with a new plugin we could optimize tool > > support much better by including the Tool vendors in the process (I'm > > just thinking about the copy-resources problems with IntelliJ). > > > > What do you think? > > > > Chris > > > > > > -- > regards, > Roland > > -- > Roland Zwaga > Senior Consultant | Stack & Heap BVBA > > +32 (0)486 16 12 62 | rol...@stackandheap.com | > +http://www.stackandheap.com > > http://zwaga.blogspot.com > http://www.springactionscript.org > http://www.as3commons.org > -- regards, Roland -- Roland Zwaga Senior Consultant | Stack & Heap BVBA +32 (0)486 16 12 62 | rol...@stackandheap.com | http://www.stackandheap.com http://zwaga.blogspot.com http://www.springactionscript.org http://www.as3commons.org
