brooklyn-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aled Sage <aled.s...@gmail.com>
Subject Re: Third party dependencies
Date Mon, 17 Aug 2015 09:55:38 GMT
Hi Thomas,

Longer term, OSGi is a great way to go: creating OSGi bundle(s) for your 
code, which reference your dependencies as other OSGi bundles - e.g. 
when you deploy your app to the catalog, reference your bundle and its 
dependencies in the "brooklyn.libraries" section of a catalog item [1].

However, that can prove fiddly, particularly if your dependencies are 
not shipped as OSGi bundles.

---
If using the dropins folder... If using maven-shade-plugin then take 
care that it does not pull in brooklyn-api etc (you don't really want 
those duplicated inside your shaded jar).

For Richard's comment about copy-pasting the code with renamed package 
names... I see where he's coming from but personally don't like it 
unless unavoidable and/or very small. It can give you some parts of 
"OSGi-like behaviour" (e.g. avoids version conflicts, but does not give 
you on-the-fly upgrading etc). However, when your dependencies have 
transitive dependencies, it can get fiddly and large.

Aled

[1] https://brooklyn.incubator.apache.org/v/latest/ops/catalog/


On 17/08/2015 10:39, Richard Downer wrote:
> Hi Thomas,
>
> For Brooklyn itself, there are many rules based in copyright law and Apache
> policy that affect how this is done. Essentially, if the licenses are
> compatible, then there's no issue with bundling dependencies into the
> project, provided that the bundled package is correctly attributed in the
> right places. The gold reference document for Apache is at [1], and my
> interpretation of how this specifically applies to Brooklyn is at [2].
>
> However if you're writing an external library that is not part of Apache
> Brooklyn - you are merely consuming Apache Brooklyn by dropping in an extra
> library - then the Apache policies do not apply to you! You do still need
> to consider copyright law however, so I advise that you let the Apache
> policy 'inspire' you as it was written with compliance of the law a key
> requirement :-)
>
> I see that retrofit has an Apache license. This is a permissive (non-viral)
> license so you're unlikely to have a problem with it, although it depends
> on the license of your project.
>
> In practical terms, yes, maven-shade-plugin will do the trick, and I think
> maven-assembly-plugin can do it too. However you need to be aware that
> these kinds of tools will invalidate signed JARs. In practice these are
> rarely a problem - we have observed an issue where BouncyCastle is degraded
> if it's not signed, but I've not seen any other kind of problem.
>
> Personally, I don't really like shading, as it obscures transitive
> dependencies. The technique taken by several projects is to physically copy
> in the source code with a different package name (e.g.
> com.example.myproject.com.google.common.collect.Iterables) and I think I
> prefer that technique. It's just a gut feel though, I cannot provide any
> facts to back it up :-)
>
> Richard.
>
> [1] https://www.apache.org/legal/resolved.html
> [2] https://brooklyn.incubator.apache.org/v/latest/dev/code/licensing.html
>
> On Mon, 17 Aug 2015 at 09:58 Thomas Bouron <thomas.bouron@cloudsoftcorp.com>
> wrote:
>
>> Hi devs.
>>
>> I'm currently working on a project for a client where I want to use this
>> library[1] for all my REST call. It is released under the Apache licence
>> v2.
>>
>> My project will be released as a jar and placed under the Brookyln's
>> dropins folder but I rather have only one jar containing all my
>> dependencies instead of adding my third party library jar one by one.
>>
>> Now I'm not sure if I can do that from a licensing point of view. Do you
>> have any thoughts? Also, If there is no issue to do so, what is the best
>> practice in that matter? Using the maven shade plugin?
>>
>> Thanks.
>>
>> Best.
>>
>> [1] http://square.github.io/retrofit/
>> --
>> Thomas Bouron • Software Engineer @ Cloudsoft Corporation •
>> http://www.cloudsoftcorp.com/
>> Github: https://github.com/tbouron
>> Twitter: https://twitter.com/eltibouron
>>
>> --
>> Cloudsoft Corporation Limited, Registered in Scotland No: SC349230.
>>   Registered Office: 13 Dryden Place, Edinburgh, EH9 1RP
>>
>> This e-mail message is confidential and for use by the addressee only. If
>> the message is received by anyone other than the addressee, please return
>> the message to the sender by replying to it and then delete the message
>> from your computer. Internet e-mails are not necessarily secure. Cloudsoft
>> Corporation Limited does not accept responsibility for changes made to this
>> message after it was sent.
>>
>> Whilst all reasonable care has been taken to avoid the transmission of
>> viruses, it is the responsibility of the recipient to ensure that the
>> onward transmission, opening or use of this message and any attachments
>> will not adversely affect its systems or data. No responsibility is
>> accepted by Cloudsoft Corporation Limited in this regard and the recipient
>> should carry out such virus and other checks as it considers appropriate.
>>


Mime
View raw message