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
