Mailing-List: contact avro-dev-help@hadoop.apache.org; run by ezmlm
Precedence: bulk
Reply-To: avro-dev@hadoop.apache.org
Message-ID: <218242142.1256785859392.JavaMail.jira@brutus>
Date: Thu, 29 Oct 2009 03:10:59 +0000 (UTC)
From: "Thiruvalluvan M. G. (JIRA)" <jira@apache.org>
To: avro-dev@hadoop.apache.org
Subject: [jira] Commented: (AVRO-163) Each language Avro supports should be
 a separate package
In-Reply-To: <694481225.1256079719457.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

Thiruvalluvan M. G. commented on AVRO-163:
------------------------------------------

+1 for Doug's proposal for directory structure.

There are merits of having java, c++ etc at one level above core and test and there are also advantages of having the opposite. There doesn't seem to be a clear winner. The latter one which is the maven convention is reasonably well understood and widely used.  But unfortunately it does not suit us because maven convention is best suited for single artifact builds; it makes it difficult to support language specific builds. This means that it'll be hard to move to maven, if we want, in the future. I'm okay with it.

> 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-cpp.patch, AVRO-163.patch, 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.