hi Charlie, did you speak about the jbundler idea ? from Rondrigo's response I concluded this.
currently it does not depend on "changing" bundler, rubygems or jruby. there is NO technical dependency to the jruby-1.7 release. so any edge case can be dealt and fixed when it pops up. since there is some interest on the project. today someone help me to fix "finding the right maven" and he is trying it out on one or two production projects. once I get positive feedback it is time to push a "prerelease" gem. maybe Rodrigo finds some time to look at it too - at least the problems he reported are fixed now. GSoC - I have the feeling the remaining parts might be (if wanted) some command line tools which is pure ruby code without any direct connection to jruby. conceptually jbundler is nothing new and very similar what ruby-maven does - instead of using maven to resolve the gems version, jbundler uses **bundler** :) if I compare it to the maven-gem/gemify approach where I do know lots of dead ends which will never work then with jbundler there is none so far. for me it already works better then maven_gemify and I will be happy if I can dump that gemify code for good. I personally have a week to put specs into jbundler then I am offline until May. propagating jbundler instead of maven_gemify would help to mature things faster - and maven_gemify still is labeled "experimental" :) jbundler is just some clue code between bundler and aether(maven) and adding a lock file to the whole thing. enough said - I guess I am just amazed how little code was needed to get it running. regards, Kristian On Thu, Apr 5, 2012 at 9:05 PM, Charles Oliver Nutter <head...@headius.com> wrote: > Ok, time for a status update. GSoC proposals close tomorrow. > > Given the timeframe of May for a JRuby 1.7 preview release, does it > seem like we can have this work done or is this something that might > take more than a month? I emphasize this is a preview release; JRuby > 1.7 has had such a long cycle and major changes we're not going > straight into RC cycle like we did with 1.6. There will probably be a > good month of cooling down after the preview release (around May 22), > and then we'll look at an RC cycle starting in June. > > Where do we stand, what needs to be done, will we have time for / want > a GSoC project? > > - Charlie > > On Wed, Apr 4, 2012 at 1:32 PM, kristian <m.krist...@web.de> wrote: >> thanx anyways. your input so far was really great made the whole thing >> happen. and it feels like a clean solution. hope you find some time to >> see what is going on with your maven3/ruby-maven error since that part >> is copy and paste of the current maven_gemify.rb from jruby. >> >> thanx again. Kristian >> >> >> On Wed, Apr 4, 2012 at 11:41 PM, Rodrigo Rosenfeld Rosas >> <rr.ro...@gmail.com> wrote: >>> Hi Kristian, I tried once to give it a quick try, but it complained about >>> Maven3 not being installed. >>> >>> I have it installed and I even installed the ruby-maven gem but the error >>> persisted. >>> >>> I didn't have time for fixing it because I need to fix some issues with the >>> Grails application I maintain and just reported a(nother) bug in Grails: >>> >>> http://jira.grails.org/browse/GRAILS-8994 >>> >>> I'm in a hurry with some issues this week and that is why I'm not able to >>> invest much time on this Maven-Bundler integration until I can breathe a >>> bit. >>> >>> But good to know that this is advancing somehow. >>> >>> Best, >>> Rodrigo. >>> >>> Em 04-04-2012 13:39, kristian escreveu: >>> >>> Hi Rodrigo, >>> >>> I just rounded up the whole thing - hope it works for someone >>> different then me. there are no commandline tools, no groups in the >>> Mvnfile and version resolution is split between gems (done by bundler) >>> and jars (done by jbundler). >>> >>> the only thing which is missing from my side are specs and maybe but >>> some common code between jbundler, ruby-maven and jruby-maven-plugins >>> into a common gem. >>> >>> any feedback is welcome. >>> >>> regards, >>> Kristian >>> >>> >>> On Mon, Apr 2, 2012 at 6:31 AM, Rodrigo Rosenfeld Rosas >>> <rr.ro...@gmail.com> wrote: >>> >>> Hi Kristian, I'm just back home after a long weekend. I'll try to find some >>> time this week to take a look at this project. >>> >>> Thank you for your effort on this. >>> >>> Cheers, >>> Rodrigo. >>> >>> Em 01-04-2012 17:42, kristian escreveu: >>> >>> Hi Rodrigo, >>> >>> I just put a few ideas and pieces together in >>> https://github.com/mkristian/jbundler >>> >>> a Mvnfile.lock needs to step deeper into maven but once the embedding >>> of maven or using of aether is clear, the actual Mvnfile.lock is quite >>> easy to achieve. >>> >>> regards, >>> Kristian >>> >>> >>> On Fri, Mar 30, 2012 at 7:08 PM, Rodrigo Rosenfeld Rosas >>> <rr.ro...@gmail.com> wrote: >>> >>> I'd love to see this completed until 1.7 release date, about May. >>> >>> But honestly, this requires a lot of energy for discussing some approach >>> with the Bundler team that would work for all of us in a sustainable way. >>> >>> Personally, I think it would be better to separate the Maven integration >>> concerns from the Bundler repository itself. We should define an API so >>> that >>> we can keep working on the Maven integration as a separate gem that would >>> be >>> used by Bundler through an API (I'm thinking in some hook here). >>> >>> So, it is not just about implementing some solution that works, but about >>> discussing the proper way to achieve it so that the JRuby community can >>> make >>> progress on the Maven integration to Bundler in a fast pace instead of >>> depending on pull requests to be approved by the Bundler team which is >>> naturally more interested in Ruby related issues than on Java integration >>> ones. >>> >>> This can require a lot of time and having someone allocated by the GSoc >>> would help this getting traction. >>> >>> Personally, in the meanwhile I'm using this solution right now while >>> making >>> some experiments with a JRuby on Rails project. >>> >>> I've created some files in the root of my project: >>> >>> Mvnfile >>> --- >>> #org.apache.solr:solr-solrj:3.5.0 >>> org.apache.poi:poi:3.7 >>> --- >>> >>> pom.xml.template >>> --- >>> <project> >>> <modelVersion>4.0.0</modelVersion> >>> <groupId>ignore</groupId> >>> <artifactId>ignore</artifactId> >>> <version>1</version> >>> <dependencies> >>> <%= dependencies %> >>> </dependencies> >>> </project> >>> --- >>> >>> resolve-maven-dependencies.sh >>> --- >>> #!/bin/bash >>> source $HOME/.rvm/scripts/rvm >>> source .rvmrc >>> # optionally we can run bundle too from here >>> # bundle >>> rvm 1.9.3 >>> ruby generate-pom.rb >>> rm -rf lib/mvn >>> mvn -DoutputDirectory=lib/mvn/ dependency:copy-dependencies >>> --- >>> >>> .rvmrc >>> --- >>> rvm jruby@my_application --create >>> --- >>> >>> generate-pom.rb >>> --- >>> require 'erb' >>> >>> dependencies = '' >>> File.read('Mvnfile').each_line do |dep| >>> dep = dep.chomp.strip >>> next if dep.empty? || dep.start_with?('#') >>> group, artifactId, version = dep.split ':' >>> dependencies += " >>> <dependency> >>> <groupId>#{group}</groupId> >>> <artifactId>#{artifactId}</artifactId> >>> <version>#{version}</version> >>> </dependency> >>> " >>> end >>> >>> File.write 'pom.xml', >>> ERB.new(File.read('pom.xml.template')).result(binding) >>> --- >>> >>> config/initializers/0-add-maven-dependencies-to-classpath.rb >>> --- >>> if RUBY_PLATFORM == 'java' >>> require 'java' # not actually needed, but better to be explicit about it >>> Dir["#{Rails.root}/lib/mvn/*.jar"].each{|f| require f} >>> end >>> --- >>> >>> This is working for me and I don't have any problems with this setup. My >>> only concern is that someone deciding between JRuby on Rails and Grails >>> will >>> find their integration to Maven much simpler. >>> >>> Best, >>> Rodrigo. >>> >>> Em 30-03-2012 09:31, Charles Oliver Nutter escreveu: >>> >>> My primary concern is that we had really hoped to have the >>> maven/rubygems/bundler support *finalized* for JRuby 1.7, which will >>> preview in May for JRubyConf. The final release schedule isn't >>> decided, but it will certainly be long before the end of summer... >>> >>> Is that unreasonable? We're talking about preview in a bit over a >>> month and a half. >>> >>> We also want time for people to test the capability. Is this too big a >>> thing to "add" or "fix" in a 1.7.x release? >>> >>> I have no objection to this being a GSoC project in general...it's >>> just timeframes that concern me. >>> >>> - Charlie >>> >>> On Fri, Mar 30, 2012 at 5:35 AM, kristian<m.krist...@web.de> wrote: >>> >>> so I just put it briefly: >>> >>> there is a demand to get bundler with maven artifact integration. >>> >>> I am happy to help supervising such a project (with the help and input >>> of other on certain issue of course) >>> >>> so for me the question is how does could this materialize ? >>> >>> I could register myself as GSoC mentor and then what ? >>> >>> regards, >>> Kristian >>> >>> On Fri, Mar 30, 2012 at 1:46 AM, Charles Oliver Nutter >>> <head...@headius.com> wrote: >>> >>> Sorry I have been absent...out of town halfway around the world... >>> >>> I'm here to answer any questions about GSoC, for which student >>> proposals end NEXT WEEK... >>> >>> So fire away with any remaining questions and we'll try to get all >>> answered! >>> >>> - Charlie >>> >>> >>> --------------------------------------------------------------------- >>> 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 >>> >>> >>> >> >> --------------------------------------------------------------------- >> 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 > > --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
