[JBoss JIRA] (TEIID-5574) Clarify buffer manager property names
by Steven Hawkins (Jira)
[ https://issues.jboss.org/browse/TEIID-5574?page=com.atlassian.jira.plugin... ]
Steven Hawkins edited comment on TEIID-5574 at 12/18/18 3:14 PM:
-----------------------------------------------------------------
Starting with the bufferservice I'll work in both directions to rationalize names. What we want to convey is that there are three tiers of caching / managed buffers. We'll stick with the terms buffer / buffer manager rather than cache. Things break down along the lines of:
* Heap Buffer
* Fixed Memory Buffer
* Disk Buffer
Also the notion of memory usage by the heap buffer is complicated because that is shared with the vm and by processing work. So we've used the term reserve to talk about what plans and the vm can "reserve" of the heap space.
While heap holds direct object references, Fixed Memory and Disk tiers hold much denser columnar serialized forms of the batches / pages. Side note: ideally that could be more fluid - years ago I started on the changes that would allow serialized batches to be used directly, but abandoned those changes. Spark has the ability to do that which can help cut down quite a bit of serialization overhead in things like multi-pass sorts.
The initial changes would be:
Heap Buffer
maxReservedKb -> maxReservedHeapKb
heapCacheMemoryInUseKB -> heapBufferInUseKb (I'll add a note that this can be greater than the max reserved - which adds back pressure on plans to wait for memory reservations and forces more evictions by workers and the cleaner lower tiers)
heapMemoryInUseByActivePlansKB -> heapReservedByActivePlansKb
Fixed Memory
memoryBufferOffHeap -> fixedMemoryBufferOffHeap
memoryBufferSpace -> fixedMemeoryBufferSpaceMb
Disk
maxBufferSpace -> maxDiskBufferSpaceMb
Other
maxStorageObjectSize -> maxStorageObjectSizeBytes
cacheReadCount/WriteCount -> fixedMemoryReadCount/WriteCount
It probably also makes sense to normalize to Mb, so maxReservedHeapMb instead.
The initial target would be to keep and deprecate the legacy properties.
[~rareddy] [~rhn-engineering-vhalbert] Any thoughts or suggestions?
was (Author: shawkins):
Starting with the bufferservice I'll work in both directions to rationalize names. What we want to convey is that there are three tiers of caching / managed buffers. We'll stick with the terms buffer / buffer manager rather than cache. Things break down along the lines of:
* Heap Buffer
* Fixed Memory Buffer
* Disk Buffer
Also the notion of memory usage by the heap buffer is complicated because that is shared with the vm and by processing work. So we've used the term reserve to talk about what plans and the vm can "reserve" of the heap space.
While heap holds direct object references, Fixed Memory and Disk tiers hold much denser columnar serialized forms of the batches / pages. Side note: ideally that could be more fluid - years ago I started on the changes that would allow serialized batches to be used directly, but abandoned those changes. Spark has the ability to do that which can help cut down quite a bit of serialization overhead in things like multi-pass sorts.
The initial changes would be:
Heap Buffer
maxReservedKb -> maxReservedHeapKb
heapCacheMemoryInUseKB -> heapBufferInUseKb (I'll add a note that this can be greater than the max reserved - which adds back pressure on plans to wait for memory reservations and forces more evictions by workers and the cleaner lower tiers)
heapMemoryInUseByActivePlansKB -> heapReservedByActivePlansKb
Fixed Memory
memoryBufferOffHeap -> fixedMemoryBufferOffHeap
memoryBufferSpace -> fixedMemeoryBufferSpaceMb
Disk
maxBufferSpace -> maxDiskBufferSpaceMb
Other
maxStorageObjectSize -> maxStorageObjectSizeBytes
cacheReadCount/WriteCount -> storageReadCount/WriteCount
It probably also makes sense to normalize to Mb, so maxReservedHeapMb instead.
The initial target would be to keep and deprecate the legacy properties.
[~rareddy] [~rhn-engineering-vhalbert] Any thoughts or suggestions?
> Clarify buffer manager property names
> -------------------------------------
>
> Key: TEIID-5574
> URL: https://issues.jboss.org/browse/TEIID-5574
> Project: Teiid
> Issue Type: Quality Risk
> Components: Query Engine, Server
> Reporter: Steven Hawkins
> Assignee: Steven Hawkins
> Priority: Major
> Fix For: 12.0
>
>
> Where possible the buffer manager properties should be better differentiated. Instead of max-buffer-space for example, we could have max-buffer-disk-space-mb.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 1 month
[JBoss JIRA] (TEIID-5577) Create clean dependencies / separate boms
by Van Halbert (Jira)
[ https://issues.jboss.org/browse/TEIID-5577?page=com.atlassian.jira.plugin... ]
Van Halbert commented on TEIID-5577:
------------------------------------
The commit for TEIID-5577 will be to align the teiid-jboss-bom and related dependencies. The TEIID-5563 will be realign the wildfly dependencies.
> Create clean dependencies / separate boms
> -----------------------------------------
>
> Key: TEIID-5577
> URL: https://issues.jboss.org/browse/TEIID-5577
> Project: Teiid
> Issue Type: Sub-task
> Components: Build/Kits
> Reporter: Steven Hawkins
> Assignee: Van Halbert
> Priority: Major
>
> The teiid-bom currently defines all of the non-overlapping dependencies with the wildfly bom.
> We should introduce another bom that defines the overlapping dependencies used by the core project - this includes things like vfs, jboss-logging, the javax api jars, marshalling, infinispan, etc. We should also substitute usage of the jboss javax jars for whatever the vanilla replacements are.
> We should then be able to cut ties with wildfly boms in the core project.
> For connector development convenience we could also introduce a bom-wildfly which imports both the teiid-bom and the wildfly-parent.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 1 month
[JBoss JIRA] (TEIID-5574) Clarify buffer manager property names
by Steven Hawkins (Jira)
[ https://issues.jboss.org/browse/TEIID-5574?page=com.atlassian.jira.plugin... ]
Steven Hawkins edited comment on TEIID-5574 at 12/18/18 2:58 PM:
-----------------------------------------------------------------
Starting with the bufferservice I'll work in both directions to rationalize names. What we want to convey is that there are three tiers of caching / managed buffers. We'll stick with the terms buffer / buffer manager rather than cache. Things break down along the lines of:
* Heap Buffer
* Fixed Memory Buffer
* Disk Buffer
Also the notion of memory usage by the heap buffer is complicated because that is shared with the vm and by processing work. So we've used the term reserve to talk about what plans and the vm can "reserve" of the heap space.
While heap holds direct object references, Fixed Memory and Disk tiers hold much denser columnar serialized forms of the batches / pages. Side note: ideally that could be more fluid - years ago I started on the changes that would allow serialized batches to be used directly, but abandoned those changes. Spark has the ability to do that which can help cut down quite a bit of serialization overhead in things like multi-pass sorts.
The initial changes would be:
Heap Buffer
maxReservedKb -> maxReservedHeapKb
heapCacheMemoryInUseKB -> heapBufferInUseKb (I'll add a note that this can be greater than the max reserved - which adds back pressure on plans to wait for memory reservations and forces more evictions by workers and the cleaner lower tiers)
heapMemoryInUseByActivePlansKB -> heapReservedByActivePlansKb
Fixed Memory
memoryBufferOffHeap -> fixedMemoryBufferOffHeap
memoryBufferSpace -> fixedMemeoryBufferSpaceMb
Disk
maxBufferSpace -> maxDiskBufferSpaceMb
Other
maxStorageObjectSize -> maxStorageObjectSizeBytes
cacheReadCount/WriteCount -> storageReadCount/WriteCount
It probably also makes sense to normalize to Mb, so maxReservedHeapMb instead.
The initial target would be to keep and deprecate the legacy properties.
[~rareddy] [~rhn-engineering-vhalbert] Any thoughts or suggestions?
was (Author: shawkins):
Starting with the bufferservice I'll work in both directions to rationalize names. What we want to convey is that there are three tiers of caching / managed buffers. We'll stick with the terms buffer / buffer manager rather than cache. Things break down along the lines of:
* Heap Buffer
* Fixed Memory Buffer
* Disk Buffer
Also the notion of memory usage by the heap buffer is complicated because that is shared with the vm and by processing work. So we've used the term reserve to talk about what plans and the vm can "reserve" of the heap space.
While heap holds direct object references, Fixed Memory and Disk tiers hold much denser columnar serialized forms of the batches / pages. Side note: ideally that could be more fluid - years ago I started on the changes that would allow serialized batches to be used directly, but abandoned those changes. Spark has the ability to do that which can help cut down quite a bit of serialization overhead in things like multi-pass sorts.
The initial changes would be:
Heap Buffer
maxReservedKb -> maxReservedHeapKb
heapCacheMemoryInUseKB -> heapBufferInUseKb (I'll add a note that this can be greater than the max reserved - which adds back pressure on plans to wait for memory reservations and forces more evictions by workers and the cleaner lower tiers)
heapMemoryInUseByActivePlansKB -> heapReservedByActivePlansKb
Fixed Memory
memoryBufferOffHeap -> fixedMemoryBufferOffHeap
memoryBufferSpace -> fixedMemeoryBufferSpaceMb
Disk
maxBufferSpace -> maxDiskBufferSpaceMb
Other
maxStorageObjectSize -> maxStorageObjectSizeBytes
cacheReadCount/WriteCount -> serializedReadCount/WriteCount (see side note above, if things are more fluid serialized may not be the right term here)
It probably also makes sense to normalize to Mb, so maxReservedHeapMb instead.
The initial target would be to keep and deprecate the legacy properties.
[~rareddy] [~rhn-engineering-vhalbert] Any thoughts or suggestions?
> Clarify buffer manager property names
> -------------------------------------
>
> Key: TEIID-5574
> URL: https://issues.jboss.org/browse/TEIID-5574
> Project: Teiid
> Issue Type: Quality Risk
> Components: Query Engine, Server
> Reporter: Steven Hawkins
> Assignee: Steven Hawkins
> Priority: Major
> Fix For: 12.0
>
>
> Where possible the buffer manager properties should be better differentiated. Instead of max-buffer-space for example, we could have max-buffer-disk-space-mb.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 1 month
[JBoss JIRA] (TEIID-5577) Create clean dependencies / separate boms
by Van Halbert (Jira)
[ https://issues.jboss.org/browse/TEIID-5577?page=com.atlassian.jira.plugin... ]
Van Halbert commented on TEIID-5577:
------------------------------------
Yes, that clarifies it.
> Create clean dependencies / separate boms
> -----------------------------------------
>
> Key: TEIID-5577
> URL: https://issues.jboss.org/browse/TEIID-5577
> Project: Teiid
> Issue Type: Sub-task
> Components: Build/Kits
> Reporter: Steven Hawkins
> Assignee: Van Halbert
> Priority: Major
>
> The teiid-bom currently defines all of the non-overlapping dependencies with the wildfly bom.
> We should introduce another bom that defines the overlapping dependencies used by the core project - this includes things like vfs, jboss-logging, the javax api jars, marshalling, infinispan, etc. We should also substitute usage of the jboss javax jars for whatever the vanilla replacements are.
> We should then be able to cut ties with wildfly boms in the core project.
> For connector development convenience we could also introduce a bom-wildfly which imports both the teiid-bom and the wildfly-parent.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 1 month
[JBoss JIRA] (TEIID-5574) Clarify buffer manager property names
by Steven Hawkins (Jira)
[ https://issues.jboss.org/browse/TEIID-5574?page=com.atlassian.jira.plugin... ]
Steven Hawkins edited comment on TEIID-5574 at 12/18/18 2:53 PM:
-----------------------------------------------------------------
Starting with the bufferservice I'll work in both directions to rationalize names. What we want to convey is that there are three tiers of caching / managed buffers. We'll stick with the terms buffer / buffer manager rather than cache. Things break down along the lines of:
* Heap Buffer
* Fixed Memory Buffer
* Disk Buffer
Also the notion of memory usage by the heap buffer is complicated because that is shared with the vm and by processing work. So we've used the term reserve to talk about what plans and the vm can "reserve" of the heap space.
While heap holds direct object references, Fixed Memory and Disk tiers hold much denser columnar serialized forms of the batches / pages. Side note: ideally that could be more fluid - years ago I started on the changes that would allow serialized batches to be used directly, but abandoned those changes. Spark has the ability to do that which can help cut down quite a bit of serialization overhead in things like multi-pass sorts.
The initial changes would be:
Heap Buffer
maxReservedKb -> maxReservedHeapKb
heapCacheMemoryInUseKB -> heapBufferInUseKb (I'll add a note that this can be greater than the max reserved - which adds back pressure on plans to wait for memory reservations and forces more evictions by workers and the cleaner lower tiers)
heapMemoryInUseByActivePlansKB -> heapReservedByActivePlansKb
Fixed Memory
memoryBufferOffHeap -> fixedMemoryBufferOffHeap
memoryBufferSpace -> fixedMemeoryBufferSpaceMb
Disk
maxBufferSpace -> maxDiskBufferSpaceMb
Other
maxStorageObjectSize -> maxStorageObjectSizeBytes
cacheReadCount/WriteCount -> serializedReadCount/WriteCount (see side note above, if things are more fluid serialized may not be the right term here)
It probably also makes sense to normalize to Mb, so maxReservedHeapMb instead.
The initial target would be to keep and deprecate the legacy properties.
[~rareddy] [~rhn-engineering-vhalbert] Any thoughts or suggestions?
was (Author: shawkins):
Starting with the bufferservice I'll work in both directions to rationalize names. What we want to convey is that there are three tiers of caching / managed buffers. We'll stick with the terms buffer / buffer manager rather than cache. Things break down along the lines of:
* Heap Buffer
* Fixed Memory Buffer
* Disk Buffer
Also the notion of memory usage by the heap buffer is complicated because that is shared with the vm and by processing work. So we've used the term reserve to talk about what plans and the vm can "reserve" of the heap space.
While heap holds direct object references, Fixed Memory and Disk tiers hold much denser columnar serialized forms of the batches / pages. Side note: ideally that could be more fluid - years ago I started on the changes that would allow serialized batches to be used directly, but abandoned those changes. Spark has the ability to do that which can help cut down quite a bit of serialization overhead in things like multi-pass sorts.
The initial changes would be:
Heap Buffer
maxReservedKb -> maxReservedHeapKb
heapCacheMemoryInUseKB -> heapBufferInUseKb (I'll add a note that this can be greater than the max reserved - which adds back pressure on plans to wait for memory reservations and forces more evictions by workers and the cleaner lower tiers)
heapMemoryInUseByActivePlansKB -> heapReservedByActivePlansKb
Fixed Memory
memoryBufferOffHeap -> fixedMemoryBufferOffHeap
memoryBufferSpace -> fixedMemeoryBufferSpaceMb
Disk
maxBufferSpace -> maxDiskBufferSpaceMb
Other
maxStorageObjectSize -> maxStorageObjectSizeBytes
cacheReadCount/WriteCount -> serializedReadCount/WriteCount (see side note above, if things are more fluid serialized may not be the right term here)
It probably also makes sense to normalize to Mb, so maxReservedHeapKb instead.
The initial target would be to keep and deprecate the legacy properties.
[~rareddy] [~rhn-engineering-vhalbert] Any thoughts or suggestions?
> Clarify buffer manager property names
> -------------------------------------
>
> Key: TEIID-5574
> URL: https://issues.jboss.org/browse/TEIID-5574
> Project: Teiid
> Issue Type: Quality Risk
> Components: Query Engine, Server
> Reporter: Steven Hawkins
> Assignee: Steven Hawkins
> Priority: Major
> Fix For: 12.0
>
>
> Where possible the buffer manager properties should be better differentiated. Instead of max-buffer-space for example, we could have max-buffer-disk-space-mb.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 1 month
[JBoss JIRA] (TEIID-5577) Create clean dependencies / separate boms
by Steven Hawkins (Jira)
[ https://issues.jboss.org/browse/TEIID-5577?page=com.atlassian.jira.plugin... ]
Steven Hawkins commented on TEIID-5577:
---------------------------------------
> as for wildfly-parent, wouldn't it be: wildfly-parent imports teiid-bom and wildfly-bom
I'm not qualifying things enough. The wildfly dependencies come from org.wildfly:wildfly-parent and also org.wildfle.core:wildfly-core-parent. I mean our wildfly bom will need to import teiid bom and from the wildfly parents (which is currently being done in our root pom).
> as to the teiid+shared bom, why not just have the teiid root pom import both the teiid-bom and jboss-dependency bom, then no need for another bom, and the wildfly parent would then import them both too, beside the wildfly bom
Sounds good. We should probably adjust the naming convention a little to use the teiid- prefix. What you are proposing would look like:
org.teiid:teiid-bom - just teiid dependencies
org.teiid:teiid-jboss-bom - just the overlap
org.teiid:teiid-parent - imports the teiid-bom and jboss-bom
org.teiid:teiid-wildfly-parent - imports the teiid-bom and wildfly parents and is the parent for stuff under the wildfly module
Such that the teiid-parent or teiid-wildfly-parent could be used a boms themselves where needed. Is that correct?
> Create clean dependencies / separate boms
> -----------------------------------------
>
> Key: TEIID-5577
> URL: https://issues.jboss.org/browse/TEIID-5577
> Project: Teiid
> Issue Type: Sub-task
> Components: Build/Kits
> Reporter: Steven Hawkins
> Assignee: Van Halbert
> Priority: Major
>
> The teiid-bom currently defines all of the non-overlapping dependencies with the wildfly bom.
> We should introduce another bom that defines the overlapping dependencies used by the core project - this includes things like vfs, jboss-logging, the javax api jars, marshalling, infinispan, etc. We should also substitute usage of the jboss javax jars for whatever the vanilla replacements are.
> We should then be able to cut ties with wildfly boms in the core project.
> For connector development convenience we could also introduce a bom-wildfly which imports both the teiid-bom and the wildfly-parent.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 1 month
[JBoss JIRA] (TEIID-5577) Create clean dependencies / separate boms
by Van Halbert (Jira)
[ https://issues.jboss.org/browse/TEIID-5577?page=com.atlassian.jira.plugin... ]
Van Halbert commented on TEIID-5577:
------------------------------------
sure, jboss-dependency-bom, and a child of build-configuration
as for wildfly-parent, wouldn't it be: wildfly-parent imports teiid-bom and wildfly-bom
as to the teiid+shared bom, why not just have the teiid root pom import both the teiid-bom and jboss-dependency bom, then no need for another bom, and the wildfly parent would then import them both too, beside the wildfly bom
> Create clean dependencies / separate boms
> -----------------------------------------
>
> Key: TEIID-5577
> URL: https://issues.jboss.org/browse/TEIID-5577
> Project: Teiid
> Issue Type: Sub-task
> Components: Build/Kits
> Reporter: Steven Hawkins
> Assignee: Van Halbert
> Priority: Major
>
> The teiid-bom currently defines all of the non-overlapping dependencies with the wildfly bom.
> We should introduce another bom that defines the overlapping dependencies used by the core project - this includes things like vfs, jboss-logging, the javax api jars, marshalling, infinispan, etc. We should also substitute usage of the jboss javax jars for whatever the vanilla replacements are.
> We should then be able to cut ties with wildfly boms in the core project.
> For connector development convenience we could also introduce a bom-wildfly which imports both the teiid-bom and the wildfly-parent.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 1 month
[JBoss JIRA] (TEIID-5574) Clarify buffer manager property names
by Steven Hawkins (Jira)
[ https://issues.jboss.org/browse/TEIID-5574?page=com.atlassian.jira.plugin... ]
Steven Hawkins commented on TEIID-5574:
---------------------------------------
Starting with the bufferservice I'll work in both directions to rationalize names. What we want to convey is that there are three tiers of caching / managed buffers. We'll stick with the terms buffer / buffer manager rather than cache. Things break down along the lines of:
* Heap Buffer
* Fixed Memory Buffer
* Disk Buffer
Also the notion of memory usage by the heap buffer is complicated because that is shared with the vm and by processing work. So we've used the term reserve to talk about what plans and the vm can "reserve" of the heap space.
While heap holds direct object references, Fixed Memory and Disk tiers hold much denser columnar serialized forms of the batches / pages. Side note: ideally that could be more fluid - years ago I started on the changes that would allow serialized batches to be used directly, but abandoned those changes. Spark has the ability to do that which can help cut down quite a bit of serialization overhead in things like multi-pass sorts.
The initial changes would be:
Heap Buffer
maxReservedKb -> maxReservedHeapKb
heapCacheMemoryInUseKB -> heapBufferInUseKb (I'll add a note that this can be greater than the max reserved - which adds back pressure on plans to wait for memory reservations and forces more evictions by workers and the cleaner lower tiers)
heapMemoryInUseByActivePlansKB -> heapReservedByActivePlansKb
Fixed Memory
memoryBufferOffHeap -> fixedMemoryBufferOffHeap
memoryBufferSpace -> fixedMemeoryBufferSpaceMb
Disk
maxBufferSpace -> maxDiskBufferSpaceMb
Other
maxStorageObjectSize -> maxStorageObjectSizeBytes
cacheReadCount/WriteCount -> serializedReadCount/WriteCount (see side note above, if things are more fluid serialized may not be the right term here)
It probably also makes sense to normalize to Mb, so maxReservedHeapKb instead.
The initial target would be to keep and deprecate the legacy properties.
[~rareddy] [~rhn-engineering-vhalbert] Any thoughts or suggestions?
> Clarify buffer manager property names
> -------------------------------------
>
> Key: TEIID-5574
> URL: https://issues.jboss.org/browse/TEIID-5574
> Project: Teiid
> Issue Type: Quality Risk
> Components: Query Engine, Server
> Reporter: Steven Hawkins
> Assignee: Steven Hawkins
> Priority: Major
> Fix For: 12.0
>
>
> Where possible the buffer manager properties should be better differentiated. Instead of max-buffer-space for example, we could have max-buffer-disk-space-mb.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 1 month
[JBoss JIRA] (TEIID-5577) Create clean dependencies / separate boms
by Steven Hawkins (Jira)
[ https://issues.jboss.org/browse/TEIID-5577?page=com.atlassian.jira.plugin... ]
Steven Hawkins commented on TEIID-5577:
---------------------------------------
Can we call it jboss-dependency-bom - that matches some of other naming conventions? Should it be a child of build-configuration?
The wildfly bom will import from the teiid-bom and the wildfly-parent correct?
As for teiid-bom importing the shared dependencies - it may make sense to keep them separate and also create a teiid-all (teiid+shared) bom.
> Create clean dependencies / separate boms
> -----------------------------------------
>
> Key: TEIID-5577
> URL: https://issues.jboss.org/browse/TEIID-5577
> Project: Teiid
> Issue Type: Sub-task
> Components: Build/Kits
> Reporter: Steven Hawkins
> Assignee: Van Halbert
> Priority: Major
>
> The teiid-bom currently defines all of the non-overlapping dependencies with the wildfly bom.
> We should introduce another bom that defines the overlapping dependencies used by the core project - this includes things like vfs, jboss-logging, the javax api jars, marshalling, infinispan, etc. We should also substitute usage of the jboss javax jars for whatever the vanilla replacements are.
> We should then be able to cut ties with wildfly boms in the core project.
> For connector development convenience we could also introduce a bom-wildfly which imports both the teiid-bom and the wildfly-parent.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 1 month
[JBoss JIRA] (TEIID-5577) Create clean dependencies / separate boms
by Van Halbert (Jira)
[ https://issues.jboss.org/browse/TEIID-5577?page=com.atlassian.jira.plugin... ]
Van Halbert commented on TEIID-5577:
------------------------------------
Here's the structure I'm proposing:
- pom.xml (root)
- build-configuration
-- pom.xml (control version properties for bom and parent to root)
-- bom / pom.xml (teiid core bom) imports inter-dependency-bom
- inter-dependency-bom
-- pom.xml (bom for overlapping dependencies)
- wildfly/bom/pom.xml (wildfly bom)
> Create clean dependencies / separate boms
> -----------------------------------------
>
> Key: TEIID-5577
> URL: https://issues.jboss.org/browse/TEIID-5577
> Project: Teiid
> Issue Type: Sub-task
> Components: Build/Kits
> Reporter: Steven Hawkins
> Assignee: Van Halbert
> Priority: Major
>
> The teiid-bom currently defines all of the non-overlapping dependencies with the wildfly bom.
> We should introduce another bom that defines the overlapping dependencies used by the core project - this includes things like vfs, jboss-logging, the javax api jars, marshalling, infinispan, etc. We should also substitute usage of the jboss javax jars for whatever the vanilla replacements are.
> We should then be able to cut ties with wildfly boms in the core project.
> For connector development convenience we could also introduce a bom-wildfly which imports both the teiid-bom and the wildfly-parent.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 1 month