Well in order to seriously do this refactoring, you would also have to do the refactoring of the directory structure. This was ne main reason for me never having continued down that path as I knew I would have to hand-merge stuff for quite some time. So in order to do something like this, we would actually have to stop working on FlexJS, rearrange the directory structure and continue from there (Eventually only a few Ant scripts would need adjusting for the time of the transition) ...
Don't know if there is the will do to something like this ... at least it was my impression that it's not. Chris ________________________________________ Von: omup...@gmail.com <omup...@gmail.com> im Auftrag von OmPrakash Muppirala <bigosma...@gmail.com> Gesendet: Freitag, 6. November 2015 10:50 An: dev@flex.apache.org Betreff: Re: WG: Loosing my drive ... Yes, the AntRun Maven plugin is a good stop gap measure. Is this an option for FlexJS? As I understand the way FlexJS is built right now, there are several dependencies to download and build before compiling the FlexJS SDK. Can we mavenize the rest and use AntRun for the build FlexJS part? If you can do the rest, I can help out with plugging in the Antrun plugin into the pom.xml. What do you think? Anyone has a better suggestion for a path forward? Thanks, Om On Fri, Nov 6, 2015 at 1:40 AM, Christofer Dutz <christofer.d...@c-ware.de> wrote: > Well here goes: > > Initially we have to separate between the compiler and the framework. > Converting the compiler to maven is easier as it's simply a Java program. > Converting the framework build to maven is eventually a little problematic. > Currently there is only one maven plugin for building flex applications > with maven (Flexmojos and unfortunately it is impossible for me to donate > this as I would have to contact anyone who contributed and have them sign > an ICLA). > > In order to dress this problem I had started a new maven plugin as part of > the flex-utils project. Here I have started setting up the structure of a > brand-new plugin that's pure ASF. The cool thing with this is that I could > drop a lot of stuff needed for supporting legacy Adobe and Apache Flex > versions. I didn't continue down that path as I wanted to make Flexmojos > feature complete prior to starting from scratch as I know this will take > quite a while. Still I am missing Mobile Packaging for iOS and auto > downloading of Flashplayer and Air runtime, but I am hoping on finishing > this soon. As soon as Flexmojos 7.1.0 is released, I want to work on the > Apache Flex Maven plugin ... If I don't loose interest in the project till > then. > > A "solution" would be to use the Maven-Antrun-Plugin to use the Flex Ant > Target inside a Maven build till the maven plugin is useable. The good > thing would be that we could concentrate on the features needed for the > build of Flex itself and hopefully transition quite fast. But we wouldn't > have to wait for that to happen as the Antrun option should work fine. > > But coming back to your questions: > > Yes in both cases ... run "mvn install" in the root the SDK would be built > and unit-tested. If you run "mvn install" in the examples, the examples > would be built, but the output directory wouldn't be "bin" but "target" ;-) > > Chris > > ________________________________________ > Von: omup...@gmail.com <omup...@gmail.com> im Auftrag von OmPrakash > Muppirala <bigosma...@gmail.com> > Gesendet: Freitag, 6. November 2015 10:26 > An: dev@flex.apache.org > Betreff: Re: WG: Loosing my drive ... > > Chris, > > I read your email twice. I don't see what I was expecting. Here are a > couple of simple questions: > > 1. As a FlexJS SDK Developer, I want to build the FlexJS SDK. I want to > go to the flex-asjs folder and run mvn install. I want the entire SDK > built and ready to release. > > 2. As a FlexJS SDK User, I want to go inside the > flex-asjs/examples/flexjs/ChartExample folder and run mvn install. I > expect to see the built artifacts in the bin/js-debug, bin/js-release and > bin-debug folders > > What is missing for these two (seemingly related, but different) build > processes to work correctly. I think we should must concentrate on these > two goals. > > Thanks, > Om > > On Fri, Nov 6, 2015 at 1:07 AM, Christofer Dutz <christofer.d...@c-ware.de > > > wrote: > > > Ok ... let me respond to some of this: > > > > Alex wrote: > > > IMO, the good and bad of Apache being a “do-ocracy” is that, while you > > can > > > work on pretty much whatever interests you, at least in this project, > > > > I definitely don't agree ... it's far from a "do-oracy" it's a > > "discuss-oracy" ... I bet the amount of bytes in the mailinglist > outweighs > > the bytes going to the repo ;-) > > > > Alex wrote: > > > >Adding my statement from the initial thread, that from now on I will > > stop > > > >contributing to things not built by a sensible build (doesn't have to > be > > > >Maven even if I strongly suggest it). > > > > > > I’m going to take that as a softening of your position. I don’t think > > > anybody would argue that builds should not be “sensible”, but what does > > > that really mean? And what practical steps can we do that doesn’t > grind > > > feature development and bug fixing to a halt? > > > > Well ANT tends to become a monster as you can do anything with it ... > > therfore everyone does everything with it, but each one differently. > Gradle > > goes down the same path ... even if it automates a lot of stuff that has > > been identified as "have to do that over and over again". Maven on the > > contrast has the beauty of not only having a pre-defined build process, > but > > also a pre-defined project structure. The first newbe here being able to > > checkout the Flex SDK and immediately explain to me the internal > structure > > of the project will get a free Beer next time we meet. With maven it > > doesn't matter what project you get, you sort of immediately grasp the > > structure as it's a standard. > > > > What are the problems I see? > > - The structure of the project istself (I still don't know exactly what > > parts of the SDK do what and I do admit that I have dug in that code much > > more than most people here) > > - The structure of the build itself (There are uncountable targets, > > sometimes with identical names in multiple build scripts ... the only way > > to understand the order in which they are called is to build and look at > > the log and hope you get it right. I wanted to add some things multiple > > times and was simply stuck with finding out how things are done and how I > > have to get my stuff in there without breaking anything else) > > - The requirements (The build doesn't tell you what it requires, what > it's > > missing and what is expected to be there. If something blows up, you have > > to get your hands dirty and investigate in Ant what's going wrong) > > - Depending on 100 different download sources (Currently it feels as if > > you start from scratch in more than 50% of the times the build doesn't > work > > as one of the sites stuff is downloaded from are unavailable. I have > never > > seen Maven-Central be offline and if this should ever happen Google > keeps a > > complete mirror online, so in the worst case all we would have to do is > > switch the root repo to the Google one) > > - Finding out thy things don't work (We check the checksums of jars when > > we download them ... but as soon as they are there, we never bother. > > Several times I haven't been working on a part of Flex for some time, > > coming back later and having problems ... after quite some time of > > investigation I found out that the version of a jar had changed, but as > we > > simply store it as "mylib.jar" the build didn't detect this and assumed > all > > was good) > > - Simply to build all of our parts you have to keep a different set of > > targets in mind to clean, clean-all, compile, test, whatsoever ... > > sometimes a target is available in multiple parts, but do different > things > > ... think about the clean goals ... clean, wipe, clean-all, > > clean-dependencies, ... can't remember all of them. > > - Building Flex, FlexJS and Falcon feels like shooting at a moving target > > ... whenever I come back I have to adjust something ... some new > > environment variables, different libs, different targets/goals to execute > > in a different order) > > - We use patched versions of ancient libs (I think using patched libs is > > the worst thing you can do. If you need something, contribute. I have > > reverse engineered the xalan patch for example and newer versions of > xalan > > have addressed similar issues, so it could be that the latest version > > solves the problems our patch hacked in there) > > > > What's missing on the maven side is a way to mavenize the FlashPlayer and > > the Air runtime, but I'm working on this ... as soon as one of the 3rd > > party libs for unpacking archives is able to unpack Mac DMG archives, I > > will be able to technically finish this. The result will be not having a > > single prerequisite to building flex applications with maven ... all you > > need is Java and Maven and off you go. And it takes care of problems you > > have due to building for a different Flash/Air version than you have > linked > > in your environment variables. BUT I am expecting to be engaged in > another > > major legal issue discussion with Adobe guys ... really not looking > forward > > to that. > > > > The general problem I see at the moment is that you want to push out > stuff > > so people start testing it and you can fix stuff. I want to make fixing > > stuff easy so more people can actually do it. Most of us don't work on > Flex > > full-time. If I find a problem and I want to fix it and I have an > afternoon > > of time, I don't want to invest this afternoon in order to setup things > so > > I could start fixing things, but then have no time left to actually do > so. > > And as soon as I find time again, things have changed in a way that I > need > > to invest most of my time again to get things running. > > > > The was things currently are the project will divide into two fractions: > > a) The ones that have the luxury of having someone pay for them to work > on > > Flex full time > > b) the others that simply sit there and wait for things to happen. > > > > That's definitely the way Adobe used to work, but it's not the way the > ASF > > works. "Community over Code" > > > > So converting Falcon to become a real Maven project as a first step isn't > > that hard. There were missing parts, but I contributed to those projects > > and the missing parts should now be available. For example JBurg is now > in > > Maven-Central ... I even created a Maven Plugin for using JBurg in a > maven > > build. Antlr and the other stuff has always been available. > > > > And again 10 times more text than code I have written for Flex for quite > > some time ... > > > > Chris > > > > ________________________________________ > > Von: omup...@gmail.com <omup...@gmail.com> im Auftrag von OmPrakash > > Muppirala <bigosma...@gmail.com> > > Gesendet: Freitag, 6. November 2015 08:56 > > An: dev@flex.apache.org > > Betreff: Re: WG: Loosing my drive ... > > > > Alex, > > > > I believe there is a disconnect between folks who are used to maven and > > those who are not. The beauty of maven is that the user does not need to > > have anything pre-installed on their computer. Write some code and > simply > > run "mvn install". This simple command takes care of downloading the > SDK, > > dependencies, compiling the code and generating the desired artifacts. > > > > Compare that with Ant: You download the SDK, dependencies, create > > environment variables, build properties etc. before you can do anything. > > As evidenced with Flex SDK and FlexJS, setting all this up and getting > > everything built is a big task in itself. Any contribution can be done > > ONLY after doing all this work, which takes several tries to say the > least. > > > > I think what Chris is saying is quite straightforward: lets make it easy > to > > build the FlexJS SDK. Maven is one way to do it. > > > > Chris, from your side, I hope you can continue to lead this 'mavenizing' > > effort. Most of the time, I don't follow what you doing although I > > understand that they are important steps in achieving this goal. If you > > can come up with a plan of action and describe what you want to do, I am > > sure that the community will come together to help out. > > > > Mavenizing does not mean we give up on Ant. Alex (and others who are > happy > > with Ant) can continue to build with Ant. I don't expect Alex to drop > what > > he is working on and help with the Mavenizing effort, although any help > > from him would be appreciated. > > > > Let's start with mavenizing FlexJS. > > > > Thanks, > > Om > > > > On Thu, Nov 5, 2015 at 11:20 PM, Alex Harui <aha...@adobe.com> wrote: > > > > > > > > > > > On 11/5/15, 10:35 PM, "Christofer Dutz" <christofer.d...@c-ware.de> > > wrote: > > > > > > >Moving this thread to public dev list ... > > > > > > > >Adding my statement from the initial thread, that from now on I will > > stop > > > >contributing to things not built by a sensible build (doesn't have to > be > > > >Maven even if I strongly suggest it). > > > > > > I’m going to take that as a softening of your position. I don’t think > > > anybody would argue that builds should not be “sensible”, but what does > > > that really mean? And what practical steps can we do that doesn’t > grind > > > feature development and bug fixing to a halt? > > > > > > And I’d like to hear from others: Would better build scripts cause you > > to > > > contribute more? Would switching from Ant to Maven cause you to > > > contribute more? What else could we change that would get you to start > > > contributing or contribute more? > > > > > > For sure, at the time Adobe transitioned Flex to Apache, having the > Flex > > > SDK work with Maven was the number one vote getter in JIRA. For > FlexJS, > > > I’m more worried about getting enough features and functionality to the > > > early adopters such that they provide us the positive testimonials we > > need > > > such that enterprises might start using FlexJS and then start asking > > about > > > Maven. IMO, if we don’t get traction, it won’t matter what our builds > > > look like. I keep hoping others will start contributing, and in the > > > upcoming 0.5.0 release I invested several days in trying to make the > > > builds more sensible because folks said that was a barrier. But what > > else > > > do we need to do in this area? Can others step in to help? > > > > > > IMO, the good and bad of Apache being a “do-ocracy” is that, while you > > can > > > work on pretty much whatever interests you, at least in this project, > > > others tend to watch you work. Maybe there’s something we can tweak so > > > more folks jump in. I often think folks still think that we are still > in > > > the “old days” where you had very little influence on the release that > > > Adobe would offer up on occasion and haven’t fully understood that in > the > > > Apache world, things are almost the exact opposite. There is no > > corporate > > > entity that decides what gets done, individuals can’t just be passive > > > customers: they need to somehow find the time to help get things done. > > > It could just be by using the releases, but it would be much better if > > > folks who know Maven could help you create a Maven builds for our > repos, > > > and folks who know Java could try to work on the compiler, etc. Yes, > > > Adobe pays me to work on Flex, but Adobe is not backing Flex like it > used > > > to. It has turned the future of Flex over to Apache and the Apache > Flex > > > community. > > > > > > Anyway, feel free to keep venting for a bit, and even take a break if > you > > > need to, but I hope you will stick with us and we can open an > discussion > > > on more concrete things that we might be able to do to make the builds > > > more “sensible” and maybe even break it down into small pieces that > > others > > > can help with. > > > > > > -Alex > > > > > > > > >
