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 <[email protected]>
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.
