I'm playing with this a bit today and having fun :) I will report more later, but a couple notes:
* It took a while to figure out what to put in settings.xml to get the plugins to work. Missing from the readme was the need to add a pluginGroup for de.saumya.mojo. Once I got that I was able to run the ruby:jruby plugin ok! * rails3:rails doesn't seem to work right now: http://gist.github.com/366114 * There doesn't appear to be a mojo for generating a Rails 2 app right now, correct? It's so cool to see this working! On Sat, Feb 6, 2010 at 8:45 AM, kristian <m.krist...@web.de> wrote: > hi Charles, > > the last days I spent my time implementing gemspec_to_pom converter > and now the gem artifact behaves almost like a normal artifact. with > an empty local maven repository things take a while. but after all the > needed (and lots of unneeded development) gems are downloaded it gives > a few hundred milliseconds overhead. > > your hint about "gem search" helped a lot - a real little door opener ;-) > > so I am already quite pleased though there is a lot of space for > performance improvements and work to remove an ugly workaround. > > but I was thinking a lot about how to get these jar-gems (the one > coming through a gem source back by a maven repository) back into the > classpath. within maven I can (more or less) easily switch from gem > back to jar when building the classpath (which is used to execute > jruby). there are several possibilities to deal with these "require > 'come_gem_jar'" within the ruby code: > > * redefine 'require' - hmm, too low level for my taste > * install an empty hull instead of the actual gem, the jar is already > in classpath and the gem does not need to require the jar > * delete the jar file after installing the gem into the per project > rubygems repository and make the ruby code which requires the jar just > warn about the missing jar and continue (i.e. assume the jar is > already in the classpath) > * or . . . ? > > with this I can keep all the jars within the java classpath at least > when using maven and when packing a war file similar things can be > done. > > this all would boil down to three types of gem artifacts: > > * gem: just ruby code when packing and as dependency it downloads as > rubygem - file-extension: .gem > * java-gem: ruby code with java extension when packing and as > dependency is downloads as rubygem - file-extension : -java.gem > * jar-gem: NOT for packing but downloads as jar and also installs an > empty gem (without the jar - to satisfy the "require") and puts the > jar into the classpath > > about the "central maven repository" from my gut feeling I would be > happy to see this part of jruby. the only thing which I like "to have" > is to release often, especially in the current state and these > releases I can use from some of my other projects. so there is no > hurry here. > > with regards > Kristian > > On Tue, Feb 2, 2010 at 7:22 PM, Charles Oliver Nutter > <head...@headius.com> wrote: >> Wow! More inline! >> >> On Mon, Feb 1, 2010 at 11:11 PM, kristian <m.krist...@web.de> wrote: >>> the current status is, that you can declare gem artifacts in your pom >>> and maven installs them for you into the local repository as well the >>> plugin installs the gem artifact in that gem repository. for the jruby >>> plugins (jruby-maven-plugin, gem-maven-plugin, rails-maven-plugin) you >>> can define (for the forked mode) GEM_HOME, GEM_PATH and setting this >>> to target/rubygems will give you a gem repository inside your project. >>> after a clean it has no duplicated gems and standard rubygems works >>> without the common "cant' activate . . . " errors. I feel it is a one >>> of the good features of bundler has. >> >> Wow! >> >>> the plugin can >>> * gem artifacts from a normal java projects and package them as gem >>> and install into the local maven repository >>> * gem artifacts from a normal ruby projects via a gemspec and package >>> them as gem and install into the local maven repository >> >> Wow! >> >>> there are two big things missing: >>> * take the complete dependencies tree of gem artifacts in account, >>> right now things work only with artifacts given in the pom directly >>> * create the pom.xml from gemspec of the gem when maven downloads a >>> copy of the gem into local repository - right now it is just a >>> pom-stub with groupId, artifactId and version in place. >> >> So is it necessary to generate the pom stub ahead of time? If so, I >> agree the way to go would be to have the maven plugin for installing >> gems automatically do all this. >> >>> a more minor things is the metadata.xml the list of versions available >>> for a given pom. you can extract the info from an html page of >>> gemcutter though some restful API would be nice. xml (does not need to >>> be the maven xml grammar) would be nicer then scrapping data of an >>> html page (which is meant for humans and not machines and the format >>> might change any time). >> >> Ideally the standard RubyGems feature would provide this, a la doing a >> "gem search" for a given name and getting the list of all versions. >> >>> if the gemspec to pom converter is ready the rest should fall in place >>> more or less. >> >> That would be the perfect reverse direction to the pom-to-gemspec code >> I and the Sonatype guys have written. The goal of full two-way >> maven/gem integration may be near! >> >>> one idea to create a gem artifact is to use maven command line inside >>> an normal ruby project: >>> mvn gem:install -Dgemspec=.... >>> which installs the gem artifact in the local repository. or put a >>> pom.xml inside that project and handle your ruby tasks with maven as >>> much possible. >> >> I doubt most Ruby folks would ever use this, but it certainly makes it >> fit into a Maven world *much* better. If the plugin was aware of >> gemcutter, etc, I assume this command line could also just install >> based on a name, right? >> >> mvn gem:install -Dname=rails >> >>> or start with a pom.xml for a ruby-only project or a jruby project >>> with includes a java library. >> >> Less interesting, but we definitely need to have a story for fully >> maven-based Ruby projects, including both gem and maven publishing >> (though most people would pick one or the other, I'm sure). >> >>> i.e. make it possible to have mixed java and ruby multi modules >>> projects - some are ruby only, some are java only and some are even >>> mixed java/ruby and you can manage everything through maven. >> >> Sounds like heaven for a maven user :) And with tweaks to get maven >> "out of the way", it could be heaven for normal Java folks as well. >> >>> even generating a gem out of java artifact is still something worth >>> having via a maven plugin I guess. I will look at one time to reuse >>> the code from the sonatype guys unless have such functionality for a >>> maven plugin already. but right now I am more focused on the maven >>> side of things and once I can manage everything from via a pom.xml for >>> rails projects I will be content. I thought I am close until I found >>> out the bundler and the gem-maven-plugin are doing similar things in >>> respect of ensuring that the dependency graph does load properly. >>> maybe it is not worth the effort, but what I like about maven is that >>> you can start the server or build the war file and no need of doing >>> something else to set up things - just download the sources and mvn >>> jetty:run-war starts the the rails application as a war file including >>> the download of the needed gems. >> >> I think this is *absolutely* worth it. Maven gets beat down a lot, but >> it does have some good aspects. Among these are single-sourced library >> management, dependency tracking, and conventions-driven development. >> Surprisingly enough, these are three key traits Rubyists hold dear >> (gemcutter is the one true repository, RubyGems tracks dependencies >> for you, Rails and other libs enforce conventions). You are definitely >> on to something here, and I want to help. >> >>> a few people started using my plugins - whether for compiling ruby >>> code into java classes or calling ruby which produces some output for >>> further processing. so soon I will to think about what to do with the >>> plugin - the main thing here is the use of my personal repostiory: >>> * either ask maven to scrape my personal repository and include them >>> into the central repository >>> * asked mojo codehaus to include these plugins >>> * asked jruby to give these plugins a new home. >>> but I guess first I focus on my little self induced goals. >> >> All three sound great. We already publish some mojo for JRuby, so it >> certainly could get rolled into JRuby proper. I actually have an >> immediate need for your plugin for the Polyglot Maven project; I want >> to use some Ruby libraries to reduce the amount of code I write, and >> while working on it I immediately hit the wall of "how/where should I >> install these gems?" Your plugin obviously solves that problem without >> firing a shot. >> >> I'm very excited about your work :) We must continue with it...it fits >> perfectly into the "JRuby 2010" goal of seamless two-way integration >> and unification of "The Ruby Way" and "The Java Way". >> >> - Charlie >> >> --------------------------------------------------------------------- >> To unsubscribe from this list, please visit: >> >> http://xircles.codehaus.org/manage_email >> >> >> > > > > -- > Kristian Meier + Saumya Sharma + Sanuka Meier > Vadakkethu House, > Edayanmula West PO - 689532, > Pathanamthitta District, Kerala, INDIA > > tel: +91 468 2319577 > > protect your privacy while searching the net: www.ixquick.com > > _=_ > q(-_-)p > '_) (_` > /__/ \ > _(<_ / )_ > (__\_\_|_/__) > > --------------------------------------------------------------------- > To unsubscribe from this list, please visit: > > http://xircles.codehaus.org/manage_email > > > --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
