[
https://issues.apache.org/jira/browse/AVRO-163?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Doug Cutting updated AVRO-163:
------------------------------
Assignee: Doug Cutting (was: Matt Massie)
Affects Version/s: (was: 1.2.0)
(was: 1.1.0)
(was: 1.0.0)
Status: In Progress (was: Patch Available)
Starting work on this.
I'm currently planning to put most things under src/, i.e.:
{code}
src
share
schemas
test
doc
java
src
test
lib
py
src
lib
c
c++
{code}
My preference is to create all artifacts in a top-level build/ directory,
treating the src/ tree as read-only. It makes bundling the sources into a
release simpler, makes the "clean" target easier to implement, simplifies
ignore file maintenance, etc. On the other hand, we want each src subdirectory
to be organized according to the norms of its language, using the build tools
of that language, etc, which may or may not make this simple.
If we decide against this, then perhaps the top-level src/ directory should be
elided.
The top-level build file should have the following targets:
- test, runs tests for all languages, including interop tests
- doc, builds all docs in build/doc
- forrestdoc builds top-level docs in build/doc
- package, creates in build/
-- avro-src-X.Y.Z.tar.gz -- includes all sources
-- avro-doc-X.Y.Z.tar.gz -- full, generated documentation
-- avro-X.Y.Z.jar -- compiled java jar
-- avro-tools-X.Y.Z.jar
-- avro-c-X.Y.Z.tar.gz -- ready-to-build C
-- avro-cpp-X.Y.Z.tar.gz -- ready-to-build C++
-- etc.
- clean
Each language should support the targets:
- test to run all of its internal tests
- gen-interop-data to generate test data files in
build/test/interop/data/$lang
- start-interop-daemon to start a daemon, recording the port in
build/test/interop/daemons/$lang
- doc to build its docs and install them in build/docs/$lang
- package to post its generated release artifacts to build/release
> 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.
