In Person, Telefongespräch, Messenger

Email, Wiki, CMS, Mailingliste / Forum

Issue-Tracker (Bug tracker, Project tracker)

Linux: „Benevolent dictator governance model“

Apache: „Meritocratic governance model“

OPS4J (Open Participation for Java): „Open Contribution“

• Code quality checks (macht die IDE automatisch indem sie dinge markiert)

• Überprüfung von sourcecode

• Code generation (kann die IDE auch machen)

• Kompilierung (macht Maven und installiert dazu alle dependencies)

• Testausführung

• Daten Sammeln für Reports, Artefakten

• Packaging

• Deployment

• Dependency Management

• Versionierung

• Parallele Entwicklung mit Branches

• Kollaboration (locking oder merging)

Für parallele Projektentwicklung (auf mehreren Zweigen), Zugriff auf ältere Versionen

Eignen sich auch zur Verwaltung von Dokumenten, nicht nur sourcecode.

• Check-out (clone): Lokale Kopie von einer Version anlegen

• Check-in (commit): Änderungen seit dem letzten Update (changeset) in das Repository übernehmen mit commit message

• Tagging: Markieren eines bestimmten Zustandes

• Merging: Änderungen aus einem Branch in einen anderen übernehmen

• Branching: eigener Strang

• Pull: Requesting main branch to pull your commit

• Push: Pushing your commit onto your branch

Server speichert Versionen → Bottleneck

Beispiele: concurrent version system CVS, Subversion SVN

Ablauf auf SVN:

Lokale Operationen, offline Arbeiten möglich

Projektmanager mit main-repository

Jede Komponente in eigener repository (Anzahl der Repos hat vor und nachteile)

Beispiele: git, mercurial, bitkeeper

Ablauf auf Git:

manche Branching-Modelle erzwingen Code Reviews

• Erstellung von Pull-Requests, Merge nach Review

  Vorteil: Qualitätssichernde Maßnahme, Wissenstransfer

Compiled code aber hat viele Zusatzfeature

• dependency management (auch transitive Abhängigkeiten, Versions-Konflikte)

• deployment

• dokumentationen aus javadoc erstellen + code quality reports

• testen - reporting

• reporten

• ...

Ähnlich wie Maven

Convention over configuration → Man hält sich an Konventionen und muss dafür nichts mehr konfigurieren außer Dinge in der pom.xml Datei (project object model).

legt Bibliotheken aller Projekte in einem zentralen Verzeichnis ab.

$\cdot$ Archetypen zum schnellen Einstellen

Automatisiertes: Builden, Testen, Integration, Deployment

• nur ein einziges Sourcecode-Repository verfügen, mit dem alle Entwickler arbeiten.

• Ablauf möglichst schnell

• Mindestens 1x täglich committen auf neutralem Rechner → "daily builds"

  „neutraler“ CI-Server automatisiert Build und Tests bei jeder Änderung im SCM-System

  Build-Automatisierungswerkzeuge:

  Entwicklerorientiert: Maven

  Server-basierte Integration: Apache Continuum, Hudson, OpenCIT

  CI Server mit: Apache Continuum oder Hudso

• Danach Berichte erstellen und verschicken

1. Entwickler erstellt neue Version im SCM (Commit, Pull-Request...).

2. CI Werkzeug reagiert auf dieses Ereignis, lädt die entsprechende Version.

3. Build Tool wird gestartet, compilierter Code wird mit einem Test-System automatisiert getestet.

4. Entwickler wird mit Bericht verständigt.

Build means to compile the project.

Deploy means to:

1. Compile the project

2. Publish the output, meaning copy it to a target directory, upload it to an FTP server etc

1. Continuous Integration
   • Build
   • Test
   • Merge

2. Continuous Delivery
   • Automatisierter Release in ein Repository
   • Deployment nach manueller Freigabe

3. Continuous Deployment
   • Automatisches Deployment in einer Produktivumgebung

Eine Gruppe an Objekten die einer bestimmten Funktion gewidmet sind.

Komponente die über ein Netzwerk angeboten wird

Rahmenbedingungen für Komponenten (Persistenz-Framework)

komplexer, mehr "overhead"

weniger die Kopplung, bessere Widerverwendbarkeit

Viele Varianten.

Hollywood Prinzip: "Dont call us, well call you"

Java

.NET

public class MyPersistence {
private MyBusinessLogic businessLogic = new MyBusinessLogic();
}
public class MyPresentation {
private MyBusinessLogic businessLogic = new MyBusinessLogic ();
}
public class MyBusinessLogic {
private MyPersistence persiistence = new MyPersistence ("path/to/db");
private MyPresentation presentation = new MyPresentation (300, 200);
}

public static void main (String[] args){
IPersistence persistence = new MyPersistence ( "path/to/db");
IPresentation presentation = new MyP resentation (300, 200);
IBusinessLogic businessLogic = new MyBusinessLogic (persistence, presentation);
persistence.setBusinessLogic(businessLogic);
presentation.setBusinessLogic(businessLogic);

Die Verantwortung für das Erzeugen und Initialisieren von Objekten wird an eine zentrale Stelle (z.B. eine Klasse) delegiert.

Von der zentralen Stelle kann man die Abhängigkeiten zwischen den Objekten leichter überblicken und steuern.

Eine Komponente wird über einem Pointer / einer Referenz aufgerufen die urprünglich nicht initialisiert ist.

Kann mit Konstruktor, Setter, Annotation initialisiert werden.

• Hohe Wiederverwendbarkeit

• Einfaches Austauschen einer Implementierung

• Verwalten von verschiedenen Konfigurationen (dev vs. prod)

• Automatisiertes „verdrahten“, weniger Boilerplate-Code benötigt.

• Verteilung von Aufgaben

Abhängigkeiten durch "setter"-Methode gesetzt oder Annotationen

public static void main(String[] args) {
Factory factory = Factory.create();IPersistence myPersistence = (IPersistence) factory.getComp("persistence");
IPresentation myPresentation = (IPresentation) factory.getComp("presentation");
MyBusinessLogic myBusinessLogic = new MyBusinessLogic(myPersistence, myPresentation);
myPersistence.setBusinessLogic(myBusinessLogic);
myPresentation.set BusinessLogic(myBusinessLogic);
}

Bzw.

public static void main(String [] args) {
Resource res = new FileSystemResource("beans.xml");
XmlBeanFactory factory = new XmlBeanFactory(res);
IPresentation ui = factory.getBean("presentation", IPresentation.class);
ui.show();
}

• Konfigurationsdatei (In Spring boot: beans = komponenten)

  <? xml version="1.0" encoding="UTF-8"?>
  <beans><bean class="MyPersistence" id="persistence">
  <property name="path">path/to/db</property>
  <property name="businessLogic" ref="businessLogic" />
  </bean><bean class="MyPresentation " id="presentation ">
  <property name="width ">300</property>
  <property name="height">200</property>
  <property name="businessLogic" ref="businessLogic" />
  </bean><bean class="MyBusinessLogic" id="businessLogic">
  <property name="persistence" ref="persistence" />
  <property name="presentation" ref="presentation" />
  </bean></beans>

  Bzw. mit Java Code

  @Configuration
  public class AppConfig {
  @Bean
  public IPersistence persistence () {
  MyPersistence myPersistence = new MyPersistence("path/to/db") ;
  myPersistence. setBusinessLogic(businessLogic());
  return myPersistence;
  }@Bean
  public IPresentation presentation () {
  MyPresentation myPresentation = new MyPresentation (300, 200);
  myPresentation.setBusinessLogic(businessLogic());
  return myPresentation;
  }@Bean
  public IBusinessLogic businessLogic() {
  return new MyBusinessLogic (persistence(), presentation());
  }
  }

Abhängigkeiten über Konstruktor definieren → Problematisch, gleiche Signatur

public class TestBean{
String id;
String internalLocation ;
String externalLocation;
public TestBean (String id, String internalLocation) {
this.id = id;
this.internalLocation = String internalLocation;
}
public TestBean (String id, String externalLocation) { -> gleiche Methoden-Signatur
this.id = id;
this.externalLocation = externalLocation;
}
}

Generelle Projektinformationen

Source Code (javadoc)

Code Quality Reports

Dokumente