I'm learning REPL for Java 9 and how to utilize it effectively. Considering Java is heavy on the configuration and external dependencies this has made experiments for anything outside the trivial more work to configure than just waiting for a build/run. For instance, to evaluate something more than a trivial line of Java, based on just its runtime, one has to reference an external library as well as its own dependencies. This over-complicates things and perhaps make the point of such a feature moot for real-world scenarios.
Until IDE's integrate REPL and automatically manage/inject dependent libraries, how does one use the feature without the feature becoming more of a burden then the hurdle it was meant to overcome? Please note I'm not looking for conjecture, but methods in which one has worked to accomplish this.
I'm using the Kulla repo here to experiment.
As of October 2015 REPL (project Kulla) is still is not integrated, and Modular JDK, runtime images goes as second alternative download. Once they are all integrated in Dec 2015, there should start work and testing of them together.
As of October 2015 all tutorials suggest starting from building sources:
JDK 9 REPL: Getting Started (Tech Tip #87)
REPL_Tutorial.pdf
JShell and REPL in Java 9
Java9-New-HTTP-2-and-REPL
Related
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.
background
I have designed many tools in the past year or so that is designed to help me program for XPages. These tools include primarily helper java classes, extended logging (making use of OpenLogger and my own stuff), and a few other things that I personally feel I cannot work without. It has been discussed with my employer, and we feel that it might be a good idea to start publishing these items to openNTF. Since these tools are made up of about 3 .nsfs, all designed to use the same java code, key javascript classes, css, and even a custom control or two, I would like to consolidate key items into a plug-in that can be installed at the server and client level. I want to do this consolidation before I even think about publishing any of the work I've done so far. It would just be far too much work to maintain, not just for me, but for potential users. I have not really found any information on how to do such a thing in google searches. I also have to make sure that I am able to make use of the ExtLib libraries, openNTF Domino API, and the Notes API.
my questions
How does one best go about designing such plug-ins? Must a designer
use eclipse, or is this it possible to do this directly in the Notes
Designer?
How does a designer best go about keeping a server and client up to date while designing and updating the plug-in code? Is this why GitHub is often used?
Where is the best place to get material to get started in this direction? I sort of feel lost in the woods, knowing I need to head north, but not having a compass for that first step.
Thank you very much for your input.
In my experience, I found that diving into plug-in development is a huge PITA until you get used to it, but it's definitely worth it overall.
As for whether you can use Designer for plugin development: yes, but you will likely eventually want to not do so. I started out by using Designer for this sort of thing for a while, presumably with the same sentiment as you: why bother installing another instance of Eclipse when I'm already sitting in one all day? However, between Designer's age (it's roughly equivalent to, I think, Eclipse 3.4), oddities when it comes to working sets between the "Applications" and "Project Explorer" views, and, in my case, my desire to use a Mac app, I ended up switching.
There are two major starting points: the XSP Starter Kit (http://www.openntf.org/internal/home.nsf/project.xsp?name=XSP%20Starter%20Kit) and Niklas Heidloff's video on setting up Eclipse for XPages development (http://www.openntf.org/main.nsf/blog.xsp?permaLink=NHEF-8RVB5H). The latter mentions the XPages SDK (http://www.openntf.org/internal/home.nsf/project.xsp?name=XPages%20SDK%20for%20Eclipse%20RCP), which is also useful. In my setup, I found the video largely useful, but some aspects either difficult to find (IBM's downloads are shifting sands) or optional (debugging, which will depend on whether or not you're using Eclipse on Windows).
Those resources should generally get you set up. The main thing to worry about when setting up your Eclipse environment will be making sure your Plug-In Execution Environment is properly done. If you're following the SDK setup instructions, that SHOULD get you where you need to be.
The next thing to know about is the way plugins are structured. Each plugin you want to install in Designer or Domino will also be paired with a feature project (a feature can house several plugins), and potentially an update site - the last one is optional if you just want to import the features into an Update Site NSF. That's how I often do my normal plugin development: export the paired feature to a directory and then import the feature into the server's Update Site NSF and then install in Designer from there using Application -> Install. You can also set things up so that you deploy into the server's plugin/feature directories instead of taking the step of installing into an update site if you'd prefer. GitHub doesn't really come into play for this aspect - it's more about sharing/collaborating with your code and also having a remote storage location for your git repositories (which I highly advise).
And as for the "lost in the woods" feeling: yep, you'll have that for a good while. There are lots of moving parts and esoteric concepts to get a hold of all at once. If you mostly follow the above links and then start with some basics from the XSP Starter Kit (which is itself a plugin project that you can pair with a feature) - say, printing text in the Activator class and making an implicit global variable just to make sure it works - that should help get your feet wet.
It's best done in Eclipse. You can debug your code running on the server from there, as well as run it directly from there. The editors are also more up-to-date. You want:
Eclipse for RCP and RAP developers
XPages SDK for Eclipse RCP (from OpenNTF)
XPages Debug Plugin (from OpenNTF - basically allows you to load the plugins to the Domino server dynamically, rather than exporting to an Update Site all the time)
XSP Starter Kit on OpenNTF is a good starting point for a plugin. There are various references to the library id, which has to be unique for your plugin. Basically, references to org.openntf.xsp.starter need changing to whatever you want to call your plugin. You're also best advised to remove what you don't need. I tend to work in a copy of the Starter, remove stuff, build and if there are errors with required classes (Activator.java obviously will be required and some others), then paste them back in from the Starter.
XPages OpenLog Logger is a good cross-reference, that was built from XPages Starter Kit. It's pretty much stripped down and you'll be able to see what had to be changed. A lot of the elements of the XSP Starter Kit correspond to Java classes you'll probably be familiar with from your XPages Java development.
GitHub etc tend to be used as source control, which is useful for working out what's changed from time to time.
Our current system is in .Net world and we are in the process of moving to FeF world (Angular) and we might keep the back end either in .net or change it to some flavor of JVM. We do not know about the server side yet but for sure, we will keep it as .Net for some time till we sort out the technology issues.
One thing I want to do during this time to do is build a CI system with language agnostic build tools. We use NAnt/MSBuild today. I would like to know as of now what are all active build tools out there, which can work with any language? I did find the following, but not sure how many are all active today. I am not trying to find which is best or not, all I want to know is the tool set and I will evaluate them based on our project requirements. I want to make sure I did not miss some build tool because I do not know the Java world.
Current list
Make
Rake
Gradle
BuildR
I did find this question but it is 5 years old.
Thanks
Interestingly if you look at the visual studio files in a text editor you will see that they are indeed build scripts. They are actually msbuild.
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.
OK, so we all know the daily build is the heart beat of a project, but whats the single best way of automating it?
We have perl scripts wrapping our pipeline which includes ClearCase, VS2005 (C++), Intel FORTRAN, Inno setup. We use cron jobs on UNIX to schedule the build, and host a simple Apache web server to view and monitor the build. All in all its rather complex, I would like to know whats the best off the shelf solution that people use?
And yes I did say FORTRAN no escaping it sometimes, it works, no point doing a huge re-implementation project for some tried and tested FEA code that just works.
A new one to me that I've heard is quite slick is hudson - also with MSBuild support.
We're in the process of implementing CC.Net. So far it seems like it would fit your model pretty well.
Out of the box it offers automated building, results tracking and notification. I'm not sure how detailed the build-in-progress monitoring is though.
There are many tools that specifically handle this:
Cruise Control
Hudson
Continuum
The tools have out of the box support for the most common build types. They all also support some sort of "run this script" type build process.
In the end you should use the nicer build tools (MSBuild, Ant, Maven, Make, ...) where you can and fill the gaps for the odder tools with custom scripts. The automated build can just invoke these in the right order.
Here is the best resource we found to help us pick a Continuous Integration tool. We have been evaluating 5 or 6 tools on this page.
http://confluence.public.thoughtworks.org/display/CC/CI+Feature+Matrix
We use TeamCity - but then its a simple C#/Java development - maybe your pipeline can done via scripts it can drive?
I have had success using Visual Build Pro.
CC.NET is very powerful. Used it and was really happy about it. Even the status icon in the systray. It's a small detail, but it gives you a good overview of the project's "health". You immediately feel motivated to fix the tests when you see it red.
Now we use a self-baked series of scripts. Since we write Python, compilation is non-existant, so the only problem is running the tests.
If you're working with Visual Studio, be sure to check out Team Foundation Build to see if it will suit your situation.
It looks like Buck Hodges' blog post on the VS 2008 version is a good resource, too.
I know this is a really old question, but it's still coming up in searches, so someone should mention Jenkins - the open source continuation of Hudson.
From the Jenkins wiki:
Among those things, current Jenkins focuses on the following two jobs:
Building/testing software projects continuously, just like CruiseControl or DamageControl. In a nutshell, Jenkins provides an easy-to-use so-called continuous integration system, making it easier for developers to integrate changes to the project, and making it easier for users to obtain a fresh build. The automated, continuous build increases the productivity.
Monitoring executions of externally-run jobs, such as cron jobs and procmail jobs, even those that are run on a remote machine. For example, with cron, all you receive is regular e-mails that capture the output, and it is up to you to look at them diligently and notice when it broke. Jenkins keeps those outputs and makes it easy for you to notice when something is wrong.
It was originally built with Java in mind, so it integrates well with lots of other Java tools, but you can use it with any language, including all those mentioned by the OP.