Feature request: Implement a mode where a project in a composite build can be processed in isolation

[dljsjr]

It would be nice if a project could be built in isolation (using release dependencies as defined in the build script) without having to clone it multiple times.

Adding a new flag might be okay, another possibility is that if a project's "excludeFromCompositeBuild" is true then you can apply the logic of excluding the rest of the workspace when building inside the isolated project.

[calvertdw]

This functionality exists when you set -PdepthFromWorkspaceDirectory=0.

Issue #41 is focused on making this more transparent. Maybe you have a better name/idea?

[dljsjr]

What if we changed the workspace logic? Instead of every project tracking its depth from the root, which imposes an artificial directory layout constraint, what if a repo group had a property (something like isWorkspaceRoot or something). And then there could be a single boolean (instead of integer) property on all code projects doWorkspaceBuild.

If doWorkspaceBuild is true in a project, then the build plugin traverses upwards through parents until it finds a parent project with isWorkspaceRoot set to true. The first one it finds it uses as the root for the composite build, and if it doesn't find one we could emit an error or something.

This makes the idea of toggling composite/non-composite a little more intuitive, and it's also a hard flag/switch instead of a computed state that the plugin can use when determining whether or not to run in composite build mode. But I don't know the build plugin well enough to know if this would be hard to implement.

[calvertdw]

Some things:

The variable depthFromWorkspaceDirectory (from here out compositeSearchHeight) is only used if that project is the build root. So when projects are being included in the build, compositeSearchHeight in those projects aren't used.

I am trying to get rid of the term "workspace". It confuses Eclipse users where workspace means something different. I would rather keep the terms used in the build plugin to Gradle terms, as I want to eventually delete parts of it as Gradle gets more functionality.

This variable kind of emerged naturally, and I wasn't expecting it to be so useful. Originally there was another boolean called includeBuildsFromWorkspace and I realized that it was just a weaker hacky way of doing compositeSearchHeight = 0, so I removed it.

[calvertdw]

I would like to keep it so that, when building some subproject, like atlas, you have a lot of flexibility for what that build is doing without having to go into other projects/files and change stuff.

[dljsjr]

Makes sense. I would say that the solution then is to just follow along with what #41 is tracking (a better name for the property) and then at some point in the future we need to document the bejesus out of the Build Plugin and make a User's Manual.