On Thu, Oct 4, 2012 at 5:30 AM, Noah Slater <nsla...@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.child...@sungard.com>wrote: > >> On Sun, Sep 30, 2012 at 1:31 PM, Noah Slater <nsla...@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 <rohit.ya...@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
