Skip to content

Latest commit

 

History

History
421 lines (271 loc) · 28.7 KB

CHANGELOG.md

File metadata and controls

421 lines (271 loc) · 28.7 KB

dbuild release notes

0.9.20

  • Support sbt 1.8.0 (by ignoring scala-xml version conflict)
  • Publish JARs to Maven Central (not Bintray)
  • Publish tarball to GitHub (not Cloudsmith)

0.9.19 (withdrawn)

0.9.18 (withdrawn)

0.9.17

  • Use https not http
  • Allow for an empty selection of subprojects in an sbt-based project

0.9.16

  • Allow patterns in "projects" and "exclude" for sbt projects

0.9.15

  • Fix to SeqSeqString serialization

0.9.14

  • This version adds compatibility with sbt 1.2.1.

0.9.13

  • A change in an internal call within sbt 1.2.0 caused dbuild to be imcompatible with that version. This new version of dbuild will automatically select the correct version of the call, and is compatible with sbt 1.2.0.

  • Fix for an incorrect internal dependency on sbt modules, where sometimes multiple versions of modules might have appeared on the classpath.

  • Some other internal improvements.

0.9.12

  • Now dbuild takes into account the new "skip in publish" flag, available in recent sbt releases.

  • Added a new flat "rewrite-overrides". In those projects that, in addition to libraryDependencies or "allDependencies", also modify "dependencyOverrides", dbuild will now rewrite the latter as well, unless the flag "rewrite-overrides" is explicitly set to "false". The flag can be specified per sbt build level, just like "check-missing" or "cross-version".

0.9.11

  • Hotfix to the deploy code, in case the target is Bintray

0.9.10

  • Fixed several issues related to timeouts, which are now all properly caught and processed, and can be customized by the user.

  • The underlying processes spawned by dbuild are now properly terminated in case of build failure, timeout, or premature termination (including Ctrl-C).

  • Better error messages when sbt terminates with an "Incomplete" exception, avoiding long printouts of unreadable internal structures. Thanks, Dale Wijnand (@dwijnand)

  • Support for the "override" flag when deploying to Bintray

  • Build code refactoring: a single command can again crossbuild all of the required libraries and archives.

  • Updates to the code base, to match updated versions of several dependencies.

  • Documentation updates and fixes.

0.9.9

  • Support for sbt 1.0.0 final.

  • The custom list of tests can now also include commands, as well as tasks. That allow scripted to be invoked as a test step.

  • Added "skip-missing-tests" flag: if some of the test tasks/commands are not defined in some of the subprojects, the build will not fail but the test step will be skipped instead for those subprojects.

  • Minor doc updates; minor fixes.

0.9.8

  • Improved support for sbt 1.0.0-M6.

0.9.7

  • This release is compatible with sbt 1.0.0-M5 and 1.0.0-M6. The source code and the build files have been reorganized, and moved to the .sbt format. The supported sbt versions are 1.0.0-M5, 1.0.0-M6, and 0.13.*; support for the old 0.12.4 has been removed.

  • A customized sbt launcher is now used to launch dbuild; the only difference being that Proguard optimization is disabled. That allowed the latest launcher to be used (the old 0.13.8 launcher was being used previously).

  • Fixes for issues #190, #158, #188

  • Added support for Jcenter in Ivy and Maven build systems

  • The dbuild sbt plugin .pom no longer directly refers to sbt jars, but uses those provided by the running sbt environment. Fixes scala/community-build#384.

  • Replaced the classic version of the dispatch library with new code based on the modern dispatch reboot.

  • Various library upgrades, and other updates

0.9.6

  • Fixed the "deploy" option when the target is a Bintray repository.

0.9.5

  • It is now possible to use different versions of the JDK on the within the same dbuild setup: the compiled data and metadata will be kept separate for the different versions of the Java language specification.
  • The local Git clones cache was moved to the "~/.dbuild/" directory, but is now configurable via the "dbuild.clones.dir" property.

0.9.4

  • Added release notes to the repository
  • Updated default repo list, replacing outdated addresses
  • Clearer message when a test task is unknown
  • Tweaked dependency on sbt-native-packager, to avoid slf4j issues
  • Added the "null:null" deploy scheme, in order to allow indexes to be generated without having to upload artifacts as well
  • Implemented the "standard" cross-versioning level for the Aether and Assemble build systems

0.9.3

  • More checks on the credentials used in Deploy
  • Adjustments needed by the BinTray migration: the dbuild binaries are now directly published to BinTray
  • The artifacts generated by dbuild may now also be easily uploaded to BinTray as well
  • More accurate debugging information is available while debugging
  • Documentation updates
  • Added the "java-options" feature to the sbt build system
  • Fix to typo that may prevent snapshot versions of dbuild from being resolved correctly
  • Fix a quirk introduced in 0.9.2, which may lead to incorrect SHAs
  • When --debug is provided, all available vars are now printed
  • Added support for multiple target projects on the command line
  • Use moduleName rather than name in module info (better with Play)
  • When printing the welcome message, also include as a reference the exact source commit the executable was compiled from
  • New "Aether" build system: similar to the "Ivy" build system, but once the artifacts are resolved they are still in Maven format, and as such can be resolved (for instance by the Scala Ant build file), or republished to an external repository
  • ~/.m2/repository is used as a read-only remote Maven repository
  • Also support "binary" and "standard" cross-version levels in the "Scala" build system
  • Correctly handle javaAllOpts in case of repeatable configs
  • Fix an issue where some -RC or milestone suffixes might have been incorrectly rewritten
  • Longer timeouts when detecting anomalous termination
  • Various minor improvements and fixes

0.9.2

  • Added ability to create index files for deployed artifacts; this facility is used when creating RP releases
  • Various refactorings and improvements
  • More accurate handling of subprojects in the Assemble build system
  • Better error handler for unknown URI schemes
  • More informative diagnostic messages, in case of failed extractions
  • Improvements to the Deploy facility
  • Respect the local "repositories" sbt file, if one is present
  • Locally published dbuild snapshots may now be more easily tested
  • Split out the Deploy feature to a separate library, which can be used by other projects to upload artifacts via scp/artifactory/etc
  • Added integration tests
  • Fix to the handling of injected settings, some of which might have been skipped in certain cases
  • Travis integration
  • Other minor fixes

0.9.1

  • Better diagnostic messages when dependency cycles are detected
  • More accurate diagnostic messages for repo consistency errors
  • Fix to serialization/deserialization of settings, which may cause repeated identical builds to fail in certain cases

0.9.0 and 0.8.1

  • Play support, and full support for compilation, rewiring, and publishing of sbt plugins: the components related to the Play Framework can now be compiled as part of the community build. The projects defined in a dbuild configuration file can use sbt plugins generated by other projects within the same configuration. Those plugins are assigned a space that is (optionally) separate from the space of the main artifacts, and use a separate version of the Scala compiler and of the various dependencies. (0.9.0)

  • New "checkout" feature! In order to debug a failing build, it is no longer necessary to install the dbuild plugin, and perform a complex manual setup: the new command "dbuild checkout" can be used instead. The syntax is "dbuild checkout uuid project path": it will interrogate the cache, extract all the build information, check out the source, switch to the right commit, rematerialize the dependent artifacts, and prepare a script that can be repeatedly invoked in order to start an interactive sbt session that is exactly equivalent to what dbuild would find during building. At this point, the user can easily debug the situation, and even reproduce exactly what dbuild would do during building, by invoking the "dbuild-build" command. (0.9.0)

  • Added the new command line options --no-notify, --no-resolvers, and --local, which simplify the local testing of dbuild configuration files that are normally deployed to Jenkins. (0.8.1)

  • Many improvements to the --debug options, that now also enables Ant debugging in Scala builds, diagnostic printing of the Maven/Ivy repository list, information on rematerialized artifacts, etc. Conversely, reduced the verbosity of some messages when "--debug" is not present. (0.8.1, 0.9.0)

  • New option "check-missing". Previously, the detection of missing dependencies and the selection of cross-version suffixes were conflated, hence the use of "cross-version:default" to disable missing dependency detection. The two aspects are now separate: the detection of missing dependencies can be switched off independently, using the new "check-missing" option. (0.9.0)

  • Changed the default sbt version number that should be used by projects. The default is now simply to use the sbt version number defined in build.properties by each project, unless overridden within dbuild. If the project has no build.properties, and no sbt version is specified in dbuild, a diagnostic message is printed. (0.9.0)

  • The new option "set-version-suffix" can be used to replace just the suffix part of a project version number, rather than the entire version as required by "set-version"; that makes it easier to keep up with evolving project versions. Artifacts can automatically be tagged with a git hash-derived suffix, so that it is clear which git commit they come from. (0.9.0)

  • The "commands" option is now complemented by a new option "settings". The option "settings" defines sbt settings that should be inserted between the project loading and the dependency rewiring or extraction; conversely, "commands" describes sbt operations that are executed after dependency rewiring, but before the actual project building. (0.9.0)

  • The work on sbt plugins support in dbuild exposed a latent bug in sbt, which was fixed in sbt 0.13.5. In order to support projects that relied on 0.12.4 or 0.13.2, the two unsupported sbt versions 0.12.5-dbuild and 0.13.3-dbuild, which include the needed fix, have been published to the dbuild support repository. Now dbuild requires at least these versions, or sbt 0.13.5 or greater. (0.9.0)

  • A new automatic variable ${vars.auto.timestamp} is available for replacement in configuration files: it contains the build timestamp. (0.9.0)

  • Fixed an obscure git-related issue that could cause an incorrect update of git source checkouts during extraction in some cases. (0.8.1)

  • Improvements to the handling of .m2 cache directories, which are now local to each Scala build, solving the problem of potential cache pollution arising from multiple similar (but different) builds. (0.8.1)

  • Improvements to the dbuild release publishing: the dbuild launcher is now published as a regular artifact, rather then via S3. (0.9.0)

  • Added workaround to the PermGen leaks that affect certain versions of sbt (0.9.0)

  • In the final execution report, projects are now sorted alphabetically rather than by dependency, so that it is easier to locate the status of a project of interest when many projects are listed. (0.9.0)

  • The resolvers list used for a particular build is now included in the repeatable config, so that builds can be reproduced more easily. The list in the repeatable configuration can be overridden in any case by using the "--no-resolvers" command line option. (0.9.0)

  • The internal architecture of dbuild has been extended in order to support build systems that need to operate on separate "universes" of artifacts. The main application is supporting the rewiring of dependencies for the plugins environment in sbt builds, but the feature can be used in other future build systems as well. In the case of sbt, further levels up (plugins of plugins, etc.) are also supported by means of this generic mechanism. (0.9.0)

  • Several build options (space.from, check-missing, cross-version, deps.include, deps.inject, and settings) can now be specified separately for the main artifacts and for the plugins in each sbt project. (0.9.0)

  • Improvements in the handling of Ivy caches in the various project builds: there is now no danger of confusion for different project builds in different spaces, even if thay happen to use the same organization, name, and rewritten version number for their generated artifacts. (0.9.0)

  • New diagnostic: since dbuild now knows about the structure of sbt plugins dependencies, it can now also diagnose which sbt plugins are needed by the listed projects, but are not included in the configuration file. (0.9.0)

  • Improvements in the handling of the list of repositories, which will simplify the future effort of supporting simultaneous (and parallel) dbuild runs on the same machine. (0.9.0)

  • Under certain circumstances a subtle bug was causing SHAs of saved data to change mysteriously across serialization/deserialization, leading to unexpected error conditions. Now fixed. (0.9.0)

  • When an sbt-based project had no "extra" record, but some commands were specified as a build section default, those commands were not correctly applied to the project. Now fixed. (0.9.0)

  • Better detection of automatically created default subprojects in sbt projects, improving the build process of certain projects. (0.9.0)

  • Code cleanups, and improved diagnostic messages throughout the code. (0.9.0)

  • Improved support for projects that use the form "dependsOn(uri)": in case an sbt subproject is automatically generated as a result, the dependency graph calculation could fail. Different code is now used to calculate dependencies, fixing the issue. (0.9.0)

  • Improved logging. Especially in build files with many different projects, it was always difficult to locate the section corresponding to a certain project in the log. Now, the project name is prepended to each line in the various sections, making it easier to locate the needed information. (0.9.0)

0.8.0

  • Spaces! Projects can now publish their artifacts, and fetch their dependencies, using "spaces", which act as independent universes of artifacts. That makes it easy, for instance, to use a common set of dependencies to test the same set of projects multiple times, using different options, or to organize bootstrap procedures in which the same artifacts are generated multiple times, in separate spaces. A wild variety of testing combinations can be consolidated into a single dbuild configuration file, thanks to this new feature.

  • The Scala build system has been further improved. It will now invoke "publish.local", if that target is available. The list of ant targets and options can be customized, and the system is able to select starr and modules from the output of the other projects; in conjunction with spaces, that allows for a full bootstrap of the compiler and the compiler modules, in multiple stages.

  • Performance improvements in the Git resolver. Now much faster, it provides a choice of either standard Git or JGit. Unmerged pull requests can now be tested in advance by specifying a URL that ends with "#pull/NNN/head". Git resolution will work from a local cache if there is no network connection.

  • dbuild will now provide, while building, a resolved copy of the configuration, containing references to specific commit hashes for each projects, and where all the variables have been resolved: that makes it much easier to re-run the exact same configuration as many times as needed. Such expanded configuration is saved to the repository of cached builds together with the generated artifacts, and can be easily retrieved using the "drepo" utility

  • The system properties can now be used as vars in config files: a definition "-Dxxx=value" on the command line will become into ${vars.sys.xxx} in the config file

  • Artifacts can now be automatically deployed to a remote server using an scp copy (in addition to S3, Artifactory/Nexus, or a local dir)

  • Automatic and configurable cleanup of temporary build data (no longer growing endlessly), plus warnings for old versioned dirs that may still be lingering around

  • Partial builds are now possible, by specifying a given target project: only that project and its dependencies will be built

  • dbuild now knows about scala compiler plugins: they can be compiled and used like regular projects

  • A new option "deps.inject" complements the existing "deps.ignore": they can be used to add or remove explicitly elements from the set of dependencies that dbuild was able to recognize automatically (if necessary)

  • Automatic comparison of the artifacts generated by different projects: the jar files are explored recursively, and the contained files/classes are compared. It is possible to specify which files should be checked by using patterns, and multiple comparisons can be specified. This is particularly useful for bootstrapping the Scala compiler: subsequent stages can be automatically checked for equality.

  • Most build options can now be specified as defaults for groups of projects; multiple groups are possible. For example, you can now specify "sbt-version:0.13.1" just once for a whole group of projects. Those defaults can still be overridden within each project.

  • Large improvements to the logging infrastructure, which is now also user-configurable: the option --debug will enable it on demand. Ivy is no longer excessively verbose during resolution.

  • Added options parsing; full help message with --help, etc.

  • Several minor improvements to the Assemble and Ivy build systems

  • The list of Ivy/Maven resolvers can now be parsed directly from each dbuild configuration file. Just send your config to another user, and he/she will be able to reproduce without having to tweak their standard resolvers list.

  • Fixed a truncated diagnostic in the cycle detection error messages

  • Fixed a metadata size issue with particularly complex build files

  • Various improvements to the documentation

Tickets closed: #48, #35, #84, #41, #53, #83, #58, #89, #86, #95

0.7.0

This release introduces a new build system, especially designed to support Scala 2.11 modularization, as well as other features, fixes and improvements. In detail:

  • The new "assemble" build system offers extended support for the new Scala modularized build. Independent artifacts are grouped and their dependencies rewritten so that they appear to all originate from a single project, rearranging cross-versioning and version numbers as needed. Both Ivy and Maven artifacts are supported. Addresses cyclic dependencies in the core Scala modules.
  • A new internal support has been added for build systems that operate recursively, allowing a set of dbuild projects to be built as part of an enclosing project
  • Flowdock integration for dbuild is now available: the build outcomes and reports can now be automatically sent as Flowdock messages, in a variety of formats, when certain events occur

Also:

  • Fixed an issue where "SeqString" was deserialized as a WrappedArray, leading to incorrect UUIDs in metadata
  • Much improved (and fine-tunable) control over a range of timeout conditions, which are now detected, captured, and forwarded as notifications
  • Reorganized the internal metadata publication; improves debuggability using "dbuild-setup", and makes it possible to use a shared internal dbuild repository on Artifactory without requiring the "delete" privilege
  • Fixed an issue that caused sbt stack traces to be lost in certain cases
  • Fixed an actor-related issue that could cause the last portion of log files to be lost (we now wait for logging actors to complete their work and exit cleanly)
  • Build variables can now also be specified via external property files, simplifying their use in the build definition files
  • More informative messages when extractions or builds fail, and also while checking library dependencies
  • More information on the configuration is printed when dbuild starts up
  • It is now possible to specify which exact version of Scala should be used during dependency extraction; that is useful for those projects whose build files specify a different set of dependencies depending on the scala version
  • Addressed a subtle inconsistency in the handling of sbt version numbers (harmless now, but might have caused troubles with future versions)
  • Simpler development, building dbuild automatically against 0.12 and 0.13 (courtesy of the sbt-cross-building plugin)
  • Tightened detection of missing dependencies, by improving the checking mechanism
  • Fixed the handling of default sbt projects, correcting a previous inability to compile some of the new Scala modules
  • More sanity checks, and other minor cleanups

0.6.5

  • This version introduces changes that are necessary to cope with the new Scala modularization, introduced in recent milestones. In particular:
    • regenerate the Scala home by also fetching the new Scala modules (with the proper cross-versioning, as rewritten by dbuild during their compilation)
    • added a facility to exclude selected dependencies from the version rewiring, allowing sets of projects that would otherwise be in a cyclic dependency to be compiled together.

Also:

  • New diagnostics when the Scala build metadata somehow cannot be parsed
  • Better error handling while reading from the configuration file (for example: file unreadable, wrong permissions, etc.)
  • Fixed cycles diagnostics (the message was processed by prepareLogMsg(), but the diagnostic message concerning cycles was inappropriately truncated to the first few lines)
  • Exceptions due to cycles are now properly intercepted, so that the related errors are correctly dispatched via the notification system (they used to resolve into an "Unexpected" outcome, and only printed to the console)
  • A new unchecked "vars" section can new be used to define strings, or whole JSON subtrees that can then be used in the rest of the configuration definition (the rest of the configuration file is still checked against its schema)
  • Other minor clean-ups

0.6.4

For those who were waiting for sbt-0.13 compatibility, this version is good news: after some hammering, the core sbt plugin is now working with both 0.12.4 and 0.13.0-RC5.

The version of sbt that should be used to compile all projects can be selected via a global build option, or overriden in each project as required. For example:

{
  name:  specs2
  uri:   "git://github.com/etorreborre/specs2.git"
  extra: { run-tests: false, sbt-version: "0.13.0-RC5" }
}

This version also addresses an issue that prevented some projects from building correctly in certain cases, and introduces a few other minor improvements.

0.6.3/0.6.2

  • The most important internal improvement is the introduction of a new dependency management infrastructure, along with a systematic handling of all the possible outcomes and error conditions arising from the compilation and testing of the different projects. Rather than compiling the various projects in a sequence, and aborting upon the first error, dbuild now explores the dependency graph while building, and is able to create informative reports about which projects failed and in which manner, and in virtue of which dependencies.

  • dbuild now includes most of the facilities required for parallel building of non-interdependent projects, including an optimized scheduling mechanism, by traversing the graph in parallel. All that remains to do is adding locking over a few repository-related sections: the next release of dbuild will be able to build projects fully in parallel.

  • The reporting facility is complemented by a notification infrastructure, which is able to send reports (by email, or in other manners) to project maintainers, when the test of their project, or their dependencies, falls within a certain subset of possible outcomes. Each report is tailored for the specific project, and messages can be customized.

  • It is now possible to integrate seamlessly pre-built binaries in the context of a dbuild configuration file, by using Ivy as an additional "build system". The selected artifacts are fetched from a Maven or Ivy repository, republished locally as if they were generated from source, and their dependencies rearranged so that they fit in with the remaining projects. They can also optionally be redeployed, as modified, to an external repository again.

Fixes and improvements:

  • There existed an issue with sbt-republish, where a non-standard use of classifiers may have caused artifacts not to be found. Now fixed.

  • Further improved missing dependencies detection.

  • If projects are arranged so that, via exclusion lists, one project publishes scala-library and another one scala-compiler, the two would receive by default different dbuild-specific version numbers, which would confuse sbt. Now all Scala artifacts will get the same dbuild-specific default version number as scala-library.

  • There was an implicit assumption that the scala-compiler artifact would be available together with scala-library, when compiling a project using sbt. That is not necessarily true, especially with the new Ivy-based build system; an explicit dependency on scala-compiler is now added to sbt-based projects.

  • Improved the generation of the scalaHome used when using different versions of the scala artifacts.

  • In the configuration file, every list of strings with a single element can be directly replaced with the string, simplifying the syntax.

  • sbt exception messages were previously lost, returning to dbuild a generic error message. Now returned properly.

  • Also, added preliminary support for checking out pull requests branches from GitHub (in the form pull/NNN/head). There is currently a speed penalty for doing so, which be addressed in the future.

0.6.1

  • A new option is available to sign artifacts using PGP, before uploading them: useful when deploying artifacts to Maven Central.

  • Better detection of missing dependencies: dbuild will let you know whether any Scala-based dependent projects are missing from your configuration file, and will offer more information about the missing bits.

  • More control over the handling of cross-versions, with different options suitable to either development or to release software.

  • Some of the Scala compiler components can now be hidden from dbuild, so that they can be supplied by different projects instead. Useful when working on Scala modularization.

0.6.0

  • The list of repositories is now fully configurable; you can set it to your local Maven/Ivy proxy, and have ultra-fast or even offline resolution.

  • Cached Git repositories: rather than re-cloning the various Git repos, dbuild will keep its own local cache, and only fetch changes. This will also work when the machine is offline and no new data can be retrieved. Further local clones are made using hard links, saving space.

  • Drastic improvements in the handling of intra-project dependencies: for sbt projects that are made up of multiple subprojects, dbuild is now able to configure partial builds by tracking all of the internal dependencies and aggregates. A new "exclude" clause can be used to split projects into multiple portions (see manual). Nameless "default" sbt projects are also supported.

  • Much better diagnostic messages in a variety of situations. More checks for error conditions (duplicates, conflicts, incorrect dependencies). Additional informational messages concerning the various intra- and inter-project dependencies are now printed while building.

  • It is now possible to override the version number with which each of the projects should be compiled. That makes it possible to stage an upcoming version of Scala, and test its various dependent projects, even without tagging anything in the repositories.

  • More control over the Scala build system: build.number can be overridden, additional options/properties can be passed to ant, and the ant target used for compilation can be customized (useful to test optimized/non-optimized builds, or other options or backends).

  • An entirely new 'deploy' configuration section has been added. At the end of the build, the generated artifacts can be published to the local file system, to Artifactory/Nexus, or to Amazon S3. It is possible to select which projects should be published, and even which subset of the sbt artifacts should be added from each project. Multiple deployments can be configured for a single build.

Also:

  • Fixed an unusual Maven-related problem that only occurred when the commit hash was entirely numeric (which happens in the 0.9% of cases).

  • Now fully compatible with 2.11.0-M4. And, a new mechanism is now in place to extract the list of internal Scala libraries/dependencies, which will be useful moving forward with further modularization (thanks Adriaan!).

  • Many documentation updates, and other minor fixes.