flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From OmPrakash Muppirala <bigosma...@gmail.com>
Subject Re: WG: Loosing my drive ...
Date Fri, 06 Nov 2015 09:26:18 GMT

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.


On Fri, Nov 6, 2015 at 1:07 AM, Christofer Dutz <christofer.dutz@c-ware.de>

> 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: omuppi1@gmail.com <omuppi1@gmail.com> im Auftrag von OmPrakash
> Muppirala <bigosmallm@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 <aharui@adobe.com> wrote:
> >
> >
> > On 11/5/15, 10:35 PM, "Christofer Dutz" <christofer.dutz@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
> >
> >

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message