Mailing-List: contact dev-help@brooklyn.incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@brooklyn.incubator.apache.org
MIME-Version: 1.0
References: 
 <CAH20XTbu7Y1+ZuUYu7L_5ad83piRXEOnY5bUkJEmKA8PoVAyfw@mail.gmail.com>
 <CABQFKi0e2QyK4LELvyYKtpcvna3+Bg14--OwHmmSDYQJqvrRZw@mail.gmail.com>
 <55D1AF9A.3080601@gmail.com>
 <CAH20XTZaQzjxmoU-1_=QaLeZU3qaPjdu+mTwSh8gF=J4rALfag@mail.gmail.com>
In-Reply-To: 
 <CAH20XTZaQzjxmoU-1_=QaLeZU3qaPjdu+mTwSh8gF=J4rALfag@mail.gmail.com>
From: Thomas Bouron <thomas.bouron@cloudsoftcorp.com>
Date: Mon, 17 Aug 2015 10:22:07 +0000
Message-ID: 
 <CAH20XTb90=c0sVG8VoKP2K=ECbFrHfFGt6boP9rg+iHgaNPGdQ@mail.gmail.com>
Subject: Re: Third party dependencies
To: dev@brooklyn.incubator.apache.org
Content-Type: multipart/alternative; boundary=001a113e3db80a1464051d7f2d9b

--001a113e3db80a1464051d7f2d9b
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

// 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_r3697=
6777

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 Apac=
he
>> > 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 ke=
y
>> > 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 ar=
e
>> > 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 a=
ny
>> > 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 =E2=80=A2 Software Engineer @ Cloudsoft Corporation =E2=
=80=A2
>> >> 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 messa=
ge
>> >> from your computer. Internet e-mails are not necessarily secure.
>> Cloudsoft
>> >> Corporation Limited does not accept responsibility for changes made t=
o
>> this
>> >> message after it was sent.
>> >>
>> >> Whilst all reasonable care has been taken to avoid the transmission o=
f
>> >> viruses, it is the responsibility of the recipient to ensure that the
>> >> onward transmission, opening or use of this message and any attachmen=
ts
>> >> 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 =E2=80=A2 Software Engineer @ Cloudsoft Corporation =E2=80=
=A2
> http://www.cloudsoftcorp.com/
> Github: https://github.com/tbouron
> Twitter: https://twitter.com/eltibouron
>
--=20
Thomas Bouron =E2=80=A2 Software Engineer @ Cloudsoft Corporation =E2=80=A2
http://www.cloudsoftcorp.com/
Github: https://github.com/tbouron
Twitter: https://twitter.com/eltibouron

--=20
Cloudsoft Corporation Limited, Registered in Scotland No: SC349230.=20
 Registered Office: 13 Dryden Place, Edinburgh, EH9 1RP
=20
This e-mail message is confidential and for use by the addressee only. If=
=20
the message is received by anyone other than the addressee, please return=
=20
the message to the sender by replying to it and then delete the message=20
from your computer. Internet e-mails are not necessarily secure. Cloudsoft=
=20
Corporation Limited does not accept responsibility for changes made to this=
=20
message after it was sent.

Whilst all reasonable care has been taken to avoid the transmission of=20
viruses, it is the responsibility of the recipient to ensure that the=20
onward transmission, opening or use of this message and any attachments=20
will not adversely affect its systems or data. No responsibility is=20
accepted by Cloudsoft Corporation Limited in this regard and the recipient=
=20
should carry out such virus and other checks as it considers appropriate.

--001a113e3db80a1464051d7f2d9b--