incubator-cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chip Childers <chip.child...@sungard.com>
Subject Re: Building debs with Maven
Date Thu, 04 Oct 2012 14:33:27 GMT
On Thu, Oct 4, 2012 at 5:30 AM, Noah Slater <nslater@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 <chip.childers@sungard.com>wrote:
>
>> On Sun, Sep 30, 2012 at 1:31 PM, Noah Slater <nslater@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 <david@gnsa.us> wrote:
>> >
>> >> On Thu, Sep 13, 2012 at 3:03 PM, Rohit Yadav <rohit.yadav@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

Mime
View raw message