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'[email protected]> 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:[email protected]] > Sent: donderdag 28 mei 2015 16:09 > To: [email protected] > 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.. > >
