As i mentioned ... I hate Adobe and Apache both starting with an "A" ;-) Of course I meant Apache and not Adobe.
The problem is with Maven I can't do the "default/override" thing. I could have always reference default and add falcon additionally, but this would make managing the versions. As I mentioned, if a user watend to use falcon 4.13 in Flexmojos, he would end up with the default mxml 4.12 as well as the falcon 4.13 being in the classpath, which would be completely yuck. I think I'll stay with creating two dedicated pom modules "mxmlc-compiler" and "falcon-compiler" and the user explicitly has to decide on which he wannts to use. If he doesn't, FM will simply be outputting an error message telling him what to do. Chris -----Ursprüngliche Nachricht----- Von: Alex Harui [mailto:aha...@adobe.com] Gesendet: Freitag, 11. April 2014 19:01 An: dev@flex.apache.org Betreff: Re: AW: How to deal with Falcon/CompC FDKs? Why can't there be a default dependency from the SDK to MXML compiler? I assume you meant to use org.apacheŠ for Falcon. Does doing this require a separate package for the compiler or will you just stick the relevant jars up in Maven Central? -Alex On 4/11/14 9:43 AM, "Christofer Dutz" <christofer.d...@c-ware.de> wrote: >Ok ... well another option would be to strip the default compiler from >flexmojos. The upside would be that I could give both compiler >artifacts different names and the user could decide which one he wanted >to use by adding the corresponding dependency. The downside would be >that it would no longer be possible to beginnners to start with Flex >and Flexmojos without providing a compiler. But thinking about that ... >I never liked the default anyway. > >So how about the Mavenizer creatng: > >For the current MXML compiler: > ><dependency> > <groupId>com.adobe.flex.compiler</groupId> > <artifactId>mxml-compiler</artifactId> > <version>fdk-version</version> > <type>pom</type> ></dependency> > >For Falcon: > ><dependency> > <groupId>com.adobe.flex.compiler</groupId> > <artifactId>falcon-compiler</artifactId> > <version>fdk-version</version> > <type>pom</type> ></dependency> > >And to get rid of the current: > ><dependency> > <groupId>com.adobe.flex </groupId> > <artifactId>compiler</artifactId> > <version>fdk-version</version> > <type>pom</type> ></dependency> > >Any objections? > >Cool thing ist hat I should be able to change FM7 to support these >changes without breaking the builds of people having FDKs mavenized by >previous versions of the Mavenizer. > >Chris > > >-----Ursprüngliche Nachricht----- >Von: Alex Harui [mailto:aha...@adobe.com] >Gesendet: Freitag, 11. April 2014 18:27 >An: dev@flex.apache.org >Betreff: Re: How to deal with Falcon/CompC FDKs? > >Hi Chris, > >Not sure I fully understood this, but consider thinking about MXMLC and >Falcon as different sub compilers supplied by different companies. I >would imagine there are other sub compilers in the Maven universe, no? > >For a while, at least, folks building projects may wish to use Falcon >or revert back to MXMLC if there are bugs in Falcon, so having the >compiler be a separate dependency should allow them to choose their >compiler by changing a dependency somewhere. And better yet, Falcon >and MXMLC are Java projects and may not need a mojo. I am open to >creating a separate MXMLC-only release package if that helps. > >Does that help toward a solution? > >-Thanks, >-Alex > >On 4/11/14 9:18 AM, "Christofer Dutz" <christofer.d...@c-ware.de> wrote: > >>Hi, >> >>I finally managed to have the Mavenizer use Falcon to compiille the >>Theme SWCs and it seems to be running fine :) >> >>Now I had the problem, that currently it would be possible to have two >>variants of mavenized compiler in the FDK. So how should web e able to >>distinguish between both? >> >>If I for example generate a org.apache.flex:compiler:pom and a >>org.apacche.flex:compiler-falcon, I guess this would be a problem, as >>including compiler-falcon in the maven config wouldn't override the >>compiler version that is included per default. So If Flexmojos was >>built against 4.12 and I wanted to use Falcon in version 4.13, the >>maven build would user compiler-4.12 and compiler-falcon-4.13, which >>could be really bad. >> >>Another option would be to add classifiers: so the falcon and the >>compc version would both be called compiler, but one would have the >>cclassifier "compc" and one would be "falcon". Then the Override >>mechanism would work. I would then make Flexmojos use "compc" as >>defaullt and we should have a minimal impact on that. Unfortunately >>classifiers can't be used for this as if you have mmultiple artifacts >>with different classifiers, they still share the same pom and >>classifiers seem to be not availablle for pom-modules. >> >>One way to solve this problemm would be to instead of creating a >>cpmpiler pom artifact, to create a jar artifact, that contains all the >>jars content of all the dependencies of the pom, but I think this is >>pretty ugly :( >> >>So I would have another proposal: >>How would it be to keep the compiler the way it was allways done >>including compc and mxml and to add another pom that contains falcon >>and to change Flexmojos to check for falcon and as soon as that's >>availallbe it would use that, if not it would use the default. Now we >>would have MXML, CompC and Falcon in the build path but from a maven >>perspective this would be the cleanest solution. >> >>What do you think? >> >>Chris >
