Bring back Livelink/Content Server builder

I have had this thing in my mind for a long time now to start a kind of petition to bring back the Livelink/CS builder. I am not sure if there is already any existing topic on this subject. I am working on LL for almost 10 years now and I started with very primitive versions like 9.1 & 9.2. And while doing any oscript development or debugging many people like me got so accustom to builder that in a way it became part of life. So, when suddenly it was discontinued with CS 10.5 and OpenText said eclipse is the way forward many others like me were surprised/disappointed. I can understand the strategic reason behind this decision which is to woo Java developers to LL. However, for lot of people like me who have used builder for years it was a bit difficult to adapt to eclipse. The ease of use of builder can only be understood by people who have worked with LL long enough. I would at least expect OpenText to provide it as an option alongside Eclipse.

Find more posts tagged with

Comments

Kashellkar_Vishal

I would second that. Working with builder on Eclipse can be a big pain for people who are used to Builder and had never used Eclipse before.

I understand the need of Eclipse but it'd be good if OT can provide builder as option.

Juliano_Ghisi

Dear Karan and Vishal

It is sad to hear that you are facing these problems with Oclipse and thanks for reaching the Content Server Development community to expose your concerns.

Unfortunately, make Builder available again is not an option and the reason for moving away from it was not only strategic, but also technical. The Eclipse platform allowed us to extend and introduce new features not only in the plugin side, but also in the Core of Content Server.

We are aware of existing challenges and we have been working hard to make the necessary improvements related to stability and performance aspects.

I would like to take the opportunity and mention that we are about to release the Content Server SDK 16.2 (CSIDE) where you will be able to see the respective improvements. The CSIDE has backward compatibility with previous version (10.5+, 16.0+).

We are commited to our dev community to provide the best experience when using our product, making sure they are productive on their daily tasks.

Please, let us know if there is anything specifically that you would like us to help and we would be more than happy to assist you.

Best Regards

Juliano

Chris Meyer

I also find CSIDE difficult to use in comparison to Builder. Here are some of my reasons:

CSIDE is much slower than Builder. On my development environment I can start Builder and start issuing requests after 4s. With CSIDE it's 24s (6x longer). Building (after doing a clean) is also slow.
With Builder you can have multiple debug windows open at the same time. With CSIDE only one is possible (or is there a way I'm unaware of?).
CSIDE crashes more frequently (although it's gotten better with recent releases). CSIDE sometimes gets stuck in a state where I have to manually kill the eclipse or java processes from the Windows Task Manager.
I find having two source code formats and toggling between them confusing. The Builder UI shows more information about an object (inherited properties, overrides, etc.) in a more visual and intuitive way.

I work around these problems by continuing to work in Builder and using tools to export my CS10 ospaces directly to CS10.5/16 source. This way I can continue to work in Builder and test with CS10.5/16 without having to restart Eclipse each time. It's a bit of a kludge, but has worked well for me so far.

I'd be happy to see Builder return, but unfortunately don't believe that'll happen.

Juliano_Ghisi

Hi Chris,

Thanks for providing your feedback.

Please, just keep in mind that CSIDE is not the only reason for a slow CS startup. Differently from old versions, Content Server has introduced many new features and default modules which are required to load at the service startup.

Just for reference, Content Server 16 release has introduced 15+ new default modules!

Also, I really appreciate your comments where you mentioned that crashes are less often on recent releases and, as I mentioned in my previous reply, we are commited to our dev community and we will continue to focus on stability and performance on upcoming releases.

Best Regards

Juliano

Tammy_Jakubowski

For multi-purpose testing, dev, and support environments, it was very convenient to have a 1 to 1 relationship with Builder to CS instance. WIth eclipse you can only troubleshoot one instance at at time per environment.

I second what everyone else already said. The more you can make the eclipse experience like Builder, the better. It's kind of water under the bridge though, since we've long since moved on and learned as a company.

Tammy Jakubowski (20 years working with Livelink and CS, this month)

Alex_Kowalenko

After all these years of being silent let me jump in. Like Tammy, I started developing with Livelink at version 7, then 8, then 9, etc. Let me say this. Just because I am older than most of you, it does not mean that I am not able to embrace new frameworks, ideas, techniques. For a while, whenever I ever brought up to the topic of keeping Builder, there was a suble hint that people like me were unwilling or unable to move forward. I ignored it - until now.

My esteemed colleagues in this forum and elsewhere have revealed good reasons why Builder was better. I agree. The story was that there were growiing pains in the new technology and it would get better over time. Time has passed. As of today there does not appear to have been appreciable improvement. Thank you Karan for starting this thread. Whether Builder itself is ressurected, or the new platform gets the characteristics that made Builder so useful is tactic. Let's see what can be done.

-alex-

Alister Grigg

Quoted Tammy Jakubowski on 02/10/2017 07:28 PM:

Tammy Jakubowski (20 years working with Livelink and CS, this month)

Congratulations Tammy!

Abhinav_Jain

Its a huge pain to use Eclipse when we create a new module or perform a enahncement with exisiting modules. Olivir ,

i have used Content Server SDK 16.2 (CSIDE) as well but there is no new improvements in it. The pain from technical prospective is quite not as lot of people still prefer builder as it is quite user friendly and more on productive side

Hans Stoop

I don’t have that negative feeling that other OScripters have with Eclipse.

I’m also programming less than I used to. And have less time to look at new features like code templates.

What is missing is a list of tricks of how to use Eclipse/CSIDE most efficiently for developing in OScript.

Hans

From: eLink Entry: Content Server Development Forum [mailto:development@elinkkc.opentext.com]
Sent: Freitag, 10. Februar 2017 16:21
To: eLink Recipient
Subject: Bring back Livelink/Content Server builder 2

Bring back Livelink/Content Server builder 2

Posted by Ghisi, Juliano On 02/10/2017 10:13 AM

Dear Karan and Vishal

It is sad to hear that you are facing these problems with Oclipse and thanks for reaching the Content Server Development community to expose your concerns.

We are aware of existing challenges and we have been working hard to make the necessary improvements related to stability and performance aspects.

We are commited to our dev community to provide the best experience when using our product, making sure they are productive on their daily tasks.

Please, let us know if there is anything specifically that you would like us to help and we would be more than happy to assist you.

Best Regards

Juliano

[To post a comment, use the normal reply function]
Topic:	Bring back Livelink/Content Server builder
Forum:	Content Server Development Forum
Content Server:	Knowledge Center CS16

David Templeton

Much more readable format :-) and forgot some minor additions

-------------------------------------------------------------------

Chris, Tammy, Karan et al

All of you bring up some interesting points here and I would like to address each point individually

CSIDE is much slower than Builder. On my development environment I can start Builder and start issuing requests after 4s. With CSIDE it's 24s (6x longer). Building (after doing a clean) is also slow.

First off, sure it could be! There are number of reasons for this:

As Juliano pointed out, the sheer number of oSpaces has increase significantly in the past couple of major versions as more functionality goes from al-a-carte to standard
At the end of the OLL load in 16 and above there is a thread initialization that can take extra seconds depending on the number of items registered. It was designed to allow this thread warming to eliminate the impact on the end user of the first request that we had been seeing in the field.
When CS loads an older OLL it is a different format and on load needs to convert to the new internal structures that 10.5 and 16 have. This is less for natively version compiled OLL.
Automatic indexing of code for Eclipse to allow code jumping with F3
Alignment with source code on disk

In the end, the goal is to make the users experience better and if the developer has to wait an extra 4s then, okay I can live with that. Now before someone shoots back “but”, I will push back on all of the freakin patches that we see being installed at customer sites. Not the patches for hot-fixing issues BUT the duck-punching of code to override functionality. In reality, customers see longer, even up to multiple minute load times before the system accepts requests so again the developer waiting an extra 4s to load is not problematic.

As for the clean build taking longer, again “okay”. And the reason is the new compiler is a least a magnitude better in catching errors that normally would have been traces and syntax issue at runtime. There have been so many code execution errors that have been found with the new compiler. Some other points to consider:

In the builder world, if a compile went crazy it would write a 2gb+ OLL and basically jumped off the cliff! Then there is that “oh ****” moment when you know realize the install is completely and utterly screwed for the next 2-3 hrs ( to days in some cases ). Now, old guys like you and me can fix this but it is a scary scenario for those new to the environment. We want new developers and therefore improve the experience
The compiled OLL is prevented from replacing the running one until it is determined that it is clean

If these take a little longer in order to prevent corrupted development environments then I support this. By your own admission, this is not hours to compile but extra seconds. In the end we are working towards a more stable friendlier development environment. To reduce the cost of support when the code gets into the field because that is where it hurts us when code fails.

With Builder you can have multiple debug windows open at the same time. With CSIDE only one is possible (or is there a way I'm unaware of?).

Eclipse when running is single threaded app. Having multiple debug is debatable at best. The multiple debug windows was a side behavior that rarely ended well. Here’s why:

Builder was a single threaded app, like eclipse
When the debug window popped up it interrupted the thread, when the second debug popped up, if it came from another request then the first’s requests information was no longer deterministic
Multiple debug windows meant that different code was being executed variables were based on the last script that ran
If there are reasons for the multiple debug windows coming up then there was a good chance of a debug ‘storm’. And builder went nuts too….and had to be killed
Prior to eclipse taking over the development environment we were looking at locking out requests when debugging, like it is in eclipse now

CSIDE crashes more frequently (although it's gotten better with recent releases). CSIDE sometimes gets stuck in a state where I have to manually kill the eclipse or java processes from the Windows Task Manager.

There is no argument that there have been more crashes and hanging than builder ( unless builder corrupted the OLLs on compile and then all hope was lost ). We have assembled an amazingly strong development environment team to further develop and enhance the plugin. Having the regular updates and for all developers to make sure they have the latest plugin is essential. Also, STOP using CS 10 as the development platform since we are NOT testing continually the loading and developing like that. It is expected that code is exported to source and the develop work from that. The source compiler is soooo much better.

I find having two source code formats and toggling between them confusing. The Builder UI shows more information about an object (inherited properties, overrides, etc.) in a more visual and intuitive way.

Chris, I am going to be really blunt :-) STOP THAT!!! If you are running from native source only then the two view thing becomes less of an issue. With the exception of making patches or debugging features I rarely use the module tab. I work from the oScript explorer

From other postings

Tammy, sure there are rare occasions of needing more than one environment, or we think we need more than one simultaneous environment. I was one of those that used to have multiple builder’s open, and we can definitely add to the backlog. But I would like an honest thought here is it that much better? As the code and the platform moves forward the same solution should not be expected to be the same on all platforms. Otherwise the solution is developed for the lowest common platform L

From Karan’s post

I hear you, I was introduced to builder in 1996 with 8.0, being an old school guy it was my life’s blood J

So, when suddenly it was discontinued with CS 10.5 and OpenText said eclipse is the way forward many others like me were surprised/disappointed. I can understand the strategic reason behind this decision which is to woo Java developers to LL

Actually, the “wooing” of the java developers was the least of the drivers in the end. Since everyone like transparency, a list of items to note

Builder was a 32bit app
Builder was latin-1
Builder was based on the MAC platform and included a number of behaviors from that environment. The MAC spinner anyone J
Builder had no development information on it and would need to reengineered from scratch
Builder used non-standard development practices ( but a lot of practices were developed after Builder J )
Builder didn’t provide support for source code systems, yes there were attempts with OSX dump and internally used OSX utils that broke things to the object level. But it was a hack at best
Builder did not know about the actual installation for secondary files like HTML and support
Builder was a focused environment for oScript only, debugging java was painful or you needed to hook up, hold on…. Eclipse J. With eclipse there is the opportunity to traverse the different code like java so the developer can walk for oScript to java and back
Builder required specialized developers to reverse engineer and develop stuff. With eclipse we can onboard java developers to help support the development environment
Yes, the eclipse environment is known to many more developers.
the eclipse code formatter is a perfect example, builder would have required the framework and the formatter, Eclipse, just the formatter ( it is getting more polished as well J ) But it just one tool that helps the developer that would have been cost prohibitive in Builder

The eclipse environment provides a platform that builder couldn’t and in the end we decided that cost and effort was best spent in developing in this direction. Do I long for the days of Builder, sure but that thought goes away knowing the path forward is not on a stagnant development platform.

However, for lot of people like me who have used builder for years it was a bit difficult to adapt to eclipse.

Internally, it was a hard transition as well, there is no whitewashing that. You have to immerse yourself in the development in a way other languages have, C, java etc. But once done it does get easier like all changes in development etc.

The ease of use of builder can only be understood by people who have worked with LL long enough. I would at least expect OpenText to provide it as an option alongside Eclipse.

There is the problem, us old guys are dwindling numbers…. I want to see CS continue, to expand and be adopted by more developers. As you can surmise by this long winded post, Builder is not coming back, it is not cost effective nor practical to do so.

A couple of action items for anyone reading this:

Stay up to date with the plugin’s
Convert old OLL’s to source and work with the source not the live OLL
Submit issues for investigation
Submit ideas for possible development opportunities ( not bringing back builder J )
Keep up conversations in the forum

Regards

David Templeton

Content Suite Enterprise Architect

OpenText Corporation

Phone:	(519) 888 7111 x2301
Mobile:	(519) 581 7600
LinkedIn:	davidt50
Twitter:	@davidt_50
Website:	www.opentext.com

This email message is confidential, may be privileged, and is intended for the exclusive use of the addressee. Any other person is strictly prohibited from disclosing or reproducing it. If the addressee cannot be reached or is unknown to you, please inform the sender by return email and delete this email message and all copies immediately.

Chris Meyer

Hi David,

In the end, the goal is to make the users experience better and if the developer has to wait an extra 4s then, okay I can live with that.

Just to be clear: It's 24s vs 4s (20s longer, or 6x slower). This is without any patches or legacy ospaces.

I don't think this has much to do with the extra modules or cache warming since they seem to load fast according to what's shown in the console. But over half the time is spent initialising Eclipse before anything shows in the console. Whatever the reason, those 20s add up when frequent restarts are necessary to recover from a crash or to reinitialise the subsystems.

By your own admission, this is not hours to compile but extra seconds.

I didn't provide numbers here. When I do a full build (i.e., via a Clean) it takes about 2 minutes (9 modules / 12 ospaces). I realise this is relative and a full build isn't done often, but there are only so many coffees I can have per day.

Chris, I am going to be really blunt :-) STOP THAT!!! If you are running from native source only then the two view thing becomes less of an issue.

My approach gives me the best of both worlds. I continue to develop with Builder and run a script to export the .os files directly to the Eclipse source directory (bypassing having to restart or run Import OSpace in Eclipse). This allows me to use Builder as my development environment and Eclipse as my compile, test, and debug environment. It works well and has prevented me from having to fork my code (since I still need to support CS10).

I continue to use Builder for other reasons. I do a lot of code generation, which is easy to do with Builder (i.e., sort of like running 0Setup() but with more involved). I haven't figured out how to do the same with the new source format.

The other reason is simply the interface. As I wrote earlier, the Builder UI provides much more context about the inheritance hierarchy, what's being overridden, what other methods are available, etc. Much of this context is lost in the OScript Explorer view (or maybe I need to get used to not seeing it?). How do you develop in this view without having to constantly toggle to the Module Explorer view to understand the context of what's being worked on?

Karan_Kadam

@Juliano
I think there are several things that be pointed out and I think you see a lot been mentioned already in this post. My argument is simple doesn’t a Java developer get an option of Netbeans? Or a .Net developer has an option of freeware like SharpDevelop. So, why can’t Oscripters get an option of builder? Why not invest in making in Builder better rather than coming up with a new IDE altogether?

@David
In the same post you have said 2 contrasting things.

1) “Actually, the “wooing” of the java developers was the least of the drivers in the end”
2) “I want to see CS continue, to expand and be adopted by more developers”

From what I see, In an attempt to please one part of community somewhere OpenText has disappointed longstanding Oscript developers. I think OT doesn’t even need to go outside to see the pain since you stated that it was hard transition internally itself.

I think @Chris mentioned a good point of using Builder and Eclipse together to make life easy. So what’s the point of releasing something which is not as perfect as the older IDE? Why not offer builder as an option alongside Eclipse atleast until Eclipse reaches to the point that it is accepted by everyone?

Best Regards,
Karan Kadam

Juliano_Ghisi

Hello Karan,

Thanks again for your reply and feedback.

The limitation on the technology and other points mentioned by David T. summarize the reason we had to jump to another platform.

In regards to our internal developers, aside from time to learn the new product/platform, I have to say that we have been very successful. I just want to highlight that we have not only released a new line of product versions with Release 16, but an entire Suite. We are about to repeat it again with Release 16.2.

At the end, I really would like to see more tickets and details about specific issues, specially because you could be facing a problem that we are not exposed in our internal environment. This would really help us to improve our product!

Best Regards

Juliano

David Templeton

Kadam

In the same post you have said 2 contrasting things.

1) “Actually, the “wooing” of the java developers was the least of the drivers in the end”
2) “I want to see CS continue, to expand and be adopted by more developers”

Actually I was not, the goal was not to woo java developers specifically. But to aid on boarding of developer in general

Learning anything new is a transition and all have challenges. It is easier for a newer developer to start working in the world of eclipse than the old one updating skills. A far as the pain is concerned again it passes with more usage

I think @Chris mentioned a good point of using Builder and Eclipse together to make life easy. So what’s the point of releasing something which is not as perfect as the older IDE? Why not offer builder as an option alongside Eclipse at least until Eclipse reaches to the point that it is accepted by everyone?

Here is the question then what features would like to forfeit in eclipse development? Eclipse has been out for a number of years now, when will the final transition occur? To bring back “Builder” would be a complete rewrite from scratch. I am not sure I can put it more nicely, Builder is not coming back, period. :-)

David

Greg Griffiths

Given the responses in this thread and elsewhere, I think the ship has sailed on bringing Builder back, what we should collectively do now is the following :

1. Developers provide a list of feature requests to OpenText to enhance the CS IDE solution to enhance it, this thread provides several examples.

2. OpenText to update OTDN to include "This is how you do X in CSIDE" type articles to support the transition from Builder.

3. OpenText to update OTDN with more content and examples, lots of OScript could do with updated commentsin the code too.

Both bullets 2 & 3 could be done in conjunction with the Community as there are many experienced people who would be happy to share and help here - as many already do and too many to name.

Additionally, the wider development footprint that is now present, e.g. WebReports/CI, WebServices, REST APIs etc mean that there may be different ways to achieve the same end result in Content Server that would previously only be done in one way, via Builder, so some posts on that too would be good.

If we work together and help OpenText enhance the CS IDE, which will help each other move forward.

HFCDev

Quoted Greg Griffiths on 02/15/2017 01:58 PM:

Given the responses in this thread and elsewhere, I think the ship has sailed on bringing Builder back, what we should collectively do now is the following :

1. Developers provide a list of feature requests to OpenText to enhance the CS IDE solution to enhance it, this thread provides several examples.

OK, I'll bite. One massive feature request would be that when you orphan an object, you have a quick way to pop up the parent's original function/feature. For example, you orphan an object X with feature Execute() and you know you just want to add a bit of code to what the original method already does, or you just want to see the original code for reference, wouldn't it be nice to be able to start writing the new method with the old method already fetched. Builder does that already TODAY.

-Hugh

David Templeton

You mean Menu->Source->Override Features?

David

HFCDev

I'll try that out next time I'm in a CS10.5+ environment (current client still on 10.0).

-Hugh

Breemer_Rick

Quoted Hans Stoop on 04/18/2017 10:03 AM:

What is missing is a list of tricks of how to use Eclipse/CSIDE most efficiently for developing in OScript.

Hans

Couldn't agree more.

We basically had to find out by trial and error that using the Module Explorer together with the OScript Explorer just doesn't work. I switched back to Builder initially because of the resulting corruptions, but eventually found out the idea is to just use the OScript Explorer.

There are a lot of things to like about Eclipse, but I mostly struggle with navigation. Page up/down takes you out of the function you're working on since it navigates the entire .OS file, so you easily get lost. Same for searching. CTRL+F also searches through all the functions in the .OS file and not just the one function you are working on.

Other than that, I'm mostly missing some of the features/scripts introduced by the customizationsRT module, like updating the module version number and creating a patch.

Oh, and creating xlates in the HTML files doesn't seem to be supported? So now I'm copying strings to a random OScript script and creating the XLATES there.

Anyways, happy to use Eclipse going forward, but a nice champion toolkit document with lots of "how to's" on using Eclipse would be very welcome

John Simon

"Oh, and creating xlates in the HTML files doesn't seem to be supported?" - In Builder you could open a script, Ctrl-L to find strings, Ctrl-T to replace strings. In oclipse Ctrl-L is mapped to a different function (goto line) but Ctrl-T still works.

Cheers...

Breemer_Rick

Does CTRL+T work for your HTML files as well? Only seems to work in scripts here. I'm on Eclipse Mars 2 with plugin com.opentext.cside_16.2.0.1421.jar...

Breemer_Rick

Oh, and does anyone know how to get rid of the warning "Using HTML escaping inside of Javascript". I get one of those each time I use OScript backticks in <script> sections, e,g:

<script type="text/javascript>var dataID = `request.objID`;</script>

Stephan_Baumann

Uncheck "Check for WebLingo escaping lint" in the OScript section of Eclipse preferences and rebuild project.

Rolf Poser

Hello Everyone

I think going with Eclipse was the right move and also hope that it will improve over time.

Something I think that can now be added (would probably have been more difficult in the Builder world) would be to create a headless compiler / builder / packager. This should be possible using Eclipse (there are other headless builders) and would be very useful in CI pipelines.

I think in team development scenarios this could be very powerful:, e.g. using something like Jenkins to watch for new check-ins in the source code repo, fetch the changes, build the OLL, package the module, deploy to a test intance, perform the module update and then run some automated tests?

John Simon

Rick,

Ctrl-T did NOT work for me in weblingo files either. I am using the same jar but on the Neon.3 release.

Cheers...

Stephan_Baumann

Check if your weblingo file is opened with the WebLingo editor. Some Eclipse editions register editors for HTML files, therefore it is possible that your are using the wrong editor. Only the WebLingo editor knows about Ctrl-t.

To check: right click on the weblingo file in Oscript Explorer and select Open With -> WebLingo editor.

Quoted John Simon on 04/19/2017 02:21 PM:

Rick,

Ctrl-T did NOT work for me in weblingo files either. I am using the same jar but on the Neon.3 release.

Cheers...

Breemer_Rick

Thanks Stephan, both your suggestions worked!

Hans Stoop

Rick wrote:

Other than that, I'm mostly missing some of the features/scripts introduced by the customizationsRT module, like updating the module version number and creating a patch.

I made them for myself again, but the problem is that I have figured out yet how to ask for any input. You can mainly keep the old code as long as you call it from the module explorer.

I also haven’t figured out yet how to overwrite the ht eini file in the source directory.from code I run in th emodul explorer.

Hans

From: eLink Entry: Content Server Development Forum [mailto:development@elinkkc.opentext.com]
Sent: Dienstag, 18. April 2017 10:06
To: eLink Recipient
Subject: RE Bring back Livelink/Content Server builder 2 2

RE Bring back Livelink/Content Server builder 2 2

Posted by Breemer, Rick On 04/18/2017 04:03 AM

Quoted Hans Stoop on 04/18/2017 10:03 AM:

What is missing is a list of tricks of how to use Eclipse/CSIDE most efficiently for developing in OScript.

Hans

Quoted Hans Stoop on 04/18/2017 10:03 AM:

What is missing is a list of tricks of how to use Eclipse/CSIDE most efficiently for developing in OScript.

/QUOTE]

Couldn't agree more.

Other than that, I'm mostly missing some of the features/scripts introduced by the customizationsRT module, like updating the module version number and creating a patch.

Oh, and creating xlates in the HTML files doesn't seem to be supported? So now I'm copying strings to a random OScript script and creating the XLATES there.

Anyways, happy to use Eclipse going forward, but a nice champion toolkit document with lots of "how to's" on using Eclipse would be very welcome

[To post a comment, use the normal reply function]
Topic:	Bring back Livelink/Content Server builder
Forum:	Content Server Development Forum
Content Server:	Knowledge Center CS16

Apparao Saripilli

i do agree with you, eclipse is not as good as build. performace is much better in builder.

David Templeton

ok I will bite, the performance of what in builder was better?