[
https://issues.apache.org/jira/browse/AVRO-735?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12982823#action_12982823
]
Scott Carey commented on AVRO-735:
----------------------------------
bq. I understand, but why does this preclude doing the easy/nonbreaking things
now? I mean, I really cannot see any reason why avro:..ipc has to contain
generic IOStream classes just because they are also used in ipc. Move them to
avro:..io and done. Same for the AvroRemoteException - it can stay in avro
alright, but there is no harm by moving it into avro..io or wherever. Bang: one
down.
The only consideration there is public classes. If its public, moving them is
an API breakage. We can do that, but until now there was little motivation.
This affects OSGi users and not others. I'll have a look at moving the easy
stuff like the IOStream and AvroRemoteException bits which were already
discussed in the past (but we saw no harm in leaving them alone).
bq. So have public and private APIs?! No need to rely on package overlaps for
that.
Someone would have to document it or use some annotation framework to declare
what is public and private. And the vast majority of users will not use such
an annotation framework and will ONLY look at what can be accessed and the
Javadoc. I feel that its always best to use the built-in java visibility when
possible. I'm not sure OSGi alone is enough of a driver to expose non-public
APIs.
bq. I think that just shows that those three really belong together, and that
dependency problems come from ipc, mapred and the tools. avro, compiler and ipc
together are still pretty small.
Their dependencies are not small. Furhtermore, as I said it is _not possible_
to build all three at once with maven. You need the output artifacts of one
to generate code to compile another. It is possible to do this in two modules
(avro + compile, ipc), but not one. Three makes the most sense since we want
to separate out the compiler dependencies. If you aren't using the compiler,
why would you require pulling in its unique dependencies? We want to be able
to use any dependency we wish in the compiler without forcing the maven/ivy
user to have those on their classpath by default.
bq. As an example, it's fairly easy to embed the avro/compiler/ipc trifecta and
just block the imports that a bundle doesn't need (assuming the bundle has
service-like standalone functionality).
If its easy to make an OSGi bundle with a couple jars then this is definitely
preferred over making a custom bundled jar artifact. Most likely this would
be avro + ipc unless you need the compiler functionality to create java classes
from .avpr .avsc or .avdl files.
I propose that we look at the low hanging fruit stuff for 1.5.0 -- simple
things like AvroRemoteException that reduce the number of packages that overlap
amongst artifacts. As long as this doesn't force something dangerous to be
publicly visible I'm fine with that. We'll need others to agree however.
Items such as moving netty/jetty and tracing out on their own are definitely
not in scope for 1.5.0, nor attempting to untangle ipc and avro. The current
structure may not be ideal for OSGi but it is a HUGE improvement for most ivy
and maven users.
> 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.
