[
https://issues.apache.org/jira/browse/AVRO-735?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12985234#action_12985234
]
Scott Carey commented on AVRO-735:
----------------------------------
I did not expect to be able to completely separate packages to be distinct per
artifact, but the patch in the child task AVRO-737 does just that.
There is more to do on the test side, but that can happen after 1.5.0.
> Split packages across artifacts
> -------------------------------
>
> Key: AVRO-735
> URL: https://issues.apache.org/jira/browse/AVRO-735
> Project: Avro
> Issue Type: Bug
> Components: java
> Affects Versions: 1.5.0
> Reporter: Holger Hoffstätte
> Fix For: 1.5.0
>
>
> I was glad to see the ongoing work for a more modular build (thanks Scott
> Carey!). Whilst looking into the cross-platform IPC facilities for use in
> OSGi I noticed something that makes OSGi compatibility (and maintenance) more
> difficult than necessary, for no good reason. I plan to submit OSGi bundle
> patches later (though not necessarily for the 1.5.0 release) so this is a
> necessary prelude.
> The term "split packages" refers to the situation that two artifacts carry
> the same packages, which means that the classes in both packages are more or
> less randomly munged together at runtime. This unfortunate situation is
> "mostly" without consequence in "normal" flat-classpath Java (assuming there
> are no overlaps!), but bad for OSGi since class visibility & wiring is based
> on package visibility. Split packages generally make any form of automatic
> package resolution (for deployment) almost impossible.
> As far as I can see there are several classes in packages across artifacts
> that can easily be moved a bit without really disturbing anything. Some
> examples:
> org.apache.avro.specific is defined by acro, compiler AND ipc
> org.apache.avro.ipc (!) is defined in avro and contains classes that could go
> into avro:avro.io (the buffers) or avro-ipc:org.apache.avro.ipc
> It seems that the previously unmodular package membership of classes has been
> carried over during the artifact separation. I'd like to see this cleaned up
> as well before the 1.5.0 release, as this is a breaking change. However, most
> of the overlaps can be fixed easily with IDE refactorings like package
> renaming or by moving classes.
> Please let me know if this is an acceptable change and if you want me to
> provide help/patches etc.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
