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