Thanks for the reply, Stan.

When you say 'via fabric' what do you mean exactly? I guess I'm asking what commands I would use?

I'm aware I could use the FMC interface, but we're actually scripting a lot of fabric setup using cucumber, so knowing the commands to use would be immensely helpful.

I've just tab completed on fabric: to seek the relevant function but can't see one.

I also checked  here but there's no fab:install command and no fab: command is available in my containers anyway, it seems.

Ah of course, I should know this! It's our first play with bundles - it's been features commands only thus far, and I'd forgotten what else you can do with profile-edit. Thank you for the timely reminder, Stan.

Hmm sadly this hasn't fixed it.

Here's what we did:

1. Create profile 'custom-fab', extending 'karaf' with feature 'fabric-bundle'*

  fabric:profile-create --parents karaf custom-fab

  fabric:profile-edit --features fabric-bundle custom-fab

1. Create profile 'custom-app', extending 'custom-fab' with fab 'myapp'*

  fabric:profile-create --parents custom-fab custom-app

  fabric:profile-edit --fabs mvn:com.custom.wms.web/myapp/1.0-SNAPSHOT custom-app

1. Create container 'demo-myapp' with profile 'custom-app'*

  fabric:container-create-child --profile custom-app root demo-myapp

This fails to provision, error is at the bottom of this post.

The fabric host has no internet connection, therefore all provisioning it has done up to this point is via the Nexus maven repositories we've specified.

We've confirmed that the myapp artifact specified exists in the repositories with the specified Maven URI.

We'll try refreshing the PAX bundles now - I believe this is what you were suggesting, Stan, where you mention "restart those URL handlers".

Here's the error seen via log:tail (for now we chose to ignore the WARN message, since that log level suggests it's not critical).

2013-01-03 15:40:47,931 | WARN  | agent-1-thread-1 | MavenRepositoryURL               | maven.commons.MavenRepositoryURL  116 | 1 - org.ops4j.pax.url.mvn - 1.3.5 | Repository spec http://maven/nexus/content/groups/all-repos/ does not contain an identifier. This is deprecated & discouraged & just evil.

2013-01-03 15:40:47,952 | ERROR | agent-1-thread-1 | DeploymentAgent                  | e.fabric.agent.DeploymentAgent$1  241 | 67 - org.fusesource.fabric.fabric-agent - 7.1.0.fuse-047 | Unable to update agent

java.io.IOException: URL mvn:com.ocado.wms.web/rf-server/1.0-SNAPSHOT could not be resolved.

        at org.fusesource.fabric.fab.osgi.internal.FabResolverFactoryImpl$FabResolverImpl.getInfo(FabResolverFactoryImpl.java:260)[67:org.fusesource.fabric.fabric-agent:7.1.0.fuse-047]

        at org.fusesource.fabric.agent.DeploymentAgent.updateDeployment(DeploymentAgent.java:517)[67:org.fusesource.fabric.fabric-agent:7.1.0.fuse-047]

        at org.fusesource.fabric.agent.DeploymentAgent.doUpdate(DeploymentAgent.java:428)[67:org.fusesource.fabric.fabric-agent:7.1.0.fuse-047]

        at org.fusesource.fabric.agent.DeploymentAgent$1.run(DeploymentAgent.java:238)[67:org.fusesource.fabric.fabric-agent:7.1.0.fuse-047]

        at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)[:1.6.0_26]

        at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)[:1.6.0_26]

        at java.util.concurrent.FutureTask.run(FutureTask.java:138)[:1.6.0_26]

        at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)[:1.6.0_26]

        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)[:1.6.0_26]

        at java.lang.Thread.run(Thread.java:662)[:1.6.0_26]

Caused by: java.lang.RuntimeException: URL mvn:com.ocado.wms.web/rf-server/1.0-SNAPSHOT could not be resolved.

        at org.ops4j.pax.url.mvn.internal.Connection.getInputStream(Connection.java:195)[1:org.ops4j.pax.url.mvn:1.3.5]

        at java.net.URL.openStream(URL.java:1010)[:1.6.0_26]

        at org.fusesource.common.util.Files.urlToFile(Files.java:68)[67:org.fusesource.fabric.fabric-agent:7.1.0.fuse-047]

        at org.fusesource.fabric.fab.osgi.internal.FabResolverFactoryImpl$FabResolverImpl.getJarFile(FabResolverFactoryImpl.java:218)[67:org.fusesource.fabric.fabric-agent:7.1.0.fuse-047]

        at org.fusesource.fabric.fab.osgi.internal.FabResolverFactoryImpl$FabResolverImpl.resolvePomDetails(FabResolverFactoryImpl.java:235)[67:org.fusesource.fabric.fabric-agent:7.1.0.fuse-047]

        at org.fusesource.fabric.fab.osgi.internal.FabResolverFactoryImpl$FabResolverImpl.getVersionedDependencyId(FabResolverFactoryImpl.java:178)[67:org.fusesource.fabric.fabric-agent:7.1.0.fuse-047]

        at org.fusesource.fabric.fab.osgi.internal.FabClassPathResolver.resolve(FabClassPathResolver.java:114)[67:org.fusesource.fabric.fabric-agent:7.1.0.fuse-047]

        at org.fusesource.fabric.fab.osgi.internal.FabResolverFactoryImpl$FabResolverImpl.configureInstructions(FabResolverFactoryImpl.java:283)[67:org.fusesource.fabric.fabric-agent:7.1.0.fuse-047]

        at org.fusesource.fabric.fab.osgi.internal.FabResolverFactoryImpl$FabResolverImpl.createInstructions(FabResolverFactoryImpl.java:275)[67:org.fusesource.fabric.fabric-agent:7.1.0.fuse-047]

        at org.fusesource.fabric.fab.osgi.internal.F

So, we can see what I presume Stan's referencing as the "URL handlers":

admin@demo-app> osgi:list

START LEVEL 100 , List Threshold: -1

   ID   State         Blueprint      Level  Name

System Bundle (4.0.3.fuse-71-047)

OPS4J Pax Url - mvn: (1.3.5)

OPS4J Pax Url - wrap: (1.3.5)

On both the root container and the demo-app container we ran:

osgi:refresh 1 2

And confirmed both refreshes with 'yes' .

We then restarted the container demo-app.

This hasn't resolved the problem sadly.

Any other suggestions? We're fairly stumped now.

We had a look at the FMC 7.1 documentation. Found  this page, but it seems more like an education in basic GUI usage!

I wish you guys had one of these documents for the latest version of Fabric (rather than FMC etc.), describing all the idiosyncrasies we've discovered and updating all out of date commands and info from the  original fabric docs.

Considering the complex nature of Fabric, it would be far more useful for we as an infrastructure team to be able to understand its inner workings with clarity rather than have to post in here continuously.

That being said, I'm very grateful to Stan Lewis for his regular advice; it would have been impossible to reach the level of comprehension we have without it.

We'll explore the Fuse ESB docs now and see whether there's anything relevant there.

Thank you for the suggestion Stan, we'll try doing so tomorrow. If it resolves the issue, maybe you'd consider changing that WARN to a different log level or else adding further emphasis to the warning message. I appreciate "just plain evil" or whatever it says is quite persuasive, but it's not unequivocal.

I forget the correct technical term for these @ suffixes - would you mind reminding me, Stan? I want to read about them to identify how we can specify both @releases and @snapshots since we have both in our Nexus multi-repository group.

Fingers crossed this fixes it, there was quite enough bafflement for my liking today.

We had a look earlier today in the  Fuse ESB 7.1 Docs Collection but aside from the cloud computing fabric doc there's no fabric-specific documentation. However, you're right in suggesting there are useful fabric mentions sprinkled within the ESB docs - we discovered a few nuggets of wisdom there today and will explore further tomorrow. Of particular interest were the Maven FAB archetypes on offer to template e.g. a project defining a Camel route.

You were right Stan, adding @snapshot when configuring the agent and fabric maven proxy with our repo has fixed it! Great work, thank you.

On a side note, the "just evil" log message I referred to is actually referencing the lack of an identifier on our repo, not the missing @snapshot. So please ignore that comment...