I’ve run into this problem quite a bit, and it came up on a post about Ray Camden’s ORM Scanner.
So the conditions are:
- User tries to install extension
- Install option does not work
- They unzip the file
- User imports the extension
- The extension works
Two subtle pieces of information that don’t always get reported:
- Extension user on Windows
- Extension author on Mac
This particular problem doesn’t appear if:
- Author uses PC
- User uses Mac
The cause of your woes:
.DS_Store files.
I’m not entirely sure why.
To combat this I build all of my extensions with ANT. (I know we provide a packager, but the work flow doesn’t work for me.) Here’re the relevant ANT targets:
<target name=”build.copy.files” description=”Create a installable version of the source code.”>
<echo message=”Copying Files to Build Location”/>
<copy todir=”${build.dir}” preservelastmodified=”true”>
<fileset dir=”${dev.dir}”>
<exclude name=’settings.xml’/>
<exclude name=’settings.properties’/>
<exclude name=’.project’/>
<exclude name=’.settings’/>
<exclude name=’build.xml’/>
<exclude name=’**/.DS_Store’/>
</fileset>
</copy>
</target>
<target name=”build.zip” description=”Creates a zip file of the build.”>
<echo message=”Creating Zip File”/>
<zip destfile=”${package.dir}/${app.name}.zip” basedir=”${build.dir}”/>
</target>
Actually the problem is simpler than that. When I made the zip, I zipped up the entire folder. So the zip was a zip of the folder. CFB insists that you create a zip from the contents. So in my (bad) zip,the top level content was the folder. In a proper extension package, the top level is the XML and handler subdirectories.
LikeLike
Oh then nevermind… Ignore that Ray Camden nonsense, he has it under control. But, this is all still true.
LikeLike
Heh, yeah. This is one of those little “nit picky” details I’m going to try to make clear at my SOTR preso. Building extensions is easy… in general. Just got a few things to watch out for. (As you already know. 🙂
LikeLike