[jira] Updated: (AVRO-163) Each language Avro supports should be a separate package

["Matt Massie (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/AVRO-163?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Matt Massie updated AVRO-163:
-----------------------------

    Attachment: AVRO-163.patch

NOTE: this patch depends on AVRO-168 which I just committed to trunk.

This simple patch changes the way that C source code is distributed:

1. "ant tar" will generate an autotools package along with md5 and sha1 signatures and place them in the top-level 'c' directory of the monolithic avro tarball
2. "ant test" will now test *both* the C source and the autotools package as well (see below)
3. The "ant compile-c" rule has been removed. C code *consumers* will use the blessed autotools package.  C code *producers* will bootstrap 'src/c'.

I hope this hybrid approach is a good compromise, Doug.  

* We'll continue voting on a single monolithic package which includes all languages that we support.
* Once this monolithic package has passed voting, I request that the files in the 'c' directory be published at the same base URL as the monolithic package.  This will allow me a definitive URL for the pristine C source package for Debian/RPM packaging.

'make distcheck' note:

To properly distribute the Avro C source, we need to run tests on the source *and* the autotools build system.  This is accomplished by running the autotools 'make distcheck' rule which will make a distribution, try to do a VPATH build, run the test suite, and finally make another tarball to ensure the distribution is self-contained.  This rigorous process will ensure that C users have a distribution that works "out of the box" without hassles.







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

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