[
https://issues.apache.org/jira/browse/AVRO-163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12769317#action_12769317
]
Doug Cutting commented on AVRO-163:
-----------------------------------
No one's yet responded to my proposal. Hmm.
I think, as a project, just as we need a single subversion repository that is
the subject of our commit review process, we should build a single src tarball
that is the subject of our release voting process: Folks should be able
examine this alone to vote on the release. Anything that needs to be fixed in
the release should be fixed here.
We can also distribute additional artifacts alongside this as a service to
consumers of our releases. This includes jars, pristine c and c++ tarballs,
python eggs, pre-built binaries, etc. Folks can and should test these
independently, but they should be derivable from the primary src tarball.
My rationale is that I worry that if we only have separate, disjoint artifacts,
that represent disjoint source trees, with different folks voting on the
different artifacts, then effectively we've become a set of projects rather
than a single project. Long-term that may be where we need to go, but for now
I don't think we need to encourage that. Currently it is possible to build and
test all of the versions with a single command on some platforms, including
their interoperability. This is a good thing, and we should encourage it as
long as we can.
> 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
>
> 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.
