I said this in another thread but since you asked I would say this would be the perfect workflow for me (for both Flex and FlexJS):
1. Provide URL to source on Github (the project would have to be on github obviously) 2. I create a local repository from that 3. I open FB and import a default *existing project* that is in the local repository* -- in my project i add a spark Button -- I then open spark.Button.as and make changes 4. I compile the project and run it. I see the changes immediately 5. I commit those changes locally and push them up to the main branch to be accepted or rejected. *No environment variables to setup, no projects to setup, etc. It should be bog standard 2 step process: import repo locally, begin work. I put a lot of work in one of my AS3 / Flex libraries and it bothers me that that work is not in the Flex SDK. It may not be as high quality as some code out there but that can be fixed by other community members reviewing it and making it better. We have AS3corelib, tons of AS3 libraries and components on github and google code and maybe not all of them, but a majority of them would give the Flex SDK an amazing API to do just about anything. And I believe if they were in the main repository they would be getting more use and improved upon daily. On Fri, Nov 6, 2015 at 9:52 AM, Alex Harui <aha...@adobe.com> wrote: > Let me see if I can summarize these various “simplify the build threads > here”. > > For me, I have to go by what I read on our mailing lists. Maybe there is > some silent faction waiting for simpler builds, but I am going to reward > those who speak up by trying to work on their issues. It doesn’t seem > right to tell someone who reports a bug that it will be several weeks > before I can fix it because I am worried about attracting people who we > don’t know exists. Go back through the archives. I rarely see new > potential committers complaining about how to get started writing FlexJS > code, especially after the recent changes I made to try to make that > simpler which was in response to the last flurry of “simplify the build” > emails from several of our current committers. Strangely, when I > completed that work and asked folks to test it, I got no responses. For > example, I didn’t see any responses from folks who could be in the silent > faction saying that it made it better, so that’s why I’m just not sure how > important it is to make it simpler than it is now. > > Harbs had issues getting started and IIRC, mostly it was environment > variables so maybe all of these emails boils down to the need to try to > reduce the reliance on environment variables. I’m definitely open to > spending some of my time on that. > > I believe Maven is important, but I do not wish stop working on other > stuff to learn Maven and do the heavy lifting on it. I hope Chris will > stick around to do it and that others can help them. I will try to help > with refactoring needed to make Maven work better. Those changes usually > help make sure we have the loose-coupling we need between modules. I’m > not that interested in refactoring the Flex SDK. I am interested in the > notion of slicing off any Flex SDK dependencies in the Falcon code base so > we can Mavenize FlexJS without dealing with the Flex SDK first. And I’m > actually looking forward to seeing the Mavenizing of FlexJS. Maybe I’ll > learn more about Maven by watching those commits. > > I’m sure in the early days of FlexJS and Falcon, going away for a while > and coming back probably didn’t work. But is that still true? And if so, > can you just blow away your repos and re-grab flex-asjs and run “ant all” > and get back up and running? > > And for folks reading this who are in the silent faction: Please speak > up. Or write me off-list if there is something you have to say that you > don’t want to say on these lists. And tell me/us why you have been > silent. Is there something we are doing or should be doing to make it > easier for you to speak up? > > So, my takeaway is that we should fork off two actionable threads. One > about eliminating environment variables for Flash/AIR, and the other about > folder restructuring in flex-asjs to make Mavenizing easier? Did I miss > anything? > > Meanwhile, I am trying to upgrade the build scripts to fix issues found in > the FalconJX packages so that we can get releases out faster in the future > by catching issues sooner. > > If you are still having problems with this FlexJS release candidate, > please provide more detail. > > Thanks, > -Alex > > On 11/6/15, 1:08 AM, "Justin Mclean" <justinmcl...@me.com> wrote: > > >HI, > > > >> Nobody is saying simpler builds wouldn’t help. But how much? > > > >A lot I think. Developer are unable to contribute if they can’t compile > >and test their changes. > > > >> More than a more functional DataGrid? Or a more Spark and/or MX-like > >>component set > >> that reduces migration time for your app? Or being able to write your > >>JS > >> using AS? > > > >IMO you would more likely get people contribution things like that if it > >was simpler to build. > > > >> To folks reading this who are interested in > >> FlexJS: what is the most important two or three things we should be > >> working on? > > > >IMO: > >1. Simpler builds > >2. More frequent releases (say every 3 or 4 months). > >3. Compiling MXML > >4. Working documented examples / how to port existing applications > > > >> The build script was improved in this release such that if you have a > >> couple of known sets of circumstances, like not having any of the repos, > >> that running “ant all” will get all the repos and build them in the > >>right > >> order. > > > >I meant to ask before does that use well known versions or does it just > >grab the latest out of the develop (or another) branch? > > > >Thanks, > >Justin > >
