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 > > > > >
