You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@aries.apache.org by Valentin Mahrwald <vm...@googlemail.com> on 2010/09/12 19:03:39 UTC
Package structure in application api
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
RE: Package structure in application api
Posted by Timothy Ward <ti...@hotmail.com>.
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: vmahrwald@googlemail.com
> Subject: Package structure in application api
> Date: Sun, 12 Sep 2010 13:03:39 -0400
> To: aries-dev@incubator.apache.org
>
> 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