Modern build managers provide support for
so that all of these can be handled quickly and efficiently as part of the normal build.
Baselines may include multiple 3rd-party libraries.
We may rely on specific version of our chosen libaries.
Those libraries may require other libraries.
Example: Report Accumulator
A project of mine, this page lists the 3rd party libraries required by the project.
The page lists various stages of the build.
E.g., for testCompile, I requested JUnit 4.12 8 Which in turned needed hamcrest-core 1.3
For the spotbugs stage, I requested spotbugs 3.1.12
A repository is a collection of packages (usually libraries) and metadata about packages
The Java world is dominated by
Maven Central (a.k.a ibiblio)
Try searching each of these for junit
It’s common for development organizations to host their own repository.
Local repositories can be
elaborate (e.g., Artifactory )
or little more than a file drop
Packages are typically identified by
The group or organization
org.apache.ant
, edu.odu.cs.extract
junit
The artifact name
junit
, hamcrest-core
, apache-commons
Version number
4.12
4.11+
: 4.11 or laterlatest.integration
: latest official release1.2-SNAPSHOT
: a version under development. The stapshot modifier serves as a notice that the actual package may be updated without a change in version number.Not every library that your project needs is needed all of the time.
junit
would only be needed when compiling and running the unit tests.spotbugs
, checkstyle
(discussed later in the semester) are only used during report generation.So build managers allow you to import libraries in selected scopes which indicate when the library is actually needed.
This affects
CLASSPATH
and other settings made available to the build steps.Examine the pom.xml file and look for the dependencies
section.
You’ll see something like
<dependencies>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<version>4.10</version>
<scope>test</scope>
</dependencies>
[4.12,]
to get versions 4.12 or greaterWhen the build is run (e.g. mvn package
):
Maven does a transitive search over the dependencies for a project
Maven then downloads the required libraries automatically
~/.m2
)How does Maven know whether junit itself depends on other libraries?
Here is the actual published content for Junit 4.12.
The .pom
file is the metadata.
Look inside. Search for <dependencies>
. You’ll find
<dependencies>
<groupId>org.hamcrest</groupId>
<artifactId>hamcrest-core</artifactId>
<version>1.3</version>
<scope>compile</scope>
</dependencies>
This is the same kind of info that we put into our own pom.xml file
Technically, our project has two repositories
Team projects will often employ an intermediate shared repository
In pom.xml:
<repositories>
<repository>
<snapshots>
<enabled>false</enabled>
</snapshots>
<id>central</id>
<name>libs-release</name>
<url>http://archive350.cs.odu.edu:8080/artifactory/libs-release</url>
</repository>
</repositories>
YAAP1 , Ivy adds the dependency management features pioneered by Maven to ant
Technically can run as a standalone application, but really the ant integration is key.
Use is similar to the dependencies/repositories portion of Maven POMs
Ivy can retrieve from and publish to the established Maven repositories
As is often the case, gradle
tends to provide simpler syntax to do much the same things as Maven and Ant.
In build.gradle
:
apply plugin: 'java'
⋮
repositories {
jcenter() ➀
// Use my own CS dept repo
ivy { ➁
url 'https://www.cs.odu.edu/~zeil/ivyrepo'
}
}
dependencies { ➂
implementation 'net.sf.saxon:saxon-dom:8.7+'
testImplementation 'junit:junit:4.12'
testRuntimeOnly 'edu.odu.cs.zeil:reportAccumulator:1.1+'
}
Here you see both the choice of libraries ➂ and of repositories ➀, ➁.
The dependencies indicate
The scope (e.g., testCompile
, which actually includes compiling and running of the unit tests)
The package, specified as organization:package:versionNumber
Scopes in Gradle
dependencies {
implementation 'net.sf.saxon:saxon-dom:8.7+'
testImplementation 'junit:junit:4.12'
testRuntimeOnly 'edu.odu.cs.zeil:reportAccumulator:1.1+'
}
If project P depends on library L, then the most common scopes recognized by Gradle are:
Generally this means that some class declared in L is used as a parameter or a return type by some public function in P.
Each of the build/library managers we have discussed have support in Eclipse
Each of the build/library managers we have discussed have support in Eclipse
May provide special editors for editing the build manager configuration files.
Each of the build/library managers we have discussed have support in Eclipse
May provide special editors for editing the build manager configuration files.
Provide ways to launch the build manager from within Eclipse
Each of the build/library managers we have discussed have support in Eclipse
May provide special editors for editing the build manager configuration files.
Provide ways to launch the build manager from within Eclipse
Sometimes it’s easier to launch separately in a separate window, e.g., from the command line from the Gradle GUI mode.
Each of the build/library managers we have discussed have support in Eclipse
May provide special editors for editing the build manager configuration files.
Provide ways to launch the build manager from within Eclipse
Sometimes it’s easier to launch separately in a separate window, e.g., from the command line from the Gradle GUI mode.
Remember to “refresh” the project in Eclipse afterwards
Each of the build/library managers we have discussed have support in Eclipse
May provide special editors for editing the build manager configuration files.
Provide ways to launch the build manager from within Eclipse
Sometimes it’s easier to launch separately in a separate window, e.g., from the command line from the Gradle GUI mode.
Remember to “refresh” the project in Eclipse afterwards
Most importantly, allows Eclipse Java projects to use any 3rd-party libraries fetched by the build/library manager.
Each of the build/library managers we have discussed have support in Eclipse
May provide special editors for editing the build manager configuration files.
Provide ways to launch the build manager from within Eclipse
Sometimes it’s easier to launch separately in a separate window, e.g., from the command line from the Gradle GUI mode.
Remember to “refresh” the project in Eclipse afterwards
Most importantly, allows Eclipse Java projects to use any 3rd-party libraries fetched by the build/library manager.
Otherwise the built-in Eclipse compilation and smart-editing features would mistakenly believe that your code was full of references to non-existent classes and funnctions.
Each of the build/library managers we have discussed have support in Eclipse
May provide special editors for editing the build manager configuration files.
Provide ways to launch the build manager from within Eclipse
Sometimes it’s easier to launch separately in a separate window, e.g., from the command line from the Gradle GUI mode.
Remember to “refresh” the project in Eclipse afterwards
Most importantly, allows Eclipse Java projects to use any 3rd-party libraries fetched by the build/library manager.
Otherwise the built-in Eclipse compilation and smart-editing features would mistakenly believe that your code was full of references to non-existent classes and funnctions.
May allow some management of the cache of old libraries.
Eclipse has various Gradle plugins available.
The most popular seems to be the BuildShip package, now standard in most Eclipse distributions.
Allows import (only) of existing Gradle projects
Allows launching Gradle from within Eclipse
Allows Eclipse Java projects to find 3rd-party libraries loaded by Gradle.
After any change to the dependencies in
build.gradle
, you must right-click onbuild.gradle
and selectGradle -> refresh Gradle project
.
- Eclipse re-reads your
build.gradle
file and obtains the desired libraries.
Plug-ins to build managers modify the build process itself
Consequently, plug-ins generally need to be fetched and processed at the very beginning of a build, much earlier than most 3rd-party libraries.
Plug-ins to build managers are generally handled separately from other items, though the syntax is often similar.
Consequently, plug-ins generally need to be fetched and processed at the very beginning of a build, much earlier than most 3rd-party libraries.
Plug-ins to build managers are generally handled separately from other items, though the syntax is often similar.
For example, in gradle, plug-ins are retrieved from repositories specified in a pluginManagement
section in settings.gradle
:
pluginManagement {
repositories {
jcenter()
ivy { // for
url 'https://www.cs.odu.edu/~zeil/ivyrepo'
}
}
}
pluginManagement
area are almost identical to the way we handle normal package repositories.Then we load the plugins from a plugins
section in build.gradle
:
plugins {
id 'java'
id 'edu.odu.cs.report_accumulator' version '1.3'
}
Maven has a similar approach, isolating plug-ins in a <plugins>
section.
Publishing artifacts to a repository is also supported by maven, Ant/Ivy, & Gradle.
mainly because most repositories are open to download, but require login credentials to upload.
Example: in Gradle build.xml
publishing {
publications {
ivyJava(IvyPublication) {
organisation 'edu.odu.cs.zeil'
module 'cowem-plugin'
revision project.version
descriptor.status = 'integration' // milestone, release
descriptor.branch = 'v1'
from components.java
}
}
repositories {
ivy {
name 'ivyRepo'
url 'sftp://linux.cs.odu.edu:22/home/zeil/secure_html/ivyrepo'
// Readable via https://www.cs.odu.edu/~zeil/ivyrepo
credentials {
⋮
}
}
}
}
Providing login credentials to a build is problematic.
A common work-around is to store a few build “properties” in a file in the user’s home directory, not kept as part of the package version control.
Example: in Gradle build.xml
// Credentials are loaded from ~/.gradle/gradle.properties
if(project.hasProperty("ivyRepoUser")){ ➀
ext.ivyRepoUser = "$ivyRepoUser";
} else {
ext.ivyRepoUser = "user";
}
if(project.hasProperty("ivyRepoPass")){
ext.ivyRepoPass = "$ivyRepoPass";
} else {
ext.ivyRepoPass = "password";
}
⋮
publishing {
⋮
credentials { ➁
username project.ivyRepoUser
password project.ivyRepoPass
}
⋮
}
➀ looks to see if properties ivyRepoUser
and ivyRepoPass
were loaded from ~/.gradle/gradle.properties
. If so, it adds them as “extension” properties of the current gradle project.
➁ passes those new extension properties as login credentials to a repository.
If the person running the build di not have a ~/.gradle/gradle.properties
or it did not contain the properties ivyRepoUser
and ivyRepoPass
proeprties, then attempted uploads to the repository would use a default username and password that would, presumably, fail.
Sadly, the situation for C++ is somewhat more complicated.
Should C++ libraries be deployed as source or binaries?
.a
or .so
in *nix) are OS-specific.
.h
) files as well as the compiled code if they are to compile their own applications.There are Operating System-dependent solutions for deploying binaries.
These solutions work for deploying applications but not so well for developers.
We Don’t Have Anything Equivalent to Maven Central for C++
There’s no recognized central place to publish and find open source C++ libraries.
No standard for what such a library would look like.
Partly, that’s because we don’t have build managers that would take advantage of such libraries if they existed.
We Don’t Have Anything Equivalent to Maven/Ivy/Gradle Dependency Management for C++
There are no build managers capable of processing dependencies for C++ while simultaneously factoring in the platform-specific requirements.
Which Came First, the Chicken or the Egg?
Who wants to set up repositories without build managers that can use them?
Who wants to write such build managers if there are no repositories that they could work with?
Gradle seems to be paying serious attention to C/C++ build support.
Gradle seems to be paying serious attention to C/C++ build support.
Gradle seems to be paying serious attention to C/C++ build support.
Conan is an attempt to provide a packaging standard for C++ library repositories.
Gradle seems to be paying serious attention to C/C++ build support.
Conan is an attempt to provide a packaging standard for C++ library repositories.
JCenter
is also hosting Conan
artifacts.Gradle seems to be paying serious attention to C/C++ build support.
Conan is an attempt to provide a packaging standard for C++ library repositories.
JCenter
is also hosting Conan
artifacts.Gradle seems to be paying serious attention to C/C++ build support.
Conan is an attempt to provide a packaging standard for C++ library repositories.
JCenter
is also hosting Conan
artifacts.Gradle seems to be paying serious attention to C/C++ build support.
Conan is an attempt to provide a packaging standard for C++ library repositories.
JCenter
is also hosting Conan
artifacts.Gradle seems to be paying serious attention to C/C++ build support.
Conan is an attempt to provide a packaging standard for C++ library repositories.
JCenter
is also hosting Conan
artifacts.In mid-summer of 2019, the Gradle project released a heavily revised set of C++ plugins, which greatly simplify building C++ with Gradle.
Gradle seems to be paying serious attention to C/C++ build support.
Conan is an attempt to provide a packaging standard for C++ library repositories.
JCenter
is also hosting Conan
artifacts.In mid-summer of 2019, the Gradle project released a heavily revised set of C++ plugins, which greatly simplify building C++ with Gradle.
These include provisions for downloading both binary and source code libraries.
Gradle seems to be paying serious attention to C/C++ build support.
Conan is an attempt to provide a packaging standard for C++ library repositories.
JCenter
is also hosting Conan
artifacts.In mid-summer of 2019, the Gradle project released a heavily revised set of C++ plugins, which greatly simplify building C++ with Gradle.
These include provisions for downloading both binary and source code libraries.
Not clear how stable these are, but it’s a promising sign.
1: Yet Another Apache Project