Automating the Build Process with Maven and Gradle

The previous session covered version control with Git and GitHub — how the two are related and why a version control system exists at all. Once you have version control in place, the next thing to think about is automating the build process. We write source code to build it and generate an artifact out of it — an exe file, a PDF, anything that lets you get your artifact out of your application. So the sequence is: write the source code, then the next phase is to build it. This session is about automating that build process by assembling software components with the help of build tools, and as per the syllabus the tools in focus are Maven and Gradle.

Think of the whole journey like a production line: version control is the raw-material warehouse (the previous session), and this session is about the assembly line that turns those raw materials into a finished, shippable product. Before any machine can assemble parts automatically, the parts themselves have to be designed and organized — which is exactly why this session starts with component-based design, then moves through dependencies, pipelines, and finally the two build tools (Maven and Gradle) that automate the assembly itself.

8.1 Component-Based Design: Why and How

8.1.1 What a Component Is and How It Gets Packaged

Whenever you have a large code structure within an application, those code structures are referred to as modules. A component is nothing but a module, and by putting multiple modules together you get your large-scale application.

A component is a large-scale code structure inside an application that has a well-defined interface (an API) and exposes behavior through limited, well-defined interactions with other components. In plain terms: each component does one coherent job — say, "handle payments" — and other parts of the application talk to it only through its API, never by reaching into its internals. "Component" is a heavily overloaded word in software; the textbook uses the terms "module" and "component" as synonyms, and clarifies that the idea has nothing to do with GUI widgets — it is about how you organize code, not which framework you use.

The packaging of a component depends on the platform. Real-world: on Windows a component is normally packaged as a DLL library; on Unix it is referred to as a .so (shared object) file; in the Java world it starts being referred to as a jar — a JAR file. These are all just ways of saying the same thing: components are the modules of your application. The names differ because each platform has its own standard mechanism for bundling compiled code so other programs can load it: Windows dynamic-link libraries (DLLs), Unix shared libraries (.so files), and Java Archives (JARs).

Component-based design helps you arrange this large-scale code structure in a modular way so that the code is easy to understand, and whenever you want, you can easily make changes. That modular arrangement is the foundation everything else in this session builds on. Notice the contrast with the monolithic system — its antithesis — which has no clear boundaries between elements responsible for different tasks, poor encapsulation, and tight coupling between logically independent parts. The textbook's formal definition of a component adds four properties most people agree on: a component is reusable, replaceable with something else implementing the same API, independently deployable, and encapsulates a coherent set of behaviors and responsibilities.

8.1.2 Benefits of Component-Based Design

The benefits the design brings are threefold.

1. Reuse of code. A component is written once and reused wherever its service is needed — the login component serves the web app, the mobile app, and the admin panel without being rewritten.
2. A good architectural diagram — loose coupling. Components talk only through well-defined interfaces, so the architecture ends up loosely coupled: changing the inside of one component does not ripple through the others. This loosely coupled structure is the pilot point, the initial point, for microservice architecture — microservices are, in essence, components that are deployed and scaled independently, often as separate running services.
3. Efficient large-team collaboration. This is the textbook's key practical point: componentization is one of the most efficient ways for a large team of developers to collaborate on one application. Each team can understand and own one part of the codebase, and a change to one component does not force everyone else to re-understand the whole system.

8.1.3 The Challenge: Components Form Dependencies

When you decompose your application into components — and decomposing is the biggest job — those several components ideally form a series of dependencies among themselves. Take the example used throughout the session: a web application called e-grocery (a grocery delivery app). For the login page of that application you need four modules: one for the login service, one for the payment gateway, one for search, and one for adding and retrieving the grocery items — grocery item management. These four modules definitely form a series of dependencies.

Each component may also have several release branches. Why would a component have several release branches? If you chose a payment gateway that currently supports delivery or net banking, and you now want to add UPI payments and credit cards, the payment gateway module will be frequently changed — and in this example the payment gateway goes through several release branches. Even the login and sign-up module changes: you might want to add one extra field, say flat address, local address, and permanent address, so you can start delivering items to the permanent address too — to capture the data of whether a customer is really from the city where the service operates or has another home where you can start advertising. That is part of the business. In that case as well the module will be changed. So whenever code changes in one module, that component will have different release branches.

8.1.4 The Release-Delay Problem

The biggest challenge with component-based design is delay in release. The very first problem is finding the good version of each of these components. Components go through several changes, so several artifacts come out of them; if you do it manually it becomes tedious, and assembling them into a system that even compiles is an extremely difficult process. Done manually, that is the challenging part. To overcome it, you need to follow the best practices and try to automate these steps.

The textbook describes the situation vividly: components form a series of dependencies, which in turn depend on external libraries, and each component may have several release branches. Finding good versions of each component that can be assembled into a system which even compiles is an extremely difficult process that can resemble a game of whack-a-mole — the authors report projects where it takes months. Only once you have done this can you start moving the system through the deployment pipeline. This is, in essence, the fundamental problem that continuous integration aims to solve.

8.1.5 Three Approaches to Keep the Application Releasable

How can one keep an application always in a releasable state? There are three approaches.

Approach 1 — Hide new functionality until it is finished. This is the feature toggling approach: you can toggle between features. Until the functionality is finished, even if the code is residing in the production environment, make that functionality hidden — the toggling flag variable for that particular functionality should be false. If the flag is false, do not access this code. This is done at the code level. The textbook's example: a travel website wants to offer hotel bookings; the new feature is deployed along with the rest of the system, but its entry point is inaccessible — access is blocked by a configuration setting. When the feature is ready, the flag flips to true and the code path opens without a big-bang release.

Approach 2 — Make changes incrementally as a series of small, releasable changes. This looks like a solution, but breaking a module into a small, small series of changes is again a difficult task. You cannot say that you will just implement a login button without the password — you need to be ready with login and password together. Sometimes, through logical or business requirements, it is not feasible to break a module into smaller chunks. So this is one possible solution, only when it is possible. The textbook adds that the analysis behind this approach is the same thought process used to break a requirement into smaller tasks — and when a change genuinely cannot be made incrementally, you should consider branch by abstraction.

Approach 3 — Branch by abstraction. Create a branch for that particular change and do not merge that branch until and unless the code is completed — the functionality is fully completed. This makes sure the application is always in a releasable state because you have not touched the main baseline, which is bug free or defect free. A perfect version, a perfect artifact, remains available. In the textbook's more precise description, you do not actually branch in version control: you create an abstraction layer over the piece to be changed, develop the new implementation in parallel, switch the abstraction to delegate to the new implementation when it is complete, then remove the old implementation and the abstraction layer. Either reading, the core idea is the same: the main baseline is never broken, so the application stays releasable.

So the three approaches are: hide the functionality at the code level; break the change down into smaller chunks; or use branch by abstraction — create a branch and do not merge it until the code is ready.

Real-world & domain. Every platform you use daily is component-based. An Android app ships as one APK containing many components; Windows system updates swap DLLs between applications; a microservice estate like Netflix or Amazon decomposes an e-commerce system into login, cart, payment, and search services that change at different rates. In e-commerce specifically, the e-grocery chains from this section are the everyday reality: payment providers (Stripe, Razorpay, UPI gateways) release new payment methods on their own cadence, and the merchant's payment component must track those releases — one reason component dependency management is the foundation of modern release engineering.

8.2 Managing Application Dependencies

8.2.1 What a Dependency Is

Before talking about library-based and component-based dependencies, it helps to define the thing itself. A dependency occurs when one piece of software depends upon another in order to build or run. We say the particular component is dependent on some library or on some other component. Examples are everywhere: every software application depends on the host operating system environment; a Java application depends on the JVM; if you want to start working with Rails you need Ruby and the Rails framework; a C application depends on the C standard libraries. The textbook gives the same catalogue: Java applications depend on the JVM which provides the Java SE API, .NET applications depend on the CLR, Rails applications on Ruby and the Rails framework, C applications on the C standard library, and so forth. In any application beyond the most trivial, there will be some dependencies.

Dependencies can be categorized broadly in two ways: by what you depend on (libraries versus components), and by when the dependency matters (build time versus runtime). Both distinctions are needed because each one changes what a build process has to do.

8.2.2 Library Dependency versus Component Dependency

A library is a software package that your team does not control other than choosing which one to use. The packages themselves are not under your team's control — your only control is opting for a particular one: you choose which libraries you need, like JRE 7 or JRE 8, or a React framework. Libraries are usually updated rarely — there are no frequent changes in libraries.

A component, by contrast, is a piece of software that your application depends upon, but which is also developed by your team or by another team in your organization. Because it is being developed inside the organization, there will be frequent changes. In the grocery application, the cart module — grocery item arrangement, retrieve, delete, add, and managing the cart — is depended upon by the payment gateway; that cart module is a component. Both components are developed within the team, so there will be several branches and frequent changes to these modules.

This distinction is really important because when you design a build process, there are more things to consider when dealing with components than with libraries. Managing library dependencies is the easier case; component dependency management is the harder one — that is why the two must be kept clear. The build-process questions that components force you to answer — do you compile the entire application in a single step, or compile each component independently when it changes? How do you manage dependencies between components and avoid circular ones? — simply do not arise for libraries.

8.2.3 Build-Time and Runtime Dependencies

A build-time dependency must be present when your application is compiled and linked, if necessary. A runtime dependency must be present when the application runs and performs its usual function. A simple example: a Maven-based project depends on the Tomcat server. At the time you run that application, you have to make sure the Tomcat server instance is up and running — that running Tomcat server is a runtime dependency for the application. In C and C++, the build-time dependencies are simply your header files, while at runtime your program requires a binary to be present in the form of a DLL or shared library, on Windows or Linux respectively.

The textbook underlines two practical consequences of this distinction. First, your deployment pipeline itself uses many pieces of software that are irrelevant to the deployed copy of the application — unit test frameworks, acceptance test frameworks, build scripting frameworks. Those are build-time concerns only. Second, the versions of libraries used at build time can differ from those used at runtime: in compiled languages you can build against a JAR containing just the interfaces of a system and run against a JAR with a full implementation (the J2EE application server pattern). Your build system must take both kinds of dependencies into account.

8.2.4 The Dependency Hell Problem

Managing these different dependencies can be difficult — this is the classic dependency hell problem, also called DLL hell, which used to happen very frequently before version control systems existed. In the old days, when you ran the software you got an artifact; those libraries used to be stored somewhere in a shared folder so other modules dependent on that DLL or library could access them. Sometimes at runtime the application used to pick up randomly — you can provide the path from where to access, but due to some issues at runtime the software used to pick a wrong DLL or wrong library during runtime, compatibility issues happened, and you had to figure out why the application was not running. Since there was no version control system, artifacts were just copy-pasted into the folder, and with multiple artifacts in the folder the application used to randomly pick any one of them — the compatibility issues appeared more and more often. That is the dependency problem when it comes to libraries: your application picking up incorrect libraries or an incorrect artifact from a folder.

The textbook's precise definition: dependency hell occurs when an application depends upon one particular version of something, but is deployed with a different version, or with nothing at all. In early Windows, all DLLs lived unversioned in a system directory (windows\system32), and new versions simply overwrote old ones; in versions before Windows XP the COM class table was a singleton, so an application that needed a particular COM object was handed whichever version had been loaded first. It was impossible for different applications to depend on different versions of a DLL — or even to know which version they would get at runtime. The .NET framework resolved this with signed, versioned assemblies stored in a global assembly cache (the GAC) that distinguishes versions even with identical filenames; Linux used a naming convention appending integers to .so files in /usr/lib with soft links for the canonical system-wide version.

Real-world: DLL hell is a famous Windows development failure mode — the exact scenario of an application grabbing the wrong DLL from a shared directory.

8.2.5 Managing Libraries: Version Control and a lib Directory

The best way to manage libraries is to keep them in a version control system rather than just copying them somewhere. For example, you were on JRE 7, now there are changes and you want JRE 8 — such libraries rarely change, and that is fine. But if your application is dependent on a third-party vendor tool, or you have your own libraries that you want to use, those libraries can change. That library should also live in a version control system, and you should pick it from that version control system.

The simplest solution — and it works fine for any small project — is to create a lib directory under your code structure. You create a src folder that holds your source code files and test cases; at the same time you create one more folder, the lib folder, in which you can keep all build, runtime, and test-time dependency libraries. It is just a simple structure. Then give the libraries a naming convention that includes their version number, so you know exactly which version you are using. Say you use some third-party tool XYZ: name it XYZ 1.0; when it has been changed and you are using XYZ 1.2, update it with the 1.2 name — now you know in your folder which one is the correct one and which is actually getting used. (The textbook suggests refining the lib folder into three subdirectories — build, test, and run — mirroring the build-time, test-time, and runtime split of Section 8.2.3, and gives the same naming rule: check in nunit-2.5.5.dll, never just nunit.dll.)

The benefits: everything you need to build your application is in the version control system. Once you have a local checkout of your project repository, you can repeatedly build the same package that everyone else is building, because that folder you created gets copied onto your GitHub repository through the version control system. If you are a new member of the team, you just clone that repository to your local machine, and whatever the other team members are doing can be done on your side too, because you have copied the libraries as well — there would not be any compatibility issue. This is the textbook's repeatable builds constraint: if I check out the project and run the automated build, I get exactly the same binaries everyone else does — and the same binaries three months from now when I debug a problem reported by a user on an old version.

The problems: as your checked-in library repository grows with the implementation of a large-scale application, it becomes very difficult to figure out manually which of these libraries are being used in your application. And if your project must run with other projects on the same platform, manually managing transitive dependencies across projects repeatedly becomes painful. A transitive dependency is a dependency of a dependency: you use library X, and X itself needs library Y — so Y is transitively required by your application. With several projects on one platform, manually keeping track of "which Y version does each X need" across projects rapidly becomes painful. Even with version control and a lib folder, you are still maintaining those libraries manually — that is the difficult task.

8.2.6 Automating Dependency Management with Build Tools

The ultimate solution is to automate. Declare the libraries and use a tool like Maven, Ivy, or Gradle, depending on what technology and language your application uses. Declare those libraries in the form of a script and let the Maven or Gradle tool use it. You can either provide for the tool to download the libraries from internet repositories, or — and organizations generally prefer this — keep your own artifact repository, in which you manage your libraries, binaries, everything. In the script you write which particular library has to be picked from which repository. Instead of doing it manually, you are now writing it in code and using the build process tool. That settles the library side of dependency management.

The textbook adds two details worth knowing. First, these tools resolve dependencies transitively: Maven or Ivy will download the libraries you declare, work out what those libraries themselves need, and check the resulting dependency graph for inconsistencies — the classic one being two components requiring mutually incompatible versions of a common library. Second, the tools cache what they download on your local machine, so the first build on a new machine is slow but later builds are fast — and they prefer your organization's own artifact repository (open source options include Artifactory and Nexus) over the public internet, because an internal repository is what keeps builds repeatable and auditable (it also makes it easy to enforce legal constraints, such as avoiding GPL-licensed libraries in BSD-licensed software).

Real-world & domain. Dependency management is a live, everyday problem in modern software. JavaScript's npm ecosystem repeatedly hit "left-pad"-style disasters and supply-chain attacks, and Android's Gradle builds pin exact versions because transitive resolution changed behavior; the .NET GAC exists specifically to end DLL hell; and every serious organization runs Artifactory or Nexus as a company-internal "library warehouse." When a company reports a diamond dependency problem — two libraries needing different versions of a shared logging library — that is dependency hell under a different name, and it is the same problem the build tools in this section are designed to prevent.

8.3 Component Pipelines and the Integration Pipeline

8.3.1 Separating Code Bases to Escape the Monolith

For components, you need to make sure the components are separated from the entire code base — your modules have to be separated from the whole code base — and that server and client are kept as different code bases. In the e-grocery example you have front-end code and back-end code, and generally you keep a separate lifecycle for back-end and front-end: a separate back-end code base and a separate front-end code base.

Why? Because it takes too long to compile and link the code. If you keep everything together in one application, in one code base, that is nothing but monolithic architecture. With a monolith it is difficult to compile the entire code: if there is only a change in the back-end part, your whole code base is still at one place, so front-end and back-end everything gets compiled again, and then the code links — that takes more time. So keep the code bases separated: whenever there is a change in one code base, only that one is built, and libraries from the previous build of your other components can just be used to launch the application.

The textbook lists the signs that it is time to separate a codebase into components: part of the codebase needs to be deployed independently (a server or a rich client); you want to turn a monolith into a core plus plugins; a component provides an interface to another system; and — directly relevant here — it takes too long to compile and link the code, or too long to open the project, or the codebase is too large for a single team.

8.3.2 One Pipeline per Component

Can we split the system into several different pipelines? Yes — since we have several different components in the application, we can split the pipeline into several different pipelines. The build for each component, or set of components, should have its own pipeline to prove that it is fit for use or fit for release. That pipeline performs all the steps: compile the code if necessary; assemble one or more binaries that are capable of deployment to any environment; perform unit tests and other test suites — acceptance, capacity, integration, and so on — and support manual testing wherever appropriate. (This is exactly the textbook's list: compile the code if necessary, assemble one or more binaries capable of deployment to any environment, run unit tests, run acceptance tests, and support manual testing where appropriate — the goal being early feedback on the viability of each change.)

In the e-grocery application — login component, search component, cart component, payment component — each has its own pipeline, so that only those components where you made a change go through build and compile and all other processes. If we make a change to login, the other components do not get built: only login goes to build, assembly, unit test, and the other testing suites. Then, to launch the e-grocery application, you need an integration pipeline that integrates all the components together — it integrates all the artifacts of the components and launches the application.

8.3.3 The Integration Pipeline and Release Flow

The integration pipeline assembles the packages and performs the subsequent testing, to make sure the system testing happens. Here you will have smoke testing and acceptance testing (the system test), then the result gets deployed to a testing environment for further manual testing if at all needed, and finally it is released to the production environment.

Look at the two-component diagram: component A has its own pipeline — compile and unit test and functional test — and component B has its own pipeline. Whenever a pipeline executes, an artifact gets created: build means once you compile and build something, the artifact is created, and those artifacts are nothing but your binaries. Those artifacts have to be stored in an artifact repository — in the figure the artifacts from component A's pipeline are stored there, with a similar structure for component B. So managing components is done with automation, with continuous integration pipelines.

The textbook describes the same flow precisely: the integration pipeline takes as its starting point the binary output of each component. Its first stage composes the appropriate binaries into a deployable package; the second stage deploys the result to a production-like environment and runs smoke tests — quick checks that the assembled application actually starts and its basic functions work; then conventional acceptance tests run on the whole application; then deployment to testing environments; then release. This matches the deployment-pipeline shape of T2_5: commit stage (compile, unit tests, analysis) → acceptance stage → capacity/UAT → production.

The textbook adds two principles to remember about integration pipelines: fast feedback (trigger downstream pipelines as soon as binaries are created and unit tests pass — do not wait for acceptance tests) and visibility (when an integration build fails, you must be able to trace back which versions of which components contributed to it — a modern CI tool shows you this in seconds).

8.3.4 When Pipelines Trigger

The same trigger rule, in the textbook's phrasing: each component has its own pipeline, triggered by changes in that component's source code or by changes to any upstream dependency; downstream pipelines are triggered by the upstream component passing its automated tests.

Real-world & domain. This is exactly how real CI/CD systems are organized. A company with separate front-end and back-end repos runs separate pipelines per repo (the practical meaning of "separate code bases"), a shared mobile app pipeline builds the app for iOS and Android, and a Jenkins/GitHub Actions workflow defines when each job triggers. GitLab, GitHub Actions, and Jenkins all support downstream triggering — the artifact repository (Nexus, Artifactory, GitHub Packages) is the shared shelf from which the integration pipeline picks component binaries — which is the structure the course demo will show with Jenkins, Maven, SonarQube, and Selenium.

8.4 Dependency Graphs and Pipeline Triggers

8.4.1 The Directed Dependency Graph

To manage dependencies you can use a dependency graph. A dependency graph is nothing but a directed graph, and it should be acyclic. Whenever there is a cycle in the graph, you have a circular dependency — a build ladder — which is discussed in Section 8.5.

A directed graph is a set of nodes connected by arrows that point one way; here the nodes are components and an arrow points from a component to the thing it depends on. A directed acyclic graph (DAG) is a directed graph with no loops — you can never follow arrows and return to where you started. If arrows could loop back, component A would need component B, which would need component A, and no build could ever start. The textbook's instruction is blunt: if you draw the dependencies between components, it should be a DAG; a cycle is a pathological dependency problem.

8.4.2 The Portfolio Management Example

Take the example of a portfolio management application (taken from the textbook). The components are: the framework component, the report engine, the settlement engine, and the pricing engine — these modules, or components, form the portfolio management application. The diagram's arrows show the dependencies: the report engine depends on the framework; the settlement engine also depends on the framework; the pricing engine depends on the framework; and at the same time the pricing engine is also dependent on the CDS pricing library, which is a third-party library. CDS here means credit default swap — a finance-domain pricing instrument.

8.4.3 Q&A: A Framework Change

The textbook's trigger rule is worth stating precisely: if a successful change is made to the framework (its own pipeline passes its tests), its immediate downstream dependencies are rebuilt — the reports engine, the pricing engine, and the settlement engine. If all three pass, the portfolio management application is rebuilt using the new versions of all three upstream components. If any of the three intermediate builds fails, the portfolio management application is not rebuilt, and the framework is treated as broken until fixed.

8.4.4 Q&A: A Third-Party Library Change

The textbook describes the same scenario: the CDS pricing library is a third-party, binary dependency, so if the version in use is updated, the pricing engine is rebuilt against the new version and the current version of the framework; that in turn triggers a rebuild of the portfolio management application. One important subtlety: the trigger is not an "and" relationship. If only the reports engine's source changes, the portfolio application is rebuilt whether or not the pricing or settlement engines are rebuilt.

8.4.5 The Pipeline Dependency Graph

You can visualize this with a pipelining dependency graph: for the framework there is one pipeline; the pricing, settlement, and reports components each have their own pipeline.

Changes in third-party libraries arrive in the artifact repository; when the artifact for the report engine that is being accessed changes, that is nothing but a code change that happened to the report engine — you have to make modifications to the reporting engine because that particular library got changed.

The graph shows the triggers. If you change the framework, pricing, settlement, and reporting pipelines are triggered. If you only change the pricing engine, the framework and others will not be triggered — however, the portfolio management application will be triggered by accessing the particular binaries and libraries. Practically, you have to make a change in your Jenkins pipeline file if you are using Jenkins (you will get to know in subsequent sessions): in the script you write that, if there is any change, the downstream pipeline should be triggered automatically once the framework is changed — that has to be maintained.

8.4.6 Upstream and Downstream Visualization

How can one visualize which particular libraries, or which particular version of your application, a component is used with? There are two approaches. The upstream approach works right to left: you are looking for the particular version of the portfolio management application, 2.0.263, and asking which libraries or binaries were used to build this particular version — yes, for pricing we used this one, for settlement engine this one, for report engine this one, and then this is the one for framework. That is your upstream dependency.

The downstream approach goes left to right: given a particular version of the framework component, which other components got built using this particular version of the framework? A tick means that version is actively used; a cross means it is not getting used; and there are three different versions of the portfolio management application that were built on the 1.3.2394 version of the framework component. This visualization exists to maintain and manage the versions of your application in a production environment, and to see by using which particular libraries the application was built. Manually it is difficult to see, so with a graphical view it becomes easy to visualize the dependencies.

Real-world & domain. This is the daily mental model of release engineers. In finance, portfolio and risk systems genuinely depend on CDS and other pricing libraries supplied by vendors, and the team has no pipeline for those vendor binaries — it consumes them from the artifact repository. Modern CI platforms encode exactly these trigger rules: Jenkins pipelines, GitHub Actions workflows, and GoCD fan-in/fan-out dependencies all implement the same graph-walking logic, and tools like Jenkins' "pipeline dependency graph" visualization are the industry incarnation of the upstream/downstream tables shown in the textbook.

8.5 Branching Components and Circular Dependencies

8.5.1 Branching at the Component Level

You can create feature and subsequent branches at the component level as well. Say there is only a change in the report engine and the others are not changing. Since each component has a different code base, you create a new feature branch for the report engine — refer to it as 1.1 — and do the changes in that branch. Bug fixes for the previous version can be done in the 1.0 branch. Once the code is ready for 1.1, you merge it to the main line, and the base code becomes report engine 1.1. This is nothing but branch by abstraction. Because the code bases are separated for each and every component, you get the flexibility to create multiple branches in each component and manage their code base changes in those branches, rather than doing it for the entire application.

The textbook describes the same pattern — branch by release — with the reports engine: the team creates a branch for the 1.0 release and develops 1.1 on mainline. New features continue on mainline; downstream users keep consuming the binaries from the 1.0 branch and get bug fixes checked into that branch; when they are ready, they switch to 1.1. The textbook is honest about the trade-off: branch-by-release defers integration and so is second best for continuous integration — but because components are (or should be) loosely coupled, the risk of painful integration later is more controllable, which makes it a very useful strategy for managing complex component changes.

8.5.2 Circular Dependencies and the Build Ladder

If the directed dependency graph contains a cycle, then the application has a circular dependency. Take the example: component A and component B — component B is dependent on component A, and at the same time component A is also dependent on component B. In this cycle A depends on B and B depends on A:

$$A\to B\text{and}B\to A$$

This is nothing but a build ladder. In a real-time project, component A is at version 1.0.21; the next time you write component B, to run component B you are using the previous version of component A, and then to run component A you are using this version of component B. So each component runs against the other's earlier version — that is a circular dependency, and it shows the build ladder. This is how it gets managed in real-time projects. Frankly speaking, it is difficult to explain in a normal way — how can this be possible in a real-time project? But most of you will agree that you come across this situation: a circular dependency in your application — and this is the hack to use it.

The textbook explains why this works: the cycle looks like a fatal bootstrapping problem — to build A you need B, to build B you need A — but you never begin a project with circular dependencies; they creep in later. The build ladder works as long as there is a version of component A that you can use to build component B. Then you use the new version of B to build the new version of A. Step by step, each component climbs one rung of the ladder.

Keep in mind: if you are using any build tool to automate your build process, no tool comes with the facility of managing circular dependency. You need to hack with your tool — hack the configuration settings of the tool — and make it supportive for your application. Circular and transitive dependencies are not directly available in the build process; with any tool you are using, you need to change the configuration settings to make it happen.

The textbook adds a critical caveat: if each component triggers a build of its dependencies automatically, the two components would build forever because of the circularity. You must be cautious about how the parts of the build interact — the ladder only works with deliberate, manual ordering. And the textbook's bottom line is firm: at runtime there is no problem as long as both components are available together, but always try to get rid of circular dependencies; use the build ladder only as a temporary workaround until you can eliminate the problem.

Real-world & domain. Circular dependencies are a known anti-pattern in real build systems; tools like Maven refuse to resolve a project graph with cycles at all, which is why teams "hack" them — often by temporarily publishing a snapshot of one component to the artifact repository so the other can build against it, exactly the ladder mechanism. In enterprise monoliths being migrated to microservices, circular domain references are one of the first things architects break apart — the "always try to get rid of circular dependencies" advice is what refactoring tools like dependency-analysis reports enforce in CI.

8.6 The Build Process and the Build-Tool Landscape

8.6.1 The Steps of a Build Process

The build process has a core set of steps. First, compile the source code. Second, the build process should run and evaluate the unit tests. Third, the build process should process the existing resources — if you have configuration files or something similar, they should be processed by your build tool. Fourth, generate the artifacts — depending on the technology you used and what artifact you want to generate out of it, those artifacts should be generated.

More steps are often executed in a build process: perform the administrative dependencies analysis; analyze the code quality with static code analysis; run more test cases like functional tests and capacity tests; and archive the generated artifact and package it in a central repository, from which other pipelines can pick those particular artifacts. These are usually the steps of any build process.

The textbook's survey adds the underlying principle: all build tools share a common core — they let you model a dependency network of tasks. When you run the tool, it calculates how to reach the goal you specify by executing tasks in the correct order, running each task that your goal depends on exactly once. For example, running your tests requires compiling your code and your tests and setting up test data; compiling requires initializing the environment; the tool works out the order automatically and never runs a task twice, even when several tasks depend on it. A task then has two essential features: the thing it does, and the other things it depends on.

8.6.2 Build Tools by Technology

Depending on the technology, there are multiple tools available in the market. For Rails technology, organizations prefer to go with Rake. For .NET technology, people tend to use MS Build. For Java technology you have Ant, Maven, and Gradle. For C and C++, the build tool is SCons. If you are using Android and mobile development with Kotlin, the best combination is to go ahead and use the Gradle build tool. So depending on the technology in which your source code is being developed, subsequent build tools are available in the market respectively — you can opt for one.

The textbook fills in the landscape behind this list. Make and its variants were the standard build tools for many years — powerful, product-oriented, and essential when compile time is a significant cost — but complex rules, whitespace-significant syntax, and OS-specific shell dependence pushed developers away; many C/C++ developers now use SCons (its build files are written in Python, which makes it powerful and portable, with Windows support and parallelized builds out of the box). Ant emerged as the Java community's cross-platform answer: fully cross-platform, with tasks written in Java and an XML external DSL; it became the de facto standard Java build tool and is still widely supported by IDEs — but it is verbose, XML-heavy, and needs a great deal of boilerplate. MSBuild (the .NET descendant of Ant and NAnt) is tightly integrated with Visual Studio and understands how to build Visual Studio solutions and projects. Rake is the dominant Ruby build tool — an internal DSL in Ruby, meaning build files are plain Ruby code with all the power of a general-purpose language, able to act as either a product-oriented or a task-oriented tool. The newer generation — Buildr, Gradle, and Gantt — combine internal DSLs with serious dependency management and multiproject build support: Buildr as a drop-in Maven replacement built on Rake, and Gradle for those who prefer their DSL in Groovy (or Kotlin). The professor's summary holds for all of them: pick the tool that matches your technology.

8.6.3 What the Tutorial Sessions Cover

As per the syllabus, this course covers Maven and Gradle. In the tutorial session, the Jenkins demonstration will cover Maven, SonarQube, and Selenium: a continuous integration pipeline will be shown for a Maven project with the Maven build tool, then SonarQube, then Selenium test cases. The next session is purely focused on Git and GitHub, and after that comes a quiz. If time permits, the tutorial session instructor will discuss either Selenium or SonarQube so that the tutorial sessions cover as much as possible.

(SonarQube — not "SonarCube" — is the open source platform for continuous inspection of code quality; SonarQube and Selenium are tools used in the demo pipeline, not build tools proper.)

Real-world & domain. The tool-per-technology mapping is the reality of every build system in industry: Android shops run Gradle (with Kotlin DSL), .NET teams run MSBuild or Cake, Rails apps ship with Rake tasks, and C/C++ teams rely on SCons or CMake. The "build as a dependency network of tasks" idea underlies every one of them — and understanding it is what lets an engineer read any project's build files, whatever the tool.

8.7 Maven

8.7.1 What Maven Is and Who Owns It

Maven is a build tool. Every component generates one artifact with it — either Java or even zip, anything — but every module will create an artifact. Maven is also a dependency management tool. It handles the versioning and releases of your application. You can describe the project using Maven and produce Java docs or site information with it. Who owns Maven? The Apache Software Foundation owns this build tool. Real-world: Maven's official website is itself built using Maven, and the tool is completely open source — whenever you want to use Maven, it is freely available.

The textbook frames Maven as the tool that removed the boilerplate of Ant: it has a richer domain model and makes many assumptions about how a Java project is laid out — the principle of convention over configuration. So long as your project conforms to the structure Maven dictates, Maven performs almost any build, deploy, test, and release task with a single command. Its second headline feature is automated management of Java libraries and dependencies between projects — the pain point of large Java projects. (The textbook also notes the trade-off: if your project does not conform to Maven's assumptions, making Maven do what you want can be extremely hard — what the professor later calls Maven's rigidity.)

8.7.2 The Maven Project Structure

A Maven project has a standard structure. There is a source folder — src/main/java: java is the technology you are using, and if you use any other language, this java folder is replaced by that language's name. By default, Maven looks for this structure: the src, main, and java directories underneath your project. Then there is the target folder, the folder where Maven compiles all your source code: whatever gets compiled and whatever output gets generated is stored in the target directory. The pom.xml is the Maven-compiled source code, in a way: how to compile this source code is provided in the pom.xml, and it is also where you manage your dependencies — you mention there how to compile the source code and what artifact has to be generated from it. Maven supports different languages; it is not restricted to Java — it works with Groovy and other resources, just the folder structure changes to the language's name.

For unit testing, Maven searches for the folder structure src/test/java — again, if you have written in Java you write java, and other resources mention their names; to perform unit testing this folder structure has to be there. Everything gets compiled in the target directory — even your tests get run and validated in the target directory — and the package contains jar, war, or zip: the artifact generated from the source code lives in the target directory.

my-app/
      ├── pom.xml                  ← how to compile, what artifact, which dependencies
      ├── src/
      │   ├── main/
      │   │   └── java/            ← production source (replace java/ with the language name)
      │   │       └── com/bits/HelloWorld.java
      │   └── test/
      │       └── java/            ← unit test source
      │           └── com/bits/HelloWorldTest.java
      └── target/                  ← created by Maven: compiled classes, test results, the packaged artifact

8.7.3 How pom.xml Identifies a Project: Group ID, Artifact ID, Version

Maven uniquely identifies a project — that is why it is a management tool too — with the help of group ID, artifact ID, and version. (The textbook calls these three coordinates, sometimes abbreviated GAV, and notes that together with packaging they uniquely identify any Maven domain object — project, dependency, or plugin.)

The group ID is often the same as your package: for example com.bits or com.maven.training is nothing but a group ID. Generally the group ID is the business name or application name that you would like to see on a web address or on a mobile application. The artifact ID is the same as the name of your application: hello world, if that is the application; on-demand service, if that is one application; e-grocery is the application name. So if e-grocery is developed under com.bits, then com.bits becomes the group ID and e-grocery becomes the artifact ID. The version shows the version of the particular project.

The version formats are usually major, minor, and maintenance. Major means the tag you would like to keep for your project; if it is under maintenance you give it as a maintenance; if it is released you give it as a release. And a hyphen followed by SNAPSHOT is the version of a project that identifies it as under development — it is not majorly or minorly released, not under maintenance, just under development:

$$V=\text{major}.\text{minor}.\text{maintenance},V_{\text{development}}=\text{major}.\text{minor}.\text{maintenance}\text{-SNAPSHOT}$$

For example, 1.0-SNAPSHOT means this is the 1.0 version of the on-demand service application and it is under development. So these three identifiers together uniquely identify the project.

The textbook adds what SNAPSHOT means in practice: append -SNAPSHOT to the version and mvn install stores the artifact under a timestamped folder (version-yyyymmdd-hhmmss-n), so consumers who declare only 1.0-SNAPSHOT always get the latest development build. Snapshots are convenient but make builds harder to reproduce — use them with care.

8.7.4 Inside pom.xml: Packaging, Dependencies, and Plugins

The pom.xml is the main file of Maven: you mention how your source code should compile, what the output from this particular component should be, and how to package that output. Packaging is how we want to distribute our application — whether you would like to give it as a jar or a war; these are nothing but the binaries out of your module. By default, if you do not mention anything under the packaging section of your script, Maven generates a jar — the default packaging is always jar.

You manage dependencies in the dependency section of the pom file: if you want to use a library, you need to know three things — the group ID of that dependency, its artifact ID, and the version you want to use. Plugins go in the plugin section of the pom.xml, where you mention what plugins you want. (The textbook's Maven section adds useful details: each dependency can carry a scope — test for test-only libraries, runtime for libraries not needed at compile time, provided for libraries the environment supplies at runtime, and compile (the default) for libraries needed at both compile and run time — and you can even declare version ranges like [1.0,2.0). The examples in the textbook are declared exactly the professor's way: commons-collections:commons-collections:jar:3.2.)

This is a vocabulary correction worth holding onto: artifact = any output of a build (JAR, WAR, ZIP, PDF, documentation, reports) — not only binaries or libraries.

The hello-world pom — a worked example. For learning purposes, a pom.xml was created with the group ID com.bits; the application name is hello world, so the artifact ID becomes hello world; this is 1.0-SNAPSHOT, which shows that it is under development. The model version is 4.0. The packaging is jar. Under the dependencies section there is a dependency: commons-lang3 — the first dependency is commons-lang3 — with version 3.8.1, and the group ID is org.apache.commons. From that particular address, that library is fetched; that is the dependency for the application, for this module. In the plugin section, the first plugin is the Maven compiler plugin, of version 3.7.0, to build this source code, and the configuration settings that you mentioned get processed in the target.

<project>
        <modelVersion>4.0.0</modelVersion>        ← the POM schema version Maven must parse
        <groupId>com.bits</groupId>               ← group ID: the business/package name
        <artifactId>hello world</artifactId>      ← artifact ID: the application name
        <version>1.0-SNAPSHOT</version>           ← 1.0, still under development
        <packaging>jar</packaging>                ← the artifact will be a JAR
        <dependencies>
          <dependency>                            ← the application depends on...
            <groupId>org.apache.commons</groupId> ← ...the Apache Commons organization...
            <artifactId>commons-lang3</artifactId>← ...library commons-lang3...
            <version>3.8.1</version>              ← ...exactly version 3.8.1
          </dependency>
        </dependencies>
        <build>
          <plugins>
            <plugin>
              <artifactId>maven-compiler-plugin</artifactId>  ← plugin that compiles the source
              <version>3.7.0</version>
            </plugin>
          </plugins>
        </build>
      </project>

Important: automation is not done automatically. There has to be a code logic or a script logic written to automate the job — the automation happens by using this particular pom.xml file. The pom explains the project, explains the dependency, and describes how you would like to build it.

8.7.5 Maven Goals: clean, package, install, deploy

Maven has multiple goals; the most common ones in industry are these four.

• mvn clean — just cleans the target directory: whatever was generated in the last build, whatever output was stored in the target directory, gets erased. That is the best practice.
• mvn package — first cleans, then compiles, then creates the package mentioned in the packaging section of your pom.xml. The package is generated and stored in the output directory. It first runs the compile goal, then runs the unit tests, and generates the artifact or package as per the pom.xml.
• mvn install — first runs the full package goal, then installs the package in the local repository. By default, the local repository on your system is the .m2 folder, which you can find under the user system folders once you have installed and started using Maven. When you run Maven install, by default the package will be pushed into your .m2 folder as well.
• mvn deploy — runs the install goal first, then deploys the package to the corporate or remote repository that you mentioned. It is just similar to file sharing: it will deploy all the artifacts to that particular repository.

There are other goals too, but these are the ones the industry most commonly uses when working with Maven projects.

8.7.6 Project Inheritance

Maven supports project inheritance: with the pom file you can inherit configurations, so you can maintain your component-level dependencies via Maven — group ID, version, project configuration, dependency, plugin configuration, and so on. How does it work? Under the project you mention the parent: which project is to be inherited by this particular module. In the parent section you can mention the Maven training parent — this is the group ID and this is the version that has to be inherited for this particular project; the project is the Maven training project, and the packaging is jar packaging. So you can inherit the configurations — you can implement project inheritance in Maven.

The textbook calls this a dependency refactoring: instead of declaring versions in every project, define them once in a parent project — wrapping the <dependencies> block in <dependencyManagement> — and child projects declare their dependencies with no version at all; the version comes from the parent. A shared parent pom is exactly how an organization keeps consistent library versions across dozens of projects.

<parent>
        <groupId>com.maven.training</groupId>
        <artifactId>maven-training-parent</artifactId>
        <version>1.0</version>
      </parent>

8.7.7 Multi-Module Projects

Maven also supports multi-module projects — it has first-class multi-module support. Maven projects create one primary artifact, and a parent pom is used to group those modules. In the example, you have Maven training; under that, you have source code and a pom.xml. Under that you have Maven training web, for which you also have source code and a pom.xml. This pom.xml is your parent pom: the parent pom has packaging of type pom, and the modules will be maven-training and maven-training-web. In this way you can manage multi-module projects — one project containing multiple modules. And that is exactly what we want: this is how Maven supports component-based design.

The connection to Section 8.1 closes the loop: multi-module Maven projects are how Maven supports component-based design — one parent pom grouping the components of an application, each module with its own artifact and its own dependency declarations, all versioned and built together.

Real-world & domain. Maven is the backbone of the Java ecosystem: almost every open source Java library is published to Maven Central as GAV coordinates, and the pom.xml you write today is consumed by the same coordinates that tools like Maven Central and GitHub Packages index. Enterprises run internal Nexus/Artifactory mirrors of Maven Central so builds are fast, repeatable, and auditable. The course demo itself shows the canonical Maven workflow: Jenkins triggers mvn clean package, SonarQube scans the code quality, and the resulting WAR deploys to Tomcat.

8.8 Gradle

8.8.1 What Gradle Is

Gradle is an open source build automation tool. Its build scripts are written in a domain-specific language (DSL). It is high performance because it runs only the required tasks which have been changed — it does not run the entire code, just the tasks that have been changed. Gradle also has a build cache that helps reuse the task outputs from the previous run: with the build cache there is no need to run all the tasks — only the changed task runs, and other task outputs can be accessed from the build cache. Gradle has the ability to share the build cache within different machines.

It is based on a JVM foundation, so the prerequisite for working with Gradle is the Java Development Kit, similar to Maven. And it is not just limited to Java — you can use it for other languages. As mentioned, Kotlin and Gradle is the best combination that you generally find in an organization.

The textbook groups Gradle with the new generation of build tools (Buildr, Gradle, Gantt) that "feature internal DSLs for building software" while making complex challenges like dependency management and multiproject builds just as easy as the older tools. Where Ant and Maven write their DSL in XML (an external DSL you must learn separately), Gradle's DSL is internal: the build script is a real programming language (Groovy or Kotlin), so the script has the full power of a general-purpose language.

8.8.2 Tasks and the Directed Acyclic Graph

The core concept is creating tasks and dependencies between them. Gradle calculates a directed acyclic graph (DAG) to determine which tasks have to be executed in which order. The graph can be changed through custom tasks, more plugins, or other modifications of the existing dependencies. You can work with plugins to allow Gradle to work with other languages — Groovy, Kotlin, C++ — you just need to install those appropriate plugins.

This is the same dependency-network idea from Section 8.6, made the heart of the tool: the build is a set of tasks (compile, test, package, ...), each task depends on others, and Gradle resolves the DAG — remembering which tasks ran and which outputs are up to date — to decide what to run and in what order.

Worked example — the task graph. The core model is based on the task: a directed acyclic graph of tasks. In the example graph, task A is the root; tasks B and C are dependent on task A; tasks D and E are dependent on C; and task Z depends on D and E:

$$A\to C\to D,E\to Z$$

To execute task Z, the order is: first task A, then task C, then task D and task E, and then task Z — the graph tells you which task has to be executed in which order. (D and E can run in either order once C has completed.)

8.8.3 The Anatomy of a Task: Action, Input, Output

A task in Gradle is nothing but a module or component where you have code that performs something — the actions. The inputs are the values given to those actions, and the output is, after performing the action, the generated output. So every task has these three parts: action, input, and output.

This three-part anatomy is what makes incremental builds and the build cache possible: Gradle records the task's inputs and outputs; on the next run it compares them. If the inputs are unchanged and the outputs already exist, the task is up-to-date and Gradle skips it, reusing the previous output — locally, and even across machines when the build cache is shared. Inputs can be files (a source folder), property values, or even other tasks' outputs; outputs are usually files or directories the action produces.

Real-world & domain. Gradle is the default build tool for Android — every Android Studio project is a Gradle project — and is the standard choice in Kotlin shops (the "Kotlin + Gradle" combination the professor called best). Its incremental build and build cache matter most in large, multi-module codebases and CI: companies like Netflix and LinkedIn have reported build-time savings of minutes per build by sharing a build cache across CI agents and developer machines.

8.9 Gradle versus Maven: How to Choose

Both Gradle and Maven support Java, and both support multiple languages. When it comes to choosing which one to opt for, you need some analysis — this comparison helps you decide when to use Gradle and when to use Maven.

8.9.1 Flexibility

Gradle has flexibility on the conventions: you can write the script because it is a domain-specific language, you can follow your own naming convention, and you can plug and play with the configuration settings of Gradle — it is so flexible, user-friendly, and customized. Maven has no flexibility on the conventions: you have to use strictly what is mentioned — the pom.xml example shows that strict way of using it. It is rigid.

The textbook frames the same point as convention over configuration: Maven's rigidity is sometimes considered a feature — it forces teams (especially large or inexperienced ones) to structure projects uniformly — but deviating from Maven's assumptions is painful. Gradle's internal DSL means the build script is real code: custom tasks, custom naming, and custom logic are ordinary programming.

8.9.2 Performance and the Build Cache

In terms of performance, Gradle processes only the files that have been changed. Reusability by working with the build cache is supported — that helps ship the project faster, because you are reusing; you are not wasting your time compiling all the tasks, only those which have been changed. Maven processes the complete build; there is no build cache concept, so shipping is slow compared to Gradle.

8.9.3 User Experience and IDE Support

When it comes to user experience: Gradle's IDE support is evolving — for example, you can integrate easily with Gradle in Visual Studio, but for other IDEs it is ongoing — while its command-line way of working is modern. Maven's IDE support is mature, and its CLI solution is classic in comparison with Gradle.

So the summary: if you do not need the build cache, working with Maven is easy because it has strong IDE support. If you need to plug and play with the configuration settings — for example in terms of managing those circular dependencies — customization is easy in Gradle because it is not that rigid.

When to pick which: choose Maven when you want a uniform, predictable, IDE-friendly build for a conventional Java project and you do not need a build cache; choose Gradle when you need performance (incremental + cache), Kotlin/Android, or the freedom to customize the build — the rigidity of Maven is precisely what makes it the wrong tool when you must bend the conventions.

8.9.4 The .m2 Repository versus the Gradle Cache

A closing note on the repositories. mvn clean is required to delete the target directory: the target directory has the processed files, and it should be clean so that there are no compatibility issues. Gradle, by contrast, has the build cache, which lives in a repository. The .m2 repository of Maven does not have processed files or artifacts — it just has the package, so you can think of .m2 as a repository and it can be used for data sharing. In the Gradle repository you will have the processed artifacts, which can be used to package the overall application or overall output.

The distinction: .m2 holds finished, packaged artifacts (the JARs your project produces and the libraries it downloads) that other projects can consume; the Gradle cache holds intermediate processed outputs (compiled classes, task results) so that tasks never re-run work that is still valid. That is why mvn clean matters — the target/ directory accumulates processed files and stale artifacts, and a clean slate avoids compatibility issues between builds — while Gradle's cache is designed to be reused.

8.9.5 Q&A: Gradle, Maven, or Jenkins — Which Is Widely Used?

This question also draws the line between two roles that beginners often merge: Gradle and Maven are build tools (they compile, test, and package), while Jenkins is an integration system (it observes your repository, triggers the build tool, and orchestrates the pipeline stages). They are not rivals of the same kind.

8.9.6 Q&A: Does Python Need a Build Tool?

The reasoning behind the correction: Python runs directly from source through its interpreter, so there is no compile step to automate in the Maven/Gradle sense; its packaging needs are handled by Python's own ecosystem (for example, pip and setuptools), not by a general-purpose build tool. Gradle pairs best with Kotlin; Maven is best suited for Java.

Real-world & domain. This comparison is made every day in real engineering choices: a 2020s startup on Kotlin/Android picks Gradle for build speed; an enterprise Java shop standardizes on Maven so hundreds of developers produce uniform builds; CI platforms (Jenkins, GitHub Actions, CircleCI) merely run whichever tool the project chose. The "3000 free builds per day" open source tier of CircleCI — and GitLab CI's comparable free tier — are why integration tools are effectively free to try, while the build tool decision remains the one that shapes a project's build experience for years.

8.10 Course Logistics and Exam Guidance

8.10.1 Q&A: What the CI/CD Demo Will Show

8.10.2 Q&A: References for the Sessions

8.10.3 Q&A: PHP Build Approaches

(For your own context: PHP follows the Python-like pattern of a self-interpreted language — Composer manages libraries and autoloading, and tools like Phing (a port of Ant) or simple shell scripts handle build tasks. The professor promised to confirm this with PHP experts.)

8.10.4 Assessment Structure and Weightage

The evaluation components for the course are: quiz 10 marks, assignment 20 marks, mid-semester 30 marks, and comprehensive 40 marks. The assignment will be opened after the mid-semester examination.

8.10.5 Quiz Scope and Timing

Quiz 2 covers everything you have learned till today — apart from whatever was covered for quiz 1, that is the part of your quiz 2. The quiz will be before the mid-semester. The quiz time window is fixed: generally it is 24 hours — one quiz was made 42 hours — and it cannot be made flexible, because this is the new pedagogy that was to be executed. The assignment, in contrast, gets weeks of time.

8.10.6 Mid-Semester Syllabus and the Comprehensive Exam

8.10.7 Exam Format and Preparation

Also worth knowing for planning: the course is not hands-on and not a code-development based course, so you do not need to worry about that; the latest course handout has been uploaded on Teams, and the class has been asked to use the handout shared there. And there is a lot to study, but it is easy if you go slowly and steadily.

Recap. The session closes the loop: build and deployment will be seen in the CI/CD demo (Maven build artifacts, unit tests, Selenium, SonarQube, Tomcat deployment); references will be uploaded; PHP build approaches are to be confirmed; and the assessment plan is quiz 10, assignment 20, mid-semester 30, comprehensive 40, with the mid-semester syllabus being everything covered till today plus the upcoming CI/testing sessions. With the course logistics settled, you now have the full picture of this session's syllabus material: component-based design, dependencies, pipelines, dependency graphs, circular dependencies, the build process, Maven, Gradle, and how to choose between them.

Exam Guidance Summary

All the assessment-relevant guidance from this session in one place:

• Weightage. Quiz 10 marks, assignment 20 marks, mid-semester 30 marks, comprehensive 40 marks. The assignment opens after the mid-semester examination; the quiz comes before the mid-semester.
• Quiz 2 scope. Everything covered till today, on top of the quiz 1 content.
• Quiz timing is fixed. The quiz window is generally 24 hours (one quiz was extended to 42 hours); it cannot be made flexible — the professor is bound by the new pedagogy. The assignment gets around three to four weeks.
• Mid-semester syllabus. Communicated by Tuesday on Teams and the portal: everything covered till today, plus the upcoming sessions on continuous integration / unit testing and Selenium automation testing. The contact session on the 18th is the cutoff — whatever it covers is in the syllabus.
• Comprehensive examination. Covers the whole course handout, from contact session one to the last session.
• Makeup examinations. Available for the mid-semester — regular and makeup examinations both exist.
• Exam format. The ninth contact session walks through the last year's question paper and the expected answers, so the question pattern is discussed there.
• Content focus. The build-tool material of this session — component-based design and the three releasability approaches, library versus component and build-time versus runtime dependencies, per-component pipelines and the integration pipeline, dependency graphs and pipeline triggers, upstream/downstream visualization, circular dependencies, the build process steps, Maven (pom.xml, group ID/artifact ID/version, goals, inheritance, multi-module projects), Gradle (tasks, DAG, build cache), and the Gradle-versus-Maven comparison — is the syllabus material for today, alongside the last two sessions' content.
• Not hands-on. The course is not a code-development course; you do not need to worry about programming it yourself.

Key Industry Applications

• Real-world: Components ship as DLLs on Windows, .so files on Unix, and JAR files in the Java world.
• Real-world: Payment gateways evolve with delivery, net banking, UPI, and credit card features; e-commerce search depends on successful authentication — everyday examples of component dependencies.
• Real-world: Feature toggling (flag variables) is how production teams hide unfinished functionality; branch by abstraction keeps the main baseline defect-free during large-scale changes.
• Real-world: DLL hell was a classic Windows failure mode — the wrong library getting picked from a shared folder at runtime.
• Real-world: Library management in practice means versioned names (XYZ 1.0, XYZ 1.2) in a lib folder under version control, or declared dependencies pulled from internet repositories like Maven Central or from an organization's own artifact repository.
• Real-world: Tomcat is a classic runtime dependency for Maven-based web applications; Java apps depend on the JVM, Rails apps on the Rails framework, C apps on the C standard library.
• Real-world: Per-component pipelines with an integration pipeline, artifacts stored in artifact repositories, and triggers on commit or merge are how real CI/CD systems are organized; Jenkins pipeline files encode the trigger logic.
• Real-world: In finance, a CDS (credit default swap) pricing library is a third-party library a pricing engine depends on — the dependency graph example is taken from a real portfolio management system.
• Real-world: Build tools map to technologies: Rake for Rails, MS Build for .NET, Ant/Maven/Gradle for Java, SCons for C/C++, and Gradle as the best combination for Kotlin and Android.
• Real-world: Maven is owned by the Apache Software Foundation and its official site is built with Maven; the .m2 folder is the local repository Maven install pushes packages into.
• Real-world: Gradle's DSL scripts, incremental task execution, and build cache are used in modern Kotlin/Android shops; CircleCI offers an open source tier with 3000 free builds per day, while Jenkins remains the reference open source integration tool.
• Real-world: In the course demo, a CI/CD pipeline builds a Maven project, runs unit tests and Selenium tests, scans with SonarQube, and deploys to Tomcat.