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.
Those advanced cases I don't cover.