[libbread-board-perl] 16/66: fix improper uses of "it's" and "its"

[Jonas Smedegaard]

This is an automated email from the git hooks/post-receive script.

js pushed a commit to branch master
in repository libbread-board-perl.

commit 404abac157d6e1806806d2e33c9b258736e3f9d5
Author: Philippe Bruhat (BooK) <book at cpan.org>
Date:   Mon Dec 3 16:17:32 2012 +0100

    fix improper uses of "it's" and "its"
---
 lib/Bread/Board/Manual.pod                   |    6 +++---
 lib/Bread/Board/Manual/Concepts.pod          |    6 +++---
 lib/Bread/Board/Manual/Concepts/Advanced.pod |    2 +-
 lib/Bread/Board/Manual/Concepts/Typemap.pod  |    2 +-
 4 files changed, 8 insertions(+), 8 deletions(-)

diff --git a/lib/Bread/Board/Manual.pod b/lib/Bread/Board/Manual.pod
index bd52682..49af346 100644
--- a/lib/Bread/Board/Manual.pod
+++ b/lib/Bread/Board/Manual.pod
@@ -29,18 +29,18 @@ is intended to help you manage this twisty maze and remove the need
 for you to manage this manually.
 
 Take your typical Catalyst application, the Catalyst framework
-itself contains it's own mini IoC framework through the
+itself contains its own mini IoC framework through the
 component subsystem. Catalyst will manage your models and views
 making sure that they will be available when you need them in
 the controllers. Catalyst makes all this easy to manage through
-it's configuration system. This is great inside your Catalyst
+its configuration system. This is great inside your Catalyst
 application, but what about outside of it? Any sufficiently
 complex web application will have a set of scripts and/or
 command-line applications to help support it. At this point
 you are left to your own devices and must manage these
 components and their dependency chains on your own.
 
-By decoupling IoC into it's own stand-alone subsystem it
+By decoupling IoC into its own stand-alone subsystem it
 becomes possible to get that same ease-of-use you get inside
 something like a Catalyst application, outside of it.
 
diff --git a/lib/Bread/Board/Manual/Concepts.pod b/lib/Bread/Board/Manual/Concepts.pod
index f288b39..a8e4fd1 100644
--- a/lib/Bread/Board/Manual/Concepts.pod
+++ b/lib/Bread/Board/Manual/Concepts.pod
@@ -111,7 +111,7 @@ container, a database connection.
   );
 
 Now lets add an authenticator to our container. The authenticator
-requires both a database connection and a logger instance in it's
+requires both a database connection and a logger instance in its
 constructor. We specify dependency relationships between services
 by providing a HASH of Bread::Board::Dependency objects which
 themselves have a path to the services they depend upon. In this
@@ -196,7 +196,7 @@ not adapt itself well to perl.
 
 =item Block Injection
 
-While not in the 'official' 3 types (mostly because its not
+While not in the 'official' 3 types (mostly because it's not
 possible in Java), but found in a few Ruby IoC frameworks,
 BlockInjection is by far the most versatile type. It simply
 requires a subroutine and a name and you do all the rest of
@@ -415,7 +415,7 @@ form of namespacing to organize your Bread::Board
 configuration better. As it is shown with the 'authenticator' service,
 it is possible to address services outside of your container
 using path notation. In this case the 'authenticator' service
-makes the assumption that it's parent container has both a
+makes the assumption that its parent container has both a
 'database' and a 'logging' sub-container and they contain a
 'db_conn' and 'logger' service respectively. And as is shown
 in the 'app' service, it is also possible to address services
diff --git a/lib/Bread/Board/Manual/Concepts/Advanced.pod b/lib/Bread/Board/Manual/Concepts/Advanced.pod
index 702e073..06b94b4 100644
--- a/lib/Bread/Board/Manual/Concepts/Advanced.pod
+++ b/lib/Bread/Board/Manual/Concepts/Advanced.pod
@@ -27,7 +27,7 @@ next few releases, for now I need to get this one out the door.
 =head2 Subclassing
 
 Bread::Board was built from the very start to be an open system and
-to allow for the subclassing of all it's internal components.
+to allow for the subclassing of all its internal components.
 
 Here is a simple example of extending L<Bread::Board::Container> to
 build a container specific to your application.
diff --git a/lib/Bread/Board/Manual/Concepts/Typemap.pod b/lib/Bread/Board/Manual/Concepts/Typemap.pod
index 22d1250..70f2722 100644
--- a/lib/Bread/Board/Manual/Concepts/Typemap.pod
+++ b/lib/Bread/Board/Manual/Concepts/Typemap.pod
@@ -9,7 +9,7 @@ A new (read: experimental) feature of Bread::Board is typemapped services.
 These are services which are mapped to a particular type rather then just
 a name. This feature has the potential to make obsolete a large amount of the
 Bread::Board configuration by simply asking Bread::Board to figure things
-out on it's own. Here is a small example of how this works.
+out on its own. Here is a small example of how this works.
 
   # define the classes making sure
   # to specify required items and

-- 
Alioth's /usr/local/bin/git-commit-notice on /srv/git.debian.org/git/pkg-perl/packages/libbread-board-perl.git