Re: [Architecture] Redesigning Puppet Modules & Publishing them in Puppet Forge
Hi Imesh, On Fri, Dec 4, 2015 at 10:12 PM, Imesh Gunaratne <im...@wso2.com> wrote: > Hi Krishantha, > > On Fri, Dec 4, 2015 at 12:36 PM, Krishantha Samaraweera < > krishan...@wso2.com> wrote: > >> >> We need to consider continues delivery aspects when designing these core >> puppet modules. Some of the suggestions that you have mentioned are already >> being implemented while automating APIM deployment patterns. If we can >> review and adhere to the way automation team design puppet scripts that >> would cut down any rework for our side. >> > > +1 Yes definitely, we are now reviewing the API-M puppet module developed > by your team, planning to take it as it is and do any necessary changes to > make it generic. > +1 for looking into existing scripts and trying to reuse them. Yes there are many things that we can make more generic. > >> Automation requirement is to do several deployments and run tests on >> those deployments without any human interventions. We already completed POC >> of this using puppet, Hiera, Mcollective and Jenkins. >> > > Do you think Mcollective and Jenkins should be part of the generic puppet > modules? > No, however we used factors to store deployment pattern and product name. By changing those factors different deployment patterns can be triggered though Jenkins. We used below Mcollective command to change factors in all agent machines. This helps us to trigger deployments though Jenkins. *mco shell run 'rm /etc/facter/facts.d/deployment_pattern.txt;mkdir -p /etc/facter/facts.d; echo "deployment_pattern=pattern1" >> /etc/facter/facts.d/deployment_pattern.txt'* So if you can consider about factors to hold high level deployment options then that would be very continuous delivery friendly option. Thanks, Krishantha. >> IMO, as the first step we should review the Hiera data model and module >> structure that we have introduced. And improve it if required or go for new >> design. >> > > +1 Will do. > >> >> Also having environment concept (Development, production, QA) would help >> us to manage/maintain puppet scripts more easily. >> >> Yes we noticed this in Hiera. We should be able to keep this feature in > the generic puppet modules. > > Thanks > > >> WDYT ? >> >> Thanks, >> Krishantha. >> >> On Fri, Dec 4, 2015 at 12:19 AM, Imesh Gunaratne <im...@wso2.com> wrote: >> >>> Hi, >>> >>> We are now trying to refactor the puppet modules in [1] according to the >>> best practices DevOps, Automation and Private PaaS teams found over the >>> recent past on designing puppet modules. These include following: >>> >>>- Using Hiera for keeping site-specific data out of the manifests [2] >>>- Use a base puppet module/class to implement common installation >>>and configuration steps >>>- Use one puppet module to install different versions of a product, >>>product version to be given using a parameter (example: puppet module = >>>wso2esb, product version = 4.9.0) >>>- Eventually include multiple sets of templates for different >>>versions of the product inside a single puppet module >>>- Provide a version for the puppet module (example: puppet module = >>>wso2esb, puppet module version = 1.0.0, product version = 4.9.0) >>>- Implement unit tests for puppet modules [3] >>>- Finally publish puppet modules in Puppet Forge >>>- Afterwards users can either use puppet install or wget for >>>installing puppet modules in their environments >>> >>> These puppet modules will be designed to support different deployment >>> models: >>> >>>- Deploying WSO2 products on VMs using a Puppet Master >>>- Building Docker images with Puppet Apply [4] for Kubernetes >>>- Deploying WSO2 products on WSO2 Private PaaS >>> - On VMs using a Puppet Master with runtime configurations >>> - On Kubernetes using Puppet Apply with runtime configurations >>> >>> Please feel free to add your thoughts. >>> >>> [1] https://github.com/wso2/puppet-modules/ >>> [2] https://docs.puppetlabs.com/hiera/latest/ >>> [3] >>> https://puppetlabs.com/blog/the-next-generation-of-puppet-module-testing >>> [4] >>> https://puppetlabs.com/blog/docker-and-puppet-for-application-management >>> >>> Thanks >>> >>> -- >>> *Imesh Gunaratne* >>> Senior Technical Lead >>
Re: [Architecture] Redesigning Puppet Modules & Publishing them in Puppet Forge
Hi Imesh, We need to consider continues delivery aspects when designing these core puppet modules. Some of the suggestions that you have mentioned are already being implemented while automating APIM deployment patterns. If we can review and adhere to the way automation team design puppet scripts that would cut down any rework for our side. Automation requirement is to do several deployments and run tests on those deployments without any human interventions. We already completed POC of this using puppet, Hiera, Mcollective and Jenkins. IMO, as the first step we should review the Hiera data model and module structure that we have introduced. And improve it if required or go for new design. IMO, we have achieved 100% data separation from puppet modules and product template versioning. Based on the review we can introduce new base module. Also having environment concept (Development, production, QA) would help us to manage/maintain puppet scripts more easily. WDYT ? Thanks, Krishantha. On Fri, Dec 4, 2015 at 12:19 AM, Imesh Gunaratne <im...@wso2.com> wrote: > Hi, > > We are now trying to refactor the puppet modules in [1] according to the > best practices DevOps, Automation and Private PaaS teams found over the > recent past on designing puppet modules. These include following: > >- Using Hiera for keeping site-specific data out of the manifests [2] >- Use a base puppet module/class to implement common installation and >configuration steps >- Use one puppet module to install different versions of a product, >product version to be given using a parameter (example: puppet module = >wso2esb, product version = 4.9.0) >- Eventually include multiple sets of templates for different versions >of the product inside a single puppet module >- Provide a version for the puppet module (example: puppet module = >wso2esb, puppet module version = 1.0.0, product version = 4.9.0) >- Implement unit tests for puppet modules [3] >- Finally publish puppet modules in Puppet Forge >- Afterwards users can either use puppet install or wget for >installing puppet modules in their environments > > These puppet modules will be designed to support different deployment > models: > >- Deploying WSO2 products on VMs using a Puppet Master >- Building Docker images with Puppet Apply [4] for Kubernetes >- Deploying WSO2 products on WSO2 Private PaaS > - On VMs using a Puppet Master with runtime configurations > - On Kubernetes using Puppet Apply with runtime configurations > > Please feel free to add your thoughts. > > [1] https://github.com/wso2/puppet-modules/ > [2] https://docs.puppetlabs.com/hiera/latest/ > [3] > https://puppetlabs.com/blog/the-next-generation-of-puppet-module-testing > [4] > https://puppetlabs.com/blog/docker-and-puppet-for-application-management > > Thanks > > -- > *Imesh Gunaratne* > Senior Technical Lead > WSO2 Inc: http://wso2.com > T: +94 11 214 5345 M: +94 77 374 2057 > W: http://imesh.gunaratne.org > Lean . Enterprise . Middleware > > -- Krishantha Samaraweera Senior Technical Lead - Test Automation Mobile: +94 77 7759918 WSO2, Inc.; http://wso2.com/ lean . enterprise . middleware. ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] Deployment Automation Progress Update
Hi Shankar, On Tue, Dec 16, 2014 at 12:55 PM, Selvaratnam Uthaiyashankar shan...@wso2.com wrote: Did you guys discuss with Chamith on this? We are planning to have a review with DevOps this week. Thanks, Krishantha. Chamith, this is similar to what you guys are doing for cloud? On Tue, Dec 16, 2014 at 9:59 AM, Suhan Dharmasuriya suh...@wso2.com wrote: We have successfully migrated to the new cloud: https://openstackstg.private.wso2.com/ Hypervisor Summary as follows. Memory available 30.8 GB Disk available 1.8 TB VCPUs available 16 Thanks, Suhan On Tue, Dec 16, 2014 at 9:38 AM, Suhan Dharmasuriya suh...@wso2.com wrote: Hi, We have introduced a new configuration file deployment.cfg [1]. Python will load the relevant initial configurations from this file including server node names. Therefore nodes.txt file is removed. When loading node names in the cluster initially had a problem of spawning instances in OpenStack in a random order. This issue was solved using python collections.OrderedDict [3] instead of using default dictionary (unordered). Cluster information is kept in a config.pp file [2]. [1] https://github.com/suhand/Deployment-Automation/blob/master/deployment-automation-total-puppet/python_scripts/deployment.cfg [2] https://github.com/suhand/Deployment-Automation/blob/master/deployment-automation-total-puppet/python_scripts/config.pp [3] http://stackoverflow.com/questions/27483096/python-config-parser-array-sort-according-to-file-content-sequence/27483584#27483584 Thanks, Suhan On Mon, Dec 15, 2014 at 11:27 AM, Suhan Dharmasuriya suh...@wso2.com wrote: Adding Ramith... On Fri, Dec 12, 2014 at 11:43 AM, Suhan Dharmasuriya suh...@wso2.com wrote: On Fri, Dec 12, 2014 at 11:40 AM, Suhan Dharmasuriya suh...@wso2.com wrote: Hi all, We are working on developing a deployment automation process which will be integrated in to the test automation framework to run test suites on different product platforms. Following is the current process of deployment automation process. Nodes information file contains all the names of nodes in the cluster of which the collective behavior is tested. It will contain hostnames of the nodes such as appserver-mgr1 appserver-wkr1. Configuration data for each node in the cluster will be kept as a data structure in another configuration file which will be restructured according to the spawned instances information (in OpenStack) and reflected in puppet master. This configuration file was initially created as an xml file similar to the product configuration files following the same xml hierarchical pattern. Following DevOps practices the configuration xml file is removed and puppet data structure file is introduced. Using python novaclient API, equal number of instances are spawned in the environment (OpenStack). When instances are being created a preconfigured OpenStack image [1] will be used from an image repository. This image includes preconfigured puppet agent and ganglia client services (aware of puppet master and ganglia monitor locations). Once the instances are spawned in OpenStack, the relevant information of the node is retrieved using facter [2]. This information will be cross mapped and merged with the configuration file with the relevant information such as IP addresses, hostnames of the instances to create a puppet central configuration file. Puppet will be taking over its operations once this configuration file is in place. By mapping the hostname of the incoming puppet agent request against the configuration file, puppet master performs the following operations. - Ensure essential packages such as unzip are present in agent node prior starting server operations. - Remove old extractions and installations of conflicting product packs. - Install the defined jdk to the instance. - Extract product pack file. - Retrieve node specific values and update product pack configuration (axis2.xml, carbon.xml, catalina-server.xml, etc...). - Start the server with given server options. In future deployment automation module will be expanded to support OpenStack, EC2, Physical networked machines and Local environments. Currently development started with OpenStack using python novaclient API. Issues encountered and findings are logged in [3], [4] and [5]. In the next phase Docker will be evaluated to facilitate cross platform test execution (Multiple DBs, JDKs, User Stores, OS etc..) Please share your ideas for improvement. We are planning to have an architectural review with DevOps team within next week. Attached diagram represents the proposed architecture. [1] https://docs.google.com/a/wso2.com/document/d/1XVEs_5Aq5I7S1IbgFKjvzMX-_xCKOX--Yo6SXgk6JYY/edit [2]http://packages.ubuntu.com/trusty/facter [3]http://suhan-opensource.blogspot.com/ [4] https://docs.google.com/a/wso2.com
Re: [Architecture] Feature Level Automation Testing
With this approach you are writing something in between unit and integration but more towards integration tests. We can't describe feature level automated tests as pure integration tests as other required components to make it a product are not present. May be we need to come up with new term for this - something like 'feature-testing' :) We need to decide whether to duplicate tests or not. If we can make sure a particular feature works 100% with feature level tests, then duplicating the same test in product level is not required (This will add extra time overhead to our builds). If you have greater coverage in feature level then tests required for product verification will be minimal. I would like to have a discussion on this with carbon-kernel team to finalize everything. Will send an invitation. Thanks, Krishantha. On Fri, Oct 31, 2014 at 8:06 PM, KasunG Gajasinghe kas...@wso2.com wrote: Hi, Will we be writing integration tests or unit tests with this approach? If we are writing integration tests here, then we will have integration tests in carbon component/feature repos in addition to what we already have in product repos. It's important to have automation tests at product level. So, when writing a new integration test, how can we decide which repo it should go to? Will we have to duplicate any test? On Wed, Oct 29, 2014 at 6:51 PM, Irham Iqbal iq...@wso2.com wrote: Hi all, I am working on creating an environment to write test cases to test standalone features. With new GIT module components and features should be released prior to product releases, so all features must be thoroughly tested and should be production ready. Carbon runtime is needed to test the standalone features, so our plan is to start carbon-core by installing all features resided in a project repository. For creating test execution environment, all features will be installed on carbon-core using carbon-p2-plugin. Before installing we have to create p2-repo with relevant features in it. To do that, need to have pom with all feature dependencies required (including common dependencies) . P2-repo will be created by installing that pom with relevant features specified. When installing a feature you have to find out and install all the other features this feature is depending on. After creating carbon-core with all required features, test framework dependency will be used with new extension classes to facilitate sever management, code coverage generation and user/tenant creation. I've done a POC to verify feature installation on carbon-core in carbon-deployment project and everything seems to work fine. Just need clarify whether this is the correct approach for feature level testing and any suggestions for alternatives. Kindly expecting your ideas on this. Attached diagram depict proposed architecture. Thanks, Iqbal -- Irham Iqbal Software Engineer - Test Automation WSO2, Inc.: http://wso2.com lean. enterprise. middleware phone: +94 777888452 -- *Kasun Gajasinghe*Senior Software Engineer, WSO2 Inc. email: kasung AT spamfree wso2.com linked-in: http://lk.linkedin.com/in/gajasinghe blog: http://kasunbg.org ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture -- Krishantha Samaraweera Senior Technical Lead - Test Automation Mobile: +94 77 7759918 WSO2, Inc.; http://wso2.com/ lean . enterprise . middlewear. ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] [IS] Test Automation - Open Id
Hi Malithi, You can use TestNG data provider along with @factory annotation to re-run the same test with different parameters. We used this combination to run the same tests in Admin/Tenant mode [1]. Test Framework 4.2.8 does support tenant mode test execution but you have to change the automation.properties file and re-execute the tests. However TAF 4.3.0 version support for this OOB where you don't need to reinitiate the tests. [1] https://docs.wso2.com/display/TA430/Writing+a+Test+Case+for+Multiple+User+Modes Thanks, Krishantha. On Mon, Oct 20, 2014 at 6:39 PM, Malithi Edirisinghe malit...@wso2.com wrote: Hi all, I'm working on $subject. During the discussions I had with my team members found that we have to automate the Open Id flow for various combination of parameters defined below. User - (Admin/Login User/Tenant User) User Consent - (Approve/Approve Always/Skip) Association Type - (DB Store/Replication Store/Crypto Store) Claims - (With/Without) Consumer Type - (Smart Mode/Dumb Mode) I'm planning to use parameterized tests supported by TestNG for this implementation, where the same test can be run over and over again for different parameter values [1]. Further I noted that the WSO2 Test Automation Framework 4.3.0 supports running tests for multiple user modes [2]. I would also like to know whether we have such support with 4.2.8 Kindly expect your thoughts on this. [1] http://www.tutorialspoint.com/testng/testng_parameterized_test.htm [2] https://docs.wso2.com/display/TA430/Writing+a+Test+Case+for+Multiple+User+Modes Thanks, Malithi. -- *Malithi Edirisinghe* Senior Software Engineer WSO2 Inc. Mobile : +94 (0) 718176807 malit...@wso2.com -- Krishantha Samaraweera Senior Technical Lead - Test Automation Mobile: +94 77 7759918 WSO2, Inc.; http://wso2.com/ lean . enterprise . middlewear. ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] Connector:BrainTree
Following methods seems to be more relevant with CRM while others for payment. i think we can use payment section with out following methods. I think we should remove those as those are less priority. isn't it? what is ur idea Rasika/Dushan ??? *Customers* createCustomer - Create a Customer on Server-To-Server deleteCustomer- Delete a customer getCustomer - Get customer details searchCustomers - Search through existing customers updateCustomer - Update an existing customer *Addresses* createAddress - Create a new address deleteAddress - Delete an address getAddressDetails - Get details of an address updateAddress - Update address detail cloneTransaction - Clone an existing transaction searchCreditCards - Search through existing Credit Cards -- View this message in context: http://wso2-oxygen-tank.10903.n7.nabble.com/Connector-BrainTree-tp98062p98244.html Sent from the WSO2 Architecture mailing list archive at Nabble.com. ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] Connector:Con - cur
Hi Malaka, I have considered only the business use cases which most possible to perform on integration. as a example admin related / one time configuration functionality such as setup accounts / setup vendors / setup paytype have not been considered as those are doing directly my accessing application and very less possibility for integration requirement. -- View this message in context: http://wso2-oxygen-tank.10903.n7.nabble.com/Connector-Con-cur-tp95939p96435.html Sent from the WSO2 Architecture mailing list archive at Nabble.com. ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] Connector:box
Final method list will as follows *Introduction* With Box, you can store all kinds of files online – then arrange them into folders just like on your desktop. Access them anytime, anywhere; share with friends and collaborate with teammates, too. Just send 'em a link. in simple it is an online storage API http://developers.box.com/docs/ box Connector Summery • Connector Name: box-connector-1.0.0 • Version: 1.0.0 • Technology: REST Authentication The Box API uses OAuth 2 for authentication. An authorization header containing a valid access_token must be included in every request. Folders createFolder - Used to create a new empty folder. getFolderInformation - Retrieves the full metadata about a folder, including information about when it was last updated as well as the files and folders contained in it. updateFolderInformation - Used to update information about the folder. deleteFolder - Used to delete a folder. copyFolder - Used to create a copy of a folder in another folder. shareFolder - Used to create a shared link for this particular folder. File getFileInformation - Used to retrieve the metadata about a file. updateFileInformation - Used to update individual or multiple fields in the file object, including renaming the file, changing it’s description, and creating a shared link for the file. downloadFile - Retrieves the actual data of the file. uploadFile - Use the Uploads API to allow users to add a new file. The user can then upload a file by specifying the destination folder for the file. deleteFile - Discards a file to the trash. copyFile - Used to create a copy of a file in another folder. shareFile - Used to create a shared link for this particular file. listFileComments - Retrieves the comments on a particular file, if any exist. Comments createComment - Used to add a comment by the user to a specific file or comment (i.e. as a reply comment). updateComment - Used to update the message of the comment. getComment - Used to retrieve the message and metadata about a specific comment. deleteComment - Permanently deletes a comment. Shared Items getSharedItem - Used to retrieve the metadata about a shared item when only given a shared link. Search search - The search endpoint provides a simple way of finding items that are accessible in a given user’s Box account. Users listUsers - Returns a list of all users for the Enterprise along with their user_id, public_name, and login. moveFolder - Moves all of the owned content from within one user’s folder into a new folder in another user’s account. -- View this message in context: http://wso2-oxygen-tank.10903.n7.nabble.com/Connector-box-tp95582p96145.html Sent from the WSO2 Architecture mailing list archive at Nabble.com. ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
[Architecture] Connector:github
Introduction GitHub is a web-based hosting service for software development projects that use the Git revision control system. GitHub offers both paid plans for private repositories, and free accounts for open source projects. API https://developer.github.com/v3/ GitHub Connector Summery • Connector Name: GitHub-connector-1.0.0 • Version: 1.0.0 • Technology: REST Authentication GitHub use oAuth2 based access token Method summary Git Data getBlob - Retrieves a blob. createBlob - Uploads a blob. createCommit- Creates a comment. Issues listRepositoryIssues- Lists issues for a repository. getIssue- Retrieves a single issue. createIssue - Any user with pull access to a repository can create an issue. editIssue - Issue owners and users with push access can edit an issue. listIssueAssignees - This call lists all the available assignees (owner + collaborators) to which issues may be assigned. listIssueComments - This lists comments on an issue. createIssueComment - Allows to create a comment on an issue. editIssueComment- Allows to edit a comment on an issue. deleteIssueComment - Allows to delete a comment on an issue. Pull Requests listPullRequests- Lists all the pull requests. getPullRequest - Retrieves a single pull request. createPullRequest - Creates a pull request. updatePullRequest - Updates a pull request. listPullRequestCommits - It list commits on a pull request. listPullRequestsFiles - This lists pull request files. getMergeStatus - Retrieve the status as to if a pull request has been merged. mergePullRequest- This merges a pull request. Search searchIssues- Find issues by state and keyword. (This method returns up to 100 results per page.) Users getUser - Retrieves a single user -- View this message in context: http://wso2-oxygen-tank.10903.n7.nabble.com/Connector-github-tp95932.html Sent from the WSO2 Architecture mailing list archive at Nabble.com. ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
[Architecture] Connector:Con - cur
*Note: Con - cur should consider by removing spaces and -* Introduction Con - cur's easy-to-use business travel and expense management software solution helps your business save time, money and gain control API https://www.concursolutions.com/api/docs/index.html (REST) Con - cur Connector Summary • Connector Name: Con - cur-connector-1.0.0 • Version: 1.0.0 • Technology: REST Authentication Con - cur use oAuth2 based access token getAllAttendeeTypes - Returns all active AttendeeTypes for the company. getExpenseEntries - Returns all expense entries owned by the user. getExpenseEntry - Returns an expense entry by ID. createExpenseEntry - Creates a new expense entry deleteExpenseEntry - Deletes the specified expense entry getExchangeRates - Retrieve exchange rate between two currencies on a given date. updatePurchaseOrderReceipts - Updates purchase order line item with receipt information and returns status of updation. createPurchaseOrder - Creates a purchase order and returns the status of creation. updatePurchaseOrder - Updates an existing purchase order and returns the status of the request. getPurchaseOrder - Gets an existing purchase order. getAllQuickExpenses - Returns all QuickExpenses owned by the user. getQuickExpense - Returns a QuickExpense by ID. createQuickExpense - Creates a new QuickExpense updateQuickExpense - Updates the QuickExpense specified in the URL. deleteQuickExpense - Deletes the specified QuickExpense getReceiptIdsForUser - Get a list of all receipt IDs owned by the user associated with the OAuth token getReceiptImageURL - Get a receipt image URL by image ID. createReceiptImage - Creates a new image in the receipt store. deleteReceiptImage - Deletes the specified receipt image getAllVendors - Gets an existing vendor. -- View this message in context: http://wso2-oxygen-tank.10903.n7.nabble.com/Connector-Con-cur-tp95939.html Sent from the WSO2 Architecture mailing list archive at Nabble.com. ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] Connector:box
#following method name will change as follows createFileSharedLink -- shareFile createFolderShareLink -- shareFolder #Share heading should corrected as Search -- View this message in context: http://wso2-oxygen-tank.10903.n7.nabble.com/Connector-box-tp95582p95820.html Sent from the WSO2 Architecture mailing list archive at Nabble.com. ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] Connector:dropbox
agreed. i have changed the names. so as a conclusion final list will be as follows Introduction Dropbox is a storage for all photos, docs, videos, and files. Anything you add to Dropbox will automatically show up on all your computers, phones and even the Dropbox website — so you can access your stuff from anywhere API https://www.dropbox.com/developers/core dropbox Connector Summery • Connector Name: dropbox-connector-1.0.0 • Version: 1.0.0 • Technology: REST Authentication The dropbox REST API requires access token as authentication mechanism (OAuth2) Files and metadata getFile - Downloads a file. uploadFile - Uploads a file using PUT semantics. getMetadata - Retrieves file and folder metadata getRevisionMetadata - Obtains metadata for the previous revisions of a file. restoreFile - Restores a file path to a previous revision. *search- Returns metadata for all files and folders whose filename contains the given search string as a substring* *share - Returns a link directly to a file* chunkUpload - Uploads large files to Dropbox in multiple chunks commitChunk - Completes an upload initiated by the [chunkUpload] method File operations copy - Copies a file or folder to a new location createFolder - Creates a folder. delete - Deletes a file or folder. move - Moves a file or folder to a new location. -- View this message in context: http://wso2-oxygen-tank.10903.n7.nabble.com/Connector-dropbox-tp95437p95576.html Sent from the WSO2 Architecture mailing list archive at Nabble.com. ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
[Architecture] Connector:box
Introduction With Box, you can store all kinds of files online – then arrange them into folders just like on your desktop. Access them anytime, anywhere; share with friends and collaborate with teammates, too. Just send 'em a link. in simple it is an online storage API http://developers.box.com/docs/ http://developers.box.com/docs/ box Connector Summery • Connector Name: box-connector-1.0.0 • Version: 1.0.0 • Technology: REST Authentication The Box API uses OAuth 2 for authentication. An authorization header containing a valid access_token must be included in every request. Folders createFolder - Used to create a new empty folder. getFolderInformation - Retrieves the full metadata about a folder, including information about when it was last updated as well as the files and folders contained in it. updateFolderInformation - Used to update information about the folder. deleteFolder - Used to delete a folder. copyFolder - Used to create a copy of a folder in another folder. createFolderSharedLink - Used to create a shared link for this particular folder. File getFileInformation - Used to retrieve the metadata about a file. updateFileInformation - Used to update individual or multiple fields in the file object, including renaming the file, changing it’s description, and creating a shared link for the file. downloadFile - Retrieves the actual data of the file. uploadFile - Use the Uploads API to allow users to add a new file. The user can then upload a file by specifying the destination folder for the file. deleteFile - Discards a file to the trash. copyFile - Used to create a copy of a file in another folder. createFileSharedLink - Used to create a shared link for this particular file. listFileComments - Retrieves the comments on a particular file, if any exist. Comments createComment - Used to add a comment by the user to a specific file or comment (i.e. as a reply comment). updateComment - Used to update the message of the comment. getComment - Used to retrieve the message and metadata about a specific comment. deleteComment - Permanently deletes a comment. Shared Items getSharedItem - Used to retrieve the metadata about a shared item when only given a shared link. Share search - The search endpoint provides a simple way of finding items that are accessible in a given user’s Box account. Users listUsers - Returns a list of all users for the Enterprise along with their user_id, public_name, and login. moveFolder - Moves all of the owned content from within one user’s folder into a new folder in another user’s account. -- View this message in context: http://wso2-oxygen-tank.10903.n7.nabble.com/Connector-box-tp95582.html Sent from the WSO2 Architecture mailing list archive at Nabble.com. ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] Connector:box
Yes Malaka, I have considered to cover all core functionalities. so we can add others later on-demand On Thu, Apr 24, 2014 at 5:28 PM, Malaka Silva mal...@wso2.com wrote: Hi, I guess this pretty much covers most of the methods? Best Regards, Malaka On Thu, Apr 24, 2014 at 1:01 PM, krishantha kr...@krishantha.com wrote: Introduction With Box, you can store all kinds of files online – then arrange them into folders just like on your desktop. Access them anytime, anywhere; share with friends and collaborate with teammates, too. Just send 'em a link. in simple it is an online storage API http://developers.box.com/docs/ http://developers.box.com/docs/ box Connector Summery • Connector Name: box-connector-1.0.0 • Version: 1.0.0 • Technology: REST Authentication The Box API uses OAuth 2 for authentication. An authorization header containing a valid access_token must be included in every request. Folders createFolder - Used to create a new empty folder. getFolderInformation - Retrieves the full metadata about a folder, including information about when it was last updated as well as the files and folders contained in it. updateFolderInformation - Used to update information about the folder. deleteFolder - Used to delete a folder. copyFolder - Used to create a copy of a folder in another folder. createFolderSharedLink - Used to create a shared link for this particular folder. File getFileInformation - Used to retrieve the metadata about a file. updateFileInformation - Used to update individual or multiple fields in the file object, including renaming the file, changing it’s description, and creating a shared link for the file. downloadFile - Retrieves the actual data of the file. uploadFile - Use the Uploads API to allow users to add a new file. The user can then upload a file by specifying the destination folder for the file. deleteFile - Discards a file to the trash. copyFile - Used to create a copy of a file in another folder. createFileSharedLink - Used to create a shared link for this particular file. listFileComments - Retrieves the comments on a particular file, if any exist. Comments createComment - Used to add a comment by the user to a specific file or comment (i.e. as a reply comment). updateComment - Used to update the message of the comment. getComment - Used to retrieve the message and metadata about a specific comment. deleteComment - Permanently deletes a comment. Shared Items getSharedItem - Used to retrieve the metadata about a shared item when only given a shared link. Share search - The search endpoint provides a simple way of finding items that are accessible in a given user’s Box account. Users listUsers - Returns a list of all users for the Enterprise along with their user_id, public_name, and login. moveFolder - Moves all of the owned content from within one user’s folder into a new folder in another user’s account. -- View this message in context: http://wso2-oxygen-tank.10903.n7.nabble.com/Connector-box-tp95582.html Sent from the WSO2 Architecture mailing list archive at Nabble.com. ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture -- Best Regards, Malaka Silva Senior Tech Lead M: +94 777 219 791 Tel : 94 11 214 5345 Fax :94 11 2145300 Skype : malaka.sampath.silva LinkedIn : http://www.linkedin.com/pub/malaka-silva/6/33/77 Blog : http://mrmalakasilva.blogspot.com/ WSO2, Inc. lean . enterprise . middleware http://www.wso2.com/ http://www.wso2.com/about/team/malaka-silva/http://wso2.com/about/team/malaka-silva/ Save a tree -Conserve nature Save the world for your future. Print this email only if it is absolutely necessary. ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
[Architecture] Connector:dropbox
*Introduction* Dropbox is a storage for all photos, docs, videos, and files. Anything you add to Dropbox will automatically show up on all your computers, phones and even the Dropbox website — so you can access your stuff from anywhere *API* https://www.dropbox.com/developers/core *dropbox Connector Summery* • Connector Name: dropbox-connector-1.0.0 • Version: 1.0.0 • Technology: REST *Authentication* The dropbox REST API requires access token as authentication mechanism (OAuth2) *Files and metadata* getFile - Downloads a file. uploadFile - Uploads a file using PUT semantics. getMetadata - Retrieves file and folder metadata getRevisionMetadata - Obtains metadata for the previous revisions of a file. restoreFile - Restores a file path to a previous revision. listFileMetadata - Returns metadata for all files and folders whose filename contains the given search string as a substring shareWithDirectLink - Returns a link directly to a file chunkUpload - Uploads large files to Dropbox in multiple chunks commitChunk - Completes an upload initiated by the [chunkUpload] method *File operations* copy - Copies a file or folder to a new location createFolder - Creates a folder. delete - Deletes a file or folder. move - Moves a file or folder to a new location. -- View this message in context: http://wso2-oxygen-tank.10903.n7.nabble.com/Connector-dropbox-tp95437.html Sent from the WSO2 Architecture mailing list archive at Nabble.com. ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] WSO2 Data Services Server 3.2.0-M2 Released
Hi Chanika, Any chance for your to run all integration tests. Can you publish the result with coverage stats Thanks, Krishatha. On Sat, Mar 29, 2014 at 10:39 AM, Chanika Geeganage chan...@wso2.comwrote: *WSO2 Data Services Server 3.2.0-M2 Released!* The Milestone-2 pack is available at: http://svn.wso2.org/repos/wso2/people/chanika/DSS_3.2.0_M2/ To run the samples please follow the read-me, $DSS_HOME/samples/README.txt Following are the bug fixes, improvements and the new features. Bug - [DS-860 https://wso2.org/jira/browse/DS-860https://wso2.org/jira/browse/DS-801] - Eventing Broker Not Available Error on Startup - [DS-853 https://wso2.org/jira/browse/DS-853] - When finish the Edit Wizard, it removes configuration of a custom datasource - [DS-805 https://wso2.org/jira/browse/DS-805] - Cant add a property when creating a data source - [DS-797 https://wso2.org/jira/browse/DS-797] - Two warning messages can be observed when start the server with samples Improvement - [DS-863 https://wso2.org/jira/browse/DS-863] - Making Task Location Resolver Class as a configurable field New Features - [DS-848 https://wso2.org/jira/browse/DS-848] - Returning a structured error message to the user when a SOAP fault occurred - [DS-864 https://wso2.org/jira/browse/DS-864] - MongoDB datasource support We welcome your feedback on this release of DSS. Thanks - WSO2 DSS Team -- Best Regards.. Chanika Geeganage Software Engineer WSO2, Inc.; http://wso2.com ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture -- Krishantha Samaraweera Senior Technical Lead - Test Automation Mobile: +94 77 7759918 WSO2, Inc.; http://wso2.com/ lean . enterprise . middlewear. ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] WSO2 Test Automation Framework 4.3.0 is ready to be used.
Hi Senaka, On Sun, Feb 16, 2014 at 7:48 PM, Senaka Fernando sen...@wso2.com wrote: Hi Dharshana, First of all, congratulations on the 4.3.0 release. I got a few questions on TAF. 1. Can we link the documentation of TAF to this release note? We are doing final touch to the documentation. Will link it once done. Even though we announced the framework readiness, all product integration tests should get migrated to this new version because test framework was all most rewritten and contain API changes. So this is more like a release focusing on WSO2 developer community rather product users. 2. Why is this pack (or some part of it) hosted in some location private to a developer (i.e. https://svn.wso2.org/repos/wso2/people/krishantha)? Note: I found this location through the docs, if that's wrong, please fix it. We decided not to release platform automated test suite until all integration tests and build problems get fixed. Will remove this link from old and new documents. Thanks, Krishantha. Thanks, Senaka. On Thu, Feb 13, 2014 at 6:20 PM, Dharshana Warusavitharana dharsha...@wso2.com wrote: WSO2 Test Automation Framework 4.3.0 is ready to be used. February 2014 WSO2 Test Automation Framework team is pleased to announce the internal release of version 4.3.0 of the framework. WSO2 Test Automation Framework (TAF) provides platform wide test automation facility. WSO2 Test Automation Framework is a Framework which enables to perform as a framework addressing the absence of a single framework which can perform equally in all stages of the development to deployment cycles of WSO2 products. WSO2 Test Automation Framework 4.3.0 will give you the flexibility of extending the framework capabilities through extensible support. And manage and execute test suite over the platform with different combinations and reuse existing test suites in different environments. This includes all of the extra integration and management functionality as well. WSO2 Test Automation Framework is an open source product available under the Apache Software License (v2.0)http://www.apache.org/licenses/LICENSE-2.0.html. Enhancements in WSO2 Test Automation Framework 4.3.0 - Introduction of lightweight automation engine. - Introduction of enhanced Automation Context API. - Ability to integrate third party products and platforms. - Native xpath based xml parsing implementation. - Introduction of single configuration file to manage all configurations. - Framework extensibility capability through pluggable modules. - Enhanced server management facility. - Enhanced User management capability. - Configuration file validator. - Introduction of enhanced code coverage through EMMA. - Enhanced support for cluster based platform wide test automation. Key Features - Platform wide Test execution support. - Simple Automation Context API. - TestNG listener based test execution. - REST backend support with JAX-RS services. - Embedded server support (FTP, Proxy server, JMS, ActiveMQ, HTTP Servers Axis2 Server). - Annotation based test execution management support. - Ability to execute same test on multiple environments. - Third party test tooling integration support (Jmeter) - Selenium webdriver integration and ability to run UI tests to cross browser environments. - Set of common test utilities to facilitate better test writing experience. Bugs Fixed and Feature implementation in This Release This release of WSO2 TAF comes with a number of bug fixes and feature implementation. All the issues which have been fixed in Test Framework 4.3.0 are recorded at following locations: - Fixed Test Framework specific issueshttps://wso2.org/jira/issues/?filter=11723 Reporting Problems - Issues can be reported using the Test Automation public JIRA available at https://wso2.org/jira/browse/TA SVN Repository - Test Framework Sourcehttps://svn.wso2.org/repos/wso2/carbon/platform/branches/turing/platform-integration/test-automation-framework-2/https://wso2.org/jira/browse/BPS Contact us WSO2 developers can be contacted via the mailing list: d...@wso2.org For details on subscriptions see http://wso2.org/mail https://wso2.org/jira/browse/TA-798?filter=11723 Discussion Forums Alternatively, questions could be raised on http://stackoverflow.comhttp://stackoverflow.com/questions/tagged/wso2 . Support We are committed to ensuring that your enterprise middleware deployment is completely supported from evaluation to production. Our unique approach ensures that all support leverages our open development methodology and is provided by the very same engineers who build the technology. For more details and to take advantage of this unique opportunity
Re: [Architecture] WSO2 Test Automation Framework 4.3.0 is ready to be used.
Hi Isuru, New framework has been added to chunk-08 poms. So anybody can build it and use as a dependency to their project. We are planning to do another more enhance user friendly release before Q1, which will have maven archetype to create test automation project, test framework distribution etc.. Thanks, Krishantha. On Mon, Feb 17, 2014 at 8:43 AM, Isuru Wimalasundera isu...@wso2.comwrote: Hi Krishantha/Dharshana When are we planning to make this released as a public release , for customers ? Regards Isuruw On Mon, Feb 17, 2014 at 1:00 AM, Krishantha Samaraweera krishan...@wso2.com wrote: Hi Senaka, On Sun, Feb 16, 2014 at 7:48 PM, Senaka Fernando sen...@wso2.com wrote: Hi Dharshana, First of all, congratulations on the 4.3.0 release. I got a few questions on TAF. 1. Can we link the documentation of TAF to this release note? We are doing final touch to the documentation. Will link it once done. Even though we announced the framework readiness, all product integration tests should get migrated to this new version because test framework was all most rewritten and contain API changes. So this is more like a release focusing on WSO2 developer community rather product users. 2. Why is this pack (or some part of it) hosted in some location private to a developer (i.e. https://svn.wso2.org/repos/wso2/people/krishantha)? Note: I found this location through the docs, if that's wrong, please fix it. We decided not to release platform automated test suite until all integration tests and build problems get fixed. Will remove this link from old and new documents. Thanks, Krishantha. Thanks, Senaka. On Thu, Feb 13, 2014 at 6:20 PM, Dharshana Warusavitharana dharsha...@wso2.com wrote: WSO2 Test Automation Framework 4.3.0 is ready to be used. February 2014 WSO2 Test Automation Framework team is pleased to announce the internal release of version 4.3.0 of the framework. WSO2 Test Automation Framework (TAF) provides platform wide test automation facility. WSO2 Test Automation Framework is a Framework which enables to perform as a framework addressing the absence of a single framework which can perform equally in all stages of the development to deployment cycles of WSO2 products. WSO2 Test Automation Framework 4.3.0 will give you the flexibility of extending the framework capabilities through extensible support. And manage and execute test suite over the platform with different combinations and reuse existing test suites in different environments. This includes all of the extra integration and management functionality as well. WSO2 Test Automation Framework is an open source product available under the Apache Software License (v2.0)http://www.apache.org/licenses/LICENSE-2.0.html. Enhancements in WSO2 Test Automation Framework 4.3.0 - Introduction of lightweight automation engine. - Introduction of enhanced Automation Context API. - Ability to integrate third party products and platforms. - Native xpath based xml parsing implementation. - Introduction of single configuration file to manage all configurations. - Framework extensibility capability through pluggable modules. - Enhanced server management facility. - Enhanced User management capability. - Configuration file validator. - Introduction of enhanced code coverage through EMMA. - Enhanced support for cluster based platform wide test automation. Key Features - Platform wide Test execution support. - Simple Automation Context API. - TestNG listener based test execution. - REST backend support with JAX-RS services. - Embedded server support (FTP, Proxy server, JMS, ActiveMQ, HTTP Servers Axis2 Server). - Annotation based test execution management support. - Ability to execute same test on multiple environments. - Third party test tooling integration support (Jmeter) - Selenium webdriver integration and ability to run UI tests to cross browser environments. - Set of common test utilities to facilitate better test writing experience. Bugs Fixed and Feature implementation in This Release This release of WSO2 TAF comes with a number of bug fixes and feature implementation. All the issues which have been fixed in Test Framework 4.3.0 are recorded at following locations: - Fixed Test Framework specific issueshttps://wso2.org/jira/issues/?filter=11723 Reporting Problems - Issues can be reported using the Test Automation public JIRA available at https://wso2.org/jira/browse/TA SVN Repository - Test Framework Sourcehttps://svn.wso2.org/repos/wso2/carbon/platform/branches/turing/platform-integration/test-automation-framework-2/https://wso2.org/jira/browse/BPS Contact us WSO2 developers can be contacted via the mailing list: d...@wso2
Re: [Architecture] Proposed code repository restructuring move to GitHub
As per the offline chat had with Azeez, We decided to migrate move service clients resided in Test Framework API to relevant service-stub modules. This will allow us to detect and fix the build breaks due to admin service api changes easily and eliminate test framework build breaks. And external users can directly use admin service clients resides in service-stub jars to invoke our backend admin services. Thanks, Krishantha. On Fri, Jan 17, 2014 at 9:26 PM, Afkham Azeez az...@wso2.com wrote: [Sorry for the very long mail. I want to document all that I had in mind the stuff we discussed. I would recommend all devs to take some time to read this] I would like to summarize he discussion we had a couple of days back. *The Problems* The problems we are trying to solve are as follows: 1. Trunk branches structures being completely different 2. Branches containing directories with version numbers 3. It is impossible to move to GitHub with the current structure because of #2 4. It is very easy to break the build by changing already released code. The room for human error is high. 5. Bamboo builds are eternally broken because the build fails at some point Bamboo cannot continue any further 6. When we branch, the trunk quickly becomes obsolete, and remains in that broken state until the next major platform release. 7. Everybody has to build all components/features, even if those are not related to their products 8. Fixed versions in branches instead of using SNAPSHOT versions. This makes it impossible to upload build artifacts to Maven/Nexus repos. This leads to #7. 9. Impossible to integrate code quality tools such as EraInsight because of #5 *Proposed solution* We have come up with the following solution after much deliberation thought. Rationale: We started looking at other open source projects out there. We took Axis2 as an example. Axis2 had many dependencies including Axiom, XmlSchema, Woden, WSS4J etc. Those 3rd party dependencies were also developed by some Axis2 contributors, but we never branched all of those together and brought them into the same code branch. We used to start what we used to call a release train, where the upstream code would have to be released first before the downstream code such as Axis2 Synapse could be released. This way, we never had any of the problems outlined above. If you look at the WSO2 product releases, again, the scenario is not that much different from the Axis2/Synapse releases. Components features are simply dependencies of the products. In order to get product releases out, we first need releases of those dependencies (components/features). So the proposal is to identify the top level components/features, and first release that code before doing product releases. Each of those components will have a GitHub repo. All active development will be done on the main branch of those components, and will be branched when they are close to the release. Instead of granting commit rights to all, we could only allow the primary developers of those components to commit, and others can send pull requests, which will be merged in by the primary owners after reviewing. These component teams could even have an internal Git repo or clone, and commit to that, run all tests, and when they are satisfied that the code is in a good state to be merged into the main branch, they can send a pull request merge the changes. We would run Bamboo which would build the components several times a day deploy them to the Nexus repo. That way, you would not have to build code that is not directly related to what you are working on, which would save 100s of valuable dev hours. In the majority of the cases, the P2 features correspond to one or more related components. So we would keep the feature close to the component. There are some cases where these components features belong in the product itself. AppFactory components are a good example. Products will also have their own GitHub repos. We will have separate GitHub repos for platform integration tests. Products such as API Manager may opt to have the API Management feature in the product itself. We would have a separate P2-repo GitHub repo which would build deploy the compatible set of P2 features. We will have Bamboo plans at multiple levels; components, products, platform, p2-repo and so on. We will not change any package structures at this time. We would defer that to Carbon 5 (if necessary). We will get rid of the chunk based release model. Continuous delivery is our ultimate aim for that to happen, we have to release a compatible set of features. We are going to rely heavily on automation, automated builds deploys to Maven. The developers will do the majority of the QA (just like the Apache Stratos team is doing now). We will use the Maven release plugin to create releases upload them to the Maven repo. *Implications to WSO2 code developers* 1
Re: [Architecture] [Dev] Developer Studio 3.3.0 Alpha 3 Released!
Hi Harshana, On Thu, Nov 21, 2013 at 2:37 PM, Harshana Martin harsh...@wso2.com wrote: Hi Samisa, On Thu, Nov 21, 2013 at 2:31 PM, Samisa Abeysinghe sam...@wso2.comwrote: Given there is no auto test help, to guard against slips, lets at least use a checklist of all mediators to be tested. Yes.. That's a good idea.. we did such cross check when we did DevS 3.0.0 release. So we will reuse the same set to make sure no slip ups. I was looking for auto tests, becuase, it is hard to test them all manually. Alternatively, we can see if we can use ESB auto tests in here, where we develop the artifacts for all mediators using DevS and test those artifacts with ESB auto test framework. That could work. Yes.. +1 We can produce CAR files with all mediator scenarios and provide them to ESB Testing Framework which could show us the error in configurations. Also once we are done with it, the same CAR files can be used for future ESB testing as well. When can we get CAR files to cover all mediators? we can add some base tests to cover deploy, undeploy and re-deployment of CAR files and allow ESB team to complete the rest. Thanks, Krishantha. We will execute that plan for the release. Thanks for the valuable input Samisa. Best Regards, Harshana Thanks, Samisa... Samisa Abeysinghe Vice President Training WSO2 Inc. http://wso2.com On Thu, Nov 21, 2013 at 2:27 PM, Harshana Martin harsh...@wso2.comwrote: Hi Samisa, On Thu, Nov 21, 2013 at 6:50 AM, Samisa Abeysinghe sam...@wso2.comwrote: What is the plan to test all mediators for basic functionality for 3.3.0? At the moment we are planning to test the mediators using the samples mainly and some known use cases. I understand that some mediators were badly broken in 3.2.0 release e.g. XACML. Although Entitlement mediator was a specific mediator only, we fixed but there could be some other mediators like that. So we are going to cover all most all mediators during the testing. Can we make use of the auto test framework to ensure that there are no absolute blockers in any mediator out of the full mediator lot. Test framework is still not developed to support that level of requirements. We will try to improve it while testing the 3.3.0. But most of the testing will happen manually for this release. We are planning to assign someone full-time basis to improve the test framework to support complete automated testing. Thanks and Regards, Harshana Thanks, Samisa... Samisa Abeysinghe Vice President Training WSO2 Inc. http://wso2.com On Mon, Nov 18, 2013 at 3:49 PM, Asanka Sanjeewa asan...@wso2.comwrote: Hi All, We have WSO2 Developer Studio 3.3.0 Alpha 3 version ready to be downloaded at [1]. Installed eclipse distributions available at [2]. This release includes following new feature, improvements and bug fixes. New Feature - [TOOLS-1855 https://wso2.org/jira/browse/TOOLS-1855] - Cloud connector support Improvements - [TOOLS-1870 https://wso2.org/jira/browse/TOOLS-1870] - Enabling Jaggery Editor Auto-Complete even without typing a character - [TOOLS-2085 https://wso2.org/jira/browse/TOOLS-2085] - There is no way to rename a GReg artifact. - [TOOLS-2106 https://wso2.org/jira/browse/TOOLS-2106] - Adding perspective login change icon into toolbar - [TOOLS-2107 https://wso2.org/jira/browse/TOOLS-2107] - Login window should not pop-up when resetting the perspective and should pop-up for new perspective Only Bug Fixes - [TOOLS-1337 https://wso2.org/jira/browse/TOOLS-1337] - There is no way to add include block inside Script Mediator - [TOOLS-1694 https://wso2.org/jira/browse/TOOLS-1694] - AF perspective detais view not filling all the feilds - [TOOLS-1719 https://wso2.org/jira/browse/TOOLS-1719] - [Dev Studio-3.2] - Logging not consistent with WSO2 Standards - [TOOLS-1722 https://wso2.org/jira/browse/TOOLS-1722] - Dev Studio fails to create Registry resource without file extension - [TOOLS-1731 https://wso2.org/jira/browse/TOOLS-1731] - Dev Studio fails to rename a resource correctly. - [TOOLS-1737 https://wso2.org/jira/browse/TOOLS-1737] - [Dev Studio 3.2] End Point Connection Issues - [TOOLS-1738 https://wso2.org/jira/browse/TOOLS-1738] - [Dev Studio 3.2] - Null Argument error for Clone Mediator - [TOOLS-1743 https://wso2.org/jira/browse/TOOLS-1743] - [Dev Studio 3.2] - Exceptions Creating EndPoint (JMS) - [TOOLS-1746 https://wso2.org/jira/browse/TOOLS-1746] - [Dev Studio-3.2] - Argument not valid Exception in Opening with Registry Info Editor - [TOOLS-1747 https://wso2.org/jira/browse/TOOLS-1747] - [Dev Studio-3.2] -Edit and saving resources to registy not possible - [TOOLS-1757 https://wso2.org/jira/browse/TOOLS-1757] - Create new Axis2 Service Project - wrong directory - [TOOLS-1945 https://wso2.org/jira/browse/TOOLS
Re: [Architecture] [Dev] [Jaggery] [Test] Test framework for jaggery
Functinalities like Server startup/shutdown, coverage generation and result generation already implemented in WSO2 Test Automation framework. So we need to reuse those functionalities in here. Having a Rest API to call tests scripts embedded in each jaggery app would be nice addition. In that way we could easily integrate it with our existing framework and use though out the platform. And this framework should support for continuous integration. So everything have to be executed without human interactions. So avoiding command line test runners etc.. is required. Thanks, Krishantha On Thu, Nov 14, 2013 at 11:02 PM, Madhuka Udantha madh...@wso2.com wrote: On Thu, Nov 14, 2013 at 5:14 PM, Udara Rathnayake uda...@wso2.com wrote: Hi all, While designing the test framework, its good if we can keep in mind that jaggery2 product also underway. Any thoughts? Sure, will think. Mainly test framework will coming for javascript(jag/js) testing so it will be written where can be extended. Regards, UdaraR On Thu, Nov 14, 2013 at 10:15 AM, Madhuka Udantha madh...@wso2.comwrote: Hi Krishantha and test automation team, I would like to get your opinion on this task regard to is there standard methodology on current testing framework where we can added such testing framework or better to go on fully independent model? My thinking is, - As it is application level testing frame work, better to work with much independent of the current system - Where application writer (developer) can run test for specific application rather running all test for platform or product - It will help to maintain both test framework with low cost - Each test frame have it's own scope (such as platform/product/appilcation). if not, complexity of the code and system will be increase but there will be API interface for interaction among the test framework. - And I thought to have interface (simple REST interface) in jaggery test frame work where current test framework also can interact with it into some extend. Thanks On Tue, Nov 12, 2013 at 5:57 PM, Madhuka Udantha madh...@wso2.comwrote: Hi, Still we do not have jaggery test framework even though there are considerable jaggery applications were developed. It is not easy maintain those jaggery applications/APIs steady without testing frame work. Now onward we will starting $subject as it is important for jaggery as well as there is no JS testing framework under WSO2 Platform. Testing framework will be under application level such as mocha, jasmine. Test frame will be apply to (basically)test. - jaggery API (js functions and arguments ) - REST APIs that are expose under jaggery application - With test coverage reporting We will be evaluating existing JavaScript test frame works regard mocha[1], jasmine[2], Qunit[3], Vows[4], expresso[5], nodeunit[6] and jsunit[7] to $subject. All suggestions are welcome. [1] http://visionmedia.github.io/mocha/ [2] http://pivotal.github.io/jasmine/ [3] http://qunitjs.com/ [4] http://vowsjs.org/ [5] http://visionmedia.github.io/expresso/ [6] https://github.com/caolan/nodeunit [7] https://github.com/pivotal/jsunit Thanks -- *Madhuka* Udantha Senior Software Engineer Development Technologies WSO2 Inc. : http://wso2.com *Mobile*: +94774066336 *Blog*: http://madhukaudantha.blogspot.com/ -- *Madhuka* Udantha Senior Software Engineer Development Technologies WSO2 Inc. : http://wso2.com *Mobile*: +94774066336 *Blog*: http://madhukaudantha.blogspot.com/ ___ Dev mailing list d...@wso2.org http://wso2.org/cgi-bin/mailman/listinfo/dev -- *Udara Rathnayake* Software Engineer WSO2 Inc. : http://wso2.com Mobile : +94 772207239 Twitter : http://twitter.com/udarakr Blog: http://udarakr.blogspot.com -- *Madhuka* Udantha Senior Software Engineer Development Technologies WSO2 Inc. : http://wso2.com *Mobile*: +94774066336 *Blog*: http://madhukaudantha.blogspot.com/ -- Krishantha Samaraweera Senior Technical Lead - Test Automation Mobile: +94 77 7759918 WSO2, Inc.; http://wso2.com/ lean . enterprise . middlewear. ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] [Test Automation] Feature installation via automation feamework
I think our feature management story isn't smooth yet. We need to sort out some of the problems before proceeding. 1. Which repository we should use for test automation - Lets take RC release, p2-repo is not released and not available online. So we have to depend on local repo. To do that p2 repo should be available at the time of product build. But repo is not included to build and depends on certain product features like product samples and styles. Thus, repo will not be available at the product build time. To solve this problem we we need to build the repo before integration tests by excluding all product level dependencies. 2. All features are not available in each release. So this trend to test failures in future. E.g - You cannot install XACML features on API Manager 1.4.0. IS was not released with Carbon 4.1.0, so the relevant feature not available. A possible solution would be to filter available features and skip tests based on feature availability. However you can start writing tests using online p2-repo (4.2.0) until we sort out above mentioned problematic areas. Thanks, Krishantha. On Mon, Sep 9, 2013 at 5:42 PM, Supun Malinga sup...@wso2.com wrote: Hi, great! thanks, On Mon, Sep 9, 2013 at 5:38 PM, Dharshana Warusavitharana dharsha...@wso2.com wrote: Hi Supun, Yes this feature is supported. But still you need to figure out how you will handle the repo location inside your test. you mean giving the relevant p2-repo url right?. In that case we can manage that at automation-framework level, since the repo is unique to each platform version. thanks, The automation API provides a client for installing features is FeatureManagementAdminServiceClienthttps://svn.wso2.org/repos/wso2/people/dharshana/automation/framework/test-automation-framework/org.wso2.carbon.automation.api/src/main/java/org/wso2/carbon/automation/api/clients/feature/mgt/FeatureManagementAdminServiceClient.java available on [1]. And sample test case to use it is available on [2]. [1]. https://svn.wso2.org/repos/wso2/people/dharshana/automation/framework/test-automation-framework/org.wso2.carbon.automation.api/src/main/java/org/wso2/carbon/automation/api/clients/feature/mgt/FeatureManagementAdminServiceClient.java [2]. https://svn.wso2.org/repos/wso2/people/dharshana/automation/esb-hackathon/esb/esb/4.7.0/modules/integration/tests/src/test/java/org/wso2/carbon/esb/hl7/transport/test/HL7TestCase.java Thank You, Dharshana. On Mon, Sep 9, 2013 at 5:33 PM, Supun Malinga sup...@wso2.com wrote: Hi All, Do we have support for this from the automation framework?. Since j2ee features are not shipped with AS by default, we would need to install j2ee features at integration tests to run j2ee tests. Can we get a sample test case if this is already available or we need add this as an improvement to the automation-framework. thanks, -- Supun Malinga, Senior Software Engineer, WSO2 Inc. http://wso2.com http://wso2.org email - sup...@wso2.com sup...@wso2.com mobile - 071 56 91 321 -- Dharshana Warusavitharana Senior Software Engineer , Test Automation WSO2 Inc. http://wso2.com email : dharsha...@wso2.com dharsha...@wso2.com Tel : +94 11 214 5345 94112145345 Fax :+94 11 2145300 cell : +94772202595 blog : http://dharshanaw.blogspot.com lean . enterprise . middleware -- Supun Malinga, Senior Software Engineer, WSO2 Inc. http://wso2.com http://wso2.org email - sup...@wso2.com sup...@wso2.com mobile - 071 56 91 321 ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
