Re: Project structure confusion
Charles Lowell
My intention was to have the option A. The jenkins-plugins gem has the plugin development tools as well as the runtime support libraries, and then the jenkins-ruby-plugins-playground is a place to test all of it out. We can split #1 out into two gems, but I don't see the need at the moment (note that the runtime doesn't actually load any of the devtools when the plugin initializes). If this is confusing, then perhaps we could split it out into two.
As for the playground, obviously, it is currently structured as a maven plugin right now. We can probably come up with a better playground that has the actual structure of a ruby plugin. Does anybody have some good suggestions for a real-world example?
cheers,
Charles
On Jul 1, 2011, at 7:08 PM, Kohsuke Kawaguchi wrote:
>
> I kicked the tire for some more time after the hack session today, and got some questions. (I'm also adding a few more people to the recipients who contacted me about this effort.)
>
>
> The way I see it, we need three projects:
>
> (1) A project that produces a ruby gem, which assists the development of a Jenkins plugin in Ruby (I'll call these Jenkins plugins "user projects".) AIU, this will have a command like "jenkins-plugin", define some Rake tasks that user projects require, and so on.
>
> (2) A project that produces a Jenkins plugin, tentatively called "ruby-support", probably built and packaged by Maven (at least for now, until #1 above becomes ready.) This project produces ruby-support.hpi that will contain JRuby runtime and all the other glue code that enables user projects. As such, this is a plugin all the user projects will require.
>
> (3) A playground project, which is a user project that we write as a proof of concept, to make sure #1 and #2 actually works.
>
>
> But we only have two (jenkins-plugins.rb and jenkins-ruby-plugins-playground), and each contains little bit of all three.
>
> For example, the playground project contains src/main/resources/test_root_action, which is a part of #3. But it also contains main/java/ruby, which is a part of #2.
>
> Then jenkins-plugins.rb contains some of #1, like bin/jenkins-plugin and cucumber tests, but it also contains a bit of #2, like lib/jenkins/model.
>
> Would it be worth splitting all three out? I'd be happy to take a stab at it. Or is the intention
>
> #1 + #2 = jenkins-plugins.rb
> #3 = jenkins-ruby-plugins-playground
>
> or
>
> #1 = jenkins-plugins.rb
> #2 + #3 = jenkins-ruby-plugins-playground
>
> ?
>
> --
> Kohsuke Kawaguchi | CloudBees, Inc. | http://cloudbees.com/
Kohsuke Kawaguchi
> Kohsuke,
>
> My intention was to have the option A. The jenkins-plugins gem has the
> plugin development tools as well as the runtime support libraries, and
> then the jenkins-ruby-plugins-playground is a place to test all of it
> out. We can split #1 out into two gems, but I don't see the need at the
> moment (note that the runtime doesn't actually load any of the devtools
> when the plugin initializes). If this is confusing, then perhaps we
> could split it out into two.
The part that I'm having a problem wrapping my head around is that #2
has to produce an hpi, not a gem. So in my mind, this needs to be a
Maven project, as it contains a bunch of Java source files.
If it's going to stay as one Git repository, I think at least it needs a
subdirectory that has files in the standard Maven layout (this actually
doesn't work well when we get to the point of running Maven release, as
Maven wants pom.xml to be at the top of the Git repository, but we can
split them up at that time, not now.)
Charles Lowell
think is a fine place to put it. However, I do think that we may want
to consider keeping the actual lib/ directory with the pure ruby bits
of runtime support as its own gem. That way, it can then be just
another gem which is bundled with the plugin.
The parts that would be in ruby-runtime-plugin would be the RubyPlugin
class, and RubyExtensionFinder, as well as all the interfaces needed
to dynamically query JRuby objects.
This does mean some duplication in the code that is brought into each
scripting container, but I think that it is not going to be of much
consequence, especially considering the number of external gems that
each plugin is likely to bring in (JSON, nokogiri, etc...) will dwarf
the jenkins glue layer.
However, I think that the main advantage is that the version of the
ruby glue layer can change without needing to update the ruby-runtime-
plugin. That way we can evolve the ruby API rapidly without breaking
existing plugins.
If people wanted to provide classes and ruby extensions, those could
be bundled as separate gems which could be included in the private
runtime.
cheers,
Charles
Kohsuke Kawaguchi
I see. So that's why those were in the jenkins-plugin.rb in the first
place. I think I understand it now.
That gem gets used both as a tool and as a bundled gem to the runtime
(and we can still split them into two down the road when the dead weight
of the tool in the runtime is considered too much.) I completely missed
that part.
Should I bring them back to where it was? In that case how do I recreate
bundled-gems.jar?
Charles Lowell
Going forward, I think that what was in bundle-gems.jar should just go at some well known path. Luckily bundler supports resolving all gems in a Gemfile and dependencies and putting them at a given path like resources/vendor/gems or something like that.
In fact, that's exactly what I did to generate bundled-gems.jar just did a bundle tmp/gems and then zipped that into a jar by hand.
cheers,
Charles
Kohsuke Kawaguchi
> bundled-gems.jar is actually legacy cruft, and was just a hack for me
> to just kinda shove all the dependencies into the jenkins plugin via a
> single file that I could copy into plugin's resources/ path. That I
> would have it at a well known location that would work as an .hpi as
> well as for .hpl
>
> Going forward, I think that what was in bundle-gems.jar should just go
> at some well known path. Luckily bundler supports resolving all gems
> in a Gemfile and dependencies and putting them at a given path like
> resources/vendor/gems or something like that.
"bundle install --path" apparently. right?
I guess we are to define a rake task that runs this so that we can
encapsulate the target path?
> In fact, that's exactly what I did to generate bundled-gems.jar just did a bundle tmp/gems and then zipped that into a jar by hand.
OK.