Thanks for the information as well as the jira permissions. I have assigned the issue to myself.
I will keep it in 'nonoss' for now and as I get near the end of the project I can make a more educated decision on that point. The change is pretty simple and it won't impact the implementation of the code, so its a non-blocking issue for now. Thanks again... On Thu, Feb 14, 2013 at 12:54 PM, Chip Childers <chip.child...@sungard.com>wrote: > On Thu, Feb 14, 2013 at 12:24:13PM -0500, Will Stevens wrote: > > - I am currently compiling my code using the 'nonoss' flag similar to > > JuniperSRX, Netscaler, etc... I will not be referencing any code > external > > to CloudStack, but I will be integrating with the Palo Alto API. I > need to > > confirm that the Palo Alto API documentation can be made publicly > > accessible. What is the standard practice regarding the nonoss flag > and > > when it should be used? > > The non-oss flag is basically so that our default build does not pull in > non ASLv2 compatible dependencies (as defined by the ASF legal folks). > In the scenario that you describe, you are creating CloudStack code that > will call a remote web service API, which means you are not adding a new > dependency to the project. Based on this, there's no reason that you > would need your code to be in the non-default build (but we'll adjust as > needed as you get further along). > > One point to note - Inclusion of the WSDL in our code may be > questionable. Inclusion of proxy class files generated from that WSDL > should not be a problem. > > > Also, I do not have permission to assign the New Feature issue I created > in > > Jira to myself, so if someone could do that for me that would be great > > (link is in the spec). > > You have permission now. Give it a shot! > > -chip >
