I've created a PR that fixes this: https://github.com/chrisdutz/flexmojos/pull/11
On Fri, May 29, 2015 at 9:29 AM, Christofer Dutz <[email protected]> wrote: > 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 <[email protected]> > Gesendet: Donnerstag, 28. Mai 2015 18:33 > An: [email protected] > 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 <[email protected]> > 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'[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.. > >> > >> > > >
