Transitive deps

[Neil Bartlett]

On Thu, Sep 5, 2013 at 1:23 PM, Sven Reimers <sven.reimers at gmail.com> wrote:
> "I think we are in broad agreement about how to manage build
> dependencies. They are not required to be transitive -- to compile
> each module we only need visibility of the modules it directly
> imports."
>
> I am sure that javac sometimes disagrees and wants to look a bit deeper into
> the implementation inheritance (may be bad design/architecture, butis valid
> Java)

Yes, sorry I was sloppy with my wording. At build time we need
visibility of the direct dependencies, which may go somewhat beyond
the literal set of import clauses in the Java code. In either case,
the build system should allow the developer to list those direct
dependencies and is not required to pull in transitives. The developer
quickly discovers whether she has missed any "implicit" (e.g.
superclass) dependencies because javac will return errors.

>
> -Sven
>
>
> On Thu, Sep 5, 2013 at 2:15 PM, Neil Bartlett <njbartlett at gmail.com> wrote:
>>
>> On Thu, Sep 5, 2013 at 12:34 PM, Jaroslav Tulach
>> <jaroslav.tulach at oracle.com> wrote:
>> >> [...]
>> > As splitted packages are rare (and maybe even unsupported in some
>> > versions of
>> > OSGI), then a package import basically means non-transitive dependency.
>> >
>> > You may realize that your belief is a specialization of my general
>> > observation. As such it is of no surprise, that if non-transitive JAR
>> > (compilation) dependencies work sufficiently, import package works for
>> > you in
>> > OSGi.
>> >
>> > Import-Package seems to be a solution of the transtivity issues, but a
>> > bit too
>> > narrow and certainly not the only one.
>> > -jt
>>
>>
>> Stepping back a bit, I feel that the underlying failure in Maven is to
>> distinguish between build and runtime dependencies. They require
>> different approaches.
>>
>> I think we are in broad agreement about how to manage build
>> dependencies. They are not required to be transitive -- to compile
>> each module we only need visibility of the modules it directly
>> imports. They should not use ranges because this results in
>> non-repeatable builds; for my customers it is important to be able to
>> reproduce a build precisely, even many years into the future. In the
>> bnd build system we can go beyond fixed module identity+version and
>> actually depend on the SHA hash of a module. Admittedly we also made
>> the mistake of using dependency ranges at build time but now strongly
>> discourage it.
>>
>> Runtime dependencies are unavoidably transitive. The key is therefore
>> to find ways to minimise the transitive dependency graph, which is the
>> purpose of the OSGi Import-Package instruction, since it creates
>> opportunities to refactor module contents and/or find alternative
>> providers.
>>
>> Neil
>>
>> >
>> >
>> >
>
>
>
>
> --
> Sven Reimers
>
> * Senior Expert Software Architect
> * NetBeans Dream Team Member: http://dreamteam.netbeans.org
> * Community Leader  NetBeans: http://community.java.net/netbeans
>                               Desktop Java:
> http://community.java.net/javadesktop
> * Duke's Choice Award Winner 2009
> * Blog: http://nbguru.blogspot.com
>
> * XING: https://www.xing.com/profile/Sven_Reimers8
> * LinkedIn: http://www.linkedin.com/in/svenreimers
>
> Join the NetBeans Groups:
> * XING: http://www.xing.com/group-20148.82db20
> * NUGM: http://haug-server.dyndns.org/display/NUGM/Home
> * LinkedIn: http://www.linkedin.com/groups?gid=1860468
>                    http://www.linkedin.com/groups?gid=107402
>                    http://www.linkedin.com/groups?gid=1684717
> * Oracle: https://mix.oracle.com/groups/18497