On importing CS 10.0 modules to CS 10.5 and beyond

Hi,

I was moving some of my CS 10.0 code into CSIDE the other day, and I noticed a difference in the way that the latest version of the CSIDE plug-in works compared to a year ago. When comparing to the code I ported 1 year ago, this year's batch, all the Oscript objects get dropped into the top level package, while a year ago, there was some attempt to create packages loosely based on the inheritance hierarchy, that is, if I had a couple of orphans in my Ospace root, say Objects, Frames, and DbSCripts, I would see three new packages in my converted source.

This has proved handy in the past in that my Oscript source is now neater. The new plugin, when it drops everything into the top level package, you increase the likelihood of a name collision. I had one where I had my standard Configure request handler, and another request handler that was a child of an LL request handlers orphan also named Configure get renamed to Configure_1 which kind of botched that request handler. Is the old behaviour of a first attempt at packaging still possible with a switch somewhere? Or is there a legacy module layout that better supports the conversion to packages?

Also, on packaging, if I start repackaging my source in my converted module, will it still respect the original $MyOspace.ChildObject.SubObject path convention, or do I need to edit the legacy.alias file? Although I'm looking to ultimately go to a CS 10.5 and up (soon to be a CS 16 and up) development pipeline, I need to be able to support the old format for a while as I have a lot of code to convert, and I'm going to have to keep the old format at least until I can make a clean break from CS 10.0 codebase.

Thanks in advance.

-Hugh Ferguson

Find more posts tagged with

Comments

Juliano_Ghisi

Hello Hugh,

First of all, thanks for your contact and for bringing this concern into our attention.

I have discussed this topic with our team and we are investigating this behaviour.

Best Regards

Juliano

HFCDev

Thanks Juliano,

In the meantime, could I maybe get an answer to this: Let's say I complete my import of my module, and I want to rearrange the source into packages so that it flows better. As an example, I have $MyModule.DbScripts as a child of my ospace root, and it has two children, say MSSQL and Oracle. In the source, I have now three objects - DbScripts.os, MSSQL.os, and Oracle.os. I now want to put all three into a package called MyModule::DbScripts. Should I be altering the legacy.alias file to do this? I'm able to move all three into a new package, but I want to make sure that the aliases will be respected so that nothing breaks.

-Hugh

HFCDev

I still haven't seen a response to my last question. I shall ask again. Is there a way to reorganize your Oscript source safely into packages after an import? Assuming that I'm going to be working in CSIDe and working with the source, but I don't want to lose the work already done in CS 10.0, I need to know what is the path forward to reorganize my source so it's manageable? Having everything simply dumped at the top level is simply unmanageable.

What I found is that if I simply repackage everything, it works for a bit, then at some point it will mess up the build, and in the module explorer, the ospace will have absolutely no methods. Previously I tried to update the legacy.alias file with the new package names as I went but that too resulted in the compiled ospace eventually having no methods or features.

Are we basically being asked to completely rebuild our modules from scratch in CSIDE? Is that what you guys did at OpenText DEV?!?

Maybe as a start, can someone explain how the new format (i.e. OSPACE::pkgName::feature) is mapped to the oldschool $OSPACE.CHildName.SubChild.Feature. Further, how is that maintained if you repackage something?

-Hugh Ferguson

HFCDev

OK, I found it!!

There is a trick. You *do* have to update the legacy.alias file, but you need to be updating that and all your .os files in tandem. If there is any mess up, the Ospace builds messed up, but as soon as you correct the mistake, it rebuilds properly and you see your original ospace in the module explorer.

I'm waiting to see what happens if I fix the packaging in 10.5 if the module will import properly in 16.

-Hugh

HFCDev

I thought I'd clarify one thing. I'm actually now wondering if the legacy.alias file was a red herring, but it was rather the corrections to various errors that I got when I reorganized my package. Probably more critical to ensuring that the old-school $Module.Child.SubChild.feature convention continues to work is the set up in the ospace's Globals.os file (which is invisible in the Module browser but quite visible when you decompile your ospace to source).

-Hugh

Breemer_Rick

Hi Hugh,

As far as I can tell, there's no need to retain the legacy.alias file. From my understanding, you can safely delete the file and just create packages and move .os files inside them. Just be mindful of updating the package line in the .os file, since it's not updated automatically when you move the file into a different package.

Cheers,

Rick