[jbosstools-dev] Question on data virtualization runtimes and where downloadRuntime support belongs

[Rob Stryker]

On 04/10/2015 04:33 AM, phantomjinx wrote:
>> >https://jira.jboss.org/jira/browse/JBIDE-19574   ?
>> >
>> >With respect for runtime detection I guess that is a completely separate
>> >story.
>> >
>> >Is teiid a separate server like SOA-P/FSW or is Teiid something that is
>> >installed into an existing EAP based server ?
> Yes, Teiid is a module installed on top of an existing EAP server that provides its own API for
> deployment of artifacts, using the jb admin port, JDBC querying of modelled db connections using its
> own port (31000) and installs its own susbsytems for translators, data sources etc.
>

Teiid itself is something that's installed on top of an EAP server. The 
"Data Virtualization" product, however, comes only in an installer form; 
no simple unzip. So at least in terms of downloading the runtime, DV 
requires special treatment, not just an unzip. (If there's a simple 
unzip available, I haven't seen it on download manager; I've only seen 
the installer there).

However you can also download "Teiid + EAP" which *does* respond to a 
simple unzip.  See, for example, 
https://sourceforge.net/projects/teiid/files/teiid-8.10.0.Final-server.zip/download

So while the project seems to allow a simple unzip, the product does not.

I'm honestly OK with both code living in either place, but  it's more a 
concern of duplication of effort / code. If I have ASTools performing 
the runtime detection, there's a few risks:

    1) I may not personally stay bleeding-edge up-to-date on teiid / dv 
structural changes, what subsystems to use for detection, etc etc, and 
will require help from teiid at keeping my detection accurate

    2) If ASTools is in charge of detecting, Teiid Designer (who I 
assume goes GA several months later) may find themselves limited. For 
example if a new Teiid Runtime / DV release comes out in the interval 
between our GA and Teiid's GA. Teiid Designer will either need to 
consume only what detection we provided, or, work around it by adding 
detection support for newer runtimes in their own code. Then we have 
duplication, and it becomes a split responsibility with code all over 
the place. Could get messy.

I personally think it makes more sense for the detection and download 
logic to both live in Teiid Designer codebase, based primarily on these 
two risks. I'm aware that it limits the usefulness of ASTools standalone 
for users wanting to use DV / Teiid Runtime, but I also think we should 
be pushing people using teiid / DV to also use Teiid Designer anyway.

I'll be glad to do the bulk of the work regardless where it 'lives', of 
course, but I just wanted to get some consensus on where the code SHOULD 
live first.



- Rob Stryker