Another oddity...most of the plugins can't be run without a pom.xml present? What can we do to change that? Many of them seem like you'd want them to work anywhere, like IRB...
On Wed, Apr 14, 2010 at 1:03 PM, Charles Oliver Nutter <head...@headius.com> wrote: > 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
