Re: [Architecture] Resilient application creation process

2014-01-06 Thread Harsha Thirimanna
Hi Suresh,

We have identified above fail points as mandatory to the app creation
process. But as you said , for the optional cases, we can do this in
configurable manner in appfactory configuration. Then user can select those
optional cases as mandatory or not.

But if we allow to create app creation without having some mandatory part,
then we have to give options to create those in later.

thanks



*Harsha Thirimanna*
Senior Software Engineer; WSO2, Inc.; http://wso2.com
* http://www.apache.org/*
* email: **hars...@wso2.com* az...@wso2.com* cell: +94 71 5186770*
* twitter: **http://twitter.com/ http://twitter.com/afkham_azeez*
*harshathirimann linked-in: **http:
http://lk.linkedin.com/in/afkhamazeez**//www.linkedin.com/pub/harsha-thirimanna/10/ab8/122
http://www.linkedin.com/pub/harsha-thirimanna/10/ab8/122*

 *Lean . Enterprise . Middleware*



On Mon, Jan 6, 2014 at 1:20 PM, Suresh Attanayaka sur...@wso2.com wrote:

 Hi,

 As a user I would like to continue app creation even when some steps are
 failed such as Issue repository creation, And then I can try those steps
 later to complete the app creation.


 On Mon, Jan 6, 2014 at 12:10 PM, Shamika Ariyawansa sham...@wso2.comwrote:

 Hi,

 Is there any possibility of showing the user that what step of this
 is exactly failed ?. So that user would know that due to that failure the
 application creation process is cancelled and rolled back.

 Regards


 On Mon, Jan 6, 2014 at 11:57 AM, Ashansa Perera asha...@wso2.com wrote:

 The main error situations would be the failures on any of the following
 actions
 - Repository creation
 - Build job creation
 - Issue repository creation
 - Authorize roles
 - Add users to application


 On Mon, Jan 6, 2014 at 11:12 AM, Samisa Abeysinghe sam...@wso2.comwrote:

 What are the error situations that we roll back on? Are they numerous
 or are they handful?

 Thanks,
 Samisa...


 Samisa Abeysinghe

 Vice President Developer Evangelism

 WSO2 Inc.
 http://wso2.com



 On Mon, Jan 6, 2014 at 11:04 AM, Ashansa Perera asha...@wso2.comwrote:

 @Ramith
 Application creation process do
 - repository creation
 - jenkins job creation
 - publish application creation ( which calls all the application event
 listeners )


 On Mon, Jan 6, 2014 at 10:55 AM, Ashansa Perera asha...@wso2.comwrote:

 Agree with Janaka's idea of having rollback mechanism first and of
 course we can have retry logic in each operation as well.


 On Mon, Jan 6, 2014 at 10:48 AM, Ramith Jayasinghe 
 ram...@wso2.comwrote:

 Shall we list down what are the steps involved in creating a
 application. then what needs to be to undo each step that was performed?


 On Mon, Jan 6, 2014 at 10:45 AM, Gayan Dhanushka gay...@wso2.comwrote:

 Hi Janaka,

 IMO it is ok for us to have a mechanism for retrying. If it was an
 intermittent issue that interrupted the system from creating the
 application this will solve it. If the application creation failed 
 after
 retrying for a few times we can roll back the entire process. If it is 
 some
 other serious issue rolling back and trying to start the application
 creation process from the begining still won't work.

 WDYT?

 GayanD

 Gayan Dhanuska
 Software Engineer
 http://wso2.com/
 Lean Enterprise Middleware

 Mobile
 071 666 2327

 Office
 Tel   : 94 11 214 5345
 Fax  : 94 11 214 5300

 Twitter : https://twitter.com/gayanlggd


 On Mon, Jan 6, 2014 at 10:33 AM, Janaka Ranabahu 
 jan...@wso2.comwrote:

 Hi Manjula,


 On Mon, Jan 6, 2014 at 10:24 AM, Manjula Rathnayake 
 manju...@wso2.com wrote:

 Hi all,

 Another option is to retry to create the application even after
 failed. There we create the application again and again until it get
 created. If it fails, users should be able to role back. In this 
 process,
 for example, if application rxt adding process succeeds but creating 
 git
 repo fails, we should be able to create git repo and continue without
 trying to add the rxt.

 If I understood you correctly, then what we need to do is to retry
 the failed process/action a number of times. But that can not 
 guarantee
 whether the app creation would complete successfully. Say that the 
 git repo
 creation(or any other task) failed due to a network error or some 
 other
 serious issue. Then retrying will not solve the issue. IMO, what we 
 need in
 the first place is the rollback functionality and as an improvement 
 we can
 do the retry logic.

 WDYT?

 Thanks,
 Janaka


 thank you.


 On Mon, Jan 6, 2014 at 10:06 AM, Ashansa Perera asha...@wso2.com
  wrote:

 Hi all,

 To make the application creation process resilient we discussed
 to implement a rollback mechanism so that if any 
 resource/infrastructure
 creation failed while creating the application we can rollback the 
 app
 creation. With this we would be able to reuse the same application 
 key and
 utilize the resources.
 Another suggestion was to ping the external servers before
 starting application creation process, but since pinging servers 
 cannot
 

Re: [Architecture] Resilient application creation process

2014-01-06 Thread Ashansa Perera
Yes, I think we can add these as improvements in next milestones after
discussing.


On Mon, Jan 6, 2014 at 1:37 PM, Harsha Thirimanna hars...@wso2.com wrote:

 Hi Suresh,

 We have identified above fail points as mandatory to the app creation
 process. But as you said , for the optional cases, we can do this in
 configurable manner in appfactory configuration. Then user can select those
 optional cases as mandatory or not.

 But if we allow to create app creation without having some mandatory part,
 then we have to give options to create those in later.

 thanks



 *Harsha Thirimanna*

 Senior Software Engineer; WSO2, Inc.; http://wso2.com
 * http://www.apache.org/*
 * email: **hars...@wso2.com* az...@wso2.com* cell: +94 71 5186770*
 * twitter: **http://twitter.com/ http://twitter.com/afkham_azeez*
 *harshathirimann linked-in: **http:
 http://lk.linkedin.com/in/afkhamazeez**//www.linkedin.com/pub/harsha-thirimanna/10/ab8/122
 http://www.linkedin.com/pub/harsha-thirimanna/10/ab8/122*

  *Lean . Enterprise . Middleware*



 On Mon, Jan 6, 2014 at 1:20 PM, Suresh Attanayaka sur...@wso2.com wrote:

 Hi,

 As a user I would like to continue app creation even when some steps are
 failed such as Issue repository creation, And then I can try those steps
 later to complete the app creation.


 On Mon, Jan 6, 2014 at 12:10 PM, Shamika Ariyawansa sham...@wso2.comwrote:

 Hi,

 Is there any possibility of showing the user that what step of this
 is exactly failed ?. So that user would know that due to that failure the
 application creation process is cancelled and rolled back.

 Regards


 On Mon, Jan 6, 2014 at 11:57 AM, Ashansa Perera asha...@wso2.comwrote:

 The main error situations would be the failures on any of the following
 actions
 - Repository creation
 - Build job creation
 - Issue repository creation
 - Authorize roles
 - Add users to application


 On Mon, Jan 6, 2014 at 11:12 AM, Samisa Abeysinghe sam...@wso2.comwrote:

 What are the error situations that we roll back on? Are they numerous
 or are they handful?

 Thanks,
 Samisa...


 Samisa Abeysinghe

 Vice President Developer Evangelism

 WSO2 Inc.
 http://wso2.com



 On Mon, Jan 6, 2014 at 11:04 AM, Ashansa Perera asha...@wso2.comwrote:

 @Ramith
 Application creation process do
 - repository creation
 - jenkins job creation
 - publish application creation ( which calls all the application
 event listeners )


 On Mon, Jan 6, 2014 at 10:55 AM, Ashansa Perera asha...@wso2.comwrote:

 Agree with Janaka's idea of having rollback mechanism first and of
 course we can have retry logic in each operation as well.


 On Mon, Jan 6, 2014 at 10:48 AM, Ramith Jayasinghe 
 ram...@wso2.comwrote:

 Shall we list down what are the steps involved in creating a
 application. then what needs to be to undo each step that was 
 performed?


 On Mon, Jan 6, 2014 at 10:45 AM, Gayan Dhanushka 
 gay...@wso2.comwrote:

 Hi Janaka,

 IMO it is ok for us to have a mechanism for retrying. If it was an
 intermittent issue that interrupted the system from creating the
 application this will solve it. If the application creation failed 
 after
 retrying for a few times we can roll back the entire process. If it 
 is some
 other serious issue rolling back and trying to start the application
 creation process from the begining still won't work.

 WDYT?

 GayanD

 Gayan Dhanuska
 Software Engineer
 http://wso2.com/
 Lean Enterprise Middleware

 Mobile
 071 666 2327

 Office
 Tel   : 94 11 214 5345
 Fax  : 94 11 214 5300

 Twitter : https://twitter.com/gayanlggd


 On Mon, Jan 6, 2014 at 10:33 AM, Janaka Ranabahu 
 jan...@wso2.comwrote:

 Hi Manjula,


 On Mon, Jan 6, 2014 at 10:24 AM, Manjula Rathnayake 
 manju...@wso2.com wrote:

 Hi all,

 Another option is to retry to create the application even after
 failed. There we create the application again and again until it get
 created. If it fails, users should be able to role back. In this 
 process,
 for example, if application rxt adding process succeeds but 
 creating git
 repo fails, we should be able to create git repo and continue 
 without
 trying to add the rxt.

 If I understood you correctly, then what we need to do is to
 retry the failed process/action a number of times. But that can not
 guarantee whether the app creation would complete successfully. Say 
 that
 the git repo creation(or any other task) failed due to a network 
 error or
 some other serious issue. Then retrying will not solve the issue. 
 IMO, what
 we need in the first place is the rollback functionality and as an
 improvement we can do the retry logic.

 WDYT?

 Thanks,
 Janaka


 thank you.


 On Mon, Jan 6, 2014 at 10:06 AM, Ashansa Perera 
 asha...@wso2.com wrote:

 Hi all,

 To make the application creation process resilient we discussed
 to implement a rollback mechanism so that if any 
 resource/infrastructure
 creation failed while creating the application we can rollback the 
 app
 creation. With this we would be able to reuse the same 

Re: [Architecture] Resilient application creation process

2014-01-06 Thread Harsha Thirimanna
Hi Ashansa,

Now what we are going to do is deleting all the stuff related to the
current failed application and give a message to the user saying failed.
After refresh the page then there will not be any information regarding
this failed app.
Instead of doing that how about if we keep the failed application detail
and show to the user that app as a failed app.then we can can offer a retry
button and if user retry after resolving this problem with administrator
and then we can continue the job. In that case either we can delete all the
stuff and recreate or , try to continue job just checking availability of
the resource.  WDYT ?

thanks


*Harsha Thirimanna*
Senior Software Engineer; WSO2, Inc.; http://wso2.com
* http://www.apache.org/*
* email: **hars...@wso2.com* az...@wso2.com* cell: +94 71 5186770*
* twitter: **http://twitter.com/ http://twitter.com/afkham_azeez*
*harshathirimann linked-in: **http:
http://lk.linkedin.com/in/afkhamazeez**//www.linkedin.com/pub/harsha-thirimanna/10/ab8/122
http://www.linkedin.com/pub/harsha-thirimanna/10/ab8/122*

 *Lean . Enterprise . Middleware*



On Mon, Jan 6, 2014 at 1:48 PM, Ashansa Perera asha...@wso2.com wrote:

 Yes, I think we can add these as improvements in next milestones after
 discussing.


 On Mon, Jan 6, 2014 at 1:37 PM, Harsha Thirimanna hars...@wso2.comwrote:

 Hi Suresh,

 We have identified above fail points as mandatory to the app creation
 process. But as you said , for the optional cases, we can do this in
 configurable manner in appfactory configuration. Then user can select those
 optional cases as mandatory or not.

 But if we allow to create app creation without having some mandatory
 part, then we have to give options to create those in later.

 thanks



 *Harsha Thirimanna*

 Senior Software Engineer; WSO2, Inc.; http://wso2.com
 * http://www.apache.org/*
 * email: **hars...@wso2.com* az...@wso2.com* cell: +94 71 5186770*
 * twitter: **http://twitter.com/ http://twitter.com/afkham_azeez*
 *harshathirimann linked-in: **http:
 http://lk.linkedin.com/in/afkhamazeez**//www.linkedin.com/pub/harsha-thirimanna/10/ab8/122
 http://www.linkedin.com/pub/harsha-thirimanna/10/ab8/122*

  *Lean . Enterprise . Middleware*



 On Mon, Jan 6, 2014 at 1:20 PM, Suresh Attanayaka sur...@wso2.comwrote:

 Hi,

 As a user I would like to continue app creation even when some steps are
 failed such as Issue repository creation, And then I can try those steps
 later to complete the app creation.


 On Mon, Jan 6, 2014 at 12:10 PM, Shamika Ariyawansa sham...@wso2.comwrote:

 Hi,

 Is there any possibility of showing the user that what step of this
 is exactly failed ?. So that user would know that due to that failure the
 application creation process is cancelled and rolled back.

 Regards


 On Mon, Jan 6, 2014 at 11:57 AM, Ashansa Perera asha...@wso2.comwrote:

 The main error situations would be the failures on any of the
 following actions
 - Repository creation
 - Build job creation
 - Issue repository creation
 - Authorize roles
 - Add users to application


 On Mon, Jan 6, 2014 at 11:12 AM, Samisa Abeysinghe sam...@wso2.comwrote:

 What are the error situations that we roll back on? Are they numerous
 or are they handful?

 Thanks,
 Samisa...


 Samisa Abeysinghe

 Vice President Developer Evangelism

 WSO2 Inc.
 http://wso2.com



 On Mon, Jan 6, 2014 at 11:04 AM, Ashansa Perera asha...@wso2.comwrote:

 @Ramith
 Application creation process do
 - repository creation
 - jenkins job creation
 - publish application creation ( which calls all the application
 event listeners )


 On Mon, Jan 6, 2014 at 10:55 AM, Ashansa Perera asha...@wso2.comwrote:

 Agree with Janaka's idea of having rollback mechanism first and of
 course we can have retry logic in each operation as well.


 On Mon, Jan 6, 2014 at 10:48 AM, Ramith Jayasinghe ram...@wso2.com
  wrote:

 Shall we list down what are the steps involved in creating a
 application. then what needs to be to undo each step that was 
 performed?


 On Mon, Jan 6, 2014 at 10:45 AM, Gayan Dhanushka 
 gay...@wso2.comwrote:

 Hi Janaka,

 IMO it is ok for us to have a mechanism for retrying. If it was
 an intermittent issue that interrupted the system from creating the
 application this will solve it. If the application creation failed 
 after
 retrying for a few times we can roll back the entire process. If it 
 is some
 other serious issue rolling back and trying to start the application
 creation process from the begining still won't work.

 WDYT?

 GayanD

 Gayan Dhanuska
 Software Engineer
 http://wso2.com/
 Lean Enterprise Middleware

 Mobile
 071 666 2327

 Office
 Tel   : 94 11 214 5345
 Fax  : 94 11 214 5300

 Twitter : https://twitter.com/gayanlggd


 On Mon, Jan 6, 2014 at 10:33 AM, Janaka Ranabahu jan...@wso2.com
  wrote:

 Hi Manjula,


 On Mon, Jan 6, 2014 at 10:24 AM, Manjula Rathnayake 
 manju...@wso2.com wrote:

 Hi all,

 Another option is to retry to create the application even after
 failed. There we 

[Architecture] [AppFactory] Create AppFactory applications from already existing application binaries

2014-01-06 Thread Shamika Ariyawansa
Hi All,

New feature that is going to be introduced to AppFactory is creating a new
application by uploading exiting binary file of an application. e.g WAR

*User Scenario*

1. User logs on to the system, goes to the application creation page.
2. In there user provides basic information related to the application,
such as name, key, description then he/she would be able to create the
application by choosing one of the following options,

 a. Create the application from the scratch by selecting the repository
type and application type which maps with existing functionality. *OR*
 b. Create the application by uploading the binary file and selecting the
binary file type. By doing so the application will be created as
non build-able application.

3. In Repos and Builds page user will be able to see the
uploaded application and he/she will be able to do following operations
from there,
  a. Delete the existing application.
  b. Upload new version of the same application. - Provides a way to upload
new binary file.
  c. Test the application by deploying to Dev cloud.

Note that for applications created like this, source repository paths,
build options and not shown to the users.

4. From Life Cycle Management page user will be able to Promote and Demote
the application through different life cycles.

*Solution*

So far in AppFactory we maintain two logical types of application flows.
Buildable and non-Buildable. Buildabale applications are mainly handled
and deployed by the buildserver (Jenkins) whereas non-Buildable are
maintained and deployed by the AppFactory itself.
uploading existing application functionality will
be implemented considering Non-Buildable application flow as follows.

[image: Inline image 2]

Further App Creation, Build and Repos and other UIs will
be changed accordingly.


Regards,
-- 
Shamika Ariyawansa
Senior Software Engineer
WSO2, Inc.; http://wso2.com

LK -  +94 7639629 Ext 5999
US - +1 408 754 7388 Ext 51732
Mob:+ 94 772929486

*twitter: 
**https://twitter.com/Amila_Shamika*https://twitter.com/Amila_Shamika
*linked-in: *http://www.linkedin.com/pub/dir/Shamika/Ariyawansa

*Lean . Enterprise . Middleware*
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture


Re: [Architecture] [AppFactory] Create AppFactory applications from already existing application binaries

2014-01-06 Thread Janaka Ranabahu
Hi Shamika,


On Mon, Jan 6, 2014 at 4:43 PM, Shamika Ariyawansa sham...@wso2.com wrote:

 Hi All,

 New feature that is going to be introduced to AppFactory is creating a new
 application by uploading exiting binary file of an application. e.g WAR

 *User Scenario*

 1. User logs on to the system, goes to the application creation page.
 2. In there user provides basic information related to the application,
 such as name, key, description then he/she would be able to create the
 application by choosing one of the following options,

  a. Create the application from the scratch by selecting the repository
 type and application type which maps with existing functionality. *OR*
  b. Create the application by uploading the binary file and selecting the
 binary file type. By doing so the application will be created as
 non build-able application.

Can we improve this so that a user can create an application pointing to a
existing source code so that AF can clone that instead of the default
template?

Thanks,
Janaka


 3. In Repos and Builds page user will be able to see the
 uploaded application and he/she will be able to do following operations
 from there,
   a. Delete the existing application.
   b. Upload new version of the same application. - Provides a way to
 upload new binary file.
   c. Test the application by deploying to Dev cloud.

 Note that for applications created like this, source repository paths,
 build options and not shown to the users.

 4. From Life Cycle Management page user will be able to Promote and Demote
 the application through different life cycles.

 *Solution*

 So far in AppFactory we maintain two logical types of application flows.
 Buildable and non-Buildable. Buildabale applications are mainly handled
 and deployed by the buildserver (Jenkins) whereas non-Buildable are
 maintained and deployed by the AppFactory itself.
 uploading existing application functionality will
 be implemented considering Non-Buildable application flow as follows.

 [image: Inline image 2]

 Further App Creation, Build and Repos and other UIs will
 be changed accordingly.


 Regards,
 --
 Shamika Ariyawansa
 Senior Software Engineer
 WSO2, Inc.; http://wso2.com

 LK -  +94 7639629 Ext 5999
 US - +1 408 754 7388 Ext 51732
 Mob:+ 94 772929486

 *twitter: 
 **https://twitter.com/Amila_Shamika*https://twitter.com/Amila_Shamika
 * linked-in: *http://www.linkedin.com/pub/dir/Shamika/Ariyawansa

 *Lean . Enterprise . Middleware*

 ___
 Architecture mailing list
 Architecture@wso2.org
 https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




-- 
*Janaka Ranabahu*
Senior Software Engineer; WSO2 Inc.; http://wso2.com


* E-mail: jan...@wso2.com http://wso2.com**M: **+94 718370861*

Lean . Enterprise . Middleware
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture


Re: [Architecture] [AppFactory] Create AppFactory applications from already existing application binaries

2014-01-06 Thread Ashansa Perera
As I feel creating an application pointing to an existing code base is
different than allowing to upload an artifact and create an application,
since this will not include any source code management. So we should
consider those as two different use cases.
IMO we can relate the use case that Janaka has mentioned to our main flow
of application creation where we can provide the option of
   - creating an application pointing to an existing source code ( so AF
can clone that and create application)
   - creating an application with default template



On Mon, Jan 6, 2014 at 5:45 PM, Harsha Thirimanna hars...@wso2.com wrote:

 Hi Janaka,

 +1 for that.

 There will some work to do this. Because

 1. we should process the pom file of that external repository and change
 artifactId, groupId to our one.
 2. we have to have credentials to access external repository.

  thanks



 *Harsha Thirimanna*

 Senior Software Engineer; WSO2, Inc.; http://wso2.com
 * http://www.apache.org/*
 * email: **hars...@wso2.com* az...@wso2.com* cell: +94 71 5186770*
 * twitter: **http://twitter.com/ http://twitter.com/afkham_azeez*
 *harshathirimann linked-in: **http:
 http://lk.linkedin.com/in/afkhamazeez**//www.linkedin.com/pub/harsha-thirimanna/10/ab8/122
 http://www.linkedin.com/pub/harsha-thirimanna/10/ab8/122*

  *Lean . Enterprise . Middleware*



 On Mon, Jan 6, 2014 at 5:28 PM, Janaka Ranabahu jan...@wso2.com wrote:

 Hi Shamika,


 On Mon, Jan 6, 2014 at 4:43 PM, Shamika Ariyawansa sham...@wso2.comwrote:

 Hi All,

 New feature that is going to be introduced to AppFactory is creating a
 new application by uploading exiting binary file of an application. e.g WAR

 *User Scenario*

 1. User logs on to the system, goes to the application creation page.
 2. In there user provides basic information related to the application,
 such as name, key, description then he/she would be able to create the
 application by choosing one of the following options,

  a. Create the application from the scratch by selecting the repository
 type and application type which maps with existing functionality. *OR*
  b. Create the application by uploading the binary file and selecting
 the binary file type. By doing so the application will be created as
 non build-able application.

 Can we improve this so that a user can create an application pointing to
 a existing source code so that AF can clone that instead of the default
 template?

 Thanks,
  Janaka


 3. In Repos and Builds page user will be able to see the
 uploaded application and he/she will be able to do following operations
 from there,
   a. Delete the existing application.
   b. Upload new version of the same application. - Provides a way to
 upload new binary file.
   c. Test the application by deploying to Dev cloud.

 Note that for applications created like this, source repository paths,
 build options and not shown to the users.

 4. From Life Cycle Management page user will be able to Promote and
 Demote the application through different life cycles.

 *Solution*

 So far in AppFactory we maintain two logical types of application flows.
 Buildable and non-Buildable. Buildabale applications are mainly handled
 and deployed by the buildserver (Jenkins) whereas non-Buildable are
 maintained and deployed by the AppFactory itself.
 uploading existing application functionality will
 be implemented considering Non-Buildable application flow as follows.

 [image: Inline image 2]

 Further App Creation, Build and Repos and other UIs will
 be changed accordingly.


 Regards,
 --
 Shamika Ariyawansa
 Senior Software Engineer
 WSO2, Inc.; http://wso2.com

 LK -  +94 7639629 Ext 5999
 US - +1 408 754 7388 Ext 51732
 Mob:+ 94 772929486

 *twitter: 
 **https://twitter.com/Amila_Shamika*https://twitter.com/Amila_Shamika
 * linked-in: *http://www.linkedin.com/pub/dir/Shamika/Ariyawansa

 *Lean . Enterprise . Middleware*

 ___
 Architecture mailing list
 Architecture@wso2.org
 https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




 --
 *Janaka Ranabahu*
 Senior Software Engineer; WSO2 Inc.; http://wso2.com


 * E-mail: jan...@wso2.com http://wso2.com**M: **+94 718370861
 %2B94%20718370861*


 Lean . Enterprise . Middleware


 ___
 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




-- 
Thanks  Regards,

Ashansa Perera
Software Engineer
WSO2, Inc
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture


Re: [Architecture] [AppFactory] Create AppFactory applications from already existing application binaries

2014-01-06 Thread Manjula Rathnayake
Hi all,


On Mon, Jan 6, 2014 at 6:48 PM, Ashansa Perera asha...@wso2.com wrote:

 As I feel creating an application pointing to an existing code base is
 different than allowing to upload an artifact and create an application,
 since this will not include any source code management. So we should
 consider those as two different use cases.
 IMO we can relate the use case that Janaka has mentioned to our main flow
 of application creation where we can provide the option of
- creating an application pointing to an existing source code ( so AF
 can clone that and create application)
- creating an application with default template

 +1, this feature is about uploading a war file and no source code is
involved.

thank you.



 On Mon, Jan 6, 2014 at 5:45 PM, Harsha Thirimanna hars...@wso2.comwrote:

 Hi Janaka,

 +1 for that.

 There will some work to do this. Because

 1. we should process the pom file of that external repository and change
 artifactId, groupId to our one.
 2. we have to have credentials to access external repository.

  thanks



 *Harsha Thirimanna*

 Senior Software Engineer; WSO2, Inc.; http://wso2.com
 * http://www.apache.org/*
 * email: **hars...@wso2.com* az...@wso2.com* cell: +94 71 5186770*
 * twitter: **http://twitter.com/ http://twitter.com/afkham_azeez*
 *harshathirimann linked-in: **http:
 http://lk.linkedin.com/in/afkhamazeez**//www.linkedin.com/pub/harsha-thirimanna/10/ab8/122
 http://www.linkedin.com/pub/harsha-thirimanna/10/ab8/122*

  *Lean . Enterprise . Middleware*



 On Mon, Jan 6, 2014 at 5:28 PM, Janaka Ranabahu jan...@wso2.com wrote:

 Hi Shamika,


 On Mon, Jan 6, 2014 at 4:43 PM, Shamika Ariyawansa sham...@wso2.comwrote:

 Hi All,

 New feature that is going to be introduced to AppFactory is creating a
 new application by uploading exiting binary file of an application. e.g WAR

 *User Scenario*

 1. User logs on to the system, goes to the application creation page.
 2. In there user provides basic information related to the application,
 such as name, key, description then he/she would be able to create the
 application by choosing one of the following options,

  a. Create the application from the scratch by selecting the repository
 type and application type which maps with existing functionality. *OR*
  b. Create the application by uploading the binary file and selecting
 the binary file type. By doing so the application will be created as
 non build-able application.

 Can we improve this so that a user can create an application pointing to
 a existing source code so that AF can clone that instead of the default
 template?

 Thanks,
  Janaka


 3. In Repos and Builds page user will be able to see the
 uploaded application and he/she will be able to do following operations
 from there,
   a. Delete the existing application.
   b. Upload new version of the same application. - Provides a way to
 upload new binary file.
   c. Test the application by deploying to Dev cloud.

 Note that for applications created like this, source repository paths,
 build options and not shown to the users.

 4. From Life Cycle Management page user will be able to Promote and
 Demote the application through different life cycles.

 *Solution*

 So far in AppFactory we maintain two logical types of application
 flows. Buildable and non-Buildable. Buildabale applications
 are mainly handled and deployed by the buildserver (Jenkins) whereas
 non-Buildable are maintained and deployed by the AppFactory itself.
 uploading existing application functionality will
 be implemented considering Non-Buildable application flow as follows.

 [image: Inline image 2]

 Further App Creation, Build and Repos and other UIs will
 be changed accordingly.


 Regards,
 --
 Shamika Ariyawansa
 Senior Software Engineer
 WSO2, Inc.; http://wso2.com

 LK -  +94 7639629 Ext 5999
 US - +1 408 754 7388 Ext 51732
 Mob:+ 94 772929486

 *twitter: 
 **https://twitter.com/Amila_Shamika*https://twitter.com/Amila_Shamika
 * linked-in: *http://www.linkedin.com/pub/dir/Shamika/Ariyawansa

 *Lean . Enterprise . Middleware*

 ___
 Architecture mailing list
 Architecture@wso2.org
 https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




 --
 *Janaka Ranabahu*
 Senior Software Engineer; WSO2 Inc.; http://wso2.com


 * E-mail: jan...@wso2.com http://wso2.com**M: **+94 718370861
 %2B94%20718370861*


 Lean . Enterprise . Middleware


 ___
 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




 --
 Thanks  Regards,

 Ashansa Perera
 Software Engineer
 WSO2, Inc

 ___
 Architecture mailing list
 Architecture@wso2.org
 

Re: [Architecture] [AppFactory] Create AppFactory applications from already existing application binaries

2014-01-06 Thread Harsha Thirimanna
Hi Shamika,
In this case, do we restrict exposing repository URL to user to
checkout/checkin this artifact ? Because even though we not show this URL
in AppFactory UI , user can see this after login to the Git server.

thanks


*Harsha Thirimanna*
Senior Software Engineer; WSO2, Inc.; http://wso2.com
* http://www.apache.org/*
* email: **hars...@wso2.com* az...@wso2.com* cell: +94 71 5186770*
* twitter: **http://twitter.com/ http://twitter.com/afkham_azeez*
*harshathirimann linked-in: **http:
http://lk.linkedin.com/in/afkhamazeez**//www.linkedin.com/pub/harsha-thirimanna/10/ab8/122
http://www.linkedin.com/pub/harsha-thirimanna/10/ab8/122*

 *Lean . Enterprise . Middleware*



On Mon, Jan 6, 2014 at 4:43 PM, Shamika Ariyawansa sham...@wso2.com wrote:

 Hi All,

 New feature that is going to be introduced to AppFactory is creating a new
 application by uploading exiting binary file of an application. e.g WAR

 *User Scenario*

 1. User logs on to the system, goes to the application creation page.
 2. In there user provides basic information related to the application,
 such as name, key, description then he/she would be able to create the
 application by choosing one of the following options,

  a. Create the application from the scratch by selecting the repository
 type and application type which maps with existing functionality. *OR*
  b. Create the application by uploading the binary file and selecting the
 binary file type. By doing so the application will be created as
 non build-able application.

 3. In Repos and Builds page user will be able to see the
 uploaded application and he/she will be able to do following operations
 from there,
   a. Delete the existing application.
   b. Upload new version of the same application. - Provides a way to
 upload new binary file.
   c. Test the application by deploying to Dev cloud.

 Note that for applications created like this, source repository paths,
 build options and not shown to the users.

 4. From Life Cycle Management page user will be able to Promote and Demote
 the application through different life cycles.

 *Solution*

 So far in AppFactory we maintain two logical types of application flows.
 Buildable and non-Buildable. Buildabale applications are mainly handled
 and deployed by the buildserver (Jenkins) whereas non-Buildable are
 maintained and deployed by the AppFactory itself.
 uploading existing application functionality will
 be implemented considering Non-Buildable application flow as follows.

 [image: Inline image 2]

 Further App Creation, Build and Repos and other UIs will
 be changed accordingly.


 Regards,
 --
 Shamika Ariyawansa
 Senior Software Engineer
 WSO2, Inc.; http://wso2.com

 LK -  +94 7639629 Ext 5999
 US - +1 408 754 7388 Ext 51732
 Mob:+ 94 772929486

 *twitter: 
 **https://twitter.com/Amila_Shamika*https://twitter.com/Amila_Shamika
 * linked-in: *http://www.linkedin.com/pub/dir/Shamika/Ariyawansa

 *Lean . Enterprise . Middleware*

___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture


Re: [Architecture] Axis2 Request Delegation for Multiple parameters with the same base URL

2014-01-06 Thread Chanika Geeganage
Please find the attached diff files for the changes done, as per the
offline chat had with Sagara regarding this problem.

Here are the load test results

No of Threads Without the fix (tps)  With the
fix (tps)
1
410 400
5
2100   2080
100
62606250

Thanks


On Sat, Jan 4, 2014 at 8:51 AM, Chanika Geeganage chan...@wso2.com wrote:




 On Sat, Jan 4, 2014 at 6:30 AM, Sagara Gunathunga sag...@wso2.com wrote:




 On Fri, Jan 3, 2014 at 5:06 PM, Chanika Geeganage chan...@wso2.comwrote:

 Hi,

 To fix that properly, we can compile the regex at deployment time and
 keep that compiled pattern as the key. But that will break the exciting
 code because of API changes. It is a utill class and as others are using it
 we can't change the API.



 Shall we have a chat on this Monday morning ?   Let's see whether we can
 find another  workaround.


 Sure. Will do



 Thanks !


 Thanks


 On Fri, Jan 3, 2014 at 4:07 PM, Samisa Abeysinghe sam...@wso2.comwrote:

 Is there any other way to fix the perf drop while fixing the issue?

 Thanks,
 Samisa...


 Samisa Abeysinghe

 Vice President Developer Evangelism

 WSO2 Inc.
 http://wso2.com



 On Fri, Jan 3, 2014 at 3:36 PM, Chanika Geeganage chan...@wso2.comwrote:

 Hi Samisa,

 The fix is for a issue occurred when we define multiple resources in a
 data service with the same resource name. For an example lets say we want
 to define following resources in a data service. (This is described in 
 this
 thread)


 products/{id}
 products/{id}/name/{name}

 The current implementation does not give the desired output as it
 keeps only the resource name as the key. According to the given fix it
 keeps a regex as the key and it compiles all regex in the map each time we
 invoke a request. That is why there is a performance drop.

 Thanks



 On Fri, Jan 3, 2014 at 3:20 PM, Samisa Abeysinghe sam...@wso2.comwrote:

 Why do we have a drop of TPS with the fix? Should we not optimize
 this for better performance?

 Thanks,
 Samisa...


 Samisa Abeysinghe

 Vice President Developer Evangelism

 WSO2 Inc.
 http://wso2.com



 On Fri, Jan 3, 2014 at 1:28 PM, Chanika Geeganage 
 chan...@wso2.comwrote:

 Hi,

 Here I have attached the changed code for the suggested solution
 (using a regex as the key). I ran some load tests and the results are
 listed below.

 No of Threads Without the fix (tps)
 With the fix (tps)
 1
 410 315
 5
 2010   1900
 100
 62606200

 Is it OK to proceed with this fix?

 Thanks



 On Thu, Dec 19, 2013 at 7:37 AM, Chanika Geeganage chan...@wso2.com
  wrote:

 Hi Sameera,

 getConstantFromHTTPLocation method in [1]  is used to maintain the
 map in deployment time and getOperationFromHTTPLocation method is 
 called
 when you invoke the rest service in [2]

 [1]
 https://svn.wso2.org/repos/wso2/carbon/kernel/branches/4.2.0/dependencies/axis2/1.6.1-wso2v10/modules/kernel/src/org/apache/axis2/wsdl/WSDLUtil.java

 [2]
 https://svn.wso2.org/repos/wso2/carbon/kernel/branches/4.2.0/dependencies/axis2/1.6.1-wso2v10/modules/kernel/src/org/apache/axis2/dispatchers/HTTPLocationBasedDispatcher.java

 Thanks


 On Thu, Dec 19, 2013 at 12:51 AM, Sameera Jayasoma 
 same...@wso2.com wrote:

 Hi Chanika,

 Can you please gimme me some pointers to the relevant code blocks
 which are responsible for this situation?

 Thanks,
 Sameera.


 On Wed, Dec 18, 2013 at 3:29 PM, Chanika Geeganage 
 chan...@wso2.com wrote:

 Hi,

 This issue was come across when we invoke a rest resource
 deployed in DSS. According to the current implementation it fails to
 delegate different requests for same base URL. For an example lets 
 say we
 want to have following resources in the dataservice config

 products/{id}
 products/{id}/name/{name}

 According to the current implementation it maintains a map to
 keep the resource info in the deployment time. It keeps a string of 
 the
 HTTP method + the resource name  as the key and the relevant axis2
 operation as the value. Therefore in the example both resources 
 having the
 same key and the value is replaced by the last one.

 So as a solution, a regex for the resource is kept in the map as
 the key, and when we invoke the resource it compares the regex with 
 the
 request url. But this will hit a performance issue, as we have to 
 compile
 all regex in the map each time we invoke resource.

 Any input regarding this is appreciated.

 Thanks
 --
 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




 --
 Sameera Jayasoma,
 Architect,

 WSO2, Inc. (http://wso2.com)
 email: same...@wso2.com
 

Re: [Architecture] carbon native linux platform packages

2014-01-06 Thread chris snow
Today I was thinking of more examples to help explain my previous email.
 Here is one example from the eclipse world:

Package: eclipse-jdt (3.8.0~rc4-1) -
http://packages.debian.org/wheezy/eclipse-jdt

dep: default-jre  Standard Java or Java compatible Runtime
or java5-runtime  virtual package provided by default-jre, gcj-4.6-jre,
gcj-4.7-jre, gcj-jre, openjdk-6-jre, openjdk-7-jre
or java6-runtime  virtual package provided by default-jre, openjdk-6-jre,
openjdk-7-jre

dep: eclipse-platform (= 3.8.0~rc4-1) Eclipse platform without development
plug-ins
..

Therefore:

$ apt-get install eclipse-jdt   # eclipse-jdt 3.8.0~rc4-1 also installs
eclipse-platform = 3.8.0~rc4-1

With chunk releases for Carbon 4.2+ being backward compatible, could the
same principle be applied:

$ apt-get install wso2-as   # wso2-as 5.0 also installs wso2-core-platform
= 4.20




On Sun, Jan 5, 2014 at 3:46 PM, chris snow chsnow...@gmail.com wrote:

 Has anyone ever looked at creating native linux platform installers for
 WSO2 products?  For example:

 - DEB for debian based distros
 - RPM for redhat based distros

 I've been thinking of how the tomcat package works on ubuntu where the
 latest major version (e.g. 7) completely replaces the previous version.

 However, from what I understand, wso2 features require a certain major +
 minor version + minimum chunk version of Carbon so there would need to be
 a packaged version of Carbon for each supported Carbon release, for example:

 - wso2-carbon-core-42.deb
 - wso2-carbon-core-50.deb
 - wso2-carbon-core-51.deb
 - etc

 However, products with a different major + minor version
 wso2-carbon-core-42, wso2-carbon-core-50, and wso2-carbon-core-51 could
 co-exist as they would be considered different packages (though ports would
 need to be selected as to avoid clashing).  With the approach, you could
 perform the following to install 4.2.x and 5.0.x side by side:

 apt-get install wso2-carbon-core-42.deb
 apt-get install wso2-carbon-core-50.deb

 An increase in the chunk version would cause the package to be upgraded
 (much the same as apt-get upgrade).  For example, version of
  wso2-carbon-core-42.deb (version chunk 2) would upgrade a previous
 installation of wso2-carbon-core-42.deb (version chunk 1).

 WSO2 products could be installed on top of the carbon core base as
 features, where there the feature has a dependency on the appropriate
 version of Carbon, for example:

 - wso2-as-52.deb would have a dependency on wso2-carbon-core-42.deb
 (version chunk 1+)

 Does this approach make sense?  Would it work?

 Many thanks,

 Chris






-- 
Check out my professional profile and connect with me on LinkedIn.
http://lnkd.in/cw5k69
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture


Re: [Architecture] Axis2 Request Delegation for Multiple parameters with the same base URL

2014-01-06 Thread Venura Kahawala
Hi Chanika,

IMO we can do little improvements to your code.

1. Please use string constants in 'getRegexForLocation' method.
2. In 'getRegexForLocation' method you can use StringBuilder.append instead
of concatenating strings with + operator
3. In 'getRegexForLocation' you can use *StringTokenizer *instead of split
operation since you are iterating through the split array.

Regards,
Venura


On Mon, Jan 6, 2014 at 8:54 PM, Chanika Geeganage chan...@wso2.com wrote:

 Please find the attached diff files for the changes done, as per the
 offline chat had with Sagara regarding this problem.

 Here are the load test results


 No of Threads Without the fix (tps)  With the
 fix (tps)
 1
 410 400
 5
 2100   2080
 100
 62606250

 Thanks


 On Sat, Jan 4, 2014 at 8:51 AM, Chanika Geeganage chan...@wso2.comwrote:




 On Sat, Jan 4, 2014 at 6:30 AM, Sagara Gunathunga sag...@wso2.comwrote:




 On Fri, Jan 3, 2014 at 5:06 PM, Chanika Geeganage chan...@wso2.comwrote:

 Hi,

 To fix that properly, we can compile the regex at deployment time and
 keep that compiled pattern as the key. But that will break the exciting
 code because of API changes. It is a utill class and as others are using it
 we can't change the API.



 Shall we have a chat on this Monday morning ?   Let's see whether we can
 find another  workaround.


 Sure. Will do



 Thanks !


 Thanks


 On Fri, Jan 3, 2014 at 4:07 PM, Samisa Abeysinghe sam...@wso2.comwrote:

 Is there any other way to fix the perf drop while fixing the issue?

 Thanks,
 Samisa...


 Samisa Abeysinghe

 Vice President Developer Evangelism

 WSO2 Inc.
 http://wso2.com



 On Fri, Jan 3, 2014 at 3:36 PM, Chanika Geeganage chan...@wso2.comwrote:

 Hi Samisa,

 The fix is for a issue occurred when we define multiple resources in
 a data service with the same resource name. For an example lets say we 
 want
 to define following resources in a data service. (This is described in 
 this
 thread)


 products/{id}
 products/{id}/name/{name}

 The current implementation does not give the desired output as it
 keeps only the resource name as the key. According to the given fix it
 keeps a regex as the key and it compiles all regex in the map each time 
 we
 invoke a request. That is why there is a performance drop.

 Thanks



 On Fri, Jan 3, 2014 at 3:20 PM, Samisa Abeysinghe sam...@wso2.comwrote:

 Why do we have a drop of TPS with the fix? Should we not optimize
 this for better performance?

 Thanks,
 Samisa...


 Samisa Abeysinghe

 Vice President Developer Evangelism

 WSO2 Inc.
 http://wso2.com



 On Fri, Jan 3, 2014 at 1:28 PM, Chanika Geeganage 
 chan...@wso2.comwrote:

 Hi,

 Here I have attached the changed code for the suggested solution
 (using a regex as the key). I ran some load tests and the results are
 listed below.

 No of Threads Without the fix (tps)
 With the fix (tps)
 1
 410 315
 5
 2010   1900
 100
 62606200

 Is it OK to proceed with this fix?

 Thanks



 On Thu, Dec 19, 2013 at 7:37 AM, Chanika Geeganage 
 chan...@wso2.com wrote:

 Hi Sameera,

 getConstantFromHTTPLocation method in [1]  is used to maintain the
 map in deployment time and getOperationFromHTTPLocation method is 
 called
 when you invoke the rest service in [2]

 [1]
 https://svn.wso2.org/repos/wso2/carbon/kernel/branches/4.2.0/dependencies/axis2/1.6.1-wso2v10/modules/kernel/src/org/apache/axis2/wsdl/WSDLUtil.java

 [2]
 https://svn.wso2.org/repos/wso2/carbon/kernel/branches/4.2.0/dependencies/axis2/1.6.1-wso2v10/modules/kernel/src/org/apache/axis2/dispatchers/HTTPLocationBasedDispatcher.java

 Thanks


 On Thu, Dec 19, 2013 at 12:51 AM, Sameera Jayasoma 
 same...@wso2.com wrote:

 Hi Chanika,

 Can you please gimme me some pointers to the relevant code blocks
 which are responsible for this situation?

 Thanks,
 Sameera.


 On Wed, Dec 18, 2013 at 3:29 PM, Chanika Geeganage 
 chan...@wso2.com wrote:

 Hi,

 This issue was come across when we invoke a rest resource
 deployed in DSS. According to the current implementation it fails to
 delegate different requests for same base URL. For an example lets 
 say we
 want to have following resources in the dataservice config

 products/{id}
 products/{id}/name/{name}

 According to the current implementation it maintains a map to
 keep the resource info in the deployment time. It keeps a string of 
 the
 HTTP method + the resource name  as the key and the relevant axis2
 operation as the value. Therefore in the example both resources 
 having the
 same key and the value is replaced by the last one.

 So as a solution, a regex for the resource is kept in the map as
 the key, and when we invoke the resource it compares the regex with 
 the
 request url. But this will hit a 

[Architecture] Fwd: [AppFactory] Create AppFactory applications from already existing application binaries

2014-01-06 Thread Shamika Ariyawansa
Hi Janaka,

This is not only for WAR files and will be supported all the other
application types which are currently supported by AppFactory like Jaggery.

IMO how about doing the scenario you mentioned like this as
a separate feature.

1. User creates the application in normal way where selecting the
application type and Repo type. So that the application will be created in
normal manner
2. In the Build and Repo page (or any other good place)  we will
be providing an extra functionality to connect with an external repository
and fetch the source code from there.

Why I think like this is dealing with source code is not something that has
to be done while creating the application.

WDYT?




On Tue, Jan 7, 2014 at 10:41 AM, Janaka Ranabahu jan...@wso2.com wrote:

 Hi Manjula,

 While I completely agree that this feature is something different from
 what I've stated, I'm trying to understand the usability of this feature.
 From what I've gathered so far from this discussion is that, we do not
 allow code modifications, versions and build for these kinds of
 applications. So basically this feature is only there to deploy, test and
 govern a pre-built artifact. But then, we loose many powerful development
 features that are provided by AppFactory.

 With this feature, the source code management, versioning and build(which
 are three important features of AF) is happening out of AppFactory and they
 have to manage them separately. But instead, what we need to do is to
 promote AppFactory for developers so that developers would be attracted to
 it. IMO, having a feature to create applications from an existing repo is
 more important in that context.

 WDYT?

 On Mon, Jan 6, 2014 at 7:24 PM, Manjula Rathnayake manju...@wso2.comwrote:

 Hi all,


 On Mon, Jan 6, 2014 at 6:48 PM, Ashansa Perera asha...@wso2.com wrote:

 As I feel creating an application pointing to an existing code base is
 different than allowing to upload an artifact and create an application,
 since this will not include any source code management. So we should
 consider those as two different use cases.
 IMO we can relate the use case that Janaka has mentioned to our main
 flow of application creation where we can provide the option of
- creating an application pointing to an existing source code ( so AF
 can clone that and create application)
- creating an application with default template

 +1, this feature is about uploading a war file and no source code is
 involved.


 Also, is this only about war files or do we support all the applications
 types of AF and are we going to support other app types like aar and car?

 Thanks,
 Janaka

 thank you.



 On Mon, Jan 6, 2014 at 5:45 PM, Harsha Thirimanna hars...@wso2.comwrote:

 Hi Janaka,

 +1 for that.

 There will some work to do this. Because

 1. we should process the pom file of that external repository and
 change artifactId, groupId to our one.
 2. we have to have credentials to access external repository.

  thanks



 *Harsha Thirimanna*

 Senior Software Engineer; WSO2, Inc.; http://wso2.com
 * http://www.apache.org/*
 * email: **hars...@wso2.com* az...@wso2.com* cell: +94 71 5186770*
 * twitter: **http://twitter.com/ http://twitter.com/afkham_azeez*
 *harshathirimann linked-in: **http:
 http://lk.linkedin.com/in/afkhamazeez**//www.linkedin.com/pub/harsha-thirimanna/10/ab8/122
 http://www.linkedin.com/pub/harsha-thirimanna/10/ab8/122*

  *Lean . Enterprise . Middleware*



 On Mon, Jan 6, 2014 at 5:28 PM, Janaka Ranabahu jan...@wso2.comwrote:

 Hi Shamika,


 On Mon, Jan 6, 2014 at 4:43 PM, Shamika Ariyawansa 
 sham...@wso2.comwrote:

 Hi All,

 New feature that is going to be introduced to AppFactory is creating
 a new application by uploading exiting binary file of an application. e.g
 WAR

 *User Scenario*

 1. User logs on to the system, goes to the application creation page.
 2. In there user provides basic information related to the
 application, such as name, key, description then he/she would be able to
 create the application by choosing one of the following options,

  a. Create the application from the scratch by selecting the
 repository type and application type which maps
 with existing functionality. *OR*
  b. Create the application by uploading the binary file and
 selecting the binary file type. By doing so the application will
 be created as non build-able application.

 Can we improve this so that a user can create an application pointing
 to a existing source code so that AF can clone that instead of the default
 template?

 Thanks,
  Janaka


 3. In Repos and Builds page user will be able to see the
 uploaded application and he/she will be able to do following operations
 from there,
   a. Delete the existing application.
   b. Upload new version of the same application. - Provides a way to
 upload new binary file.
   c. Test the application by deploying to Dev cloud.

 Note that for applications created like this, source repository
 paths, build options 

Re: [Architecture] [AppFactory] Create AppFactory applications from already existing application binaries

2014-01-06 Thread Ajanthan Balachandran
On Mon, Jan 6, 2014 at 4:43 PM, Shamika Ariyawansa sham...@wso2.com wrote:

 Hi All,

 New feature that is going to be introduced to AppFactory is creating a
 new application by uploading exiting binary file of an application. e.gWAR

 *User Scenario*

 1. User logs on to the system, goes to the application creation page.
 2. In there user provides basic information related to the application,
 such as name, key, description then he/she would be able to create the
 application by choosing one of the following options,

  a. Create the application from the scratch by selecting the repository
 type and application type which maps with existing functionality. *OR*
  b. Create the application by uploading the binary file and selecting the
 binary file type. By doing so the application will be created as non build
 -able application.

 3. In Repos and Builds page user will be able to see the
 uploaded application and he/she will be able to do following operationsfrom 
 there,
   a. Delete the existing application.
   b. Upload new version of the same application. - Provides a way to
 upload new binary file.

Re uploading should be allowed in the dev stage only. Isn't it?

   c. Test the application by deploying to Dev cloud.

 Note that for applications created like this, source repository paths,
 build options and not shown to the users.

 4. From Life Cycle Management page user will be able to Promote and Demote
 the application through different life cycles.

 *Solution*

 So far in AppFactory we maintain two logical types of application flows.
 Buildable and non-Buildable. Buildabale applications are mainly handled
 and deployed by the buildserver (Jenkins) whereas non-Buildable are
 maintained and deployed by the AppFactory itself.
 uploading existing application functionality will
 be implemented considering Non-Buildable application flow as follows.

 [image: Inline image 2]

 Further App Creation, Build and Repos and other UIs will
 be changed accordingly.


 Regards,
 --
 Shamika Ariyawansa
 Senior Software Engineer
 WSO2, Inc.; http://wso2.com

 LK -  +94 7639629 Ext 5999
 US - +1 408 754 7388 Ext 51732
 Mob:+ 94 772929486

 *twitter: 
 **https://twitter.com/Amila_Shamika*https://twitter.com/Amila_Shamika
 * linked-in: *http://www.linkedin.com/pub/dir/Shamika/Ariyawansa

 *Lean . Enterprise . Middleware*




-- 
ajanthan
-- 
Ajanthan Balachandiran
Senior Software Engineer;
Solutions Technologies Team ;WSO2, Inc.;  http://wso2.com/

email: ajanthan http://goog_595075977@wso2.com; cell: +94775581497
blog: http://bkayts.blogspot.com/

Lean . Enterprise . Middleware
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture


Re: [Architecture] [AppFactory] Create AppFactory applications from already existing application binaries

2014-01-06 Thread Shamika Ariyawansa
On Tue, Jan 7, 2014 at 11:05 AM, Ajanthan Balachandran ajant...@wso2.comwrote:




 On Mon, Jan 6, 2014 at 4:43 PM, Shamika Ariyawansa sham...@wso2.comwrote:

 Hi All,

 New feature that is going to be introduced to AppFactory is creating a
 new application by uploading exiting binary file of an application. e.gWAR

 *User Scenario*

 1. User logs on to the system, goes to the application creation page.
 2. In there user provides basic information related to the application,
 such as name, key, description then he/she would be able to create the
 application by choosing one of the following options,

  a. Create the application from the scratch by selecting the repository
 type and application type which maps with existing functionality. *OR*
  b. Create the application by uploading the binary file and selecting
 the binary file type. By doing so the application will be created as non
 build-able application.

 3. In Repos and Builds page user will be able to see the
 uploaded application and he/she will be able to do following operationsfrom 
 there,
   a. Delete the existing application.
   b. Upload new version of the same application. - Provides a way to
 upload new binary file.

 Re uploading should be allowed in the dev stage only. Isn't it?

Yes


   c. Test the application by deploying to Dev cloud.

 Note that for applications created like this, source repository paths,
 build options and not shown to the users.

 4. From Life Cycle Management page user will be able to Promote and
 Demote the application through different life cycles.

 *Solution*

 So far in AppFactory we maintain two logical types of application flows.
 Buildable and non-Buildable. Buildabale applications are mainly handled
 and deployed by the buildserver (Jenkins) whereas non-Buildable are
 maintained and deployed by the AppFactory itself.
 uploading existing application functionality will
 be implemented considering Non-Buildable application flow as follows.

 [image: Inline image 2]

 Further App Creation, Build and Repos and other UIs will
 be changed accordingly.


 Regards,
 --
 Shamika Ariyawansa
 Senior Software Engineer
 WSO2, Inc.; http://wso2.com

 LK -  +94 7639629 Ext 5999
 US - +1 408 754 7388 Ext 51732
 Mob:+ 94 772929486

 *twitter: 
 **https://twitter.com/Amila_Shamika*https://twitter.com/Amila_Shamika
 * linked-in: *http://www.linkedin.com/pub/dir/Shamika/Ariyawansa

 *Lean . Enterprise . Middleware*




 --
 ajanthan
 --
 Ajanthan Balachandiran
 Senior Software Engineer;
 Solutions Technologies Team ;WSO2, Inc.;  http://wso2.com/

 email: ajanthan http://goog_595075977@wso2.com; cell: +94775581497
 blog: http://bkayts.blogspot.com/


 Lean . Enterprise . Middleware




-- 
Shamika Ariyawansa
Senior Software Engineer
WSO2, Inc.; http://wso2.com

LK -  +94 7639629 Ext 5999
US - +1 408 754 7388 Ext 51732
Mob:+ 94 772929486

*twitter: 
**https://twitter.com/Amila_Shamika*https://twitter.com/Amila_Shamika
*linked-in: *http://www.linkedin.com/pub/dir/Shamika/Ariyawansa

*Lean . Enterprise . Middleware*
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture


Re: [Architecture] [AppFactory] Create AppFactory applications from already existing application binaries

2014-01-06 Thread Shamika Ariyawansa
Hi Harsha,


On Mon, Jan 6, 2014 at 8:09 PM, Harsha Thirimanna hars...@wso2.com wrote:

 Hi Shamika,
 In this case, do we restrict exposing repository URL to user to
 checkout/checkin this artifact ? Because even though we not show this URL
 in AppFactory UI , user can see this after login to the Git server.


We are trying to resolve this issue by introducing an permission (Read
only) so that even though the Repo is visible the user can do modifications
to it. However this is still to be found out.


 thanks


 *Harsha Thirimanna*

 Senior Software Engineer; WSO2, Inc.; http://wso2.com
 * http://www.apache.org/*
 * email: **hars...@wso2.com* az...@wso2.com* cell: +94 71 5186770*
 * twitter: **http://twitter.com/ http://twitter.com/afkham_azeez*
 *harshathirimann linked-in: **http:
 http://lk.linkedin.com/in/afkhamazeez**//www.linkedin.com/pub/harsha-thirimanna/10/ab8/122
 http://www.linkedin.com/pub/harsha-thirimanna/10/ab8/122*

  *Lean . Enterprise . Middleware*



 On Mon, Jan 6, 2014 at 4:43 PM, Shamika Ariyawansa sham...@wso2.comwrote:

 Hi All,

 New feature that is going to be introduced to AppFactory is creating a
 new application by uploading exiting binary file of an application. e.g WAR

 *User Scenario*

 1. User logs on to the system, goes to the application creation page.
 2. In there user provides basic information related to the application,
 such as name, key, description then he/she would be able to create the
 application by choosing one of the following options,

  a. Create the application from the scratch by selecting the repository
 type and application type which maps with existing functionality. *OR*
  b. Create the application by uploading the binary file and selecting
 the binary file type. By doing so the application will be created as
 non build-able application.

 3. In Repos and Builds page user will be able to see the
 uploaded application and he/she will be able to do following operations
 from there,
   a. Delete the existing application.
   b. Upload new version of the same application. - Provides a way to
 upload new binary file.
   c. Test the application by deploying to Dev cloud.

 Note that for applications created like this, source repository paths,
 build options and not shown to the users.

 4. From Life Cycle Management page user will be able to Promote and
 Demote the application through different life cycles.

 *Solution*

 So far in AppFactory we maintain two logical types of application flows.
 Buildable and non-Buildable. Buildabale applications are mainly handled
 and deployed by the buildserver (Jenkins) whereas non-Buildable are
 maintained and deployed by the AppFactory itself.
 uploading existing application functionality will
 be implemented considering Non-Buildable application flow as follows.

 [image: Inline image 2]

 Further App Creation, Build and Repos and other UIs will
 be changed accordingly.


 Regards,
 --
 Shamika Ariyawansa
 Senior Software Engineer
 WSO2, Inc.; http://wso2.com

 LK -  +94 7639629 Ext 5999
 US - +1 408 754 7388 Ext 51732
 Mob:+ 94 772929486

 *twitter: 
 **https://twitter.com/Amila_Shamika*https://twitter.com/Amila_Shamika
 * linked-in: *http://www.linkedin.com/pub/dir/Shamika/Ariyawansa

 *Lean . Enterprise . Middleware*





-- 
Shamika Ariyawansa
Senior Software Engineer
WSO2, Inc.; http://wso2.com

LK -  +94 7639629 Ext 5999
US - +1 408 754 7388 Ext 51732
Mob:+ 94 772929486

*twitter: 
**https://twitter.com/Amila_Shamika*https://twitter.com/Amila_Shamika
*linked-in: *http://www.linkedin.com/pub/dir/Shamika/Ariyawansa

*Lean . Enterprise . Middleware*
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture


Re: [Architecture] [AppFactory] Create AppFactory applications from already existing application binaries

2014-01-06 Thread Janaka Ranabahu
Hi Manjula,


On Tue, Jan 7, 2014 at 11:05 AM, Manjula Rathnayake manju...@wso2.comwrote:

 Hi Janaka,


 On Tue, Jan 7, 2014 at 10:41 AM, Janaka Ranabahu jan...@wso2.com wrote:

 Hi Manjula,

 While I completely agree that this feature is something different from
 what I've stated, I'm trying to understand the usability of this feature.
 From what I've gathered so far from this discussion is that, we do not
 allow code modifications, versions and build for these kinds of
 applications. So basically this feature is only there to deploy, test and
 govern a pre-built artifact. But then, we loose many powerful development
 features that are provided by AppFactory.

 With this feature, the source code management, versioning and build(which
 are three important features of AF) is happening out of AppFactory and they
 have to manage them separately. But instead, what we need to do is to
 promote AppFactory for developers so that developers would be attracted to
 it. IMO, having a feature to create applications from an existing repo is
 more important in that context.

 I understand your point, but uploading a war file(or any deployable
 artifact) is the feature we implement here. There might be situations where
 users do not need to share their source code into our source repository.
 They just need to maintain binary artifacts within appfactory. But the
 feature you mentioned is a valid feature we can provide and can be
 implemented separately.


Understood.

I have few more points to clarify.

Now when a user creates such application project do we allow him to upload
the same binary to the same version of that application. Say that the user
found a bug in the uploaded application. What is the procedure of fixing
the bug and testing it using AF. Does he need to create a new version to
upload the new artifact or can he simply replace the existing artifact in
current version?

How can this help to enforce the governance best practices of an
application? Eg:- when an application version in promoted to the production
environment, how do we guarantee that there will be no commits and builds
on that version? Even though that we can stop deployment from AF side,
there is no guarantee that the original source is in the same state.

Do we rename the binary to AppFactory default format when creating these
types of applications? Otherwise default applications in AF will have one
format(applicaiton_key-version) where this would have something else. Also
If not, how does features like log download(which needs to find the
application name to download logs) will work?

Do we allow developers to be invited into these types of applications? If
so what are the functionality available to them? Is it only deployment and
developer testing or do we allow a developer to upload a new binary/new
version of the artifact?

Thanks,
Janaka


 thank you.


 WDYT?

 On Mon, Jan 6, 2014 at 7:24 PM, Manjula Rathnayake manju...@wso2.comwrote:

 Hi all,


 On Mon, Jan 6, 2014 at 6:48 PM, Ashansa Perera asha...@wso2.com wrote:

 As I feel creating an application pointing to an existing code base is
 different than allowing to upload an artifact and create an application,
 since this will not include any source code management. So we should
 consider those as two different use cases.
 IMO we can relate the use case that Janaka has mentioned to our main
 flow of application creation where we can provide the option of
- creating an application pointing to an existing source code ( so
 AF can clone that and create application)
- creating an application with default template

 +1, this feature is about uploading a war file and no source code is
 involved.


 Also, is this only about war files or do we support all the applications
 types of AF and are we going to support other app types like aar and car?

 Thanks,
 Janaka

 thank you.



 On Mon, Jan 6, 2014 at 5:45 PM, Harsha Thirimanna hars...@wso2.comwrote:

 Hi Janaka,

 +1 for that.

 There will some work to do this. Because

 1. we should process the pom file of that external repository and
 change artifactId, groupId to our one.
 2. we have to have credentials to access external repository.

  thanks



 *Harsha Thirimanna*

 Senior Software Engineer; WSO2, Inc.; http://wso2.com
 * http://www.apache.org/*
 * email: **hars...@wso2.com* az...@wso2.com* cell: +94 71 5186770*
 * twitter: **http://twitter.com/ http://twitter.com/afkham_azeez*
 *harshathirimann linked-in: **http:
 http://lk.linkedin.com/in/afkhamazeez**//www.linkedin.com/pub/harsha-thirimanna/10/ab8/122
 http://www.linkedin.com/pub/harsha-thirimanna/10/ab8/122*

  *Lean . Enterprise . Middleware*



 On Mon, Jan 6, 2014 at 5:28 PM, Janaka Ranabahu jan...@wso2.comwrote:

 Hi Shamika,


 On Mon, Jan 6, 2014 at 4:43 PM, Shamika Ariyawansa 
 sham...@wso2.comwrote:

 Hi All,

 New feature that is going to be introduced to AppFactory is creating
 a new application by uploading exiting binary file of an application. 
 e.g
 WAR

 

Re: [Architecture] [AppFactory] Create AppFactory applications from already existing application binaries

2014-01-06 Thread Manjula Rathnayake
Hi Janaka,


On Tue, Jan 7, 2014 at 11:33 AM, Janaka Ranabahu jan...@wso2.com wrote:

 Hi Manjula,


 On Tue, Jan 7, 2014 at 11:05 AM, Manjula Rathnayake manju...@wso2.comwrote:

 Hi Janaka,


 On Tue, Jan 7, 2014 at 10:41 AM, Janaka Ranabahu jan...@wso2.com wrote:

 Hi Manjula,

 While I completely agree that this feature is something different from
 what I've stated, I'm trying to understand the usability of this feature.
 From what I've gathered so far from this discussion is that, we do not
 allow code modifications, versions and build for these kinds of
 applications. So basically this feature is only there to deploy, test and
 govern a pre-built artifact. But then, we loose many powerful development
 features that are provided by AppFactory.

 With this feature, the source code management, versioning and
 build(which are three important features of AF) is happening out of
 AppFactory and they have to manage them separately. But instead, what we
 need to do is to promote AppFactory for developers so that developers would
 be attracted to it. IMO, having a feature to create applications from an
 existing repo is more important in that context.

 I understand your point, but uploading a war file(or any deployable
 artifact) is the feature we implement here. There might be situations where
 users do not need to share their source code into our source repository.
 They just need to maintain binary artifacts within appfactory. But the
 feature you mentioned is a valid feature we can provide and can be
 implemented separately.


 Understood.

 I have few more points to clarify.

 Now when a user creates such application project do we allow him to upload
 the same binary to the same version of that application. Say that the user
 found a bug in the uploaded application. What is the procedure of fixing
 the bug and testing it using AF. Does he need to create a new version to
 upload the new artifact or can he simply replace the existing artifact in
 current version?

If it is development stage, it can be replaced with new binary file. But if
it is in other stages, it has to follow application life cycle. They can
use issue tracker to report bugs and demote on testing stage or even in
production stage. As per the diagram, initial development stage artifacts
are stored in gitblit.


 How can this help to enforce the governance best practices of an
 application? Eg:- when an application version in promoted to the production
 environment, how do we guarantee that there will be no commits and builds
 on that version? Even though that we can stop deployment from AF side,
 there is no guarantee that the original source is in the same state.

Yes, If someone manage their source code outside of AF, we can not do
anything on that. But still they can use application life cycle flow, issue
tracking, user management, log viewers like features.


 Do we rename the binary to AppFactory default format when creating these
 types of applications? Otherwise default applications in AF will have one
 format(applicaiton_key-version) where this would have something else. Also
 If not, how does features like log download(which needs to find the
 application name to download logs) will work?

This is a limitation in appfactory. However we have decided to enforce this
as artifact name matters in many places of appfactory(security, logs,
deployment,etc). So we have to rename the binary.


 Do we allow developers to be invited into these types of applications? If
 so what are the functionality available to them? Is it only deployment and
 developer testing or do we allow a developer to upload a new binary/new
 version of the artifact?

Application upload is done by app owners but we can allow developers as
well in any case if appfactory users need to do so, as it is configurable.

This is a feature to bring current existing applications into AppFactory
and manage application life cycle. When they need to bring the source code,
AF can provide a link to add source. In that case, we can commit the
initial code and change the application type to default source code based
application types. As you mentioned, some part of governance story is
missing due to the fact that source code control is not done via AppFactory.

thank you.


 Thanks,
 Janaka


 thank you.


 WDYT?

 On Mon, Jan 6, 2014 at 7:24 PM, Manjula Rathnayake manju...@wso2.comwrote:

 Hi all,


 On Mon, Jan 6, 2014 at 6:48 PM, Ashansa Perera asha...@wso2.comwrote:

 As I feel creating an application pointing to an existing code base is
 different than allowing to upload an artifact and create an application,
 since this will not include any source code management. So we should
 consider those as two different use cases.
 IMO we can relate the use case that Janaka has mentioned to our main
 flow of application creation where we can provide the option of
- creating an application pointing to an existing source code ( so
 AF can clone that and create application)
- creating 

Re: [Architecture] [AppFactory] Create AppFactory applications from already existing application binaries

2014-01-06 Thread Harsha Thirimanna
*please look at the comment.*



On Tue, Jan 7, 2014 at 11:33 AM, Janaka Ranabahu jan...@wso2.com wrote:

 Hi Manjula,


 On Tue, Jan 7, 2014 at 11:05 AM, Manjula Rathnayake manju...@wso2.comwrote:

 Hi Janaka,


 On Tue, Jan 7, 2014 at 10:41 AM, Janaka Ranabahu jan...@wso2.com wrote:

 Hi Manjula,

 While I completely agree that this feature is something different from
 what I've stated, I'm trying to understand the usability of this feature.
 From what I've gathered so far from this discussion is that, we do not
 allow code modifications, versions and build for these kinds of
 applications. So basically this feature is only there to deploy, test and
 govern a pre-built artifact. But then, we loose many powerful development
 features that are provided by AppFactory.

 With this feature, the source code management, versioning and
 build(which are three important features of AF) is happening out of
 AppFactory and they have to manage them separately. But instead, what we
 need to do is to promote AppFactory for developers so that developers would
 be attracted to it. IMO, having a feature to create applications from an
 existing repo is more important in that context.

 I understand your point, but uploading a war file(or any deployable
 artifact) is the feature we implement here. There might be situations where
 users do not need to share their source code into our source repository.
 They just need to maintain binary artifacts within appfactory. But the
 feature you mentioned is a valid feature we can provide and can be
 implemented separately.


 Understood.

 I have few more points to clarify.

 Now when a user creates such application project do we allow him to upload
 the same binary to the same version of that application. Say that the user
 found a bug in the uploaded application. What is the procedure of fixing
 the bug and testing it using AF. Does he need to create a new version to
 upload the new artifact or can he simply replace the existing artifact in
 current version?


*Yes , we should allow to delete existing one and upload new one.*


 How can this help to enforce the governance best practices of an
 application? Eg:- when an application version in promoted to the production
 environment, how do we guarantee that there will be no commits and builds
 on that version? Even though that we can stop deployment from AF side,
 there is no guarantee that the original source is in the same state.


*In this case, our repository is built artifact , not the source. if they
want to put new build , it is new version of that.*




 Do we rename the binary to AppFactory default format when creating these
 types of applications? Otherwise default applications in AF will have one
 format(applicaiton_key-version) where this would have something else. Also
 If not, how does features like log download(which needs to find the
 application name to download logs) will work?


*Yes, I think we should rename to our standard.*




 Do we allow developers to be invited into these types of applications? If
 so what are the functionality available to them? Is it only deployment and
 developer testing or do we allow a developer to upload a new binary/new
 version of the artifact?


*Yes , we allow to do version and upload new artifact to that*




 Thanks,
 Janaka


 thank you.


 WDYT?

 On Mon, Jan 6, 2014 at 7:24 PM, Manjula Rathnayake manju...@wso2.comwrote:

 Hi all,


 On Mon, Jan 6, 2014 at 6:48 PM, Ashansa Perera asha...@wso2.comwrote:

 As I feel creating an application pointing to an existing code base is
 different than allowing to upload an artifact and create an application,
 since this will not include any source code management. So we should
 consider those as two different use cases.
 IMO we can relate the use case that Janaka has mentioned to our main
 flow of application creation where we can provide the option of
- creating an application pointing to an existing source code ( so
 AF can clone that and create application)
- creating an application with default template

 +1, this feature is about uploading a war file and no source code is
 involved.


 Also, is this only about war files or do we support all the applications
 types of AF and are we going to support other app types like aar and car?

 Thanks,
 Janaka

 thank you.



 On Mon, Jan 6, 2014 at 5:45 PM, Harsha Thirimanna hars...@wso2.comwrote:

 Hi Janaka,

 +1 for that.

 There will some work to do this. Because

 1. we should process the pom file of that external repository and
 change artifactId, groupId to our one.
 2. we have to have credentials to access external repository.

  thanks



 *Harsha Thirimanna*

 Senior Software Engineer; WSO2, Inc.; http://wso2.com
 * http://www.apache.org/*
 * email: **hars...@wso2.com* az...@wso2.com* cell: +94 71 5186770*
 * twitter: **http://twitter.com/ http://twitter.com/afkham_azeez*
 *harshathirimann linked-in: **http:
 

Re: [Architecture] [AppFactory] Create AppFactory applications from already existing application binaries

2014-01-06 Thread Janaka Ranabahu
Hi Manjula,

Thanks for the clarifications. Seems good.

Thanks,
Janaka


On Tue, Jan 7, 2014 at 11:54 AM, Manjula Rathnayake manju...@wso2.comwrote:

 Hi Janaka,


 On Tue, Jan 7, 2014 at 11:33 AM, Janaka Ranabahu jan...@wso2.com wrote:

 Hi Manjula,


 On Tue, Jan 7, 2014 at 11:05 AM, Manjula Rathnayake manju...@wso2.comwrote:

 Hi Janaka,


 On Tue, Jan 7, 2014 at 10:41 AM, Janaka Ranabahu jan...@wso2.comwrote:

 Hi Manjula,

 While I completely agree that this feature is something different from
 what I've stated, I'm trying to understand the usability of this feature.
 From what I've gathered so far from this discussion is that, we do not
 allow code modifications, versions and build for these kinds of
 applications. So basically this feature is only there to deploy, test and
 govern a pre-built artifact. But then, we loose many powerful development
 features that are provided by AppFactory.

 With this feature, the source code management, versioning and
 build(which are three important features of AF) is happening out of
 AppFactory and they have to manage them separately. But instead, what we
 need to do is to promote AppFactory for developers so that developers would
 be attracted to it. IMO, having a feature to create applications from an
 existing repo is more important in that context.

 I understand your point, but uploading a war file(or any deployable
 artifact) is the feature we implement here. There might be situations where
 users do not need to share their source code into our source repository.
 They just need to maintain binary artifacts within appfactory. But the
 feature you mentioned is a valid feature we can provide and can be
 implemented separately.


 Understood.

 I have few more points to clarify.

 Now when a user creates such application project do we allow him to
 upload the same binary to the same version of that application. Say that
 the user found a bug in the uploaded application. What is the procedure of
 fixing the bug and testing it using AF. Does he need to create a new
 version to upload the new artifact or can he simply replace the existing
 artifact in current version?

 If it is development stage, it can be replaced with new binary file. But
 if it is in other stages, it has to follow application life cycle. They can
 use issue tracker to report bugs and demote on testing stage or even in
 production stage. As per the diagram, initial development stage artifacts
 are stored in gitblit.


 How can this help to enforce the governance best practices of an
 application? Eg:- when an application version in promoted to the production
 environment, how do we guarantee that there will be no commits and builds
 on that version? Even though that we can stop deployment from AF side,
 there is no guarantee that the original source is in the same state.

 Yes, If someone manage their source code outside of AF, we can not do
 anything on that. But still they can use application life cycle flow, issue
 tracking, user management, log viewers like features.


 Do we rename the binary to AppFactory default format when creating these
 types of applications? Otherwise default applications in AF will have one
 format(applicaiton_key-version) where this would have something else. Also
 If not, how does features like log download(which needs to find the
 application name to download logs) will work?

 This is a limitation in appfactory. However we have decided to enforce
 this as artifact name matters in many places of appfactory(security, logs,
 deployment,etc). So we have to rename the binary.


 Do we allow developers to be invited into these types of applications? If
 so what are the functionality available to them? Is it only deployment and
 developer testing or do we allow a developer to upload a new binary/new
 version of the artifact?

 Application upload is done by app owners but we can allow developers as
 well in any case if appfactory users need to do so, as it is configurable.

 This is a feature to bring current existing applications into AppFactory
 and manage application life cycle. When they need to bring the source code,
 AF can provide a link to add source. In that case, we can commit the
 initial code and change the application type to default source code based
 application types. As you mentioned, some part of governance story is
 missing due to the fact that source code control is not done via AppFactory.

 thank you.


 Thanks,
 Janaka


 thank you.


 WDYT?

 On Mon, Jan 6, 2014 at 7:24 PM, Manjula Rathnayake 
 manju...@wso2.comwrote:

 Hi all,


 On Mon, Jan 6, 2014 at 6:48 PM, Ashansa Perera asha...@wso2.comwrote:

 As I feel creating an application pointing to an existing code base
 is different than allowing to upload an artifact and create an 
 application,
 since this will not include any source code management. So we should
 consider those as two different use cases.
 IMO we can relate the use case that Janaka has mentioned to our main
 flow of