WIXLIB

Principles of Software Construction:Objects, Design, and ConcurrencyVersion control with gitChristian Kästner Bogdan VasilescuSchool ofComputer Science15-214(Adapted from Christopher Parnin/NCSU & PremDevanbu/UC Davis & Kenneth Anderson/CU Boulder)1

Intro to JavaGit, CIGUIsUMLStatic AnalysisPerformanceConfig managementGUIsMore GitDesignPart 1:Design at a Class LevelPart 2:Designing (Sub)systemsDesign for Change:Information Hiding,Contracts, Design Patterns,Unit TestingUnderstanding the ProblemDesign for Reuse:Inheritance, Delegation,Immutability, LSP,Design PatternsResponsibility Assignment,Design Patterns,GUI vs Core,Design Case StudiesTesting SubsystemsPart 3:Designing ConcurrentSystemsConcurrency Primitives,SynchronizationDesigning Abstractions forConcurrencyDistributed Systems in aNutshellDesign for Reuse at Scale:Frameworks and APIs15-2142

Administrivia Homework 6 due tonight, 11:59 p.m. Final exam Thursday, 11 May, 1pm-4pm inGHC 4401 Review session in Wednesday, 10 May,6pm-9pm in GHC 440115-2143

The Modern World Which Version?How to recreate?How to fix?Where to apply the fix?How/when toRedistribute?15-2144

The Modern WorldVersionControl WorkflowsBuildManagersDeploymentManagers VMs ContainersPackageManagersApp Markets UpdateManagers15-2145

Components of ModernConfiguration ManagementVersion Control: Branches/Forks/WorkflowTask and Build managersBuild machines, virtual environments (dev stacks)Package managersContainers, VMs, in the CloudDeployment –Infrastructure as Code.Data migrationOther issues: orchestration, inventory, compliance15-2146

Task and Build ManagersAnalyze dependencies, and efficiently build(only) what needs to be built or rebuilt.Tools: make, ivy, ant, maven, gradle, 15-2147

Make dependency graph A makefile can be modeled as a dependency graph.The make algorithm performs a traversal over the graph.Each node is checked after all of its children, and the actionsare run if any child has a timestamp greater than its parent15-2148

Good things about make Available on pretty much every darn platform.Very fast.Fully featured programming language (but weird)First mover advantage15-2149

Bad things about make Weird syntax (indent is tab, NOT space) Has only global variables. Where shell can be used, and where make commands?Weird. No standards for anything. E.g.,: recursion, dependencyanalysis, file lists. No “reuse” or inheritance of makefiles. Not portable across OS, even across Unix flavors. Debugging? Yeah, good luck with that. Can’t guarantee consistency/reproducibility.15-21410

Ant15-21411

Ant vs makeMake file in XML.Replace weird indentations with weird angle brackets.Replace “variables” with property / Replace “targets” with target name “jar” / Replace “rules” with target name “jar”,depends “init, classes” / ” Replace “recipes in shell” with tasks.“ javac / ”,“ mkdir / ”,“ jar / ” 15-21412

Ant’s model Everything is a Task (sort of)– A task has an associated XML element in Ant buildfiles and an associated Java class that implements thetask.– The XML element can have various attributes and subelements, converted into parameters and passed tothe Java class.– Build file called build.xml by convention First task executed by invoking its associated Java class andpassing it its input parameters (if any). What’s the difference between tasks as shellcommands vs tasks as Java?15-21413

Ant Project Format build.xml 15-214Project NameProperty ValuesPathsTasksTargets14

Construction of Ant Build Files The default name for a Ant build file is build.xml The xml root element must be the ‘project’ element– The ‘default’ attribute of the project element is required andspecifies the default target to use Targets contain zero or more AntTasks– The ‘name’ attribute is required AntTasks are the smallest units of the build process15-21415

Ant Build File Example project default "hello" target name "hello" echo message "Hello, World"/ /target /project Executionof build file:15-214% antBuildfile: build.xmlhello: [echo] Hello, WorldBUILD SUCCESSFULTotal time: 2 seconds16

Ant Build File Example project default "hello" target name "hello" echo message "Hello, World"/ /target target name ”bye" echo message ”goodbye, World"/ /target /project 15-21417

Ant Properties property name "lib.dir" value "lib"/ From command lineIn build.xmlFrom external XMLFrom external property filesFrom environment15-21418

Ant Path, Ant Target/Task path id "classpath" fileset dir " {lib.dir}"includes "**/*.jar"/ /path target name "compile" mkdir dir " {classes.dir}"/ javac srcdir " {src.dir}"destdir " {classes.dir}"classpathref "classpath"/ /target 15-21419

Ant Target 15-214NameDescriptionDependenciesConditionals antcall task20

Ant Tasks Core Tasks Optional Tasks Custom Tasks15-21421

Dependencies15-21422

Version Compatibility? Tracking bug/securityfixes? Transitivedependencies? Consistency?15-21423

Imperfect techniques to managedependencies Placing all dependent projects (JAR files) in adirectory that's checked into the project'sversion-control repository. Allocating dependent JARs to a common fileserver Copying JAR files manually to a specific locationon each developer's workstation. Performing an HTTP Get to download files to adeveloper's workstation, either manually or aspart of the automated build.15-21424

Ivy15-21425

Defining dependencies in ivy.xml ?xml version "1.0" encoding "ISO-8859-1"? ?xml-stylesheet type "text/xsl" href "./config/ivy/ivydoc.xsl"? ivy-module version "1.0" info organisation "com" module "integratebutton" / dependencies dependency name "hsqldb" rev "1.8.0.7" / dependency name "pmd" rev "2.0" / dependency name "cobertura" rev "1.9"/ dependency name "checkstyle" rev "4.1" / dependency name "junitperf" rev "1.9.1" / dependency name "junit" rev "3.8.1" / /dependencies /ivy-module Note: no indication of file locations or URLs Convention: dependency name "cobertura"rev "1.9" translates to cobertura-1.9.jar15-21426

Specifying dependencies in Ivy Note: no indication of file locations or URLs Convention: dependency name "cobertura"rev "1.9" translates to cobertura-1.9.jar15-21427

Ivy settings file15-21428

Depending on dependencies15-21429

Useivy.xmlwithin anANTbuild.xml15-21430

Maven15-21431

Main Ideas of Maven “Convention over Configuration” DESCRIBE, don’t IMPLEMENT. Reuse build logic & standards whenever possible(mostly done as “Maven plugins”) Organize dependencies clearly, logically, aesthetically15-21432

Main Benefits of Maven Reuse across multiple projects on the same platform. Smaller, more standardized, reusable, build procedures. Spend less time on Build, more time Coding Apps15-21433

A simple Java app mvn archetype:generate -DgroupId edu.cmu.cs DartifactId hello -DarchetypeArtifactId mavenarchetype-quickstart -DinteractiveMode false– What’s in the directory structure? Mvn compile Run: java -cp target/classes edu.cmu.cs.App mvn clean Mvn test (see test results) Mvn package Java –cp target/*jar edu.cmu.cs.App15-21434

Gradle15-21435

Task-Based Managers: Gradle Combines the best of Ant and Maven From Ant keep: Portability: Build commands described platform-independently Flexibility: Describe almost any sequence of processing steps but drop: XML as build language, inability to express simple control flow From Maven keep: Dependency management Standard directory layouts & build conventions for common project types but drop: XML, inflexibility, inability to express simple control flow15-21436

Summary15-21437

What every build system must do: Manage dependencies within-project.Manage dependencies for outside libraries.Maintain consistency and versioning.Know tasks that ”complete” the dependencies.Deal with complex directory structures and many types of files.Be as simple as possible, but no simpler. How do each of the build systems we discussed do at all this?15-21438

Building a project should be repeatableand automated All but the smallest projects have a nontrivialbuild process You want to capture and automate theknowledge of how to build your system, ideally ina single command Build scripts are code (executable specifications)that need to be managed just like other pieces ofcode Use a build tool to script building, packaging,testing, and deploying your system– Most IDEs have an integrated build system15-21439

Versioning entire projects15-21440

Which files to manage All code and noncode files– Java code– Build scripts– Documentation Exclude generated files (.class, ) Most version control systems have amechanism to exclude files (e.g., .gitignore)15-21441

COLLABORATION15-21442

Collaborating on Files How to exchange files– Send changes by email– Manual synchronization at project meeting– All files on shared network directory Permission models– Each file has an owner; only person allowed to change it– Everybody may change all files (collective ownership)15-21443

Concurrent Modifications Allowing concurrent modifications ischallenging Conflicts (accidental overwriting) may occur Common strategies– Locking to change– Detecting conflicts (optimistic model)15-21444

Change Conflicts15-214source „Version Control with Subversion“45

Locking Files15-214Practical problems oflocking model?46

Locking Problems How to lock?– Central system vs announcement on mailing list– Forgetting to unlock common Unnecesary sequentializing– Cannot work on different concepts in same file False sense of security– Changing dependant files can cause conflicts notprevented by locking15-21447

Merging (1/2)15-21448

Merging (2/2)15-21449

Example15-21450

Example15-21451

Example15-214System cannot decide order52Einführung in dieSoftwaretechnik52

3-way merge File changed in two ways– Overlapping changes - conflicts– Merge combines non-conflicting changes from both Merging not always automatic– diff tool to show changes– Manual resolution of conflicts during merge (potentiallyrequires additional communication) Automatic merge potentially dangerous- syntactic notion of conflicts Merging of binary files difficult In practice: most merges are conflict free15-21453

BRANCHING15-21454

Branching Parallel copies of the source tree Can be changed independently, versionedseparately, and merged later (or left separate) Often used for exploratory changes or to isolatedevelopment activities Many usage patterns, common:– Main branch for maintenance OR main development– New branches for experimental features; merge whensuccessful– New branches for nontrivial maintenance work– Branches for maintenance of old versions15-21455

Release management with branches15-21456

Variants and Revisions Revision replaces prior revision (temporal)Variant coexists with other variantsVersion describes bothRelease: Published and named versionBase system (Windows)Linux variantV1.0V1.1V2.0V3.0XXXXXXXXXServer variantExtension for customer AXExtension for customer B15-214XX57

Semantic Versioning for Releases Given a version number MAJOR.MINOR.PATCH,increment the:– MAJOR version when you make incompatible APIchanges,– MINOR version when you add functionality in abackwards-compatible manner, and– PATCH version when you make backwards-compatiblebug fixes. Additional labels for pre-release and buildmetadata are available as extensions to theMAJOR.MINOR.PATCH format.http://semver.org/15-21458

Variants and Revisions[Staples&Hill, APSEC’04]15-21459

Managing variants Branching for variants does not scale well Requires special planning or tooling Many solutionsConfiguration filesOO polymorphismPreprocessorsBuild systemsDSLsSoftware productlines– ––––––15-21460

CENTRALIZED VERSION CONTROL(E.G., SVN)15-21461