1. Archetype
1.1. für freenet-Projekte
1.2. für OMS-Projekte
1.3. für Tapestry-Projekte
1.4. Vererbung
2. Parent-POM
2.1. Definition der Profile
2.2. allg. Dependencies
2.3. Def. von Versionsnummern
2.4. allg. Plugin-Einstellungen
2.5. allg. Extensions
3. Versionierung
3.1. Versionsnummer von Branches
3.1.1. muss sich in Branches unterscheiden
3.2. major.minor.patch
3.2.1. Definition von http://docs.codehaus.org/display/GEOT/5.+9+Versioning
3.2.1.1. major
3.2.1.1.1. is incremented to indicate that a module has lost full compatibility to earlier versions. So you can safely upgrade to later versions of a module so long as the major version has not changed.
3.2.1.2. minor
3.2.1.2.1. is incremented whenever new features are added. Modules are forward compatible across minor versions, but usually not backward compatible
3.2.1.3. patch
3.2.1.3.1. is for bug fixes. It is used to indicate fixes in bugs only. No new features were made and full compatibility is preserved.
4. Release-Management
5. Verwendung von Snapshots
6. Continuum
7. Profile
7.1. nach Axis
7.1.1. Axis 1.1
7.1.2. Axis 1.3
7.1.3. Axis 2 ?
8. Assemblies
8.1. Meta-Projekte
8.1.1. WorkflowProcessor
8.1.2. Tomcat-Umgebung
9. Probleme bei der täglichen Arbeit
9.1. Herstellung einer Entwicklungsumgebung
9.1.1. viele voneinander abhängige Projekte
9.1.2. manchmal ist Update in abhängigen Projekten notwendig, damit eigenes Projekt übersetzt
9.2. Bereitstellung von Testversionen
9.3. fehlende Abhängigkeiten beim Deployment
9.4. Bugfixes für Production Release
9.4.1. geht mit Release-Tags im Subversion
9.5. Bereitstellung von Features für Test/Produktionsumgebungen
9.5.1. Features werden separat getestet und müssen dann auch separat live genommen werden können
9.5.1.1. pro Feature ein Branch
9.5.1.1.1. Merge-Stress
10. Branches
10.1. Flying Fish
10.2. svnmerge
11. Entwicklung-Cycle
11.1. neues Feature implementieren
11.2. Unit-Test
11.2.1. danach Bugfixing
11.3. Integrationstest
11.3.1. muss unabhängig von anderen neuen Features sein
11.3.2. danach Bugfixing
11.4. Live-Stellung
11.4.1. danach Bugfixing
12. Vorschlag Entwicklungs-Cycle
12.1. Entwicklung eines neuen Features auf Branch
12.1.1. Maven-Versionsnummer enthält Branch?
12.1.2. regelmäßiger Merge von Trunk
12.2. Bereitstellung eines Snapshot-Release für Integrationstest
12.3. Nach Freigabe durch QS Merge in Trunk, Branch schließen, Release erstellen (minor++,patch=0)
12.4. Live-Stellung mit Production-Release
12.5. Bugfixing von Production-Release
12.5.1. auf Release-Branch entwickeln
12.5.1.1. ändern auf SNAPSHOT
12.5.2. Snapshot-Release für Integrationstest bereitstellen
12.5.3. nach Freigabe durch QS Release erstellen (patch++)