On 04-Oct-2012, at 2:45 PM, Noah Slater <nsla...@tumbolia.org> wrote:
> Comments inline. > > On Wed, Oct 3, 2012 at 7:40 AM, Rohit Yadav <rohit.ya...@citrix.com> wrote: > >> 2. While building these required jars are needed to be build against them, >> linking means only class definitions are verified and the plugin is >> compiled. No class is copied from these nonoss libs to these plugins. For >> running these plugins, the above mentioned requirement/deps/jars should be >> in their class path. >> > > Sounds good. > > >> My proposal is to have individual packages (rpms, debs) for these plugins >> which won't have any of these non-ASF libs/jars. A user whose has rightful >> ownership of these non-ASF jars will be just required to install them, and >> install any of these plugins and configure them correctly in the conf files >> mentioned in 3. >> > > Confused by this bit. > > Can you outline your plan for both the source release and the binary > packages? This is just for binary release. For source release, all the code that needs to be shipped is already in the repository. > > Will the source release contain the source for all the plugins? (My best > guess is yes, and this sounds fine.) Yes, it already does, in plugins/ directory. > > If you were providing a binary package, why separate out the plugins? If all plugins artifacts are in separate deb/rpm packages, user has more power to decide which plugin she wants and which she does not. So, if I'm using only xen, I may not want to install kvm, ovm etc. > > Sounds like a binary package should contain all of the plugins we ship, > just like a source release. Yes, the non-asf/nonoss plugins won't work unless user install the libs mentioned in 1. > > >> On build.apache.org, to build cloudstack, we can wget a patch which would >> contain the non-ASF jars mentioned in 1. from non-ASF hosting, build these >> CloudStack debs and rpms, and delete this patch. >> > > This confuses me in the context of the above paragraph. In the above > paragraph, I understand you to be talking about separating out the plugins > for for DEBs and RPMs. But here you seem to be talking about a setup where > build.apache.org is fetching 3rd party non-OS software, so that it can > prepare a binary build that contains all the plugins and is properly linked. You understand correct, my question is, will ASF allow such a process. It's just like installing gcc and libs and building code and removing gcc/libs; not that we use gcc or its libs. > > Let me re-emphasize, the builds won't contain >> > > Won't contain…? The build/binary release, won't contain anything that is not compatible with the Apache license. Thanks for replying, Rohit > > > -- > NS
