flex-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christofer Dutz <christofer.d...@c-ware.de>
Subject AW: FM7.1.0 and odd compilation error.
Date Fri, 29 May 2015 08:29:47 GMT
Well actually it would be a little difficult as I use the framework dependency to detect the
flex version.
But this has always been that way ... I usually always had all "rsl" dependencies added to
my pom and at the end I added the framework. This way all are happy.

Chris

________________________________________
Von: Nigel Magnay <nigel.magnay@gmail.com>
Gesendet: Donnerstag, 28. Mai 2015 18:33
An: users@flex.apache.org
Betreff: Re: FM7.1.0 and odd compilation error.

A-ha. I think I have discovered why.

FM assumes that your pom has a dependency on something like
org.apache.flex:framework:pom. If you don't, then it doesn't correctly
insert the namespaces into the config, and you get the behaviour described.

Now - we don't specify the framework pom because of the way maven totally
screws up transitive dependiencies with scopes it doesn't understand (we
mention them all explicitly instead).

It shouldn't be too difficult a patch for FM to get this back to working. I
may submit a PR if I can figure something out.


On Thu, May 28, 2015 at 3:26 PM, Nigel Magnay <nigel.magnay@gmail.com>
wrote:

> Hmm. Problem is, if I clear those 3 errors, it generates another 27
> complaining about other spark elements (s:Group, for example). So it feels
> like a losing approach :(
>
>
> I don't know if it's possible to get mxmlc to take the generated config
> file and execute it? That way I could at least make change-by-change to see
> what's actually wrong.
>
> On Thu, May 28, 2015 at 3:22 PM, L'Hommelet Filip <
> Filip.L'Hommelet@ilias-solutions.com> wrote:
>
>> Hi Nigel,
>>
>> Had the same issue with SolidColor.
>>
>> In some projects I had to use the mx-namespace for FM7.1.0 to be happy.
>>
>> So mx:SolidColor should do the trick (and won’t have your flashbuilder
>> complaining.)
>>
>> Seems like FB can mingle both s and mx namespace and be more forgiving
>> than FM7.1.0.
>>
>>
>> From: Nigel Magnay [mailto:nigel.magnay@gmail.com]
>> Sent: donderdag 28 mei 2015 16:09
>> To: users@flex.apache.org
>> Subject: FM7.1.0 and odd compilation error.
>>
>> I'm trying to upgrade our app to a more modern version of FM and Flex.
>>
>> I'm getting weird errors on a library project, like this:
>>
>> /Users/magnayn/dev/realtimehealth/realtime-workspace/realtime/flex-modules/realtime-flex-controls-spark/src/main/flex/net/realtimehealth/realtime/command/dialog/observations/ObservationGridItemRenderer.mxml(76):
>> Error: Could not resolve <s:SolidColor> to a component implementation.
>>         <s:SolidColor id="background" alpha="0.2"/>
>> I'm building with FM7.1.0-SNAPSHOT and the 4.11.1 sdk (though I have seen
>> the above on other SDKs, I think it's an issue with the move to 7.x)
>> It compiles fine in FB, so I'm resorting to looking at the configuration
>> XML generated. The prominent things I notice are:
>> The FB version has a populated <namespaces> section, the FM does not. E.g:
>> <namespaces>
>>          <!-- compiler.namespaces.namespace: Specify a URI to associate
>> with a manifest of components for use as MXML elements-->
>>          <namespace>
>>             <uri>http://ns.adobe.com/mxml/2009</uri>
>>             <manifest>mxml-2009-manifest.xml</manifest>
>>          </namespace>
>>
>> Secondly, all attempts to persuade FM to have <target-player>7.0.0</>
(by
>> the targetPlayer config section) seem to have failed, and target-player
>> insists to remain 11.1
>>
>> Thirdly the ordering in the external-library-path section seems to be
>> different from the POM in one way (I explicitly list all library
>> dependencies) in that the playerglobal is the last listed, not the first
>> (not sure if this is significant).
>>
>> I've attached the outputs from config and our POM.
>>
>> Any hints gratefully received..
>>
>>
>

Mime
View raw message