1) Otherwise, why would we need to build a custom Mojo just to do regex string replacement?
Because regexp replacement was the wrong thing to do from the start. It would have been good to use a diff patch approach and for that there are already plugins available and tested. Anyway ... have you looked at the "Mojos"? They are simple classes implementing an interface with an execute method ... I wouldn't call that "first you have to create a mojo" sort of like climbing the Mt Everest ;-) 2) Why does Maven support calling Ant in the first place? This is the one and only plugin I would like to have un-deployed. In my trainings I always say that this plugin is the step to the dark side of the force, cause if you start using it for one thing you tend to go the easy and messy way more and more often. I usually even ban the usage of that plugin to prevent bad things from happening. 3) Do we know of any other Maven-built code bases that use conditional compilation and offer slightly different APIs for downstream modules? I don't know of any, but I do know projects that produce different output from the same input ... if you look at GWT projects for example. Here part of the code is compiled to java and another is compiled to JavaScript but everything is written in Java. I probably don't know of any, cause it's probably not the question "how do we structure such a project?" which we should ask but "why do we need different APIs in our libraries depending on the output?". I am proposing to make the libraries, like Core, self contained so they have the same API no matter what output they are needed for. For example IUIBase ... why do we need to have different return types for get element? Sure the implementation might be different, but then I would suggest to introduce an intermediate layer that is mapped to IFlexJSElement and WrappedHTMLElement. This way we don't need conditional compilation everywhere IUIBase.element is accessed. I think that's an implementation detail only Core should worry about and all the downstream Libraries should only know "IElement" (IElement being the non existing element abstraction). This would also improve IDE support as the IDE doesn't have to know about conditional compilation. Currently IntelliJ is completely full of red code, cause it doesn't really know what to do with it. Also SonarQube will definitely not know what to do. If we were to abstract the implementation details, we only need the externs for Pure JavaScript libraries and for those the externs approach is absolutely valid. So If you ask me for my vote on this it's deffinitels: "Cleanly abstract the implementation and eliminate the need to generate two types of artifacts from one code base". I know this is work, it's not glorious work you get Aaaaahs and Ooooohs at conferences for, but it's work that just need to be done. I am willing to work on this, but I'm not willing to work on this all on my own and I'm not willing to waste my time in continuing to support sloppy design work. Chris ________________________________________ Von: Alex Harui <aha...@adobe.com> Gesendet: Freitag, 6. Mai 2016 09:16:53 An: dev@flex.apache.org Betreff: Re: [FALCON] Code analysis stats for Falcon On 5/5/16, 11:28 PM, "carlos.rov...@gmail.com on behalf of Carlos Rovira" <carlos.rov...@gmail.com on behalf of carlos.rov...@codeoscopic.com> wrote: >2016-05-06 2:24 GMT+02:00 Alex Harui <aha...@adobe.com>: > >> >> 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 >> >> >Alex, cause is the nature of maven...is all or nothing. Embrace it or let >it go. Ant is a thing of the past, and if you want FlexJS to be the >"framework of the year" in 2017 or 2018, it could not be supported in some >kind of...mixture of ant scripts that are so cumbersome to manage. I >already said, and is just MHO...this is like the turn from SVN to GIT. All >actual projects are GIT based, if Apache Flex would be already SVN based, >what's the read people approaching this project would have and seeing we >are stuck in such arcane piece of software? My opinion (and is just that, >my opinion) is that lots of that people would directly not see far of that >point. > >For me a build system that makes such complex and big project is very >recomendable. But to make such effort, not only we need a guy with the >extensive knowledge it requieres, we need support him during the period >that transformation happens, letting drive the change. > IMO, Git does everything SVN does and more. Maven doesn't, IMO, fully replace Ant. Otherwise, why would we need to build a custom Mojo just to do regex string replacement? Why not just call Ant to do that? Why does Maven support calling Ant in the first place? Do we know of any other Maven-built code bases that use conditional compilation and offer slightly different APIs for downstream modules? Let's see how they organized their code. Maybe the answer we want is somewhere in there. But if there isn't an easy answer, let's offer the customers the artifacts they want and worry less about how we create those artifacts. Why put the entire project on hold? Don't people also want to know if we can shim the MX and Spark libraries? -Alex
