> 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?
downloads.xml is called automatically by the main Ant build. You shouldn't need to call it manually, and most people will never do that. If you needed to call it manually, for some reason, it sounds like a bug. I'm guessing what went wrong is that you had some of the downloads already, but not all. If I remember correctly, when I added the Node.js externs, I discovered that when download.xml saw that some specific files were already present, it assumed that everything was downloaded. So if one download was actually missing, it remained missing. I'm sure that can be fixed easily. - Josh On Thu, May 5, 2016 at 10:30 AM, Christofer Dutz <christofer.d...@c-ware.de> wrote: > > 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. > > Chris > > ________________________________________ > Von: Alex Harui <aha...@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 > Ant. > > 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 > externs/projects/Core/target/Core-externs.swc > -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 > > > frameworks/projects/Core/src/main/flex/org/apache/flex/core/Application.as, > etc. > frameworks/projects/Core/src/main/config/compile-as-config.xml > > Produces: > Frameworks/projects/Core/target/Core.swc > > 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 > externs/project/Core/target/Core-externs.swc > > 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 > -externs.swcs. > > > Thoughts? > -Alex > > > > On 5/5/16, 6:26 AM, "carlos.rov...@gmail.com on behalf of Carlos Rovira" > <carlos.rov...@gmail.com on behalf of carlos.rov...@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 > >to > >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 > >contributing > >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 > > > >Carlos > > > > > > > >2016-05-05 12:32 GMT+02:00 Christofer Dutz <christofer.d...@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 > >>don't > >> want to be the only one complaining about the status quo. It was an > >>insane > >> amount of work to get falcon to build with Maven. I invested far nite > >>time > >> 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 > >>impression > >> I'm making things more complicated with Maven, I better invest my time > >>in > >> other projects. > >> > >> Chris > >> > >> > >> Von meinem Samsung Galaxy Smartphone gesendet. > >> > >> > >> -------- Ursprüngliche Nachricht -------- > >> Von: Harbs <harbs.li...@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.d...@c-ware.de > > > >> wrote: > >> > >> > Actually it does support ActionScript. But unfortunately I need to > >>build > >> with Maven fire that and I doubt it will be able to understand the > >>flexjs > >> code with all these define blocks > >> > > >> > Chris > >> > > >> > > >> > > >> > Von meinem Samsung Galaxy Smartphone gesendet. > >> > > >> > > >> > -------- Ursprüngliche Nachricht -------- > >> > Von: Harbs <harbs.li...@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 > >><christofer.d...@c-ware.de> > >> wrote: > >> > > >> >> Hi, > >> >> > >> >> > >> >> I just turned on public access to my SonarQube server ... there you > >>can > >> see an up-to-date code analysis report for Falcon and FalconJX. It > >>clearly > >> 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 > >http://www.codeoscopic.com > >http://www.avant2.es > > > > > >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 > >comunicamos > >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 > >nuestras > >oficinas c/ Paseo de la Habana 9-11, 28036, Madrid con la documentación > >necesaria. > >
