Naming scheme for component model

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Naming scheme for component model

Daz DeBoer-2
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
Reply | Threaded
Open this post in threaded view
|

Re: Naming scheme for component model

Adam Murdoch

On 19 Jul 2014, at 2:52 am, Daz DeBoer <[hidden email]> 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



Reply | Threaded
Open this post in threaded view
|

Re: Naming scheme for component model

Andrew Oberstar

Would something like minified JavaScript be in scope here? If so, binary may be too limiting

Andrew Oberstar

On Jul 21, 2014 8:54 PM, "Adam Murdoch" <[hidden email]> wrote:

On 19 Jul 2014, at 2:52 am, Daz DeBoer <[hidden email]> 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



Reply | Threaded
Open this post in threaded view
|

Re: Naming scheme for component model

Adam Murdoch

On 22 Jul 2014, at 12:35 pm, Andrew Oberstar <[hidden email]> wrote:

Would something like minified JavaScript be in scope here?

Yes, absolutely. It should cover any kind of software artefact, including those that happen to be encoded as text instead of some binary format, such as libraries or apps made up of javascript, css, html and the like.

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.

If so, binary may be too limiting

Right, it implies some binary format, and it also suggests that it is a single file, which often isn't the case.


Andrew Oberstar

On Jul 21, 2014 8:54 PM, "Adam Murdoch" <[hidden email]> wrote:

On 19 Jul 2014, at 2:52 am, Daz DeBoer <[hidden email]> 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





--
Adam Murdoch
Gradle Co-founder
http://www.gradle.org
CTO Gradleware Inc. - Gradle Training, Support, Consulting
http://www.gradleware.com