[
https://issues.apache.org/jira/browse/AVRO-647?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12905063#action_12905063
]
Doug Cutting commented on AVRO-647:
-----------------------------------
A breakdown by use-case might be:
- avro-data (core & data files)
- avro-rpc (includes netty, jetty) depends on avro-data
- avro-mapred (mapreduce APIs) depends on avro-data
- avro-mapred-tether (RPC-based mapred API) depends on avro-mapred & avro-rpc
- avro-dev (specific & idl compiler, ant tasks) depends on avdo-data
About dependencies:
- paranamer is used by reflect, to get the names of method parameters.
Perhaps avro-reflect should be made a separate jar?
- velocity is used by RPC stats charting stuff and by AVRO-648 (template-based
specific compiler)
- commons-lang is used by the IDL compiler for StringEscapeUtils
If we separate jars, it might be good to split the build-time classpath in the
same manner, by splitting the src tree. The build order would then be: data,
mapred, dev, rpc, mapred-tether, since rpc depends on dev to compile the
handshake. Note that this would split packages among trees, as specific has
some data classes and some rpc classes.
Finally, to be clear, is there a motive for this beyond better expressing
dependencies? Functionally sticking everything in a single jar with lots of
optional dependencies works fine, but folks then have to guess which
dependencies they actually need, and that's the primary problem this seeks to
solve. Is that right, or are there other problems too?
> Break avro.jar into avro.jar, avro-dev.jar and avro-hadoop.jar
> --------------------------------------------------------------
>
> Key: AVRO-647
> URL: https://issues.apache.org/jira/browse/AVRO-647
> Project: Avro
> Issue Type: Improvement
> Components: java
> Reporter: Scott Carey
> Assignee: Scott Carey
>
> Our dependencies are starting to get a little complicated on the Java side.
> I propose we build two (possibly more) jars related to our major dependencies
> and functions.
> 1. avro.jar (or perhaps avro-core.jar)
> This contains all of the core avro functionality for _using_ avro as a
> library. This excludes the specific compiler, avro idl, and other build-time
> or development tools, as well as avro packages for third party integration
> such as hadoop. This jar should then have a minimal set of dependencies
> (jackson, jetty, SLF4J ?).
> 2. avro-dev.jar
> This would contain compilers, idl, development tools, etc. Most applications
> will not need this, but build systems and developers will.
> 3. avro-hadoop.jar
> This would contain the hadoop API and possibly pig/hive/whatever related to
> that. This makes it easier for pig/hive/hadoop to consume avro-core without
> circular dependencies.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
