I agree that there definitely needs to be some separation added here, I would be guided by the level of interdependence between the SPI classes.
I actually prefer the deeper split, but it only makes sense if it doesn't involve a huge uses statement. I'd try going for the split by resposibility and see what BND makes of it. If there are lots of uses constraints then it probably doesn't make sense, if there aren't then it would be my preferred option. Regards, Tim ---------------------------------------- > From: [email protected] > Subject: Package structure in application api > Date: Sun, 12 Sep 2010 13:03:39 -0400 > To: [email protected] > > 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
