Importing CS 10 module to CS 16 - sometimes appends _1 to end of feature

Hi,

I imported a group of modules today from CS 10 to CS 16. All but one of them imported properly. The other, it always imports and in the src, the Configure request handler gets renamed to Configure_1, meaning if I uninstall and reinstall the newly CS-16-ized module, it will fail to install because the request handler name got renamed.

The request handler group shows a reference to the renamed Configure_1 in the new CS10.5 syntax,

but if allowed to compile, it replaces Configure with Configure_1.

I imported this module both in a group, and also completely in isolation. Can anyone explain what's going on? is this a new CSIDE bug? I'm using CSIDE 16.0.0.1119

-Hugh Ferguson

PS One huge pitfall of making all the documentation only available online is that in the Government of Canada, all servers are configured such that only an account with internet disabled is allowed to log on to the server. That makes reviewing documentation within CSIDE impossible

Find more posts tagged with

Comments

Apparao Saripilli

Hi Hugh Ferguson,

i am also facing same issue, did you find any solution?

Thanks

Appa.

HFCDev

So far I didn't. As the client had a change of management and all custom code projects were halted I didn't get a chance to follow up. For another client, I'm revisiting this. As I recall, after the import, I could manually reorganize the source, although if you do this, double check each time that your module rebuilds immediately after you repackage any of your objects. I found this a rather tedious process to be honest. A much older version of the CSIDE plug-in did a much better job at reorganization and would attempt to at least for objects creatd under $Ospace root, place them into equivalently named packages, ie if you had $MyOspace.Utils.DBUtils and a bunch of functions, it would try to create MyOspace::Utils::DBUtils as a package in your source. Since 1 yr ago, it just dumps everything into the root package which causes name collision.

-Hugh

Hany Samuel

This issue has been resolved since CSIDE 16.0.2.1333 that was released in December 2, 2016. Please use latest CSIDE released version 16.2.2.5 (released August 23, 2017) and please update the thread if you still encounter this issue or any other issues.

Thanks,

David Templeton

I suggest we state this thread is closed. As always stay up to date with the releases

David

Chris Meyer

I see the behaviour described by Hugh with the latest release of CSIDE (com.opentext.cside_16.2.2.5.jar as of 7.11.17). An OSpace import will often put everything into a single package, which causes all sorts of problems with naming and organization. It also crashes sometimes with the following error:

Errors occurred during the build.Errors running builder 'OScript Source Builder' on project 'OTCS162'.Unable to clean up OLL Builder.Connection refused to host: 10.0.2.15; nested exception is:     java.net.ConnectException: Connection refused: connectUnable to clean up OLL Builder.Connection refused to host: 10.0.2.15; nested exception is:     java.net.ConnectException: Connection refused: connect

I find it unusable.

For this and other reasons I've written my own .oll to .os conversion tool, which I have found to be faster and more reliable. It's also been very useful for maintaining a single code stream from CS10 to the latest version.

@Hugh: If you're still seeing this behaviour with the latest CSIDE release then perhaps we should try my conversion tool with your ospace. I'll send you an e-mail.

Eric_Hohnbaum

I have seen that when attempting to import from OLL to source more than once. The idea was to refresh the source from the OLL. I havent tried it on the latest CSIDE plugin but posters were asking what can cause it.

Hany Samuel

Quoted Eric Hohnbaum on 02/12/2018 09:35 AM:

This should not be happening with the latest plugin, please report if you see it with the detailes of your OLL so we can track it. The only case for this to happen now when you have two or more objects with the same name, as now objects are represented as file in the file systems and you can not have same file name replicated on the same folder so we append _x to the name where x is the number of this name replication. If this happens, you have to change the name in your code.

Chris Meyer

Is there a reason the import operation no longer creates a hierarchy of packages? This helped mitigate naming conflicts when similarily named objects were members of different packages.

Hany Samuel

import operation does create the hierarchy of packages ! Are you using the latest released CSIDE ?

Chris Meyer

import operation does create the hierarchy of packages ! Are you using the latest released CSIDE ?

I've had this problem for a year or two now on various instances, so it's unlikely an isolated case. I just had it fail again with com.opentext.cside_16.2.3.107.jar, Eclipse Mars.2, and CS16.0.3.

Hany Samuel

Please report exactly what you encounter and how to reproduce it so we can inverstigate. Please include the oll that causes this behaviour (if possible). In your eclipse workspace, zip the contents of the folder .metadata\.plugins\com.opentext.cside and attach it (these are the logs). You can send this information directly to my email.

Thanks