| Author |
Message
|
| EricCox |
 Posted: Fri Apr 05, 2013 7:16 am Post subject: How to Revert from Application back to normal Project |
 |
|
Master
Joined: 08 Apr 2011
Posts: 292
|
To all,
How is the suggested way to revert back to a normal project after converting to an application? I don't find the menu items to support this. It isn't a one way street is it?
Thanks,
Eric |
|
| Back to top |
|
 |
| mqjeff |
| Posted: Fri Apr 05, 2013 7:18 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
Yes, it's a one-way street.
But that doesn't mean anything.
Nothing prevents you from renaming the application, creating a new message flow project, and moving everything. |
|
| Back to top |
|
|
| NealM |
| Posted: Fri Apr 05, 2013 7:39 am Post subject: |
|
|
Master
Joined: 22 Feb 2011
Posts: 230
Location: NC or Utah (depends)
|
| It's sorta sad really. To me the biggest reason to use an Application would be to test out differences between two versions of a flow(s) or common subflow(s). But once worked out, I would perhaps want to revert to a broker project and take advantage of the shared libraries. There really should be an easier way to revert. |
|
| Back to top |
|
|
| EricCox |
| Posted: Fri Apr 05, 2013 7:43 am Post subject: Beware of the one way street |
|
|
Master
Joined: 08 Apr 2011
Posts: 292
|
IBM has put me in the precarious position of having recommended a path forward with no way back.
Source control systems and release managers such as myself don't like to make messes in our source code repository. Now I have to either manually change the code in the .project file or create a new version of the project with a new name. Neither is acceptable. I should be able to revert the project back to its original form through a supported feature.
I'm not happy that they did this to me. This is now going to cost me time to fix. |
|
| Back to top |
|
|
| lancelotlinc |
| Posted: Fri Apr 05, 2013 7:48 am Post subject: |
|
|
Jedi Knight
Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA
|
Unit testing hopefully would have pointed out this issue before the source code was committed by the developer to the SCR.
_________________
http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER |
|
| Back to top |
|
|
| EricCox |
| Posted: Fri Apr 05, 2013 7:52 am Post subject: Moving Forward |
|
|
Master
Joined: 08 Apr 2011
Posts: 292
|
| Finding a company and business unit that is focused on moving forward with technology and not backward would also solve this. |
|
| Back to top |
|
|
| smdavies99 |
| Posted: Fri Apr 05, 2013 7:53 am Post subject: |
|
|
Jedi Council
Joined: 10 Feb 2003
Posts: 6076
Location: Somewhere over the Rainbow this side of Never-never land.
|
| lancelotlinc wrote: |
| Unit testing hopefully would have pointed out this issue before the source code was committed by the developer to the SCR. |
Or a new 'application POC' branch could have been created.
_________________
WMQ User since 1999
MQSI/WBI/WMB/'Thingy' User since 2002
Linux user since 1995
Every time you reinvent the wheel the more square it gets (anon). If in doubt think and investigate before you ask silly questions. |
|
| Back to top |
|
|
| EricCox |
| Posted: Fri Apr 05, 2013 7:57 am Post subject: POC Branch |
|
|
Master
Joined: 08 Apr 2011
Posts: 292
|
| Yes, I made the polyana assumption the company wanted to move forward with technology. |
|
| Back to top |
|
|
| Vitor |
| Posted: Fri Apr 05, 2013 9:26 am Post subject: Re: POC Branch |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| EricCox wrote: |
| Yes, I made the polyana assumption the company wanted to move forward with technology. |
You Fool! 
Fallen for the oldest management trick in the book; the technology bait & switch.
We've all fallen for that at least once.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| rekarm01 |
| Posted: Fri Apr 05, 2013 10:25 am Post subject: Re: Beware of the one way street |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 1415
|
| EricCox wrote: |
IBM has put me in the precarious position of having recommended a path forward with no way back.
Source control systems and release managers such as myself don't like to make messes in our source code repository. Now I have to either manually change the code in the .project file or create a new version of the project with a new name. Neither is acceptable. I should be able to revert the project back to its original form through a supported feature. |
Another option is to check out the prior version of the affected .project files from the source code repository, and refresh the workspace. That seems to work.
| NealM wrote: |
| It's sorta sad really. To me the biggest reason to use an Application would be to test out differences between two versions of a flow(s) or common subflow(s). But once worked out, I would perhaps want to revert to a broker project and take advantage of the shared libraries. |
Please explain this. Why can't applications take advantage of the shared libraries? |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Fri Apr 05, 2013 11:10 am Post subject: Re: Beware of the one way street |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| rekarm01 wrote: |
Please explain this. Why can't applications take advantage of the shared libraries? |
I think what was meant here is that in order to take advantage of a change in a library/flow, you have to compile and redeploy the application, whereas if it is in the default application space, everybody in that space gets the change on deploy of the resource... 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| mqjeff |
| Posted: Fri Apr 05, 2013 11:29 am Post subject: Re: Beware of the one way street |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| EricCox wrote: |
IBM has put me in the precarious position of having recommended a path forward with no way back.
Source control systems and release managers such as myself don't like to make messes in our source code repository. Now I have to either manually change the code in the .project file or create a new version of the project with a new name. Neither is acceptable. I should be able to revert the project back to its original form through a supported feature.
I'm not happy that they did this to me. This is now going to cost me time to fix. |
It should take you about five minutes. And doesn't actually require a new project of any kind.
The suggestion I made assumed you had no version control of any kind, because the question as stated doesn't make any sense if you have version control. As mentioned, if you have version control, just roll back any changes that were made to resources that are NOT broker code resources - .project, and etc. files. |
|
| Back to top |
|
|
| NealM |
| Posted: Fri Apr 05, 2013 12:27 pm Post subject: |
|
|
Master
Joined: 22 Feb 2011
Posts: 230
Location: NC or Utah (depends)
|
| Quote: |
fjb_saper wrote:
| Quote: |
rekarm01 wrote:
Please explain this. Why can't applications take advantage of the shared libraries? |
I think what was meant here is that in order to take advantage of a change in a library/flow, you have to compile and redeploy the application, whereas if it is in the default application space, everybody in that space gets the change on deploy of the resource... |
Yes, that and the fact that there is only one copy of the library at the EG level, shared by all independent broker projects using it, whereas there is a copy of the library in each application using it. So if you have a common subflow(s) used in hundreds of deployed flows......
Also, see my self-updated Any MB8 "rules of thumb" for library subflows topic. |
|
| Back to top |
|
|
| rekarm01 |
| Posted: Mon Apr 08, 2013 12:38 am Post subject: Re: Beware of the one way street |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 1415
|
| fjb_saper wrote: |
| rekarm01 wrote: |
| Please explain this. Why can't applications take advantage of the shared libraries? |
I think what was meant here is that in order to take advantage of a change in a library/flow, you have to compile and redeploy the application, whereas if it is in the default application space, everybody in that space gets the change on deploy of the resource... |
Ok, that seems a lot more obvious now. Thanks. |
|
| Back to top |
|
|
|
|
