G'day The new 'native runtime' support (C/C++/etc) introduced a powerful component model for defining the software you are trying to build: libraries, applications, variants, buildTypes, etc. We're now rolling this concept into the jvm runtime, with a new set of 'component' plugins that will give you a new way to define jvm libraries, jvm applications and jvm web applications built from Java/Scala/Groovy.
The concept of a 'component' will also be used as we develop variant-aware dependency management. So the jvm library you're building will depend on other jvm libraries, and a native library will depend on native libraries, etc. The question I have is the terminology and naming scheme used for classes within the component model. *Components and Binaries* We're currently using 'component' to refer to a jvm library, native library or web app. So "commons-logging" is a component, as is 'cunit', as is a JEE wep app. We then use 'binary' to refer to a specific variant of that component, such as 'cunit-4.2-win-x86-debug'. In some ways, we're thinking of the different versions of the library as different binaries of the same component, too. For example in the java space a dependency on 'MyJvmLibrary' will be resolved to a specific JvmLibraryBinary, such as 'my-jvm-library-2.0-jdk1.5-obfuscated'. We can probably find better names for these 2 concepts. Options: Component: SoftwareComponent, SoftwareProduct, Module, ... Binary: Variant, ComponentInstance, ... Alternatives and suggestions would be welcome. *Hierarchy separation* There's a difference between a definition of a library (something you're building) and a library you're depending on (something you're using). There are 2 parallel hierarchies, and Gradle will take a "library definition" with "variant definitions" and build it into a "library" with "variants". Currently we're using the "Project" prefix for things you're building, but I'd like to find something better. So a NativeLibrary is something you'd depend on and a ProjectNativeLibrary is something you're building. So we have: - Component | ProjectComponent - Binary | ProjectBinary - JvmLibrary | ProjectJvmLibrary - JvmLibraryBinary | ProjectJvmLibraryBinary - NativeExecutable | ProjectNativeExecutable - etc I'm thinking of changing to use the "Spec" suffix in place of the "Project" prefix, but "Definition" also works as a suffix. So options: - ComponentSpec, JvmLibrarySpec, SharedLibraryBinarySpec - ComponentDefinition, JvmLibraryDefinition, SharedLibraryBinaryDefinition - ... Maybe there are some better patterns for maintaining a parallel hierarchy like this. I'd be open to suggestions. *Summary* These are not difficult changes to make but they will be disruptive and pervasive. So I'm seeking feedback (and hopefully agreement) before moving forward. Thanks -- Darrell (Daz) DeBoer http://www.gradleware.com
