On 5/13/17, 6:01 AM, "Christofer Dutz" <christofer.d...@c-ware.de> wrote:
>I wonder why topics in which I am forced to respond in a lengthy fashion >always pop up when I’m travelling and responding lengthily on my phone is >no fun. But it seems that I must. Happens to me too. IMO it is a sign of a healthy community. Our vacations schedules should not impact folks scratching their itch. > >You wrote “AFAICT” (after checking the meaning of this) … well the thing >is you are telling wrong. Maven is far more than a simple xml with nodes. >Behind every dependency declared in the pom there are transitive >dependencies. Different ones depending on the type. You can inherit >dependencies from parents and have dependencies in profiles which are >activated on checking multiple types of conditions. Also, you can use >dependency management in the pom or in any parent poms which handles >which versions are loaded and how transitive dependencies are eventually >excluded. You can even use properties to configure versions or other >parts. I could keep on going mentioning mechanisms in place here, but I >think this is enough. If you would implement pom handling the way you >were mentioning, this will break the entire Maven integration unless you >use Maven to achieve this. Bundling maven with the compiler is the wrong >way and I don’t see any sense in this. > >However, getting rid of the config files would be super-easy if the >configuration system was cleaned up. Then the Maven plugin would >configure everything using Maven (this is ok cause it’s a Maven plugin) >and pass in the configuration into the compiler. Right now, I wouldn’t >trust the concurrent compilation of modules Maven supports as I only >managed to clean up parts of the configs. Much more cleaning up needed >here. Solving this problem by adding another module that needs >maintenance is the wrong way. > >The Eclipse Aether library has recently been donated to the Maven >project, which is handling the dependency resolutions and soon this will >become an extendable mechanism. As soon as that’s done I can extend the >maven plugin to support Flex’s dependency scopes. Then things would start >becoming even more complex if the mechanism was manually implemented in >the compiler. > >So, regarding Maven questions … please trust my opinion. The internals of >the compiler are your domain, Maven however is something I do have >expertise in and you should trust me, if I make such suggestions. You are definitely our maven expert, but as the expert, you do have to take time to educate the rest of us, and also be patient with us as we learn. I get that Maven dependency management is quite sophisticated, but I'm just trying to solve a practical issue. If you will have the time to build out your re-do of the configuration system and do so in a way that folks can use the compiler in Ant and off the command-line without Maven and you'll get to it "soon", that would be great, I've got plenty of other fish to fry. But while the dependency management system is quite sophisticated, AFAICT, our use of it specifically for passing the list of SWCs and compiler options to the compiler does not seem to leverage this sophistication. I'm just interested in saving the community time, so if you won't be able to do the re-do "soon", and from a practical matter, the things we need to pass from the pom.xml to the compiler can be easily found by parsing the pom and parent poms, and I can leverage XML parsing code already in the compiler, and I can spend a day on it and it will save other folks more than a day, it might be worth it, even if we abandon it later. It may not be theoretically perfect, but it might net out to helping the community. I just tried adding a <thisIsAlex>true</thisIsAlex> tag to the DragDrop SWC's pom.xml compiler configuration and the maven build didn't seem to care. That's sort of cool because then if I did teach the compiler to read this section of the pom.xml, it could mean that all of the non-swc options for the compiler could be copied into the configuration section in the same syntax used in the -config.xml files and we wouldn't need to change the BaseMojo when we add new configuration options or make folks use the "additionalCompilerOptions" option. So, specifically, is there something about the actual implementation of compiler options in the pom.xml that is more sophisticated than I am seeing? And will you be able to execute the re-do of the configuration subsystem soon? Thanks, -Alex
