Marking the parent issue as resolved with module name changes to add consistency to the stuff under the wildfly module. Also updated the admin guide with the migration notes.

rhn-engineering-vhalbert on the javax stuff - that was mostly dealt with by the changes to allow for building with java 11. Anything that was no longer part of the runtime jar is referenced via a maven dependency. The only lingering issue for me is that we consolidated on the wildfly dependencies for consistency, but should probably switch to their generic equivalents now. That's called out in the pom as a todo.

There is never better timing, since we are in flow I suggest take the plunge

So the proposal for Teiid 12 is to redo the group and some of the artifact names under the wildfly module - they will have a consistent parent, go back to using the term connector, and replace jboss with wildfly where appropriate.

This will affect a limited number of users of Teiid embedded that have followed the teiid embedded examples (which will need updated) that reference the resource adapter jars.

I'm fine if we defer the change to translators group id.

Now that the wildfly reorg is done, can this be closed and a new one opened to focus on what's to be done next?

> (1) one involves many pom changes, 4 will result in a lot of doc changes I think.

We can do this in two phases if that makes sense - Teiid 12 reorg and propose new module names, then change things in 13. The only things that have actually changed in the coordinates at this point are the wildfly kit artifacts.

> 1) It seems appropriate to introduce the "org.teiid.wildfly" as groupid for any projects underneath "wildfly" module.

This for example will look like org.teiid.wildfly:teiid-wildfly-admin

> 3) Consider renaming project from "connector-xxxx" to "xxxx-ra" or "ra-xxxx", this along with group-id clearly separate them as WildFly constructs. But this is not really required.

I'm fine with leaving them as they are - especially if we do 4. Connector is the common name for resource adapter.

> 4) org.teiid.translator makes sense, but only for aesthetic reasons. Probably provides more clarity for nomenclature and removes "connectors" altogether which could be duplicate in times with connector, and relieves us from legacy names.

Yes this is the change that clarifies things the most.

Couple suggestions.

1) It seems appropriate to introduce the "org.teiid.wildfly" as groupid for any projects underneath "wildfly" module.

2) Consider getting rid of the duplicate definition of "groupid" in the projects like "connector-xxxx", that will base their group id to "org.teiid.wildfly.resource-adapters". If we can't do (1) then at least introduce that for resource-adapters module and down.

3) Consider renaming project from "connector-xxxx" to "xxxx-ra" or "ra-xxxx", this along with group-id clearly separate them as WildFly constructs. But this is not really required.

4) org.teiid.translator makes sense, but only for aesthetic reasons. Probably provides more clarity for nomenclature and removes "connectors" altogether which could be duplicate in times with connector, and relieves us from legacy names.

(1) one involves many pom changes, 4 will result in a lot of doc changes I think.

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

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.

Is there any concern over the name wildfly-parent vs. teiid-wildfly-parent - since there is already an org.wildfly:wildfly-parent pom?

We should consider if the wildfly-parent should have the managed dependencies for the connectors, rather than the teiid-bom.

I've built on your commit: https://github.com/shawkins/teiid/tree/TEIID-5563

• moved resource-spi to wildfly
• moved all javax.resource out of the core - which also requires moving eclipselink and hotrod tests to integration. Although I only moved the test java and didn't fully hook things back up.
• moved the teiid-build-configuration-parent off of the jboss-parent - a follow on is to use basepom instead.
• similarly moved wildfly-parent to jboss-parent instead of teiid-parent - I know this may end up causing us to have some duplicate plugin configuration.

> commented out the following 2 tests that will need to be reevaluated (jira will be created if not resolved in the commit), something to do with transaction timeouts

I'll try to determine what's going on there and get the new integration tests running, then have you rebase to that.

Here is the branch that has the changes: https://github.com/vhalbert/teiid/tree/teiid-5577

• wildfly submodule is the submodule
• new profile: wildfly and wildfly was added to the release and final-release
• commented out the following 2 tests that will need to be reevaluated (jira will be created if not resolved in the commit), something to do with transaction timeouts
  a. org.teiid.metadatastore.TestDDLMetadataStore.testVDBExport (runtime)
  b. org.teiid.translator.infinispan.hotrod.TestHotrodExecution (translator-infinispan) - both tests

> With the removal of the wildfly related dependencies from the core build, there are numerous dependencies that the engine, runtime, olingo, rest-service, etc. are now missing.

Yes, they will need to be duplicated. I modified your commit to just put all of that in the teiid-bom https://github.com/shawkins/teiid/commit/1df3f49ff7df4d4bfa9d9dbb1a5f28a014a7493d

Any wildfly dependencies coming from the wildfly parents that are used in jboss*, connectors, and the integration project will not be duplicated.

> because all these will need to be added to the "teiid-jboss-bom"?

I've backed off the idea of a separate shared bom for now. It doesn't seem to buy us as much as I thought and it seems to just add to the complexity of things.

With the removal of the wildfly related dependencies from the core build, there are numerous dependencies that the engine, runtime, olingo, rest-service, etc. are now missing. So I assume this is the part about managing the duplicate dependencies, because all these will need to be added to the "teiid-jboss-bom"?

The resource dependency has now been removed from the engine. We needed a new interface XAImporter to encapsulate the functionality provided by the workmanager and xaterminator. For simplicity the interface is in teiid-api and the impl is in teiid-resource-spi. This does mean that api still has a dependency to javax.transaction, but since that still exists in the engine it's a minor issue.

xml.ws has now been moved out of teiid-api by just putting the connection interface with the translator.

> Do you think we can refactor such a way that we can just make this as optional dependency required only in the imported XA transaction case?

Yes, I can introduce that with these changes.

Sorry, Forgot about #2. Do you think we can refactor such a way that we can just make this as optional dependency required only in the imported XA transaction case?

rareddy_mk-kafka There's a two usages:

1. we allowed for the workmanager to be pluggable as a thread pool, which then meant our work items needed to be Work. - I'd be ok with removing this feature.
2. The transaction service to handle imported xa transactions uses the workmanager and xaterminator - and transactioncontext extends ExecutionContext. - this is what seems to necessitate a refactoring

rhn-engineering-shawkins it is unfortunate the WorkManager stuff is in the javax.resource, but as I remember we do not actually use the WorkManager of JEE to submit teiid work right? Didn't we create our own threading model underneath this api to make the thread reuse? If that is case we can get rid of it, otherwise not sure what are the options

rareddy_mk-kafka Do you want to go to the extent of removing javax.resource from engine/runtime? That will require a new transaction/work specific module - it would still be separate from the jboss stuff as it seems like a third-party txn manager is something that may need supported, but without the jboss dependencies.

> Other than pulling that into ws-translator or replacing with something like HTTPConnection I guess there are not better options

Right, we'd have to introduce an api module or directly depend on the translator. I'll go ahead and move it into the translator as all of the dependent translators already reference the ws translator.

After this mornings discussion, my next step is to refactor the wildfly dependencies into a new submodule off the root.

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.

> 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.

>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.

rhn-engineering-shawkins Why dependency on "JAX-WS API" in api module? looks like a transitive dependency?

> 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.

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_mk-kafka 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.

TEIID-5066 is one I logged for the connection/ConnectionFactory work. I think we can separate teiid-wildfly module work and that as two separate tasks. I started a branch on this a while ago but quickly got blocked by my thinking to pull out a common connection factory for managing the properties for connection management. I do think, that is difficult to solve across different runtimes, and also sometimes we have no control over it as in teiid-komodo/syndesis combination. We can leave that to be distribution specific.

javax.activation - used by InputStreamFactory and an engine convention with translator logic (OData, Swagger, Webservice). 60-70k for the dependency. This is a low priority to remove.

For jboss-transaction-api and jboss-connector-api we can split out the org.teiid.resource.spi - but are still left with a few references:
ExecutionFactory has some built-in handling of javax.resource.Connection/ConnectionFactory.
FileConnection and WSConnection extend javax.resource.Connection - actually all of our "Connection" interfaces do this though. It should be fine to just strip this off as their implementation classes via BasicConnection are already required to implement javax.resource.Connection.

> That can be refined to jboss-client maven module. The kitted client jar doesn't need the modules logic.

The pr for that is: https://github.com/teiid/teiid/pull/1110

It can alternatively be simplified to just a single jboss module, but that effectively makes everything public.

> Yes, but I feel that we are giving precedent to WildFly but not others. I would like to see all of them released once if possible, or set course for each one. For example, release teiid-wildfly everytime WildFly and/or Teiid is released. I believe jenkins pipeline builds may solve this issue with multiple repos at same time.

Given the current state of things wildfly is the dominant. I'm all for getting to the next state - but lets have the build pipelines setup in advance of reperate repos, rather than the other way around.

So the initial steps are to create a new structure for the modules that isolates the wildfly dependencies and to remove the jboss/ee dependencies as much as possible from core teiid.

The next step is to promote builds that can trigger the creation of the runtime specific builds - what public jenkins will we use for that?

The last step is to move the wildfly stuff to its own repo.

sorry, I missed the updates from previous comments.

> Otherwise I would see a release across all runtimes.
Yes, but I feel that we are giving precedent to WildFly but not others. I would like to see all of them released once if possible, or set course for each one. For example, release teiid-wildfly everytime WildFly and/or Teiid is released. I believe jenkins pipeline builds may solve this issue with multiple repos at same time.

> I do not see a scenario where it makes sense to release a Teiid 13.1
I am looking at it as teiid as in a bunch of libraries, that one can spin up an embedded instance if they want to

> are you proposing new kititng / overlay / patching logic?
No, just ability to for user to fork and update dependencies if they need to, for example stay on teiid 10, but go to WildFly 14. Not that one would do this actively..

> It seemed that Ramesh was alluding to something in the intermediate term that would produce a faster moving core teiid and a slower moving teiid wildfly distribution.
I was thinking more independently moving Teiid rather than faster without runtime.

There are two topics here. The first is to just initially do this by moving the modules around. So basically what you have, but put it under a teiid-wildfly module. For now that would set aside any concerns about basepom, separate versioning, etc.

The other topic is what could it mean for an independent teiid-wildfly integration either in the near term or the long term. My basic argument is that in the near term separate repos/versions/releases will just lead to more work, but without much benefit. It seemed that Ramesh was alluding to something in the intermediate term that would produce a faster moving core teiid and a slower moving teiid wildfly distribution. I was asking about what the logistics of that would be.

Now that we're not splitting into a separate repo, I see the discussion about the remodulization should be attempted. When you say a separate module, are you saying that a new module layer within a wildfly distribution should be created? Like we currently have the "dv" layer, so another layer would be used to split the core teiid with the teiid-jboss extensions. Is this what you are wanting?

> But you being one who does all the builds I do understand the pain of more work, so, I am fine whatever we decide in the end

The overriding consideration is can this be done through maven modules alone - especially initially. If yes, then is using a separate repo overkill.

> Separate lifecycles is something we should consider IMO. Otherwise, we need to set a precedent and call about teiid-thorntail and teiid-spring-boot and how to handle those with a single build.

The primary release driver is Teiid itself. When will we release a Teiid 13.1 for example and not the corresponding runtime support? In my mind this would only occur if/when we have truly fundamental divergence - core Teiid is at JRE X and runtime R is at JRE Y. Otherwise I would see a release across all runtimes.

What you are probably more thinking of is likely the scenario that a fix is applicable to only runtime T, then can we get that out "faster", correct?

> Deemphasize WildFly as main distribution, set its course if we want to do regular updates or not. I understand that is we said for 13 and beyond.

See above. Unless there is a fundamental conflict, I do not see a scenario where it makes sense to release a Teiid 13.1 for example and not do it across all supported runtimes. Can you define what you mean by irregular updates? How that would benefit us? Or are you proposing a further restructuring of the distribution - such that there could be some kind of core teiid overlay on base kit of wildfly + teiid-wildfly integration?

> Gives a better option for the community to be at set Teiid version but update the resource-adapters or WildFly version. We can sync these releases more with WF releases?

Maybe that's an extension of what I'm asking above - are you proposing new kititng / overlay / patching logic? If so we need to understand what is being proposed.

> I also would like core Teiid to move to basepom after the changes. Clear separation of modules.
> I see we will be divergent in support of "data sources" based on distribution flavour. I would not be obligated, say if I came up with source support in SB not WildFly or vice versa.

Neither of these necessitate a new repo.

rhn-engineering-shawkins My thinking on separate repository as follows

1. Separate lifecycles is something we should consider IMO. Otherwise, we need to set a precedent and call about teiid-thorntail and teiid-spring-boot and how to handle those with a single build.
2. Deemphasize WildFly as main distribution, set its course if we want to do regular updates or not. I understand that is we said for 13 and beyond.
3. Gives a better option for the community to be at set Teiid version but update the resource-adapters or WildFly version. We can sync these releases more with WF releases?
4. I also would like core Teiid to move to basepom after the changes. Clear separation of modules.
5. I see we will be divergent in support of "data sources" based on distribution flavour. I would not be obligated, say if I came up with source support in SB not WildFly or vice versa.

But you being one who does all the builds I do understand the pain of more work, so, I am fine whatever we decide in the end

Then lets talk about this before I continue this path of resolving all these dependency issues.

> Does "client" need to be moved to teiid-wildfly, it has a dependency on org.jboss.modules in the ModuleHelper.

That can be refined to jboss-client maven module. The kitted client jar doesn't need the modules logic.

Thinking about things some more, I'm not sure about using a separate repository at this point. It seems to needlessly complicate the release process. If on every teiid release we will release a version of the wildfly integration, it would be much simpler to have this all under one repository. As is, I'd likely link to the new repo as a git submodule. If and only if the projects have different lifecycles does a separate repo / versioning seem necessary.

No, client should not be moved to teiid-wildfly but we need to find an alternative way to resolve that or move only the affected code etc. Leave dependency as is for now, either rhn-engineering-shawkins and myself need to redo some refactoring there to get rid of the modules dependency altogether, it is optional even now.

BTW, eclipselink-platform is like Hibernate should be aligned with core Teiid IMO. Overall I think it looks pretty good

I suspect more build type changes on Teiid Core side.

Does "client" need to be moved to teiid-wildfly, it has a dependency on org.jboss.modules in the ModuleHelper.

Now I'm working on the changes to teiid/teiid.git.

All the teiid-core projects have been removed. Now going about cleaning up:

• renaming to teiid-wildfly in the pom's.
• updating README.md

Done, updated to teiid-wildfly.

Before I move this repo to teiid/teiid-wildfly, would like a review to see if there is anything else you would like changed.

Here are the modules that are left to call from the root pom.xml:

                <module>build-configuration</module>
		<module>eclipselink-platform</module>		
		<module>jboss-admin</module>
		<module>jboss-integration</module>
		<module>jboss-security</module>
		<module>teiid-feature-pack</module>
               <module>connectors</module>

accidentally pulled out test-integration, adding it back

Cool, magic! It will work until we change the pom versions of it. The pulled out translators needed to be added as dependencies, then start pulling out teiid core libraries except for

• jboss-integration
• jboss-admin
• jboss-security
• test-integration

BTW, all the feature-pack projects whether they belong to Teiid Core or not will stay this repo. Also any "api" modules also move along with Translators. However, "build" stuff stays here.

It appears the parent fork is no longer there: https://github.com/vhalbert/teiid-wildfly

Locally, I've got the translators pulled out, building and the wildfly kit still working.

van.halbert were you able to remove the parent fork out of it? because that would be the key, to push this back into its own repo later with history. I am also not sure if the parent fork is removed if history is still intact or not, if not you have to follow what rhn-engineering-shawkins is suggesting.

rareddy_mk-kafka I've created my version of teiid-wildfly, using the above technique, and begun removing what's not needed.

van.halbert Another option is to leave the current repo as is to begin with and follow this way to create your clone https://stackoverflow.com/questions/16052477/delete-fork-dependency-of-a-github-repository then edit the clone that way we can keep all the version history directory structures etc. We need to keep version history if possible at all.

rhn-engineering-vhalbert start with this as a module before moving to a different repo.