[
https://issues.jboss.org/browse/TEIID-4437?page=com.atlassian.jira.plugin...
]
Kylin Soong commented on TEIID-4437:
------------------------------------
Copy from mail list for convenient to view:
I have took at stab at feature pack build design, and found out that is quite simple once
I found a good example "keycloak" project. What you have shown me and what other
projects have done with defining the dependencies that are unnecessary which caused lot
more confusion in my head.
First of all "feature-packs" have NOTHING to do with WF Swarm. It is a
build/distribution paradigm that WF invented to handle modules/configuration of
subsystems. So, we need to treat it as such. So entered separate JIRA TEIID-4437 for this.
I want to see this fixed, independent of your wildFly-Swarm work. So, do not bring in any
of changes related to that in this issue.
Based on TEIID-4437, I worked on implementation on my branch
https://github.com/rareddy/teiid/commits/feature-pack as the starting point, fork/pull it,
and submit your pull requests against this branch ONE translator/resource-adapter combo as
I suggested in the JIRA at time. I will review each and every one of them and pull it in.
Pay attention to pom.xml files and not introduce dependencies other than required.
As you can see in my branch I already created the feature packs for Teiid, I split them
into client/public api, wf-integration, rest project. Olingo one needs to be done still (I
will see if I can do that). I also did, JDBC translator as an example too. Once all the
feature packs are completed, then you can work on "wildfly-server" module to
develop a overlay distribution ZIP. As you can see I did some work there already, but left
out configuration part.
As I mentioned above, my branch is where we would work. Once we resolve all these issues,
we can submit a pull request into upstream. My idea is once you are done, I will do a file
2 file comparison with old and new distributions to validate we did not miss anything.
I am also pretty much confident on this design, knowing all the decisions we took to reach
this point, so unless you show me a big flaw some where, THIS IS how I would like this to
be done.
Steve/Van: Please comment on the grouping of the translator and resource-adapter as I
suggested in JIRA, if there are any concerns. I would like to keep translator/ra projects
independent as possible, if/when we need to pull these off into separate projects. Open
Shift work is already asking for detached modules to keep the image size as low as
possible.
Convert Teiid build to use "feature-pack"
-----------------------------------------
Key: TEIID-4437
URL:
https://issues.jboss.org/browse/TEIID-4437
Project: Teiid
Issue Type: Task
Components: Build/Kits
Reporter: Ramesh Reddy
Assignee: Kylin Soong
Fix For: 9.2
Change the current build process to build "feature-packs" for project, and then
based on feature pack, build
- WildFly Server distribution
-WildFly Server Overlay distribution
Teiid currently have distributions, but not based on feature-packs, they need to be.
Other distributions like AdminShell do not fall into this category. Only distributions
that has WF involvement need a feature -pack (this is important to remember).
Currently Teiid uses "kit" directory in many different projects along with
"wildfly-dist.xml" to populate "modules" directory. A feature-pack
does EXACTLY same thing, but more with checks and balances. A feature pack, makes sure all
the dependencies are met based on module.xml and module.xml defines the maven artifact
rather than JAR file. i.e. it defines a metadata file, from which it can be build the zip
file that "wildfly-dist.xml" assembly is currently doing. It also can has
capabilities to "configure" the WF subsystem. That is manually done or done
through CLI currently, using this part will be new.
Implementation Rules
1) Every where we have "kit" directory, that module REQUIRES a
"feature-pack" module. That means, every translator and resource-adapter gets
it's own, and Teiid engine modules separately gets its own module. The reason to
keep/create multiple modules is STRICTLY to keep the "modules" directory in
feature-pack aligned ONE TO ONE with project that feature-pack represents. Otherwise, as
developer we will NOT know which project is bringing in certain dependency, if all the
modules are in single place. So, this is more about management of dependencies in a sane
way. (Teiid did have all the modules in once place before in 7.x/8.x time, it is a
nightmare to handle growing dependencies with our translators)
2) NONE of the work we have is useless/or need to be redone, most everything we have
PERFECTLY maps to this effort, except for for configuration part.
3) For translator and resource adapter pair, I recommend that we pull them into single
sub folder, and create a single feature pack for it. For example:
we have
{code}
connectors/translator-mongodb
connectors/connector-mongodb
{code}
I would like see we design as
{code}
connectors
/mongdb
/translator-mongodb
/connector-mongodb
/feature-pack-mongodb
{code}
No need to create "dist" packages for any resource-adapters or translators. As
I mentioned in the beginning of the issue, there are two distributions, they are built
using these various feature-packs.
4) I would like to see a clean move of "kit/wildfly/modules" to
"feature-packs" using "git", NOT CUT n PASTE where we loose the GIT
history. This will preserve the confidence that what we have currently is EXACTLY same as
in future with feature-packs.
5) When designing the "feature-pack" projects, they ABSOLUTELY MUST NOT define
any dependencies in their pom.xml other than Teiid project(s) they represent and any other
feature-pack they refer to. (Kylin this is what cause most concern from your design for
me)
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)