Skip to content

Split components into separate repositories

For now, everything in the Soong ecosystem is in the same repository - with APIs still changing regularly, it's much simpler than trying to keep dependencies in sync across repos. Once the APIs are fairly stable, though, and definitely before the 1.0.0 release, we'll want to split things up. The proposed structure is:

Those last three are pretty obvious split points, but we have some less clear ones:

  • Should OptionsResolverComponent and the base classes extending it - i.e., the integration with Symfony OptionsResolver - go in the soong repo, go into their own repo, or go into something like a soong/basics repo?
  • Should our basic Property and Record classes (and their factories) go into the soong repo, go into their own repo, or go into something like a soong/basics repo?
  • Should our basic Task, EtlTask, and TaskPipeline classes go into the soong repo, go into their own repo, or go into something like a soong/basics repo?
  • Should the most commonly used Transformer classes like Copy and KeyMapLookup go into the soong repo, go into their own repo, or go into something like a soong/basics repo?
  • Should the most commonly used Filter classes like Select go into the soong repo, go into their own repo, or go into something like a soong/basics repo?
  • Should basic components useful for testing and debugging, like ArrayExtractor and the VarDump loader, go into the soong repo, go into their own repo, or go into something like a soong/basics repo?

At the moment, my inclination is to move the latter bunch (except the testing/debugging stuff, which is used by test base classes) to a soong/basics (or somesuch name) repo and we can then see if there's any motivation to split things further.

To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information