| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
this extracts certain parts of cbt into stand-alone libraries, which can
be published to maven and used outside of cbt.
This also adds scalariform for these parts of the code.
This slows down cbt’s own build a lot because of the number of projects
involved! So we’ll follow this by a bunch of performance tweak commits.
|
|\
| |
| | |
ScalaPB plugin
|
| | |
|
| | |
|
|/ |
|
|
|
|
|
|
|
|
|
|
| |
THis is mostly cleanup and a little bit feature.
Before it was done partially in 3 places, BuildBuild,
loadRoot and GitDependency. Now DirectoryDependencies
also support referencing sub-builds.
Also introduce scalariform for the first few files
of cbt's core code :).
|
| |
|
|\
| |
| | |
Scalafix plugin
|
| | |
|
|/ |
|
| |
|
|
|
|
|
|
|
| |
last file watching update didn’t work well enough. This now
- rips out barbary watch service as it seems buggy crashing the jvm
- make cbt exclusively write files to watch to a file
- uses fswatch instead watching all files in that file
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
now CBT and builds pass their file names to the current build
via the context. The build then simply blocks until any file changes.
Then it returns with a special exit code, which the bash script picks
up and restarts CBT. Thats works well for looping over project files.
It works less well for looping over builds and CBT itself. For this
a build has to success once, so that the .cbt-loop.tmp file exists.
Then looping works for cbt and builds, but the file list is not
updated in case of compile errors, etc.
Fixes
- https://github.com/cvogt/cbt/issues/406
- https://github.com/cvogt/cbt/issues/405
- https://github.com/cvogt/cbt/issues/202
- https://github.com/cvogt/cbt/issues/50
- https://github.com/cvogt/cbt/issues/22
We should improve for 1.0 in https://github.com/cvogt/cbt/issues/419
to handle looping over build files and cbt itself smarter.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
| |
- split out manifest and scaladoc logic
- refactor lib calls from inheritance layer
- only strip project directory prefix from individually specified files
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Code is much simpler now.
Now cbt sub-tasks are separated by . instead of spaces to
unify the syntax with method calls Scala. Also the reflective
code now works not only on builds but any kind of values,
so zero argument members of any types of return values can
simply be called.
This is also a large step towards detangling the reflective
lookup from cbt and turning it into a fully fletched
shell to Scala "native" call solution.
|
|
|
|
|
|
|
|
|
|
|
| |
This should allow for build to add other builds to their dependencies
and interact with them in a type-safe way. And ever regardless it seems
like good practice to never have the same class existing in the same
package or the top-level package even if they don’t end up on the same
classpath. This might also help make stack traces easier to understand.
Also improve error messages for mistakes with the build class, e.g.
constructor, super classes, etc.
|
|
|
|
|
| |
caused by multiple root package Main classes from different subproject
or test projects ending up on the same classpath
|
| |
|
|
|
|
|
| |
and prepares for allowing `run` and `runFlat` at
Dependency instead of Build level
|
| |
|
|
|
|
| |
showing how to do the same in a single build
|
| |
|
| |
|
|
|
|
|
|
| |
because this cbt version has become incompatible with the ones
references there and would lead to Context related errors
part 1 of 2
|
|
|
|
|
|
| |
using lastModified instead of a non-idempotent needsUpdate flag
this fixes a bug where dependees would not be rebuilt if cbt exited
or was killed after dependencies were already rebuilt.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The concurrent hashmap approach to classloader caching was flawed.
Assume you have two concurrently running builds A and B and projects
P2 and P3 depending on project P1. And assume a time sequence where A
compiles P1, then compiles P2, then P1’s sources change, then B compiles
P1, then A compiles P3. At the end P2 and P3 will have different
versions of P1 as their parent classloaders. This is inconsistent.
The easiest way to work around this is making sure only one thread is
changing the classloader cache during it’s entire run. This would mean
either no concurrency or what we have done here, which is letting
threads work on a copy of the cache and replace the original cache in
the end using an atomic operation. This means the thread that finishes
last wins, but for caching that’s fine. Worst case some things aren’t
cached in a concurrent execution.
This change also means that we don’t need concurrent hashmaps for the
classloader cache anymore since no two theads will access the same
hashmap. We still need a concurrent hashmap for the class caches inside
of the classloaders as multiple threads can access the same
classloaders.
|
|
|
|
|
|
|
| |
This isn’t type-safe, but re-using that same hashmap for both keys and
classloaders allows to reduce the number of members in Context. Also
we can re-use the same hashMap for other things as well in the coming
commits, e.g. timestamps.
|
|
|
|
| |
also improve failure output
|
|
|
|
| |
part 2
|
| |
|
| |
|
|
|
|
|
| |
The exact precedence rule of override code vs original code may still
need to be tweaked as we go along.
|
| |
|
| |
|
| |
|
| |
|
| |
|