I see that you cover add-ons in the Spring Roo in Action book. Do you also cover the use of PGP trusted add-ons?
This looks like it could be quite valuable in the academic realm where we collaborate with several other institutions and would want to establish a trust relationship through PGP via the use of a common certificate authority. The goal would be to have 1 common web application that fronts big data (genomic) with swappable analysis routines implemented as Roo add-ons.
William Stephens wrote:I see that you cover add-ons in the Spring Roo in Action book. Do you also cover the use of PGP trusted add-ons?
That's exactly what you'd do, use the same PGP key. If you follow the key registration process, you'll have to have one key administrator and one pass phrase, but that said you can definitely sign your artifacts. It's using the maven-gpg-plugin plugin to sign the resources, and then the Roo shell lets you install a trusted key (once it has been registered properly) so that you can install those add-ons.
If you try to install an add-on without a trusted key, you'll be prompted to lower your trust or add the key. You'd then do that with pgp automatic trust enabled or with adding a pgp key (syntax escapes me as I'm writing).
This is all covered in the book, in the second add-on chapter.
Now, what you can't do using the RooBot (and the addon search / addon install commands) is make that key private and/or filter your projects from the public, as you have no protected security rights on that repository. I would recommend you use the OSGI OBR Repository mechanism. Here's what you can do:
1. Set up a cloudbees or other hosting service to get a maven repository
2. Set up rights to that maven repository and send the username/password to your collaborators
3. Have them use osgi obr url add and then osgi obr start to add the OBR repository and install the add-ons
That way, you've set up a shared set of Maven artifacts via the Object Bundle Repository (OBR) approach, which I also cover in the book. You're basically having the build update a repository.xml file in the root of the Maven repo which documents all versions of all OSGi bundles you've installed there. Once you protect that repo, you can limit what organizations can gain access to the contents.
Now, even further down, you can use Nexus or Artifactory as maven servers in your environments, download those trusted artifacts, and host them locally in your organization so your developers don't need to have protected access.
BIG WARNING THOUGH - currently, until ROO-3127 is fixed, you can't host these on a SSL host - it only accepts non-SSL http repositories. I'm thinking this will be fixed in ROO 1.3. (Vote that issue up if you want more of an option for hosting OSGi modules on an SSL-only repository or one that does rewrites.
Yeah. We still drive a lot of our development from XMI logical models. We had a tool that would generate a data model from a logical model. It was nice, but with some current frameworks, like Roo, we don't have to generate the data model at all because the framework does the work.
I extended this tool to:
Read an XMI model containing a logical model
Provide a selection of web frameworks: Roo, Grails (this is extensible)
Iterate through the objects and relationships
Output a shell script of CLI commands that will create an app
Note: Roo provides the most fully useable CLI for this approach.
In this way, we can continue to focus obsessively on a logical model in the initial stages of a research project. However, we can then generate an application and switch to Domain Driven Design and have the ability to change the domain objects when we hit an unexpected issue or receive a new requirement. This seems to add a little more of an engineering approach that seems missing with most approaches using domain driven frameworks.
That is a really interesting angle for using Roo. I know of others who are using the dbre reverse engineering add-on, as well, to keep a Roo crud app in sync with changes to their product under development.