search

killbill / killbill-plugin-framework-ruby

Framework to write Kill Bill plugins in Ruby
http://killbill.io
8 stars 11 forks source link

(more) rake task improvements #36

Closed kares closed 9 years ago

kares commented 9 years ago

commits should explain,

should now (at least) pack GEM_HOME into a similar layout as Bundler uses whenever there are gem declarations with :git paths in the Gemfile ... for "normal" gem cases expected to work as previously.

some more details: https://gist.github.com/kares/09520ab72ac8204d229a

TODO

kares commented 9 years ago

some more commits came in and packaging now works reliably but loading is still an issue : 

Caused by: java.lang.IllegalArgumentException: org.jruby.embed.EvalFailedException: (LoadError) Could not find 'killbill' (>= 0) among 32 total gem(s)
    at org.killbill.billing.osgi.bundles.jruby.JRubyPlugin.checkValidPlugin(JRubyPlugin.java:161) ~[na:na]
    at org.killbill.billing.osgi.bundles.jruby.JRubyPlugin.instantiatePlugin(JRubyPlugin.java:93) ~[na:na]
    at org.killbill.billing.osgi.bundles.jruby.JRubyActivator.doStartPlugin(JRubyActivator.java:180) ~[na:na]
    at org.killbill.billing.osgi.bundles.jruby.JRubyActivator.startPlugin(JRubyActivator.java:116) ~[na:na]
    at org.killbill.billing.osgi.bundles.jruby.JRubyActivator.access$1300(JRubyActivator.java:40) ~[na:na]
    at org.killbill.billing.osgi.bundles.jruby.JRubyActivator$2.doCall(JRubyActivator.java:103) ~[na:na]
    at org.killbill.billing.osgi.bundles.jruby.JRubyActivator.withContextClassLoader(JRubyActivator.java:227) ~[na:na]
    at org.killbill.billing.osgi.bundles.jruby.JRubyActivator.startWithContextClassLoader(JRubyActivator.java:75) ~[na:na]
    at org.killbill.billing.osgi.bundles.jruby.JRubyActivator.access$000(JRubyActivator.java:40) ~[na:na]
    at org.killbill.billing.osgi.bundles.jruby.JRubyActivator$1.isRegistered(JRubyActivator.java:63) ~[na:na]
    at org.killbill.killbill.osgi.libs.killbill.KillbillServiceListener.serviceChanged(KillbillServiceListener.java:66) ~[killbill-platform-osgi-bundles-lib-killbill-0.1.1.jar:na]
    at org.killbill.killbill.osgi.libs.killbill.KillbillServiceListener.listenForService(KillbillServiceListener.java:40) ~[killbill-platform-osgi-bundles-lib-killbill-0.1.1.jar:na]
    at org.killbill.billing.osgi.bundles.jruby.JRubyActivator.start(JRubyActivator.java:66) ~[na:na]
    at org.apache.felix.framework.util.SecureAction.startActivator(SecureAction.java:645) ~[org.apache.felix.framework-4.4.1.jar:na]
    at org.apache.felix.framework.Felix.activateBundle(Felix.java:2154) ~[org.apache.felix.framework-4.4.1.jar:na]
    ... 60 common frames omitted
Caused by: org.jruby.embed.EvalFailedException: (LoadError) Could not find 'killbill' (>= 0) among 32 total gem(s)
    at org.jruby.embed.internal.EmbedEvalUnitImpl.run(EmbedEvalUnitImpl.java:133) ~[na:na]
    at org.jruby.embed.ScriptingContainer.runUnit(ScriptingContainer.java:1317) ~[na:na]
    at org.jruby.embed.ScriptingContainer.runScriptlet(ScriptingContainer.java:1310) ~[na:na]
    at org.killbill.billing.osgi.bundles.jruby.JRubyPlugin.checkValidPlugin(JRubyPlugin.java:159) ~[na:na]
    ... 74 common frames omitted
Caused by: org.jruby.exceptions.RaiseException: (LoadError) Could not find 'killbill' (>= 0) among 32 total gem(s)
    at RUBY.to_specs(classpath:/META-INF/jruby.home/lib/ruby/shared/rubygems/dependency.rb:298) ~[na:na]
    at RUBY.to_spec(classpath:/META-INF/jruby.home/lib/ruby/shared/rubygems/dependency.rb:309) ~[na:na]
    at RUBY.gem(classpath:/META-INF/jruby.home/lib/ruby/shared/rubygems/core_ext/kernel_gem.rb:47) ~[na:na]
    at RUBY.(root)(<script>:4) ~[na:na]

... so there's work that will need to happen on that front as well (Warbler loads :git gems just fine and they should be packed ~ same way as presented in the PR)

pierre commented 9 years ago

It seems to work in my setup. I have an extra patch to make it work with Travis (https://github.com/killbill/killbill-plugin-framework-ruby/commit/987908a8f0dbba3fa6cdb4d2d03b5ed181926c99).

Regarding your issue, could it be related to the WARN in your logs?

KillBill [2015-04-16 20:11:03.223] WARN  : Unable to stage killbill from /opt/local/rvm/gems/jruby-1.7.19@kb/bundler/gems/killbill-plugin-framework-ruby-ce5e19f45bc9: Permission denied - /home/kares/workspace/oss/killbill/killbill-stripe-plugin/killbill-stripe/0.2.3/gems/bundler/gems/killbill-plugin-framework-ruby-ce5e19f45bc9/.git/objects/pack/pack-bfa0c3de40faae07e0f0c2ea09a62fbb26e9baf3.idx
kares commented 9 years ago

gist reflects state up until https://github.com/kares/killbill-plugin-framework-ruby/commit/df40ce7248baac79f (first green travis marker) ... WARN happened when trying to re-package (packaging only worked when cleaned up first - now that I think of it on bundle updates it will keep the old :git gem directory).

thus no it's not related with the added commits - packaging now works on re-packs (we delete the target gem dir first to make sure there are no left-overs). not sure what the issue is, since the :git gem packing is very similar to Warbler (where it works fine).

pierre commented 9 years ago

Another thought: the :git gems are staged under bundler/gems instead of gems, but the jruby.jar only knows about RubyGems. There might be some setup needed on that side too?

kares commented 9 years ago

yy something I was looking at ... we'll need to do a kind of Bundler.setup there to get the correct $LOAD_PATH filled for :git gems (as well) - my only concern is that it will change how gems outside the bundle get activated and requires of packed gems outside the locked bundle won't load - although it should not be an issue at all

on a related note, why is there a rescue for the plugin require line - is it possible for it to work without it?

pierre commented 9 years ago

on a related note, why is there a rescue for the plugin require line - is it possible for it to work without it?

This is a trick to support various naming conventions, similar to an active_foo gem (you can require activefoo or active_foo). In case of a loading failure, the extra require line is required (see here example).

For reference, here is the original commit which introduced it (granted, not the best commit comment...).

kares commented 9 years ago

there's more stuff ... that much is required to get this working fine with gem 'xxx' :git ... mostly due a gemspec declarion in the Gemfile :

so this actually forces us to do the packaging differently for the plugin code - it's no longer packed along side under gems ("did you built it?" fails won't happen) but is pretty much at this point copied in ...

to be precise it's not a simple copy but rather a one where plugin.gemspec is loaded and the .gem is built from it, than the generated .gemspec (contained in the .gem) is copied into the package (to avoid depending on git on the PATH as the gemspec uses git ls-files) along side with the built (temporary) gem being unpacked under the target plugin root directory.

to somehow simplify the JRubyPlugin's getRequireLine process of setting up with Bundler there's another "new" feature a boot.rb script is generated which if found is used to do the preliminary booting

currently, everything works backwards-compatibly but obviously this boot.rb mechanism could be extended to do most of the work present in JRubyPlugin (we can even go as far as pretty much not use killbill.properties at least some parts such as the require line)

also hacks such as *.rb globbing could be avoided as we allow for user-customized boot.rb scripts during staging which can than do whatever they like.

I simply did not want to go further too much (this is still more than I hoped for :) without feedback ...

while all should be backwards compatible for packing without Bundler I'm not sure if it actually ever worked with the current code, as it only packs the plugin gem (none of it's dependencies get packed).

pierre commented 9 years ago

Awesome stuff! I'm still doing some testing but I wanted to share my initial thoughts/remarks...

There is an issue when the gems are vendored as Bundler itself cannot be found. The following patch defaults to building the gem (which fixes it), although I'm not sure if it's the right thing to do?

FYI, I have also another (unrelated) fix to delete the packages each time. Running bundle exec rake killbill:package twice in a row will do the right thing (rebuild the plugin gem), however the packages themselves are not updated.

to be precise it's not a simple copy but rather a one where plugin.gemspec is loaded and the .gem is built from it, than the generated .gemspec (contained in the .gem) is copied into the package (to avoid depending on git on the PATH as the gemspec uses git ls-files) along side with the built (temporary) gem being unpacked under the target plugin root directory.

Aww, that makes the deployment directory quite messy (it has killbill-litle/1.10.0/NEWS, killbill-litle/1.10.0/release.sh, etc.) :crying_cat_face:

Could we at least push the structure down one level (under bundler, vendor or maybe plugin -- not sure what the right convention is)? There are top level important files and directories (tmp dir for a Passenger-like experience, config.ru, etc.), which could conflict.

Also, it looks like that behavior happens even when the Gemfile doesn't have a git: entry. Is there an easy way to default to the previous packaging in that case?

to somehow simplify the JRubyPlugin's getRequireLine process of setting up with Bundler there's another "new" feature a boot.rb script is generated which if found is used to do the preliminary booting

:+1: (I didn't have a chance to try it out yet due to :airplane: travel preparations :baggage_claim: but I'll give it a try as soon as I can)

currently, everything works backwards-compatibly but obviously this boot.rb mechanism could be extended to do most of the work present in JRubyPlugin (we can even go as far as pretty much not use killbill.properties at least some parts such as the require line)

Yup, I think require can go away (and maybe mainClass) but pluginType would still be required for Kill Bill to understand the type of plugin (we support various types, payment plugins being only one kind). We can keep support in JRubyPlugin for all three for backward compatibility for now, but happy to update the generator to get rid of them moving forward.

kares commented 9 years ago

thanks for the feedback @pierre ... some najs catches as always!

There is an issue when the gems are vendored as Bundler itself cannot be found. The following patch defaults to building the gem (which fixes it), although I'm not sure if it's the right thing to do?

about ~ to what I was hitting with (default) gems scattered under different directories that lead to #12 I wanted to hit that issue again but did not know how (so I added the raise) - the thing is under the PR I hacked the find_plugin_gem method assuming it's there to find plugin related gems while now I know that the intention was for it to only look for the plugin.gem itself ... will try to refactor/update that here.

Aww, that makes the deployment directory quite messy (it has killbill-litle/1.10.0/NEWS, killbill-litle/1.10.0/release.sh, etc.) :crying_cat_face:

well yes, but that is mostly due the .gem including "everything git commited"

Could we at least push the structure down one level (under bundler, vendor or maybe plugin -- not sure what the right convention is)? There are top level important files and directories (tmp dir for a Passenger-like experience, config.ru, etc.), which could conflict.

give it some more thought, I do like the layout resembling the plugin directory but I do not mind changing it if it's necessary at all ... one note though if you mean unpacking the whole plugin gem somewhere else than I would advise against having the structure (with the Gemfile) under gems (GEM_HOME) directory.

Also, it looks like that behavior happens even when the Gemfile doesn't have a git: entry. Is there an easy way to default to the previous packaging in that case?

we could but it would slightly complicate the packaging - we might end up with having to deal with to different boot.rbs being generated in the future and it would also work slightly differently for 2 users packaging the same code one with a :git gem and one with "normal" one. the improved isolation I think is desired to have - Bundler makes it pretty hard to load something outside the bundle (e.g. one forgets a $LOAD_PATH << to get some gem code in, it would work happily on his machine even when packaged using the current RG only setup).

Yup, I think require can go away (and maybe mainClass) but pluginType would still be required for Kill Bill to understand the type of plugin (we support various types, payment plugins being only one kind). We can keep support in JRubyPlugin for all three for backward compatibility for now, but happy to update the generator to get rid of them moving forward.

OK, will give it another spin than moving more into boot.rb ... we'll see where it goes & how it works/looks.

kares commented 9 years ago

did an alternative to https://github.com/killbill/killbill-plugin-framework-ruby/commit/0b31fdb51c0c02db3e1ad5a36a964ceadcd1c96d ... that splits my find_plugin_gem "hacks" from #12 : https://github.com/kares/killbill-plugin-framework-ruby/commit/5ba52b07bdf7a1a9ccf6f6bf00952647f891456d

... when trying bundle --path it worked but as I gem uninstall bundler (have been testing 1.9, good that you had a different version), thus resolving (1.7.9) from default-gems, the spec's paths ended up quite a mess and it no longer worked - the only option seems to: https://github.com/killbill/killbill-plugin-framework-ruby/commit/766e613c1c200b11a1655290ff5a542a0d324bdd (in general it's still a "hack" but there's nothing else I can think of with spec.base_dir being messed up and it's "good" that the "messy" gem-path resolution no longer happens with the plugin gem as in #12)

pierre commented 9 years ago

Ugh, I edited your comment instead of replying - sorry, I'll go back to my email notifications and try to fix it... (in my defense, just arrived in :de: => still :sleeping:)

well yes, but that is mostly due the .gem including "everything git commited"

Just for background, the reason we use this trick is to make sure we never package sensitive files in the gem (such as gateway certificates or passwords...).

After trying the latest commits, plugins don't package anymore. I now get:

Errno::ENOENT: No such file or directory - Gemfile.lock

when running plugin_gem.build(true) (when it's building the plugin gem, e.g. killbill-litle). I do have a non-standard Gemfile (export BUNDLE_GEMFILE=Gemfile.head), but even if I copy my Gemfile.head.lock to Gemfile.lock, it then complains about the Jarfile.lock:

Errno::ENOENT: No such file or directory - Jarfile.lock

I'm not sure what changed, I'll try to debug it more.

kares commented 9 years ago

Hey, NP - do not worry about it too much and get some sleep (or conference preparation) instead :) ... can look at the export BUNDLE_GEMFILE=Gemfile.head case for you later.

pierre commented 9 years ago

Hey, NP - do not worry about it too much and get some sleep (or conference preparation) instead :)

Thanks but I did fix it :-)

we could but it would slightly complicate the packaging - we might end up with having to deal with to different boot.rbs being generated in the future and it would also work slightly differently for 2 users packaging the same code one with a :git gem and one with "normal" one. the improved isolation I think is desired to have - Bundler makes it pretty hard to load something outside the bundle (e.g. one forgets a $LOAD_PATH << to get some gem code in, it would work happily on his machine even when packaged using the current RG only setup).

ack - let's not do it for simplicity.

give it some more thought, I do like the layout resembling the plugin directory but I do not mind changing it if it's necessary at all ... one note though if you mean unpacking the whole plugin gem somewhere else than I would advise against having the structure (with the Gemfile) under gems (GEM_HOME) directory.

Going back to this, :+1: for the layout being essentially the plugin tree with a gems subdirectory for dependencies (it's actually conceptually similar to running bundle install --path=gems), but I think we should push everything down one level to keep the first level for special files and configs.

So it would look like:

This would also let us change the layout more easily moving forward without changing the convention for special files (e.g. restarter file).

Note that the file /var/tmp/bundles/plugins/ruby/killbill-litle/1.10.0/killbill.properties served as a bootstrap protocol between Kill Bill and the plugin, but now it's being (hopefully completely) replaced by the boot.rb, the boot.rb could be kept at the top level (/var/tmp/bundles/plugins/ruby/killbill-litle/1.10.0/boot.rb) instead of being part of the plugin code.

Thoughts?

I'm not sure what changed, I'll try to debug it more.

I did some more investigation and here is the summary of my latest (nightly!) round of testing (Bundler version 1.8.3 and JRuby version 1.7.19).

With BUNDLE_GEMFILE=Gemfile:

With BUNDLE_GEMFILE=Gemfile.head and no Gemfile.lock, I get:

KillBill [2015-04-28 10:11:41.145] INFO  : Building killbill-litle gem from killbill-litle-plugin/killbill-litle.gemspec
rake aborted!
Errno::ENOENT: No such file or directory - Gemfile.lock
killbill-litle-plugin/vendor/bundle/jruby/1.9/bundler/gems/killbill-plugin-framework-ruby-442be0b80de8/lib/killbill/rake_task.rb:307:in `stage_dependencies'
killbill-litle-plugin/vendor/bundle/jruby/1.9/bundler/gems/killbill-plugin-framework-ruby-442be0b80de8/lib/killbill/rake_task.rb:295:in `stage_dependencies'
killbill-litle-plugin/vendor/bundle/jruby/1.9/bundler/gems/killbill-plugin-framework-ruby-442be0b80de8/lib/killbill/rake_task.rb:113:in `install'
kares commented 9 years ago

so I improved the .gem file created in the current dir ... it's best we do the gem build in a temporary place. did miss that the plugin .gem is actually being generated and kept completely, thanks!

regarding a custom BUNDLE_GEMFILE ... all seems well :

kares@sputnik:~/workspace/oss/killbill/killbill-stripe-plugin$ BUNDLE_GEMFILE=Gemfile.head rake killbill:package[true]
rake aborted!
Unable to find the Gemfile.lock at /home/kares/workspace/oss/killbill/killbill-stripe-plugin/Gemfile.head.lock for your plugin. Please run `bundle install' first
/home/kares/workspace/oss/killbill/killbill-plugin-framework-ruby/lib/killbill/rake_task.rb:257:in `find_gemfile'
/home/kares/workspace/oss/killbill/killbill-plugin-framework-ruby/lib/killbill/rake_task.rb:160:in `validate'
/home/kares/workspace/oss/killbill/killbill-plugin-framework-ruby/lib/killbill/rake_task.rb:87:in `install'
/opt/local/rvm/gems/jruby-1.7.19@kb/bin/jruby_executable_hooks:15:in `(root)'
Tasks: TOP => killbill:package => killbill:stage => killbill:validate
(See full trace by running task with --trace)

... improved the error message since it's not necessary a Gemfile.lock : 

kares@sputnik:~/workspace/oss/killbill/killbill-stripe-plugin$ BUNDLE_GEMFILE=Gemfile.head rake killbill:package[true]
rake aborted!
Missing bundle .lock file at /home/kares/workspace/oss/killbill/killbill-stripe-plugin/Gemfile.head.lock for your plugin. Please run `bundle install' first

than after BUNDLE_GEMFILE=Gemfile.head bundle install it rolls as : 

kares@sputnik:~/workspace/oss/killbill/killbill-stripe-plugin$ BUNDLE_GEMFILE=Gemfile.head rake killbill:package[true]
KillBill [2015-04-29 10:17:50.916] DEBUG : Parsing /home/kares/workspace/oss/killbill/killbill-stripe-plugin/Gemfile.head and /home/kares/workspace/oss/killbill/killbill-stripe-plugin/Gemfile.head.lock
mkdir -p /home/kares/workspace/oss/killbill/killbill-stripe-plugin/killbill-stripe/0.2.4.2/gems
KillBill [2015-04-29 10:17:50.967] DEBUG : Installing all gem dependencies to /home/kares/workspace/oss/killbill/killbill-stripe-plugin/killbill-stripe/0.2.4.2/gems
cp /home/kares/workspace/oss/killbill/killbill-stripe-plugin/Gemfile.head /home/kares/workspace/oss/killbill/killbill-stripe-plugin/killbill-stripe/0.2.4.2/Gemfile
cp /home/kares/workspace/oss/killbill/killbill-stripe-plugin/Gemfile.head.lock /home/kares/workspace/oss/killbill/killbill-stripe-plugin/killbill-stripe/0.2.4.2/Gemfile.lock
Resolving dependencies...
[...]

what is probably the issue is that with Gemfile.head you're using the killbill gem code from master (and thus not testing the actual code :) - I do have a small hack in place to always load my latest rake_tasks changes in Rakefile replaced require 'killbill/rake_task' with load File.expand_path('../killbill-plugin-framework-ruby/lib/killbill/rake_task.rb') ... or wherever is sits)

kares commented 9 years ago

gem :path

Bundler likely always looks at :path so it would only work locally - we can make it work with a warning.

in case of :git the commit it stored in Gemfile.lock and since it caches it under _GEMHOME/bundler in a directory who's name ends with the commit's hash it's portable. I will double check but I think we can not play a similar trick here unless were about to parse and adjust the Gemfile ... I'm not much into that unless it's really - really - really desired to have :)

layout

your proposition looks good.

/var/tmp/bundles/plugins/ruby/killbill-litle/1.10.0/some_clever_name

we seem to have run out of clever names as I look at the path :) but I think something will pop-up as it gets implemented - also it's probably something that the boot.rb can handle - chdir into whatever's there (thus it's a detail)

one minor feedback though I just realized ... what I (kind of) missed is to be able to run the plugin during development "as is" ... I think we're getting closer.

any reason killbill-litle directory during packaging to be generated at the plugin root level, would it be possible to move it to pkg or a temporary directory?

the boot.rb could be kept at the top level (/var/tmp/bundles/plugins/ruby/killbill-litle/1.10.0/boot.rb) instead of being part of the plugin code

yep, wasn't meaning to get a boot.rb into the gem (I'll actually go ahead and add it to .gitignore by default) ... it's mostly a development hack I've been using to tune the generated boot.rb while resolving Bundler bootstrap issues.

p.s. putting a small TODO list into the issue's description so that we do not forget anything and now what's left to decide/implement.

kares commented 9 years ago

... expect the generated require line to be fully compatible with existing plugins. ... related change at JRubyPlugin: https://github.com/kares/killbill-platform/commit/79b1668c77e8c351d9c36128db0f7487c550dcae

pierre commented 9 years ago

Bundler likely always looks at :path so it would only work locally - we can make it work with a warning.

:+1: We only use it locally for development.

one minor feedback though I just realized ... what I (kind of) missed is to be able to run the plugin during development "as is" ... I think we're getting closer.

Yup, it was something @sbrossie had asked for for a while too...

any reason killbill-litle directory during packaging to be generated at the plugin root level, would it be possible to move it to pkg or a temporary directory?

Yup, I think it would be cleaner (and would even simplify our template files!).

p.s. putting a small TODO list into the issue's description so that we do not forget anything and now what's left to decide/implement.

:+1:

... related change at JRubyPlugin: kares/killbill-platform@79b1668

I just merged it in my kares-performance branch and ran regression tests - all looks good!

Just FYI, I'm getting ready to release the Java stack as JRuby 1.7.20 is likely to be out today. I cherry-picked some of your recent and older[1] commits, and did a pass at the various repos you forked (killbill-commons, killbill-platform and killbill). I think I got it all, but let me know otherwise.

Once the Java stack is released (and we've found a clever name), I'll merge this and perform regression tests with most plugins.

[1] Unfortunately, logback is still a hard dependency in the main killbill build because the fix for LOGBACK-730 hasn't been released yet, but I'll keep it on my radar to make it easier to switch slf4j implementations moving forward.

kares commented 9 years ago

... changed the packaging layout (introduced another ROOT sub-directory) ... this needed further changes at the kb-platform side https://github.com/kares/killbill-platform/commit/ec378d51bdddcc94c020cc2cb530eae309a6e990

kares commented 9 years ago

I just merged it in my kares-performance branch and ran regression tests - all looks good!

... the new layout will require changes - see the above commit

Just FYI, I'm getting ready to release the Java stack as JRuby 1.7.20 is likely to be out today. I cherry-picked some of your recent and older[1] commits, and did a pass at the various repos you forked (killbill-commons, killbill-platform and killbill). I think I got it all, but let me know otherwise.

will re-check and try to finish up ... possibly pls give me time till tomorrow as I try to make sure more changes won't be necessary to code outside this repository.

Once the Java stack is released (and we've found a clever name), I'll merge this and perform regression tests with most plugins.

... clever name is ROOT for now - should boot as is (with the killbill-platform changes) looks smt like : 

chdir-ed: /var/tmp/bundles/plugins/ruby/killbill-stripe/0.2.4.2/ROOT
 GEM_HOME = "/var/tmp/bundles/plugins/ruby/killbill-stripe/0.2.4.2/ROOT/gems"
 BUNDLE_GEMFILE: "/var/tmp/bundles/plugins/ruby/killbill-stripe/0.2.4.2/ROOT/Gemfile"

[stripe-plugin] stripe payment plugin started
[stripe-plugin] Found Rack configuration file at /var/tmp/bundles/plugins/ruby/killbill-stripe/0.2.4.2/config.ru
kares commented 9 years ago

OK, so I did most that ended up on my TODO plate here ... notable changes :

for details see the commit messages - tried to keep them atomic and explain the changes in detail.

kares commented 9 years ago

pushed the last (but not least) development killbill:deploy ... should maybe waited and put those in a separate PR. thus feel free to ignore some of the last commits if it's easier, otherwise please test it :) ... not sure about naming things: killbill:deploy:dev, the fake plugin base (linked as /var/tmp/bundles/plugin/jruby/killbill-xxx ->) is tmp/deploy:dev, gems are not installed but the existing local RGs install is used.

pierre commented 9 years ago

Some testing notes with export BUNDLE_GEMFILE=Gemfile.head: the packaging process still complains about Gemfile.lock not existing (I didn't get the nicer message Missing bundle .lock file). If I copy manually Gemfile.head.lock to Gemfile.lock, packaging goes through but the plugin doesn't start:

2015-05-07 06:45:02,594 [Thread-20] INFO  o.k.b.k.0.3.0.SNAPSHOT - Starting JRuby plugin Killbill::Plugin::Api::PaymentPluginApi
Bundler::VersionConflict: Bundler could not find compatible versions for gem "killbill":
  In Gemfile:
    killbill-stripe (>= 0) java depends on
      killbill (>= 0) java
Could not find gem 'killbill (>= 0) java', which is required by gem 'killbill-stripe (>= 0) java', in any of the sources.
            start at /var/tmp/bundles/plugins/ruby/killbill-stripe/0.2.3/ROOT/gems/gems/bundler-1.9.6/lib/bundler/resolver.rb:203
          resolve at /var/tmp/bundles/plugins/ruby/killbill-stripe/0.2.3/ROOT/gems/gems/bundler-1.9.6/lib/bundler/resolver.rb:182
          resolve at /var/tmp/bundles/plugins/ruby/killbill-stripe/0.2.3/ROOT/gems/gems/bundler-1.9.6/lib/bundler/definition.rb:192
            specs at /var/tmp/bundles/plugins/ruby/killbill-stripe/0.2.3/ROOT/gems/gems/bundler-1.9.6/lib/bundler/definition.rb:132
        specs_for at /var/tmp/bundles/plugins/ruby/killbill-stripe/0.2.3/ROOT/gems/gems/bundler-1.9.6/lib/bundler/definition.rb:177
  requested_specs at /var/tmp/bundles/plugins/ruby/killbill-stripe/0.2.3/ROOT/gems/gems/bundler-1.9.6/lib/bundler/definition.rb:166
  requested_specs at /var/tmp/bundles/plugins/ruby/killbill-stripe/0.2.3/ROOT/gems/gems/bundler-1.9.6/lib/bundler/environment.rb:18
            setup at /var/tmp/bundles/plugins/ruby/killbill-stripe/0.2.3/ROOT/gems/gems/bundler-1.9.6/lib/bundler/runtime.rb:13
            setup at /var/tmp/bundles/plugins/ruby/killbill-stripe/0.2.3/ROOT/gems/gems/bundler-1.9.6/lib/bundler.rb:122
           (root) at /var/tmp/bundles/plugins/ruby/killbill-stripe/0.2.3/boot.rb:14
             load at org/jruby/RubyKernel.java:1091
           (root) at <script>:1

Unless I'm missing something in my setup (wrong code exercised), don't worry about it, I don't think we should spend more cycles right now on it (it would be a nice-to-have, but it's not a requirement for the upcoming release).