All about Java
Ed Merks, Cedric Brun (Obeo), Sebastian Zarnekow (itemis)
Abstract:
The Eclipse Modeling Project is one of the most active projects within the Eclipse community. Ed Merks will give a quick overview of the Modeling projects …
Kenn Hussey (Cloudsmith)
Abstract:
The Eclipse Modeling Framework (EMF) has long provided a code generation facility capable of emitting everything needed to get started with building a complete application for EMF-based do…
Ian Bull (EclipseSource)
Abstract:
Ian Bull, component lead for Zest and the Eclipse Visualization Framework and committer on the Equinox p2 project, presents the top 10 features in Helios he is most excited about.
This p…
Eclipse Committers
Abstract:
The Eclipse Foundation is presenting Helios In Action – a virtual conference where you can interact with project leads involved in the release and see demos of the new features. The annual simul…
Ekkehard Gentz
Abstract:
redView (Riena EMF Dynamic Views) uses technologies from Eclipse Modeling and Eclipse Runtime to ease the development of Business UI (SWT). If you’re new to redView, this webinar will help you to …
Eike Stepper, Ed Merks
Abstract:
Are you already modeling and generating your applications with the Eclipse Modeling Framework (EMF)? Great! So you are already enjoying automatically generated model-based runtimes, structu…
Sven Efftinge (itemis), Jan Koehnlein (itemis)
Abstract:
On June 23, the new Xtext version 1.0 will be released as part of Eclipse’s annual release train. During the last year Xtext has grown from a tiny DSL editor generato…
<!–
–>
Are you already modeling and generating your applications with the Eclipse Modeling Framework (EMF)? Great! So you are already enjoying automatically generated model-based runtimes, structured or graphical user interfaces, XML serialization and so much more.
But what if…
The Connected Data Objects (CDO) model repository and distributed shared model for EMF delivers solutions to these challenges and more. CDO is a component of the EMF project and has been successfully adopted by many companies and organizations. Join the webinar and learn about the CDO Model Repository and its new 3.0 features!
Total running time 1 hour, 02:18 minutes
Thanks to Adobe for contributing their Adobe Acrobat Connect product to host this webinar.
delicious | 
digg | 
dzone
<!–
–>
Event Date: April 29, 2010 2:00 pm GMT-8
<!–
–>
Are you already modeling and generating your applications with the Eclipse Modeling Framework (EMF)? Great! So you are already enjoying automatically generated model-based runtimes, structured or graphical user interfaces, XML serialization and so much more.
But what if…
The Connected Data Objects (CDO) model repository and distributed shared model for EMF delivers solutions to these challenges and more. CDO is a component of the EMF project and has been successfully adopted by many companies and organizations. lJoin the webinar and learn about the CDO Model Repository and its new 3.0 features!
Total running time will be approximately 1 hour
7:00 am PDT / 10:00 am EDT / 2:00 pm GMT – Convert to other time zones
Thanks to Adobe for contributing their Adobe Acrobat Connect product to host this webinar.
delicious | digg | dzone
<!–
–>
Adobe Ajax Android Anwendung Apache API C++ Community Developer Eclipse Eclipse Foundation Embedded English Enterprise Entwickler Equinox Galileo Google Handy IBM IDE Individual Java Member Microsoft Mobile Modeling NetBeans News Open …
I landed on a few articles about “UML in Colors” lately, I enjoyed reading those as modeling is used here as a design tool and support for efficient communication. It also made me think : that’s a nice use case for our extensible modeling environment !
Recently, we received some bug about EEF for the library sample of EMF. After some fixes, EEF works for this metamodel. So I took 5 minutes (yes 5 minutes ! ) to make a demo about this sample.
The important thing behind this demo is the entire EEF process. You have all the steps needed to use EEF in the EMF generated treeviewer. Enjoy
Let’s assume for the moment, that in an alternate reality I can travel back in time to 2008. Once there, I meet a bright bunch of people that work on something called e5 (executive summary.odp). My summary:
“the runtime platform that is simple and appealing to _____ application developers”
Here’s what I would say to them:
When I became interested in Eclipse it was cool and disruptive. A real game changer. It is now the established tooling platform and understandably locked into perpetual refinement mode (Entrenched Player’s Dilemma). Make sure that e5 is equally game changing. Otherwise we are setting ourselves up to be disrupted.
At the EclipseCon 2008 we committed a “strategic sin”. We agreed that e4 would be compatible with 3.x. This limited the potential for e4 by forcing it to be something that is “in the box” vs. “outside the box”.
(taken from Death by risk-aversion by Kathy Sierra)
For e5 to be successful it needs to take risks. I don’t think that we need a better tooling platform. We already have a very good one with 3.x. And it’s still improving and not going away. Instead we need a runtime that provides something unique and remarkable. It must kick-ass in a new way.
If you try to be everything to everybody, you will at best be mediocre at everything. e5 should be laser focused on being the best runtime for ___________ developers.
People tend to avoid specialization. It is perceived as a risk. However, if you ask a marketing person he / she will tell you that specialization is good. It’s your way to get noticed. It’s your foot in the door. You build a niche, become unbeatable and expand. Eclipse 3.x first became the tooling platform of choice, then client platform of choice for Java devs, then the modeling technology of choice for Java devs.
Unfortunately e4 lacks a driver that would help it specialize and focus. A driver, like the JDT was for the Platform. As far as I know, there is no major product build on top of e4. I believe that the current e4 (Feb 2010) is not yet appealing enough for web development or client development. It will not lure web-side Java developers away from Spring / J2EE / GWT. Or client-side Java developers away from RCP. Or Javascript folks away from jQuery / Prototype / Dojo. Or Rubyists away from Rails.
It is hard to pick the right driver. I don’t want to attempt providing an answer and limit your thinking. But feel free to share your thoughts in the comments.
If you believe Eclipse 3.x is easy to get into, attend a beginner’s training. You will see how experienced Java developers struggle with the learning curve. And it’s not becoming easier with e4.
That is a problem, because it limits the mass appeal of Eclipse as a runtime solution. If you think it is a popular runtime, go to a Java User Group and see how few of the people who use Eclipse have written a plug-in for it.
It is in our human nature, that we tend to take the path that has the least resistance (read: easy) not the path that offers the most rewards (read: complex technology).
For e5 to be broadly successful it must kick-ass AND be easy to learn & master.
Looking forward to your comments,
Elias.
UML has been getting a lot of criticism from all sides, even from the modeling community. Sure, it has its warts:
However, even though I see a lot of room for improvement, I still don’t think there is anything better out there. The more I become familiar with the UML specification, the more impressed I am about its completeness, and how issues I had never thought about before were dealt with by its designers. And it seems that the OMG recognizes some of the issues I raised above as shortcomings and is working towards addressing them. Unfortunately, some fundamental problems are likely to remain.
In my opinion (hey, this is my blog!), for a modeling language to beat UML:
My suspicion is that the next modeling language that will beat the UML as we know today is the future major release of UML. Honestly, I would rather see a new modeling language built from scratch, focused on building systems, that didn’t carry all that requirement/communication/documentation-oriented crap^H^H^H^Hbaggage that UML has (yes, I am talking about you, use case, sequence, instance and collaboration diagrams!), and developed in a more open and agile process than the OMG can possibly do. But I am not hopeful. The current divide between general purpose and domain specific modeling communities is not helping either.
So, what is your opinion? Do you think there are any better alternatives that address the shortcomings of UML without imposing any significant caveats of their own? Have your say.
Ein Proposal für das neue Eclipse-Projekt Sphinx steht zur Einsicht bereit. Unter das Model-Development-Tools-(MDT-)Projekt eingereiht, soll Sphinx eine erweiterbare Plattform für das Bauen integrierter Modeling-Tools-Umgebungen bereitstellen. Ein …
Needham, MA, USA and Ottawa, ON, Canada – February 3, 2010 –
OMG™ and the Eclipse Foundation have issued a Call for Participation for the 2nd
Biannual Symposium on Eclipse Open Source Software and OMG Open Specifications to be held
June 23, 2010 in Minneapolis, Minn., USA. The submission deadline is February 24. For more
information visit http://www.omg.org/eclipse-cfp.
Eclipse is an open source community whose projects are focused on building an open development
platform comprised of extensible frameworks, tools and runtimes for building, deploying and
managing software across the lifecycle. Many Eclipse projects implement one or more OMG
specifications. This symposium follows two successful one-day events that Eclipse and OMG
jointly organized in 2008 to promote and build on the partnership between Eclipse’s open
source software and OMG’s open specifications. It will include a series of discussion
sessions on OMG standards and corresponding Eclipse projects, to facilitate alignment between
current specifications and implemented software, and identify areas where the cooperation
could be further improved in future.
Eclipse Foundation and OMG invite position papers on any of the topic areas below, or any
other area where an OMG specification relates to Eclipse software. The Program Committee
will publish all submitted position papers, and invite selected paper authors to lead
individual discussion sessions.
Topics may include (but are not limited to) the following:
The Program Committee particularly welcomes papers that deal with specific problems and
solutions that may benefit from a wider discussion than that available though Eclipse Bug
Reports or OMG Issue reporting.
Interested individuals or organizations are invited to submit a brief (up to 600 words)
position paper by February 24, 2010 using this web form (please select “Presentation”):
http://www.omg.org/abstracts.
The Program Committee will send invitations to prospective session leaders in early March
2010. The final symposium agenda and registration details will be available on March 17,
2010 and posted at:
http://www.omg.org/news/meetings/tc/mn/special-events/Eclipse.htm.
About the Eclipse Foundation
Eclipse is an open source community, whose projects are focused on building an open development
platform comprised of extensible frameworks, tools and runtimes for building, deploying and
managing software across the lifecycle. A large, vibrant ecosystem of major technology vendors,
innovative start-ups, universities and research institutions and individuals extend, complement
and support the Eclipse Platform.
The Eclipse Foundation is a not-for-profit, member supported corporation that hosts the Eclipse
projects. Full details of Eclipse and the Eclipse Foundation are available at www.eclipse.org.
About OMG
OMG™ is an international, open membership, not-for-profit computer industry standards
consortium. OMG Task Forces develop enterprise integration standards for a wide range of
technologies and an even wider range of industries. OMG’s modeling standards, including the
Unified Modeling Language™ (UML®) and Model Driven Architecture® (MDA®),
enable powerful visual design, execution and maintenance of software and other processes,
including IT and Systems Modeling, and Business Process. OMG’s middleware standards and
profiles are based on the Common Object Request Broker Architecture (CORBA®) and support
a wide variety of industries. For more information, visit
www.omg.org.
Pen-based/Tablet technology it’s been around for a long time, but recently this ‘touch-oriented interaction’ has been gaining more attention, with all the buzz around iPad. So if we’re starting to interact to devices with our hands, we are not clicking anymore — perhaps our interfaces should start to be less click-oriented? How can we take advantage of the popularity of those devices? Wouldn’t be nice if we had sketching recognition withing Eclipse?
I think so, I’ve been working on sketch recognition for GEF/GMF editors while creating the MoLIC editor, take a look:
Sketch API (former OmniModeling) on MoLIC Editor from Ugo Sangiorgi on Vimeo.
There are other posts on this blog reporting the evolution until this point — the API is able to recognize shapes the way you draw, learning withing the process if it cant recognize it upfront. It can recognize any shape, really, you will ‘teach’ it how.
Omnimodeling: Multi-Agent Recognition from Ugo Sangiorgi on Vimeo.
So it’s on! I decided to contribute to Eclipse by proposing a Sketch API for GEF/GMF using the former OmniModeling project base, take a look at the proposal we are working on. Mariot Chauvin and Chris Aniszczyk are helping me through, thank you so much guys!
Comments and contributions are welcome 
I should acknowledge Simone D.J. Barbosa for the kind support during the OmniModeling project, as well as my colleagues at the Semiotic Engineering Group of PUCRio.
As everyone, I suppose you have seen iPad videos, at least you heard about it :
I suppose you have complained about its closed platform, its single-task os, or may be its tendentious commercial name. However with such a device (a tablet), you think your GEF based editor could benefit from sketch capabilities ? Indeed that something Ugo Sangiorgi did :
OmniModeling on MoLIC Editor from Ugo Sangiorgi on Vimeo.
The good news is that it will probably be contributed to Eclipse.org. If you are interested, have a look to this new project proposal.
I don’t think you can go to school in Canada and not read Hugh MacLennan’s the Two Solitudes. So for me it was an obvious metaphor for a phenomenon that has become apparent to me over the past year or so. That is: Europeans and Americans (particularly Californians) view the practice of software development in materially different ways.
I travel a lot to both Europe and California and I talk to a lot of people about what they are building and how they are building it. In my personal and completely unscientific experience the difference between the two regions is stark. I thought it might be interesting to explain what I am observing and see if others see things in a similar way. I freely admit that my experiences could be completely coloured by sample bias (e.g. maybe I’m just talking to completely different crowds in the different regions).
BTW, some of these ideas are distantly related to Michael Cusumano’s book The Business of Software, where he points out that the US is somewhat unique in looking at software as a business. Certainly there are not that many European independent software vendors relative to the US.
It seems that most of the Europeans I talk to are focused on large systems engineering problems. As a result, they largely view software as part of a supply chain, where what they are working on is going to either be part of or in support of a systems engineering product such as an automobile or an airplane. The next largest group that I talk to are fairly typical application developers working in large banks, insurance companies and the like. But here are the interesting bits:
- Both of these groups are deeply concerned about software complexity and both are looking to modeling and model-driven development as part of the solution. They view modeling as absolutely strategic to their future ability to develop the software their customers or businesses will need.
- I also see a lot more interest in desktop applications as opposed to web applications. Just recently I had two different conversations with groups that are migrating existing web applications to Eclipse RCP desktop applications. This is not to say that Europeans don’t build websites or use RIAs! But in my experience there is a very noticeable difference in the relative interest in desktop applications in Europe.
Now if you’re still reading this, you’ve likely guessed where its going next. My experiences in the US generally and even more so in California is that the Web is king and that anything which doesn’t run in the browser is uninteresting. I also uniformly get incredulous reactions if you ask someone in the US if they’re using modeling or model-driven development practices. They’re all hacking code with small, fast, super-smart teams. It’s just a completely different world in my personal experience.
Do others have similar observations?
The challenge for Eclipse in this context, of course, is to be relevant in both contexts. I actually think that we are doing a good — but not yet great — job of doing so. Projects like e4 are leading the way to making the Eclipse platform more relevant in the Web 2.0 world. But it certainly has a ways to go. The Modeling project has a virtual alphabet soup of technologies in it, but at the moment falls short of a providing a cohesive modeling platform. Something I hope to see the community begin to address shortly.
The Eclipse Development Process (EDP) defines “incubation” as a phase that projects go through on their way to maturity. New projects start in incubation to allow the project’s committers time to familiarize themselves with the state of being an Eclipse project, give them time to start developing a following in the community, and allow them some leeway to make and correct early mistakes. Projects in incubation can make releases, but they must be pre-1.0 releases, and must be labeled as “Incubating”. Frankly, I think that incubation is a fantastic idea and intend to keep it very much a part of the EDP.
An interesting use of the incubation phase as emerged and is the topic of discussion on Bug 300000 (which sounds a little like the title of a really bad sci-fi movie): the perpetual incubator. Many mature Eclipse projects now have projects that are intended to remain in perpetual incubation. These never-grow-up “Peter Pan” projects are an excellent place to innovate, test new ideas, and grow functionality that may one day be moved into the mature project. It is a curious, however, that the very notion of an incubator project is essentially (though not explicitly) forbidden by the EDP in its current form.
With the next revision of the EDP, I’d like to acknowledge the notion of an “Incubator” project. In Bug 300000, Holger Voorman and others propose that we adopt the name “Labs” for this notion to conform with precedents set by other open source organizations. Frankly, though, I believe that we’ve already established our own precedent and intend to run with it (I’m sure you’ll let me know if you disagree).
As I see them, Incubators are operating projects that never have releases; they do not require yearly continuation reviews; and they are not part of the release train. Incubators have builds, and downloads. They conform to the standard incubation branding are subject to the IP due diligence rules outlined for incubating projects. Incubators do not graduate.
I’d like to avoid creating any new process around the notion of Incubators. I’m hopeful that it will be enough to change some of the language in the EDP (and the Incubation HOW TO document) to allow projects to simply declare themselves as an incubator and leave it at that.
Unfortunately, I think that we may have a language issue. An “Incubator” project is in the incubation phase. However, a project in the incubation phase is not necessarily an incubator. A project like Mint, that one day intends to graduate, is in incubation. The Examples and the Equinox Incubator projects never intend to graduate and so are incubator projects in the incubation phase.
Maybe it’ll help if I stop thinking about it so much.
These are heady times in Eclipse project-land. I feel busier than a… well, I’m really, really busy.
We have creation reviews pending for the Modeling Team Framework and Object Teams proposals. Object Teams is an already-established, mature project that’s moving to Eclipse. The logistics of the move are interesting enough (the project itself is darned interesting to boot). This project will enter eclipse.org under incubation, but intends to graduate with their first release; this makes a lot of sense for a project with established code base as it allows their developers time to get used to the Eclipse Development Process, but then quickly establish themselves as mature technology. There is some overlap with this project and some existing Eclipse project, but discussions are underway to see how these technologies can work together, or carve out their own unique corners.
New project proposals are flowing it at an incredible pace.
The Enterprise Modules Project, code-named Gemini, was proposed in late 2009 and is due for creation soon. This project will “provide a home for subprojects that integrate existing Java enterprise technologies into module-based platforms, and/or that implement enterprise specifications on module-based platforms.” As a start, the reference implementations for eight OSGi Enterprise Expert Group specifications will be created as subprojects. Gemini is complemented by Dynamic Enterprise Application Platform Project, Virgo, which intends “to provide a runtime platform for the development of server-side enterprise applications built on top of Equinox, and optionally using modules from the Gemini project.”
Also queued up are the Graphiti, JavaScript Development Tools, Mangrove – SOA Modeling Framework, Mylyn Reviews, and ScalaModules proposals. There are about a dozen other proposals pending that I’d love to tell you about, but will have to wait.
There seems to be no end of interest in bringing projects to Eclipse. This is very gratifying to me and I do love working with the hard-working folks involved. Parts of our process can be frustrating though, and I’m working hard to address them while balancing the important principles that define what it means to be an Eclipse project. I’ll be presenting the Eclipse Board with an overview of the changes to the Eclipse Development Process that I’m working on in mid-February. I intend to have a draft ready for presentation to the Board in time for EclipseCon. In the meantime, I’ll be discussing the changes here and in Eclipse Bugzilla. If there are specific issues that you’d like addressed as part of this revision, either open a bug or email me directly (I’m the only “wayne” at the Eclipse Foundation).
Last December I had the pleasure of being interviewed by Jordi Cabot, the maintainer of Modeling-Languages.com, a web site on all things moden-driven. We talked mostly about the TextUML Toolkit project, but Jordi also asked about my opinions on more general subjects, such as modeling notations, textual modeling frameworks, DSLs, UML and trends in modeling.
Jordi has recently made a transcription of the interview available on his web site. Take a read, feel free to leave a comment, I am very keen on discussing on any of the topics covered.
It was bound to happen: I was finally asked to be a model. I kid you not. The truth is stranger than fiction. It happened at Upper Canada Mall. Leaving a store that sells leather jackets, I was interrupted by a plaintiff “Excuse me sir, would you mind helping us out for a second.” It turned out I was just the right build to act as a model for the lady’s husband; she and two other ladies were picking a jacket for him. Being incredibly helpful and generally unable to say no, of course I obliged, volunteering my own opinion on which jacket fit best. All the while, visions of an easy life on the Paris runway just standing and modeling flashed before my eyes. But then I started to feel just like a piece of meat and I decided to keep my regular day job where looking pretty isn’t all that important.
Life continues to be far too busy. It’s pretty much impossible to balance my personal life with all the other demands on my time. I’m writing this post today from Berlin which is in the grip of a frigid winter not unlike the kind one normally expects in Toronto, so I feel right at home. Last weekend I was in Vancouver getting married. Tomorrow I head over to Munich where Peter and I present at OOP 2010; no, I will not be presenting in German though my German is definitely improving, something one might expect when you marry a German. The more German I learn—I can almost follow a conversation now—the more frustrated I am with not knowing more. This coming Thursday Ralph has arranged another Eclipse Stammtisch so I plan to attend that; I’m sure much German will be spoken. Maybe I’ll see you there. I just hope it’s not so cold.
I don’t head back home to Toronto until February 2nd, but I expect to be back in Berlin yet again for the Modeling Code Camp at the beginning of March. Itemis does trainings like this as well. It’s unfortunate that more people don’t take advantage of the opportunity to get a jump start on exploiting open source technology. It might seem cheaper to muddle through on your own but suboptimal design decisions are likely a much bigger hidden cost down the road. EclipseCon will be yet another cost effective opportunity to learn new things, and yet another reason to travel. There will certainly be a great deal of modeling content. Too bad we couldn’t accept more submissions. After EclipseCon I expect a short break in the travel schedule before I head over to Germany yet again for the JAX conference in Mainz. Maybe I should just move to Germany to save all the travel time.
Ein Projekt-Proposal für das neu vorgeschlagene Eclipse-Projekt “Mangrove” steht zur Einsicht bereit. Mit Mangrove soll ein SOA Modeling Framework als Teil des Eclipse SOA Top-Level Projekts eingerichtet werden, das existierende und zukünftige SOA …
