GitHub user ahgittin opened a pull request:
https://github.com/apache/incubator-brooklyn/pull/993
Introduce a type registry as a simplified catalog
Currently simply provides a compatible stateless facade to catalog. A lot
more to do -- commit describes the plans -- but I want early review and of
course to try to avoid any merge conflicts!
Idea of type registry is that this will allow us to generalize atop types
(soon adding "beans" alongside the "specs" which is all that catalog previously
supported) in order to:
* simplify persistence/rebind across versions
* define types for local resolution, e.g. when uploading a plan
* define types to be used in specialized YAML, e.g. listing tasks for an
effector
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/ahgittin/incubator-brooklyn type-registry
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/incubator-brooklyn/pull/993.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #993
----
commit dc968f9d0dab816df6f6993399f0a84ce5e8810c
Author: Alex Heneveld <[email protected]>
Date: 2015-10-29T22:28:14Z
introduce BrooklynTypeRegistry and start migrating Catalog to it
remove some of the deprecated Catalog methods, and change many lookups to
catalog to lookup in the type registry.
NEXT - immediate low-hanging fruit:
* move the TypeReg classes to where they belong
* finish changing lookups in catalog so all reads go through registry
(but writes still go to catalog)
NEXT - provide new features:
* add TypeReg for Beans, so types can be registered (at least by brooklyn
startup code) for relationships, tasks, etc
* new TypeReg REST API, including allowing completion proposals for yaml
* new PlanToSpecTransformer API, and use the TypeImplementation.kind to
pick the transformer to use, so we don't try the stupid
attempt-load-with-any-transformer
NEXT - clean up:
* persist registered types and REST API and addToCatalog allows defining
new (e.g. new relationships)
* get rid of catalog, or at least deprecate it and make all *writes* to
TypeRegistry, and it stores things
* optionally, allow interim/multiple TypeRegistry instances to be used when
loading catalogs or to resolve deep blueprints
commit 4585e2c496a528fe83bcbf2b76bf41603c4fda7c
Author: Alex Heneveld <[email protected]>
Date: 2015-10-30T02:50:34Z
fix package name of RelationshipType
----
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at [email protected] or file a JIRA ticket
with INFRA.
---
