Facing problems in Clearcase 8 plugin for Eclipse Luna for config spec update - eclipse-plugin

I have been using Eclipse Helios/Luna with plugin installation of clearcase plugin 8.0.1.x version and have imported the base code.
Recently, when trying to change the config-spec to update the build files, the process is running for hours continuously even without a single file.
Previously, we had Clearcase version as 7.0.x version and the corresponding plugin installed on Eclipse Helios without facing any issues.
But, have been facing issues during update of files after the upgrade of clearcase server to 8.0.x and with the corresponding client plugin in eclipse.
Also, tried manual update from repository for the whole folder. Still no luck.
But, if I know manually update the file one by one individually, it is going fine.
As the number of files in the project is more, it would not be efficient for us.
Can someone provide some alternatives to resolve this problem?
As a workaround, we have been creating new views everytime there is an update to the config-spec.

One workaround would be to switch to dynamic views, supported in the latest 8.x version of ClearTeam/ClearCase. No reload needed with those kind of views.
The other would be to test with a minimal config spec, and load rules making sure you are loading only as few files as possible (jsut to check that those files do update when you change the config spec).
It can also depends on the exact version of your ClearCase installation.
There are some patches for hanging issue (like "PM48668 Problem: The IBM Rational ClearTeam Explorer may hang intermittently when many views are started.")

Related

How to disable IntelliJ IDEA pulling repository automatically?

I'm working on multiple projects at the same time which are inter dependent. Sometimes, when one developer pushes updates to one project (for example Liquibase changes), they are picked up by my IntelliJ which immediately complains about missing columns when I restart the project. I did not explicitly issue any fetch/pull or update request against the remote repository. This is kind of annoying because I am then forced to pull all the new changes locally.
I remember my old IntelliJ version behaving normally (2019) so this is a new "feature" I guess? How can I disable it?
Could you please share screenshots of an issue? IDE doesn't run pull/fetch or upgrade automatically if you are using Git, but there is a chance that you may have Git Toolbox plugin installed and it has a feature for Auto-fetch and you need to disable it in settings

Update OSGi Bundle in Apache Geronimo

I am an absolute novice with Apache Geronimo, so my forgive my obvious ignorance.
Apache Geronimo ships with older versions of the HTTPCore and HTTPClient libraries. The current version of OpenID requires at least v4.1 of both HTTPCore and HTTPClient. I have found the OSGi Bundle page in the Geronimo Console, and see how to use this to install a new bundle. I also see that existing bundles have an "update" option, although this does not seem to update either of these bundles to the latest version.
Is there an easy magical way to just update these? If I need to download bundles for the appropriate version, where, exactly, would I go to download them? I've located and downloaded JARs for these two libraries, and have included them in my project and been able to package it with Maven, but this doesn't (apparently) deploy the updated versions into Geronimo (i.e., it loads the old versions and I get runtime errors).
If I had bundles for the later version, the UI is pretty obvious as to how to install them - will that replace the existing version, or will I then have both versions installed? Will this present a runtime issue? If so, how do I remove the exiting bundle (I see no way via the UI to accomplish this).
Any assistance is greatly appreciated.
David Mullin

Worklight 5.0.6 wipes out native customizations in shell

I upgraded my environment to v5.0.6. Problem is that everytime i start Eclipse it does this:
[2013-04-19 18:38:41] FWLST1017I: [AppShell] upgraded to the latest
platform version.
When this upgrade takes place, it reverts my templates and adds class files to the iphone\native folder and removes the plugins I configured in the shell:
Removes all my custom plugins from components/AppShell/iphone/native/Classes
Resets project.pbxproj.wltemplate.wluser to stock removing includes for my classes
Resets config.xml.wluser removing all mappings to my plugins
It also always shows at the end of the upgrade process:
Failed to upgrade Worklight project 'AppMobile' to the latest platform
version. [null]
Is that why it keeps running the upgrade and reverting my changes?
According to your question, you have some .wluser files, which means that something is wrong with your project.
Can you please let me know whether the problem still exists and whether you still have those files in you project?

Distributing Eclipse plugin with dependencies

I recently wrote an Eclipse plugin, and I'm trying to get some coworkers to install it for testing.
As far as I can tell, dropping the .jar into the dropins folder in Eclipse is supposed to install it, but it seems to not be working on any installation of Eclipse but the one I developed on. This seems to be a problem with the dependencies not being installed.
I thought that the dropins folder was supposed to automatically calculate and install dependencies, but perhaps I'm wrong. If so, how can I distribute it without having everybody install each dependency separately?
I'd recommend against using the dropins folder. It is unreliable as you have seen. Instead, I'd recommend that you export your plugin as an update site.
So:
Create a feature for your plugin. This is a lot simpler than it sounds. See Lars Vogel's tutorial: http://www.vogella.de/articles/EclipseFeatureProject/article.html
File -> Export... -> Deployable Features.
In the options, section, select "Package as individual jar files..." (see screenshot)
Tweak other things as required
Finish
Now, you have an update site that you can zip up, or put on a web server somewhere. Your colleagues can add that update site just like any other. To install, make sure that they also have all of the dependencies available from other update sites and that they have "Contact all update sites..." checked.
The nice thing about this is that if you place your plugins on a web server somewhere, and you replace it with a new versions, people will be able to update transparently.

How do you distribute the IDE and it's configuration within your Team?

I'm wondering how Software Development Team distribute their Standard IDE(s)?
E.g. developing with Eclipse, custom Code formatter, svn Resository, Copyright Header..
At the moment my Team has a standard zip File which is then distributed withhin the developers.
Problem:
If one file, a Plugin or the IDE itself changes, e.g. new Coding Guidlines, Upgrade Eclipse 3.5.1 the whole distribution has to be done again. Every developer needs to unzip the bundel again. Imagine your working with different Workspaces (Jetty, different Tomcamt Versions, WTP) due to Project History That doesn't scale
I know that there are some related Articels
A new version of Eclipse just came out. Is there anything I can do to avoid having to manually hunt down my plugins again?
Manage Your Eclipse Install With A Local Git Repository
And some comercial Programs.
Eclipse also has a new Update-Installer Approach
But I don't see the Killer App. How do your team solve this? Is there a best practice?
I guess best would be a Program letting you choose your current Project and then downloads the configured IDE from the Server and leting you know if Project Config Files are Updated
For eclipse look at Buckminster it targets exactly your target I suppose, didn't use it personally through.
At my previous company they wrote a custom update agent that pulled from a centrally configured server which was updated by the team leaders. It worked well, until people wanted to install their own plugins.
Basically, a developer wanted a plugin, fought in futility to get it included in the default (managed) repo, installed it himself, then updates broke on his machine when the team lead had a sudden stroke of common sense and included it.
They never did come up with a 'good' way to manage it. But, at least they didn't put us all on terminal servers with thin clients.