Centralizing the toolbox

Posted by rbf on 24-Feb-2009 09:33

It is possible to centralize the assemblies.xml file by using the -assemblies startup parameter. How can you achieve something similar with the toolbox.xml file?

All Replies

Posted by Matt Baker on 24-Feb-2009 09:55

Use a linked file.

Posted by rbf on 24-Feb-2009 10:07

I vaguely remember that from *nix, but on windoze?

Posted by Admin on 24-Feb-2009 10:14

He was probably talking about a linked resource of type file in eclipse.

Use the file -> new menu and select "File".

In the advanced part of the dialog, you can link it to an existing file on the file system (on any folder). I haven't tried that with the toolbox.xml file yet. But if that works, it should be the solution.

The problem with files used by the prowin32.exe and the linked resources is that the prowin32.exe still relies more on the propath then on eclipses virtual file system.

Message was edited by:

Mike Fechner

Posted by Matt Baker on 24-Feb-2009 10:23

Yes, I was talking about Eclipse linked files as Mike pointed out.

Posted by Simon de Kraa on 24-Feb-2009 12:07

I vaguely remember that from *nix, but on windoze?

Off-topic.

Junction.exe can be used to create Windows symbolic links which can come in handy if you for example installed OpenEdge in a different directory than is expected by a 3rd party tool.

junction.exe C:\Progress\OE10.2A C:\Progress\OpenEdge

Posted by Admin on 24-Feb-2009 13:55

That's really cool!

But after reading the text on the website I doubt it really helps with the toolbox.xml file as junktion.exe creates links for directories, not files and toolbox.xml needs to be located in the project root folder.

Posted by Simon de Kraa on 24-Feb-2009 14:11

I know, this was just FYI... Couldn't resist...

Posted by rbf on 02-Mar-2009 14:07

Use a linked file.

Well after trying that out in single user mode for a week I switched to trying it in multi user mode and the results were desastrous. OEA does not seem to like to share that file. Some workstations even refused to startup OEA. The only solution was to manually remove the linked file reference from the .project file.

So even though linked files are possible, be warned not to use them for multi user update mode.

Posted by Matt Baker on 02-Mar-2009 15:52

Perhaps a better explanation of what "multi user mode" encompasses. Does this mean you are sharing everything on a MS file share? Are are you using version control and the linked directory has a hard-coded path to something on your machine and no one else has the exact same path.

 * mbaker ponders unclosed file handles.

Posted by rbf on 02-Mar-2009 15:55

The file is on a windoze network share. At least that was the general idea.

Posted by Matt Baker on 02-Mar-2009 16:01

Linked files end up as entries in the .project file. They generally are a hard-coded absolute path to the directory/file in question. Is this path correct for your network share environment? And if it is, then would you care to log a bug with tech support to the affect that OEA (actually visual designer) isn't sharing the file nicely with other people.

Posted by rbf on 02-Mar-2009 16:10

Yes the path is the same for everybody on the network.

I will look into it.

Posted by egarcia on 03-Mar-2009 08:29

In reference to links on a Windows platform.

The fsutil hardlink command can be used to create links to files on a local NTFS drive (which then could be accessed as shared).

I do not think that using a link as this would help for sharing the toolbox.xml. Specially when it on a source control system.

I just wanted to mention it to clarify on a previous post about junction.

Posted by jankeir on 03-Mar-2009 08:50

In reference to links on a Windows platform.

The fsutil hardlink command can be used to create

links to files on a local NTFS drive (which then

could be accessed as shared).

Thank you! I didn't know that command yet but have long wanted it.

This thread is closed