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.
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:
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:
Maybe there are some better patterns for maintaining a parallel hierarchy like this. I'd be open to suggestions.
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.
Darrell (Daz) DeBoer
One problem with ‘component’ is that it generally means ‘part of something else’. Almost all of the things we build are in fact components of something larger, but are not necessarily so.
I like ‘product’ as this communicates the point of the whole exercise.
I’d leaning towards not including ‘Software’ in the name of whatever we choose, as we should be able to model things like, say, books or articles as buildable things.
However, we don’t really need to go super-abstract here. If we find we need a more general concept, we can introduce it in a backwards compatible way later. Same for more concrete concepts too.
I’d like a term that doesn’t imply that the thing is some representation of a component/product. It should imply that the thing is usable in some way: a package, a binary, a resource, an artefact, an assembly.
I think this is an improvement. I like “spec” better than “definition”.
On Jul 21, 2014 8:54 PM, "Adam Murdoch" <[hidden email]> wrote:
On 22 Jul 2014, at 12:35 pm, Andrew Oberstar <[hidden email]> wrote:
Ideally, it would also cover non-software artefacts such as books, papers, reports and other documentation. But this isn’t as important a goal. We might just live with something like ‘buildable thing’ to cover the universe of things Gradle might produce.
Right, it implies some binary format, and it also suggests that it is a single file, which often isn't the case.
|Free forum by Nabble||Edit this page|