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 Tue, 18 Aug 2009 02:59:14 GMT
I just looked at your GitHub home page (at http://github.com/digitalsanctum).
I can see in your feed that you created the Buildr project, but I can't
navigate to it.  Did you delete it?  I suspect that this may be a case where
GitHub got something stuck in its queue and is now refusing to allow anybody
access.  You may have to open a support issue with them (they usually get
back to you within a few days).

Daniel

On Mon, Aug 17, 2009 at 8:52 PM, Shane Witbeck <shane@digitalsanctum.com>wrote:

> Daniel,
>
> All seemed to work fine except when I get to Step nine:
>
> jackal:buildr shane$ git push origin gae
> Repository not found. If you've just created it, please try again in a few
> seconds.
> fatal: The remote end hung up unexpectedly
>
> I had to do some manual hacking of my ~/.gitconfig file to get this far.
> Here's what it looks like:
>
> [user]
>    name = Shane Witbeck
>    email = shane@digitalsanctum.com
> [github]
>    user = digitalsanctum
>    token = 4704be457cb04aba23816c6d364a265d
> [remote "origin"]
>    url = git@github.com:digitalsanctum/dotfiles.git
>
>
> Have any suggestions?
>
> Thanks,
> -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>
> <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