Hi, currently the application api project has one package org.apache.aries.application.management which seems like a very disparate collection of client interfaces and various layers of interfaces to glue the runtime together. I would like to split that so that the packages are more coherent and can be versioned with greater independence.
At the very least there ought to be a split between user's api and implementer's spi: API (everything available from AriesApplicationManager): AriesApplication, AriesApplicationContext, AriesApplicationEvent, AriesApplicationListener, AriesApplicationManager, BundleInfo, ManagementException, ResolveConstraint, ResolverException, UpdateException SPI (everything else) AriesApplicationContextManager, AriesApplicationResolver, BundleConversion, BundleConverter, BundleFramework, BundleFrameworkFactory, BundleFrameworkManager, BundleRepository, BundleRepositoryManager, ContextException, ConversionException, DeploymentManifestManager, LocalPlatform, PlatformRepository, RepositoryGenerator, UpdateStrategy InvalidAttributeException seems to belong in the org.apache.aries.application package since it is only referenced in DeploymentMetadata, which lives there. But even with this the runtime bundles that currently exist would be client and implementer for interfaces in the SPI package at the same time. So a further (OTT) split by responsibility might make sense: spi.conversion: BundleConversion, BundleConverter, ConversionException spi.framework: BundleFramework, BundleFrameworkFactory, BundleFrameworkManager spi.repository: BundleRepository, BundleRepositoryManager, PlatformRepository, RepositoryGenerator spi.resolve: AriesApplicationResolver, DeploymentManifestManager spi.runtime: AriesApplicationContextManager spi.update: UpdateStrategy spi.util: LocalPlatform With the oddball ContextException to be still sorted out What do people think? Is either of these splits sensible or is there something else that would be better? Valentin
