Introduction to Software Engineering: Tools and Environments

1. Introduction to Software Engineering: Tools and Environments Session 8 Oded Lachish Room: Mal 405 Visiting Hours: Wednesday 17:00 to 20:00 Email: oded@dcs.bbk.ac.uk Module URL: http://www.dcs.bbk.ac.uk/~oded/Tools2012-2013/Web/Tools2012-2013.html

2. Last time Tools for bug management After Git this is the second time that we focused on tools that are group specific This time Build tools Can be developer specific but their main importance is in a larger context – integration and the rest.

3. Managing a Project’s Build Build Tools

4. Building a Project The task of creating something useful (executable) from the text you call code

5. Building a Project • In the beginning, before GUI, we had command line. • There was a time when compilation and linking was done with just command line. • But then projects became more and more complex • Large directory structure • Many files and file dependencies • Vast variety of precompiled libraries • The command line was not sufficient anymore

6. Build Tools and their Scripting Languages A naive solution to the build complexity problem Write a program for building A proper solution Build a tool with its own scripting language Why? A dedicated (and hopefully simple) language for building improves the efficiency of the automation of the build process

7. But why isn’t Building Easy Question: Why can’t we just tell the compiler where to find all the files and libraries? Answer: A combination of a large number of files and dependencies That was already mentioned, what does it mean? To answer this question we need to know a bit more about the Java complier options

8. The Java Compiler “javac.exe” What does it do? One of the answers: It reads “.java” files (java language) and translates them to “.class” files (java class files containing platform neutral Java bytecode(the language of the java virtual machine (JVM))) But in skilful hands it can do much more! Remark: There are compilers that translate to other languages.

9. Examining the Java Compiler • There are many manners in which javac can be controlled. • Options given as they would be in command line. • “-d directory” - destination directory for class files. Must exist because javac will not create it. • “-g Generate” – generate all debugging information, including local variables. • “-g:none Generate” – do not generate any debugging information • “-nowarn Disable” - do not generate warning messages. • “-verbose” - print information such as each class loaded and each source file compiled.

10. Examining the Java Compiler • “-classpath path” - Specify where to find user class files • “-sourcepathsourcepath” – location of source code (path to search) for class or interface definitions • Example: • javac -sourcepathsrc -classpath lib\*.jar \ src\Operations\adder.java -d bin

11. Anything more? Of course but more of the same flavour. Q: So why is there any problem? A: For a reasonable answer we need to understand what the compiler does. When compiling a source file, the compiler may require information about a types whose definition did not appear in the source files given on the command line. When that occurs the compiler searches first for class files! (why?)

12. Again? Q: So why is there any problem? A: The problem is not in what there is but in what’s missing! Imagine the project is very big, hundreds to thousands of files. Now you’ve just changed one little class. You definitely do not want to compile the whole project again! Q: So why don’t you tell the compiler to compile only that class?

13. Two Classes and Dependencies • Imagine we changed two classes one a super-class of the other. • Now the subclass depends on the super class. • So we should tell the compiler to recompile the super-class before the sub-class otherwise the subclass will be recompiled with an old version of the super-class • (since we are recompiling we probably told the compiler where the old class files are and that includes the previous version of the super-class) • How do we get the compiler to actually take this into account?

14. Dependencies Dependencies such as described in the previous slides might actually exist between previously compiled classes and even just the one class that we changed! Things just got complicated. When changing one class we want to recompile only what we have to! This is one of the reasons why we need build tools!

15. More Reasons for Using Build Tools • Portability - the build process should not depend on the IDE (which did the job for us until now) the same code may give different compilation results on different IDE’s. • Automation (as usual) • Build tools can do much more than orchestrating the compilation. For example, they can be used to execute tests, for actual deployment and many other things. • They may also look for the proper libraries

16. Back to dependencies Can you guess what can be done to overcome this problem?

17. Ant and Maven • Open source tools for building a project and sometime a lot more. • Both abstract away the dependencies issue • Both are available as plug-ins for eclipse • Both tools use XML for configuring • Maven and Ant differ significantly in their approach

18. XML

19. What is XML? • The eXtensibleMarkup Language (XML) defines ageneric syntax used to mark up data with simple, human-readable tags • Has been standardized by the World Wide Web • Is flexible enough to be customized for domains as diverse as: • Web sites • Electronic data interchange • Vector graphics

20. What is XML? • Data in XML documents is represented as strings of text • This data is surrounded by text markup that describes the data (<person> Alan Turing </person>) • A particular unit of data and markup is called an element • XML specifies the exact syntax of how elements are delimited by tags, what a tag looks like, what names are acceptable, and so on

21. Elements, Tags, and Data • A very simple, yet complete, XML document: • <person> • Alan Turing • </person> • Composed of a single element whose type is person • Element is delimited by the start tag <person> and the end tag </person> • Everything between the start tag and end tag (exclusive) is the element’s content

22. Elements, Tags, and Data(2) • Content of the above element is the text string “Alan Turing” • Whitespace is part to the content (although many applications choose to ignore it) • <person> and </person> are markup, • The string Alan Turing and surrounding whitespace are character data

23. Entity References • Character data inside an element may not contain a raw • unescaped opening angle bracket < • If this character is needed in the text, it has to be escaped by using the &lt; entity reference • XML predefines five entity references:

24. XML Documents and Trees XML documents can be represented as trees <person> <name> <first_name>Alan</first_name> <last_name>Turing</last_name> </name> <profession> computer scientist </profession> <profession> mathematician </profession> </person>

25. Attributes • XML elements can have attributes • An attribute is name-value pair attached to an element’s start tag • Names are separated from values by an equals sign • Values are enclosed in single or double quotation marks • Example: • <person born=’1912/06/23’ died=’1954/06/07’> • Alan Turing • </person>

26. Comments • XML documents can also be commented • Similar to HTML comments, they begin with <!– and end with --> • Comments may appear • anywhere in character data • before or after the root element • However, NOT inside a tag or another comment • XML parsers may or may not pass along information found in comments

27. XML Declaration • The XML declaration looks like a processing instruction, but only gives some information about the document: • <?xml version=’1.0’ • encoding=’US-ASCIII’ • standalone=’yes’?> • version: at the moment 1.0 and 1.1 are available • encoding: defines the character set used (e.g. ASCII, Latin-1, Unicode) • standalone: determines if some other file (e.g. DTD) has to be read to determine proper values for parts of the document

28. Ant

29. Ant build.xml structure <?xml version="1.0"?> <project name="StateMachine" default="DTarget"> <target name="BTarget"> <echo>BTarget</echo> </target> <target name="DTarget" depends="BTarget"> <echo>BTarget</echo> </target> </project> • <project ...>, </project> - • project begin and end tags • <target ...>, </target> - • target begin and end tags • <echo>, </echo> • Ant task of printing to console

30. Ant Terminology • Ant Task – a command that Ant can execute such as compile and echo • Ant Target – an ordered series of Ant tasks – we shall see that they can depend on other named targets • Ant Project – a collection of targets that are executed according to the time stampsof the files

31. Creating the build.xml file The build.xml file needs to be in the project directory. (It also needs to be committed)

32. File name should “build.xml”

33. After build.xml file added

34. Simple example build.xml

35. How to get Ant to Run

36. Console after run Nice but we want to do more

37. Depends: Ant build.xml structure <?xml version="1.0"?> <project name="StateMachine" default="DTarget"> <target name="BTarget"> <echo>BTarget</echo> </target> <target name="DTarget" depends="BTarget"> <echo>BTarget</echo> </target> </project> depends="Btarget” is used to tell Ant that target Dtarget depends on target BTarget

38. Depends: Circular Dependency <?xml version="1.0"?> <project name="StateMachine" default=“three"> <target name="one" depends=“three” > <echo>Running One</echo> </target> <target name="two" depends="one"> <echo>Running Two</echo> </target> <target name="three" depends=“one"> <echo>Running Three</echo> </target> </project> Circular dependency

39. Depends: Circular Dependency. NO NONO NO NONO at the editing stage Lets execute to see what happens

40. Execution: Circular Dependency. Now Ant is shouting that it detected a cycle and it even explicitly describes the culprit

41. Standard Naming Convention • It is recommended to adopt a standard naming convention and stick to it. • Targets: • init – create temporary directories in the build folder • clean – remove any compiled and intermediate files should be run before creating a zip file • build – compile source files • Install – copy files to a testing system • Folders: • src – location of source code • build – the output of the build process

42. Actually Building with ANT • <project name="HE" default="compile"> • <target name="alive"> • <echo> Did something </echo> • </target> • <target name="clean"> • <delete dir="build"/> • </target> • <target name="compile" depends="alive"> • <mkdir dir="build/classes"/> • <javacsrcdir="src" destdir="build/classes“ includeantruntime="false"/> • </target> • </project>

43. Build Result

44. Build again Result Surprise nothing was compiled

45. Changed Just One File Surprise one file was compiled

46. How Does Ant Know What to Recompile? Ant checks the timestamps of files to determine whether they’ve changed or not, and only compiles files that have changed, thus reducing build times, often drastically on large projects.

47. Ant Properties “properties” are constructs Ant uses “like variables” Example: <project name="StateMachine" default= "ATarget"> <!-- set global properties --> <property name="SrcDir" value="src"/> <property name="BuildDir" value="build"/> <target name= "ATarget"> <echo message = "Source directory is = ${SrcDir}"/> <echo message = "Build directory is ${BuildDir}"/> </target> </project>

48. Results of example Execution

49. Ant with Properties <?xml version="1.0"?> <project name="HE" default="run" basedir="."> <property name="source.dir" value="src"/> <property name="build.dir" value="build"/> <property name="classes.dir" value="${build.dir}/classes"/> <property name="jar.dir" value="${build.dir}/jar"/> <property name="main-class" value="Pk.First"/> <target name="clean"> <delete dir="${build.dir}"/> </target> <target name="compile"> <mkdir dir="${classes.dir}"/> <javacsrcdir="${source.dir}" destdir="${classes.dir}" includeantruntime="false"/> </target> <target name="jar" depends="compile"> <mkdir dir="${jar.dir}"/> <jar destfile="${jar.dir}/${ant.project.name}.jar" basedir="${classes.dir}"> <manifest> <attribute name="Main-Class" value="${main-class}"/> </manifest> </jar> </target> <target name="run" depends="jar"> <java jar="${jar.dir}/${ant.project.name}.jar" fork="true"/> </target> </project> This compiles, converts to JAR and then runs

50. First and Second run