Seva Lapsha at Work

Time passes and doesn’t wait, and some of the plans don’t be realized, you know. So due to last year inactivity my PDT committer rights were expired and I was appointed with the Eclipse Committer Emeritus status. How sad.

I will still try to not loose connections and relations with my good old friends and will do my best for the project’s success (even if it will be just mental support).

Recently, while playing with Scala/Python/PHP comparative implementation of lazy algorithms (I will hopefully describe them some days later) with colleague and friend of mine Michael Fuks, I sorrowfully discovered that, despite there are several SPL units, which define basic Iterator interfaces and functionality, most of the functionality available for arrays is missing for Iterators.

So I decided to fill the gap and started to reimplement for Iterators the applicable non-trivial array functions and also started trying to simulate iterator comprehension (generator routines) in PHP which is missing there too. For this reason I opened a GoogleCode project of php-iterator-utils – please observe my first experiments here.

In addition I need to notice that latest NetBeans build (6.8) branch has great PHP 5.3 support and feels more stable, fast and functional than Eclipse PDT

Got the Programming in Scala eBook. I hope to get time and build an experimental Eclipse Plugin with it.

I’ve just failed to install JDT over clean Eclipse Platform RC1 (and this time a bug has been opened):

An error occurred while installing the items
session context was:(profile=PlatformProfile, phase=org.eclipse.equinox.internal.provisional.p2.engine.phases.Install, operand=null –> [R]org.eclipse.ant.ui 3.4.0.v20090504, action=org.eclipse.equinox.internal.p2.touchpoint.eclipse.actions.InstallBundleAction).
Error while loading manipulator.
Error while loading manipulator.

Retrying causes the message immediately. Reverting to the previous installation stage does not help. Restarting does not help either.

It’s very sad that what they call Release Candidate is still rare. Waiting for the release…

Honestly, I was pretty unsure regarding Maven at all. “Why should I port my projects from Ant, where everything is plain, simple and predictable? Single point integration jars are connected to their dependent projects, shared ones are extracted to a Libraries project. Deployment is as easy as checkout and build…” – I convinced myself.

But soon I’ve realized that if our team’s Product is no more than a chain in the string of Products and Components which are unified into the Solution, than why the hell should our code base not to be like that? It’s so nice that lots of Environments has their packaging systems which make installation simple and aesthetic… So if you work in Java and harmony and beauty are not just senseless terms for you, believe me, you should use Maven.

The main Maven’s advantage over Ant is that each dependency, called artifact can be (and commonly is) an independent project with its own history of versions and dependencies. So, if you want your project to be dependent of any library, you can just find it in one of major Maven repositories, add its id to your pom and – voila! it works.

Then, when time comes to deploy your stuff, you pack it and do the same – upload your stuff to another maven repository. Here the cycle closes and the universal happiness has been achieved.

Now, regarding the subject. There are 2 Maven Eclipse plug-ins in the market – m2eclipse and q4eclipse. Both of them recently were accepted as Eclipse native incubation projects as M2E and IAM. I tried them both starting from the second, but as it always happens, the first was the better one. M2E is very stable, comfortable and easy to understand w/o any documentation, while IAM is pretty buggy and unclear.

So I chose M2E to work with and it took just about 3 hours to convert all my projects to poms, configuring all their dependencies and then converting the projects into Maven managed ones. With the last action, all the Eclipse dependencies convert into Maven dependencies, the build is replaced with Maven build and it guarantees that there will be no surprises in production builds. And then you can proceed with LB/Continuum/CC with no time spent to understand why nothing doesn’t get built correctly.

Now what’s remaining is to reintegrate the changes from the sandbox branch and help the team to not be too scared of the changes

Long time ago I set up Google alerts to receive new search results related to myself. And today I’ve discovered that Aptana steals “prepares derivative work of“ PDT code.

The only visible “derivation” there is they changed package names, though.

As you all know in Eclipse 3.4 there is a new Update Manager (more correctly – Plug-in Manager) which is intended to be better.

The update managing side of it is an improvement indeed. But the first thing raised my alertness is there is no place to point where do I want my selected plug-ins to be installed. Well, I thought it’s just a default selection and manually downloaded the plug-ins and dropped them into the famous dropins directory (of course with keeping directory structure). And then after restarting eclipse I discovered that there is no such a thing like hierarchy of plug-ins and plug-in locations at all. That’s too bad.

Now, let’s say you installed all the plug-ins. Then if you want to update them, you don’t have a overall progress bar. And this is a network connection related progress. Isn’t it stupid?

Another glitch: My wireless connection to my neighbor’s hub suddenly aborted. So what does it do? It shows me an error dialog behind the modal dialog of progress information. I’m not even mentioning that there is no retry/ignore options.

Now they say: you can replace the new p2 with the good old Update Manager. But for that you must restore several configuration files from 3.3.2. I understand, this is my stupid mistake that I first completely destroyed my previous installation (I can allow it to myself at home), but it’s still annoying.

As I mentioned previously, recently I started to work on two monitors. Here comes the picture (sorry for the bad quality):

Several days ago I was given an additional monitor, and the question of “how to arrange Eclipse view on two displays” was raised. After several tests I made the conclusion that the best way is to stay with my default preferred arrangement, with single difference – to detach and move all the non-editor views to the secondary screen. It frees up editor area and at the same time does not require re-adopting new layout.

The bad news is Eclipse rejects to start up when UltraMon is running.

One of my first assignments at the new company (remember, I left Zend previous week), was analysing existing projects structure. Which means distribution of classes into packages, package dependencies, libraries usage etc.

The results, I would say, were far from being perfect, but I can bet, most of large (and especially proprietary) projects would look similar or even worse. But this is not what I was going to say.

What I am going to say, is for this purpose I evaluated several analysis tools and I want to share my opinion about them.

Here they are (in order of evaluation).

1. Eclipse Metrics(1) (CPL)

Pros: Runs fast, provides tangle detector.

Cons: Dependencies graph is not usable with large projects. No text output of dependencies is available.

2. Eclipse Metrics(2) (CPL)

Pros: no.

Cons: Does not analyze dependencies.

2. JDepend

Pros: Nice and simple UI, fast analysis.

Cons: Provides neither graph nor detailed dependency cycles information, doesn’t provide links to source.

3. eDepend (Commercial)

Pros: full featured graphic dependency analyzer, allows filtering on dependency kind

Cons: Commercial, creates disproportedly wide graphs for large projects that are hard to maintain, very slow analyzing and graph creation, doesn’t provide info on elements which depend on selected element.

4. stan4j (Free Beta)

Pros: Full featured graphic dependency analyzer, very cute GEF based UI, cycles and tangles visualizer, very convenient eclipse integration, report/graphics export ability.

Cons: Does not provide recursive dependency paths on selected elements, does not provide inter-package class dependencies information, non graphical views improvement is suggested.

Conclusion

In the end, in order to perform my task I’ve mostly used stan4j, sometimes switched to eDepend
and once or twice times executed JDepend - each of them has its specific advantages.