From 37722eca39874bb6abdcd120e3e458bd62dea62b Mon Sep 17 00:00:00 2001
From: Dylan William Hardison <dylan@hardison.net>
Date: Wed, 5 Jul 2017 11:43:18 -0700
Subject: Bug 1377933 - Remove trailing whitespace from all perl files

---
 Bugzilla/Extension.pm | 78 +++++++++++++++++++++++++--------------------------
 1 file changed, 39 insertions(+), 39 deletions(-)

(limited to 'Bugzilla/Extension.pm')

diff --git a/Bugzilla/Extension.pm b/Bugzilla/Extension.pm
index e7f398784..7e53d87f3 100644
--- a/Bugzilla/Extension.pm
+++ b/Bugzilla/Extension.pm
@@ -74,7 +74,7 @@ sub load {
     my ($class, $extension_file, $config_file) = @_;
     my $package;
 
-    # This is needed during checksetup.pl, because Extension packages can 
+    # This is needed during checksetup.pl, because Extension packages can
     # only be loaded once (they return "1" the second time they're loaded,
     # instead of their name). During checksetup.pl, extensions are loaded
     # once by Bugzilla::Install::Requirements, and then later again via
@@ -89,7 +89,7 @@ sub load {
             my $name = require $config_file;
             if ($name =~ /^\d+$/) {
                 ThrowCodeError('extension_must_return_name',
-                               { extension => $config_file, 
+                               { extension => $config_file,
                                  returned  => $name });
             }
             $package = "${class}::$name";
@@ -102,7 +102,7 @@ sub load {
     else {
         my $name = require $extension_file;
         if ($name =~ /^\d+$/) {
-            ThrowCodeError('extension_must_return_name', 
+            ThrowCodeError('extension_must_return_name',
                            { extension => $extension_file, returned => $name });
         }
         $package = "${class}::$name";
@@ -124,7 +124,7 @@ sub _validate_package {
     }
 
     if (!eval { $package->NAME }) {
-        ThrowCodeError('extension_no_name', 
+        ThrowCodeError('extension_no_name',
                        { filename => $extension_file, package => $package });
     }
 
@@ -183,7 +183,7 @@ Bugzilla::Extension - Base class for Bugzilla Extensions.
 
 =head1 SYNOPSIS
 
-The following would be in F<extensions/Foo/Extension.pm> or 
+The following would be in F<extensions/Foo/Extension.pm> or
 F<extensions/Foo.pm>:
 
  package Bugzilla::Extension::Foo
@@ -198,7 +198,7 @@ F<extensions/Foo.pm>:
  __PACKAGE__->NAME;
 
 Custom templates would go into F<extensions/Foo/template/en/default/>.
-L<Template hooks|/Template Hooks> would go into 
+L<Template hooks|/Template Hooks> would go into
 F<extensions/Foo/template/en/default/hook/>.
 
 =head1 DESCRIPTION
@@ -209,7 +209,7 @@ This is the base class for all Bugzilla extensions.
 
 The L</SYNOPSIS> above gives a pretty good overview of what's basically
 required to write an extension. This section gives more information
-on exactly how extensions work and how you write them. There is also a 
+on exactly how extensions work and how you write them. There is also a
 L<wiki page|https://wiki.mozilla.org/Bugzilla:Extension_Notes> with additional HOWTOs, tips and tricks.
 
 =head2 Using F<extensions/create.pl>
@@ -243,7 +243,7 @@ There are two ways to write extensions:
 =item 1
 
 If your extension will have only code and no templates or other files,
-you can create a simple C<.pm> file in the F<extensions/> directory. 
+you can create a simple C<.pm> file in the F<extensions/> directory.
 
 For example, if you wanted to create an extension called "Foo" using this
 method, you would put your code into a file called F<extensions/Foo.pm>.
@@ -318,13 +318,13 @@ described in the L</Where Extension Code Goes> section above.
 
 During your subroutine, you may want to know what values were passed
 as CGI arguments  to the current script, or what arguments were passed to
-the current WebService method. You can get that data via 
+the current WebService method. You can get that data via
 L<Bugzilla/input_params>.
 
 =head3 Adding New Hooks To Bugzilla
 
 If you need a new hook for your extension and you want that hook to be
-added to Bugzilla itself, see our development process at 
+added to Bugzilla itself, see our development process at
 L<http://wiki.mozilla.org/Bugzilla:Developers>.
 
 In order for a new hook to be accepted into Bugzilla, it has to work,
@@ -350,7 +350,7 @@ L<Bugzilla::Install::Requirements/REQUIRED_MODULES>.
 
 If there are optional modules that add additional functionality to your
 application, you can specify them in a constant called OPTIONAL_MODULES,
-which has the same format as 
+which has the same format as
 L<Bugzilla::Install::Requirements/OPTIONAL_MODULES>.
 
 =head3 If Your Extension Needs Certain Modules In Order To Compile
@@ -385,11 +385,11 @@ named C<Foo>:
 Note that it is I<not> a subclass of C<Bugzilla::Extension>, because
 at the time that module requirements are being checked in L<checksetup>,
 C<Bugzilla::Extension> cannot be loaded. Also, just like F<Extension.pm>,
-it ends with C<< __PACKAGE__->NAME; >>. Note also that it has the 
+it ends with C<< __PACKAGE__->NAME; >>. Note also that it has the
 B<exact same> C<package> name as F<Extension.pm>.
 
 This file may not use any Perl modules other than L<Bugzilla::Constants>,
-L<Bugzilla::Install::Util>, L<Bugzilla::Install::Requirements>, and 
+L<Bugzilla::Install::Util>, L<Bugzilla::Install::Requirements>, and
 modules that ship with Perl itself.
 
 If you want to define both C<REQUIRED_MODULES> and C<OPTIONAL_MODULES>,
@@ -401,7 +401,7 @@ will have access to everything in F<Config.pm>. Don't define anything
 with an identical name in both files, or Perl may throw a warning that
 you are redefining things.
 
-This method of setting C<REQUIRED_MODULES> is of course not available if 
+This method of setting C<REQUIRED_MODULES> is of course not available if
 your extension is a single file named C<Foo.pm>.
 
 If any of this is confusing, just look at the code of the Example extension.
@@ -410,7 +410,7 @@ It uses this method to specify requirements.
 =head2 Libraries
 
 Extensions often want to have their own Perl modules. Your extension
-can load any Perl module in its F<lib/> directory. (So, if your extension is 
+can load any Perl module in its F<lib/> directory. (So, if your extension is
 F<extensions/Foo/>, then your Perl modules go into F<extensions/Foo/lib/>.)
 
 However, the C<package> name of your libraries will not work quite
@@ -421,12 +421,12 @@ which should have C<package Bugzilla::Extension::Foo::Bar;> as its package
 name.
 
 This allows any place in Bugzilla to load your modules, which is important
-for some hooks. It even allows other extensions to load your modules, and 
+for some hooks. It even allows other extensions to load your modules, and
 allows you to install your modules into the global Perl install
 as F<Bugzilla/Extension/Foo/Bar.pm>, if you'd like, which helps allow CPAN
 distribution of Bugzilla extensions.
 
-B<Note:> If you want to C<use> or C<require> a module that's in 
+B<Note:> If you want to C<use> or C<require> a module that's in
 F<extensions/Foo/lib/> at the top level of your F<Extension.pm>,
 you must have a F<Config.pm> (see above) with at least the C<NAME>
 constant defined in it.
@@ -462,13 +462,13 @@ interface of Bugzilla.
 =head3 Which Templates Can Be Hooked
 
 There is no list of template hooks like there is for standard code hooks.
-To find what places in the user interface can be hooked, search for the 
-string C<Hook.process> in Bugzilla's templates (in the 
-F<template/en/default/> directory). That will also give you the name of 
+To find what places in the user interface can be hooked, search for the
+string C<Hook.process> in Bugzilla's templates (in the
+F<template/en/default/> directory). That will also give you the name of
 the hooks--the first argument to C<Hook.process> is the name of the hook.
 (A later section in this document explains how to use that name).
 
-For example, if you see C<Hook.process("additional_header")>, that means 
+For example, if you see C<Hook.process("additional_header")>, that means
 the name of the hook is C<additional_header>.
 
 =head3 Where Template Hooks Go
@@ -485,10 +485,10 @@ intended to distribute.)
 The files that go into this directory have a certain name, based on the
 name of the template that is being hooked, and the name of the hook.
 For example, let's imagine that you have an extension named "Foo",
-and you want to use the C<additional_header> hook in 
+and you want to use the C<additional_header> hook in
 F<template/en/default/global/header.html.tmpl>. Your code would go into
-F<extensions/Foo/template/en/default/hook/global/header-additional_header.html.tmpl>. Any code you put into that file will happen at the point that 
-C<Hook.process("additional_header")> is called in 
+F<extensions/Foo/template/en/default/hook/global/header-additional_header.html.tmpl>. Any code you put into that file will happen at the point that
+C<Hook.process("additional_header")> is called in
 F<template/en/default/global/header.html.tmpl>.
 
 As you can see, template extension file names follow a pattern. The
@@ -500,7 +500,7 @@ pattern looks like:
 
 =item <templates>
 
-This is the full path to the template directory, like 
+This is the full path to the template directory, like
 F<extensions/Foo/template/en/default>. This works much like normal templates
 do, in the sense that template extensions in C<custom> override template
 extensions in C<default> for your extension, templates for different languages
@@ -512,13 +512,13 @@ will be run for I<every> extension, whereas for normal templates, Bugzilla
 just takes the first one it finds and stops searching. So while a template
 extension in the C<custom> directory may override the same-named template
 extension in the  C<default> directory I<within your Bugzilla extension>,
-it will not override the same-named template extension in the C<default> 
+it will not override the same-named template extension in the C<default>
 directory of another Bugzilla extension.
 
 =item <template path>
 
-This is the part of the path (excluding the filename) that comes after 
-F<template/en/default/> in a template's path. So, for 
+This is the part of the path (excluding the filename) that comes after
+F<template/en/default/> in a template's path. So, for
 F<template/en/default/global/header.html.tmpl>, this would simply be
 C<global>.
 
@@ -531,7 +531,7 @@ C<header>.
 =item <hook name>
 
 This is the name of the hook--what you saw in C<Hook.process> inside
-of the template you want to hook. In our example, this is 
+of the template you want to hook. In our example, this is
 C<additional_header>.
 
 =item <template type>
@@ -545,7 +545,7 @@ type of output the template has.
 
 =head3 Adding New Template Hooks to Bugzilla
 
-Adding new template hooks is just like adding code hooks (see 
+Adding new template hooks is just like adding code hooks (see
 L</Adding New Hooks To Bugzilla>) except that you don't have to
 document them, and including example code is optional.
 
@@ -556,11 +556,11 @@ it entirely with your extension's template, or you want to add an entirely
 new template to Bugzilla for your extension to use.
 
 To replace the F<template/en/default/global/banner.html.tmpl> template
-in an extension named "Foo", create a file called 
+in an extension named "Foo", create a file called
 F<extensions/Foo/template/en/default/global/banner.html.tmpl>. Note that this
 is very similar to the path for a template hook, except that it excludes
 F<hook/>, and the template is named I<exactly> like the standard Bugzilla
-template. 
+template.
 
 You can also use this method to add entirely new templates. If you have
 an extension named "Foo", and you add a file named
@@ -592,10 +592,10 @@ other pages that other extensions might add.
 If you include CSS, JavaScript, and images in your extension that are
 served directly to the user (that is, they're not read by a script and
 then printed--they're just linked directly in your HTML), they should go
-into the F<web/> subdirectory of your extension. 
+into the F<web/> subdirectory of your extension.
 
 So, for example, if you had a CSS file called F<style.css> and your
-extension was called F<Foo>, your file would go into 
+extension was called F<Foo>, your file would go into
 F<extensions/Foo/web/style.css>.
 
 =head2 Disabling Your Extension
@@ -617,13 +617,13 @@ return C<0> or some false value.
 
 If you've made an extension and you want to publish it, the first
 thing you'll want to do is package up your extension's code and
-then put a link to it in the appropriate section of 
+then put a link to it in the appropriate section of
 L<http://wiki.mozilla.org/Bugzilla:Addons>.
 
 =head2 Distributing on CPAN
 
 If you want a centralized distribution point that makes it easy
-for Bugzilla users to install your extension, it is possible to 
+for Bugzilla users to install your extension, it is possible to
 distribute your Bugzilla Extension through CPAN.
 
 The details of making a standard CPAN module are too much to
@@ -631,7 +631,7 @@ go into here, but a lot of it is covered in L<perlmodlib>
 and on L<http://www.cpan.org/> among other places.
 
 When you distribute your extension via CPAN, your F<Extension.pm>
-should simply install itself as F<Bugzilla/Extension/Foo.pm>, 
+should simply install itself as F<Bugzilla/Extension/Foo.pm>,
 where C<Foo> is the name of your module. You do not need a separate
 F<Config.pm> file, because CPAN itself will handle installing
 the prerequisites of your module, so Bugzilla doesn't have to
@@ -705,9 +705,9 @@ by Bugzilla, and C<0> otherwise.
 
 =head3 C<package_dir>
 
-This returns the directory that your extension is located in. 
+This returns the directory that your extension is located in.
 
-If this is an extension that was installed via CPAN, the directory will 
+If this is an extension that was installed via CPAN, the directory will
 be the path to F<Bugzilla/Extension/Foo/>, if C<Foo.pm> is the name of your
 extension.
 
-- 
cgit v1.2.3-24-g4f1b