[
https://issues.apache.org/jira/browse/AVRO-647?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12912771#action_12912771
]
Scott Carey commented on AVRO-647:
----------------------------------
It sounds like there is at least consensus to split the source tree up. This
will make either Ant or Maven easier to deal with to get the job done. So
that rules out #1.
{quote}
> To wire up IDL and the Specific compiler, Maven plugins would be required.
> Interop testing would probably still require ant.
Can you please explain these more?
{quote}
IDL and the Specific compiler depend on Avro core to run. We have a multi-step
build: build classes that don't {depends.on.generated} then generate some
stuff, then build those classes.
In maven, its not strictly required, but very difficult, to do something like
the above without declaring the dependency and making it its own artifact.
Basically, the easy way is to split things up into core, rpc, idl, mapred, and
tools and build them in the right order as separate components with explicit
dependencies.
The easy way to do code generation is to make a maven plugin like AVRO-159 and
use it in the build. Fortunately, that means that Maven plugins for Specific
and IDL are part of our own build and thus natural for us to maintain.
I have made a pom.xml that will build avro, but it excludes the
{depends.on.generated} stuff and doesn't do any tests that require code
generation or interop.
I haven't looked at how to do interop testing yet, but it seems like something
that is at a higher level than the Java build. Maven doesn't naturally pull
data from anywhere that is not within the project or a declared artifact.
That might end up being easier to wire up with the other language builds using
ant or shell scripts.
> Break avro.jar into avro.jar, avro-dev.jar and avro-hadoop.jar
> --------------------------------------------------------------
>
> Key: AVRO-647
> URL: https://issues.apache.org/jira/browse/AVRO-647
> Project: Avro
> Issue Type: Improvement
> Components: java
> Reporter: Scott Carey
> Assignee: Scott Carey
>
> Our dependencies are starting to get a little complicated on the Java side.
> I propose we build two (possibly more) jars related to our major dependencies
> and functions.
> 1. avro.jar (or perhaps avro-core.jar)
> This contains all of the core avro functionality for _using_ avro as a
> library. This excludes the specific compiler, avro idl, and other build-time
> or development tools, as well as avro packages for third party integration
> such as hadoop. This jar should then have a minimal set of dependencies
> (jackson, jetty, SLF4J ?).
> 2. avro-dev.jar
> This would contain compilers, idl, development tools, etc. Most applications
> will not need this, but build systems and developers will.
> 3. avro-hadoop.jar
> This would contain the hadoop API and possibly pig/hive/whatever related to
> that. This makes it easier for pig/hive/hadoop to consume avro-core without
> circular dependencies.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
