Thanks Brian, I saw that configuration and realized that was one solution, but 
needed a non-SNAPSHOT means of completing the task.  I don't know the criteria 
that an issue gets promoted to configuration level options, but it seems like 
this issue periodically comes up as new archive formats are created.  It might 
be useful to have this as build-level configuration

It turns out that 'swc' *is* supported, 'swf' is not.  That actually makes 
sense, I can't imagine a situation where one would want to create a flattened 
archive with the contents of a swf since it is already a self-contained module 
with a single entry point.  This is how I realized I was using the wrong tool 
for the job, assembly:single with <dependencySet> seems to want to flatten the 
contents of the dependency into the output archive, where I wanted to include 
the dependency directly.  

Someone on the flexmojos list pointed out that I could use dependency:copy to 
handle this.  (So many plugins, so little time ;-))  That's working for me now.

One thing that seems relevant as a general Maven point-of-note, flexmojos has a 
goal called copy-flex-resources which takes any flex dependencies and adds them 
to the output WAR for this specific POM, and it gives a warning if the output 
artifact is not a WAR.  It's convenient, but not a universally applicable 
solution (such as when the flex resources need to be included in a zip 
archive).  So the general inquiry here is how dependency artifacts of opaque 
and previously undefined types should be included into archives such as .zip or 
.war.  Is this kind of copy-flex-resources thing the best way to do it 
everywhere?  If not, any thoughts on a better means?

On May 14, 2010, at 10:37 AM, Brian Fox wrote:

> Take a look at the patch for this issue:
> http://jira.codehaus.org/browse/MDEP-183
> 
> You would need to do something along the same lines, possibly
> introducing your own archiver impl, but this shows how you map the
> extension to the impl.
> 
> On Tue, May 11, 2010 at 2:52 PM, Brian Topping <[email protected]> wrote:
>> We've been successfully using Flex-mojos with our projects under Maven.  
>> It's been working well, but we need to include the .swf artifacts that are 
>> generated in an assembly.  That seems to be failing, and I get the following 
>> error:
>> 
>> Caused by: org.codehaus.plexus.archiver.manager.NoSuchArchiverException: No 
>> such archiver: 'swf'.
>>        at 
>> org.codehaus.plexus.archiver.manager.DefaultArchiverManager.getResourceCollection(DefaultArchiverManager.java:90)
>>        at 
>> org.codehaus.plexus.archiver.manager.DefaultArchiverManager.getResourceCollection(DefaultArchiverManager.java:128)
>>        at 
>> org.codehaus.plexus.archiver.AbstractArchiver.asResourceCollection(AbstractArchiver.java:506)
>> 
>> My assembly descriptor, for reference, is pretty simple:
>> 
>> <assembly 
>> xmlns="http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.0";
>>          xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
>>          
>> xsi:schemaLocation="http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.0
>>  http://maven.apache.org/xsd/assembly-1.1.0.xsd";>
>>    <id>php-webapp</id>
>>    <formats>
>>        <format>zip</format>
>>    </formats>
>>    <dependencySets>
>>        <dependencySet>
>>            <includes>
>>              <include>*:swf:*</include>
>>            </includes>
>>            <outputDirectory>/</outputDirectory>
>>            <unpack>false</unpack>
>>        </dependencySet>
>>        </dependencySets>
>>        <fileSets>
>>                <fileSet>
>>                        <directory>src/main/php</directory>
>>                        <outputDirectory>/</outputDirectory>
>>                </fileSet>
>>        </fileSets>
>> </assembly>
>> 
>> Is this the best way to compose the assembly?  If it is, I presume that I 
>> need to create and add an archiver that can deal with .swf (treating it as 
>> an opaque blob, presumably).  If not, it would be pretty easy to write a 
>> plugin, but I can't imagine I'm the only person running into this issue.
>> 
>> Thanks for any thoughts,
>> 
>> Brian
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
> 
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to