I've been playing around with a crazy idea ...

I've been playing around with a crazy idea of recreating Eclipse JDT tooling with XText.

While it does sound a fair bit more than a little crazy, it appeals to me for few reasons:
  1. It would give me great opportunity to learn XText and test it in a non-trivial setting.
  2. It would give me great opportunity to learn more about Java the language.
  3. Having Java source code parsed into a well defined EMF structure opens up JDT to all the  goodness of EMF tooling that has been developed over these past years.
It seems like an interesting idea. I wonder if I actually get around to giving it a try...

Comments

Federico Tomassetti said…
Are you aware of EMF metamodels of the Java language? Did you make any progress on this idea?
1:04 PM
Luolong said…
I am aware of them in the sense that I've certainly heard of them, but I have not really checked them out.
Neither have I made any progress on the idea...
4:56 PM
Post a Comment

Popular posts from this blog

Musings about build systems

I was just hacking the other day our somewhat horrible hairball of an ant build to try to mold it to my understanding of how a build should work when I had a sort of an epiphany about why on earth I dislike Ant so much. Apart from the syntax (and I think it is universally agreed by now, that XML is a horrible, horrible language for scripting like tasks), what hit me is that while ant is okay for simple one-shot single project builds, it really falls on it's knees as soon as you start building complex modularized systems where you need some sort of dependency management. Now, before I go on, I must mention that I have heard of alternatives like make, Maven , Buckminster , b3 and the ilk, but I really don't know much about any of those (well, by the time I started to write this piece, I had taken a peek at Buckminster). I am not really what you would call a "build person" - I'm using Ant, because it's what comes with most of the projects I've been invol
Read more

Comparing Jenkins vs TeamCity - Part 2

Image
This is a second installment in a series of posts that tries to compare two continuous integration and build automation server products. In my previous post I briefly introduced the contenders open source developed Jenkins and a commercial offering from JetBrains called TeamCity and compared their respective installation experience. This time I'll try to cover the post-installation configuration steps I need to make before I can start putting some builds into them. Configuration No server software is usually useful out of the box in and by itself. You almost always need to tweak and configure it before you can really reap the benefits. Continuous integration is just another type of server and it needs to be configured before it becomes really useful. TeamCity After you've installed your copy of TeamCity and opened up it's web interface for the first time, it greets you with a nice little license agreement, you need to agree to in order to be able to continue.
Read more

Comparing Jenkins vs TeamCity - Part 1

As some of my closest friends already know, I decided to bite the bullet and switched jobs recently. As the new company I now work for is really small compared to the one I left, it also means that as a developer I am also involved in more than just programming. One of the decisions I had to make and implement was selecting and setting up a CI server for continuous building and deployment of our next product. Having had extensive exposure to CruiseControl, I immediately discarded it as I've developed a particular dislike for this product. The next alternative I had had any exposure to was Hudson ( now renamed to Jenkins ) and JetBrains's TeamCity , which I had heard a lot of nice things about. Adding to the mix that first project to hit our CI server would be .NET project, I needed a solution that would run on Windows and build .NET projects using MSBuild. I settled on Jenkins and TeamCity as the two major contenders. I would like to point out that this post is ful
Read more