Chris, do you think the folder structure is "final" or could it change as you fix these issues? If "final", I will start making sure the Ant scripts and Eclipse projects work.
-Alex On 4/13/16, 3:16 AM, "Christofer Dutz" <christofer.d...@c-ware.de> wrote: >Hi, > > >today I finished cleaning up the Tests so they should now work on Mac and >Windows. > > >The current version now provides a little more sophisticated >flexjs-maven-plugin that allows a packaging of type "swc" so it no longer >produces the dummy jar files. I really didn't want them to go into the >snapshot repo. > > >I am currently struggling to build the compiler and the externs in one >build, but am having a little classloader problem, that I am currently >working on. If you build the compiler and the externs in one build the >extern compilations fail complaining about compiler classes missing. I am >working on this minor issue. so currently we have to do 3 builds: > > >mvn -s settings-template.xml clean install -P minimal > > >mvn -s settings-template.xml clean install -P compiler > > >mvn -s settings-template.xml clean install -P externs > > >If you simply copy the "settings-template.xml" into a ".m2" directory >inside your users home directory and name it "settings.xml" you can omit >the "-s settings-template.xml" part of the command. > > >As soon as we are able to produce snapshots in the ASF snapshot repo, the >first can be omitted and as soon as I have resolved the classloading >issue, the third one can be removed as well ... reducing the default to >just this build command for downloading third party stuff, building and >testing: > > >mvn clean install > >As soon as the classloading issue is resolved, I will concentrate on >bringing in the debug-player automatically. This would then remove the >need to set any environment variables at all. So it would bring down the >effort to checking out the code and running "mvn install" ... > > >One thing the current Maven build doesn't do, is prepare an installable >SDK. For this I will add an assembly project that will produce these, but >I need a little more information on how these SDK distributions should >look like. > > >For the long term, I would suggest to release the build-utils (jburg >types and little helper maven plugins) separately from the rest. They >will probably not change often and only complicate the build if they stay >part of it. For the flex-maven-plugin I would suggest to move that code >over to a separate git repo ... we currently already have a >flex-maven-plugin in the utils repo ... I guess this is where that code >belongs. Currently the plugin is really dumb, all it does is set 3 or 4 >command line arguments, I would like to make it more and more like >Flexmojos, that it doesn't need a hand written build config, but >generates one from the maven configuration. > > >So far for the update. Up till now I only have one report of someone >having tried the maven build, I would really feel comfortable if some >more would give it a try. I don't want to make this official without >having a few people having used it. ... So just checkout the >"feature/maven-migration" branch, run the "migrate-to-maven.sh" script >(On windows run that script in the git-bash or in Cygwin) and then run >the tree commands I posted above. > > >Chris > > >
