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: Luke Bellandi <email@hidden>
- Date: Thu, 26 Apr 2007 15:35:37 -0700
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