> > >>>>> Why? Well, the library.SWF (from the 3rd party SWC) has a given >>>>> checksum. Then you optimize that SWF, which will have a new checksum. In >>>>> order to get this RSL usable, you need to update this checksum inside the >>>>> original SWC, that will break maven md5, sha1 and signatures. This is >>>>> really really bad. >>>>> >>>> >>>> Agreed, but for what I've seen until now most flex libraries doesn't >>>> publish their RSL equivalent... >>>> >>> >>> "Two wrongs don't make a right" >>> >> >> :) You are right, but still I've a problem to solve. Hope you can see my >> point... >> > > Yes, I do, some third party SWC producer is dropping the ball. Which is > bad, but fixing that on flexmojos makes it is bad as well. > >> Ok
> No, I was missing it... :) Anyway I think we should avoid re-building and >> updating the digest in case optimization is disabled, don't you agree? I >> think we can just include the digest block inside the optimizeRSL block... >> > > Ok > <http://flexmojos.sonatype.org/> > Then I'll do it and it will be on my fork this evening, I still can't push to github at work. About the FM3 vs FM4 regarding the SWF optimization, I think we are doing the exact same thing, we both provide a Configuration and a CompilerConfiguration to the mxmlc `optimize` method, the only thing changing is the approach used to provide such informations: FM4 is a lot more structured than FM3. I'm wondering if this could a problem with the compiler API... do you think it's worth trying to update the dependencies to the 3.5 sdk? -- You received this message because you are subscribed to the Google Groups "Flex Mojos" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/flex-mojos http://flexmojos.sonatype.org/
