You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avro.apache.org by "Scott Carey (JIRA)" <ji...@apache.org> on 2011/01/28 02:12:43 UTC

[jira] Resolved: (AVRO-735) Split packages across artifacts

     [ https://issues.apache.org/jira/browse/AVRO-735?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Scott Carey resolved AVRO-735.
------------------------------

    Resolution: Fixed
      Assignee: Scott Carey

This was resolved in AVRO-737.   I had expected to only partially resolve this there, but ended up completing all of it.

> 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
>            Assignee: Scott Carey
>             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.