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 15:05:30 -0700
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.
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