Re: Building debs with Maven

[Chip Childers <ch...@sungard.com>]

On Sun, Sep 30, 2012 at 1:31 PM, Noah Slater <ns...@tumbolia.org> wrote:
> Just a clarification here. It is fine to use, or depend on proprietary
> software that exists on the system. During the build, or after install.
> "For example, using a GPL'ed tool during the build is OK." [1] The
> stipulation is that we cannot ship anything WITH the build that is
> incompatible with our license.
>
> [1] http://www.apache.org/legal/resolved.html

Understood.

The approach we are taking is to ensure that the default build process
only includes compatible dependencies in the produced RPM and DEB
packages (with a few "system dependencies" being required by the
packages themselves).  The intent here was to have the RPM and DEB's
published via ASF infrastructure.  We've changed course a little bit
recently (with Wido hosting the repos outside of ASF), which does open
up the possibility of changing our approach.

That being said, I personally like the clean model that we have in
place right now.  Someone that gets the source code today knows that
the default build will only pull in dependencies that are compatible
from a licensing perspective.  They are then responsible for some
required system dependencies.  And for those dependencies that can
optionally be enabled in the build, they are able to follow the
instructions to build their own copy of the app that includes the
other features.

The approach is largely based on the answer for "Can Apache projects
rely on components whose licensing affects the Apache product?" from
the legal "resolved" page.  It keeps us in a position to potentially
host package repos on ASF infra, and sends a clear signal to companies
/ organizations that want to include an integration into their product
for how best to reach a broader audience (via permissive OSS
licensing).

Make sense?

-chip

> On Thu, Sep 13, 2012 at 8:13 PM, David Nalley <da...@gnsa.us> wrote:
>
>> On Thu, Sep 13, 2012 at 3:03 PM, Rohit Yadav <ro...@citrix.com>
>> wrote:
>> >
>> >>But how do you build them without those libraries - for instance the
>> >>VMware plugin doesn't build without the vmware libraries being
>> >>present.
>> >
>> > No, not vmware plugin or any nonoss plugin.
>> > By default mvn builds only oss ones.
>> >
>> > So if you've the non-oss jars, you copy them to deps/ and run the
>> install-non-oss.sh script.
>> > This will copy the nonoss deps to ~/.m2 and you build with the nonoss
>> profile:
>> > mvn package -Pnonoss, this creates packages with these nonoss plugins.
>> > (check plugin/pom.xml, that will clear the confusion).
>> >
>> > Lastly, why is kvm under nonoss in plugin/pom.xml? Thanks.
>>
>>
>> Because until today the libvirt-java library that it needed was LGPL
>> which is not compliant with the ASF guidelines for permissible
>> licenses to be included/depended on by the default build.
>>
>> --David
>>
>
>
>
> --
> NS

Re: Building debs with Maven

[Chip Childers <ch...@sungard.com>]

On Thu, Oct 4, 2012 at 5:30 AM, Noah Slater <ns...@tumbolia.org> wrote:
> Chip, thank for the explanation. This makes perfect sense, and I like the
> approach.
>
> To summarise what I'm hearing:
>
>    - A release includes source for plugins for non-OS software

Yes

>    - By default, the release will only build plugins for OS software

Yes - or more specifically, the default build flags are set to only
build the portions of the code that depend on OS software.

>    - Users can enable the plugins for non-OS software at build time

Yes - by getting the dependencies and running the build with the non-oss flag.

>    - If we host builds that include deps, we will not enable plugins for
>    non-OS software

Yes

>    - Community provided builds have the option to include these plugins and
>    deps

Yes

> As a side note, from my time as a Debian developer, I find it strange to
> think that we would bundle dependancies within the deb file. Is this common
> practice for Java systems? (Or just something we would do to simplify our
> packaging efforts?)

It's not really a Java thing.  The real question is if there are
packages available!  IMO, we should, over time, eliminate packaging as
many dependency jars as possible from our spec / deb files, and rely
on package-based dependencies.  We're just not there yet.

>
> On Mon, Oct 1, 2012 at 8:16 PM, Chip Childers <ch...@sungard.com>wrote:
>
>> On Sun, Sep 30, 2012 at 1:31 PM, Noah Slater <ns...@tumbolia.org> wrote:
>> > Just a clarification here. It is fine to use, or depend on proprietary
>> > software that exists on the system. During the build, or after install.
>> > "For example, using a GPL'ed tool during the build is OK." [1] The
>> > stipulation is that we cannot ship anything WITH the build that is
>> > incompatible with our license.
>> >
>> > [1] http://www.apache.org/legal/resolved.html
>>
>> Understood.
>>
>> The approach we are taking is to ensure that the default build process
>> only includes compatible dependencies in the produced RPM and DEB
>> packages (with a few "system dependencies" being required by the
>> packages themselves).  The intent here was to have the RPM and DEB's
>> published via ASF infrastructure.  We've changed course a little bit
>> recently (with Wido hosting the repos outside of ASF), which does open
>> up the possibility of changing our approach.
>>
>> That being said, I personally like the clean model that we have in
>> place right now.  Someone that gets the source code today knows that
>> the default build will only pull in dependencies that are compatible
>> from a licensing perspective.  They are then responsible for some
>> required system dependencies.  And for those dependencies that can
>> optionally be enabled in the build, they are able to follow the
>> instructions to build their own copy of the app that includes the
>> other features.
>>
>> The approach is largely based on the answer for "Can Apache projects
>> rely on components whose licensing affects the Apache product?" from
>> the legal "resolved" page.  It keeps us in a position to potentially
>> host package repos on ASF infra, and sends a clear signal to companies
>> / organizations that want to include an integration into their product
>> for how best to reach a broader audience (via permissive OSS
>> licensing).
>>
>> Make sense?
>>
>> -chip
>>
>> > On Thu, Sep 13, 2012 at 8:13 PM, David Nalley <da...@gnsa.us> wrote:
>> >
>> >> On Thu, Sep 13, 2012 at 3:03 PM, Rohit Yadav <ro...@citrix.com>
>> >> wrote:
>> >> >
>> >> >>But how do you build them without those libraries - for instance the
>> >> >>VMware plugin doesn't build without the vmware libraries being
>> >> >>present.
>> >> >
>> >> > No, not vmware plugin or any nonoss plugin.
>> >> > By default mvn builds only oss ones.
>> >> >
>> >> > So if you've the non-oss jars, you copy them to deps/ and run the
>> >> install-non-oss.sh script.
>> >> > This will copy the nonoss deps to ~/.m2 and you build with the nonoss
>> >> profile:
>> >> > mvn package -Pnonoss, this creates packages with these nonoss plugins.
>> >> > (check plugin/pom.xml, that will clear the confusion).
>> >> >
>> >> > Lastly, why is kvm under nonoss in plugin/pom.xml? Thanks.
>> >>
>> >>
>> >> Because until today the libvirt-java library that it needed was LGPL
>> >> which is not compliant with the ASF guidelines for permissible
>> >> licenses to be included/depended on by the default build.
>> >>
>> >> --David
>> >>
>> >
>> >
>> >
>> > --
>> > NS
>>
>
>
>
> --
> NS

Re: Building debs with Maven

[Noah Slater <ns...@tumbolia.org>]

Chip, thank for the explanation. This makes perfect sense, and I like the
approach.

To summarise what I'm hearing:

   - A release includes source for plugins for non-OS software
   - By default, the release will only build plugins for OS software
   - Users can enable the plugins for non-OS software at build time
   - If we host builds that include deps, we will not enable plugins for
   non-OS software
   - Community provided builds have the option to include these plugins and
   deps

As a side note, from my time as a Debian developer, I find it strange to
think that we would bundle dependancies within the deb file. Is this common
practice for Java systems? (Or just something we would do to simplify our
packaging efforts?)


On Mon, Oct 1, 2012 at 8:16 PM, Chip Childers <ch...@sungard.com>wrote:

> On Sun, Sep 30, 2012 at 1:31 PM, Noah Slater <ns...@tumbolia.org> wrote:
> > Just a clarification here. It is fine to use, or depend on proprietary
> > software that exists on the system. During the build, or after install.
> > "For example, using a GPL'ed tool during the build is OK." [1] The
> > stipulation is that we cannot ship anything WITH the build that is
> > incompatible with our license.
> >
> > [1] http://www.apache.org/legal/resolved.html
>
> Understood.
>
> The approach we are taking is to ensure that the default build process
> only includes compatible dependencies in the produced RPM and DEB
> packages (with a few "system dependencies" being required by the
> packages themselves).  The intent here was to have the RPM and DEB's
> published via ASF infrastructure.  We've changed course a little bit
> recently (with Wido hosting the repos outside of ASF), which does open
> up the possibility of changing our approach.
>
> That being said, I personally like the clean model that we have in
> place right now.  Someone that gets the source code today knows that
> the default build will only pull in dependencies that are compatible
> from a licensing perspective.  They are then responsible for some
> required system dependencies.  And for those dependencies that can
> optionally be enabled in the build, they are able to follow the
> instructions to build their own copy of the app that includes the
> other features.
>
> The approach is largely based on the answer for "Can Apache projects
> rely on components whose licensing affects the Apache product?" from
> the legal "resolved" page.  It keeps us in a position to potentially
> host package repos on ASF infra, and sends a clear signal to companies
> / organizations that want to include an integration into their product
> for how best to reach a broader audience (via permissive OSS
> licensing).
>
> Make sense?
>
> -chip
>
> > On Thu, Sep 13, 2012 at 8:13 PM, David Nalley <da...@gnsa.us> wrote:
> >
> >> On Thu, Sep 13, 2012 at 3:03 PM, Rohit Yadav <ro...@citrix.com>
> >> wrote:
> >> >
> >> >>But how do you build them without those libraries - for instance the
> >> >>VMware plugin doesn't build without the vmware libraries being
> >> >>present.
> >> >
> >> > No, not vmware plugin or any nonoss plugin.
> >> > By default mvn builds only oss ones.
> >> >
> >> > So if you've the non-oss jars, you copy them to deps/ and run the
> >> install-non-oss.sh script.
> >> > This will copy the nonoss deps to ~/.m2 and you build with the nonoss
> >> profile:
> >> > mvn package -Pnonoss, this creates packages with these nonoss plugins.
> >> > (check plugin/pom.xml, that will clear the confusion).
> >> >
> >> > Lastly, why is kvm under nonoss in plugin/pom.xml? Thanks.
> >>
> >>
> >> Because until today the libvirt-java library that it needed was LGPL
> >> which is not compliant with the ASF guidelines for permissible
> >> licenses to be included/depended on by the default build.
> >>
> >> --David
> >>
> >
> >
> >
> > --
> > NS
>



-- 
NS