avro-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Doug Cutting (JIRA)" <j...@apache.org>
Subject [jira] Commented: (AVRO-647) Break avro.jar into avro.jar, avro-dev.jar and avro-hadoop.jar
Date Tue, 21 Sep 2010 21:56:33 GMT

    [ https://issues.apache.org/jira/browse/AVRO-647?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12913276#action_12913276

Doug Cutting commented on AVRO-647:

> ByteBufferInputStream and ByteBufferOutputStream are used by BinaryDecoder and BinaryEncoder
and we should consider moving them to util or io.

Those should perhaps move to the io package.

> In order to make a 'core' library I moved Requestor and Responder to avro-ipc.

You moved these along with the various implementations of Requestor and Responder, so the
jar splits don't correspond to java packages, right?  If we embrace that approach generally,
then we wouldn't move any classes to different packages at this stage.  Rather the different
trees and jars can overlap in the java packages they contain.  The only incompatibility we
create at this point will be in packaging, not in any APIs.  It would be good to separate
API changes from packaging changes.

So we'd then leave ByteBufferInputStream, ByteBufferOutputStream and AvroRemoteException in
the ipc package, but include them in the core jar & tree.

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

View raw message