Details
-
Type:
Bug
-
Status:
Closed
-
Priority:
Minor
-
Resolution: Fixed
-
Affects Version/s: buildnumber-maven-plugin-1.0-beta-3
-
Fix Version/s: None
-
Component/s: osxappbundle
-
Labels:None
-
Environment:HideMac OSX 10.5.7
Model Name: Mac Pro
Model Identifier: MacPro3,1
Processor Name: Quad-Core Intel Xeon
Processor Speed: 2.8 GHz
Number Of Processors: 2
Total Number Of Cores: 8
L2 Cache (per processor): 12 MB
Memory: 4 GB
Bus Speed: 1.6 GHz
Boot ROM Version: MP31.006C.B05
SMC Version (system): 1.25f4ShowMac OSX 10.5.7 Model Name: Mac Pro Model Identifier: MacPro3,1 Processor Name: Quad-Core Intel Xeon Processor Speed: 2.8 GHz Number Of Processors: 2 Total Number Of Cores: 8 L2 Cache (per processor): 12 MB Memory: 4 GB Bus Speed: 1.6 GHz Boot ROM Version: MP31.006C.B05 SMC Version (system): 1.25f4
-
Complexity:Intermediate
-
Number of attachments :
Description
After a mvn clean package I looked at the SetFile specific bits in the com.apple.FinderInfo information for the app file using
xattr -l target/buildapp-1.0-SNAPSHOT/BuildApp.app
on the mac app bundle directory. What came out was:
- * * *
0000 00 00 00 00 00 00 00 00 08 80 00 00 00 00 00 00 ................
0010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
What was expected was: - * * *
0000 00 00 00 00 00 00 00 00 20 00 00 00 00 00 00 00 ................
0010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
As far as I can tell by using SetFile to set and unset bits on a directory the meaning of the 16 bits are as follows (see the SetFile man page):
AVBS TC?I - NM?E ???D
0000 1000 - 1000 0000 --> what was produced
0010 0000 - 0000 0000 --> what I expected from SetFile -a B "someDir"
Related to this problem was another where I switched from using alpha-1 to the alpha-2 version of the plugin. This caused me to get a *.app file that had the invisible bit set. I.e.
0000 00 00 00 00 00 00 00 00 48 01 00 00 00 00 00 00 ........H.......
0010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
which translates to:
0100 1000 - 0000 0001 -> invisible *.app file.
This made the .app file not show up in the find and even the .dmg file appear empty when opened. The only way I could get around this was to use a different application/build name.
Out of curiosity I tried the directory creation and SetFile code from the plugin in a test app, but it works fine, and sets the bit as expected on any new file I create. However I can get strange bits showing up if I reuse the same directory names as the build, even after a mvn clean. Its like the mac is remembering and reapplying file attribute information elsewhere.
SetFile from the command line works as expected i.e.
SetFile -a avBstclinmed target/buildapp-1.0-SNAPSHOT/BuildApp.app/
ensures the bundle bit is set and everything else is unset.
But running the same command from a java app does not work and doesn't throw and exception as to why not.
Has anyone else seen this problem? It may be related to the empty dmg file reported in MOJO-1302.
Can you check that your file attribute bits are set as expected on your machine (i.e. is it just my machine acting weird)?
Thank you (and thank you for the plugin!)
Attachments
Issue Links
| This issue duplicates: | ||||
| MOJO-1302 | if finalName is defined the created dmg does not show the application in Finder |
|
|
|
I was having the same problem and I did some digging and think I found the cause.
The creation of the setfile process is like this:
setFile.setExecutable(SET_FILE_PATH); setFile.createArgument().setValue( "-a B" ); setFile.createArgument().setValue( bundleDir.getAbsolutePath() ); setFile.execute();This is essentially the same as running the command line this:
because the each value is sent as a seperate argument. In this case setfile thinks "-a B" is the file name (I guess because it doesnt match any of its options?) and fails with a useless error message:
I got the same error message when I logged the output of the process within the plugin. I'm not sure why some file/directory names don't expose this problem, I have two builds going, 3.1-SNAPSHOT and 3.0.1-SNAPSHOT and only one of them had this problem.
The attached patch splits the argument in two so its parsed properly. It fixed it in my case at least.
setFile.setExecutable(SET_FILE_PATH); setFile.createArgument().setValue( "-a B" ); setFile.createArgument().setValue( bundleDir.getAbsolutePath() ); setFile.execute();