14 comments
Comment actions Permalink

Hello Eugene,

EZ> Does JetBrains plan to add native (not third-party released)
EZ> ClearCase support? And, if not, what should happen to change your
EZ> plans? Feature ID http://www.jetbrains.net/jira/browse/IDEABKL-587

It's quite likely that ClearCase support will be implemented in IntelliJ
IDEA 7.

--
Dmitry Jemerov
Software Developer
http://www.jetbrains.com/
"Develop with Pleasure!"


0
Comment actions Permalink

Dmitry,

This is a great news ! However, i think that it's a bit disappointing because 6.0 is not even out, so that means that we must wait a whole year before taking advantage of it.

But let me talk a bit about the existing ClearcasePlugin.

Important links :
JIRA : http://jira.codehaus.org/secure/BrowseProject.jspa?id=11081
Confluence : http://docs.codehaus.org/display/IDEACLEARCASE/Home
Subversion repository : http://svn.codehaus.org/idea-clearcase-plugin/
Wiki Intellij : http://www.intellij.org/twiki/bin/view/Main/ClearcasePlugin

First, the developers. AFAIK there are 4 developers on this project :
Jacques Morel, Vincent Mallet, Wesley Williams, and me.

Since i've joined i have done the following :
- Migrated the bugs and feature requests from the wiki in JIRA
- Implemented preliminary activity support (http://jira.codehaus.org/browse/IDEACLEARCASE-34)
- Implemented Option to detect out-of-date checkout (http://jira.codehaus.org/browse/IDEACLEARCASE-17)

For reasons explained later, i've not released a version with these features.
Honestly, i have not much time to devote to the plugin. So here is a short description to help users and maybe future committers ;) :

Basically it integrates with Clearcase (CC) in 4 different manners. You can choose that in the plugin configuration screen.
1 - Native integration - uses an old DLL to call CC
2 - CommandLine integration - uses command line calls to 'cleartool', which is a CC executable.
3 - NewNative integration (new way) - uses a recent DLL to call CC (this dll is from the the sourceforge project : http://sourceforge.net/projects/clearcase-java, and is also used by the non-official CC Eclipse plugin located at http://sourceforge.net/projects/eclipse-ccase)
4 - NewCommandLine integration (new way) - uses command line 'cleartool', via the clearcase-java project

2 and 4 exist for non-windows platform, and are pretty stable. 1 is the most stable for me (i'm using windows), 3 is unreliable, you can get a lot of weird messages like "can't co-create object" (it uses JACOB under the hood, see http://sourceforge.net/projects/jacob-project/ )
As far as I know, 3 and 4 are evolutions of 1 and 2. ClearcasePlugin and eclipse-ccase plugin writers just decided to put in common re-usable parts of their respective plugin.


The reliable implementations already works well for basic functionalities :

  • update

  • checkin & checkout & undo checkout files

  • check in project

  • rename class (make sure you use checkin-project though)

  • delete class (requires you to checkout the file first... odd)


.. and not so well for advanced ones :

  • lack of activities support, although i've implemented a version for implementation number ... 3, the unreliable one :(

  • lack of synchronization feature to obtain correct clearcase status for each files (you must make sure you haven't any checkout and your view is up-to-date, then you 'mark your project as current')


From my experience, Clearcase integration is often a must-have when decidors must make their choice on a IDE.
Large companies often have a strong commitment to Clearcase and have not waited for Subversion to come out of beta, or even tried to handle CVS shortcomings (versioned directories anyone ?).
Of course there are other competitors on the market (perforce, starteam etc...), and it would be interesting to compare their respective market shares.


So, to sum it up, here are some scenarios that Jetbrains could up with :

1 - you could "take over" the existing plugin and retrofit it as much as you want and make it an entreprise-grade plugin. (I'm sure Jacques, Vincent, Wes wouldn't mind as it's a burden to support this plugin)
2 - you could start another plugin from scratch
3 - you could help us iron out the existing bugs.

Thank you for reading

Gilles Philippart

0
Comment actions Permalink

Hello Gilles,

GP> So, to sum it up, here are some scenarios that Jetbrains could up
GP> with :
GP>
GP> 1 - you could "take over" the existing plugin and retrofit it as
GP> much as you want and make it an entreprise-grade plugin. (I'm sure
GP> Jacques, Vincent, Wes wouldn't mind as it's a burden to support this
GP> plugin)
GP> 2 - you could start another plugin from scratch
GP> 3 - you could help us iron out the existing bugs.

Most likely we'll go the same route as we did with the Perforce and Subversion
plugins: take over the existing third-party plugin and start maintaining
and improving it. In this case, the plugin will remain open-source, and if
any of the original developers will be interested in continuing working on
it, they'll have such a possibility.

Right now we can't help much with the development of the ClearCase plugin
because we don't even have an installation of ClearCase to test the plugin
with.

--
Dmitry Jemerov
Software Developer
http://www.jetbrains.com/
"Develop with Pleasure!"


0
Comment actions Permalink

Thank you for your answer,

another question (connected to clearcase but not directly).
We can have several versions of package or directory with set of JS files in project (in different source folder points). As I know I can exclude only directories, not stand alone files. But even if it possible - it's not very comfortable to exclude new created file every time it added it somewhere else.
It would be great if I can just set package/source folder as primary for project and it will work as only source for navigating through sources, compiling and etc. How I can initiate such activity?

Thank you.
Eugene

0
Comment actions Permalink

Hello Eugene,

EZ> We can have several versions of package or directory with set of JS
EZ> files in project (in different source folder points). As I know I
EZ> can exclude only directories, not stand alone files. But even if it
EZ> possible - it's not very comfortable to exclude new created file
EZ> every time it added it somewhere else.
EZ>
EZ> It would be great if I can just set package/source folder as primary
EZ> for project and it will work as only source for navigating through
EZ> sources, compiling and etc. How I can initiate such activity?

Sorry, I didn't understand your question very well. If you have different
directories in your project that contain different branches of the same source
files, you should probably create a separate module for each of the branches
and add the respective directories as source roots for the modules.

--
Dmitry Jemerov
Software Developer
http://www.jetbrains.com/
"Develop with Pleasure!"


0
Comment actions Permalink

Dmitry,

I try to clarify
we have such situation:
we have core version of project in CC. For every customer we start new development tree (not branch) in CC and it contains only changed files. So I have two content roots: one of them is full nut another contains files that are customized for my project and I do not need core versions of these files.

Thanks.
Eugene

0
Comment actions Permalink

Hello Eugene,

EZ> I try to clarify
EZ> we have such situation:
EZ> we have core version of project in CC. For every customer we start
EZ> new development tree (not branch) in CC and it contains only changed
EZ> files. So I have two content roots: one of them is full nut another
EZ> contains files that are customized for my project and I do not need
EZ> core versions of these files.

I don't have any experience with ClearCase, but that's exactly the situation
where I would have used branches with any other version control system. There
is no special support in IDEA for configurations such as yours, and I don't
think that we plan to provide any.

--
Dmitry Jemerov
Software Developer
http://www.jetbrains.com/
"Develop with Pleasure!"


0
Comment actions Permalink

I fully agree, you definitely should use branches, that's exactly for that kind of setup that someone would use them.

0
Comment actions Permalink

Yes, I know that branches is the right way in such situation, but this structure was made a long ago and we have no any chance to change that. So I am trying to find a way to organize work in existing conditions

0
Comment actions Permalink

So original development team for the plugin virtually abandoned it (have no time to refine it for JIdea 6) and IntelliJ is not ready to take it over before version 7.
Am I right?

0
Comment actions Permalink

+So original development team for the plugin virtually abandoned it (have no time to refine it for JIdea 6) +

I think we can say yes to this question...


IntelliJ is not ready to take it over before version 7.

It should be 6.5 not 7... hopefully

0
Comment actions Permalink

Could you please write anywhere your contact email so that I could write you to discuss CC plugin requirements?
thank you in advance

0
Comment actions Permalink

Could you please write anywhere your contact email so that I could write you to discuss CC plugin requirements?
thank you in advance

0
Comment actions Permalink

darkace at mail dot ru

But basicly, the functionality we had with Idea 5.1 and ClearCase plugin suited me by 100%. There were some minor glitches in UI and sometimes it didn't catch some advanced rename/move/delete modifications (minor priority for me, since it's rare situation)

0

Please sign in to leave a comment.