brooklyn-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thomas Bouron <thomas.bou...@cloudsoftcorp.com>
Subject Re: Third party dependencies
Date Mon, 17 Aug 2015 10:18:25 GMT
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

-- 
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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message