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-163) Each language Avro supports should be a separate package
Date Fri, 23 Oct 2009 21:22:00 GMT

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

Doug Cutting commented on AVRO-163:

I don't see the point of putting the autotools package into the "monolithic" tar ball.  

I thought the plan was to:
  - rename the primary tarball avro-src-X.X.X.tar.gz.  this will mostly contain a snapshot
of svn, in particular:
   -- all source code
   -- no jar files
   -- no C or C++ binaries from it
  - generate the following sibling files:
   -- avro-X.X.X.jar
   -- avro-doc-X.X.X.tar.gz
   -- avro-c-src.X.X.X.tar.gz
  - we distribute all of these

If you only want to do the C-related parts of this now, that's probably fine, and we can file
issues to do the others before we next release.  But packaging the autotools package into
the primary tarball seems like a step in the wrong direction.

I can't tell whether there's something you don't like about my proposal, or something you
don't get about it.  Is it that you don't like having a primary tarball with sources for all
languages?  I thought your priority was to distribute a C-only src tarball.  I understand
the utility of that and embrace it.  My priority is to have a single artifact that we can
vote on.  That's the way things are done at Apache, and I don't see a compelling reason to
try to invent new Apache policy.


> To properly distribute the Avro C source, we need to run tests on the source and the
autotools build system.

Then please make that a part of the target run by 'ant test' at the top-level, if you have
not already.  That target is intended for folks who'd like to try to test everything fully.

> Each language Avro supports should be a separate package
> --------------------------------------------------------
>                 Key: AVRO-163
>                 URL: https://issues.apache.org/jira/browse/AVRO-163
>             Project: Avro
>          Issue Type: Improvement
>          Components: c, c++, java, python
>    Affects Versions: 1.0.0, 1.1.0, 1.2.0
>         Environment: We currently release Avro as a single monolithic tarball with ant
being used to build all the languages that Avro supports.
>            Reporter: Matt Massie
>            Assignee: Matt Massie
>            Priority: Critical
>             Fix For: 1.2.1, 1.3.0
>         Attachments: AVRO-163.patch
>   Original Estimate: 8h
>  Remaining Estimate: 8h
> *Build Issue*
> While ant is used for building Java projects, it is almost never used to build python,
c++ or c projects.  C and C++ projects are often managed using autotools while Python uses
setuptools.  Forcing these languages to use a foreign build system ('ant') is suboptimal and
will cause us headaches as we move forward.
> *Release issue*
> Releasing a single monolithic package forces users of one language to download binary
and source for all languages.  For example, at this time the Avro C distribution is only 384K
in size (built using autotools 'make distcheck' target).  People interested in using the C
implementation would be forced to download a large monolithic tarball (currently 3.8 MB) that
includes dozens of third-party jar files for the Java implementation.  Furthermore, C users
would be forced to use 'ant' as the top-level build tool.  This monolithic approach would
also prevent us from submitting Avro for inclusion in Linux distribution yum/apt repositories
as RPM and Debian packages.  It's important to allow C/C++ code to have a pristine release
tarball on which to base Debian and RPM packaging.
> *Solution*
> Create top-level directories: 'java', 'python', 'c++ ' , 'c', 'shared' and 'release'.
 Each language directory would contain the source for that language and use the build system
natural for that language, e.g. ant, autotools, setuptools, gem, etc.  The 'shared' directory
would have, for example, common test schema and data files for interoperability testing between
each language.  A simple top-level bash script would call into each language to build a release
package, documentation, etc. into the 'release' directory.  Each Avro release would then be
compromised of package(s) for each language Avro supports, e.g. avro-java-1.2.3.tar.gz, pyavro-1.2.3.tar.gz,
avro-c++-1.2.3.tar.gz and avro-c-1.2.3.tar.gz.  Later on, we'll also likely have libavro-devel-1.2.3-1.x86_64.rpm

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message