Project Defaults (aka Bootstrap projects)

[Tobias Roeser]

Hello folks,

let me share some idea I have for a long time. I really like to get your
thoughts or veto or support for it.

Motivation:

On (larger) projects, you often want to share some project settings, like
compiler settings, dependencies, plugins, version numbers between all (or
some) modules. Today, this is possible with the @include annotation. But that
approach has some disadvantages:

- You can not share script dependencies which you would typically add with
@classpath in each project file
- You have to provide all dependencies of the included file via @classpath, in
each module that uses the includes file
- You have to program extra "boilerplate" to apply some functionality of the
included file to the project.

The Feature:

Let me introduce the `@defaults` annotation, to fix these shortcommings and to
add some additional advantages.

I essence, I want to annotate a project with an additional annotation
`@defaults("Defaults.scala")` pointing to another scala resource (e.g.
Defaults.scala). This file will be compiled and somehow applied to the project
before the project class itself (SBuild.scala) is applied. Thus it will be
able to configure the project. That configuration will be available very early
and will even influence the scheme handlers available in the @classpath and
@include annotations of the project.

The "Defaults.scala" class itself will look pretty much the same as an project
buildfile, beside the class name.

As I alread started to convert all current default scheme handler into
plugins, it will be very easily to configure thoose over the Plugin API. E.g.
it would be easy to configure the "mvn:" scheme to use additional remote
repositories or to add an "https:" scheme handler containing some pre-
authentication to a dedicated corporate server. I general, a lot more use
cases might show up, once this feature is implemented.

I also pretty much like the idea of a second boolean "replace" parameter in
the @defaults annotation. If it is `true`, the given Defaults files will
disable the built-in defaults (but it will itself use theses previous
defaults). The default would be to not replace (but extend) the defaults.

Technically, there is no reason, why a Defaults project shouldn't itself be
able to use a defaults file itself, but of course this might leed to hard to
grasp project setups, so I tend to disable that ability.

I'm not that sure, if the internal state of the Defaults file should be keept
in the same directory (which means, that it can be shared) or if that state is
keept in the project using it (no shared state and each project needs to
compile that include file itself) or if this should be configurable, too, e.g.
with a `@shared` annotation on that class.


I hope you got an idea of the planned concept. Any feedback is much
appreciated! If something is not clear, I'd be glad to clarify, just ask.

Best regards,
Tobias

[Tobias Roeser]

I created the 'bootstrap' branch, which implements a `@bootstrap` annotation. This already works, and it works recursive, so you can experiment if this is useful or not. I did not implement the `replace` idea, because it would be very tricky to hide classes from the child project classloaders which were already present in the parent class loader. But I can imagine to have some kind of `@bootstrapDisable` annotation, which is mutual exclusive to `@bootstrap`. That way, you could opt-out the built-in defaults. Please also note, that the current version does not have any defaults and thus also no default scheme handlers. I'm not sure, if we should make the handling of the default consistent with the current process, which means, we roll out a source file and on the first run, SBuild will compile it, or if we should ship a pre-compiled version. Do you have any strong opinions in that regard?

I created a WIP pull request, so feel free to review and comment there, too: https://github.com/SBuild-org/sbuild/pull/190

Have a nice weekend,
Tobias