ashvina commented on code in PR #612: URL: https://github.com/apache/incubator-xtable/pull/612#discussion_r1948023904
########## rfc/rfc2.md: ########## @@ -0,0 +1,73 @@ +<!-- + Licensed to the Apache Software Foundation (ASF) under one or more + contributor license agreements. See the NOTICE file distributed with + this work for additional information regarding copyright ownership. + The ASF licenses this file to You under the Apache License, Version 2.0 + (the "License"); you may not use this file except in compliance with + the License. You may obtain a copy of the License at + + http://www.apache.org/licenses/LICENSE-2.0 + + Unless required by applicable law or agreed to in writing, software + distributed under the License is distributed on an "AS IS" BASIS, + WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. + See the License for the specific language governing permissions and + limitations under the License. +--> +# RFC-2: Module Structure + +## Proposers + +- @the-other-tim-brown + +## Approvers +- @<approver1 github username> +- @<approver2 github username> + +## Status + +GH Feature Request: https://github.com/apache/incubator-xtable/issues/611 + +> Please keep the status updated in `rfc/README.md`. + +## Abstract +This proposal aims to make it easier for users to run the XTable code when incorporating it into their own project or leveraging the pre-built jars published by the XTable project. +As part of this, there is a secondary goal to make sure that the jars published, including the bundled jars, are trimmed down to the minimum size possible to prevent bloat for our users and to make sure there are no compliance issues with the dependencies. + +## Background +Currently, XTable users have two options for running the conversion code. +They can create their own jar with the XTable dependencies specified in their build file or they can generate the xtable-utilities bundled jar and run that on its own. +There are difficulties when using either approach currently. + +When running the prebuilt utilities bundle jar, the user will bring in all the required dependencies which currently include three table formats, spark, and hadoop. +This results in a very large jar containing more than the user really needs. + +When building your own jar, you can run into issues with conflicts in versions for the specific table formats you want to use since the user will often already have an implementation of at least one format on their classpath. +These conflicts may only surface as runtime errors when there is difference in method signature for example. +This can make the experience brittle for the end user by requiring them to closely follow any upgrades within the XTable repo as well. +In this scenario the user will also have dependencies on all 3 table formats by default. + +## Implementation Review Comment: The current implementation description outlines what users will need to do once the modules are created (thanks for adding it). However, I anticipate the process of splitting the modules to be a bit involved task and won't be as simple as moving classes to new packages. There could be several sub-tasks, such as resolving test dependencies, moving any format classes in the API module, and more. It might be helpful to list these tasks here and create trackable sub-tasks that can be distributed among contributors. Additionally, could you share how you imagine this change to take effect? For instance, clarify whether this change will happen all at once in one PR or incrementally in multiple PRs. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
