[
https://issues.apache.org/jira/browse/AVRO-735?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12981857#action_12981857
]
Scott Carey commented on AVRO-735:
----------------------------------
The initial move did not try and solve this problem because it is trickier than
it looks and would complicate the initial split ticket significantly.
There are some cases that would be simple moves, but there are others that
simple movement would require changing classes or methods with package scope
visibility to public, which is not acceptable. To avoid this there is more
refactoring required and some API breakages.
This is a change that I agree we should attempt, but I'm not convinced that we
should do so before 1.5.0 or that it is even possible. If it is we could
introduce the resulting API breakages in a later release. 1.5.0 may be very
soon.
Conceptually, the requirement that we can't share packages across jars means
that avro-ipc can only use public API's to work with avro -- and that may never
be desirable.
Its not possible to build avro-ipc and avro using Maven in the same project --
avro-ipc requires compiling schema files into Java classes. In order to
compile those schema files, the build needs to have already created the
avro-compiler artifact which depends on avro.
Would it be possible for OSGi to simply not support a smaller bundle than avro
+ avro-ipc? I think all other components can separate cleanly by package.
Alternatively, we could build a variation avro-ipc.jar that shades in avro.jar
that could be the smallest unit for OSGi. This however would mean that all
Avro users have to pull in jetty and netty even if they aren't using those
features.
Another approach would be to trim the dependencies from avro-ipc down by
removing implementations like netty and jetty. Then we could have a separate
jar with those implementations, which could be in a different package.
> 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.
