nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

How to do a "dif" in eclipse?

Tammy_Jakubowski

I did a search on this topic and got this result.

08/07/2013

0 KB

RE RE How can we "dif" ospaces with the previous ospace version?

RE How can we "dif" ospaces with the previous ospace version? How can we "dif" ospaces with the previous ospace version? Jeff Lang said more specifically: Can you ask OT how we can get a dump of the ospace so we can diff the changes with the last version of CS10? Topic: How can we "dif" ospaces with the previous ospace version? RE RE How can we "dif" ospaces with the previous ospace version?

Add Favorite

Created Date: 08/07/2013

But the result gves me a SDNR error from the Open Text Knowledge Center. Does anyone one know the answer?

Find more posts tagged with

Comments

Darcy_Casselman

There's no function to diff OLLs in CSIDE.

You can use the source code import functionality to get a dump of the contents of the OLL. This won't tell you object IDs. Note that if you import your source, CSIDE will attempt to build from that source and replace the OLL, possibly invalidating whatever you're trying to do.* Also, if you import, build from source, change the OLL and import again, there will be whitespace differences between the source code.

There's also an OSX Export function, intended for backporting code to the old Builder osx format for CS10 and earlier. You could use that to compare OLLs. That *will* contain object IDs. The function is only available in the OScript Explorer, so you'll need to import source (noting above the caveat about CSIDE compiling from that source). Alternatively, creating empty module/OSPACE folders might do the trick.

* What are you trying to do, exactly?

Darcy.

Tammy_Jakubowski

Hi Darcy,

There are two reasons (along with some opinions)

<![if !supportLists]>1. <![endif]>Basically we're trying to figure out what Open Text changed in specific ospaces from update to update. We need to react to whatever changes affect the code that we override or add to. It's one thing to read the release notes (which are never going to detail all the changes) and it's another to know that the XML import/Export code was changed in CS 10.5 Sp1 so that a manual import of a workflow map would fail because no versions would be imported. That's a perfect example of why we need to know specifically what changed and is not documented. Because Open Text has adopted the agile method of programming, changes are quick; and then reversions back to previous code are often just as quick.

<![if !supportLists]>2. <![endif]>Sometimes patches are delivered with new ospaces. The "versions" of modules such as eSign and Forms, and Records Management are the same, but a patch that applied a new ospace makes them quite different. The only way to tell after the fact (in some cases it might be a day or in others it might be 2-3 months) when we discover a problem is to do a dif on the ospaces. Since these are ospace changes, it's much more involved to back out any change, and I think you'd have to resort to un-installing the module altogether, along with its patches, and start over. It's much easier for us and for customers if Open Text did not deliver ospaces In patches, but instead made new versions of modules.

Tammy

Kyle_Swidrovich

Tammy,

In addition to the release notes, we provide a readme outlining all features that were added, updated or deleted for the update.
Have you reviewed the readmes to see if they meet your needs?

Kyle

Kyle_Swidrovich

With regards to delivering Ospaces in patches...

Ospaces are typically provided in a patch when the code needing to be patched only runs on startup, before the patch loader runs.
We have found that delivering a new version of a module is much higher impact for organizations as they have to consider it to be an "upgrade" scenario as opposed to a "patch" scenario.

Integrations should only be performed through public interfaces to minimize the impact of a code change.
If you are unable to find such an interface, please contact support and express your desire for a hook / mechanism for you to integrate through.

Cheers,
Kyle

Tammy_Jakubowski

Yes, I read the release notes and the read-me files and everything that Open Text provides. There are always a few surprises, regardless, because no one can predict the unintended consequences of changing something.

Jeff Lang

I understand shipping an ospace as a patch, but the real issue is that it can become hard to tell what version of the ospace the customer has installed. In most cases, there is no easy way to tell that the ospace has been updated with a specific patch, so we're never sure what code is being run until we open the ospaces with either builder or eclipse.

The other patching issue has to do with including schema updates in patches. When this happens, how do you back the patch out if it causes unintended side effects. All patches should be able to be removed if they cause more issues that they fix.

Af for only using public interfaces, that's kind of a joke. Anyone that writes add-on modules for CS knows that the public interface system in CS is woefully lacking. I've been waiting 7 years for the hooks I requested into the workflow system to make it more extensible. I even sent the source code for the hooks along with 30-50 bug fixes. All the bug fixes were put in, but not a single hook, so using public interfaces is not a viable option when creating module that extend features of CS.

Kyle_Swidrovich

Jeff,

Due to IP concerns amongst others (e.g., performance, design, internal API planning, etc.), we are unable to simply add hooks based on source code you send us.

We will of course appreciate any input as to what problems you have and we can approach those problems appropriately.

If you have requested that we extend interfaces for your use through standard means, I would imagine that you would have been provided with reference numbers for tracking purposes.
If you can provide me with those numbers, I can follow up with the workflow product manager.

Regards,
Kyle

Tammy_Jakubowski

Here's an example of an issue that caused a database lockup that we didn;'t know the customer had a patch that had a schema change and an ospace change: https://support.opentext.com/portal/site/css?ticketId=2024454

Jeff Lang

I suppose I could look up all the correspondences with the developers, product managers and development managers that I exchanged emails with about these issues, but that would mean loading old email postboxes. I gave up requesting after 5 years. I'm a patient man, but I'm not Job.

It is funny though that all the bug fixes I sent the code for were integrated into the first version of CS 10, but not a single hook. Maybe it's only selective integrations that aren't allowed.

Tammy_Jakubowski

Kyle, I do not have the ticket numbers, but it would have been exchange with David Templeton once it was submitted to Support more than 4 years ago, but probably about 6-7 years ago. We were also told then that none of the hooks could be put in then for similar reasons that you mentioned. I did a search on Open Text's ticket tracking system, but I can't find them, but I know they were submitted to Open Text Support.

Kyle_Swidrovich

Thanks Tammy.

The product and product direction was quite different 5-7 years ago, and there is a lot more emphasis on the developer in recent years (as one can see with CSIDE, Oscript Language enhancements and REST API efforts).

If you or Jeff are aware of outstanding hook requirements that would facilitate development for GlobalCents, please raise them again through support and current product management would be happy to take them into consideration.

Best regards,
Kyle

Chris Meyer

I'm following this thread with interest. A big challenge is ensuring modules continue to work with upgraded and patched versions of Content Server. I've gotten better at this over the years by creating tools to minimise the intrusiveness of my code and overrides. I blogged about it here if you're interested.

Integrations should only be performed through public interfaces to minimize the impact of a code change.

I agree with this, but what defines a public interface? Many modules I've seen or worked on over the years somehow changes core behaviour rather than adds to it. You can rarely do this without some type of override of core code. We could make a feature request to insert a callback or hook, but there is little chance that will ever get added in the time frame demanded by the end user. What options are left?

Tammy_Jakubowski

Nice blog, Chris. I see the usual long-time Livelink/CS suspects are reading and replying. I'll ask my developers to check it out.

I am not sure how this devolved into how to make CS do what you want and follow the rules that Open Text suggests, but it has. Sometimes overriding is the only way to make things work they way they must in order to meet your/the customer's desired outcome. Some customers need things that Open Text can't provide or won't provide in a timely, cost-efficient given customer requirements. If that was not true, there would be no reason for technology partners or consultants to exist. It's just reality, and not some inherant issue with Open Text. It is the same with all software vendors. This is not an adversarial position. This is a great way to please customers. If Open Text can't provide ALL the solutions, some others can, and in the long term, the customer is happy. Isn't that what we all want...satisfied, long term customers?

I asked for a way to do something so that our job was a little easier and Darcy gave some great suggestions. Thanks again Darcy. I think it's a fair question to ask for a feature that existed in Builder but doesn't exist in Eclipse. I never expected that Open Text would ever change anything; I only brought it up because Darcy asked WHY we needed a tool for "dif".