buildr-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Spiewak <djspie...@gmail.com>
Subject Re: procedure and tips for creating a Buildr plugin?
Date Sat, 15 Aug 2009 19:19:11 GMT
Just to elaborate on this, we do accept submissions for inclusion in the
core Buildr addons, but they do have to go through a review process and such
before we determine whether or not there is enough interest to merit
inclusion.  A good, present-day example of this is the (still forthcoming)
checkstyle and pmd extensions, which have garnered considerable interest and
are currently in the review/legal-release stage.

As far as I'm concerned, GAE support would be very nice.  You may want to
take a look at some preliminary work I've done in that direction:
http://github.com/djspiewak/buildr (gae branch).  I'm less interested in
Flex, but I know there have been other community members in the past who
have commented on Buildr's lack of support and requested improvement (there
may even be an open issue in JIRA).

Daniel

On Sat, Aug 15, 2009 at 3:12 PM, Assaf Arkin <assaf@labnotes.org> wrote:

> 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