1) Why use different poms for building the same project, but different output?
For one module it doesn't (at least shouldn't) matter what the output it, it still needs the same dependencies, has the same language settings, uses the same namespaces etc. In my initial Flexmojos FlexJS support I solved this problem by simply adding a switch to the configuration. This defaults to Flash output, but I could flip it and produce HTML5 ... so building the Flash application would be "mvn clean install" and building the HTML5 could be "mvn clean isntall -Doutput=html5" (or you set the defaults to build html5 if you want that the default). Why use two poms that would probably be 99% identical? In the flash case it would produce a swc in the other a zip/war which can be used as overlay in another war application. 2) Ant does everything right now If it does, how come I have to work through the build scripts all the time to find out why things are not working? I agree ... you could do everything with Ant what you can do with Maven. The problem is that we don't do it. It is possible to build an Ant script that takes care of downloading stuff, checking it's the right version etc. But in order to make the Ant build that safe and stable would be an enormous effort. You claim it's easy to do this and that ... so why hasn't this been done? We are having build issue problems related to Ant problems every few days. It's easy to stuff holes as you see them. The problem is that there are so man holes needing stuffing, sometimes it's better to just get a new bucket which comes without holes. So either start a new Ant build from scratch following some good design principles, or switch to maven which brings all of this for free (after the initial effort of migrating). 3) Multi target with alternate dependency chains I still don't understand why we need different dependency chains at all? Of course in the end we need to go to the JavaScript or the Flashplayer root classes, but after a first layer of abstraction I still don't get why we need some different dependency chains after that layer. If we do, we need to refactor that and clean things up. But that's the point where we keep on turning in circles. You (@alex) always claim: It works in Ant, so if it doesn't in Maven, lets just stick to Ant. In my maven trainings there is one thing I tell my students over and over again. It's the one rule I have learned to respect and which has never proven to be wrong: "If it's hard with Maven, you're doing it wrong". Usually all you need to do is step back, look at what you're trying to do and re think. Example: Maven can only compile each module once. This was a problem with compiling falcon, cause the Ant build compiles part of the code then executes that compiled parts and then compiles everything again. That's not possible with Maven, but if you have a look why you need to do it in the first place you quickly find out that code generators and utility classes are embedded inside the modules they to build. The Maven way is to put them in a separate module and use that in the original module. This way you also clean up your modules so the Falcon compiler doesn't ship with some hand written plugins to annotate Java code with certain Annotations. Now after my refactoring things are separated cleanly. So one may say it's a problem with Maven that you are not flexible enough to do two compilations, I rather say it's a feature cause it forces you to do things right. 4) Mavenizing Falcon and ASJS turned out to be harder than expected This was solely due to the fact that when I started working on this I based my initial assumption on how much work it would be on experience I had. For example I did the same for huge codebases as Volkswagen (where I migrated all of their software from Ant to Maven) and I just finished a project for one of the biggest german Banks where I did the same. The one thing that Falcon greatly differed from the rest is code-quality and architecture. Most of the problems I was having was due to unclean code handling things in a way that I don't get an error message, but a NullPointerException, which you have to track down. I have requested us to go slower and work on quality, but probably most people seeing it the same way on this list kept quiet and you claim "feature over quality". Well I see it differently ... what use is a feature, but using it is difficult cause whenever you don't use it right it blows up, giving you no clue why. Mavenizing Falcon was hard, yes, but migrating ASJS turned out to be a nightmare cause the core concepts seem to be flawed. This is where I ran into a wall. I complain about problems in the architecture and all I get in response is, "Then just use Ant cause that doesn't care" 5) Why not use Ant for the things that are hard and Maven for the rest? This way we have to configure two build systems. And it doesn't make us think twice about design decisions. If our first thought doesn't work with maven we do it with Ant. Anyway it wouldn't solve the root problem: The large amount of people having problem with the Ant build. If the Ant build is so good, why do we tend to have Build related questions on these lists avery few days? IF the Ant build was solid and good I would never have put so much weight into migrating. Do you hear me migrating the old SDK? Probably not cause that build simply seems to be working. Except for those periodic dropouts of download sources, but by downloading stuff from Maven central I can't even remember the last time someone had a problem with that. 6) Having a problem with Ant No I'm not having a problem with Ant ... it's uncountable problems. Every time I start working on something and have to touch the Ant build. For example using apache commons-io for handling the Path normailsation instead of re-implementing this logic over and over again. How do I get this Jar? How do I get it into the right classpath? How much code do I need to add this to Ant? In Maven I just add a dependency and continue coding. With Ant this is a difficult task. So I should post the log of a failed ant Build? That's huge and unfortunately It doesn't show the important parts. I remember that my build failed with 4 failed tests, but I wasn't able to find what tests failed in the log? I keep on deleting my workspace, checking out everything from scratch to solve problems, but that simply can't be the way to go. 7) Providing Maven artifacts This is not the issue, I think I solved that problem ... the SDK is perfectly usable using my Mavenizer and for Falcon and ASJS I added some Ant scripts to produce the artifacts. But whenever things with the SDK changed these scripts would have to be manually adjusted to the latest changes. I was expecting this to happen, but I guess it's wasted time in the "feature over quality" discussion. I kept on re-adjusting those scripts for every ApacheCon, but have come to the conclusion that the current Ant build is the root problem of the FlexJS project and hereby started an initiative to solve that problem. I want to actually start fixing things, making things stable, but I won't do that with such a fu**ed up build. And I guess this is what's keeping several people on this list from contributing. 8) Ant == High developer productivity Are you actually reading the posts on this list? People are claiming not having the time to fix things. If you look at my SonarQube there would be an enormous amount of low hanging fruit that you could fix several in your lunch-break. But noone even thinks about that cause he knows the lunch-break would not be enough to even get started. So I would like to claim that Ant != High developer productivity. It might be high Alex productivity, but I wouldn't claim that it is good for the overall developer. Hey ... I'm the best example for it not being that way so we are currently at a draw. 9) Ant == High code quality? Are you serious? Falcon and ASJS has by far the worst code quality I have ever come across. It's so bad that i stopped talking about it in my company cause I was afraid that they would make fun of me, if someone ever had a look. I have come across uncountable places where I had to laugh cause it would be a perfect nerd-joke on a t-shirt ;-) 10) Ant == High maintainablity? Are you serious? Try adding something simple as a new dependency to the build. You might be able to do that, but I doubt 90% of the people on this list do. I even have real big problems with that. Even if you just add a new module, or add tests to a module? You call the Ant build maintainable? I don't. 11) Only one expert on the project Well at least we would have one expert. I wouldn't claim the Ant build to be expert work. And by cleaning up the project the complexity level would drop that much that you wouldn't have to be an expert to continue. I agree migrating to Maven is a job that even very hard for an expert, but I'm doing that an progress had been very good for Falcon and I would be willing to do that for ASJS. As soon as that's done the rest should be easy. and if the sky should fall on my head after the migration, we are in the ASF ... the place that builds Maven, so what would be so hard in simply asking fellow ASF people at the Maven project? It's not that I'm the only expert on this topic. 12) would having a parallel set of projects in an "externs" folder help or not? No it would not. I read your emails but you don't seem to be reading my answers. Building the externs is the smallest problems I am having. Actually that's the part that's working nicely. I am having problems with the rest- Building ASJS libraries that depend on other ASJS libraries. 13) Flex isn't a corporate sponsored project I think it is ... Adobe is paying you full time to work on this, so I guess it is a corporate sponsored project. What is if Adobe decided to stop paying you for working on Flex? Then we would be stuck with this build that none, not even you seem to understand to 100%. I'd rather be stuck with a standard build, that follows some standard rules instead of with the current solution ... and ... Adobe promised to support us for 5 years by paying someone to continue working on Flex ... so how much time do we have left? Ufff ... think I'm through with it :-) I think I'll sketch my vision of flex in a separate Email ;-) Chris ________________________________________ Von: Alex Harui <aha...@adobe.com> Gesendet: Freitag, 6. Mai 2016 02:24 An: dev@flex.apache.org Betreff: Re: [FALCON] Code analysis stats for Falcon On 5/5/16, 1:36 PM, "omup...@gmail.com on behalf of OmPrakash Muppirala" <omup...@gmail.com on behalf of bigosma...@gmail.com> wrote: > >For multiple targets, I think it should be possible by using different pom >files for different targets. You could have a parent pom that calls these >two poms if you want to chain them together. Sounds possible. I wonder why we haven't tried that yet. > >From an end user point of view, I don't need to have SDK downloaded, no >env. variables set, no dependencies to download, etc. All I have to do is >run "mvn install" from my project folder where I have my FlexJS project. >Maven will take care of everything else (downloading, compiling, copying, >etc.) It will also cache everything in the right places so that nothing >has >to be downloaded more than once. > >From an SDK developer/contributor point of view, I want to be able to run >maven and quickly compile the changes I make. This makes it easier for me >to contribute to the SDK development. > >This is the end goal of what Chris is trying. Ant does not come close to >this. Actually, other than Playerglobal and FlashPlayerDebugger, Ant already does this. And it could easily be made to do the other two but they are build tools and I wasn't sure our official build scripts can/should do that (needs licensing acceptance, makes us appear to have dependencies on non-AL-compatible things). I'm totally in favor of having Maven artifacts. I don't understand the "all-Maven-for-every-build-step or nothing" attitude. So what if we use Ant for some of it? -Alex
