We are proposing to make the "execution" feature set optional. We could do this now by tweaking our feature.xml and update-site build if we didn't have hard dependencies. Key will be to perform any necessary refactoring to allow this to happen. We think we can. Barry ----- Original Message ----- From: "John Doyle" <jdoyle(a)redhat.comTo: "Barry Lafond" <blafond(a)redhat.comCc: "Steve Jacobs" <sjacobs(a)redhat.com&gt;, "teiid-designer-dev" <teiid-designer-dev(a)lists.jboss.orgSent: Thursday, February 11, 2010 1:42:48 PM GMT -06:00 US/Canada Central Subject: Re: [teiid-designer-dev] 7.0 Release Planning - REV 2 Hey Barry, Do I understand correctly that this is an implementation decision, and not a statement about how these features would be packaged? In other words, outside of the milestones listed below, do you expect that we will continue to ship these two features together, or do you envision that we might make them available independently? ~jd ----- "Barry Lafond" <blafond(a)redhat.com&gt; wrote: Please feel free to comment on the following portion of our 7.0 Release plans. To better accommodate changes required for JBoss Tools integration and Teiid 7.0 integration we propose to modify/refactor our current code-base in the following way. We propose to separate Teiid Designer code into Design-time code and Run-time code resulting in two installable Eclipse-based feature sets. • Design-time is specified as all modeling exercises short of creating/editing/executing VDB's or previewing data. • Users can create model projects, import/create/edit models, organize models into projects and folders, check-in/check-out from their favorite repository, etc.... • UDF modeling will still be available. • Importing data for model creation will NOT auto-create connectors and data preview feature will not be available. • The VDB will NOT be a visible concept. • Run-time refers to any data preview or VDB execution logic • This feature will initially depend on installed Design-time features to run. • Users can create/edit/execute VBD's . • Importing data for model creation will auto-create connectors. • Data Preview will be available for design-time modeling. • Auto-deploy VDB to Teiid server (stretch) • Modify DQP/SQL Explorer plugins to execute VDB via DTP's jdbc connection to Teiid. • No Designer-related jar management for UDF of JDBC/JDBC connections (assumed to be in place on server) Motivating factors for making these changes to Designer include: • Creation of lighter-weight tool which is NOT dependent on Teiid runtime code-base will facilitate easier development of the modeling features. • Eliminates duplicate code maintenance between Designer and Teiid. • Allows independent run-time feature development. • Simplifies run-time features by removing non-essential Eclipse dependencies (EMF, UML2, etc...) There will be a few milestones related to our 7.0 release M1 - Design-time tooling feature set (modeling only) • separation of any preview data or vdb execution from modeling • keep current JDBC import methodology M2 - Run-time execution tooling feature set (add-on to design-time feature set) • utilizes current SQL Explorer M3 - Integration of Designer with DTP functionality • remove SQL Explorer and replace with common DTP data source querying • customize through DTP to perform preview data queries. Barry LaFond > Teiid Designer Project > _______________________________________________ teiid-designer-dev mailing list teiid-designer-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/teiid-designer-dev

On Feb 11, 2010, at 2:05 PM, John Doyle wrote: I'm not sure what you mean by 'option', but to clarify a bit more, the main motivation behind the 2 features revolves around ensuring the project remains useable by itself, meaning outside of bundled distribution options such as within JBT or JBDS. Nothing else Barry discussed is a motivating factor, but rather side-effects of moving in this direction. Thus, there would be one feature in our update site for designer that does not include any runtime capability, and another feature that adds runtime to the base feature. The core feature would, by definition, but more limited than both together, but still usable just to model. In the future, we could get the runtime feature to not depend upon the design-time feature, potentially allowing for a more lightweight installation by testers and the like that only care about runtime and not the modeling aspects. So, not sure if the idea of turning on an option applies. Thanks, JPAV