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

Reply via email to