buildr-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Shane Witbeck <sh...@digitalsanctum.com>
Subject Re: procedure and tips for creating a Buildr plugin?
Date Mon, 17 Aug 2009 13:48:36 GMT
Awesome! Thanks for the guide.

I will get setup and let you know when I have my additions available.

-Shane


On Sun, Aug 16, 2009 at 6:08 PM, Daniel Spiewak <djspiewak@gmail.com> wrote:

> Actually, Apache mailing-lists seem to filter out attachments, so I never
> got the file you sent.  However, I can do you one better...
>
> *Presenting: Daniel Spiewak's Thirty Second Guide to Contributing to Buildr
> using Git!
> *
> (ok, only thirty seconds if you type *really* fast)
>
> Step one: create a GitHub account.
> Step two: clone the apache/buildr repository (
> http://github.com/apache/buildr) using the cleverly disguised button at
> the
> top.
> Step three: hit the little "paste icon" next to the "Your Clone URL".
> Step four: install Git (use MsysGit on Windows).
> Step five: run the following command in the directory you wish to contain
> your buildr directory (paste the URL from earlier where indicated):
>
> $ git clone <url copied earlier>
> $ cd buildr
>
> Step six: add my repository as a remote by using the following command.
> Feel free to repeat this step for any other repositories you wish to pull
> from:
>
> $ git remote add daniel git://github.com/djspiewak/buildr.git
>
> Step seven: fetch the changes from my repository:
>
> $ git fetch daniel
>
> Step eight: create a new branch based on my `gae` branch and select it as
> the current working branch:
>
> $ git branch gae daniel/gae
> $ git checkout gae
>
> Step nine: hack, hack, hack, hack (you may find this cheatsheet helpful:
> http://ktown.kde.org/~zrusin/git/git-cheat-sheet-medium.png<http://ktown.kde.org/%7Ezrusin/git/git-cheat-sheet-medium.png>
> )
> Step ten: push your gae branch (including all of your commits) up to your
> clone of the Buildr repository:
>
> $ git push origin gae
>
> (note: once you have run the above command, future changes can be pushed
> simply by running `git push`)
>
> Step eleven: let me know that you've made some changes!  I'll pull your
> changes into my repository (merging with my local gae branch).
>
> Rinse and repeat from step seven, and eventually we'll get something put
> together that is ready to push into the main Buildr repository.  Once we're
> ready, I'll merge our gae branch in with the trunk and commit our changes
> using git-svn.  It's easy!  (actually, there's some legal releases which
> have to take place somewhere in there, but we can worry about those later)
>
> If you have any questions, feel free to ask here on the mailing-list.  We
> like to encourage contribution as much as possible, which is the main
> reason
> we have Git clones in the first place.  You are of course free to just send
> us patch files (the best way to do this is by attaching them to a JIRA
> issue), but Git is a lot easier once you get the hang of it.
>
> Daniel
>
> On Sun, Aug 16, 2009 at 1:51 PM, Shane Witbeck <shane@digitalsanctum.com
> >wrote:
>
> > Daniel,
> >
> > Thanks for the elaboration and pointer to the code you started. I added a
> > "enhance" task to what you had in gae.rb and attached it. I'm not lingual
> in
> > git yet so I wasn't sure how to add it there.
> >
> > Thanks again,
> >
> > -Shane
> >
> >
> >
> > On Sat, Aug 15, 2009 at 3:19 PM, Daniel Spiewak <djspiewak@gmail.com
> >wrote:
> >
> >> 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