I created a "buildr" repository tried running the above command then deleted the repository and tried again after it didn't work the first time. Do I need to create a repository if I'm cloning the existing official buildr repo? I'll go ahead and open a support issue.
Thanks, -Shane On Mon, Aug 17, 2009 at 10:59 PM, Daniel Spiewak <[email protected]>wrote: > 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 <[email protected] > >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 = [email protected] > > [github] > > user = digitalsanctum > > token = 4704be457cb04aba23816c6d364a265d > > [remote "origin"] > > url = [email protected]:digitalsanctum/dotfiles.git > > > > > > Have any suggestions? > > > > Thanks, > > -Shane > > > > > > On Sun, Aug 16, 2009 at 6:08 PM, Daniel Spiewak <[email protected]> > > 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> > > <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 < > [email protected] > > > >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 <[email protected] > > > >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 <[email protected]> > > > wrote: > > > >> > > > >> > On Sat, Aug 15, 2009 at 11:54 AM, Shane Witbeck < > > > >> [email protected] > > > >> > >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 < > > > [email protected]> > > > >> > > 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 < > > > >> > > [email protected] > > > >> > > > >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 > > > >> > > > > > > > >> > > > > > > >> > > > > > >> > > > > >> > > > > > > > > > > > > > >
