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]
