brooklyn-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Hadrian Zbarcea <hzbar...@gmail.com>
Subject Re: Third party dependencies
Date Mon, 17 Aug 2015 17:30:22 GMT
I wonder what // Internal could mean in this context.
If a library is not OSGi-ified, you can still shade it. Of course the 
licenses still have to be compatible.

Hadrian

On 08/17/2015 06:22 AM, Thomas Bouron wrote:
> // Internal
>
> Hi Aled.
>
> Yes, I'm talking about the bdaap project, more specifically
> brooklyn-ambari[1] and this PR[2].
>
> We have only one dependency[3] that need to be bundled within the generated
> jar.
>
> [1] https://github.com/brooklyncentral/brooklyn-ambari
> [2] https://github.com/brooklyncentral/brooklyn-ambari/pull/24
> [3]
> https://github.com/brooklyncentral/brooklyn-ambari/pull/24#discussion_r36976777
>
> On Mon, 17 Aug 2015 at 11:18 Thomas Bouron <thomas.bouron@cloudsoftcorp.com>
> wrote:
>
>> Hi Richard, Aled.
>>
>> Thanks for sharing. I checked the retrofit library but it seems that they
>> don't provide an OSGi bundle of it so this is dead end.
>> I do feel like Aled on Richard's comment about copy-pasting source code. I
>> don't think that is particularly suitable for retrofit either as it has a
>> fair amount of code.
>>
>> That leaves the maven shade or assembly plugin. I would go for the second
>> one based on its home page and plugin description but it's a gut feeling.
>>
>> On Mon, 17 Aug 2015 at 10:55 Aled Sage <aled.sage@gmail.com> wrote:
>>
>>> 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.
>>>>>
>>>
>>> --
>> Thomas Bouron • Software Engineer @ Cloudsoft Corporation •
>> http://www.cloudsoftcorp.com/
>> Github: https://github.com/tbouron
>> Twitter: https://twitter.com/eltibouron
>>

Mime
View raw message