buildr-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Assaf Arkin <as...@labnotes.org>
Subject Re: procedure and tips for creating a Buildr plugin?
Date Sat, 15 Aug 2009 19:12:30 GMT
On Sat, Aug 15, 2009 at 11:54 AM, Shane Witbeck <shane@digitalsanctum.com>wrote:

> Daniel,
>
> Thanks a lot for the overview of extensions. I was actually more interested
> in addon's found in addon/buildr such as openjpa.rb. My apologies for not
> being more clear with my naming of plugins vs. addons vs. extensions. Maybe
> a better question to start would have been: When is it appropriate to
> create
> an addon vs. an extension?
>
> The topics I'm interested in creating an extension for is around Flex and
> Google App Engine for Java. GAE uses some bytecode enhancement similar to
> the OpenJPA addon that I'd like to be able to do from Buildr.
>
> I'm familiar with extensions but I was under the impression that something
> more robust in the works regarding a plugin framework. I think it was Assaf
> who mentioned it in a thread a while back.
>
> If extensions is meant to be the primary means of "extending" Buildr,
> should
> there be a less "ad-hoc" way of distributing them?


There's a very robust extension API.  We know it's robust because most of
Buildr is written in the form of extensions (compile, test, package, etc are
all extensions to a very small core).

There are several ways to distribute extensions:
- Put them in the same place (e.g. ~/.buildr) and require them from your
buildfile
- Put them in the project, typically under the tasks directory
- As Ruby gems and specify which gems are used in the settings file



At some point in the past I split the Buildr code base in two.  If it was a
core feature and well tested it went into core.  If it wasn't a core
feature, or simply untested, it went into addon.  The idea was to extract
some addons into separate plugins (e.g. OpenJPA is a good candidate) and
shame other addons into getting test coverage and entering core (e.g Jetty).

Assaf



>
>
> Thanks again,
>
> -Shane
>
>
> On Sat, Aug 15, 2009 at 1:06 PM, Daniel Spiewak <djspiewak@gmail.com>
> wrote:
>
> > Actually, this is pretty much all you need to know:
> > http://buildr.apache.org/extending.html#extensions  These docs were
> enough
> > to get me up and running, building my first extension not so long ago.
> > Buildr doesn't have formal plugins in the Maven sense; extensions require
> a
> > lot less ceremony.  All you need to do is create the extension according
> to
> > the documentation previously linked, place it in a .rb file and require
> > that
> > file from within your buildfile.  It's pretty much as simple as that.
> >
> > Distribution of extensions is usually pretty ad-hoc.  However, it is
> > possible to package up a Buildr extension as a Ruby Gem, which can then
> be
> > uploaded to the Rubyforge repository and made accessible to all Buildr
> > users
> > through the following mechanism:
> > http://buildr.apache.org/more_stuff.html#gems
> >
> > As for best practices, usually you will want to RDoc any major methods.
> > Testing is nice, but it can be a little difficult to setup a formal test
> > suite for a simple extension (Buildr's own test suite has some fairly
> > extensive infrastructure to ease this process).  All of my "for self"
> > extensions have been tested mainly by hand (yeah, I'm lazy).
> > Architecturally, you should follow the example set by the Java compiler
> > (lib/buildr/java/compiler.rb).  Buildr itself is just a set of extensions
> > (even "core" functionality), so examples abound if you're willing to look
> > at
> > the source code.
> >
> > Daniel
> >
> > On Sat, Aug 15, 2009 at 11:19 AM, Shane Witbeck <
> shane@digitalsanctum.com
> > >wrote:
> >
> > > I'm looking for docs (other than looking at existing plugins) to help
> me
> > > determine the steps for building a plugin. Does anything like this
> exist?
> > > Any tips in terms of what a complete plugin should have (ie. tests,
> etc.)
> > > before submitting it would be helpful as well.
> > >
> > > If formal docs on this topic don't already exist, I think this would be
> a
> > > big help to Buildr and it's users.
> > >
> > > Thanks,
> > >
> > > -Shane
> > >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message