Home » Archived » EPF » Migration to newever library version
|
| Re: Migration to newever library version [message #36425 is a reply to message #36070] |
Fri, 03 August 2007 15:40   |
 J. Fincher
Messages: 14
Registered: July 2009 |
Junior Member |
|
|
Hello,
I have a similar question.
I've been working with OpenUP 0.9 to customize it for our use. I created a
separate library, created a plugin for our use, and imported the OpenUp 0.9
plugins for reference. I would like to do the same with OpenUP 1.0.
However, when I try to import the OpenUp 1.0 plugin, the import function is
"seeing" the new plugin as being the same as the existing plug in. The two
plugins have both been renamed from within EPFC.
I've tried locating information on the import/export function in the help
system and online to see if I'm doing something wrong, but I haven't yet
found anything that addresses this.
Any help would be greatly appreciated.
Thanks,
Jan Fincher, Business Applications Analyst
Florida Div. of Rehab & Liq
jan.fincher@fldfs.com
"Roman Smirak" <roman.smirak@tietoenator.com> wrote in message
news:f87j6j$3v7$1@build.eclipse.org...
> Hi,
>
> I have just downloaded latest version of OpenUP library and tried to
> migrate my plugin to this.
>
> My plugin has been developed on OpenUP 0.9 distributed with Composer 1.2
> M3 (I guess - can I check it somewhere? Plugin.xml, etc.)
>
> I started EPF with OpenUP 1.0-RC3-20070720 and imported my plugin; and it
> didn't work - workspace/.metadata/.log shows:
> java.lang.NullPointerException
> at
> org.eclipse.epf.authoring.ui.forms.ConfigurationPage.updateC heckStates(Unknown
> Source)
> at org.eclipse.epf.authoring.ui.forms.ConfigurationPage.setInpu t(Unknown
> Source)
> at
> org.eclipse.epf.authoring.ui.forms.ConfigurationPage.createF ormContent(Unknown
> Source)
> at org.eclipse.ui.forms.editor.FormPage$1.run(FormPage.java:151 )
> at org.eclipse.swt.custom.BusyIndicator.showWhile(BusyIndicator .java:67)
> at
> org.eclipse.ui.forms.editor.FormPage.createPartControl(FormP age.java:149)
> at org.eclipse.ui.forms.editor.FormEditor.pageChange(FormEditor .java:484)
> at
> org.eclipse.epf.authoring.ui.editors.MethodElementEditor.pag eChange(Unknown
> Source)
> at
> org.eclipse.ui.part.MultiPageEditorPart$2.widgetSelected(Mul tiPageEditorPart.java:239)
> at
> org.eclipse.swt.widgets.TypedListener.handleEvent(TypedListe ner.java:227)
> at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java :66)
> at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:938)
> at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:962)
> at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:947)
> at org.eclipse.swt.widgets.Widget.notifyListeners(Widget.java:7 06)
> at org.eclipse.swt.custom.CTabFolder.setSelection(CTabFolder.ja va:3206)
> at org.eclipse.swt.custom.CTabFolder.onMouse(CTabFolder.java:19 88)
> at org.eclipse.swt.custom.CTabFolder$1.handleEvent(CTabFolder.j ava:308)
> at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java :66)
> at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:938)
> at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.ja va:3673)
> at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java :3284)
> at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.jav a:2337)
> at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:2301)
> at org.eclipse.ui.internal.Workbench.access$4(Workbench.java:21 76)
> at org.eclipse.ui.internal.Workbench$4.run(Workbench.java:463)
> at
> org.eclipse.core.databinding.observable.Realm.runWithDefault (Realm.java:289)
> at
> org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Work bench.java:458)
> at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.j ava:149)
> at org.eclipse.epf.rcp.ui.MainApplication.createWorkbenchAdviso r(Unknown
> Source)
> at org.eclipse.epf.rcp.ui.MainApplication.start(Unknown Source)
> at
> org.eclipse.equinox.internal.app.EclipseAppHandle.run(Eclips eAppHandle.java:146)
> at
> org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher .runApplication(EclipseAppLauncher.java:106)
> at
> org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher .start(EclipseAppLauncher.java:76)
> at
> org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseS tarter.java:356)
> at
> org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseS tarter.java:171)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
> at java.lang.reflect.Method.invoke(Unknown Source)
> at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java: 476)
> at org.eclipse.equinox.launcher.Main.basicRun(Main.java:416)
> at org.eclipse.equinox.launcher.Main.run(Main.java:1141)
>
> However, next time it worked (I just deleted workspace, copied library and
> imported my plugin again) and so I cannot reproduce it. I'm putting it
> here just FYI.
>
> Now I see couple of errors telling me:
> Severity and Description Path Resource Location Creation Time Id
> Could not resolve proxy
> 'uma://_0TLvwMlgEdmt3adZL5Dmdw#_h15dULCxEdujaOuld2kPdg'
> OpenUP/configurations OpenUP_TS.xmi
> C:\workbench\workspaces\workspace-epf2\OpenUP\configurations \OpenUP_TS.xmi
> 1185369789419 17
> Could not resolve proxy
> 'uma://_0TLvwMlgEdmt3adZL5Dmdw#_XIwYQPTYEduDKIuqTXQ8SA'
> OpenUP/configurations OpenUP_TS.xmi
> C:\workbench\workspaces\workspace-epf2\OpenUP\configurations \OpenUP_TS.xmi
> 1185369789520 18
> Could not resolve proxy
> 'uma://_WCUhAO8KEdmKSqa_gSYthg#_AejKAMadEduMlb2cQZNTYw'
> OpenUP/configurations OpenUP_TS.xmi
> C:\workbench\workspaces\workspace-epf2\OpenUP\configurations \OpenUP_TS.xmi
> 1185369789209 16
>
> Does it mean that my plugin contributes to some elements which have
> changed or don't exist anymore?
>
> Question: what are your suggestions/recommended practices for the
> migration?
>
> Roman
>
>
|
|
|
| Re: Migration to newever library version [message #36477 is a reply to message #36425] |
Fri, 03 August 2007 16:11 |
J. Fincher
Messages: 14
Registered: July 2009 |
Junior Member |
|
|
I've done more poking around and it looks like the issue may be that the two
plugins have the same id even though they are named differently?
If that's the issue, how can I get them to have different IDs?
(Please forgive me if this is a stupid question - I am not a programmer and
am doing pretty well to get this far on my own).
Thanks again,
Jan Fincher, Business Applications Analyst
Florida Div. of Rehab & Liq
jan.fincher@fldfs.com
"Jan Fincher" <myjunk68@yahoo.com> wrote in message
news:f8vi92$lab$1@build.eclipse.org...
> Hello,
>
> I have a similar question.
>
> I've been working with OpenUP 0.9 to customize it for our use. I created
> a
> separate library, created a plugin for our use, and imported the OpenUp
> 0.9
> plugins for reference. I would like to do the same with OpenUP 1.0.
>
> However, when I try to import the OpenUp 1.0 plugin, the import function
> is
> "seeing" the new plugin as being the same as the existing plug in. The
> two
> plugins have both been renamed from within EPFC.
>
> I've tried locating information on the import/export function in the help
> system and online to see if I'm doing something wrong, but I haven't yet
> found anything that addresses this.
>
> Any help would be greatly appreciated.
>
> Thanks,
>
> Jan Fincher, Business Applications Analyst
> Florida Div. of Rehab & Liq
> jan.fincher@fldfs.com
>
> "Roman Smirak" <roman.smirak@tietoenator.com> wrote in message
> news:f87j6j$3v7$1@build.eclipse.org...
>> Hi,
>>
>> I have just downloaded latest version of OpenUP library and tried to
>> migrate my plugin to this.
>>
>> My plugin has been developed on OpenUP 0.9 distributed with Composer 1.2
>> M3 (I guess - can I check it somewhere? Plugin.xml, etc.)
>>
>> I started EPF with OpenUP 1.0-RC3-20070720 and imported my plugin; and it
>> didn't work - workspace/.metadata/.log shows:
>> java.lang.NullPointerException
>> at
>> org.eclipse.epf.authoring.ui.forms.ConfigurationPage.updateC heckStates(Unknown
>> Source)
>> at org.eclipse.epf.authoring.ui.forms.ConfigurationPage.setInpu t(Unknown
>> Source)
>> at
>> org.eclipse.epf.authoring.ui.forms.ConfigurationPage.createF ormContent(Unknown
>> Source)
>> at org.eclipse.ui.forms.editor.FormPage$1.run(FormPage.java:151 )
>> at org.eclipse.swt.custom.BusyIndicator.showWhile(BusyIndicator .java:67)
>> at
>> org.eclipse.ui.forms.editor.FormPage.createPartControl(FormP age.java:149)
>> at org.eclipse.ui.forms.editor.FormEditor.pageChange(FormEditor .java:484)
>> at
>> org.eclipse.epf.authoring.ui.editors.MethodElementEditor.pag eChange(Unknown
>> Source)
>> at
>> org.eclipse.ui.part.MultiPageEditorPart$2.widgetSelected(Mul tiPageEditorPart.java:239)
>> at
>> org.eclipse.swt.widgets.TypedListener.handleEvent(TypedListe ner.java:227)
>> at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java :66)
>> at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:938)
>> at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:962)
>> at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:947)
>> at org.eclipse.swt.widgets.Widget.notifyListeners(Widget.java:7 06)
>> at org.eclipse.swt.custom.CTabFolder.setSelection(CTabFolder.ja va:3206)
>> at org.eclipse.swt.custom.CTabFolder.onMouse(CTabFolder.java:19 88)
>> at org.eclipse.swt.custom.CTabFolder$1.handleEvent(CTabFolder.j ava:308)
>> at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java :66)
>> at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:938)
>> at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.ja va:3673)
>> at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java :3284)
>> at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.jav a:2337)
>> at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:2301)
>> at org.eclipse.ui.internal.Workbench.access$4(Workbench.java:21 76)
>> at org.eclipse.ui.internal.Workbench$4.run(Workbench.java:463)
>> at
>> org.eclipse.core.databinding.observable.Realm.runWithDefault (Realm.java:289)
>> at
>> org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Work bench.java:458)
>> at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.j ava:149)
>> at org.eclipse.epf.rcp.ui.MainApplication.createWorkbenchAdviso r(Unknown
>> Source)
>> at org.eclipse.epf.rcp.ui.MainApplication.start(Unknown Source)
>> at
>> org.eclipse.equinox.internal.app.EclipseAppHandle.run(Eclips eAppHandle.java:146)
>> at
>> org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher .runApplication(EclipseAppLauncher.java:106)
>> at
>> org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher .start(EclipseAppLauncher.java:76)
>> at
>> org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseS tarter.java:356)
>> at
>> org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseS tarter.java:171)
>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>> at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
>> at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
>> at java.lang.reflect.Method.invoke(Unknown Source)
>> at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java: 476)
>> at org.eclipse.equinox.launcher.Main.basicRun(Main.java:416)
>> at org.eclipse.equinox.launcher.Main.run(Main.java:1141)
>>
>> However, next time it worked (I just deleted workspace, copied library
>> and
>> imported my plugin again) and so I cannot reproduce it. I'm putting it
>> here just FYI.
>>
>> Now I see couple of errors telling me:
>> Severity and Description Path Resource Location Creation Time Id
>> Could not resolve proxy
>> 'uma://_0TLvwMlgEdmt3adZL5Dmdw#_h15dULCxEdujaOuld2kPdg'
>> OpenUP/configurations OpenUP_TS.xmi
>> C:\workbench\workspaces\workspace-epf2\OpenUP\configurations \OpenUP_TS.xmi
>> 1185369789419 17
>> Could not resolve proxy
>> 'uma://_0TLvwMlgEdmt3adZL5Dmdw#_XIwYQPTYEduDKIuqTXQ8SA'
>> OpenUP/configurations OpenUP_TS.xmi
>> C:\workbench\workspaces\workspace-epf2\OpenUP\configurations \OpenUP_TS.xmi
>> 1185369789520 18
>> Could not resolve proxy
>> 'uma://_WCUhAO8KEdmKSqa_gSYthg#_AejKAMadEduMlb2cQZNTYw'
>> OpenUP/configurations OpenUP_TS.xmi
>> C:\workbench\workspaces\workspace-epf2\OpenUP\configurations \OpenUP_TS.xmi
>> 1185369789209 16
>>
>> Does it mean that my plugin contributes to some elements which have
>> changed or don't exist anymore?
>>
>> Question: what are your suggestions/recommended practices for the
>> migration?
>>
>> Roman
>>
>>
>
>
>
>
|
|
| | | |
| Re: Migration to newever library version [message #37301 is a reply to message #37233] |
Thu, 09 August 2007 23:35 |
Ricardo Balduino
Messages: 191
Registered: July 2009 |
Senior Member |
|
|
Option A sounds less cumbersome and safer, as the EPF Composer tool will
take care of the work. In fact, according to your description of option A,
OpenUP 2.x would overwrite OpenUP 1.x.
Instead of playing with importing a new OpenUP plug-in into your existing
library, have you considered getting the new OpenUP library available and
import your plug-in into it instead? With that approach, you are moving your
plug-in around, so you know there are no duplicates of it in a brand new
OpenUP library. If your plug-in initially depended on some OpenUP element
that does not exist anymore when a new version of OpenUP is released, the
import will show you warnings, which will help you to spot where you need to
maintain your plug-in to extend the most current version of OpenUP.
Additions to OpenUP will not affect your plug-in.
Cheers,
Ricardo Balduino.
"K.Benameur" <benameur@freesurf.fr> wrote in message
news:f9f8cn$ah0$1@build.eclipse.org...
> Hi Peter,
>
> Sorry to bother you with all my questions !!!
>
> I am not sure that I have completly understood your answer.
>
> To check this I propose a simple scenario :
> - I develop a library using Open Up 1.x.
> - A new version of Open Up is out let say 2.x
> - I wan't to take advantage of this new Open Up version.
>
> A) So ideally, I import the new version in my library and Open Up 1.x is
> updated to 2.x.
>
> I have the feeling that it will not be so simple as many links will be
> broken due to changes between 1.X and 2.X.
>
> B) I use the copy operation to have the 1.X & 2.X plugin in my library
>
> It seems that option B) is the one to go as you said that we have to do a
> copy as uuid must be unique.
> =>
> I have to do the migration manually by replacing elements of Open 1.x by
> their counterparts in 2.x.
>
> is it right or I missed something like a smart import that detect
> conflicts and propose to update automatically element that exist in 1.X &
> 2.X /delete obsolete element of 1.X / etc.. ?
>
> The question is what is the recommended procedure to perform a plug-in
> upgrade with a minimum effort ?
>
> My concern will be the maintenance cost of a library. If we build our
> library from many commercial or non commercial plugins we have to deal
> with their evolutions at a minimal cost.
>
>
>
>
> Best Regards ...
>
> PS: I will be in vacation for the next 2 weeks so you have plenty of time
> for an anwser ;)
>
>
> PS:
> We use ClearCase but it will not help here except to roll back to a
> stable baseline and lock elements for modification ...
> We are developping our process in multi site. As we didn't want to add
> more complexity we decided to work only on one site (windows terminal
> server for the distant site) with one development branch in base CC.
> May be you have a successfull experience using CC multisite & UCM ? Can
> you share your experience ?
> Seems that in CC 7 (we use CC 6) the merge manager have a new option i.e.
> to always copy. So may be we can now have branches & multisite as now xmi
> file can be merged by a copy. I see here a potential source of trouble as
> we may surely end with invalid references if for instance the merge (copy)
> is done partially on some xmi ...
>
> Peter Haumer wrote:
>> Hello.
>> You cannot load multiple versions of the same plugin into the same
>> library. All library elements are identified by global unique ids and
>> hence such ids needs to be unique. To get more than one copy of an
>> element you need to use the copy operation in the library view. In
>> general we recommend to use a version control system like Rational
>> ClearCase which allows you to label and restore old versions of whole
>> groups of files.
>>
>> Best regards,
>> Peter.
>>
>> P.S.: Surely they should not be an exception when loading the same
>> content twice, but an error message. Please, file a bugzilla with
>> reproducible steps.
>>
>>
>> "K.Benameur" <benameur@freesurf.fr> wrote in message
>> news:f973f4$goo$1@build.eclipse.org...
>>> Hi all,
>>>
>>> It is a very good question. May be it can be addressed by an update of
>>> an existing guideline as the Development Guideline ?
>>>
>>> I think that we should have a "recommended" procedure from the EPF team
>>> to update plug-ins to a new version.
>>> It is now a fairly common scenario that multiple versions of the same
>>> plug-ins are out.
>>>
>>> And it is not only related to Open Up but for any library / plug-in as
>>> part of the development process (we are developing our own library /
>>> plug-ins without Open Up).
>>>
>>>
>>> In short, what is the recommended procedure to migrate to a new version
>>> ? Do we have to export / import ? What are the risks? What we may lose ?
>>>
>>>
>>> Best Regards
>>>
>>>
>>
|
|
|
| Re: Migration to newever library version [message #37369 is a reply to message #37301] |
Fri, 10 August 2007 23:46 |
Ricardo Balduino
Messages: 191
Registered: July 2009 |
Senior Member |
|
|
In first paragraph I meant less cumbersome, yet safer ;-)
"Ricardo Balduino" <balduino@us.ibm.com> wrote in message
news:f9g8d0$db$1@build.eclipse.org...
> Option A sounds less cumbersome and safer, as the EPF Composer tool will
> take care of the work. In fact, according to your description of option A,
> OpenUP 2.x would overwrite OpenUP 1.x.
>
> Instead of playing with importing a new OpenUP plug-in into your existing
> library, have you considered getting the new OpenUP library available and
> import your plug-in into it instead? With that approach, you are moving
> your plug-in around, so you know there are no duplicates of it in a brand
> new OpenUP library. If your plug-in initially depended on some OpenUP
> element that does not exist anymore when a new version of OpenUP is
> released, the import will show you warnings, which will help you to spot
> where you need to maintain your plug-in to extend the most current version
> of OpenUP. Additions to OpenUP will not affect your plug-in.
>
> Cheers,
>
> Ricardo Balduino.
>
> "K.Benameur" <benameur@freesurf.fr> wrote in message
> news:f9f8cn$ah0$1@build.eclipse.org...
>> Hi Peter,
>>
>> Sorry to bother you with all my questions !!!
>>
>> I am not sure that I have completly understood your answer.
>>
>> To check this I propose a simple scenario :
>> - I develop a library using Open Up 1.x.
>> - A new version of Open Up is out let say 2.x
>> - I wan't to take advantage of this new Open Up version.
>>
>> A) So ideally, I import the new version in my library and Open Up 1.x is
>> updated to 2.x.
>>
>> I have the feeling that it will not be so simple as many links will be
>> broken due to changes between 1.X and 2.X.
>>
>> B) I use the copy operation to have the 1.X & 2.X plugin in my library
>>
>> It seems that option B) is the one to go as you said that we have to do a
>> copy as uuid must be unique.
>> =>
>> I have to do the migration manually by replacing elements of Open 1.x by
>> their counterparts in 2.x.
>>
>> is it right or I missed something like a smart import that detect
>> conflicts and propose to update automatically element that exist in 1.X &
>> 2.X /delete obsolete element of 1.X / etc.. ?
>>
>> The question is what is the recommended procedure to perform a plug-in
>> upgrade with a minimum effort ?
>>
>> My concern will be the maintenance cost of a library. If we build our
>> library from many commercial or non commercial plugins we have to deal
>> with their evolutions at a minimal cost.
>>
>>
>>
>>
>> Best Regards ...
>>
>> PS: I will be in vacation for the next 2 weeks so you have plenty of time
>> for an anwser ;)
>>
>>
>> PS:
>> We use ClearCase but it will not help here except to roll back to a
>> stable baseline and lock elements for modification ...
>> We are developping our process in multi site. As we didn't want to add
>> more complexity we decided to work only on one site (windows terminal
>> server for the distant site) with one development branch in base CC.
>> May be you have a successfull experience using CC multisite & UCM ? Can
>> you share your experience ?
>> Seems that in CC 7 (we use CC 6) the merge manager have a new option i.e.
>> to always copy. So may be we can now have branches & multisite as now xmi
>> file can be merged by a copy. I see here a potential source of trouble as
>> we may surely end with invalid references if for instance the merge
>> (copy) is done partially on some xmi ...
>>
>> Peter Haumer wrote:
>>> Hello.
>>> You cannot load multiple versions of the same plugin into the same
>>> library. All library elements are identified by global unique ids and
>>> hence such ids needs to be unique. To get more than one copy of an
>>> element you need to use the copy operation in the library view. In
>>> general we recommend to use a version control system like Rational
>>> ClearCase which allows you to label and restore old versions of whole
>>> groups of files.
>>>
>>> Best regards,
>>> Peter.
>>>
>>> P.S.: Surely they should not be an exception when loading the same
>>> content twice, but an error message. Please, file a bugzilla with
>>> reproducible steps.
>>>
>>>
>>> "K.Benameur" <benameur@freesurf.fr> wrote in message
>>> news:f973f4$goo$1@build.eclipse.org...
>>>> Hi all,
>>>>
>>>> It is a very good question. May be it can be addressed by an update of
>>>> an existing guideline as the Development Guideline ?
>>>>
>>>> I think that we should have a "recommended" procedure from the EPF team
>>>> to update plug-ins to a new version.
>>>> It is now a fairly common scenario that multiple versions of the same
>>>> plug-ins are out.
>>>>
>>>> And it is not only related to Open Up but for any library / plug-in as
>>>> part of the development process (we are developing our own library /
>>>> plug-ins without Open Up).
>>>>
>>>>
>>>> In short, what is the recommended procedure to migrate to a new
>>>> version ? Do we have to export / import ? What are the risks? What we
>>>> may lose ?
>>>>
>>>>
>>>> Best Regards
>>>>
>>>>
>>>
>
|
|
|
| Re: Migration to newever library version [message #37403 is a reply to message #37369] |
Sat, 11 August 2007 13:13 |
Roman Smirak
Messages: 136
Registered: July 2009 |
Senior Member |
|
|
Hi Ricardo,
the way you described below is the one I've been using so far; however, I
have few issues here:
1/ What if you refactor the content of OpenUP, e.g. an element I was
referencing to is no longer in same package or plugin? Is there any impact
on UID?
2/ Currently we have the whole library in a versioning repository, although
everyone has got the basis (OpenUP, or RUP) with the tool (EMC, or RMC) - no
problem for OpenUP, in case of RUP, well we are talking about 60MB or so
(which you have to check in every time you migrate)
3/ Let say we have a common basis in our department X, let's call it
OpenUP/X; there is a project A which will use it plus extension A minus
irrelevant content from basis; in case of eclipse plugins they simply check
out required plugins (they stay in touch with their updates by department X
authority) but they don't check out irrelevant plugins (no mess) + create
their new one and check it in their repository (will be maintained there);
currently they need to check out whole library X + submit their plugins A
into the library shared by others (and they do same action as well => mess X
+ A + B + C, etc.) in order to fulfil the use case (the basis maintained by
department, a project extension maintained by the project itself)
I see the library.xml as a big constraint in this use case.
Regards,
Roman
"Ricardo Balduino" <balduino@us.ibm.com> wrote in message
news:f9itco$87k$1@build.eclipse.org...
> In first paragraph I meant less cumbersome, yet safer ;-)
>
> "Ricardo Balduino" <balduino@us.ibm.com> wrote in message
> news:f9g8d0$db$1@build.eclipse.org...
>> Option A sounds less cumbersome and safer, as the EPF Composer tool will
>> take care of the work. In fact, according to your description of option
>> A, OpenUP 2.x would overwrite OpenUP 1.x.
>>
>> Instead of playing with importing a new OpenUP plug-in into your existing
>> library, have you considered getting the new OpenUP library available and
>> import your plug-in into it instead? With that approach, you are moving
>> your plug-in around, so you know there are no duplicates of it in a brand
>> new OpenUP library. If your plug-in initially depended on some OpenUP
>> element that does not exist anymore when a new version of OpenUP is
>> released, the import will show you warnings, which will help you to spot
>> where you need to maintain your plug-in to extend the most current
>> version of OpenUP. Additions to OpenUP will not affect your plug-in.
>>
>> Cheers,
>>
>> Ricardo Balduino.
>>
>> "K.Benameur" <benameur@freesurf.fr> wrote in message
>> news:f9f8cn$ah0$1@build.eclipse.org...
>>> Hi Peter,
>>>
>>> Sorry to bother you with all my questions !!!
>>>
>>> I am not sure that I have completly understood your answer.
>>>
>>> To check this I propose a simple scenario :
>>> - I develop a library using Open Up 1.x.
>>> - A new version of Open Up is out let say 2.x
>>> - I wan't to take advantage of this new Open Up version.
>>>
>>> A) So ideally, I import the new version in my library and Open Up 1.x is
>>> updated to 2.x.
>>>
>>> I have the feeling that it will not be so simple as many links will be
>>> broken due to changes between 1.X and 2.X.
>>>
>>> B) I use the copy operation to have the 1.X & 2.X plugin in my library
>>>
>>> It seems that option B) is the one to go as you said that we have to do
>>> a copy as uuid must be unique.
>>> =>
>>> I have to do the migration manually by replacing elements of Open 1.x
>>> by their counterparts in 2.x.
>>>
>>> is it right or I missed something like a smart import that detect
>>> conflicts and propose to update automatically element that exist in 1.X
>>> & 2.X /delete obsolete element of 1.X / etc.. ?
>>>
>>> The question is what is the recommended procedure to perform a plug-in
>>> upgrade with a minimum effort ?
>>>
>>> My concern will be the maintenance cost of a library. If we build our
>>> library from many commercial or non commercial plugins we have to deal
>>> with their evolutions at a minimal cost.
>>>
>>>
>>>
>>>
>>> Best Regards ...
>>>
>>> PS: I will be in vacation for the next 2 weeks so you have plenty of
>>> time for an anwser ;)
>>>
>>>
>>> PS:
>>> We use ClearCase but it will not help here except to roll back to a
>>> stable baseline and lock elements for modification ...
>>> We are developping our process in multi site. As we didn't want to add
>>> more complexity we decided to work only on one site (windows terminal
>>> server for the distant site) with one development branch in base CC.
>>> May be you have a successfull experience using CC multisite & UCM ? Can
>>> you share your experience ?
>>> Seems that in CC 7 (we use CC 6) the merge manager have a new option
>>> i.e. to always copy. So may be we can now have branches & multisite as
>>> now xmi file can be merged by a copy. I see here a potential source of
>>> trouble as we may surely end with invalid references if for instance the
>>> merge (copy) is done partially on some xmi ...
>>>
>>> Peter Haumer wrote:
>>>> Hello.
>>>> You cannot load multiple versions of the same plugin into the same
>>>> library. All library elements are identified by global unique ids and
>>>> hence such ids needs to be unique. To get more than one copy of an
>>>> element you need to use the copy operation in the library view. In
>>>> general we recommend to use a version control system like Rational
>>>> ClearCase which allows you to label and restore old versions of whole
>>>> groups of files.
>>>>
>>>> Best regards,
>>>> Peter.
>>>>
>>>> P.S.: Surely they should not be an exception when loading the same
>>>> content twice, but an error message. Please, file a bugzilla with
>>>> reproducible steps.
>>>>
>>>>
>>>> "K.Benameur" <benameur@freesurf.fr> wrote in message
>>>> news:f973f4$goo$1@build.eclipse.org...
>>>>> Hi all,
>>>>>
>>>>> It is a very good question. May be it can be addressed by an update of
>>>>> an existing guideline as the Development Guideline ?
>>>>>
>>>>> I think that we should have a "recommended" procedure from the EPF
>>>>> team to update plug-ins to a new version.
>>>>> It is now a fairly common scenario that multiple versions of the same
>>>>> plug-ins are out.
>>>>>
>>>>> And it is not only related to Open Up but for any library / plug-in as
>>>>> part of the development process (we are developing our own library /
>>>>> plug-ins without Open Up).
>>>>>
>>>>>
>>>>> In short, what is the recommended procedure to migrate to a new
>>>>> version ? Do we have to export / import ? What are the risks? What we
>>>>> may lose ?
>>>>>
>>>>>
>>>>> Best Regards
>>>>>
>>>>>
>>>>
>>
>
>
|
|
|
| Re: Migration to newever library version [message #37569 is a reply to message #37233] |
Sun, 12 August 2007 23:21 |
Peter Haumer
Messages: 228
Registered: July 2009 |
Senior Member |
|
|
Hello K.
We do not support B, which is in fact the more complicated one as all plugin
element can have outgoing as well as incoming relationships. Because of
several issues related to this we currently do not support a copy-paste
operation of plugins. You can only copy-paste individual elements. Our
relationships system is based on global unique identifiers (guids) to fully
support A. All html hyperplinks that have a guid attribute are automatically
recomputed based on that guid for refactoring operations; e.g. elements move
packages or even plugins. Elements will never change guids when you move
them around; unless you delete an element and create a new one with the same
name you should be save from release to release unless the OpenUP team
introduces all new elements.
As we do not have compare-merge editors, yet, we only support base ClearCase
so far.
Best regards,
Peter.
"K.Benameur" <benameur@freesurf.fr> wrote in message
news:f9f8cn$ah0$1@build.eclipse.org...
> Hi Peter,
>
> Sorry to bother you with all my questions !!!
>
> I am not sure that I have completly understood your answer.
>
> To check this I propose a simple scenario :
> - I develop a library using Open Up 1.x.
> - A new version of Open Up is out let say 2.x
> - I wan't to take advantage of this new Open Up version.
>
> A) So ideally, I import the new version in my library and Open Up 1.x is
> updated to 2.x.
>
> I have the feeling that it will not be so simple as many links will be
> broken due to changes between 1.X and 2.X.
>
> B) I use the copy operation to have the 1.X & 2.X plugin in my library
>
> It seems that option B) is the one to go as you said that we have to do a
> copy as uuid must be unique.
> =>
> I have to do the migration manually by replacing elements of Open 1.x by
> their counterparts in 2.x.
>
> is it right or I missed something like a smart import that detect
> conflicts and propose to update automatically element that exist in 1.X &
> 2.X /delete obsolete element of 1.X / etc.. ?
>
> The question is what is the recommended procedure to perform a plug-in
> upgrade with a minimum effort ?
>
> My concern will be the maintenance cost of a library. If we build our
> library from many commercial or non commercial plugins we have to deal
> with their evolutions at a minimal cost.
>
>
>
>
> Best Regards ...
>
> PS: I will be in vacation for the next 2 weeks so you have plenty of time
> for an anwser ;)
>
>
> PS:
> We use ClearCase but it will not help here except to roll back to a
> stable baseline and lock elements for modification ...
> We are developping our process in multi site. As we didn't want to add
> more complexity we decided to work only on one site (windows terminal
> server for the distant site) with one development branch in base CC.
> May be you have a successfull experience using CC multisite & UCM ? Can
> you share your experience ?
> Seems that in CC 7 (we use CC 6) the merge manager have a new option i.e.
> to always copy. So may be we can now have branches & multisite as now xmi
> file can be merged by a copy. I see here a potential source of trouble as
> we may surely end with invalid references if for instance the merge (copy)
> is done partially on some xmi ...
>
> Peter Haumer wrote:
>> Hello.
>> You cannot load multiple versions of the same plugin into the same
>> library. All library elements are identified by global unique ids and
>> hence such ids needs to be unique. To get more than one copy of an
>> element you need to use the copy operation in the library view. In
>> general we recommend to use a version control system like Rational
>> ClearCase which allows you to label and restore old versions of whole
>> groups of files.
>>
>> Best regards,
>> Peter.
>>
>> P.S.: Surely they should not be an exception when loading the same
>> content twice, but an error message. Please, file a bugzilla with
>> reproducible steps.
>>
>>
>> "K.Benameur" <benameur@freesurf.fr> wrote in message
>> news:f973f4$goo$1@build.eclipse.org...
>>> Hi all,
>>>
>>> It is a very good question. May be it can be addressed by an update of
>>> an existing guideline as the Development Guideline ?
>>>
>>> I think that we should have a "recommended" procedure from the EPF team
>>> to update plug-ins to a new version.
>>> It is now a fairly common scenario that multiple versions of the same
>>> plug-ins are out.
>>>
>>> And it is not only related to Open Up but for any library / plug-in as
>>> part of the development process (we are developing our own library /
>>> plug-ins without Open Up).
>>>
>>>
>>> In short, what is the recommended procedure to migrate to a new version
>>> ? Do we have to export / import ? What are the risks? What we may lose ?
>>>
>>>
>>> Best Regards
>>>
>>>
>>
|
|
|
| Re: Migration to newever library version [message #37599 is a reply to message #37403] |
Sun, 12 August 2007 23:29 |
Peter Haumer
Messages: 228
Registered: July 2009 |
Senior Member |
|
|
1) no, the guid remains the same
2) not sure I understand the context of this, but I would recommend to only
version manage your own files and if you are using cvs directly get the
OpenUP sources from our server or if you use CC provide a zip/rar file with
the OpenUP files that users can unzip as view-private files
3) Rational Method Composer 7.2 will fully support this scenario, which is
not in scope for EPF Composer. For enterprise deployments and full
scalability we recommend RMC in which every plugin can be maintained as an
eclipse project and loaded when needed. In addition we provide project types
for configurations, enterprise reports, and estimation models in RMC. EPF
Composer is designed to support a single project per library only as it is
primary used to maintain OpenUP. A workaround for you would be what I
described above for (2).
Best regards,
Peter Haumer.
"Roman Smirak" <roman.smirak@tietoenator.com> wrote in message
news:f9kcmi$idh$1@build.eclipse.org...
> Hi Ricardo,
>
> the way you described below is the one I've been using so far; however,
> I have few issues here:
> 1/ What if you refactor the content of OpenUP, e.g. an element I was
> referencing to is no longer in same package or plugin? Is there any impact
> on UID?
>
> 2/ Currently we have the whole library in a versioning repository,
> although everyone has got the basis (OpenUP, or RUP) with the tool (EMC,
> or RMC) - no problem for OpenUP, in case of RUP, well we are talking about
> 60MB or so (which you have to check in every time you migrate)
>
> 3/ Let say we have a common basis in our department X, let's call it
> OpenUP/X; there is a project A which will use it plus extension A minus
> irrelevant content from basis; in case of eclipse plugins they simply
> check out required plugins (they stay in touch with their updates by
> department X authority) but they don't check out irrelevant plugins (no
> mess) + create their new one and check it in their repository (will be
> maintained there); currently they need to check out whole library X +
> submit their plugins A into the library shared by others (and they do same
> action as well => mess X + A + B + C, etc.) in order to fulfil the use
> case (the basis maintained by department, a project extension maintained
> by the project itself)
>
> I see the library.xml as a big constraint in this use case.
>
> Regards,
>
> Roman
>
> "Ricardo Balduino" <balduino@us.ibm.com> wrote in message
> news:f9itco$87k$1@build.eclipse.org...
>> In first paragraph I meant less cumbersome, yet safer ;-)
>>
>> "Ricardo Balduino" <balduino@us.ibm.com> wrote in message
>> news:f9g8d0$db$1@build.eclipse.org...
>>> Option A sounds less cumbersome and safer, as the EPF Composer tool will
>>> take care of the work. In fact, according to your description of option
>>> A, OpenUP 2.x would overwrite OpenUP 1.x.
>>>
>>> Instead of playing with importing a new OpenUP plug-in into your
>>> existing library, have you considered getting the new OpenUP library
>>> available and import your plug-in into it instead? With that approach,
>>> you are moving your plug-in around, so you know there are no duplicates
>>> of it in a brand new OpenUP library. If your plug-in initially depended
>>> on some OpenUP element that does not exist anymore when a new version of
>>> OpenUP is released, the import will show you warnings, which will help
>>> you to spot where you need to maintain your plug-in to extend the most
>>> current version of OpenUP. Additions to OpenUP will not affect your
>>> plug-in.
>>>
>>> Cheers,
>>>
>>> Ricardo Balduino.
>>>
>>> "K.Benameur" <benameur@freesurf.fr> wrote in message
>>> news:f9f8cn$ah0$1@build.eclipse.org...
>>>> Hi Peter,
>>>>
>>>> Sorry to bother you with all my questions !!!
>>>>
>>>> I am not sure that I have completly understood your answer.
>>>>
>>>> To check this I propose a simple scenario :
>>>> - I develop a library using Open Up 1.x.
>>>> - A new version of Open Up is out let say 2.x
>>>> - I wan't to take advantage of this new Open Up version.
>>>>
>>>> A) So ideally, I import the new version in my library and Open Up 1.x
>>>> is updated to 2.x.
>>>>
>>>> I have the feeling that it will not be so simple as many links will be
>>>> broken due to changes between 1.X and 2.X.
>>>>
>>>> B) I use the copy operation to have the 1.X & 2.X plugin in my library
>>>>
>>>> It seems that option B) is the one to go as you said that we have to do
>>>> a copy as uuid must be unique.
>>>> =>
>>>> I have to do the migration manually by replacing elements of Open 1.x
>>>> by their counterparts in 2.x.
>>>>
>>>> is it right or I missed something like a smart import that detect
>>>> conflicts and propose to update automatically element that exist in 1.X
>>>> & 2.X /delete obsolete element of 1.X / etc.. ?
>>>>
>>>> The question is what is the recommended procedure to perform a plug-in
>>>> upgrade with a minimum effort ?
>>>>
>>>> My concern will be the maintenance cost of a library. If we build our
>>>> library from many commercial or non commercial plugins we have to deal
>>>> with their evolutions at a minimal cost.
>>>>
>>>>
>>>>
>>>>
>>>> Best Regards ...
>>>>
>>>> PS: I will be in vacation for the next 2 weeks so you have plenty of
>>>> time for an anwser ;)
>>>>
>>>>
>>>> PS:
>>>> We use ClearCase but it will not help here except to roll back to a
>>>> stable baseline and lock elements for modification ...
>>>> We are developping our process in multi site. As we didn't want to add
>>>> more complexity we decided to work only on one site (windows terminal
>>>> server for the distant site) with one development branch in base CC.
>>>> May be you have a successfull experience using CC multisite & UCM ? Can
>>>> you share your experience ?
>>>> Seems that in CC 7 (we use CC 6) the merge manager have a new option
>>>> i.e. to always copy. So may be we can now have branches & multisite as
>>>> now xmi file can be merged by a copy. I see here a potential source of
>>>> trouble as we may surely end with invalid references if for instance
>>>> the merge (copy) is done partially on some xmi ...
>>>>
>>>> Peter Haumer wrote:
>>>>> Hello.
>>>>> You cannot load multiple versions of the same plugin into the same
>>>>> library. All library elements are identified by global unique ids and
>>>>> hence such ids needs to be unique. To get more than one copy of an
>>>>> element you need to use the copy operation in the library view. In
>>>>> general we recommend to use a version control system like Rational
>>>>> ClearCase which allows you to label and restore old versions of whole
>>>>> groups of files.
>>>>>
>>>>> Best regards,
>>>>> Peter.
>>>>>
>>>>> P.S.: Surely they should not be an exception when loading the same
>>>>> content twice, but an error message. Please, file a bugzilla with
>>>>> reproducible steps.
>>>>>
>>>>>
>>>>> "K.Benameur" <benameur@freesurf.fr> wrote in message
>>>>> news:f973f4$goo$1@build.eclipse.org...
>>>>>> Hi all,
>>>>>>
>>>>>> It is a very good question. May be it can be addressed by an update
>>>>>> of an existing guideline as the Development Guideline ?
>>>>>>
>>>>>> I think that we should have a "recommended" procedure from the EPF
>>>>>> team to update plug-ins to a new version.
>>>>>> It is now a fairly common scenario that multiple versions of the
>>>>>> same plug-ins are out.
>>>>>>
>>>>>> And it is not only related to Open Up but for any library / plug-in
>>>>>> as part of the development process (we are developing our own library
>>>>>> / plug-ins without Open Up).
>>>>>>
>>>>>>
>>>>>> In short, what is the recommended procedure to migrate to a new
>>>>>> version ? Do we have to export / import ? What are the risks? What we
>>>>>> may lose ?
>>>>>>
>>>>>>
>>>>>> Best Regards
>>>>>>
>>>>>>
>>>>>
>>>
>>
>>
>
>
|
|
|
| Re: Migration to newever library version [message #37691 is a reply to message #37599] |
Mon, 13 August 2007 09:06 |
Roman Smirak
Messages: 136
Registered: July 2009 |
Senior Member |
|
|
Hi Peter,
thanks for info, however, RMC is based on EPF and I see current solution
of EPF (library.xml) as a fundamental constraint for clear & easy solution
at RMC level. Or?
Can you please describe the scenario with RMC how it will be implemented?
Or shall I post this at IBM Rational forum?
Roman
"Peter Haumer" <phaumer@us.ibm.com> wrote in message
news:f9o54i$924$1@build.eclipse.org...
> 1) no, the guid remains the same
> 2) not sure I understand the context of this, but I would recommend to
> only version manage your own files and if you are using cvs directly get
> the OpenUP sources from our server or if you use CC provide a zip/rar file
> with the OpenUP files that users can unzip as view-private files
> 3) Rational Method Composer 7.2 will fully support this scenario, which is
> not in scope for EPF Composer. For enterprise deployments and full
> scalability we recommend RMC in which every plugin can be maintained as an
> eclipse project and loaded when needed. In addition we provide project
> types for configurations, enterprise reports, and estimation models in
> RMC. EPF Composer is designed to support a single project per library
> only as it is primary used to maintain OpenUP. A workaround for you would
> be what I described above for (2).
>
> Best regards,
> Peter Haumer.
>
>
> "Roman Smirak" <roman.smirak@tietoenator.com> wrote in message
> news:f9kcmi$idh$1@build.eclipse.org...
>> Hi Ricardo,
>>
>> the way you described below is the one I've been using so far; however,
>> I have few issues here:
>> 1/ What if you refactor the content of OpenUP, e.g. an element I was
>> referencing to is no longer in same package or plugin? Is there any
>> impact on UID?
>>
>> 2/ Currently we have the whole library in a versioning repository,
>> although everyone has got the basis (OpenUP, or RUP) with the tool (EMC,
>> or RMC) - no problem for OpenUP, in case of RUP, well we are talking
>> about 60MB or so (which you have to check in every time you migrate)
>>
>> 3/ Let say we have a common basis in our department X, let's call it
>> OpenUP/X; there is a project A which will use it plus extension A minus
>> irrelevant content from basis; in case of eclipse plugins they simply
>> check out required plugins (they stay in touch with their updates by
>> department X authority) but they don't check out irrelevant plugins (no
>> mess) + create their new one and check it in their repository (will be
>> maintained there); currently they need to check out whole library X +
>> submit their plugins A into the library shared by others (and they do
>> same action as well => mess X + A + B + C, etc.) in order to fulfil the
>> use case (the basis maintained by department, a project extension
>> maintained by the project itself)
>>
>> I see the library.xml as a big constraint in this use case.
>>
>> Regards,
>>
>> Roman
>>
>> "Ricardo Balduino" <balduino@us.ibm.com> wrote in message
>> news:f9itco$87k$1@build.eclipse.org...
>>> In first paragraph I meant less cumbersome, yet safer ;-)
>>>
>>> "Ricardo Balduino" <balduino@us.ibm.com> wrote in message
>>> news:f9g8d0$db$1@build.eclipse.org...
>>>> Option A sounds less cumbersome and safer, as the EPF Composer tool
>>>> will take care of the work. In fact, according to your description of
>>>> option A, OpenUP 2.x would overwrite OpenUP 1.x.
>>>>
>>>> Instead of playing with importing a new OpenUP plug-in into your
>>>> existing library, have you considered getting the new OpenUP library
>>>> available and import your plug-in into it instead? With that approach,
>>>> you are moving your plug-in around, so you know there are no duplicates
>>>> of it in a brand new OpenUP library. If your plug-in initially depended
>>>> on some OpenUP element that does not exist anymore when a new version
>>>> of OpenUP is released, the import will show you warnings, which will
>>>> help you to spot where you need to maintain your plug-in to extend the
>>>> most current version of OpenUP. Additions to OpenUP will not affect
>>>> your plug-in.
>>>>
>>>> Cheers,
>>>>
>>>> Ricardo Balduino.
>>>>
>>>> "K.Benameur" <benameur@freesurf.fr> wrote in message
>>>> news:f9f8cn$ah0$1@build.eclipse.org...
>>>>> Hi Peter,
>>>>>
>>>>> Sorry to bother you with all my questions !!!
>>>>>
>>>>> I am not sure that I have completly understood your answer.
>>>>>
>>>>> To check this I propose a simple scenario :
>>>>> - I develop a library using Open Up 1.x.
>>>>> - A new version of Open Up is out let say 2.x
>>>>> - I wan't to take advantage of this new Open Up version.
>>>>>
>>>>> A) So ideally, I import the new version in my library and Open Up 1.x
>>>>> is updated to 2.x.
>>>>>
>>>>> I have the feeling that it will not be so simple as many links will be
>>>>> broken due to changes between 1.X and 2.X.
>>>>>
>>>>> B) I use the copy operation to have the 1.X & 2.X plugin in my library
>>>>>
>>>>> It seems that option B) is the one to go as you said that we have to
>>>>> do a copy as uuid must be unique.
>>>>> =>
>>>>> I have to do the migration manually by replacing elements of Open 1.x
>>>>> by their counterparts in 2.x.
>>>>>
>>>>> is it right or I missed something like a smart import that detect
>>>>> conflicts and propose to update automatically element that exist in
>>>>> 1.X & 2.X /delete obsolete element of 1.X / etc.. ?
>>>>>
>>>>> The question is what is the recommended procedure to perform a plug-in
>>>>> upgrade with a minimum effort ?
>>>>>
>>>>> My concern will be the maintenance cost of a library. If we build our
>>>>> library from many commercial or non commercial plugins we have to deal
>>>>> with their evolutions at a minimal cost.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Best Regards ...
>>>>>
>>>>> PS: I will be in vacation for the next 2 weeks so you have plenty of
>>>>> time for an anwser ;)
>>>>>
>>>>>
>>>>> PS:
>>>>> We use ClearCase but it will not help here except to roll back to a
>>>>> stable baseline and lock elements for modification ...
>>>>> We are developping our process in multi site. As we didn't want to
>>>>> add more complexity we decided to work only on one site (windows
>>>>> terminal server for the distant site) with one development branch in
>>>>> base CC.
>>>>> May be you have a successfull experience using CC multisite & UCM ?
>>>>> Can you share your experience ?
>>>>> Seems that in CC 7 (we use CC 6) the merge manager have a new option
>>>>> i.e. to always copy. So may be we can now have branches & multisite as
>>>>> now xmi file can be merged by a copy. I see here a potential source of
>>>>> trouble as we may surely end with invalid references if for instance
>>>>> the merge (copy) is done partially on some xmi ...
>>>>>
>>>>> Peter Haumer wrote:
>>>>>> Hello.
>>>>>> You cannot load multiple versions of the same plugin into the same
>>>>>> library. All library elements are identified by global unique ids and
>>>>>> hence such ids needs to be unique. To get more than one copy of an
>>>>>> element you need to use the copy operation in the library view. In
>>>>>> general we recommend to use a version control system like Rational
>>>>>> ClearCase which allows you to label and restore old versions of whole
>>>>>> groups of files.
>>>>>>
>>>>>> Best regards,
>>>>>> Peter.
>>>>>>
>>>>>> P.S.: Surely they should not be an exception when loading the same
>>>>>> content twice, but an error message. Please, file a bugzilla with
>>>>>> reproducible steps.
>>>>>>
>>>>>>
>>>>>> "K.Benameur" <benameur@freesurf.fr> wrote in message
>>>>>> news:f973f4$goo$1@build.eclipse.org...
>>>>>>> Hi all,
>>>>>>>
>>>>>>> It is a very good question. May be it can be addressed by an update
>>>>>>> of an existing guideline as the Development Guideline ?
>>>>>>>
>>>>>>> I think that we should have a "recommended" procedure from the EPF
>>>>>>> team to update plug-ins to a new version.
>>>>>>> It is now a fairly common scenario that multiple versions of the
>>>>>>> same plug-ins are out.
>>>>>>>
>>>>>>> And it is not only related to Open Up but for any library / plug-in
>>>>>>> as part of the development process (we are developing our own
>>>>>>> library / plug-ins without Open Up).
>>>>>>>
>>>>>>>
>>>>>>> In short, what is the recommended procedure to migrate to a new
>>>>>>> version ? Do we have to export / import ? What are the risks? What
>>>>>>> we may lose ?
>>>>>>>
>>>>>>>
>>>>>>> Best Regards
>>>>>>>
>>>>>>>
>>>>>>
>>>>
>>>
>>>
>>
>>
>
>
|
|
|
| Re: Migration to newever library version [message #37799 is a reply to message #37691] |
Mon, 13 August 2007 19:07 |
Peter Haumer
Messages: 228
Registered: July 2009 |
Senior Member |
|
|
Hello Roman.
Well, if our competitors can abuse this forum to plug their products; so can
I :-)
RMC 7.2 does not need the library.xmi file anymore as it uses the Eclipse
workspace's projects to find all the files. Every plugin is a project as
well as you can create more than one project for managing configurations and
one project for estimation data (another RMC added value). The problem view
is used just as in Eclipse to tell you if you are missing elements in your
workspace that other elements depend upon. You could ignore those errors or
fix them by loading the project's that contain the missing elements.
See the attached image with an example where I was using plugins managed in
CVS and plugins managed in CC all at the same time in the same workspace.
Plugins can now reside in complete different directories even on different
machine. Just like Eclipse projects, you load them into your workspace and
use them whenever you need to use them.
However, RMC can still generate a library.xmi for you to manage libraries
that are fully compatible with EPF Composer. For example, if you check the
OpenUP CVS repository: it already has project files in each plugin
directory. That is because I was already working with OpenUP in RMC 7.2; at
the same time where the rest of the team continued working with EPF
Composer. Two ways of loading the same library in a fully compatible way.
Hope this helps,
Peter.
"Roman Smirak" <roman.smirak@tietoenator.com> wrote in message
news:f9p6up$mmu$1@build.eclipse.org...
> Hi Peter,
>
> thanks for info, however, RMC is based on EPF and I see current solution
> of EPF (library.xml) as a fundamental constraint for clear & easy solution
> at RMC level. Or?
>
> Can you please describe the scenario with RMC how it will be implemented?
>
> Or shall I post this at IBM Rational forum?
>
> Roman
>
> "Peter Haumer" <phaumer@us.ibm.com> wrote in message
> news:f9o54i$924$1@build.eclipse.org...
>> 1) no, the guid remains the same
>> 2) not sure I understand the context of this, but I would recommend to
>> only version manage your own files and if you are using cvs directly get
>> the OpenUP sources from our server or if you use CC provide a zip/rar
>> file
>> with the OpenUP files that users can unzip as view-private files
>> 3) Rational Method Composer 7.2 will fully support this scenario, which
>> is
>> not in scope for EPF Composer. For enterprise deployments and full
>> scalability we recommend RMC in which every plugin can be maintained as
>> an
>> eclipse project and loaded when needed. In addition we provide project
>> types for configurations, enterprise reports, and estimation models in
>> RMC. EPF Composer is designed to support a single project per library
>> only as it is primary used to maintain OpenUP. A workaround for you
>> would
>> be what I described above for (2).
>>
>> Best regards,
>> Peter Haumer.
>>
>>
>> "Roman Smirak" <roman.smirak@tietoenator.com> wrote in message
>> news:f9kcmi$idh$1@build.eclipse.org...
>>> Hi Ricardo,
>>>
>>> the way you described below is the one I've been using so far;
>>> however,
>>> I have few issues here:
>>> 1/ What if you refactor the content of OpenUP, e.g. an element I was
>>> referencing to is no longer in same package or plugin? Is there any
>>> impact on UID?
>>>
>>> 2/ Currently we have the whole library in a versioning repository,
>>> although everyone has got the basis (OpenUP, or RUP) with the tool (EMC,
>>> or RMC) - no problem for OpenUP, in case of RUP, well we are talking
>>> about 60MB or so (which you have to check in every time you migrate)
>>>
>>> 3/ Let say we have a common basis in our department X, let's call it
>>> OpenUP/X; there is a project A which will use it plus extension A minus
>>> irrelevant content from basis; in case of eclipse plugins they simply
>>> check out required plugins (they stay in touch with their updates by
>>> department X authority) but they don't check out irrelevant plugins (no
>>> mess) + create their new one and check it in their repository (will be
>>> maintained there); currently they need to check out whole library X +
>>> submit their plugins A into the library shared by others (and they do
>>> same action as well => mess X + A + B + C, etc.) in order to fulfil the
>>> use case (the basis maintained by department, a project extension
>>> maintained by the project itself)
>>>
>>> I see the library.xml as a big constraint in this use case.
>>>
>>> Regards,
>>>
>>> Roman
>>>
>>> "Ricardo Balduino" <balduino@us.ibm.com> wrote in message
>>> news:f9itco$87k$1@build.eclipse.org...
>>>> In first paragraph I meant less cumbersome, yet safer ;-)
>>>>
>>>> "Ricardo Balduino" <balduino@us.ibm.com> wrote in message
>>>> news:f9g8d0$db$1@build.eclipse.org...
>>>>> Option A sounds less cumbersome and safer, as the EPF Composer tool
>>>>> will take care of the work. In fact, according to your description of
>>>>> option A, OpenUP 2.x would overwrite OpenUP 1.x.
>>>>>
>>>>> Instead of playing with importing a new OpenUP plug-in into your
>>>>> existing library, have you considered getting the new OpenUP library
>>>>> available and import your plug-in into it instead? With that approach,
>>>>> you are moving your plug-in around, so you know there are no
>>>>> duplicates
>>>>> of it in a brand new OpenUP library. If your plug-in initially
>>>>> depended
>>>>> on some OpenUP element that does not exist anymore when a new version
>>>>> of OpenUP is released, the import will show you warnings, which will
>>>>> help you to spot where you need to maintain your plug-in to extend the
>>>>> most current version of OpenUP. Additions to OpenUP will not affect
>>>>> your plug-in.
>>>>>
>>>>> Cheers,
>>>>>
>>>>> Ricardo Balduino.
>>>>>
>>>>> "K.Benameur" <benameur@freesurf.fr> wrote in message
>>>>> news:f9f8cn$ah0$1@build.eclipse.org...
>>>>>> Hi Peter,
>>>>>>
>>>>>> Sorry to bother you with all my questions !!!
>>>>>>
>>>>>> I am not sure that I have completly understood your answer.
>>>>>>
>>>>>> To check this I propose a simple scenario :
>>>>>> - I develop a library using Open Up 1.x.
>>>>>> - A new version of Open Up is out let say 2.x
>>>>>> - I wan't to take advantage of this new Open Up version.
>>>>>>
>>>>>> A) So ideally, I import the new version in my library and Open Up 1.x
>>>>>> is updated to 2.x.
>>>>>>
>>>>>> I have the feeling that it will not be so simple as many links will
>>>>>> be
>>>>>> broken due to changes between 1.X and 2.X.
>>>>>>
>>>>>> B) I use the copy operation to have the 1.X & 2.X plugin in my
>>>>>> library
>>>>>>
>>>>>> It seems that option B) is the one to go as you said that we have to
>>>>>> do a copy as uuid must be unique.
>>>>>> =>
>>>>>> I have to do the migration manually by replacing elements of Open
>>>>>> 1.x
>>>>>> by their counterparts in 2.x.
>>>>>>
>>>>>> is it right or I missed something like a smart import that detect
>>>>>> conflicts and propose to update automatically element that exist in
>>>>>> 1.X & 2.X /delete obsolete element of 1.X / etc.. ?
>>>>>>
>>>>>> The question is what is the recommended procedure to perform a
>>>>>> plug-in
>>>>>> upgrade with a minimum effort ?
>>>>>>
>>>>>> My concern will be the maintenance cost of a library. If we build our
>>>>>> library from many commercial or non commercial plugins we have to
>>>>>> deal
>>>>>> with their evolutions at a minimal cost.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> Best Regards ...
>>>>>>
>>>>>> PS: I will be in vacation for the next 2 weeks so you have plenty of
>>>>>> time for an anwser ;)
>>>>>>
>>>>>>
>>>>>> PS:
>>>>>> We use ClearCase but it will not help here except to roll back to a
>>>>>> stable baseline and lock elements for modification ...
>>>>>> We are developping our process in multi site. As we didn't want to
>>>>>> add more complexity we decided to work only on one site (windows
>>>>>> terminal server for the distant site) with one development branch in
>>>>>> base CC.
>>>>>> May be you have a successfull experience using CC multisite & UCM ?
>>>>>> Can you share your experience ?
>>>>>> Seems that in CC 7 (we use CC 6) the merge manager have a new option
>>>>>> i.e. to always copy. So may be we can now have branches & multisite
>>>>>> as
>>>>>> now xmi file can be merged by a copy. I see here a potential source
>>>>>> of
>>>>>> trouble as we may surely end with invalid references if for instance
>>>>>> the merge (copy) is done partially on some xmi ...
>>>>>>
>>>>>> Peter Haumer wrote:
>>>>>>> Hello.
>>>>>>> You cannot load multiple versions of the same plugin into the same
>>>>>>> library. All library elements are identified by global unique ids
>>>>>>> and
>>>>>>> hence such ids needs to be unique. To get more than one copy of an
>>>>>>> element you need to use the copy operation in the library view. In
>>>>>>> general we recommend to use a version control system like Rational
>>>>>>> ClearCase which allows you to label and restore old versions of
>>>>>>> whole
>>>>>>> groups of files.
>>>>>>>
>>>>>>> Best regards,
>>>>>>> Peter.
>>>>>>>
>>>>>>> P.S.: Surely they should not be an exception when loading the same
>>>>>>> content twice, but an error message. Please, file a bugzilla with
>>>>>>> reproducible steps.
>>>>>>>
>>>>>>>
>>>>>>> "K.Benameur" <benameur@freesurf.fr> wrote in message
>>>>>>> news:f973f4$goo$1@build.eclipse.org...
>>>>>>>> Hi all,
>>>>>>>>
>>>>>>>> It is a very good question. May be it can be addressed by an update
>>>>>>>> of an existing guideline as the Development Guideline ?
>>>>>>>>
>>>>>>>> I think that we should have a "recommended" procedure from the EPF
>>>>>>>> team to update plug-ins to a new version.
>>>>>>>> It is now a fairly common scenario that multiple versions of the
>>>>>>>> same plug-ins are out.
>>>>>>>>
>>>>>>>> And it is not only related to Open Up but for any library / plug-in
>>>>>>>> as part of the development process (we are developing our own
>>>>>>>> library / plug-ins without Open Up).
>>>>>>>>
>>>>>>>>
>>>>>>>> In short, what is the recommended procedure to migrate to a new
>>>>>>>> version ? Do we have to export / import ? What are the risks? What
>>>>>>>> we may lose ?
>>>>>>>>
>>>>>>>>
>>>>>>>> Best Regards
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>
|
|
|
| Re: Migration to newever library version [message #37931 is a reply to message #37799] |
Tue, 14 August 2007 06:54 |
Roman Smirak
Messages: 136
Registered: July 2009 |
Senior Member |
|
|
Hi Peter,
that is great, the implementation perfectly matches with my vision. Why
not to have it in EPF? I guess many users would welcome the feature.
We have licences of RMC, however, we prefer to use EPF since early releases
are available.
Regards,
Roman
"Peter Haumer" <phaumer@us.ibm.com> wrote in message
news:f9qa5o$jac$1@build.eclipse.org...
> Hello Roman.
> Well, if our competitors can abuse this forum to plug their products; so
> can I :-)
>
> RMC 7.2 does not need the library.xmi file anymore as it uses the Eclipse
> workspace's projects to find all the files. Every plugin is a project as
> well as you can create more than one project for managing configurations
> and one project for estimation data (another RMC added value). The problem
> view is used just as in Eclipse to tell you if you are missing elements in
> your workspace that other elements depend upon. You could ignore those
> errors or fix them by loading the project's that contain the missing
> elements.
>
> See the attached image with an example where I was using plugins managed
> in CVS and plugins managed in CC all at the same time in the same
> workspace. Plugins can now reside in complete different directories even
> on different machine. Just like Eclipse projects, you load them into your
> workspace and use them whenever you need to use them.
>
> However, RMC can still generate a library.xmi for you to manage libraries
> that are fully compatible with EPF Composer. For example, if you check the
> OpenUP CVS repository: it already has project files in each plugin
> directory. That is because I was already working with OpenUP in RMC 7.2;
> at the same time where the rest of the team continued working with EPF
> Composer. Two ways of loading the same library in a fully compatible way.
>
> Hope this helps,
> Peter.
>
>
>
> "Roman Smirak" <roman.smirak@tietoenator.com> wrote in message
> news:f9p6up$mmu$1@build.eclipse.org...
>> Hi Peter,
>>
>> thanks for info, however, RMC is based on EPF and I see current
>> solution
>> of EPF (library.xml) as a fundamental constraint for clear & easy
>> solution
>> at RMC level. Or?
>>
>> Can you please describe the scenario with RMC how it will be implemented?
>>
>> Or shall I post this at IBM Rational forum?
>>
>> Roman
>>
>> "Peter Haumer" <phaumer@us.ibm.com> wrote in message
>> news:f9o54i$924$1@build.eclipse.org...
>>> 1) no, the guid remains the same
>>> 2) not sure I understand the context of this, but I would recommend to
>>> only version manage your own files and if you are using cvs directly get
>>> the OpenUP sources from our server or if you use CC provide a zip/rar
>>> file
>>> with the OpenUP files that users can unzip as view-private files
>>> 3) Rational Method Composer 7.2 will fully support this scenario, which
>>> is
>>> not in scope for EPF Composer. For enterprise deployments and full
>>> scalability we recommend RMC in which every plugin can be maintained as
>>> an
>>> eclipse project and loaded when needed. In addition we provide project
>>> types for configurations, enterprise reports, and estimation models in
>>> RMC. EPF Composer is designed to support a single project per library
>>> only as it is primary used to maintain OpenUP. A workaround for you
>>> would
>>> be what I described above for (2).
>>>
>>> Best regards,
>>> Peter Haumer.
>>>
>>>
>>> "Roman Smirak" <roman.smirak@tietoenator.com> wrote in message
>>> news:f9kcmi$idh$1@build.eclipse.org...
>>>> Hi Ricardo,
>>>>
>>>> the way you described below is the one I've been using so far;
>>>> however,
>>>> I have few issues here:
>>>> 1/ What if you refactor the content of OpenUP, e.g. an element I was
>>>> referencing to is no longer in same package or plugin? Is there any
>>>> impact on UID?
>>>>
>>>> 2/ Currently we have the whole library in a versioning repository,
>>>> although everyone has got the basis (OpenUP, or RUP) with the tool
>>>> (EMC,
>>>> or RMC) - no problem for OpenUP, in case of RUP, well we are talking
>>>> about 60MB or so (which you have to check in every time you migrate)
>>>>
>>>> 3/ Let say we have a common basis in our department X, let's call it
>>>> OpenUP/X; there is a project A which will use it plus extension A minus
>>>> irrelevant content from basis; in case of eclipse plugins they simply
>>>> check out required plugins (they stay in touch with their updates by
>>>> department X authority) but they don't check out irrelevant plugins (no
>>>> mess) + create their new one and check it in their repository (will be
>>>> maintained there); currently they need to check out whole library X +
>>>> submit their plugins A into the library shared by others (and they do
>>>> same action as well => mess X + A + B + C, etc.) in order to fulfil the
>>>> use case (the basis maintained by department, a project extension
>>>> maintained by the project itself)
>>>>
>>>> I see the library.xml as a big constraint in this use case.
>>>>
>>>> Regards,
>>>>
>>>> Roman
>>>>
>>>> "Ricardo Balduino" <balduino@us.ibm.com> wrote in message
>>>> news:f9itco$87k$1@build.eclipse.org...
>>>>> In first paragraph I meant less cumbersome, yet safer ;-)
>>>>>
>>>>> "Ricardo Balduino" <balduino@us.ibm.com> wrote in message
>>>>> news:f9g8d0$db$1@build.eclipse.org...
>>>>>> Option A sounds less cumbersome and safer, as the EPF Composer tool
>>>>>> will take care of the work. In fact, according to your description of
>>>>>> option A, OpenUP 2.x would overwrite OpenUP 1.x.
>>>>>>
>>>>>> Instead of playing with importing a new OpenUP plug-in into your
>>>>>> existing library, have you considered getting the new OpenUP library
>>>>>> available and import your plug-in into it instead? With that
>>>>>> approach,
>>>>>> you are moving your plug-in around, so you know there are no
>>>>>> duplicates
>>>>>> of it in a brand new OpenUP library. If your plug-in initially
>>>>>> depended
>>>>>> on some OpenUP element that does not exist anymore when a new version
>>>>>> of OpenUP is released, the import will show you warnings, which will
>>>>>> help you to spot where you need to maintain your plug-in to extend
>>>>>> the
>>>>>> most current version of OpenUP. Additions to OpenUP will not affect
>>>>>> your plug-in.
>>>>>>
>>>>>> Cheers,
>>>>>>
>>>>>> Ricardo Balduino.
>>>>>>
>>>>>> "K.Benameur" <benameur@freesurf.fr> wrote in message
>>>>>> news:f9f8cn$ah0$1@build.eclipse.org...
>>>>>>> Hi Peter,
>>>>>>>
>>>>>>> Sorry to bother you with all my questions !!!
>>>>>>>
>>>>>>> I am not sure that I have completly understood your answer.
>>>>>>>
>>>>>>> To check this I propose a simple scenario :
>>>>>>> - I develop a library using Open Up 1.x.
>>>>>>> - A new version of Open Up is out let say 2.x
>>>>>>> - I wan't to take advantage of this new Open Up version.
>>>>>>>
>>>>>>> A) So ideally, I import the new version in my library and Open Up
>>>>>>> 1.x
>>>>>>> is updated to 2.x.
>>>>>>>
>>>>>>> I have the feeling that it will not be so simple as many links will
>>>>>>> be
>>>>>>> broken due to changes between 1.X and 2.X.
>>>>>>>
>>>>>>> B) I use the copy operation to have the 1.X & 2.X plugin in my
>>>>>>> library
>>>>>>>
>>>>>>> It seems that option B) is the one to go as you said that we have to
>>>>>>> do a copy as uuid must be unique.
>>>>>>> =>
>>>>>>> I have to do the migration manually by replacing elements of Open
>>>>>>> 1.x
>>>>>>> by their counterparts in 2.x.
>>>>>>>
>>>>>>> is it right or I missed something like a smart import that detect
>>>>>>> conflicts and propose to update automatically element that exist in
>>>>>>> 1.X & 2.X /delete obsolete element of 1.X / etc.. ?
>>>>>>>
>>>>>>> The question is what is the recommended procedure to perform a
>>>>>>> plug-in
>>>>>>> upgrade with a minimum effort ?
>>>>>>>
>>>>>>> My concern will be the maintenance cost of a library. If we build
>>>>>>> our
>>>>>>> library from many commercial or non commercial plugins we have to
>>>>>>> deal
>>>>>>> with their evolutions at a minimal cost.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Best Regards ...
>>>>>>>
>>>>>>> PS: I will be in vacation for the next 2 weeks so you have plenty of
>>>>>>> time for an anwser ;)
>>>>>>>
>>>>>>>
>>>>>>> PS:
>>>>>>> We use ClearCase but it will not help here except to roll back to a
>>>>>>> stable baseline and lock elements for modification ...
>>>>>>> We are developping our process in multi site. As we didn't want to
>>>>>>> add more complexity we decided to work only on one site (windows
>>>>>>> terminal server for the distant site) with one development branch in
>>>>>>> base CC.
>>>>>>> May be you have a successfull experience using CC multisite & UCM ?
>>>>>>> Can you share your experience ?
>>>>>>> Seems that in CC 7 (we use CC 6) the merge manager have a new option
>>>>>>> i.e. to always copy. So may be we can now have branches & multisite
>>>>>>> as
>>>>>>> now xmi file can be merged by a copy. I see here a potential source
>>>>>>> of
>>>>>>> trouble as we may surely end with invalid references if for instance
>>>>>>> the merge (copy) is done partially on some xmi ...
>>>>>>>
>>>>>>> Peter Haumer wrote:
>>>>>>>> Hello.
>>>>>>>> You cannot load multiple versions of the same plugin into the same
>>>>>>>> library. All library elements are identified by global unique ids
>>>>>>>> and
>>>>>>>> hence such ids needs to be unique. To get more than one copy of an
>>>>>>>> element you need to use the copy operation in the library view. In
>>>>>>>> general we recommend to use a version control system like Rational
>>>>>>>> ClearCase which allows you to label and restore old versions of
>>>>>>>> whole
>>>>>>>> groups of files.
>>>>>>>>
>>>>>>>> Best regards,
>>>>>>>> Peter.
>>>>>>>>
>>>>>>>> P.S.: Surely they should not be an exception when loading the same
>>>>>>>> content twice, but an error message. Please, file a bugzilla with
>>>>>>>> reproducible steps.
>>>>>>>>
>>>>>>>>
>>>>>>>> "K.Benameur" <benameur@freesurf.fr> wrote in message
>>>>>>>> news:f973f4$goo$1@build.eclipse.org...
>>>>>>>>> Hi all,
>>>>>>>>>
>>>>>>>>> It is a very good question. May be it can be addressed by an
>>>>>>>>> update
>>>>>>>>> of an existing guideline as the Development Guideline ?
>>>>>>>>>
>>>>>>>>> I think that we should have a "recommended" procedure from the EPF
>>>>>>>>> team to update plug-ins to a new version.
>>>>>>>>> It is now a fairly common scenario that multiple versions of the
>>>>>>>>> same plug-ins are out.
>>>>>>>>>
>>>>>>>>> And it is not only related to Open Up but for any library /
>>>>>>>>> plug-in
>>>>>>>>> as part of the development process (we are developing our own
>>>>>>>>> library / plug-ins without Open Up).
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> In short, what is the recommended procedure to migrate to a new
>>>>>>>>> version ? Do we have to export / import ? What are the risks? What
>>>>>>>>> we may lose ?
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Best Regards
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>
>
|
|
|
| Re: Migration to newever library version [message #39895 is a reply to message #37931] |
Thu, 06 September 2007 20:05 |
Eclipse User |
|
|
|
Originally posted by: kamal.osellus.com
This is a multi-part message in MIME format.
------=_NextPart_000_0011_01C7F09F.CAC4F440
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
"EPF Composer is designed to support a single project per library only =
as it is primary used to maintain OpenUP".
=20
I wanted to clarify if it really is the case that EPF Composer is =
designed to be primarily used to maintain OpenUP only. =20
=20
Kamal
"Roman Smirak" <roman.smirak@tietoenator.com> wrote in message =
news:f9rjjo$50e$1@build.eclipse.org...
Hi Peter,
that is great, the implementation perfectly matches with my vision. =
Why=20
not to have it in EPF? I guess many users would welcome the feature.
We have licences of RMC, however, we prefer to use EPF since early =
releases=20
are available.
Regards,
Roman
"Peter Haumer" <phaumer@us.ibm.com> wrote in message=20
news:f9qa5o$jac$1@build.eclipse.org...
> Hello Roman.
> Well, if our competitors can abuse this forum to plug their =
products; so=20
> can I :-)
>
> RMC 7.2 does not need the library.xmi file anymore as it uses the =
Eclipse=20
> workspace's projects to find all the files. Every plugin is a =
project as=20
> well as you can create more than one project for managing =
configurations=20
> and one project for estimation data (another RMC added value). The =
problem=20
> view is used just as in Eclipse to tell you if you are missing =
elements in=20
> your workspace that other elements depend upon. You could ignore =
those=20
> errors or fix them by loading the project's that contain the missing =
> elements.
>
> See the attached image with an example where I was using plugins =
managed=20
> in CVS and plugins managed in CC all at the same time in the same=20
> workspace. Plugins can now reside in complete different directories =
even=20
> on different machine. Just like Eclipse projects, you load them =
into your=20
> workspace and use them whenever you need to use them.
>
> However, RMC can still generate a library.xmi for you to manage =
libraries=20
> that are fully compatible with EPF Composer. For example, if you =
check the=20
> OpenUP CVS repository: it already has project files in each plugin=20
> directory. That is because I was already working with OpenUP in RMC =
7.2;=20
> at the same time where the rest of the team continued working with =
EPF=20
> Composer. Two ways of loading the same library in a fully =
compatible way.
>
> Hope this helps,
> Peter.
>
>
>
> "Roman Smirak" <roman.smirak@tietoenator.com> wrote in message=20
> news:f9p6up$mmu$1@build.eclipse.org...
>> Hi Peter,
>>
>> thanks for info, however, RMC is based on EPF and I see current=20
>> solution
>> of EPF (library.xml) as a fundamental constraint for clear & easy=20
>> solution
>> at RMC level. Or?
>>
>> Can you please describe the scenario with RMC how it will be =
implemented?
>>
>> Or shall I post this at IBM Rational forum?
>>
>> Roman
>>
>> "Peter Haumer" <phaumer@us.ibm.com> wrote in message
>> news:f9o54i$924$1@build.eclipse.org...
>>> 1) no, the guid remains the same
>>> 2) not sure I understand the context of this, but I would =
recommend to
>>> only version manage your own files and if you are using cvs =
directly get
>>> the OpenUP sources from our server or if you use CC provide a =
zip/rar=20
>>> file
>>> with the OpenUP files that users can unzip as view-private files
>>> 3) Rational Method Composer 7.2 will fully support this scenario, =
which=20
>>> is
>>> not in scope for EPF Composer. For enterprise deployments and =
full
>>> scalability we recommend RMC in which every plugin can be =
maintained as=20
>>> an
>>> eclipse project and loaded when needed. In addition we provide =
project
>>> types for configurations, enterprise reports, and estimation =
models in
>>> RMC. EPF Composer is designed to support a single project per =
library
>>> only as it is primary used to maintain OpenUP. A workaround for =
you=20
>>> would
>>> be what I described above for (2).
>>>
>>> Best regards,
>>> Peter Haumer.
>>>
>>>
>>> "Roman Smirak" <roman.smirak@tietoenator.com> wrote in message
>>> news:f9kcmi$idh$1@build.eclipse.org...
>>>> Hi Ricardo,
>>>>
>>>> the way you described below is the one I've been using so far;=20
>>>> however,
>>>> I have few issues here:
>>>> 1/ What if you refactor the content of OpenUP, e.g. an element I =
was
>>>> referencing to is no longer in same package or plugin? Is there =
any
>>>> impact on UID?
>>>>
>>>> 2/ Currently we have the whole library in a versioning =
repository,
>>>> although everyone has got the basis (OpenUP, or RUP) with the =
tool=20
>>>> (EMC,
>>>> or RMC) - no problem for OpenUP, in case of RUP, well we are =
talking
>>>> about 60MB or so (which you have to check in every time you =
migrate)
>>>>
>>>> 3/ Let say we have a common basis in our department X, let's call =
it
>>>> OpenUP/X; there is a project A which will use it plus extension A =
minus
>>>> irrelevant content from basis; in case of eclipse plugins they =
simply
>>>> check out required plugins (they stay in touch with their updates =
by
>>>> department X authority) but they don't check out irrelevant =
plugins (no
>>>> mess) + create their new one and check it in their repository =
(will be
>>>> maintained there); currently they need to check out whole library =
X +
>>>> submit their plugins A into the library shared by others (and =
they do
>>>> same action as well =3D> mess X + A + B + C, etc.) in order to =
fulfil the
>>>> use case (the basis maintained by department, a project extension
>>>> maintained by the project itself)
>>>>
>>>> I see the library.xml as a big constraint in this use case.
>>>>
>>>> Regards,
>>>>
>>>> Roman
>>>>
>>>> "Ricardo Balduino" <balduino@us.ibm.com> wrote in message
>>>> news:f9itco$87k$1@build.eclipse.org...
>>>>> In first paragraph I meant less cumbersome, yet safer ;-)
>>>>>
>>>>> "Ricardo Balduino" <balduino@us.ibm.com> wrote in message
>>>>> news:f9g8d0$db$1@build.eclipse.org...
>>>>>> Option A sounds less cumbersome and safer, as the EPF Composer =
tool
>>>>>> will take care of the work. In fact, according to your =
description of
>>>>>> option A, OpenUP 2.x would overwrite OpenUP 1.x.
>>>>>>
>>>>>> Instead of playing with importing a new OpenUP plug-in into =
your
>>>>>> existing library, have you considered getting the new OpenUP =
library
>>>>>> available and import your plug-in into it instead? With that=20
>>>>>> approach,
>>>>>> you are moving your plug-in around, so you know there are no=20
>>>>>> duplicates
>>>>>> of it in a brand new OpenUP library. If your plug-in initially=20
>>>>>> depended
>>>>>> on some OpenUP element that does not exist anymore when a new =
version
>>>>>> of OpenUP is released, the import will show you warnings, which =
will
>>>>>> help you to spot where you need to maintain your plug-in to =
extend=20
>>>>>> the
>>>>>> most current version of OpenUP. Additions to OpenUP will not =
affect
>>>>>> your plug-in.
>>>>>>
>>>>>> Cheers,
>>>>>>
>>>>>> Ricardo Balduino.
>>>>>>
>>>>>> "K.Benameur" <benameur@freesurf.fr> wrote in message
>>>>>> news:f9f8cn$ah0$1@build.eclipse.org...
>>>>>>> Hi Peter,
>>>>>>>
>>>>>>> Sorry to bother you with all my questions !!!
>>>>>>>
>>>>>>> I am not sure that I have completly understood your answer.
>>>>>>>
>>>>>>> To check this I propose a simple scenario :
>>>>>>> - I develop a library using Open Up 1.x.
>>>>>>> - A new version of Open Up is out let say 2.x
>>>>>>> - I wan't to take advantage of this new Open Up version.
>>>>>>>
>>>>>>> A) So ideally, I import the new version in my library and Open =
Up=20
>>>>>>> 1.x
>>>>>>> is updated to 2.x.
>>>>>>>
>>>>>>> I have the feeling that it will not be so simple as many links =
will=20
>>>>>>> be
>>>>>>> broken due to changes between 1.X and 2.X.
>>>>>>>
>>>>>>> B) I use the copy operation to have the 1.X & 2.X plugin in my =
>>>>>>> library
>>>>>>>
>>>>>>> It seems that option B) is the one to go as you said that we =
have to
>>>>>>> do a copy as uuid must be unique.
>>>>>>> =3D>
>>>>>>> I have to do the migration manually by replacing elements of =
Open=20
>>>>>>> 1.x
>>>>>>> by their counterparts in 2.x.
>>>>>>>
>>>>>>> is it right or I missed something like a smart import that =
detect
>>>>>>> conflicts and propose to update automatically element that =
exist in
>>>>>>> 1.X & 2.X /delete obsolete element of 1.X / etc.. ?
>>>>>>>
>>>>>>> The question is what is the recommended procedure to perform a =
>>>>>>> plug-in
>>>>>>> upgrade with a minimum effort ?
>>>>>>>
>>>>>>> My concern will be the maintenance cost of a library. If we =
build=20
>>>>>>> our
>>>>>>> library from many commercial or non commercial plugins we have =
to=20
>>>>>>> deal
>>>>>>> with their evolutions at a minimal cost.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Best Regards ...
>>>>>>>
>>>>>>> PS: I will be in vacation for the next 2 weeks so you have =
plenty of
>>>>>>> time for an anwser ;)
>>>>>>>
>>>>>>>
>>>>>>> PS:
>>>>>>> We use ClearCase but it will not help here except to roll =
back to a
>>>>>>> stable baseline and lock elements for modification ...
>>>>>>> We are developping our process in multi site. As we didn't =
want to
>>>>>>> add more complexity we decided to work only on one site =
(windows
>>>>>>> terminal server for the distant site) with one development =
branch in
>>>>>>> base CC.
>>>>>>> May be you have a successfull experience using CC multisite & =
UCM ?
>>>>>>> Can you share your experience ?
>>>>>>> Seems that in CC 7 (we use CC 6) the merge manager have a new =
option
>>>>>>> i.e. to always copy. So may be we can now have branches & =
multisite=20
>>>>>>> as
>>>>>>> now xmi file can be merged by a copy. I see here a potential =
source=20
>>>>>>> of
>>>>>>> trouble as we may surely end with invalid references if for =
instance
>>>>>>> the merge (copy) is done partially on some xmi ...
>>>>>>>
>>>>>>> Peter Haumer wrote:
>>>>>>>> Hello.
>>>>>>>> You cannot load multiple versions of the same plugin into the =
same
>>>>>>>> library. All library elements are identified by global unique =
ids=20
>>>>>>>> and
>>>>>>>> hence such ids needs to be unique. To get more than one copy =
of an
>>>>>>>> element you need to use the copy operation in the library =
view. In
>>>>>>>> general we recommend to use a version control system like =
Rational
>>>>>>>> ClearCase which allows you to label and restore old versions =
of=20
>>>>>>>> whole
>>>>>>>> groups of files.
>>>>>>>>
>>>>>>>> Best regards,
>>>>>>>> Peter.
>>>>>>>>
>>>>>>>> P.S.: Surely they should not be an exception when loading the =
same
>>>>>>>> content twice, but an error message. Please, file a bugzilla =
with
>>>>>>>> reproducible steps.
>>>>>>>>
>>>>>>>>
>>>>>>>> "K.Benameur" <benameur@freesurf.fr> wrote in message
>>>>>>>> news:f973f4$goo$1@build.eclipse.org...
>>>>>>>>> Hi all,
>>>>>>>>>
>>>>>>>>> It is a very good question. May be it can be addressed by an =
>>>>>>>>> update
>>>>>>>>> of an existing guideline as the Development Guideline ?
>>>>>>>>>
>>>>>>>>> I think that we should have a "recommended" procedure from =
the EPF
>>>>>>>>> team to update plug-ins to a new version.
>>>>>>>>> It is now a fairly common scenario that multiple versions =
of the
>>>>>>>>> same plug-ins are out.
>>>>>>>>>
>>>>>>>>> And it is not only related to Open Up but for any library /=20
>>>>>>>>> plug-in
>>>>>>>>> as part of the development process (we are developing our =
own
>>>>>>>>> library / plug-ins without Open Up).
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> In short, what is the recommended procedure to migrate to a =
new
>>>>>>>>> version ? Do we have to export / import ? What are the =
risks? What
>>>>>>>>> we may lose ?
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Best Regards
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>
>=20
------=_NextPart_000_0011_01C7F09F.CAC4F440
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.6000.16527" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>
<P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><FONT size=3D3><FONT=20
face=3D"Times New Roman">=93EPF Composer is designed to support a single =
project per=20
library only as it is primary used to maintain OpenUP=94.<?xml:namespace =
prefix =3D=20
o ns =3D "urn:schemas-microsoft-com:office:office" =
/><o:p></o:p></FONT></FONT></P>
<P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><o:p><FONT =
face=3D"Times New Roman"=20
size=3D3> </FONT></o:p></P>
<P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><FONT size=3D3><FONT=20
face=3D"Times New Roman">I wanted to clarify if it really is =
the case=20
that EPF Composer is designed to be primarily used to maintain OpenUP =
only.=20
<o:p></o:p></FONT></FONT></P>
<P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><o:p><FONT =
face=3D"Times New Roman"=20
size=3D3> </FONT></o:p></P>
<P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><FONT size=3D3><FONT=20
face=3D"Times New Roman">Kamal<o:p></o:p></FONT></FONT></P></FONT></DIV >
<BLOCKQUOTE=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
<DIV>"Roman Smirak" <<A=20
=
href=3D"mailto:roman.smirak@tietoenator.com">roman.smirak@tietoenator.com=
</A>>=20
wrote in message <A=20
=
href=3D"news:f9rjjo$50e$1@build.eclipse.org">news:f9rjjo$50e$1@build.ecli=
pse.org</A>...</DIV>Hi=20
Peter,<BR><BR> that is great, the implementation perfectly =
matches=20
with my vision. Why <BR>not to have it in EPF? I guess many users =
would=20
welcome the feature.<BR><BR>We have licences of RMC, however, we =
prefer to use=20
EPF since early releases <BR>are=20
available.<BR><BR>Regards,<BR><BR>Roman<BR><BR>"Peter Haumer" <<A=20
href=3D"mailto:phaumer@us.ibm.com">phaumer@us.ibm.com</A>> wrote in =
message=20
<BR><A=20
=
href=3D"news:f9qa5o$jac$1@build.eclipse.org">news:f9qa5o$jac$1@build.ecli=
pse.org</A>...<BR>>=20
Hello Roman.<BR>> Well, if our competitors can abuse this forum to =
plug=20
their products; so <BR>> can I :-)<BR>><BR>> RMC 7.2 does not =
need=20
the library.xmi file anymore as it uses the Eclipse <BR>> =
workspace's=20
projects to find all the files. Every plugin is a project as <BR>> =
well as=20
you can create more than one project for managing configurations =
<BR>> and=20
one project for estimation data (another RMC added value). The problem =
<BR>> view is used just as in Eclipse to tell you if you are =
missing=20
elements in <BR>> your workspace that other elements depend =
upon. You=20
could ignore those <BR>> errors or fix them by loading the =
project's that=20
contain the missing <BR>> elements.<BR>><BR>> See the =
attached image=20
with an example where I was using plugins managed <BR>> in CVS and =
plugins=20
managed in CC all at the same time in the same <BR>> workspace. =
Plugins can=20
now reside in complete different directories even <BR>> on =
different=20
machine. Just like Eclipse projects, you load them into your =
<BR>>=20
workspace and use them whenever you need to use them.<BR>><BR>> =
However,=20
RMC can still generate a library.xmi for you to manage libraries =
<BR>> that=20
are fully compatible with EPF Composer. For example, if you check the =
<BR>>=20
OpenUP CVS repository: it already has project files in each plugin =
<BR>>=20
directory. That is because I was already working with OpenUP in =
RMC 7.2;=20
<BR>> at the same time where the rest of the team continued working =
with=20
EPF <BR>> Composer. Two ways of loading the same library in a =
fully=20
compatible way.<BR>><BR>> Hope this helps,<BR>>=20
Peter.<BR>><BR>><BR>><BR>> "Roman Smirak" <<A=20
=
href=3D"mailto:roman.smirak@tietoenator.com">roman.smirak@tietoenator.com=
</A>>=20
wrote in message <BR>> <A=20
=
href=3D"news:f9p6up$mmu$1@build.eclipse.org">news:f9p6up$mmu$1@build.ecli=
pse.org</A>...<BR>>>=20
Hi Peter,<BR>>><BR>>> thanks for info, =
however, RMC is=20
based on EPF and I see current <BR>>> solution<BR>>> of =
EPF=20
(library.xml) as a fundamental constraint for clear & easy =
<BR>>>=20
solution<BR>>> at RMC level. Or?<BR>>><BR>>> Can you =
please=20
describe the scenario with RMC how it will be=20
implemented?<BR>>><BR>>> Or shall I post this at IBM =
Rational=20
forum?<BR>>><BR>>> Roman<BR>>><BR>>> "Peter =
Haumer"=20
<<A href=3D"mailto:phaumer@us.ibm.com">phaumer@us.ibm.com</A>> =
wrote in=20
message<BR>>> <A=20
=
href=3D"news:f9o54i$924$1@build.eclipse.org">news:f9o54i$924$1@build.ecli=
pse.org</A>...<BR>>>>=20
1) no, the guid remains the same<BR>>>> 2) not sure I =
understand the=20
context of this, but I would recommend to<BR>>>> only version =
manage=20
your own files and if you are using cvs directly get<BR>>>> =
the=20
OpenUP sources from our server or if you use CC provide a zip/rar=20
<BR>>>> file<BR>>>> with the OpenUP files that users =
can=20
unzip as view-private files<BR>>>> 3) Rational Method =
Composer 7.2=20
will fully support this scenario, which <BR>>>> =
is<BR>>>>=20
not in scope for EPF Composer. For enterprise deployments and=20
full<BR>>>> scalability we recommend RMC in which every =
plugin can be=20
maintained as <BR>>>> an<BR>>>> eclipse project and =
loaded=20
when needed. In addition we provide project<BR>>>> types for=20
configurations, enterprise reports, and estimation models =
in<BR>>>>=20
RMC. EPF Composer is designed to support a single project per=20
library<BR>>>> only as it is primary used to maintain =
OpenUP. A=20
workaround for you <BR>>>> would<BR>>>> be what I =
described=20
above for (2).<BR>>>><BR>>>> Best =
regards,<BR>>>>=20
Peter Haumer.<BR>>>><BR>>>> <BR>>>> "Roman =
Smirak"=20
<<A=20
=
href=3D"mailto:roman.smirak@tietoenator.com">roman.smirak@tietoenator.com=
</A>>=20
wrote in message<BR>>>> <A=20
=
href=3D"news:f9kcmi$idh$1@build.eclipse.org">news:f9kcmi$idh$1@build.ecli=
pse.org</A>...<BR>>>>>=20
Hi Ricardo,<BR>>>>><BR>>>>> the =
way you=20
described below is the one I've been using so far; =
<BR>>>>>=20
however,<BR>>>>> I have few issues =
here:<BR>>>>> 1/=20
What if you refactor the content of OpenUP, e.g. an element I=20
was<BR>>>>> referencing to is no longer in same package or =
plugin?=20
Is there any<BR>>>>> impact on=20
UID?<BR>>>>><BR>>>>> 2/ Currently we have the =
whole=20
library in a versioning repository,<BR>>>>> although =
everyone has=20
got the basis (OpenUP, or RUP) with the tool <BR>>>>>=20
(EMC,<BR>>>>> or RMC) - no problem for OpenUP, in case of =
RUP,=20
well we are talking<BR>>>>> about 60MB or so (which you =
have to=20
check in every time you =
migrate)<BR>>>>><BR>>>>> 3/=20
Let say we have a common basis in our department X, let's call=20
it<BR>>>>> OpenUP/X; there is a project A which will use =
it plus=20
extension A minus<BR>>>>> irrelevant content from basis; =
in case=20
of eclipse plugins they simply<BR>>>>> check out required =
plugins=20
(they stay in touch with their updates by<BR>>>>> =
department X=20
authority) but they don't check out irrelevant plugins =
(no<BR>>>>>=20
mess) + create their new one and check it in their repository (will=20
be<BR>>>>> maintained there); currently they need to check =
out=20
whole library X +<BR>>>>> submit their plugins A into the =
library=20
shared by others (and they do<BR>>>>> same action as well =
=3D>=20
mess X + A + B + C, etc.) in order to fulfil the<BR>>>>> =
use case=20
(the basis maintained by department, a project =
extension<BR>>>>>=20
maintained by the project =
itself)<BR>>>>><BR>>>>> I=20
see the library.xml as a big constraint in this use=20
case.<BR>>>>><BR>>>>>=20
Regards,<BR>>>>><BR>>>>>=20
Roman<BR>>>>><BR>>>>> "Ricardo Balduino" =
<<A=20
href=3D"mailto:balduino@us.ibm.com">balduino@us.ibm.com</A>> wrote =
in=20
message<BR>>>>> <A=20
=
href=3D"news:f9itco$87k$1@build.eclipse.org">news:f9itco$87k$1@build.ecli=
pse.org</A>...<BR>>>>>>=20
In first paragraph I meant less cumbersome, yet safer=20
;-)<BR>>>>>><BR>>>>>> "Ricardo Balduino" =
<<A=20
href=3D"mailto:balduino@us.ibm.com">balduino@us.ibm.com</A>> wrote =
in=20
message<BR>>>>>> <A=20
=
href=3D"news:f9g8d0$db$1@build.eclipse.org">news:f9g8d0$db$1@build.eclips=
e.org</A>...<BR>>>>>>>=20
Option A sounds less cumbersome and safer, as the EPF Composer=20
tool<BR>>>>>>> will take care of the work. In fact,=20
according to your description of<BR>>>>>>> option A, =
OpenUP=20
2.x would overwrite OpenUP=20
1.x.<BR>>>>>>><BR >>>>>>> Instead =
of=20
playing with importing a new OpenUP plug-in into=20
your<BR>>>>>>> existing library, have you considered =
getting=20
the new OpenUP library<BR>>>>>>> available and =
import your=20
plug-in into it instead? With that <BR>>>>>>>=20
approach,<BR>>>>>>> you are moving your plug-in =
around, so=20
you know there are no <BR>>>>>>>=20
duplicates<BR>>>>>>> of it in a brand new OpenUP =
library. If=20
your plug-in initially <BR>>>>>>>=20
depended<BR>>>>>>> on some OpenUP element that does =
not=20
exist anymore when a new version<BR>>>>>>> of OpenUP =
is=20
released, the import will show you warnings, which=20
will<BR>>>>>>> help you to spot where you need to =
maintain=20
your plug-in to extend <BR>>>>>>>=20
the<BR>>>>>>> most current version of OpenUP. =
Additions to=20
OpenUP will not affect<BR>>>>>>> your=20
plug-in.<BR>>>>>>> <BR>>>>>>>=20
Cheers,<BR>>>>>>> <BR>>>>>>> =
Ricardo=20
Balduino.<BR>>>>>>> <BR>>>>>>> =
"K.Benameur"=20
<<A =
href=3D"mailto:benameur@freesurf.fr">benameur@freesurf.fr</A>> wrote=20
in message<BR>>>>>>> <A=20
=
href=3D"news:f9f8cn$ah0$1@build.eclipse.org">news:f9f8cn$ah0$1@build.ecli=
pse.org</A>...<BR>>>>>>>>=20
Hi =
Peter,<BR>>>>>>>> <BR>>>>>>>>=20
Sorry to bother you with all my questions=20
!!!<BR>>>>>>>> <BR>>>>>>>> I =
am not=20
sure that I have completly understood your=20
=
answer.<BR>>>>>>>> <BR>>>>>>>> =
To=20
check this I propose a simple scenario =20
:<BR> >>>>>>>& ;nbsp; - I develop a library =
using Open=20
Up 1.x.<BR> >>>>>>>& ;nbsp; - A new version of =
Open Up=20
is out let say 2.x<BR> >>>>>>>& ;nbsp; - I wan't to =
take=20
advantage of this new Open Up=20
=
version.<BR>>>>>>>> <BR>>>>>>>> =
A) So=20
ideally, I import the new version in my library and Open Up=20
<BR>>>>>>>> 1.x<BR>>>>>>>> =
is=20
updated to=20
2.x.<BR>>>>>>>> <BR>>>>>>>> I =
have=20
the feeling that it will not be so simple as many links will=20
<BR>>>>>>>> be<BR>>>>>>>> =
broken due=20
to changes between 1.X and=20
2.X.<BR>>>>>>>> <BR>>>>>>>> =
B) I use=20
the copy operation to have the 1.X & 2.X plugin in my=20
<BR>>>>>>>>=20
=
library<BR>>>>>>>> <BR>>>>>>>> =
It=20
seems that option B) is the one to go as you said that we have=20
to<BR>>>>>>>> do a copy as uuid must be=20
unique.<BR>>>>>>>> =
=3D><BR>>>>>>>>=20
I have to do the migration manually by replacing elements of =
Open=20
<BR>>>>>>>> 1.x<BR>>>>>>>> =
by their=20
counterparts in=20
2.x.<BR>>>>>>>> <BR>>>>>>>> =
is it=20
right or I missed something like a smart import that=20
detect<BR>>>>>>>> conflicts and propose to update =
automatically element that exist in<BR>>>>>>>> =
1.X &=20
2.X /delete obsolete element of 1.X / etc..=20
?<BR>>>>>>>> <BR>>>>>>>> The =
question=20
is what is the recommended procedure to perform a=20
<BR>>>>>>>> =
plug-in<BR>>>>>>>>=20
upgrade with a minimum effort=20
?<BR>>>>>>>> <BR>>>>>>>> My =
concern=20
will be the maintenance cost of a library. If we build=20
<BR>>>>>>>> our<BR>>>>>>>> =
library=20
from many commercial or non commercial plugins we have to=20
<BR>>>>>>>> deal<BR>>>>>>>> =
with=20
their evolutions at a minimal=20
=
cost.<BR>>>>>>>> <BR>>>>>>>> <BR>=
>>>>>>><BR >>>>>>>><BR >>>&=
gt;>>>>=20
Best Regards=20
...<BR>>>>>>>> <BR>>>>>>>> =
PS: I will=20
be in vacation for the next 2 weeks so you have plenty=20
of<BR>>>>>>>> time for an anwser=20
=
;)<BR>>>>>>>> <BR>>>>>>>> <BR>>=
;>>>>>>=20
PS:<BR> >>>>>>>& ;nbsp; We use ClearCase but it will =
not=20
help here except to roll back to a<BR>>>>>>>> =
stable=20
baseline and lock elements for modification=20
...<BR> >>>>>>>& ;nbsp; We are developping our =
process in=20
multi site. As we didn't want to<BR>>>>>>>> add =
more=20
complexity we decided to work only on one site=20
(windows<BR>>>>>>>> terminal server for the =
distant site)=20
with one development branch in<BR>>>>>>>> base=20
CC.<BR>>>>>>>> May be you have a successfull =
experience=20
using CC multisite & UCM ?<BR>>>>>>>> Can you =
share=20
your experience ?<BR>>>>>>>> Seems that in CC 7 =
(we use=20
CC 6) the merge manager have a new =
option<BR>>>>>>>> i.e.=20
to always copy. So may be we can now have branches & multisite=20
<BR>>>>>>>> as<BR>>>>>>>> =
now xmi=20
file can be merged by a copy. I see here a potential source=20
<BR>>>>>>>> of<BR>>>>>>>> =
trouble as=20
we may surely end with invalid references if for=20
instance<BR>>>>>>>> the merge (copy) is done =
partially on=20
some xmi =
....<BR>>>>>>>> <BR>>>>>>>>=20
Peter Haumer wrote:<BR> >>>>>>>& ;gt;=20
Hello.<BR> >>>>>>>& ;gt; You cannot load multiple =
versions=20
of the same plugin into the same<BR> >>>>>>>& ;gt; =
library.=20
All library elements are identified by global unique ids=20
<BR> >>>>>>>& ;gt; =
and<BR> >>>>>>>& ;gt;=20
hence such ids needs to be unique. To get more than one copy of=20
an<BR> >>>>>>>& ;gt; element you need to use the =
copy=20
operation in the library view. In<BR> >>>>>>>& ;gt; =
general=20
we recommend to use a version control system like=20
Rational<BR> >>>>>>>& ;gt; ClearCase which allows =
you to=20
label and restore old versions of <BR> >>>>>>>& ;gt; =
whole<BR> >>>>>>>& ;gt; groups of=20
=
files.<BR> >>>>>>>& ;gt; <BR>>>>>>>>=
;>=20
Best regards,<BR> >>>>>>>& ;gt;=20
=
Peter.<BR> >>>>>>>& ;gt; <BR>>>>>>>>=
;>=20
P.S.: Surely they should not be an exception when loading the=20
same<BR> >>>>>>>& ;gt; content twice, but an error=20
message. Please, file a bugzilla=20
with<BR> >>>>>>>& ;gt; reproducible=20
=
steps.<BR> >>>>>>>& ;gt; <BR>>>>>>>>=
;><BR> >>>>>>>& ;gt;=20
"K.Benameur" <<A=20
href=3D"mailto:benameur@freesurf.fr">benameur@freesurf.fr</A>> =
wrote in=20
message<BR> >>>>>>>& ;gt; <A=20
=
href=3D"news:f973f4$goo$1@build.eclipse.org">news:f973f4$goo$1@build.ecli=
pse.org</A>...<BR> >>>>>>>& ;gt;>=20
Hi=20
=
all,<BR> >>>>>>>& ;gt;> <BR>>>>>>>&=
gt;>>=20
It is a very good question. May be it can be addressed by an=20
<BR> >>>>>>>& ;gt;>=20
update<BR> >>>>>>>& ;gt;> of an existing =
guideline as the=20
Development Guideline=20
=
?<BR> >>>>>>>& ;gt;> <BR>>>>>>>>=
>>=20
I think that we should have a "recommended" procedure from the=20
EPF<BR> >>>>>>>& ;gt;> team to update plug-ins to =
a new=20
version.<BR> >>>>>>>& ;gt;> It is now a =
fairly=20
common scenario that multiple versions of=20
the<BR> >>>>>>>& ;gt;> same plug-ins are=20
=
out.<BR> >>>>>>>& ;gt;> <BR>>>>>>>&=
gt;>>=20
And it is not only related to Open Up but for any library /=20
<BR> >>>>>>>& ;gt;>=20
plug-in<BR> >>>>>>>& ;gt;> as part of the =
development=20
process (we are developing our =
own<BR> >>>>>>>& ;gt;>=20
library / plug-ins without Open=20
=
Up).<BR> >>>>>>>& ;gt;> <BR>>>>>>>&=
gt;>><BR> >>>>>>>& ;gt;> =20
In short, what is the recommended procedure to migrate to a=20
new<BR> >>>>>>>& ;gt;> version ? Do we have to =
export /=20
import ? What are the risks? =
What<BR> >>>>>>>& ;gt;> we=20
may lose=20
=
?<BR> >>>>>>>& ;gt;> <BR>>>>>>>>=
>><BR> >>>>>>>& ;gt;>=20
Best=20
=
Regards<BR> >>>>>>>& ;gt;> <BR>>>>>>&g=
t;>>><BR> >>>>>>>& ;gt; <BR>>>>>>=
;><BR>>>>>><BR>>>>>> <BR>>>>>=
<BR>>>>><BR>>>> <BR>>>><BR>>><BR>>&=
gt;<BR>><BR>><BR>>=20
<BR><BR></BLOCKQUOTE></BODY></HTML>
------=_NextPart_000_0011_01C7F09F.CAC4F440--
|
|
|
| Re: Migration to newever library version [message #39929 is a reply to message #39895] |
Thu, 06 September 2007 20:22 |
Ricardo Balduino
Messages: 191
Registered: July 2009 |
Senior Member |
|
|
This is a multi-part message in MIME format.
------=_NextPart_000_0047_01C7F089.063F8380
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
>>> I wanted to clarify if it really is the case that EPF Composer is =
designed to be primarily used to maintain OpenUP only. =20
It is not really the case.
EPF Composer is used by the EPF team to maintain OpenUP, DSDM, Scrum, XP =
and any other processes being captured today and in the future under the =
EPF project.
Moreover, EPF users can capture their own home-grown processes or =
extensions to available processes using EPF Composer.
I hope this clarifies your question.
Regards,
Ricardo Balduino.
"Kamal Ahluwalia" <kamal@osellus.com> wrote in message =
news:fbpmjg$rai$1@build.eclipse.org...
"EPF Composer is designed to support a single project per library only =
as it is primary used to maintain OpenUP".
=20
I wanted to clarify if it really is the case that EPF Composer is =
designed to be primarily used to maintain OpenUP only. =20
=20
Kamal
"Roman Smirak" <roman.smirak@tietoenator.com> wrote in message =
news:f9rjjo$50e$1@build.eclipse.org...
Hi Peter,
that is great, the implementation perfectly matches with my =
vision. Why=20
not to have it in EPF? I guess many users would welcome the feature.
We have licences of RMC, however, we prefer to use EPF since early =
releases=20
are available.
Regards,
Roman
"Peter Haumer" <phaumer@us.ibm.com> wrote in message=20
news:f9qa5o$jac$1@build.eclipse.org...
> Hello Roman.
> Well, if our competitors can abuse this forum to plug their =
products; so=20
> can I :-)
>
> RMC 7.2 does not need the library.xmi file anymore as it uses the =
Eclipse=20
> workspace's projects to find all the files. Every plugin is a =
project as=20
> well as you can create more than one project for managing =
configurations=20
> and one project for estimation data (another RMC added value). The =
problem=20
> view is used just as in Eclipse to tell you if you are missing =
elements in=20
> your workspace that other elements depend upon. You could ignore =
those=20
> errors or fix them by loading the project's that contain the =
missing=20
> elements.
>
> See the attached image with an example where I was using plugins =
managed=20
> in CVS and plugins managed in CC all at the same time in the same=20
> workspace. Plugins can now reside in complete different =
directories even=20
> on different machine. Just like Eclipse projects, you load them =
into your=20
> workspace and use them whenever you need to use them.
>
> However, RMC can still generate a library.xmi for you to manage =
libraries=20
> that are fully compatible with EPF Composer. For example, if you =
check the=20
> OpenUP CVS repository: it already has project files in each plugin =
> directory. That is because I was already working with OpenUP in =
RMC 7.2;=20
> at the same time where the rest of the team continued working with =
EPF=20
> Composer. Two ways of loading the same library in a fully =
compatible way.
>
> Hope this helps,
> Peter.
>
>
>
> "Roman Smirak" <roman.smirak@tietoenator.com> wrote in message=20
> news:f9p6up$mmu$1@build.eclipse.org...
>> Hi Peter,
>>
>> thanks for info, however, RMC is based on EPF and I see current =
>> solution
>> of EPF (library.xml) as a fundamental constraint for clear & easy =
>> solution
>> at RMC level. Or?
>>
>> Can you please describe the scenario with RMC how it will be =
implemented?
>>
>> Or shall I post this at IBM Rational forum?
>>
>> Roman
>>
>> "Peter Haumer" <phaumer@us.ibm.com> wrote in message
>> news:f9o54i$924$1@build.eclipse.org...
>>> 1) no, the guid remains the same
>>> 2) not sure I understand the context of this, but I would =
recommend to
>>> only version manage your own files and if you are using cvs =
directly get
>>> the OpenUP sources from our server or if you use CC provide a =
zip/rar=20
>>> file
>>> with the OpenUP files that users can unzip as view-private files
>>> 3) Rational Method Composer 7.2 will fully support this =
scenario, which=20
>>> is
>>> not in scope for EPF Composer. For enterprise deployments and =
full
>>> scalability we recommend RMC in which every plugin can be =
maintained as=20
>>> an
>>> eclipse project and loaded when needed. In addition we provide =
project
>>> types for configurations, enterprise reports, and estimation =
models in
>>> RMC. EPF Composer is designed to support a single project per =
library
>>> only as it is primary used to maintain OpenUP. A workaround for =
you=20
>>> would
>>> be what I described above for (2).
>>>
>>> Best regards,
>>> Peter Haumer.
>>>
>>>
>>> "Roman Smirak" <roman.smirak@tietoenator.com> wrote in message
>>> news:f9kcmi$idh$1@build.eclipse.org...
>>>> Hi Ricardo,
>>>>
>>>> the way you described below is the one I've been using so =
far;=20
>>>> however,
>>>> I have few issues here:
>>>> 1/ What if you refactor the content of OpenUP, e.g. an element =
I was
>>>> referencing to is no longer in same package or plugin? Is there =
any
>>>> impact on UID?
>>>>
>>>> 2/ Currently we have the whole library in a versioning =
repository,
>>>> although everyone has got the basis (OpenUP, or RUP) with the =
tool=20
>>>> (EMC,
>>>> or RMC) - no problem for OpenUP, in case of RUP, well we are =
talking
>>>> about 60MB or so (which you have to check in every time you =
migrate)
>>>>
>>>> 3/ Let say we have a common basis in our department X, let's =
call it
>>>> OpenUP/X; there is a project A which will use it plus extension =
A minus
>>>> irrelevant content from basis; in case of eclipse plugins they =
simply
>>>> check out required plugins (they stay in touch with their =
updates by
>>>> department X authority) but they don't check out irrelevant =
plugins (no
>>>> mess) + create their new one and check it in their repository =
(will be
>>>> maintained there); currently they need to check out whole =
library X +
>>>> submit their plugins A into the library shared by others (and =
they do
>>>> same action as well =3D> mess X + A + B + C, etc.) in order to =
fulfil the
>>>> use case (the basis maintained by department, a project =
extension
>>>> maintained by the project itself)
>>>>
>>>> I see the library.xml as a big constraint in this use case.
>>>>
>>>> Regards,
>>>>
>>>> Roman
>>>>
>>>> "Ricardo Balduino" <balduino@us.ibm.com> wrote in message
>>>> news:f9itco$87k$1@build.eclipse.org...
>>>>> In first paragraph I meant less cumbersome, yet safer ;-)
>>>>>
>>>>> "Ricardo Balduino" <balduino@us.ibm.com> wrote in message
>>>>> news:f9g8d0$db$1@build.eclipse.org...
>>>>>> Option A sounds less cumbersome and safer, as the EPF =
Composer tool
>>>>>> will take care of the work. In fact, according to your =
description of
>>>>>> option A, OpenUP 2.x would overwrite OpenUP 1.x.
>>>>>>
>>>>>> Instead of playing with importing a new OpenUP plug-in into =
your
>>>>>> existing library, have you considered getting the new OpenUP =
library
>>>>>> available and import your plug-in into it instead? With that=20
>>>>>> approach,
>>>>>> you are moving your plug-in around, so you know there are no=20
>>>>>> duplicates
>>>>>> of it in a brand new OpenUP library. If your plug-in =
initially=20
>>>>>> depended
>>>>>> on some OpenUP element that does not exist anymore when a new =
version
>>>>>> of OpenUP is released, the import will show you warnings, =
which will
>>>>>> help you to spot where you need to maintain your plug-in to =
extend=20
>>>>>> the
>>>>>> most current version of OpenUP. Additions to OpenUP will not =
affect
>>>>>> your plug-in.
>>>>>>
>>>>>> Cheers,
>>>>>>
>>>>>> Ricardo Balduino.
>>>>>>
>>>>>> "K.Benameur" <benameur@freesurf.fr> wrote in message
>>>>>> news:f9f8cn$ah0$1@build.eclipse.org...
>>>>>>> Hi Peter,
>>>>>>>
>>>>>>> Sorry to bother you with all my questions !!!
>>>>>>>
>>>>>>> I am not sure that I have completly understood your answer.
>>>>>>>
>>>>>>> To check this I propose a simple scenario :
>>>>>>> - I develop a library using Open Up 1.x.
>>>>>>> - A new version of Open Up is out let say 2.x
>>>>>>> - I wan't to take advantage of this new Open Up version.
>>>>>>>
>>>>>>> A) So ideally, I import the new version in my library and =
Open Up=20
>>>>>>> 1.x
>>>>>>> is updated to 2.x.
>>>>>>>
>>>>>>> I have the feeling that it will not be so simple as many =
links will=20
>>>>>>> be
>>>>>>> broken due to changes between 1.X and 2.X.
>>>>>>>
>>>>>>> B) I use the copy operation to have the 1.X & 2.X plugin in =
my=20
>>>>>>> library
>>>>>>>
>>>>>>> It seems that option B) is the one to go as you said that we =
have to
>>>>>>> do a copy as uuid must be unique.
>>>>>>> =3D>
>>>>>>> I have to do the migration manually by replacing elements =
of Open=20
>>>>>>> 1.x
>>>>>>> by their counterparts in 2.x.
>>>>>>>
>>>>>>> is it right or I missed something like a smart import that =
detect
>>>>>>> conflicts and propose to update automatically element that =
exist in
>>>>>>> 1.X & 2.X /delete obsolete element of 1.X / etc.. ?
>>>>>>>
>>>>>>> The question is what is the recommended procedure to perform =
a=20
>>>>>>> plug-in
>>>>>>> upgrade with a minimum effort ?
>>>>>>>
>>>>>>> My concern will be the maintenance cost of a library. If we =
build=20
>>>>>>> our
>>>>>>> library from many commercial or non commercial plugins we =
have to=20
>>>>>>> deal
>>>>>>> with their evolutions at a minimal cost.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Best Regards ...
>>>>>>>
>>>>>>> PS: I will be in vacation for the next 2 weeks so you have =
plenty of
>>>>>>> time for an anwser ;)
>>>>>>>
>>>>>>>
>>>>>>> PS:
>>>>>>> We use ClearCase but it will not help here except to roll =
back to a
>>>>>>> stable baseline and lock elements for modification ...
>>>>>>> We are developping our process in multi site. As we didn't =
want to
>>>>>>> add more complexity we decided to work only on one site =
(windows
>>>>>>> terminal server for the distant site) with one development =
branch in
>>>>>>> base CC.
>>>>>>> May be you have a successfull experience using CC multisite =
& UCM ?
>>>>>>> Can you share your experience ?
>>>>>>> Seems that in CC 7 (we use CC 6) the merge manager have a =
new option
>>>>>>> i.e. to always copy. So may be we can now have branches & =
multisite=20
>>>>>>> as
>>>>>>> now xmi file can be merged by a copy. I see here a potential =
source=20
>>>>>>> of
>>>>>>> trouble as we may surely end with invalid references if for =
instance
>>>>>>> the merge (copy) is done partially on some xmi ...
>>>>>>>
>>>>>>> Peter Haumer wrote:
>>>>>>>> Hello.
>>>>>>>> You cannot load multiple versions of the same plugin into =
the same
>>>>>>>> library. All library elements are identified by global =
unique ids=20
>>>>>>>> and
>>>>>>>> hence such ids needs to be unique. To get more than one =
copy of an
>>>>>>>> element you need to use the copy operation in the library =
view. In
>>>>>>>> general we recommend to use a version control system like =
Rational
>>>>>>>> ClearCase which allows you to label and restore old =
versions of=20
>>>>>>>> whole
>>>>>>>> groups of files.
>>>>>>>>
>>>>>>>> Best regards,
>>>>>>>> Peter.
>>>>>>>>
>>>>>>>> P.S.: Surely they should not be an exception when loading =
the same
>>>>>>>> content twice, but an error message. Please, file a =
bugzilla with
>>>>>>>> reproducible steps.
>>>>>>>>
>>>>>>>>
>>>>>>>> "K.Benameur" <benameur@freesurf.fr> wrote in message
>>>>>>>> news:f973f4$goo$1@build.eclipse.org...
>>>>>>>>> Hi all,
>>>>>>>>>
>>>>>>>>> It is a very good question. May be it can be addressed by =
an=20
>>>>>>>>> update
>>>>>>>>> of an existing guideline as the Development Guideline ?
>>>>>>>>>
>>>>>>>>> I think that we should have a "recommended" procedure from =
the EPF
>>>>>>>>> team to update plug-ins to a new version.
>>>>>>>>> It is now a fairly common scenario that multiple versions =
of the
>>>>>>>>> same plug-ins are out.
>>>>>>>>>
>>>>>>>>> And it is not only related to Open Up but for any library =
/=20
>>>>>>>>> plug-in
>>>>>>>>> as part of the development process (we are developing our =
own
>>>>>>>>> library / plug-ins without Open Up).
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> In short, what is the recommended procedure to migrate to =
a new
>>>>>>>>> version ? Do we have to export / import ? What are the =
risks? What
>>>>>>>>> we may lose ?
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Best Regards
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>
>=20
------=_NextPart_000_0047_01C7F089.063F8380
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML xmlns:o =3D "urn:schemas-microsoft-com:office:office"><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2900.3132" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>>>> <FONT size=3D3><FONT=20
face=3D"Times New Roman">I wanted to clarify if it really is =
the case=20
that EPF Composer is designed to be primarily used to maintain OpenUP=20
only. </FONT></FONT></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><FONT size=3D3><FONT=20
face=3D"Times New Roman"></FONT></FONT></FONT> </DIV>
<DIV><FONT><FONT><FONT face=3DArial><FONT size=3D2>It is not really the=20
case.</FONT></FONT></FONT></FONT></DIV>
<DIV><FONT><FONT><FONT face=3DArial><FONT=20
size=3D2></FONT></FONT></FONT></FONT> </DIV>
<DIV><FONT><FONT><FONT face=3DArial><FONT size=3D2>EPF Composer is used =
by the EPF=20
team to maintain OpenUP, DSDM, Scrum, XP and any other processes being =
captured=20
today and in the future under the EPF =
project.</FONT></FONT></FONT></FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>Moreover, EPF users can capture their =
own=20
home-grown processes or extensions to available processes using EPF=20
Composer.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>I hope this clarifies your =
question.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>Regards,</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>Ricardo Balduino.</FONT></DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
<DIV>"Kamal Ahluwalia" <<A=20
href=3D"mailto:kamal@osellus.com">kamal@osellus.com</A>> wrote in =
message <A=20
=
href=3D"news:fbpmjg$rai$1@build.eclipse.org">news:fbpmjg$rai$1@build.ecli=
pse.org</A>...</DIV>
<DIV><FONT face=3DArial size=3D2>
<P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><FONT =
size=3D3><FONT=20
face=3D"Times New Roman">=93EPF Composer is designed to support a =
single project=20
per library only as it is primary used to maintain=20
OpenUP=94.<o:p></o:p></FONT></FONT></P>
<P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><o:p><FONT=20
face=3D"Times New Roman" size=3D3> </FONT></o:p></P>
<P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><FONT =
size=3D3><FONT=20
face=3D"Times New Roman">I wanted to clarify if it really is =
the case=20
that EPF Composer is designed to be primarily used to maintain OpenUP =
only.=20
<o:p></o:p></FONT></FONT></P>
<P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><o:p><FONT=20
face=3D"Times New Roman" size=3D3> </FONT></o:p></P>
<P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><FONT =
size=3D3><FONT=20
face=3D"Times New =
Roman">Kamal<o:p></o:p></FONT></FONT></P></FONT></DIV >
<BLOCKQUOTE=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
<DIV>"Roman Smirak" <<A=20
=
href=3D"mailto:roman.smirak@tietoenator.com">roman.smirak@tietoenator.com=
</A>>=20
wrote in message <A=20
=
href=3D"news:f9rjjo$50e$1@build.eclipse.org">news:f9rjjo$50e$1@build.ecli=
pse.org</A>...</DIV>Hi=20
Peter,<BR><BR> that is great, the implementation =
perfectly=20
matches with my vision. Why <BR>not to have it in EPF? I guess many =
users=20
would welcome the feature.<BR><BR>We have licences of RMC, however, =
we=20
prefer to use EPF since early releases <BR>are=20
available.<BR><BR>Regards,<BR><BR>Roman<BR><BR>"Peter Haumer" <<A =
href=3D"mailto:phaumer@us.ibm.com">phaumer@us.ibm.com</A>> wrote =
in message=20
<BR><A=20
=
href=3D"news:f9qa5o$jac$1@build.eclipse.org">news:f9qa5o$jac$1@build.ecli=
pse.org</A>...<BR>>=20
Hello Roman.<BR>> Well, if our competitors can abuse this forum =
to plug=20
their products; so <BR>> can I :-)<BR>><BR>> RMC 7.2 does =
not need=20
the library.xmi file anymore as it uses the Eclipse <BR>> =
workspace's=20
projects to find all the files. Every plugin is a project as =
<BR>> well=20
as you can create more than one project for managing configurations =
<BR>>=20
and one project for estimation data (another RMC added value). The =
problem=20
<BR>> view is used just as in Eclipse to tell you if you are =
missing=20
elements in <BR>> your workspace that other elements depend =
upon. =20
You could ignore those <BR>> errors or fix them by loading the =
project's=20
that contain the missing <BR>> elements.<BR>><BR>> See the =
attached=20
image with an example where I was using plugins managed <BR>> in =
CVS and=20
plugins managed in CC all at the same time in the same <BR>> =
workspace.=20
Plugins can now reside in complete different directories even =
<BR>> on=20
different machine. Just like Eclipse projects, you load them =
into your=20
<BR>> workspace and use them whenever you need to use=20
them.<BR>><BR>> However, RMC can still generate a library.xmi =
for you=20
to manage libraries <BR>> that are fully compatible with EPF =
Composer.=20
For example, if you check the <BR>> OpenUP CVS repository: it =
already has=20
project files in each plugin <BR>> directory. That is =
because I was=20
already working with OpenUP in RMC 7.2; <BR>> at the same time =
where the=20
rest of the team continued working with EPF <BR>> Composer. =
Two=20
ways of loading the same library in a fully compatible =
way.<BR>><BR>>=20
Hope this helps,<BR>> Peter.<BR>><BR>><BR>><BR>> =
"Roman=20
Smirak" <<A=20
=
href=3D"mailto:roman.smirak@tietoenator.com">roman.smirak@tietoenator.com=
</A>>=20
wrote in message <BR>> <A=20
=
href=3D"news:f9p6up$mmu$1@build.eclipse.org">news:f9p6up$mmu$1@build.ecli=
pse.org</A>...<BR>>>=20
Hi Peter,<BR>>><BR>>> thanks for info, =
however, RMC=20
is based on EPF and I see current <BR>>> solution<BR>>> =
of EPF=20
(library.xml) as a fundamental constraint for clear & easy =
<BR>>>=20
solution<BR>>> at RMC level. Or?<BR>>><BR>>> Can =
you=20
please describe the scenario with RMC how it will be=20
implemented?<BR>>><BR>>> Or shall I post this at IBM =
Rational=20
forum?<BR>>><BR>>> Roman<BR>>><BR>>> "Peter =
Haumer"=20
<<A href=3D"mailto:phaumer@us.ibm.com">phaumer@us.ibm.com</A>> =
wrote in=20
message<BR>>> <A=20
=
href=3D"news:f9o54i$924$1@build.eclipse.org">news:f9o54i$924$1@build.ecli=
pse.org</A>...<BR>>>>=20
1) no, the guid remains the same<BR>>>> 2) not sure I =
understand=20
the context of this, but I would recommend to<BR>>>> only =
version=20
manage your own files and if you are using cvs directly =
get<BR>>>>=20
the OpenUP sources from our server or if you use CC provide a =
zip/rar=20
<BR>>>> file<BR>>>> with the OpenUP files that =
users can=20
unzip as view-private files<BR>>>> 3) Rational Method =
Composer 7.2=20
will fully support this scenario, which <BR>>>> =
is<BR>>>>=20
not in scope for EPF Composer. For enterprise deployments and=20
full<BR>>>> scalability we recommend RMC in which every =
plugin can=20
be maintained as <BR>>>> an<BR>>>> eclipse project =
and=20
loaded when needed. In addition we provide project<BR>>>> =
types for=20
configurations, enterprise reports, and estimation models =
in<BR>>>>=20
RMC. EPF Composer is designed to support a single project per=20
library<BR>>>> only as it is primary used to maintain =
OpenUP. =20
A workaround for you <BR>>>> would<BR>>>> be what =
I=20
described above for (2).<BR>>>><BR>>>> Best=20
regards,<BR>>>> Peter=20
Haumer.<BR>>>><BR>>>> <BR>>>> "Roman =
Smirak"=20
<<A=20
=
href=3D"mailto:roman.smirak@tietoenator.com">roman.smirak@tietoenator.com=
</A>>=20
wrote in message<BR>>>> <A=20
=
href=3D"news:f9kcmi$idh$1@build.eclipse.org">news:f9kcmi$idh$1@build.ecli=
pse.org</A>...<BR>>>>>=20
Hi Ricardo,<BR>>>>><BR>>>>> the =
way you=20
described below is the one I've been using so far; =
<BR>>>>>=20
however,<BR>>>>> I have few issues =
here:<BR>>>>> 1/=20
What if you refactor the content of OpenUP, e.g. an element I=20
was<BR>>>>> referencing to is no longer in same package =
or=20
plugin? Is there any<BR>>>>> impact on=20
UID?<BR>>>>><BR>>>>> 2/ Currently we have =
the whole=20
library in a versioning repository,<BR>>>>> although =
everyone=20
has got the basis (OpenUP, or RUP) with the tool =
<BR>>>>>=20
(EMC,<BR>>>>> or RMC) - no problem for OpenUP, in case =
of RUP,=20
well we are talking<BR>>>>> about 60MB or so (which you =
have to=20
check in every time you =
migrate)<BR>>>>><BR>>>>> 3/=20
Let say we have a common basis in our department X, let's call=20
it<BR>>>>> OpenUP/X; there is a project A which will use =
it plus=20
extension A minus<BR>>>>> irrelevant content from basis; =
in case=20
of eclipse plugins they simply<BR>>>>> check out =
required=20
plugins (they stay in touch with their updates =
by<BR>>>>>=20
department X authority) but they don't check out irrelevant plugins=20
(no<BR>>>>> mess) + create their new one and check it in =
their=20
repository (will be<BR>>>>> maintained there); currently =
they=20
need to check out whole library X +<BR>>>>> submit their =
plugins=20
A into the library shared by others (and they do<BR>>>>> =
same=20
action as well =3D> mess X + A + B + C, etc.) in order to fulfil=20
the<BR>>>>> use case (the basis maintained by =
department, a=20
project extension<BR>>>>> maintained by the project=20
itself)<BR>>>>><BR>>>>> I see the =
library.xml as a=20
big constraint in this use =
case.<BR>>>>><BR>>>>>=20
Regards,<BR>>>>><BR>>>>>=20
Roman<BR>>>>><BR>>>>> "Ricardo Balduino" =
<<A=20
href=3D"mailto:balduino@us.ibm.com">balduino@us.ibm.com</A>> =
wrote in=20
message<BR>>>>> <A=20
=
href=3D"news:f9itco$87k$1@build.eclipse.org">news:f9itco$87k$1@build.ecli=
pse.org</A>...<BR>>>>>>=20
In first paragraph I meant less cumbersome, yet safer=20
;-)<BR>>>>>><BR>>>>>> "Ricardo =
Balduino"=20
<<A =
href=3D"mailto:balduino@us.ibm.com">balduino@us.ibm.com</A>> wrote=20
in message<BR>>>>>> <A=20
=
href=3D"news:f9g8d0$db$1@build.eclipse.org">news:f9g8d0$db$1@build.eclips=
e.org</A>...<BR>>>>>>>=20
Option A sounds less cumbersome and safer, as the EPF Composer=20
tool<BR>>>>>>> will take care of the work. In =
fact,=20
according to your description of<BR>>>>>>> option =
A,=20
OpenUP 2.x would overwrite OpenUP=20
1.x.<BR>>>>>>><BR >>>>>>> Instead =
of=20
playing with importing a new OpenUP plug-in into=20
your<BR>>>>>>> existing library, have you =
considered=20
getting the new OpenUP library<BR>>>>>>> available =
and=20
import your plug-in into it instead? With that =
<BR>>>>>>>=20
approach,<BR>>>>>>> you are moving your plug-in =
around, so=20
you know there are no <BR>>>>>>>=20
duplicates<BR>>>>>>> of it in a brand new OpenUP =
library.=20
If your plug-in initially <BR>>>>>>>=20
depended<BR>>>>>>> on some OpenUP element that =
does not=20
exist anymore when a new version<BR>>>>>>> of =
OpenUP is=20
released, the import will show you warnings, which=20
will<BR>>>>>>> help you to spot where you need to =
maintain=20
your plug-in to extend <BR>>>>>>>=20
the<BR>>>>>>> most current version of OpenUP. =
Additions to=20
OpenUP will not affect<BR>>>>>>> your=20
plug-in.<BR>>>>>>> <BR>>>>>>>=20
Cheers,<BR>>>>>>> <BR>>>>>>> =
Ricardo=20
Balduino.<BR>>>>>>> <BR>>>>>>>=20
"K.Benameur" <<A=20
href=3D"mailto:benameur@freesurf.fr">benameur@freesurf.fr</A>> =
wrote in=20
message<BR>>>>>>> <A=20
=
href=3D"news:f9f8cn$ah0$1@build.eclipse.org">news:f9f8cn$ah0$1@build.ecli=
pse.org</A>...<BR>>>>>>>>=20
Hi =
Peter,<BR>>>>>>>> <BR>>>>>>>>=20
Sorry to bother you with all my questions=20
!!!<BR>>>>>>>> <BR>>>>>>>> =
I am not=20
sure that I have completly understood your=20
=
answer.<BR>>>>>>>> <BR>>>>>>>> =
To=20
check this I propose a simple scenario =20
:<BR> >>>>>>>& ;nbsp; - I develop a library =
using=20
Open Up 1.x.<BR> >>>>>>>& ;nbsp; - A new =
version of=20
Open Up is out let say 2.x<BR> >>>>>>>& ;nbsp; - I =
wan't=20
to take advantage of this new Open Up=20
=
version.<BR>>>>>>>> <BR>>>>>>>> =
A)=20
So ideally, I import the new version in my library and Open Up=20
<BR>>>>>>>> 1.x<BR>>>>>>>> =
is=20
updated to=20
2.x.<BR>>>>>>>> <BR>>>>>>>> =
I have=20
the feeling that it will not be so simple as many links will=20
<BR>>>>>>>> be<BR>>>>>>>> =
broken=20
due to changes between 1.X and=20
2.X.<BR>>>>>>>> <BR>>>>>>>> =
B) I=20
use the copy operation to have the 1.X & 2.X plugin in my=20
<BR>>>>>>>>=20
=
library<BR>>>>>>>> <BR>>>>>>>> =
It=20
seems that option B) is the one to go as you said that we have=20
to<BR>>>>>>>> do a copy as uuid must be=20
unique.<BR>>>>>>>>=20
=3D><BR>>>>>>>> I have to do the migration=20
manually by replacing elements of Open=20
<BR>>>>>>>> 1.x<BR>>>>>>>> =
by=20
their counterparts in=20
2.x.<BR>>>>>>>> <BR>>>>>>>> =
is it=20
right or I missed something like a smart import that=20
detect<BR>>>>>>>> conflicts and propose to =
update=20
automatically element that exist in<BR>>>>>>>> =
1.X=20
& 2.X /delete obsolete element of 1.X / etc..=20
?<BR>>>>>>>> <BR>>>>>>>> =
The=20
question is what is the recommended procedure to perform a=20
<BR>>>>>>>> =
plug-in<BR>>>>>>>>=20
upgrade with a minimum effort=20
?<BR>>>>>>>> <BR>>>>>>>> My =
concern=20
will be the maintenance cost of a library. If we build=20
<BR>>>>>>>> our<BR>>>>>>>> =
library=20
from many commercial or non commercial plugins we have to=20
<BR>>>>>>>> =
deal<BR>>>>>>>> with=20
their evolutions at a minimal=20
=
cost.<BR>>>>>>>> <BR>>>>>>>> <BR>=
>>>>>>><BR >>>>>>>><BR >>>&=
gt;>>>>=20
Best Regards=20
...<BR>>>>>>>> <BR>>>>>>>> =
PS: I=20
will be in vacation for the next 2 weeks so you have plenty=20
of<BR>>>>>>>> time for an anwser=20
=
;)<BR>>>>>>>> <BR>>>>>>>> <BR>>=
;>>>>>>=20
PS:<BR> >>>>>>>& ;nbsp; We use ClearCase but it =
will not=20
help here except to roll back to a<BR>>>>>>>> =
stable=20
baseline and lock elements for modification=20
...<BR> >>>>>>>& ;nbsp; We are developping our =
process in=20
multi site. As we didn't want to<BR>>>>>>>> add =
more=20
complexity we decided to work only on one site=20
(windows<BR>>>>>>>> terminal server for the =
distant=20
site) with one development branch in<BR>>>>>>>> =
base=20
CC.<BR>>>>>>>> May be you have a successfull =
experience=20
using CC multisite & UCM ?<BR>>>>>>>> Can =
you share=20
your experience ?<BR>>>>>>>> Seems that in CC 7 =
(we use=20
CC 6) the merge manager have a new =
option<BR>>>>>>>>=20
i.e. to always copy. So may be we can now have branches & =
multisite=20
<BR>>>>>>>> as<BR>>>>>>>> =
now xmi=20
file can be merged by a copy. I see here a potential source=20
<BR>>>>>>>> of<BR>>>>>>>> =
trouble=20
as we may surely end with invalid references if for=20
instance<BR>>>>>>>> the merge (copy) is done =
partially=20
on some xmi=20
...<BR>>>>>>>> <BR>>>>>>>> =
Peter=20
Haumer wrote:<BR> >>>>>>>& ;gt;=20
Hello.<BR> >>>>>>>& ;gt; You cannot load multiple =
versions=20
of the same plugin into the same<BR> >>>>>>>& ;gt; =
library. All library elements are identified by global unique ids=20
<BR> >>>>>>>& ;gt; =
and<BR> >>>>>>>& ;gt;=20
hence such ids needs to be unique. To get more than one copy =
of=20
an<BR> >>>>>>>& ;gt; element you need to use the =
copy=20
operation in the library view. =
In<BR> >>>>>>>& ;gt;=20
general we recommend to use a version control system like=20
Rational<BR> >>>>>>>& ;gt; ClearCase which allows =
you to=20
label and restore old versions of =
<BR> >>>>>>>& ;gt;=20
whole<BR> >>>>>>>& ;gt; groups of=20
=
files.<BR> >>>>>>>& ;gt; <BR>>>>>>>>=
;>=20
Best regards,<BR> >>>>>>>& ;gt;=20
=
Peter.<BR> >>>>>>>& ;gt; <BR>>>>>>>>=
;>=20
P.S.: Surely they should not be an exception when loading the=20
same<BR> >>>>>>>& ;gt; content twice, but an error =
message. Please, file a bugzilla=20
with<BR> >>>>>>>& ;gt; reproducible=20
=
steps.<BR> >>>>>>>& ;gt; <BR>>>>>>>>=
;><BR> >>>>>>>& ;gt;=20
"K.Benameur" <<A=20
href=3D"mailto:benameur@freesurf.fr">benameur@freesurf.fr</A>> =
wrote in=20
message<BR> >>>>>>>& ;gt; <A=20
=
href=3D"news:f973f4$goo$1@build.eclipse.org">news:f973f4$goo$1@build.ecli=
pse.org</A>...<BR> >>>>>>>& ;gt;>=20
Hi=20
=
all,<BR> >>>>>>>& ;gt;> <BR>>>>>>>&=
gt;>>=20
It is a very good question. May be it can be addressed by an=20
<BR> >>>>>>>& ;gt;>=20
update<BR> >>>>>>>& ;gt;> of an existing =
guideline as=20
the Development Guideline=20
=
?<BR> >>>>>>>& ;gt;> <BR>>>>>>>>=
>>=20
I think that we should have a "recommended" procedure from the=20
EPF<BR> >>>>>>>& ;gt;> team to update plug-ins =
to a new=20
version.<BR> >>>>>>>& ;gt;> It is now a =
fairly=20
common scenario that multiple versions of=20
the<BR> >>>>>>>& ;gt;> same plug-ins are=20
=
out.<BR> >>>>>>>& ;gt;> <BR>>>>>>>&=
gt;>>=20
And it is not only related to Open Up but for any library /=20
<BR> >>>>>>>& ;gt;>=20
plug-in<BR> >>>>>>>& ;gt;> as part of the =
development=20
process (we are developing our =
own<BR> >>>>>>>& ;gt;>=20
library / plug-ins without Open=20
=
Up).<BR> >>>>>>>& ;gt;> <BR>>>>>>>&=
gt;>><BR> >>>>>>>& ;gt;> =20
In short, what is the recommended procedure to migrate to a=20
new<BR> >>>>>>>& ;gt;> version ? Do we have to =
export /=20
import ? What are the risks? =
What<BR> >>>>>>>& ;gt;> we=20
may lose=20
=
?<BR> >>>>>>>& ;gt;> <BR>>>>>>>>=
>><BR> >>>>>>>& ;gt;>=20
Best=20
=
Regards<BR> >>>>>>>& ;gt;> <BR>>>>>>&g=
t;>>><BR> >>>>>>>& ;gt; <BR>>>>>>=
;><BR>>>>>><BR>>>>>> <BR>>>>>=
<BR>>>>><BR>>>> <BR>>>><BR>>><BR>>&=
gt;<BR>><BR>><BR>>=20
<BR><BR></BLOCKQUOTE></BLOCKQUOTE></BODY></HTML>
------=_NextPart_000_0047_01C7F089.063F8380--
|
|
|
| Re: Migration to newever library version [message #39963 is a reply to message #39929] |
Thu, 06 September 2007 21:22 |
| Eclipse User |
|
|
|
Originally posted by: kamal.osellus.com
This is a multi-part message in MIME format.
------=_NextPart_000_003F_01C7F0AA.74CD32E0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Thanks for your response Ricardo.
=20
This thread highlights some of the fundamental constraints in using EPF =
Composer, especially library.xml to maintain processes. It appears RMC =
7.2 addresses some of these problems. Are there any plans to donate =
those bits to EPF so that the community can benefit ?
=20
Kamal=20
"Ricardo Balduino" <balduino@us.ibm.com> wrote in message =
news:fbpnj1$24t$1@build.eclipse.org...
>>> I wanted to clarify if it really is the case that EPF Composer is =
designed to be primarily used to maintain OpenUP only. =20
It is not really the case.
EPF Composer is used by the EPF team to maintain OpenUP, DSDM, Scrum, =
XP and any other processes being captured today and in the future under =
the EPF project.
Moreover, EPF users can capture their own home-grown processes or =
extensions to available processes using EPF Composer.
I hope this clarifies your question.
Regards,
Ricardo Balduino.
"Kamal Ahluwalia" <kamal@osellus.com> wrote in message =
news:fbpmjg$rai$1@build.eclipse.org...
"EPF Composer is designed to support a single project per library =
only as it is primary used to maintain OpenUP".
=20
I wanted to clarify if it really is the case that EPF Composer is =
designed to be primarily used to maintain OpenUP only. =20
=20
Kamal
"Roman Smirak" <roman.smirak@tietoenator.com> wrote in message =
news:f9rjjo$50e$1@build.eclipse.org...
Hi Peter,
that is great, the implementation perfectly matches with my =
vision. Why=20
not to have it in EPF? I guess many users would welcome the =
feature.
We have licences of RMC, however, we prefer to use EPF since early =
releases=20
are available.
Regards,
Roman
"Peter Haumer" <phaumer@us.ibm.com> wrote in message=20
news:f9qa5o$jac$1@build.eclipse.org...
> Hello Roman.
> Well, if our competitors can abuse this forum to plug their =
products; so=20
> can I :-)
>
> RMC 7.2 does not need the library.xmi file anymore as it uses =
the Eclipse=20
> workspace's projects to find all the files. Every plugin is a =
project as=20
> well as you can create more than one project for managing =
configurations=20
> and one project for estimation data (another RMC added value). =
The problem=20
> view is used just as in Eclipse to tell you if you are missing =
elements in=20
> your workspace that other elements depend upon. You could =
ignore those=20
> errors or fix them by loading the project's that contain the =
missing=20
> elements.
>
> See the attached image with an example where I was using plugins =
managed=20
> in CVS and plugins managed in CC all at the same time in the =
same=20
> workspace. Plugins can now reside in complete different =
directories even=20
> on different machine. Just like Eclipse projects, you load them =
into your=20
> workspace and use them whenever you need to use them.
>
> However, RMC can still generate a library.xmi for you to manage =
libraries=20
> that are fully compatible with EPF Composer. For example, if you =
check the=20
> OpenUP CVS repository: it already has project files in each =
plugin=20
> directory. That is because I was already working with OpenUP in =
RMC 7.2;=20
> at the same time where the rest of the team continued working =
with EPF=20
> Composer. Two ways of loading the same library in a fully =
compatible way.
>
> Hope this helps,
> Peter.
>
>
>
> "Roman Smirak" <roman.smirak@tietoenator.com> wrote in message=20
> news:f9p6up$mmu$1@build.eclipse.org...
>> Hi Peter,
>>
>> thanks for info, however, RMC is based on EPF and I see =
current=20
>> solution
>> of EPF (library.xml) as a fundamental constraint for clear & =
easy=20
>> solution
>> at RMC level. Or?
>>
>> Can you please describe the scenario with RMC how it will be =
implemented?
>>
>> Or shall I post this at IBM Rational forum?
>>
>> Roman
>>
>> "Peter Haumer" <phaumer@us.ibm.com> wrote in message
>> news:f9o54i$924$1@build.eclipse.org...
>>> 1) no, the guid remains the same
>>> 2) not sure I understand the context of this, but I would =
recommend to
>>> only version manage your own files and if you are using cvs =
directly get
>>> the OpenUP sources from our server or if you use CC provide a =
zip/rar=20
>>> file
>>> with the OpenUP files that users can unzip as view-private =
files
>>> 3) Rational Method Composer 7.2 will fully support this =
scenario, which=20
>>> is
>>> not in scope for EPF Composer. For enterprise deployments and =
full
>>> scalability we recommend RMC in which every plugin can be =
maintained as=20
>>> an
>>> eclipse project and loaded when needed. In addition we provide =
project
>>> types for configurations, enterprise reports, and estimation =
models in
>>> RMC. EPF Composer is designed to support a single project per =
library
>>> only as it is primary used to maintain OpenUP. A workaround =
for you=20
>>> would
>>> be what I described above for (2).
>>>
>>> Best regards,
>>> Peter Haumer.
>>>
>>>
>>> "Roman Smirak" <roman.smirak@tietoenator.com> wrote in message
>>> news:f9kcmi$idh$1@build.eclipse.org...
>>>> Hi Ricardo,
>>>>
>>>> the way you described below is the one I've been using so =
far;=20
>>>> however,
>>>> I have few issues here:
>>>> 1/ What if you refactor the content of OpenUP, e.g. an =
element I was
>>>> referencing to is no longer in same package or plugin? Is =
there any
>>>> impact on UID?
>>>>
>>>> 2/ Currently we have the whole library in a versioning =
repository,
>>>> although everyone has got the basis (OpenUP, or RUP) with the =
tool=20
>>>> (EMC,
>>>> or RMC) - no problem for OpenUP, in case of RUP, well we are =
talking
>>>> about 60MB or so (which you have to check in every time you =
migrate)
>>>>
>>>> 3/ Let say we have a common basis in our department X, let's =
call it
>>>> OpenUP/X; there is a project A which will use it plus =
extension A minus
>>>> irrelevant content from basis; in case of eclipse plugins =
they simply
>>>> check out required plugins (they stay in touch with their =
updates by
>>>> department X authority) but they don't check out irrelevant =
plugins (no
>>>> mess) + create their new one and check it in their repository =
(will be
>>>> maintained there); currently they need to check out whole =
library X +
>>>> submit their plugins A into the library shared by others (and =
they do
>>>> same action as well =3D> mess X + A + B + C, etc.) in order =
to fulfil the
>>>> use case (the basis maintained by department, a project =
extension
>>>> maintained by the project itself)
>>>>
>>>> I see the library.xml as a big constraint in this use case.
>>>>
>>>> Regards,
>>>>
>>>> Roman
>>>>
>>>> "Ricardo Balduino" <balduino@us.ibm.com> wrote in message
>>>> news:f9itco$87k$1@build.eclipse.org...
>>>>> In first paragraph I meant less cumbersome, yet safer ;-)
>>>>>
>>>>> "Ricardo Balduino" <balduino@us.ibm.com> wrote in message
>>>>> news:f9g8d0$db$1@build.eclipse.org...
>>>>>> Option A sounds less cumbersome and safer, as the EPF =
Composer tool
>>>>>> will take care of the work. In fact, according to your =
description of
>>>>>> option A, OpenUP 2.x would overwrite OpenUP 1.x.
>>>>>>
>>>>>> Instead of playing with importing a new OpenUP plug-in into =
your
>>>>>> existing library, have you considered getting the new =
OpenUP library
>>>>>> available and import your plug-in into it instead? With =
that=20
>>>>>> approach,
>>>>>> you are moving your plug-in around, so you know there are =
no=20
>>>>>> duplicates
>>>>>> of it in a brand new OpenUP library. If your plug-in =
initially=20
>>>>>> depended
>>>>>> on some OpenUP element that does not exist anymore when a =
new version
>>>>>> of OpenUP is released, the import will show you warnings, =
which will
>>>>>> help you to spot where you need to maintain your plug-in to =
extend=20
>>>>>> the
>>>>>> most current version of OpenUP. Additions to OpenUP will =
not affect
>>>>>> your plug-in.
>>>>>>
>>>>>> Cheers,
>>>>>>
>>>>>> Ricardo Balduino.
>>>>>>
>>>>>> "K.Benameur" <benameur@freesurf.fr> wrote in message
>>>>>> news:f9f8cn$ah0$1@build.eclipse.org...
>>>>>>> Hi Peter,
>>>>>>>
>>>>>>> Sorry to bother you with all my questions !!!
>>>>>>>
>>>>>>> I am not sure that I have completly understood your =
answer.
>>>>>>>
>>>>>>> To check this I propose a simple scenario :
>>>>>>> - I develop a library using Open Up 1.x.
>>>>>>> - A new version of Open Up is out let say 2.x
>>>>>>> - I wan't to take advantage of this new Open Up version.
>>>>>>>
>>>>>>> A) So ideally, I import the new version in my library and =
Open Up=20
>>>>>>> 1.x
>>>>>>> is updated to 2.x.
>>>>>>>
>>>>>>> I have the feeling that it will not be so simple as many =
links will=20
>>>>>>> be
>>>>>>> broken due to changes between 1.X and 2.X.
>>>>>>>
>>>>>>> B) I use the copy operation to have the 1.X & 2.X plugin =
in my=20
>>>>>>> library
>>>>>>>
>>>>>>> It seems that option B) is the one to go as you said that =
we have to
>>>>>>> do a copy as uuid must be unique.
>>>>>>> =3D>
>>>>>>> I have to do the migration manually by replacing elements =
of Open=20
>>>>>>> 1.x
>>>>>>> by their counterparts in 2.x.
>>>>>>>
>>>>>>> is it right or I missed something like a smart import that =
detect
>>>>>>> conflicts and propose to update automatically element that =
exist in
>>>>>>> 1.X & 2.X /delete obsolete element of 1.X / etc.. ?
>>>>>>>
>>>>>>> The question is what is the recommended procedure to =
perform a=20
>>>>>>> plug-in
>>>>>>> upgrade with a minimum effort ?
>>>>>>>
>>>>>>> My concern will be the maintenance cost of a library. If =
we build=20
>>>>>>> our
>>>>>>> library from many commercial or non commercial plugins we =
have to=20
>>>>>>> deal
>>>>>>> with their evolutions at a minimal cost.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Best Regards ...
>>>>>>>
>>>>>>> PS: I will be in vacation for the next 2 weeks so you have =
plenty of
>>>>>>> time for an anwser ;)
>>>>>>>
>>>>>>>
>>>>>>> PS:
>>>>>>> We use ClearCase but it will not help here except to roll =
back to a
>>>>>>> stable baseline and lock elements for modification ...
>>>>>>> We are developping our process in multi site. As we =
didn't want to
>>>>>>> add more complexity we decided to work only on one site =
(windows
>>>>>>> terminal server for the distant site) with one development =
branch in
>>>>>>> base CC.
>>>>>>> May be you have a successfull experience using CC =
multisite & UCM ?
>>>>>>> Can you share your experience ?
>>>>>>> Seems that in CC 7 (we use CC 6) the merge manager have a =
new option
>>>>>>> i.e. to always copy. So may be we can now have branches & =
multisite=20
>>>>>>> as
>>>>>>> now xmi file can be merged by a copy. I see here a =
potential source=20
>>>>>>> of
>>>>>>> trouble as we may surely end with invalid references if =
for instance
>>>>>>> the merge (copy) is done partially on some xmi ...
>>>>>>>
>>>>>>> Peter Haumer wrote:
>>>>>>>> Hello.
>>>>>>>> You cannot load multiple versions of the same plugin into =
the same
>>>>>>>> library. All library elements are identified by global =
unique ids=20
>>>>>>>> and
>>>>>>>> hence such ids needs to be unique. To get more than one =
copy of an
>>>>>>>> element you need to use the copy operation in the library =
view. In
>>>>>>>> general we recommend to use a version control system like =
Rational
>>>>>>>> ClearCase which allows you to label and restore old =
versions of=20
>>>>>>>> whole
>>>>>>>> groups of files.
>>>>>>>>
>>>>>>>> Best regards,
>>>>>>>> Peter.
>>>>>>>>
>>>>>>>> P.S.: Surely they should not be an exception when loading =
the same
>>>>>>>> content twice, but an error message. Please, file a =
bugzilla with
>>>>>>>> reproducible steps.
>>>>>>>>
>>>>>>>>
>>>>>>>> "K.Benameur" <benameur@freesurf.fr> wrote in message
>>>>>>>> news:f973f4$goo$1@build.eclipse.org...
>>>>>>>>> Hi all,
>>>>>>>>>
>>>>>>>>> It is a very good question. May be it can be addressed =
by an=20
>>>>>>>>> update
>>>>>>>>> of an existing guideline as the Development Guideline ?
>>>>>>>>>
>>>>>>>>> I think that we should have a "recommended" procedure =
from the EPF
>>>>>>>>> team to update plug-ins to a new version.
>>>>>>>>> It is now a fairly common scenario that multiple =
versions of the
>>>>>>>>> same plug-ins are out.
>>>>>>>>>
>>>>>>>>> And it is not only related to Open Up but for any =
library /=20
>>>>>>>>> plug-in
>>>>>>>>> as part of the development process (we are developing =
our own
>>>>>>>>> library / plug-ins without Open Up).
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> In short, what is the recommended procedure to migrate =
to a new
>>>>>>>>> version ? Do we have to export / import ? What are the =
risks? What
>>>>>>>>> we may lose ?
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Best Regards
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>
>=20
------=_NextPart_000_003F_01C7F0AA.74CD32E0
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML xmlns:o =3D "urn:schemas-microsoft-com:office:office"><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.6000.16527" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>
<P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><SPAN=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman','serif'">Thanks =
for your=20
response Ricardo.<o:p></o:p></SPAN></P>
<P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><SPAN=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New =
Roman','serif'"><o:p> </o:p></SPAN></P>
<P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><SPAN=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman','serif'">This =
thread=20
highlights some of the fundamental constraints in using EPF Composer, =
especially=20
library.xml to maintain processes. It appears RMC 7.2 addresses some of =
these=20
problems. Are there any plans to donate those bits to EPF so that the =
community=20
can benefit ?<o:p></o:p></SPAN></P>
<P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><SPAN=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New =
Roman','serif'"><o:p> </o:p></SPAN></P>
<P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><SPAN=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman','serif'">Kamal=20
<o:p></o:p></SPAN></P></FONT></DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
<DIV>"Ricardo Balduino" <<A=20
href=3D"mailto:balduino@us.ibm.com">balduino@us.ibm.com</A>> wrote =
in message=20
<A=20
=
href=3D"news:fbpnj1$24t$1@build.eclipse.org">news:fbpnj1$24t$1@build.ecli=
pse.org</A>...</DIV>
<DIV><FONT face=3DArial size=3D2>>>> <FONT size=3D3><FONT=20
face=3D"Times New Roman">I wanted to clarify if it really is =
the case=20
that EPF Composer is designed to be primarily used to maintain OpenUP=20
only. </FONT></FONT></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><FONT size=3D3><FONT=20
face=3D"Times New Roman"></FONT></FONT></FONT> </DIV>
<DIV><FONT size=3D+0><FONT size=3D+0><FONT face=3DArial><FONT =
size=3D2>It is not=20
really the case.</FONT></FONT></FONT></FONT></DIV>
<DIV><FONT size=3D+0><FONT size=3D+0><FONT face=3DArial><FONT=20
size=3D2></FONT></FONT></FONT></FONT> </DIV>
<DIV><FONT size=3D+0><FONT size=3D+0><FONT face=3DArial><FONT =
size=3D2>EPF Composer is=20
used by the EPF team to maintain OpenUP, DSDM, Scrum, XP and any other =
processes being captured today and in the future under the EPF=20
project.</FONT></FONT></FONT></FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>Moreover, EPF users can capture their =
own=20
home-grown processes or extensions to available processes using EPF=20
Composer.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>I hope this clarifies your =
question.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>Regards,</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>Ricardo Balduino.</FONT></DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
<DIV>"Kamal Ahluwalia" <<A=20
href=3D"mailto:kamal@osellus.com">kamal@osellus.com</A>> wrote in =
message=20
<A=20
=
href=3D"news:fbpmjg$rai$1@build.eclipse.org">news:fbpmjg$rai$1@build.ecli=
pse.org</A>...</DIV>
<DIV><FONT face=3DArial size=3D2>
<P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><FONT =
size=3D3><FONT=20
face=3D"Times New Roman">=93EPF Composer is designed to support a =
single project=20
per library only as it is primary used to maintain=20
OpenUP=94.<o:p></o:p></FONT></FONT></P>
<P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><o:p><FONT=20
face=3D"Times New Roman" size=3D3> </FONT></o:p></P>
<P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><FONT =
size=3D3><FONT=20
face=3D"Times New Roman">I wanted to clarify if it really =
is the=20
case that EPF Composer is designed to be primarily used to maintain =
OpenUP=20
only. <o:p></o:p></FONT></FONT></P>
<P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><o:p><FONT=20
face=3D"Times New Roman" size=3D3> </FONT></o:p></P>
<P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><FONT =
size=3D3><FONT=20
face=3D"Times New =
Roman">Kamal<o:p></o:p></FONT></FONT></P></FONT></DIV >
<BLOCKQUOTE=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
<DIV>"Roman Smirak" <<A=20
=
href=3D"mailto:roman.smirak@tietoenator.com">roman.smirak@tietoenator.com=
</A>>=20
wrote in message <A=20
=
href=3D"news:f9rjjo$50e$1@build.eclipse.org">news:f9rjjo$50e$1@build.ecli=
pse.org</A>...</DIV>Hi=20
Peter,<BR><BR> that is great, the implementation =
perfectly=20
matches with my vision. Why <BR>not to have it in EPF? I guess =
many users=20
would welcome the feature.<BR><BR>We have licences of RMC, =
however, we=20
prefer to use EPF since early releases <BR>are=20
available.<BR><BR>Regards,<BR><BR>Roman<BR><BR>"Peter Haumer" =
<<A=20
href=3D"mailto:phaumer@us.ibm.com">phaumer@us.ibm.com</A>> =
wrote in=20
message <BR><A=20
=
href=3D"news:f9qa5o$jac$1@build.eclipse.org">news:f9qa5o$jac$1@build.ecli=
pse.org</A>...<BR>>=20
Hello Roman.<BR>> Well, if our competitors can abuse this forum =
to plug=20
their products; so <BR>> can I :-)<BR>><BR>> RMC 7.2 does =
not=20
need the library.xmi file anymore as it uses the Eclipse <BR>>=20
workspace's projects to find all the files. Every plugin is a =
project as=20
<BR>> well as you can create more than one project for managing =
configurations <BR>> and one project for estimation data =
(another RMC=20
added value). The problem <BR>> view is used just as in Eclipse =
to tell=20
you if you are missing elements in <BR>> your workspace that =
other=20
elements depend upon. You could ignore those <BR>> errors =
or fix=20
them by loading the project's that contain the missing <BR>>=20
elements.<BR>><BR>> See the attached image with an example =
where I=20
was using plugins managed <BR>> in CVS and plugins managed in =
CC all at=20
the same time in the same <BR>> workspace. Plugins can now =
reside in=20
complete different directories even <BR>> on different =
machine. =20
Just like Eclipse projects, you load them into your <BR>> =
workspace and=20
use them whenever you need to use them.<BR>><BR>> However, =
RMC can=20
still generate a library.xmi for you to manage libraries <BR>> =
that are=20
fully compatible with EPF Composer. For example, if you check the =
<BR>>=20
OpenUP CVS repository: it already has project files in each plugin =
<BR>> directory. That is because I was already working =
with=20
OpenUP in RMC 7.2; <BR>> at the same time where the rest of the =
team=20
continued working with EPF <BR>> Composer. Two ways of =
loading=20
the same library in a fully compatible way.<BR>><BR>> Hope =
this=20
helps,<BR>> Peter.<BR>><BR>><BR>><BR>> "Roman =
Smirak"=20
<<A=20
=
href=3D"mailto:roman.smirak@tietoenator.com">roman.smirak@tietoenator.com=
</A>>=20
wrote in message <BR>> <A=20
=
href=3D"news:f9p6up$mmu$1@build.eclipse.org">news:f9p6up$mmu$1@build.ecli=
pse.org</A>...<BR>>>=20
Hi Peter,<BR>>><BR>>> thanks for info, =
however,=20
RMC is based on EPF and I see current <BR>>> =
solution<BR>>> of=20
EPF (library.xml) as a fundamental constraint for clear & easy =
<BR>>> solution<BR>>> at RMC level.=20
Or?<BR>>><BR>>> Can you please describe the scenario =
with RMC=20
how it will be implemented?<BR>>><BR>>> Or shall I =
post this=20
at IBM Rational forum?<BR>>><BR>>>=20
Roman<BR>>><BR>>> "Peter Haumer" <<A=20
href=3D"mailto:phaumer@us.ibm.com">phaumer@us.ibm.com</A>> =
wrote in=20
message<BR>>> <A=20
=
href=3D"news:f9o54i$924$1@build.eclipse.org">news:f9o54i$924$1@build.ecli=
pse.org</A>...<BR>>>>=20
1) no, the guid remains the same<BR>>>> 2) not sure I =
understand=20
the context of this, but I would recommend to<BR>>>> only =
version=20
manage your own files and if you are using cvs directly=20
get<BR>>>> the OpenUP sources from our server or if you =
use CC=20
provide a zip/rar <BR>>>> file<BR>>>> with the =
OpenUP=20
files that users can unzip as view-private files<BR>>>> =
3)=20
Rational Method Composer 7.2 will fully support this scenario, =
which=20
<BR>>>> is<BR>>>> not in scope for EPF =
Composer. =20
For enterprise deployments and full<BR>>>> scalability we =
recommend RMC in which every plugin can be maintained as =
<BR>>>>=20
an<BR>>>> eclipse project and loaded when needed. In =
addition we=20
provide project<BR>>>> types for configurations, =
enterprise=20
reports, and estimation models in<BR>>>> RMC. EPF =
Composer=20
is designed to support a single project per =
library<BR>>>> only=20
as it is primary used to maintain OpenUP. A workaround for =
you=20
<BR>>>> would<BR>>>> be what I described above =
for=20
(2).<BR>>>><BR>>>> Best regards,<BR>>>> =
Peter=20
Haumer.<BR>>>><BR>>>> <BR>>>> "Roman =
Smirak"=20
<<A=20
=
href=3D"mailto:roman.smirak@tietoenator.com">roman.smirak@tietoenator.com=
</A>>=20
wrote in message<BR>>>> <A=20
=
href=3D"news:f9kcmi$idh$1@build.eclipse.org">news:f9kcmi$idh$1@build.ecli=
pse.org</A>...<BR>>>>>=20
Hi Ricardo,<BR>>>>><BR>>>>> =
the way=20
you described below is the one I've been using so far;=20
<BR>>>>> however,<BR>>>>> I have few =
issues=20
here:<BR>>>>> 1/ What if you refactor the content of =
OpenUP,=20
e.g. an element I was<BR>>>>> referencing to is no =
longer in=20
same package or plugin? Is there any<BR>>>>> impact on =
UID?<BR>>>>><BR>>>>> 2/ Currently we have =
the=20
whole library in a versioning repository,<BR>>>>> =
although=20
everyone has got the basis (OpenUP, or RUP) with the tool=20
<BR>>>>> (EMC,<BR>>>>> or RMC) - no =
problem for=20
OpenUP, in case of RUP, well we are talking<BR>>>>> =
about 60MB=20
or so (which you have to check in every time you=20
migrate)<BR>>>>><BR>>>>> 3/ Let say we =
have a=20
common basis in our department X, let's call =
it<BR>>>>>=20
OpenUP/X; there is a project A which will use it plus extension A=20
minus<BR>>>>> irrelevant content from basis; in case =
of=20
eclipse plugins they simply<BR>>>>> check out required =
plugins=20
(they stay in touch with their updates by<BR>>>>> =
department X=20
authority) but they don't check out irrelevant plugins=20
(no<BR>>>>> mess) + create their new one and check it =
in their=20
repository (will be<BR>>>>> maintained there); =
currently they=20
need to check out whole library X +<BR>>>>> submit =
their=20
plugins A into the library shared by others (and they=20
do<BR>>>>> same action as well =3D> mess X + A + B =
+ C, etc.)=20
in order to fulfil the<BR>>>>> use case (the basis =
maintained=20
by department, a project extension<BR>>>>> maintained =
by the=20
project itself)<BR>>>>><BR>>>>> I see the=20
library.xml as a big constraint in this use=20
case.<BR>>>>><BR>>>>>=20
Regards,<BR>>>>><BR>>>>>=20
Roman<BR>>>>><BR>>>>> "Ricardo Balduino" =
<<A=20
href=3D"mailto:balduino@us.ibm.com">balduino@us.ibm.com</A>> =
wrote in=20
message<BR>>>>> <A=20
=
href=3D"news:f9itco$87k$1@build.eclipse.org">news:f9itco$87k$1@build.ecli=
pse.org</A>...<BR>>>>>>=20
In first paragraph I meant less cumbersome, yet safer=20
;-)<BR>>>>>><BR>>>>>> "Ricardo =
Balduino"=20
<<A =
href=3D"mailto:balduino@us.ibm.com">balduino@us.ibm.com</A>> wrote=20
in message<BR>>>>>> <A=20
=
href=3D"news:f9g8d0$db$1@build.eclipse.org">news:f9g8d0$db$1@build.eclips=
e.org</A>...<BR>>>>>>>=20
Option A sounds less cumbersome and safer, as the EPF Composer=20
tool<BR>>>>>>> will take care of the work. In =
fact,=20
according to your description of<BR>>>>>>> =
option A,=20
OpenUP 2.x would overwrite OpenUP=20
1.x.<BR>>>>>>><BR >>>>>>> =
Instead of=20
playing with importing a new OpenUP plug-in into=20
your<BR>>>>>>> existing library, have you =
considered=20
getting the new OpenUP library<BR>>>>>>> =
available and=20
import your plug-in into it instead? With that=20
<BR>>>>>>> approach,<BR>>>>>>> =
you are=20
moving your plug-in around, so you know there are no=20
<BR>>>>>>> =
duplicates<BR>>>>>>> of it=20
in a brand new OpenUP library. If your plug-in initially=20
<BR>>>>>>> depended<BR>>>>>>> =
on some=20
OpenUP element that does not exist anymore when a new=20
version<BR>>>>>>> of OpenUP is released, the =
import will=20
show you warnings, which will<BR>>>>>>> help you =
to spot=20
where you need to maintain your plug-in to extend=20
<BR>>>>>>> the<BR>>>>>>> most =
current=20
version of OpenUP. Additions to OpenUP will not=20
affect<BR>>>>>>> your=20
plug-in.<BR>>>>>>> <BR>>>>>>>=20
Cheers,<BR>>>>>>> <BR>>>>>>> =
Ricardo=20
Balduino.<BR>>>>>>> <BR>>>>>>>=20
"K.Benameur" <<A=20
href=3D"mailto:benameur@freesurf.fr">benameur@freesurf.fr</A>> =
wrote in=20
message<BR>>>>>>> <A=20
=
href=3D"news:f9f8cn$ah0$1@build.eclipse.org">news:f9f8cn$ah0$1@build.ecli=
pse.org</A>...<BR>>>>>>>>=20
Hi =
Peter,<BR>>>>>>>> <BR>>>>>>>>=20
Sorry to bother you with all my questions=20
=
!!!<BR>>>>>>>> <BR>>>>>>>> I am =
not sure that I have completly understood your=20
=
answer.<BR>>>>>>>> <BR>>>>>>>> =
To=20
check this I propose a simple scenario =20
:<BR> >>>>>>>& ;nbsp; - I develop a =
library using=20
Open Up 1.x.<BR> >>>>>>>& ;nbsp; - A new =
version=20
of Open Up is out let say =
2.x<BR> >>>>>>>& ;nbsp; - I=20
wan't to take advantage of this new Open Up=20
=
version.<BR>>>>>>>> <BR>>>>>>>> =
A) So ideally, I import the new version in my library and Open Up=20
<BR>>>>>>>> =
1.x<BR>>>>>>>> is=20
updated to=20
=
2.x.<BR>>>>>>>> <BR>>>>>>>> I=20
have the feeling that it will not be so simple as many links will=20
<BR>>>>>>>> =
be<BR>>>>>>>> broken=20
due to changes between 1.X and=20
=
2.X.<BR>>>>>>>> <BR>>>>>>>> B) =
I=20
use the copy operation to have the 1.X & 2.X plugin in my=20
<BR>>>>>>>>=20
=
library<BR>>>>>>>> <BR>>>>>>>> =
It=20
seems that option B) is the one to go as you said that we have=20
to<BR>>>>>>>> do a copy as uuid must be=20
unique.<BR>>>>>>>>=20
=3D><BR>>>>>>>> I have to do the migration =
manually by replacing elements of Open=20
<BR>>>>>>>> =
1.x<BR>>>>>>>> by=20
their counterparts in=20
=
2.x.<BR>>>>>>>> <BR>>>>>>>> is =
it=20
right or I missed something like a smart import that=20
detect<BR>>>>>>>> conflicts and propose to =
update=20
automatically element that exist =
in<BR>>>>>>>> 1.X=20
& 2.X /delete obsolete element of 1.X / etc..=20
?<BR>>>>>>>> <BR>>>>>>>> =
The=20
question is what is the recommended procedure to perform a=20
<BR>>>>>>>> =
plug-in<BR>>>>>>>>=20
upgrade with a minimum effort=20
?<BR>>>>>>>> <BR>>>>>>>> =
My=20
concern will be the maintenance cost of a library. If we build=20
<BR>>>>>>>> =
our<BR>>>>>>>>=20
library from many commercial or non commercial plugins we have to=20
<BR>>>>>>>> =
deal<BR>>>>>>>> with=20
their evolutions at a minimal=20
=
cost.<BR>>>>>>>> <BR>>>>>>>> <BR>=
>>>>>>><BR >>>>>>>><BR >>>&=
gt;>>>>=20
Best Regards=20
=
....<BR>>>>>>>> <BR>>>>>>>> PS: =
I=20
will be in vacation for the next 2 weeks so you have plenty=20
of<BR>>>>>>>> time for an anwser=20
=
;)<BR>>>>>>>> <BR>>>>>>>> <BR>>=
;>>>>>>=20
PS:<BR> >>>>>>>& ;nbsp; We use ClearCase but it =
will not=20
help here except to roll back to a<BR>>>>>>>> =
stable=20
baseline and lock elements for modification=20
...<BR> >>>>>>>& ;nbsp; We are developping our =
process=20
in multi site. As we didn't want =
to<BR>>>>>>>> add=20
more complexity we decided to work only on one site=20
(windows<BR>>>>>>>> terminal server for the =
distant=20
site) with one development branch =
in<BR>>>>>>>> base=20
CC.<BR>>>>>>>> May be you have a successfull=20
experience using CC multisite & UCM =
?<BR>>>>>>>>=20
Can you share your experience ?<BR>>>>>>>> =
Seems that=20
in CC 7 (we use CC 6) the merge manager have a new=20
option<BR>>>>>>>> i.e. to always copy. So may =
be we=20
can now have branches & multisite =
<BR>>>>>>>>=20
as<BR>>>>>>>> now xmi file can be merged by a =
copy. I=20
see here a potential source <BR>>>>>>>>=20
of<BR>>>>>>>> trouble as we may surely end =
with=20
invalid references if for instance<BR>>>>>>>> =
the=20
merge (copy) is done partially on some xmi=20
=
....<BR>>>>>>>> <BR>>>>>>>> =
Peter=20
Haumer wrote:<BR> >>>>>>>& ;gt;=20
Hello.<BR> >>>>>>>& ;gt; You cannot load =
multiple=20
versions of the same plugin into the=20
same<BR> >>>>>>>& ;gt; library. All library =
elements are=20
identified by global unique ids =
<BR> >>>>>>>& ;gt;=20
and<BR> >>>>>>>& ;gt; hence such ids needs to be =
unique. To get more than one copy of=20
an<BR> >>>>>>>& ;gt; element you need to use the =
copy=20
operation in the library view. =
In<BR> >>>>>>>& ;gt;=20
general we recommend to use a version control system like=20
Rational<BR> >>>>>>>& ;gt; ClearCase which =
allows you to=20
label and restore old versions of =
<BR> >>>>>>>& ;gt;=20
whole<BR> >>>>>>>& ;gt; groups of=20
=
files.<BR> >>>>>>>& ;gt; <BR>>>>>>>>=
;>=20
Best regards,<BR> >>>>>>>& ;gt;=20
=
Peter.<BR> >>>>>>>& ;gt; <BR>>>>>>>>=
;>=20
P.S.: Surely they should not be an exception when loading the=20
same<BR> >>>>>>>& ;gt; content twice, but an =
error=20
message. Please, file a bugzilla=20
with<BR> >>>>>>>& ;gt; reproducible=20
=
steps.<BR> >>>>>>>& ;gt; <BR>>>>>>>>=
;><BR> >>>>>>>& ;gt;=20
"K.Benameur" <<A=20
href=3D"mailto:benameur@freesurf.fr">benameur@freesurf.fr</A>> =
wrote in=20
message<BR> >>>>>>>& ;gt; <A=20
=
href=3D"news:f973f4$goo$1@build.eclipse.org">news:f973f4$goo$1@build.ecli=
pse.org</A>...<BR> >>>>>>>& ;gt;>=20
Hi=20
=
all,<BR> >>>>>>>& ;gt;> <BR>>>>>>>&=
gt;>>=20
It is a very good question. May be it can be addressed by an=20
<BR> >>>>>>>& ;gt;>=20
update<BR> >>>>>>>& ;gt;> of an existing =
guideline as=20
the Development Guideline=20
=
?<BR> >>>>>>>& ;gt;> <BR>>>>>>>>=
>>=20
I think that we should have a "recommended" procedure from the=20
EPF<BR> >>>>>>>& ;gt;> team to update =
plug-ins to a=20
new version.<BR> >>>>>>>& ;gt;> It is =
now a=20
fairly common scenario that multiple versions of=20
the<BR> >>>>>>>& ;gt;> same plug-ins are=20
=
out.<BR> >>>>>>>& ;gt;> <BR>>>>>>>&=
gt;>>=20
And it is not only related to Open Up but for any library /=20
<BR> >>>>>>>& ;gt;>=20
plug-in<BR> >>>>>>>& ;gt;> as part of the =
development=20
process (we are developing our =
own<BR> >>>>>>>& ;gt;>=20
library / plug-ins without Open=20
=
Up).<BR> >>>>>>>& ;gt;> <BR>>>>>>>&=
gt;>><BR> >>>>>>>& ;gt;> =20
In short, what is the recommended procedure to migrate to a=20
new<BR> >>>>>>>& ;gt;> version ? Do we have =
to export=20
/ import ? What are the risks?=20
What<BR> >>>>>>>& ;gt;> we may lose=20
=
?<BR> >>>>>>>& ;gt;> <BR>>>>>>>>=
>><BR> >>>>>>>& ;gt;>=20
Best=20
=
Regards<BR> >>>>>>>& ;gt;> <BR>>>>>>&g=
t;>>><BR> >>>>>>>& ;gt; <BR>>>>>>=
;><BR>>>>>><BR>>>>>> <BR>>>>>=
<BR>>>>><BR>>>> <BR>>>><BR>>><BR>>&=
gt;<BR>><BR>><BR>>=20
<BR><BR></BLOCKQUOTE></BLOCKQUOTE></BLOCKQUOTE></BODY></HTML >
------=_NextPart_000_003F_01C7F0AA.74CD32E0--
|
|
|
| Re: Migration to newever library version [message #40123 is a reply to message #39963] |
Fri, 07 September 2007 05:49 |
Peter Haumer
Messages: 228
Registered: July 2009 |
Senior Member |
|
|
This is a multi-part message in MIME format.
------=_NextPart_000_005E_01C7F0D8.2005ED50
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Hello Kamal.
I see an increase of interest and lecturing from Osellus in recent days =
here in the forum. Are you guys finally ready to contribute and write =
some code for EPF? ;-)=20
As we clearly said, the feature to loosely combine method plug-ins and =
scale your libraries up to the enterprise level is a Rational Method =
Composer distinguishing feature and for us not in scope of EPF. As =
Ricardo points out EPFC is powerful enough to build any kind of large =
method library. The focus is here on one library at a time. RMC allows =
to scale this up to multiple collocated libraries at the time.=20
This is something we sell, which is in line with the license and agenda =
of Eclipse to provide platforms that can be used to build commercial =
tools on top that can be sold. Osellus only sells and does not work in =
open source and no communities benefit. Hence, I thought that especially =
you guys would understand and not try to push the issue on this one.=20
Best regards,
Peter.
"Kamal Ahluwalia" <kamal@osellus.com> wrote in message =
news:fbpr2j$sbm$1@build.eclipse.org...
Thanks for your response Ricardo.
=20
This thread highlights some of the fundamental constraints in using =
EPF Composer, especially library.xml to maintain processes. It appears =
RMC 7.2 addresses some of these problems. Are there any plans to donate =
those bits to EPF so that the community can benefit ?
=20
Kamal=20
"Ricardo Balduino" <balduino@us.ibm.com> wrote in message =
news:fbpnj1$24t$1@build.eclipse.org...
>>> I wanted to clarify if it really is the case that EPF Composer =
is designed to be primarily used to maintain OpenUP only. =20
It is not really the case.
EPF Composer is used by the EPF team to maintain OpenUP, DSDM, =
Scrum, XP and any other processes being captured today and in the future =
under the EPF project.
Moreover, EPF users can capture their own home-grown processes or =
extensions to available processes using EPF Composer.
I hope this clarifies your question.
Regards,
Ricardo Balduino.
"Kamal Ahluwalia" <kamal@osellus.com> wrote in message =
news:fbpmjg$rai$1@build.eclipse.org...
"EPF Composer is designed to support a single project per library =
only as it is primary used to maintain OpenUP".
=20
I wanted to clarify if it really is the case that EPF Composer is =
designed to be primarily used to maintain OpenUP only. =20
=20
Kamal
"Roman Smirak" <roman.smirak@tietoenator.com> wrote in message =
news:f9rjjo$50e$1@build.eclipse.org...
Hi Peter,
that is great, the implementation perfectly matches with my =
vision. Why=20
not to have it in EPF? I guess many users would welcome the =
feature.
We have licences of RMC, however, we prefer to use EPF since =
early releases=20
are available.
Regards,
Roman
"Peter Haumer" <phaumer@us.ibm.com> wrote in message=20
news:f9qa5o$jac$1@build.eclipse.org...
> Hello Roman.
> Well, if our competitors can abuse this forum to plug their =
products; so=20
> can I :-)
>
> RMC 7.2 does not need the library.xmi file anymore as it uses =
the Eclipse=20
> workspace's projects to find all the files. Every plugin is a =
project as=20
> well as you can create more than one project for managing =
configurations=20
> and one project for estimation data (another RMC added value). =
The problem=20
> view is used just as in Eclipse to tell you if you are missing =
elements in=20
> your workspace that other elements depend upon. You could =
ignore those=20
> errors or fix them by loading the project's that contain the =
missing=20
> elements.
>
> See the attached image with an example where I was using =
plugins managed=20
> in CVS and plugins managed in CC all at the same time in the =
same=20
> workspace. Plugins can now reside in complete different =
directories even=20
> on different machine. Just like Eclipse projects, you load =
them into your=20
> workspace and use them whenever you need to use them.
>
> However, RMC can still generate a library.xmi for you to =
manage libraries=20
> that are fully compatible with EPF Composer. For example, if =
you check the=20
> OpenUP CVS repository: it already has project files in each =
plugin=20
> directory. That is because I was already working with OpenUP =
in RMC 7.2;=20
> at the same time where the rest of the team continued working =
with EPF=20
> Composer. Two ways of loading the same library in a fully =
compatible way.
>
> Hope this helps,
> Peter.
>
>
>
> "Roman Smirak" <roman.smirak@tietoenator.com> wrote in message =
> news:f9p6up$mmu$1@build.eclipse.org...
>> Hi Peter,
>>
>> thanks for info, however, RMC is based on EPF and I see =
current=20
>> solution
>> of EPF (library.xml) as a fundamental constraint for clear & =
easy=20
>> solution
>> at RMC level. Or?
>>
>> Can you please describe the scenario with RMC how it will be =
implemented?
>>
>> Or shall I post this at IBM Rational forum?
>>
>> Roman
>>
>> "Peter Haumer" <phaumer@us.ibm.com> wrote in message
>> news:f9o54i$924$1@build.eclipse.org...
>>> 1) no, the guid remains the same
>>> 2) not sure I understand the context of this, but I would =
recommend to
>>> only version manage your own files and if you are using cvs =
directly get
>>> the OpenUP sources from our server or if you use CC provide =
a zip/rar=20
>>> file
>>> with the OpenUP files that users can unzip as view-private =
files
>>> 3) Rational Method Composer 7.2 will fully support this =
scenario, which=20
>>> is
>>> not in scope for EPF Composer. For enterprise deployments =
and full
>>> scalability we recommend RMC in which every plugin can be =
maintained as=20
>>> an
>>> eclipse project and loaded when needed. In addition we =
provide project
>>> types for configurations, enterprise reports, and estimation =
models in
>>> RMC. EPF Composer is designed to support a single project =
per library
>>> only as it is primary used to maintain OpenUP. A workaround =
for you=20
>>> would
>>> be what I described above for (2).
>>>
>>> Best regards,
>>> Peter Haumer.
>>>
>>>
>>> "Roman Smirak" <roman.smirak@tietoenator.com> wrote in =
message
>>> news:f9kcmi$idh$1@build.eclipse.org...
>>>> Hi Ricardo,
>>>>
>>>> the way you described below is the one I've been using so =
far;=20
>>>> however,
>>>> I have few issues here:
>>>> 1/ What if you refactor the content of OpenUP, e.g. an =
element I was
>>>> referencing to is no longer in same package or plugin? Is =
there any
>>>> impact on UID?
>>>>
>>>> 2/ Currently we have the whole library in a versioning =
repository,
>>>> although everyone has got the basis (OpenUP, or RUP) with =
the tool=20
>>>> (EMC,
>>>> or RMC) - no problem for OpenUP, in case of RUP, well we =
are talking
>>>> about 60MB or so (which you have to check in every time you =
migrate)
>>>>
>>>> 3/ Let say we have a common basis in our department X, =
let's call it
>>>> OpenUP/X; there is a project A which will use it plus =
extension A minus
>>>> irrelevant content from basis; in case of eclipse plugins =
they simply
>>>> check out required plugins (they stay in touch with their =
updates by
>>>> department X authority) but they don't check out irrelevant =
plugins (no
>>>> mess) + create their new one and check it in their =
repository (will be
>>>> maintained there); currently they need to check out whole =
library X +
>>>> submit their plugins A into the library shared by others =
(and they do
>>>> same action as well =3D> mess X + A + B + C, etc.) in order =
to fulfil the
>>>> use case (the basis maintained by department, a project =
extension
>>>> maintained by the project itself)
>>>>
>>>> I see the library.xml as a big constraint in this use case.
>>>>
>>>> Regards,
>>>>
>>>> Roman
>>>>
>>>> "Ricardo Balduino" <balduino@us.ibm.com> wrote in message
>>>> news:f9itco$87k$1@build.eclipse.org...
>>>>> In first paragraph I meant less cumbersome, yet safer ;-)
>>>>>
>>>>> "Ricardo Balduino" <balduino@us.ibm.com> wrote in message
>>>>> news:f9g8d0$db$1@build.eclipse.org...
>>>>>> Option A sounds less cumbersome and safer, as the EPF =
Composer tool
>>>>>> will take care of the work. In fact, according to your =
description of
>>>>>> option A, OpenUP 2.x would overwrite OpenUP 1.x.
>>>>>>
>>>>>> Instead of playing with importing a new OpenUP plug-in =
into your
>>>>>> existing library, have you considered getting the new =
OpenUP library
>>>>>> available and import your plug-in into it instead? With =
that=20
>>>>>> approach,
>>>>>> you are moving your plug-in around, so you know there are =
no=20
>>>>>> duplicates
>>>>>> of it in a brand new OpenUP library. If your plug-in =
initially=20
>>>>>> depended
>>>>>> on some OpenUP element that does not exist anymore when a =
new version
>>>>>> of OpenUP is released, the import will show you warnings, =
which will
>>>>>> help you to spot where you need to maintain your plug-in =
to extend=20
>>>>>> the
>>>>>> most current version of OpenUP. Additions to OpenUP will =
not affect
>>>>>> your plug-in.
>>>>>>
>>>>>> Cheers,
>>>>>>
>>>>>> Ricardo Balduino.
>>>>>>
>>>>>> "K.Benameur" <benameur@freesurf.fr> wrote in message
>>>>>> news:f9f8cn$ah0$1@build.eclipse.org...
>>>>>>> Hi Peter,
>>>>>>>
>>>>>>> Sorry to bother you with all my questions !!!
>>>>>>>
>>>>>>> I am not sure that I have completly understood your =
answer.
>>>>>>>
>>>>>>> To check this I propose a simple scenario :
>>>>>>> - I develop a library using Open Up 1.x.
>>>>>>> - A new version of Open Up is out let say 2.x
>>>>>>> - I wan't to take advantage of this new Open Up =
version.
>>>>>>>
>>>>>>> A) So ideally, I import the new version in my library =
and Open Up=20
>>>>>>> 1.x
>>>>>>> is updated to 2.x.
>>>>>>>
>>>>>>> I have the feeling that it will not be so simple as many =
links will=20
>>>>>>> be
>>>>>>> broken due to changes between 1.X and 2.X.
>>>>>>>
>>>>>>> B) I use the copy operation to have the 1.X & 2.X plugin =
in my=20
>>>>>>> library
>>>>>>>
>>>>>>> It seems that option B) is the one to go as you said =
that we have to
>>>>>>> do a copy as uuid must be unique.
>>>>>>> =3D>
>>>>>>> I have to do the migration manually by replacing =
elements of Open=20
>>>>>>> 1.x
>>>>>>> by their counterparts in 2.x.
>>>>>>>
>>>>>>> is it right or I missed something like a smart import =
that detect
>>>>>>> conflicts and propose to update automatically element =
that exist in
>>>>>>> 1.X & 2.X /delete obsolete element of 1.X / etc.. ?
>>>>>>>
>>>>>>> The question is what is the recommended procedure to =
perform a=20
>>>>>>> plug-in
>>>>>>> upgrade with a minimum effort ?
>>>>>>>
>>>>>>> My concern will be the maintenance cost of a library. If =
we build=20
>>>>>>> our
>>>>>>> library from many commercial or non commercial plugins =
we have to=20
>>>>>>> deal
>>>>>>> with their evolutions at a minimal cost.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Best Regards ...
>>>>>>>
>>>>>>> PS: I will be in vacation for the next 2 weeks so you =
have plenty of
>>>>>>> time for an anwser ;)
>>>>>>>
>>>>>>>
>>>>>>> PS:
>>>>>>> We use ClearCase but it will not help here except to =
roll back to a
>>>>>>> stable baseline and lock elements for modification ...
>>>>>>> We are developping our process in multi site. As we =
didn't want to
>>>>>>> add more complexity we decided to work only on one site =
(windows
>>>>>>> terminal server for the distant site) with one =
development branch in
>>>>>>> base CC.
>>>>>>> May be you have a successfull experience using CC =
multisite & UCM ?
>>>>>>> Can you share your experience ?
>>>>>>> Seems that in CC 7 (we use CC 6) the merge manager have =
a new option
>>>>>>> i.e. to always copy. So may be we can now have branches =
& multisite=20
>>>>>>> as
>>>>>>> now xmi file can be merged by a copy. I see here a =
potential source=20
>>>>>>> of
>>>>>>> trouble as we may surely end with invalid references if =
for instance
>>>>>>> the merge (copy) is done partially on some xmi ...
>>>>>>>
>>>>>>> Peter Haumer wrote:
>>>>>>>> Hello.
>>>>>>>> You cannot load multiple versions of the same plugin =
into the same
>>>>>>>> library. All library elements are identified by global =
unique ids=20
>>>>>>>> and
>>>>>>>> hence such ids needs to be unique. To get more than =
one copy of an
>>>>>>>> element you need to use the copy operation in the =
library view. In
>>>>>>>> general we recommend to use a version control system =
like Rational
>>>>>>>> ClearCase which allows you to label and restore old =
versions of=20
>>>>>>>> whole
>>>>>>>> groups of files.
>>>>>>>>
>>>>>>>> Best regards,
>>>>>>>> Peter.
>>>>>>>>
>>>>>>>> P.S.: Surely they should not be an exception when =
loading the same
>>>>>>>> content twice, but an error message. Please, file a =
bugzilla with
>>>>>>>> reproducible steps.
>>>>>>>>
>>>>>>>>
>>>>>>>> "K.Benameur" <benameur@freesurf.fr> wrote in message
>>>>>>>> news:f973f4$goo$1@build.eclipse.org...
>>>>>>>>> Hi all,
>>>>>>>>>
>>>>>>>>> It is a very good question. May be it can be addressed =
by an=20
>>>>>>>>> update
>>>>>>>>> of an existing guideline as the Development Guideline =
?
>>>>>>>>>
>>>>>>>>> I think that we should have a "recommended" procedure =
from the EPF
>>>>>>>>> team to update plug-ins to a new version.
>>>>>>>>> It is now a fairly common scenario that multiple =
versions of the
>>>>>>>>> same plug-ins are out.
>>>>>>>>>
>>>>>>>>> And it is not only related to Open Up but for any =
library /=20
>>>>>>>>> plug-in
>>>>>>>>> as part of the development process (we are developing =
our own
>>>>>>>>> library / plug-ins without Open Up).
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> In short, what is the recommended procedure to =
migrate to a new
>>>>>>>>> version ? Do we have to export / import ? What are the =
risks? What
>>>>>>>>> we may lose ?
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Best Regards
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>
>=20
------=_NextPart_000_005E_01C7F0D8.2005ED50
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML xmlns:o =3D "urn:schemas-microsoft-com:office:office"><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2900.3157" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>Hello Kamal.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>I see an increase of interest and =
lecturing from=20
Osellus in recent days here in the forum. Are you guys finally =
ready to=20
contribute and write some code for EPF? ;-) </FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>As we clearly said, the feature to =
loosely combine=20
method plug-ins and scale your libraries up to the enterprise level is a =
Rational Method Composer distinguishing feature and for us not in scope =
of=20
EPF. As Ricardo points out EPFC is powerful enough to build any =
kind of=20
large method library. The focus is here on one library at a =
time. =20
RMC allows to scale this up to multiple collocated libraries at the =
time.=20
</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>This is something we sell, =
which </FONT><FONT=20
face=3DArial size=3D2>is in line with the license and agenda of =
Eclipse to=20
provide platforms that can be used to build commercial tools on top that =
can be=20
sold. Osellus only sells and does not work in open source and no =
communities=20
benefit. Hence, I thought that especially you guys would understand and =
not try=20
to push the issue on this one. </FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>Best regards,</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Peter.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
<DIV>"Kamal Ahluwalia" <<A=20
href=3D"mailto:kamal@osellus.com">kamal@osellus.com</A>> wrote in =
message <A=20
=
href=3D"news:fbpr2j$sbm$1@build.eclipse.org">news:fbpr2j$sbm$1@build.ecli=
pse.org</A>...</DIV>
<DIV><FONT face=3DArial size=3D2>
<P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><SPAN=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New =
Roman','serif'">Thanks for=20
your response Ricardo.<o:p></o:p></SPAN></P>
<P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><SPAN=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New =
Roman','serif'"><o:p> </o:p></SPAN></P>
<P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><SPAN=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman','serif'">This =
thread=20
highlights some of the fundamental constraints in using EPF Composer,=20
especially library.xml to maintain processes. It appears RMC 7.2 =
addresses=20
some of these problems. Are there any plans to donate those bits to =
EPF so=20
that the community can benefit ?<o:p></o:p></SPAN></P>
<P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><SPAN=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New =
Roman','serif'"><o:p> </o:p></SPAN></P>
<P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><SPAN=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New =
Roman','serif'">Kamal=20
<o:p></o:p></SPAN></P></FONT></DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
<DIV>"Ricardo Balduino" <<A=20
href=3D"mailto:balduino@us.ibm.com">balduino@us.ibm.com</A>> =
wrote in=20
message <A=20
=
href=3D"news:fbpnj1$24t$1@build.eclipse.org">news:fbpnj1$24t$1@build.ecli=
pse.org</A>...</DIV>
<DIV><FONT face=3DArial size=3D2>>>> <FONT size=3D3><FONT=20
face=3D"Times New Roman">I wanted to clarify if it really =
is the=20
case that EPF Composer is designed to be primarily used to maintain =
OpenUP=20
only. </FONT></FONT></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><FONT size=3D3><FONT=20
face=3D"Times New Roman"></FONT></FONT></FONT> </DIV>
<DIV><FONT size=3D+0><FONT size=3D+0><FONT face=3DArial><FONT =
size=3D2>It is not=20
really the case.</FONT></FONT></FONT></FONT></DIV>
<DIV><FONT size=3D+0><FONT size=3D+0><FONT face=3DArial><FONT=20
size=3D2></FONT></FONT></FONT></FONT> </DIV>
<DIV><FONT size=3D+0><FONT size=3D+0><FONT face=3DArial><FONT =
size=3D2>EPF Composer=20
is used by the EPF team to maintain OpenUP, DSDM, Scrum, XP and any =
other=20
processes being captured today and in the future under the EPF=20
project.</FONT></FONT></FONT></FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>Moreover, EPF users can capture =
their own=20
home-grown processes or extensions to available processes using EPF=20
Composer.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>I hope this clarifies your=20
question.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>Regards,</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>Ricardo Balduino.</FONT></DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
<DIV>"Kamal Ahluwalia" <<A=20
href=3D"mailto:kamal@osellus.com">kamal@osellus.com</A>> wrote =
in message=20
<A=20
=
href=3D"news:fbpmjg$rai$1@build.eclipse.org">news:fbpmjg$rai$1@build.ecli=
pse.org</A>...</DIV>
<DIV><FONT face=3DArial size=3D2>
<P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><FONT =
size=3D3><FONT=20
face=3D"Times New Roman">=93EPF Composer is designed to support a =
single=20
project per library only as it is primary used to maintain=20
OpenUP=94.<o:p></o:p></FONT></FONT></P>
<P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><o:p><FONT=20
face=3D"Times New Roman" size=3D3> </FONT></o:p></P>
<P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><FONT =
size=3D3><FONT=20
face=3D"Times New Roman">I wanted to clarify =
if it really is the=20
case that EPF Composer is designed to be primarily used to =
maintain OpenUP=20
only. <o:p></o:p></FONT></FONT></P>
<P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><o:p><FONT=20
face=3D"Times New Roman" size=3D3> </FONT></o:p></P>
<P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><FONT =
size=3D3><FONT=20
face=3D"Times New =
Roman">Kamal<o:p></o:p></FONT></FONT></P></FONT></DIV >
<BLOCKQUOTE=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
<DIV>"Roman Smirak" <<A=20
=
href=3D"mailto:roman.smirak@tietoenator.com">roman.smirak@tietoenator.com=
</A>>=20
wrote in message <A=20
=
href=3D"news:f9rjjo$50e$1@build.eclipse.org">news:f9rjjo$50e$1@build.ecli=
pse.org</A>...</DIV>Hi=20
Peter,<BR><BR> that is great, the implementation =
perfectly=20
matches with my vision. Why <BR>not to have it in EPF? I guess =
many=20
users would welcome the feature.<BR><BR>We have licences of RMC, =
however, we prefer to use EPF since early releases <BR>are=20
available.<BR><BR>Regards,<BR><BR>Roman<BR><BR>"Peter Haumer" =
<<A=20
href=3D"mailto:phaumer@us.ibm.com">phaumer@us.ibm.com</A>> =
wrote in=20
message <BR><A=20
=
href=3D"news:f9qa5o$jac$1@build.eclipse.org">news:f9qa5o$jac$1@build.ecli=
pse.org</A>...<BR>>=20
Hello Roman.<BR>> Well, if our competitors can abuse this =
forum to=20
plug their products; so <BR>> can I :-)<BR>><BR>> RMC =
7.2 does=20
not need the library.xmi file anymore as it uses the Eclipse =
<BR>>=20
workspace's projects to find all the files. Every plugin is a =
project as=20
<BR>> well as you can create more than one project for =
managing=20
configurations <BR>> and one project for estimation data =
(another RMC=20
added value). The problem <BR>> view is used just as in =
Eclipse to=20
tell you if you are missing elements in <BR>> your workspace =
that=20
other elements depend upon. You could ignore those =
<BR>> errors=20
or fix them by loading the project's that contain the missing =
<BR>>=20
elements.<BR>><BR>> See the attached image with an example =
where I=20
was using plugins managed <BR>> in CVS and plugins managed in =
CC all=20
at the same time in the same <BR>> workspace. Plugins can now =
reside=20
in complete different directories even <BR>> on different=20
machine. Just like Eclipse projects, you load them into =
your=20
<BR>> workspace and use them whenever you need to use=20
them.<BR>><BR>> However, RMC can still generate a =
library.xmi for=20
you to manage libraries <BR>> that are fully compatible with =
EPF=20
Composer. For example, if you check the <BR>> OpenUP CVS =
repository:=20
it already has project files in each plugin <BR>> =
directory. =20
That is because I was already working with OpenUP in RMC 7.2; =
<BR>>=20
at the same time where the rest of the team continued working =
with EPF=20
<BR>> Composer. Two ways of loading the same library in =
a fully=20
compatible way.<BR>><BR>> Hope this helps,<BR>>=20
Peter.<BR>><BR>><BR>><BR>> "Roman Smirak" <<A=20
=
href=3D"mailto:roman.smirak@tietoenator.com">roman.smirak@tietoenator.com=
</A>>=20
wrote in message <BR>> <A=20
=
href=3D"news:f9p6up$mmu$1@build.eclipse.org">news:f9p6up$mmu$1@build.ecli=
pse.org</A>...<BR>>>=20
Hi Peter,<BR>>><BR>>> thanks for info, =
however,=20
RMC is based on EPF and I see current <BR>>> =
solution<BR>>>=20
of EPF (library.xml) as a fundamental constraint for clear & =
easy=20
<BR>>> solution<BR>>> at RMC level.=20
Or?<BR>>><BR>>> Can you please describe the scenario =
with=20
RMC how it will be implemented?<BR>>><BR>>> Or shall =
I post=20
this at IBM Rational forum?<BR>>><BR>>>=20
Roman<BR>>><BR>>> "Peter Haumer" <<A=20
href=3D"mailto:phaumer@us.ibm.com">phaumer@us.ibm.com</A>> =
wrote in=20
message<BR>>> <A=20
=
href=3D"news:f9o54i$924$1@build.eclipse.org">news:f9o54i$924$1@build.ecli=
pse.org</A>...<BR>>>>=20
1) no, the guid remains the same<BR>>>> 2) not sure I=20
understand the context of this, but I would recommend =
to<BR>>>>=20
only version manage your own files and if you are using cvs =
directly=20
get<BR>>>> the OpenUP sources from our server or if you =
use CC=20
provide a zip/rar <BR>>>> file<BR>>>> with the =
OpenUP=20
files that users can unzip as view-private files<BR>>>> =
3)=20
Rational Method Composer 7.2 will fully support this scenario, =
which=20
<BR>>>> is<BR>>>> not in scope for EPF =
Composer. =20
For enterprise deployments and full<BR>>>> scalability =
we=20
recommend RMC in which every plugin can be maintained as=20
<BR>>>> an<BR>>>> eclipse project and loaded =
when=20
needed. In addition we provide project<BR>>>> types for =
configurations, enterprise reports, and estimation models=20
in<BR>>>> RMC. EPF Composer is designed to =
support a=20
single project per library<BR>>>> only as it is primary =
used to=20
maintain OpenUP. A workaround for you <BR>>>>=20
would<BR>>>> be what I described above for=20
(2).<BR>>>><BR>>>> Best =
regards,<BR>>>> Peter=20
Haumer.<BR>>>><BR>>>> <BR>>>> "Roman =
Smirak"=20
<<A=20
=
href=3D"mailto:roman.smirak@tietoenator.com">roman.smirak@tietoenator.com=
</A>>=20
wrote in message<BR>>>> <A=20
=
href=3D"news:f9kcmi$idh$1@build.eclipse.org">news:f9kcmi$idh$1@build.ecli=
pse.org</A>...<BR>>>>>=20
Hi Ricardo,<BR>>>>><BR>>>>> =
the way=20
you described below is the one I've been using so far;=20
<BR>>>>> however,<BR>>>>> I have few =
issues=20
here:<BR>>>>> 1/ What if you refactor the content of =
OpenUP,=20
e.g. an element I was<BR>>>>> referencing to is no =
longer in=20
same package or plugin? Is there any<BR>>>>> impact =
on=20
UID?<BR>>>>><BR>>>>> 2/ Currently we =
have the=20
whole library in a versioning repository,<BR>>>>> =
although=20
everyone has got the basis (OpenUP, or RUP) with the tool=20
<BR>>>>> (EMC,<BR>>>>> or RMC) - no =
problem for=20
OpenUP, in case of RUP, well we are talking<BR>>>>> =
about=20
60MB or so (which you have to check in every time you=20
migrate)<BR>>>>><BR>>>>> 3/ Let say we =
have a=20
common basis in our department X, let's call =
it<BR>>>>>=20
OpenUP/X; there is a project A which will use it plus extension =
A=20
minus<BR>>>>> irrelevant content from basis; in case =
of=20
eclipse plugins they simply<BR>>>>> check out =
required=20
plugins (they stay in touch with their updates =
by<BR>>>>>=20
department X authority) but they don't check out irrelevant =
plugins=20
(no<BR>>>>> mess) + create their new one and check =
it in=20
their repository (will be<BR>>>>> maintained there); =
currently they need to check out whole library X =
+<BR>>>>>=20
submit their plugins A into the library shared by others (and =
they=20
do<BR>>>>> same action as well =3D> mess X + A + =
B + C,=20
etc.) in order to fulfil the<BR>>>>> use case (the =
basis=20
maintained by department, a project =
extension<BR>>>>>=20
maintained by the project=20
itself)<BR>>>>><BR>>>>> I see the =
library.xml as=20
a big constraint in this use=20
case.<BR>>>>><BR>>>>>=20
Regards,<BR>>>>><BR>>>>>=20
Roman<BR>>>>><BR>>>>> "Ricardo Balduino" =
<<A=20
href=3D"mailto:balduino@us.ibm.com">balduino@us.ibm.com</A>> =
wrote in=20
message<BR>>>>> <A=20
=
href=3D"news:f9itco$87k$1@build.eclipse.org">news:f9itco$87k$1@build.ecli=
pse.org</A>...<BR>>>>>>=20
In first paragraph I meant less cumbersome, yet safer=20
;-)<BR>>>>>><BR>>>>>> "Ricardo =
Balduino"=20
<<A =
href=3D"mailto:balduino@us.ibm.com">balduino@us.ibm.com</A>>=20
wrote in message<BR>>>>>> <A=20
=
href=3D"news:f9g8d0$db$1@build.eclipse.org">news:f9g8d0$db$1@build.eclips=
e.org</A>...<BR>>>>>>>=20
Option A sounds less cumbersome and safer, as the EPF Composer=20
tool<BR>>>>>>> will take care of the work. In =
fact,=20
according to your description of<BR>>>>>>> =
option A,=20
OpenUP 2.x would overwrite OpenUP=20
1.x.<BR>>>>>>><BR >>>>>>> =
Instead of=20
playing with importing a new OpenUP plug-in into=20
your<BR>>>>>>> existing library, have you =
considered=20
getting the new OpenUP library<BR>>>>>>> =
available and=20
import your plug-in into it instead? With that=20
<BR>>>>>>> =
approach,<BR>>>>>>> you=20
are moving your plug-in around, so you know there are no=20
<BR>>>>>>> =
duplicates<BR>>>>>>> of=20
it in a brand new OpenUP library. If your plug-in initially=20
<BR>>>>>>> =
depended<BR>>>>>>> on=20
some OpenUP element that does not exist anymore when a new=20
version<BR>>>>>>> of OpenUP is released, the =
import=20
will show you warnings, which will<BR>>>>>>> =
help you=20
to spot where you need to maintain your plug-in to extend=20
<BR>>>>>>> the<BR>>>>>>> =
most=20
current version of OpenUP. Additions to OpenUP will not=20
affect<BR>>>>>>> your=20
plug-in.<BR>>>>>>> <BR>>>>>>> =
Cheers,<BR>>>>>>> <BR>>>>>>> =
Ricardo=20
=
Balduino.<BR>>>>>>> <BR>>>>>>>=20
"K.Benameur" <<A=20
=
href=3D"mailto:benameur@freesurf.fr">benameur@freesurf.fr</A>> wrote =
in=20
message<BR>>>>>>> <A=20
=
href=3D"news:f9f8cn$ah0$1@build.eclipse.org">news:f9f8cn$ah0$1@build.ecli=
pse.org</A>...<BR>>>>>>>>=20
Hi=20
=
Peter,<BR>>>>>>>> <BR>>>>>>>>=20
Sorry to bother you with all my questions=20
=
!!!<BR>>>>>>>> <BR>>>>>>>> I am =
not sure that I have completly understood your=20
=
answer.<BR>>>>>>>> <BR>>>>>>>>=20
To check this I propose a simple scenario =20
:<BR> >>>>>>>& ;nbsp; - I develop a =
library=20
using Open Up 1.x.<BR> >>>>>>>& ;nbsp; - =
A new=20
version of Open Up is out let say=20
2.x<BR> >>>>>>>& ;nbsp; - I wan't to take =
advantage of=20
this new Open Up=20
=
version.<BR>>>>>>>> <BR>>>>>>>> =
A) So ideally, I import the new version in my library and Open =
Up=20
<BR>>>>>>>> =
1.x<BR>>>>>>>> is=20
updated to=20
=
2.x.<BR>>>>>>>> <BR>>>>>>>> I=20
have the feeling that it will not be so simple as many links =
will=20
<BR>>>>>>>> =
be<BR>>>>>>>>=20
broken due to changes between 1.X and=20
=
2.X.<BR>>>>>>>> <BR>>>>>>>> B)=20
I use the copy operation to have the 1.X & 2.X plugin in my=20
<BR>>>>>>>>=20
=
library<BR>>>>>>>> <BR>>>>>>>>=20
It seems that option B) is the one to go as you said that we =
have=20
to<BR>>>>>>>> do a copy as uuid must be=20
unique.<BR>>>>>>>>=20
=3D><BR>>>>>>>> I have to do the =
migration=20
manually by replacing elements of Open=20
<BR>>>>>>>> =
1.x<BR>>>>>>>> by=20
their counterparts in=20
=
2.x.<BR>>>>>>>> <BR>>>>>>>> is=20
it right or I missed something like a smart import that=20
detect<BR>>>>>>>> conflicts and propose to =
update=20
automatically element that exist =
in<BR>>>>>>>> 1.X=20
& 2.X /delete obsolete element of 1.X / etc..=20
=
?<BR>>>>>>>> <BR>>>>>>>> The=20
question is what is the recommended procedure to perform a=20
<BR>>>>>>>> =
plug-in<BR>>>>>>>>=20
upgrade with a minimum effort=20
=
?<BR>>>>>>>> <BR>>>>>>>> My=20
concern will be the maintenance cost of a library. If we build=20
<BR>>>>>>>> =
our<BR>>>>>>>>=20
library from many commercial or non commercial plugins we have =
to=20
<BR>>>>>>>> =
deal<BR>>>>>>>>=20
with their evolutions at a minimal=20
=
cost.<BR>>>>>>>> <BR>>>>>>>> <BR>=
>>>>>>><BR >>>>>>>><BR >>>&=
gt;>>>>=20
Best Regards=20
=
....<BR>>>>>>>> <BR>>>>>>>> PS:=20
I will be in vacation for the next 2 weeks so you have plenty=20
of<BR>>>>>>>> time for an anwser=20
=
;)<BR>>>>>>>> <BR>>>>>>>> <BR>>=
;>>>>>>=20
PS:<BR> >>>>>>>& ;nbsp; We use ClearCase but =
it will=20
not help here except to roll back to =
a<BR>>>>>>>>=20
stable baseline and lock elements for modification=20
...<BR> >>>>>>>& ;nbsp; We are developping our =
process=20
in multi site. As we didn't want =
to<BR>>>>>>>> add=20
more complexity we decided to work only on one site=20
(windows<BR>>>>>>>> terminal server for the =
distant=20
site) with one development branch =
in<BR>>>>>>>>=20
base CC.<BR>>>>>>>> May be you have a =
successfull=20
experience using CC multisite & UCM=20
?<BR>>>>>>>> Can you share your experience=20
?<BR>>>>>>>> Seems that in CC 7 (we use CC =
6) the=20
merge manager have a new option<BR>>>>>>>> =
i.e. to=20
always copy. So may be we can now have branches & multisite=20
<BR>>>>>>>> =
as<BR>>>>>>>> now=20
xmi file can be merged by a copy. I see here a potential source=20
<BR>>>>>>>> =
of<BR>>>>>>>>=20
trouble as we may surely end with invalid references if for=20
instance<BR>>>>>>>> the merge (copy) is =
done=20
partially on some xmi=20
=
....<BR>>>>>>>> <BR>>>>>>>>=20
Peter Haumer wrote:<BR> >>>>>>>& ;gt;=20
Hello.<BR> >>>>>>>& ;gt; You cannot load =
multiple=20
versions of the same plugin into the=20
same<BR> >>>>>>>& ;gt; library. All library =
elements=20
are identified by global unique ids =
<BR> >>>>>>>& ;gt;=20
and<BR> >>>>>>>& ;gt; hence such ids needs to =
be=20
unique. To get more than one copy of=20
an<BR> >>>>>>>& ;gt; element you need to use =
the copy=20
operation in the library view. =
In<BR> >>>>>>>& ;gt;=20
general we recommend to use a version control system like=20
Rational<BR> >>>>>>>& ;gt; ClearCase which =
allows you=20
to label and restore old versions of=20
<BR> >>>>>>>& ;gt;=20
whole<BR> >>>>>>>& ;gt; groups of=20
=
files.<BR> >>>>>>>& ;gt; <BR>>>>>>>>=
;>=20
Best regards,<BR> >>>>>>>& ;gt;=20
=
Peter.<BR> >>>>>>>& ;gt; <BR>>>>>>>>=
;>=20
P.S.: Surely they should not be an exception when loading the=20
same<BR> >>>>>>>& ;gt; content twice, but an =
error=20
message. Please, file
|
|
|
| Re: Migration to newever library version [message #40208 is a reply to message #40123] |
Fri, 07 September 2007 18:07 |
| Eclipse User |
|
|
|
Originally posted by: kamal.osellus.com
This is a multi-part message in MIME format.
------=_NextPart_000_0012_01C7F158.5DEC6CE0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Hi Peter
=20
As you very well know Osellus has made significant contributions to the =
software process community by the over three years work we have done in =
OMG culminating in a comprehensive end-to-end standard submission. There =
are past EPF newsgroup threads on this topic that the community is =
already aware of.
=20
Recently, we are very happy to see interest in this forum on the need =
for enactment of EPF generated processes. This is in line with our long =
established philosophy of treating enactment entities as first class =
citizens and not an afterthought. We are working on solutions that would =
move any content developed using EPF Composer to a collaborative =
development environment of choice for enactment in live projects. The =
first version of this is Content Bridge for VSTS, a tool for moving =
processes from EPF Composer to Microsoft's Visual Studio Team System.=20
=20
I would also point out and hope that the clarifications we are seeking =
and the feedback we are sharing in the forum will be of use to the =
community.=20
=20
I see all of this as significant investment by a company that is a =
fraction of the size of IBM. We have been open to the idea of =
code-contribution but feel that the past concerns we have raised =
relating to requirements, architecture and meta-model coupled with the =
limited development resources prevent us from taking a more active role =
than we already have.
=20
Finally, I hope that it's just my impression and not something you meant =
but I found your tone to have crossed the boundaries of a professional =
inclusive attitude to individuals who are trying to raise awareness on =
outstanding or unclear issues in this newsgroup. I had merely asked if =
IBM was open to sharing the bits it had developed that may go way in =
making EPF more widely adopted. From your answer it is clear that is not =
the case.
=20
Thanks
Kamal
"Peter Haumer" <phaumer@us.ibm.com> wrote in message =
news:fbqood$ijk$1@build.eclipse.org...
Hello Kamal.
I see an increase of interest and lecturing from Osellus in recent =
days here in the forum. Are you guys finally ready to contribute and =
write some code for EPF? ;-)=20
As we clearly said, the feature to loosely combine method plug-ins and =
scale your libraries up to the enterprise level is a Rational Method =
Composer distinguishing feature and for us not in scope of EPF. As =
Ricardo points out EPFC is powerful enough to build any kind of large =
method library. The focus is here on one library at a time. RMC allows =
to scale this up to multiple collocated libraries at the time.=20
This is something we sell, which is in line with the license and =
agenda of Eclipse to provide platforms that can be used to build =
commercial tools on top that can be sold. Osellus only sells and does =
not work in open source and no communities benefit. Hence, I thought =
that especially you guys would understand and not try to push the issue =
on this one.=20
Best regards,
Peter.
"Kamal Ahluwalia" <kamal@osellus.com> wrote in message =
news:fbpr2j$sbm$1@build.eclipse.org...
Thanks for your response Ricardo.
=20
This thread highlights some of the fundamental constraints in using =
EPF Composer, especially library.xml to maintain processes. It appears =
RMC 7.2 addresses some of these problems. Are there any plans to donate =
those bits to EPF so that the community can benefit ?
=20
Kamal=20
"Ricardo Balduino" <balduino@us.ibm.com> wrote in message =
news:fbpnj1$24t$1@build.eclipse.org...
>>> I wanted to clarify if it really is the case that EPF Composer =
is designed to be primarily used to maintain OpenUP only. =20
It is not really the case.
EPF Composer is used by the EPF team to maintain OpenUP, DSDM, =
Scrum, XP and any other processes being captured today and in the future =
under the EPF project.
Moreover, EPF users can capture their own home-grown processes or =
extensions to available processes using EPF Composer.
I hope this clarifies your question.
Regards,
Ricardo Balduino.
"Kamal Ahluwalia" <kamal@osellus.com> wrote in message =
news:fbpmjg$rai$1@build.eclipse.org...
"EPF Composer is designed to support a single project per =
library only as it is primary used to maintain OpenUP".
=20
I wanted to clarify if it really is the case that EPF Composer =
is designed to be primarily used to maintain OpenUP only. =20
=20
Kamal
"Roman Smirak" <roman.smirak@tietoenator.com> wrote in message =
news:f9rjjo$50e$1@build.eclipse.org...
Hi Peter,
that is great, the implementation perfectly matches with my =
vision. Why=20
not to have it in EPF? I guess many users would welcome the =
feature.
We have licences of RMC, however, we prefer to use EPF since =
early releases=20
are available.
Regards,
Roman
"Peter Haumer" <phaumer@us.ibm.com> wrote in message=20
news:f9qa5o$jac$1@build.eclipse.org...
> Hello Roman.
> Well, if our competitors can abuse this forum to plug their =
products; so=20
> can I :-)
>
> RMC 7.2 does not need the library.xmi file anymore as it =
uses the Eclipse=20
> workspace's projects to find all the files. Every plugin is =
a project as=20
> well as you can create more than one project for managing =
configurations=20
> and one project for estimation data (another RMC added =
value). The problem=20
> view is used just as in Eclipse to tell you if you are =
missing elements in=20
> your workspace that other elements depend upon. You could =
ignore those=20
> errors or fix them by loading the project's that contain the =
missing=20
> elements.
>
> See the attached image with an example where I was using =
plugins managed=20
> in CVS and plugins managed in CC all at the same time in the =
same=20
> workspace. Plugins can now reside in complete different =
directories even=20
> on different machine. Just like Eclipse projects, you load =
them into your=20
> workspace and use them whenever you need to use them.
>
> However, RMC can still generate a library.xmi for you to =
manage libraries=20
> that are fully compatible with EPF Composer. For example, if =
you check the=20
> OpenUP CVS repository: it already has project files in each =
plugin=20
> directory. That is because I was already working with =
OpenUP in RMC 7.2;=20
> at the same time where the rest of the team continued =
working with EPF=20
> Composer. Two ways of loading the same library in a fully =
compatible way.
>
> Hope this helps,
> Peter.
>
>
>
> "Roman Smirak" <roman.smirak@tietoenator.com> wrote in =
message=20
> news:f9p6up$mmu$1@build.eclipse.org...
>> Hi Peter,
>>
>> thanks for info, however, RMC is based on EPF and I see =
current=20
>> solution
>> of EPF (library.xml) as a fundamental constraint for clear =
& easy=20
>> solution
>> at RMC level. Or?
>>
>> Can you please describe the scenario with RMC how it will =
be implemented?
>>
>> Or shall I post this at IBM Rational forum?
>>
>> Roman
>>
>> "Peter Haumer" <phaumer@us.ibm.com> wrote in message
>> news:f9o54i$924$1@build.eclipse.org...
>>> 1) no, the guid remains the same
>>> 2) not sure I understand the context of this, but I would =
recommend to
>>> only version manage your own files and if you are using =
cvs directly get
>>> the OpenUP sources from our server or if you use CC =
provide a zip/rar=20
>>> file
>>> with the OpenUP files that users can unzip as view-private =
files
>>> 3) Rational Method Composer 7.2 will fully support this =
scenario, which=20
>>> is
>>> not in scope for EPF Composer. For enterprise deployments =
and full
>>> scalability we recommend RMC in which every plugin can be =
maintained as=20
>>> an
>>> eclipse project and loaded when needed. In addition we =
provide project
>>> types for configurations, enterprise reports, and =
estimation models in
>>> RMC. EPF Composer is designed to support a single project =
per library
>>> only as it is primary used to maintain OpenUP. A =
workaround for you=20
>>> would
>>> be what I described above for (2).
>>>
>>> Best regards,
>>> Peter Haumer.
>>>
>>>
>>> "Roman Smirak" <roman.smirak@tietoenator.com> wrote in =
message
>>> news:f9kcmi$idh$1@build.eclipse.org...
>>>> Hi Ricardo,
>>>>
>>>> the way you described below is the one I've been using =
so far;=20
>>>> however,
>>>> I have few issues here:
>>>> 1/ What if you refactor the content of OpenUP, e.g. an =
element I was
>>>> referencing to is no longer in same package or plugin? Is =
there any
>>>> impact on UID?
>>>>
>>>> 2/ Currently we have the whole library in a versioning =
repository,
>>>> although everyone has got the basis (OpenUP, or RUP) with =
the tool=20
>>>> (EMC,
>>>> or RMC) - no problem for OpenUP, in case of RUP, well we =
are talking
>>>> about 60MB or so (which you have to check in every time =
you migrate)
>>>>
>>>> 3/ Let say we have a common basis in our department X, =
let's call it
>>>> OpenUP/X; there is a project A which will use it plus =
extension A minus
>>>> irrelevant content from basis; in case of eclipse plugins =
they simply
>>>> check out required plugins (they stay in touch with their =
updates by
>>>> department X authority) but they don't check out =
irrelevant plugins (no
>>>> mess) + create their new one and check it in their =
repository (will be
>>>> maintained there); currently they need to check out whole =
library X +
>>>> submit their plugins A into the library shared by others =
(and they do
>>>> same action as well =3D> mess X + A + B + C, etc.) in =
order to fulfil the
>>>> use case (the basis maintained by department, a project =
extension
>>>> maintained by the project itself)
>>>>
>>>> I see the library.xml as a big constraint in this use =
case.
>>>>
>>>> Regards,
>>>>
>>>> Roman
>>>>
>>>> "Ricardo Balduino" <balduino@us.ibm.com> wrote in message
>>>> news:f9itco$87k$1@build.eclipse.org...
>>>>> In first paragraph I meant less cumbersome, yet safer =
;-)
>>>>>
>>>>> "Ricardo Balduino" <balduino@us.ibm.com> wrote in =
message
>>>>> news:f9g8d0$db$1@build.eclipse.org...
>>>>>> Option A sounds less cumbersome and safer, as the EPF =
Composer tool
>>>>>> will take care of the work. In fact, according to your =
description of
>>>>>> option A, OpenUP 2.x would overwrite OpenUP 1.x.
>>>>>>
>>>>>> Instead of playing with importing a new OpenUP plug-in =
into your
>>>>>> existing library, have you considered getting the new =
OpenUP library
>>>>>> available and import your plug-in into it instead? With =
that=20
>>>>>> approach,
>>>>>> you are moving your plug-in around, so you know there =
are no=20
>>>>>> duplicates
>>>>>> of it in a brand new OpenUP library. If your plug-in =
initially=20
>>>>>> depended
>>>>>> on some OpenUP element that does not exist anymore when =
a new version
>>>>>> of OpenUP is released, the import will show you =
warnings, which will
>>>>>> help you to spot where you need to maintain your =
plug-in to extend=20
>>>>>> the
>>>>>> most current version of OpenUP. Additions to OpenUP =
will not affect
>>>>>> your plug-in.
>>>>>>
>>>>>> Cheers,
>>>>>>
>>>>>> Ricardo Balduino.
>>>>>>
>>>>>> "K.Benameur" <benameur@freesurf.fr> wrote in message
>>>>>> news:f9f8cn$ah0$1@build.eclipse.org...
>>>>>>> Hi Peter,
>>>>>>>
>>>>>>> Sorry to bother you with all my questions !!!
>>>>>>>
>>>>>>> I am not sure that I have completly understood your =
answer.
>>>>>>>
>>>>>>> To check this I propose a simple scenario :
>>>>>>> - I develop a library using Open Up 1.x.
>>>>>>> - A new version of Open Up is out let say 2.x
>>>>>>> - I wan't to take advantage of this new Open Up =
version.
>>>>>>>
>>>>>>> A) So ideally, I import the new version in my library =
and Open Up=20
>>>>>>> 1.x
>>>>>>> is updated to 2.x.
>>>>>>>
>>>>>>> I have the feeling that it will not be so simple as =
many links will=20
>>>>>>> be
>>>>>>> broken due to changes between 1.X and 2.X.
>>>>>>>
>>>>>>> B) I use the copy operation to have the 1.X & 2.X =
plugin in my=20
>>>>>>> library
>>>>>>>
>>>>>>> It seems that option B) is the one to go as you said =
that we have to
>>>>>>> do a copy as uuid must be unique.
>>>>>>> =3D>
>>>>>>> I have to do the migration manually by replacing =
elements of Open=20
>>>>>>> 1.x
>>>>>>> by their counterparts in 2.x.
>>>>>>>
>>>>>>> is it right or I missed something like a smart import =
that detect
>>>>>>> conflicts and propose to update automatically element =
that exist in
>>>>>>> 1.X & 2.X /delete obsolete element of 1.X / etc.. ?
>>>>>>>
>>>>>>> The question is what is the recommended procedure to =
perform a=20
>>>>>>> plug-in
>>>>>>> upgrade with a minimum effort ?
>>>>>>>
>>>>>>> My concern will be the maintenance cost of a library. =
If we build=20
>>>>>>> our
>>>>>>> library from many commercial or non commercial plugins =
we have to=20
>>>>>>> deal
>>>>>>> with their evolutions at a minimal cost.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Best Regards ...
>>>>>>>
>>>>>>> PS: I will be in vacation for the next 2 weeks so you =
have plenty of
>>>>>>> time for an anwser ;)
>>>>>>>
>>>>>>>
>>>>>>> PS:
>>>>>>> We use ClearCase but it will not help here except to =
roll back to a
>>>>>>> stable baseline and lock elements for modification ...
>>>>>>> We are developping our process in multi site. As we =
didn't want to
>>>>>>> add more complexity we decided to work only on one =
site (windows
>>>>>>> terminal server for the distant site) with one =
development branch in
>>>>>>> base CC.
>>>>>>> May be you have a successfull experience using CC =
multisite & UCM ?
>>>>>>> Can you share your experience ?
>>>>>>> Seems that in CC 7 (we use CC 6) the merge manager =
have a new option
>>>>>>> i.e. to always copy. So may be we can now have =
branches & multisite=20
>>>>>>> as
>>>>>>> now xmi file can be merged by a copy. I see here a =
potential source=20
>>>>>>> of
>>>>>>> trouble as we may surely end with invalid references =
if for instance
>>>>>>> the merge (copy) is done partially on some xmi ...
>>>>>>>
>>>>>>> Peter Haumer wrote:
>>>>>>>> Hello.
>>>>>>>> You cannot load multiple versions of the same plugin =
into the same
>>>>>>>> library. All library elements are identified by =
global unique ids=20
>>>>>>>> and
>>>>>>>> hence such ids needs to be unique. To get more than =
one copy of an
>>>>>>>> element you need to use the copy operation in the =
library view. In
>>>>>>>> general we recommend to use a version control system =
like Rational
>>>>>>>> ClearCase which allows you to label and restore old =
versions of=20
>>>>>>>> whole
>>>>>>>> groups of files.
>>>>>>>>
>>>>>>>> Best regards,
>>>>>>>> Peter.
>>>>>>>>
>>>>>>>> P.S.: Surely they should not be an exception when =
loading the same
>>>>>>>> content twice, but an error message. Please, file a =
bugzilla with
>>>>>>>> reproducible steps.
>>>>>>>>
>>>>>>>>
>>>>>>>> "K.Benameur" <benameur@freesurf.fr> wrote in message
>>>>>>>> news:f973f4$goo$1@build.eclipse.org...
>>>>>>>>> Hi all,
>>>>>>>>>
>>>>>>>>> It is a very good question. May be it can be =
addressed by an=20
>>>>>>>>> update
>>>>>>>>> of an existing guideline as the Development =
Guideline ?
>>>>>>>>>
>>>>>>>>> I think that we should have a "recommended" =
procedure from the EPF
>>>>>>>>> team to update plug-ins to a new version.
>>>>>>>>> It is now a fairly common scenario that multiple =
versions of the
>>>>>>>>> same plug-ins are out.
>>>>>>>>>
>>>>>>>>> And it is not only related to Open Up but for any =
library /=20
>>>>>>>>> plug-in
>>>>>>>>> as part of the development process (we are =
developing our own
>>>>>>>>> library / plug-ins without Open Up).
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> In short, what is the recommended procedure to =
migrate to a new
>>>>>>>>> version ? Do we have to export / import ? What are =
the risks? What
>>>>>>>>> we may lose ?
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Best Regards
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>
>=20
------=_NextPart_000_0012_01C7F158.5DEC6CE0
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML xmlns:o =3D "urn:schemas-microsoft-com:office:office"><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.6000.16527" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>
<P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Arial','sans-serif'">Hi=20
Peter<o:p></o:p></SPAN></P>
<P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
'Arial','sans-serif'"><o:p> </o:p></SPAN></P>
<P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Arial','sans-serif'">As you very =
well know=20
Osellus has made significant contributions to the software process =
community by=20
the over three years work we have done in OMG culminating in a =
comprehensive=20
end-to-end standard submission. There are past EPF newsgroup threads on =
this=20
topic that the community is already aware of.<o:p></o:p></SPAN></P>
<P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
'Arial','sans-serif'"><o:p> </o:p></SPAN></P>
<P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Arial','sans-serif'">Recently, =
we are very=20
happy to see interest in this forum on the need for enactment of EPF =
generated=20
processes. This is in line with our long established philosophy of =
treating enactment entities as first class citizens and not an =
afterthought. We=20
are working on solutions that would move any content developed using EPF =
Composer to a collaborative development environment of choice for =
enactment in=20
live projects. The first version of this is <A=20
href=3D" http://www.osellus.com/products/contentbridge/contentbridge_ for_v=
sts.html"><SPAN=20
style=3D"FONT-SIZE: 11pt; COLOR: windowtext; FONT-FAMILY: =
'Calibri','sans-serif'; TEXT-DECORATION: none; text-underline: =
none">Content=20
Bridge for VSTS</SPAN></A>, a tool for moving processes from EPF=20
Composer to Microsoft=92s <A=20
href=3D"http://msdn2.microsoft.com/en-us/teamsystem/default.aspx"><SPAN=20
style=3D"FONT-SIZE: 11pt; COLOR: windowtext; FONT-FAMILY: =
'Calibri','sans-serif'; TEXT-DECORATION: none; text-underline: =
none">Visual=20
Studio Team System</SPAN></A>. <o:p></o:p></SPAN></P>
<P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
'Arial','sans-serif'"><o:p> </o:p></SPAN></P>
<P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Arial','sans-serif'">I would =
also point=20
out and hope that the clarifications we are seeking and the feedback we =
are=20
sharing in the forum will be of use to the community. =
<o:p></o:p></SPAN></P>
<P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
'Arial','sans-serif'"><o:p> </o:p></SPAN></P>
<P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Arial','sans-serif'">I see all =
of this as=20
significant investment by a company that is a fraction of the size of =
IBM. We=20
have been open to the idea of code-contribution but feel that the past =
concerns=20
we have raised relating to requirements, architecture and meta-model =
coupled=20
with the limited development resources prevent us from taking a =
more active=20
role than we already have.<o:p></o:p></SPAN></P>
<P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
'Arial','sans-serif'"><o:p> </o:p></SPAN></P>
<P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Arial','sans-serif'">Finally, I =
hope that=20
it=92s just my impression and not something you meant but I found your =
tone to=20
have crossed the boundaries of a professional inclusive attitude to =
individuals=20
who are trying to raise awareness on outstanding or unclear issues in =
this=20
newsgroup. I had merely asked if IBM was open to sharing the bits it had =
developed that may go way in making EPF more widely adopted. From your =
answer it=20
is clear that is not the case.<o:p></o:p></SPAN></P>
<P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
'Arial','sans-serif'"><o:p> </o:p></SPAN></P>
<P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
'Arial','sans-serif'">Thanks<o:p></o:p></SPAN></P>
<P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
'Arial','sans-serif'">Kamal<o:p></o:p></SPAN></P></FONT ></DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
<DIV>"Peter Haumer" <<A=20
href=3D"mailto:phaumer@us.ibm.com">phaumer@us.ibm.com</A>> wrote in =
message=20
<A=20
=
href=3D"news:fbqood$ijk$1@build.eclipse.org">news:fbqood$ijk$1@build.ecli=
pse.org</A>...</DIV>
<DIV><FONT face=3DArial size=3D2>Hello Kamal.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>I see an increase of interest and =
lecturing from=20
Osellus in recent days here in the forum. Are you guys finally =
ready to=20
contribute and write some code for EPF? ;-) </FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>As we clearly said, the feature to =
loosely=20
combine method plug-ins and scale your libraries up to the enterprise =
level is=20
a Rational Method Composer distinguishing feature and for us not in =
scope of=20
EPF. As Ricardo points out EPFC is powerful enough to build any =
kind of=20
large method library. The focus is here on one library at a =
time. =20
RMC allows to scale this up to multiple collocated libraries at the =
time.=20
</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>This is something we sell,=20
which </FONT><FONT face=3DArial size=3D2>is in line with =
the license and=20
agenda of Eclipse to provide platforms that can be used to build =
commercial=20
tools on top that can be sold. Osellus only sells and does not work in =
open=20
source and no communities benefit. Hence, I thought that especially =
you guys=20
would understand and not try to push the issue on this one. =
</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>Best regards,</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Peter.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
<DIV>"Kamal Ahluwalia" <<A=20
href=3D"mailto:kamal@osellus.com">kamal@osellus.com</A>> wrote in =
message=20
<A=20
=
href=3D"news:fbpr2j$sbm$1@build.eclipse.org">news:fbpr2j$sbm$1@build.ecli=
pse.org</A>...</DIV>
<DIV><FONT face=3DArial size=3D2>
<P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><SPAN=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New =
Roman','serif'">Thanks for=20
your response Ricardo.<o:p></o:p></SPAN></P>
<P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><SPAN=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New =
Roman','serif'"><o:p> </o:p></SPAN></P>
<P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><SPAN=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New =
Roman','serif'">This thread=20
highlights some of the fundamental constraints in using EPF =
Composer,=20
especially library.xml to maintain processes. It appears RMC 7.2 =
addresses=20
some of these problems. Are there any plans to donate those bits to =
EPF so=20
that the community can benefit ?<o:p></o:p></SPAN></P>
<P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><SPAN=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New =
Roman','serif'"><o:p> </o:p></SPAN></P>
<P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><SPAN=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New =
Roman','serif'">Kamal=20
<o:p></o:p></SPAN></P></FONT></DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
<DIV>"Ricardo Balduino" <<A=20
href=3D"mailto:balduino@us.ibm.com">balduino@us.ibm.com</A>> =
wrote in=20
message <A=20
=
href=3D"news:fbpnj1$24t$1@build.eclipse.org">news:fbpnj1$24t$1@build.ecli=
pse.org</A>...</DIV>
<DIV><FONT face=3DArial size=3D2>>>> <FONT size=3D3><FONT =
face=3D"Times New Roman">I wanted to clarify =
if it really is the=20
case that EPF Composer is designed to be primarily used to =
maintain OpenUP=20
only. </FONT></FONT></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><FONT size=3D3><FONT=20
face=3D"Times New Roman"></FONT></FONT></FONT> </DIV>
<DIV><FONT size=3D+0><FONT size=3D+0><FONT face=3DArial><FONT =
size=3D2>It is not=20
really the case.</FONT></FONT></FONT></FONT></DIV>
<DIV><FONT size=3D+0><FONT size=3D+0><FONT face=3DArial><FONT=20
size=3D2></FONT></FONT></FONT></FONT> </DIV>
<DIV><FONT size=3D+0><FONT size=3D+0><FONT face=3DArial><FONT =
size=3D2>EPF=20
Composer is used by the EPF team to maintain OpenUP, DSDM, Scrum, =
XP and=20
any other processes being captured today and in the future under =
the EPF=20
project.</FONT></FONT></FONT></FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>Moreover, EPF users can capture =
their own=20
home-grown processes or extensions to available processes using =
EPF=20
Composer.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>I hope this clarifies your=20
question.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>Regards,</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>Ricardo Balduino.</FONT></DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
<DIV>"Kamal Ahluwalia" <<A=20
href=3D"mailto:kamal@osellus.com">kamal@osellus.com</A>> =
wrote in=20
message <A=20
=
href=3D"news:fbpmjg$rai$1@build.eclipse.org">news:fbpmjg$rai$1@build.ecli=
pse.org</A>...</DIV>
<DIV><FONT face=3DArial size=3D2>
<P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><FONT =
size=3D3><FONT=20
face=3D"Times New Roman">=93EPF Composer is designed to support =
a single=20
project per library only as it is primary used to maintain=20
OpenUP=94.<o:p></o:p></FONT></FONT></P>
<P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><o:p><FONT=20
face=3D"Times New Roman" size=3D3> </FONT></o:p></P>
<P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><FONT =
size=3D3><FONT=20
face=3D"Times New Roman">I wanted to clarify =
if it really is the=20
case that EPF Composer is designed to be primarily used to =
maintain=20
OpenUP only. <o:p></o:p></FONT></FONT></P>
<P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><o:p><FONT=20
face=3D"Times New Roman" size=3D3> </FONT></o:p></P>
<P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><FONT =
size=3D3><FONT=20
face=3D"Times New =
Roman">Kamal<o:p></o:p></FONT></FONT></P></FONT></DIV >
<BLOCKQUOTE=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: =
5px; BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
<DIV>"Roman Smirak" <<A=20
=
href=3D"mailto:roman.smirak@tietoenator.com">roman.smirak@tietoenator.com=
</A>>=20
wrote in message <A=20
=
href=3D"news:f9rjjo$50e$1@build.eclipse.org">news:f9rjjo$50e$1@build.ecli=
pse.org</A>...</DIV>Hi=20
Peter,<BR><BR> that is great, the implementation =
perfectly=20
matches with my vision. Why <BR>not to have it in EPF? I guess =
many=20
users would welcome the feature.<BR><BR>We have licences of =
RMC,=20
however, we prefer to use EPF since early releases <BR>are=20
available.<BR><BR>Regards,<BR><BR>Roman<BR><BR>"Peter Haumer" =
<<A=20
href=3D"mailto:phaumer@us.ibm.com">phaumer@us.ibm.com</A>> =
wrote in=20
message <BR><A=20
=
href=3D"news:f9qa5o$jac$1@build.eclipse.org">news:f9qa5o$jac$1@build.ecli=
pse.org</A>...<BR>>=20
Hello Roman.<BR>> Well, if our competitors can abuse this =
forum to=20
plug their products; so <BR>> can I :-)<BR>><BR>> RMC =
7.2=20
does not need the library.xmi file anymore as it uses the =
Eclipse=20
<BR>> workspace's projects to find all the files. Every =
plugin is a=20
project as <BR>> well as you can create more than one =
project for=20
managing configurations <BR>> and one project for =
estimation data=20
(another RMC added value). The problem <BR>> view is used =
just as=20
in Eclipse to tell you if you are missing elements in <BR>> =
your=20
workspace that other elements depend upon. You could =
ignore=20
those <BR>> errors or fix them by loading the project's =
that=20
contain the missing <BR>> elements.<BR>><BR>> See the =
attached image with an example where I was using plugins =
managed=20
<BR>> in CVS and plugins managed in CC all at the same time =
in the=20
same <BR>> workspace. Plugins can now reside in complete =
different=20
directories even <BR>> on different machine. Just =
like=20
Eclipse projects, you load them into your <BR>> workspace =
and use=20
them whenever you need to use them.<BR>><BR>> However, =
RMC can=20
still generate a library.xmi for you to manage libraries =
<BR>> that=20
are fully compatible with EPF Composer. For example, if you =
check the=20
<BR>> OpenUP CVS repository: it already has project files =
in each=20
plugin <BR>> directory. That is because I was already =
working=20
with OpenUP in RMC 7.2; <BR>> at the same time where the =
rest of=20
the team continued working with EPF <BR>> Composer. =
Two ways=20
of loading the same library in a fully compatible =
way.<BR>><BR>>=20
Hope this helps,<BR>> =
Peter.<BR>><BR>><BR>><BR>> "Roman=20
Smirak" <<A=20
=
href=3D"mailto:roman.smirak@tietoenator.com">roman.smirak@tietoenator.com=
</A>>=20
wrote in message <BR>> <A=20
=
href=3D"news:f9p6up$mmu$1@build.eclipse.org">news:f9p6up$mmu$1@build.ecli=
pse.org</A>...<BR>>>=20
Hi Peter,<BR>>><BR>>> thanks for info, =
however, RMC is based on EPF and I see current <BR>>>=20
solution<BR>>> of EPF (library.xml) as a fundamental =
constraint=20
for clear & easy <BR>>> solution<BR>>> at RMC =
level.=20
Or?<BR>>><BR>>> Can you please describe the =
scenario with=20
RMC how it will be implemented?<BR>>><BR>>> Or =
shall I=20
post this at IBM Rational forum?<BR>>><BR>>>=20
Roman<BR>>><BR>>> "Peter Haumer" <<A=20
href=3D"mailto:phaumer@us.ibm.com">phaumer@us.ibm.com</A>> =
wrote in=20
message<BR>>> <A=20
=
href=3D"news:f9o54i$924$1@build.eclipse.org">news:f9o54i$924$1@build.ecli=
pse.org</A>...<BR>>>>=20
1) no, the guid remains the same<BR>>>> 2) not sure I =
understand the context of this, but I would recommend=20
to<BR>>>> only version manage your own files and if =
you are=20
using cvs directly get<BR>>>> the OpenUP sources from =
our=20
server or if you use CC provide a zip/rar <BR>>>>=20
file<BR>>>> with the OpenUP files that users can =
unzip as=20
view-private files<BR>>>> 3) Rational Method Composer =
7.2=20
will fully support this scenario, which <BR>>>>=20
is<BR>>>> not in scope for EPF Composer. For =
enterprise=20
deployments and full<BR>>>> scalability we recommend =
RMC in=20
which every plugin can be maintained as <BR>>>>=20
an<BR>>>> eclipse project and loaded when needed. In =
addition=20
we provide project<BR>>>> types for configurations,=20
enterprise reports, and estimation models in<BR>>>>=20
RMC. EPF Composer is designed to support a single =
project per=20
library<BR>>>> only as it is primary used to maintain =
OpenUP. A workaround for you <BR>>>>=20
would<BR>>>> be what I described above for=20
(2).<BR>>>><BR>>>> Best =
regards,<BR>>>>=20
Peter Haumer.<BR>>>><BR>>>> <BR>>>> =
"Roman=20
Smirak" <<A=20
=
href=3D"mailto:roman.smirak@tietoenator.com">roman.smirak@tietoenator.com=
</A>>=20
wrote in message<BR>>>> <A=20
=
href=3D"news:f9kcmi$idh$1@build.eclipse.org">news:f9kcmi$idh$1@build.ecli=
pse.org</A>...<BR>>>>>=20
Hi =
Ricardo,<BR>>>>><BR>>>>> the=20
way you described below is the one I've been using so far;=20
<BR>>>>> however,<BR>>>>> I have few =
issues=20
here:<BR>>>>> 1/ What if you refactor the content =
of=20
OpenUP, e.g. an element I was<BR>>>>> referencing =
to is no=20
longer in same package or plugin? Is there =
any<BR>>>>>=20
impact on UID?<BR>>>>><BR>>>>> 2/ =
Currently we=20
have the whole library in a versioning =
repository,<BR>>>>>=20
although everyone has got the basis (OpenUP, or RUP) with the =
tool=20
<BR>>>>> (EMC,<BR>>>>> or RMC) - no =
problem=20
for OpenUP, in case of RUP, well we are =
talking<BR>>>>>=20
about 60MB or so (which you have to check in every time you=20
migrate)<BR>>>>><BR>>>>> 3/ Let say we =
have a=20
common basis in our department X, let's call =
it<BR>>>>>=20
OpenUP/X; there is a project A which will use it plus =
extension A=20
minus<BR>>>>> irrelevant content from basis; in =
case of=20
eclipse plugins they simply<BR>>>>> check out =
required=20
plugins (they stay in touch with their updates =
by<BR>>>>>=20
department X authority) but they don't check out irrelevant =
plugins=20
(no<BR>>>>> mess) + create their new one and check =
it in=20
their repository (will be<BR>>>>> maintained =
there);=20
currently they need to check out whole library X =
+<BR>>>>>=20
submit their plugins A into the library shared by others (and =
they=20
do<BR>>>>> same action as well =3D> mess X + A =
+ B + C,=20
etc.) in order to fulfil the<BR>>>>> use case (the =
basis=20
maintained by department, a project =
extension<BR>>>>>=20
maintained by the project=20
itself)<BR>>>>><BR>>>>> I see the =
library.xml=20
as a big constraint in this use=20
case.<BR>>>>><BR>>>>>=20
Regards,<BR>>>>><BR>>>>>=20
Roman<BR>>>>><BR>>>>> "Ricardo =
Balduino"=20
<<A =
href=3D"mailto:balduino@us.ibm.com">balduino@us.ibm.com</A>>=20
wrote in message<BR>>>>> <A=20
=
href=3D"news:f9itco$87k$1@build.eclipse.org">news:f9itco$87k$1@build.ecli=
pse.org</A>...<BR>>>>>>=20
In first paragraph I meant less cumbersome, yet safer=20
;-)<BR>>>>>><BR>>>>>> "Ricardo =
Balduino"=20
<<A =
href=3D"mailto:balduino@us.ibm.com">balduino@us.ibm.com</A>>=20
wrote in message<BR>>>>>> <A=20
=
href=3D"news:f9g8d0$db$1@build.eclipse.org">news:f9g8d0$db$1@build.eclips=
e.org</A>...<BR>>>>>>>=20
Option A sounds less cumbersome and safer, as the EPF Composer =
tool<BR>>>>>>> will take care of the work. =
In fact,=20
according to your description of<BR>>>>>>> =
option A,=20
OpenUP 2.x would overwrite OpenUP=20
1.x.<BR>>>>>>><BR >>>>>>> =
Instead=20
of playing with importing a new OpenUP plug-in into=20
your<BR>>>>>>> existing library, have you =
considered=20
getting the new OpenUP library<BR>>>>>>> =
available=20
and import your plug-in into it instead? With that=20
<BR>>>>>>> =
approach,<BR>>>>>>> you=20
are moving your plug-in around, so you know there are no=20
<BR>>>>>>> =
duplicates<BR>>>>>>> of=20
it in a brand new OpenUP library. If your plug-in initially=20
<BR>>>>>>> =
depended<BR>>>>>>> on=20
some OpenUP element that does not exist anymore when a new=20
version<BR>>>>>>> of OpenUP is released, the =
import=20
will show you warnings, which will<BR>>>>>>> =
help=20
you to spot where you need to maintain your plug-in to extend=20
<BR>>>>>>> the<BR>>>>>>> =
most=20
current version of OpenUP. Additions to OpenUP will not=20
affect<BR>>>>>>> your=20
=
plug-in.<BR>>>>>>> <BR>>>>>>>=20
=
Cheers,<BR>>>>>>> <BR>>>>>>>=20
Ricardo=20
=
Balduino.<BR>>>>>>> <BR>>>>>>>=20
"K.Benameur" <<A=20
=
href=3D"mailto:benameur@freesurf.fr">benameur@freesurf.fr</A>> wrote=20
in message<BR>>>>>>> <A=20
=
href=3D"news:f9f8cn$ah0$1@build.eclipse.org">news:f9f8cn$ah0$1@build
|
|
|
| Re: Migration to newever library version [message #40290 is a reply to message #40208] |
Sun, 09 September 2007 04:27 |
AJ 
Messages: 77
Registered: July 2009 |
Member |
|
|
Hi Kamal,
I 100% agree with your comments, in particular the one about peter.
However, keep in mind that he does not speak for IBM or the EPF project
team.
Regarding the process enactment, it is clear that the UMA meta-model gives
software development a knowledge of structure. A structure for experts to
document how software development and related activities are conducted.
Thus the content in EPF grows, it becomes a huge knowledge base. However,
this also means that for practitioners, the wealth of such knowledge
becomes hard to absorb.
So, it will be fantastic to have efforts to make EPF enactable. For
instance, a way to execute the content in EPF and do the following:
1. Guide the practitioner in applying EPF processes.
2. Update the models for the practitioner.
3. Check what the practitioner does.
4. Able to execute an active process description from EPF passive set of
web pages.
For the later, which I presonally rather call it "Dynamic Process", we
need to investigate a way to specify and build an execution engine for the
EPF core model. For instance, the Actions Semantics (an extension to the
UML), to describe the behavior of actions; or the workflow formalism
defined in the OMG Workflow Management Facility.
Also, notice that defining in a consistent manner both the definition and
execution meta-models may also lead to many benefits in process
management. In the WfMC reference model the design of a workflow and its
execution are separate activities. Weaving these two aspects may allow
roundtrips between them. Therefore, changes in the definition may impact
the under way executions. This could even allow the process definition to
be built as the executions go along. So, executions may also alter the
process definition.
Cheers,
-AJ
|
|
|
| Re: Migration to newever library version [message #581008 is a reply to message #36070] |
Fri, 03 August 2007 15:40 |
J. Fincher
Messages: 14
Registered: July 2009 |
Junior Member |
|
|
Hello,
I have a similar question.
I've been working with OpenUP 0.9 to customize it for our use. I created a
separate library, created a plugin for our use, and imported the OpenUp 0.9
plugins for reference. I would like to do the same with OpenUP 1.0.
However, when I try to import the OpenUp 1.0 plugin, the import function is
"seeing" the new plugin as being the same as the existing plug in. The two
plugins have both been renamed from within EPFC.
I've tried locating information on the import/export function in the help
system and online to see if I'm doing something wrong, but I haven't yet
found anything that addresses this.
Any help would be greatly appreciated.
Thanks,
Jan Fincher, Business Applications Analyst
Florida Div. of Rehab & Liq
jan.fincher@fldfs.com
"Roman Smirak" <roman.smirak@tietoenator.com> wrote in message
news:f87j6j$3v7$1@build.eclipse.org...
> Hi,
>
> I have just downloaded latest version of OpenUP library and tried to
> migrate my plugin to this.
>
> My plugin has been developed on OpenUP 0.9 distributed with Composer 1.2
> M3 (I guess - can I check it somewhere? Plugin.xml, etc.)
>
> I started EPF with OpenUP 1.0-RC3-20070720 and imported my plugin; and it
> didn't work - workspace/.metadata/.log shows:
> java.lang.NullPointerException
> at
> org.eclipse.epf.authoring.ui.forms.ConfigurationPage.updateC heckStates(Unknown
> Source)
> at org.eclipse.epf.authoring.ui.forms.ConfigurationPage.setInpu t(Unknown
> Source)
> at
> org.eclipse.epf.authoring.ui.forms.ConfigurationPage.createF ormContent(Unknown
> Source)
> at org.eclipse.ui.forms.editor.FormPage$1.run(FormPage.java:151 )
> at org.eclipse.swt.custom.BusyIndicator.showWhile(BusyIndicator .java:67)
> at
> org.eclipse.ui.forms.editor.FormPage.createPartControl(FormP age.java:149)
> at org.eclipse.ui.forms.editor.FormEditor.pageChange(FormEditor .java:484)
> at
> org.eclipse.epf.authoring.ui.editors.MethodElementEditor.pag eChange(Unknown
> Source)
> at
> org.eclipse.ui.part.MultiPageEditorPart$2.widgetSelected(Mul tiPageEditorPart.java:239)
> at
> org.eclipse.swt.widgets.TypedListener.handleEvent(TypedListe ner.java:227)
> at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java :66)
> at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:938)
> at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:962)
> at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:947)
> at org.eclipse.swt.widgets.Widget.notifyListeners(Widget.java:7 06)
> at org.eclipse.swt.custom.CTabFolder.setSelection(CTabFolder.ja va:3206)
> at org.eclipse.swt.custom.CTabFolder.onMouse(CTabFolder.java:19 88)
> at org.eclipse.swt.custom.CTabFolder$1.handleEvent(CTabFolder.j ava:308)
> at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java :66)
> at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:938)
> at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.ja va:3673)
> at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java :3284)
> at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.jav a:2337)
> at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:2301)
> at org.eclipse.ui.internal.Workbench.access$4(Workbench.java:21 76)
> at org.eclipse.ui.internal.Workbench$4.run(Workbench.java:463)
> at
> org.eclipse.core.databinding.observable.Realm.runWithDefault (Realm.java:289)
> at
> org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Work bench.java:458)
> at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.j ava:149)
> at org.eclipse.epf.rcp.ui.MainApplication.createWorkbenchAdviso r(Unknown
> Source)
> at org.eclipse.epf.rcp.ui.MainApplication.start(Unknown Source)
> at
> org.eclipse.equinox.internal.app.EclipseAppHandle.run(Eclips eAppHandle.java:146)
> at
> org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher .runApplication(EclipseAppLauncher.java:106)
> at
> org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher .start(EclipseAppLauncher.java:76)
> at
> org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseS tarter.java:356)
> at
> org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseS tarter.java:171)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
> at java.lang.reflect.Method.invoke(Unknown Source)
> at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java: 476)
> at org.eclipse.equinox.launcher.Main.basicRun(Main.java:416)
> at org.eclipse.equinox.launcher.Main.run(Main.java:1141)
>
> However, next time it worked (I just deleted workspace, copied library and
> imported my plugin again) and so I cannot reproduce it. I'm putting it
> here just FYI.
>
> Now I see couple of errors telling me:
> Severity and Description Path Resource Location Creation Time Id
> Could not resolve proxy
> 'uma://_0TLvwMlgEdmt3adZL5Dmdw#_h15dULCxEdujaOuld2kPdg'
> OpenUP/configurations OpenUP_TS.xmi
> C:\workbench\workspaces\workspace-epf2\OpenUP\configurations \OpenUP_TS.xmi
> 1185369789419 17
> Could not resolve proxy
> 'uma://_0TLvwMlgEdmt3adZL5Dmdw#_XIwYQPTYEduDKIuqTXQ8SA'
> OpenUP/configurations OpenUP_TS.xmi
> C:\workbench\workspaces\workspace-epf2\OpenUP\configurations \OpenUP_TS.xmi
> 1185369789520 18
> Could not resolve proxy
> 'uma://_WCUhAO8KEdmKSqa_gSYthg#_AejKAMadEduMlb2cQZNTYw'
> OpenUP/configurations OpenUP_TS.xmi
> C:\workbench\workspaces\workspace-epf2\OpenUP\configurations \OpenUP_TS.xmi
> 1185369789209 16
>
> Does it mean that my plugin contributes to some elements which have
> changed or don't exist anymore?
>
> Question: what are your suggestions/recommended practices for the
> migration?
>
> Roman
>
>
|
|
|
| Re: Migration to newever library version [message #581028 is a reply to message #36425] |
Fri, 03 August 2007 16:11 |
J. Fincher
Messages: 14
Registered: July 2009 |
Junior Member |
|
|
I've done more poking around and it looks like the issue may be that the two
plugins have the same id even though they are named differently?
If that's the issue, how can I get them to have different IDs?
(Please forgive me if this is a stupid question - I am not a programmer and
am doing pretty well to get this far on my own).
Thanks again,
Jan Fincher, Business Applications Analyst
Florida Div. of Rehab & Liq
jan.fincher@fldfs.com
"Jan Fincher" <myjunk68@yahoo.com> wrote in message
news:f8vi92$lab$1@build.eclipse.org...
> Hello,
>
> I have a similar question.
>
> I've been working with OpenUP 0.9 to customize it for our use. I created
> a
> separate library, created a plugin for our use, and imported the OpenUp
> 0.9
> plugins for reference. I would like to do the same with OpenUP 1.0.
>
> However, when I try to import the OpenUp 1.0 plugin, the import function
> is
> "seeing" the new plugin as being the same as the existing plug in. The
> two
> plugins have both been renamed from within EPFC.
>
> I've tried locating information on the import/export function in the help
> system and online to see if I'm doing something wrong, but I haven't yet
> found anything that addresses this.
>
> Any help would be greatly appreciated.
>
> Thanks,
>
> Jan Fincher, Business Applications Analyst
> Florida Div. of Rehab & Liq
> jan.fincher@fldfs.com
>
> "Roman Smirak" <roman.smirak@tietoenator.com> wrote in message
> news:f87j6j$3v7$1@build.eclipse.org...
>> Hi,
>>
>> I have just downloaded latest version of OpenUP library and tried to
>> migrate my plugin to this.
>>
>> My plugin has been developed on OpenUP 0.9 distributed with Composer 1.2
>> M3 (I guess - can I check it somewhere? Plugin.xml, etc.)
>>
>> I started EPF with OpenUP 1.0-RC3-20070720 and imported my plugin; and it
>> didn't work - workspace/.metadata/.log shows:
>> java.lang.NullPointerException
>> at
>> org.eclipse.epf.authoring.ui.forms.ConfigurationPage.updateC heckStates(Unknown
>> Source)
>> at org.eclipse.epf.authoring.ui.forms.ConfigurationPage.setInpu t(Unknown
>> Source)
>> at
>> org.eclipse.epf.authoring.ui.forms.ConfigurationPage.createF ormContent(Unknown
>> Source)
>> at org.eclipse.ui.forms.editor.FormPage$1.run(FormPage.java:151 )
>> at org.eclipse.swt.custom.BusyIndicator.showWhile(BusyIndicator .java:67)
>> at
>> org.eclipse.ui.forms.editor.FormPage.createPartControl(FormP age.java:149)
>> at org.eclipse.ui.forms.editor.FormEditor.pageChange(FormEditor .java:484)
>> at
>> org.eclipse.epf.authoring.ui.editors.MethodElementEditor.pag eChange(Unknown
>> Source)
>> at
>> org.eclipse.ui.part.MultiPageEditorPart$2.widgetSelected(Mul tiPageEditorPart.java:239)
>> at
>> org.eclipse.swt.widgets.TypedListener.handleEvent(TypedListe ner.java:227)
>> at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java :66)
>> at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:938)
>> at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:962)
>> at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:947)
>> at org.eclipse.swt.widgets.Widget.notifyListeners(Widget.java:7 06)
>> at org.eclipse.swt.custom.CTabFolder.setSelection(CTabFolder.ja va:3206)
>> at org.eclipse.swt.custom.CTabFolder.onMouse(CTabFolder.java:19 88)
>> at org.eclipse.swt.custom.CTabFolder$1.handleEvent(CTabFolder.j ava:308)
>> at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java :66)
>> at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:938)
>> at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.ja va:3673)
>> at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java :3284)
>> at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.jav a:2337)
>> at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:2301)
>> at org.eclipse.ui.internal.Workbench.access$4(Workbench.java:21 76)
>> at org.eclipse.ui.internal.Workbench$4.run(Workbench.java:463)
>> at
>> org.eclipse.core.databinding.observable.Realm.runWithDefault (Realm.java:289)
>> at
>> org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Work bench.java:458)
>> at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.j ava:149)
>> at org.eclipse.epf.rcp.ui.MainApplication.createWorkbenchAdviso r(Unknown
>> Source)
>> at org.eclipse.epf.rcp.ui.MainApplication.start(Unknown Source)
>> at
>> org.eclipse.equinox.internal.app.EclipseAppHandle.run(Eclips eAppHandle.java:146)
>> at
>> org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher .runApplication(EclipseAppLauncher.java:106)
>> at
>> org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher .start(EclipseAppLauncher.java:76)
>> at
>> org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseS tarter.java:356)
>> at
>> org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseS tarter.java:171)
>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>> at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
>> at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
>> at java.lang.reflect.Method.invoke(Unknown Source)
>> at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java: 476)
>> at org.eclipse.equinox.launcher.Main.basicRun(Main.java:416)
>> at org.eclipse.equinox.launcher.Main.run(Main.java:1141)
>>
>> However, next time it worked (I just deleted workspace, copied library
>> and
>> imported my plugin again) and so I cannot reproduce it. I'm putting it
>> here just FYI.
>>
>> Now I see couple of errors telling me:
>> Severity and Description Path Resource Location Creation Time Id
>> Could not resolve proxy
>> 'uma://_0TLvwMlgEdmt3adZL5Dmdw#_h15dULCxEdujaOuld2kPdg'
>> OpenUP/configurations OpenUP_TS.xmi
>> C:\workbench\workspaces\workspace-epf2\OpenUP\configurations \OpenUP_TS.xmi
>> 1185369789419 17
>> Could not resolve proxy
>> 'uma://_0TLvwMlgEdmt3adZL5Dmdw#_XIwYQPTYEduDKIuqTXQ8SA'
>> OpenUP/configurations OpenUP_TS.xmi
>> C:\workbench\workspaces\workspace-epf2\OpenUP\configurations \OpenUP_TS.xmi
>> 1185369789520 18
>> Could not resolve proxy
>> 'uma://_WCUhAO8KEdmKSqa_gSYthg#_AejKAMadEduMlb2cQZNTYw'
>> OpenUP/configurations OpenUP_TS.xmi
>> C:\workbench\workspaces\workspace-epf2\OpenUP\configurations \OpenUP_TS.xmi
>> 1185369789209 16
>>
>> Does it mean that my plugin contributes to some elements which have
>> changed or don't exist anymore?
>>
>> Question: what are your suggestions/recommended practices for the
>> migration?
>>
>> Roman
>>
>>
>
>
>
>
|
|
| | | |
| Re: Migration to newever library version [message #581474 is a reply to message #37233] |
Thu, 09 August 2007 23:35 |
Ricardo Balduino
Messages: 191
Registered: July 2009 |
Senior Member |
|
|
Option A sounds less cumbersome and safer, as the EPF Composer tool will
take care of the work. In fact, according to your description of option A,
OpenUP 2.x would overwrite OpenUP 1.x.
Instead of playing with importing a new OpenUP plug-in into your existing
library, have you considered getting the new OpenUP library available and
import your plug-in into it instead? With that approach, you are moving your
plug-in around, so you know there are no duplicates of it in a brand new
OpenUP library. If your plug-in initially depended on some OpenUP element
that does not exist anymore when a new version of OpenUP is released, the
import will show you warnings, which will help you to spot where you need to
maintain your plug-in to extend the most current version of OpenUP.
Additions to OpenUP will not affect your plug-in.
Cheers,
Ricardo Balduino.
"K.Benameur" <benameur@freesurf.fr> wrote in message
news:f9f8cn$ah0$1@build.eclipse.org...
> Hi Peter,
>
> Sorry to bother you with all my questions !!!
>
> I am not sure that I have completly understood your answer.
>
> To check this I propose a simple scenario :
> - I develop a library using Open Up 1.x.
> - A new version of Open Up is out let say 2.x
> - I wan't to take advantage of this new Open Up version.
>
> A) So ideally, I import the new version in my library and Open Up 1.x is
> updated to 2.x.
>
> I have the feeling that it will not be so simple as many links will be
> broken due to changes between 1.X and 2.X.
>
> B) I use the copy operation to have the 1.X & 2.X plugin in my library
>
> It seems that option B) is the one to go as you said that we have to do a
> copy as uuid must be unique.
> =>
> I have to do the migration manually by replacing elements of Open 1.x by
> their counterparts in 2.x.
>
> is it right or I missed something like a smart import that detect
> conflicts and propose to update automatically element that exist in 1.X &
> 2.X /delete obsolete element of 1.X / etc.. ?
>
> The question is what is the recommended procedure to perform a plug-in
> upgrade with a minimum effort ?
>
> My concern will be the maintenance cost of a library. If we build our
> library from many commercial or non commercial plugins we have to deal
> with their evolutions at a minimal cost.
>
>
>
>
> Best Regards ...
>
> PS: I will be in vacation for the next 2 weeks so you have plenty of time
> for an anwser ;)
>
>
> PS:
> We use ClearCase but it will not help here except to roll back to a
> stable baseline and lock elements for modification ...
> We are developping our process in multi site. As we didn't want to add
> more complexity we decided to work only on one site (windows terminal
> server for the distant site) with one development branch in base CC.
> May be you have a successfull experience using CC multisite & UCM ? Can
> you share your experience ?
> Seems that in CC 7 (we use CC 6) the merge manager have a new option i.e.
> to always copy. So may be we can now have branches & multisite as now xmi
> file can be merged by a copy. I see here a potential source of trouble as
> we may surely end with invalid references if for instance the merge (copy)
> is done partially on some xmi ...
>
> Peter Haumer wrote:
>> Hello.
>> You cannot load multiple versions of the same plugin into the same
>> library. All library elements are identified by global unique ids and
>> hence such ids needs to be unique. To get more than one copy of an
>> element you need to use the copy operation in the library view. In
>> general we recommend to use a version control system like Rational
>> ClearCase which allows you to label and restore old versions of whole
>> groups of files.
>>
>> Best regards,
>> Peter.
>>
>> P.S.: Surely they should not be an exception when loading the same
>> content twice, but an error message. Please, file a bugzilla with
>> reproducible steps.
>>
>>
>> "K.Benameur" <benameur@freesurf.fr> wrote in message
>> news:f973f4$goo$1@build.eclipse.org...
>>> Hi all,
>>>
>>> It is a very good question. May be it can be addressed by an update of
>>> an existing guideline as the Development Guideline ?
>>>
>>> I think that we should have a "recommended" procedure from the EPF team
>>> to update plug-ins to a new version.
>>> It is now a fairly common scenario that multiple versions of the same
>>> plug-ins are out.
>>>
>>> And it is not only related to Open Up but for any library / plug-in as
>>> part of the development process (we are developing our own library /
>>> plug-ins without Open Up).
>>>
>>>
>>> In short, what is the recommended procedure to migrate to a new version
>>> ? Do we have to export / import ? What are the risks? What we may lose ?
>>>
>>>
>>> Best Regards
>>>
>>>
>>
|
|
|
| Re: Migration to newever library version [message #581494 is a reply to message #37301] |
Fri, 10 August 2007 23:46 |
Ricardo Balduino
Messages: 191
Registered: July 2009 |
Senior Member |
|
|
In first paragraph I meant less cumbersome, yet safer ;-)
"Ricardo Balduino" <balduino@us.ibm.com> wrote in message
news:f9g8d0$db$1@build.eclipse.org...
> Option A sounds less cumbersome and safer, as the EPF Composer tool will
> take care of the work. In fact, according to your description of option A,
> OpenUP 2.x would overwrite OpenUP 1.x.
>
> Instead of playing with importing a new OpenUP plug-in into your existing
> library, have you considered getting the new OpenUP library available and
> import your plug-in into it instead? With that approach, you are moving
> your plug-in around, so you know there are no duplicates of it in a brand
> new OpenUP library. If your plug-in initially depended on some OpenUP
> element that does not exist anymore when a new version of OpenUP is
> released, the import will show you warnings, which will help you to spot
> where you need to maintain your plug-in to extend the most current version
> of OpenUP. Additions to OpenUP will not affect your plug-in.
>
> Cheers,
>
> Ricardo Balduino.
>
> "K.Benameur" <benameur@freesurf.fr> wrote in message
> news:f9f8cn$ah0$1@build.eclipse.org...
>> Hi Peter,
>>
>> Sorry to bother you with all my questions !!!
>>
>> I am not sure that I have completly understood your answer.
>>
>> To check this I propose a simple scenario :
>> - I develop a library using Open Up 1.x.
>> - A new version of Open Up is out let say 2.x
>> - I wan't to take advantage of this new Open Up version.
>>
>> A) So ideally, I import the new version in my library and Open Up 1.x is
>> updated to 2.x.
>>
>> I have the feeling that it will not be so simple as many links will be
>> broken due to changes between 1.X and 2.X.
>>
>> B) I use the copy operation to have the 1.X & 2.X plugin in my library
>>
>> It seems that option B) is the one to go as you said that we have to do a
>> copy as uuid must be unique.
>> =>
>> I have to do the migration manually by replacing elements of Open 1.x by
>> their counterparts in 2.x.
>>
>> is it right or I missed something like a smart import that detect
>> conflicts and propose to update automatically element that exist in 1.X &
>> 2.X /delete obsolete element of 1.X / etc.. ?
>>
>> The question is what is the recommended procedure to perform a plug-in
>> upgrade with a minimum effort ?
>>
>> My concern will be the maintenance cost of a library. If we build our
>> library from many commercial or non commercial plugins we have to deal
>> with their evolutions at a minimal cost.
>>
>>
>>
>>
>> Best Regards ...
>>
>> PS: I will be in vacation for the next 2 weeks so you have plenty of time
>> for an anwser ;)
>>
>>
>> PS:
>> We use ClearCase but it will not help here except to roll back to a
>> stable baseline and lock elements for modification ...
>> We are developping our process in multi site. As we didn't want to add
>> more complexity we decided to work only on one site (windows terminal
>> server for the distant site) with one development branch in base CC.
>> May be you have a successfull experience using CC multisite & UCM ? Can
>> you share your experience ?
>> Seems that in CC 7 (we use CC 6) the merge manager have a new option i.e.
>> to always copy. So may be we can now have branches & multisite as now xmi
>> file can be merged by a copy. I see here a potential source of trouble as
>> we may surely end with invalid references if for instance the merge
>> (copy) is done partially on some xmi ...
>>
>> Peter Haumer wrote:
>>> Hello.
>>> You cannot load multiple versions of the same plugin into the same
>>> library. All library elements are identified by global unique ids and
>>> hence such ids needs to be unique. To get more than one copy of an
>>> element you need to use the copy operation in the library view. In
>>> general we recommend to use a version control system like Rational
>>> ClearCase which allows you to label and restore old versions of whole
>>> groups of files.
>>>
>>> Best regards,
>>> Peter.
>>>
>>> P.S.: Surely they should not be an exception when loading the same
>>> content twice, but an error message. Please, file a bugzilla with
>>> reproducible steps.
>>>
>>>
>>> "K.Benameur" <benameur@freesurf.fr> wrote in message
>>> news:f973f4$goo$1@build.eclipse.org...
>>>> Hi all,
>>>>
>>>> It is a very good question. May be it can be addressed by an update of
>>>> an existing guideline as the Development Guideline ?
>>>>
>>>> I think that we should have a "recommended" procedure from the EPF team
>>>> to update plug-ins to a new version.
>>>> It is now a fairly common scenario that multiple versions of the same
>>>> plug-ins are out.
>>>>
>>>> And it is not only related to Open Up but for any library / plug-in as
>>>> part of the development process (we are developing our own library /
>>>> plug-ins without Open Up).
>>>>
>>>>
>>>> In short, what is the recommended procedure to migrate to a new
>>>> version ? Do we have to export / import ? What are the risks? What we
>>>> may lose ?
>>>>
>>>>
>>>> Best Regards
>>>>
>>>>
>>>
>
|
|
|
| Re: Migration to newever library version [message #581505 is a reply to message #37369] |
Sat, 11 August 2007 13:13 |
Roman Smirak
Messages: 136
Registered: July 2009 |
Senior Member |
|
|
Hi Ricardo,
the way you described below is the one I've been using so far; however, I
have few issues here:
1/ What if you refactor the content of OpenUP, e.g. an element I was
referencing to is no longer in same package or plugin? Is there any impact
on UID?
2/ Currently we have the whole library in a versioning repository, although
everyone has got the basis (OpenUP, or RUP) with the tool (EMC, or RMC) - no
problem for OpenUP, in case of RUP, well we are talking about 60MB or so
(which you have to check in every time you migrate)
3/ Let say we have a common basis in our department X, let's call it
OpenUP/X; there is a project A which will use it plus extension A minus
irrelevant content from basis; in case of eclipse plugins they simply check
out required plugins (they stay in touch with their updates by department X
authority) but they don't check out irrelevant plugins (no mess) + create
their new one and check it in their repository (will be maintained there);
currently they need to check out whole library X + submit their plugins A
into the library shared by others (and they do same action as well => mess X
+ A + B + C, etc.) in order to fulfil the use case (the basis maintained by
department, a project extension maintained by the project itself)
I see the library.xml as a big constraint in this use case.
Regards,
Roman
"Ricardo Balduino" <balduino@us.ibm.com> wrote in message
news:f9itco$87k$1@build.eclipse.org...
> In first paragraph I meant less cumbersome, yet safer ;-)
>
> "Ricardo Balduino" <balduino@us.ibm.com> wrote in message
> news:f9g8d0$db$1@build.eclipse.org...
>> Option A sounds less cumbersome and safer, as the EPF Composer tool will
>> take care of the work. In fact, according to your description of option
>> A, OpenUP 2.x would overwrite OpenUP 1.x.
>>
>> Instead of playing with importing a new OpenUP plug-in into your existing
>> library, have you considered getting the new OpenUP library available and
>> import your plug-in into it instead? With that approach, you are moving
>> your plug-in around, so you know there are no duplicates of it in a brand
>> new OpenUP library. If your plug-in initially depended on some OpenUP
>> element that does not exist anymore when a new version of OpenUP is
>> released, the import will show you warnings, which will help you to spot
>> where you need to maintain your plug-in to extend the most current
>> version of OpenUP. Additions to OpenUP will not affect your plug-in.
>>
>> Cheers,
>>
>> Ricardo Balduino.
>>
>> "K.Benameur" <benameur@freesurf.fr> wrote in message
>> news:f9f8cn$ah0$1@build.eclipse.org...
>>> Hi Peter,
>>>
>>> Sorry to bother you with all my questions !!!
>>>
>>> I am not sure that I have completly understood your answer.
>>>
>>> To check this I propose a simple scenario :
>>> - I develop a library using Open Up 1.x.
>>> - A new version of Open Up is out let say 2.x
>>> - I wan't to take advantage of this new Open Up version.
>>>
>>> A) So ideally, I import the new version in my library and Open Up 1.x is
>>> updated to 2.x.
>>>
>>> I have the feeling that it will not be so simple as many links will be
>>> broken due to changes between 1.X and 2.X.
>>>
>>> B) I use the copy operation to have the 1.X & 2.X plugin in my library
>>>
>>> It seems that option B) is the one to go as you said that we have to do
>>> a copy as uuid must be unique.
>>> =>
>>> I have to do the migration manually by replacing elements of Open 1.x
>>> by their counterparts in 2.x.
>>>
>>> is it right or I missed something like a smart import that detect
>>> conflicts and propose to update automatically element that exist in 1.X
>>> & 2.X /delete obsolete element of 1.X / etc.. ?
>>>
>>> The question is what is the recommended procedure to perform a plug-in
>>> upgrade with a minimum effort ?
>>>
>>> My concern will be the maintenance cost of a library. If we build our
>>> library from many commercial or non commercial plugins we have to deal
>>> with their evolutions at a minimal cost.
>>>
>>>
>>>
>>>
>>> Best Regards ...
>>>
>>> PS: I will be in vacation for the next 2 weeks so you have plenty of
>>> time for an anwser ;)
>>>
>>>
>>> PS:
>>> We use ClearCase but it will not help here except to roll back to a
>>> stable baseline and lock elements for modification ...
>>> We are developping our process in multi site. As we didn't want to add
>>> more complexity we decided to work only on one site (windows terminal
>>> server for the distant site) with one development branch in base CC.
>>> May be you have a successfull experience using CC multisite & UCM ? Can
>>> you share your experience ?
>>> Seems that in CC 7 (we use CC 6) the merge manager have a new option
>>> i.e. to always copy. So may be we can now have branches & multisite as
>>> now xmi file can be merged by a copy. I see here a potential source of
>>> trouble as we may surely end with invalid references if for instance the
>>> merge (copy) is done partially on some xmi ...
>>>
>>> Peter Haumer wrote:
>>>> Hello.
>>>> You cannot load multiple versions of the same plugin into the same
>>>> library. All library elements are identified by global unique ids and
>>>> hence such ids needs to be unique. To get more than one copy of an
>>>> element you need to use the copy operation in the library view. In
>>>> general we recommend to use a version control system like Rational
>>>> ClearCase which allows you to label and restore old versions of whole
>>>> groups of files.
>>>>
>>>> Best regards,
>>>> Peter.
>>>>
>>>> P.S.: Surely they should not be an exception when loading the same
>>>> content twice, but an error message. Please, file a bugzilla with
>>>> reproducible steps.
>>>>
>>>>
>>>> "K.Benameur" <benameur@freesurf.fr> wrote in message
>>>> news:f973f4$goo$1@build.eclipse.org...
>>>>> Hi all,
>>>>>
>>>>> It is a very good question. May be it can be addressed by an update of
>>>>> an existing guideline as the Development Guideline ?
>>>>>
>>>>> I think that we should have a "recommended" procedure from the EPF
>>>>> team to update plug-ins to a new version.
>>>>> It is now a fairly common scenario that multiple versions of the same
>>>>> plug-ins are out.
>>>>>
>>>>> And it is not only related to Open Up but for any library / plug-in as
>>>>> part of the development process (we are developing our own library /
>>>>> plug-ins without Open Up).
>>>>>
>>>>>
>>>>> In short, what is the recommended procedure to migrate to a new
>>>>> version ? Do we have to export / import ? What are the risks? What we
>>>>> may lose ?
>>>>>
>>>>>
>>>>> Best Regards
>>>>>
>>>>>
>>>>
>>
>
>
|
|
|
| Re: Migration to newever library version [message #581588 is a reply to message #37233] |
Sun, 12 August 2007 23:21 |
Peter Haumer
Messages: 228
Registered: July 2009 |
Senior Member |
|
|
Hello K.
We do not support B, which is in fact the more complicated one as all plugin
element can have outgoing as well as incoming relationships. Because of
several issues related to this we currently do not support a copy-paste
operation of plugins. You can only copy-paste individual elements. Our
relationships system is based on global unique identifiers (guids) to fully
support A. All html hyperplinks that have a guid attribute are automatically
recomputed based on that guid for refactoring operations; e.g. elements move
packages or even plugins. Elements will never change guids when you move
them around; unless you delete an element and create a new one with the same
name you should be save from release to release unless the OpenUP team
introduces all new elements.
As we do not have compare-merge editors, yet, we only support base ClearCase
so far.
Best regards,
Peter.
"K.Benameur" <benameur@freesurf.fr> wrote in message
news:f9f8cn$ah0$1@build.eclipse.org...
> Hi Peter,
>
> Sorry to bother you with all my questions !!!
>
> I am not sure that I have completly understood your answer.
>
> To check this I propose a simple scenario :
> - I develop a library using Open Up 1.x.
> - A new version of Open Up is out let say 2.x
> - I wan't to take advantage of this new Open Up version.
>
> A) So ideally, I import the new version in my library and Open Up 1.x is
> updated to 2.x.
>
> I have the feeling that it will not be so simple as many links will be
> broken due to changes between 1.X and 2.X.
>
> B) I use the copy operation to have the 1.X & 2.X plugin in my library
>
> It seems that option B) is the one to go as you said that we have to do a
> copy as uuid must be unique.
> =>
> I have to do the migration manually by replacing elements of Open 1.x by
> their counterparts in 2.x.
>
> is it right or I missed something like a smart import that detect
> conflicts and propose to update automatically element that exist in 1.X &
> 2.X /delete obsolete element of 1.X / etc.. ?
>
> The question is what is the recommended procedure to perform a plug-in
> upgrade with a minimum effort ?
>
> My concern will be the maintenance cost of a library. If we build our
> library from many commercial or non commercial plugins we have to deal
> with their evolutions at a minimal cost.
>
>
>
>
> Best Regards ...
>
> PS: I will be in vacation for the next 2 weeks so you have plenty of time
> for an anwser ;)
>
>
> PS:
> We use ClearCase but it will not help here except to roll back to a
> stable baseline and lock elements for modification ...
> We are developping our process in multi site. As we didn't want to add
> more complexity we decided to work only on one site (windows terminal
> server for the distant site) with one development branch in base CC.
> May be you have a successfull experience using CC multisite & UCM ? Can
> you share your experience ?
> Seems that in CC 7 (we use CC 6) the merge manager have a new option i.e.
> to always copy. So may be we can now have branches & multisite as now xmi
> file can be merged by a copy. I see here a potential source of trouble as
> we may surely end with invalid references if for instance the merge (copy)
> is done partially on some xmi ...
>
> Peter Haumer wrote:
>> Hello.
>> You cannot load multiple versions of the same plugin into the same
>> library. All library elements are identified by global unique ids and
>> hence such ids needs to be unique. To get more than one copy of an
>> element you need to use the copy operation in the library view. In
>> general we recommend to use a version control system like Rational
>> ClearCase which allows you to label and restore old versions of whole
>> groups of files.
>>
>> Best regards,
>> Peter.
>>
>> P.S.: Surely they should not be an exception when loading the same
>> content twice, but an error message. Please, file a bugzilla with
>> reproducible steps.
>>
>>
>> "K.Benameur" <benameur@freesurf.fr> wrote in message
>> news:f973f4$goo$1@build.eclipse.org...
>>> Hi all,
>>>
>>> It is a very good question. May be it can be addressed by an update of
>>> an existing guideline as the Development Guideline ?
>>>
>>> I think that we should have a "recommended" procedure from the EPF team
>>> to update plug-ins to a new version.
>>> It is now a fairly common scenario that multiple versions of the same
>>> plug-ins are out.
>>>
>>> And it is not only related to Open Up but for any library / plug-in as
>>> part of the development process (we are developing our own library /
>>> plug-ins without Open Up).
>>>
>>>
>>> In short, what is the recommended procedure to migrate to a new version
>>> ? Do we have to export / import ? What are the risks? What we may lose ?
>>>
>>>
>>> Best Regards
>>>
>>>
>>
|
|
|
| Re: Migration to newever library version [message #581604 is a reply to message #37403] |
Sun, 12 August 2007 23:29 |
Peter Haumer
Messages: 228
Registered: July 2009 |
Senior Member |
|
|
1) no, the guid remains the same
2) not sure I understand the context of this, but I would recommend to only
version manage your own files and if you are using cvs directly get the
OpenUP sources from our server or if you use CC provide a zip/rar file with
the OpenUP files that users can unzip as view-private files
3) Rational Method Composer 7.2 will fully support this scenario, which is
not in scope for EPF Composer. For enterprise deployments and full
scalability we recommend RMC in which every plugin can be maintained as an
eclipse project and loaded when needed. In addition we provide project types
for configurations, enterprise reports, and estimation models in RMC. EPF
Composer is designed to support a single project per library only as it is
primary used to maintain OpenUP. A workaround for you would be what I
described above for (2).
Best regards,
Peter Haumer.
"Roman Smirak" <roman.smirak@tietoenator.com> wrote in message
news:f9kcmi$idh$1@build.eclipse.org...
> Hi Ricardo,
>
> the way you described below is the one I've been using so far; however,
> I have few issues here:
> 1/ What if you refactor the content of OpenUP, e.g. an element I was
> referencing to is no longer in same package or plugin? Is there any impact
> on UID?
>
> 2/ Currently we have the whole library in a versioning repository,
> although everyone has got the basis (OpenUP, or RUP) with the tool (EMC,
> or RMC) - no problem for OpenUP, in case of RUP, well we are talking about
> 60MB or so (which you have to check in every time you migrate)
>
> 3/ Let say we have a common basis in our department X, let's call it
> OpenUP/X; there is a project A which will use it plus extension A minus
> irrelevant content from basis; in case of eclipse plugins they simply
> check out required plugins (they stay in touch with their updates by
> department X authority) but they don't check out irrelevant plugins (no
> mess) + create their new one and check it in their repository (will be
> maintained there); currently they need to check out whole library X +
> submit their plugins A into the library shared by others (and they do same
> action as well => mess X + A + B + C, etc.) in order to fulfil the use
> case (the basis maintained by department, a project extension maintained
> by the project itself)
>
> I see the library.xml as a big constraint in this use case.
>
> Regards,
>
> Roman
>
> "Ricardo Balduino" <balduino@us.ibm.com> wrote in message
> news:f9itco$87k$1@build.eclipse.org...
>> In first paragraph I meant less cumbersome, yet safer ;-)
>>
>> "Ricardo Balduino" <balduino@us.ibm.com> wrote in message
>> news:f9g8d0$db$1@build.eclipse.org...
>>> Option A sounds less cumbersome and safer, as the EPF Composer tool will
>>> take care of the work. In fact, according to your description of option
>>> A, OpenUP 2.x would overwrite OpenUP 1.x.
>>>
>>> Instead of playing with importing a new OpenUP plug-in into your
>>> existing library, have you considered getting the new OpenUP library
>>> available and import your plug-in into it instead? With that approach,
>>> you are moving your plug-in around, so you know there are no duplicates
>>> of it in a brand new OpenUP library. If your plug-in initially depended
>>> on some OpenUP element that does not exist anymore when a new version of
>>> OpenUP is released, the import will show you warnings, which will help
>>> you to spot where you need to maintain your plug-in to extend the most
>>> current version of OpenUP. Additions to OpenUP will not affect your
>>> plug-in.
>>>
>>> Cheers,
>>>
>>> Ricardo Balduino.
>>>
>>> "K.Benameur" <benameur@freesurf.fr> wrote in message
>>> news:f9f8cn$ah0$1@build.eclipse.org...
>>>> Hi Peter,
>>>>
>>>> Sorry to bother you with all my questions !!!
>>>>
>>>> I am not sure that I have completly understood your answer.
>>>>
>>>> To check this I propose a simple scenario :
>>>> - I develop a library using Open Up 1.x.
>>>> - A new version of Open Up is out let say 2.x
>>>> - I wan't to take advantage of this new Open Up version.
>>>>
>>>> A) So ideally, I import the new version in my library and Open Up 1.x
>>>> is updated to 2.x.
>>>>
>>>> I have the feeling that it will not be so simple as many links will be
>>>> broken due to changes between 1.X and 2.X.
>>>>
>>>> B) I use the copy operation to have the 1.X & 2.X plugin in my library
>>>>
>>>> It seems that option B) is the one to go as you said that we have to do
>>>> a copy as uuid must be unique.
>>>> =>
>>>> I have to do the migration manually by replacing elements of Open 1.x
>>>> by their counterparts in 2.x.
>>>>
>>>> is it right or I missed something like a smart import that detect
>>>> conflicts and propose to update automatically element that exist in 1.X
>>>> & 2.X /delete obsolete element of 1.X / etc.. ?
>>>>
>>>> The question is what is the recommended procedure to perform a plug-in
>>>> upgrade with a minimum effort ?
>>>>
>>>> My concern will be the maintenance cost of a library. If we build our
>>>> library from many commercial or non commercial plugins we have to deal
>>>> with their evolutions at a minimal cost.
>>>>
>>>>
>>>>
>>>>
>>>> Best Regards ...
>>>>
>>>> PS: I will be in vacation for the next 2 weeks so you have plenty of
>>>> time for an anwser ;)
>>>>
>>>>
>>>> PS:
>>>> We use ClearCase but it will not help here except to roll back to a
>>>> stable baseline and lock elements for modification ...
>>>> We are developping our process in multi site. As we didn't want to add
>>>> more complexity we decided to work only on one site (windows terminal
>>>> server for the distant site) with one development branch in base CC.
>>>> May be you have a successfull experience using CC multisite & UCM ? Can
>>>> you share your experience ?
>>>> Seems that in CC 7 (we use CC 6) the merge manager have a new option
>>>> i.e. to always copy. So may be we can now have branches & multisite as
>>>> now xmi file can be merged by a copy. I see here a potential source of
>>>> trouble as we may surely end with invalid references if for instance
>>>> the merge (copy) is done partially on some xmi ...
>>>>
>>>> Peter Haumer wrote:
>>>>> Hello.
>>>>> You cannot load multiple versions of the same plugin into the same
>>>>> library. All library elements are identified by global unique ids and
>>>>> hence such ids needs to be unique. To get more than one copy of an
>>>>> element you need to use the copy operation in the library view. In
>>>>> general we recommend to use a version control system like Rational
>>>>> ClearCase which allows you to label and restore old versions of whole
>>>>> groups of files.
>>>>>
>>>>> Best regards,
>>>>> Peter.
>>>>>
>>>>> P.S.: Surely they should not be an exception when loading the same
>>>>> content twice, but an error message. Please, file a bugzilla with
>>>>> reproducible steps.
>>>>>
>>>>>
>>>>> "K.Benameur" <benameur@freesurf.fr> wrote in message
>>>>> news:f973f4$goo$1@build.eclipse.org...
>>>>>> Hi all,
>>>>>>
>>>>>> It is a very good question. May be it can be addressed by an update
>>>>>> of an existing guideline as the Development Guideline ?
>>>>>>
>>>>>> I think that we should have a "recommended" procedure from the EPF
>>>>>> team to update plug-ins to a new version.
>>>>>> It is now a fairly common scenario that multiple versions of the
>>>>>> same plug-ins are out.
>>>>>>
>>>>>> And it is not only related to Open Up but for any library / plug-in
>>>>>> as part of the development process (we are developing our own library
>>>>>> / plug-ins without Open Up).
>>>>>>
>>>>>>
>>>>>> In short, what is the recommended procedure to migrate to a new
>>>>>> version ? Do we have to export / import ? What are the risks? What we
>>>>>> may lose ?
>>>>>>
>>>>>>
>>>>>> Best Regards
>>>>>>
>>>>>>
>>>>>
>>>
>>
>>
>
>
|
|
|
| Re: Migration to newever library version [message #581667 is a reply to message #37599] |
Mon, 13 August 2007 09:06 |
Roman Smirak
Messages: 136
Registered: July 2009 |
Senior Member |
|
|
Hi Peter,
thanks for info, however, RMC is based on EPF and I see current solution
of EPF (library.xml) as a fundamental constraint for clear & easy solution
at RMC level. Or?
Can you please describe the scenario with RMC how it will be implemented?
Or shall I post this at IBM Rational forum?
Roman
"Peter Haumer" <phaumer@us.ibm.com> wrote in message
news:f9o54i$924$1@build.eclipse.org...
> 1) no, the guid remains the same
> 2) not sure I understand the context of this, but I would recommend to
> only version manage your own files and if you are using cvs directly get
> the OpenUP sources from our server or if you use CC provide a zip/rar file
> with the OpenUP files that users can unzip as view-private files
> 3) Rational Method Composer 7.2 will fully support this scenario, which is
> not in scope for EPF Composer. For enterprise deployments and full
> scalability we recommend RMC in which every plugin can be maintained as an
> eclipse project and loaded when needed. In addition we provide project
> types for configurations, enterprise reports, and estimation models in
> RMC. EPF Composer is designed to support a single project per library
> only as it is primary used to maintain OpenUP. A workaround for you would
> be what I described above for (2).
>
> Best regards,
> Peter Haumer.
>
>
> "Roman Smirak" <roman.smirak@tietoenator.com> wrote in message
> news:f9kcmi$idh$1@build.eclipse.org...
>> Hi Ricardo,
>>
>> the way you described below is the one I've been using so far; however,
>> I have few issues here:
>> 1/ What if you refactor the content of OpenUP, e.g. an element I was
>> referencing to is no longer in same package or plugin? Is there any
>> impact on UID?
>>
>> 2/ Currently we have the whole library in a versioning repository,
>> although everyone has got the basis (OpenUP, or RUP) with the tool (EMC,
>> or RMC) - no problem for OpenUP, in case of RUP, well we are talking
>> about 60MB or so (which you have to check in every time you migrate)
>>
>> 3/ Let say we have a common basis in our department X, let's call it
>> OpenUP/X; there is a project A which will use it plus extension A minus
>> irrelevant content from basis; in case of eclipse plugins they simply
>> check out required plugins (they stay in touch with their updates by
>> department X authority) but they don't check out irrelevant plugins (no
>> mess) + create their new one and check it in their repository (will be
>> maintained there); currently they need to check out whole library X +
>> submit their plugins A into the library shared by others (and they do
>> same action as well => mess X + A + B + C, etc.) in order to fulfil the
>> use case (the basis maintained by department, a project extension
>> maintained by the project itself)
>>
>> I see the library.xml as a big constraint in this use case.
>>
>> Regards,
>>
>> Roman
>>
>> "Ricardo Balduino" <balduino@us.ibm.com> wrote in message
>> news:f9itco$87k$1@build.eclipse.org...
>>> In first paragraph I meant less cumbersome, yet safer ;-)
>>>
>>> "Ricardo Balduino" <balduino@us.ibm.com> wrote in message
>>> news:f9g8d0$db$1@build.eclipse.org...
>>>> Option A sounds less cumbersome and safer, as the EPF Composer tool
>>>> will take care of the work. In fact, according to your description of
>>>> option A, OpenUP 2.x would overwrite OpenUP 1.x.
>>>>
>>>> Instead of playing with importing a new OpenUP plug-in into your
>>>> existing library, have you considered getting the new OpenUP library
>>>> available and import your plug-in into it instead? With that approach,
>>>> you are moving your plug-in around, so you know there are no duplicates
>>>> of it in a brand new OpenUP library. If your plug-in initially depended
>>>> on some OpenUP element that does not exist anymore when a new version
>>>> of OpenUP is released, the import will show you warnings, which will
>>>> help you to spot where you need to maintain your plug-in to extend the
>>>> most current version of OpenUP. Additions to OpenUP will not affect
>>>> your plug-in.
>>>>
>>>> Cheers,
>>>>
>>>> Ricardo Balduino.
>>>>
>>>> "K.Benameur" <benameur@freesurf.fr> wrote in message
>>>> news:f9f8cn$ah0$1@build.eclipse.org...
>>>>> Hi Peter,
>>>>>
>>>>> Sorry to bother you with all my questions !!!
>>>>>
>>>>> I am not sure that I have completly understood your answer.
>>>>>
>>>>> To check this I propose a simple scenario :
>>>>> - I develop a library using Open Up 1.x.
>>>>> - A new version of Open Up is out let say 2.x
>>>>> - I wan't to take advantage of this new Open Up version.
>>>>>
>>>>> A) So ideally, I import the new version in my library and Open Up 1.x
>>>>> is updated to 2.x.
>>>>>
>>>>> I have the feeling that it will not be so simple as many links will be
>>>>> broken due to changes between 1.X and 2.X.
>>>>>
>>>>> B) I use the copy operation to have the 1.X & 2.X plugin in my library
>>>>>
>>>>> It seems that option B) is the one to go as you said that we have to
>>>>> do a copy as uuid must be unique.
>>>>> =>
>>>>> I have to do the migration manually by replacing elements of Open 1.x
>>>>> by their counterparts in 2.x.
>>>>>
>>>>> is it right or I missed something like a smart import that detect
>>>>> conflicts and propose to update automatically element that exist in
>>>>> 1.X & 2.X /delete obsolete element of 1.X / etc.. ?
>>>>>
>>>>> The question is what is the recommended procedure to perform a plug-in
>>>>> upgrade with a minimum effort ?
>>>>>
>>>>> My concern will be the maintenance cost of a library. If we build our
>>>>> library from many commercial or non commercial plugins we have to deal
>>>>> with their evolutions at a minimal cost.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Best Regards ...
>>>>>
>>>>> PS: I will be in vacation for the next 2 weeks so you have plenty of
>>>>> time for an anwser ;)
>>>>>
>>>>>
>>>>> PS:
>>>>> We use ClearCase but it will not help here except to roll back to a
>>>>> stable baseline and lock elements for modification ...
>>>>> We are developping our process in multi site. As we didn't want to
>>>>> add more complexity we decided to work only on one site (windows
>>>>> terminal server for the distant site) with one development branch in
>>>>> base CC.
>>>>> May be you have a successfull experience using CC multisite & UCM ?
>>>>> Can you share your experience ?
>>>>> Seems that in CC 7 (we use CC 6) the merge manager have a new option
>>>>> i.e. to always copy. So may be we can now have branches & multisite as
>>>>> now xmi file can be merged by a copy. I see here a potential source of
>>>>> trouble as we may surely end with invalid references if for instance
>>>>> the merge (copy) is done partially on some xmi ...
>>>>>
>>>>> Peter Haumer wrote:
>>>>>> Hello.
>>>>>> You cannot load multiple versions of the same plugin into the same
>>>>>> library. All library elements are identified by global unique ids and
>>>>>> hence such ids needs to be unique. To get more than one copy of an
>>>>>> element you need to use the copy operation in the library view. In
>>>>>> general we recommend to use a version control system like Rational
>>>>>> ClearCase which allows you to label and restore old versions of whole
>>>>>> groups of files.
>>>>>>
>>>>>> Best regards,
>>>>>> Peter.
>>>>>>
>>>>>> P.S.: Surely they should not be an exception when loading the same
>>>>>> content twice, but an error message. Please, file a bugzilla with
>>>>>> reproducible steps.
>>>>>>
>>>>>>
>>>>>> "K.Benameur" <benameur@freesurf.fr> wrote in message
>>>>>> news:f973f4$goo$1@build.eclipse.org...
>>>>>>> Hi all,
>>>>>>>
>>>>>>> It is a very good question. May be it can be addressed by an update
>>>>>>> of an existing guideline as the Development Guideline ?
>>>>>>>
>>>>>>> I think that we should have a "recommended" procedure from the EPF
>>>>>>> team to update plug-ins to a new version.
>>>>>>> It is now a fairly common scenario that multiple versions of the
>>>>>>> same plug-ins are out.
>>>>>>>
>>>>>>> And it is not only related to Open Up but for any library / plug-in
>>>>>>> as part of the development process (we are developing our own
>>>>>>> library / plug-ins without Open Up).
>>>>>>>
>>>>>>>
>>>>>>> In short, what is the recommended procedure to migrate to a new
>>>>>>> version ? Do we have to export / import ? What are the risks? What
>>>>>>> we may lose ?
>>>>>>>
>>>>>>>
>>>>>>> Best Regards
>>>>>>>
>>>>>>>
>>>>>>
>>>>
>>>
>>>
>>
>>
>
>
|
|
|
| Re: Migration to newever library version [message #581734 is a reply to message #37691] |
Mon, 13 August 2007 19:07 |
Peter Haumer
Messages: 228
Registered: July 2009 |
Senior Member |
|
|
Hello Roman.
Well, if our competitors can abuse this forum to plug their products; so can
I :-)
RMC 7.2 does not need the library.xmi file anymore as it uses the Eclipse
workspace's projects to find all the files. Every plugin is a project as
well as you can create more than one project for managing configurations and
one project for estimation data (another RMC added value). The problem view
is used just as in Eclipse to tell you if you are missing elements in your
workspace that other elements depend upon. You could ignore those errors or
fix them by loading the project's that contain the missing elements.
See the attached image with an example where I was using plugins managed in
CVS and plugins managed in CC all at the same time in the same workspace.
Plugins can now reside in complete different directories even on different
machine. Just like Eclipse projects, you load them into your workspace and
use them whenever you need to use them.
However, RMC can still generate a library.xmi for you to manage libraries
that are fully compatible with EPF Composer. For example, if you check the
OpenUP CVS repository: it already has project files in each plugin
directory. That is because I was already working with OpenUP in RMC 7.2; at
the same time where the rest of the team continued working with EPF
Composer. Two ways of loading the same library in a fully compatible way.
Hope this helps,
Peter.
"Roman Smirak" <roman.smirak@tietoenator.com> wrote in message
news:f9p6up$mmu$1@build.eclipse.org...
> Hi Peter,
>
> thanks for info, however, RMC is based on EPF and I see current solution
> of EPF (library.xml) as a fundamental constraint for clear & easy solution
> at RMC level. Or?
>
> Can you please describe the scenario with RMC how it will be implemented?
>
> Or shall I post this at IBM Rational forum?
>
> Roman
>
> "Peter Haumer" <phaumer@us.ibm.com> wrote in message
> news:f9o54i$924$1@build.eclipse.org...
>> 1) no, the guid remains the same
>> 2) not sure I understand the context of this, but I would recommend to
>> only version manage your own files and if you are using cvs directly get
>> the OpenUP sources from our server or if you use CC provide a zip/rar
>> file
>> with the OpenUP files that users can unzip as view-private files
>> 3) Rational Method Composer 7.2 will fully support this scenario, which
>> is
>> not in scope for EPF Composer. For enterprise deployments and full
>> scalability we recommend RMC in which every plugin can be maintained as
>> an
>> eclipse project and loaded when needed. In addition we provide project
>> types for configurations, enterprise reports, and estimation models in
>> RMC. EPF Composer is designed to support a single project per library
>> only as it is primary used to maintain OpenUP. A workaround for you
>> would
>> be what I described above for (2).
>>
>> Best regards,
>> Peter Haumer.
>>
>>
>> "Roman Smirak" <roman.smirak@tietoenator.com> wrote in message
>> news:f9kcmi$idh$1@build.eclipse.org...
>>> Hi Ricardo,
>>>
>>> the way you described below is the one I've been using so far;
>>> however,
>>> I have few issues here:
>>> 1/ What if you refactor the content of OpenUP, e.g. an element I was
>>> referencing to is no longer in same package or plugin? Is there any
>>> impact on UID?
>>>
>>> 2/ Currently we have the whole library in a versioning repository,
>>> although everyone has got the basis (OpenUP, or RUP) with the tool (EMC,
>>> or RMC) - no problem for OpenUP, in case of RUP, well we are talking
>>> about 60MB or so (which you have to check in every time you migrate)
>>>
>>> 3/ Let say we have a common basis in our department X, let's call it
>>> OpenUP/X; there is a project A which will use it plus extension A minus
>>> irrelevant content from basis; in case of eclipse plugins they simply
>>> check out required plugins (they stay in touch with their updates by
>>> department X authority) but they don't check out irrelevant plugins (no
>>> mess) + create their new one and check it in their repository (will be
>>> maintained there); currently they need to check out whole library X +
>>> submit their plugins A into the library shared by others (and they do
>>> same action as well => mess X + A + B + C, etc.) in order to fulfil the
>>> use case (the basis maintained by department, a project extension
>>> maintained by the project itself)
>>>
>>> I see the library.xml as a big constraint in this use case.
>>>
>>> Regards,
>>>
>>> Roman
>>>
>>> "Ricardo Balduino" <balduino@us.ibm.com> wrote in message
>>> news:f9itco$87k$1@build.eclipse.org...
>>>> In first paragraph I meant less cumbersome, yet safer ;-)
>>>>
>>>> "Ricardo Balduino" <balduino@us.ibm.com> wrote in message
>>>> news:f9g8d0$db$1@build.eclipse.org...
>>>>> Option A sounds less cumbersome and safer, as the EPF Composer tool
>>>>> will take care of the work. In fact, according to your description of
>>>>> option A, OpenUP 2.x would overwrite OpenUP 1.x.
>>>>>
>>>>> Instead of playing with importing a new OpenUP plug-in into your
>>>>> existing library, have you considered getting the new OpenUP library
>>>>> available and import your plug-in into it instead? With that approach,
>>>>> you are moving your plug-in around, so you know there are no
>>>>> duplicates
>>>>> of it in a brand new OpenUP library. If your plug-in initially
>>>>> depended
>>>>> on some OpenUP element that does not exist anymore when a new version
>>>>> of OpenUP is released, the import will show you warnings, which will
>>>>> help you to spot where you need to maintain your plug-in to extend the
>>>>> most current version of OpenUP. Additions to OpenUP will not affect
>>>>> your plug-in.
>>>>>
>>>>> Cheers,
>>>>>
>>>>> Ricardo Balduino.
>>>>>
>>>>> "K.Benameur" <benameur@freesurf.fr> wrote in message
>>>>> news:f9f8cn$ah0$1@build.eclipse.org...
>>>>>> Hi Peter,
>>>>>>
>>>>>> Sorry to bother you with all my questions !!!
>>>>>>
>>>>>> I am not sure that I have completly understood your answer.
>>>>>>
>>>>>> To check this I propose a simple scenario :
>>>>>> - I develop a library using Open Up 1.x.
>>>>>> - A new version of Open Up is out let say 2.x
>>>>>> - I wan't to take advantage of this new Open Up version.
>>>>>>
>>>>>> A) So ideally, I import the new version in my library and Open Up 1.x
>>>>>> is updated to 2.x.
>>>>>>
>>>>>> I have the feeling that it will not be so simple as many links will
>>>>>> be
>>>>>> broken due to changes between 1.X and 2.X.
>>>>>>
>>>>>> B) I use the copy operation to have the 1.X & 2.X plugin in my
>>>>>> library
>>>>>>
>>>>>> It seems that option B) is the one to go as you said that we have to
>>>>>> do a copy as uuid must be unique.
>>>>>> =>
>>>>>> I have to do the migration manually by replacing elements of Open
>>>>>> 1.x
>>>>>> by their counterparts in 2.x.
>>>>>>
>>>>>> is it right or I missed something like a smart import that detect
>>>>>> conflicts and propose to update automatically element that exist in
>>>>>> 1.X & 2.X /delete obsolete element of 1.X / etc.. ?
>>>>>>
>>>>>> The question is what is the recommended procedure to perform a
>>>>>> plug-in
>>>>>> upgrade with a minimum effort ?
>>>>>>
>>>>>> My concern will be the maintenance cost of a library. If we build our
>>>>>> library from many commercial or non commercial plugins we have to
>>>>>> deal
>>>>>> with their evolutions at a minimal cost.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> Best Regards ...
>>>>>>
>>>>>> PS: I will be in vacation for the next 2 weeks so you have plenty of
>>>>>> time for an anwser ;)
>>>>>>
>>>>>>
>>>>>> PS:
>>>>>> We use ClearCase but it will not help here except to roll back to a
>>>>>> stable baseline and lock elements for modification ...
>>>>>> We are developping our process in multi site. As we didn't want to
>>>>>> add more complexity we decided to work only on one site (windows
>>>>>> terminal server for the distant site) with one development branch in
>>>>>> base CC.
>>>>>> May be you have a successfull experience using CC multisite & UCM ?
>>>>>> Can you share your experience ?
>>>>>> Seems that in CC 7 (we use CC 6) the merge manager have a new option
>>>>>> i.e. to always copy. So may be we can now have branches & multisite
>>>>>> as
>>>>>> now xmi file can be merged by a copy. I see here a potential source
>>>>>> of
>>>>>> trouble as we may surely end with invalid references if for instance
>>>>>> the merge (copy) is done partially on some xmi ...
>>>>>>
>>>>>> Peter Haumer wrote:
>>>>>>> Hello.
>>>>>>> You cannot load multiple versions of the same plugin into the same
>>>>>>> library. All library elements are identified by global unique ids
>>>>>>> and
>>>>>>> hence such ids needs to be unique. To get more than one copy of an
>>>>>>> element you need to use the copy operation in the library view. In
>>>>>>> general we recommend to use a version control system like Rational
>>>>>>> ClearCase which allows you to label and restore old versions of
>>>>>>> whole
>>>>>>> groups of files.
>>>>>>>
>>>>>>> Best regards,
>>>>>>> Peter.
>>>>>>>
>>>>>>> P.S.: Surely they should not be an exception when loading the same
>>>>>>> content twice, but an error message. Please, file a bugzilla with
>>>>>>> reproducible steps.
>>>>>>>
>>>>>>>
>>>>>>> "K.Benameur" <benameur@freesurf.fr> wrote in message
>>>>>>> news:f973f4$goo$1@build.eclipse.org...
>>>>>>>> Hi all,
>>>>>>>>
>>>>>>>> It is a very good question. May be it can be addressed by an update
>>>>>>>> of an existing guideline as the Development Guideline ?
>>>>>>>>
>>>>>>>> I think that we should have a "recommended" procedure from the EPF
>>>>>>>> team to update plug-ins to a new version.
>>>>>>>> It is now a fairly common scenario that multiple versions of the
>>>>>>>> same plug-ins are out.
>>>>>>>>
>>>>>>>> And it is not only related to Open Up but for any library / plug-in
>>>>>>>> as part of the development process (we are developing our own
>>>>>>>> library / plug-ins without Open Up).
>>>>>>>>
>>>>>>>>
>>>>>>>> In short, what is the recommended procedure to migrate to a new
>>>>>>>> version ? Do we have to export / import ? What are the risks? What
>>>>>>>> we may lose ?
>>>>>>>>
>>>>>>>>
>>>>>>>> Best Regards
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>
|
|
|
| Re: Migration to newever library version [message #581803 is a reply to message #37799] |
Tue, 14 August 2007 06:54 |
Roman Smirak
Messages: 136
Registered: July 2009 |
Senior Member |
|
|
Hi Peter,
that is great, the implementation perfectly matches with my vision. Why
not to have it in EPF? I guess many users would welcome the feature.
We have licences of RMC, however, we prefer to use EPF since early releases
are available.
Regards,
Roman
"Peter Haumer" <phaumer@us.ibm.com> wrote in message
news:f9qa5o$jac$1@build.eclipse.org...
> Hello Roman.
> Well, if our competitors can abuse this forum to plug their products; so
> can I :-)
>
> RMC 7.2 does not need the library.xmi file anymore as it uses the Eclipse
> workspace's projects to find all the files. Every plugin is a project as
> well as you can create more than one project for managing configurations
> and one project for estimation data (another RMC added value). The problem
> view is used just as in Eclipse to tell you if you are missing elements in
> your workspace that other elements depend upon. You could ignore those
> errors or fix them by loading the project's that contain the missing
> elements.
>
> See the attached image with an example where I was using plugins managed
> in CVS and plugins managed in CC all at the same time in the same
> workspace. Plugins can now reside in complete different directories even
> on different machine. Just like Eclipse projects, you load them into your
> workspace and use them whenever you need to use them.
>
> However, RMC can still generate a library.xmi for you to manage libraries
> that are fully compatible with EPF Composer. For example, if you check the
> OpenUP CVS repository: it already has project files in each plugin
> directory. That is because I was already working with OpenUP in RMC 7.2;
> at the same time where the rest of the team continued working with EPF
> Composer. Two ways of loading the same library in a fully compatible way.
>
> Hope this helps,
> Peter.
>
>
>
> "Roman Smirak" <roman.smirak@tietoenator.com> wrote in message
> news:f9p6up$mmu$1@build.eclipse.org...
>> Hi Peter,
>>
>> thanks for info, however, RMC is based on EPF and I see current
>> solution
>> of EPF (library.xml) as a fundamental constraint for clear & easy
>> solution
>> at RMC level. Or?
>>
>> Can you please describe the scenario with RMC how it will be implemented?
>>
>> Or shall I post this at IBM Rational forum?
>>
>> Roman
>>
>> "Peter Haumer" <phaumer@us.ibm.com> wrote in message
>> news:f9o54i$924$1@build.eclipse.org...
>>> 1) no, the guid remains the same
>>> 2) not sure I understand the context of this, but I would recommend to
>>> only version manage your own files and if you are using cvs directly get
>>> the OpenUP sources from our server or if you use CC provide a zip/rar
>>> file
>>> with the OpenUP files that users can unzip as view-private files
>>> 3) Rational Method Composer 7.2 will fully support this scenario, which
>>> is
>>> not in scope for EPF Composer. For enterprise deployments and full
>>> scalability we recommend RMC in which every plugin can be maintained as
>>> an
>>> eclipse project and loaded when needed. In addition we provide project
>>> types for configurations, enterprise reports, and estimation models in
>>> RMC. EPF Composer is designed to support a single project per library
>>> only as it is primary used to maintain OpenUP. A workaround for you
>>> would
>>> be what I described above for (2).
>>>
>>> Best regards,
>>> Peter Haumer.
>>>
>>>
>>> "Roman Smirak" <roman.smirak@tietoenator.com> wrote in message
>>> news:f9kcmi$idh$1@build.eclipse.org...
>>>> Hi Ricardo,
>>>>
>>>> the way you described below is the one I've been using so far;
>>>> however,
>>>> I have few issues here:
>>>> 1/ What if you refactor the content of OpenUP, e.g. an element I was
>>>> referencing to is no longer in same package or plugin? Is there any
>>>> impact on UID?
>>>>
>>>> 2/ Currently we have the whole library in a versioning repository,
>>>> although everyone has got the basis (OpenUP, or RUP) with the tool
>>>> (EMC,
>>>> or RMC) - no problem for OpenUP, in case of RUP, well we are talking
>>>> about 60MB or so (which you have to check in every time you migrate)
>>>>
>>>> 3/ Let say we have a common basis in our department X, let's call it
>>>> OpenUP/X; there is a project A which will use it plus extension A minus
>>>> irrelevant content from basis; in case of eclipse plugins they simply
>>>> check out required plugins (they stay in touch with their updates by
>>>> department X authority) but they don't check out irrelevant plugins (no
>>>> mess) + create their new one and check it in their repository (will be
>>>> maintained there); currently they need to check out whole library X +
>>>> submit their plugins A into the library shared by others (and they do
>>>> same action as well => mess X + A + B + C, etc.) in order to fulfil the
>>>> use case (the basis maintained by department, a project extension
>>>> maintained by the project itself)
>>>>
>>>> I see the library.xml as a big constraint in this use case.
>>>>
>>>> Regards,
>>>>
>>>> Roman
>>>>
>>>> "Ricardo Balduino" <balduino@us.ibm.com> wrote in message
>>>> news:f9itco$87k$1@build.eclipse.org...
>>>>> In first paragraph I meant less cumbersome, yet safer ;-)
>>>>>
>>>>> "Ricardo Balduino" <balduino@us.ibm.com> wrote in message
>>>>> news:f9g8d0$db$1@build.eclipse.org...
>>>>>> Option A sounds less cumbersome and safer, as the EPF Composer tool
>>>>>> will take care of the work. In fact, according to your description of
>>>>>> option A, OpenUP 2.x would overwrite OpenUP 1.x.
>>>>>>
>>>>>> Instead of playing with importing a new OpenUP plug-in into your
>>>>>> existing library, have you considered getting the new OpenUP library
>>>>>> available and import your plug-in into it instead? With that
>>>>>> approach,
>>>>>> you are moving your plug-in around, so you know there are no
>>>>>> duplicates
>>>>>> of it in a brand new OpenUP library. If your plug-in initially
>>>>>> depended
>>>>>> on some OpenUP element that does not exist anymore when a new version
>>>>>> of OpenUP is released, the import will show you warnings, which will
>>>>>> help you to spot where you need to maintain your plug-in to extend
>>>>>> the
>>>>>> most current version of OpenUP. Additions to OpenUP will not affect
>>>>>> your plug-in.
>>>>>>
>>>>>> Cheers,
>>>>>>
>>>>>> Ricardo Balduino.
>>>>>>
>>>>>> "K.Benameur" <benameur@freesurf.fr> wrote in message
>>>>>> news:f9f8cn$ah0$1@build.eclipse.org...
>>>>>>> Hi Peter,
>>>>>>>
>>>>>>> Sorry to bother you with all my questions !!!
>>>>>>>
>>>>>>> I am not sure that I have completly understood your answer.
>>>>>>>
>>>>>>> To check this I propose a simple scenario :
>>>>>>> - I develop a library using Open Up 1.x.
>>>>>>> - A new version of Open Up is out let say 2.x
>>>>>>> - I wan't to take advantage of this new Open Up version.
>>>>>>>
>>>>>>> A) So ideally, I import the new version in my library and Open Up
>>>>>>> 1.x
>>>>>>> is updated to 2.x.
>>>>>>>
>>>>>>> I have the feeling that it will not be so simple as many links will
>>>>>>> be
>>>>>>> broken due to changes between 1.X and 2.X.
>>>>>>>
>>>>>>> B) I use the copy operation to have the 1.X & 2.X plugin in my
>>>>>>> library
>>>>>>>
>>>>>>> It seems that option B) is the one to go as you said that we have to
>>>>>>> do a copy as uuid must be unique.
>>>>>>> =>
>>>>>>> I have to do the migration manually by replacing elements of Open
>>>>>>> 1.x
>>>>>>> by their counterparts in 2.x.
>>>>>>>
>>>>>>> is it right or I missed something like a smart import that detect
>>>>>>> conflicts and propose to update automatically element that exist in
>>>>>>> 1.X & 2.X /delete obsolete element of 1.X / etc.. ?
>>>>>>>
>>>>>>> The question is what is the recommended procedure to perform a
>>>>>>> plug-in
>>>>>>> upgrade with a minimum effort ?
>>>>>>>
>>>>>>> My concern will be the maintenance cost of a library. If we build
>>>>>>> our
>>>>>>> library from many commercial or non commercial plugins we have to
>>>>>>> deal
>>>>>>> with their evolutions at a minimal cost.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Best Regards ...
>>>>>>>
>>>>>>> PS: I will be in vacation for the next 2 weeks so you have plenty of
>>>>>>> time for an anwser ;)
>>>>>>>
>>>>>>>
>>>>>>> PS:
>>>>>>> We use ClearCase but it will not help here except to roll back to a
>>>>>>> stable baseline and lock elements for modification ...
>>>>>>> We are developping our process in multi site. As we didn't want to
>>>>>>> add more complexity we decided to work only on one site (windows
>>>>>>> terminal server for the distant site) with one development branch in
>>>>>>> base CC.
>>>>>>> May be you have a successfull experience using CC multisite & UCM ?
>>>>>>> Can you share your experience ?
>>>>>>> Seems that in CC 7 (we use CC 6) the merge manager have a new option
>>>>>>> i.e. to always copy. So may be we can now have branches & multisite
>>>>>>> as
>>>>>>> now xmi file can be merged by a copy. I see here a potential source
>>>>>>> of
>>>>>>> trouble as we may surely end with invalid references if for instance
>>>>>>> the merge (copy) is done partially on some xmi ...
>>>>>>>
>>>>>>> Peter Haumer wrote:
>>>>>>>> Hello.
>>>>>>>> You cannot load multiple versions of the same plugin into the same
>>>>>>>> library. All library elements are identified by global unique ids
>>>>>>>> and
>>>>>>>> hence such ids needs to be unique. To get more than one copy of an
>>>>>>>> element you need to use the copy operation in the library view. In
>>>>>>>> general we recommend to use a version control system like Rational
>>>>>>>> ClearCase which allows you to label and restore old versions of
>>>>>>>> whole
>>>>>>>> groups of files.
>>>>>>>>
>>>>>>>> Best regards,
>>>>>>>> Peter.
>>>>>>>>
>>>>>>>> P.S.: Surely they should not be an exception when loading the same
>>>>>>>> content twice, but an error message. Please, file a bugzilla with
>>>>>>>> reproducible steps.
>>>>>>>>
>>>>>>>>
>>>>>>>> "K.Benameur" <benameur@freesurf.fr> wrote in message
>>>>>>>> news:f973f4$goo$1@build.eclipse.org...
>>>>>>>>> Hi all,
>>>>>>>>>
>>>>>>>>> It is a very good question. May be it can be addressed by an
>>>>>>>>> update
>>>>>>>>> of an existing guideline as the Development Guideline ?
>>>>>>>>>
>>>>>>>>> I think that we should have a "recommended" procedure from the EPF
>>>>>>>>> team to update plug-ins to a new version.
>>>>>>>>> It is now a fairly common scenario that multiple versions of the
>>>>>>>>> same plug-ins are out.
>>>>>>>>>
>>>>>>>>> And it is not only related to Open Up but for any library /
>>>>>>>>> plug-in
>>>>>>>>> as part of the development process (we are developing our own
>>>>>>>>> library / plug-ins without Open Up).
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> In short, what is the recommended procedure to migrate to a new
>>>>>>>>> version ? Do we have to export / import ? What are the risks? What
>>>>>>>>> we may lose ?
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Best Regards
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>
>
|
|
|
| Re: Migration to newever library version [message #582864 is a reply to message #37931] |
Thu, 06 September 2007 20:05 |
| Eclipse User |
|
|
|
Originally posted by: kamal.osellus.com
This is a multi-part message in MIME format.
------=_NextPart_000_0011_01C7F09F.CAC4F440
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
"EPF Composer is designed to support a single project per library only =
as it is primary used to maintain OpenUP".
=20
I wanted to clarify if it really is the case that EPF Composer is =
designed to be primarily used to maintain OpenUP only. =20
=20
Kamal
"Roman Smirak" <roman.smirak@tietoenator.com> wrote in message =
news:f9rjjo$50e$1@build.eclipse.org...
Hi Peter,
that is great, the implementation perfectly matches with my vision. =
Why=20
not to have it in EPF? I guess many users would welcome the feature.
We have licences of RMC, however, we prefer to use EPF since early =
releases=20
are available.
Regards,
Roman
"Peter Haumer" <phaumer@us.ibm.com> wrote in message=20
news:f9qa5o$jac$1@build.eclipse.org...
> Hello Roman.
> Well, if our competitors can abuse this forum to plug their =
products; so=20
> can I :-)
>
> RMC 7.2 does not need the library.xmi file anymore as it uses the =
Eclipse=20
> workspace's projects to find all the files. Every plugin is a =
project as=20
> well as you can create more than one project for managing =
configurations=20
> and one project for estimation data (another RMC added value). The =
problem=20
> view is used just as in Eclipse to tell you if you are missing =
elements in=20
> your workspace that other elements depend upon. You could ignore =
those=20
> errors or fix them by loading the project's that contain the missing =
> elements.
>
> See the attached image with an example where I was using plugins =
managed=20
> in CVS and plugins managed in CC all at the same time in the same=20
> workspace. Plugins can now reside in complete different directories =
even=20
> on different machine. Just like Eclipse projects, you load them =
into your=20
> workspace and use them whenever you need to use them.
>
> However, RMC can still generate a library.xmi for you to manage =
libraries=20
> that are fully compatible with EPF Composer. For example, if you =
check the=20
> OpenUP CVS repository: it already has project files in each plugin=20
> directory. That is because I was already working with OpenUP in RMC =
7.2;=20
> at the same time where the rest of the team continued working with =
EPF=20
> Composer. Two ways of loading the same library in a fully =
compatible way.
>
> Hope this helps,
> Peter.
>
>
>
> "Roman Smirak" <roman.smirak@tietoenator.com> wrote in message=20
> news:f9p6up$mmu$1@build.eclipse.org...
>> Hi Peter,
>>
>> thanks for info, however, RMC is based on EPF and I see current=20
>> solution
>> of EPF (library.xml) as a fundamental constraint for clear & easy=20
>> solution
>> at RMC level. Or?
>>
>> Can you please describe the scenario with RMC how it will be =
implemented?
>>
>> Or shall I post this at IBM Rational forum?
>>
>> Roman
>>
>> "Peter Haumer" <phaumer@us.ibm.com> wrote in message
>> news:f9o54i$924$1@build.eclipse.org...
>>> 1) no, the guid remains the same
>>> 2) not sure I understand the context of this, but I would =
recommend to
>>> only version manage your own files and if you are using cvs =
directly get
>>> the OpenUP sources from our server or if you use CC provide a =
zip/rar=20
>>> file
>>> with the OpenUP files that users can unzip as view-private files
>>> 3) Rational Method Composer 7.2 will fully support this scenario, =
which=20
>>> is
>>> not in scope for EPF Composer. For enterprise deployments and =
full
>>> scalability we recommend RMC in which every plugin can be =
maintained as=20
>>> an
>>> eclipse project and loaded when needed. In addition we provide =
project
>>> types for configurations, enterprise reports, and estimation =
models in
>>> RMC. EPF Composer is designed to support a single project per =
library
>>> only as it is primary used to maintain OpenUP. A workaround for =
you=20
>>> would
>>> be what I described above for (2).
>>>
>>> Best regards,
>>> Peter Haumer.
>>>
>>>
>>> "Roman Smirak" <roman.smirak@tietoenator.com> wrote in message
>>> news:f9kcmi$idh$1@build.eclipse.org...
>>>> Hi Ricardo,
>>>>
>>>> the way you described below is the one I've been using so far;=20
>>>> however,
>>>> I have few issues here:
>>>> 1/ What if you refactor the content of OpenUP, e.g. an element I =
was
>>>> referencing to is no longer in same package or plugin? Is there =
any
>>>> impact on UID?
>>>>
>>>> 2/ Currently we have the whole library in a versioning =
repository,
>>>> although everyone has got the basis (OpenUP, or RUP) with the =
tool=20
>>>> (EMC,
>>>> or RMC) - no problem for OpenUP, in case of RUP, well we are =
talking
>>>> about 60MB or so (which you have to check in every time you =
migrate)
>>>>
>>>> 3/ Let say we have a common basis in our department X, let's call =
it
>>>> OpenUP/X; there is a project A which will use it plus extension A =
minus
>>>> irrelevant content from basis; in case of eclipse plugins they =
simply
>>>> check out required plugins (they stay in touch with their updates =
by
>>>> department X authority) but they don't check out irrelevant =
plugins (no
>>>> mess) + create their new one and check it in their repository =
(will be
>>>> maintained there); currently they need to check out whole library =
X +
>>>> submit their plugins A into the library shared by others (and =
they do
>>>> same action as well =3D> mess X + A + B + C, etc.) in order to =
fulfil the
>>>> use case (the basis maintained by department, a project extension
>>>> maintained by the project itself)
>>>>
>>>> I see the library.xml as a big constraint in this use case.
>>>>
>>>> Regards,
>>>>
>>>> Roman
>>>>
>>>> "Ricardo Balduino" <balduino@us.ibm.com> wrote in message
>>>> news:f9itco$87k$1@build.eclipse.org...
>>>>> In first paragraph I meant less cumbersome, yet safer ;-)
>>>>>
>>>>> "Ricardo Balduino" <balduino@us.ibm.com> wrote in message
>>>>> news:f9g8d0$db$1@build.eclipse.org...
>>>>>> Option A sounds less cumbersome and safer, as the EPF Composer =
tool
>>>>>> will take care of the work. In fact, according to your =
description of
>>>>>> option A, OpenUP 2.x would overwrite OpenUP 1.x.
>>>>>>
>>>>>> Instead of playing with importing a new OpenUP plug-in into =
your
>>>>>> existing library, have you considered getting the new OpenUP =
library
>>>>>> available and import your plug-in into it instead? With that=20
>>>>>> approach,
>>>>>> you are moving your plug-in around, so you know there are no=20
>>>>>> duplicates
>>>>>> of it in a brand new OpenUP library. If your plug-in initially=20
>>>>>> depended
>>>>>> on some OpenUP element that does not exist anymore when a new =
version
>>>>>> of OpenUP is released, the import will show you warnings, which =
will
>>>>>> help you to spot where you need to maintain your plug-in to =
extend=20
>>>>>> the
>>>>>> most current version of OpenUP. Additions to OpenUP will not =
affect
>>>>>> your plug-in.
>>>>>>
>>>>>> Cheers,
>>>>>>
>>>>>> Ricardo Balduino.
>>>>>>
>>>>>> "K.Benameur" <benameur@freesurf.fr> wrote in message
>>>>>> news:f9f8cn$ah0$1@build.eclipse.org...
>>>>>>> Hi Peter,
>>>>>>>
>>>>>>> Sorry to bother you with all my questions !!!
>>>>>>>
>>>>>>> I am not sure that I have completly understood your answer.
>>>>>>>
>>>>>>> To check this I propose a simple scenario :
>>>>>>> - I develop a library using Open Up 1.x.
>>>>>>> - A new version of Open Up is out let say 2.x
>>>>>>> - I wan't to take advantage of this new Open Up version.
>>>>>>>
>>>>>>> A) So ideally, I import the new version in my library and Open =
Up=20
>>>>>>> 1.x
>>>>>>> is updated to 2.x.
>>>>>>>
>>>>>>> I have the feeling that it will not be so simple as many links =
will=20
>>>>>>> be
>>>>>>> broken due to changes between 1.X and 2.X.
>>>>>>>
>>>>>>> B) I use the copy operation to have the 1.X & 2.X plugin in my =
>>>>>>> library
>>>>>>>
>>>>>>> It seems that option B) is the one to go as you said that we =
have to
>>>>>>> do a copy as uuid must be unique.
>>>>>>> =3D>
>>>>>>> I have to do the migration manually by replacing elements of =
Open=20
>>>>>>> 1.x
>>>>>>> by their counterparts in 2.x.
>>>>>>>
>>>>>>> is it right or I missed something like a smart import that =
detect
>>>>>>> conflicts and propose to update automatically element that =
exist in
>>>>>>> 1.X & 2.X /delete obsolete element of 1.X / etc.. ?
>>>>>>>
>>>>>>> The question is what is the recommended procedure to perform a =
>>>>>>> plug-in
>>>>>>> upgrade with a minimum effort ?
>>>>>>>
>>>>>>> My concern will be the maintenance cost of a library. If we =
build=20
>>>>>>> our
>>>>>>> library from many commercial or non commercial plugins we have =
to=20
>>>>>>> deal
>>>>>>> with their evolutions at a minimal cost.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Best Regards ...
>>>>>>>
>>>>>>> PS: I will be in vacation for the next 2 weeks so you have =
plenty of
>>>>>>> time for an anwser ;)
>>>>>>>
>>>>>>>
>>>>>>> PS:
>>>>>>> We use ClearCase but it will not help here except to roll =
back to a
>>>>>>> stable baseline and lock elements for modification ...
>>>>>>> We are developping our process in multi site. As we didn't =
want to
>>>>>>> add more complexity we decided to work only on one site =
(windows
>>>>>>> terminal server for the distant site) with one development =
branch in
>>>>>>> base CC.
>>>>>>> May be you have a successfull experience using CC multisite & =
UCM ?
>>>>>>> Can you share your experience ?
>>>>>>> Seems that in CC 7 (we use CC 6) the merge manager have a new =
option
>>>>>>> i.e. to always copy. So may be we can now have branches & =
multisite=20
>>>>>>> as
>>>>>>> now xmi file can be merged by a copy. I see here a potential =
source=20
>>>>>>> of
>>>>>>> trouble as we may surely end with invalid references if for =
instance
>>>>>>> the merge (copy) is done partially on some xmi ...
>>>>>>>
>>>>>>> Peter Haumer wrote:
>>>>>>>> Hello.
>>>>>>>> You cannot load multiple versions of the same plugin into the =
same
>>>>>>>> library. All library elements are identified by global unique =
ids=20
>>>>>>>> and
>>>>>>>> hence such ids needs to be unique. To get more than one copy =
of an
>>>>>>>> element you need to use the copy operation in the library =
view. In
>>>>>>>> general we recommend to use a version control system like =
Rational
>>>>>>>> ClearCase which allows you to label and restore old versions =
of=20
>>>>>>>> whole
>>>>>>>> groups of files.
>>>>>>>>
>>>>>>>> Best regards,
>>>>>>>> Peter.
>>>>>>>>
>>>>>>>> P.S.: Surely they should not be an exception when loading the =
same
>>>>>>>> content twice, but an error message. Please, file a bugzilla =
with
>>>>>>>> reproducible steps.
>>>>>>>>
>>>>>>>>
>>>>>>>> "K.Benameur" <benameur@freesurf.fr> wrote in message
>>>>>>>> news:f973f4$goo$1@build.eclipse.org...
>>>>>>>>> Hi all,
>>>>>>>>>
>>>>>>>>> It is a very good question. May be it can be addressed by an =
>>>>>>>>> update
>>>>>>>>> of an existing guideline as the Development Guideline ?
>>>>>>>>>
>>>>>>>>> I think that we should have a "recommended" procedure from =
the EPF
>>>>>>>>> team to update plug-ins to a new version.
>>>>>>>>> It is now a fairly common scenario that multiple versions =
of the
>>>>>>>>> same plug-ins are out.
>>>>>>>>>
>>>>>>>>> And it is not only related to Open Up but for any library /=20
>>>>>>>>> plug-in
>>>>>>>>> as part of the development process (we are developing our =
own
>>>>>>>>> library / plug-ins without Open Up).
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> In short, what is the recommended procedure to migrate to a =
new
>>>>>>>>> version ? Do we have to export / import ? What are the =
risks? What
>>>>>>>>> we may lose ?
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Best Regards
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>
>=20
------=_NextPart_000_0011_01C7F09F.CAC4F440
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.6000.16527" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>
<P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><FONT size=3D3><FONT=20
face=3D"Times New Roman">=93EPF Composer is designed to support a single =
project per=20
library only as it is primary used to maintain OpenUP=94.<?xml:namespace =
prefix =3D=20
o ns =3D "urn:schemas-microsoft-com:office:office" =
/><o:p></o:p></FONT></FONT></P>
<P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><o:p><FONT =
face=3D"Times New Roman"=20
size=3D3> </FONT></o:p></P>
<P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><FONT size=3D3><FONT=20
face=3D"Times New Roman">I wanted to clarify if it really is =
the case=20
that EPF Composer is designed to be primarily used to maintain OpenUP =
only.=20
<o:p></o:p></FONT></FONT></P>
<P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><o:p><FONT =
face=3D"Times New Roman"=20
size=3D3> </FONT></o:p></P>
<P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><FONT size=3D3><FONT=20
face=3D"Times New Roman">Kamal<o:p></o:p></FONT></FONT></P></FONT></DIV >
<BLOCKQUOTE=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
<DIV>"Roman Smirak" <<A=20
=
href=3D"mailto:roman.smirak@tietoenator.com">roman.smirak@tietoenator.com=
</A>>=20
wrote in message <A=20
=
href=3D"news:f9rjjo$50e$1@build.eclipse.org">news:f9rjjo$50e$1@build.ecli=
pse.org</A>...</DIV>Hi=20
Peter,<BR><BR> that is great, the implementation perfectly =
matches=20
with my vision. Why <BR>not to have it in EPF? I guess many users =
would=20
welcome the feature.<BR><BR>We have licences of RMC, however, we =
prefer to use=20
EPF since early releases <BR>are=20
available.<BR><BR>Regards,<BR><BR>Roman<BR><BR>"Peter Haumer" <<A=20
href=3D"mailto:phaumer@us.ibm.com">phaumer@us.ibm.com</A>> wrote in =
message=20
<BR><A=20
=
href=3D"news:f9qa5o$jac$1@build.eclipse.org">news:f9qa5o$jac$1@build.ecli=
pse.org</A>...<BR>>=20
Hello Roman.<BR>> Well, if our competitors can abuse this forum to =
plug=20
their products; so <BR>> can I :-)<BR>><BR>> RMC 7.2 does not =
need=20
the library.xmi file anymore as it uses the Eclipse <BR>> =
workspace's=20
projects to find all the files. Every plugin is a project as <BR>> =
well as=20
you can create more than one project for managing configurations =
<BR>> and=20
one project for estimation data (another RMC added value). The problem =
<BR>> view is used just as in Eclipse to tell you if you are =
missing=20
elements in <BR>> your workspace that other elements depend =
upon. You=20
could ignore those <BR>> errors or fix them by loading the =
project's that=20
contain the missing <BR>> elements.<BR>><BR>> See the =
attached image=20
with an example where I was using plugins managed <BR>> in CVS and =
plugins=20
managed in CC all at the same time in the same <BR>> workspace. =
Plugins can=20
now reside in complete different directories even <BR>> on =
different=20
machine. Just like Eclipse projects, you load them into your =
<BR>>=20
workspace and use them whenever you need to use them.<BR>><BR>> =
However,=20
RMC can still generate a library.xmi for you to manage libraries =
<BR>> that=20
are fully compatible with EPF Composer. For example, if you check the =
<BR>>=20
OpenUP CVS repository: it already has project files in each plugin =
<BR>>=20
directory. That is because I was already working with OpenUP in =
RMC 7.2;=20
<BR>> at the same time where the rest of the team continued working =
with=20
EPF <BR>> Composer. Two ways of loading the same library in a =
fully=20
compatible way.<BR>><BR>> Hope this helps,<BR>>=20
Peter.<BR>><BR>><BR>><BR>> "Roman Smirak" <<A=20
=
href=3D"mailto:roman.smirak@tietoenator.com">roman.smirak@tietoenator.com=
</A>>=20
wrote in message <BR>> <A=20
=
href=3D"news:f9p6up$mmu$1@build.eclipse.org">news:f9p6up$mmu$1@build.ecli=
pse.org</A>...<BR>>>=20
Hi Peter,<BR>>><BR>>> thanks for info, =
however, RMC is=20
based on EPF and I see current <BR>>> solution<BR>>> of =
EPF=20
(library.xml) as a fundamental constraint for clear & easy =
<BR>>>=20
solution<BR>>> at RMC level. Or?<BR>>><BR>>> Can you =
please=20
describe the scenario with RMC how it will be=20
implemented?<BR>>><BR>>> Or shall I post this at IBM =
Rational=20
forum?<BR>>><BR>>> Roman<BR>>><BR>>> "Peter =
Haumer"=20
<<A href=3D"mailto:phaumer@us.ibm.com">phaumer@us.ibm.com</A>> =
wrote in=20
message<BR>>> <A=20
=
href=3D"news:f9o54i$924$1@build.eclipse.org">news:f9o54i$924$1@build.ecli=
pse.org</A>...<BR>>>>=20
1) no, the guid remains the same<BR>>>> 2) not sure I =
understand the=20
context of this, but I would recommend to<BR>>>> only version =
manage=20
your own files and if you are using cvs directly get<BR>>>> =
the=20
OpenUP sources from our server or if you use CC provide a zip/rar=20
<BR>>>> file<BR>>>> with the OpenUP files that users =
can=20
unzip as view-private files<BR>>>> 3) Rational Method =
Composer 7.2=20
will fully support this scenario, which <BR>>>> =
is<BR>>>>=20
not in scope for EPF Composer. For enterprise deployments and=20
full<BR>>>> scalability we recommend RMC in which every =
plugin can be=20
maintained as <BR>>>> an<BR>>>> eclipse project and =
loaded=20
when needed. In addition we provide project<BR>>>> types for=20
configurations, enterprise reports, and estimation models =
in<BR>>>>=20
RMC. EPF Composer is designed to support a single project per=20
library<BR>>>> only as it is primary used to maintain =
OpenUP. A=20
workaround for you <BR>>>> would<BR>>>> be what I =
described=20
above for (2).<BR>>>><BR>>>> Best =
regards,<BR>>>>=20
Peter Haumer.<BR>>>><BR>>>> <BR>>>> "Roman =
Smirak"=20
<<A=20
=
href=3D"mailto:roman.smirak@tietoenator.com">roman.smirak@tietoenator.com=
</A>>=20
wrote in message<BR>>>> <A=20
=
href=3D"news:f9kcmi$idh$1@build.eclipse.org">news:f9kcmi$idh$1@build.ecli=
pse.org</A>...<BR>>>>>=20
Hi Ricardo,<BR>>>>><BR>>>>> the =
way you=20
described below is the one I've been using so far; =
<BR>>>>>=20
however,<BR>>>>> I have few issues =
here:<BR>>>>> 1/=20
What if you refactor the content of OpenUP, e.g. an element I=20
was<BR>>>>> referencing to is no longer in same package or =
plugin?=20
Is there any<BR>>>>> impact on=20
UID?<BR>>>>><BR>>>>> 2/ Currently we have the =
whole=20
library in a versioning repository,<BR>>>>> although =
everyone has=20
got the basis (OpenUP, or RUP) with the tool <BR>>>>>=20
(EMC,<BR>>>>> or RMC) - no problem for OpenUP, in case of =
RUP,=20
well we are talking<BR>>>>> about 60MB or so (which you =
have to=20
check in every time you =
migrate)<BR>>>>><BR>>>>> 3/=20
Let say we have a common basis in our department X, let's call=20
it<BR>>>>> OpenUP/X; there is a project A which will use =
it plus=20
extension A minus<BR>>>>> irrelevant content from basis; =
in case=20
of eclipse plugins they simply<BR>>>>> check out required =
plugins=20
(they stay in touch with their updates by<BR>>>>> =
department X=20
authority) but they don't check out irrelevant plugins =
(no<BR>>>>>=20
mess) + create their new one and check it in their repository (will=20
be<BR>>>>> maintained there); currently they need to check =
out=20
whole library X +<BR>>>>> submit their plugins A into the =
library=20
shared by others (and they do<BR>>>>> same action as well =
=3D>=20
mess X + A + B + C, etc.) in order to fulfil the<BR>>>>> =
use case=20
(the basis maintained by department, a project =
extension<BR>>>>>=20
maintained by the project =
itself)<BR>>>>><BR>>>>> I=20
see the library.xml as a big constraint in this use=20
case.<BR>>>>><BR>>>>>=20
Regards,<BR>>>>><BR>>>>>=20
Roman<BR>>>>><BR>>>>> "Ricardo Balduino" =
<<A=20
href=3D"mailto:balduino@us.ibm.com">balduino@us.ibm.com</A>> wrote =
in=20
message<BR>>>>> <A=20
=
href=3D"news:f9itco$87k$1@build.eclipse.org">news:f9itco$87k$1@build.ecli=
pse.org</A>...<BR>>>>>>=20
In first paragraph I meant less cumbersome, yet safer=20
;-)<BR>>>>>><BR>>>>>> "Ricardo Balduino" =
<<A=20
href=3D"mailto:balduino@us.ibm.com">balduino@us.ibm.com</A>> wrote =
in=20
message<BR>>>>>> <A=20
=
href=3D"news:f9g8d0$db$1@build.eclipse.org">news:f9g8d0$db$1@build.eclips=
e.org</A>...<BR>>>>>>>=20
Option A sounds less cumbersome and safer, as the EPF Composer=20
tool<BR>>>>>>> will take care of the work. In fact,=20
according to your description of<BR>>>>>>> option A, =
OpenUP=20
2.x would overwrite OpenUP=20
1.x.<BR>>>>>>><BR >>>>>>> Instead =
of=20
playing with importing a new OpenUP plug-in into=20
your<BR>>>>>>> existing library, have you considered =
getting=20
the new OpenUP library<BR>>>>>>> available and =
import your=20
plug-in into it instead? With that <BR>>>>>>>=20
approach,<BR>>>>>>> you are moving your plug-in =
around, so=20
you know there are no <BR>>>>>>>=20
duplicates<BR>>>>>>> of it in a brand new OpenUP =
library. If=20
your plug-in initially <BR>>>>>>>=20
depended<BR>>>>>>> on some OpenUP element that does =
not=20
exist anymore when a new version<BR>>>>>>> of OpenUP =
is=20
released, the import will show you warnings, which=20
will<BR>>>>>>> help you to spot where you need to =
maintain=20
your plug-in to extend <BR>>>>>>>=20
the<BR>>>>>>> most current version of OpenUP. =
Additions to=20
OpenUP will not affect<BR>>>>>>> your=20
plug-in.<BR>>>>>>> <BR>>>>>>>=20
Cheers,<BR>>>>>>> <BR>>>>>>> =
Ricardo=20
Balduino.<BR>>>>>>> <BR>>>>>>> =
"K.Benameur"=20
<<A =
href=3D"mailto:benameur@freesurf.fr">benameur@freesurf.fr</A>> wrote=20
in message<BR>>>>>>> <A=20
=
href=3D"news:f9f8cn$ah0$1@build.eclipse.org">news:f9f8cn$ah0$1@build.ecli=
pse.org</A>...<BR>>>>>>>>=20
Hi =
Peter,<BR>>>>>>>> <BR>>>>>>>>=20
Sorry to bother you with all my questions=20
!!!<BR>>>>>>>> <BR>>>>>>>> I =
am not=20
sure that I have completly understood your=20
=
answer.<BR>>>>>>>> <BR>>>>>>>> =
To=20
check this I propose a simple scenario =20
:<BR> >>>>>>>& ;nbsp; - I develop a library =
using Open=20
Up 1.x.<BR> >>>>>>>& ;nbsp; - A new version of =
Open Up=20
is out let say 2.x<BR> >>>>>>>& ;nbsp; - I wan't to =
take=20
advantage of this new Open Up=20
=
version.<BR>>>>>>>> <BR>>>>>>>> =
A) So=20
ideally, I import the new version in my library and Open Up=20
<BR>>>>>>>> 1.x<BR>>>>>>>> =
is=20
updated to=20
2.x.<BR>>>>>>>> <BR>>>>>>>> I =
have=20
the feeling that it will not be so simple as many links will=20
<BR>>>>>>>> be<BR>>>>>>>> =
broken due=20
to changes between 1.X and=20
2.X.<BR>>>>>>>> <BR>>>>>>>> =
B) I use=20
the copy operation to have the 1.X & 2.X plugin in my=20
<BR>>>>>>>>=20
=
library<BR>>>>>>>> <BR>>>>>>>> =
It=20
seems that option B) is the one to go as you said that we have=20
to<BR>>>>>>>> do a copy as uuid must be=20
unique.<BR>>>>>>>> =
=3D><BR>>>>>>>>=20
I have to do the migration manually by replacing elements of =
Open=20
<BR>>>>>>>> 1.x<BR>>>>>>>> =
by their=20
counterparts in=20
2.x.<BR>>>>>>>> <BR>>>>>>>> =
is it=20
right or I missed something like a smart import that=20
detect<BR>>>>>>>> conflicts and propose to update =
automatically element that exist in<BR>>>>>>>> =
1.X &=20
2.X /delete obsolete element of 1.X / etc..=20
?<BR>>>>>>>> <BR>>>>>>>> The =
question=20
is what is the recommended procedure to perform a=20
<BR>>>>>>>> =
plug-in<BR>>>>>>>>=20
upgrade with a minimum effort=20
?<BR>>>>>>>> <BR>>>>>>>> My =
concern=20
will be the maintenance cost of a library. If we build=20
<BR>>>>>>>> our<BR>>>>>>>> =
library=20
from many commercial or non commercial plugins we have to=20
<BR>>>>>>>> deal<BR>>>>>>>> =
with=20
their evolutions at a minimal=20
=
cost.<BR>>>>>>>> <BR>>>>>>>> <BR>=
>>>>>>><BR >>>>>>>><BR >>>&=
gt;>>>>=20
Best Regards=20
...<BR>>>>>>>> <BR>>>>>>>> =
PS: I will=20
be in vacation for the next 2 weeks so you have plenty=20
of<BR>>>>>>>> time for an anwser=20
=
;)<BR>>>>>>>> <BR>>>>>>>> <BR>>=
;>>>>>>=20
PS:<BR> >>>>>>>& ;nbsp; We use ClearCase but it will =
not=20
help here except to roll back to a<BR>>>>>>>> =
stable=20
baseline and lock elements for modification=20
...<BR> >>>>>>>& ;nbsp; We are developping our =
process in=20
multi site. As we didn't want to<BR>>>>>>>> add =
more=20
complexity we decided to work only on one site=20
(windows<BR>>>>>>>> terminal server for the =
distant site)=20
with one development branch in<BR>>>>>>>> base=20
CC.<BR>>>>>>>> May be you have a successfull =
experience=20
using CC multisite & UCM ?<BR>>>>>>>> Can you =
share=20
your experience ?<BR>>>>>>>> Seems that in CC 7 =
(we use=20
CC 6) the merge manager have a new =
option<BR>>>>>>>> i.e.=20
to always copy. So may be we can now have branches & multisite=20
<BR>>>>>>>> as<BR>>>>>>>> =
now xmi=20
file can be merged by a copy. I see here a potential source=20
<BR>>>>>>>> of<BR>>>>>>>> =
trouble as=20
we may surely end with invalid references if for=20
instance<BR>>>>>>>> the merge (copy) is done =
partially on=20
some xmi =
....<BR>>>>>>>> <BR>>>>>>>>=20
Peter Haumer wrote:<BR> >>>>>>>& ;gt;=20
Hello.<BR> >>>>>>>& ;gt; You cannot load multiple =
versions=20
of the same plugin into the same<BR> >>>>>>>& ;gt; =
library.=20
All library elements are identified by global unique ids=20
<BR> >>>>>>>& ;gt; =
and<BR> >>>>>>>& ;gt;=20
hence such ids needs to be unique. To get more than one copy of=20
an<BR> >>>>>>>& ;gt; element you need to use the =
copy=20
operation in the library view. In<BR> >>>>>>>& ;gt; =
general=20
we recommend to use a version control system like=20
Rational<BR> >>>>>>>& ;gt; ClearCase which allows =
you to=20
label and restore old versions of <BR> >>>>>>>& ;gt; =
whole<BR> >>>>>>>& ;gt; groups of=20
=
files.<BR> >>>>>>>& ;gt; <BR>>>>>>>>=
;>=20
Best regards,<BR> >>>>>>>& ;gt;=20
=
Peter.<BR> >>>>>>>& ;gt; <BR>>>>>>>>=
;>=20
P.S.: Surely they should not be an exception when loading the=20
same<BR> >>>>>>>& ;gt; content twice, but an error=20
message. Please, file a bugzilla=20
with<BR> >>>>>>>& ;gt; reproducible=20
=
steps.<BR> >>>>>>>& ;gt; <BR>>>>>>>>=
;><BR> >>>>>>>& ;gt;=20
"K.Benameur" <<A=20
href=3D"mailto:benameur@freesurf.fr">benameur@freesurf.fr</A>> =
wrote in=20
message<BR> >>>>>>>& ;gt; <A=20
=
href=3D"news:f973f4$goo$1@build.eclipse.org">news:f973f4$goo$1@build.ecli=
pse.org</A>...<BR> >>>>>>>& ;gt;>=20
Hi=20
=
all,<BR> >>>>>>>& ;gt;> <BR>>>>>>>&=
gt;>>=20
It is a very good question. May be it can be addressed by an=20
<BR> >>>>>>>& ;gt;>=20
update<BR> >>>>>>>& ;gt;> of an existing =
guideline as the=20
Development Guideline=20
=
?<BR> >>>>>>>& ;gt;> <BR>>>>>>>>=
>>=20
I think that we should have a "recommended" procedure from the=20
EPF<BR> >>>>>>>& ;gt;> team to update plug-ins to =
a new=20
version.<BR> >>>>>>>& ;gt;> It is now a =
fairly=20
common scenario that multiple versions of=20
the<BR> >>>>>>>& ;gt;> same plug-ins are=20
=
out.<BR> >>>>>>>& ;gt;> <BR>>>>>>>&=
gt;>>=20
And it is not only related to Open Up but for any library /=20
<BR> >>>>>>>& ;gt;>=20
plug-in<BR> >>>>>>>& ;gt;> as part of the =
development=20
process (we are developing our =
own<BR> >>>>>>>& ;gt;>=20
library / plug-ins without Open=20
=
Up).<BR> >>>>>>>& ;gt;> <BR>>>>>>>&=
gt;>><BR> >>>>>>>& ;gt;> =20
In short, what is the recommended procedure to migrate to a=20
new<BR> >>>>>>>& ;gt;> version ? Do we have to =
export /=20
import ? What are the risks? =
What<BR> >>>>>>>& ;gt;> we=20
may lose=20
=
?<BR> >>>>>>>& ;gt;> <BR>>>>>>>>=
>><BR> >>>>>>>& ;gt;>=20
Best=20
=
Regards<BR> >>>>>>>& ;gt;> <BR>>>>>>&g=
t;>>><BR> >>>>>>>& ;gt; <BR>>>>>>=
;><BR>>>>>><BR>>>>>> <BR>>>>>=
<BR>>>>><BR>>>> <BR>>>><BR>>><BR>>&=
gt;<BR>><BR>><BR>>=20
<BR><BR></BLOCKQUOTE></BODY></HTML>
------=_NextPart_000_0011_01C7F09F.CAC4F440--
|
|
|
| Re: Migration to newever library version [message #582879 is a reply to message #39895] |
Thu, 06 September 2007 20:22 |
Ricardo Balduino
Messages: 191
Registered: July 2009 |
Senior Member |
|
|
This is a multi-part message in MIME format.
------=_NextPart_000_0047_01C7F089.063F8380
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
>>> I wanted to clarify if it really is the case that EPF Composer is =
designed to be primarily used to maintain OpenUP only. =20
It is not really the case.
EPF Composer is used by the EPF team to maintain OpenUP, DSDM, Scrum, XP =
and any other processes being captured today and in the future under the =
EPF project.
Moreover, EPF users can capture their own home-grown processes or =
extensions to available processes using EPF Composer.
I hope this clarifies your question.
Regards,
Ricardo Balduino.
"Kamal Ahluwalia" <kamal@osellus.com> wrote in message =
news:fbpmjg$rai$1@build.eclipse.org...
"EPF Composer is designed to support a single project per library only =
as it is primary used to maintain OpenUP".
=20
I wanted to clarify if it really is the case that EPF Composer is =
designed to be primarily used to maintain OpenUP only. =20
=20
Kamal
"Roman Smirak" <roman.smirak@tietoenator.com> wrote in message =
news:f9rjjo$50e$1@build.eclipse.org...
Hi Peter,
that is great, the implementation perfectly matches with my =
vision. Why=20
not to have it in EPF? I guess many users would welcome the feature.
We have licences of RMC, however, we prefer to use EPF since early =
releases=20
are available.
Regards,
Roman
"Peter Haumer" <phaumer@us.ibm.com> wrote in message=20
news:f9qa5o$jac$1@build.eclipse.org...
> Hello Roman.
> Well, if our competitors can abuse this forum to plug their =
products; so=20
> can I :-)
>
> RMC 7.2 does not need the library.xmi file anymore as it uses the =
Eclipse=20
> workspace's projects to find all the files. Every plugin is a =
project as=20
> well as you can create more than one project for managing =
configurations=20
> and one project for estimation data (another RMC added value). The =
problem=20
> view is used just as in Eclipse to tell you if you are missing =
elements in=20
> your workspace that other elements depend upon. You could ignore =
those=20
> errors or fix them by loading the project's that contain the =
missing=20
> elements.
>
> See the attached image with an example where I was using plugins =
managed=20
> in CVS and plugins managed in CC all at the same time in the same=20
> workspace. Plugins can now reside in complete different =
directories even=20
> on different machine. Just like Eclipse projects, you load them =
into your=20
> workspace and use them whenever you need to use them.
>
> However, RMC can still generate a library.xmi for you to manage =
libraries=20
> that are fully compatible with EPF Composer. For example, if you =
check the=20
> OpenUP CVS repository: it already has project files in each plugin =
> directory. That is because I was already working with OpenUP in =
RMC 7.2;=20
> at the same time where the rest of the team continued working with =
EPF=20
> Composer. Two ways of loading the same library in a fully =
compatible way.
>
> Hope this helps,
> Peter.
>
>
>
> "Roman Smirak" <roman.smirak@tietoenator.com> wrote in message=20
> news:f9p6up$mmu$1@build.eclipse.org...
>> Hi Peter,
>>
>> thanks for info, however, RMC is based on EPF and I see current =
>> solution
>> of EPF (library.xml) as a fundamental constraint for clear & easy =
>> solution
>> at RMC level. Or?
>>
>> Can you please describe the scenario with RMC how it will be =
implemented?
>>
>> Or shall I post this at IBM Rational forum?
>>
>> Roman
>>
>> "Peter Haumer" <phaumer@us.ibm.com> wrote in message
>> news:f9o54i$924$1@build.eclipse.org...
>>> 1) no, the guid remains the same
>>> 2) not sure I understand the context of this, but I would =
recommend to
>>> only version manage your own files and if you are using cvs =
directly get
>>> the OpenUP sources from our server or if you use CC provide a =
zip/rar=20
>>> file
>>> with the OpenUP files that users can unzip as view-private files
>>> 3) Rational Method Composer 7.2 will fully support this =
scenario, which=20
>>> is
>>> not in scope for EPF Composer. For enterprise deployments and =
full
>>> scalability we recommend RMC in which every plugin can be =
maintained as=20
>>> an
>>> eclipse project and loaded when needed. In addition we provide =
project
>>> types for configurations, enterprise reports, and estimation =
models in
>>> RMC. EPF Composer is designed to support a single project per =
library
>>> only as it is primary used to maintain OpenUP. A workaround for =
you=20
>>> would
>>> be what I described above for (2).
>>>
>>> Best regards,
>>> Peter Haumer.
>>>
>>>
>>> "Roman Smirak" <roman.smirak@tietoenator.com> wrote in message
>>> news:f9kcmi$idh$1@build.eclipse.org...
>>>> Hi Ricardo,
>>>>
>>>> the way you described below is the one I've been using so =
far;=20
>>>> however,
>>>> I have few issues here:
>>>> 1/ What if you refactor the content of OpenUP, e.g. an element =
I was
>>>> referencing to is no longer in same package or plugin? Is there =
any
>>>> impact on UID?
>>>>
>>>> 2/ Currently we have the whole library in a versioning =
repository,
>>>> although everyone has got the basis (OpenUP, or RUP) with the =
tool=20
>>>> (EMC,
>>>> or RMC) - no problem for OpenUP, in case of RUP, well we are =
talking
>>>> about 60MB or so (which you have to check in every time you =
migrate)
>>>>
>>>> 3/ Let say we have a common basis in our department X, let's =
call it
>>>> OpenUP/X; there is a project A which will use it plus extension =
A minus
>>>> irrelevant content from basis; in case of eclipse plugins they =
simply
>>>> check out required plugins (they stay in touch with their =
updates by
>>>> department X authority) but they don't check out irrelevant =
plugins (no
>>>> mess) + create their new one and check it in their repository =
(will be
>>>> maintained there); currently they need to check out whole =
library X +
>>>> submit their plugins A into the library shared by others (and =
they do
>>>> same action as well =3D> mess X + A + B + C, etc.) in order to =
fulfil the
>>>> use case (the basis maintained by department, a project =
extension
>>>> maintained by the project itself)
>>>>
>>>> I see the library.xml as a big constraint in this use case.
>>>>
>>>> Regards,
>>>>
>>>> Roman
>>>>
>>>> "Ricardo Balduino" <balduino@us.ibm.com> wrote in message
>>>> news:f9itco$87k$1@build.eclipse.org...
>>>>> In first paragraph I meant less cumbersome, yet safer ;-)
>>>>>
>>>>> "Ricardo Balduino" <balduino@us.ibm.com> wrote in message
>>>>> news:f9g8d0$db$1@build.eclipse.org...
>>>>>> Option A sounds less cumbersome and safer, as the EPF =
Composer tool
>>>>>> will take care of the work. In fact, according to your =
description of
>>>>>> option A, OpenUP 2.x would overwrite OpenUP 1.x.
>>>>>>
>>>>>> Instead of playing with importing a new OpenUP plug-in into =
your
>>>>>> existing library, have you considered getting the new OpenUP =
library
>>>>>> available and import your plug-in into it instead? With that=20
>>>>>> approach,
>>>>>> you are moving your plug-in around, so you know there are no=20
>>>>>> duplicates
>>>>>> of it in a brand new OpenUP library. If your plug-in =
initially=20
>>>>>> depended
>>>>>> on some OpenUP element that does not exist anymore when a new =
version
>>>>>> of OpenUP is released, the import will show you warnings, =
which will
>>>>>> help you to spot where you need to maintain your plug-in to =
extend=20
>>>>>> the
>>>>>> most current version of OpenUP. Additions to OpenUP will not =
affect
>>>>>> your plug-in.
>>>>>>
>>>>>> Cheers,
>>>>>>
>>>>>> Ricardo Balduino.
>>>>>>
>>>>>> "K.Benameur" <benameur@freesurf.fr> wrote in message
>>>>>> news:f9f8cn$ah0$1@build.eclipse.org...
>>>>>>> Hi Peter,
>>>>>>>
>>>>>>> Sorry to bother you with all my questions !!!
>>>>>>>
>>>>>>> I am not sure that I have completly understood your answer.
>>>>>>>
>>>>>>> To check this I propose a simple scenario :
>>>>>>> - I develop a library using Open Up 1.x.
>>>>>>> - A new version of Open Up is out let say 2.x
>>>>>>> - I wan't to take advantage of this new Open Up version.
>>>>>>>
>>>>>>> A) So ideally, I import the new version in my library and =
Open Up=20
>>>>>>> 1.x
>>>>>>> is updated to 2.x.
>>>>>>>
>>>>>>> I have the feeling that it will not be so simple as many =
links will=20
>>>>>>> be
>>>>>>> broken due to changes between 1.X and 2.X.
>>>>>>>
>>>>>>> B) I use the copy operation to have the 1.X & 2.X plugin in =
my=20
>>>>>>> library
>>>>>>>
>>>>>>> It seems that option B) is the one to go as you said that we =
have to
>>>>>>> do a copy as uuid must be unique.
>>>>>>> =3D>
>>>>>>> I have to do the migration manually by replacing elements =
of Open=20
>>>>>>> 1.x
>>>>>>> by their counterparts in 2.x.
>>>>>>>
>>>>>>> is it right or I missed something like a smart import that =
detect
>>>>>>> conflicts and propose to update automatically element that =
exist in
>>>>>>> 1.X & 2.X /delete obsolete element of 1.X / etc.. ?
>>>>>>>
>>>>>>> The question is what is the recommended procedure to perform =
a=20
>>>>>>> plug-in
>>>>>>> upgrade with a minimum effort ?
>>>>>>>
>>>>>>> My concern will be the maintenance cost of a library. If we =
build=20
>>>>>>> our
>>>>>>> library from many commercial or non commercial plugins we =
have to=20
>>>>>>> deal
>>>>>>> with their evolutions at a minimal cost.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Best Regards ...
>>>>>>>
>>>>>>> PS: I will be in vacation for the next 2 weeks so you have =
plenty of
>>>>>>> time for an anwser ;)
>>>>>>>
>>>>>>>
>>>>>>> PS:
>>>>>>> We use ClearCase but it will not help here except to roll =
back to a
>>>>>>> stable baseline and lock elements for modification ...
>>>>>>> We are developping our process in multi site. As we didn't =
want to
>>>>>>> add more complexity we decided to work only on one site =
(windows
>>>>>>> terminal server for the distant site) with one development =
branch in
>>>>>>> base CC.
>>>>>>> May be you have a successfull experience using CC multisite =
& UCM ?
>>>>>>> Can you share your experience ?
>>>>>>> Seems that in CC 7 (we use CC 6) the merge manager have a =
new option
>>>>>>> i.e. to always copy. So may be we can now have branches & =
multisite=20
>>>>>>> as
>>>>>>> now xmi file can be merged by a copy. I see here a potential =
source=20
>>>>>>> of
>>>>>>> trouble as we may surely end with invalid references if for =
instance
>>>>>>> the merge (copy) is done partially on some xmi ...
>>>>>>>
>>>>>>> Peter Haumer wrote:
>>>>>>>> Hello.
>>>>>>>> You cannot load multiple versions of the same plugin into =
the same
>>>>>>>> library. All library elements are identified by global =
unique ids=20
>>>>>>>> and
>>>>>>>> hence such ids needs to be unique. To get more than one =
copy of an
>>>>>>>> element you need to use the copy operation in the library =
view. In
>>>>>>>> general we recommend to use a version control system like =
Rational
>>>>>>>> ClearCase which allows you to label and restore old =
versions of=20
>>>>>>>> whole
>>>>>>>> groups of files.
>>>>>>>>
>>>>>>>> Best regards,
>>>>>>>> Peter.
>>>>>>>>
>>>>>>>> P.S.: Surely they should not be an exception when loading =
the same
>>>>>>>> content twice, but an error message. Please, file a =
bugzilla with
>>>>>>>> reproducible steps.
>>>>>>>>
>>>>>>>>
>>>>>>>> "K.Benameur" <benameur@freesurf.fr> wrote in message
>>>>>>>> news:f973f4$goo$1@build.eclipse.org...
>>>>>>>>> Hi all,
>>>>>>>>>
>>>>>>>>> It is a very good question. May be it can be addressed by =
an=20
>>>>>>>>> update
>>>>>>>>> of an existing guideline as the Development Guideline ?
>>>>>>>>>
>>>>>>>>> I think that we should have a "recommended" procedure from =
the EPF
>>>>>>>>> team to update plug-ins to a new version.
>>>>>>>>> It is now a fairly common scenario that multiple versions =
of the
>>>>>>>>> same plug-ins are out.
>>>>>>>>>
>>>>>>>>> And it is not only related to Open Up but for any library =
/=20
>>>>>>>>> plug-in
>>>>>>>>> as part of the development process (we are developing our =
own
>>>>>>>>> library / plug-ins without Open Up).
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> In short, what is the recommended procedure to migrate to =
a new
>>>>>>>>> version ? Do we have to export / import ? What are the =
risks? What
>>>>>>>>> we may lose ?
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Best Regards
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>
>=20
------=_NextPart_000_0047_01C7F089.063F8380
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML xmlns:o =3D "urn:schemas-microsoft-com:office:office"><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2900.3132" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>>>> <FONT size=3D3><FONT=20
face=3D"Times New Roman">I wanted to clarify if it really is =
the case=20
that EPF Composer is designed to be primarily used to maintain OpenUP=20
only. </FONT></FONT></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><FONT size=3D3><FONT=20
face=3D"Times New Roman"></FONT></FONT></FONT> </DIV>
<DIV><FONT><FONT><FONT face=3DArial><FONT size=3D2>It is not really the=20
case.</FONT></FONT></FONT></FONT></DIV>
<DIV><FONT><FONT><FONT face=3DArial><FONT=20
size=3D2></FONT></FONT></FONT></FONT> </DIV>
<DIV><FONT><FONT><FONT face=3DArial><FONT size=3D2>EPF Composer is used =
by the EPF=20
team to maintain OpenUP, DSDM, Scrum, XP and any other processes being =
captured=20
today and in the future under the EPF =
project.</FONT></FONT></FONT></FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>Moreover, EPF users can capture their =
own=20
home-grown processes or extensions to available processes using EPF=20
Composer.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>I hope this clarifies your =
question.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>Regards,</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>Ricardo Balduino.</FONT></DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
<DIV>"Kamal Ahluwalia" <<A=20
href=3D"mailto:kamal@osellus.com">kamal@osellus.com</A>> wrote in =
message <A=20
=
href=3D"news:fbpmjg$rai$1@build.eclipse.org">news:fbpmjg$rai$1@build.ecli=
pse.org</A>...</DIV>
<DIV><FONT face=3DArial size=3D2>
<P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><FONT =
size=3D3><FONT=20
face=3D"Times New Roman">=93EPF Composer is designed to support a =
single project=20
per library only as it is primary used to maintain=20
OpenUP=94.<o:p></o:p></FONT></FONT></P>
<P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><o:p><FONT=20
face=3D"Times New Roman" size=3D3> </FONT></o:p></P>
<P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><FONT =
size=3D3><FONT=20
face=3D"Times New Roman">I wanted to clarify if it really is =
the case=20
that EPF Composer is designed to be primarily used to maintain OpenUP =
only.=20
<o:p></o:p></FONT></FONT></P>
<P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><o:p><FONT=20
face=3D"Times New Roman" size=3D3> </FONT></o:p></P>
<P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><FONT =
size=3D3><FONT=20
face=3D"Times New =
Roman">Kamal<o:p></o:p></FONT></FONT></P></FONT></DIV >
<BLOCKQUOTE=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
<DIV>"Roman Smirak" <<A=20
=
href=3D"mailto:roman.smirak@tietoenator.com">roman.smirak@tietoenator.com=
</A>>=20
wrote in message <A=20
=
href=3D"news:f9rjjo$50e$1@build.eclipse.org">news:f9rjjo$50e$1@build.ecli=
pse.org</A>...</DIV>Hi=20
Peter,<BR><BR> that is great, the implementation =
perfectly=20
matches with my vision. Why <BR>not to have it in EPF? I guess many =
users=20
would welcome the feature.<BR><BR>We have licences of RMC, however, =
we=20
prefer to use EPF since early releases <BR>are=20
available.<BR><BR>Regards,<BR><BR>Roman<BR><BR>"Peter Haumer" <<A =
href=3D"mailto:phaumer@us.ibm.com">phaumer@us.ibm.com</A>> wrote =
in message=20
<BR><A=20
=
href=3D"news:f9qa5o$jac$1@build.eclipse.org">news:f9qa5o$jac$1@build.ecli=
pse.org</A>...<BR>>=20
Hello Roman.<BR>> Well, if our competitors can abuse this forum =
to plug=20
their products; so <BR>> can I :-)<BR>><BR>> RMC 7.2 does =
not need=20
the library.xmi file anymore as it uses the Eclipse <BR>> =
workspace's=20
projects to find all the files. Every plugin is a project as =
<BR>> well=20
as you can create more than one project for managing configurations =
<BR>>=20
and one project for estimation data (another RMC added value). The =
problem=20
<BR>> view is used just as in Eclipse to tell you if you are =
missing=20
elements in <BR>> your workspace that other elements depend =
upon. =20
You could ignore those <BR>> errors or fix them by loading the =
project's=20
that contain the missing <BR>> elements.<BR>><BR>> See the =
attached=20
image with an example where I was using plugins managed <BR>> in =
CVS and=20
plugins managed in CC all at the same time in the same <BR>> =
workspace.=20
Plugins can now reside in complete different directories even =
<BR>> on=20
different machine. Just like Eclipse projects, you load them =
into your=20
<BR>> workspace and use them whenever you need to use=20
them.<BR>><BR>> However, RMC can still generate a library.xmi =
for you=20
to manage libraries <BR>> that are fully compatible with EPF =
Composer.=20
For example, if you check the <BR>> OpenUP CVS repository: it =
already has=20
project files in each plugin <BR>> directory. That is =
because I was=20
already working with OpenUP in RMC 7.2; <BR>> at the same time =
where the=20
rest of the team continued working with EPF <BR>> Composer. =
Two=20
ways of loading the same library in a fully compatible =
way.<BR>><BR>>=20
Hope this helps,<BR>> Peter.<BR>><BR>><BR>><BR>> =
"Roman=20
Smirak" <<A=20
=
href=3D"mailto:roman.smirak@tietoenator.com">roman.smirak@tietoenator.com=
</A>>=20
wrote in message <BR>> <A=20
=
href=3D"news:f9p6up$mmu$1@build.eclipse.org">news:f9p6up$mmu$1@build.ecli=
pse.org</A>...<BR>>>=20
Hi Peter,<BR>>><BR>>> thanks for info, =
however, RMC=20
is based on EPF and I see current <BR>>> solution<BR>>> =
of EPF=20
(library.xml) as a fundamental constraint for clear & easy =
<BR>>>=20
solution<BR>>> at RMC level. Or?<BR>>><BR>>> Can =
you=20
please describe the scenario with RMC how it will be=20
implemented?<BR>>><BR>>> Or shall I post this at IBM =
Rational=20
forum?<BR>>><BR>>> Roman<BR>>><BR>>> "Peter =
Haumer"=20
<<A href=3D"mailto:phaumer@us.ibm.com">phaumer@us.ibm.com</A>> =
wrote in=20
message<BR>>> <A=20
=
href=3D"news:f9o54i$924$1@build.eclipse.org">news:f9o54i$924$1@build.ecli=
pse.org</A>...<BR>>>>=20
1) no, the guid remains the same<BR>>>> 2) not sure I =
understand=20
the context of this, but I would recommend to<BR>>>> only =
version=20
manage your own files and if you are using cvs directly =
get<BR>>>>=20
the OpenUP sources from our server or if you use CC provide a =
zip/rar=20
<BR>>>> file<BR>>>> with the OpenUP files that =
users can=20
unzip as view-private files<BR>>>> 3) Rational Method =
Composer 7.2=20
will fully support this scenario, which <BR>>>> =
is<BR>>>>=20
not in scope for EPF Composer. For enterprise deployments and=20
full<BR>>>> scalability we recommend RMC in which every =
plugin can=20
be maintained as <BR>>>> an<BR>>>> eclipse project =
and=20
loaded when needed. In addition we provide project<BR>>>> =
types for=20
configurations, enterprise reports, and estimation models =
in<BR>>>>=20
RMC. EPF Composer is designed to support a single project per=20
library<BR>>>> only as it is primary used to maintain =
OpenUP. =20
A workaround for you <BR>>>> would<BR>>>> be what =
I=20
described above for (2).<BR>>>><BR>>>> Best=20
regards,<BR>>>> Peter=20
Haumer.<BR>>>><BR>>>> <BR>>>> "Roman =
Smirak"=20
<<A=20
=
href=3D"mailto:roman.smirak@tietoenator.com">roman.smirak@tietoenator.com=
</A>>=20
wrote in message<BR>>>> <A=20
=
href=3D"news:f9kcmi$idh$1@build.eclipse.org">news:f9kcmi$idh$1@build.ecli=
pse.org</A>...<BR>>>>>=20
Hi Ricardo,<BR>>>>><BR>>>>> the =
way you=20
described below is the one I've been using so far; =
<BR>>>>>=20
however,<BR>>>>> I have few issues =
here:<BR>>>>> 1/=20
What if you refactor the content of OpenUP, e.g. an element I=20
was<BR>>>>> referencing to is no longer in same package =
or=20
plugin? Is there any<BR>>>>> impact on=20
UID?<BR>>>>><BR>>>>> 2/ Currently we have =
the whole=20
library in a versioning repository,<BR>>>>> although =
everyone=20
has got the basis (OpenUP, or RUP) with the tool =
<BR>>>>>=20
(EMC,<BR>>>>> or RMC) - no problem for OpenUP, in case =
of RUP,=20
well we are talking<BR>>>>> about 60MB or so (which you =
have to=20
check in every time you =
migrate)<BR>>>>><BR>>>>> 3/=20
Let say we have a common basis in our department X, let's call=20
it<BR>>>>> OpenUP/X; there is a project A which will use =
it plus=20
extension A minus<BR>>>>> irrelevant content from basis; =
in case=20
of eclipse plugins they simply<BR>>>>> check out =
required=20
plugins (they stay in touch with their updates =
by<BR>>>>>=20
department X authority) but they don't check out irrelevant plugins=20
(no<BR>>>>> mess) + create their new one and check it in =
their=20
repository (will be<BR>>>>> maintained there); currently =
they=20
need to check out whole library X +<BR>>>>> submit their =
plugins=20
A into the library shared by others (and they do<BR>>>>> =
same=20
action as well =3D> mess X + A + B + C, etc.) in order to fulfil=20
the<BR>>>>> use case (the basis maintained by =
department, a=20
project extension<BR>>>>> maintained by the project=20
itself)<BR>>>>><BR>>>>> I see the =
library.xml as a=20
big constraint in this use =
case.<BR>>>>><BR>>>>>=20
Regards,<BR>>>>><BR>>>>>=20
Roman<BR>>>>><BR>>>>> "Ricardo Balduino" =
<<A=20
href=3D"mailto:balduino@us.ibm.com">balduino@us.ibm.com</A>> =
wrote in=20
message<BR>>>>> <A=20
=
href=3D"news:f9itco$87k$1@build.eclipse.org">news:f9itco$87k$1@build.ecli=
pse.org</A>...<BR>>>>>>=20
In first paragraph I meant less cumbersome, yet safer=20
;-)<BR>>>>>><BR>>>>>> "Ricardo =
Balduino"=20
<<A =
href=3D"mailto:balduino@us.ibm.com">balduino@us.ibm.com</A>> wrote=20
in message<BR>>>>>> <A=20
=
href=3D"news:f9g8d0$db$1@build.eclipse.org">news:f9g8d0$db$1@build.eclips=
e.org</A>...<BR>>>>>>>=20
Option A sounds less cumbersome and safer, as the EPF Composer=20
tool<BR>>>>>>> will take care of the work. In =
fact,=20
according to your description of<BR>>>>>>> option =
A,=20
OpenUP 2.x would overwrite OpenUP=20
1.x.<BR>>>>>>><BR >>>>>>> Instead =
of=20
playing with importing a new OpenUP plug-in into=20
your<BR>>>>>>> existing library, have you =
considered=20
getting the new OpenUP library<BR>>>>>>> available =
and=20
import your plug-in into it instead? With that =
<BR>>>>>>>=20
approach,<BR>>>>>>> you are moving your plug-in =
around, so=20
you know there are no <BR>>>>>>>=20
duplicates<BR>>>>>>> of it in a brand new OpenUP =
library.=20
If your plug-in initially <BR>>>>>>>=20
depended<BR>>>>>>> on some OpenUP element that =
does not=20
exist anymore when a new version<BR>>>>>>> of =
OpenUP is=20
released, the import will show you warnings, which=20
will<BR>>>>>>> help you to spot where you need to =
maintain=20
your plug-in to extend <BR>>>>>>>=20
the<BR>>>>>>> most current version of OpenUP. =
Additions to=20
OpenUP will not affect<BR>>>>>>> your=20
plug-in.<BR>>>>>>> <BR>>>>>>>=20
Cheers,<BR>>>>>>> <BR>>>>>>> =
Ricardo=20
Balduino.<BR>>>>>>> <BR>>>>>>>=20
"K.Benameur" <<A=20
href=3D"mailto:benameur@freesurf.fr">benameur@freesurf.fr</A>> =
wrote in=20
message<BR>>>>>>> <A=20
=
href=3D"news:f9f8cn$ah0$1@build.eclipse.org">news:f9f8cn$ah0$1@build.ecli=
pse.org</A>...<BR>>>>>>>>=20
Hi =
Peter,<BR>>>>>>>> <BR>>>>>>>>=20
Sorry to bother you with all my questions=20
!!!<BR>>>>>>>> <BR>>>>>>>> =
I am not=20
sure that I have completly understood your=20
=
answer.<BR>>>>>>>> <BR>>>>>>>> =
To=20
check this I propose a simple scenario =20
:<BR> >>>>>>>& ;nbsp; - I develop a library =
using=20
Open Up 1.x.<BR> >>>>>>>& ;nbsp; - A new =
version of=20
Open Up is out let say 2.x<BR> >>>>>>>& ;nbsp; - I =
wan't=20
to take advantage of this new Open Up=20
=
version.<BR>>>>>>>> <BR>>>>>>>> =
A)=20
So ideally, I import the new version in my library and Open Up=20
<BR>>>>>>>> 1.x<BR>>>>>>>> =
is=20
updated to=20
2.x.<BR>>>>>>>> <BR>>>>>>>> =
I have=20
the feeling that it will not be so simple as many links will=20
<BR>>>>>>>> be<BR>>>>>>>> =
broken=20
due to changes between 1.X and=20
2.X.<BR>>>>>>>> <BR>>>>>>>> =
B) I=20
use the copy operation to have the 1.X & 2.X plugin in my=20
<BR>>>>>>>>=20
=
library<BR>>>>>>>> <BR>>>>>>>> =
It=20
seems that option B) is the one to go as you said that we have=20
to<BR>>>>>>>> do a copy as uuid must be=20
unique.<BR>>>>>>>>=20
=3D><BR>>>>>>>> I have to do the migration=20
manually by replacing elements of Open=20
<BR>>>>>>>> 1.x<BR>>>>>>>> =
by=20
their counterparts in=20
2.x.<BR>>>>>>>> <BR>>>>>>>> =
is it=20
right or I missed something like a smart import that=20
detect<BR>>>>>>>> conflicts and propose to =
update=20
automatically element that exist in<BR>>>>>>>> =
1.X=20
& 2.X /delete obsolete element of 1.X / etc..=20
?<BR>>>>>>>> <BR>>>>>>>> =
The=20
question is what is the recommended procedure to perform a=20
<BR>>>>>>>> =
plug-in<BR>>>>>>>>=20
upgrade with a minimum effort=20
?<BR>>>>>>>> <BR>>>>>>>> My =
concern=20
will be the maintenance cost of a library. If we build=20
<BR>>>>>>>> our<BR>>>>>>>> =
library=20
from many commercial or non commercial plugins we have to=20
<BR>>>>>>>> =
deal<BR>>>>>>>> with=20
their evolutions at a minimal=20
=
cost.<BR>>>>>>>> <BR>>>>>>>> <BR>=
>>>>>>><BR >>>>>>>><BR >>>&=
gt;>>>>=20
Best Regards=20
...<BR>>>>>>>> <BR>>>>>>>> =
PS: I=20
will be in vacation for the next 2 weeks so you have plenty=20
of<BR>>>>>>>> time for an anwser=20
=
;)<BR>>>>>>>> <BR>>>>>>>> <BR>>=
;>>>>>>=20
PS:<BR> >>>>>>>& ;nbsp; We use ClearCase but it =
will not=20
help here except to roll back to a<BR>>>>>>>> =
stable=20
baseline and lock elements for modification=20
...<BR> >>>>>>>& ;nbsp; We are developping our =
process in=20
multi site. As we didn't want to<BR>>>>>>>> add =
more=20
complexity we decided to work only on one site=20
(windows<BR>>>>>>>> terminal server for the =
distant=20
site) with one development branch in<BR>>>>>>>> =
base=20
CC.<BR>>>>>>>> May be you have a successfull =
experience=20
using CC multisite & UCM ?<BR>>>>>>>> Can =
you share=20
your experience ?<BR>>>>>>>> Seems that in CC 7 =
(we use=20
CC 6) the merge manager have a new =
option<BR>>>>>>>>=20
i.e. to always copy. So may be we can now have branches & =
multisite=20
<BR>>>>>>>> as<BR>>>>>>>> =
now xmi=20
file can be merged by a copy. I see here a potential source=20
<BR>>>>>>>> of<BR>>>>>>>> =
trouble=20
as we may surely end with invalid references if for=20
instance<BR>>>>>>>> the merge (copy) is done =
partially=20
on some xmi=20
...<BR>>>>>>>> <BR>>>>>>>> =
Peter=20
Haumer wrote:<BR> >>>>>>>& ;gt;=20
Hello.<BR> >>>>>>>& ;gt; You cannot load multiple =
versions=20
of the same plugin into the same<BR> >>>>>>>& ;gt; =
library. All library elements are identified by global unique ids=20
<BR> >>>>>>>& ;gt; =
and<BR> >>>>>>>& ;gt;=20
hence such ids needs to be unique. To get more than one copy =
of=20
an<BR> >>>>>>>& ;gt; element you need to use the =
copy=20
operation in the library view. =
In<BR> >>>>>>>& ;gt;=20
general we recommend to use a version control system like=20
Rational<BR> >>>>>>>& ;gt; ClearCase which allows =
you to=20
label and restore old versions of =
<BR> >>>>>>>& ;gt;=20
whole<BR> >>>>>>>& ;gt; groups of=20
=
files.<BR> >>>>>>>& ;gt; <BR>>>>>>>>=
;>=20
Best regards,<BR> >>>>>>>& ;gt;=20
=
Peter.<BR> >>>>>>>& ;gt; <BR>>>>>>>>=
;>=20
P.S.: Surely they should not be an exception when loading the=20
same<BR> >>>>>>>& ;gt; content twice, but an error =
message. Please, file a bugzilla=20
with<BR> >>>>>>>& ;gt; reproducible=20
=
steps.<BR> >>>>>>>& ;gt; <BR>>>>>>>>=
;><BR> >>>>>>>& ;gt;=20
"K.Benameur" <<A=20
href=3D"mailto:benameur@freesurf.fr">benameur@freesurf.fr</A>> =
wrote in=20
message<BR> >>>>>>>& ;gt; <A=20
=
href=3D"news:f973f4$goo$1@build.eclipse.org">news:f973f4$goo$1@build.ecli=
pse.org</A>...<BR> >>>>>>>& ;gt;>=20
Hi=20
=
all,<BR> >>>>>>>& ;gt;> <BR>>>>>>>&=
gt;>>=20
It is a very good question. May be it can be addressed by an=20
<BR> >>>>>>>& ;gt;>=20
update<BR> >>>>>>>& ;gt;> of an existing =
guideline as=20
the Development Guideline=20
=
?<BR> >>>>>>>& ;gt;> <BR>>>>>>>>=
>>=20
I think that we should have a "recommended" procedure from the=20
EPF<BR> >>>>>>>& ;gt;> team to update plug-ins =
to a new=20
version.<BR> >>>>>>>& ;gt;> It is now a =
fairly=20
common scenario that multiple versions of=20
the<BR> >>>>>>>& ;gt;> same plug-ins are=20
=
out.<BR> >>>>>>>& ;gt;> <BR>>>>>>>&=
gt;>>=20
And it is not only related to Open Up but for any library /=20
<BR> >>>>>>>& ;gt;>=20
plug-in<BR> >>>>>>>& ;gt;> as part of the =
development=20
process (we are developing our =
own<BR> >>>>>>>& ;gt;>=20
library / plug-ins without Open=20
=
Up).<BR> >>>>>>>& ;gt;> <BR>>>>>>>&=
gt;>><BR> >>>>>>>& ;gt;> =20
In short, what is the recommended procedure to migrate to a=20
new<BR> >>>>>>>& ;gt;> version ? Do we have to =
export /=20
import ? What are the risks? =
What<BR> >>>>>>>& ;gt;> we=20
may lose=20
=
?<BR> >>>>>>>& ;gt;> <BR>>>>>>>>=
>><BR> >>>>>>>& ;gt;>=20
Best=20
=
Regards<BR> >>>>>>>& ;gt;> <BR>>>>>>&g=
t;>>><BR> >>>>>>>& ;gt; <BR>>>>>>=
;><BR>>>>>><BR>>>>>> <BR>>>>>=
<BR>>>>><BR>>>> <BR>>>><BR>>><BR>>&=
gt;<BR>><BR>><BR>>=20
<BR><BR></BLOCKQUOTE></BLOCKQUOTE></BODY></HTML>
------=_NextPart_000_0047_01C7F089.063F8380--
|
|
|
| Re: Migration to newever library version [message #582903 is a reply to message #39929] |
Thu, 06 September 2007 21:22 |
| Eclipse User |
|
|
|
Originally posted by: kamal.osellus.com
This is a multi-part message in MIME format.
------=_NextPart_000_003F_01C7F0AA.74CD32E0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Thanks for your response Ricardo.
=20
This thread highlights some of the fundamental constraints in using EPF =
Composer, especially library.xml to maintain processes. It appears RMC =
7.2 addresses some of these problems. Are there any plans to donate =
those bits to EPF so that the community can benefit ?
=20
Kamal=20
"Ricardo Balduino" <balduino@us.ibm.com> wrote in message =
news:fbpnj1$24t$1@build.eclipse.org...
>>> I wanted to clarify if it really is the case that EPF Composer is =
designed to be primarily used to maintain OpenUP only. =20
It is not really the case.
EPF Composer is used by the EPF team to maintain OpenUP, DSDM, Scrum, =
XP and any other processes being captured today and in the future under =
the EPF project.
Moreover, EPF users can capture their own home-grown processes or =
extensions to available processes using EPF Composer.
I hope this clarifies your question.
Regards,
Ricardo Balduino.
"Kamal Ahluwalia" <kamal@osellus.com> wrote in message =
news:fbpmjg$rai$1@build.eclipse.org...
"EPF Composer is designed to support a single project per library =
only as it is primary used to maintain OpenUP".
=20
I wanted to clarify if it really is the case that EPF Composer is =
designed to be primarily used to maintain OpenUP only. =20
=20
Kamal
"Roman Smirak" <roman.smirak@tietoenator.com> wrote in message =
news:f9rjjo$50e$1@build.eclipse.org...
Hi Peter,
that is great, the implementation perfectly matches with my =
vision. Why=20
not to have it in EPF? I guess many users would welcome the =
feature.
We have licences of RMC, however, we prefer to use EPF since early =
releases=20
are available.
Regards,
Roman
"Peter Haumer" <phaumer@us.ibm.com> wrote in message=20
news:f9qa5o$jac$1@build.eclipse.org...
> Hello Roman.
> Well, if our competitors can abuse this forum to plug their =
products; so=20
> can I :-)
>
> RMC 7.2 does not need the library.xmi file anymore as it uses =
the Eclipse=20
> workspace's projects to find all the files. Every plugin is a =
project as=20
> well as you can create more than one project for managing =
configurations=20
> and one project for estimation data (another RMC added value). =
The problem=20
> view is used just as in Eclipse to tell you if you are missing =
elements in=20
> your workspace that other elements depend upon. You could =
ignore those=20
> errors or fix them by loading the project's that contain the =
missing=20
> elements.
>
> See the attached image with an example where I was using plugins =
managed=20
> in CVS and plugins managed in CC all at the same time in the =
same=20
> workspace. Plugins can now reside in complete different =
directories even=20
> on different machine. Just like Eclipse projects, you load them =
into your=20
> workspace and use them whenever you need to use them.
>
> However, RMC can still generate a library.xmi for you to manage =
libraries=20
> that are fully compatible with EPF Composer. For example, if you =
check the=20
> OpenUP CVS repository: it already has project files in each =
plugin=20
> directory. That is because I was already working with OpenUP in =
RMC 7.2;=20
> at the same time where the rest of the team continued working =
with EPF=20
> Composer. Two ways of loading the same library in a fully =
compatible way.
>
> Hope this helps,
> Peter.
>
>
>
> "Roman Smirak" <roman.smirak@tietoenator.com> wrote in message=20
> news:f9p6up$mmu$1@build.eclipse.org...
>> Hi Peter,
>>
>> thanks for info, however, RMC is based on EPF and I see =
current=20
>> solution
>> of EPF (library.xml) as a fundamental constraint for clear & =
easy=20
>> solution
>> at RMC level. Or?
>>
>> Can you please describe the scenario with RMC how it will be =
implemented?
>>
>> Or shall I post this at IBM Rational forum?
>>
>> Roman
>>
>> "Peter Haumer" <phaumer@us.ibm.com> wrote in message
>> news:f9o54i$924$1@build.eclipse.org...
>>> 1) no, the guid remains the same
>>> 2) not sure I understand the context of this, but I would =
recommend to
>>> only version manage your own files and if you are using cvs =
directly get
>>> the OpenUP sources from our server or if you use CC provide a =
zip/rar=20
>>> file
>>> with the OpenUP files that users can unzip as view-private =
files
>>> 3) Rational Method Composer 7.2 will fully support this =
scenario, which=20
>>> is
>>> not in scope for EPF Composer. For enterprise deployments and =
full
>>> scalability we recommend RMC in which every plugin can be =
maintained as=20
>>> an
>>> eclipse project and loaded when needed. In addition we provide =
project
>>> types for configurations, enterprise reports, and estimation =
models in
>>> RMC. EPF Composer is designed to support a single project per =
library
>>> only as it is primary used to maintain OpenUP. A workaround =
for you=20
>>> would
>>> be what I described above for (2).
>>>
>>> Best regards,
>>> Peter Haumer.
>>>
>>>
>>> "Roman Smirak" <roman.smirak@tietoenator.com> wrote in message
>>> news:f9kcmi$idh$1@build.eclipse.org...
>>>> Hi Ricardo,
>>>>
>>>> the way you described below is the one I've been using so =
far;=20
>>>> however,
>>>> I have few issues here:
>>>> 1/ What if you refactor the content of OpenUP, e.g. an =
element I was
>>>> referencing to is no longer in same package or plugin? Is =
there any
>>>> impact on UID?
>>>>
>>>> 2/ Currently we have the whole library in a versioning =
repository,
>>>> although everyone has got the basis (OpenUP, or RUP) with the =
tool=20
>>>> (EMC,
>>>> or RMC) - no problem for OpenUP, in case of RUP, well we are =
talking
>>>> about 60MB or so (which you have to check in every time you =
migrate)
>>>>
>>>> 3/ Let say we have a common basis in our department X, let's =
call it
>>>> OpenUP/X; there is a project A which will use it plus =
extension A minus
>>>> irrelevant content from basis; in case of eclipse plugins =
they simply
>>>> check out required plugins (they stay in touch with their =
updates by
>>>> department X authority) but they don't check out irrelevant =
plugins (no
>>>> mess) + create their new one and check it in their repository =
(will be
>>>> maintained there); currently they need to check out whole =
library X +
>>>> submit their plugins A into the library shared by others (and =
they do
>>>> same action as well =3D> mess X + A + B + C, etc.) in order =
to fulfil the
>>>> use case (the basis maintained by department, a project =
extension
>>>> maintained by the project itself)
>>>>
>>>> I see the library.xml as a big constraint in this use case.
>>>>
>>>> Regards,
>>>>
>>>> Roman
>>>>
>>>> "Ricardo Balduino" <balduino@us.ibm.com> wrote in message
>>>> news:f9itco$87k$1@build.eclipse.org...
>>>>> In first paragraph I meant less cumbersome, yet safer ;-)
>>>>>
>>>>> "Ricardo Balduino" <balduino@us.ibm.com> wrote in message
>>>>> news:f9g8d0$db$1@build.eclipse.org...
>>>>>> Option A sounds less cumbersome and safer, as the EPF =
Composer tool
>>>>>> will take care of the work. In fact, according to your =
description of
>>>>>> option A, OpenUP 2.x would overwrite OpenUP 1.x.
>>>>>>
>>>>>> Instead of playing with importing a new OpenUP plug-in into =
your
>>>>>> existing library, have you considered getting the new =
OpenUP library
>>>>>> available and import your plug-in into it instead? With =
that=20
>>>>>> approach,
>>>>>> you are moving your plug-in around, so you know there are =
no=20
>>>>>> duplicates
>>>>>> of it in a brand new OpenUP library. If your plug-in =
initially=20
>>>>>> depended
>>>>>> on some OpenUP element that does not exist anymore when a =
new version
>>>>>> of OpenUP is released, the import will show you warnings, =
which will
>>>>>> help you to spot where you need to maintain your plug-in to =
extend=20
>>>>>> the
>>>>>> most current version of OpenUP. Additions to OpenUP will =
not affect
>>>>>> your plug-in.
>>>>>>
>>>>>> Cheers,
>>>>>>
>>>>>> Ricardo Balduino.
>>>>>>
>>>>>> "K.Benameur" <benameur@freesurf.fr> wrote in message
>>>>>> news:f9f8cn$ah0$1@build.eclipse.org...
>>>>>>> Hi Peter,
>>>>>>>
>>>>>>> Sorry to bother you with all my questions !!!
>>>>>>>
>>>>>>> I am not sure that I have completly understood your =
answer.
>>>>>>>
>>>>>>> To check this I propose a simple scenario :
>>>>>>> - I develop a library using Open Up 1.x.
>>>>>>> - A new version of Open Up is out let say 2.x
>>>>>>> - I wan't to take advantage of this new Open Up version.
>>>>>>>
>>>>>>> A) So ideally, I import the new version in my library and =
Open Up=20
>>>>>>> 1.x
>>>>>>> is updated to 2.x.
>>>>>>>
>>>>>>> I have the feeling that it will not be so simple as many =
links will=20
>>>>>>> be
>>>>>>> broken due to changes between 1.X and 2.X.
>>>>>>>
>>>>>>> B) I use the copy operation to have the 1.X & 2.X plugin =
in my=20
>>>>>>> library
>>>>>>>
>>>>>>> It seems that option B) is the one to go as you said that =
we have to
>>>>>>> do a copy as uuid must be unique.
>>>>>>> =3D>
>>>>>>> I have to do the migration manually by replacing elements =
of Open=20
>>>>>>> 1.x
>>>>>>> by their counterparts in 2.x.
>>>>>>>
>>>>>>> is it right or I missed something like a smart import that =
detect
>>>>>>> conflicts and propose to update automatically element that =
exist in
>>>>>>> 1.X & 2.X /delete obsolete element of 1.X / etc.. ?
>>>>>>>
>>>>>>> The question is what is the recommended procedure to =
perform a=20
>>>>>>> plug-in
>>>>>>> upgrade with a minimum effort ?
>>>>>>>
>>>>>>> My concern will be the maintenance cost of a library. If =
we build=20
>>>>>>> our
>>>>>>> library from many commercial or non commercial plugins we =
have to=20
>>>>>>> deal
>>>>>>> with their evolutions at a minimal cost.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Best Regards ...
>>>>>>>
>>>>>>> PS: I will be in vacation for the next 2 weeks so you have =
plenty of
>>>>>>> time for an anwser ;)
>>>>>>>
>>>>>>>
>>>>>>> PS:
>>>>>>> We use ClearCase but it will not help here except to roll =
back to a
>>>>>>> stable baseline and lock elements for modification ...
>>>>>>> We are developping our process in multi site. As we =
didn't want to
>>>>>>> add more complexity we decided to work only on one site =
(windows
>>>>>>> terminal server for the distant site) with one development =
branch in
>>>>>>> base CC.
>>>>>>> May be you have a successfull experience using CC =
multisite & UCM ?
>>>>>>> Can you share your experience ?
>>>>>>> Seems that in CC 7 (we use CC 6) the merge manager have a =
new option
>>>>>>> i.e. to always copy. So may be we can now have branches & =
multisite=20
>>>>>>> as
>>>>>>> now xmi file can be merged by a copy. I see here a =
potential source=20
>>>>>>> of
>>>>>>> trouble as we may surely end with invalid references if =
for instance
>>>>>>> the merge (copy) is done partially on some xmi ...
>>>>>>>
>>>>>>> Peter Haumer wrote:
>>>>>>>> Hello.
>>>>>>>> You cannot load multiple versions of the same plugin into =
the same
>>>>>>>> library. All library elements are identified by global =
unique ids=20
>>>>>>>> and
>>>>>>>> hence such ids needs to be unique. To get more than one =
copy of an
>>>>>>>> element you need to use the copy operation in the library =
view. In
>>>>>>>> general we recommend to use a version control system like =
Rational
>>>>>>>> ClearCase which allows you to label and restore old =
versions of=20
>>>>>>>> whole
>>>>>>>> groups of files.
>>>>>>>>
>>>>>>>> Best regards,
>>>>>>>> Peter.
>>>>>>>>
>>>>>>>> P.S.: Surely they should not be an exception when loading =
the same
>>>>>>>> content twice, but an error message. Please, file a =
bugzilla with
>>>>>>>> reproducible steps.
>>>>>>>>
>>>>>>>>
>>>>>>>> "K.Benameur" <benameur@freesurf.fr> wrote in message
>>>>>>>> news:f973f4$goo$1@build.eclipse.org...
>>>>>>>>> Hi all,
>>>>>>>>>
>>>>>>>>> It is a very good question. May be it can be addressed =
by an=20
>>>>>>>>> update
>>>>>>>>> of an existing guideline as the Development Guideline ?
>>>>>>>>>
>>>>>>>>> I think that we should have a "recommended" procedure =
from the EPF
>>>>>>>>> team to update plug-ins to a new version.
>>>>>>>>> It is now a fairly common scenario that multiple =
versions of the
>>>>>>>>> same plug-ins are out.
>>>>>>>>>
>>>>>>>>> And it is not only related to Open Up but for any =
library /=20
>>>>>>>>> plug-in
>>>>>>>>> as part of the development process (we are developing =
our own
>>>>>>>>> library / plug-ins without Open Up).
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> In short, what is the recommended procedure to migrate =
to a new
>>>>>>>>> version ? Do we have to export / import ? What are the =
risks? What
>>>>>>>>> we may lose ?
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Best Regards
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>
>=20
------=_NextPart_000_003F_01C7F0AA.74CD32E0
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML xmlns:o =3D "urn:schemas-microsoft-com:office:office"><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.6000.16527" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>
<P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><SPAN=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman','serif'">Thanks =
for your=20
response Ricardo.<o:p></o:p></SPAN></P>
<P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><SPAN=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New =
Roman','serif'"><o:p> </o:p></SPAN></P>
<P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><SPAN=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman','serif'">This =
thread=20
highlights some of the fundamental constraints in using EPF Composer, =
especially=20
library.xml to maintain processes. It appears RMC 7.2 addresses some of =
these=20
problems. Are there any plans to donate those bits to EPF so that the =
community=20
can benefit ?<o:p></o:p></SPAN></P>
<P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><SPAN=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New =
Roman','serif'"><o:p> </o:p></SPAN></P>
<P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><SPAN=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman','serif'">Kamal=20
<o:p></o:p></SPAN></P></FONT></DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
<DIV>"Ricardo Balduino" <<A=20
href=3D"mailto:balduino@us.ibm.com">balduino@us.ibm.com</A>> wrote =
in message=20
<A=20
=
href=3D"news:fbpnj1$24t$1@build.eclipse.org">news:fbpnj1$24t$1@build.ecli=
pse.org</A>...</DIV>
<DIV><FONT face=3DArial size=3D2>>>> <FONT size=3D3><FONT=20
face=3D"Times New Roman">I wanted to clarify if it really is =
the case=20
that EPF Composer is designed to be primarily used to maintain OpenUP=20
only. </FONT></FONT></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><FONT size=3D3><FONT=20
face=3D"Times New Roman"></FONT></FONT></FONT> </DIV>
<DIV><FONT size=3D+0><FONT size=3D+0><FONT face=3DArial><FONT =
size=3D2>It is not=20
really the case.</FONT></FONT></FONT></FONT></DIV>
<DIV><FONT size=3D+0><FONT size=3D+0><FONT face=3DArial><FONT=20
size=3D2></FONT></FONT></FONT></FONT> </DIV>
<DIV><FONT size=3D+0><FONT size=3D+0><FONT face=3DArial><FONT =
size=3D2>EPF Composer is=20
used by the EPF team to maintain OpenUP, DSDM, Scrum, XP and any other =
processes being captured today and in the future under the EPF=20
project.</FONT></FONT></FONT></FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>Moreover, EPF users can capture their =
own=20
home-grown processes or extensions to available processes using EPF=20
Composer.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>I hope this clarifies your =
question.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>Regards,</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>Ricardo Balduino.</FONT></DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
<DIV>"Kamal Ahluwalia" <<A=20
href=3D"mailto:kamal@osellus.com">kamal@osellus.com</A>> wrote in =
message=20
<A=20
=
href=3D"news:fbpmjg$rai$1@build.eclipse.org">news:fbpmjg$rai$1@build.ecli=
pse.org</A>...</DIV>
<DIV><FONT face=3DArial size=3D2>
<P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><FONT =
size=3D3><FONT=20
face=3D"Times New Roman">=93EPF Composer is designed to support a =
single project=20
per library only as it is primary used to maintain=20
OpenUP=94.<o:p></o:p></FONT></FONT></P>
<P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><o:p><FONT=20
face=3D"Times New Roman" size=3D3> </FONT></o:p></P>
<P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><FONT =
size=3D3><FONT=20
face=3D"Times New Roman">I wanted to clarify if it really =
is the=20
case that EPF Composer is designed to be primarily used to maintain =
OpenUP=20
only. <o:p></o:p></FONT></FONT></P>
<P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><o:p><FONT=20
face=3D"Times New Roman" size=3D3> </FONT></o:p></P>
<P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><FONT =
size=3D3><FONT=20
face=3D"Times New =
Roman">Kamal<o:p></o:p></FONT></FONT></P></FONT></DIV >
<BLOCKQUOTE=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
<DIV>"Roman Smirak" <<A=20
=
href=3D"mailto:roman.smirak@tietoenator.com">roman.smirak@tietoenator.com=
</A>>=20
wrote in message <A=20
=
href=3D"news:f9rjjo$50e$1@build.eclipse.org">news:f9rjjo$50e$1@build.ecli=
pse.org</A>...</DIV>Hi=20
Peter,<BR><BR> that is great, the implementation =
perfectly=20
matches with my vision. Why <BR>not to have it in EPF? I guess =
many users=20
would welcome the feature.<BR><BR>We have licences of RMC, =
however, we=20
prefer to use EPF since early releases <BR>are=20
available.<BR><BR>Regards,<BR><BR>Roman<BR><BR>"Peter Haumer" =
<<A=20
href=3D"mailto:phaumer@us.ibm.com">phaumer@us.ibm.com</A>> =
wrote in=20
message <BR><A=20
=
href=3D"news:f9qa5o$jac$1@build.eclipse.org">news:f9qa5o$jac$1@build.ecli=
pse.org</A>...<BR>>=20
Hello Roman.<BR>> Well, if our competitors can abuse this forum =
to plug=20
their products; so <BR>> can I :-)<BR>><BR>> RMC 7.2 does =
not=20
need the library.xmi file anymore as it uses the Eclipse <BR>>=20
workspace's projects to find all the files. Every plugin is a =
project as=20
<BR>> well as you can create more than one project for managing =
configurations <BR>> and one project for estimation data =
(another RMC=20
added value). The problem <BR>> view is used just as in Eclipse =
to tell=20
you if you are missing elements in <BR>> your workspace that =
other=20
elements depend upon. You could ignore those <BR>> errors =
or fix=20
them by loading the project's that contain the missing <BR>>=20
elements.<BR>><BR>> See the attached image with an example =
where I=20
was using plugins managed <BR>> in CVS and plugins managed in =
CC all at=20
the same time in the same <BR>> workspace. Plugins can now =
reside in=20
complete different directories even <BR>> on different =
machine. =20
Just like Eclipse projects, you load them into your <BR>> =
workspace and=20
use them whenever you need to use them.<BR>><BR>> However, =
RMC can=20
still generate a library.xmi for you to manage libraries <BR>> =
that are=20
fully compatible with EPF Composer. For example, if you check the =
<BR>>=20
OpenUP CVS repository: it already has project files in each plugin =
<BR>> directory. That is because I was already working =
with=20
OpenUP in RMC 7.2; <BR>> at the same time where the rest of the =
team=20
continued working with EPF <BR>> Composer. Two ways of =
loading=20
the same library in a fully compatible way.<BR>><BR>> Hope =
this=20
helps,<BR>> Peter.<BR>><BR>><BR>><BR>> "Roman =
Smirak"=20
<<A=20
=
href=3D"mailto:roman.smirak@tietoenator.com">roman.smirak@tietoenator.com=
</A>>=20
wrote in message <BR>> <A=20
=
href=3D"news:f9p6up$mmu$1@build.eclipse.org">news:f9p6up$mmu$1@build.ecli=
pse.org</A>...<BR>>>=20
Hi Peter,<BR>>><BR>>> thanks for info, =
however,=20
RMC is based on EPF and I see current <BR>>> =
solution<BR>>> of=20
EPF (library.xml) as a fundamental constraint for clear & easy =
<BR>>> solution<BR>>> at RMC level.=20
Or?<BR>>><BR>>> Can you please describe the scenario =
with RMC=20
how it will be implemented?<BR>>><BR>>> Or shall I =
post this=20
at IBM Rational forum?<BR>>><BR>>>=20
Roman<BR>>><BR>>> "Peter Haumer" <<A=20
href=3D"mailto:phaumer@us.ibm.com">phaumer@us.ibm.com</A>> =
wrote in=20
message<BR>>> <A=20
=
href=3D"news:f9o54i$924$1@build.eclipse.org">news:f9o54i$924$1@build.ecli=
pse.org</A>...<BR>>>>=20
1) no, the guid remains the same<BR>>>> 2) not sure I =
understand=20
the context of this, but I would recommend to<BR>>>> only =
version=20
manage your own files and if you are using cvs directly=20
get<BR>>>> the OpenUP sources from our server or if you =
use CC=20
provide a zip/rar <BR>>>> file<BR>>>> with the =
OpenUP=20
files that users can unzip as view-private files<BR>>>> =
3)=20
Rational Method Composer 7.2 will fully support this scenario, =
which=20
<BR>>>> is<BR>>>> not in scope for EPF =
Composer. =20
For enterprise deployments and full<BR>>>> scalability we =
recommend RMC in which every plugin can be maintained as =
<BR>>>>=20
an<BR>>>> eclipse project and loaded when needed. In =
addition we=20
provide project<BR>>>> types for configurations, =
enterprise=20
reports, and estimation models in<BR>>>> RMC. EPF =
Composer=20
is designed to support a single project per =
library<BR>>>> only=20
as it is primary used to maintain OpenUP. A workaround for =
you=20
<BR>>>> would<BR>>>> be what I described above =
for=20
(2).<BR>>>><BR>>>> Best regards,<BR>>>> =
Peter=20
Haumer.<BR>>>><BR>>>> <BR>>>> "Roman =
Smirak"=20
<<A=20
=
href=3D"mailto:roman.smirak@tietoenator.com">roman.smirak@tietoenator.com=
</A>>=20
wrote in message<BR>>>> <A=20
=
href=3D"news:f9kcmi$idh$1@build.eclipse.org">news:f9kcmi$idh$1@build.ecli=
pse.org</A>...<BR>>>>>=20
Hi Ricardo,<BR>>>>><BR>>>>> =
the way=20
you described below is the one I've been using so far;=20
<BR>>>>> however,<BR>>>>> I have few =
issues=20
here:<BR>>>>> 1/ What if you refactor the content of =
OpenUP,=20
e.g. an element I was<BR>>>>> referencing to is no =
longer in=20
same package or plugin? Is there any<BR>>>>> impact on =
UID?<BR>>>>><BR>>>>> 2/ Currently we have =
the=20
whole library in a versioning repository,<BR>>>>> =
although=20
everyone has got the basis (OpenUP, or RUP) with the tool=20
<BR>>>>> (EMC,<BR>>>>> or RMC) - no =
problem for=20
OpenUP, in case of RUP, well we are talking<BR>>>>> =
about 60MB=20
or so (which you have to check in every time you=20
migrate)<BR>>>>><BR>>>>> 3/ Let say we =
have a=20
common basis in our department X, let's call =
it<BR>>>>>=20
OpenUP/X; there is a project A which will use it plus extension A=20
minus<BR>>>>> irrelevant content from basis; in case =
of=20
eclipse plugins they simply<BR>>>>> check out required =
plugins=20
(they stay in touch with their updates by<BR>>>>> =
department X=20
authority) but they don't check out irrelevant plugins=20
(no<BR>>>>> mess) + create their new one and check it =
in their=20
repository (will be<BR>>>>> maintained there); =
currently they=20
need to check out whole library X +<BR>>>>> submit =
their=20
plugins A into the library shared by others (and they=20
do<BR>>>>> same action as well =3D> mess X + A + B =
+ C, etc.)=20
in order to fulfil the<BR>>>>> use case (the basis =
maintained=20
by department, a project extension<BR>>>>> maintained =
by the=20
project itself)<BR>>>>><BR>>>>> I see the=20
library.xml as a big constraint in this use=20
case.<BR>>>>><BR>>>>>=20
Regards,<BR>>>>><BR>>>>>=20
Roman<BR>>>>><BR>>>>> "Ricardo Balduino" =
<<A=20
href=3D"mailto:balduino@us.ibm.com">balduino@us.ibm.com</A>> =
wrote in=20
message<BR>>>>> <A=20
=
href=3D"news:f9itco$87k$1@build.eclipse.org">news:f9itco$87k$1@build.ecli=
pse.org</A>...<BR>>>>>>=20
In first paragraph I meant less cumbersome, yet safer=20
;-)<BR>>>>>><BR>>>>>> "Ricardo =
Balduino"=20
<<A =
href=3D"mailto:balduino@us.ibm.com">balduino@us.ibm.com</A>> wrote=20
in message<BR>>>>>> <A=20
=
href=3D"news:f9g8d0$db$1@build.eclipse.org">news:f9g8d0$db$1@build.eclips=
e.org</A>...<BR>>>>>>>=20
Option A sounds less cumbersome and safer, as the EPF Composer=20
tool<BR>>>>>>> will take care of the work. In =
fact,=20
according to your description of<BR>>>>>>> =
option A,=20
OpenUP 2.x would overwrite OpenUP=20
1.x.<BR>>>>>>><BR >>>>>>> =
Instead of=20
playing with importing a new OpenUP plug-in into=20
your<BR>>>>>>> existing library, have you =
considered=20
getting the new OpenUP library<BR>>>>>>> =
available and=20
import your plug-in into it instead? With that=20
<BR>>>>>>> approach,<BR>>>>>>> =
you are=20
moving your plug-in around, so you know there are no=20
<BR>>>>>>> =
duplicates<BR>>>>>>> of it=20
in a brand new OpenUP library. If your plug-in initially=20
<BR>>>>>>> depended<BR>>>>>>> =
on some=20
OpenUP element that does not exist anymore when a new=20
version<BR>>>>>>> of OpenUP is released, the =
import will=20
show you warnings, which will<BR>>>>>>> help you =
to spot=20
where you need to maintain your plug-in to extend=20
<BR>>>>>>> the<BR>>>>>>> most =
current=20
version of OpenUP. Additions to OpenUP will not=20
affect<BR>>>>>>> your=20
plug-in.<BR>>>>>>> <BR>>>>>>>=20
Cheers,<BR>>>>>>> <BR>>>>>>> =
Ricardo=20
Balduino.<BR>>>>>>> <BR>>>>>>>=20
"K.Benameur" <<A=20
href=3D"mailto:benameur@freesurf.fr">benameur@freesurf.fr</A>> =
wrote in=20
message<BR>>>>>>> <A=20
=
href=3D"news:f9f8cn$ah0$1@build.eclipse.org">news:f9f8cn$ah0$1@build.ecli=
pse.org</A>...<BR>>>>>>>>=20
Hi =
Peter,<BR>>>>>>>> <BR>>>>>>>>=20
Sorry to bother you with all my questions=20
=
!!!<BR>>>>>>>> <BR>>>>>>>> I am =
not sure that I have completly understood your=20
=
answer.<BR>>>>>>>> <BR>>>>>>>> =
To=20
check this I propose a simple scenario =20
:<BR> >>>>>>>& ;nbsp; - I develop a =
library using=20
Open Up 1.x.<BR> >>>>>>>& ;nbsp; - A new =
version=20
of Open Up is out let say =
2.x<BR> >>>>>>>& ;nbsp; - I=20
wan't to take advantage of this new Open Up=20
=
version.<BR>>>>>>>> <BR>>>>>>>> =
A) So ideally, I import the new version in my library and Open Up=20
<BR>>>>>>>> =
1.x<BR>>>>>>>> is=20
updated to=20
=
2.x.<BR>>>>>>>> <BR>>>>>>>> I=20
have the feeling that it will not be so simple as many links will=20
<BR>>>>>>>> =
be<BR>>>>>>>> broken=20
due to changes between 1.X and=20
=
2.X.<BR>>>>>>>> <BR>>>>>>>> B) =
I=20
use the copy operation to have the 1.X & 2.X plugin in my=20
<BR>>>>>>>>=20
=
library<BR>>>>>>>> <BR>>>>>>>> =
It=20
seems that option B) is the one to go as you said that we have=20
to<BR>>>>>>>> do a copy as uuid must be=20
unique.<BR>>>>>>>>=20
=3D><BR>>>>>>>> I have to do the migration =
manually by replacing elements of Open=20
<BR>>>>>>>> =
1.x<BR>>>>>>>> by=20
their counterparts in=20
=
2.x.<BR>>>>>>>> <BR>>>>>>>> is =
it=20
right or I missed something like a smart import that=20
detect<BR>>>>>>>> conflicts and propose to =
update=20
automatically element that exist =
in<BR>>>>>>>> 1.X=20
& 2.X /delete obsolete element of 1.X / etc..=20
?<BR>>>>>>>> <BR>>>>>>>> =
The=20
question is what is the recommended procedure to perform a=20
<BR>>>>>>>> =
plug-in<BR>>>>>>>>=20
upgrade with a minimum effort=20
?<BR>>>>>>>> <BR>>>>>>>> =
My=20
concern will be the maintenance cost of a library. If we build=20
<BR>>>>>>>> =
our<BR>>>>>>>>=20
library from many commercial or non commercial plugins we have to=20
<BR>>>>>>>> =
deal<BR>>>>>>>> with=20
their evolutions at a minimal=20
=
cost.<BR>>>>>>>> <BR>>>>>>>> <BR>=
>>>>>>><BR >>>>>>>><BR >>>&=
gt;>>>>=20
Best Regards=20
=
....<BR>>>>>>>> <BR>>>>>>>> PS: =
I=20
will be in vacation for the next 2 weeks so you have plenty=20
of<BR>>>>>>>> time for an anwser=20
=
;)<BR>>>>>>>> <BR>>>>>>>> <BR>>=
;>>>>>>=20
PS:<BR> >>>>>>>& ;nbsp; We use ClearCase but it =
will not=20
help here except to roll back to a<BR>>>>>>>> =
stable=20
baseline and lock elements for modification=20
...<BR> >>>>>>>& ;nbsp; We are developping our =
process=20
in multi site. As we didn't want =
to<BR>>>>>>>> add=20
more complexity we decided to work only on one site=20
(windows<BR>>>>>>>> terminal server for the =
distant=20
site) with one development branch =
in<BR>>>>>>>> base=20
CC.<BR>>>>>>>> May be you have a successfull=20
experience using CC multisite & UCM =
?<BR>>>>>>>>=20
Can you share your experience ?<BR>>>>>>>> =
Seems that=20
in CC 7 (we use CC 6) the merge manager have a new=20
option<BR>>>>>>>> i.e. to always copy. So may =
be we=20
can now have branches & multisite =
<BR>>>>>>>>=20
as<BR>>>>>>>> now xmi file can be merged by a =
copy. I=20
see here a potential source <BR>>>>>>>>=20
of<BR>>>>>>>> trouble as we may surely end =
with=20
invalid references if for instance<BR>>>>>>>> =
the=20
merge (copy) is done partially on some xmi=20
=
....<BR>>>>>>>> <BR>>>>>>>> =
Peter=20
Haumer wrote:<BR> >>>>>>>& ;gt;=20
Hello.<BR> >>>>>>>& ;gt; You cannot load =
multiple=20
versions of the same plugin into the=20
same<BR> >>>>>>>& ;gt; library. All library =
elements are=20
identified by global unique ids =
<BR> >>>>>>>& ;gt;=20
and<BR> >>>>>>>& ;gt; hence such ids needs to be =
unique. To get more than one copy of=20
an<BR> >>>>>>>& ;gt; element you need to use the =
copy=20
operation in the library view. =
In<BR> >>>>>>>& ;gt;=20
general we recommend to use a version control system like=20
Rational<BR> >>>>>>>& ;gt; ClearCase which =
allows you to=20
label and restore old versions of =
<BR> >>>>>>>& ;gt;=20
whole<BR> >>>>>>>& ;gt; groups of=20
=
files.<BR> >>>>>>>& ;gt; <BR>>>>>>>>=
;>=20
Best regards,<BR> >>>>>>>& ;gt;=20
=
Peter.<BR> >>>>>>>& ;gt; <BR>>>>>>>>=
;>=20
P.S.: Surely they should not be an exception when loading the=20
same<BR> >>>>>>>& ;gt; content twice, but an =
error=20
message. Please, file a bugzilla=20
with<BR> >>>>>>>& ;gt; reproducible=20
=
steps.<BR> >>>>>>>& ;gt; <BR>>>>>>>>=
;><BR> >>>>>>>& ;gt;=20
"K.Benameur" <<A=20
href=3D"mailto:benameur@freesurf.fr">benameur@freesurf.fr</A>> =
wrote in=20
message<BR> >>>>>>>& ;gt; <A=20
=
href=3D"news:f973f4$goo$1@build.eclipse.org">news:f973f4$goo$1@build.ecli=
pse.org</A>...<BR> >>>>>>>& ;gt;>=20
Hi=20
=
all,<BR> >>>>>>>& ;gt;> <BR>>>>>>>&=
gt;>>=20
It is a very good question. May be it can be addressed by an=20
<BR> >>>>>>>& ;gt;>=20
update<BR> >>>>>>>& ;gt;> of an existing =
guideline as=20
the Development Guideline=20
=
?<BR> >>>>>>>& ;gt;> <BR>>>>>>>>=
>>=20
I think that we should have a "recommended" procedure from the=20
EPF<BR> >>>>>>>& ;gt;> team to update =
plug-ins to a=20
new version.<BR> >>>>>>>& ;gt;> It is =
now a=20
fairly common scenario that multiple versions of=20
the<BR> >>>>>>>& ;gt;> same plug-ins are=20
=
out.<BR> >>>>>>>& ;gt;> <BR>>>>>>>&=
gt;>>=20
And it is not only related to Open Up but for any library /=20
<BR> >>>>>>>& ;gt;>=20
plug-in<BR> >>>>>>>& ;gt;> as part of the =
development=20
process (we are developing our =
own<BR> >>>>>>>& ;gt;>=20
library / plug-ins without Open=20
=
Up).<BR> >>>>>>>& ;gt;> <BR>>>>>>>&=
gt;>><BR> >>>>>>>& ;gt;> =20
In short, what is the recommended procedure to migrate to a=20
new<BR> >>>>>>>& ;gt;> version ? Do we have =
to export=20
/ import ? What are the risks?=20
What<BR> >>>>>>>& ;gt;> we may lose=20
=
?<BR> >>>>>>>& ;gt;> <BR>>>>>>>>=
>><BR> >>>>>>>& ;gt;>=20
Best=20
=
Regards<BR> >>>>>>>& ;gt;> <BR>>>>>>&g=
t;>>><BR> >>>>>>>& ;gt; <BR>>>>>>=
;><BR>>>>>><BR>>>>>> <BR>>>>>=
<BR>>>>><BR>>>> <BR>>>><BR>>><BR>>&=
gt;<BR>><BR>><BR>>=20
<BR><BR></BLOCKQUOTE></BLOCKQUOTE></BLOCKQUOTE></BODY></HTML >
------=_NextPart_000_003F_01C7F0AA.74CD32E0--
|
|
|
| Re: Migration to newever library version [message #582970 is a reply to message #39963] |
Fri, 07 September 2007 05:49 |
Peter Haumer
Messages: 228
Registered: July 2009 |
Senior Member |
|
|
This is a multi-part message in MIME format.
------=_NextPart_000_005E_01C7F0D8.2005ED50
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Hello Kamal.
I see an increase of interest and lecturing from Osellus in recent days =
here in the forum. Are you guys finally ready to contribute and write =
some code for EPF? ;-)=20
As we clearly said, the feature to loosely combine method plug-ins and =
scale your libraries up to the enterprise level is a Rational Method =
Composer distinguishing feature and for us not in scope of EPF. As =
Ricardo points out EPFC is powerful enough to build any kind of large =
method library. The focus is here on one library at a time. RMC allows =
to scale this up to multiple collocated libraries at the time.=20
This is something we sell, which is in line with the license and agenda =
of Eclipse to provide platforms that can be used to build commercial =
tools on top that can be sold. Osellus only sells and does not work in =
open source and no communities benefit. Hence, I thought that especially =
you guys would understand and not try to push the issue on this one.=20
Best regards,
Peter.
"Kamal Ahluwalia" <kamal@osellus.com> wrote in message =
news:fbpr2j$sbm$1@build.eclipse.org...
Thanks for your response Ricardo.
=20
This thread highlights some of the fundamental constraints in using =
EPF Composer, especially library.xml to maintain processes. It appears =
RMC 7.2 addresses some of these problems. Are there any plans to donate =
those bits to EPF so that the community can benefit ?
=20
Kamal=20
"Ricardo Balduino" <balduino@us.ibm.com> wrote in message =
news:fbpnj1$24t$1@build.eclipse.org...
>>> I wanted to clarify if it really is the case that EPF Composer =
is designed to be primarily used to maintain OpenUP only. =20
It is not really the case.
EPF Composer is used by the EPF team to maintain OpenUP, DSDM, =
Scrum, XP and any other processes being captured today and in the future =
under the EPF project.
Moreover, EPF users can capture their own home-grown processes or =
extensions to available processes using EPF Composer.
I hope this clarifies your question.
Regards,
Ricardo Balduino.
"Kamal Ahluwalia" <kamal@osellus.com> wrote in message =
news:fbpmjg$rai$1@build.eclipse.org...
"EPF Composer is designed to support a single project per library =
only as it is primary used to maintain OpenUP".
=20
I wanted to clarify if it really is the case that EPF Composer is =
designed to be primarily used to maintain OpenUP only. =20
=20
Kamal
"Roman Smirak" <roman.smirak@tietoenator.com> wrote in message =
news:f9rjjo$50e$1@build.eclipse.org...
Hi Peter,
that is great, the implementation perfectly matches with my =
vision. Why=20
not to have it in EPF? I guess many users would welcome the =
feature.
We have licences of RMC, however, we prefer to use EPF since =
early releases=20
are available.
Regards,
Roman
"Peter Haumer" <phaumer@us.ibm.com> wrote in message=20
news:f9qa5o$jac$1@build.eclipse.org...
> Hello Roman.
> Well, if our competitors can abuse this forum to plug their =
products; so=20
> can I :-)
>
> RMC 7.2 does not need the library.xmi file anymore as it uses =
the Eclipse=20
> workspace's projects to find all the files. Every plugin is a =
project as=20
> well as you can create more than one project for managing =
configurations=20
> and one project for estimation data (another RMC added value). =
The problem=20
> view is used just as in Eclipse to tell you if you are missing =
elements in=20
> your workspace that other elements depend upon. You could =
ignore those=20
> errors or fix them by loading the project's that contain the =
missing=20
> elements.
>
> See the attached image with an example where I was using =
plugins managed=20
> in CVS and plugins managed in CC all at the same time in the =
same=20
> workspace. Plugins can now reside in complete different =
directories even=20
> on different machine. Just like Eclipse projects, you load =
them into your=20
> workspace and use them whenever you need to use them.
>
> However, RMC can still generate a library.xmi for you to =
manage libraries=20
> that are fully compatible with EPF Composer. For example, if =
you check the=20
> OpenUP CVS repository: it already has project files in each =
plugin=20
> directory. That is because I was already working with OpenUP =
in RMC 7.2;=20
> at the same time where the rest of the team continued working =
with EPF=20
> Composer. Two ways of loading the same library in a fully =
compatible way.
>
> Hope this helps,
> Peter.
>
>
>
> "Roman Smirak" <roman.smirak@tietoenator.com> wrote in message =
> news:f9p6up$mmu$1@build.eclipse.org...
>> Hi Peter,
>>
>> thanks for info, however, RMC is based on EPF and I see =
current=20
>> solution
>> of EPF (library.xml) as a fundamental constraint for clear & =
easy=20
>> solution
>> at RMC level. Or?
>>
>> Can you please describe the scenario with RMC how it will be =
implemented?
>>
>> Or shall I post this at IBM Rational forum?
>>
>> Roman
>>
>> "Peter Haumer" <phaumer@us.ibm.com> wrote in message
>> news:f9o54i$924$1@build.eclipse.org...
>>> 1) no, the guid remains the same
>>> 2) not sure I understand the context of this, but I would =
recommend to
>>> only version manage your own files and if you are using cvs =
directly get
>>> the OpenUP sources from our server or if you use CC provide =
a zip/rar=20
>>> file
>>> with the OpenUP files that users can unzip as view-private =
files
>>> 3) Rational Method Composer 7.2 will fully support this =
scenario, which=20
>>> is
>>> not in scope for EPF Composer. For enterprise deployments =
and full
>>> scalability we recommend RMC in which every plugin can be =
maintained as=20
>>> an
>>> eclipse project and loaded when needed. In addition we =
provide project
>>> types for configurations, enterprise reports, and estimation =
models in
>>> RMC. EPF Composer is designed to support a single project =
per library
>>> only as it is primary used to maintain OpenUP. A workaround =
for you=20
>>> would
>>> be what I described above for (2).
>>>
>>> Best regards,
>>> Peter Haumer.
>>>
>>>
>>> "Roman Smirak" <roman.smirak@tietoenator.com> wrote in =
message
>>> news:f9kcmi$idh$1@build.eclipse.org...
>>>> Hi Ricardo,
>>>>
>>>> the way you described below is the one I've been using so =
far;=20
>>>> however,
>>>> I have few issues here:
>>>> 1/ What if you refactor the content of OpenUP, e.g. an =
element I was
>>>> referencing to is no longer in same package or plugin? Is =
there any
>>>> impact on UID?
>>>>
>>>> 2/ Currently we have the whole library in a versioning =
repository,
>>>> although everyone has got the basis (OpenUP, or RUP) with =
the tool=20
>>>> (EMC,
>>>> or RMC) - no problem for OpenUP, in case of RUP, well we =
are talking
>>>> about 60MB or so (which you have to check in every time you =
migrate)
>>>>
>>>> 3/ Let say we have a common basis in our department X, =
let's call it
>>>> OpenUP/X; there is a project A which will use it plus =
extension A minus
>>>> irrelevant content from basis; in case of eclipse plugins =
they simply
>>>> check out required plugins (they stay in touch with their =
updates by
>>>> department X authority) but they don't check out irrelevant =
plugins (no
>>>> mess) + create their new one and check it in their =
repository (will be
>>>> maintained there); currently they need to check out whole =
library X +
>>>> submit their plugins A into the library shared by others =
(and they do
>>>> same action as well =3D> mess X + A + B + C, etc.) in order =
to fulfil the
>>>> use case (the basis maintained by department, a project =
extension
>>>> maintained by the project itself)
>>>>
>>>> I see the library.xml as a big constraint in this use case.
>>>>
>>>> Regards,
>>>>
>>>> Roman
>>>>
>>>> "Ricardo Balduino" <balduino@us.ibm.com> wrote in message
>>>> news:f9itco$87k$1@build.eclipse.org...
>>>>> In first paragraph I meant less cumbersome, yet safer ;-)
>>>>>
>>>>> "Ricardo Balduino" <balduino@us.ibm.com> wrote in message
>>>>> news:f9g8d0$db$1@build.eclipse.org...
>>>>>> Option A sounds less cumbersome and safer, as the EPF =
Composer tool
>>>>>> will take care of the work. In fact, according to your =
description of
>>>>>> option A, OpenUP 2.x would overwrite OpenUP 1.x.
>>>>>>
>>>>>> Instead of playing with importing a new OpenUP plug-in =
into your
>>>>>> existing library, have you considered getting the new =
OpenUP library
>>>>>> available and import your plug-in into it instead? With =
that=20
>>>>>> approach,
>>>>>> you are moving your plug-in around, so you know there are =
no=20
>>>>>> duplicates
>>>>>> of it in a brand new OpenUP library. If your plug-in =
initially=20
>>>>>> depended
>>>>>> on some OpenUP element that does not exist anymore when a =
new version
>>>>>> of OpenUP is released, the import will show you warnings, =
which will
>>>>>> help you to spot where you need to maintain your plug-in =
to extend=20
>>>>>> the
>>>>>> most current version of OpenUP. Additions to OpenUP will =
not affect
>>>>>> your plug-in.
>>>>>>
>>>>>> Cheers,
>>>>>>
>>>>>> Ricardo Balduino.
>>>>>>
>>>>>> "K.Benameur" <benameur@freesurf.fr> wrote in message
>>>>>> news:f9f8cn$ah0$1@build.eclipse.org...
>>>>>>> Hi Peter,
>>>>>>>
>>>>>>> Sorry to bother you with all my questions !!!
>>>>>>>
>>>>>>> I am not sure that I have completly understood your =
answer.
>>>>>>>
>>>>>>> To check this I propose a simple scenario :
>>>>>>> - I develop a library using Open Up 1.x.
>>>>>>> - A new version of Open Up is out let say 2.x
>>>>>>> - I wan't to take advantage of this new Open Up =
version.
>>>>>>>
>>>>>>> A) So ideally, I import the new version in my library =
and Open Up=20
>>>>>>> 1.x
>>>>>>> is updated to 2.x.
>>>>>>>
>>>>>>> I have the feeling that it will not be so simple as many =
links will=20
>>>>>>> be
>>>>>>> broken due to changes between 1.X and 2.X.
>>>>>>>
>>>>>>> B) I use the copy operation to have the 1.X & 2.X plugin =
in my=20
>>>>>>> library
>>>>>>>
>>>>>>> It seems that option B) is the one to go as you said =
that we have to
>>>>>>> do a copy as uuid must be unique.
>>>>>>> =3D>
>>>>>>> I have to do the migration manually by replacing =
elements of Open=20
>>>>>>> 1.x
>>>>>>> by their counterparts in 2.x.
>>>>>>>
>>>>>>> is it right or I missed something like a smart import =
that detect
>>>>>>> conflicts and propose to update automatically element =
that exist in
>>>>>>> 1.X & 2.X /delete obsolete element of 1.X / etc.. ?
>>>>>>>
>>>>>>> The question is what is the recommended procedure to =
perform a=20
>>>>>>> plug-in
>>>>>>> upgrade with a minimum effort ?
>>>>>>>
>>>>>>> My concern will be the maintenance cost of a library. If =
we build=20
>>>>>>> our
>>>>>>> library from many commercial or non commercial plugins =
we have to=20
>>>>>>> deal
>>>>>>> with their evolutions at a minimal cost.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Best Regards ...
>>>>>>>
>>>>>>> PS: I will be in vacation for the next 2 weeks so you =
have plenty of
>>>>>>> time for an anwser ;)
>>>>>>>
>>>>>>>
>>>>>>> PS:
>>>>>>> We use ClearCase but it will not help here except to =
roll back to a
>>>>>>> stable baseline and lock elements for modification ...
>>>>>>> We are developping our process in multi site. As we =
didn't want to
>>>>>>> add more complexity we decided to work only on one site =
(windows
>>>>>>> terminal server for the distant site) with one =
development branch in
>>>>>>> base CC.
>>>>>>> May be you have a successfull experience using CC =
multisite & UCM ?
>>>>>>> Can you share your experience ?
>>>>>>> Seems that in CC 7 (we use CC 6) the merge manager have =
a new option
>>>>>>> i.e. to always copy. So may be we can now have branches =
& multisite=20
>>>>>>> as
>>>>>>> now xmi file can be merged by a copy. I see here a =
potential source=20
>>>>>>> of
>>>>>>> trouble as we may surely end with invalid references if =
for instance
>>>>>>> the merge (copy) is done partially on some xmi ...
>>>>>>>
>>>>>>> Peter Haumer wrote:
>>>>>>>> Hello.
>>>>>>>> You cannot load multiple versions of the same plugin =
into the same
>>>>>>>> library. All library elements are identified by global =
unique ids=20
>>>>>>>> and
>>>>>>>> hence such ids needs to be unique. To get more than =
one copy of an
>>>>>>>> element you need to use the copy operation in the =
library view. In
>>>>>>>> general we recommend to use a version control system =
like Rational
>>>>>>>> ClearCase which allows you to label and restore old =
versions of=20
>>>>>>>> whole
>>>>>>>> groups of files.
>>>>>>>>
>>>>>>>> Best regards,
>>>>>>>> Peter.
>>>>>>>>
>>>>>>>> P.S.: Surely they should not be an exception when =
loading the same
>>>>>>>> content twice, but an error message. Please, file a =
bugzilla with
>>>>>>>> reproducible steps.
>>>>>>>>
>>>>>>>>
>>>>>>>> "K.Benameur" <benameur@freesurf.fr> wrote in message
>>>>>>>> news:f973f4$goo$1@build.eclipse.org...
>>>>>>>>> Hi all,
>>>>>>>>>
>>>>>>>>> It is a very good question. May be it can be addressed =
by an=20
>>>>>>>>> update
>>>>>>>>> of an existing guideline as the Development Guideline =
?
>>>>>>>>>
>>>>>>>>> I think that we should have a "recommended" procedure =
from the EPF
>>>>>>>>> team to update plug-ins to a new version.
>>>>>>>>> It is now a fairly common scenario that multiple =
versions of the
>>>>>>>>> same plug-ins are out.
>>>>>>>>>
>>>>>>>>> And it is not only related to Open Up but for any =
library /=20
>>>>>>>>> plug-in
>>>>>>>>> as part of the development process (we are developing =
our own
>>>>>>>>> library / plug-ins without Open Up).
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> In short, what is the recommended procedure to =
migrate to a new
>>>>>>>>> version ? Do we have to export / import ? What are the =
risks? What
>>>>>>>>> we may lose ?
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Best Regards
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>
>=20
------=_NextPart_000_005E_01C7F0D8.2005ED50
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML xmlns:o =3D "urn:schemas-microsoft-com:office:office"><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2900.3157" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>Hello Kamal.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>I see an increase of interest and =
lecturing from=20
Osellus in recent days here in the forum. Are you guys finally =
ready to=20
contribute and write some code for EPF? ;-) </FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>As we clearly said, the feature to =
loosely combine=20
method plug-ins and scale your libraries up to the enterprise level is a =
Rational Method Composer distinguishing feature and for us not in scope =
of=20
EPF. As Ricardo points out EPFC is powerful enough to build any =
kind of=20
large method library. The focus is here on one library at a =
time. =20
RMC allows to scale this up to multiple collocated libraries at the =
time.=20
</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>This is something we sell, =
which </FONT><FONT=20
face=3DArial size=3D2>is in line with the license and agenda of =
Eclipse to=20
provide platforms that can be used to build commercial tools on top that =
can be=20
sold. Osellus only sells and does not work in open source and no =
communities=20
benefit. Hence, I thought that especially you guys would understand and =
not try=20
to push the issue on this one. </FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>Best regards,</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Peter.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
<DIV>"Kamal Ahluwalia" <<A=20
href=3D"mailto:kamal@osellus.com">kamal@osellus.com</A>> wrote in =
message <A=20
=
href=3D"news:fbpr2j$sbm$1@build.eclipse.org">news:fbpr2j$sbm$1@build.ecli=
pse.org</A>...</DIV>
<DIV><FONT face=3DArial size=3D2>
<P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><SPAN=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New =
Roman','serif'">Thanks for=20
your response Ricardo.<o:p></o:p></SPAN></P>
<P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><SPAN=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New =
Roman','serif'"><o:p> </o:p></SPAN></P>
<P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><SPAN=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman','serif'">This =
thread=20
highlights some of the fundamental constraints in using EPF Composer,=20
especially library.xml to maintain processes. It appears RMC 7.2 =
addresses=20
some of these problems. Are there any plans to donate those bits to =
EPF so=20
that the community can benefit ?<o:p></o:p></SPAN></P>
<P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><SPAN=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New =
Roman','serif'"><o:p> </o:p></SPAN></P>
<P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><SPAN=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New =
Roman','serif'">Kamal=20
<o:p></o:p></SPAN></P></FONT></DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
<DIV>"Ricardo Balduino" <<A=20
href=3D"mailto:balduino@us.ibm.com">balduino@us.ibm.com</A>> =
wrote in=20
message <A=20
=
href=3D"news:fbpnj1$24t$1@build.eclipse.org">news:fbpnj1$24t$1@build.ecli=
pse.org</A>...</DIV>
<DIV><FONT face=3DArial size=3D2>>>> <FONT size=3D3><FONT=20
face=3D"Times New Roman">I wanted to clarify if it really =
is the=20
case that EPF Composer is designed to be primarily used to maintain =
OpenUP=20
only. </FONT></FONT></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><FONT size=3D3><FONT=20
face=3D"Times New Roman"></FONT></FONT></FONT> </DIV>
<DIV><FONT size=3D+0><FONT size=3D+0><FONT face=3DArial><FONT =
size=3D2>It is not=20
really the case.</FONT></FONT></FONT></FONT></DIV>
<DIV><FONT size=3D+0><FONT size=3D+0><FONT face=3DArial><FONT=20
size=3D2></FONT></FONT></FONT></FONT> </DIV>
<DIV><FONT size=3D+0><FONT size=3D+0><FONT face=3DArial><FONT =
size=3D2>EPF Composer=20
is used by the EPF team to maintain OpenUP, DSDM, Scrum, XP and any =
other=20
processes being captured today and in the future under the EPF=20
project.</FONT></FONT></FONT></FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>Moreover, EPF users can capture =
their own=20
home-grown processes or extensions to available processes using EPF=20
Composer.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>I hope this clarifies your=20
question.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>Regards,</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>Ricardo Balduino.</FONT></DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
<DIV>"Kamal Ahluwalia" <<A=20
href=3D"mailto:kamal@osellus.com">kamal@osellus.com</A>> wrote =
in message=20
<A=20
=
href=3D"news:fbpmjg$rai$1@build.eclipse.org">news:fbpmjg$rai$1@build.ecli=
pse.org</A>...</DIV>
<DIV><FONT face=3DArial size=3D2>
<P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><FONT =
size=3D3><FONT=20
face=3D"Times New Roman">=93EPF Composer is designed to support a =
single=20
project per library only as it is primary used to maintain=20
OpenUP=94.<o:p></o:p></FONT></FONT></P>
<P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><o:p><FONT=20
face=3D"Times New Roman" size=3D3> </FONT></o:p></P>
<P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><FONT =
size=3D3><FONT=20
face=3D"Times New Roman">I wanted to clarify =
if it really is the=20
case that EPF Composer is designed to be primarily used to =
maintain OpenUP=20
only. <o:p></o:p></FONT></FONT></P>
<P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><o:p><FONT=20
face=3D"Times New Roman" size=3D3> </FONT></o:p></P>
<P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><FONT =
size=3D3><FONT=20
face=3D"Times New =
Roman">Kamal<o:p></o:p></FONT></FONT></P></FONT></DIV >
<BLOCKQUOTE=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
<DIV>"Roman Smirak" <<A=20
=
href=3D"mailto:roman.smirak@tietoenator.com">roman.smirak@tietoenator.com=
</A>>=20
wrote in message <A=20
=
href=3D"news:f9rjjo$50e$1@build.eclipse.org">news:f9rjjo$50e$1@build.ecli=
pse.org</A>...</DIV>Hi=20
Peter,<BR><BR> that is great, the implementation =
perfectly=20
matches with my vision. Why <BR>not to have it in EPF? I guess =
many=20
users would welcome the feature.<BR><BR>We have licences of RMC, =
however, we prefer to use EPF since early releases <BR>are=20
available.<BR><BR>Regards,<BR><BR>Roman<BR><BR>"Peter Haumer" =
<<A=20
href=3D"mailto:phaumer@us.ibm.com">phaumer@us.ibm.com</A>> =
wrote in=20
message <BR><A=20
=
href=3D"news:f9qa5o$jac$1@build.eclipse.org">news:f9qa5o$jac$1@build.ecli=
pse.org</A>...<BR>>=20
Hello Roman.<BR>> Well, if our competitors can abuse this =
forum to=20
plug their products; so <BR>> can I :-)<BR>><BR>> RMC =
7.2 does=20
not need the library.xmi file anymore as it uses the Eclipse =
<BR>>=20
workspace's projects to find all the files. Every plugin is a =
project as=20
<BR>> well as you can create more than one project for =
managing=20
configurations <BR>> and one project for estimation data =
(another RMC=20
added value). The problem <BR>> view is used just as in =
Eclipse to=20
tell you if you are missing elements in <BR>> your workspace =
that=20
other elements depend upon. You could ignore those =
<BR>> errors=20
or fix them by loading the project's that contain the missing =
<BR>>=20
elements.<BR>><BR>> See the attached image with an example =
where I=20
was using plugins managed <BR>> in CVS and plugins managed in =
CC all=20
at the same time in the same <BR>> workspace. Plugins can now =
reside=20
in complete different directories even <BR>> on different=20
machine. Just like Eclipse projects, you load them into =
your=20
<BR>> workspace and use them whenever you need to use=20
them.<BR>><BR>> However, RMC can still generate a =
library.xmi for=20
you to manage libraries <BR>> that are fully compatible with =
EPF=20
Composer. For example, if you check the <BR>> OpenUP CVS =
repository:=20
it already has project files in each plugin <BR>> =
directory. =20
That is because I was already working with OpenUP in RMC 7.2; =
<BR>>=20
at the same time where the rest of the team continued working =
with EPF=20
<BR>> Composer. Two ways of loading the same library in =
a fully=20
compatible way.<BR>><BR>> Hope this helps,<BR>>=20
Peter.<BR>><BR>><BR>><BR>> "Roman Smirak" <<A=20
=
href=3D"mailto:roman.smirak@tietoenator.com">roman.smirak@tietoenator.com=
</A>>=20
wrote in message <BR>> <A=20
=
href=3D"news:f9p6up$mmu$1@build.eclipse.org">news:f9p6up$mmu$1@build.ecli=
pse.org</A>...<BR>>>=20
Hi Peter,<BR>>><BR>>> thanks for info, =
however,=20
RMC is based on EPF and I see current <BR>>> =
solution<BR>>>=20
of EPF (library.xml) as a fundamental constraint for clear & =
easy=20
<BR>>> solution<BR>>> at RMC level.=20
Or?<BR>>><BR>>> Can you please describe the scenario =
with=20
RMC how it will be implemented?<BR>>><BR>>> Or shall =
I post=20
this at IBM Rational forum?<BR>>><BR>>>=20
Roman<BR>>><BR>>> "Peter Haumer" <<A=20
href=3D"mailto:phaumer@us.ibm.com">phaumer@us.ibm.com</A>> =
wrote in=20
message<BR>>> <A=20
=
href=3D"news:f9o54i$924$1@build.eclipse.org">news:f9o54i$924$1@build.ecli=
pse.org</A>...<BR>>>>=20
1) no, the guid remains the same<BR>>>> 2) not sure I=20
understand the context of this, but I would recommend =
to<BR>>>>=20
only version manage your own files and if you are using cvs =
directly=20
get<BR>>>> the OpenUP sources from our server or if you =
use CC=20
provide a zip/rar <BR>>>> file<BR>>>> with the =
OpenUP=20
files that users can unzip as view-private files<BR>>>> =
3)=20
Rational Method Composer 7.2 will fully support this scenario, =
which=20
<BR>>>> is<BR>>>> not in scope for EPF =
Composer. =20
For enterprise deployments and full<BR>>>> scalability =
we=20
recommend RMC in which every plugin can be maintained as=20
<BR>>>> an<BR>>>> eclipse project and loaded =
when=20
needed. In addition we provide project<BR>>>> types for =
configurations, enterprise reports, and estimation models=20
in<BR>>>> RMC. EPF Composer is designed to =
support a=20
single project per library<BR>>>> only as it is primary =
used to=20
maintain OpenUP. A workaround for you <BR>>>>=20
would<BR>>>> be what I described above for=20
(2).<BR>>>><BR>>>> Best =
regards,<BR>>>> Peter=20
Haumer.<BR>>>><BR>>>> <BR>>>> "Roman =
Smirak"=20
<<A=20
=
href=3D"mailto:roman.smirak@tietoenator.com">roman.smirak@tietoenator.com=
</A>>=20
wrote in message<BR>>>> <A=20
=
href=3D"news:f9kcmi$idh$1@build.eclipse.org">news:f9kcmi$idh$1@build.ecli=
pse.org</A>...<BR>>>>>=20
Hi Ricardo,<BR>>>>><BR>>>>> =
the way=20
you described below is the one I've been using so far;=20
<BR>>>>> however,<BR>>>>> I have few =
issues=20
here:<BR>>>>> 1/ What if you refactor the content of =
OpenUP,=20
e.g. an element I was<BR>>>>> referencing to is no =
longer in=20
same package or plugin? Is there any<BR>>>>> impact =
on=20
UID?<BR>>>>><BR>>>>> 2/ Currently we =
have the=20
whole library in a versioning repository,<BR>>>>> =
although=20
everyone has got the basis (OpenUP, or RUP) with the tool=20
<BR>>>>> (EMC,<BR>>>>> or RMC) - no =
problem for=20
OpenUP, in case of RUP, well we are talking<BR>>>>> =
about=20
60MB or so (which you have to check in every time you=20
migrate)<BR>>>>><BR>>>>> 3/ Let say we =
have a=20
common basis in our department X, let's call =
it<BR>>>>>=20
OpenUP/X; there is a project A which will use it plus extension =
A=20
minus<BR>>>>> irrelevant content from basis; in case =
of=20
eclipse plugins they simply<BR>>>>> check out =
required=20
plugins (they stay in touch with their updates =
by<BR>>>>>=20
department X authority) but they don't check out irrelevant =
plugins=20
(no<BR>>>>> mess) + create their new one and check =
it in=20
their repository (will be<BR>>>>> maintained there); =
currently they need to check out whole library X =
+<BR>>>>>=20
submit their plugins A into the library shared by others (and =
they=20
do<BR>>>>> same action as well =3D> mess X + A + =
B + C,=20
etc.) in order to fulfil the<BR>>>>> use case (the =
basis=20
maintained by department, a project =
extension<BR>>>>>=20
maintained by the project=20
itself)<BR>>>>><BR>>>>> I see the =
library.xml as=20
a big constraint in this use=20
case.<BR>>>>><BR>>>>>=20
Regards,<BR>>>>><BR>>>>>=20
Roman<BR>>>>><BR>>>>> "Ricardo Balduino" =
<<A=20
href=3D"mailto:balduino@us.ibm.com">balduino@us.ibm.com</A>> =
wrote in=20
message<BR>>>>> <A=20
=
href=3D"news:f9itco$87k$1@build.eclipse.org">news:f9itco$87k$1@build.ecli=
pse.org</A>...<BR>>>>>>=20
In first paragraph I meant less cumbersome, yet safer=20
;-)<BR>>>>>><BR>>>>>> "Ricardo =
Balduino"=20
<<A =
href=3D"mailto:balduino@us.ibm.com">balduino@us.ibm.com</A>>=20
wrote in message<BR>>>>>> <A=20
=
href=3D"news:f9g8d0$db$1@build.eclipse.org">news:f9g8d0$db$1@build.eclips=
e.org</A>...<BR>>>>>>>=20
Option A sounds less cumbersome and safer, as the EPF Composer=20
tool<BR>>>>>>> will take care of the work. In =
fact,=20
according to your description of<BR>>>>>>> =
option A,=20
OpenUP 2.x would overwrite OpenUP=20
1.x.<BR>>>>>>><BR >>>>>>> =
Instead of=20
playing with importing a new OpenUP plug-in into=20
your<BR>>>>>>> existing library, have you =
considered=20
getting the new OpenUP library<BR>>>>>>> =
available and=20
import your plug-in into it instead? With that=20
<BR>>>>>>> =
approach,<BR>>>>>>> you=20
are moving your plug-in around, so you know there are no=20
<BR>>>>>>> =
duplicates<BR>>>>>>> of=20
it in a brand new OpenUP library. If your plug-in initially=20
<BR>>>>>>> =
depended<BR>>>>>>> on=20
some OpenUP element that does not exist anymore when a new=20
version<BR>>>>>>> of OpenUP is released, the =
import=20
will show you warnings, which will<BR>>>>>>> =
help you=20
to spot where you need to maintain your plug-in to extend=20
<BR>>>>>>> the<BR>>>>>>> =
most=20
current version of OpenUP. Additions to OpenUP will not=20
affect<BR>>>>>>> your=20
plug-in.<BR>>>>>>> <BR>>>>>>> =
Cheers,<BR>>>>>>> <BR>>>>>>> =
Ricardo=20
=
Balduino.<BR>>>>>>> <BR>>>>>>>=20
"K.Benameur" <<A=20
=
href=3D"mailto:benameur@freesurf.fr">benameur@freesurf.fr</A>> wrote =
in=20
message<BR>>>>>>> <A=20
=
href=3D"news:f9f8cn$ah0$1@build.eclipse.org">news:f9f8cn$ah0$1@build.ecli=
pse.org</A>...<BR>>>>>>>>=20
Hi=20
=
Peter,<BR>>>>>>>> <BR>>>>>>>>=20
Sorry to bother you with all my questions=20
=
!!!<BR>>>>>>>> <BR>>>>>>>> I am =
not sure that I have completly understood your=20
=
answer.<BR>>>>>>>> <BR>>>>>>>>=20
To check this I propose a simple scenario =20
:<BR> >>>>>>>& ;nbsp; - I develop a =
library=20
using Open Up 1.x.<BR> >>>>>>>& ;nbsp; - =
A new=20
version of Open Up is out let say=20
2.x<BR> >>>>>>>& ;nbsp; - I wan't to take =
advantage of=20
this new Open Up=20
=
version.<BR>>>>>>>> <BR>>>>>>>> =
A) So ideally, I import the new version in my library and Open =
Up=20
<BR>>>>>>>> =
1.x<BR>>>>>>>> is=20
updated to=20
=
2.x.<BR>>>>>>>> <BR>>>>>>>> I=20
have the feeling that it will not be so simple as many links =
will=20
<BR>>>>>>>> =
be<BR>>>>>>>>=20
broken due to changes between 1.X and=20
=
2.X.<BR>>>>>>>> <BR>>>>>>>> B)=20
I use the copy operation to have the 1.X & 2.X plugin in my=20
<BR>>>>>>>>=20
=
library<BR>>>>>>>> <BR>>>>>>>>=20
It seems that option B) is the one to go as you said that we =
have=20
to<BR>>>>>>>> do a copy as uuid must be=20
unique.<BR>>>>>>>>=20
=3D><BR>>>>>>>> I have to do the =
migration=20
manually by replacing elements of Open=20
<BR>>>>>>>> =
1.x<BR>>>>>>>> by=20
their counterparts in=20
=
2.x.<BR>>>>>>>> <BR>>>>>>>> is=20
it right or I missed something like a smart import that=20
detect<BR>>>>>>>> conflicts and propose to =
update=20
automatically element that exist =
in<BR>>>>>>>> 1.X=20
& 2.X /delete obsolete element of 1.X / etc..=20
=
?<BR>>>>>>>> <BR>>>>>>>> The=20
question is what is the recommended procedure to perform a=20
<BR>>>>>>>> =
plug-in<BR>>>>>>>>=20
upgrade with a minimum effort=20
=
?<BR>>>>>>>> <BR>>>>>>>> My=20
concern will be the maintenance cost of a library. If we build=20
<BR>>>>>>>> =
our<BR>>>>>>>>=20
library from many commercial or non commercial plugins we have =
to=20
<BR>>>>>>>> =
deal<BR>>>>>>>>=20
with their evolutions at a minimal=20
=
cost.<BR>>>>>>>> <BR>>>>>>>> <BR>=
>>>>>>><BR >>>>>>>><BR >>>&=
gt;>>>>=20
Best Regards=20
=
....<BR>>>>>>>> <BR>>>>>>>> PS:=20
I will be in vacation for the next 2 weeks so you have plenty=20
of<BR>>>>>>>> time for an anwser=20
=
;)<BR>>>>>>>> <BR>>>>>>>> <BR>>=
;>>>>>>=20
PS:<BR> >>>>>>>& ;nbsp; We use ClearCase but =
it will=20
not help here except to roll back to =
a<BR>>>>>>>>=20
stable baseline and lock elements for modification=20
...<BR> >>>>>>>& ;nbsp; We are developping our =
process=20
in multi site. As we didn't want =
to<BR>>>>>>>> add=20
more complexity we decided to work only on one site=20
(windows<BR>>>>>>>> terminal server for the =
distant=20
site) with one development branch =
in<BR>>>>>>>>=20
base CC.<BR>>>>>>>> May be you have a =
successfull=20
experience using CC multisite & UCM=20
?<BR>>>>>>>> Can you share your experience=20
?<BR>>>>>>>> Seems that in CC 7 (we use CC =
6) the=20
merge manager have a new option<BR>>>>>>>> =
i.e. to=20
always copy. So may be we can now have branches & multisite=20
<BR>>>>>>>> =
as<BR>>>>>>>> now=20
xmi file can be merged by a copy. I see here a potential source=20
<BR>>>>>>>> =
of<BR>>>>>>>>=20
trouble as we may surely end with invalid references if for=20
instance<BR>>>>>>>> the merge (copy) is =
done=20
partially on some xmi=20
=
....<BR>>>>>>>> <BR>>>>>>>>=20
Peter Haumer wrote:<BR> >>>>>>>& ;gt;=20
Hello.<BR> >>>>>>>& ;gt; You cannot load =
multiple=20
versions of the same plugin into the=20
same<BR> >>>>>>>& ;gt; library. All library =
elements=20
are identified by global unique ids =
<BR> >>>>>>>& ;gt;=20
and<BR> >>>>>>>& ;gt; hence such ids needs to =
be=20
unique. To get more than one copy of=20
an<BR> >>>>>>>& ;gt; element you need to use =
the copy=20
operation in the library view. =
In<BR> >>>>>>>& ;gt;=20
general we recommend to use a version control system like=20
Rational<BR> >>>>>>>& ;gt; ClearCase which =
allows you=20
to label and restore old versions of=20
<BR> >>>>>>>& ;gt;=20
whole<BR> >>>>>>>& ;gt; groups of=20
=
files.<BR> >>>>>>>& ;gt; <BR>>>>>>>>=
;>=20
Best regards,<BR> >>>>>>>& ;gt;=20
=
Peter.<BR> >>>>>>>& ;gt; <BR>>>>>>>>=
;>=20
P.S.: Surely they should not be an exception when loading the=20
same<BR> >>>>>>>& ;gt; content twice, but an =
error=20
message. Please, file
|
|
|
| Re: Migration to newever library version [message #583020 is a reply to message #40123] |
Fri, 07 September 2007 18:07 |
| Eclipse User |
|
|
|
Originally posted by: kamal.osellus.com
This is a multi-part message in MIME format.
------=_NextPart_000_0012_01C7F158.5DEC6CE0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Hi Peter
=20
As you very well know Osellus has made significant contributions to the =
software process community by the over three years work we have done in =
OMG culminating in a comprehensive end-to-end standard submission. There =
are past EPF newsgroup threads on this topic that the community is =
already aware of.
=20
Recently, we are very happy to see interest in this forum on the need =
for enactment of EPF generated processes. This is in line with our long =
established philosophy of treating enactment entities as first class =
citizens and not an afterthought. We are working on solutions that would =
move any content developed using EPF Composer to a collaborative =
development environment of choice for enactment in live projects. The =
first version of this is Content Bridge for VSTS, a tool for moving =
processes from EPF Composer to Microsoft's Visual Studio Team System.=20
=20
I would also point out and hope that the clarifications we are seeking =
and the feedback we are sharing in the forum will be of use to the =
community.=20
=20
I see all of this as significant investment by a company that is a =
fraction of the size of IBM. We have been open to the idea of =
code-contribution but feel that the past concerns we have raised =
relating to requirements, architecture and meta-model coupled with the =
limited development resources prevent us from taking a more active role =
than we already have.
=20
Finally, I hope that it's just my impression and not something you meant =
but I found your tone to have crossed the boundaries of a professional =
inclusive attitude to individuals who are trying to raise awareness on =
outstanding or unclear issues in this newsgroup. I had merely asked if =
IBM was open to sharing the bits it had developed that may go way in =
making EPF more widely adopted. From your answer it is clear that is not =
the case.
=20
Thanks
Kamal
"Peter Haumer" <phaumer@us.ibm.com> wrote in message =
news:fbqood$ijk$1@build.eclipse.org...
Hello Kamal.
I see an increase of interest and lecturing from Osellus in recent =
days here in the forum. Are you guys finally ready to contribute and =
write some code for EPF? ;-)=20
As we clearly said, the feature to loosely combine method plug-ins and =
scale your libraries up to the enterprise level is a Rational Method =
Composer distinguishing feature and for us not in scope of EPF. As =
Ricardo points out EPFC is powerful enough to build any kind of large =
method library. The focus is here on one library at a time. RMC allows =
to scale this up to multiple collocated libraries at the time.=20
This is something we sell, which is in line with the license and =
agenda of Eclipse to provide platforms that can be used to build =
commercial tools on top that can be sold. Osellus only sells and does =
not work in open source and no communities benefit. Hence, I thought =
that especially you guys would understand and not try to push the issue =
on this one.=20
Best regards,
Peter.
"Kamal Ahluwalia" <kamal@osellus.com> wrote in message =
news:fbpr2j$sbm$1@build.eclipse.org...
Thanks for your response Ricardo.
=20
This thread highlights some of the fundamental constraints in using =
EPF Composer, especially library.xml to maintain processes. It appears =
RMC 7.2 addresses some of these problems. Are there any plans to donate =
those bits to EPF so that the community can benefit ?
=20
Kamal=20
"Ricardo Balduino" <balduino@us.ibm.com> wrote in message =
news:fbpnj1$24t$1@build.eclipse.org...
>>> I wanted to clarify if it really is the case that EPF Composer =
is designed to be primarily used to maintain OpenUP only. =20
It is not really the case.
EPF Composer is used by the EPF team to maintain OpenUP, DSDM, =
Scrum, XP and any other processes being captured today and in the future =
under the EPF project.
Moreover, EPF users can capture their own home-grown processes or =
extensions to available processes using EPF Composer.
I hope this clarifies your question.
Regards,
Ricardo Balduino.
"Kamal Ahluwalia" <kamal@osellus.com> wrote in message =
news:fbpmjg$rai$1@build.eclipse.org...
"EPF Composer is designed to support a single project per =
library only as it is primary used to maintain OpenUP".
=20
I wanted to clarify if it really is the case that EPF Composer =
is designed to be primarily used to maintain OpenUP only. =20
=20
Kamal
"Roman Smirak" <roman.smirak@tietoenator.com> wrote in message =
news:f9rjjo$50e$1@build.eclipse.org...
Hi Peter,
that is great, the implementation perfectly matches with my =
vision. Why=20
not to have it in EPF? I guess many users would welcome the =
feature.
We have licences of RMC, however, we prefer to use EPF since =
early releases=20
are available.
Regards,
Roman
"Peter Haumer" <phaumer@us.ibm.com> wrote in message=20
news:f9qa5o$jac$1@build.eclipse.org...
> Hello Roman.
> Well, if our competitors can abuse this forum to plug their =
products; so=20
> can I :-)
>
> RMC 7.2 does not need the library.xmi file anymore as it =
uses the Eclipse=20
> workspace's projects to find all the files. Every plugin is =
a project as=20
> well as you can create more than one project for managing =
configurations=20
> and one project for estimation data (another RMC added =
value). The problem=20
> view is used just as in Eclipse to tell you if you are =
missing elements in=20
> your workspace that other elements depend upon. You could =
ignore those=20
> errors or fix them by loading the project's that contain the =
missing=20
> elements.
>
> See the attached image with an example where I was using =
plugins managed=20
> in CVS and plugins managed in CC all at the same time in the =
same=20
> workspace. Plugins can now reside in complete different =
directories even=20
> on different machine. Just like Eclipse projects, you load =
them into your=20
> workspace and use them whenever you need to use them.
>
> However, RMC can still generate a library.xmi for you to =
manage libraries=20
> that are fully compatible with EPF Composer. For example, if =
you check the=20
> OpenUP CVS repository: it already has project files in each =
plugin=20
> directory. That is because I was already working with =
OpenUP in RMC 7.2;=20
> at the same time where the rest of the team continued =
working with EPF=20
> Composer. Two ways of loading the same library in a fully =
compatible way.
>
> Hope this helps,
> Peter.
>
>
>
> "Roman Smirak" <roman.smirak@tietoenator.com> wrote in =
message=20
> news:f9p6up$mmu$1@build.eclipse.org...
>> Hi Peter,
>>
>> thanks for info, however, RMC is based on EPF and I see =
current=20
>> solution
>> of EPF (library.xml) as a fundamental constraint for clear =
& easy=20
>> solution
>> at RMC level. Or?
>>
>> Can you please describe the scenario with RMC how it will =
be implemented?
>>
>> Or shall I post this at IBM Rational forum?
>>
>> Roman
>>
>> "Peter Haumer" <phaumer@us.ibm.com> wrote in message
>> news:f9o54i$924$1@build.eclipse.org...
>>> 1) no, the guid remains the same
>>> 2) not sure I understand the context of this, but I would =
recommend to
>>> only version manage your own files and if you are using =
cvs directly get
>>> the OpenUP sources from our server or if you use CC =
provide a zip/rar=20
>>> file
>>> with the OpenUP files that users can unzip as view-private =
files
>>> 3) Rational Method Composer 7.2 will fully support this =
scenario, which=20
>>> is
>>> not in scope for EPF Composer. For enterprise deployments =
and full
>>> scalability we recommend RMC in which every plugin can be =
maintained as=20
>>> an
>>> eclipse project and loaded when needed. In addition we =
provide project
>>> types for configurations, enterprise reports, and =
estimation models in
>>> RMC. EPF Composer is designed to support a single project =
per library
>>> only as it is primary used to maintain OpenUP. A =
workaround for you=20
>>> would
>>> be what I described above for (2).
>>>
>>> Best regards,
>>> Peter Haumer.
>>>
>>>
>>> "Roman Smirak" <roman.smirak@tietoenator.com> wrote in =
message
>>> news:f9kcmi$idh$1@build.eclipse.org...
>>>> Hi Ricardo,
>>>>
>>>> the way you described below is the one I've been using =
so far;=20
>>>> however,
>>>> I have few issues here:
>>>> 1/ What if you refactor the content of OpenUP, e.g. an =
element I was
>>>> referencing to is no longer in same package or plugin? Is =
there any
>>>> impact on UID?
>>>>
>>>> 2/ Currently we have the whole library in a versioning =
repository,
>>>> although everyone has got the basis (OpenUP, or RUP) with =
the tool=20
>>>> (EMC,
>>>> or RMC) - no problem for OpenUP, in case of RUP, well we =
are talking
>>>> about 60MB or so (which you have to check in every time =
you migrate)
>>>>
>>>> 3/ Let say we have a common basis in our department X, =
let's call it
>>>> OpenUP/X; there is a project A which will use it plus =
extension A minus
>>>> irrelevant content from basis; in case of eclipse plugins =
they simply
>>>> check out required plugins (they stay in touch with their =
updates by
>>>> department X authority) but they don't check out =
irrelevant plugins (no
>>>> mess) + create their new one and check it in their =
repository (will be
>>>> maintained there); currently they need to check out whole =
library X +
>>>> submit their plugins A into the library shared by others =
(and they do
>>>> same action as well =3D> mess X + A + B + C, etc.) in =
order to fulfil the
>>>> use case (the basis maintained by department, a project =
extension
>>>> maintained by the project itself)
>>>>
>>>> I see the library.xml as a big constraint in this use =
case.
>>>>
>>>> Regards,
>>>>
>>>> Roman
>>>>
>>>> "Ricardo Balduino" <balduino@us.ibm.com> wrote in message
>>>> news:f9itco$87k$1@build.eclipse.org...
>>>>> In first paragraph I meant less cumbersome, yet safer =
;-)
>>>>>
>>>>> "Ricardo Balduino" <balduino@us.ibm.com> wrote in =
message
>>>>> news:f9g8d0$db$1@build.eclipse.org...
>>>>>> Option A sounds less cumbersome and safer, as the EPF =
Composer tool
>>>>>> will take care of the work. In fact, according to your =
description of
>>>>>> option A, OpenUP 2.x would overwrite OpenUP 1.x.
>>>>>>
>>>>>> Instead of playing with importing a new OpenUP plug-in =
into your
>>>>>> existing library, have you considered getting the new =
OpenUP library
>>>>>> available and import your plug-in into it instead? With =
that=20
>>>>>> approach,
>>>>>> you are moving your plug-in around, so you know there =
are no=20
>>>>>> duplicates
>>>>>> of it in a brand new OpenUP library. If your plug-in =
initially=20
>>>>>> depended
>>>>>> on some OpenUP element that does not exist anymore when =
a new version
>>>>>> of OpenUP is released, the import will show you =
warnings, which will
>>>>>> help you to spot where you need to maintain your =
plug-in to extend=20
>>>>>> the
>>>>>> most current version of OpenUP. Additions to OpenUP =
will not affect
>>>>>> your plug-in.
>>>>>>
>>>>>> Cheers,
>>>>>>
>>>>>> Ricardo Balduino.
>>>>>>
>>>>>> "K.Benameur" <benameur@freesurf.fr> wrote in message
>>>>>> news:f9f8cn$ah0$1@build.eclipse.org...
>>>>>>> Hi Peter,
>>>>>>>
>>>>>>> Sorry to bother you with all my questions !!!
>>>>>>>
>>>>>>> I am not sure that I have completly understood your =
answer.
>>>>>>>
>>>>>>> To check this I propose a simple scenario :
>>>>>>> - I develop a library using Open Up 1.x.
>>>>>>> - A new version of Open Up is out let say 2.x
>>>>>>> - I wan't to take advantage of this new Open Up =
version.
>>>>>>>
>>>>>>> A) So ideally, I import the new version in my library =
and Open Up=20
>>>>>>> 1.x
>>>>>>> is updated to 2.x.
>>>>>>>
>>>>>>> I have the feeling that it will not be so simple as =
many links will=20
>>>>>>> be
>>>>>>> broken due to changes between 1.X and 2.X.
>>>>>>>
>>>>>>> B) I use the copy operation to have the 1.X & 2.X =
plugin in my=20
>>>>>>> library
>>>>>>>
>>>>>>> It seems that option B) is the one to go as you said =
that we have to
>>>>>>> do a copy as uuid must be unique.
>>>>>>> =3D>
>>>>>>> I have to do the migration manually by replacing =
elements of Open=20
>>>>>>> 1.x
>>>>>>> by their counterparts in 2.x.
>>>>>>>
>>>>>>> is it right or I missed something like a smart import =
that detect
>>>>>>> conflicts and propose to update automatically element =
that exist in
>>>>>>> 1.X & 2.X /delete obsolete element of 1.X / etc.. ?
>>>>>>>
>>>>>>> The question is what is the recommended procedure to =
perform a=20
>>>>>>> plug-in
>>>>>>> upgrade with a minimum effort ?
>>>>>>>
>>>>>>> My concern will be the maintenance cost of a library. =
If we build=20
>>>>>>> our
>>>>>>> library from many commercial or non commercial plugins =
we have to=20
>>>>>>> deal
>>>>>>> with their evolutions at a minimal cost.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Best Regards ...
>>>>>>>
>>>>>>> PS: I will be in vacation for the next 2 weeks so you =
have plenty of
>>>>>>> time for an anwser ;)
>>>>>>>
>>>>>>>
>>>>>>> PS:
>>>>>>> We use ClearCase but it will not help here except to =
roll back to a
>>>>>>> stable baseline and lock elements for modification ...
>>>>>>> We are developping our process in multi site. As we =
didn't want to
>>>>>>> add more complexity we decided to work only on one =
site (windows
>>>>>>> terminal server for the distant site) with one =
development branch in
>>>>>>> base CC.
>>>>>>> May be you have a successfull experience using CC =
multisite & UCM ?
>>>>>>> Can you share your experience ?
>>>>>>> Seems that in CC 7 (we use CC 6) the merge manager =
have a new option
>>>>>>> i.e. to always copy. So may be we can now have =
branches & multisite=20
>>>>>>> as
>>>>>>> now xmi file can be merged by a copy. I see here a =
potential source=20
>>>>>>> of
>>>>>>> trouble as we may surely end with invalid references =
if for instance
>>>>>>> the merge (copy) is done partially on some xmi ...
>>>>>>>
>>>>>>> Peter Haumer wrote:
>>>>>>>> Hello.
>>>>>>>> You cannot load multiple versions of the same plugin =
into the same
>>>>>>>> library. All library elements are identified by =
global unique ids=20
>>>>>>>> and
>>>>>>>> hence such ids needs to be unique. To get more than =
one copy of an
>>>>>>>> element you need to use the copy operation in the =
library view. In
>>>>>>>> general we recommend to use a version control system =
like Rational
>>>>>>>> ClearCase which allows you to label and restore old =
versions of=20
>>>>>>>> whole
>>>>>>>> groups of files.
>>>>>>>>
>>>>>>>> Best regards,
>>>>>>>> Peter.
>>>>>>>>
>>>>>>>> P.S.: Surely they should not be an exception when =
loading the same
>>>>>>>> content twice, but an error message. Please, file a =
bugzilla with
>>>>>>>> reproducible steps.
>>>>>>>>
>>>>>>>>
>>>>>>>> "K.Benameur" <benameur@freesurf.fr> wrote in message
>>>>>>>> news:f973f4$goo$1@build.eclipse.org...
>>>>>>>>> Hi all,
>>>>>>>>>
>>>>>>>>> It is a very good question. May be it can be =
addressed by an=20
>>>>>>>>> update
>>>>>>>>> of an existing guideline as the Development =
Guideline ?
>>>>>>>>>
>>>>>>>>> I think that we should have a "recommended" =
procedure from the EPF
>>>>>>>>> team to update plug-ins to a new version.
>>>>>>>>> It is now a fairly common scenario that multiple =
versions of the
>>>>>>>>> same plug-ins are out.
>>>>>>>>>
>>>>>>>>> And it is not only related to Open Up but for any =
library /=20
>>>>>>>>> plug-in
>>>>>>>>> as part of the development process (we are =
developing our own
>>>>>>>>> library / plug-ins without Open Up).
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> In short, what is the recommended procedure to =
migrate to a new
>>>>>>>>> version ? Do we have to export / import ? What are =
the risks? What
>>>>>>>>> we may lose ?
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Best Regards
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>
>=20
------=_NextPart_000_0012_01C7F158.5DEC6CE0
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML xmlns:o =3D "urn:schemas-microsoft-com:office:office"><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.6000.16527" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>
<P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Arial','sans-serif'">Hi=20
Peter<o:p></o:p></SPAN></P>
<P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
'Arial','sans-serif'"><o:p> </o:p></SPAN></P>
<P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Arial','sans-serif'">As you very =
well know=20
Osellus has made significant contributions to the software process =
community by=20
the over three years work we have done in OMG culminating in a =
comprehensive=20
end-to-end standard submission. There are past EPF newsgroup threads on =
this=20
topic that the community is already aware of.<o:p></o:p></SPAN></P>
<P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
'Arial','sans-serif'"><o:p> </o:p></SPAN></P>
<P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Arial','sans-serif'">Recently, =
we are very=20
happy to see interest in this forum on the need for enactment of EPF =
generated=20
processes. This is in line with our long established philosophy of =
treating enactment entities as first class citizens and not an =
afterthought. We=20
are working on solutions that would move any content developed using EPF =
Composer to a collaborative development environment of choice for =
enactment in=20
live projects. The first version of this is <A=20
href=3D" http://www.osellus.com/products/contentbridge/contentbridge_ for_v=
sts.html"><SPAN=20
style=3D"FONT-SIZE: 11pt; COLOR: windowtext; FONT-FAMILY: =
'Calibri','sans-serif'; TEXT-DECORATION: none; text-underline: =
none">Content=20
Bridge for VSTS</SPAN></A>, a tool for moving processes from EPF=20
Composer to Microsoft=92s <A=20
href=3D"http://msdn2.microsoft.com/en-us/teamsystem/default.aspx"><SPAN=20
style=3D"FONT-SIZE: 11pt; COLOR: windowtext; FONT-FAMILY: =
'Calibri','sans-serif'; TEXT-DECORATION: none; text-underline: =
none">Visual=20
Studio Team System</SPAN></A>. <o:p></o:p></SPAN></P>
<P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
'Arial','sans-serif'"><o:p> </o:p></SPAN></P>
<P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Arial','sans-serif'">I would =
also point=20
out and hope that the clarifications we are seeking and the feedback we =
are=20
sharing in the forum will be of use to the community. =
<o:p></o:p></SPAN></P>
<P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
'Arial','sans-serif'"><o:p> </o:p></SPAN></P>
<P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Arial','sans-serif'">I see all =
of this as=20
significant investment by a company that is a fraction of the size of =
IBM. We=20
have been open to the idea of code-contribution but feel that the past =
concerns=20
we have raised relating to requirements, architecture and meta-model =
coupled=20
with the limited development resources prevent us from taking a =
more active=20
role than we already have.<o:p></o:p></SPAN></P>
<P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
'Arial','sans-serif'"><o:p> </o:p></SPAN></P>
<P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Arial','sans-serif'">Finally, I =
hope that=20
it=92s just my impression and not something you meant but I found your =
tone to=20
have crossed the boundaries of a professional inclusive attitude to =
individuals=20
who are trying to raise awareness on outstanding or unclear issues in =
this=20
newsgroup. I had merely asked if IBM was open to sharing the bits it had =
developed that may go way in making EPF more widely adopted. From your =
answer it=20
is clear that is not the case.<o:p></o:p></SPAN></P>
<P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
'Arial','sans-serif'"><o:p> </o:p></SPAN></P>
<P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
'Arial','sans-serif'">Thanks<o:p></o:p></SPAN></P>
<P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
'Arial','sans-serif'">Kamal<o:p></o:p></SPAN></P></FONT ></DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
<DIV>"Peter Haumer" <<A=20
href=3D"mailto:phaumer@us.ibm.com">phaumer@us.ibm.com</A>> wrote in =
message=20
<A=20
=
href=3D"news:fbqood$ijk$1@build.eclipse.org">news:fbqood$ijk$1@build.ecli=
pse.org</A>...</DIV>
<DIV><FONT face=3DArial size=3D2>Hello Kamal.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>I see an increase of interest and =
lecturing from=20
Osellus in recent days here in the forum. Are you guys finally =
ready to=20
contribute and write some code for EPF? ;-) </FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>As we clearly said, the feature to =
loosely=20
combine method plug-ins and scale your libraries up to the enterprise =
level is=20
a Rational Method Composer distinguishing feature and for us not in =
scope of=20
EPF. As Ricardo points out EPFC is powerful enough to build any =
kind of=20
large method library. The focus is here on one library at a =
time. =20
RMC allows to scale this up to multiple collocated libraries at the =
time.=20
</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>This is something we sell,=20
which </FONT><FONT face=3DArial size=3D2>is in line with =
the license and=20
agenda of Eclipse to provide platforms that can be used to build =
commercial=20
tools on top that can be sold. Osellus only sells and does not work in =
open=20
source and no communities benefit. Hence, I thought that especially =
you guys=20
would understand and not try to push the issue on this one. =
</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>Best regards,</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Peter.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
<DIV>"Kamal Ahluwalia" <<A=20
href=3D"mailto:kamal@osellus.com">kamal@osellus.com</A>> wrote in =
message=20
<A=20
=
href=3D"news:fbpr2j$sbm$1@build.eclipse.org">news:fbpr2j$sbm$1@build.ecli=
pse.org</A>...</DIV>
<DIV><FONT face=3DArial size=3D2>
<P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><SPAN=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New =
Roman','serif'">Thanks for=20
your response Ricardo.<o:p></o:p></SPAN></P>
<P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><SPAN=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New =
Roman','serif'"><o:p> </o:p></SPAN></P>
<P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><SPAN=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New =
Roman','serif'">This thread=20
highlights some of the fundamental constraints in using EPF =
Composer,=20
especially library.xml to maintain processes. It appears RMC 7.2 =
addresses=20
some of these problems. Are there any plans to donate those bits to =
EPF so=20
that the community can benefit ?<o:p></o:p></SPAN></P>
<P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><SPAN=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New =
Roman','serif'"><o:p> </o:p></SPAN></P>
<P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><SPAN=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New =
Roman','serif'">Kamal=20
<o:p></o:p></SPAN></P></FONT></DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
<DIV>"Ricardo Balduino" <<A=20
href=3D"mailto:balduino@us.ibm.com">balduino@us.ibm.com</A>> =
wrote in=20
message <A=20
=
href=3D"news:fbpnj1$24t$1@build.eclipse.org">news:fbpnj1$24t$1@build.ecli=
pse.org</A>...</DIV>
<DIV><FONT face=3DArial size=3D2>>>> <FONT size=3D3><FONT =
face=3D"Times New Roman">I wanted to clarify =
if it really is the=20
case that EPF Composer is designed to be primarily used to =
maintain OpenUP=20
only. </FONT></FONT></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><FONT size=3D3><FONT=20
face=3D"Times New Roman"></FONT></FONT></FONT> </DIV>
<DIV><FONT size=3D+0><FONT size=3D+0><FONT face=3DArial><FONT =
size=3D2>It is not=20
really the case.</FONT></FONT></FONT></FONT></DIV>
<DIV><FONT size=3D+0><FONT size=3D+0><FONT face=3DArial><FONT=20
size=3D2></FONT></FONT></FONT></FONT> </DIV>
<DIV><FONT size=3D+0><FONT size=3D+0><FONT face=3DArial><FONT =
size=3D2>EPF=20
Composer is used by the EPF team to maintain OpenUP, DSDM, Scrum, =
XP and=20
any other processes being captured today and in the future under =
the EPF=20
project.</FONT></FONT></FONT></FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>Moreover, EPF users can capture =
their own=20
home-grown processes or extensions to available processes using =
EPF=20
Composer.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>I hope this clarifies your=20
question.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>Regards,</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>Ricardo Balduino.</FONT></DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
<DIV>"Kamal Ahluwalia" <<A=20
href=3D"mailto:kamal@osellus.com">kamal@osellus.com</A>> =
wrote in=20
message <A=20
=
href=3D"news:fbpmjg$rai$1@build.eclipse.org">news:fbpmjg$rai$1@build.ecli=
pse.org</A>...</DIV>
<DIV><FONT face=3DArial size=3D2>
<P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><FONT =
size=3D3><FONT=20
face=3D"Times New Roman">=93EPF Composer is designed to support =
a single=20
project per library only as it is primary used to maintain=20
OpenUP=94.<o:p></o:p></FONT></FONT></P>
<P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><o:p><FONT=20
face=3D"Times New Roman" size=3D3> </FONT></o:p></P>
<P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><FONT =
size=3D3><FONT=20
face=3D"Times New Roman">I wanted to clarify =
if it really is the=20
case that EPF Composer is designed to be primarily used to =
maintain=20
OpenUP only. <o:p></o:p></FONT></FONT></P>
<P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><o:p><FONT=20
face=3D"Times New Roman" size=3D3> </FONT></o:p></P>
<P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><FONT =
size=3D3><FONT=20
face=3D"Times New =
Roman">Kamal<o:p></o:p></FONT></FONT></P></FONT></DIV >
<BLOCKQUOTE=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: =
5px; BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
<DIV>"Roman Smirak" <<A=20
=
href=3D"mailto:roman.smirak@tietoenator.com">roman.smirak@tietoenator.com=
</A>>=20
wrote in message <A=20
=
href=3D"news:f9rjjo$50e$1@build.eclipse.org">news:f9rjjo$50e$1@build.ecli=
pse.org</A>...</DIV>Hi=20
Peter,<BR><BR> that is great, the implementation =
perfectly=20
matches with my vision. Why <BR>not to have it in EPF? I guess =
many=20
users would welcome the feature.<BR><BR>We have licences of =
RMC,=20
however, we prefer to use EPF since early releases <BR>are=20
available.<BR><BR>Regards,<BR><BR>Roman<BR><BR>"Peter Haumer" =
<<A=20
href=3D"mailto:phaumer@us.ibm.com">phaumer@us.ibm.com</A>> =
wrote in=20
message <BR><A=20
=
href=3D"news:f9qa5o$jac$1@build.eclipse.org">news:f9qa5o$jac$1@build.ecli=
pse.org</A>...<BR>>=20
Hello Roman.<BR>> Well, if our competitors can abuse this =
forum to=20
plug their products; so <BR>> can I :-)<BR>><BR>> RMC =
7.2=20
does not need the library.xmi file anymore as it uses the =
Eclipse=20
<BR>> workspace's projects to find all the files. Every =
plugin is a=20
project as <BR>> well as you can create more than one =
project for=20
managing configurations <BR>> and one project for =
estimation data=20
(another RMC added value). The problem <BR>> view is used =
just as=20
in Eclipse to tell you if you are missing elements in <BR>> =
your=20
workspace that other elements depend upon. You could =
ignore=20
those <BR>> errors or fix them by loading the project's =
that=20
contain the missing <BR>> elements.<BR>><BR>> See the =
attached image with an example where I was using plugins =
managed=20
<BR>> in CVS and plugins managed in CC all at the same time =
in the=20
same <BR>> workspace. Plugins can now reside in complete =
different=20
directories even <BR>> on different machine. Just =
like=20
Eclipse projects, you load them into your <BR>> workspace =
and use=20
them whenever you need to use them.<BR>><BR>> However, =
RMC can=20
still generate a library.xmi for you to manage libraries =
<BR>> that=20
are fully compatible with EPF Composer. For example, if you =
check the=20
<BR>> OpenUP CVS repository: it already has project files =
in each=20
plugin <BR>> directory. That is because I was already =
working=20
with OpenUP in RMC 7.2; <BR>> at the same time where the =
rest of=20
the team continued working with EPF <BR>> Composer. =
Two ways=20
of loading the same library in a fully compatible =
way.<BR>><BR>>=20
Hope this helps,<BR>> =
Peter.<BR>><BR>><BR>><BR>> "Roman=20
Smirak" <<A=20
=
href=3D"mailto:roman.smirak@tietoenator.com">roman.smirak@tietoenator.com=
</A>>=20
wrote in message <BR>> <A=20
=
href=3D"news:f9p6up$mmu$1@build.eclipse.org">news:f9p6up$mmu$1@build.ecli=
pse.org</A>...<BR>>>=20
Hi Peter,<BR>>><BR>>> thanks for info, =
however, RMC is based on EPF and I see current <BR>>>=20
solution<BR>>> of EPF (library.xml) as a fundamental =
constraint=20
for clear & easy <BR>>> solution<BR>>> at RMC =
level.=20
Or?<BR>>><BR>>> Can you please describe the =
scenario with=20
RMC how it will be implemented?<BR>>><BR>>> Or =
shall I=20
post this at IBM Rational forum?<BR>>><BR>>>=20
Roman<BR>>><BR>>> "Peter Haumer" <<A=20
href=3D"mailto:phaumer@us.ibm.com">phaumer@us.ibm.com</A>> =
wrote in=20
message<BR>>> <A=20
=
href=3D"news:f9o54i$924$1@build.eclipse.org">news:f9o54i$924$1@build.ecli=
pse.org</A>...<BR>>>>=20
1) no, the guid remains the same<BR>>>> 2) not sure I =
understand the context of this, but I would recommend=20
to<BR>>>> only version manage your own files and if =
you are=20
using cvs directly get<BR>>>> the OpenUP sources from =
our=20
server or if you use CC provide a zip/rar <BR>>>>=20
file<BR>>>> with the OpenUP files that users can =
unzip as=20
view-private files<BR>>>> 3) Rational Method Composer =
7.2=20
will fully support this scenario, which <BR>>>>=20
is<BR>>>> not in scope for EPF Composer. For =
enterprise=20
deployments and full<BR>>>> scalability we recommend =
RMC in=20
which every plugin can be maintained as <BR>>>>=20
an<BR>>>> eclipse project and loaded when needed. In =
addition=20
we provide project<BR>>>> types for configurations,=20
enterprise reports, and estimation models in<BR>>>>=20
RMC. EPF Composer is designed to support a single =
project per=20
library<BR>>>> only as it is primary used to maintain =
OpenUP. A workaround for you <BR>>>>=20
would<BR>>>> be what I described above for=20
(2).<BR>>>><BR>>>> Best =
regards,<BR>>>>=20
Peter Haumer.<BR>>>><BR>>>> <BR>>>> =
"Roman=20
Smirak" <<A=20
=
href=3D"mailto:roman.smirak@tietoenator.com">roman.smirak@tietoenator.com=
</A>>=20
wrote in message<BR>>>> <A=20
=
href=3D"news:f9kcmi$idh$1@build.eclipse.org">news:f9kcmi$idh$1@build.ecli=
pse.org</A>...<BR>>>>>=20
Hi =
Ricardo,<BR>>>>><BR>>>>> the=20
way you described below is the one I've been using so far;=20
<BR>>>>> however,<BR>>>>> I have few =
issues=20
here:<BR>>>>> 1/ What if you refactor the content =
of=20
OpenUP, e.g. an element I was<BR>>>>> referencing =
to is no=20
longer in same package or plugin? Is there =
any<BR>>>>>=20
impact on UID?<BR>>>>><BR>>>>> 2/ =
Currently we=20
have the whole library in a versioning =
repository,<BR>>>>>=20
although everyone has got the basis (OpenUP, or RUP) with the =
tool=20
<BR>>>>> (EMC,<BR>>>>> or RMC) - no =
problem=20
for OpenUP, in case of RUP, well we are =
talking<BR>>>>>=20
about 60MB or so (which you have to check in every time you=20
migrate)<BR>>>>><BR>>>>> 3/ Let say we =
have a=20
common basis in our department X, let's call =
it<BR>>>>>=20
OpenUP/X; there is a project A which will use it plus =
extension A=20
minus<BR>>>>> irrelevant content from basis; in =
case of=20
eclipse plugins they simply<BR>>>>> check out =
required=20
plugins (they stay in touch with their updates =
by<BR>>>>>=20
department X authority) but they don't check out irrelevant =
plugins=20
(no<BR>>>>> mess) + create their new one and check =
it in=20
their repository (will be<BR>>>>> maintained =
there);=20
currently they need to check out whole library X =
+<BR>>>>>=20
submit their plugins A into the library shared by others (and =
they=20
do<BR>>>>> same action as well =3D> mess X + A =
+ B + C,=20
etc.) in order to fulfil the<BR>>>>> use case (the =
basis=20
maintained by department, a project =
extension<BR>>>>>=20
maintained by the project=20
itself)<BR>>>>><BR>>>>> I see the =
library.xml=20
as a big constraint in this use=20
case.<BR>>>>><BR>>>>>=20
Regards,<BR>>>>><BR>>>>>=20
Roman<BR>>>>><BR>>>>> "Ricardo =
Balduino"=20
<<A =
href=3D"mailto:balduino@us.ibm.com">balduino@us.ibm.com</A>>=20
wrote in message<BR>>>>> <A=20
=
href=3D"news:f9itco$87k$1@build.eclipse.org">news:f9itco$87k$1@build.ecli=
pse.org</A>...<BR>>>>>>=20
In first paragraph I meant less cumbersome, yet safer=20
;-)<BR>>>>>><BR>>>>>> "Ricardo =
Balduino"=20
<<A =
href=3D"mailto:balduino@us.ibm.com">balduino@us.ibm.com</A>>=20
wrote in message<BR>>>>>> <A=20
=
href=3D"news:f9g8d0$db$1@build.eclipse.org">news:f9g8d0$db$1@build.eclips=
e.org</A>...<BR>>>>>>>=20
Option A sounds less cumbersome and safer, as the EPF Composer =
tool<BR>>>>>>> will take care of the work. =
In fact,=20
according to your description of<BR>>>>>>> =
option A,=20
OpenUP 2.x would overwrite OpenUP=20
1.x.<BR>>>>>>><BR >>>>>>> =
Instead=20
of playing with importing a new OpenUP plug-in into=20
your<BR>>>>>>> existing library, have you =
considered=20
getting the new OpenUP library<BR>>>>>>> =
available=20
and import your plug-in into it instead? With that=20
<BR>>>>>>> =
approach,<BR>>>>>>> you=20
are moving your plug-in around, so you know there are no=20
<BR>>>>>>> =
duplicates<BR>>>>>>> of=20
it in a brand new OpenUP library. If your plug-in initially=20
<BR>>>>>>> =
depended<BR>>>>>>> on=20
some OpenUP element that does not exist anymore when a new=20
version<BR>>>>>>> of OpenUP is released, the =
import=20
will show you warnings, which will<BR>>>>>>> =
help=20
you to spot where you need to maintain your plug-in to extend=20
<BR>>>>>>> the<BR>>>>>>> =
most=20
current version of OpenUP. Additions to OpenUP will not=20
affect<BR>>>>>>> your=20
=
plug-in.<BR>>>>>>> <BR>>>>>>>=20
=
Cheers,<BR>>>>>>> <BR>>>>>>>=20
Ricardo=20
=
Balduino.<BR>>>>>>> <BR>>>>>>>=20
"K.Benameur" <<A=20
=
href=3D"mailto:benameur@freesurf.fr">benameur@freesurf.fr</A>> wrote=20
in message<BR>>>>>>> <A=20
=
href=3D"news:f9f8cn$ah0$1@build.eclipse.org">news:f9f8cn$ah0$1@build
|
|
|
| Re: Migration to newever library version [message #583068 is a reply to message #40208] |
Sun, 09 September 2007 04:27 |
AJ
Messages: 77
Registered: July 2009 |
Member |
|
|
Hi Kamal,
I 100% agree with your comments, in particular the one about peter.
However, keep in mind that he does not speak for IBM or the EPF project
team.
Regarding the process enactment, it is clear that the UMA meta-model gives
software development a knowledge of structure. A structure for experts to
document how software development and related activities are conducted.
Thus the content in EPF grows, it becomes a huge knowledge base. However,
this also means that for practitioners, the wealth of such knowledge
becomes hard to absorb.
So, it will be fantastic to have efforts to make EPF enactable. For
instance, a way to execute the content in EPF and do the following:
1. Guide the practitioner in applying EPF processes.
2. Update the models for the practitioner.
3. Check what the practitioner does.
4. Able to execute an active process description from EPF passive set of
web pages.
For the later, which I presonally rather call it "Dynamic Process", we
need to investigate a way to specify and build an execution engine for the
EPF core model. For instance, the Actions Semantics (an extension to the
UML), to describe the behavior of actions; or the workflow formalism
defined in the OMG Workflow Management Facility.
Also, notice that defining in a consistent manner both the definition and
execution meta-models may also lead to many benefits in process
management. In the WfMC reference model the design of a workflow and its
execution are separate activities. Weaving these two aspects may allow
roundtrips between them. Therefore, changes in the definition may impact
the under way executions. This could even allow the process definition to
be built as the executions go along. So, executions may also alter the
process definition.
Cheers,
-AJ
|
|
|
Goto Forum:
Current Time: Fri Apr 19 21:29:21 GMT 2024
Powered by FUDForum. Page generated in 0.07815 seconds |
] 
Search
Help
Register
Login
Home
