Eclipse Ganymede is Released Into the Wild!
Hi all...
It should be common knowledge, but Eclipse Ganymede (also known as Eclipse 3.4) is being release today! As said by the Eclipse folks (thanks Ian for writing a great press release as always) - "The Ganymede Release is a coordinated release of 23 different Eclipse project teams and represents over 18 million lines of code." It's an enormous undertaking by a diverse group of people, projects, and companies, so kudos to everyone involved!
Along with Ganymede is the next major release of DTP (version 1.6). With this release, we add some new functionality and streamline some of what was already there...
One of the things that people have asked for over the last few releases has been a graphical SQL query editor. And it's finally there! Yay!
There is still a bunch of work left to do with it, but for a first release I think it works great. I'm not a big fan of hand-coding joins in SQL statements and this makes it VERY easy to do that. Just click an drag!
Beyond that, we did a ton of work on usability in DTP 1.6 also. We've streamlined the process for creating driver definitions and connection profiles to the point where it only takes a few clicks before you're connecting to and drilling into the Data Source Explorer to view your databases. So a big thank you goes out to Max at JBoss and the Zend folks and everyone else who provided valuable feedback during our prototyping and implementation of these changes.
It's been a heck of a year, but I think DTP is better and stronger than ever. We will get started shortly on our first maintenance release (1.6.1, due out in September) and planning for the next major Eclipse release (in June 2009).
As always, we depend on the community for support and guidance going forward. As you start to explore our Ganymede release, keep an eye to the future and let us know what you'd like to see us do by next June!
Thanks to everyone involved in the DTP 1.6 release -- from Sybase, Actuate, IBM, JBoss, Zend, Ingres, and all those who I can't remember at the moment. Everyone take a bow as the curtain drops on Ganymede, enjoy a brief rest, and then it'll be time to get going again!
--Fitz
So how do you add your own custom driver template?
Hi all...
Sorry there's been a bit of a lag between articles. We've been busy trying to get Ganymede out the door and start planning for the future (maintenance releases for 1.6 plus the next major release of DTP for next June). I need to ditch my crystal ball for a magic eight ball I think. :)
Anyway... This week we're going to chat about how to create a new custom driver template.
First of all, when would you want to do this? There are a few possibilities:
1) You're creating support for a new database type not currently covered by DTP Enablement.
2) You want to add support for a third-party driver (such as DataDirect or jTDS) for a currently supported database.
3) You simply want to add an alternative driver template to complement an existing driver that adds properties or changes default values for use in your application(s).
That said, let's pick #1. We can use it as an example to provide functionality through this article series and eventually add some new database support to DTP Enablement.
For this example, let's work on SQLite support.
You can find a ton of information about SQLite on the SQLite home page (
http://www.sqlite.org/). And you can grab the SQLite JDBC driver from the SQLiteJDBC page (
http://www.zentus.com/sqlitejdbc/). So we'll grab the SQLite binaries for Windows (in my case) and the
sqlitejdbc-v051-bin.tgz for this case. (You'll need to put the sqlitejdbc.dll in your JRE's or SDK's JRE bin directory to get this working.)
Typically the process I work through when deciding whether or not we need a custom connection profile for a given database is as follows:
1) Can I create a new Generic JDBC driver definition that references the jar (sqlitejdbc-v051-native.jar in this case)? Yes.
2) Can I then create a new Generic JDBC connection profile that uses my driver definition from (1) to connect to the database? Yes.
3) Can I browse into the database to see schemas, tables, stored procedures, and the like? Unfortunately not in this case.
This means we need to go a step further and go through these stages:
Stage 1: Create a new Database Definition for our Database
Stage 2: Create a new Driver Template for our Database (and the associated UI)
Stage 3: Create a new Connection Profile for our Database
Stage 4: Create a Custom Catalog Loader for our Database
So let's start with Stage 1 and get Stage 2 started today...
For each database that is supported in DTP and presents its structure in the Data Source Explorer (DSE), we have to tell the base models what the database supports. This is represented by the Database Definition (or "DB Definition"). What data types does it handle? Does it handle aliases or triggers? What kinds of constraints?
The DB Definition file itself is simply an XMI file (an XML file that provides metadata for some other XML files). In this case, it maps back to an EMF model for the DB Definition.
Basically we need to create an XMI file to tell DTP what basic properties this database adheres to. What data types does it support, does it have catalogs, and so on. Most of this information can be found in the database documentation.
To simplify the process a little, we have a sample Java file that can be customized to create a new XMI file. I've modified it somewhat to create the XMI file locally. And I'll post a zip with the necessary files on the DTP website so you can grab them at the end of this exercise.
Once that's created, you can create a plug-in wrapper called "org.eclipse.datatools.enablement.sqlite.dbdefinition". And in that plug-in wrapper we will use the org.eclipse.datatools.connectivity.sqm.core.databaseDefinition extension point to tell DTP about it. Basically the databaseDefinition extension point just maps the XMI file to a named vendor and a named version. That's how the underlying systems will locate it. (You'll see the terms vendor and version appear later as we define our driver template as well.)
So now we have a DB Definition and a plug-in wrapper for it. Cool. Now we can move to the first part of Stage 2: Creating a driver template.
To create a new driver template, we'll start by creating another plug-in. This plug-in will house all the non-UI bits and pieces we want for our SQLite connection profile. We'll call it "org.eclipse.datatools.enablement.sqlite".
In the manifest for our new SQLite plug-in, we will create a new org.eclipse.datatools.connectivity.driverExtension extension. This extension point is used to register driver template categories and driver templates within the DTP framework.
Remember how we were talking about vendor and version earlier? Well, now we're going to map some driver template categories to them.
First we'll create a "SQLite" category, which maps back to the vendor name we chose earlier and has org.eclipse.datatools.connectivity.db.driverCategory as a parent. All database drivers fall under this category in DTP so we can easily find them. We'll call our new category "SQLite" and give it an ID "org.eclipse.datatools.enablement.sqlite.driver.category".
Next, we'll create a "3.5.9" category, to map to the version we selected earlier (3.5.9 is the most recent version of SQLite I could find). This one will use our "SQLite" category as its parent. We'll call it "3.5.9", and give it an ID "org.eclipse.datatools.enablement.sqlite.3_5_9.category"
Lastly we'll create the driver template itself. We'll give it the name "SQLite JDBC Driver" (not very original, but easy to remember) and an ID "org.eclipse.datatools.enablement.sqlite.3_5_9.driver". We'll set it to our SQLite 3.5.9 parent category so it has some context, setting it to the category ID we made a second ago "org.eclipse.datatools.enablement.sqlite.3_5_9.category".
We know it needs a driver jar, so we'll provide a default jar name as "sqlitejdbc-v051-native.jar". If we get fancy later, we can provide some mechanisms to pre-populate the path to the local version of that jar, but for now we'll assume the user will be able to know where their jar is located and set it appropriately in the driver definition. (Yes, we'll talk about the "fancier" way to do this automatically later.)
Beyond that, we need to get a few key bits of information about the driver. Based on the documentation for SQLite, it appears that we require the following property values:
* Driver Class: org.sqlite.JDBC
* JDBC URL: jdbc:sqlite:test.db
Easy enough, right? Well, we also require a few other things for a standard driver definition:
* Vendor: SQLite
* Version: 3.5.9
* Database name: TEST (we can extrapolate this from the sample URL)
* User ID: (not applicable, so we just leave it blank)
With these basic bits and pieces, we have defined our driver template! Whew. Took a bit of work though, I know.
That said, we now have reusable bits we can take into the next part of this process, which is creating a connection profile that can use our new driver definition and driver template.
At this point we're just laying the ground work.
So next time we'll look at creating a basic connection profile that can actually use these bits!
You can find a zip file with some of the bits developed in this article
here.
--Fitz
The 3G iPhone Announcement – Still NO Native MMS
Let's talk about the iPhone some more. Over the last, almost 1 year, this little device has done a great deal for the mobile industry. Love it or hate it, it has had an impact. In less than one year, the iPhone has captured around 19% of the smartphone market and has done more than any other device to make mobile Internet browsing mainstream.
On June 9th, Steve Jobs unveiled the new 3G iPhone at Apple’s Worldwide Developer Conference in San Francisco. This new incarnation of the iPhone will be available, starting on July 11th with AT&T in the USA. I won’t spend a lot of time here listing the new features, but I should note that the 3G iPhone STILL does not currently have a native MMS client. It is still missing things like copy & paste, Flash, Java, and video support – features that most of the other smartphones in the marketplace, support natively. I should point out that, thanks to the iPhone SDK, we should expect Sun to make available a Java Virtual Machine for the iPhone, sometime this summer. Additionally, we should expect Adobe to release Flash for the iPhone as well.
CNET provided live coverage of the 3G iPhone announcement along with details of 3rd party applications and the application developer’s toolkit. Another well-respected industry blog at Engadget gives a nice overview. Note all of the blogger comment complaints about lack of MMS.
There is now a 3rd party MMS client called “Swirly MMS” that is making some news in the blogspace. It is currently a very rough application(can only send, not receive) that one can download. Still, it is a start.
Recall from previous blogs; if I send an MMS to an iPhone user, the recipient will receive an SMS stating that they have an MMS to retrieve from an AT&T (and likely other operator) web site – a terrible user experience reminiscent of the old days when most handsets didn’t support native MMS. Hopefully, this will change
Despite the lack of true MMS on the iPhone, MMS traffic, in general, continues to grow organically and is now approaching 30% of the subscriber population sending at least 1 MMS per month in many markets.
Now that I'm back State-side
Howdy everyone. Been awhile since I've posted huh? Well, after traveling through South Korea, Australia, and Northern New Zealand throughout May doing an ASE Cluster Edition roadshow, I'm happy to be back in the office again. The roadshow was, in essence, 3+ hours of technical information on Cluster Edition, discussing everything from architectural changes, to look-and-feel changes, to implementation tips to get you started. (Some of you out there may have seen Jeff Tallman give a similar presentation throughout other parts of Asia.)
(More...)
