We are investigating possibility of using BeanShell to write scripts that do a lot of file operations.
Currently bash scripts are used.
Now the main question is - is BeanShell stable at this moment?
I know that it is not actively supported , but does that matter? Are there bugs?
What about BeanShell2? Is it original plus some bug-fixes? Or are there other changes?
I am also wondering if at this point in time using Groovy is better given that it is actively supported and developed by Pivotal.
Any additional information regarding pros and cons of either Bash scripts, BeanShell and Groovy scripts is greatly appreciated.
You really haven't given us much to go on here. No specifics about your environment, not much in the way of criteria. Nothing really about the problems that you are trying to solve with scripting. You are clearly thinking about moving away from bash for some reason, but you haven't really told us why.
If you are comfortable with bash, then I agree with #Nick Ellis. Stick with it.
However, if for some reason you are determined to choose either Groovy or Beanshell, the choice is pretty clear. Groovy is a well-supported language whose user base and application base are both growing by leaps and bounds. Beanshell... not so much.
I searched around to understand the current situation a few months ago and here are my findings.
Original release from http://www.beanshell.org hasn't been updated since 2.0b4
In maven repository, last release from benshell.org is 2.0b5 on Jun, 2005.
In 2011, beanshell2 was forked. Last release was v2.1.8 on Feb 20,2014. This fork is never released to maven repo.
In 2012, there was a discussion on apache commons-dev to adopt beanshell.
In 2013, it was reminded that it was not voted on incubator list.
Shortly after, it was proposed and voted on incubator-general.
But then, it was followed by a discussion that it should be put into sandbox.
In 2015, beanshell2 was cloned to github from google code.
Also on 2015-09-23, apache-extras repository was moved from google code to https://github.com/beanshell/beanshell/. (I missed the creation of original repository)
I would stick with bash. Even if one of these scripting languages is better in the sense that it has features you want, is easier to use, or has more support, you still need to switch from bash to this other language. Furthermore bash is drastically more common and well known, which means it is easier to find people who know it and find solutions on line. Without a very strong reason, such as a feature you need that bash doesn't provide, it seems like making the switch would be a lot of trouble without gaining much ground.
Adding to #hsib answer, There's a new 2.0b6 version:
2016-02-18 Security update
Note: A security vulnerability has been identified in BeanShell that could be exploited for remote code execution in applications that has BeanShell on its classpath (CVE-2016-2510). The vulnerability has been fixed in the security update BeanShell 2.0b6.
Related
I know that the 5.0 release note say "After the migration, source syntax-highlighting won't be available on a project until it has been successfully analyzed"
BUT, i can't imagine that there is no way to activate just by running another analysis. In fact, when you have thousands of components (it's our case), you can't plan 4500 analysis just to "restore" a basic but helpful functionality ! And it's more true when you know that the majority of theses components wasn't changed since a time ago... :(
So, please, say me that we can write a little batch or program that will do the job without need to pull all the sources ! I don't know how because i don't' understand this limitation of this upgrade (why sources aren't accessible)
You should trust the release notes. Information required for syntax highlighting is computed during analysis. Note that it also requires the language plugins to support this feature. I suggest to upgrade them to latest versions.
I was wondering if you know any tools that help keep track of "code smells". So that team members could report some finding in the code and then possibly vote on the most problematic ones (in terms of future project development).
Any experiences?
Have you looked at find bugs or check style? Both of these are pretty good for this.
I would also recommend pmd. These let you analyse common problems such as not setting method parameters final.
Lastly, I'd recommend using Sonar as this will highlight any code errors in order of priority. Such as code that is knowingly going to through a NPE, it will highlight this to you and can be integrated with Jenkins.
All these together can really help you move towards the "Clean Code" mantra.
I'm using both scrollTo and the "child"-plugin serialScroll quite frequently, and like them because they
Actually SCROLL things, rather than animating css-properties (margin/position etc)
Are flexible and can be used in many different situations, unlike lots of other scroller/sliders that adds a bunch of bells and whistles that you don't really need.
Thing is, the plugins haven't been updated since 2009, and although they still work just fine, regardless of jquery version, there are things that could need improving (like the ability to change settings after initilaisation), and overall it doesn't fell optimal to use a 3 year old plugin, solid and stable as it is.
Does anyone have a suggestion of other plugins that might do the same thing, perhaps better?
http://flesler.blogspot.se/2007/10/jqueryscrollto.html
This is an old question, but for the record, as Shauna said, the plugins aren't outdated, OP might have been looking at Google code hosting which is indeed out of date.
The plugin is now hosted on Github. There's no much of a need to update it too often given it's very stable already, but I do land some commits every now and then when needed.
I don't have a suggestion for anything better (even Google is coming up with Flesler's plugin or hand-written from base JavaScript or jQuery), but Flesler is still updating the plugin. You can find the latest version in GitHub.
What do you think about this build tool? I'm thinking of migrating from maven2 to raven (my poms are getting bigger and bigger), but I'd like to hear some opinions first.
Thanks!
#andre:
Thank's for writing but I was actually looking for real experiences using raven. Anyway, the fact that nobody wrote is an indicator by itself (it seems few people are using it)
I haven't used either Raven or Buildr, but I have heard good things about the latter. In this blog article by Assaf Arkin, there is a nice case study: a 5,443 line, 52 file Maven configuration was reduced to 485 lines of Buildr. And, even though everybody says "Ruby is slow", Buildr was 2-6x faster than Maven.
Also, unlike Raven, Buildr seems to still be maintained: it is currently in the incubator stage as an official Apache project.
pom growth is a problem that everybody faces w/ maven I guess, but maven is at least maintained (2.1. just around the corner) and the raven project looks pretty dead to me. No updates this year and the mailinglist archives are also very small. It looks to me as it's too risky to switch your build process to a tool w/o a living community. Not quite the answer you wanted I guess, but my 2 cents.
I don't know anything about raven.
You should check out plain old rake, which lets you create very powerful tasks.
I've also heard about sake, which is just like rake tasks but system-wide, instead of being only available inside one of your projects.
They may not be specialized for Java, but they sure beat the hell out of plain old bash or (heaven forbid) batch scripts.
I use cruisecontrol.rb for CI and FogBugz for bug tracking, but the more general the answers, the better.
First is the technical problem: is there an API for FogBugz? Are there good tutorials, or better yet, pre-written code?
Second is the procedural problem: what, exactly, should the CI put in the bug tracker when the build breaks? Perhaps:
Title: "#{last committer} broke the build!"
Body: "#{ error traces }"
I suppose this presupposes the answer to this question: should I even put CI breaks into my bug tracking?
At my company we've recently adopted the (commercial) Atlassian stack - including JIRA for issue tracking and Bamboo for builds. Much like the Microsoft world (I'm guessing - we're a Java shop), if you get all your products from a single vendor you get the bonus of tight integration.
For an example of how they've done interoperability, view their interoperability page.
Enough shilling. Generally speaking, I can summarize their general approach as:
Create issues in your bug tracker (ex: issue key of PROJ-123).
When you commit code, add "PROJ-123" to your commit comment to indicate what bug this code change fixes.
When your CI server checks out the code, scan the commit comments of the diffs. Record any strings matching the regex of your issue keys.
When the build completes, generate a report of what issue keys were found.
Specifically to your second problem:
Your CI doesn't doesn't have to put anything into your bug tracker. Bamboo doesn't put anything into JIRA. Instead, the Atlassian folks have provided a plugin to JIRA that will make a remote api call into Bamboo, asking the question "Bamboo, to what builds am I (a JIRA issue) related?". This is probably best explained with a screenshot.
All the CI setups I've worked with send an email (to a list), but if you did want—especially if your team uses FogBugz much as a todo system—you could just open a case in FogBugz 6. It has an API that lets you open cases. For that matter, you could just configure it to send the email to your FogBugz' email submission address, but the API might let you do more, like assign the case to the last committer.
Brian's answer suggests to me, if your CI finds a failure in a commit that had a case number, you might even just reopen the existing case. Like codifying a case field for every little thing, though, there's a point where the CI automation could be "too smart," get it wrong, and just be annoying. Opening a new case could be plenty.
And thanks: this makes me wonder if I should try integrating our Chimps setup with our FogBugz!
CC comes with a utility that warns you when builds fail, it probably isn't worth logging the failing build in FogBugz - you don't need to track issues that are immediately resolved (as most broken builds will be)
To go the other way round (FogBugz showing checkins that fixed the issue) you need a web based repository browser - FogBugz is easy to configure so that it shows the right changes.