OSGi bundle de pacote de estrutura

Question

Eu estive pensando sobre "boas práticas" em relação a estrutura do pacote dentro de pacotes osgi.Atualmente, em média, temos em torno de 8 a 12 aulas por conjunto.Um dos meus iniciativa/proposta tem sido a de ter dois pacotes;com.company_name.osgi.serviços.api (api relacionados com as classes/interfaces (que é exportada externamente) e um pacote com.company_name.osgi.serviços.impl para a implementação (não exportados)).Quais são os prós os contras dessa?Alguma outra sugestão?

Answer 1

Você também pode considerar colocar as interfaces em com.company_name.subsystem, e a implementação em com.company_name.subsystem.impl, o código específico do OSGI, se houver, poderia estar em com.company_name.subsystem.osgi. Em algum momento, você pode ter uma implementação múltipla das mesmas interfaces. Nesse caso, você pode considerar - com.company_name.subsystem.impl1 e com.company_name.subsystem.impl2, por exemplo:

com.company.scm        // the scm api
com.company.scm.git    // its git implementaton
com.company.scm.svn    // its subversion implementation
com.company.scm.osgi   // the place to put an OSGI Activator

Nesse sentido

com.company.scm.sca     // or whatever component model you might think of

Sempre tendo api e impl No nome do seu pacote, pode ser irritante. Em caso de dúvida, use impl mas não api.

Answer 2

Não é o número de classes que é importante, mas os conceitos.Na minha opinião, você deveria ter uma entidade conceitual em um pacote.Em alguns casos, isso pode ser apenas algumas aulas em outros vários pacotes com 100s de classes.

O que é importante é que você separe a API e implementação.Um pacote contém a API de seu conceito e a outra para a implementação.Como esta você pode fornecer implementações diferentes para um bem definidas API.Em alguns casos, isso pode ser necessário se você quiser acessar os serviços de um bundle remotamente (usando por exemploR-OGSi)

Os pacotes da API, em seguida, são utilizados por a partilha de código e os serviços da aplicação de feixes de serviço do compartilhamento.A melhor maneira de explorar essas possibilidades é olhar para o ServiceTrackers.

Answer 3

No seu caso, você pode ter a implementação no mesmo pacote, mas todas as suas classes "protegiam o pacote". Dessa forma, você pode exportar o pacote e a implementação não seria visível para o exterior, mesmo quando não estiver usando osgi (mas como um arquivo jar comum).