Great to hear. I definitely agree that it would be hugely helpful. Here are some thoughts I’ve had during and since development of the first version of the IDE. It’s hopefully not too rambling, but I’ll try to lay out some architecture and design ideas/thoughts I’ve had
Target Market
I’m not sure the demographics of who uses liquibase, but I would guess that it is generally agile-practicing developers who use java. There are some non-java developers who use liquibase, and there are some non-developers (i.e. DBAs, release managers, etc) who use liquibase, but I think that they are a minority. Should the liquibase IDE cater to our current largest group? Or does the core liquibase library meet their needs to a large extent, and the IDE should have a goal of giving liquibase a larger reach? I think an IDE would make it much easier to quickly understand how liquibase can help you without necessarily exposing you to the Java/XML implementation details and so a DBA used to using TOAD or a .Net developer wanting to manage their database would find the Liquibase IDE to be a good tool while they would never have considered the core liquibase library. At the same time, we have an existing market, and we certainly do not want to increase the time develop, complexity, or usefulness of the IDE for that existing java developer market for the hope of expanding liquibase to people who may still not be interested.
Stand alone IDE vs Plugin
The old IDE version was built first on top of Eclipse, and then also as an IntelliJ IDEA plugin. There are many good IDE base packages to build on, and we definitely want to take advantage of one of them so that we can focus on the liquibase logic, and not on all the other logic that goes into building an IDE. One question we need to answer is if we want to go the plugin route, or the stand alone IDE route. Developers certainly like having everything in a single IDE, but if you build a plugin for one IDE you are cutting out users of different editors. I was going to go the route of abstracting the plugin code so that it was easy to write eclipse, intellij, netbeans, etc. adapters but since that effort fizzled due to a lack of time, I’ve been starting to wonder if that is unnecessary work. Each IDE works differently and has different UI requirements. If we spread our small resources over too many editors, they will all suffer. Plus, while developers do like having everything in their IDE, they are fine using different tools, especially with regards to databases. They are used to having the MySQL workbench or sqlserver management studio open in addition to their IDE, and so if they can replace that window with the liquibase IDE, that may not be a deal breaker. So I would suggest concentrating on creating a stand-alone IDE and not worrying about supporting plugins to multiple IDEs. If we choose a base platform that is an IDE that supports it as a plugin, great, but it shouldn’t be a requirement. What is a requirement, is that there is a low-overhead version of the platform so the final liquibase IDE isn’t a huge, bloated app because it also supports php competition and ejb deployment.
What base to use
Assuming we are doing the stand-alone IDE, not a plugin, we would want a base toolkit that supports:
- A user-friendly database schema browser
- XML editing support
- Multiple database types
- Easy installation
- Ability to include only functionality we need (see above)
- Royalty-free
- Looks like a standard application, even to DBAs and non-developers
From the IDE world, I think that means: eclipse, netbeans, intellij Liquibase Open Source, visual studio shell. From the database-tool world there may be options as well including SQuirreL.
A potentially obvious choice would be eclipse: it is open source, it is very common among java developers, so it would fit as a plugin and just not stand alone, and plugin support is a strong part of their architecture. I haven’t looked at eclipse for a while, so my opinions on it may be outdated. I found the database tool support to be very not user-friendly. It consisted of dealing with drivers, url strings, and confusing connection management to open a connection, then the schema browser was limited and not as extensible as we would need. I also found the support for stand-alone IDEs built on eclipse rather than plugins was less documented and thought out, and creating a single codebase to support both options was overly difficult. I also feel that the eclipse UI in general takes getting used to and so would be a deal-breaker for non-java+eclipse developers such as DBAs.
At this point, NetBeans concerns me to use as a base, given Oracle’s purchase of Sun. I don’t think it will go away, but it has never had the reach or user base of eclipse, and I’m not sure how much more it will be advanced. When I last looked, their stand-alone IDE support was also very poor.
JetBrains IntelliJ Liquibase Open Source is a new entry. I personally find their UI much nicer looking and more user-friendly than eclipse (which is why I use IntelliJ and perhaps why I am biased). They open-sourced their base IDE, but it does not (from what I could tell) include their database browser. I’m not sure if it includes a data source connection manager at least, or not. Creating a base platform that Jetbrains can build on is a very good business move for them (they have several IDEs built off it now), but I don’t know how well they will treat the open-source version. Is it the same as they use? Or a fork that needs to be maintained separately? Will they decide it’s not worth keeping open source and move development internal at some point? Those are questions we would need to answer.
Visual Studio Shell is a surprising option to throw out but is worth considering. It is certainly the most native-feeling application as a stand-alone IDE and with VS2010 arguably the prettiest. It is not open source, but it is royalty-free. It would definitely help make liquibase appeal to the .net crew (and possibly the DBA crew as well). Would it alienate our large java developer users? I would think not. To them, it should just look like a stand-alone app that they can use to modify their changelog files that are then run on server startup or deployment like always. The two biggest issues in my mind is:
- IDE cost for contributors. If we had a .net app, the devs would already have VS and it wouldn’t be an issue. For a java developer looking to help, however, there would be no reason they would want to buy VS so they can volunteer time. I’m not sure if MS has any open source project licensing options.
- .Net port of liquibase. I did a proof of concept port and it looks like it would not be overly difficult using ikvmc. However, to use liquibase from inside of VS, it would be much easier to have a .net version running to use. Adding this as a requirement, probably makes the chance of ever getting to the IDE near zero.
Beyond those issues, I’m also unsure as to the support for multiple database types and/or the ease of use of their database browsing tool. I wasn’t able to figure out how to get it to connect to non-sqlserver databases, but I am also not a .net developer. Still, VS is a option worth strongly considering, I think.
Database Browser UI (aka Not a Code IDE)
As I eluded too above, I’m not sure if any of the IDE platforms really have a strong, user-friendly database browsing base. They way I imagine the liquibase IDE to work, is to open it up and select your connection. Then you can browse the tree view of tables, columns, views, etc which you can right click to bring up editing and “refactor” menus. You should be able to have the normal “edit table definition” type UI where you can see the current definition and make changes such as chanign the name in the textbox or changing a column’s datatype and the UI will know what type of chagneSets to create from that. There should also be the “refactor” menu for more complex operation such as “introduce lookup table” and easier versions of simple commands like “rename table”. You also need the ability to view and edit the changelog xml files as XML (or whatever format they are in) from within the tool.
Most of the above IDEs are primarily code editors with a database tool bolted on. They either don’t have a database explorer, or it is very limited and somewhat second class (you need to have a java project created and attach database connection information to it). If one of the IDEs above has a greatly improved database editor since last I looked, that would put it in the front of the pack but I am suspicious that whatever base we choose, we will need to create our own database connection management and browsing support. It’s not ideal since it takes time away from making the liquibase part of the liquibase IDE, but it is probably what we will need to do if it needs to stand alone as a tool and be user-friendly enough to get users.
A better option would be to write a plugin to an existing database editing tool. Unfortunately, I don’t know of any viable candidates. From the research I did (more should be done, though), they either don’t support plugins, support only one database type, or are not actively supported and maintained. If you know any good candidates, let me know.
That is probably a good starting point for discussion, I think. I have some support thought about in the Liquibase Open Source library (affected database objects, change classes knowing what type of database object they can operate on, etc) but I think the base framework needs to be decided on first.
What is your development background and thoughts?
Nathan
