Ik zit in een project waar meerdere bedrijven aan bijdragen. Dit project bestaat uit ongeveer 4 hoofddelen en elke deel bestaat uit 3 of meer jars (server, shared, client services, gui)
Om de version serialid incompatible problemen te ondervangen heeft een partner een ant task gemaakt wat een java file genereerd met een static string waar de versie in staat. Met elke build haalt hij de versie nummer (wat dus de CVS TAG is) uit de release notes en compiled een Version.class file naar de bin folder.
De klanten moeten ook een overzicht hebben over welke modulen er allemaal geinstalleerd zijn zodat wij betere support kunnen leveren.
Alle modulen hebben dus een eigen package met daarin een Version.class. Echter met het generen van het overzicht, moet ik alle packaged hardcoded invoeren en daar de versie uit halen. Aangezien ons systeem op een plugin framework (OGSi) is gebaseerd kan het aantal jars per deployment verschillenen (de JNLP file wordt door een servlet gegeneerd en de resource entries worden dynamisch toegevoegd door over de lib folder te itereren). Hierdoor is het dus niet echt makkelijk om hardcoded alle versies uit te lezen.
Ik heb altijd twijfels gehad met deze aanpak...
Na het lezen van de Java Product Versioning Specification (http://java.sun.com/j2se/1.5/pdf/versioning.pdf) en het onderzoeken van de MANIFEST.MF bestanden lijkt het me beter om alle versie in de MANIFEST.MF te zetten. Tenslotte kan je bij alle jars die door de classloader geladen zijn de MANIFEST.MF van uitlezen.
Mijn idee is om alle build files (stuk of 20
) aan te passen om de versie in de META-INF folder te zetten en deze uit te lezen
Versioning op package level gaat te ver. Ik hoef alleen de versies op JAR level te weten.
Opzich kunnen server en client versies van elkaar verschillen zolang de shared objecten niet wijzigen. Er is dus een dependancy tussen de server --> shared < -- client. Kan deze dependancy ook in de manifest.mf gezet worden? dus als de shared objecten veranderen, moet de server geen diensten verlenen aan versies die ouder zijn.
Wat is nu een goede aanpak voor Versioning? Zijn daar standaard frameworks voor? het project wordt maar groter en groter en voor mij is het nog wel goed te doen om het overzicht te bewaren, maar als we dalijk support moeten gaan leveren, dan willen we wel exact weten welke branch een klant heeft geinstalleerd.
Om de version serialid incompatible problemen te ondervangen heeft een partner een ant task gemaakt wat een java file genereerd met een static string waar de versie in staat. Met elke build haalt hij de versie nummer (wat dus de CVS TAG is) uit de release notes en compiled een Version.class file naar de bin folder.
De klanten moeten ook een overzicht hebben over welke modulen er allemaal geinstalleerd zijn zodat wij betere support kunnen leveren.
Alle modulen hebben dus een eigen package met daarin een Version.class. Echter met het generen van het overzicht, moet ik alle packaged hardcoded invoeren en daar de versie uit halen. Aangezien ons systeem op een plugin framework (OGSi) is gebaseerd kan het aantal jars per deployment verschillenen (de JNLP file wordt door een servlet gegeneerd en de resource entries worden dynamisch toegevoegd door over de lib folder te itereren). Hierdoor is het dus niet echt makkelijk om hardcoded alle versies uit te lezen.
Ik heb altijd twijfels gehad met deze aanpak...
Na het lezen van de Java Product Versioning Specification (http://java.sun.com/j2se/1.5/pdf/versioning.pdf) en het onderzoeken van de MANIFEST.MF bestanden lijkt het me beter om alle versie in de MANIFEST.MF te zetten. Tenslotte kan je bij alle jars die door de classloader geladen zijn de MANIFEST.MF van uitlezen.
Mijn idee is om alle build files (stuk of 20
) aan te passen om de versie in de META-INF folder te zetten en deze uit te lezen Java:
1
2
3
4
5
6
| for (Enumeration e = TrackingFramework.class.getClassLoader().getResources( "META-INF/MANIFEST.MF"); e.hasMoreElements();) { URL url = (URL) e.nextElement(); //haal versie uit de manifest.mf } |
Versioning op package level gaat te ver. Ik hoef alleen de versies op JAR level te weten.
Opzich kunnen server en client versies van elkaar verschillen zolang de shared objecten niet wijzigen. Er is dus een dependancy tussen de server --> shared < -- client. Kan deze dependancy ook in de manifest.mf gezet worden? dus als de shared objecten veranderen, moet de server geen diensten verlenen aan versies die ouder zijn.
Wat is nu een goede aanpak voor Versioning? Zijn daar standaard frameworks voor? het project wordt maar groter en groter en voor mij is het nog wel goed te doen om het overzicht te bewaren, maar als we dalijk support moeten gaan leveren, dan willen we wel exact weten welke branch een klant heeft geinstalleerd.