On Tue, Jan 18, 2011 at 10:19, Marvin Froeder <[email protected]> wrote:

>
>>
>>> 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...


>
>
>>
>>
>>> To deal with the problem correctly, whoever is publishing the SWC must
>>> publish the optimized SWF as well.  This is specially trickier when some as3
>>> metadata must be preserved, so it is the role of the person that produces
>>> the SWC to produce the optimized SWF as well.
>>> Sure, I could accept that, but, FM users already proven that if there is
>>> a easier lifecycle that will potentially lead to the problems if you don't
>>> really know what you are doing, people will go the easy road then write a
>>> huge blog, twitter or whatever saying how flexmojos screw their life....
>>> not blaming on you, just saying what already happen with me more then once.
>>> Not really inclined on add such thing into FM code.   Not that I did any
>>> code last 6 months ;)
>>>
>>
>> Well, I can live having that code on my personal flexmojos installation
>> for use in-house :) The reason behind that mojo is we wish to migrate to
>> RSLs but we needed a simple and easy way to generate RSLs for those
>> dependencies not publishing the SWF file.
>>
>> I don't actually know if it is possible to make that goal runnable only
>> outside of the build lifecycle, like the default maven installer mojo...
>>
>
> That would make me more comfortable with it...
>

Then I'll dig about it, I think it can be achieved by using an expression
parameter without any default which takes values like
"dependencies","transitive-dependencies" or "artifact" with the latter
requiring artifactId, groupId, version and optional classifier. With such
goal you can say something like "install or deploy SWF when missing" and
such goal can be run on demand outside of the build lifecycle.


>
>
>>
>>
>>>
>>> About the InstallerMojo, what is the value it brings over OtimizerMojo
>>> with optimizeRsls set to false? Am I missing something?
>>>
>>
>> Humm... in flexmojos-3 there's not an optimizeRsls configuration parameter
>> and I didn't want to break too much. Anyway, the reason I started that mojo
>> is the optimization process fails, or, better, it ignores my
>> keepAs3Metadatas directive which is the main reason I started to contribute
>> on this project.
>>
>
>
> http://repository.sonatype.org/content/sites/flexmojos-site/3.7.1/optimize-mojo.html#optimizeRsls
>
> https://github.com/Flexmojos/flexmojos/blob/flexmojos-3.x/flexmojos-maven-plugin/src/main/java/org/sonatype/flexmojos/optimizer/OptimizerMojo.java#L92
>
> Am I missing something?
>
>

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...


>
>> If I can get the OptimizerMojos to correctly preserve my metadatas I can
>> drop the InstallerMojo and add the optimizeRsls parameter to the former, but
>> it looks to me an `optimize` goal should ever perform optimization :)
>>
>> Can you help me with that metadata? I'm not confident with the SWF format
>> or mxmlc API, can you please check if I did something wrong?
>>
>
> FM4 handles that.
>

I know, but we are stuck to FM3 for many different reasons. And I was trying
to backport that functionality to FM3 with my limited knowledge of the MXML
compiler API...

I'm really sorry to bother you on that, I thought I could be able to solve
the problem on my own and just contribute the solution, but as we all can
see... I was wrong once more. :)


>  --
> 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]<flex-mojos%[email protected]>
> For more options, visit this group at
> http://groups.google.com/group/flex-mojos
>
> http://flexmojos.sonatype.org/
>

-- 
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/

Reply via email to