Yeah, that all sounds reasonable. I guess my biggest interest is having a way to take a JRuby distribution, Gem in a few libraries, and JAR that whole thing up for deployment. I would have a similar scenario for rolling my Rails stuff into a deployable JAR, and the whole thing would get stuff in a WAR file and tossed into the server. The important point is that as a typical UNIX installation, the front-loading of a JRuby distribution would mimic the front-loading of a Ruby install...the eventual JRuby JAR I'd ball up would look and act like the read-only Ruby install.
These deployment scenarios will have to get fleshed out better in the future as we support more of the major Ruby apps, but it's good to have this discussion. I think we're in agreement on how to move forward with jruby.home and friends for now. - Charlie On 1/25/06, Thomas E Enebo <[EMAIL PROTECTED]> wrote: > For people who embed using ant makes sense as a scenario for > repackaging. We don't even need an additional rule for this. > We can just add an additional project root subdir into the the > serialize/jar targets. For example, if 'extras' is the special > dir then they can put the new packages there and type 'ant'...jruby.jar > now contains those new packages without making CVS say you have > possible new modules to commit. > > OTOH, if you are deploying to a web-app (using ROR) you probably > could add some relative load path which grabs those files from WEB-INF/*. > Doing a web-app in java neccesitates having a build process to deploy. > JRuby will not provide that. I do not know enough about how RoR would > fit into a web container to know about possible scenarios. One would > be the live container scenario where you can copy new files in an > exploded web-app and the changes happen live without bouncing > tomcat/your-web-container-here. > > For people who don't embed then they will basically install the unzip'd > binary distro into a directory. Those people will not use ant. > When they install a package it should work identically to ruby > (except pre-packaged modules will be in jar and not lib). > > For people who use JRuby to embed in a web app and dynamically install > packages in a deployed dir via gems....Hardly a best practice? > ... > Scenario 1 is not really a concern...It is an embedded app they can > do an eval to load the libraries they need. jruby.home is not a > requirement (unless they plan on doing anything with what is in > rbconfig. > > Same with 2. If they want to have a bizarre config and set jruby.home > outside the container, then that is there rope to hang with. > > Scenario 3. yep makes sense > > Scenario 4. makes sense. Though again we should let them set > whatever dir they want (including any external). > > So it sounds like we should add the ability to specify a "classpath-only" > directory specifier so we can allow people to set up these embedded > environments better. ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnk&kid3432&bid#0486&dat1642 _______________________________________________ Jruby-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/jruby-devel
