The new paths for existing JDV customers will be developer directed initially via maven projects to build vdb images and beetle studio. It was determined that these two worlds will initially be separate. It is not clear if a project level import of a developer workspace will be desirable and more than likely the use of an operator for deployment will require even further changes to the workspace concept.

Each path will have significant changes from JDV. Much of this was captured previously, such as removing support for xml document and function models. However there will be a lot more to add to that list including:

• removal of the vdb version concept
• support only for ddl with some conversion tooling
• all configuration will change - no jboss cli, no .xml, etc. Some system properties will be the same - but they were previously likely set via the eap config.
  • some configuration values in the vdb may need their meaning changed or the new keys - lib, security-domain, system property expansion, role mapping
• it's not clear if a vdb zip archive will be a primary artifact. inclusion of lib jars and resources will need to change if this is the case.
• incremental support for translators - a road map will need to be developed for inclusion
• the packaging / deployment of anything custom will be different - no jboss modules, everything will need to be based upon the ddl/pom/spring. For non-custom paths we will strive to keep direct spring exposure to a minimum - it will probably just be in the configuration property conventions.
  • JCA is also out - custom resource adapters will need to be completely rewritten. a guide to this is tbd. a lot of the development can be combined custom translators, but will need to follow some defined conventions for things like xa to work.
• We are looking to retire the mmx protocol. There are numerous behavior changes with using pg drivers and even the pg protocol TEIID-5622
• Multi-source support may not be initially available. Dynamic multi-source sources (supported in EAP though the cli and the adminapi) will not work.

The ui will have additional restrictions, such as:

• only a single virtual schema/model. this will require most customer scenarios to be rewritten as virtual base layers are typically included.
• metadata import options will be more limited than Teiid Designer. More than likely we'll also need to enforce a paradigm of each source represents only one source schema.