Make previousLocation customizable in Archi4Migrator

[jbsarrodie]

Hi,

Like some other (enterprise) users, I maintain an internal package for Archi which exhibits some specific configuration. Until now, I was using a custom location for Archi's config files and user "profile". Now that these have changed, I'd like to use the new defaults.

My issue is that the Archi4Migrator use hard-coded path for previousLocation, so it is not able to migrate data in my context. Would it be possible to make it customizable in some ways so that it could work also in my context?

Ping #925

[Phillipus]

The idea for the Archi4Migrator was to handle the typical user who has defaults for previousLocation. I was hoping that power users might do a manual copy to the new destinations.

The problem is, how would the migrator know what the previous locations were? When Archi 5 is launched it only knows its own locations for workspace etc.

Unless perhaps it takes some arguments?

[jbsarrodie]

I was hoping that power users might do a manual copy to the new destinations.

People (like me) who designs such custom configs are power users, but our end users are not :-(

The problem is, how would the migrator know what the previous locations were? When Archi 5 is launched it only knows its own locations for workspace etc. Unless perhaps it takes some arguments?

Yes, IMHO the best way to do it would be through a new argument passed through Archi.ini (because if one face this issue, that's because he/she already changed this file).

Is this something possible ?

(another option for me is to simply stick with my custom setup)

[Phillipus]

If it was just one location instead of the default user.home/AppData/Roaming/Archi4 that could be specified in the Archi.ini file like -DmigrationLocation=/path/to/Archi4 but would get complicated if you've set more than one location for workspace and dropins and config.

[Phillipus]

So the answer is "yes" if it's just one location. Note that the migrator creates a marker file called migrated in the previous location so it knows not to ask again.

[jbsarrodie]

BTW, I might have another related issue : for coArchi users, migrating Archi4 folder also means moving thousands of XML files, and this is a very long operation. Asof now, there's no feedback for people to know the operation is ongoing, and some might think Archi is stuck and kill it while the operation is not finished. Maybe some visual feedback to know that Archi does something would be helpful.

[jbsarrodie]

[...] but would get complicated if you've set more than one location for workspace and dropins and config.

...which is my case :-(

I do use a path using "plugins" instead of "dropins" because this is easier to understand for people (if at some points they have to do something manually with this folder).

Maybe a set of options:

• -DworkspaceMigrationLocation=/path/to/Archi4
• -DdropinsMigrationLocation=/path/to/Archi4
• -DconfigMigrationLocation=/path/to/Archi4

?

[Phillipus]

Maybe some visual feedback

I can show a cancellable progress dialog. If the user cancels, the operation is halted, and the migrated file is not created. The user will be asked again next time with the same options. The probably shouldn't have cancelled, but maybe something happened.

The config location is junk and that doesn't get copied.

[Phillipus]

Well I can do it if there are just two options:

-DworkspaceMigrationLocation=/oldPath
-DdropinsMigrationLocation=/oldPath

If the first option is set that is used instead of the inbuilt one.

If the second option is set it will copy that directory, if it exists, to a dropins folder in the new workspace location. But if you have also set -Dorg.eclipse.equinox.p2.reconciler.dropins.directory to something else then things are going to get really complicated and that is something I don't want to do (See code in DropinsPluginHandler for how complicated that is.)

[Phillipus]

But if you want to migrate the old dropins folder that implies that you want it to be copied to the new default dropins location, right? Otherwise you would keep the existing -Dorg.eclipse.equinox.p2.reconciler.dropins.directory setting?

[jbsarrodie]

But if you want to migrate the old dropins folder that implies that you want it to be copied to the new default dropins location, right? Otherwise you would keep the existing -Dorg.eclipse.equinox.p2.reconciler.dropins.directory setting?

Not necessarily. In my case I use a custom dropins folder named "plugins" and under "Archi4", so I might want to migrate it outside this "Archi4" folder, but not into the default dropins folder.

But if you have also set -Dorg.eclipse.equinox.p2.reconciler.dropins.directory to something else then things are going to get really complicated

~Not sure to see why this would be complicated.~

Ok, I've looked at the logic coded into DropinsPluginHandler and see the issue related to % variables substitutions. Btw, this would also impact workspaceMigrationLocation and dropinsMigrationLocation as they would also rely on % variables.

Would it be possible to make DropinsPluginHandler#getUserDropinsFolder() and DropinsPluginHandler#substituteVariables() public and static and to call them from Archi4Migrator ? This would make it possible to "decode" workspaceMigrationLocation and dropinsMigrationLocation, and to find the right target dropins folder, whatever its path/name.

If such approach makes sense for you, I can work on it myself and let you review the code after.

[Phillipus]

It's not the problem of substituteVariables (which actually is only needed for the dropins folder). It's the way that the dropins folder can be one of many things (user set, "plugins", etc...)

But I think I can find a way to do this - move substituteVariables into ArchiPlugin, add a getUserDropinsFolder method there (which returns null if not set) and then use that when copying to a user set dropinsMigrationLocation

I can work on it myself and let you review the code after.

I'll do it.

[Phillipus]

BTW - work so far is in migrator branch.

[jbsarrodie]

which actually is only needed for the dropins folder

Well, if workspaceMigrationLocation is set to @user.home\somepath, something has to happen for this @user.home to be converted to something useful (unless the magical eclipse framework does it for us?).

I'll do it.

Thank you !

[Phillipus]

@user.home is easy - we do a path.replace("@user.home", System.getProperty("user.home")); But the dropins substitution is more complicated to be Eclipse compatible.

[Phillipus]

(I'll just be glad when everyone has migrated to Archi 5)

[Phillipus]

OK, I think I've done it now. You can set these in Archi.ini before launching Archi for the first time:

-DworkspaceMigrationLocation=@user.home/oldPath/to/workspace
-DdropinsMigrationLocation=/oldPath/to/dropins
-Dorg.eclipse.equinox.p2.reconciler.dropins.directory=%user.home%/somewhere/else

Dropins will be copied from dropinsMigrationLocation to whatever is set in org.eclipse.equinox.p2.reconciler.dropins.directory (assuming they're not the same).

Note that we use the %user.home% for the dropins path because that's what Eclipse parses when it sets the dropins folder. In order for us to also parse the dropins folder we have to do the same thing (there's no simple Eclipse API to get this so we have to re-invent the wheel with our copy of substituteVariables to get it. Hey, Eclipse rocks! 😢 )

[Phillipus]

Not necessarily. In my case I use a custom dropins folder named "plugins" and under "Archi4"

Now it gets complicated if that plugins folder is in user.home/AppData/Roaming/Archi4. When copying files and folders to the new destination from this folder the logic is:

• If it's a file, copy it to target workspace (files like models.xml, templates.xml)
• If it's the .config folder, ignore it
• If it's the dropins folder, copy it to target workspace
• If it's the .metadata folder, copy it to target workspace
• If it's any other folder (could be model-repository, jasper-reports or any user created folder) copy it to user.home/Documents/Archi

So your plugins folder will get copied as in the last case.

[Phillipus]

It might be easier if you tell me what your folder layout is exactly, so I can test it. It's all getting rather complicated.

[jbsarrodie]

It might be easier if you tell me what your folder layout is exactly, so I can test it.

Here's my current configuration:

-Dosgi.instance.area=@user.home/Archi4
-Dosgi.configuration.area=@user.home/Archi4/.config
-Dorg.eclipse.equinox.p2.reconciler.dropins.directory=%user.home%/Archi4/plugins

Now it gets complicated if that plugins folder is in user.home/AppData/Roaming/Archi4. When copying files and folders to the new destination from this folder the logic is: [...] So your plugins folder will get copied as in the last case.

I guess it is possible to check if current file/folder to be copied is the same as dropinsMigrationLocation, and if yes skip it.

It's all getting rather complicated.

You don't have to implement all this by yourself, I can easily work on it in the coming days if you want.

[Phillipus]

You don't have to implement all this by yourself, I can easily work on it in the coming days if you want.

I'm almost done with it, but getting a fix out for HTML/Jasper not working should come soon.

[Phillipus]

Here's my current configuration:

And what will be the settings for the new Archi.ini 5 configuration, including the workspaceMigrationLocation and dropinsMigrationLocation?

These ones:

-Ddata.location=@user.home/Documents/Archi
-Dosgi.instance.area=@user.home/AppData/Roaming/Archi
-Dosgi.configuration.area=@user.home/AppData/Roaming/Archi/config
-Dorg.eclipse.equinox.p2.reconciler.dropins.directory=%user.home%/AppData/Roaming/Archi/dropins

The migration ones will be:

-DworkspaceMigrationLocation=@user.home/Archi4
-DdropinsMigrationLocation=@user.home/Archi4/plugins

[Phillipus]

I guess it is possible to check if current file/folder to be copied is the same as dropinsMigrationLocation, and if yes skip it.

Yes, that should work

Please try this build - https://www.archimatetool.com/downloads/temp/Archi-Win64-5.0.2.zip

[jbsarrodie]

Please try this build

Checking it tomorrow morning :-)

[jbsarrodie]

Checking it tomorrow morning :-)

I've checked and it almost work. For some reasons my dropins folder (name plugins) didn't get copied. I'm trying to understand why (checking the code and my folders right now)

[Phillipus]

Please post args you're using and folder structure

[jbsarrodie]

It now works !

The migration ones will be:

-DworkspaceMigrationLocation=@user.home/Archi4
-DdropinsMigrationLocation=@user.home/Archi4/plugins

In fact dropinsMigrationLocation should be defined as %user.home%/Archi4/plugins instead (variables pattern is different).

[Phillipus]

In fact dropinsMigrationLocation should be defined as %user.home%/Archi4/plugins instead (variables pattern is different).

No, dropinsMigrationLocation is parsed using @user.home The %user.home% construct only works in org.eclipse.equinox.p2.reconciler.dropins.directory

[jbsarrodie]

Wait, it seems to work, but there might be an issue anyway. Digging....

[Phillipus]

Please share your Archi.ini...

[jbsarrodie]

No, dropinsMigrationLocation is parsed using @user.home The %user.home% construct only works in org.eclipse.equinox.p2.reconciler.dropins.directory

That's what I've seen just after.

I've solved it. The root cause was an issue with my Archi.ini in which (due to several changes done), I had -Dorg.eclipse.equinox.p2.reconciler.dropins.directory=@user.home/Documents/Archi/plugins5, so using the wrong variable.

At some point I thought it worked with -DdropinsMigrationLocation=%user.home%/Archi4/plugins, but that was just a side effect of Archi4Migrator not able to find the old dropins folder, so copying everything (including my old plugins dir) into the target workspace.

So in short: was my fault and eclipse using multiple variables patterns sucks ;-)

It definitely works !

[jbsarrodie]

BTW: I think this Archi4Migrator can be helpful also in the long term (in fact each time someone has to change the default configuration)

[Phillipus]

This is now in Archi 5.0.2.