On 19 Jul 2014, at 2:52 am, Daz DeBoer <darrell.deb...@gradleware.com> wrote:
> 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, … 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. > Binary: Variant, ComponentInstance, … 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. > > 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 > … I think this is an improvement. I like “spec” better than “definition”. -- Adam Murdoch Gradle Co-founder http://www.gradle.org CTO Gradleware Inc. - Gradle Training, Support, Consulting http://www.gradleware.com
