Best practice per il controllo dell'accesso a un pacchetto ".internal"

Question

Scrivo i plug-in Eclipse ed esporta alcune classi come API pur volendo limitare l'accesso ad altre classi.

Seguo la pratica comune di Eclipse di separare queste classi in un subpackage ".internal".

Tuttavia, non posso utilizzare "pacchetto" o accesso di livello predefinito su queste classi poiché molte di esse devono essere utilizzate dalle classi che sto esportando.

Qual è la prassi migliore per impedire o scoraggiare gli utenti della mia API dall'utilizzare queste classi per i propri scopi? C'è un correttore automatico?

Ammetto che ho sguazzato nel usando alcune delle classi interne di Eclipse, quando non avevo altra scelta :)

Precisazione: Ho un bisogno simile con codice non-plugin.

Answer 1

Non è solo un caso di aggiornamento di META-INF/MANIFEST.MF a un progetto di osgi plug-in (se non lo è già?). Dovrebbe assomigliare a:

Manifest-Version: 1.0 
Bundle-ManifestVersion: 2 
Bundle-Name: My-plugin 
Bundle-SymbolicName: com.mycompany.mypluginname 
Bundle-Version: 1.0.0 
Bundle-Vendor: MyCompany 
Bundle-RequiredExecutionEnvironment: JavaSE-1.6 
Service-Component: 
Import-Package: org.apache.log4j;version="1.2.14" (, separated etc) 
Export-Package: com.mycompany.mypluginname.myapipackage;version="1.0.0" 

E quindi omettere il pacchetto .internal. La piattaforma dovrebbe fare il resto.

A proposito, si utilizza il pacchetto di importazione: in qualsiasi bundle dipendente, plug-in, ecc, piuttosto che in base al jar/progetto (che è il vecchio modo sucky che non funziona - come sei individuazione).

Questo ti dà un enorme disaccoppiamento delle dipendenze del codice. Se decidi che il codice del tuo plug-in dovrebbe appartenere a un altro jar/bundle, devi solo spostare singoli pacchetti e fare in modo che il nuovo bundle/plug-in lo esporti. Poiché i bundle client importano semplicemente il pacchetto da "the cloud" (il cloud è la piattaforma OSGi), è possibile spostare il codice molto più liberamente.

Nota: Come menzionato nei commenti, non è necessario eseguire le app in OSGi per ottenere questo "vantaggio". Eclipse può compilare il codice sotto le restrizioni del pacchetto OSGi e il tuo build/server può essere eseguito nel "mondo non protetto". per esempio. i manifesti di OSGi non impongono nulla a terze parti (che desiderano utilizzare .internal), ma forniscono "notifiche" e restrizioni a coloro che li desiderano.

Answer 2

A meno che non si debba gestire il codice non affidabile di qualcun altro utilizzando la propria libreria attendibile, si prega di non limitarlo.

L'esigenza di accesso interno/pacchetto a volte indica un errore della progettazione dell'API e non è possibile conoscerne fino a molto tempo dopo.

Rendilo pubblico, chiamalo InternalWhatever e vivi con esso.

Answer 3

Per progetti di plug-in: Utilizzare la configurazione di Manifest che menziona Stephen. (È inoltre possibile modificare questo attraverso la pagina "runtime" dell'editor manifesto. Si noti che se si desidera esporre solo un pacchetto per i plugin specifici si può fare anche utilizzando

Export-Package: com.javadude.foo;x-friends:="com.javadude.fee" 

Per i non-plugin progetti: utilizzare cartelle di origine separate per definire ciò che viene esportato dal progetto.

1. pulsante destro del mouse progetto e scegliete Nuova cartella di origine (forse il nome "interno-source")
2. progetto pulsante destro del mouse e scegliere Proprietà
3. Vai a Java Build Path
4. Clicca l'Ordine e scheda Esporta
5. deselezionare le cartelle di origine che non si desidera esportare

Solo le cartelle di origine che vengono controllati in "ordine e export" volontà essere aggiunto al percorso di classe dei progetti di riferimento.