Hi Alex, the problem is that a Maven build of an Artifact goes through a fixed set of phases ... one of these is "generate-sources" and one of them is "compile" ... "compile" naturally comes after "generate-sources". In the case of Falcon, there are some classes which the generators need to be compiled when generating code. So you see there is a problem with this. So I have to extract these into a separate Maven artifact (jar file) and add a dependency on that. A Maven plugin is just a jar with some meta-data. I didn't change the UnknownTreePatternInputOutput class at all ... it's in the plugin exactly the same way it was in Falcon. So you could continue to use the "unknown.tree.pattern.input.output"-Target and "unknown.tree.handler.patterns"-Target in the build.xml, but would have to adjust some paths.
I could also use the exec-maven-plugin to manually execute the generation (exactly the same way as in the Ant script). In this case the artifact wouldn't have to be a Maven-Plugin, but could be a Jar with one class. But no matter what, it doesn't change the need to have the generator class compiled before the code-generation. Anyway ... I don't like the idea of bundling code generators inside the artifacts they created. And it requires builds like: Build this and that class ... and this package ... ignore the rest ... so stuff ... compile the rest. That's not really nice to maintain and certainly not nice to work yourself into. It's one of the things that Maven intentionally makes hard, cause doing it the easy way actually is bad. It might save you a little time when implementing, but it makes it hard for others to dig into the project, it costs additional time every time you need to do maintenance. I fixed the other problem by not using the Antlr plugin, but by using the exec-maven-plugin to spawn a new JVM with the working-directory set to the directory with the grammar ... not pretty, but it works now. The reason that it works with Ant is that Ant seems to spawn new VMs everywhere and they seem to set the working directory for every execution. I pinged Tom about doing a 1.10.3 release of JBurg to resolve the classloading issue in JBurg as well as releasing the jburg-maven-plugin. I guess you won't be able to try this without these two parts. As soon as that's done, I will setup a branch and commit my changes so you guys can review them. I think the consolidation of code generation shouldn't be done now ... It's something I have on my radar AFTER the build is cleaned up. Don't want to dig up too many holes ... I might end up in one ;-) Chris ________________________________________ Von: Alex Harui <aha...@adobe.com> Gesendet: Samstag, 20. Februar 2016 07:47 An: dev@flex.apache.org Betreff: Re: AW: AW: [FALCONJX]Compiling Falcon with externs problems On 2/19/16, 12:50 PM, "Christofer Dutz" <christofer.d...@c-ware.de> wrote: >Ok ... so what do you think of this? ;-) > >[INFO] >------------------------------------------------------------------------ >[INFO] BUILD SUCCESS >[INFO] >------------------------------------------------------------------------ >[INFO] Total time: 14.472 s >[INFO] Finished at: 2016-02-19T21:35:49+01:00 >[INFO] Final Memory: 29M/387M >[INFO] >------------------------------------------------------------------------ > >And the cool thing ... without a single environment variable ;-) Good progress! > >I finally managed to build the falcon.jar completely with maven. >Besides moving stuff around, I did need to create two additional >artifacts: >1. A maven plugin (falcon-unknown-tree-handler-generator-maven-plugin) >that generates some strange class from an xml file for that I moved the >org.apache.flex.compiler.internal.as.codegen.UnknownTreePatternInputOutput > class to that plugin (A code generation helper shouldn't be part of the >falcon jar anyway) I'm not that familiar with Maven plugins or the UnknownTreePattern code, but why did it have to become a Maven plugin? Won't that make it hard to have an Ant equivalent? I think it would be ok to remove that class from the Falcon jars, but why can't a Java file just be compiled and run as part of the Maven build? That's what it looks like the Ant build does. >2. I needed to move the interface >org.apache.flex.compiler.internal.as.codegen.IASNodeAdapter into a >dedicated jar as this class needs to be compiled in order for JBurg to be >able to run. Is that because Maven doesn't like dealing with .class files? > >One thing that's really ugly though, is that Antlr seems to look for the >vocabulary files "ImportMetadataTokenTypes.txt" in the directory where >the VM is started. Which is the root of the maven project ... have to >figure out something how I can avoid that. Will dig in to the sources of >the Antlr plugin and hopefully sort that out soon. Hmm. That file is not at the root of the current Falcon projects but Antlr2 seems to find it. > >But one thing that could be good, would be to streamline the used >generators a little ... we are using Antlr2, Antlr3, JFlex, JBurg and our >own custom one ... think that's not really nice for useablity. But for >now I'll focus on the maven migration. I'm not opposed to someone trying to consolidate this. I am pretty sure it won't be me. Thanks, -Alex
