December 2018 - teiid-issues - Jboss List Archives

[JBoss JIRA] (TEIID-5563) Separate the Teiid WildFly distribution into their own repo or module

by Ramesh Reddy (Jira)

[ https://issues.jboss.org/browse/TEIID-5563?page=com.atlassian.jira.plugin... ] Ramesh Reddy commented on TEIID-5563: ------------------------------------- Other than pulling that into ws-translator or replacing with something like HTTPConnection I guess there are not better options :( I wasn't thinking about module name changes yet, so yeah, that makes sense. > 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)

5 years, 5 months

1
0
0 / 0

[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 would like to see Van Halbert changes before we cut the release. You mean reorganize/relocate the modules? I wouldn't necessarily hold up the release for that - unless you are thinking about changing the maven coordinates. > Why dependency on "JAX-WS API" in api module? looks like a transitive dependency? For WSConnection. It was put in api (just like FileConnection) as it was shared among several resource adapters. > 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)

5 years, 5 months

1
0
0 / 0

[JBoss JIRA] (TEIID-5563) Separate the Teiid WildFly distribution into their own repo or module

by Ramesh Reddy (Jira)

[ https://issues.jboss.org/browse/TEIID-5563?page=com.atlassian.jira.plugin... ] Ramesh Reddy commented on TEIID-5563: ------------------------------------- >Looking at this more we would need to make a similar change in the resource adapters as well to simplify classpath management in flat classpath environments. >For now I'll just leave things at the jboss versions. we should probably wait for a Teiid release based on these changes before we change the flat classpath environments like spring boot. I would like to see [~van.halbert] changes before we cut the release. [~shawkins] Why dependency on "JAX-WS API" in api module? looks like a transitive dependency? > 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)

5 years, 5 months

1
0
0 / 0

[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: --------------------------------------- > This just leaves org.jboss.spec.javax.xml.ws as the only a dependency of teiid-api that could be refined out - or just replaced with the generic java equivalent. Looking at this more we would need to make a similar change in the resource adapters as well to simplify classpath management in flat classpath environments. For now I'll just leave things at the jboss versions. > 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)

5 years, 5 months

1
0
0 / 0

[JBoss JIRA] (TEIID-5572) FileExecutionFactory fails with ftp source

by Steven Hawkins (Jira)

[ https://issues.jboss.org/browse/TEIID-5572?page=com.atlassian.jira.plugin... ] Steven Hawkins resolved TEIID-5572. ----------------------------------- Resolution: Done Updated the indexing logic. Resolved in master as part of TEIID-5563. > FileExecutionFactory fails with ftp source > ------------------------------------------ > > Key: TEIID-5572 > URL: https://issues.jboss.org/browse/TEIID-5572 > Project: Teiid > Issue Type: Bug > Components: Misc. Connectors > Reporter: Steven Hawkins > Assignee: Steven Hawkins > Priority: Major > Fix For: 11.1.2, 12.0, 11.2.2 > > > The virtualfileconnection logic does not correctly handle the files array - getfiles will always result in an indexoutofbounds exceptions. -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 5 months

1
0
0 / 0

[JBoss JIRA] (TEIID-5573) Ending a teiid odata url with a slash causes a 'Malformed URI' error

by Steven Hawkins (Jira)

[ https://issues.jboss.org/browse/TEIID-5573?page=com.atlassian.jira.plugin... ] Steven Hawkins resolved TEIID-5573. ----------------------------------- Fix Version/s: 11.1.2 12.0 11.2.2 Resolution: Done The upstream issue isn't a blocker for this because we can workaround with the context aware request cleansing of the url. > Ending a teiid odata url with a slash causes a 'Malformed URI' error > -------------------------------------------------------------------- > > Key: TEIID-5573 > URL: https://issues.jboss.org/browse/TEIID-5573 > Project: Teiid > Issue Type: Bug > Components: OData > Affects Versions: 9.1.1 > Reporter: Paul Richardson > Assignee: Steven Hawkins > Priority: Major > Fix For: 11.1.2, 12.0, 11.2.2 > > > As discussed on #teiid (IRC), the URI used to access a teiid odata service fails if a '/' is appended to it, eg. > {code:java} > https://${HOST}:${PORT}/odata4/usstates/USStates/SvcView/ > {code} > This results in this error (in Chrome): > {code:xml} > <error xmlns="http://docs.oasis-open.org/odata/ns/metadata"> > <script/> > <code>null</code> > <message>The URI is malformed.</message> > </error> > {code} > Removing the '/' works correctly. > This appears to be an underlying problem with the olingo4 libraries since the [tutorial|https://olingo.apache.org/doc/odata4/tutorials/read/tutorial_rea...] when implemented suffers the same error. > However, the odata.org reference [implementation|https://services.odata.org/TripPinRESTierService/(S(4gus0w...] does handle the slash correctly. > *_Why does this matter?_* > The [camel-odata|https://github.com/apache/camel/blob/master/components/camel-...] connector uses the olingo4 libraries and positively [adds|https://github.com/apache/camel/blob/master/components/camel-olingo4...] a '/' when forming the full URI to read data. This camel connector was originally created using the reference odata implementation as test data so unsurprising that it assumes the extra '/'. > *_Who should fix what?_* > Probably, the olingo4 libraries should be fixed to correctly handle the extra '/'. However, that would require both teiid and the camel odata-connector picking up a new version of the library, which may well take some time. From the discussion on IRC, it is possible to workaround this in teiid with the use of _'servlet filters'_. > *_Tested version_* > The version of teiid actually tested is 9.1.1 but would imagine that later versions may also be affected given it is ultimately a problem with the olingo4 libraries. -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 5 months

1
0
0 / 0

[JBoss JIRA] (TEIID-5573) Ending a teiid odata url with a slash causes a 'Malformed URI' error

by Steven Hawkins (Jira)

[ https://issues.jboss.org/browse/TEIID-5573?page=com.atlassian.jira.plugin... ] Steven Hawkins commented on TEIID-5573: --------------------------------------- The exception is "The URI is malformed", with the cause being "Unexpected start of resource-path segment." from the ResourcePathParser. Captured as https://issues.apache.org/jira/browse/OLINGO-1324 > Ending a teiid odata url with a slash causes a 'Malformed URI' error > -------------------------------------------------------------------- > > Key: TEIID-5573 > URL: https://issues.jboss.org/browse/TEIID-5573 > Project: Teiid > Issue Type: Bug > Components: OData > Affects Versions: 9.1.1 > Reporter: Paul Richardson > Assignee: Steven Hawkins > Priority: Major > > As discussed on #teiid (IRC), the URI used to access a teiid odata service fails if a '/' is appended to it, eg. > {code:java} > https://${HOST}:${PORT}/odata4/usstates/USStates/SvcView/ > {code} > This results in this error (in Chrome): > {code:xml} > <error xmlns="http://docs.oasis-open.org/odata/ns/metadata"> > <script/> > <code>null</code> > <message>The URI is malformed.</message> > </error> > {code} > Removing the '/' works correctly. > This appears to be an underlying problem with the olingo4 libraries since the [tutorial|https://olingo.apache.org/doc/odata4/tutorials/read/tutorial_rea...] when implemented suffers the same error. > However, the odata.org reference [implementation|https://services.odata.org/TripPinRESTierService/(S(4gus0w...] does handle the slash correctly. > *_Why does this matter?_* > The [camel-odata|https://github.com/apache/camel/blob/master/components/camel-...] connector uses the olingo4 libraries and positively [adds|https://github.com/apache/camel/blob/master/components/camel-olingo4...] a '/' when forming the full URI to read data. This camel connector was originally created using the reference odata implementation as test data so unsurprising that it assumes the extra '/'. > *_Who should fix what?_* > Probably, the olingo4 libraries should be fixed to correctly handle the extra '/'. However, that would require both teiid and the camel odata-connector picking up a new version of the library, which may well take some time. From the discussion on IRC, it is possible to workaround this in teiid with the use of _'servlet filters'_. > *_Tested version_* > The version of teiid actually tested is 9.1.1 but would imagine that later versions may also be affected given it is ultimately a problem with the olingo4 libraries. -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 5 months

1
0
0 / 0

[JBoss JIRA] (TEIID-5571) If set null as argument to replace function, the column of all records becomes null

by Steven Hawkins (Jira)

[ https://issues.jboss.org/browse/TEIID-5571?page=com.atlassian.jira.plugin... ] Steven Hawkins commented on TEIID-5571: --------------------------------------- See also the related upstream issue that handles removing unsupported characters. > If set null as argument to replace function, the column of all records becomes null > ----------------------------------------------------------------------------------- > > Key: TEIID-5571 > URL: https://issues.jboss.org/browse/TEIID-5571 > Project: Teiid > Issue Type: Bug > Components: Query Engine > Affects Versions: 8.12.16.6_4 > Environment: jdv6.4.5 > Reporter: Hiroki Daicho > Assignee: Steven Hawkins > Priority: Major > Attachments: Client.java, logs.zip, oraclevdb-vdb.xml > > > When argument of replace function set to null, all records of the column are set null value. > - Query > select num, replace(name, 'a', null) from TEST01 > Results > 1: 0, null > 2: 1, null > 3: 2, null > 4: 3, null > Results (Expected) > 1: 0, null > 2: 1, b > 3: 2, c > 4: 3, d > {code} > 14:03:17,019 INFO [org.teiid.COMMAND_LOG] (New I/O worker #2) MH/yC1t35aMa START USER COMMAND: startTime=2018-12-13 14:03:17.019 requestID=MH/yC1t35aMa.0 txID=null sessionID=MH/yC1t35aMa applicationName=JDBC principal=teiidUser@teiid-security vdbName=oraclevdb vdbVersion=1 sql=select num, replace(name, 'a', null) from TEST01 > 14:03:17,309 DEBUG [org.teiid.COMMAND_LOG] (Worker1_QueryProcessorQueue1) MH/yC1t35aMa START DATA SRC COMMAND: startTime=2018-12-13 14:03:17.309 requestID=MH/yC1t35aMa.0 sourceCommandID=0 executionID=0 txID=null modelName=oracle translatorName=oracle sessionID=MH/yC1t35aMa principal=teiidUser@teiid-security sql=SELECT g_0.NUM FROM oracle.TEST01 AS g_0 > 14:03:17,314 DEBUG [org.teiid.COMMAND_LOG] (Worker1_QueryProcessorQueue1) MH/yC1t35aMa SOURCE SRC COMMAND: endTime=2018-12-13 14:03:17.314 requestID=MH/yC1t35aMa.0 sourceCommandID=0 executionID=0 txID=null modelName=oracle translatorName=oracle sessionID=MH/yC1t35aMa principal=teiidUser@teiid-security sourceCommand=[SELECT g_0."NUM" FROM "TESTDB"."TEST01" g_0] > 14:03:17,440 DEBUG [org.teiid.COMMAND_LOG] (Worker0_QueryProcessorQueue2) MH/yC1t35aMa END SRC COMMAND: endTime=2018-12-13 14:03:17.44 requestID=MH/yC1t35aMa.0 sourceCommandID=0 executionID=0 txID=null modelName=oracle translatorName=oracle sessionID=MH/yC1t35aMa principal=teiidUser@teiid-security finalRowCount=4 cpuTime(ns)=121768769 > 14:03:17,481 INFO [org.teiid.COMMAND_LOG] (Worker0_QueryProcessorQueue3) MH/yC1t35aMa END USER COMMAND: endTime=2018-12-13 14:03:17.481 requestID=MH/yC1t35aMa.0 txID=null sessionID=MH/yC1t35aMa principal=teiidUser@teiid-security vdbName=oraclevdb vdbVersion=1 finalRowCount=4 > {code} > This query is also same result. > select num, replace(name, null, 'a') from TEST01 > When the replace function is in view model as follows, the result is same as the above. > {code} > <model name="oracle_view" type="VIRTUAL"> > <property name="imports" value="oracle"/> > <metadata type="DDL"><![CDATA[ > CREATE VIEW V_TEST01 ( > NUM bigdecimal(38) NOT NULL OPTIONS(NAMEINSOURCE '"NUM"', NATIVE_TYPE 'NUMBER', UPDATABLE 'FALSE', FIXED_LENGTH 'TRUE'), > NAME string(20) OPTIONS(NAMEINSOURCE '"NAME"', NATIVE_TYPE 'VARCHAR2', UPDATABLE 'FALSE'), > CONSTRAINT PK_NUM PRIMARY KEY(NUM) OPTIONS(NAMEINSOURCE '"PK_NUM"') > ) OPTIONS(NAMEINSOURCE '"TESTDB"."TEST01"') > AS > SELECT > t.NUM, replace(t.NAME, 'a', null) AS name > FROM > oracle.TEST01 AS t; > ]]></metadata> > </model> > {code} -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 5 months

1
0
0 / 0

[JBoss JIRA] (TEIID-5573) Ending a teiid odata url with a slash causes a 'Malformed URI' error

by Paul Richardson (Jira)

Paul Richardson created TEIID-5573: -------------------------------------- Summary: Ending a teiid odata url with a slash causes a 'Malformed URI' error Key: TEIID-5573 URL: https://issues.jboss.org/browse/TEIID-5573 Project: Teiid Issue Type: Bug Components: OData Affects Versions: 9.1.1 Reporter: Paul Richardson Assignee: Steven Hawkins As discussed on #teiid (IRC), the URI used to access a teiid odata service fails if a '/' is appended to it, eg. {code:java} https://${HOST}:${PORT}/odata4/usstates/USStates/SvcView/ {code} This results in this error (in Chrome): {code:xml} <error xmlns="http://docs.oasis-open.org/odata/ns/metadata"> <script/> <code>null</code> <message>The URI is malformed.</message> </error> {code} Removing the '/' works correctly. This appears to be an underlying problem with the olingo4 libraries since the [tutorial|https://olingo.apache.org/doc/odata4/tutorials/read/tutorial_rea...] when implemented suffers the same error. However, the odata.org reference [implementation|https://services.odata.org/TripPinRESTierService/(S(4gus0w...] does handle the slash correctly. *_Why does this matter?_* The [camel-odata|https://github.com/apache/camel/blob/master/components/camel-...] connector uses the olingo4 libraries and positively [adds|https://github.com/apache/camel/blob/master/components/camel-olingo4...] a '/' when forming the full URI to read data. This camel connector was originally created using the reference odata implementation as test data so unsurprising that it assumes the extra '/'. *_Who should fix what?_* Probably, the olingo4 libraries should be fixed to correctly handle the extra '/'. However, that would require both teiid and the camel odata-connector picking up a new version of the library, which may well take some time. From the discussion on IRC, it is possible to workaround this in teiid with the use of _'servlet filters'_. *_Tested version_* The version of teiid actually tested is 9.1.1 but would imagine that later versions may also be affected given it is ultimately a problem with the olingo4 libraries. -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 5 months

1
0
0 / 0

[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: --------------------------------------- Updated the pr with the removal of the javax.resource dependency from the core. It has now been pushed to each resource adapter and a new module teiid-resource-spi. I've checked the changes against java 8 and 11. [~rareddy] [~van.halbert] Have a look at the pr and see what you think. Possible issues: any disagreement with the new module names are you ok with using TranslatorException instead of ResourceException This just leaves org.jboss.spec.javax.xml.ws as the only a dependency of teiid-api that could be refined out - or just replaced with the generic java equivalent. > 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)

5 years, 5 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

teiid-issues December 2018