Loading of YangFiles dependent on bundle order in features.xml

It appears that the order of bundles in the feature.xml matters in terms of how the yang files are loaded by the config subsystem.

When I do a feature:install odl-restconf I see the below exception:

**(NOTE: CONTROLLER-811 fixes this particular instance, but you can recreate the problem following the below instructions in reverse ).***

2014-09-11 12:34:29,218 | INFO | Local user karaf | SharedSchemaContextFactory | 96 - org.opendaylight.yangtools.yang-parser-impl - 0.6.2.SNAPSHOT | Failed to assemble sources
SchemaResolutionException{unsatisfiedImports={SourceIdentifier [name=sal-remote-augment@2014-7-8]=[ModuleImportImpl [name=sal-remote, revision=2014-01-14]]}}
at org.opendaylight.yangtools.yang.parser.repo.SharedSchemaContextFactory$2.apply(SharedSchemaContextFactory.java:77)
at

== Full Exception @ end ===

When I modify the odl-restconf feature and move the

<bundle>mvn:org.opendaylight.controller/sal-remote/${mdsal.version}</bundle>

above

<bundle>mvn:org.opendaylight.controller/sal-rest-connector/${mdsal.version}</bundle>

the exception goes away.

Unknown what affects this have.

==== Possible Resolution ====

Move the bundle for now, and long term we should look at removing the order dependency.

==== FULL EXCEPTION ====

2014-09-11 12:34:29,218 | INFO | Local user karaf | SharedSchemaContextFactory | 96 - org.opendaylight.yangtools.yang-parser-impl - 0.6.2.SNAPSHOT | Failed to assemble sources
SchemaResolutionException{unsatisfiedImports={SourceIdentifier [name=sal-remote-augment@2014-7-8]=[ModuleImportImpl [name=sal-remote, revision=2014-01-14]]}}
at org.opendaylight.yangtools.yang.parser.repo.SharedSchemaContextFactory$2.apply(SharedSchemaContextFactory.java:77)
at org.opendaylight.yangtools.yang.parser.repo.SharedSchemaContextFactory$2.apply(SharedSchemaContextFactory.java:61)
at com.google.common.util.concurrent.Futures$ChainingListenableFuture.run(Futures.java:859)
at com.google.common.util.concurrent.MoreExecutors$SameThreadExecutorService.execute(MoreExecutors.java:293)
at com.google.common.util.concurrent.ExecutionList$RunnableExecutorPair.execute(ExecutionList.java:150)
at com.google.common.util.concurrent.ExecutionList.add(ExecutionList.java:106)
at com.google.common.util.concurrent.AbstractFuture.addListener(AbstractFuture.java:170)
at com.google.common.util.concurrent.Futures.transform(Futures.java:613)
at com.google.common.util.concurrent.Futures.transform(Futures.java:565)
at org.opendaylight.yangtools.yang.parser.repo.SharedSchemaContextFactory.createSchemaContext(SharedSchemaContextFactory.java:126)
at org.opendaylight.yangtools.yang.parser.repo.URLSchemaContextResolver.getSchemaContext(URLSchemaContextResolver.java:165)
at org.opendaylight.controller.sal.dom.broker.GlobalBundleScanningSchemaServiceImpl.tryToUpdateSchemaContext(GlobalBundleScanningSchemaServiceImpl.java:236)
at org.opendaylight.controller.sal.dom.broker.GlobalBundleScanningSchemaServiceImpl$BundleScanner.addingBundle(GlobalBundleScanningSchemaServiceImpl.java:191)
at org.opendaylight.controller.sal.dom.broker.GlobalBundleScanningSchemaServiceImpl$BundleScanner.addingBundle(GlobalBundleScanningSchemaServiceImpl.java:165)
at org.osgi.util.tracker.BundleTracker$Tracked.customizerAdding(BundleTracker.java:467)[karaf-org.osgi.core.jar:]
at org.osgi.util.tracker.BundleTracker$Tracked.customizerAdding(BundleTracker.java:414)[karaf-org.osgi.core.jar:]
at org.osgi.util.tracker.AbstractTracked.trackAdding(AbstractTracked.java:256)[karaf-org.osgi.core.jar:]
at org.osgi.util.tracker.AbstractTracked.track(AbstractTracked.java:229)[karaf-org.osgi.core.jar:]
at org.osgi.util.tracker.BundleTracker$Tracked.bundleChanged(BundleTracker.java:443)[karaf-org.osgi.core.jar:]
at org.eclipse.osgi.framework.internal.core.BundleContextImpl.dispatchEvent(BundleContextImpl.java:847)
at org.eclipse.osgi.framework.eventmgr.EventManager.dispatchEvent(EventManager.java:230)
...