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" <adam.murd...@gradleware.com> wrote: > > 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 > > > >
