[JBoss JIRA] (TEIID-2605) Optimization substitutes wrong column in where clause
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-2605?page=com.atlassian.jira.plugin... ]
Steven Hawkins closed TEIID-2605.
---------------------------------
> Optimization substitutes wrong column in where clause
> -----------------------------------------------------
>
> Key: TEIID-2605
> URL: https://issues.jboss.org/browse/TEIID-2605
> Project: Teiid
> Issue Type: Bug
> Components: Query Engine
> Affects Versions: 8.1
> Environment: z/OS
> Reporter: Jeff Hayes
> Assignee: Steven Hawkins
> Attachments: query_plan.txt, views.xml
>
>
> Optimization results in a query with a different column in the WHERE clause producing an empty result set.
> Full query plan is attached but the beginning and ending queries are shown below. Note that the subject column of the IN clause is SCOPEID but optimization changes it to AUTHID for some reason.
> USER COMMAND:
> SELECT * FROM SECURITY.SCPXREF AS CHORUS_B WHERE (CHORUS_B.SYSID = 'DE29') AND ((CHORUS_B.SCOPEID IN (SELECT SN5.SCOPEID FROM SECURI
> TY.SCPNEXT AS SN5 WHERE (SYSID = 'DE29') AND (NEXTREC IN (SELECT SN4.SCOPEID FROM SECURITY.SCPNEXT AS SN4 WHERE (SYSID = 'DE29') AND
> (NEXTREC IN (SELECT SN3.SCOPEID FROM SECURITY.SCPNEXT AS SN3 WHERE (SYSID = 'DE29') AND (NEXTREC IN (SELECT SN2.SCOPEID FROM SECURI
> TY.SCPNEXT AS SN2 WHERE (SYSID = 'DE29') AND (NEXTREC = 'CHRDEPT1'))))))))) OR (CHORUS_B.SCOPEID IN (SELECT SN4.SCOPEID FROM SECURIT
> Y.SCPNEXT AS SN4 WHERE (SYSID = 'DE29') AND (NEXTREC IN (SELECT SN3.SCOPEID FROM SECURITY.SCPNEXT AS SN3 WHERE (SYSID = 'DE29') AND
> (NEXTREC IN (SELECT SN2.SCOPEID FROM SECURITY.SCPNEXT AS SN2 WHERE (SYSID = 'DE29') AND (NEXTREC = 'CHRDEPT1'))))))) OR (CHORUS_B.SC
> OPEID IN (SELECT SN3.SCOPEID FROM SECURITY.SCPNEXT AS SN3 WHERE (SYSID = 'DE29') AND (NEXTREC IN (SELECT SN2.SCOPEID FROM SECURITY.S
> CPNEXT AS SN2 WHERE (SYSID = 'DE29') AND (NEXTREC = 'CHRDEPT1'))))) OR (CHORUS_B.SCOPEID IN (SELECT SN2.SCOPEID FROM SECURITY.SCPNEX
> T AS SN2 WHERE (SYSID = 'DE29') AND (NEXTREC = 'CHRDEPT1'))) OR (CHORUS_B.SCOPEID = 'CHRDEPT1'))
> OPTIMIZATION COMPLETE:
> PROCESSOR PLAN:
> AccessNode(10) output=[x.sysid AS sysid, x.scopeid AS authid, x.authid AS scopeid, x.authtype AS authtype] SELECT g_0.SYSID, g_0.SCO
> PEID, g_0.AUTHID, g_0.AUTHTYPE FROM SECURITY_CIA_DB2_D91BPTIB_CIADB01.SCPXREF AS g_0 WHERE (g_0.SYSID = 'DE29') AND ((g_0.AUTHID IN
> (SELECT g_1.SCOPEID FROM SECURITY_CIA_DB2_D91BPTIB_CIADB01.SCPNEXT AS g_1 WHERE (g_1.SYSID = 'DE29') AND (g_1.NEXTREC IN (SELECT g_2
> .SCOPEID FROM SECURITY_CIA_DB2_D91BPTIB_CIADB01.SCPNEXT AS g_2 WHERE (g_2.SYSID = 'DE29') AND (g_2.NEXTREC IN (SELECT g_3.SCOPEID FR
> OM SECURITY_CIA_DB2_D91BPTIB_CIADB01.SCPNEXT AS g_3 WHERE (g_3.SYSID = 'DE29') AND (g_3.NEXTREC IN (SELECT g_4.SCOPEID FROM SECURITY
> _CIA_DB2_D91BPTIB_CIADB01.SCPNEXT AS g_4 WHERE (g_4.SYSID = 'DE29') AND (g_4.NEXTREC = 'CHRDEPT1'))))))))) OR (g_0.AUTHID IN (SELECT
> g_5.SCOPEID FROM SECURITY_CIA_DB2_D91BPTIB_CIADB01.SCPNEXT AS g_5 WHERE (g_5.SYSID = 'DE29') AND (g_5.NEXTREC IN (SELECT g_6.SCOPEI
> D FROM SECURITY_CIA_DB2_D91BPTIB_CIADB01.SCPNEXT AS g_6 WHERE (g_6.SYSID = 'DE29') AND (g_6.NEXTREC IN (SELECT g_7.SCOPEID FROM SECU
> RITY_CIA_DB2_D91BPTIB_CIADB01.SCPNEXT AS g_7 WHERE (g_7.SYSID = 'DE29') AND (g_7.NEXTREC = 'CHRDEPT1'))))))) OR (g_0.AUTHID IN (SELE
> CT g_8.SCOPEID FROM SECURITY_CIA_DB2_D91BPTIB_CIADB01.SCPNEXT AS g_8 WHERE (g_8.SYSID = 'DE29') AND (g_8.NEXTREC IN (SELECT g_9.SCOP
> EID FROM SECURITY_CIA_DB2_D91BPTIB_CIADB01.SCPNEXT AS g_9 WHERE (g_9.SYSID = 'DE29') AND (g_9.NEXTREC = 'CHRDEPT1'))))) OR (g_0.AUTH
> ID IN (SELECT g_10.SCOPEID FROM SECURITY_CIA_DB2_D91BPTIB_CIADB01.SCPNEXT AS g_10 WHERE (g_10.SYSID = 'DE29') AND (g_10.NEXTREC = 'C
> HRDEPT1'))) OR (g_0.AUTHID = 'CHRDEPT1'))
> The view definitions are shown below:
> <view name="SCPNEXT">
> <columns>
> <column name="sysid" type="varchar"/>
> <column name="scopeid" type="varchar"/>
> <column name="nextrec" type="varchar"/>
> </columns>
> <definition>
> #if ($db.count("select count(*) from sys.tables where Name='config' and SchemaName = 'security_db'") > 0)
> #set ($count = 0)
> #foreach($t in $db.query("select DB_TYPE, DB_LOC, DB_QUAL from security_db.config WHERE TYPE = 'CIA'"))
> #if ($db.count("select count(*) from sys.tables where SchemaName = 'SECURITY_CIA_${t.DB_TYPE}_${t.DB_LOC}_${t.DB_QUAL}'") == 0)
> #set ($count = $count + 1)
> #end
> #end
> #if ($count == 0)
> SELECT t.sysid, t.scopeid, t.nextrec
> FROM (
> #foreach($t in $db.query("select DB_TYPE, DB_LOC, DB_QUAL from security_db.config WHERE TYPE = 'CIA'"))
> SELECT n.sysid, n.scopeid, n.nextrec
> FROM SECURITY_CIA_${t.DB_TYPE}_${t.DB_LOC}_${t.DB_QUAL}.SCPNEXT n
> #if( $velocityHasNext ) UNION #end
> #end
> ) AS t
> #end
> #end
> </definition>
> </view>
> <view name="SCPXREF">
> <columns>
> <column name="sysid" type="varchar"/>
> <column name="authid" type="varchar"/>
> <column name="scopeid" type="varchar"/>
> <column name="authtype" type="varchar"/>
> </columns>
> <definition>
> #if ($db.count("select count(*) from sys.tables where Name='config' and SchemaName = 'security_db'") > 0)
> #set ($count = 0)
> #foreach($t in $db.query("select DB_TYPE, DB_LOC, DB_QUAL from security_db.config WHERE TYPE = 'CIA'"))
> #if ($db.count("select count(*) from sys.tables where SchemaName = 'SECURITY_CIA_${t.DB_TYPE}_${t.DB_LOC}_${t.DB_QUAL}'") == 0)
> #set ($count = $count + 1)
> #end
> #end
> #if ($count == 0)
> SELECT sysid, scopeid, authid, authtype
> FROM (
> #foreach($t in $db.query("select DB_TYPE, DB_LOC, DB_QUAL from security_db.config WHERE TYPE = 'CIA'"))
> SELECT x.sysid, x.scopeid, x.authid, x.authtype
> FROM SECURITY_CIA_${t.DB_TYPE}_${t.DB_LOC}_${t.DB_QUAL}.SCPXREF x
> #if( $velocityHasNext ) UNION #end
> #end
> ) AS t
> #end
> #end
> </definition>
> </view>
> I guess the best way to test this is to define these views and run the input query with SHOWPLAN=DEBUG and see if the AUTHID substitution is occurring.
> Thanks!
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
2 weeks, 4 days
[JBoss JIRA] (TEIID-5581) No @nextlink for virtualized procedure
by Steven Hawkins (Jira)
[ https://issues.jboss.org/browse/TEIID-5581?page=com.atlassian.jira.plugin... ]
Steven Hawkins commented on TEIID-5581:
---------------------------------------
For a procedure that returns multiple rows we use a complex type result - but we still apply the batch size when doing the result fetching. The skip token only affects entity set results.
Workaround:
Add a procedure relational view with a primary key:
{code}
create view procView (Param1, myValue primary key) as select Param1, myValue from procExample
{code}
Of course just a get of the procView entity without specifying param1 would fail.
Possible changes:
* give the user the option of specifying the procedure result as an entity - extension metadata for the unique key?
* make the complex type procedure result unaffected by the batch size - however some cap would still need to exist.
> No @nextlink for virtualized procedure
> --------------------------------------
>
> Key: TEIID-5581
> URL: https://issues.jboss.org/browse/TEIID-5581
> Project: Teiid
> Issue Type: Bug
> Components: OData
> Affects Versions: 8.12.16.6_4
> Reporter: Colin Mondesir
> Assignee: Steven Hawkins
> Priority: Major
> Attachments: example.xmi, procExample_Odata_Results.xml, procExample_SELECT.sql
>
>
> If we query a table "Field" via VDB, we get the following line in XML :
> <a:link rel="next" href="http://<IP-address>:8080/odata4/UDVvdb.13/BusinessObjects/Field?$skiptoken=6lS4u9tYdm4j,256"/>
> This allow end-user to loop on results easily.
> But when we call virtualized procedure, we do not see that line.
> It looks like :
> <m:value xmlns:m="http://docs.oasis-open.org/odata/ns/metadata" xmlns:d="http://docs.oasis-open.org/odata/ns/data" xmlns:a="http://www.w3.org/2005/Atom" m:type="#Collection(UDVvdb.13.Wellmap.getOffsetWells_ResultSet)" m:context="$metadata#Collection(UDVvdb.13.Wellmap.getOffsetWells_ResultSet)">
> [List of <m:element>]
> </m:value>
> Odata batch is currently limited to 256 so without a next link it's not possible to get to the rest of the data.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 10 months
[JBoss JIRA] (TEIID-5563) Separate the Teiid WildFly distribution into their own repo or module
by Steven Hawkins (Jira)
[ https://issues.jboss.org/browse/TEIID-5563?page=com.atlassian.jira.plugin... ]
Steven Hawkins commented on TEIID-5563:
---------------------------------------
All tests are running on the branch now and a snapshot pushes correctly.
I've combined the teiid bom and build configuration parent back into the teiid-parent.
As the teiid-parent is no longer the direct parent of wildfly, the profiles from the teiid parent have been copied into the wildfly parent to keep the release / travis commands the same for now - more will need to be done if/when we move things completely.
Before the final release we need agreement on the module names. As Van was asking should "connectors" be renamed translators and instead of org.teiid.connectors:translator-foo, should we use org.teiid.translator? Should the use of the jboss name be replaced with wildfly under the wildfly module? Should we use teiid-wildfly-parent instead of wildfly-parent, etc.
Other tasks:
* One minor change is that this moves the maven coordinates for the wildfly release artifacts, the download page will need updated accordingly
* Move teiid core to basepom
* references to teiid core artifacts from wildfly stuff using ${project.version} should be removed - that should come from the bom(s). As we'll need the versions eventually independent.
* (low priority) move references to the javax lib stuff in core teiid from the wildfly dependency to something more generic
> Separate the Teiid WildFly distribution into their own repo or module
> ---------------------------------------------------------------------
>
> Key: TEIID-5563
> URL: https://issues.jboss.org/browse/TEIID-5563
> Project: Teiid
> Issue Type: Task
> Components: Build/Kits, Integration Tests
> Affects Versions: 12.x
> Reporter: Van Halbert
> Assignee: Van Halbert
> Priority: Major
>
> With the different types of distributions now being built based on Teiid like
> * WildFly
> * Thorntail
> * SpringBoot
> * Embedded
> Having main `github.com/teiid` repo contain artifacts for WildFly distribution poses an unnecessary dependency burden on other distributions. For example, the resource adapters are mainly for use with WildFly and Thorntail V2. They can still be applicable to embedded and SpringBoot as either non-managed connection factories, or require the user to provide appropriate management / pooling. When they are pulled into environments like SpringBoot they will bring several wildfly dependencies / and JEE constructs that are unnecessary - specifically the dependencies jboss-jaxws-api (teiid-api), javax.activation (teiid-core), jboss-transaction-api (teiid-api), and jboss-connector-api (teiid-api).
> This proposal is to separate "teiid" core modules along with all translators into one repository and move all the resource adapters along with any feature-packs and module building into a sperate repository like "teiid-wildfly". With the goal of providing similar connectivity in SpringBoot using as much common logic from SpringBoot (Spring Data in particular) and even Fuse as possible.
> Basically, when finished, the core Teiid modules only provide Maven artifacts along with their clean pom.xml with for direct and maybe transitive dependencies. None of the WildFly based modules support will be here. At worst this may introduce duplicate dependencies into the WildFly environment as we will need to manage all core / translator dependencies independently from those provided by WildFly. Where possible the teiid-api / core modules will need to use the generic javax dependency - or even remove the dependency if possible.
> The "teiid-wildfly" module on the other hand, will exactly preserve what is in the current repo as far feature packs and module building and overall WildFly distribution building.
> A follow-on task we can task we can look into is, converting the main teiid then to use basepom rather than the jboss-parent pom. However, the recommendation is this should be done after, not simultaneously.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 10 months
[JBoss JIRA] (TEIID-5563) Separate the Teiid WildFly distribution into their own repo or module
by Steven Hawkins (Jira)
[ https://issues.jboss.org/browse/TEIID-5563?page=com.atlassian.jira.plugin... ]
Steven Hawkins updated TEIID-5563:
----------------------------------
Comment: was deleted
(was: [~rareddy] With our ConnectionFactory api, I made it generic to match what you had. But I see now we can't do that without adding back implements Connection to all of the connection interfaces. Unless you want to that path, I'll just change it to object for now.)
> Separate the Teiid WildFly distribution into their own repo or module
> ---------------------------------------------------------------------
>
> Key: TEIID-5563
> URL: https://issues.jboss.org/browse/TEIID-5563
> Project: Teiid
> Issue Type: Task
> Components: Build/Kits, Integration Tests
> Affects Versions: 12.x
> Reporter: Van Halbert
> Assignee: Van Halbert
> Priority: Major
>
> With the different types of distributions now being built based on Teiid like
> * WildFly
> * Thorntail
> * SpringBoot
> * Embedded
> Having main `github.com/teiid` repo contain artifacts for WildFly distribution poses an unnecessary dependency burden on other distributions. For example, the resource adapters are mainly for use with WildFly and Thorntail V2. They can still be applicable to embedded and SpringBoot as either non-managed connection factories, or require the user to provide appropriate management / pooling. When they are pulled into environments like SpringBoot they will bring several wildfly dependencies / and JEE constructs that are unnecessary - specifically the dependencies jboss-jaxws-api (teiid-api), javax.activation (teiid-core), jboss-transaction-api (teiid-api), and jboss-connector-api (teiid-api).
> This proposal is to separate "teiid" core modules along with all translators into one repository and move all the resource adapters along with any feature-packs and module building into a sperate repository like "teiid-wildfly". With the goal of providing similar connectivity in SpringBoot using as much common logic from SpringBoot (Spring Data in particular) and even Fuse as possible.
> Basically, when finished, the core Teiid modules only provide Maven artifacts along with their clean pom.xml with for direct and maybe transitive dependencies. None of the WildFly based modules support will be here. At worst this may introduce duplicate dependencies into the WildFly environment as we will need to manage all core / translator dependencies independently from those provided by WildFly. Where possible the teiid-api / core modules will need to use the generic javax dependency - or even remove the dependency if possible.
> The "teiid-wildfly" module on the other hand, will exactly preserve what is in the current repo as far feature packs and module building and overall WildFly distribution building.
> A follow-on task we can task we can look into is, converting the main teiid then to use basepom rather than the jboss-parent pom. However, the recommendation is this should be done after, not simultaneously.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 10 months
[JBoss JIRA] (TEIID-5563) Separate the Teiid WildFly distribution into their own repo or module
by Steven Hawkins (Jira)
[ https://issues.jboss.org/browse/TEIID-5563?page=com.atlassian.jira.plugin... ]
Steven Hawkins commented on TEIID-5563:
---------------------------------------
[~rareddy] With our ConnectionFactory api, I made it generic to match what you had. But I see now we can't do that without adding back implements Connection to all of the connection interfaces. Unless you want to that path, I'll just change it to object for now.
> Separate the Teiid WildFly distribution into their own repo or module
> ---------------------------------------------------------------------
>
> Key: TEIID-5563
> URL: https://issues.jboss.org/browse/TEIID-5563
> Project: Teiid
> Issue Type: Task
> Components: Build/Kits, Integration Tests
> Affects Versions: 12.x
> Reporter: Van Halbert
> Assignee: Van Halbert
> Priority: Major
>
> With the different types of distributions now being built based on Teiid like
> * WildFly
> * Thorntail
> * SpringBoot
> * Embedded
> Having main `github.com/teiid` repo contain artifacts for WildFly distribution poses an unnecessary dependency burden on other distributions. For example, the resource adapters are mainly for use with WildFly and Thorntail V2. They can still be applicable to embedded and SpringBoot as either non-managed connection factories, or require the user to provide appropriate management / pooling. When they are pulled into environments like SpringBoot they will bring several wildfly dependencies / and JEE constructs that are unnecessary - specifically the dependencies jboss-jaxws-api (teiid-api), javax.activation (teiid-core), jboss-transaction-api (teiid-api), and jboss-connector-api (teiid-api).
> This proposal is to separate "teiid" core modules along with all translators into one repository and move all the resource adapters along with any feature-packs and module building into a sperate repository like "teiid-wildfly". With the goal of providing similar connectivity in SpringBoot using as much common logic from SpringBoot (Spring Data in particular) and even Fuse as possible.
> Basically, when finished, the core Teiid modules only provide Maven artifacts along with their clean pom.xml with for direct and maybe transitive dependencies. None of the WildFly based modules support will be here. At worst this may introduce duplicate dependencies into the WildFly environment as we will need to manage all core / translator dependencies independently from those provided by WildFly. Where possible the teiid-api / core modules will need to use the generic javax dependency - or even remove the dependency if possible.
> The "teiid-wildfly" module on the other hand, will exactly preserve what is in the current repo as far feature packs and module building and overall WildFly distribution building.
> A follow-on task we can task we can look into is, converting the main teiid then to use basepom rather than the jboss-parent pom. However, the recommendation is this should be done after, not simultaneously.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 10 months
[JBoss JIRA] (TEIID-5563) Separate the Teiid WildFly distribution into their own repo or module
by Steven Hawkins (Jira)
[ https://issues.jboss.org/browse/TEIID-5563?page=com.atlassian.jira.plugin... ]
Steven Hawkins edited comment on TEIID-5563 at 12/21/18 8:17 AM:
-----------------------------------------------------------------
I've got things cleanly separated and the wildfly dist seems to build correctly. However neither the test-integration/common nor the arquillian tests are running.
I've also removed the wildfly profile for now - that is a slightly larger change that impacts the release docs and travis build.
was (Author: shawkins):
I've got things cleanly separated and the wildfly dist seems to build correctly. However neither the test-integration/common nor the arquillian tests are running.
> Separate the Teiid WildFly distribution into their own repo or module
> ---------------------------------------------------------------------
>
> Key: TEIID-5563
> URL: https://issues.jboss.org/browse/TEIID-5563
> Project: Teiid
> Issue Type: Task
> Components: Build/Kits, Integration Tests
> Affects Versions: 12.x
> Reporter: Van Halbert
> Assignee: Van Halbert
> Priority: Major
>
> With the different types of distributions now being built based on Teiid like
> * WildFly
> * Thorntail
> * SpringBoot
> * Embedded
> Having main `github.com/teiid` repo contain artifacts for WildFly distribution poses an unnecessary dependency burden on other distributions. For example, the resource adapters are mainly for use with WildFly and Thorntail V2. They can still be applicable to embedded and SpringBoot as either non-managed connection factories, or require the user to provide appropriate management / pooling. When they are pulled into environments like SpringBoot they will bring several wildfly dependencies / and JEE constructs that are unnecessary - specifically the dependencies jboss-jaxws-api (teiid-api), javax.activation (teiid-core), jboss-transaction-api (teiid-api), and jboss-connector-api (teiid-api).
> This proposal is to separate "teiid" core modules along with all translators into one repository and move all the resource adapters along with any feature-packs and module building into a sperate repository like "teiid-wildfly". With the goal of providing similar connectivity in SpringBoot using as much common logic from SpringBoot (Spring Data in particular) and even Fuse as possible.
> Basically, when finished, the core Teiid modules only provide Maven artifacts along with their clean pom.xml with for direct and maybe transitive dependencies. None of the WildFly based modules support will be here. At worst this may introduce duplicate dependencies into the WildFly environment as we will need to manage all core / translator dependencies independently from those provided by WildFly. Where possible the teiid-api / core modules will need to use the generic javax dependency - or even remove the dependency if possible.
> The "teiid-wildfly" module on the other hand, will exactly preserve what is in the current repo as far feature packs and module building and overall WildFly distribution building.
> A follow-on task we can task we can look into is, converting the main teiid then to use basepom rather than the jboss-parent pom. However, the recommendation is this should be done after, not simultaneously.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 10 months
[JBoss JIRA] (TEIID-5563) Separate the Teiid WildFly distribution into their own repo or module
by Steven Hawkins (Jira)
[ https://issues.jboss.org/browse/TEIID-5563?page=com.atlassian.jira.plugin... ]
Steven Hawkins commented on TEIID-5563:
---------------------------------------
I've got things cleanly separated and the wildfly dist seems to build correctly. However neither the test-integration/common nor the arquillian tests are running.
> Separate the Teiid WildFly distribution into their own repo or module
> ---------------------------------------------------------------------
>
> Key: TEIID-5563
> URL: https://issues.jboss.org/browse/TEIID-5563
> Project: Teiid
> Issue Type: Task
> Components: Build/Kits, Integration Tests
> Affects Versions: 12.x
> Reporter: Van Halbert
> Assignee: Van Halbert
> Priority: Major
>
> With the different types of distributions now being built based on Teiid like
> * WildFly
> * Thorntail
> * SpringBoot
> * Embedded
> Having main `github.com/teiid` repo contain artifacts for WildFly distribution poses an unnecessary dependency burden on other distributions. For example, the resource adapters are mainly for use with WildFly and Thorntail V2. They can still be applicable to embedded and SpringBoot as either non-managed connection factories, or require the user to provide appropriate management / pooling. When they are pulled into environments like SpringBoot they will bring several wildfly dependencies / and JEE constructs that are unnecessary - specifically the dependencies jboss-jaxws-api (teiid-api), javax.activation (teiid-core), jboss-transaction-api (teiid-api), and jboss-connector-api (teiid-api).
> This proposal is to separate "teiid" core modules along with all translators into one repository and move all the resource adapters along with any feature-packs and module building into a sperate repository like "teiid-wildfly". With the goal of providing similar connectivity in SpringBoot using as much common logic from SpringBoot (Spring Data in particular) and even Fuse as possible.
> Basically, when finished, the core Teiid modules only provide Maven artifacts along with their clean pom.xml with for direct and maybe transitive dependencies. None of the WildFly based modules support will be here. At worst this may introduce duplicate dependencies into the WildFly environment as we will need to manage all core / translator dependencies independently from those provided by WildFly. Where possible the teiid-api / core modules will need to use the generic javax dependency - or even remove the dependency if possible.
> The "teiid-wildfly" module on the other hand, will exactly preserve what is in the current repo as far feature packs and module building and overall WildFly distribution building.
> A follow-on task we can task we can look into is, converting the main teiid then to use basepom rather than the jboss-parent pom. However, the recommendation is this should be done after, not simultaneously.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 10 months