Does the SourceForge Clear Case plugin work with Snapshot views? - clearcase

I'm using Eclipse 3.6 (Helios) with the latest Clear Case plugin from Source Forge v2.2.14.201202241422. Our ClearCase server tells me:
ClearCase version 7.1.2.0 (Tue Sep 21 12:01:15 EDT 2010) (7.1.2.D100920)
#(#) MVFS version 7.1.2.0 (Tue Aug 10 00:37:25 2010)
cleartool 7.1.2.0 (Wed Sep 8 12:56:06 2010)
db_server 7.1.2.0 (Sat Sep 4 01:27:12 2010)
VOB database schema version: 54
I have a snapshot view already created on my local machine. I've imported the project into Eclipse.
EDIT: The snapshot view was created using CCRC (Clear Case Remote Client).
When I click my project in the Project Explorer, and then run Team -> Associate With ClearCase, I get a dialog that says it's scanning the project folder and I get no errors when it finishes. (Nothing in Error Log view either).
I see label decorations (although they are all empty), but other than that, it appears the association didn't actually do anything.
When I select Properties -> Clear Case on the project or any file within it, I get:
"The selected resource is not a clear case element".
Is there something I need to do to make this work? Or does the plugin simply not support snapshot views?
FYI, the IBM plugin works in the exact same configuration, however it is horribly implemented, so I'd rather not use it.

I use generally the IBM Eclipse plugin for ClearCase, but I have seen the SourceForge Clear Case plugin works with snapshot view, but only for base ClearCase, not for CCRC.
The main difference I saw between the two plugin (beside their behavior/implementation) is that the IBM one needs the .project and .classpath to be where the project files are (and not separate, one in the Eclipse workspace, the others in an external path).
The other difference is in the type of ClearCase client supported:
The IBM ClearCase plugin can also support CCRC views (as opposed to the Sourceforge ClearCase plugin, limited to Base or UCM full ClearCase client).

Related

How to Add Missing Foundation Baselines in ClearCase

So Someone from my team has deleted some foundation Baselines from an Integration Stream and now when people rebase their development stream many of the folders and files inside them are missing.
We can see those missing foundation baselines in the development streams of that Integration Stream.
So I wanted to know how I can add those missing foundation Baselines from those dev stream to int stream, we only have access to IBM ClearTeam explorer to do it.
we only have access to IBM ClearTeam explorer to do it.
So you still have the CCRC CLI (rcleartool) (assuming the CCRC WAN Server is upgraded to ClearCase® version 8.0.0.3 or higher)
mkbl, however, is a cleartool command only (not rcleartool) in CC8, but rcleartool mkbl does exist for CC 9.x.
You could use that to recreate your fundation baseline, assuming you can tweak a (preferable dynamic or webview) config spec to select the right versions.
The baseline still exists, so you should be able to rebase the integration stream to re-add the baselines. You may want to describe the baseline to find the stream the baseline was created in to be sure you know everything you need to know about it.
rcleartool rebase -baseline baseline1#/vobs/mypvob,baseline2#/vobs/mypvob
Should be enough to accomplish the job. If your int stream has a successor baseline as the foundation now, and the component is not read-only in your project, you'll get an error message. The error message should tell you more about why you can't do the rebase.

When publishing how to have only the latest version

I have a WPF application which i publish in intranet, the thing is i published the application 20 times till now, so i have 20 folders and the size of the build becomes more, i manually delete and leave only 2 latest versions, but is there a way to only have latest version to be published?
Right now i save in folder and then copy to inetpub\wwwroot, but if i had to send the files directly using Visual Studio, i have speed issues due to weak intranet lines in some branches.
but is there a way to only have latest version to be published?
You are already only publishing the latest version each time you publish.
The older versions don't magically disappear when you publish a new version though. You'll have to remove them manually one way or another:
Can ClickOnce be configured to delete off old published directories?
Actually when u publish only current and previous version source are there in application files,Visual studio publishing tool doesnt delete the older versions in published folder ,so we are seeing too many folders .Just delete everything in publish folder before publsihing and you will have only two folders current and previous version.

Upgrde to Clearcase 9

Project has taken so long to decide to upgrade Clearcase from 7.1.2.6 that we 8 going out of support in less than a year we now looking at CC version 9.
Does anyone have any experience or knowledge if potentials pitfalls or issues doing this.
We are using UCM CC with CQ and have seen one post describing an update in how this can work but is there anything else any one has encountered?
Common stumbling blocks include:
VOB schema version. Since you're on 7.1 already, we at least know your VOB schema is supported.
Feature level. If any of your VOBs are not at least feature level 6, you need to update them to FL6 before upgrading CC. See About feature Levels and ClearCase for more on the available feature levels.
Platform support. Between 7.1.x and 9.0, a number of older platforms were explicitly desupported, among them XP, Windows 2003, Solaris 10, Red Hat Linux 4 & 5, etc. You may have to update the OS, which may require a hardware update. You should review the ClearCase 9.0 Detailed System requirements to verify whether your server and client hosts need to be updated in order to support the new release.
Integration changes. If you are using older development tools, they may no longer integrate with the current ClearCase release.
User Interface changes. ClearCase 9 includes an Eclipse-based client called ClearTeam Explorer which has some, but not necessarily all, of the functionality from CC Explorer, Project Explorer, the vtree browser, and some merge tools. Those older tools still work, largely the way they did before warts and all.
There is a lot of work in 9.0 to make ClearCase more "thread-friendly" to allow for multithreading some server processes in subsequent releases. Some of this (view and albd improvements) should show up fairly soon in 9.0.1.
As with any large system migration, setting up a test environment would be recommended to locate any issues with tool integrations before rolling it out in production.

Need to customize DNN 8 Modules and Skins

Is it possible to customize the DNN 8 modules and Skins? Is it possible to config the DNN 8 and use it in VS 2010 framework 4.0? If is it let me know the steps to do, because I have configured DNN 8 site to the IIS 7 and it works good from the there, but when I am trying to load this to the VS2010 and Build it, it gives me different errors.
Errors:
i) Unknown server tag 'dnn:DnnCssIncludes' - Which was resolved by adding one line for dnn tag in the same file.
ii) After resolving previous error the another error wsa of ckFinder, and it was resolved by adding ckFinder.dll file in bin folder.
iii) After resolving previous issues it generates new error for ckEditor. It shows me the following error message:
The type or namespace name 'Ventrian' could not be found (are you missing a using directive or an assembly reference?)
I have tried to resolve and search for the solution but fail to do. Will any one let me know the fixes for this?
Yes, this is possible, you will want to do a couple of things
Setup your Environment
Open the Project for whatever you are modifying, this typically involves install the SOURCE package of the extension you want to modify.
Don't change "core", meaning don't change "DNN" itself, you can, it's open source, but once you do you are forked and upgrading to new releases of DNN is very difficult to do if you aren't careful.
Setting up your environment
From http://www.christoc.com/Tutorials/All-Tutorials/aid/1
Setting up your development environment can vary based on what your end goal is. If you are doing module development for your own use, and within your own DNN environments, you can ignore a few of the settings below. If you are doing module development with the idea that you might turn around and give the modules away, or sell them, then you will likely want to follow the guidelines set forth below to support the widest array of DNN installation environments.
I recommend that each developer have their own local development environment, with a local IIS website running DotNetNuke, and a SQL Server 2008/2012 (not express, though you can use it) database for the website. Having an individual development environment makes group module development far easier than if you share environments/databases.
Choosing a DotNetNuke Version
Choosing a version of DotNetNuke is important when you start your development for couple of reasons. For modules that you are developing for yourself, you need to ask, what is the minimum version of DotNetNuke that you have in production. Are you running DNN 5.6.1? Are you running 6.2.6, 7.0.0, 7.0.6? Based on the answer you can determine what version of DNN you should setup as your development environment. You shouldn't be developing on a newer version of DNN than what you have running in production. As with everything there are ways around this, but I am not going to go into the details on that in this tutorial.
As a developer working to create modules and release those, you might have production sites that are running on the latest and greatest version of DNN, but what about your customers? Or your potential customers? You have to ask yourself, do you want to provide support for really old versions of DotNetNuke? From a development perspective you will probably say no, but from a business perspective, you might say yes, and here’s why. Not everyone upgrades DotNetNuke websites as they should, and often times you will find that some people never upgrade. While I don’t advise taking that approach to managing a DotNetNuke website, it is a fact of life that people don’t always upgrade and there are thousands of people, if not tens of thousands, that have sites that aren’t running on the latest version of DNN. You should take that into account when you are doing your module development, if you compile your module against an older version of DNN then your module should run on newer versions of as well, for example. If you compile your module against DotNetNuke 6.2.6 it will likely run on every version of DNN released since then. Though there are extended cases where this won’t always work, DNN strives to maintain backwards compatibility, this isn't always possible.
You might also want to use features that are only available starting with a specific version of DotNetNuke, such as the workflow functionality found starting in DNN 5.1, in that case you may choose not to support older versions of the platform out of necessity. This will minimize the market in which you can sell your modules, but also can make for less support and an easier development cycle due to the features that DNN provides.
Choosing a Package
Now here’s one that may baffle you a bit. I’m going to recommend that you use the INSTALL package for whatever version of DotNetNuke that you download. What? The INSTALL package? What about the SOURCE package? Well you can use the source, but you don’t need it. The module development that I’m setting you up for doesn't require the DNN source, and using the INSTALL package makes your development environment cleaner. We aren't going to be opening the DotNetNuke project when we do our module development, so why have the files sitting around for nothing? Also, if you've ever tried to use the SOURCE package for anything, you'll know it isn't easy.
The steps for setting up your development environment will apply to both the Community and Professional editions of DotNetNuke.
Installation Configuration
Once you have the version selection out of the way you can go through the installation process. While I’m not going to walk you through the minutest of details of each step of installing DotNetNuke in this post, I will at least try to point you in the right direction for each step.
Download the INSTALL package of the version of DotNetNuke you want to use in your development environment.
Extract the files in the INSTALL package to a location of your choosing, this location is where you will point IIS (the web server) when we can configure the website. In my environment I typically use c:\websites\dnndev.me\ (One item of note: you may need to right click on the ZIP file and choose Properties before extracting, on the properties window if you have an UNBLOCK option, click that. Some versions of Windows have started blocking files within the DotNetNuke ZIP files, which will cause you problems later during the actual install.)
Setup IIS
IIS is the web server that comes with Windows computers. DNN 7 requires IIS 7 or later (7,7.5,8.0), so you will need at least Windows Vista, Windows 7, Windows 8, or Windows Server 2008 R2, Windows Server 2012.
In IIS you should create a new website (Note: If you use an existing website in IIS be sure to add the HOST binding for DNNDEV.ME), and point to the folder where you extracted the INSTALL package.
Note: With DotNetNuke 7.0+, .NET Framework 4.0 is required, so be sure that your application pool is configured to run under 4.0, and not 2.0.
Set File Permissions
Setting up the file permissions for your DNN install is often the step that causes the most trouble. You should right click on the FOLDER in which you extracted DNN (c:\websites\dnndev.me) and choose properties. Choose the Security tab. You need to add permissions for the account in which your website's application pool is running under. You will want to setup the permissions to give the account Full or Modify permissions for the DNNDEV.ME folder. Which account you will use will vary based on your version of IIS, here’s a simple list of some of the default accounts based on the version of IIS.
IIS Version Operating System Account
IIS 7 Windows Vista, Windows Server 2008 localmachine\Network Service
IIS 7.5 Windows 2008 R2, Windows 7 IIS AppPool\APPPOOLNAME
IIS 8 Windows 2012, Windows 8 IIS AppPool\APPPOOLNAME
Note: If you are using IIS7.5/8.0 you’ll notice in the above table that we have APPPOOLNAME in the identity, this is because when you setup a new website in IIS a new application pool is created. In place of you should type in the name of the application pool that was created. You can also bypass this and configure your application pool to use the Network Service account instead of a dynamic account if you would like.
Database Configuration
In SQL Server you should go through and create a new database. I always create a database with the same name as the website, so in this case DNNDEV.ME. Once you have created the database, create a user that can access that database. I always use SQL authentication, turn off the enforce password requirements, and give the user DB Owner and Public access to the DNNDEV.ME database. Remember the username and password you create here as you will need them when you walk through the Installation screen for DotNetNuke.
DotNetNuke Installation Screen
Populate the installation screen with the standard DNN information, Host username, password, etc. For the Database option, choose Custom and configure your database connection, providing the Server IP/Name, the Database name (dnndev.me). For the database authentication you'll want to choose the option that allows you to enter the username/password for the database user that you created previously.
Now there are two additional options you can configure, normally I would tell you not to modify these, but from a development environment perspective I do recommend that you change the objectQualifier setting. It should be blank by default, you should type in “dnn” (without quotes), this will prepend “dnn_” to all of the objects that get created by DNN such as Tables and Stored Procedures. This is not something I recommend from a production stand point, but if you are developing modules for sale, then supporting objectQualifier in your development is recommended. It will save you time down the road if you have a customer who has an objectQualifier defined on their production databases.
DotNetNuke Module Development
To get started with your DNN module development, be sure to read our tutorial on how to install our Module Development Templates.
Next, setup Visual Studio Templates (you'll want to use VS 2015) and create a project.
You can find the templates here https://visualstudiogallery.msdn.microsoft.com/bdd506ef-d5c3-4274-bf1d-9e673fb23484
Download that, run the VSIX package installer, or search through the online templates for DotNetNuke. Watch this video https://www.youtube.com/watch?v=kOoQJDeTlJ0&list=PLFpEtny5sIbb9jGxJ7RBM5hIizodOCtoj&index=1

Simple deployment from ClearCase on Unix

I have recently joined a team that has several applications that perform workload automation. They use ClearCase for version control but the development and test environments are (I surmise due to a lack of ClearCase expertise within the team) not checked out/deployed out of ClearCase but simply FTP-ed to respective Unix servers from Window. I said "simple deployment" because all the code is interpreted (Perl and shell) so no need to compile. Needless to say, many things are wrong with this approach, most specifically the lack of version management in these environments from the point of deployment onward.
So I would like to bind our deployments to the repository and start controlling changes but I am only a ClearCase novice. My specific question is: what is it that I deploy, a VIEW or a STREAM? I would say the latter cause views are user-specific while (according to my understanding) a stream is a project trunk off of each view is like a branch and views are integrated into their stream.
If anyone has any pointers on some useful yet succint and lightweight ClearCase tutorials for an "accidental" CM liason, please share.
Alternatively, if you think this task is suitable for Jenkins, despite being relatively simple (no build/compile involved) please chime in.
Thanks in advace
You would need to use the Jenkins ClearCase UCM plugin (in combination with Jenkins ClearCase plugin) in order to start jobs based on a ClearCase Stream
Jenkins will create an UCM snapshot view based on the stream you will specify in it.
See also, for more on the stream:
"Difference between branches and streams in ClearCase?"
"Integration stream vs integration view in ClearCase"

Resources