[Dev] [Bamboo-Build] WSO2 Carbon 4.0.x - Nightly > Kernel_4.0.3 > #3 was SUCCESSFUL
--- WSO2 Carbon 4.0.x - Nightly > Kernel_4.0.3 > #3 was successful. --- This build was manually triggered by Maheshika Goonetilleke. http://wso2.org/bamboo/browse/WCB002-KER003-3/ -- This message is automatically generated by Atlassian Bamboo___ Dev mailing list Dev@wso2.org http://wso2.org/cgi-bin/mailman/listinfo/dev
[Dev] [Bamboo-Build] WSO2 Carbon 4.0.x > Platform 4.0.3 > #45 has FAILED. Change made by 6 authors.
--- WSO2 Carbon 4.0.x > Platform 4.0.3 > #45 failed. --- This build occurred because it is a dependant of WCB001-KER001-21. No failed tests found, a possible compilation error. http://wso2.org/bamboo/browse/WCB001-PLA001-45/ - Currently Responsible - No one is responsible for fixing this build. -- Failing Jobs -- - Default Job (Default Stage): 1005 tests passed. -- Code Changes -- asela (147051): >fix policy editor issues rajika (147047): >Fixed the manager build falire in a clean repo. Applied path by Reka >Thirunavukkarasu. asela (147042): >adding specific config files -- This message is automatically generated by Atlassian Bamboo___ Dev mailing list Dev@wso2.org http://wso2.org/cgi-bin/mailman/listinfo/dev
Re: [Dev] Best approach to fix https://wso2.org/jira/browse/REGISTRY-1378
Hi, So shall we adhere to that method? i.e using fullstops instead of spaces. ? (I tested with fullstops and it worked) Thanks On Thu, Nov 1, 2012 at 9:37 AM, Evanthika Amarasiri wrote: > Yes. We came across this issue while testing G-Reg 4.0.0 release and then > the solution given was to use fullstops instead of spaces. In fact, in > latest G-Reg packs, the default ServiceLifeCycle has a state in this > format. > > : > > > > class="org.wso2.carbon.governance.registry.extensions.executors.DemoteActionExecutor"> > > class="org.wso2.carbon.governance.registry.extensions.executors.apistore.ApiStoreExecutor"> > > > > > > > > > : > > Regards, > Evanthika > > > On Wed, Oct 31, 2012 at 11:36 PM, Janaka Ranabahu wrote: > >> Hi Shelan, >> >> Did you try defining the state ID by replacing all the whitespaces with >> '.' character. >> >> *Eg:- Ready For QA ==> Ready.For.QA* >> >> IIRC, it should show that correctly in the UI. Also IIRC, similar >> scenarios have been tested against lifecycles in past releases. Maybe QA >> folks can share more information on that. >> >> Thanks, >> Janaka >> >> >> On Wed, Oct 31, 2012 at 2:18 PM, Shelan Perera wrote: >> >>> Hi, >>> >>> For the issue [1] we cannot specify whitespaces in state ID. It is a >>> constraint added by SCXML and it gives an exception when it tries to parse. >>> According to this [2] release note they have mentioned >>> not to add white spaces in state IDs. A fix would be to add a temporary >>> element which will complaint with parsing and then again replace it with >>> white space. Is that approach clean enough to introduce? >>> >>> Thanks >>> >>> >>> [1] https://wso2.org/jira/browse/REGISTRY-1378 >>> >>> [2] >>> http://svn.apache.org/repos/asf/commons/proper/scxml/tags/SCXML_0_7/RELEASE-NOTES.txt >>> -- >>> *Shelan Perera* >>> >>> Software Engineer >>> ** >>> *WSO2, Inc. : wso2.com* >>> lean.enterprise.middleware. >>> >>> *Home Page* :shelan.org >>> *Blog* : blog.shelan.org >>> *Linked-i*n :http://www.linkedin.com/pub/shelan-perera/a/194/465 >>> *Twitter* :https://twitter.com/#!/shelan >>> >>> *Mobile* : +94 772 604 402 >>> >>> >>> >>> ___ >>> Dev mailing list >>> Dev@wso2.org >>> http://wso2.org/cgi-bin/mailman/listinfo/dev >>> >>> >> >> >> -- >> Janaka Ranabahu >> Software Engineer >> WSO2 Inc. >> >> Mobile +94 718370861 >> Email : jan...@wso2.com >> Blog : janakaranabahu.blogspot.com >> >> > -- *Shelan Perera* Software Engineer ** *WSO2, Inc. : wso2.com* lean.enterprise.middleware. *Home Page* :shelan.org *Blog* : blog.shelan.org *Linked-i*n :http://www.linkedin.com/pub/shelan-perera/a/194/465 *Twitter* :https://twitter.com/#!/shelan *Mobile* : +94 772 604 402 ___ Dev mailing list Dev@wso2.org http://wso2.org/cgi-bin/mailman/listinfo/dev
[Dev] [BUILD FAILED] WSO2 Carbon 4.0.x Platform_4.0.3 build #45
Hi All The Carbon Platform_4.0.3 has failed due to the below errors; 01-Nov-2012 02:31:48[INFO] 01-Nov-2012 02:31:48[INFO] BUILD FAILURE01-Nov-2012 02:31:48[INFO] 01-Nov-2012 02:31:48[INFO] Total time: 32:53.358s01-Nov-2012 02:31:48[INFO] Finished at: Thu Nov 01 02:31:47 PDT 201201-Nov-2012 02:31:59[INFO] Final Memory: 1427M/2662M01-Nov-2012 02:31:59[INFO] 01-Nov-2012 02:31:59[ERROR] Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:2.3.2:compile (default-compile) on project org.wso2.carbon.mediator.bam: Compilation failure: Compilation failure:01-Nov-2012 02:31:59[ERROR] /home/bamboo/Bamboo-3.4/source-repository/build-dir/WCB001-PLA001-JOB1/components/mediators/bam/org.wso2.carbon.mediator.bam/4.0.3/src/main/java/org/wso2/carbon/mediator/bam/Stream.java:[34,44] package org.wso2.carbon.mediator.bam.builders does not exist01-Nov-2012 02:31:59[ERROR] /home/bamboo/Bamboo-3.4/source-repository/build-dir/WCB001-PLA001-JOB1/components/mediators/bam/org.wso2.carbon.mediator.bam/4.0.3/src/main/java/org/wso2/carbon/mediator/bam/Stream.java:[35,44] package org.wso2.carbon.mediator.bam.builders does not exist01-Nov-2012 02:31:59[ERROR] /home/bamboo/Bamboo-3.4/source-repository/build-dir/WCB001-PLA001-JOB1/components/mediators/bam/org.wso2.carbon.mediator.bam/4.0.3/src/main/java/org/wso2/carbon/mediator/bam/Stream.java:[36,44] package org.wso2.carbon.mediator.bam.builders does not exist01-Nov-2012 02:31:59[ERROR] /home/bamboo/Bamboo-3.4/source-repository/build-dir/WCB001-PLA001-JOB1/components/mediators/bam/org.wso2.carbon.mediator.bam/4.0.3/src/main/java/org/wso2/carbon/mediator/bam/Stream.java:[51,12] cannot find symbol01-Nov-2012 02:31:59[ERROR] symbol : class PayloadDataBuilder01-Nov-2012 02:31:59[ERROR] location: class org.wso2.carbon.mediator.bam.Stream01-Nov-2012 02:31:59[ERROR] /home/bamboo/Bamboo-3.4/source-repository/build-dir/WCB001-PLA001-JOB1/components/mediators/bam/org.wso2.carbon.mediator.bam/4.0.3/src/main/java/org/wso2/carbon/mediator/bam/Stream.java:[52,12] cannot find symbol01-Nov-2012 02:31:59[ERROR] symbol : class MetaDataBuilder01-Nov-2012 02:31:59[ERROR] location: class org.wso2.carbon.mediator.bam.Stream01-Nov-2012 02:31:59[ERROR] /home/bamboo/Bamboo-3.4/source-repository/build-dir/WCB001-PLA001-JOB1/components/mediators/bam/org.wso2.carbon.mediator.bam/4.0.3/src/main/java/org/wso2/carbon/mediator/bam/Stream.java:[53,12] cannot find symbol01-Nov-2012 02:31:59[ERROR] symbol : class CorrelationDataBuilder01-Nov-2012 02:31:59[ERROR] location: class org.wso2.carbon.mediator.bam.Stream01-Nov-2012 02:31:59[ERROR] /home/bamboo/Bamboo-3.4/source-repository/build-dir/WCB001-PLA001-JOB1/components/mediators/bam/org.wso2.carbon.mediator.bam/4.0.3/src/main/java/org/wso2/carbon/mediator/bam/Stream.java:[34,44] package org.wso2.carbon.mediator.bam.builders does not exist01-Nov-2012 02:31:59[ERROR] /home/bamboo/Bamboo-3.4/source-repository/build-dir/WCB001-PLA001-JOB1/components/mediators/bam/org.wso2.carbon.mediator.bam/4.0.3/src/main/java/org/wso2/carbon/mediator/bam/Stream.java:[35,44] package org.wso2.carbon.mediator.bam.builders does not exist01-Nov-2012 02:31:59[ERROR] /home/bamboo/Bamboo-3.4/source-repository/build-dir/WCB001-PLA001-JOB1/components/mediators/bam/org.wso2.carbon.mediator.bam/4.0.3/src/main/java/org/wso2/carbon/mediator/bam/Stream.java:[36,44] package org.wso2.carbon.mediator.bam.builders does not exist01-Nov-2012 02:31:59[ERROR] /home/bamboo/Bamboo-3.4/source-repository/build-dir/WCB001-PLA001-JOB1/components/mediators/bam/org.wso2.carbon.mediator.bam/4.0.3/src/main/java/org/wso2/carbon/mediator/bam/Stream.java:[51,12] cannot find symbol01-Nov-2012 02:31:59[ERROR] symbol : class PayloadDataBuilder01-Nov-2012 02:31:59[ERROR] location: class org.wso2.carbon.mediator.bam.Stream01-Nov-2012 02:31:59[ERROR] /home/bamboo/Bamboo-3.4/source-repository/build-dir/WCB001-PLA001-JOB1/components/mediators/bam/org.wso2.carbon.mediator.bam/4.0.3/src/main/java/org/wso2/carbon/mediator/bam/Stream.java:[52,12] cannot find symbol01-Nov-2012 02:31:59[ERROR] symbol : class MetaDataBuilder01-Nov-2012 02:31:59[ERROR] location: class org.wso2.carbon.mediator.bam.Stream01-Nov-2012 02:31:59[ERROR] /home/bamboo/Bamboo-3.4/source-repository/build-dir/WCB001-PLA001-JOB1/components/mediators/bam/org.wso2.carbon.mediator.bam/4.0.3/src/main/java/org/wso2/carbon/mediator/bam/Stream.java:[53,12] cannot find symbol01-Nov-2012 02:31:59[ERROR] symbol : class CorrelationDataBuilder01-Nov-2012 02:31:59[ERROR] location: class org.wso2.carbon.mediator.bam.Stream01-Nov-2012 02:31:59[ERROR] /home/bamboo/Bamboo-3.4/source-repository/build-dir/WCB001-PLA001-JOB1/components/mediators/bam/org.wso2.carbon.mediator.bam/4.0.3/src/main/java/org/wso2/carbon/mediator/bam/Stream.java:[60,33] cannot f
Re: [Dev] [BUILD FAILED] WSO2 Carbon 4.0.x Platform_4.0.3 build #45
This was fixed a while ago. Should build with a SVN up inside components/mediators/bam. Regards Buddhika On Thu, Nov 1, 2012 at 3:39 PM, Maheshika Goonetilleke wrote: > Hi All > > The Carbon Platform_4.0.3 has failed due to the below errors; > > 01-Nov-2012 02:31:48 [INFO] > 01-Nov-2012 > 02:31:48 [INFO] BUILD FAILURE 01-Nov-2012 02:31:48[INFO] > > 01-Nov-2012 > 02:31:48 [INFO] Total time: 32:53.358s01-Nov-2012 02:31:48 [INFO] > Finished at: Thu Nov 01 02:31:47 PDT 201201-Nov-2012 02:31:59 [INFO] > Final Memory: 1427M/2662M01-Nov-2012 02:31:59 [INFO] > 01-Nov-2012 > 02:31:59 [ERROR] Failed to execute goal > org.apache.maven.plugins:maven-compiler-plugin:2.3.2:compile > (default-compile) on project org.wso2.carbon.mediator.bam: Compilation > failure: Compilation failure: 01-Nov-2012 02:31:59 [ERROR] > /home/bamboo/Bamboo-3.4/source-repository/build-dir/WCB001-PLA001-JOB1/components/mediators/bam/org.wso2.carbon.mediator.bam/4.0.3/src/main/java/org/wso2/carbon/mediator/bam/Stream.java:[34,44] > package org.wso2.carbon.mediator.bam.builders does not exist 01-Nov-2012 > 02:31:59 [ERROR] > /home/bamboo/Bamboo-3.4/source-repository/build-dir/WCB001-PLA001-JOB1/components/mediators/bam/org.wso2.carbon.mediator.bam/4.0.3/src/main/java/org/wso2/carbon/mediator/bam/Stream.java:[35,44] > package org.wso2.carbon.mediator.bam.builders does not exist 01-Nov-2012 > 02:31:59 [ERROR] > /home/bamboo/Bamboo-3.4/source-repository/build-dir/WCB001-PLA001-JOB1/components/mediators/bam/org.wso2.carbon.mediator.bam/4.0.3/src/main/java/org/wso2/carbon/mediator/bam/Stream.java:[36,44] > package org.wso2.carbon.mediator.bam.builders does not exist 01-Nov-2012 > 02:31:59 [ERROR] > /home/bamboo/Bamboo-3.4/source-repository/build-dir/WCB001-PLA001-JOB1/components/mediators/bam/org.wso2.carbon.mediator.bam/4.0.3/src/main/java/org/wso2/carbon/mediator/bam/Stream.java:[51,12] > cannot find symbol 01-Nov-2012 02:31:59 [ERROR] symbol : class > PayloadDataBuilder01-Nov-2012 02:31:59 [ERROR] location: class > org.wso2.carbon.mediator.bam.Stream01-Nov-2012 02:31:59 [ERROR] > /home/bamboo/Bamboo-3.4/source-repository/build-dir/WCB001-PLA001-JOB1/components/mediators/bam/org.wso2.carbon.mediator.bam/4.0.3/src/main/java/org/wso2/carbon/mediator/bam/Stream.java:[52,12] > cannot find symbol 01-Nov-2012 02:31:59 [ERROR] symbol : class > MetaDataBuilder01-Nov-2012 02:31:59 [ERROR] location: class > org.wso2.carbon.mediator.bam.Stream01-Nov-2012 02:31:59 [ERROR] > /home/bamboo/Bamboo-3.4/source-repository/build-dir/WCB001-PLA001-JOB1/components/mediators/bam/org.wso2.carbon.mediator.bam/4.0.3/src/main/java/org/wso2/carbon/mediator/bam/Stream.java:[53,12] > cannot find symbol 01-Nov-2012 02:31:59 [ERROR] symbol : class > CorrelationDataBuilder01-Nov-2012 02:31:59 [ERROR] location: class > org.wso2.carbon.mediator.bam.Stream01-Nov-2012 02:31:59 [ERROR] > /home/bamboo/Bamboo-3.4/source-repository/build-dir/WCB001-PLA001-JOB1/components/mediators/bam/org.wso2.carbon.mediator.bam/4.0.3/src/main/java/org/wso2/carbon/mediator/bam/Stream.java:[34,44] > package org.wso2.carbon.mediator.bam.builders does not exist 01-Nov-2012 > 02:31:59 [ERROR] > /home/bamboo/Bamboo-3.4/source-repository/build-dir/WCB001-PLA001-JOB1/components/mediators/bam/org.wso2.carbon.mediator.bam/4.0.3/src/main/java/org/wso2/carbon/mediator/bam/Stream.java:[35,44] > package org.wso2.carbon.mediator.bam.builders does not exist 01-Nov-2012 > 02:31:59 [ERROR] > /home/bamboo/Bamboo-3.4/source-repository/build-dir/WCB001-PLA001-JOB1/components/mediators/bam/org.wso2.carbon.mediator.bam/4.0.3/src/main/java/org/wso2/carbon/mediator/bam/Stream.java:[36,44] > package org.wso2.carbon.mediator.bam.builders does not exist 01-Nov-2012 > 02:31:59 [ERROR] > /home/bamboo/Bamboo-3.4/source-repository/build-dir/WCB001-PLA001-JOB1/components/mediators/bam/org.wso2.carbon.mediator.bam/4.0.3/src/main/java/org/wso2/carbon/mediator/bam/Stream.java:[51,12] > cannot find symbol 01-Nov-2012 02:31:59 [ERROR] symbol : class > PayloadDataBuilder01-Nov-2012 02:31:59 [ERROR] location: class > org.wso2.carbon.mediator.bam.Stream01-Nov-2012 02:31:59 [ERROR] > /home/bamboo/Bamboo-3.4/source-repository/build-dir/WCB001-PLA001-JOB1/components/mediators/bam/org.wso2.carbon.mediator.bam/4.0.3/src/main/java/org/wso2/carbon/mediator/bam/Stream.java:[52,12] > cannot find symbol 01-Nov-2012 02:31:59 [ERROR] symbol : class > MetaDataBuilder01-Nov-2012 02:31:59 [ERROR] location: class > org.wso2.carbon.mediator.bam.Stream01-Nov-2012 02:31:59 [ERROR] > /home/bamboo/Bamboo-3.4/source-repository/build-dir/WCB001-PLA001-JOB1/components/mediators/bam/org.wso2.carbon.mediator.bam/4.0.3/src/main/java/org/wso2/carbon/mediator/bam/Stream.java:[53,12] > cannot find symbol 01-Nov-2012 02:31:59 [ERROR] symbol : class > C
Re: [Dev] [BUILD FAILED] WSO2 Carbon 4.0.x Platform_4.0.3 build #45
This is already fixed. Rajika On Thu, Nov 1, 2012 at 3:39 PM, Maheshika Goonetilleke wrote: > Hi All > > The Carbon Platform_4.0.3 has failed due to the below errors; > > 01-Nov-2012 02:31:48 [INFO] > 01-Nov-2012 > 02:31:48 [INFO] BUILD FAILURE 01-Nov-2012 02:31:48[INFO] > > 01-Nov-2012 > 02:31:48 [INFO] Total time: 32:53.358s01-Nov-2012 02:31:48 [INFO] > Finished at: Thu Nov 01 02:31:47 PDT 201201-Nov-2012 02:31:59 [INFO] > Final Memory: 1427M/2662M01-Nov-2012 02:31:59 [INFO] > 01-Nov-2012 > 02:31:59 [ERROR] Failed to execute goal > org.apache.maven.plugins:maven-compiler-plugin:2.3.2:compile > (default-compile) on project org.wso2.carbon.mediator.bam: Compilation > failure: Compilation failure: 01-Nov-2012 02:31:59 [ERROR] > /home/bamboo/Bamboo-3.4/source-repository/build-dir/WCB001-PLA001-JOB1/components/mediators/bam/org.wso2.carbon.mediator.bam/4.0.3/src/main/java/org/wso2/carbon/mediator/bam/Stream.java:[34,44] > package org.wso2.carbon.mediator.bam.builders does not exist 01-Nov-2012 > 02:31:59 [ERROR] > /home/bamboo/Bamboo-3.4/source-repository/build-dir/WCB001-PLA001-JOB1/components/mediators/bam/org.wso2.carbon.mediator.bam/4.0.3/src/main/java/org/wso2/carbon/mediator/bam/Stream.java:[35,44] > package org.wso2.carbon.mediator.bam.builders does not exist 01-Nov-2012 > 02:31:59 [ERROR] > /home/bamboo/Bamboo-3.4/source-repository/build-dir/WCB001-PLA001-JOB1/components/mediators/bam/org.wso2.carbon.mediator.bam/4.0.3/src/main/java/org/wso2/carbon/mediator/bam/Stream.java:[36,44] > package org.wso2.carbon.mediator.bam.builders does not exist 01-Nov-2012 > 02:31:59 [ERROR] > /home/bamboo/Bamboo-3.4/source-repository/build-dir/WCB001-PLA001-JOB1/components/mediators/bam/org.wso2.carbon.mediator.bam/4.0.3/src/main/java/org/wso2/carbon/mediator/bam/Stream.java:[51,12] > cannot find symbol 01-Nov-2012 02:31:59 [ERROR] symbol : class > PayloadDataBuilder01-Nov-2012 02:31:59 [ERROR] location: class > org.wso2.carbon.mediator.bam.Stream01-Nov-2012 02:31:59 [ERROR] > /home/bamboo/Bamboo-3.4/source-repository/build-dir/WCB001-PLA001-JOB1/components/mediators/bam/org.wso2.carbon.mediator.bam/4.0.3/src/main/java/org/wso2/carbon/mediator/bam/Stream.java:[52,12] > cannot find symbol 01-Nov-2012 02:31:59 [ERROR] symbol : class > MetaDataBuilder01-Nov-2012 02:31:59 [ERROR] location: class > org.wso2.carbon.mediator.bam.Stream01-Nov-2012 02:31:59 [ERROR] > /home/bamboo/Bamboo-3.4/source-repository/build-dir/WCB001-PLA001-JOB1/components/mediators/bam/org.wso2.carbon.mediator.bam/4.0.3/src/main/java/org/wso2/carbon/mediator/bam/Stream.java:[53,12] > cannot find symbol 01-Nov-2012 02:31:59 [ERROR] symbol : class > CorrelationDataBuilder01-Nov-2012 02:31:59 [ERROR] location: class > org.wso2.carbon.mediator.bam.Stream01-Nov-2012 02:31:59 [ERROR] > /home/bamboo/Bamboo-3.4/source-repository/build-dir/WCB001-PLA001-JOB1/components/mediators/bam/org.wso2.carbon.mediator.bam/4.0.3/src/main/java/org/wso2/carbon/mediator/bam/Stream.java:[34,44] > package org.wso2.carbon.mediator.bam.builders does not exist 01-Nov-2012 > 02:31:59 [ERROR] > /home/bamboo/Bamboo-3.4/source-repository/build-dir/WCB001-PLA001-JOB1/components/mediators/bam/org.wso2.carbon.mediator.bam/4.0.3/src/main/java/org/wso2/carbon/mediator/bam/Stream.java:[35,44] > package org.wso2.carbon.mediator.bam.builders does not exist 01-Nov-2012 > 02:31:59 [ERROR] > /home/bamboo/Bamboo-3.4/source-repository/build-dir/WCB001-PLA001-JOB1/components/mediators/bam/org.wso2.carbon.mediator.bam/4.0.3/src/main/java/org/wso2/carbon/mediator/bam/Stream.java:[36,44] > package org.wso2.carbon.mediator.bam.builders does not exist 01-Nov-2012 > 02:31:59 [ERROR] > /home/bamboo/Bamboo-3.4/source-repository/build-dir/WCB001-PLA001-JOB1/components/mediators/bam/org.wso2.carbon.mediator.bam/4.0.3/src/main/java/org/wso2/carbon/mediator/bam/Stream.java:[51,12] > cannot find symbol 01-Nov-2012 02:31:59 [ERROR] symbol : class > PayloadDataBuilder01-Nov-2012 02:31:59 [ERROR] location: class > org.wso2.carbon.mediator.bam.Stream01-Nov-2012 02:31:59 [ERROR] > /home/bamboo/Bamboo-3.4/source-repository/build-dir/WCB001-PLA001-JOB1/components/mediators/bam/org.wso2.carbon.mediator.bam/4.0.3/src/main/java/org/wso2/carbon/mediator/bam/Stream.java:[52,12] > cannot find symbol 01-Nov-2012 02:31:59 [ERROR] symbol : class > MetaDataBuilder01-Nov-2012 02:31:59 [ERROR] location: class > org.wso2.carbon.mediator.bam.Stream01-Nov-2012 02:31:59 [ERROR] > /home/bamboo/Bamboo-3.4/source-repository/build-dir/WCB001-PLA001-JOB1/components/mediators/bam/org.wso2.carbon.mediator.bam/4.0.3/src/main/java/org/wso2/carbon/mediator/bam/Stream.java:[53,12] > cannot find symbol 01-Nov-2012 02:31:59 [ERROR] symbol : class > CorrelationDataBuilder01-Nov-2012 02:31:59 [ERROR] location: class > org.wso
[Dev] [Bamboo-Build] WSO2 Carbon 4.0.x - Nightly > Platform_4.0.3 > #4 has FAILED (5 tests failed). Change made by 7 authors.
--- WSO2 Carbon 4.0.x - Nightly > Platform_4.0.3 > #4 failed. --- This build was manually triggered by Maheshika Goonetilleke. 5/978 tests failed. http://wso2.org/bamboo/browse/WCB002-PLA003-4/ - Currently Responsible - No one is responsible for fixing this build. -- Failing Jobs -- - Default Job (Default Stage): 5 of 978 tests failed. -- Code Changes -- ajithn (147110): >add DBTokenStore as default TokenStoreClass rajika (147117): >Fixed p2 profile. Added patches by Hasitha Hiranya. deep (147100): >updated logging mgt to 4.0.3 and added ntask > -- Tests -- New Test Failures (5) - EndpointTest: Service adding endpoints with wsdl - EndpointTest: Add wsdl with endpoints - ServiceTest: Service attachments - ServiceTest: Service search - WSDLTest: Add w s d l -- This message is automatically generated by Atlassian Bamboo___ Dev mailing list Dev@wso2.org http://wso2.org/cgi-bin/mailman/listinfo/dev
[Dev] [Bamboo-Build] WSO2 Carbon 4.0.x > Platform 4.0.3 > #46 was SUCCESSFUL (with 1005 tests). Change made by 8 authors.
--- WSO2 Carbon 4.0.x > Platform 4.0.3 > #46 was successful. --- This build occurred because it is a dependant of WCB001-KER001-22. 1005 tests in total. http://wso2.org/bamboo/browse/WCB001-PLA001-46/ -- Code Changes -- ajithn (147110): >add DBTokenStore as default TokenStoreClass ajithn (147108): >add 4.0.3 bundle > rajika (147102): >Fixed the feature build issue. -- This message is automatically generated by Atlassian Bamboo___ Dev mailing list Dev@wso2.org http://wso2.org/cgi-bin/mailman/listinfo/dev
[Dev] [GReg] Provide only delete option for installed RXT types
Hi, This is regarding when GReg provides a UI to upload RXTs and also list them. Shall we have $subject ? Because if we provide edit options for an already installed RXT, once the RXT config is updated, already created RXT instances out of the old one becomes staled. And you cannot expect the new behavior from the old instances (users might not able to identify the old ones explicitly) . In that context I feel it is an invalid use case. This can be considered when we support development time governance. So shall we do $subject ? Subash Chaturanga Software Engineer WSO2 Inc. http://wso2.com email - sub...@wso2.com phone - 077 2225922 ___ Dev mailing list Dev@wso2.org http://wso2.org/cgi-bin/mailman/listinfo/dev
[Dev] IS 4.0.0 RC and 4.0.3 release artifacts
Please find the IS 4.0.0 RC and the other 4.0.3 release artifacts below. http://builder3.us1.wso2.org/builds/01-11-2012-r147123/ These were built with a clean repo with test enabled from the revision 147123. Please smoke test these pack for any issues. If no major issues found these will be the final release artifacts. Rajika ___ Dev mailing list Dev@wso2.org http://wso2.org/cgi-bin/mailman/listinfo/dev
Re: [Dev] IS 4.0.0 RC and 4.0.3 release artifacts
OAuth 1.0, 2.0 is working On Thu, Nov 1, 2012 at 9:55 PM, Rajika Kumarasiri wrote: > Please find the IS 4.0.0 RC and the other 4.0.3 release artifacts below. > > http://builder3.us1.wso2.org/builds/01-11-2012-r147123/ > > These were built with a clean repo with test enabled from the revision > 147123. Please smoke test these pack for any issues. If no major issues > found these will be the final release artifacts. > > Rajika > > ___ > Dev mailing list > Dev@wso2.org > http://wso2.org/cgi-bin/mailman/listinfo/dev > > -- Thanks, Dinuka Malalanayake ___ Dev mailing list Dev@wso2.org http://wso2.org/cgi-bin/mailman/listinfo/dev
Re: [Dev] [GReg] Provide only delete option for installed RXT types
Hi Subash, On Thu, Nov 1, 2012 at 9:18 PM, Subash Chaturanga wrote: > Hi, > This is regarding when GReg provides a UI to upload RXTs and also list > them. Shall we have $subject ? Because if we provide edit options for an > already installed RXT, once the RXT config is updated, already created RXT > instances out of the old one becomes staled. And you cannot expect the new > behavior from the old instances (users might not able to identify the old > ones explicitly) . In that context I feel it is an invalid use case. > > This can be considered when we support development time governance. > So shall we do $subject ? > +1. Since we use have the validations for RXTs when uploading, we should have the feeling that there are no error in the configuration. So I guess there is no point in updating a RXT other than to do a content (artifact content) change which can be done by changing the configuration (Configure tab). So there are less or no usecase in changing the RXT. thanks Eranda * * ___ Dev mailing list Dev@wso2.org http://wso2.org/cgi-bin/mailman/listinfo/dev
Re: [Dev] IS 4.0.0 RC and 4.0.3 release artifacts
Passive STS having some problem in this pack https://wso2.org/jira/browse/IDENTITY-563 On Thu, Nov 1, 2012 at 10:18 PM, Dinuka Malalanayake wrote: > OAuth 1.0, 2.0 is working > > > On Thu, Nov 1, 2012 at 9:55 PM, Rajika Kumarasiri wrote: > >> Please find the IS 4.0.0 RC and the other 4.0.3 release artifacts below. >> >> http://builder3.us1.wso2.org/builds/01-11-2012-r147123/ >> >> These were built with a clean repo with test enabled from the revision >> 147123. Please smoke test these pack for any issues. If no major issues >> found these will be the final release artifacts. >> >> Rajika >> >> ___ >> Dev mailing list >> Dev@wso2.org >> http://wso2.org/cgi-bin/mailman/listinfo/dev >> >> > > > -- > Thanks, > Dinuka Malalanayake > > > -- Thanks, Dinuka Malalanayake ___ Dev mailing list Dev@wso2.org http://wso2.org/cgi-bin/mailman/listinfo/dev
Re: [Dev] [GReg] Provide only delete option for installed RXT types
Hi Subash, Hold on, there are multiple angles to this. You've just pointed out one, but there are several other things one might try to do. For example, 1. someone might want to create a copy from an existing RXT and create a new one. Some people actually do this even today. For them, edit is not required, but being able to view the existing RXT is. (note: in the LC UI, view and edit are both a single interface). 2. another user might try to make changes to the columns in a list UI, but not actually change the layout of the add/edit view. Asking someone to delete and add again is not the best answer. So, for #1, view is required and for #2 a partial edit is required. We also have a #3, which Eranda pointed out (i.e. being able to reconfigure the layout of the add/edit view). #3 can actually be done through the configure UI, but one could ask, why don't we have a complete edit instead of a partial edit, and get rid of the separate configure UI. This would make services and RXTs inconsistent, but then again, we can convert service to be represented using an RXT too. So, I'd like to suggest that we reconsider this decision and understand the problem end-to-end and find a proper lasting solution, without attempting a quick fix. Thanks, Senaka. On Thu, Nov 1, 2012 at 10:24 PM, Eranda Sooriyabandara wrote: > Hi Subash, > > > On Thu, Nov 1, 2012 at 9:18 PM, Subash Chaturanga wrote: > >> Hi, >> This is regarding when GReg provides a UI to upload RXTs and also list >> them. Shall we have $subject ? Because if we provide edit options for an >> already installed RXT, once the RXT config is updated, already created RXT >> instances out of the old one becomes staled. And you cannot expect the new >> behavior from the old instances (users might not able to identify the old >> ones explicitly) . In that context I feel it is an invalid use case. >> >> This can be considered when we support development time governance. >> So shall we do $subject ? >> > > +1. Since we use have the validations for RXTs when uploading, we should > have the feeling that there are no error in the configuration. So I guess > there is no point in updating a RXT other than to do a content (artifact > content) change which can be done by changing the configuration (Configure > tab). So there are less or no usecase in changing the RXT. > > thanks > Eranda > > * > * > > -- *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 ___ Dev mailing list Dev@wso2.org http://wso2.org/cgi-bin/mailman/listinfo/dev
[Dev] [Bamboo-Build] WSO2 Carbon 4.0.x > Products 4.0.3 > #16 was SUCCESSFUL (with 58 tests). Change made by 10 authors.
--- WSO2 Carbon 4.0.x > Products 4.0.3 > #16 was successful. --- This build occurred because it is a dependant of WCB001-PLA001-47. 58 tests in total. http://wso2.org/bamboo/browse/WCB001-PRO001-16/ -- Code Changes -- asela (147023): >fixing caching issues ajithn (147108): >add 4.0.3 bundle > lalaji (147040): >Added breadcumb and left menu for revokeToken page -- This message is automatically generated by Atlassian Bamboo___ Dev mailing list Dev@wso2.org http://wso2.org/cgi-bin/mailman/listinfo/dev
Re: [Dev] [GReg] Provide only delete option for installed RXT types
+1 for providing a view option in addition. So what is the conclusion ? On Thu, Nov 1, 2012 at 11:21 PM, Senaka Fernando wrote: > Hi Subash, > > Hold on, there are multiple angles to this. You've just pointed out one, > but there are several other things one might try to do. For example, > > 1. someone might want to create a copy from an existing RXT and create a > new one. Some people actually do this even today. For them, edit is not > required, but being able to view the existing RXT is. (note: in the LC UI, > view and edit are both a single interface). > > 2. another user might try to make changes to the columns in a list UI, but > not actually change the layout of the add/edit view. Asking someone to > delete and add again is not the best answer. > > So, for #1, view is required and for #2 a partial edit is required. We > also have a #3, which Eranda pointed out (i.e. being able to reconfigure > the layout of the add/edit view). #3 can actually be done through the > configure UI, but one could ask, why don't we have a complete edit instead > of a partial edit, and get rid of the separate configure UI. This would > make services and RXTs inconsistent, but then again, we can convert service > to be represented using an RXT too. > > So, I'd like to suggest that we reconsider this decision and understand > the problem end-to-end and find a proper lasting solution, without > attempting a quick fix. > > Thanks, > Senaka. > > On Thu, Nov 1, 2012 at 10:24 PM, Eranda Sooriyabandara wrote: > >> Hi Subash, >> >> >> On Thu, Nov 1, 2012 at 9:18 PM, Subash Chaturanga wrote: >> >>> Hi, >>> This is regarding when GReg provides a UI to upload RXTs and also list >>> them. Shall we have $subject ? Because if we provide edit options for an >>> already installed RXT, once the RXT config is updated, already created RXT >>> instances out of the old one becomes staled. And you cannot expect the new >>> behavior from the old instances (users might not able to identify the old >>> ones explicitly) . In that context I feel it is an invalid use case. >>> >>> This can be considered when we support development time governance. >>> So shall we do $subject ? >>> >> >> +1. Since we use have the validations for RXTs when uploading, we should >> have the feeling that there are no error in the configuration. So I guess >> there is no point in updating a RXT other than to do a content (artifact >> content) change which can be done by changing the configuration (Configure >> tab). So there are less or no usecase in changing the RXT. >> >> thanks >> Eranda >> >> * >> * >> >> > > > -- > *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 - sub...@wso2.com phone - 077 2225922 ___ Dev mailing list Dev@wso2.org http://wso2.org/cgi-bin/mailman/listinfo/dev
Re: [Dev] [GReg] Provide only delete option for installed RXT types
Looking at these use cases, I would imagine that we have to have an LC like listing of RXT types under config tab, rather than having them listed individually in there - in other words, one-stop-shop view to help with these actions. On Thu, Nov 1, 2012 at 11:21 PM, Senaka Fernando wrote: > Hi Subash, > > Hold on, there are multiple angles to this. You've just pointed out one, > but there are several other things one might try to do. For example, > > 1. someone might want to create a copy from an existing RXT and create a > new one. Some people actually do this even today. For them, edit is not > required, but being able to view the existing RXT is. (note: in the LC UI, > view and edit are both a single interface). > > 2. another user might try to make changes to the columns in a list UI, but > not actually change the layout of the add/edit view. Asking someone to > delete and add again is not the best answer. > > So, for #1, view is required and for #2 a partial edit is required. We > also have a #3, which Eranda pointed out (i.e. being able to reconfigure > the layout of the add/edit view). #3 can actually be done through the > configure UI, but one could ask, why don't we have a complete edit instead > of a partial edit, and get rid of the separate configure UI. This would > make services and RXTs inconsistent, but then again, we can convert service > to be represented using an RXT too. > > So, I'd like to suggest that we reconsider this decision and understand > the problem end-to-end and find a proper lasting solution, without > attempting a quick fix. > > Thanks, > Senaka. > > On Thu, Nov 1, 2012 at 10:24 PM, Eranda Sooriyabandara wrote: > >> Hi Subash, >> >> >> On Thu, Nov 1, 2012 at 9:18 PM, Subash Chaturanga wrote: >> >>> Hi, >>> This is regarding when GReg provides a UI to upload RXTs and also list >>> them. Shall we have $subject ? Because if we provide edit options for an >>> already installed RXT, once the RXT config is updated, already created RXT >>> instances out of the old one becomes staled. And you cannot expect the new >>> behavior from the old instances (users might not able to identify the old >>> ones explicitly) . In that context I feel it is an invalid use case. >>> >>> This can be considered when we support development time governance. >>> So shall we do $subject ? >>> >> >> +1. Since we use have the validations for RXTs when uploading, we should >> have the feeling that there are no error in the configuration. So I guess >> there is no point in updating a RXT other than to do a content (artifact >> content) change which can be done by changing the configuration (Configure >> tab). So there are less or no usecase in changing the RXT. >> >> thanks >> Eranda >> >> * >> * >> >> > > > -- > *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 > > Thanks, Samisa... Samisa Abeysinghe VP Engineering WSO2 Inc. http://wso2.com http://wso2.org ___ Dev mailing list Dev@wso2.org http://wso2.org/cgi-bin/mailman/listinfo/dev
Re: [Dev] [GReg] Provide only delete option for installed RXT types
On Fri, Nov 2, 2012 at 4:25 AM, Samisa Abeysinghe wrote: > Looking at these use cases, I would imagine that we have to have an LC > like listing of RXT types under config tab, rather than having them listed > individually in there - in other words, one-stop-shop view to help with > these actions. > If I am not mistaken you mean a LC like listing under Home > Extensions > Configure > Lifecycles ? If so that is the intended implementation (i.e Home > Extensions > Configure > Artifact Types). Anyway we will have the RXT configurations individually listed under Home > Configure. > > On Thu, Nov 1, 2012 at 11:21 PM, Senaka Fernando wrote: > >> Hi Subash, >> >> Hold on, there are multiple angles to this. You've just pointed out one, >> but there are several other things one might try to do. For example, >> >> 1. someone might want to create a copy from an existing RXT and create a >> new one. Some people actually do this even today. For them, edit is not >> required, but being able to view the existing RXT is. (note: in the LC UI, >> view and edit are both a single interface). >> >> 2. another user might try to make changes to the columns in a list UI, >> but not actually change the layout of the add/edit view. Asking someone to >> delete and add again is not the best answer. >> >> So, for #1, view is required and for #2 a partial edit is required. We >> also have a #3, which Eranda pointed out (i.e. being able to reconfigure >> the layout of the add/edit view). #3 can actually be done through the >> configure UI, but one could ask, why don't we have a complete edit instead >> of a partial edit, and get rid of the separate configure UI. This would >> make services and RXTs inconsistent, but then again, we can convert service >> to be represented using an RXT too. >> >> So, I'd like to suggest that we reconsider this decision and understand >> the problem end-to-end and find a proper lasting solution, without >> attempting a quick fix. >> >> Thanks, >> Senaka. >> >> On Thu, Nov 1, 2012 at 10:24 PM, Eranda Sooriyabandara >> wrote: >> >>> Hi Subash, >>> >>> >>> On Thu, Nov 1, 2012 at 9:18 PM, Subash Chaturanga wrote: >>> Hi, This is regarding when GReg provides a UI to upload RXTs and also list them. Shall we have $subject ? Because if we provide edit options for an already installed RXT, once the RXT config is updated, already created RXT instances out of the old one becomes staled. And you cannot expect the new behavior from the old instances (users might not able to identify the old ones explicitly) . In that context I feel it is an invalid use case. This can be considered when we support development time governance. So shall we do $subject ? >>> >>> +1. Since we use have the validations for RXTs when uploading, we should >>> have the feeling that there are no error in the configuration. So I guess >>> there is no point in updating a RXT other than to do a content (artifact >>> content) change which can be done by changing the configuration (Configure >>> tab). So there are less or no usecase in changing the RXT. >>> >>> thanks >>> Eranda >>> >>> * >>> * >>> >>> >> >> >> -- >> *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 >> >> Thanks, > Samisa... > > Samisa Abeysinghe > VP Engineering > WSO2 Inc. > http://wso2.com > http://wso2.org > > > -- Subash Chaturanga Software Engineer WSO2 Inc. http://wso2.com email - sub...@wso2.com phone - 077 2225922 ___ Dev mailing list Dev@wso2.org http://wso2.org/cgi-bin/mailman/listinfo/dev
Re: [Dev] [GReg] Provide only delete option for installed RXT types
On Fri, Nov 2, 2012 at 4:45 AM, Subash Chaturanga wrote: > > > On Fri, Nov 2, 2012 at 4:25 AM, Samisa Abeysinghe wrote: > >> Looking at these use cases, I would imagine that we have to have an LC >> like listing of RXT types under config tab, rather than having them listed >> individually in there - in other words, one-stop-shop view to help with >> these actions. >> > > If I am not mistaken you mean a LC like listing under Home > Extensions > > Configure > Lifecycles ? If so that is the intended implementation > (i.e Home > Extensions > Configure > Artifact Types). > +1 > Anyway we will have the RXT configurations individually listed under > Home > Configure. > If we have the above, would we still need this? > > >> >> On Thu, Nov 1, 2012 at 11:21 PM, Senaka Fernando wrote: >> >>> Hi Subash, >>> >>> Hold on, there are multiple angles to this. You've just pointed out one, >>> but there are several other things one might try to do. For example, >>> >>> 1. someone might want to create a copy from an existing RXT and create a >>> new one. Some people actually do this even today. For them, edit is not >>> required, but being able to view the existing RXT is. (note: in the LC UI, >>> view and edit are both a single interface). >>> >>> 2. another user might try to make changes to the columns in a list UI, >>> but not actually change the layout of the add/edit view. Asking someone to >>> delete and add again is not the best answer. >>> >>> So, for #1, view is required and for #2 a partial edit is required. We >>> also have a #3, which Eranda pointed out (i.e. being able to reconfigure >>> the layout of the add/edit view). #3 can actually be done through the >>> configure UI, but one could ask, why don't we have a complete edit instead >>> of a partial edit, and get rid of the separate configure UI. This would >>> make services and RXTs inconsistent, but then again, we can convert service >>> to be represented using an RXT too. >>> >>> So, I'd like to suggest that we reconsider this decision and understand >>> the problem end-to-end and find a proper lasting solution, without >>> attempting a quick fix. >>> >>> Thanks, >>> Senaka. >>> >>> On Thu, Nov 1, 2012 at 10:24 PM, Eranda Sooriyabandara >>> wrote: >>> Hi Subash, On Thu, Nov 1, 2012 at 9:18 PM, Subash Chaturanga wrote: > Hi, > This is regarding when GReg provides a UI to upload RXTs and also list > them. Shall we have $subject ? Because if we provide edit options for an > already installed RXT, once the RXT config is updated, already created RXT > instances out of the old one becomes staled. And you cannot expect the new > behavior from the old instances (users might not able to identify the old > ones explicitly) . In that context I feel it is an invalid use case. > > This can be considered when we support development time governance. > So shall we do $subject ? > +1. Since we use have the validations for RXTs when uploading, we should have the feeling that there are no error in the configuration. So I guess there is no point in updating a RXT other than to do a content (artifact content) change which can be done by changing the configuration (Configure tab). So there are less or no usecase in changing the RXT. thanks Eranda * * >>> >>> >>> -- >>> *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 >>> >>> Thanks, >> Samisa... >> >> Samisa Abeysinghe >> VP Engineering >> WSO2 Inc. >> http://wso2.com >> http://wso2.org >> >> >> > > > -- > > Subash Chaturanga > Software Engineer > WSO2 Inc. http://wso2.com > > email - sub...@wso2.com > phone - 077 2225922 > > Thanks, Samisa... Samisa Abeysinghe VP Engineering WSO2 Inc. http://wso2.com http://wso2.org ___ Dev mailing list Dev@wso2.org http://wso2.org/cgi-bin/mailman/listinfo/dev
Re: [Dev] [GReg] Provide only delete option for installed RXT types
On Fri, Nov 2, 2012 at 4:54 AM, Samisa Abeysinghe wrote: > > > On Fri, Nov 2, 2012 at 4:45 AM, Subash Chaturanga wrote: > >> >> >> On Fri, Nov 2, 2012 at 4:25 AM, Samisa Abeysinghe wrote: >> >>> Looking at these use cases, I would imagine that we have to have an LC >>> like listing of RXT types under config tab, rather than having them listed >>> individually in there - in other words, one-stop-shop view to help with >>> these actions. >>> >> >> If I am not mistaken you mean a LC like listing under Home > Extensions > >> Configure > Lifecycles ? If so that is the intended implementation >> (i.e Home > Extensions > Configure > Artifact Types). >> > > +1 > > > >> Anyway we will have the RXT configurations individually listed under >> Home > Configure. >> > > If we have the above, would we still need this? > In the current implementation what we have is the RXTs gets list under Home > Configure. And what I am implementing is a LC creation like UI as above which also has the list of artifacts. And there I thought a delete option is enough in that list. > > > >> >> >>> >>> On Thu, Nov 1, 2012 at 11:21 PM, Senaka Fernando wrote: >>> Hi Subash, Hold on, there are multiple angles to this. You've just pointed out one, but there are several other things one might try to do. For example, 1. someone might want to create a copy from an existing RXT and create a new one. Some people actually do this even today. For them, edit is not required, but being able to view the existing RXT is. (note: in the LC UI, view and edit are both a single interface). 2. another user might try to make changes to the columns in a list UI, but not actually change the layout of the add/edit view. Asking someone to delete and add again is not the best answer. So, for #1, view is required and for #2 a partial edit is required. We also have a #3, which Eranda pointed out (i.e. being able to reconfigure the layout of the add/edit view). #3 can actually be done through the configure UI, but one could ask, why don't we have a complete edit instead of a partial edit, and get rid of the separate configure UI. This would make services and RXTs inconsistent, but then again, we can convert service to be represented using an RXT too. So, I'd like to suggest that we reconsider this decision and understand the problem end-to-end and find a proper lasting solution, without attempting a quick fix. Thanks, Senaka. On Thu, Nov 1, 2012 at 10:24 PM, Eranda Sooriyabandara >>> > wrote: > Hi Subash, > > > On Thu, Nov 1, 2012 at 9:18 PM, Subash Chaturanga wrote: > >> Hi, >> This is regarding when GReg provides a UI to upload RXTs and also >> list them. Shall we have $subject ? Because if we provide edit options >> for >> an already installed RXT, once the RXT config is updated, already created >> RXT instances out of the old one becomes staled. And you cannot expect >> the >> new behavior from the old instances (users might not able to identify the >> old ones explicitly) . In that context I feel it is an invalid use case. >> >> This can be considered when we support development time governance. >> So shall we do $subject ? >> > > +1. Since we use have the validations for RXTs when uploading, we > should have the feeling that there are no error in the configuration. So I > guess there is no point in updating a RXT other than to do a content > (artifact content) change which can be done by changing the configuration > (Configure tab). So there are less or no usecase in changing the RXT. > > thanks > Eranda > > * > * > > -- *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 Thanks, >>> Samisa... >>> >>> Samisa Abeysinghe >>> VP Engineering >>> WSO2 Inc. >>> http://wso2.com >>> http://wso2.org >>> >>> >>> >> >> >> -- >> >> Subash Chaturanga >> Software Engineer >> WSO2 Inc. http://wso2.com >> >> email - sub...@wso2.com >> phone - 077 2225922 >> >> Thanks, > Samisa... > > Samisa Abeysinghe > VP Engineering > WSO2 Inc. > http://wso2.com > http://wso2.org > > > -- Subash Chaturanga Software Engineer WSO2 Inc. http://wso2.com email - sub...@wso2.com phone - 077 2225922 ___ Dev mailing list Dev@wso2.org http://wso2.org/cgi-bin/mailman/listinfo/dev
Re: [Dev] [GReg] Provide only delete option for installed RXT types
On Fri, Nov 2, 2012 at 5:34 AM, Subash Chaturanga wrote: > > > On Fri, Nov 2, 2012 at 4:54 AM, Samisa Abeysinghe wrote: > >> >> >> On Fri, Nov 2, 2012 at 4:45 AM, Subash Chaturanga wrote: >> >>> >>> >>> On Fri, Nov 2, 2012 at 4:25 AM, Samisa Abeysinghe wrote: >>> Looking at these use cases, I would imagine that we have to have an LC like listing of RXT types under config tab, rather than having them listed individually in there - in other words, one-stop-shop view to help with these actions. >>> >>> If I am not mistaken you mean a LC like listing under Home > >>> Extensions > Configure > Lifecycles ? If so that is the intended >>> implementation (i.e Home > Extensions > Configure > Artifact Types). >>> >> >> +1 >> >> >> >>> Anyway we will have the RXT configurations individually listed under >>> Home > Configure. >>> >> >> If we have the above, would we still need this? >> > > In the current implementation what we have is the RXTs gets list > under Home > Configure. And what I am implementing is a LC creation like > UI as above which also has the list of artifacts. And there I thought a > delete option is enough in that list. > There is a usability issue with listing RXT randomy in the config tab. 1. it looks messy with 10/12 RXTs 2. I have no control as a user on the listing order The link only allow editing, thus why not have that linked form the listing page and be done with it rather than adding to the menu? > >> >> >> >>> >>> On Thu, Nov 1, 2012 at 11:21 PM, Senaka Fernando wrote: > Hi Subash, > > Hold on, there are multiple angles to this. You've just pointed out > one, but there are several other things one might try to do. For example, > > 1. someone might want to create a copy from an existing RXT and create > a new one. Some people actually do this even today. For them, edit is not > required, but being able to view the existing RXT is. (note: in the LC UI, > view and edit are both a single interface). > > 2. another user might try to make changes to the columns in a list UI, > but not actually change the layout of the add/edit view. Asking someone to > delete and add again is not the best answer. > > So, for #1, view is required and for #2 a partial edit is required. We > also have a #3, which Eranda pointed out (i.e. being able to reconfigure > the layout of the add/edit view). #3 can actually be done through the > configure UI, but one could ask, why don't we have a complete edit instead > of a partial edit, and get rid of the separate configure UI. This would > make services and RXTs inconsistent, but then again, we can convert > service > to be represented using an RXT too. > > So, I'd like to suggest that we reconsider this decision and > understand the problem end-to-end and find a proper lasting solution, > without attempting a quick fix. > > Thanks, > Senaka. > > On Thu, Nov 1, 2012 at 10:24 PM, Eranda Sooriyabandara < > era...@wso2.com> wrote: > >> Hi Subash, >> >> >> On Thu, Nov 1, 2012 at 9:18 PM, Subash Chaturanga wrote: >> >>> Hi, >>> This is regarding when GReg provides a UI to upload RXTs and also >>> list them. Shall we have $subject ? Because if we provide edit options >>> for >>> an already installed RXT, once the RXT config is updated, already >>> created >>> RXT instances out of the old one becomes staled. And you cannot expect >>> the >>> new behavior from the old instances (users might not able to identify >>> the >>> old ones explicitly) . In that context I feel it is an invalid use case. >>> >>> This can be considered when we support development time governance. >>> So shall we do $subject ? >>> >> >> +1. Since we use have the validations for RXTs when uploading, we >> should have the feeling that there are no error in the configuration. So >> I >> guess there is no point in updating a RXT other than to do a content >> (artifact content) change which can be done by changing the configuration >> (Configure tab). So there are less or no usecase in changing the RXT. >> >> thanks >> Eranda >> >> * >> * >> >> > > > -- > *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 > > Thanks, Samisa... Samisa Abeysinghe VP Engineering WSO2 Inc. http://wso2.com http://wso2.org >>> >>> >>> -- >>> >>> Subash Chaturanga >>> Software Engineer >>> WSO2 Inc. http:/
[Dev] Data Set for a CEP test
Look like twitter is taking down data sets e.g. http://www.quora.com/Is-there-a-recent-Twitter-dataset-that-has-been-made-available-to-download-for-academic-research e.g. There was a very nice one in http://snap.stanford.edu/data/twitter7.html, which has taken down. Another option is the following weather data set, 20GB. It is in Amazon free data sets. So do not have to pay for transfer etc. If we need more, we can replay the data. Daily Global Weather Measurements, 1929-2009 (NCDC, GSOD) A collection of daily weather measurements (temperature, wind speed, humidity, pressure, &c.) from 9000+ weather stations around the world. http://aws.amazon.com/datasets/Climate/2759 -- Srinath Perera, Ph.D. Senior Software Architect, WSO2 Inc. Visiting Faculty, University of Moratuwa Member, Apache Software Foundation Research Scientist, Lanka Software Foundation Blog: http://srinathsview.blogspot.com/ Photos: http://www.flickr.com/photos/hemapani/ Phone: 0772360902 ___ Dev mailing list Dev@wso2.org http://wso2.org/cgi-bin/mailman/listinfo/dev
[Dev] [Bamboo-Build] WSO2 Carbon 4.0.x > Products 4.0.3 > #17 was SUCCESSFUL (with 58 tests). Change made by rajika.
--- WSO2 Carbon 4.0.x > Products 4.0.3 > #17 was successful. --- This build occurred because it is a dependant of WCB001-PLA001-48. 58 tests in total. http://wso2.org/bamboo/browse/WCB001-PRO001-17/ -- Code Changes -- rajika (147123): >Fixed stub build failure in clean repo due to old build libaries. -- This message is automatically generated by Atlassian Bamboo___ Dev mailing list Dev@wso2.org http://wso2.org/cgi-bin/mailman/listinfo/dev
[Dev] [Bamboo-Build] WSO2 Carbon 4.0.x - Nightly > Platform_4.0.3 > #5 has FAILED. Change made by rajika.
--- WSO2 Carbon 4.0.x - Nightly > Platform_4.0.3 > #5 failed. --- This build occurred because it is a dependant of WCB002-KER003-4. No failed tests found, a possible compilation error. http://wso2.org/bamboo/browse/WCB002-PLA003-5/ - Currently Responsible - No one is responsible for fixing this build. -- Failing Jobs -- - Default Job (Default Stage): 958 tests passed. -- Code Changes -- rajika (147123): >Fixed stub build failure in clean repo due to old build libaries. rajika (147120): >Fixed the build failure in manager. Pach by Amila Mahaarachchi. -- This message is automatically generated by Atlassian Bamboo___ Dev mailing list Dev@wso2.org http://wso2.org/cgi-bin/mailman/listinfo/dev
