CloudBees is one of the best current Platform as a Service providers. And it is one of the few (maybe only one) who provides tools such as Jenkins as a service too. Its Dev@cloud also provides 2GB free Maven repository which could be a perfect solutions for a lot of home-brewed libraries in your company. This article will show you how to use this free repository in Gradle builds.
Uploading to the repository
There are a lot of reasons why you should want to upload your library to the repository. The most obvious one is managing the dependencies more easily. If you build your libraries with Gradle you can set up uploading to the CloudBees' Maven repository by adding a few more configuration to your build script.
Gradle to CloudBees
There is no magic about this configuration. You just have to use proper wagon library to support webdav protocol and use the right protocol in the URLs. If you write them manually you should check twice that you use "dav" not "webdav" as the protocol specification.
To upload your artifacts to the repository you just run gradle uploadArchives task.
Using the repository
Using the repository is little bit trickier because to make it work you must use the right server realm.
Using CloudBees repository in Gradle script
The only important part is setting the credentials. The resolver needs the same realm as the server which is "accountname repository".
Lift your IT into the Clouds - We are specialist in the field of Google Apps custom development (Google APIs, Google Apps Script, Google App Engine) and Google Apps implementation.
Wednesday, August 17, 2011
Tuesday, June 21, 2011
Groovy 1.8 DSL: Google Spreadsheet Query Language
The development in AppSatori is generally all about integrating applications with some Google API. One of your current project is about exporting Google Spreadsheet contents as XML. The XML part is easy thanks to Groovy MarkupBuilder. Fetching the data from Google Spreadsheet is much more cumbersome because standard API is a little bit verbose. So the decision was made to wrap the API with SQL-like declarative domain specific language (DSL).
Creating DSL in Groovy is very easy since 1.8 release where GEP 3 - Command Expression based DSL was introduced. No more commas as method accessors are needed if you alternate method calls with method parameters. Following code snippet shows the DSL in action the difference between Groovy 1.7 and 1.8 release.
GSQLExample
First thing you must think about when creating DSL is the grammar. Our desired Google Spreadsheet Query Language wraps Google's ListQuery class and could be defined by following grammar:
Order by column
As you could already mention from previous snippets the query is just ordinary POGO which collects the query parameters. In fact there are three of them to force the order of the commands. The only DSL magic is to add keyword(value) method to the query builder class. You should notice that these methods also constraints the expected value by type. The querying itself happens in the build method of the QueryBuilder class.
SelectBuilder
QueryBuilder
OrderBuilder
The GSQL is still work-in-progress. In future it might support also some data manipulation language for executing updated etc. There are also few things which must be done unless the business users could use the language safely. The most important one is to create secured shell which will prevent writing malicious code in the queries.
Creating DSL in Groovy is very easy since 1.8 release where GEP 3 - Command Expression based DSL was introduced. No more commas as method accessors are needed if you alternate method calls with method parameters. Following code snippet shows the DSL in action the difference between Groovy 1.7 and 1.8 release.
GSQLExample
First thing you must think about when creating DSL is the grammar. Our desired Google Spreadsheet Query Language wraps Google's ListQuery class and could be defined by following grammar:
The second step is to write tests for all supported use cases. Here is one example:select [all|'<column name>'*|<position>*] from 'spreadsheet' [ sheet 'worksheet'] [where 'spreadsheet query'] [contains 'fulltext'] [order by column [<position>|'<column name>]] [sort [asc|desc]] [limit <limit>] [offeset <offset>]
Order by column
The next step is to create the entry point to start building the query. In the case of GSQL it is the select method of GSQL class which is defined statically in GSQL class and star-imported to any class or script which wants to use the DSL. Also some keywords like all or desc are defined as static properties of the GSQL class for the same reasons.
GSQL
As you could already mention from previous snippets the query is just ordinary POGO which collects the query parameters. In fact there are three of them to force the order of the commands. The only DSL magic is to add keyword(value) method to the query builder class. You should notice that these methods also constraints the expected value by type. The querying itself happens in the build method of the QueryBuilder class.
SelectBuilder
QueryBuilder
OrderBuilder
The GSQL is still work-in-progress. In future it might support also some data manipulation language for executing updated etc. There are also few things which must be done unless the business users could use the language safely. The most important one is to create secured shell which will prevent writing malicious code in the queries.
Tuesday, May 24, 2011
Easy switching between Groovy Eclipse 1.7 and 1.8 compilers
Groovy 1.8 compiler support for Groovy Eclipse is out for a while but many people waited for final Groovy 1.8 release to start using it. Using a new compiler is tricky because you need to restart Eclipse each time you want to switch from 1.7 to 1.8 compiler version but the switching button doesn't work as expected. This article will guide you how to set up Eclipse to work easily with Groovy 1.7 and 1.8 project in one single installation.
Switching dialog in Eclipse Preferences
The first thing which came to my mind was to create two separate workspaces - one for Groovy 1.7 projects and the other for 1.8 ones. I hoped the settings are per workspace and this will be enough but the compiler setting is set globally for whole Eclipse installation. Nevertheless, using separate workspaces gives you a good overview, which version projects use and in my opinion you should not mix 1.7 and 1.8 projects unless you want to spend a day confirming "The source cannot be build because some-lib is not compatible with Groovy 1.X version" message dialog. Spock framework libs could be especially annoying because they have two separate versions for 1.7 and 1.8 which are not compatible with the other one. The other way is to keep project in one workspace and always close the projects causing the troubles which is quite cumbersome.
As for now we should have two workspaces - one for each bunch of projects for particular Groovy version. But this doesn't fix our problem. What we need are two configuration folders. The best way to create them is to launch your Eclipse, switch to the 1.8 compiler and close it. Then go to your Eclipse installation folder and duplicate whole configuration folder to the e.g. configuration18. To switch the original configuration back to 1.7 compiler follow these steps from the switching guide
Switching dialog in Eclipse Preferences
The first thing which came to my mind was to create two separate workspaces - one for Groovy 1.7 projects and the other for 1.8 ones. I hoped the settings are per workspace and this will be enough but the compiler setting is set globally for whole Eclipse installation. Nevertheless, using separate workspaces gives you a good overview, which version projects use and in my opinion you should not mix 1.7 and 1.8 projects unless you want to spend a day confirming "The source cannot be build because some-lib is not compatible with Groovy 1.X version" message dialog. Spock framework libs could be especially annoying because they have two separate versions for 1.7 and 1.8 which are not compatible with the other one. The other way is to keep project in one workspace and always close the projects causing the troubles which is quite cumbersome.
As for now we should have two workspaces - one for each bunch of projects for particular Groovy version. But this doesn't fix our problem. What we need are two configuration folders. The best way to create them is to launch your Eclipse, switch to the 1.8 compiler and close it. Then go to your Eclipse installation folder and duplicate whole configuration folder to the e.g. configuration18. To switch the original configuration back to 1.7 compiler follow these steps from the switching guide
- Go to eclipse/configuration/org.eclipse.equinox.simpleconfigurator
- Make a backup copy of bundles.info
- Open bundles.info in a text editor
- Find the line for org.codehaus.groovy_1.8 and delete (thus leaving the 1.7 compiler enabled)
Do this for the configuration folder only and leave the configuration18 as it is. The last mile is to launch the Eclipse with given configuration using the command line arguments
eclipse -configuration configuration18 -data workspace18
Specifying the workspace folder is optional. You will probably want to wrap up it as a BAT file or a shell alias/script. This launcher will use the 1.8 compiler. If you want to run 1.7 one you just use the standard one.
Labels:
development,
eclipse,
groovy
Thursday, May 19, 2011
Writing Groovy DSL descriptors (DSLD) for Eclipse
Andrew Eisenberg recently announced new great feature in Groovy Eclipse - the new DSL descriptors which brings you better code completion based on domain specific languages into your Groovy scripts and classes. If you are library developer or just enthusiastic user who wants better Eclipse coding go ahead and create your own DSL descriptor. It's surprisingly easy. In this article I want to share my experience from creating DSLD file for the Gaelyk.
Preparation
Before you start, be sure you have all items on the following check list
Creating the DSLD file
The DSL descriptor is all about finding the right places using the pointcuts and contributing right method or properties to the scope found. If you successfully download the DSLD files descriptor you should have a code completion on place and can start coding.
If you are author of the framework or library it is easy to find out which contribution you want to create. If you aren't you should find the origins of contributions you want to cover in your DSLD not to forget anything. In the case of Gaelyk there are a few places where this happens: variables for views and templates are added using GaelykBindingEnhancer, routes DSL is defined in RoutesBaseScript and finally App Engine enhancements comes from GaelykCategory.
The DSLD official documentation is little bit messy so I've created following tables of all available pointcuts and contributions.
Pointcuts and Contributions
As soon as you know what do you want contribute and how should you do it the rest is all about copy pasting and rewriting (unless your DSL comes from a category so you can use the Category Explorer for scaffolding).
Shortcuts for Groovlets
Groovlets are scripts which resides in war/WEB-INF/groovy so we could pick them using sourceFolderOfCurrentType('war/WEB-INF/groovy') pointcut in combination with enclosingScript(). Everything else is just about declaring the right methods and properties.
App Engine Shortcuts
App Engine shortcuts are all defined inside GaelykCategory class. They apply on particular App Engine types (currentType(type)) inside Groovlets which are scripts residing in war/WEB-INF/groovy as written above. We define the pointcut once and then we can use it for each supported type. Since GaelykCategory is category the Category Explorer was used for scaffolding.
Image Manipulation Language
The definition of image manipulation language is the most advanced one. We are looking for closure passed into the method call named transform on com.google.appengine.api.images.Image type. Everything else is just the same boring copy pasting again.
Tips, tricks and pitfalls
Here are some ideas which I learnt when I created the Gaelyk DSDL.
Preparation
Before you start, be sure you have all items on the following check list
- Latest Groovy Eclipse plugin, idealy inside SpringSource Tool Suite
- Latest version of DSLD files descriptor
You should also explore the sources at the end of the article. DSL Descriptors for Groovy Eclipse is actually only source describing the DSLD and DSLD Examples could give you good overview what is possible to achieve with DSLDs.
When everything in place, you can open your Eclipse, create new Groovy project and add libraries you want the DSLD create for to the classpath (for testing and documentation purposes). Then save the DSLD files descriptor into the src folder and also create your new DSLD file in the src folder too.
Creating the DSLD file
The DSL descriptor is all about finding the right places using the pointcuts and contributing right method or properties to the scope found. If you successfully download the DSLD files descriptor you should have a code completion on place and can start coding.
If you are author of the framework or library it is easy to find out which contribution you want to create. If you aren't you should find the origins of contributions you want to cover in your DSLD not to forget anything. In the case of Gaelyk there are a few places where this happens: variables for views and templates are added using GaelykBindingEnhancer, routes DSL is defined in RoutesBaseScript and finally App Engine enhancements comes from GaelykCategory.
The DSLD official documentation is little bit messy so I've created following tables of all available pointcuts and contributions.
Pointcuts and Contributions
As soon as you know what do you want contribute and how should you do it the rest is all about copy pasting and rewriting (unless your DSL comes from a category so you can use the Category Explorer for scaffolding).
Shortcuts for Groovlets
Groovlets are scripts which resides in war/WEB-INF/groovy so we could pick them using sourceFolderOfCurrentType('war/WEB-INF/groovy') pointcut in combination with enclosingScript(). Everything else is just about declaring the right methods and properties.
App Engine Shortcuts
App Engine shortcuts are all defined inside GaelykCategory class. They apply on particular App Engine types (currentType(type)) inside Groovlets which are scripts residing in war/WEB-INF/groovy as written above. We define the pointcut once and then we can use it for each supported type. Since GaelykCategory is category the Category Explorer was used for scaffolding.
Image Manipulation Language
The definition of image manipulation language is the most advanced one. We are looking for closure passed into the method call named transform on com.google.appengine.api.images.Image type. Everything else is just the same boring copy pasting again.
Tips, tricks and pitfalls
Here are some ideas which I learnt when I created the Gaelyk DSDL.
- The DSLD file won't compile and show in DSLD preferences screen if you import any non-standard class even it is on the project's classpath so you'd better prefer to use fully qualified strings to specify the types e.g. javax.servlet.http.HttpServletRequest.
- Some of the pointcuts could be tricky, e.g. name of the script when name() pointcut is used is always without the suffix. To get name with the suffix included use fileName() one. You can also get only the suffix by using fileSuffix() pointcut.
- I cannot find the easy way to debug the script but you can run your STS from console and watch the log. You can insert console prints in your DSLD files to explore the states of the variables.
- Divide a editor viewport on half vertically and show a 'test' file/script/class bellow your DSLD file. If something goes wrong you get visual feedback immediately.
- Try to be DRY. Combine pointcuts to the closures and reuse them.
- Find the source of contributions and try to reuse them. For example you can scaffold the DSLD from Category class using the simple Category Explorer
- Think twice when arguments are type of Map. Aren't they just named args? So you should use useNamedArgs = true and write all the desired named args in params (see e.g. add method on queues)
- DSLDs are greate but there are still some features missing. For example I couldn't find how to specify what parameters are expected to be passed into the closure or how to specify type parameters for parametrized types e.g. maps.
Splitted viewport for better visual feedback
Summary
DSL descriptors takes coding Groovy in Eclipse one level higher. Where used to be underlined methods and properties you now get full code completion. Even more advanced DSL could be supported, just like Gaelyk's image manipulation language. So don't wait and write DSL descriptor for your favourite library! The Groovy Eclipse users will love you for it!
Sources
Written by Vladimir Oraný (@musketyr)
Labels:
development,
dsld,
eclipse,
groovy,
sts
Sunday, April 17, 2011
Don't miss any tweet with Kiwittr
Have you ever missed an important tweet just because you were on holiday with no roaming or you were just to busy to read new tweets? This will no longer happen. Our new product Kiwittr will help you to deal with this problem. The Kiwittr adds new event to your calendar whenever new tweet you are interested in occurs. If you have SMS notification enabled the message will be also sent to your cell phone.
It is very easy to start using the Kiwittr. First of all you need to sign in using your Google Account and accept the ability to use your Google Account to sign in. Then the profile page welcomes you with its stepwise wizard. You need to authorize access to your Google Calendar so the Kiwittr will be able to add new events into it and also you need to authorize your Twitter account so the Kiwittr can run search queries using your account (the access is read only so there is guarantee we will not spam anyone using your Twitter, you can use share on Twitter button manually if you like the product).
It is very easy to start using the Kiwittr. First of all you need to sign in using your Google Account and accept the ability to use your Google Account to sign in. Then the profile page welcomes you with its stepwise wizard. You need to authorize access to your Google Calendar so the Kiwittr will be able to add new events into it and also you need to authorize your Twitter account so the Kiwittr can run search queries using your account (the access is read only so there is guarantee we will not spam anyone using your Twitter, you can use share on Twitter button manually if you like the product).
After everything goes green you can add new Twitter query. You probably wants to add some sophisticated one such as "from:manningdotd java OR groovy" not to miss any deal of the day from Manning publisher but you can as well type a single word such as "myinterest". If you are bored of retrieving notifications you can delete particular query using the "remove" link right next to the query text.
And what happen when a new query is found? If you have SMS notification enabled in your Google Calendar you retrieve ordinal text message such as "Reminder: new tweets for query from:manningdotd java OR groovy". Now you probably hurry to the closest wifi enabled coffee house or a hotel room and read what's actually happen. You don't need to search twitter again to find what's new. The found text is recorded in the description of newly created event.
The Kiwittr is currently in beta testing phase with the limited number of users. So don't wait and try it now.
See who's using Google Apps!
If you are a company doing Google Apps business the information who actually uses them is very valuable for you. There are several ways how to find it out. You can for example follow the #gonegoogle hashtag on Twitter, check the map provided by Google or the official list of the companies but there are too much or contrary too few information. What you usually need is to find out if the particular company uses Google Apps. This could be difficult but now we offer you a simple web service Google Apps Finder which does the hard work for you.
Google Apps Finder comes to you in two forms. You can use it's web interface or you can install it as a chrome extension. Using web interface you can check any domain you want. You can also see the latest discovered domains. The chrome extension shows green or red magnifier icon in address bar each time the domain you are currently browsing on uses or might use Google Apps. If the icon is green it is certain that the domain uses Google Apps including gmail (email services). Red icon indicates that Google Apps is present on a domain but email is not activated. So it may be that someone was just playing with Google Apps for a while or it is used just for documents or so.
Wish you happy Google Apps Finding!
Open PDF GMail attachments in Google Viewer again
Do you miss old good Google Viewer for PDF attachments where you could save the PDF file directly to the Google Docs? We created new Show PDF in GViewer extension for you so you can now use Google Viewer for PDF files again.
After installation new icon appears next to "View" link. Clicking this icon you can view your attachments in old good Google Viewer.
Subscribe to:
Posts (Atom)