flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Harui <aha...@adobe.com>
Subject Re: AW: How to deal with Falcon/CompC FDKs?
Date Fri, 11 Apr 2014 17:00:57 GMT
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.dutz@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:aharui@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.dutz@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
>


Mime
View raw message