[
https://issues.apache.org/jira/browse/AVRO-647?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12913116#action_12913116
]
Scott Carey commented on AVRO-647:
----------------------------------
More experimentation on the Avro front has brought out some interesting quirks
in our dependencies.
1. I'm not sure it makes sense to separate IDL and Specific from Core. It
turns out that the only extra library required as a runtime dependency for
those two is commons-lang, and the _one_ class and method used there we could
simply copy into our code to avoid the dependency. Javacc is a build time
only dependency that should not show up in our POM at all. Paranamer-ant is
the same. Both have Maven plugins. The upcoming templating version of
SpecificCompiler might change what we want to do though.
2. A LOT of our testing requires use of the Specific Compiler. Most of the
ipc package depends on output of the Specific Compiler to compile;
Requestor/Responder are at the heart of that. This would require that these be
in a separate artifact. The Maven artifacts would be
avro-core (possibly with IDL)
avro-compile (optional, current version can be in core, template based one may
require separation or shading)
avro-maven-plugin (Maven plugins for idl, specific compiler; depends on core
and compile)
avro-ant (the two classes for Ant tasks; depends on core, compile)
avro-ipc (IPC w/ netty/jetty; depends on core, compile, uses maven-plugin;
most testing is not possible until here!)
avro-mapred (including tether, or that separate?)
avro-tools
That is a lot of stuff, but really only 4 libraries that others can depend on,
two build tools, and one command-line tool.
The part that is a bit of a problem is that most of our testing of core can't
happen in the core project because of its dependencies on specific compiler
output.
> 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.
