I've been searching for a while, and I can't find any modern rails plugin management tools. I found several gem management tools (such as bundler and isolate), but no plugin management tools. The closest thing to that I found was piston, and that's not exactly what I was looking for was it was for plugin svn:externals management. Our plugins are not using svn:externals. Some can be used as gems, and managed by bundler, but not all plugins are offered by their developers in that form.
They can always be managed by hand, of course, but I'd rather have a tool to keep them current, etc., that works for plugins like isolate or bundler work for gems.
If others could use this I'll see if I can get supervisor approval to work on such and contribute it, assuming also there's not a good or even fair solution out there that I'm missing.
Cheers,
Craig
I use git submodules for that.
But, indeed in Rails 3, it is more natural to package each plugin as a gem, and i think it is the preferred way, especially for the reasons you mention.
Related
STS is over 350MB and most of it is corporate blubber ware that I do not need. For example its default installation includes bunch of Servers that shows up in project explorer and other things related to VMware cloud related products. All I need is Grails and Groovy and JavaScript related development and nothing else.
What is the procedure to remove all these things for clean and light installation of STS without destabilizing STS?
You can choose not to install tc server, Spring Roo and Apache Maven during the install. Also, you can go under Help -> About SpringSource Tool Suite, click Installation Details..., and uninstall plugins you don't want.
I know this question is already answered, but I just wanted to mention another way of installiong STS. You can do this through update sites. This way is slightly more complicated (only slightly), but does have the smallest footprint. You can see the instructions here:
http://blog.springsource.com/2011/03/25/early-access-springsource-tool-suite-for-eclipse-indigo-3-7/
I'm using Netbeans and JRuby to develop a Rails web application.
But for deployment, I will be using Heroku.
Since Heroku uses the Ruby-C implementation, I was wondering my use of JRuby can cause problems? Is this approach a safe thing to do?
You can develop in NetBeans and use C-Ruby (aka MRI Ruby). Just install Ruby separately, go to Ruby Platforms, and select it. I highly recommend you install a separate Ruby anyway, whether or not it is MRI Ruby, because if you use the built-in NetBeans version of JRuby (which is often not the latest) and then upgrade NetBeans, you'll lose all the gems you've installed. Installing Ruby/JRuby outside of NetBeans helps you to better manage the versions and gems.
Now to answer your questions: Likely you will not encounter problems with basic Rails applications. If you ever have the need to use non-native libraries you may run into issues. Some gems (e.g. Nokogiri) have a C version and a Java version so you'd be OK, but if you wanted to use a plugin that relied on RMagick, for example, you'd struggle, as you'd probably go a different route if you were developing and deploying with JRuby.
Bottom line: I wouldn't recommend it. I'd recommend using the same platform for both. But you can use MRI Ruby in NetBeans.
funny thing: I stumbled in your question while looking for a tool chain to do it the other way round (developing in MRI Ruby, deploying with JRuby). Of course you can not use any Java classes and internals, but this for sure is obvious to you. According to my results thus far you shouldn't encounter any process structural issues, because MRI Ruby adheres to the shared nothing principle whereas your requests in the development app share the VM at least. Maybe to be shure you should hae a look at http://kenai.com/projects/jruby/pages/DifferencesBetweenMriAndJruby and read it in a reverse sense, especially the "Native Endian is Big Endian" paragraph when un-/packing Strings or Arrays.
You will save yourself a lot of trouble if you develop on the same platform as you deploy. This goes for OS as well, especially Windows then deploying on Linux, less so with OSX, but still sometimes an issue. You will be troubleshooting on your deployment system and that just isn't the same as catching something as you code it in development. I recently started using JRuby for a project and there are quite a few differences and different gems altogether in some cases.
As for loosing installed gems etc. take a look at using Bundle while you are at it, that will also save you some trouble down the line with gem versions out of sync.
I've spent a fair bit of time with PHP & Python frameworks and recently thought I'd branch out to rails. The framework itself I like, but I seem to spend at least half my development time navigating through odd bugs and/or version incompatibilities between rails/ruby/rake/gems.
I'm happy to battle through it all if it gets less of a hassle, but even after a month it seems like I spend 90% of my time chasing down other people's bugs & only 10% of my time chasing down my own. The only guy I've talked to (who used it extensively until 2008) suggests "For the past 2 years, that's pretty much rails"
Any opinion on this? Does it get better, or is this just par for rails development at the moment?
Running it through Ubuntu 10.04, if it matters.
Rails is in transition right now between 2.3x and 3.0 so you are going to find it quite challenging as much of the most recent documentation and rails plugin readmes are being updated for rails 3. There are several tools that are indispensable right now for negotiating this stuff. First, Rails 3 uses bundler to manage dependencies, it is a much more civil way to manage gems.
gem install bundler
cd my_rails_project
bundle install
RVM (ruby version manager) is awesome and I would recommend installing it. Then you can build gemsets and dependency sets on a per project basis. and you don't need to superuser access to install.
also, if it were me, I'd just go ahead and start in rails 3
gem install rails --pre
if you want to stay with rails 2.3.x use the rake task for installing declared dependencies.
rake gems:install
if the project is a good project, it will be pretty specific about what it needs (declared in the config/environment.rb file), then if it doesn't run, checkout the stack traces to see where its failing.
In my experience this is not par for Rails development.
While using gems read the README file on github project repos and have a look at the issues and wikis....that should give you a fair idea of which gem is compatible with your Rails version. Regarding the framework, it is pretty stable....major bugs or patches or releases are reported on weblog.rubyonrails.org
Things grow incrementally with each release and that is obvious. There are some deprecations which are well documented in the Rails code and are reported when you run the code.
Rails itself is pretty bug free. I've not witnessed a bug in the framework itself now for a while unless I've been duplicating open tickets.
Where the problems you're seeing have crept in have been over a couple of different areas:
We've moved as a community from Ruby 1.8.x to 1.9
over the last year or so, and some
gems have specific Ruby version
requirements you need to check out
before using them. Most of the more
popular gems are fine and tested to
work in multiple environments. Read the docs first.
Rails itself has matured
significantly over the last few
years, and that has meant many
features have been deprecated. Lots
of plugins out there were written
for an older version of the
framework and expect behaviour that
just isn't valid any more. Read the docs first.
Several different Ruby interpreters
are now available (which is great),
but these sometimes can have an
impact when it comes to 3rd-party
code, but that's rare. Basically,
some gems and plugins expect to be
running on a specific interpreter.
None of the really popular ones are
like this, but you need to be aware
some gem builders are idiots. Read the docs first.
You might notice there is a common theme to the end of each point: read the docs first. :-)
I would say your experience is not at all typical of most Rails developer's workflows, although we've all had a day of struggling from time to time.
You will learn quickly which gems to trust, which ones you'll need but may struggle with from time to time (mysql - building that kills me on OS X, every time), and which ones you should avoid.
Overall though, the development cycle is more fluid (and you'll develop more rapidly) with Rails once you've got your bearings and are adopting good practice. There's a reason why we all like TDD and BDD though - if nothing else it helps us get through a gem update knowing stuff still works when a developer we don't know has done something moronic. :-)
Have been developing with Grails for couple of weeks now,
Though I've loved the experience and the possibilities, I've seen following problems starting up.
Please share if you've had similar issues.. and remedies would help too.
Transaction management (in-built) doesn't seem to work in some circumstances.
AOP with domain objects doesn't work
Grails IDE-plugins are pretty primitive
GWT-Integration (with the plugin)
Plugin installation (fails unusually) probably cause plugins are not matured enough.
Lack of extensive documentation (though what is available is pretty good)
Debugging support
If you actually want solutions for these problems you should post a separate question for each with a lot more information than you've provided here. For example, I can't possibly diagnose the cause of the problem when all I know is
Transaction management (in-built)
doesn't seem to work in some
circumstances.
Here is my opinion on these issues:
Transaction management (in-built) doesn't seem to work in some circumstances.
I haven't noticed any such problem
AOP with domain objects doesn't work
I guess what you mean here is that meta-programming domain objects doesn't work. I have encountered this and haven't found any solution. If you really meant AOP then I can't help you as I've never used it with Groovy.
Grails IDE-plugins are pretty primitive
The IntelliJ plugin is very, very good. The Netbeans plugin is OK. Last time I tried the Eclipse Groovy plugin it was awful. However, I believe that a new Eclipse Groovy plugin has recently been released as part of the Spring Tool Suite (STS). It's supposed to be big improvement on the previous Eclipse Groovy plugin, but I don't think it has much Grails support yet
GWT-Integration (with the plugin)
I don't use GWT, so have no comment
Plugin installation (fails unusually) probably cause plugins are not matured enough.
I've never had problems installing plugins, though if I update a plugin, I sometimes need to manually remove the old version from the .grails directory.
Lack of extensive documentation (though what is available is pretty good)
I think the level of documentation for Grails is way ahead of most OS projects. There is a wide range of Grails books available, there's an active mailing list, and the official document is 176 page long.
Debugging support
Again, it depends on the tools you're using. With IntelliJ, debugging a Grails app is as easy as debugging a Java app with Eclipse.
My own pet peeves about Grails development are:
Upgrading from one version to another is often a very painful process due to lack of backward compatibility. When I upgraded from 1.0.4 to 1.1.1 about 20% of my tests started failing
Application reloading is very hit and miss.
My feedback after few months with Grails:
Didn't happen to me.
I don't use AOP
Wrong. IntelliJ is very good and especially the last beta version. You can download it for a free trial. I know that Eclipse support is very limited and NetBeans becomes better but still behind IntelliJ
I can't say. I don't use it
Agree. My piece of advice here is to follow these following principles: 1.Use plugins as few as you can. Your application will be lighter and more maintainable. Also, you will upgrade Grails version more easily. 2.if you want to use a plugin, test it before with a dummy project. It takes few minutes for creating a grails application and you could test your next plugin rapidly. Be aware that sometimes plugins have compatibility issues between theselves so, do not hesitate to install all of the plugins you need into your dummy project
Agree. Grails is a very complex framework and documentation does not cover every aspect of Grails. But what is available is well explained. Also, grails community is very responsive, so if you don't find something you will easily have an answer in Grails forum or even on StackOverflow
Definitely Agree. Again, with IntelliJ you can debug easily but it is resource-consuming and takes time when reloading your app. So usually, I end up with logging traces and I debugg my full stack of exceptions like that! IMHO, this is one of the major shortcomings of Grails.
I recently started working on a small personal project in Ruby on Rails, and have run into a few things that I couldn't find definitive answers for. If anyone here is knowledgeable enough to help, that would be greatly appreciated. All of my questions are below:
What benefit is there to using the Rails Gem instead of having it in vendor/rails?
Is there any benefit to using Rails 2.3.2? Some of the plugins I hoped to use don't seem to be compatible with 2.3.2 (ActiveScaffold)? Does it offer a great improvement over 2.2?
What is the benefit of using Ruby 1.9? Many plugins aren't yet compatible. Does it offer a great improvement over older versions?
Thanks for any help you guys might be able to offer.
vendor/rails probably makes your project more portable. Deployments that run the rake gems:install can act kind of wonky, especially if you upgrade a "Framework Gem" (you have to do these manually).
The downside to vendor/rails is that it makes your deployment slightly bigger (more files that have to be pushed) but if you use git and something like Capistrano, this only bites you on the initial deploy... but its not that bad.
I don't think there are any huge benefits; it just depends on if you need features from 2.3.2. Obviously you want to try to run the latest version to make upgrades less painful. I've found that you always need to be upgrading the framework underneath Rails if you want to have any change of upgrading in the future.
Performance. As you pointed out though, a lot of plugins are broken. This is sort of a chicken-and-egg problem but overtime this should fix itself. We're not running 1.9 yet in any of our production apps because its too unstable with the rest of the stack.
I'll address the gem question.
I've used vendored gems in the past but I have pretty much moved away from it except in the rare case where I need to fork a gem to customize it for some purpose in which case I would vendor the gem.
The main reason not to vendor from my perspective is that you can't cleanly vendor any gems with C modules since they require compilation.
A really good option is to use a gem management tool such as geminstaller, it lets you configure the gems and specific versions of gems that your project works against so that you have a consistent set of gems on your deployment.
What benefit is there to using the
Rails Gem instead of having it in
vendor/rails?
The biggest benefit is that you do not carry around the full rails source code with your project, the other benefit is that moving to a newer version of rails is going to involve less effort.
Keep in mind that the gem command will allow you to install a specific version of a gem.
Is there any benefit to using Rails 2.3.2? Some of the plugins I
hoped to use don't seem to be
compatible with 2.3.2
(ActiveScaffold)? Does it offer a
great improvement over 2.2?
A lot has changed from rails 2.2 to 2.3.2, there are also a bunch of security, performance and bug fixes. ActiveScaffold is compatible with rails 2.3.2, as are most of the plugins out there. If you are starting a new project I would recommend using the latest and greatest.
What is the benefit of using Ruby 1.9? Many plugins aren't yet compatible. Does it offer a great
improvement over older versions?
Ruby 1.9 is much faster than Ruby 1.8.x, however adoption of 1.9 is not that high. Rails 2.3.2 works just fine on Ruby 1.9, however there are some plugins and gems that do not. Make sure you read this stackoverflow question on the topic.