On Thu, Oct 4, 2012 at 5:30 AM, Noah Slater 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 plug
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 softw
On Sun, Sep 30, 2012 at 1:31 PM, Noah Slater 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 canno
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
On Thu, Sep 13, 2012 at 3:03 PM, Rohit Yadav 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
>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
inst
On Thu, Sep 13, 2012 at 1:41 PM, Rohit Yadav wrote:
> Hi David,
>
> I think I misunderstood the problem. Okay the plugins directory in our
> repository contains all ASF compliant code.
> I think the VMWare, NetApp etc. code in plugins are mere wrapper over the
> actual libraries shipped by respe
acts.
Thanks.
Regards,
Rohit
From: David Nalley [da...@gnsa.us]
Sent: Thursday, September 13, 2012 10:54 PM
To: cloudstack-dev@incubator.apache.org
Subject: Re: Building debs with Maven
On Thu, Sep 13, 2012 at 1:10 PM, Rohit Yadav wrote:
> Thanks David for the com
s. Thanks.
Regards,
Rohit
From: Chip Childers [chip.child...@sungard.com]
Sent: Thursday, September 13, 2012 10:43 PM
To: cloudstack-dev@incubator.apache.org
Subject: Re: Building debs with Maven
Rohit,
Can we keep the same package structure that exists today?
-chip
On Th
On Thu, Sep 13, 2012 at 1:10 PM, Rohit Yadav wrote:
> Thanks David for the comments. Alright, in that case, the non-compliant
> packages can be shipped as non-oss.
> Regards.
I am not sure that having two packages (one oss and one nonoss)
satisfies the problem.
Consider the F5, VMware, NetApp,
; Regards.
>
> From: David Nalley [da...@gnsa.us]
> Sent: Thursday, September 13, 2012 10:30 PM
> To: cloudstack-dev@incubator.apache.org
> Subject: Re: Building debs with Maven
>
> On Thu, Sep 13, 2012 at 12:32 PM, Rohit Yadav wrote:
>> Another poll:
>>
>> Would
: Building debs with Maven
On Thu, Sep 13, 2012 at 12:32 PM, Rohit Yadav wrote:
> Another poll:
>
> Would you prefer all the plugin jars/artifacts in one cloud-plugin deb/rpm,
> or, have separate debs/rpms for each plugin jar/artifact, like
> cloud-plugin-kvm etc.
>
> Some problem
On Thu, Sep 13, 2012 at 12:32 PM, Rohit Yadav wrote:
> Another poll:
>
> Would you prefer all the plugin jars/artifacts in one cloud-plugin deb/rpm,
> or, have separate debs/rpms for each plugin jar/artifact, like
> cloud-plugin-kvm etc.
>
> Some problem with attachments, my branch here:
> https:
Another poll:
Would you prefer all the plugin jars/artifacts in one cloud-plugin deb/rpm,
or, have separate debs/rpms for each plugin jar/artifact, like cloud-plugin-kvm
etc.
Some problem with attachments, my branch here:
https://github.com/bhaisaab/incubator-cloudstack/tree/maven-debs
Regards,
14 matches
Mail list logo