Re: [jbosstools-dev] Question on data virtualization runtimes and where downloadRuntime support belongs
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.zi...
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