Curious what it’s like to develop tools and IDEs with Eclipse? In this episode, Greg Amerson goes into the details of how you get started and what to expect:

Download the episode directly right here, subscribe to the feed in iTunes or other podcatcher to have episodes downloaded automatically, or just click play below to listen to it right here:

I met Greg at the Liferay West Symposium this week: when I heard he was the “one man team” for Liferay’s IDE and had worked on Genuitec’s MyEclipse before that, I figured he’d be the perfect person to talk to about using the Eclipse platform to develop tools and IDEs. We do just that in this episode.

Also in this episode, you can win free tickets to the upcoming Strange Loop conference if you answer our trivia question. As I say in the podcast, it looks like it’ll be a good event.

Show Notes

• Greg in Twitter: @greg_amerson – if you like this topic, you should follow him!
• Liferay IDE – which Gregg currently works on.
• Greg previously worked at Genuitec on many of their popular Eclipse based products.
• Eclipse PDE – where it all starts.

Transcript

As usual with these un-sponsored episodes, I haven’t spent time to clean up the transcript. If you see us saying something crazy, check the original audio first. There are time-codes where there were transcription problems.

Michael Coté: Well, hello everybody! Here we are in lovely Anaheim, California or technically I think it’s Garden something.

Greg Amerson: Garden Grove.

Michael Coté: But whatever, we will call it Anaheim. As someone who lives in Austin and someone who lives in Dallas, pretty fantastic weather. With that meteorological note, this is another episode of ‘make all’, I think it’s 10. Anyways, it’s ‘make all’, the podcast about fun and interesting stuff in the software development world and things going on with those damn computers.

As always, this is your host, Michael Coté, available at peopleoverprocess.com, and I am joined by a guest while I am here at the Liferay West Coast Symposium. I found the Liferayer, if that’s what you guys call yourselves, who basically is the one-man team for the IDE at the moment.

Greg Amerson: A tooling expert, I guess.

Michael Coté: That’s right. Why don’t you introduce yourself?

Greg Amerson: Well, thanks Michael. My name is Greg Amerson, and like you said, I am based out of Dallas. I work for Liferay. Since about February, came on board there. Previous to Liferay, I was working for Genuitec, makers of the MyEclipse product line, worked for 00:58. Was their first full-time developer actually back when they started seven years ago, and kind of cut my teeth in their organization and did Eclipse plug-in development for about six years. And then found out about Liferay, found out about some needs they had, and some life opportunities I would have coming and working for them, that worked for me and my family, and made the change, and now I am the Eclipse guy.

So my day is, I do Eclipse plug-in development by day and then I support everybody that uses Eclipse. If they have got some weird Eclipse bug, I will try to help them out, because if there is some weird esoteric problem in the platform, I have probably dealt with it. They enjoy having the Eclipse guy on staff.

Michael Coté: Right. Yeah. After seeing you give kind of a presentation of updates to the Liferay IDE the other day, I was thinking — and with the background you have, I was thinking, like it would be a great opportunity to just kind of discuss what it’s like building a tool in Eclipse, if you will, building an IDE, which is — I mean, there is actually lots of content out there and everything, but anyways, it would be a fun and interesting thing to discuss.

I think what that kind of — my currently overused analogy, those bumpers in the bowling alley, the guidelines there. I am kind of going in here blind, like I don’t really know exactly how you would answer this question, but that’s why you are here.

So if I like sat down one day and it’s like, alright, I am going to write an IDE for my whatever, a chuck of middleware in Eclipse, like what are the things I would get, like how would I start bootstrapping into that?

Greg Amerson: Sure. Well, the easiest thing to do — now, the first thing is you have got to get the right download. So Eclipse has kind of morphed over the years. It used to be, it was, if you came to the Eclipse site, you were looking to build the tool on top of Eclipse, you weren’t coming to look for an IDE, or you weren’t coming to look for web tools, CSS Editor. You were coming to look, I want to build the tool, I would rather use the Eclipse platform to build that tool.

So you would go there and the first thing you downloaded was the SDK. Now it’s kind of changed, you are there, you are downloading and the end users —

Michael Coté: They have it packaged into the galaxy names there.

Greg Amerson: Right, the galaxy names.

Michael Coté: The astronomical names.

Greg Amerson: Right. Cosmology names and so —

Michael Coté: There you go, cosmology names.

Greg Amerson: So that’s what you get. You can still get it, it’s just a few links now, but that’s — you will need to start with the SDK, and what that gives you is different from what you expect with the Eclipse, because Eclipse is known as the best Java environment out there or open source Java environment.

So what you have now, you have to get the Eclipse SDK, which is essentially a few release engineering plug-ins, but the big part is, is the PDE, the Plug-in Development Environment. If you have that installed, it’s simply a perspective switch. So your first day sitting down, you switch into the Plug-in Development Environment perspective and then from there, you don’t create a Java project, you create a plug-in project, which is just a Java project with some more metadata, some additional editors and validators, because you are going to be editing an XML file, plus your OSGi manifest settings.

Then you just kind of — you pull down some examples. You can use any of the Eclipse source that you want to, to take a look, or you can read a tutorial, how to do my first plug-in, how to contribute my first wizard and my first view or whatnot.

Michael Coté: I assume you are basically developing in SWT, right?

Greg Amerson: That’s true. You have to — so traditionally, since way back when, it’s changing now in e4, which we will probably talk about that a little later, but it was, if you were going to do any UI work, it was done using the SWT framework. Eclipse has got its abstractions on top of JFace and whatnot, but essentially, at some point you are going to be swinging some low level GUI code that’s a little bit from a Swing developer, like I was, originally coming into SWT, there were a lot of orientation switches I had to make, because SWT kind of has to follow the more OS pattern of things of, to build a widget, the widget has got to know its parent first, whereas Swing, you could build your widget and then throw it into whatever container. SWT, it’s the other way around.

(00:04:58)

So after you get used to that and kind of figuring out the idiosyncrasies there, you can be pretty proficient. Mainly because of the wealth of community documentation snippets, there’s hundreds of SWT snippets out there, so if you are looking on how to do a sortable tree table, somebody has written it, there’s some drop in and —

Michael Coté: Yeah. I mean, Eclipse especially is an IDE environment, as PDE stuff has been around for a long, long time.

Greg Amerson: Right, because of the dogfooding, right? So they had to — I think that’s why the Java Editor was so good, because the Eclipse guys, I mean, I wasn’t around at the beginning, the 1.0 days, but I imagine they were like, we have to build this platform, build this platform in Java, we need a really good Java Editor, we need a really good PDE. I really think that’s where the plug-in development shines.

I have developed a little IntelliJ and a little bit of NetBeans plug-ins, not enough to really comment on the whole ecosystem there, but I do know that the Eclipse plug-in development, what they allow you to do with the self-hosting and the hosted Workbench, so essentially when you make your changes, you have got my plug-in A, my plug-in B. You launch another copy of the Workbench and do some very sophisticated class path wizardry, whatever changes you have made in those plug-in, so then the new copy of the Workbench is everything you had before, plus just your changes and any overrides you make.

And what’s really beautiful and what I enjoy the most is, I think of Eclipse, a tooling guy, that’s riding tools on the Eclipse platform, it’s a little bit like a treasure hunt, because anything you want to do has been done, it’s just a matter of where has it been done, and let me go find that, and see how they did it, and be like, oh, okay, that’s how you do it.

Michael Coté: So there are sort of numerous pet shops that you can go and base things off.

Greg Amerson: Numerous pet shops that you can go. So you can go through the bazaar of different things that have been done, like a little of that, a little of that. And when I worked with Genuitec, those guys were unbelievable at their ability to consume large amounts of open source code, figure out what dots to connect, weave those together, package that in as a nice robust user experience that’s bug tested and fixed, and a lot of the real sharp corners rounded off, they were really good at that, still are. So I really enjoyed working for those guys.

Michael Coté: So when you are going on this treasure hunt, if you are like — I mean like, what are the — typically in the work you have done, kind of like what are the first sort of, I don’t know, features that you build into your tool?

So let’s say you have got middleware framework run-time X and you are going to build the tool for it, like what are the kind of the first task or I mean, what do you even call that, like when you are sitting down, you are like, alright, here’s the feature I am going to build. Like I am going to build something that lets you edit a config file, or I mean, kind of what are the common things that you start building for some chunk of middleware you are tooling around?

Greg Amerson: Sure. Well, usually I follow the platforms laid here. And what they will usually do is split every feature into core things that are non-UI based, and then — so that they can unit test it and things that are done on the UI; strictly UI based and kind of pull those over in a different bundle.

So what you will generally do is, if I am going to build editor X, Y, Z for my run-time’s specialized config file, I will create a plug-in and then I will start looking for extension points. I will start figuring out where in the platform am I going to plug-in. So am I going to plug into the project facet framework, which means in these projects, Eclipse has these highly configurable projects, well, one little bit I want to flip is also in this project, can have my run-time’s X, Y, Z file in it. So I need to be able to attach to that project metadata, hey, this is a project that can be a host for my X, Y, Z file.

Michael Coté: Right, right. So you are sort of describing the kind of declarative stuff that’s involved in the wider —

Greg Amerson: Exactly. So I declare, hey, I want to be a participant in project structure, I want to be a participant in deployment, I want to be a participant in content. So across the platform there is this notion of content types, and XML, JSP, whatever, and then on top of XML, you can create your own and say, not only am I an XML, I am a specific kind of XML that has a certain scheme.

Michael Coté: Like a Liferay configure file.

Greg Amerson: Like a Liferay configure file. So that’s exactly what I did. I went in there and I said, okay, I am going to contribute a new content type that is specific to Liferay deployment descriptors, and then with that — so that’s in the core and then on the UI side, I will say okay, I am going to bind through that content type my specialized editor and it will contribute additional features that the platform doesn’t have.

Michael Coté: And then the end result is like, so if you are in the File View or the Tree, or whatever different perspective or whatnot you are in, you click on that configuration file type and it would open up the editor, the special editor that you —

Greg Amerson: My editor. You can set it as a default, you get a little icon. You are able to brand, hey, these are my parts that I am controlling, and Eclipse has provided historically — I mean, it’s ever more ability for a tooling provider to customize experience for their run-time. It’s amazing, doing as long as I have done it from the 2.0 days now, to the 3.6, going in the 4.0 days, just the level of control you can have. It’s just, every release is more. Even with the e4 stuff, it’s — the door is going to be blown wide open even more.

(00:10:08)

So back when I was working at Genuitec, we were constantly — since we weren’t tooling provider-specific, we were trying to be broad, we were trying to customize large areas of the Workbench.

In the old 2.0 days, you can only do an IDE extension. I mean, Eclipse only wanted to be an IDE, and that’s all it had been. And then starting around the 2.1, going into the 3.0, they started saying, hey, I remember Genuitec, we were building RCP apps and stripping out plug-ins and taking it down to its bare metal, and other people were doing it too. And the platform responded with the RCP framework that’s sitting there and said, okay, I see what you are trying to go at, you don’t want all the IDE stuff, you may not even want Java.

Michael Coté: You just want different components.

Greg Amerson: Yeah, I just want just this little piece. And of course that was helped by the OSGi adoption in 3.0. It was pretty painful, being a plug-in developer from 2.1 to 3.0. I think they went through, I don’t know how many milestones, but I can remember at Genuitec, every milestone would just break all kinds of stuff, and they were upfront about it. They were saying, hey, this stuff is going to break.

Because back then you had to do — to do anything powerful, you had to get way down deep and touch things that maybe you shouldn’t have been touching in. So when the platform would change, it took some significant effort. But nowadays, it is really no sweat. Those guys on the platform team have stabilized it so well, you can go 3.4, 3.5, 3.6, unless you are doing something really crazy, with very little disruption at all.

Michael Coté: There’s not much — the backward compatibility —

Greg Amerson: No, it’s not much turn —

Michael Coté: Or I guess forward compatibility.

Greg Amerson: Not much turn at all, it’s really amazing what they have done kind of post 3.2, it’s a great time. Of course they are about to — with e4 coming out, they are kind of going to upset the applecart a little bit.

Michael Coté: For people who don’t know, can you give kind of like a quick overview of what’s going on in the e4 world, like what does that mean, e4?

Greg Amerson: Sure. I am not a — I know Eclipse has published a few webinars and podcasts about it, so I am not an e4 expert, I have just downloaded the new preview release and stuff. But I do know as a tooling guy, the guy that’s built plug-ins, 2.0, you had to be an IDE, you had to do it the Workbench way. In 3.1, 3.2, 3.3, 3.4, you could kind of break out, you could define new structures, but there were still some assumptions always in place, like you are always going to have an edit area that’s in the center. So views couldn’t be in the same as an edit area, they were always separate.

Michael Coté: You had to have structural ethos assumptions, this is what you are going to do with this platform, something that’s involves editing something.

Greg Amerson: Editing something in some contributing views, that was still deep down in architecture, and if you tried to deviate from that at all, you had severe problems. I mean, you could — I know at the last project I was on in Genuitec, the mobile tools, what we were trying to do, the platform just simply wouldn’t let us do. It would not let us have a rich, kind of a RIA experience of editors and views overlapping stuff, it just was not possible. We worked on it, we spent a lot of time, some really smart guys looking at it, and it wasn’t possible.

With e4 what they have done is they have said, okay, we realize that the architecture that’s been kind of baked in over the last ten years is not — the application architecture is not the same for everybody. So in e4, they have completely stripped that out and made it its own model. So the application architecture is modeled.

And then all of the platform services are there to support that, but you declare, declaratively once again in an XML file, what my model is going to be, I want these windows, these actions, these views, and they have kind of torn away some of the assumptions; views can live next to editors and you could edit inside of view, and all these things. In other words, they have really kind of — they have kind of torn down some of those old edifices that they had in there.

Michael Coté: So when you are looking at kind of scoping out the work that you will have to do eventually, like when — I don’t know, how are you kind of arranging in your head when you are going to start doing e4 stuff, if you will?

Greg Amerson: It’s a good question. So the good news is that any plug-in I do for the 3.x, it’s going to — there will be a compatibility layer in there. The Eclipse guys bend over backwards to make compatibility layers. I think there is still probably some 2.1 compatibility stuff in there. Maybe it’s deprecated, don’t quote me on that, but I think it’s still in there that you could make a 2.1 stop plug-in and it would still run.

Michael Coté: Yeah.

Greg Amerson: So I suspect any three — if you are currently working on 3.x, 3.5, Galileo, Ganymede, you are going to be fine in e4, but the good thing is, is that guys that — like the guys at Genuitec, they were trying to break out of that mold and do things completely out of the box, that’s going to be a new platform.

Now, it comes with the tradeoff, you have got to become a model guy. A model guy is kind of — I am not a model guy, to be honest, I have MBA, I have always kind of kept away from it.

Michael Coté: I have noticed, and it’s one of my like interesting side notes that there is a very strong modeling sub-community in the Eclipse world.

Greg Amerson: Oh, some huge subcultures, yeah.

(00:14:59)

Michael Coté: And I always get the sense that there is a lot of — over here in the States, for whatever reason, we are kind of like a anti-model, where there was the whole UML thing that happened, which I think for a certain generation of programmers who kind of came up or were after that, it makes them not like boxes and arrows, but on the other hand, over in Europe and other places, it seems like they are model crazy. So there is — I don’t know, it’s interesting, it’s kind of a cultural thing that there is a huge, just people who love models and people who think models are like death.

Greg Amerson: Right. It’s really your point of view and perspective. I know, my experience, when we would run into models, we would fine that they weren’t flexible enough at the time, and because of the generated nature of some of the codes, you couldn’t change the thing that’s downstream from the model, if the model is not flexible enough on its own.

That kind of goes back to, let’s say, I do run into something in the Eclipse platform that is not what I like, what is my freedom or flexibility to be able to change it? As a lightweight tooling provider, I am just going to contribute some plug-ins that go into your system, there is not much you can do.

But if you decide to kind of say, okay, I am going to provide my customers an all encompassing product, my own branded Eclipse, then you are going to have a lot more freedom to say, okay, if the core of the platform is not behaving like I want, or there are some assumptions that are incorrect for my business or my tool, you can go in and change it. Then you have all that power and flexibility, there are some tradeoffs there too, because if somebody wants to install a plug-in into your customized version of Eclipse, that’s not compatible with what you changed.

Michael Coté: Yeah. That’s actually one of the things I wanted to ask you since you have worked on so many toll things is when — and this may not necessarily be a technical thing, but when do you make that decision to move from being a plug-in within Eclipse to subsuming the whole thing, kind of taking, hijacking, if you will, all Eclipse?

For example, Adobe’s Flex Builder or Flash Builder as they call it now, it’s definitely not a plug-in, it’s like the whole thing.

Greg Amerson: Aptana, those guys?

Michael Coté: Yes. There are several people who do that kind of thing. I mean, what’s the thinking you have gone through in the past when you make that jump between the two?

Greg Amerson: Well, for us it was all about customer experience and they — we weren’t going to let some platform concern reach up and hurt a user’s productivity. It was almost, we would wait till the very last bit, but if it was keeping us from delivering a feature to the user, we would — at Genuitec, and as I lead the team at Liferay, we will bite the bullet and go ahead and make that platform change and suffer those consequences.

We found that we always would err on the side of delivering to the one customer that is looking for that tool, and then dealing with ramifications that, well, you just broke X, Y, Z user, because he has got — he has merged your product in with a completely different, maybe incompatibles.

Michael Coté: And that seems like the major consequences, if you grow beyond your plug-in bridges, as it were, basically the problem is, it’s a lot more difficult to include other plug-ins if you wanted to.

Like we were talking about Mylyn last night. Like if you wanted to add Mylyn in, like it might be harder, or I don’t know if it’s even possible, but you could definitely shut out being able to add in all the integrated Eclipse things.

Greg Amerson: Exactly! So there is a cost, and it’s a case — it’s almost — it’s one of those things that you always maintain both versions. You never want to plug yourself in to one or the other. All companies will have, here is our productized version, that’s fully customized, and we have taken control of everything. Here is the version that is — that’s just a plug-in and then there is — you give them a list of what they can have as a plug-in and you kind of let them make the decision. This is what I have to trade off.

But yeah, it’s a great time to be a plug-in developer. I mean, the OSGi development is — after you get used to it and kind of figure out what it’s all about, there are a lot of powerful things you can do.

Michael Coté: Sure.

Greg Amerson: The modeling tools that are in Eclipse are just unbelievable what you can do. There is a way that you can do it, and I am not familiar with it, I am actually starting to look into it for Liferay, but you can take an Eclipse model, an EMF model, and then you can use this graphical modeling framework tooling and you can merge the two together and it can just spit out a graphical WYSIWYG editor on the other side.

Michael Coté: Yeah. I have done a couple of screencasts with various things like EMF and other components over the years and there is — you are always in the lookout for that flexibility, like you were saying, but it does seem like there is a lot of niceness in, whether it’s with EMF or the other kind of model driven stuff in Eclipse, where if you kind of understand the model, you can just kind of attach to that one point in the model.

You can do the classic OO or Object Oriented kind of fantasy land of like, I just write these five lines of code and suddenly rainbows, everything is different.

Greg Amerson: Yeah, there is a lot of truth to the fantasy aspect of that. Sometimes it just doesn’t work out that way, but –.

(00:19:57)

So I am getting more into the modeling now, because I am a one-man shop, and I need my lines of code to go further. At Genuitec, we would always — part of it was a legacy, historical thing, when we built all of our tooling over there, none of that existed yet, or at least it was in a form that was really hard to use, so we kind of had to build our own things; so project structures, wrappers, and Visual Editors and stuff. I am amazed at what’s available now, visual. It’s actually surprising to see Eclipse pushing so far into the RAD and visual stuff as a platform.

Michael Coté: Yeah. That’s kind of a missing part of the tooling world nowadays. I mean, there is a few people who kind of fill in the RAD gap, but it doesn’t really exist so much, which is kind of interesting.

We were talking about this last night too, like I kind of feel like, this is all theory on my part, but I feel like the PHP Web World kind of came around and somehow, I don’t know, it took away that like a right-click sort of program that existed. I mean, RAD development had carved out a nice niche for itself, which isn’t so much, I don’t know, it’s not around so much anymore

Greg Amerson: It’s there, but nobody is blogging it, nobody is 21:07 were just plugging away at their ten-year contract software parts that — and they are happy, because when they do make that config file, they have got that nice rich UI to help them out as opposed to saying, well, what was that file we had, XML setting we had to flip?

I think it exists, but it’s just not the hot stuff, it’s not what’s making headlines.

Michael Coté: Yeah. It seems like the mentality is to kind of start with a bunch of plug-ins and build your own thing. I mean, despite the success of Genuitec, for example, which is definitely not that. It’s kind of, you solved that problem.

That was the kind of the last thing I was interested in talking about is like what — it’s kind of — one phase of what we were just talking about there is, what types of developers do you see sort of like using the Liferay IDE? For example, we were talking about, there is like the Spring IDE, and Oracle has an IDE for their WebLogic VDA stuff, and it’s interesting to see — you have got a general purpose IDE, like the way you would download with whatever Eclipse version, versus a specialized sort of IDE, and I don’t know, what kind of users are you seeing using those different — those specialized things?

Greg Amerson: Well, definitely new users, users unfamiliar with the platform, people that are wanting to discover more of what’s capable. I think one thing the Liferay IDE could provide to Liferay users is just exposing what’s possible. I mean, did they know that there is a way that they can gzip their JavaScript, all the JavaScript file, if they set a setting in the XML file? There is not a document anywhere, but an IDE could bring that setting forward. I mean, that’s something.

And then also from a best practices architecture thing, IDEs are great for helping a guy that’s not an architect, that isn’t a 22:56 that can architect these systems in the —

Michael Coté: It sort of automates the architecture.

Greg Amerson: Automates the architecture using best standards and things we have learned and all the — taking feedback from partners and trainings and stuff and saying, this is the way you have got to set up projects.

So I think that’s — so it’s almost the — individual development, I mean, yeah, it’s kind of — it can have its ups and downs, but I think maybe the meta structure of things, what is a Liferay instance all about, it’s more than just projects, its runtimes and SDKs and various deployment settings. So I think IDE has a chance to help corral all that into one way.

And I also see it providing a lot of value to Liferay’s partners and Liferay’s training partners in training itself. So we were speaking earlier about how when a Liferay partner goes in to do training now, or a Liferay customer goes into a training, they have paid hundreds of dollars for, they spend the first half day doing environment config and set up, it’s not any value at all.

With the IDE, they unzip one file and they can literally be working on the first portlet in seconds, not hours. So I think that’s one obvious value that we can provide. Whether they use it and roll the IDE out in their entire environment is maybe a different story. I hope that they do, I hope that we can solve the problems if they need, but if they don’t, I think we can still provide some value.

And the fact that we can provide value and can have just a small team is because of what’s possible in Eclipse and how much you can get for essentially nothing. What is out there in open source, 40 million lines of code, I think, or maybe even more than in the latest release of the — train release that’s out there, that you can just build them on top of, just customize your parts. It’s pretty compelling.

Michael Coté: Yeah. I mean, it’s interesting, its definitely evolved as like a milestone of maturity for any given, whether it’s middleware, runtime, or whatever, some sort of Java based thing to have kind of like an Eclipse base tool that goes on with it.

(00:24:51)

Greg Amerson: Right. It’s a sign of maturity. I know one of the reasons that the Liferay guys brought me in is, is their customers were looking for stability, longevity, you guys are really behind this platform, and they can have the greatest developer features in the world, I mean, unbelievable extensibility, some of the stuff they have demoed here at the Symposium, but it’s almost like, if there is not some pretty wizard to help you do it, it doesn’t really exist.

So it’s almost like you need to build wizards that people are never going to use. But they see them and they say, oh, yeah, of course, you can do x, y, z, because I see there is a wizard for it, so you must be able to do it.

So kind of like we were talking yesterday, a lot of that UML — you build the UML tool so that no one will use it, but they know the UML tool exists. So we found a lot of that happening at Genuitec.

But the one thing that — so hats off to the platform about what they have made for the individual plug-in developer or the team. There are some areas that I would like to complain, and that’s about the builds, release engineering. You are pretty much on your own, and it’s pretty much a wild, wild west scene there on, okay, I have got my plug-in, it’s working great in my environment, how do I get this to people, how do I give it to people?

Michael Coté: Oh, how do you distribute it out there?

Greg Amerson: Distribute it out, yeah.

Michael Coté: Over the years that has been like a pain point.

Greg Amerson: Oh my goodness, yeah!

Michael Coté: Nowadays we thankfully have the concept of an App Store or whatever, and you guys had Pulse at Genuitec, right?

Greg Amerson: Right. At Genuitec we had Pulse and that solves a lot of those problems. It really helps out —

Michael Coté: Didn’t Eclipse launch something recently that was kind of like a —

Greg Amerson: They have an Eclipse Marketplace Client, which is kind of like the free version of Pulse. I mean, connect you up to all the open source things that are out there on the Marketplace. The Marketplace is a great thing they are doing.

So there is commercial companies that have solved the provisioning, installation side, and of course Eclipse gets you this far, but it’s that part in the middle, like I have got my plug-in, there is a way to get that to the customers, but all of those systems that help provision out to the customers assume that it’s already in its final form, signed, built on an update site, but how do you get to the update site? This is a personal sore spot for me, because that’s what I did for five years at Genuitec, I was — wore many hats at first, and then I became like the release guy. Oh my goodness, it was —

Michael Coté: It sounds like you kind of would like to be able to put alphas and betas and stuff like that and kind of have the equivalent of, like in Linux you have package management, which kind of allows you to — and the command might go and basically very quickly type out, like update all my software, and then also, get me this version of the software.

Greg Amerson: Or build it if it doesn’t exist, pull it from source, build it. That’s the piece that I know Eclipse is trying to solve it. There has been many build projects. Out of the box you have PDE Build that helps you go from plug-ins in your workspace to something delivered to the customer. But that was really hard to use.

And then another project came along, it’s what we use at Liferay IDE called Dash Athena. And that tried to just basically bull down 20 Ant scripts into one .properties file, and say, just set some settings and we will go manage the 20 Ant scripts.

Then something came along — and then the Maven guys got involved, because the Maven guys started doing plug-ins, and they were like, this is no good. So they actually wrote — and then there is the Tycho project, so now Maven can build Eclipse plug-ins and they can output OSGi bundles. So that kind of — and then there has been a new Build project in Eclipse called b3, which — it’s kind of a playoff of p2, their new update deal.

So b3, from what I understand is like, okay, we hear you community, the build in Eclipse doesn’t need to be so wild, wild west anymore, we are going to —

Michael Coté: Standardize it.

Greg Amerson: Yeah, we are going to standardize it, make a model, then different people can implement that, kind of like — but it’s basically trying to make that concrete, what does build look like in Eclipse? You have got your plug-ins built, you have got your provisioning figured out, if you have got an update site, but how do you get it from my workspace to my update site, so that customers can install it, and that —

Michael Coté: I mean, the goal there is like — I mean, if you are going to be building a tool in Eclipse, you should be writing the tool and not worrying about the build.

Greg Amerson: Exactly, exactly. I mean, the time I spent in my last job, and even now, it’s just time that — nobody pays for that stuff. It’s like they pay for the features, they pay for you to help me manage my provisioning, but they are not paying for you to get them compiled, and it’s essentially what you are doing, that’s just something that should just happen.

So that’s one area I really hope to see some improvement, and I think there will be. I mean, the platform has responded in all the other areas; e4 being the best example of those guys saying, no, we are going to not be obsoleted by these new flashbang browser-based frameworks.

So I hope to learn more about e4, and not look at what it takes to build an e4 plug-in, if this is just exactly the same as it has been in 3.x.

Michael Coté: I mean, it has been sort of cooking for a while now, and probably in the 2011 Eclipse Con, I am sure they will talk about it a lot more, I would think they would.

Greg Amerson: Should be a big topic.

(00:29:56)

Michael Coté: Yeah, yeah. Well, great, well, I mean that was exactly the kind of overview of stuff I was looking for, I mean unless there is anything else you wanted to throw in.

Greg Amerson: No, that’s pretty much all I had.

Michael Coté: Well, for the listeners who have listened this long, which we always appreciate, actually listening to everything, actually one of my old online friends, if you will, Alex Miller, who kind of runs around in the Java world, if you will, I don’t know if he is putting on this conference or if it’s him and some other folks, but whatever, there is this conference, he calls it the Strange Loop Conference, and it’s up in St. Louis, where I have never actually been, it’s October 14 and 15.

And it sounds like, from the description he has, it’s basically like going over kind of some emerging languages, kind of in the — I don’t know if it’s restricted to Java or whatever, but he was saying there’s like Closure and Scala and things like that, and some NoSQL stuff, but it looks like it will be kind of a fun, very developer nerdy conference.

He has got like Guy Steele, who, you may remember, I don’t know if it’s Gee or Guy, who knows, but you may remember from the, I don’t know, the Java Spec and other stuff, kind of speaking and things like that. He gave me a couple of free passes. So if you want to get one of those free passes, I have only got two left, but if you are really interested in going, just send me an email at [email protected]. We should think of some sort of contest, what should be the — do you have some sort of trivia question that’s not too onerous to look up?

Greg Amerson: Trivia question, let’s see.

Michael Coté: How about like something like, who were the last project leads on the p2 or the b4 or something like that, go do a little look up of Eclipse things or something like that.

Greg Amerson: Right, that would be a good question, or who is the lead developer of PDE or who is the lead developer of —

Michael Coté: There you go. So here we have been talking about PDE a lot, whoever the lead developer of PDE is, I am sure it’s easy to go look up, right? Just go look that up and the first two people or one, if there’s only one successful one, that emails me that at [email protected], I will send you the code to get a free pass to that Strange Loop Conference, which unfortunately, they won’t be able to go to, but I would if I was available.

So hey, thanks a lot again for going over this stuff.

Greg Amerson: Thanks a lot Michael.

Michael Coté: And we will see everyone next time.

Disclosure: while Liferay is a client and paid my expenses to their symposium, this is not a sponsored podcast. The Eclipse Foundation is a client as well.