Metodi sostenibili per l'utilizzo di un plug-in standard e il riconfezionamento di un piccolo pezzo leggermente modificato in un plug-in personalizzato

1

Un po 'di background sul sistema con cui ho a che fare:

Piattaforma di analisi --compreso da - > Plugin OSGi --compresi da - > Pacchetti Java - contenenti - > unità (s) di funzionalità ciascuna con MVC indipendenti (chiamati "nodi")

Il plug-in che vorrei aumentare è chiamato "base" e tutti gli utenti finali della piattaforma di analisi lo utilizzano per impostazione predefinita. È open source, standard con la piattaforma di analisi ed espone un'API Java. Mi piacerebbe aumentare un nodo all'interno della base. Il nodo è chiamato "File Reader".

Che cosa devo fare: ho bisogno di fornire una versione aggiuntiva aumentata del nodo "File Reader" con una modifica: ho bisogno di aggiungere una casella di controllo per disabilitare il casting automatico dei dati in ingresso il nodo e implementare la disabilitazione.

Requisiti aggiuntivi:

  • Fornisci il lettore di file aumentato in un plugin OSGi aggiuntivo che gli utenti possono scaricare e installare
  • Assicurati che il plugin aggiuntivo possa essere usato insieme al plugin "base" senza causare problemi. Ad esempio, assicurati che gli utenti finali possano utilizzare contemporaneamente sia il nodo originale "Lettore di file" sia il mio nuovo nodo "Lettore di file aumentato"
  • Mantieni aggiornato "Lettore di file aumentato" con correzioni di errori e aggiornamenti "Lettore di file"
  • Mantenere più versioni del mio plugin corrispondenti a più versioni del plugin "base"

Sfida: la scelta naturale è estendere l'API disponibile del Lettore file. Tuttavia, alcune delle funzionalità del nodo Lettore file originale sono package-private, in particolare parti della vista di MVC. Potrei provare ad estendere (tramite ereditarietà) quanto più possibile dall'API esposta da File Reader, quindi replicare la vista privata del pacchetto di File Reader nel mio plugin personalizzato. Tuttavia, replicare la vista mi farebbe duplicare 500-2000 righe di codice. Tutto quello che voglio fare è inserire una casella di controllo che disabiliti un'unità di funzionalità predefinita nel Lettore file originale, che dovrebbe essere facile, dato che è Swing. La mia funzionalità probabilmente cambierà 5-30 righe di codice. Pertanto, non penso che meriti di ri-implementare la vista.

Note importanti presentate dalla discussione con Doc Brown:

  • I manutentori della suite di analisi hanno messo in chiaro che non accetteranno richieste di pull in questo momento.

  • Inoltre, se forzo il repository git del manutentore e implemento la funzione in un plugin "base" aumentato, gli utenti finali semplicemente non saranno disposti a utilizzare la mia versione del plug-in, dal momento che include tanta funzionalità ( Il 99% dei quali non riguarda ciò che sto cercando di fare).

Qualcun altro ha riscontrato questa situazione? Esiste un modo standard per gestirlo?

La mia migliore idea su una soluzione fin da ora (si prega di commentare e criticare):

  • Sostituisci il codebase del plugin "base" originale (git) per aggiungere la funzione
  • mantieni il codice di "base" come se aggiungessi semplicemente una funzionalità al nodo Lettore file in un nuovo ramo del plugin "base"
  • Crea una build personalizzata: includi solo il nodo del lettore di file aumentata nel mio plugin
  • Anche nella build personalizzata: per garantire che non ci siano conflitti di pacchetti / classi con il plugin "base" in fase di caricamento / runtime, utilizzare una sorta di macro refactoring pre-compilazione per rinominare classi, pacchetti e qualsiasi altra cosa che potrebbe causare conflitti
posta joe55 27.04.2017 - 17:25
fonte

2 risposte

1

Bene, non so nulla dei dettagli della tecnologia che hai menzionato, ma il modo migliore per soddisfare i tuoi "requisiti aggiuntivi" è probabilmente:

  • convinca il manutentore del plug-in originale per integrare le modifiche necessarie nel bagagliaio

Assicurati che le modifiche siano fatte in un modo compatibile con le versioni precedenti, in modo che altri utenti del plugin possano usarlo ancora in modo originale, se lo desiderano, o in modo migliorato, se preferiscono questo. Dovresti anche testare bene le tue modifiche prima di fare una richiesta di pull al manutentore e assicurarti che si adatti al progetto esistente, il che probabilmente aumenterà le probabilità di unire le tue modifiche nel trunk.

    
risposta data 27.04.2017 - 19:29
fonte
0

In OSGi puoi facilmente codificare i byte in altri pacchetti. Se registri un servizio WeavingHook, avrai la possibilità di cambiare i codici byte dei pacchetti che vengono caricati dopo di te. Il trucco potrebbe essere quello di registrarsi abbastanza presto.

Utilizzando le librerie di programmazione orientate ad Aspect puoi semplificare la selezione del target attuale.

    
risposta data 28.04.2017 - 09:10
fonte

Leggi altre domande sui tag