When I went digging into Ivy's code base I discovered that it's been
checking if the repository layout pattern ends with M2_PATTERN to use
maven-metadata.xml, which for sbt would return false since we customize
the mattern -
https://github.com/apache/ant-ivy/blob/2.3.0/src/java/org/apache/ivy/plu
gins/resolver/IBiblioResolver.java#L497-L499
To pass File => Unit callback across the classloader boundary
I am encoding it as a java.util.List[File] by overriding
method.
This was needed since Java didn't allow me to cast
from one classloader to the other.
This provides a convenience function for running an input task from the
extracted state. This is particularly useful for commands, release steps
etc that may want to run input tasks, like scripted.
Cached resolution saves dynamic mini graphs (including subproject
graphs) timestamped to the logical clock (State).
This enables graph caching across the subprojects.
On the other hand, it creates garbage that becomes stale almost
immediately. Prior to #2030 fix, this garbage would reach 1GB+.
This fix timestamps these graphs using calendar date, and cleans them
up after a day.
- On some of the builds graph.json is reaching 250MB+
- JSON parsing alone takes hours
- 97% of the content are caller info
- This change summarizes all callers into one (zero caller would have
correctness issues)
The pom generation code tries its best to map Ivy's configurations
to Maven scopes; however, sources and javadoc artifacts cannot be
properly mapped and they currently are emitted as dependencies in
the default scope (compile). That may lead to the source/doc jars
being erroneously processed like regular jars by automated tools.
Arguably, the source/docs jars should not be included in the pom
file as dependencies at all. This commit filters out the
dependencies that only appear in the sources and/or javadoc Ivy
configurations, thereby preventing them from appearing in the
final pom file.