Moving sub-projects in Git

When I started this project I didn't actually know I was starting a project - it was going to be a template application for Vaadin 7, and the sandbox name I gave it was "V7".

I finally got round to changing the name, and decided to go through a major refactoring exercise at the same time.

I had a multi-project set up with a single Git repository and a master repo on Github.

Managing a multi-project set up is simple with the combination of Gradle, Git and IDEA that I use.  There's a Gradle plugin for Vaadin, too, to make life really easy. 

However, I decided I would separate sub-projects into their own repositories .. mainly to provide logical separation, but also because some of the experimental sub-projects will never be completed.

I wasn't looking forward to the task, thinking it would end up in some complex Git manipulation, but I was pleasantly surprised.  

The method described here, works extremely well - and it keeps your Git history.  The only issue I had was IDEA occasionally re-creating references to sub-projects that I had deleted - I'm not sure what was going on there, but I eventually cleared them.

The final step was to "promote" one remaining sub-project to become the main project, in the existing repo.  This again proved straightforward.  Git is quite happy for you move files around, or rename the local repo, as I did, as long as you don't modify the content of the files at the same time.

And finally, Github makes it really easy to change the name of your repo, even re-directing your original URL to the new one.

It makes a change for something you expect to be complicated to turn out to be easy ...

Eclipse to IDEA

Why consider a change?

I have been using Eclipse for many years, and still really only used a small part of its capability.  I had always been reasonably happy with it, despite the occasional issues, I fully appreciated the fact that I was using free software (although I did make a couple of small donations).

But a couple of years ago I started getting problems with its interactions with Ubuntu.  Now to be fair to Eclipse, some of the underlying issues were almost certainly outside Eclipse itself  ..  but I had been losing time from menus disappearing and SWT related random crashes for a long time.

At a suitable break point in developing V7,  I decided to upgrade to Eclipse Luna.  Initially I thought all was well, but when some (but not all) menus stopped working I admit I just lost patience.

So I tried Intellij IDEA.

Making the Change

I knew of course that changing from something very familiar would be a bit of a challenge, so naturally I started with the Community Edition of IDEA.  

Trying to do some very simple things took time, because I had to find out how to do them.  Now the IDEA documentation is pretty good, but sometimes you just have to know the right words to find what you are looking for.

It wasn't helped because I only code in my spare time - my current day job doesn't require it - so I was forgetting new things between sessions.  But I resolved to be patient and give myself a chance to find my way around ...

For reasons I can't explain, I find I use keyboard shortcuts more than I did on Eclipse.  Ironically, if I had used shortcuts more on Eclipse the changeover may have been easier as you can select an Eclipse key mapping for IDEA.

Anyway, after a bit of early frustration just getting used to the differences, I came to like IDEA, and I've been using it for about 3 months now.  The biggest single reason is still that it doesn't crash, or have quirky menu issues.  

My favourite feature is the Live Templates - much more powerful than the Eclipse equivalent and can be a real time saver by generating code for your common coding patterns.

I like the Gradle integration too .. with Eclipse I always used the command line for Gradle, it was just easier.  No great problem, but Gradle actually just feels like part of IDEA.

Of course there isn't the huge array of plugins that Eclipse has available, but even so, there are quite a few;  it seems that most, if not all, of the common requirements would be covered.

Paying the Price

Now the Community Edition is only for pure Java, and for a while that was enough.  But it doesn't take long before you stray into needing the licenced (called 'Ultimate') version.  In my case, I wanted to run a web app on Tomcat, which isn't supported via the Community Edition.

So then I was faced with buying a licence, or returning to Eclipse ... and the licence would cost more than I had contributed to Eclipse. 

I decided to go ahead, still mainly because of stability, but also because I keep finding features, often quite small in themselves, which just make coding a bit easier ... and I am fortunate enough to be able to afford a personal licence.

I must admit though, that I still feel a bit guilty about leaving Eclipse  ... I've always been a keen supporter of the open source movement.

Vaadin, Guice and Quartz

Progress

I can't believe it is so long since I posted to this blog.  I guess I must have been busy!

Those who have read previous posts will know that I have been working on a project called V7 to provide Vaadin, Guice and Shiro integration, with some I18N and navigation support thrown in.

Making Time(r)?

Quartz has become a popular scheduler for Java, and I wanted something to test my V7 design to ensure that I could integrate and add in a library without too much difficulty.

I have recently committed an implementation for this, so there now also an optional V7 library for Quartz, already integrated with Guice.

Observations

I do find some of the Quartz API a little strange, but despite that the integration seems to be fairly robust.  And to be fair, I guess Quartz is popular for a reason - it works!

One thing which I find strangely missing (and I know I am not alone) is the ability to define dependencies between jobs.  

But .. it works, and is now integrated with V7.