brooklyn-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aled Sage <>
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.



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.
> 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]
> [2]
> On Mon, 17 Aug 2015 at 09:58 Thomas Bouron <>
> 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]
>> --
>> Thomas Bouron • Software Engineer @ Cloudsoft Corporation •
>> Github:
>> Twitter:
>> --
>> 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.

View raw message