Mailing-List: contact dev-help@brooklyn.incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@brooklyn.incubator.apache.org
From: ahgittin <git@git.apache.org>
To: dev@brooklyn.incubator.apache.org
Reply-To: dev@brooklyn.incubator.apache.org
References: <git-pr-993-incubator-brooklyn@git.apache.org>
In-Reply-To: <git-pr-993-incubator-brooklyn@git.apache.org>
Subject: [GitHub] incubator-brooklyn pull request: Introduce a type registry
 as a si...
Content-Type: text/plain
Message-Id: <20151030033439.6257DDFA0B@git1-us-west.apache.org>
Date: Fri, 30 Oct 2015 03:34:39 +0000 (UTC)

GitHub user ahgittin reopened 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 <alex.heneveld@cloudsoftcorp.com>
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 <alex.heneveld@cloudsoftcorp.com>
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 infrastructure@apache.org or file a JIRA ticket
with INFRA.
---