[
https://issues.apache.org/jira/browse/AVRO-737?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Scott Carey updated AVRO-737:
-----------------------------
Attachment: AVRO-737.v2.patch
Updated patch includes the prior changes plus:
* AvroRemoteException is now in o.a.a. Generated signatures in protocols
include this change. (address AVRO-732 separately after)
* mapred.tether generated classes now in ipc.mapred.tether.
* Tool.java and all Tool classes now in tools project, in o.a.a.tool
I took the opportunity to do one more package reorg:
create o.a.a.compiler
move o.a.a.idl and o.a.a.specific.compiler inside of here.
The end result is a good one, and was easier than I thought it would be ---
* avro-ipc.jar exclusively contains o.a.a.ipc.** packages
* avro-tools.jar exclusively contains o.a.a.tool.** packages
* avro-mapred.jar exclusively contains o.a.a.mapred.** packages
* avro-maven-plugin.jar exclusively contains o.a.a.mojo.** packages
* avro-compiler.jar exclusively contains o.a.a.compiler.** packages
* avro.jar contains all the other stuff -- util, tools, o.a.a, file, generic,
specific, reflect, io
There is work to do to refactor the test side of things to work similarly. I
That is going to be more difficult and require some maven pom.xml changes, but
will be worthwhile. Right now we don't unit test the compiler completely until
ipc, but ipc requires the compiler to generate sources. So if there is a bug
in the compiler that makes code generation fail you can't test it!
> Java: Improve correlation between packages and modules
> ------------------------------------------------------
>
> Key: AVRO-737
> URL: https://issues.apache.org/jira/browse/AVRO-737
> Project: Avro
> Issue Type: Sub-task
> Components: java
> Reporter: Scott Carey
> Assignee: Scott Carey
> Fix For: 1.5.0
>
> Attachments: AVRO-737.v1.patch, AVRO-737.v2.patch
>
>
> Several packages have classes from multiple modules in the new layout.
> In general, we should avoid this. Ideally, o.a.a.ipc would only exist in the
> avro-ipc.jar for example.
> For 1.5.0, I'd like to move the easy stuff around to better correlate
> packages with modules.
> This will cause API changes we need to document. Unfortunately, moving
> classes around is not something you can do gradually. Ideally these are
> isolated.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
