Choosing compile target version for CSIDE

Hi,

I think I know how to do this, but I would like clarification. Given that CSIDE is a single jar that works on every version of Content Server from 10.5 to 16.2, what determines whether the ospace builds to a 10.5 ospace, a 16.0 ospace, or above? I suspect that internally CSIDE may be using the environment to determine which compatibility level to build to, but I just wanted to check that. Presumably that means a vendor, if needing to produce modules compatible with 10.5, 16.0 and 16.2 and beyond, they would have one Oscript source project and share it between different environments - the same CSIDE plugin lloaded into an environment that is 10.5, another that is 16.0, and so on.

If this is incorrect, please advise the correct approach.

Thanks

-Hugh

Find more posts tagged with

Comments

Chris Meyer

Hi Hugh, I believe there are three OLL binary formats: CS10, CS10.5, and CS16+. I suspect the CS16 binary format won't change in the future.

I know some partners who continue to develop in CS10 and use the OSpaces with CS10.5 and later. Content Server loads them in some type of legacy mode. It technically works, but I had some performance problems and now always compile the OSpace for the target platform (either CS10.5 or CS16 and later) when I make a release.

I work by developing in CS10 (Builder) and run an export script to update the srcmodules/ of the CSIDE installation with the .os files. This gets picked up by CSIDE and is compiled into a CS10.5 or CS16 compatible format. I keep the other directories (support/, html/, etc.) synchronised with subversion.

It's unconventional, but I find working this way more efficient than working with CSIDE and dealing with its limitations. It also permits a single code stream from CS10 to the latest release.

I suspect that internally CSIDE may be using the environment to determine which compatibility level to build to, but I just wanted to check that

I believe that's exactly how it works.

Hany Samuel

CSIDE itself does not contains SDK for building the OLL (till now). It is an interface to bring CS development and debugging to the eclipse platform. The real work and compilation is done at the Content server itself. When you create a project it asks you to choose OTHOME, this is the server that being used from this point on. CSIDE check if the server is running or not and asks you to shut it down. CSIDE start the server itself as single thread, you will see the startup logs in the console same as written in OTHOME/logs/thread0 . when you build your source, CS get your source tree and build the oll accordingly. In the latest CSIDE we force now single server per workspace as old versions allowed you to choose server per each project you build which caused problems for users that are not aware of CS internals. so now to build your source against different versions, create workspace for each version and choose the right OTHOME when creating your project.

Thanks

David Templeton

I need to make a couple of comments here, first using builder and exporting to CSIDE is hack around, there should be no reason to do this. The latest CSIDE now exceed what builder could ever achieve. With the code formatter and visual indicator of issues in the ospace view developers have better tools. The sync with source control like perforce and others was never there in builder. Now if there are actual technical issue then please open support tickets so they can be addressed

We are in the process of changing a number of items around OLL’s and the format. At the 2016 EW, we announced we are researching signing OLL’s, checksum on scripts and features and preventing older version OLL’s from being loaded into a Content Server running in server mode ( can still be imported into CSIDE). The first is due to the need validate source of the software. The loading prevention is due to as we move further away from 10.5 and 16 OLL formats we need to add new features, like those mentioned and for the customer ensuring good software is essential. Before people start complaining, other software does this like .Net frameworks etc. We had 22yrs+ of compatibilityJ time to move along. It should be noted the compile/loading of OLL’s is done by CS not CSIDE.

You wrote:

It's unconventional, but I find working this way more efficient than working with CSIDE and dealing with its limitations. It also permits a single code stream from CS10 to the latest release.

What limitations?? Please list them? Oh the single code stream, yeah and the lowest common code or worse no compiling in native environment to use the IDE to catch compile and code errors. None of us is perfect so the IDE helps. For the record R&D maintains multiple code streams…..

Regards

David

David Templeton

Hugh

Presumably that means a vendor, if needing to produce modules compatible with 10.5, 16.0 and 16.2 and beyond, they would have one Oscript source project and share it between different environments - the same CSIDE plugin lloaded into an environment that is 10.5, another that is 16.0, and so on.

We recently changed this to be one eclipse project to one CS install. Since there were way too many issues trying to share project. But the same CSIDE can be used.

David

Chris Meyer

Hi David,

What limitations?? Please list them?

I've mentioned this in other threads, but here it is again. My main concerns with CSIDE are:

frequent crashes
sluggish performance
single threaded debugging

Oh the single code stream, yeah and the lowest common code or worse no compiling in native environment to use the IDE to catch compile and code errors. None of us is perfect so the IDE helps.

I don't think I'm being clear: I export the ospace to .os files and compile it in CSIDE for CS10.5 and CS16. This provides a native binary and gives me the error handling not provided in Builder.

For the record R&D maintains multiple code streams…..

I can't comment on this, but in general it's more efficient to work with a single stream. When I find a bug or add a new feature I address it once and not multiple times in each stream.

The latest CSIDE now exceed what builder could ever achieve. With the code formatter and visual indicator of issues in the ospace view developers have better tools.

I realise there are pros and cons to my approach, but I work far more efficiently this way. I also have a code formatter in Builder...

David Templeton

Single stream, again without hacking, runtime switches or remaining on lowest common functional code base it is not efficient to maintain. Pain to debug, and patch etc. Lots of experience with it. If it works for your needs, all the power to you. For the record, there will be changes coming that will make single stream nearly impossible, but the most noted if JQuery 3.x. A number of functionality has been removed. Now some will say they wrap up their own jQuery etc, that is not a great solution to present to customers and causes issues with the system. Security concerns, interaction, compatibility with other libraries etc. We have been working to get solutions to not ship their own, namely for security concerns. Use the one shipping in the product.

frequent crashes

Get on latest plugin, many crashes have been addressed and I myself have not had crashes related to code in I can’t recall. Changing IP means a restart but that is not CSIDE. But as always if people are not reporting issues and keeping up to date on the plugin then it is really hard for us to help. PeriodJ

sluggish performance

Get on the latest, there have been significant improvements on performance, especially debugging, F6. Even a full recompile of source for me, which is ALL of the core code is in the area of a couple of minutes and much safer than before. Again, specific jira reports and the team can investigate. The team is doing a great job in making CSIDE more stable, more performant and more featured. I loved builder but no longer wanting it back.

single threaded debugging

I think I have commented on this before, while the idea of builders multiple request during debugging an issue appeared to be a good feature it actually was horrid in general. Since it was not multithreaded in builder either and there were many cases that just screwed up the environment. If it worked in your usage then great, but generally it caused more problems and I don’t want others to think it was a great behavior to somehow expect

I also have a code formatter in Builder...

OkJ

In the end we are a community and we move forward with you, Hugh and all the others helping us. We want feedback but we need detailed issues and then we can make the product better. Builder is not the answer anymore.

Regards

David

Chris Meyer

Hi David: I think our experiences with managing a single code stream have been very different. I haven't had the problems you mentioned. Whatever the case, it works for me and I'll continue on this path as long as I have to.

I look forward to hearing of the upcoming changes that will make managing a single stream more difficult. Perhaps this is for another thread and time, but what is the security concern with using an instance of jQuery separate from the one in Content Server? I've been doing this for years and it works really well.

I'll give the latest CSIDE plugin a try and see if it addresses my concerns. Thanks.

HFCDev

Does the latest version of CSIDE address the issue where when you import an Ospace (even a 10.5 ospace) into your environment, it builds the source tree with every single object dumped into the root package? That was certainly my issue about 6 months ago. If that's fixed now, that would be fantastic. I guess I'll find out in the morning when I try to do an import.

-Hugh

Chris Meyer

Hi Hugh,

Does the latest version of CSIDE address the issue where when you import an Ospace (even a 10.5 ospace) into your environment, it builds the source tree with every single object dumped into the root package? That was certainly my issue about 6 months ago. If that's fixed now, that would be fantastic. I guess I'll find out in the morning when I try to do an import.

It doesn't seem to be resolved with the latest plugin (com.opentext.cside_16.2.2.5.jar). See my reply in this other thread.

However, you raise an interesting question: Does this work with a CS10.5 OSpace? It depends, is probably the best answer. Let me explain how I understand this and please correct me if I'm wrong:

Every object (or "ophan") in a CS10.5+ OSpace has a fully-qualified name (or "FQN"). This is based on the path of the object relative to the OSpace and package it's contained in. You don't see this in the Module Explorer view (one of the more confusing aspects of the new format), but you know it's there since you can reference objects with it. For example:

attrData = LLIAPI::AttrObjects::AttrData.New(prgCtx, id, verNum)

This tells you the AttrData object belongs to the package AttrObjects and is in the module LLIAPI. This is explicity defined in the OSpace.

If you do an OSpace Import of such an OLL then CSIDE should reconstruct the package hierarchy since it's explicitly defined. This is not the case with a CS10 OSpace since there is no concept of packages in the format. In the CS10 case CSIDE must make assumptions to map the CS10 object hierarchy to a package hierarchy. This seems to be failing with the latest plugin.

To get back to your question: CSIDE will import a CS10.5 OSpace according to how the packages are defined within the OSpace. If the OSpace was constructed from source files with everything in the root package then it will continue to be this way. I ran into this problem recently.

How does one fix a CS10.5+ OSpace that has been corrupted like this? I suppose I could generate the .os files and spend hours manually reorganizing the files, but that's tedious and error prone. To get around this I wrote a downgrade tool to convert a CS10.5+ OLL back to CS10, which could then be exported to a clean package hierarchy using the other export tool I've mentioned. It's a roundabout way of doing things, but I see no other way at the moment.

Hany Samuel

Hugh,

This specific issue we are currently working on it tickets OIDE-1164 and OIDE-1048. We just solved big issue that was also occurs specifically with old OLL format working on 10.5 and 16 that cause the hex ID being used instead of Object FQN. this fix will be in our coming release 16.2.3. However this issue you mentioned will not catch this release but expected to be in the following alpha release. If you do not have access to these internal resources please reach out to me through email and I can arrange a hotfix release for you when the issue is resolved.

Just to note here, this issue was not encountered internally here as our developer import the source directly from source control agent. It was mainly reported by our external third party developers (who do use the import from oll functionality). That shows clearly why we encourage you to come forward reporting any issues you find so we can improve our product to suit your needs.

Thanks