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