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


Reply via email to