flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christofer Dutz <christofer.d...@c-ware.de>
Subject AW: WG: Loosing my drive ...
Date Fri, 06 Nov 2015 09:07:30 GMT
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
>
>
Mime
View raw message