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 Thu, 07 Jan 2010 00:16:54 GMT

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

Doug Cutting commented on AVRO-163:
-----------------------------------

> A nice advantage of the latter is that a language's specific build never needs to go
up the directory tree [ ... ]

Somehow release artifacts need to make it up to the top-level dist/ directory.  I'd assumed
this would be done by each language implementing a 'dist' target that pushes its release artifacts
to dist/.  Similarly, each language's 'doc' target would push generated documentation to the
top-level build/doc/$lang directory so that the top-level build can bundle these into dist/avro-doc-X.Y.Z.tar.gz.
 With this approach, language-specific builds would still need to go up the directory tree.

Alternately we could have the top-level build pull docs and other release artifacts from the
language-specific builds.  The langauge-specific 'dist' and 'docs' targets would create artifacts
in language-specific places, and the top-level build would know where these are and pull them
from there to the top-level dist/ directory.

Note that we can use 'svn export' to create the src release in the top-level build, so the
presence of language-specific generated files should not complicate that.


> 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
>         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: Doug Cutting
>            Priority: Critical
>             Fix For: 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.


Mime
View raw message