Re: Get the package's NSBundle from a plugin
Re: Get the package's NSBundle from a plugin
- Subject: Re: Get the package's NSBundle from a plugin
- From: Mike <email@hidden>
- Date: Thu, 26 Apr 2007 17:18:04 -0700
Yeah, it could be done that way too. In fact that is the way our old
product did it - look for a flag in the prefs file after reboot and if
true, then blow away the installer. The path could also be saved in the
prefs file at install time and then the product could read that to learn
where the installer was and blow it away.
My guess is in Installer.app when "Restart" is clicked it just quits
Installer and everything goes away. It probably ignores any errors if
the bundle from a pkg can't be closed or it may in fact have already
closed the pkg when the Restart pane is displayed.
Putting a symlink in /tmp wouldn't work in this case incidentally
because our installer requires reboot and the OS blows away everything
in /tmp after each reboot.
Thanks,
Mike
Luke Bellandi wrote:
Hi Mike,
On Apr 26, 2007, at 3:05 PM, Mike wrote:
I verified that in all cases (that I know of), moving the .pkg or
.mpkg to /tmp from within a plugin does work and does not crash the
installer, but only on two conditons: 1) that the moving of the
package happen as the very last thing before the final "Restart"
button is clicked and 2) that the pkg or mpkg *requires* the Restart
option.
Under these conditions, I find that moving the package to tmp as the
last step works fine.
Just to play devil's advocate, that is not a supported use-case, even
though you've found it to work empirically for now. A file/bundle is
expected to exist for as long as it is open by a process. There is no
guarantee that the Installer is done with a package until its process is
dead.
A solution that doesn't break that contract would be to write a
lightweight sentinel tool that you spawn after your install has
completed. This tool can run in the background and wait until there are
no processes with bundle ID 'com.apple.installer' running, or until it
receives a system shutdown message, at which point it can delete the
package and quit itself.
How will it know where the package is? If your plugin makes a symlink
with a known name in /tmp/ to the package's location on disk, your
sentinel tool can look for that file and delete the file its symlink
points to (as well as the symlink.)
The only way this could fail is if a user hard-rebooted her machine and
your sentinel tool didn't have a chance to do its duty.
Just some food for thought...
- Luke
Mike
Peter Bierman wrote:
Yes, except I don't see any reason for you to instantiate an NSBundle
for the .mpkg itself. You just need the path, so you can rename(2) it
into the /tmp directory.
But removing or moving the package while the installer is still using
it is probably not going to go smoothly. It'll probably cause a crash
at some point.
You'd be better off having your app remove the package when launched.
In the meantime, please file an enhancement request in Radar for a
flag causing us to delete the package for you when the installer is
done with it.
-pmb
At 3:54 PM -0700 4/13/07, Mike wrote:
So what you are saying is to get the path to the plugin's bundle,
then manually munge it to get the full path to the containing .mpkg,
then use bundleWithPath to make a new NSBundle to the .mpkg itself?
I am assuming the upshot here is that I have to do some path
manipulation myself in order to get at the .mpkg's bundle and that
there is no way to get it directly with any NSBundle call from
within the plugin.
I've used you suggestion and done:
mpkgBundle = [ NSBundle bundleForClass:[ DeletePane class ] ];
DeletePane being my subclass to the InstallerPlugin class.
This does indeed give me the bundle to my plugin so if the manual
path munging is the way to go, then this will work.
Stéphane Sudre wrote:
Why wouldn't it work (if you replace Class with class)?
You probably have at least one subclass of the Installer Plugins
classes. If you run this method on an instance of this subclass,
you will get the NSBundle of the plugin.
Then you would just have to build the path of the metapackage
"bundle" from the path of the plugin bundle (+[NSBundle
bundleWithPath:]).
On Apr 13, 2007, at 5:02 AM, Mike wrote:
That would be a neat trick but in this case it won't work because
self is an InstallerPane which is a member of an InstallerSection
which is an NSView in the class object.
Thanks,
Mike
Peter Bierman wrote:
At 6:01 PM -0700 4/12/07, Mike wrote:
Is there an easy way to get the NSBundle of the .mpkg that
contains a plugin from the plugin's code?
I see the InstallerSection class has a -bundle method but it
appears to return the plugin's bundle, not the bundle of the
.mpkg itself. This also doesn't seem to be mentioned in Software
Delivery Guide.
A useful NSBundle trick for plugins everywhere:
[NSBundle bundleForClass:[self Class]]
This should find you the bundle that whatever class you're in
came from.
-pmb
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Installer-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Installer-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden