> Hey. Good work on plugins and code reuse across projects. I work for a Rails
> development shop in San Francisco called Pivotal Labs, and I'd like to thank
> you for sharing your thoughts on all of this. We've learned a lot from your
> approach and are excited about appable plugins and their companions.

> We're having some issues with appable plugins that we'd like to make you
> aware of. We're considering moving forward with the spirit of your plugin
> approach but with our own code, but we'd really like to work together on
> this for our mutual benefit. We're attaching a toy project that exhibits
> issues 0 through 2.

> 0. We can't run your tests

> We try to execute appable_plugins_test and fail with the following
> exception:

> /usr/local/lib/ruby/gems/1.8/gems/plugin_dependencies-1.2.0/lib/plugin_depe ndencies.rb:33:in
> `plugin': undefined method `configuration' for nil:NilClass (NoMethodError)
>         from /usr/local/lib/ruby/gems/1.8/gems/plugin_dependencies-1.2.0/lib/plugin_depe ndencies.rb:18:in
> `require'
>         from
> ./vendor/plugins/appable_plugins/test/unit/../rails_root/config/../../../li b/appable_plugins.rb:309:in
> `require'
>         from /usr/local/lib/ruby/gems/1.8/gems/activesupport-1.4.1/lib/active_support/de pendencies.rb:342:in
> `new_constants_in'
>         from
> ./vendor/plugins/appable_plugins/test/unit/../rails_root/config/../../../li b/appable_plugins.rb:308:in
> `require'
>         from
> vendor/plugins/appable_plugins/test/unit/../rails_root/config/../vendor/plu gins/plugin_with_dependencies/init.rb:1:in
> `load_plugin_without_appable_plugins'
>         from /usr/local/lib/ruby/gems/1.8/gems/rails-
> 1.2.2/lib/initializer.rb:401:in
> `load_plugin_without_appable_plugins'
>         from /usr/local/lib/ruby/gems/1.8/gems/activesupport-1.4.1/lib/active_support/co re_ext/kernel/reporting.rb:11:in
> `silence_warnings'
>         from /usr/local/lib/ruby/gems/1.8/gems/rails-1.2.2/lib/initializer.rb:401:in
> `load_plugin_without_appable_plugins'
>         from
> ./vendor/plugins/appable_plugins/test/unit/../rails_root/config/../../../li b/appable_plugins.rb:39:in
> `load_plugin_without_loaded_plugins'
>         from /usr/local/lib/ruby/gems/1.8/gems/loaded_plugins-0.0.4/lib/loaded_plugins.r b:57:in
> `load_plugin'
>         from /usr/local/lib/ruby/gems/1.8/gems/rails-1.2.2/lib/initializer.rb:185:in
> `load_plugins'
>         from /usr/local/lib/ruby/gems/1.8/gems/rails-1.2.2/lib/initializer.rb:185:in
> `load_plugins'
>         from /usr/local/lib/ruby/gems/1.8/gems/rails-1.2.2/lib/initializer.rb:105:in
> `process'
>         from /usr/local/lib/ruby/gems/1.8/gems/rails-
> 1.2.2/lib/initializer.rb:43:in
> `run'
>         from
> ./vendor/plugins/appable_plugins/test/unit/../rails_root/config/environment .rb:8
>         from ./vendor/plugins/appable_plugins/test/unit/../test_helper.rb:3
>         from
> vendor/plugins/appable_plugins/test/unit/appable_plugins_test.rb:1

> We think this is because the embedded rails root requires
> plugin_dependencies (which we have installed as a gem), but this does not
> invoke the init.rb associated with this plugin, which does the actual work
> of mixing in your code with Initializer. How do you guys get this to run?

> 1. Issues model evaluation order

> As we understand it, model classes introduced by appable plugins should be
> evaluated in the order the plugins were loaded. In our sample app, we two
> plugins with a "user.rb " model in their app/models directory and a "user.rb"
> model in our application's model directory.

> The "dumb_user" plugin comes alphabetically first, so its init.rb is first
> to be evaluated. At the top of this init.rb is "require_plugin smart_user".
> This does indeed cause "smart_user" to be loaded before proceeding with
> loading

> According to our understanding of how appable plugins are supposed to work,
> upon a lazy load of user.rb, the file from "smart_user" should be evaluated,
> the file from "dumb_user" should then be evaluated, and then the file from
> our application.

> The order we see instead is "dumb_user", "smart_user", and then the
> application.

> 2. When user.rb is not in the application, the last plugin in the chain
> (which is in the wrong order) is not loaded.

> When user.rb is not in the application's models directory, instead of the
> broken but still workable loading behavior described above, we get something
> else. Now "dumb_user" is evaluated twice and "smart_user" is not evaluated
> at all.

> We know why this happens: Here's the code. Our comment is in all caps above
> the source of the bug. Can you tell us the intention of this if statement?

> def load_from_appable_paths(file_path, method)
>   use_strict_file_names = use_strict_file_names?(method)
>   use_file_path_for_last_load = use_file_path_for_last_load?(method)

>   full_file_path = (use_strict_file_names || file_path.ends_with?('.rb')) ?
> file_path : "#{file_path}.rb"
>   file_name = File.basename(full_file_path)

>   processed = false
>   if load_paths = get_appable_paths_for(full_file_path)
>     load_paths.each_with_index do |load_path, index|
>       # Check if we're using the original file_name on load

>       ### HERE IT IS. IF YOU COMMENT OUT THIS IF STATEMENT AND JUST USE THE
> ELSE BRANCH, THE BUG DOES NOT OCCUR
>       if use_file_path_for_last_load && index == load_paths.size - 1
>         load_path = file_path
>       else
>         load_path = "#{load_path}/#{file_name}"
>       end

>       new_result = send("#{method}_without_appable_plugins", load_path)
>       processed = true
>     end
>   end

>   processed
> end

> 3. Not covered in our toy project investigation are some strange class
> reloading issues we're experiencing in production apps we're developing. It
> seems like controllers introduced by plugins are available on the first
> request but not on subsequent requests in development mode. But this is with
> version 0.0.1 of appable plugins on Rails 1.2.2, so our information is less
> solid on this problem.

> 4. Process issues.

> We really like your ideas regarding code reuse across projects, and we're
> going to move forward with it in our organization. We'd really like to use
> your plugins, but it would help us a lot if your subversion repository
> employed tags for releases. Is this something you'd be open to doing?

>  pet.zip
> 351KDownload

> On Feb 16, 5:35 pm, "Brian Takita" <brian.tak...@gmail.com> wrote:

> > ---------- Forwarded message ----------
> > From: Nathan Sobo <nathans...@pivotalsf.com>
> > Date: Feb 16, 2007 11:25 AM
> > Subject: We'd really like to use appable_plugins...
> > To: Parker Thompson <par...@pivotalsf.com>, pluginaweek-talk@googlegroups.com
> > , Ian McFarland <i...@pivotalsf.com>

> > Hey. Good work on plugins and code reuse across projects. I work for a Rails
> > development shop in San Francisco called Pivotal Labs, and I'd like to thank
> > you for sharing your thoughts on all of this. We've learned a lot from your
> > approach and are excited about appable plugins and their companions.

> > We're having some issues with appable plugins that we'd like to make you
> > aware of. We're considering moving forward with the spirit of your plugin
> > approach but with our own code, but we'd really like to work together on
> > this for our mutual benefit. We're attaching a toy project that exhibits
> > issues 0 through 2.

> > 0. We can't run your tests

> > We try to execute appable_plugins_test and fail with the following
> > exception:

> > /usr/local/lib/ruby/gems/1.8/gems/plugin_dependencies-1.2.0/lib/plugin_depe ndencies.rb:33:in
> > `plugin': undefined method `configuration' for nil:NilClass (NoMethodError)
> >         from /usr/local/lib/ruby/gems/1.8/gems/plugin_dependencies-1.2.0/lib/plugin_depe ndencies.rb:18:in
> > `require'
> >         from
> > ./vendor/plugins/appable_plugins/test/unit/../rails_root/config/../../../li b/appable_plugins.rb:309:in
> > `require'
> >         from /usr/local/lib/ruby/gems/1.8/gems/activesupport-1.4.1/lib/active_support/de pendencies.rb:342:in
> > `new_constants_in'
> >         from
> > ./vendor/plugins/appable_plugins/test/unit/../rails_root/config/../../../li b/appable_plugins.rb:308:in
> > `require'
> >         from
> > vendor/plugins/appable_plugins/test/unit/../rails_root/config/../vendor/plu gins/plugin_with_dependencies/init.rb:1:in
> > `load_plugin_without_appable_plugins'
> >         from /usr/local/lib/ruby/gems/1.8/gems/rails-
> > 1.2.2/lib/initializer.rb:401:in
> > `load_plugin_without_appable_plugins'
> >         from /usr/local/lib/ruby/gems/1.8/gems/activesupport-1.4.1/lib/active_support/co re_ext/kernel/reporting.rb:11:in
> > `silence_warnings'
> >         from /usr/local/lib/ruby/gems/1.8/gems/rails-1.2.2/lib/initializer.rb:401:in
> > `load_plugin_without_appable_plugins'
> >         from
> > ./vendor/plugins/appable_plugins/test/unit/../rails_root/config/../../../li b/appable_plugins.rb:39:in
> > `load_plugin_without_loaded_plugins'
> >         from /usr/local/lib/ruby/gems/1.8/gems/loaded_plugins-0.0.4/lib/loaded_plugins.r b:57:in
> > `load_plugin'
> >         from /usr/local/lib/ruby/gems/1.8/gems/rails-1.2.2/lib/initializer.rb:185:in
> > `load_plugins'
> >         from /usr/local/lib/ruby/gems/1.8/gems/rails-1.2.2/lib/initializer.rb:185:in
> > `load_plugins'
> >         from /usr/local/lib/ruby/gems/1.8/gems/rails-1.2.2/lib/initializer.rb:105:in
> > `process'
> >         from /usr/local/lib/ruby/gems/1.8/gems/rails-
> > 1.2.2/lib/initializer.rb:43:in
> > `run'
> >         from
> > ./vendor/plugins/appable_plugins/test/unit/../rails_root/config/environment .rb:8
> >         from ./vendor/plugins/appable_plugins/test/unit/../test_helper.rb:3
> >         from
> > vendor/plugins/appable_plugins/test/unit/appable_plugins_test.rb:1

> > We think this is because the embedded rails root requires
> > plugin_dependencies (which we have installed as a gem), but this does not
> > invoke the init.rb associated with this plugin, which does the actual work
> > of mixing in your code with Initializer. How do you guys get this to run?

> > 1. Issues model evaluation order

> > As we understand it, model classes introduced by appable plugins should be
> > evaluated in the order the plugins were loaded. In our sample app, we two
> > plugins with a "user.rb " model in their app/models directory and a "user.rb"
> > model in our application's model directory.

> > The "dumb_user" plugin comes alphabetically first, so its init.rb is first
> > to be evaluated. At the top of this init.rb is "require_plugin smart_user".
> > This does indeed cause "smart_user" to be loaded before proceeding with
> > loading

> > According to our understanding of how appable plugins are supposed to work,
> > upon a lazy load of user.rb, the file from "smart_user" should be evaluated,
> > the file from "dumb_user" should then be evaluated, and then the file from
> > our application.

> > The order we see instead is "dumb_user", "smart_user", and then the
> > application.

> > 2. When user.rb is not in the application, the last plugin in the chain
> > (which is in the wrong order) is not loaded.

> > When user.rb is not in the application's models directory, instead of the
> > broken but still workable loading behavior described above, we get something
> > else. Now "dumb_user" is evaluated twice and "smart_user" is not evaluated
> > at all.

> > We know why this happens: Here's the code. Our comment is in all caps above
> > the source of the bug. Can you tell us the intention of this if statement?

> > def load_from_appable_paths(file_path, method)
> >   use_strict_file_names = use_strict_file_names?(method)
> >   use_file_path_for_last_load = use_file_path_for_last_load?(method)

> >   full_file_path = (use_strict_file_names || file_path.ends_with?('.rb')) ?
> > file_path : "#{file_path}.rb"
> >   file_name = File.basename(full_file_path)

> >   processed = false
> >   if load_paths = get_appable_paths_for(full_file_path)
> >     load_paths.each_with_index do |load_path, index|
> >       # Check if we're using the original file_name on load

> >       ### HERE IT IS. IF YOU COMMENT OUT THIS IF STATEMENT AND JUST USE THE
> > ELSE BRANCH, THE BUG DOES NOT OCCUR
> >       if use_file_path_for_last_load && index == load_paths.size - 1
> >         load_path = file_path
> >       else
> >         load_path = "#{load_path}/#{file_name}"
> >       end

> >       new_result = send("#{method}_without_appable_plugins", load_path)
> >       processed = true
> >     end
> >   end

> >   processed
> > end

> > 3. Not covered in our toy project investigation are some strange class
> > reloading issues we're experiencing in production apps we're developing. It
> > seems like controllers introduced by plugins are available on the first
> > request but not on subsequent requests in development mode. But this is with
> > version 0.0.1 of appable plugins on Rails 1.2.2, so our information is less
> > solid on this problem.

> > 4. Process issues.

> > We really like your ideas regarding code reuse across projects, and we're
> > going to move forward with it in our organization. We'd really like to use
> > your plugins, but it would help us a lot if your subversion repository
> > employed tags for releases. Is this something you'd be open to doing?

> >  pet.zip
> > 351KDownload

> I've just committedhttp://dev.pluginaweek.org/changeset/440.  This should
> address most of the problems you were experiencing.  However, I don't have a
> test case for the class reloading issue yet to verify whether the changes I
> made fixed that problem.  I'm booked for the next week, so I unfortunately
> will not have much time to work on the plugins for the time being.  The
> 0.1.0 gem releases of the plugins will come out in about 10 days.  In the
> meantime, if you could verify whether this changeset fixed your issues, I'd
> appreciate it.  Thanks!

> -Aaron

> On 2/16/07, Brian Takita <brian.tak...@gmail.com> wrote:

> > ---------- Forwarded message ----------
> > From: Nathan Sobo < nathans...@pivotalsf.com>
> > Date: Feb 16, 2007 11:25 AM
> > Subject: We'd really like to use appable_plugins...
> > To: Parker Thompson <par...@pivotalsf.com >, pluginaweek-talk@googlegroups.com
> > , Ian McFarland <i...@pivotalsf.com>

> > Hey. Good work on plugins and code reuse across projects. I work for a
> > Rails development shop in San Francisco called Pivotal Labs, and I'd like to
> > thank you for sharing your thoughts on all of this. We've learned a lot from
> > your approach and are excited about appable plugins and their companions.

> > We're having some issues with appable plugins that we'd like to make you
> > aware of. We're considering moving forward with the spirit of your plugin
> > approach but with our own code, but we'd really like to work together on
> > this for our mutual benefit. We're attaching a toy project that exhibits
> > issues 0 through 2.

> > 0. We can't run your tests

> > We try to execute appable_plugins_test and fail with the following
> > exception:

> > /usr/local/lib/ruby/gems/1.8/gems/plugin_dependencies-1.2.0/lib/plugin_depe ndencies.rb:33:in
> > `plugin': undefined method `configuration' for nil:NilClass (NoMethodError)
> >         from /usr/local/lib/ruby/gems/1.8/gems/plugin_dependencies-1.2.0/lib/plugin_depe ndencies.rb:18:in
> > `require'
> >         from
> > ./vendor/plugins/appable_plugins/test/unit/../rails_root/config/../../../li b/appable_plugins.rb:309:in
> > `require'
> >         from /usr/local/lib/ruby/gems/1.8/gems/activesupport-1.4.1/lib/active_support/de pendencies.rb:342:in
> > `new_constants_in'
> >         from
> > ./vendor/plugins/appable_plugins/test/unit/../rails_root/config/../../../li b/appable_plugins.rb:308:in
> > `require'
> >         from
> > vendor/plugins/appable_plugins/test/unit/../rails_root/config/../vendor/plu gins/plugin_with_dependencies/init.rb:1:in
> > `load_plugin_without_appable_plugins'
> >         from /usr/local/lib/ruby/gems/1.8/gems/rails- 1.2.2/lib/initializer.rb:401:in
> > `load_plugin_without_appable_plugins'
> >         from /usr/local/lib/ruby/gems/1.8/gems/activesupport-1.4.1/lib/active_support/co re_ext/kernel/reporting.rb:11:in
> > `silence_warnings'
> >         from /usr/local/lib/ruby/gems/1.8/gems/rails-1.2.2/lib/initializer.rb:401:in
> > `load_plugin_without_appable_plugins'
> >         from
> > ./vendor/plugins/appable_plugins/test/unit/../rails_root/config/../../../li b/appable_plugins.rb:39:in
> > `load_plugin_without_loaded_plugins'
> >         from /usr/local/lib/ruby/gems/1.8/gems/loaded_plugins-0.0.4/lib/loaded_plugins.r b:57:in
> > `load_plugin'
> >         from /usr/local/lib/ruby/gems/1.8/gems/rails-1.2.2/lib/initializer.rb:185:in
> > `load_plugins'
> >         from /usr/local/lib/ruby/gems/1.8/gems/rails-1.2.2/lib/initializer.rb:185:in
> > `load_plugins'
> >         from /usr/local/lib/ruby/gems/1.8/gems/rails-1.2.2/lib/initializer.rb:105:in
> > `process'
> >         from /usr/local/lib/ruby/gems/1.8/gems/rails- 1.2.2/lib/initializer.rb:43:in
> > `run'
> >         from
> > ./vendor/plugins/appable_plugins/test/unit/../rails_root/config/environment .rb:8
> >         from
> > ./vendor/plugins/appable_plugins/test/unit/../test_helper.rb:3
> >         from
> > vendor/plugins/appable_plugins/test/unit/appable_plugins_test.rb:1

> > We think this is because the embedded rails root requires
> > plugin_dependencies (which we have installed as a gem), but this does not
> > invoke the init.rb associated with this plugin, which does the actual work
> > of mixing in your code with Initializer. How do you guys get this to run?

> > 1. Issues model evaluation order

> > As we understand it, model classes introduced by appable plugins should be
> > evaluated in the order the plugins were loaded. In our sample app, we two
> > plugins with a "user.rb " model in their app/models directory and a "
> > user.rb" model in our application's model directory.

> > The "dumb_user" plugin comes alphabetically first, so its init.rb is first
> > to be evaluated. At the top of this init.rb is "require_plugin
> > smart_user". This does indeed cause "smart_user" to be loaded before
> > proceeding with loading

> > According to our understanding of how appable plugins are supposed to
> > work, upon a lazy load of user.rb, the file from "smart_user" should be
> > evaluated, the file from "dumb_user" should then be evaluated, and then the
> > file from our application.

> > The order we see instead is "dumb_user", "smart_user", and then the
> > application.

> > 2. When user.rb is not in the application, the last plugin in the chain
> > (which is in the wrong order) is not loaded.

> > When user.rb is not in the application's models directory, instead of the
> > broken but still workable loading behavior described above, we get something
> > else. Now "dumb_user" is evaluated twice and "smart_user" is not evaluated
> > at all.

> > We know why this happens: Here's the code. Our comment is in all caps
> > above the source of the bug. Can you tell us the intention of this if
> > statement?

> > def load_from_appable_paths(file_path, method)
> >   use_strict_file_names = use_strict_file_names?(method)
> >   use_file_path_for_last_load = use_file_path_for_last_load?(method)

> >   full_file_path = (use_strict_file_names || file_path.ends_with?('.rb'))
> > ? file_path : "#{file_path}.rb"
> >   file_name = File.basename(full_file_path)

> >   processed = false
> >   if load_paths = get_appable_paths_for(full_file_path)
> >     load_paths.each_with_index do |load_path, index|
> >       # Check if we're using the original file_name on load

> >       ### HERE IT IS. IF YOU COMMENT OUT THIS IF STATEMENT AND JUST USE
> > THE ELSE BRANCH, THE BUG DOES NOT OCCUR
> >       if use_file_path_for_last_load && index == load_paths.size - 1
> >         load_path = file_path
> >       else
> >         load_path = "#{load_path}/#{file_name}"
> >       end

> >       new_result = send("#{method}_without_appable_plugins", load_path)
> >       processed = true
> >     end
> >   end

> >   processed
> > end

> > 3. Not covered in our toy project investigation are some strange class
> > reloading issues we're experiencing in production apps we're developing. It
> > seems like controllers introduced by plugins are available on the first
> > request but not on subsequent requests in development mode. But this is with
> > version 0.0.1 of appable plugins on Rails 1.2.2, so our information is
> > less solid on this problem.

> > 4. Process issues.

> > We really like your ideas regarding code reuse across projects, and we're
> > going to move forward with it in our organization. We'd really like to use
> > your plugins, but it would help us a lot if your subversion repository
> > employed tags for releases. Is this something you'd be open to doing?

> I'm wondering what the status of the class reloading fix is.  It's
> encouraging us to test more to avoid restarting mongrel, which is
> good :), but we'd love to get tis solved.

> Thanks!

> pt.

> On Feb 17, 8:23 pm, "Aaron Pfeifer" <aaron.pfei...@gmail.com> wrote:

> > Brian,

> > I've just committedhttp://dev.pluginaweek.org/changeset/440.  This should
> > address most of the problems you were experiencing.  However, I don't have a
> > test case for the class reloading issue yet to verify whether the changes I
> > made fixed that problem.  I'm booked for the next week, so I unfortunately
> > will not have much time to work on the plugins for the time being.  The
> > 0.1.0 gem releases of the plugins will come out in about 10 days.  In the
> > meantime, if you could verify whether this changeset fixed your issues, I'd
> > appreciate it.  Thanks!

> > -Aaron

> > On 2/16/07, Brian Takita <brian.tak...@gmail.com> wrote:

> > > ---------- Forwarded message ----------
> > > From: Nathan Sobo < nathans...@pivotalsf.com>
> > > Date: Feb 16, 2007 11:25 AM
> > > Subject: We'd really like to use appable_plugins...
> > > To: Parker Thompson <par...@pivotalsf.com >, pluginaweek-talk@googlegroups.com
> > > , Ian McFarland <i...@pivotalsf.com>

> > > Hey. Good work on plugins and code reuse across projects. I work for a
> > > Rails development shop in San Francisco called Pivotal Labs, and I'd like to
> > > thank you for sharing your thoughts on all of this. We've learned a lot from
> > > your approach and are excited about appable plugins and their companions.

> > > We're having some issues with appable plugins that we'd like to make you
> > > aware of. We're considering moving forward with the spirit of your plugin
> > > approach but with our own code, but we'd really like to work together on
> > > this for our mutual benefit. We're attaching a toy project that exhibits
> > > issues 0 through 2.

> > > 0. We can't run your tests

> > > We try to execute appable_plugins_test and fail with the following
> > > exception:

> > > /usr/local/lib/ruby/gems/1.8/gems/plugin_dependencies-1.2.0/lib/plugin_depe ndencies.rb:33:in
> > > `plugin': undefined method `configuration' for nil:NilClass (NoMethodError)
> > >         from /usr/local/lib/ruby/gems/1.8/gems/plugin_dependencies-1.2.0/lib/plugin_depe ndencies.rb:18:in
> > > `require'
> > >         from
> > > ./vendor/plugins/appable_plugins/test/unit/../rails_root/config/../../../li b/appable_plugins.rb:309:in
> > > `require'
> > >         from /usr/local/lib/ruby/gems/1.8/gems/activesupport-1.4.1/lib/active_support/de pendencies.rb:342:in
> > > `new_constants_in'
> > >         from
> > > ./vendor/plugins/appable_plugins/test/unit/../rails_root/config/../../../li b/appable_plugins.rb:308:in
> > > `require'
> > >         from
> > > vendor/plugins/appable_plugins/test/unit/../rails_root/config/../vendor/plu gins/plugin_with_dependencies/init.rb:1:in
> > > `load_plugin_without_appable_plugins'
> > >         from /usr/local/lib/ruby/gems/1.8/gems/rails- 1.2.2/lib/initializer.rb:401:in
> > > `load_plugin_without_appable_plugins'
> > >         from /usr/local/lib/ruby/gems/1.8/gems/activesupport-1.4.1/lib/active_support/co re_ext/kernel/reporting.rb:11:in
> > > `silence_warnings'
> > >         from /usr/local/lib/ruby/gems/1.8/gems/rails-1.2.2/lib/initializer.rb:401:in
> > > `load_plugin_without_appable_plugins'
> > >         from
> > > ./vendor/plugins/appable_plugins/test/unit/../rails_root/config/../../../li b/appable_plugins.rb:39:in
> > > `load_plugin_without_loaded_plugins'
> > >         from /usr/local/lib/ruby/gems/1.8/gems/loaded_plugins-0.0.4/lib/loaded_plugins.r b:57:in
> > > `load_plugin'
> > >         from /usr/local/lib/ruby/gems/1.8/gems/rails-1.2.2/lib/initializer.rb:185:in
> > > `load_plugins'
> > >         from /usr/local/lib/ruby/gems/1.8/gems/rails-1.2.2/lib/initializer.rb:185:in
> > > `load_plugins'
> > >         from /usr/local/lib/ruby/gems/1.8/gems/rails-1.2.2/lib/initializer.rb:105:in
> > > `process'
> > >         from /usr/local/lib/ruby/gems/1.8/gems/rails- 1.2.2/lib/initializer.rb:43:in
> > > `run'
> > >         from
> > > ./vendor/plugins/appable_plugins/test/unit/../rails_root/config/environment .rb:8
> > >         from
> > > ./vendor/plugins/appable_plugins/test/unit/../test_helper.rb:3
> > >         from
> > > vendor/plugins/appable_plugins/test/unit/appable_plugins_test.rb:1

> > > We think this is because the embedded rails root requires
> > > plugin_dependencies (which we have installed as a gem), but this does not
> > > invoke the init.rb associated with this plugin, which does the actual work
> > > of mixing in your code with Initializer. How do you guys get this to run?

> > > 1. Issues model evaluation order

> > > As we understand it, model classes introduced by appable plugins should be
> > > evaluated in the order the plugins were loaded. In our sample app, we two
> > > plugins with a "user.rb " model in their app/models directory and a "
> > > user.rb" model in our application's model directory.

> > > The "dumb_user" plugin comes alphabetically first, so its init.rb is first
> > > to be evaluated. At the top of this init.rb is "require_plugin
> > > smart_user". This does indeed cause "smart_user" to be loaded before
> > > proceeding with loading

> > > According to our understanding of how appable plugins are supposed to
> > > work, upon a lazy load of user.rb, the file from "smart_user" should be
> > > evaluated, the file from "dumb_user" should then be evaluated, and then the
> > > file from our application.

> > > The order we see instead is "dumb_user", "smart_user", and then the
> > > application.

> > > 2. When user.rb is not in the application, the last plugin in the chain
> > > (which is in the wrong order) is not loaded.

> > > When user.rb is not in the application's models directory, instead of the
> > > broken but still workable loading behavior described above, we get something
> > > else. Now "dumb_user" is evaluated twice and "smart_user" is not evaluated
> > > at all.

> > > We know why this happens: Here's the code. Our comment is in all caps
> > > above the source of the bug. Can you tell us the intention of this if
> > > statement?

> > > def load_from_appable_paths(file_path, method)
> > >   use_strict_file_names = use_strict_file_names?(method)
> > >   use_file_path_for_last_load = use_file_path_for_last_load?(method)

> > >   full_file_path = (use_strict_file_names || file_path.ends_with?('.rb'))
> > > ? file_path : "#{file_path}.rb"
> > >   file_name = File.basename(full_file_path)

> > >   processed = false
> > >   if load_paths = get_appable_paths_for(full_file_path)
> > >     load_paths.each_with_index do |load_path, index|
> > >       # Check if we're using the original file_name on load

> > >       ### HERE IT IS. IF YOU COMMENT OUT THIS IF STATEMENT AND JUST USE
> > > THE ELSE BRANCH, THE BUG DOES NOT OCCUR
> > >       if use_file_path_for_last_load && index == load_paths.size - 1
> > >         load_path = file_path
> > >       else
> > >         load_path = "#{load_path}/#{file_name}"
> > >       end

> > >       new_result = send("#{method}_without_appable_plugins", load_path)
> > >       processed = true
> > >     end
> > >   end

> > >   processed
> > > end

> > > 3. Not covered in our toy project investigation are some strange class
> > > reloading issues we're experiencing in production apps we're developing. It
> > > seems like controllers introduced by plugins are available on the first
> > > request but not on subsequent requests in development mode. But this is with
> > > version 0.0.1 of appable plugins on Rails 1.2.2, so our information is
> > > less solid on this problem.

> > > 4. Process issues.

> > > We really like your ideas regarding code reuse across projects, and we're
> > > going to move forward with it in our organization. We'd really like to use
> > > your plugins, but it would help us a lot if your subversion repository
> > > employed tags for releases. Is this something you'd be open to doing?

> pt,

> This was fixed in changest 486 (http://dev.pluginaweek.org/changeset/
> 486) on edge.  It was related to the fact that plugin paths were being
> added to Dependencies.load_once_paths when they shouldn't have been.
> Sorry for any problems it may have been causing.

> -Aaron

> On Mar 6, 2:03 pm, "park...@gmail.com" <park...@gmail.com> wrote:
> > Aaron,

> > I'm wondering what the status of the class reloading fix is.  It's
> > encouraging us to test more to avoid restarting mongrel, which is
> > good :), but we'd love to get tis solved.

> > Thanks!

> > pt.

> > On Feb 17, 8:23 pm, "Aaron Pfeifer" <aaron.pfei...@gmail.com> wrote:

> > > Brian,

> > > I've just committedhttp://dev.pluginaweek.org/changeset/440.  This should
> > > address most of the problems you were experiencing.  However, I don't have a
> > > test case for the class reloading issue yet to verify whether the changes I
> > > made fixed that problem.  I'm booked for the next week, so I unfortunately
> > > will not have much time to work on the plugins for the time being.  The
> > > 0.1.0 gem releases of the plugins will come out in about 10 days.  In the
> > > meantime, if you could verify whether this changeset fixed your issues, I'd
> > > appreciate it.  Thanks!

> > > -Aaron

> > > On 2/16/07, Brian Takita <brian.tak...@gmail.com> wrote:

> > > > ---------- Forwarded message ----------
> > > > From: Nathan Sobo < nathans...@pivotalsf.com>
> > > > Date: Feb 16, 2007 11:25 AM
> > > > Subject: We'd really like to use appable_plugins...
> > > > To: Parker Thompson <par...@pivotalsf.com >, pluginaweek-talk@googlegroups.com
> > > > , Ian McFarland <i...@pivotalsf.com>

> > > > Hey. Good work on plugins and code reuse across projects. I work for a
> > > > Rails development shop in San Francisco called Pivotal Labs, and I'd like to
> > > > thank you for sharing your thoughts on all of this. We've learned a lot from
> > > > your approach and are excited about appable plugins and their companions.

> > > > We're having some issues with appable plugins that we'd like to make you
> > > > aware of. We're considering moving forward with the spirit of your plugin
> > > > approach but with our own code, but we'd really like to work together on
> > > > this for our mutual benefit. We're attaching a toy project that exhibits
> > > > issues 0 through 2.

> > > > 0. We can't run your tests

> > > > We try to execute appable_plugins_test and fail with the following
> > > > exception:

> > > > /usr/local/lib/ruby/gems/1.8/gems/plugin_dependencies-1.2.0/lib/plugin_depe ndencies.rb:33:in
> > > > `plugin': undefined method `configuration' for nil:NilClass (NoMethodError)
> > > >         from /usr/local/lib/ruby/gems/1.8/gems/plugin_dependencies-1.2.0/lib/plugin_depe ndencies.rb:18:in
> > > > `require'
> > > >         from
> > > > ./vendor/plugins/appable_plugins/test/unit/../rails_root/config/../../../li b/appable_plugins.rb:309:in
> > > > `require'
> > > >         from /usr/local/lib/ruby/gems/1.8/gems/activesupport-1.4.1/lib/active_support/de pendencies.rb:342:in
> > > > `new_constants_in'
> > > >         from
> > > > ./vendor/plugins/appable_plugins/test/unit/../rails_root/config/../../../li b/appable_plugins.rb:308:in
> > > > `require'
> > > >         from
> > > > vendor/plugins/appable_plugins/test/unit/../rails_root/config/../vendor/plu gins/plugin_with_dependencies/init.rb:1:in
> > > > `load_plugin_without_appable_plugins'
> > > >         from /usr/local/lib/ruby/gems/1.8/gems/rails- 1.2.2/lib/initializer.rb:401:in
> > > > `load_plugin_without_appable_plugins'
> > > >         from /usr/local/lib/ruby/gems/1.8/gems/activesupport-1.4.1/lib/active_support/co re_ext/kernel/reporting.rb:11:in
> > > > `silence_warnings'
> > > >         from /usr/local/lib/ruby/gems/1.8/gems/rails-1.2.2/lib/initializer.rb:401:in
> > > > `load_plugin_without_appable_plugins'
> > > >         from
> > > > ./vendor/plugins/appable_plugins/test/unit/../rails_root/config/../../../li b/appable_plugins.rb:39:in
> > > > `load_plugin_without_loaded_plugins'
> > > >         from /usr/local/lib/ruby/gems/1.8/gems/loaded_plugins-0.0.4/lib/loaded_plugins.r b:57:in
> > > > `load_plugin'
> > > >         from /usr/local/lib/ruby/gems/1.8/gems/rails-1.2.2/lib/initializer.rb:185:in
> > > > `load_plugins'
> > > >         from /usr/local/lib/ruby/gems/1.8/gems/rails-1.2.2/lib/initializer.rb:185:in
> > > > `load_plugins'
> > > >         from /usr/local/lib/ruby/gems/1.8/gems/rails-1.2.2/lib/initializer.rb:105:in
> > > > `process'
> > > >         from /usr/local/lib/ruby/gems/1.8/gems/rails- 1.2.2/lib/initializer.rb:43:in
> > > > `run'
> > > >         from
> > > > ./vendor/plugins/appable_plugins/test/unit/../rails_root/config/environment .rb:8
> > > >         from
> > > > ./vendor/plugins/appable_plugins/test/unit/../test_helper.rb:3
> > > >         from
> > > > vendor/plugins/appable_plugins/test/unit/appable_plugins_test.rb:1

> > > > We think this is because the embedded rails root requires
> > > > plugin_dependencies (which we have installed as a gem), but this does not
> > > > invoke the init.rb associated with this plugin, which does the actual work
> > > > of mixing in your code with Initializer. How do you guys get this to run?

> > > > 1. Issues model evaluation order

> > > > As we understand it, model classes introduced by appable plugins should be
> > > > evaluated in the order the plugins were loaded. In our sample app, we two
> > > > plugins with a "user.rb " model in their app/models directory and a "
> > > > user.rb" model in our application's model directory.

> > > > The "dumb_user" plugin comes alphabetically first, so its init.rb is first
> > > > to be evaluated. At the top of this init.rb is "require_plugin
> > > > smart_user". This does indeed cause "smart_user" to be loaded before
> > > > proceeding with loading

> > > > According to our understanding of how appable plugins are supposed to
> > > > work, upon a lazy load of user.rb, the file from "smart_user" should be
> > > > evaluated, the file from "dumb_user" should then be evaluated, and then the
> > > > file from our application.

> > > > The order we see instead is "dumb_user", "smart_user", and then the
> > > > application.

> > > > 2. When user.rb is not in the application, the last plugin in the chain
> > > > (which is in the wrong order) is not loaded.

> > > > When user.rb is not in the application's models directory, instead of the
> > > > broken but still workable loading behavior described above, we get something
> > > > else. Now "dumb_user" is evaluated twice and "smart_user" is not evaluated
> > > > at all.

> > > > We know why this happens: Here's the code. Our comment is in all caps
> > > > above the source of the bug. Can you tell us the intention of this if
> > > > statement?

> > > > def load_from_appable_paths(file_path, method)
> > > >   use_strict_file_names = use_strict_file_names?(method)
> > > >   use_file_path_for_last_load = use_file_path_for_last_load?(method)

> > > >   full_file_path = (use_strict_file_names || file_path.ends_with?('.rb'))
> > > > ? file_path : "#{file_path}.rb"
> > > >   file_name = File.basename(full_file_path)

> > > >   processed = false
> > > >   if load_paths = get_appable_paths_for(full_file_path)
> > > >     load_paths.each_with_index do |load_path, index|
> > > >       # Check if we're using the original file_name on load

> > > >       ### HERE IT IS. IF YOU COMMENT OUT THIS IF STATEMENT AND JUST USE
> > > > THE ELSE BRANCH, THE BUG DOES NOT OCCUR
> > > >       if use_file_path_for_last_load && index == load_paths.size - 1
> > > >         load_path = file_path
> > > >       else
> > > >         load_path = "#{load_path}/#{file_name}"
> > > >       end

> > > >       new_result = send("#{method}_without_appable_plugins", load_path)
> > > >       processed = true
> > > >     end
> > > >   end

> > > >   processed
> > > > end

> > > > 3. Not covered in our toy project investigation are some strange class
> > > > reloading issues we're experiencing in production apps we're developing. It
> > > > seems like controllers introduced by plugins are available on the first
> > > > request but not on subsequent requests in development mode. But this is with
> > > > version 0.0.1 of appable plugins on Rails 1.2.2, so our information is
> > > > less solid on this problem.

> > > > 4. Process issues.

> > > > We really like your ideas regarding code reuse across projects, and we're
> > > > going to move forward with it in our organization. We'd really like to use
> > > > your plugins, but it would help us a lot if your subversion repository
> > > > employed tags for releases. Is this something you'd be open to doing?