I search for the best way to manage java dependancies in a jruby app/library.
Some time ago i read an article about getting java dependancies based on Maven through rubygems. I tried to follow up on this and found some information that this feature was dropped in JRuby 1.7. Also I found some projects like ruby_maven and jbundler but they look like work in progress.
Im especially interested in the integration with bundler and gemspec.
I am no fan of maven and prefer the ruby / bundler way.
Would be nice if a jruby pro could shed some light on the current state.
Me and my coworker are working on a tool to handle mixed Java/JRuby projects. We're hoping to be finished with it this week, so check it out next week and see if it meets your needs. (We still need to update the documentation a little bit, too.)
https://github.com/sam/doubleshot
You had mentioned that JBundler looks like a work in progress, but it does work. I'd recommend giving it a shot if you can't wait a week to try out our project.
Related
In my React Native apps, I've had bugs where the solution was to either upgrade Gradle or the Android Gradle Plugin. Is there a best practice on when to upgrade them? For example, should you keep an eye out for new versions of both of them and always keep them up-to-date? Or only when you upgrade react-native versions? Or something else?
Personally, I haven't had to upgrade Gradle often, but it's a good thing to try if you're app isn't building. Gradle is a build tool, if building isn't working, Gradle being out of date might be part of the problem.
I basically see two ideologies. 1. Always update, 2. Update when you have to. Always keeping your dependencies up to date can help with troubleshooting and keeping with best practices, but can also open you up to bugs and can take a lot of extra work. Updating when you have to is good for mission critical apps that require stability over new features. It also cuts down on development work.
Gradle also adds a potential breaking changes section to their update documentation.
At the company where I am working, there is a huge codebase currently running on Ruby 1.6.8 (2002), which I am tasked with updating to the latest possible version.
There already exists a documentation, which explains how to update the code to Ruby 1.9.3, but even then there is not much documentation which explains the changes which 2.x introduced.
This documentation is also not ideal for me, since it wasn't extensive enough. Is there a website where I can find the changelogs for every Ruby version?
Here https://www.ruby-lang.org/en/downloads/releases/ are the changelogs of each version.
is there any plugins available for analyzing Ruby code inn sonarqube. I have downloaded Ruby plugin for sonarqube which has just very few rules like six. is there any other plugins for analyzing Ruby in sonarqube.
Thanks.....
I've been looking for the same thing for a while now. It doesn't seem like there's any good support right now outside of ruby-sonar-plugin. SonarQube is a great tool and is awesome for managers to look into and it's a shame that the repo hasn't been updated for 2 years (at the time I'm writing this).
I know this isn't an answer, but it should provide more visibility on the question, at least.
I've been developing RoR applications since beginning of this year, and I've been using vim and it's plugins to develop all of my applications. AFAIK, RoR has been build to be used with a simple text editor.
However, I have a project that keeps growing, so sooner or later, I think that an IDE would become a necessary tool to continue building my projects.
I've been researching on the internet, and Netbeans is not a good solution, because of it's few developers, today there is no more support for rails, and the plugins are quite obsolete.
I've found also EasyEclipse, but this projects also is quite abandoned, and rails plugins have problems to work properly with different Eclipse versions.
What I've been thinking -since Eclipse is a highly customizable IDE- maybe I could install a generic ruby plugin (since a generic ruby plugin may be stable on time) and manually customize it myself in order to use it for ruby on rails application (establish my gems path, ruby path, etc).
I've found Ruby DLTK 5.0 Kepler plugin, and I think maybe it is a good start point. But since I'm pretty new to Eclipse, I don't know which other tools/plugins are necessary in order to achieve my goal (¿maybe a server plugin?), nor the important settings that I must tweak up.
Does anybody know if it's possible to configure Eclipse this way?
There is RubyMine, it is great but not free unfortulantly
In this question, I mentioned my assumption that rubyforge gems are more official, authoritative, and stable than github forks. One of the people replying to my question said that my assumption might not be accurate.
What have you observed? Do people use github to release early and release often, only putting stable releases on rubyforge, or do people release less often on rubyforge for other reasons (eg rubyforge being more of a hassle)?
Update: This question is a little moot now. Github gems are defunct, and rubyforge gems are going to be moved to rubygems.org.
No difference as far as I can tell.
There is a huge range in quality/stability of gems from both sources. Some are rock solid, others are pre-alpha quality.
It really depends on the gem project itself.
Having said that though, the github model does lend itself to more rapid turn around on issues. It's much easier to fork a project, fix a bug, and submit it back to be included in the original source. So at least on the popular projects, bugs get fixed quicker. So maybe that helps projects mature quicker, but I don't know.
What I noticed is a decreasing quality of GEM released via GitHub compared with the overall quality of GEMS at RubyForge.
IMHO there are at least two major explanation for this behavior:
--
Prior to GitHub the 99% of Rubyist was Subversion-dependent. You can say what you want about Subversion, but it is definitely more easy to use compared with Git and everybody is aware of the trunk/tags/branches layout. Then people started to move to Git. Just a super-limited slice of Subversion users started to use Git with the level of knowledge it should require and, what I noticed, is that people started to forgot about tags.
Once upon a time there were tags. In subversion people were used to release new version based on specific tags so that you can easily detect which version you installed and which was the stable branch.
Nowadays I see tons of libraries always under development in the Git master branch. No tags, no stable branches. In general, when libraries where released via RubyForge there was an higher level of attention to the deployment step.
--
GitHub makes the publishing step no more a hassle. That said, you can easily publish a new GEM simply pushing the gemspec into your repository.
In my opinion this simplicity might can lead to a lower quality. More less-skilled developed started to distribute GEMS because it's as easy as generating a new project with Jeweler (or a similar library) and pushing a git repository. They didn't know much more about release management, backward compatibility, release bumps, release maintenance.
Often I came across an unfinished libraries packaged as a GEM just because the developer forgot to remote the .gemspec file. Each commit caused a new GEM to be build with no apparent coherence and consistence.
I'm absolutely in favor of the "release often" practice but when it makes sense. Git provides an excellent branch support, you don't need to clutter the master branch with tons of unrelated commits and releasing unfinished piece of code that you call libraries.
--
Last but not least, what I probably hate the most is the unlimited duplication of the same GEM. When RubyForge was the unchallenged GEM source, it was quite easy to find and install a new project.
IMHO, GitHub introduced an unnecessary layer of complexity. First, you have GEM both available via rubyforge as mygem and via GitHub as username-mygem. You often need to spend time to figure out which GEM is the most updated and holds the master development.
Furthermore, some popular GEM was no longer updated on RubyForge and many people continues to use them just because RubyGems doesn't notify you about new versions. Easy to understand, if you installed coolgem release 1.2.4 and the same library is now available as superuser-coolgem (release 2.0), RubyGems is not clever enough to tell you a new update is available.
--
Now it's time for a disclaimer.
I'm not saying GitHub users produces crappy GEMS compared with RubyForge. I'm a GitHub user and prior I was a RubyForge user as well. Thousands of GEMS successfully migrated from RubyForge to GitHub without leaving the end-user in the "which one" limbo.
The best example Rails, but I can mention many other GEMs including (but not limited to) Capistrano, Hpricot, RedCloth... All those libraries are now hosted on GitHub and if you carefully look at them you can easily recognize the same level of quality as before.
Last but not least, all those libraries continue to be released via RubyForge as the master source so that you don't need to reconfigure your environment to detect whether to install rails-rails or rails.
Also, the end-user is not affected by development decisions. Take Capistrano for instance. A couple of months ago Jamis announced the end of its commitment to the development. The community took charge of the development and moved the master repository from jamis/capistrano to capistrano/capistrano. What would happen if the GEM was released as jamis-capistrano? All the users would have to switch to the new GEM and the new repository with lot of hassle.
This scenario never arised because RubyForge was and continue to be the main Capistrano delivery hub.
--
In conclusion, I unfortunately notices an overall decrease of GEM quality mainly caused by more people approaching Ruby and RubyGems without the necessary level of knowledge. The same apply to a large number of Rails plugins.
GitHub cannot be labelled as the culprit. When complex things become more easy and more people approach them without an underlying knowledge, it's normal that the quality can decrease because complexity is a natural selection process.
Anyway, there's still an excellent level of quality in the Ruby community. It's amazing to see how Ruby developers are committed to unit testing and other professional programming habits.
Probably less stable and slightly more up to date :)
-r
to answer your question finally: both of the resources you mentioned (rubyforge, github) are now obsolete, since gemcutter is the new and only place for rubygems.
Gemcutter Is The New Official Default RubyGem Host:
http://www.rubyinside.com/gemcutter-is-the-new-official-default-rubygem-host-2659.html