tecsinapse/glimpse

Glimpse is a client/server tool that allows one to execute Groovy scripts inside a Spring Application

#Glimpse

Glimpse is a client/server tool that allows one to execute Groovy scripts inside a Spring Application.

Currently there is one client implementation as an Eclipse plugin. There could be potentially other implementations such as other IDE's plugins, command line based, browser based, and so on.

We also envision porting Glimpse to run in a CDI environment.

Use Cases

• Exploratory development: allows one to easily invoke code in an application, so they can have a taste of how the code works. That doesn't replace unit tests, but we know that in reality is not always easy to set the environment to execute code from a unit test. And some times you just want to experiment.
• Testing code unreachable from the user interface: things like scheduled tasks can be tested without the hassle of changing cron expressions just for the sake of testing.
• Loading/Extracting ad hoc data: need to get data from that unexpected file your customer sent you, no need to write code in the application, just write a Groovy script.
• Generate test data: by using a general purpose language (Groovy), one can write a script to generate random data to be used in tests.
• Your imagination: Glimpse lets you do basically anything you could do using a Groovy script.

Features

• Every Spring singleton bean becomes a script variable, so one can invoke methods on those beans.
• REPL mode: type an expression and get the result.
• Progress monitoring: in case of long running scripts, it integrates with the IDE progress bar.
• Overwritten println: println's in scripts run by Glimpse are redirected to Glimpse's output (there is an open issue to allow redirection of the entire application output to Glimpse).
• Extensibility: one can plug things like an authenticator for security purposes or a new source for script variables (this will be the way to allow Glimpse to be run on CDI, for example).

Why Groovy

Glimpse was created to be used in Java applications, and we find that Groovy is the easiest dynamic language for a Java developer to learn. They basically already know it as almost any Java code is Groovy code also. If you don't know anything about Groovy, we advise you to take a look at its website: http://groovy.codehaus.org/. Even if you just learn the most basic features of Groovy, it will help you to take the most out of Glimpse.

How to use

Please, refer to the [wiki] (https://github.com/tecsinapse/glimpse/wiki) for instructions on how to use Glimpse.

Ask Questions

Join the discussion group (https://groups.google.com/d/forum/tecsinapse-glimpse).

License

Copyright (C) 2012 Tecsinapse

Glimpse is released under version 2.0 of the [Apache License] (http://www.apache.org/licenses/LICENSE-2.0).

glimpse's Issues

Implement progress bar on CLI

Let Glimpse choose the port to be used, in case the indicated port is not available

Redirect System/out/err to Glimpse Console

Let the user decide whether to redirect or not.

Implement authorization for http

Try to get connection back to the server when the connection is reset

Sometimes it's just a temporary problem. Glimpse could try to connect again so the user would not even realize that.

Job run in parallel overwrites first job variables

That can create all sort of bugs, the main symptom being that the first job output is redirected to the second's

Implement CDI support

Allow Glimpse clients to retain a session so a repl can be built

Right now, one can only send an entire script to glimpse server that gets executed, but glimpse doesn't remember anything about that script. If Glimpse allows a client to start a session, than from the execution of a script to the other, Glimpse could remeber variables and functions defined in past executions. Throught that we could build a repl for Glimpse.

Let clients set parameters for a script

Right now, scripts need to hard-code parameter values or obtain them from a file/database in the server.

Make import work in the repl

Allow client/server define which enconding should be used

Rewrite communication protocol between client and server

The current protocol is quite handly made, making it very difficult to add new features. The idea is to use some kind of standard technology like json/xml in order to make the protocol more extensible.

The connector doesn't seem to detect that the port is already in use

Create name property to desambiguate multiple glimpses