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.2.0, 1.1.0, 1.0.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


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

Reply via email to