9:39 p.m.
Hey all:
So, astools has historically housed almost all the download-runtime code
for various jboss runtimes. This changed a bit, however, when karaf /
fuse / serviceworks came on the scene. The FuseIDE code now provides a
home for their server bean loaders (things that accurately identify
local installs), their runtime detectors (to work with turning those
installs into IRuntime objects in eclipse), and their download runtimes
(to know where to fetch them / download them / install them).
Where does Data Virtualization / teiid fit in for this? I'm not very
familiar with what teiid adds on to our server types. It seems they
don't add their own server types, so that would suggest I should put
their runtime detection code in with astools. However, if they require
any special / teiid-only property keys to be set when creating the
server, that would indicate they should handle the import and not me,
since I won't have access to their custom keys. This is important for
runtime detection, as I don't want to return a half-complete runtime /
server with missing flags that's unusable for teiid.
So the question is: where should the code for recognizing local DV
installs, downloading DV runtimes, etc, live? ASTools, or Teiid?
- Rob Stryker
2:53 a.m.
To summarize (and cc Barry since he is the one doing teiid tooling)
So the question is: where should the code for recognizing local DV
installs, downloading DV runtimes, etc, live? ASTools, or Teiid?
I do not see any reason to why ASTools should handle download of Teiid.
Shouldn't Teiid just do this using
the api we provide like done for the others ?
I assume this is all in context of
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 ?
Does teiid even need "special" recognition handling ?
how does teiid today figure out wether an EAP server needs to show Teiid
features in the server view ?
/max
http://about.me/maxandersen
3:33 a.m.
Rob, Max,
See inline ...
On 10/04/15 08:53, Max Rydahl Andersen wrote:
To summarize (and cc Barry since he is the one doing teiid tooling)
> So the question is: where should the code for recognizing local DV
> installs, downloading DV runtimes, etc, live? ASTools, or Teiid?
I do not see any reason to why ASTools should handle download of Teiid.
Shouldn't Teiid just do this using
the api we provide like done for the others ?
I would strongly support Teiid doing it itself. At the moment, the teiid-runtime is
carried by the
Teiid Designer plugins and is designed to be backward compatible over Teiid versions and
to some
extent across jboss versions (7/8). Thus, install Teiid Designer and you get support for
whatever
Teiid version has been installed on your jboss server.
I assume this is all in context of
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.
Does teiid even need "special" recognition handling ?
how does teiid today figure out wether an EAP server needs to show Teiid
features in the server view ?
The Teiid Designer plugins take care of this by
querying the EAP server for the relevent subsystems
that Teiid would be installed to. It also finds the version of Teiid installed and
provides this
back to the modelling environment as the modelling version (determines
parsing/resolving/validating
of SQL queries for example). The UI for Teiid in the Server View is tacked onto the
existing View
using one of the extension points already available.
Essentially, this means if you want to model/deploy a Virtual Database (VDB) to Teiid
using Eclipse
then install the Teiid Designer plugins and you get all the extra pieces required.
Hope this helps.
PGR
--
Paul Richardson
* p.g.richardson(a)phantomjinx.co.uk
* p.g.richardson(a)redhat.com
* pgrichardson(a)linux.com
"I know exactly who reads the papers ...
* The Daily Mirror is read by people who think they run the country.
* The Guardian is read by people who think they ought to run the country.
* The Times is read by people who do actually run the country.
* The Daily Mail is read by the wives of the people who run the country.
* The Financial Times is read by the people who own the country.
* The Morning Star is read by the people who think the country ought to be run by
another country.
* The Daily Telegraph is read by the people who think it is."
Jim Hacker, Yes Minister
11:52 a.m.
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
12:22 p.m.
On 10 April 2015 17:52:56 GMT+01:00, Rob Stryker <rstryker(a)redhat.com> wrote:
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
Little perplexed as to what code you want to "put" in Astools or Designer. As I
said, the latter already detects the installed version of teiid.
As to DV v Teiid. The product of DV is EAP+Teiid wrapped up in a single installer. The
layout ends up slightly different with the product having a dedicated DV directory
containing the teiid modules but the result is the same.
PGR
2:13 p.m.
After some discussion with PGR, we think it makes more sense for the
detection to live in the Teiid Designer repository.
Teiid Designer currently only has code for detecting teiid in *running*
servers, with no support for identifying a Teiid installation in servers
that aren't running. This makes sense for their use case (server may be
remote) but is not useful for runtime detection at all.
TD currently is not involved in the server creation at all, but rather
just adds listeners so that once a server is added, or started, they can
begin their configuration / build up their model. They also provide
editor extensions that allow setting fields on the IServerWorkingCopy.
*Barry*: One thing that would help tremendously with identifying
installations in non-running local servers is if I could have a map of
Teiid / DV releases and what underlying JBoss / Wildfly / EAP versions
they correspond to. What I've heard so far is that Teiid 7.x was based
on JBoss 5, while the 8.x stream is for AS7. It's pretty important to
get a full mapping of supported releases to their underlying JBoss
version, though. This way I can properly implement the Server Bean
Loaders / Runtime detection.
One final thing to note, which I think we should bring up to the Teiid
runtime team directly, is that DV product properly uses the layer system
in JBoss 7. It has the expected
org/jboss/as/product/dv/dir/META-INF/MANIFEST.MF file, with the
expected attribute JBoss-Product-Release-Version: 6.1.0...
But the community releases of Teiid *do not*. They simply put
everything in modules/system/layers/base, with no clear way of
identifying a version. If I wanted to look at the version here, I'd need
to introspect
teiid-8.10.0.Final/modules/system/layers/base/org/jboss/teiid/api/main/teiid-api-8.10.0.Final.jar
and look at it's manifest.mf for the Bundle-Version, which so far seems
accurate.
With all this in mind, it should be relatively painless (once I get that
version mapping from Barry) to get runtime detection + downloading
supported for Teiid Runtime / DV. There may be some issues in
stacks.yaml (since I'm not too familiar with all the bom stuff) but I
expect the version mapping will help me to properly pull from other
parts of stacks.yaml without issue.
- Rob Stryker
- Rob Stryker
5:45 a.m.
I'm still not following/seeing why Teiid Designer needs runtime
detection if it detects it at runtime ?
/max
After some discussion with PGR, we think it makes more sense for the
detection to live in the Teiid Designer repository.
Teiid Designer currently only has code for detecting teiid in
*running* servers, with no support for identifying a Teiid
installation in servers that aren't running. This makes sense for
their use case (server may be remote) but is not useful for runtime
detection at all.
TD currently is not involved in the server creation at all, but rather
just adds listeners so that once a server is added, or started, they
can begin their configuration / build up their model. They also
provide editor extensions that allow setting fields on the
IServerWorkingCopy.
*Barry*: One thing that would help tremendously with identifying
installations in non-running local servers is if I could have a map of
Teiid / DV releases and what underlying JBoss / Wildfly / EAP versions
they correspond to. What I've heard so far is that Teiid 7.x was based
on JBoss 5, while the 8.x stream is for AS7. It's pretty important to
get a full mapping of supported releases to their underlying JBoss
version, though. This way I can properly implement the Server Bean
Loaders / Runtime detection.
One final thing to note, which I think we should bring up to the Teiid
runtime team directly, is that DV product properly uses the layer
system in JBoss 7. It has the expected
org/jboss/as/product/dv/dir/META-INF/MANIFEST.MF file, with the
expected attribute JBoss-Product-Release-Version: 6.1.0...
But the community releases of Teiid *do not*. They simply put
everything in modules/system/layers/base, with no clear way of
identifying a version. If I wanted to look at the version here, I'd
need to introspect
teiid-8.10.0.Final/modules/system/layers/base/org/jboss/teiid/api/main/teiid-api-8.10.0.Final.jar
and look at it's manifest.mf for the Bundle-Version, which so far
seems accurate.
With all this in mind, it should be relatively painless (once I get
that version mapping from Barry) to get runtime detection +
downloading supported for Teiid Runtime / DV. There may be some
issues in stacks.yaml (since I'm not too familiar with all the bom
stuff) but I expect the version mapping will help me to properly pull
from other parts of stacks.yaml without issue.
- Rob Stryker
- Rob Stryker
/max
http://about.me/maxandersen
12:21 p.m.
On 04/13/2015 06:45 AM, Max Rydahl Andersen wrote:
I'm still not following/seeing why Teiid Designer needs runtime
detection if it detects it at runtime ?
/max
Download Runtime consists of 2 parts: 1 downloading + installing, and
2: making the server adapter (ie runtime detection).
Currently there are no server beans that can identify a DV / teiid
installation. So the runtime would only be recognized as an "EAP-Based
Product" by the code in ASTools, and it won't be given the most optimal
name... basically the same situation JPP was in before we added custom
server beans for them. It's a small issue in some ways, but, it's better
if all our APIs (including server bean loader) ensure the most accurate
results possible, and if it's possible for them to identify a DV / Teiid
Runtime installation, it's better to do it than to not do it.
> After some discussion with PGR, we think it makes more sense for the
> detection to live in the Teiid Designer repository.
>
> Teiid Designer currently only has code for detecting teiid in
> *running* servers, with no support for identifying a Teiid
> installation in servers that aren't running. This makes sense for
> their use case (server may be remote) but is not useful for runtime
> detection at all.
>
> TD currently is not involved in the server creation at all, but
> rather just adds listeners so that once a server is added, or
> started, they can begin their configuration / build up their model.
> They also provide editor extensions that allow setting fields on the
> IServerWorkingCopy.
>
> *Barry*: One thing that would help tremendously with identifying
> installations in non-running local servers is if I could have a map
> of Teiid / DV releases and what underlying JBoss / Wildfly / EAP
> versions they correspond to. What I've heard so far is that Teiid 7.x
> was based on JBoss 5, while the 8.x stream is for AS7. It's pretty
> important to get a full mapping of supported releases to their
> underlying JBoss version, though. This way I can properly implement
> the Server Bean Loaders / Runtime detection.
>
> One final thing to note, which I think we should bring up to the
> Teiid runtime team directly, is that DV product properly uses the
> layer system in JBoss 7. It has the expected
> org/jboss/as/product/dv/dir/META-INF/MANIFEST.MF file, with the
> expected attribute JBoss-Product-Release-Version: 6.1.0...
>
> But the community releases of Teiid *do not*. They simply put
> everything in modules/system/layers/base, with no clear way of
> identifying a version. If I wanted to look at the version here, I'd
> need to introspect
>
teiid-8.10.0.Final/modules/system/layers/base/org/jboss/teiid/api/main/teiid-api-8.10.0.Final.jar
> and look at it's manifest.mf for the Bundle-Version, which so far
> seems accurate.
>
> With all this in mind, it should be relatively painless (once I get
> that version mapping from Barry) to get runtime detection +
> downloading supported for Teiid Runtime / DV. There may be some
> issues in stacks.yaml (since I'm not too familiar with all the bom
> stuff) but I expect the version mapping will help me to properly pull
> from other parts of stacks.yaml without issue.
>
> - Rob Stryker
>
> - Rob Stryker
/max
http://about.me/maxandersen
2:49 a.m.
On 13 Apr 2015, at 19:21, Rob Stryker wrote:
On 04/13/2015 06:45 AM, Max Rydahl Andersen wrote:
> I'm still not following/seeing why Teiid Designer needs runtime
> detection if it detects it at runtime ?
>
> /max
Download Runtime consists of 2 parts: 1 downloading + installing, and
2: making the server adapter (ie runtime detection).
Currently there are no server beans that can identify a DV / teiid
installation. So the runtime would only be recognized as an "EAP-Based
Product" by the code in ASTools, and it won't be given the most
optimal name... basically the same situation JPP was in before we
added custom server beans for them. It's a small issue in some ways,
but, it's better if all our APIs (including server bean loader)
ensure the most accurate results possible, and if it's possible for
them to identify a DV / Teiid Runtime installation, it's better to do
it than to not do it.
Ah, I forgot about the naming aspect. Sure this does make sense and
definitely something that is better of in Teiid IMO.
/max
http://about.me/maxandersen
1:36 p.m.
Rob,
Paul gave you the rundown on Teiid Designer's discovery of Teiid runtime versions
after server start-up and that we contribute providers & actions to the Server View.
Designer is designed to be backwards compatible (7.7 > 9.x) in terms of working with
Teiid runtime admin and jdbc API. So in a sense, Designer doesn't care what Teiid
runtime is installed. If it makes it easier on the user for server-set-up if JBT
discovers/downloads/installs Teiid runtimes I'm in favor of it.
Teiid Teiid
Designer
7.7 7.7
8.0 8.2
8.1 8.3
8.2 - 8.4 8.4
8.5 - 8.6 8.7
9.0 8.8
9.1 8.9 (planned)
9.2 8.11 (planned)
I've cc'd Ramesh Reddy on the Teiid project team and Van Halber, the DV build guy.
They would know the version mappings between AS and Teiid runtimes.
You are correct that Teiid 7.x was based on JBoss 5, while the 8.x stream is for AS7. Note
also that Teiid 8.x community releases were compatible with EAP 6.x Alpha releases, not
Final. Those are reserved for DV/Product releases.
So my understanding is that the server configurations are fairly different between project
and product.
Barry
----- Original Message -----
From: "Max Rydahl Andersen" <manderse(a)redhat.com>
To: "Rob Stryker" <rstryker(a)redhat.com>
Cc: "phantomjinx" <p.g.richardson(a)phantomjinx.co.uk>,
"jbosstools-dev
jbosstools-dev" <jbosstools-dev(a)lists.jboss.org>, "Barry Lafond"
<blafond(a)redhat.com>
Sent: Monday, April 13, 2015 5:45:48 AM
Subject: Re: [jbosstools-dev] Question on data virtualization runtimes and
where downloadRuntime support belongs
I'm still not following/seeing why Teiid Designer needs runtime
detection if it detects it at runtime ?
/max
> After some discussion with PGR, we think it makes more sense for
the
> detection to live in the Teiid Designer repository.
>
> Teiid Designer currently only has code for detecting teiid in
> *running* servers, with no support for identifying a Teiid
> installation in servers that aren't running. This makes sense for
> their use case (server may be remote) but is not useful for runtime
> detection at all.
>
> TD currently is not involved in the server creation at all, but rather
> just adds listeners so that once a server is added, or started, they
> can begin their configuration / build up their model. They also
> provide editor extensions that allow setting fields on the
> IServerWorkingCopy.
>
> *Barry*: One thing that would help tremendously with identifying
> installations in non-running local servers is if I could have a map of
> Teiid / DV releases and what underlying JBoss / Wildfly / EAP versions
> they correspond to. What I've heard so far is that Teiid 7.x was based
> on JBoss 5, while the 8.x stream is for AS7. It's pretty important to
> get a full mapping of supported releases to their underlying JBoss
> version, though. This way I can properly implement the Server Bean
> Loaders / Runtime detection.
>
> One final thing to note, which I think we should bring up to the Teiid
> runtime team directly, is that DV product properly uses the layer
> system in JBoss 7. It has the expected
> org/jboss/as/product/dv/dir/META-INF/MANIFEST.MF file, with the
> expected attribute JBoss-Product-Release-Version: 6.1.0...
>
> But the community releases of Teiid *do not*. They simply put
> everything in modules/system/layers/base, with no clear way of
> identifying a version. If I wanted to look at the version here, I'd
> need to introspect
>
teiid-8.10.0.Final/modules/system/layers/base/org/jboss/teiid/api/main/teiid-api-8.10.0.Final.jar
> and look at it's manifest.mf for the Bundle-Version, which so far
> seems accurate.
>
> With all this in mind, it should be relatively painless (once I get
> that version mapping from Barry) to get runtime detection +
> downloading supported for Teiid Runtime / DV. There may be some
> issues in stacks.yaml (since I'm not too familiar with all the bom
> stuff) but I expect the version mapping will help me to properly pull
> from other parts of stacks.yaml without issue.
>
> - Rob Stryker
>
> - Rob Stryker
/max
> http://about.me/maxandersen
10:20 p.m.
The usecase you are going after is download the Teiid runtime based on the Designer? Or
you want to download the Teiid runtime based on the EAP? If it is former, Designer has
strong preferences as to which Teiid runtime it works with, but in a given major release
it work more seamless. If it is later
EAP 5.1 is used with Teiid 7.x
EAP 6.1 Alpha, up to Teiid 8.8
EAP 6.3 Alpha, Teiid 8.9, 8.10
We are planning for
EAP 6.4.Alpha for Teiid 8.11
No WildFly support yet. If you think a marker file like in the MANIFEST.MF makes it
easier, we are open to add such file.
Ramesh..
----- Original Message -----
Rob,
Paul gave you the rundown on Teiid Designer's discovery of Teiid
runtime
versions after server start-up and that we contribute providers & actions to
the Server View. Designer is designed to be backwards compatible (7.7 > 9.x)
in terms of working with Teiid runtime admin and jdbc API. So in a sense,
Designer doesn't care what Teiid runtime is installed. If it makes it easier
on the user for server-set-up if JBT discovers/downloads/installs Teiid
runtimes I'm in favor of it.
Teiid Teiid
Designer
7.7 7.7
8.0 8.2
8.1 8.3
8.2 - 8.4 8.4
8.5 - 8.6 8.7
9.0 8.8
9.1 8.9 (planned)
9.2 8.11 (planned)
I've cc'd Ramesh Reddy on the Teiid project team and Van
Halber, the DV build
guy. They would know the version mappings between AS and Teiid runtimes.
You are correct that Teiid 7.x was based on JBoss 5, while the 8.x
stream is
for AS7. Note also that Teiid 8.x community releases were compatible with
EAP 6.x Alpha releases, not Final. Those are reserved for DV/Product
releases.
So my understanding is that the server configurations are fairly
different
between project and product.
Barry
----- Original Message -----
> From: "Max Rydahl Andersen"
<manderse(a)redhat.com>
> To: "Rob Stryker" <rstryker(a)redhat.com>
> Cc: "phantomjinx" <p.g.richardson(a)phantomjinx.co.uk>,
"jbosstools-dev
> jbosstools-dev" <jbosstools-dev(a)lists.jboss.org>, "Barry
Lafond"
> <blafond(a)redhat.com>
> Sent: Monday, April 13, 2015 5:45:48 AM
> Subject: Re: [jbosstools-dev] Question on data virtualization runtimes and
> where downloadRuntime support belongs
> I'm still not following/seeing why Teiid Designer needs
runtime
> detection if it detects it at runtime ?
> /max
> > After some discussion with PGR, we think it makes more
sense for the
> > detection to live in the Teiid Designer repository.
> >
> > Teiid Designer currently only has code for detecting teiid in
> > *running* servers, with no support for identifying a Teiid
> > installation in servers that aren't running. This makes sense for
> > their use case (server may be remote) but is not useful for runtime
> > detection at all.
> >
> > TD currently is not involved in the server creation at all, but rather
> > just adds listeners so that once a server is added, or started, they
> > can begin their configuration / build up their model. They also
> > provide editor extensions that allow setting fields on the
> > IServerWorkingCopy.
> >
> > *Barry*: One thing that would help tremendously with identifying
> > installations in non-running local servers is if I could have a map of
> > Teiid / DV releases and what underlying JBoss / Wildfly / EAP versions
> > they correspond to. What I've heard so far is that Teiid 7.x was based
> > on JBoss 5, while the 8.x stream is for AS7. It's pretty important to
> > get a full mapping of supported releases to their underlying JBoss
> > version, though. This way I can properly implement the Server Bean
> > Loaders / Runtime detection.
> >
> > One final thing to note, which I think we should bring up to the Teiid
> > runtime team directly, is that DV product properly uses the layer
> > system in JBoss 7. It has the expected
> > org/jboss/as/product/dv/dir/META-INF/MANIFEST.MF file, with the
> > expected attribute JBoss-Product-Release-Version: 6.1.0...
> >
> > But the community releases of Teiid *do not*. They simply put
> > everything in modules/system/layers/base, with no clear way of
> > identifying a version. If I wanted to look at the version here, I'd
> > need to introspect
> >
teiid-8.10.0.Final/modules/system/layers/base/org/jboss/teiid/api/main/teiid-api-8.10.0.Final.jar
> > and look at it's manifest.mf for the Bundle-Version, which so far
> > seems accurate.
> >
> > With all this in mind, it should be relatively painless (once I get
> > that version mapping from Barry) to get runtime detection +
> > downloading supported for Teiid Runtime / DV. There may be some
> > issues in stacks.yaml (since I'm not too familiar with all the bom
> > stuff) but I expect the version mapping will help me to properly pull
> > from other parts of stacks.yaml without issue.
> >
> > - Rob Stryker
> >
> > - Rob Stryker
> /max
> > http://about.me/maxandersen
>
7:11 a.m.
On 15 Apr 2015, at 5:20, Ramesh Reddy wrote:
The usecase you are going after is download the Teiid runtime based
on
the Designer? Or you want to download the Teiid runtime based on the
EAP? If it is former, Designer has strong preferences as to which
Teiid runtime it works with, but in a given major release it work more
seamless. If it is later
EAP 5.1 is used with Teiid 7.x
EAP 6.1 Alpha, up to Teiid 8.8
EAP 6.3 Alpha, Teiid 8.9, 8.10
eh - I thought you guys supported multiple runtimes by now ?
btw. this is not for matching teiid runtimes with designer - it is about
when JBoss Tools runtime detection or server wizard detects a server we
would like to know
if it is more than just the generic EAP server - we already check if it
is portal or SOA-P or FSW
and then name the server adaptor appropriately.
By adding Teeid support to we would get "JBoss Data Virtualisation 7.4"
instead of "JBoss EAP 5.1".
That is all - very simple actually ;)
We are planning for
EAP 6.4.Alpha for Teiid 8.11
No WildFly support yet. If you think a marker file like in the
MANIFEST.MF makes it easier, we are open to add such file.
Ramesh..
----- Original Message -----
> Rob,
> Paul gave you the rundown on Teiid Designer's discovery of Teiid
> runtime
> versions after server start-up and that we contribute providers &
> actions to
> the Server View. Designer is designed to be backwards compatible (7.7
> > 9.x)
> in terms of working with Teiid runtime admin and jdbc API. So in a
> sense,
> Designer doesn't care what Teiid runtime is installed. If it makes it
> easier
> on the user for server-set-up if JBT discovers/downloads/installs
> Teiid
> runtimes I'm in favor of it.
> Teiid Teiid
> Designer
> 7.7 7.7
> 8.0 8.2
> 8.1 8.3
> 8.2 - 8.4 8.4
> 8.5 - 8.6 8.7
> 9.0 8.8
> 9.1 8.9 (planned)
> 9.2 8.11 (planned)
> I've cc'd Ramesh Reddy on the Teiid project team and Van Halber, the
> DV build
> guy. They would know the version mappings between AS and Teiid
> runtimes.
> You are correct that Teiid 7.x was based on JBoss 5, while the 8.x
> stream is
> for AS7. Note also that Teiid 8.x community releases were compatible
> with
> EAP 6.x Alpha releases, not Final. Those are reserved for DV/Product
> releases.
> So my understanding is that the server configurations are fairly
> different
> between project and product.
> Barry
> ----- Original Message -----
>> From: "Max Rydahl Andersen" <manderse(a)redhat.com>
>
>> To: "Rob Stryker" <rstryker(a)redhat.com>
>
>> Cc: "phantomjinx" <p.g.richardson(a)phantomjinx.co.uk>,
>> "jbosstools-dev
>> jbosstools-dev" <jbosstools-dev(a)lists.jboss.org>, "Barry
Lafond"
>> <blafond(a)redhat.com>
>
>> Sent: Monday, April 13, 2015 5:45:48 AM
>
>> Subject: Re: [jbosstools-dev] Question on data virtualization
>> runtimes and
>> where downloadRuntime support belongs
>
>> I'm still not following/seeing why Teiid Designer needs runtime
>
>> detection if it detects it at runtime ?
>
>> /max
>
>>> After some discussion with PGR, we think it makes more sense for
>>> the
>
>>> detection to live in the Teiid Designer repository.
>
>>>
>
>>> Teiid Designer currently only has code for detecting teiid in
>
>>> *running* servers, with no support for identifying a Teiid
>
>>> installation in servers that aren't running. This makes sense for
>
>>> their use case (server may be remote) but is not useful for runtime
>
>>> detection at all.
>
>>>
>
>>> TD currently is not involved in the server creation at all, but
>>> rather
>
>>> just adds listeners so that once a server is added, or started,
>>> they
>
>>> can begin their configuration / build up their model. They also
>
>>> provide editor extensions that allow setting fields on the
>
>>> IServerWorkingCopy.
>
>>>
>
>>> *Barry*: One thing that would help tremendously with identifying
>
>>> installations in non-running local servers is if I could have a map
>>> of
>
>>> Teiid / DV releases and what underlying JBoss / Wildfly / EAP
>>> versions
>
>>> they correspond to. What I've heard so far is that Teiid 7.x was
>>> based
>
>>> on JBoss 5, while the 8.x stream is for AS7. It's pretty important
>>> to
>
>>> get a full mapping of supported releases to their underlying JBoss
>
>>> version, though. This way I can properly implement the Server Bean
>
>>> Loaders / Runtime detection.
>
>>>
>
>>> One final thing to note, which I think we should bring up to the
>>> Teiid
>
>>> runtime team directly, is that DV product properly uses the layer
>
>>> system in JBoss 7. It has the expected
>
>>> org/jboss/as/product/dv/dir/META-INF/MANIFEST.MF file, with the
>
>>> expected attribute JBoss-Product-Release-Version: 6.1.0...
>
>>>
>
>>> But the community releases of Teiid *do not*. They simply put
>
>>> everything in modules/system/layers/base, with no clear way of
>
>>> identifying a version. If I wanted to look at the version here, I'd
>
>>> need to introspect
>
>>>
teiid-8.10.0.Final/modules/system/layers/base/org/jboss/teiid/api/main/teiid-api-8.10.0.Final.jar
>
>>> and look at it's manifest.mf for the Bundle-Version, which so far
>
>>> seems accurate.
>
>>>
>
>>> With all this in mind, it should be relatively painless (once I get
>
>>> that version mapping from Barry) to get runtime detection +
>
>>> downloading supported for Teiid Runtime / DV. There may be some
>
>>> issues in stacks.yaml (since I'm not too familiar with all the bom
>
>>> stuff) but I expect the version mapping will help me to properly
>>> pull
>
>>> from other parts of stacks.yaml without issue.
>
>>>
>
>>> - Rob Stryker
>
>>>
>
>>> - Rob Stryker
>
>> /max
>
>> http://about.me/maxandersen
>
/max
http://about.me/maxandersen
8:10 a.m.
----- Original Message -----
On 15 Apr 2015, at 5:20, Ramesh Reddy wrote:
> The usecase you are going after is download the Teiid runtime based on
> the Designer? Or you want to download the Teiid runtime based on the
> EAP? If it is former, Designer has strong preferences as to which
> Teiid runtime it works with, but in a given major release it work more
> seamless. If it is later
> EAP 5.1 is used with Teiid 7.x
> EAP 6.1 Alpha, up to Teiid 8.8
> EAP 6.3 Alpha, Teiid 8.9, 8.10
eh - I thought you guys supported multiple runtimes by now ?
The issue there is we depend heavily on service, deployment and management APIs of the AS,
not to mention all the common dependencies to other libraries. We have to change based on
them thus we can not release a single Teiid runtime across all the EAP instances.
btw. this is not for matching teiid runtimes with designer - it is about
when JBoss Tools runtime detection or server wizard detects a server we
would like to know
if it is more than just the generic EAP server - we already check if it
is portal or SOA-P or FSW
and then name the server adaptor appropriately.
By adding Teeid support to we would get "JBoss Data Virtualisation 7.4"
instead of "JBoss EAP 5.1".
MANIFEST.MF is the discovery mechanism with SOA-P or FSW? As I said we can adopt to that
mechanism if that is what we want.
That is all - very simple actually ;)
> We are planning for
>
> EAP 6.4.Alpha for Teiid 8.11
>
> No WildFly support yet. If you think a marker file like in the
> MANIFEST.MF makes it easier, we are open to add such file.
>
> Ramesh..
>
> ----- Original Message -----
>
>> Rob,
>
>> Paul gave you the rundown on Teiid Designer's discovery of Teiid
>> runtime
>> versions after server start-up and that we contribute providers &
>> actions to
>> the Server View. Designer is designed to be backwards compatible (7.7
>> > 9.x)
>> in terms of working with Teiid runtime admin and jdbc API. So in a
>> sense,
>> Designer doesn't care what Teiid runtime is installed. If it makes it
>> easier
>> on the user for server-set-up if JBT discovers/downloads/installs
>> Teiid
>> runtimes I'm in favor of it.
>
>> Teiid Teiid
>> Designer
>> 7.7 7.7
>> 8.0 8.2
>> 8.1 8.3
>> 8.2 - 8.4 8.4
>> 8.5 - 8.6 8.7
>> 9.0 8.8
>> 9.1 8.9 (planned)
>> 9.2 8.11 (planned)
>
>> I've cc'd Ramesh Reddy on the Teiid project team and Van Halber, the
>> DV build
>> guy. They would know the version mappings between AS and Teiid
>> runtimes.
>
>> You are correct that Teiid 7.x was based on JBoss 5, while the 8.x
>> stream is
>> for AS7. Note also that Teiid 8.x community releases were compatible
>> with
>> EAP 6.x Alpha releases, not Final. Those are reserved for DV/Product
>> releases.
>
>> So my understanding is that the server configurations are fairly
>> different
>> between project and product.
>
>> Barry
>
>> ----- Original Message -----
>
>>> From: "Max Rydahl Andersen" <manderse(a)redhat.com>
>>
>>> To: "Rob Stryker" <rstryker(a)redhat.com>
>>
>>> Cc: "phantomjinx" <p.g.richardson(a)phantomjinx.co.uk>,
>>> "jbosstools-dev
>>> jbosstools-dev" <jbosstools-dev(a)lists.jboss.org>, "Barry
Lafond"
>>> <blafond(a)redhat.com>
>>
>>> Sent: Monday, April 13, 2015 5:45:48 AM
>>
>>> Subject: Re: [jbosstools-dev] Question on data virtualization
>>> runtimes and
>>> where downloadRuntime support belongs
>>
>
>>> I'm still not following/seeing why Teiid Designer needs runtime
>>
>>> detection if it detects it at runtime ?
>>
>
>>> /max
>>
>
>>>> After some discussion with PGR, we think it makes more sense for
>>>> the
>>
>>>> detection to live in the Teiid Designer repository.
>>
>>>>
>>
>>>> Teiid Designer currently only has code for detecting teiid in
>>
>>>> *running* servers, with no support for identifying a Teiid
>>
>>>> installation in servers that aren't running. This makes sense for
>>
>>>> their use case (server may be remote) but is not useful for runtime
>>
>>>> detection at all.
>>
>>>>
>>
>>>> TD currently is not involved in the server creation at all, but
>>>> rather
>>
>>>> just adds listeners so that once a server is added, or started,
>>>> they
>>
>>>> can begin their configuration / build up their model. They also
>>
>>>> provide editor extensions that allow setting fields on the
>>
>>>> IServerWorkingCopy.
>>
>>>>
>>
>>>> *Barry*: One thing that would help tremendously with identifying
>>
>>>> installations in non-running local servers is if I could have a map
>>>> of
>>
>>>> Teiid / DV releases and what underlying JBoss / Wildfly / EAP
>>>> versions
>>
>>>> they correspond to. What I've heard so far is that Teiid 7.x was
>>>> based
>>
>>>> on JBoss 5, while the 8.x stream is for AS7. It's pretty important
>>>> to
>>
>>>> get a full mapping of supported releases to their underlying JBoss
>>
>>>> version, though. This way I can properly implement the Server Bean
>>
>>>> Loaders / Runtime detection.
>>
>>>>
>>
>>>> One final thing to note, which I think we should bring up to the
>>>> Teiid
>>
>>>> runtime team directly, is that DV product properly uses the layer
>>
>>>> system in JBoss 7. It has the expected
>>
>>>> org/jboss/as/product/dv/dir/META-INF/MANIFEST.MF file, with the
>>
>>>> expected attribute JBoss-Product-Release-Version: 6.1.0...
>>
>>>>
>>
>>>> But the community releases of Teiid *do not*. They simply put
>>
>>>> everything in modules/system/layers/base, with no clear way of
>>
>>>> identifying a version. If I wanted to look at the version here, I'd
>>
>>>> need to introspect
>>
>>>>
teiid-8.10.0.Final/modules/system/layers/base/org/jboss/teiid/api/main/teiid-api-8.10.0.Final.jar
>>
>>>> and look at it's manifest.mf for the Bundle-Version, which so far
>>
>>>> seems accurate.
>>
>>>>
>>
>>>> With all this in mind, it should be relatively painless (once I get
>>
>>>> that version mapping from Barry) to get runtime detection +
>>
>>>> downloading supported for Teiid Runtime / DV. There may be some
>>
>>>> issues in stacks.yaml (since I'm not too familiar with all the bom
>>
>>>> stuff) but I expect the version mapping will help me to properly
>>>> pull
>>
>>>> from other parts of stacks.yaml without issue.
>>
>>>>
>>
>>>> - Rob Stryker
>>
>>>>
>>
>>>> - Rob Stryker
>>
>
>>> /max
>>
>>> http://about.me/maxandersen
>>
/max
http://about.me/maxandersen
11:33 a.m.
On 15 Apr 2015, at 15:10, Ramesh Reddy wrote:
----- Original Message -----
> On 15 Apr 2015, at 5:20, Ramesh Reddy wrote:
>
>> The usecase you are going after is download the Teiid runtime based
>> on
>> the Designer? Or you want to download the Teiid runtime based on the
>> EAP? If it is former, Designer has strong preferences as to which
>> Teiid runtime it works with, but in a given major release it work
>> more
>> seamless. If it is later
>
>> EAP 5.1 is used with Teiid 7.x
>> EAP 6.1 Alpha, up to Teiid 8.8
>> EAP 6.3 Alpha, Teiid 8.9, 8.10
>
> eh - I thought you guys supported multiple runtimes by now ?
The issue there is we depend heavily on service, deployment and
management APIs of the AS, not to mention all the common dependencies
to other libraries. We have to change based on them thus we can not
release a single Teiid runtime across all the EAP instances.
I'm not talking about Teiid runtime supporting multiple EAP.
I'm talking Teiid Designer supporting multiple versions of Teiid
runtime.
> btw. this is not for matching teiid runtimes with designer - it
is
> about
> when JBoss Tools runtime detection or server wizard detects a server
> we
> would like to know
> if it is more than just the generic EAP server - we already check if
> it
> is portal or SOA-P or FSW
> and then name the server adaptor appropriately.
>
> By adding Teeid support to we would get "JBoss Data Virtualisation
> 7.4"
> instead of "JBoss EAP 5.1".
MANIFEST.MF is the discovery mechanism with SOA-P or FSW? As I said we
can adopt to that mechanism if that is what we want.
we use the jboss product layering metadata.
Rob can outline the details.
Note, in case you don't actually use that it would be interesting to
know why.
i.e. is it A) we didn't know about it - lets use it! or B) Teiid is not
considered a layered product and can be installed/patched in a different
way than SOA-P, FSW,etc. thus it is not registered as a layered product.
/max
http://about.me/maxandersen
3543
days inactive
3548
days old
jbosstools-dev@lists.jboss.org
13 comments
5 participants
participants (5)
-
Barry Lafond -
Max Rydahl Andersen -
phantomjinx -
Ramesh Reddy -
Rob Stryker