On Wed, Nov 28, 2012 at 12:31 AM, Senaka Fernando <[email protected]> wrote:
> Hi Subash, > > On Tue, Nov 27, 2012 at 5:36 PM, Subash Chaturanga <[email protected]>wrote: > >> >> >> On Tue, Nov 27, 2012 at 1:24 PM, Senaka Fernando <[email protected]> wrote: >> >>> Hi Subash, >>> >>> Aggregate Download is now working, but we need to make it meaningful. >>> For example, when you download the WSDL as a zip, the relative paths inside >>> the downloaded zip should be fixed. For example, the schema locations in >>> the authenticate WSDL, needs to change from >>> "../../../../schemas/com/pictor/services/authenticate.xsd" to >>> "dependencies/authenticate.xsd". >>> >> +1 >> >>> Also, if there was a WSDL or schema inside the dependencies folder that >>> has further imports, those also need to be fixed appropriately. >>> >> For a given WSDL/artifact it has N number of dependencies. You mean we >> should download the dependencies of each dependency and continue this >> further. >> > > Well yes. Say someone downloads a WSDL which has a Schema Foo that imports > a Schema Bar. Unless you download all 3, someone can't use that and > generate code for instance. > What should be the dependency download structure ? Currently this downloads the first level dependencies. i.e download foo.wsdl foo.zip - foo.wsdl - dependencies - foo-dep1.xsd - foo-dep2.xsd >> >>> If we have time, we need to create an extension point where people can >>> define there own aggregate download manager class which can handle >>> proprietary media types as well. >>> >> >> ++1 . Users should be able to define their custom aggregate download >> manager classes where each class can be defined against a particular media >> type. And We should have our global download manager class which will get >> hit if none of the managers are registered to the current resource media >> type. WDYT ? >> > > Not quite. We need not have multiple classes. The user should be able to > extend the global download manager class with his/her class. IMO, just a > single download manager is sufficient for this. > > Thanks, > Senaka. > >> >> >>> But, the extension point is something we can keep for later if this is >>> too much of work. >>> >>> After done, lets schedule a review with Srinath et al and get the >>> roadmap item resolved. >>> >>> Thanks, >>> Senaka. >>> >>> -- >>> *Senaka Fernando* >>> Member - Integration Technologies Management Committee; >>> Technical Lead; WSO2 Inc.; http://wso2.com* >>> Member; Apache Software Foundation; http://apache.org >>> >>> E-mail: senaka AT wso2.com >>> **P: +1 408 754 7388; ext: 51736*; *M: +94 77 322 1818 >>> Linked-In: http://linkedin.com/in/senakafernando >>> >>> *Lean . Enterprise . Middleware >>> >>> >> >> >> -- >> >> Subash Chaturanga >> Software Engineer >> WSO2 Inc. http://wso2.com >> >> email - [email protected] >> phone - 077 2225922 >> >> > > > -- > *Senaka Fernando* > Member - Integration Technologies Management Committee; > Technical Lead; WSO2 Inc.; http://wso2.com* > Member; Apache Software Foundation; http://apache.org > > E-mail: senaka AT wso2.com > **P: +1 408 754 7388; ext: 51736*; *M: +94 77 322 1818 > Linked-In: http://linkedin.com/in/senakafernando > > *Lean . Enterprise . Middleware > > -- Subash Chaturanga Software Engineer WSO2 Inc. http://wso2.com email - [email protected] phone - 077 2225922
_______________________________________________ Dev mailing list [email protected] http://wso2.org/cgi-bin/mailman/listinfo/dev
