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: [FALCON] Code analysis stats for Falcon
Date Thu, 05 May 2016 17:30:15 GMT

Ok so here we are again ... you claim to know how Maven works but are unwilling to learn what
maven is. So we keep on having these unproductive discussions like one of those bar-talks
where everyone knows things better without actually knowing anything. I guess everyone here
that knows Maven will probably know Ant and he will probably support my efforts. You don't
know a thing about Maven but keep on talking as if you do.

Yes Maven follows the principal of one primary artifact per module, but ist the "primary"
you should be paying attention to.
I have setup Maven to build both the externs as well as the swcs from one and the same code-base
in one run of the build. And that's a totally valid Maven strategy. The problem I am having
is that the magic Ant build seems to be producing different output than mine, even if I match
the input to the compilers to the bit (I actually tried that), so I guess there is other magic
involved, that I simply can't see. Some system properties, that configure things differently.

I for my part don't trust builds I don't understand and I don't understand the Ant build and
judging from your comments on my last mail you can't explain what all of the knobs and levers
in the build actually are needed for. I wanted to build Falcon yesterday, but couldn't because
it was missing apache-commons-io ... so I had a look and could see the downloads for the utility
jar are done by going into the src/test/resources directory of the compiler and calling an
Ant script called download.xml there ... WTF? You call that maintainable?

I don't want to contribute to a project that I have to figure out how to build every 2 or
3 weeks ... I don't want to contribute to a project, where I have something working on one
day, the next day nothing works because a download was added and the bloody download scripts
don't know to update. So I start doing "ant wipe-all" + "ant all" all the time. Thinking in
Maven terms this is like deleting the Maven local repo every time. I've wasted far too many
days of productive time with this build out of hell (As we inherited this I probably won't
offend anyone in this project). To me this project feels like it's having a detached head.
There is a hand full of people that keep on hacking and the others are waiting for stuff to
happen, because they don't want to get run over by problems with the build or they simply
don't understand how to contribute. I think we have a lot of people here (We are actually
the 10th biggest ASF project judging from the committer numbers) that are too afraid to get
started. I want to get them into the boat.

So as long as I don't hear a meaningful number of others stepping up ... I'll step down and
start living a life again ... far too many friends I didn't have a beer with cause I was working
on Flex, far to many days my girlfriend was mad at me, cause I sat at the computer the whole
day trying to get this one thing finished.

I'm sick of it and so I'll check where to put a sensible amount of effort into other projects
at ApacheCon.


Von: Alex Harui <aharui@adobe.com>
Gesendet: Donnerstag, 5. Mai 2016 18:22:26
An: dev@flex.apache.org
Betreff: Re: [FALCON] Code analysis stats for Falcon

There is a phrase: "right tool for the job".

At the time we migrated Adobe JIRA to Apache JIRA, Maven support for Flex
was easily the most voted-on issue.  I don't follow the Maven community so
I don't know if other tools have become more popular, but I otherwise have
no reason to doubt that if FlexJS gets traction within the same set of
customers, Maven will again be sought after.

So, I am totally in favor of trying to get our JARs and SWCs up in Maven
Central so that folks can develop applications the Maven way, and I have
postponed feature development to help make it happen.

But whether we use Maven for every step of generating the JARs and SWCs is
the actual question, and I am no longer clear that Maven is the right tool
for every step of that job.  Yes, you can extend Maven with Mojos to make
it work, but it isn't clear to me that the investment in these Mojos are
worth it when Ant can already do it.  IMO, a Mojo is worth the investment
in writing and maintaining when there is going to be lots of re-use of it,
so that's why FlexMojos is worth it.  AIUI, FlexMojos makes Maven
understand ActionScript and SWCs instead of just Java and JARs.  But Mojos
just to insert or replace text seems like a lot of work when an Ant script
already exists to do that work.

Further, Maven seems to expect applications to be written in a particular
pattern:  single-source to single-target.  The FlexJS framework is
single-source to multi-target via conditional compilation.  We've tried 3
different source code patterns so far (separate AS and JS folders,
separate folders for platform vs multi platform, single folder with
conditional compile) and I believe that conditional compilation is getting
us the best code productivity.  For example, last night I was able to fix
a bug by touching one file instead of two.  Wikipedia says that
conditional compilation is often used for multi-platform, so I using
conditional compilation is a valid approach.  I'm open to other code
management ideas, but separating the code in order to make the build
system happy doesn't make sense to me.

Doing the refactoring to try to get Maven to work has been a good thing.
I think there is more consistency in the organization of the code and
fewer if any circularities in the build order.  But what we are really
trying to do in FlexJS is get some library developers to abstract away the
differences between platforms so that application developers can have a
single-source to single-target.  And those library developers are
currently finding that single-source to multi-target is the most efficient
way to develop those abstractions.

When I think of it that way, I think we should use both Ant and Maven.  I
still haven't heard feedback on the idea of creating an "externs" folder
as a sibling to the "frameworks" folder which, independent of Maven, might
help us manage doing library abstraction development in IDEs.  That would
give you a fresh set of pom.xml files to work with, but all of the source
would be outside of the project folder.  Which Ant is totally fine with,
but is not quite what Maven had in mind.

So, why not just have Maven call Ant to do the dirty work until the
results are essentially single-source to single-target?  Then there aren't
as many, if any, custom Mojos to maintain.  Maybe Ant is the right tool
for taking our conditional compilation code base and generating output so
Maven can do the rest.  I would imagine that's why Maven supports calls to

The proposal is, if we build out an "externs" sibling to "frameworks",
then I think the folder structure would look like this:

externs/projects/Core/.project  -  FlashBuilder project for building
-There would not be a src/main/flex folder in externs/projects/Core.
-externs/projects/Core/src/main/config/compile-js-config.xml would have
relative paths back to frameworks/projects/Core



Ant would use externs/projects/Core to generate the
frameworks/projects/Core/target/generated-sources/flexjs folder
Ant would use externs/projects/Core to generate the

I think the Maven build would use Ant to do the generated-sources and
XXX-externs.swc for all of the other externs/projects before Ant or Maven
builds final SWCs by going through the frameworks/projects.
Maven could also do these steps if it ok with having the source outside
the project folder.

When that is done, I think Maven should have an easier time producing the
final SWC because inside frameworks/projects/Core is a set of source files
and generated files that have a single output (Core.swc) which is the only
artifact our application developer customers need.  We should consider
deploying the Core-externs.swc for folks creating third-party libraries
that rely on our libraries but would expect less demand for the


On 5/5/16, 6:26 AM, "carlos.rovira@gmail.com on behalf of Carlos Rovira"
<carlos.rovira@gmail.com on behalf of carlos.rovira@codeoscopic.com> wrote:

>Hi Chris,
>I'm following your iteration (silently in order to not introduce noise),
>and I think you're doing a great work. I know about others here very
>interested in this stuff too.
>Regarding Maven things, people working with maven knows how much pain is
>make a working maven setup correctly, and it needs too much effort, but as
>things gets working, it's an invaluable tool. I think this is the way to
>go, and even, If I need to choose, I'll vote for maven over ant, dropping
>ant support. But this should be the way of thinking for others
>to FlexJS. I don't know what others think about maven support and if they
>know about the benefits. It's like the benefits of GIT over SVN, it was a
>bit painful to jump over GIT, but I think people looking back in the past
>could appreciate the great benefits of GIT on this project (hopefuly) :)
>Thanks for your effort, hope you decide to keep the great work
>2016-05-05 12:32 GMT+02:00 Christofer Dutz <christofer.dutz@c-ware.de>:
>> To me it feels like I'm the only one actually wanting to go to Maven :-(
>> I'm even thinking about dropping the ball on this entirely, cause I
>> want to be the only one complaining about the status quo. It was an
>> amount of work to get falcon to build with Maven. I invested far nite
>> than I actually had. All I am hearing is that I'm making things more
>> complicated. If everyone is happy with Ant and it's the overall
>> I'm making things more complicated with Maven, I better invest my time
>> other projects.
>> Chris
>> Von meinem Samsung Galaxy Smartphone gesendet.
>> -------- Ursprüngliche Nachricht --------
>> Von: Harbs <harbs.lists@gmail.com>
>> Datum: 05.05.16 11:54 (GMT+01:00)
>> An: dev@flex.apache.org
>> Betreff: Re: [FALCON] Code analysis stats for Falcon
>> Got it.
>> Once you have the Maven build working, it would be great to see what it
>> does with asjs. Who knows. Maybe we’ll be lucky… ;-)
>> On May 5, 2016, at 12:32 PM, Christofer Dutz <christofer.dutz@c-ware.de>
>> wrote:
>> > Actually it does support ActionScript. But unfortunately I need to
>> with Maven fire that and I doubt it will be able to understand the
>> code with all these define blocks
>> >
>> > Chris
>> >
>> >
>> >
>> > Von meinem Samsung Galaxy Smartphone gesendet.
>> >
>> >
>> > -------- Ursprüngliche Nachricht --------
>> > Von: Harbs <harbs.lists@gmail.com>
>> > Datum: 05.05.16 11:02 (GMT+01:00)
>> > An: dev@flex.apache.org
>> > Betreff: Re: [FALCON] Code analysis stats for Falcon
>> >
>> > Wow. That’s really nice. Seems like it’s very useful!
>> >
>> > Does this only work for Java, or can it be configured for other
>> languages (such as ActionScript)?
>> >
>> > Harbs
>> >
>> > On May 5, 2016, at 11:35 AM, Christofer Dutz
>> wrote:
>> >
>> >> Hi,
>> >>
>> >>
>> >> I just turned on public access to my SonarQube server ... there you
>> see an up-to-date code analysis report for Falcon and FalconJX. It
>> points out the Null Pointer hot spots.
>> >>
>> >>
>> >> http://dev.c-ware.de:10000/overview?id=2471
>> >>
>> >>
>> >> Perhaps looking into this every now and then could help improving
>> code-quality, stability and resillience of our software.
>> >>
>> >>
>> >> Chris
>> >
>Carlos Rovira
>Director General
>M: +34 607 22 60 05
>Este mensaje se dirige exclusivamente a su destinatario y puede contener
>información privilegiada o confidencial. Si ha recibido este mensaje por
>error, le rogamos que nos lo comunique inmediatamente por esta misma vía y
>proceda a su destrucción.
>De la vigente Ley Orgánica de Protección de Datos (15/1999), le
>que sus datos forman parte de un fichero cuyo responsable es CODEOSCOPIC
>S.A. La finalidad de dicho tratamiento es facilitar la prestación del
>servicio o información solicitados, teniendo usted derecho de acceso,
>rectificación, cancelación y oposición de sus datos dirigiéndose a
>oficinas c/ Paseo de la Habana 9-11, 28036, Madrid con la documentación

View raw message