Archiv für eigene Klassen

[Carcharoth]

Guten Tag

Ich nutze Eclipse als IDE und GIT zur Versionierung meiner Projekte.

Im Laufe der Zeit schreibe ich mir eine ganze Reihe von nützlichen Klassen die ich immer wieder in meinen Projekten verwenden kann.
Ich überlege mir, wie ich mir so etwas wie ein Archiv anlegen könnte für meine eigene Klassen.

Ich habe an folgende Ansätze gedacht:
- Ich archiviere manuell die entsprechenden JAR-Files in einem Ordner. Dort kann ich jederzeit die gewünschte Klasse holen und in mein aktuelles Projekt einfügen.
- Ich erstelle mir ein Dummy-Projekt unter Eclipse und platziere dort meine Klassen, griffbereit für meine zukünftige Projekte.

Welche Tipps zu diesem Thema hättet ihr mir ?

Danke und Gruss

 

[Thallius]

Eigentlich weiß man doch in welchem Projekt man was geschrieben hat. Ich hole mir in solchen Fällen einfach die Klassen aus den alten Projekten.

 

[kneitzel]

Ich habe ein Projekt, in dem ich die entsprechenden Klassen mit den Tests habe und dann kopiere ich diese - so ich es benötige - da auch einfach raus.

Generell könnte man da aber auch die Library z.B. ins local Repository packen und dann einfach als Abhängigkeit einbinden. Das würde das kopieren vereinfachen und auch nicht diese Wust an doppeltem Code mit sich bringen. Ist ja auch klar: Aktualisierungen wandern dann nur manuell in die jeweiligen Projekte und damit hat man dann ggf. in diversen Projekten unterschiedliche Versionen. Was z.B. bei Fehlerbehebungen oder Erweiterungen recht blöd ist, weil dann ein Projekt noch auf ein Fehler läuft, den man doch eigentlich schon behoben hatte ...

Aber dafür muss ich nicht ganze Libraries einbinden mit Dingen, die ich nicht brauche, nur weil eine Klasse wichtig ist... (Das sind nur einzelne Klassen, die dann in der Regel interessant sind. Und Ausgangspunkt war ja nicht selten, dass ich eine Klasse geschrieben habe, weil ich wegen einer Funktionalität keine ganze Library einbinden wollte ... Bilder in der Größe anpassen wäre ein Beispiel. Für sowas gibt es tolle, Libraries, die extrem viel bieten - aber ich brauche doch nur eine kleine Funktionalität daraus ....)

Und damit ist das dann auch ein Spielgrund - in meiner C# / .Net Library habe ich auch Klassen, die ich nur mal aus Jux geschrieben habe (Balanced Search Tree und sowas in der Art) - Die Klassen würde ich nie verwenden, aber die sind halt mal als Demonstration entstanden.)

Auf das zentrale Projekt würde ich nicht verzichten wollen. So hat man dann einen klaren "Master", bei dem man die letzte Version finden kann,

 

[Thallius]

Generell könnte man da aber auch die Library z.B. ins local Repository packen und dann einfach als Abhängigkeit einbinden. Das würde das kopieren vereinfachen und auch nicht diese Wust an doppeltem Code mit sich bringen. Ist ja auch klar: Aktualisierungen wandern dann nur manuell in die jeweiligen Projekte und damit hat man dann ggf. in diversen Projekten unterschiedliche Versionen. Was z.B. bei Fehlerbehebungen oder Erweiterungen recht blöd ist, weil dann ein Projekt noch auf ein Fehler läuft, den man doch eigentlich schon behoben hatte ...

generell sind solche wiederverwendbaren Klassen aber doch recht einfache Sachen. Also zumindest bei mir habe ich keine “generell“ verwendbare Klassen die eine Größe haben als das sie Fehler enthalten würden. da halte ich es für gefährlicher diese zu zentralisieren und irgendwann mal auf die Idee zu kommen sie zu ändern und dabei vergisst, dass sie auf diese neue Art und Weise sie in einem Projekt von vor 10 Jahren nicht mehr funktionieren wird.

 

[Carcharoth]

Danke für eure Tipps.

 

[kneitzel]

da halte ich es für gefährlicher diese zu zentralisieren und irgendwann mal auf die Idee zu kommen sie zu ändern und dabei vergisst, dass sie auf diese neue Art und Weise sie in einem Projekt von vor 10 Jahren nicht mehr funktionieren wird.

Also die Gefahr sehe ich nicht, denn es geht ja nur um eine zentrale Stelle, die sozusagen eine Master-Kopie beinhaltet. Manuell kopieren musst Du die von dort immer noch.

Und wenn man es wirklich als Library aufzieht, dann hat man hoffentlich eine Versionierung. Dann ist also ein Update von 1.0 auf 1.1 oder so auch wieder ein manueller Akt.

Breaking Changes sind ansonsten immer zu dokumentieren. Daher kommen wir auch direkt auf das Thema Unit Tests (da hatten wir ja schon Diskussionen zu in der Vergangenheit): Die legen halt die erwartete Funktionalität fest. Wenn sich daran etwas ändert, dann ist es kritisch und das wird dokumentiert. Bei den Klassen, die ich kopiere, sind das dann kleine Anmerkungen im Kopf der Datei (Da fühlt man sich wie vor über 20 Jahren ... diese CVS Kommentare und so kommen mir da in den Sinn) ...

Aber das halte ich für existenziell - bei einer Library habe/hätte ich dann ja auch ein Release Dokument, in dem Änderungen vermerkt werden.

 

[temi]

Man könnte auch ein lokales Maven/Gradle Repository dafür hernehmen, dann kann man diese Bibliotheken mit Maven/Gradle importieren und dabei auch Versionen entsprechend berücksichtigen.

Ungefähr so, im Bibliotheksprojekt:

publishing {
    publications {
        mavenJava(MavenPublication) {
            from components.java
        }
    }

    repositories {
        maven {
            url 'file://home/java/.m2/'
        }
    }
}

Und dann im nutzenden Projekt:

repositories {
    mavenCentral()
    maven {
        url 'file://home/java/.m2/'
    }
}

 

[mrBrown]

Eigentlich weiß man doch in welchem Projekt man was geschrieben hat.

Ich weiß ja nicht mal, was für Projekte ich geschrieben hab. geschweige denn in welchem Projekt ich welchen Code geschrieben hab...

 

[Carcharoth]

Ich weiß ja nicht mal, was für Projekte ich geschrieben hab. geschweige denn in welchem Projekt ich welchen Code geschrieben hab...

Ja, das ist genau der Ursprung meiner Frage ;-)

 

[White_Fox]

Also...wenn ich eine Klasse (normalerweise sind es aber mehrere Klassen, die irgendwie zusammengehören) schreibe, die so allgemein und gut ist daß ich in Versuchung kommen könnte sie mal wieder zu verwenden, kommt sie erstmal in ein separates Package.

WENN ich sie dann wiederverwenden wollen würde, würde ich das Package in eine externe Bibliothek auslagern und diese in beide Projekte einbinden. Für die Bibliothek kann ich dann ein eigenes Repository aufmachen oder was mir sonst noch beliebt. Dank Unittests und Versionierung sollte da nicht allzuviel allzufürchterlich schiefgehen können, das Änderungen in der Bibliothek ältere Programme kompromittieren.
Andererseits profitieren auch ältere Programme möglicherweise, wenn die Bibliothek mal für ein anderes Programm verbessert wird.

Aber da ich ja kein Softie bin, betrifft mich das sowieso kaum.