You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@brooklyn.apache.org by Thomas Bouron <th...@cloudsoftcorp.com> on 2015/08/17 10:58:29 UTC
Third party dependencies
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.
Re: Third party dependencies
Posted by Thomas Bouron <th...@cloudsoftcorp.com>.
Hi all.
Wanted to share the solution in case the question comes up again: I finally
went for the maven assembly plugin[1] as it felt cleaner than using maven
shade plugin.
Best.
[1]
https://github.com/brooklyncentral/brooklyn-ambari/commit/dd76858c61c0be387dd647361feda01417099f64
On Mon, 17 Aug 2015 10:55 Aled Sage <al...@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.
Re: Third party dependencies
Posted by Hadrian Zbarcea <hz...@gmail.com>.
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 <th...@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 <al...@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
>>
Re: Third party dependencies
Posted by Thomas Bouron <th...@cloudsoftcorp.com>.
// 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 <th...@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 <al...@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
>
--
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.
Re: Third party dependencies
Posted by Thomas Bouron <th...@cloudsoftcorp.com>.
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 <al...@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.
Re: Third party dependencies
Posted by Aled Sage <al...@gmail.com>.
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 <th...@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.
>>
Re: Third party dependencies
Posted by Richard Downer <ri...@apache.org>.
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 <th...@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.
>