IDE plugins should be more uniform in their architecture

[lacasseio]

The core concept that repeats between IDEs are:

• IDE Workspace: The root container containing all projects (or component) to edit
• IDE Project: A component to build. Sometimes the test components are attached to the tested component's project other time it must be a separate project. This should be handled at the specific IDE implementation. Each project can have multiple build configuration. A project can be unbuildable for some reason.
• IDE Build Configuration: A configuration for building a variant of the component. For example, a debug application or x86_64 release library.
• IDE Source Sets or Group or Filters: Logical separation of the sources. For example, Sources, Headers, etc. A root source set should always exist.
• IDE Debug Configuration: A configuration for debugging a variant of the component.

For each IDE, we should focus on delegating to Gradle, whatever that means for the IDE in question. It also means the IDE should have the least configuration as possible. Any behaviour configuration should come out from the Gradle model. If something must be configured in the IDE, it should be a configuration on the Gradle model as well with a clear use case.

Users can be allowed to compose new IDE workspace and project according to a set of simple public API meaning they can't just configure every single detail of an IDE using the APIs. This means we may be opinionated through those APIs. For example, Intellisense for Xcode is built another target. There may be other ways to do this, but that is an implementation detail that we use, the users can't change it or configure it directly and it may change in the future to some other techniques. Another example is Visual Studio fake an NMake project. This may change in the future so the details of this should be an implementation detail and not exposed to the users.

Having a stronger opinion on how IDE integration work with Gradle will allow for more uniform support and more cross-cutting features.

Other points we should make here is the importance of the public API:

• Should we allow IDE plugins to be applied by type?
• Are the IDE tasks type important for the users?

[lacasseio]

I feel like we should be more aggressive in what we make internal and implementation detail. For example, I would say that all IDE types that aren't used for configuring the extension (that users can use) should be internal. It forces the IDE plugins to be more closed down and focus on bridging the IDE and Gradle instead of allowing every possibility. What is the general feeling about this?

[lacasseio]

We already have IdeWorkspace. I would move with incremental PRs that introduce IdeWorkspace to the idea and eclipse plugins followed by moving toward Introducing the other generic concept to all plugins at the same time aka IdeProject, IdeSourceSet, IdeBuildConfiguration, IdeDebugConfiguration. Each implementation would type those generic concepts to the specific naming of the IDE. I would also have a wave of moving types to internal ones to make the public API spread smaller within a couple release (for native) and next major release (for Java).