Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » Eclipse 4 » Developing plug-ins
Developing plug-ins [message #550482] Fri, 30 July 2010 14:02 Go to next message
Vlad Dumitrescu is currently offline Vlad Dumitrescu
Messages: 318
Registered: July 2009
Location: Gothenburg
Senior Member
Hi,

Maybe I'm missing the obvious, but I'm still trying to get all my bearings right.

The existing tutorials are targeting RCP applications. I can't find anything about developing plugins that will run in the IDE -- the PDE tooling targets 3.6 and less and generates old-style plugins...

Thanks in advance,
Vlad
Re: Developing plug-ins [message #550501 is a reply to message #550482] Fri, 30 July 2010 14:30 Go to previous messageGo to next message
Simon Chemouil is currently offline Simon Chemouil
Messages: 24
Registered: July 2009
Junior Member
Vlad Dumitrescu a écrit :
> Hi,
>
> Maybe I'm missing the obvious, but I'm still trying to get all my
> bearings right.
>
> The existing tutorials are targeting RCP applications. I can't find
> anything about developing plugins that will run in the IDE -- the PDE
> tooling targets 3.6 and less and generates old-style plugins...

As it is now, the plan is that IDE plugin developers should develop
their plugins just as they always did, and make sure they're only
consuming public API. The only difference is that they should test their
plugins against both 3.x and 4.0 if they want to be compatible with both
releases.

The "org.eclipse.e4" API is provisional and is used internally by the
compatibility layer which is a new implementation of the Eclipse
Workbench over the Eclipse 4 Application Platform. Adventurous RCP
developers can benefit from the provisional API because it offers new
and freer ways to develop apps, but there is not much to gain for plugin
developers as it is now.

By programming against the provisional API, a plugin developer loses
compatibility with the 3.x series (unless by using a 4->3 compatibility
layer), has no guarantee the model or the API won't change, and the gain
is minimal: the SDK/IDE look is not a problem for plugins, and plugins
themselves extend current bundles/features that are probably not
developed using the 4.0 API. If your plugin has dependencies which are
themselves dependent on 3.x, the interest is really limited. It can be
interesting when your plugin only depends on eclipse core/ui.

As of today, for a plugin developer, the only advantages I can see are:
* for fun, learning, etc.
* taking advantage of the new modeled UI, contexts, DI, etc, but
keeping in mind that you're forced to go back to the 3.x-style API
through compatibility for most of the integration with current
plugins/features (like JDT, Team, etc).


In the long run, of course, the plan is to have a stable 4.x API that
plugin developers code against, but some features are still missing now
so the 4.0 story for plugin developers is incomplete.

The early adopters release will allow the 4.0 team to improve the
compatibility layer by having plugin developers test their 3.6 compliant
plugins on the 4.0 SDK, and report their bugs.

If you still want to write plugins for 4.0 knowing that they'll likely
have to mix 3.x and 4.0, but still only be compatible with 4.0, with no
API stability guarantee... Well you should go for it, because the 4.x
programming model is much more pleasant imo, but keep in mind that by
doing so, you will be reaching less users today.

In this case, install model tooling, the E4 SDK and the EMF SDK from the
p2 update site already preconfigured in the 4.0 SDK ("E4 2010 updates")
and try to mix 3.x and 4.0 tutorials...

By the way, PDE doesn't "generate" for 3.6. It has a target platform,
and once you install the 4.0 bundles, you can use them and generate the
bundles using them from PDE.


Hope this helps,

Simon
Re: Developing plug-ins [message #550526 is a reply to message #550501] Fri, 30 July 2010 16:30 Go to previous messageGo to next message
Vlad Dumitrescu is currently offline Vlad Dumitrescu
Messages: 318
Registered: July 2009
Location: Gothenburg
Senior Member
Hi Simon,

Thanks a lot for the detailed answer.

Simon Chemouil wrote on Fri, 30 July 2010 10:30
As of today, for a plugin developer, the only advantages I can see are:
* for fun, learning, etc.
* taking advantage of the new modeled UI, contexts, DI, etc, but
keeping in mind that you're forced to go back to the 3.x-style API
through compatibility for most of the integration with current
plugins/features (like JDT, Team, etc).


I'm definitely in the second camp Smile I already have bothered Tom Schindl with questions about the e4 compatibility layer...

One of the main things I was after in my question, but didn't express it clearly, was about the modeled UI: I can't find out how to use that for a single view. I mean, I have a model fragment, but how do I plug it in?

I found a nice walkthrough at http://tomsondev.bestsolution.at/2010/07/09/e4-some-more-new s-from-the-modeltooling/, but the unanswered questions are:
- how do I get the "Find parent elements" dialog?
- how can I refer to (and possibly open in the workbenchmodel editor) the model for the IDE?

best regards,
Vlad

Re: Developing plug-ins [message #550534 is a reply to message #550526] Fri, 30 July 2010 17:07 Go to previous messageGo to next message
Vlad Dumitrescu is currently offline Vlad Dumitrescu
Messages: 318
Registered: July 2009
Location: Gothenburg
Senior Member
Vlad Dumitrescu wrote on Fri, 30 July 2010 12:30

- how do I get the "Find parent elements" dialog?



Ok, scratch that, I found it -- but it's empty...

regards,
Vlad

Re: Developing plug-ins [message #550542 is a reply to message #550534] Fri, 30 July 2010 18:21 Go to previous messageGo to next message
Thomas Schindl is currently offline Thomas Schindl
Messages: 5422
Registered: July 2009
Senior Member
Hi,

The problem with the find-parents dialog is that the initial
Legacy-Application model is well fairly empty because in the current 4.0
SDK 3.x informations coming through code (Advisors) and extension points
are making up the model on the fly.

Beside that I think what you really want to contribute is not a Part but
a PartDescriptor (which is the equivalent of what you contribute through
the editor/view extension point).

The relationship between PartDescriptor and Part is similar to the Class
and Object relation in Java itself. When you select a view entry in the
"Show View"-Menu the "blueprint" information of PartDescriptor is used
to the make up an Part-Instance which is inserted into the UI-Structure
of the workbench. Does this description make sense to you else I'll try
to rephrase?

Writing up informations on how to write plug-ins using the
model-fragment concept is on my TODO-List but there's simply too much
I'll have to write up (I still want to code for Eclipse 4.1 :-)

The list of up coming things are:
* Tutorial on writing your own Theme (first blog post with informations
is fairly ready)

* Tutorial on contributing through Model-Fragments to the 4.0 workbench
(as outlined above this is a bit tricky because of the implementation
of the compat-layer) - event I myself need to find out test out
things :-)

* What ever people want to know about Eclipse 4.0 and the underlying
technology

Thanks for your interest into Eclipse 4.x we are trying to provide you
as much informations and service we can with the given resources (as
stated some of us are going to be on holiday in the next weeks :-)

Tom

Am 30.07.10 19:07, schrieb Vlad Dumitrescu:
> Vlad Dumitrescu wrote on Fri, 30 July 2010 12:30
>> - how do I get the "Find parent elements" dialog?
>
>
> Ok, scratch that, I found it -- but it's empty...
> regards,
> Vlad
>
>
Re: Developing plug-ins [message #550543 is a reply to message #550542] Fri, 30 July 2010 18:28 Go to previous messageGo to next message
Thomas Schindl is currently offline Thomas Schindl
Messages: 5422
Registered: July 2009
Senior Member
Hi,

One more note. There's a demo application we are using to work out what
we need to make the new model story a first class concept.

The project is named Simple-IDE and it for example holds a descriptor
which is able to replace the editor-extension point. The current
PartDescriptor mentioned below is a replacement for the view-extension
point because for an editor more meta informations are needed (e.g.
which file-extensions it is used for, ...)

You can find the sources for the project in CVS:
e4/org.eclipse.e4.ui/examples/org.eclipse.e4.demo.simpleide* and
org.eclipse.e4.demo.tools.simpleide*.

Tom

Am 30.07.10 20:21, schrieb Tom Schindl:
> Hi,
>
> The problem with the find-parents dialog is that the initial
> Legacy-Application model is well fairly empty because in the current 4.0
> SDK 3.x informations coming through code (Advisors) and extension points
> are making up the model on the fly.
>
> Beside that I think what you really want to contribute is not a Part but
> a PartDescriptor (which is the equivalent of what you contribute through
> the editor/view extension point).
>
> The relationship between PartDescriptor and Part is similar to the Class
> and Object relation in Java itself. When you select a view entry in the
> "Show View"-Menu the "blueprint" information of PartDescriptor is used
> to the make up an Part-Instance which is inserted into the UI-Structure
> of the workbench. Does this description make sense to you else I'll try
> to rephrase?
>
> Writing up informations on how to write plug-ins using the
> model-fragment concept is on my TODO-List but there's simply too much
> I'll have to write up (I still want to code for Eclipse 4.1 :-)
>
> The list of up coming things are:
> * Tutorial on writing your own Theme (first blog post with informations
> is fairly ready)
>
> * Tutorial on contributing through Model-Fragments to the 4.0 workbench
> (as outlined above this is a bit tricky because of the implementation
> of the compat-layer) - event I myself need to find out test out
> things :-)
>
> * What ever people want to know about Eclipse 4.0 and the underlying
> technology
>
> Thanks for your interest into Eclipse 4.x we are trying to provide you
> as much informations and service we can with the given resources (as
> stated some of us are going to be on holiday in the next weeks :-)
>
> Tom
>
> Am 30.07.10 19:07, schrieb Vlad Dumitrescu:
>> Vlad Dumitrescu wrote on Fri, 30 July 2010 12:30
>>> - how do I get the "Find parent elements" dialog?
>>
>>
>> Ok, scratch that, I found it -- but it's empty...
>> regards,
>> Vlad
>>
>>
>
Re: Developing plug-ins [message #550554 is a reply to message #550543] Fri, 30 July 2010 19:04 Go to previous messageGo to next message
Vlad Dumitrescu is currently offline Vlad Dumitrescu
Messages: 318
Registered: July 2009
Location: Gothenburg
Senior Member
Tom Schindl wrote on Fri, 30 July 2010 14:28
Hi,
The project is named Simple-IDE and it for example holds a descriptor
which is able to replace the editor-extension point. The current
PartDescriptor mentioned below is a replacement for the view-extension
point because for an editor more meta informations are needed (e.g.
which file-extensions it is used for, ...)

You can find the sources for the project in CVS:
e4/org.eclipse.e4.ui/examples/org.eclipse.e4.demo.simpleide* and
org.eclipse.e4.demo.tools.simpleide*.



Thanks a lot for the answers, Tom! Maybe it's not a bad idea that you will go on vacation, it will force me to do better research before asking Smile

I'm not sure why the SimpleIDE project went unnoticed... anyway, I just imported the sources and I get an exception when opening Application.e4xmi:
org.eclipse.emf.ecore.xmi.PackageNotFoundException: Package with uri 'http://www.eclipse.org/e4/demo/simpleide' not found. (file:/E:/Users/Vlad/workspace4/org.eclipse.e4.demo.simpleide.e4editor/xmi/fragment.e4xmi, 4, 315)
	at org.eclipse.emf.ecore.xmi.impl.XMLHandler.getPackageForURI(XMLHandler.java:2591)
	at org.eclipse.emf.ecore.xmi.impl.XMLHandler.getFactoryForPrefix(XMLHandler.java:2422)
	at org.eclipse.emf.ecore.xmi.impl.XMLHandler.createObjectFromTypeName(XMLHandler.java:2072)
	at org.eclipse.emf.ecore.xmi.impl.XMLHandler.createObject(XMLHandler.java:2031)
	at org.eclipse.emf.ecore.xmi.impl.XMIHandler.createObject(XMIHandler.java:134)
	at org.eclipse.emf.ecore.xmi.impl.XMLHandler.handleFeature(XMLHandler.java:1840)
	at org.eclipse.emf.ecore.xmi.impl.XMLHandler.processElement(XMLHandler.java:1023)
	at org.eclipse.emf.ecore.xmi.impl.XMIHandler.processElement(XMIHandler.java:87)
	at org.eclipse.emf.ecore.xmi.impl.XMLHandler.startElement(XMLHandler.java:1001)
	at org.eclipse.emf.ecore.xmi.impl.XMLHandler.startElement(XMLHandler.java:712)
	at org.eclipse.emf.ecore.xmi.impl.XMIHandler.startElement(XMIHandler.java:169)
	at com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.startElement(Unknown Source)
	at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanStartElement(Unknown Source)
	at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl$FragmentContentDriver.next(Unknown Source)
	at com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl.next(Unknown Source)
	at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown Source)
	at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(Unknown Source)
	at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(Unknown Source)
	at com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(Unknown Source)
	at com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.parse(Unknown Source)
	at com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl$JAXPSAXParser.parse(Unknown Source)
	at javax.xml.parsers.SAXParser.parse(Unknown Source)
	at org.eclipse.emf.ecore.xmi.impl.XMLLoadImpl.load(XMLLoadImpl.java:181)
	at org.eclipse.emf.ecore.xmi.impl.XMLResourceImpl.doLoad(XMLResourceImpl.java:180)
	at org.eclipse.emf.ecore.resource.impl.ResourceImpl.load(ResourceImpl.java:1494)
	at org.eclipse.emf.ecore.resource.impl.ResourceImpl.load(ResourceImpl.java:1282)
	at org.eclipse.emf.ecore.resource.impl.ResourceSetImpl.demandLoad(ResourceSetImpl.java:255)
	at org.eclipse.emf.ecore.resource.impl.ResourceSetImpl.demandLoadHelper(ResourceSetImpl.java:270)


regards,
Vlad

Re: Developing plug-ins [message #550557 is a reply to message #550554] Fri, 30 July 2010 19:18 Go to previous messageGo to next message
Vlad Dumitrescu is currently offline Vlad Dumitrescu
Messages: 318
Registered: July 2009
Location: Gothenburg
Senior Member
I also get other exceptions when opening e4xmi files (sometimes)
java.lang.ClassCastException: org.eclipse.e4.ui.model.fragment.impl.ModelFragmentsImpl cannot be cast to org.eclipse.e4.ui.model.application.impl.ApplicationImpl
	at org.eclipse.e4.tools.ui.designer.E4UIRenderer.doLoad(E4UIRenderer.java:72)
	at org.eclipse.e4.xwt.tools.ui.designer.core.ceditor.ConfigureDesigner$1.runInUIThread(ConfigureDesigner.java:151)

Re: Developing plug-ins [message #550569 is a reply to message #550557] Fri, 30 July 2010 20:32 Go to previous messageGo to next message
Vlad Dumitrescu is currently offline Vlad Dumitrescu
Messages: 318
Registered: July 2009
Location: Gothenburg
Senior Member
Okay, I finally fumbled my way through... The usual way long lists with a "search" filed at the top work is that when the search field is empty, everything is shown. In the case of "find parent elements" the list is initially empty and one has to enter a part of an id that matches something in order to populate the list.

If the key combo for showing the live editor (Alt+Shift+F9) is mentioned somewhere in the docs/tutorials, I missed it too. Very helpful tool!

On to the next problem, I'm sure it's not far away! Smile

/Vlad
Re: Developing plug-ins [message #550579 is a reply to message #550557] Fri, 30 July 2010 21:45 Go to previous messageGo to next message
Thomas Schindl is currently offline Thomas Schindl
Messages: 5422
Registered: July 2009
Senior Member
Well - I think the Visual Designer can't deal with ModelFragments. You
need to use the Formbased ModelEditor.

Tom

Am 30.07.10 21:18, schrieb Vlad Dumitrescu:
> I also get other exceptions when opening e4xmi files (sometimes)
>
> java.lang.ClassCastException:
> org.eclipse.e4.ui.model.fragment.impl.ModelFragmentsImpl cannot be cast
> to org.eclipse.e4.ui.model.application.impl.ApplicationImpl
> at
> org.eclipse.e4.tools.ui.designer.E4UIRenderer.doLoad(E4UIRen derer.java:72)
> at
> org.eclipse.e4.xwt.tools.ui.designer.core.ceditor.ConfigureD esigner$1.runInUIThread(ConfigureDesigner.java:151)
>
>
>
Re: Developing plug-ins [message #550583 is a reply to message #550554] Fri, 30 July 2010 21:50 Go to previous messageGo to next message
Thomas Schindl is currently offline Thomas Schindl
Messages: 5422
Registered: July 2009
Senior Member
The SimpleIDE uses an extended EMF-Model, so the problem you are facing
is that org.eclipse.e4.demo.simpleide.model is not in your OSGi-Runtime.

There are 2 possibilities:
a) Export
* org.eclipse.e4.demo.simpleide.model
* org.eclipse.e4.demo.tools.simpleide
and copy them to your dropins-Folder

b) Launch an inner Eclipse
* Checkout org.eclipse.e4.demo.tools.simpleide and
org.eclipse.e4.demo.simpleide.model
* Launch an Inner Eclipse
* Checkout the rest

Tom

Am 30.07.10 21:04, schrieb Vlad Dumitrescu:
> Tom Schindl wrote on Fri, 30 July 2010 14:28
>> Hi,
>> The project is named Simple-IDE and it for example holds a descriptor
>> which is able to replace the editor-extension point. The current
>> PartDescriptor mentioned below is a replacement for the view-extension
>> point because for an editor more meta informations are needed (e.g.
>> which file-extensions it is used for, ...)
>>
>> You can find the sources for the project in CVS:
>> e4/org.eclipse.e4.ui/examples/org.eclipse.e4.demo.simpleide* and
>> org.eclipse.e4.demo.tools.simpleide*.
>
>
> Thanks a lot for the answers, Tom! Maybe it's not a bad idea that you
> will go on vacation, it will force me to do better research before
> asking :)
>
> I'm not sure why the SimpleIDE project went unnoticed... anyway, I just
> imported the sources and I get an exception when opening Application.e4xmi:
> org.eclipse.emf.ecore.xmi.PackageNotFoundException: Package with uri
> 'http://www.eclipse.org/e4/demo/simpleide' not found.
> (file:/E:/Users/Vlad/workspace4/org.eclipse.e4.demo.simpleid e.e4editor/xmi/fragment.e4xmi,
> 4, 315)
> at
> org.eclipse.emf.ecore.xmi.impl.XMLHandler.getPackageForURI(X MLHandler.java:2591)
>
> at
> org.eclipse.emf.ecore.xmi.impl.XMLHandler.getFactoryForPrefi x(XMLHandler.java:2422)
>
> at
> org.eclipse.emf.ecore.xmi.impl.XMLHandler.createObjectFromTy peName(XMLHandler.java:2072)
>
> at
> org.eclipse.emf.ecore.xmi.impl.XMLHandler.createObject(XMLHa ndler.java:2031)
>
> at
> org.eclipse.emf.ecore.xmi.impl.XMIHandler.createObject(XMIHa ndler.java:134)
> at
> org.eclipse.emf.ecore.xmi.impl.XMLHandler.handleFeature(XMLH andler.java:1840)
>
> at
> org.eclipse.emf.ecore.xmi.impl.XMLHandler.processElement(XML Handler.java:1023)
>
> at
> org.eclipse.emf.ecore.xmi.impl.XMIHandler.processElement(XMI Handler.java:87)
>
> at
> org.eclipse.emf.ecore.xmi.impl.XMLHandler.startElement(XMLHa ndler.java:1001)
>
> at
> org.eclipse.emf.ecore.xmi.impl.XMLHandler.startElement(XMLHa ndler.java:712)
> at
> org.eclipse.emf.ecore.xmi.impl.XMIHandler.startElement(XMIHa ndler.java:169)
> at
> com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser .startElement(Unknown
> Source)
> at
> com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentS cannerImpl.scanStartElement(Unknown
> Source)
> at
> com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentS cannerImpl$FragmentContentDriver.next(Unknown
> Source)
> at
> com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerIm pl.next(Unknown
> Source)
> at
> com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentS cannerImpl.scanDocument(Unknown
> Source)
> at
> com.sun.org.apache.xerces.internal.parsers.XML11Configuratio n.parse(Unknown
> Source)
> at
> com.sun.org.apache.xerces.internal.parsers.XML11Configuratio n.parse(Unknown
> Source)
> at
> com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(U nknown Source)
> at
> com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser .parse(Unknown
> Source)
> at
> com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl$JAXPSA XParser.parse(Unknown
> Source)
> at javax.xml.parsers.SAXParser.parse(Unknown Source)
> at
> org.eclipse.emf.ecore.xmi.impl.XMLLoadImpl.load(XMLLoadImpl. java:181)
> at
> org.eclipse.emf.ecore.xmi.impl.XMLResourceImpl.doLoad(XMLRes ourceImpl.java:180)
>
> at
> org.eclipse.emf.ecore.resource.impl.ResourceImpl.load(Resour ceImpl.java:1494)
>
> at
> org.eclipse.emf.ecore.resource.impl.ResourceImpl.load(Resour ceImpl.java:1282)
>
> at
> org.eclipse.emf.ecore.resource.impl.ResourceSetImpl.demandLo ad(ResourceSetImpl.java:255)
>
> at
> org.eclipse.emf.ecore.resource.impl.ResourceSetImpl.demandLo adHelper(ResourceSetImpl.java:270)
>
>
>
> regards,
> Vlad
>
>
Re: Developing plug-ins [message #550741 is a reply to message #550583] Wed, 04 August 2010 08:49 Go to previous messageGo to next message
Simon Chemouil is currently offline Simon Chemouil
Messages: 24
Registered: July 2009
Junior Member
Tom Schindl a écrit :
> The SimpleIDE uses an extended EMF-Model, so the problem you are facing
> is that org.eclipse.e4.demo.simpleide.model is not in your OSGi-Runtime.
>
> There are 2 possibilities:
> a) Export
> * org.eclipse.e4.demo.simpleide.model
> * org.eclipse.e4.demo.tools.simpleide
> and copy them to your dropins-Folder

There's also PDE's super handy "Export into host repository" which can
install them directly into your running instance (in your workspace
PDE's metadata).

This is exactly the same as what you proposed, but with this method, no
need to copy to dropins, it's limited to your workspace and there's no
fear of a mistake (copying to the wrong directory, etc).

The same feature is really useful when patching any Eclipse bundle, just
import the sources, hack and export to host repository... and you're
running a customized Eclipse instance in a matter of minutes.

Simon
Re: Developing plug-ins [message #550749 is a reply to message #550741] Wed, 04 August 2010 09:05 Go to previous messageGo to next message
Vlad Dumitrescu is currently offline Vlad Dumitrescu
Messages: 318
Registered: July 2009
Location: Gothenburg
Senior Member
Cool, thanks, I will try that!

/Vlad
Re: Developing plug-ins [message #579741 is a reply to message #550482] Fri, 30 July 2010 14:30 Go to previous messageGo to next message
Simon Chemouil is currently offline Simon Chemouil
Messages: 24
Registered: July 2009
Junior Member
Vlad Dumitrescu a écrit :
> Hi,
>
> Maybe I'm missing the obvious, but I'm still trying to get all my
> bearings right.
>
> The existing tutorials are targeting RCP applications. I can't find
> anything about developing plugins that will run in the IDE -- the PDE
> tooling targets 3.6 and less and generates old-style plugins...

As it is now, the plan is that IDE plugin developers should develop
their plugins just as they always did, and make sure they're only
consuming public API. The only difference is that they should test their
plugins against both 3.x and 4.0 if they want to be compatible with both
releases.

The "org.eclipse.e4" API is provisional and is used internally by the
compatibility layer which is a new implementation of the Eclipse
Workbench over the Eclipse 4 Application Platform. Adventurous RCP
developers can benefit from the provisional API because it offers new
and freer ways to develop apps, but there is not much to gain for plugin
developers as it is now.

By programming against the provisional API, a plugin developer loses
compatibility with the 3.x series (unless by using a 4->3 compatibility
layer), has no guarantee the model or the API won't change, and the gain
is minimal: the SDK/IDE look is not a problem for plugins, and plugins
themselves extend current bundles/features that are probably not
developed using the 4.0 API. If your plugin has dependencies which are
themselves dependent on 3.x, the interest is really limited. It can be
interesting when your plugin only depends on eclipse core/ui.

As of today, for a plugin developer, the only advantages I can see are:
* for fun, learning, etc.
* taking advantage of the new modeled UI, contexts, DI, etc, but
keeping in mind that you're forced to go back to the 3.x-style API
through compatibility for most of the integration with current
plugins/features (like JDT, Team, etc).


In the long run, of course, the plan is to have a stable 4.x API that
plugin developers code against, but some features are still missing now
so the 4.0 story for plugin developers is incomplete.

The early adopters release will allow the 4.0 team to improve the
compatibility layer by having plugin developers test their 3.6 compliant
plugins on the 4.0 SDK, and report their bugs.

If you still want to write plugins for 4.0 knowing that they'll likely
have to mix 3.x and 4.0, but still only be compatible with 4.0, with no
API stability guarantee... Well you should go for it, because the 4.x
programming model is much more pleasant imo, but keep in mind that by
doing so, you will be reaching less users today.

In this case, install model tooling, the E4 SDK and the EMF SDK from the
p2 update site already preconfigured in the 4.0 SDK ("E4 2010 updates")
and try to mix 3.x and 4.0 tutorials...

By the way, PDE doesn't "generate" for 3.6. It has a target platform,
and once you install the 4.0 bundles, you can use them and generate the
bundles using them from PDE.


Hope this helps,

Simon
Re: Developing plug-ins [message #579754 is a reply to message #550501] Fri, 30 July 2010 16:30 Go to previous messageGo to next message
Vlad Dumitrescu is currently offline Vlad Dumitrescu
Messages: 318
Registered: July 2009
Location: Gothenburg
Senior Member
Hi Simon,

Thanks a lot for the detailed answer.

Simon Chemouil wrote on Fri, 30 July 2010 10:30
> As of today, for a plugin developer, the only advantages I can see are:
> * for fun, learning, etc.
> * taking advantage of the new modeled UI, contexts, DI, etc, but
> keeping in mind that you're forced to go back to the 3.x-style API
> through compatibility for most of the integration with current
> plugins/features (like JDT, Team, etc).


I'm definitely in the second camp :) I already have bothered Tom Schindl with questions about the e4 compatibility layer...

One of the main things I was after in my question, but didn't express it clearly, was about the modeled UI: I can't find out how to use that for a single view. I mean, I have a model fragment, but how do I plug it in?

I found a nice walkthrough at http://tomsondev.bestsolution.at/2010/07/09/e4-some-more-new s-from-the-modeltooling/, but the unanswered questions are:
- how do I get the "Find parent elements" dialog?
- how can I refer to (and possibly open in the workbenchmodel editor) the model for the IDE?

best regards,
Vlad
Re: Developing plug-ins [message #579774 is a reply to message #550526] Fri, 30 July 2010 17:07 Go to previous messageGo to next message
Vlad Dumitrescu is currently offline Vlad Dumitrescu
Messages: 318
Registered: July 2009
Location: Gothenburg
Senior Member
Vlad Dumitrescu wrote on Fri, 30 July 2010 12:30
> - how do I get the "Find parent elements" dialog?


Ok, scratch that, I found it -- but it's empty...

regards,
Vlad
Re: Developing plug-ins [message #579786 is a reply to message #550534] Fri, 30 July 2010 18:21 Go to previous messageGo to next message
Thomas Schindl is currently offline Thomas Schindl
Messages: 5422
Registered: July 2009
Senior Member
Hi,

The problem with the find-parents dialog is that the initial
Legacy-Application model is well fairly empty because in the current 4.0
SDK 3.x informations coming through code (Advisors) and extension points
are making up the model on the fly.

Beside that I think what you really want to contribute is not a Part but
a PartDescriptor (which is the equivalent of what you contribute through
the editor/view extension point).

The relationship between PartDescriptor and Part is similar to the Class
and Object relation in Java itself. When you select a view entry in the
"Show View"-Menu the "blueprint" information of PartDescriptor is used
to the make up an Part-Instance which is inserted into the UI-Structure
of the workbench. Does this description make sense to you else I'll try
to rephrase?

Writing up informations on how to write plug-ins using the
model-fragment concept is on my TODO-List but there's simply too much
I'll have to write up (I still want to code for Eclipse 4.1 :-)

The list of up coming things are:
* Tutorial on writing your own Theme (first blog post with informations
is fairly ready)

* Tutorial on contributing through Model-Fragments to the 4.0 workbench
(as outlined above this is a bit tricky because of the implementation
of the compat-layer) - event I myself need to find out test out
things :-)

* What ever people want to know about Eclipse 4.0 and the underlying
technology

Thanks for your interest into Eclipse 4.x we are trying to provide you
as much informations and service we can with the given resources (as
stated some of us are going to be on holiday in the next weeks :-)

Tom

Am 30.07.10 19:07, schrieb Vlad Dumitrescu:
> Vlad Dumitrescu wrote on Fri, 30 July 2010 12:30
>> - how do I get the "Find parent elements" dialog?
>
>
> Ok, scratch that, I found it -- but it's empty...
> regards,
> Vlad
>
>
Re: Developing plug-ins [message #579801 is a reply to message #550542] Fri, 30 July 2010 18:28 Go to previous messageGo to next message
Thomas Schindl is currently offline Thomas Schindl
Messages: 5422
Registered: July 2009
Senior Member
Hi,

One more note. There's a demo application we are using to work out what
we need to make the new model story a first class concept.

The project is named Simple-IDE and it for example holds a descriptor
which is able to replace the editor-extension point. The current
PartDescriptor mentioned below is a replacement for the view-extension
point because for an editor more meta informations are needed (e.g.
which file-extensions it is used for, ...)

You can find the sources for the project in CVS:
e4/org.eclipse.e4.ui/examples/org.eclipse.e4.demo.simpleide* and
org.eclipse.e4.demo.tools.simpleide*.

Tom

Am 30.07.10 20:21, schrieb Tom Schindl:
> Hi,
>
> The problem with the find-parents dialog is that the initial
> Legacy-Application model is well fairly empty because in the current 4.0
> SDK 3.x informations coming through code (Advisors) and extension points
> are making up the model on the fly.
>
> Beside that I think what you really want to contribute is not a Part but
> a PartDescriptor (which is the equivalent of what you contribute through
> the editor/view extension point).
>
> The relationship between PartDescriptor and Part is similar to the Class
> and Object relation in Java itself. When you select a view entry in the
> "Show View"-Menu the "blueprint" information of PartDescriptor is used
> to the make up an Part-Instance which is inserted into the UI-Structure
> of the workbench. Does this description make sense to you else I'll try
> to rephrase?
>
> Writing up informations on how to write plug-ins using the
> model-fragment concept is on my TODO-List but there's simply too much
> I'll have to write up (I still want to code for Eclipse 4.1 :-)
>
> The list of up coming things are:
> * Tutorial on writing your own Theme (first blog post with informations
> is fairly ready)
>
> * Tutorial on contributing through Model-Fragments to the 4.0 workbench
> (as outlined above this is a bit tricky because of the implementation
> of the compat-layer) - event I myself need to find out test out
> things :-)
>
> * What ever people want to know about Eclipse 4.0 and the underlying
> technology
>
> Thanks for your interest into Eclipse 4.x we are trying to provide you
> as much informations and service we can with the given resources (as
> stated some of us are going to be on holiday in the next weeks :-)
>
> Tom
>
> Am 30.07.10 19:07, schrieb Vlad Dumitrescu:
>> Vlad Dumitrescu wrote on Fri, 30 July 2010 12:30
>>> - how do I get the "Find parent elements" dialog?
>>
>>
>> Ok, scratch that, I found it -- but it's empty...
>> regards,
>> Vlad
>>
>>
>
Re: Developing plug-ins [message #579813 is a reply to message #550543] Fri, 30 July 2010 19:04 Go to previous messageGo to next message
Vlad Dumitrescu is currently offline Vlad Dumitrescu
Messages: 318
Registered: July 2009
Location: Gothenburg
Senior Member
Tom Schindl wrote on Fri, 30 July 2010 14:28
> Hi,
> The project is named Simple-IDE and it for example holds a descriptor
> which is able to replace the editor-extension point. The current
> PartDescriptor mentioned below is a replacement for the view-extension
> point because for an editor more meta informations are needed (e.g.
> which file-extensions it is used for, ...)
>
> You can find the sources for the project in CVS:
> e4/org.eclipse.e4.ui/examples/org.eclipse.e4.demo.simpleide* and
> org.eclipse.e4.demo.tools.simpleide*.


Thanks a lot for the answers, Tom! Maybe it's not a bad idea that you will go on vacation, it will force me to do better research before asking :)

I'm not sure why the SimpleIDE project went unnoticed... anyway, I just imported the sources and I get an exception when opening Application.e4xmi:
org.eclipse.emf.ecore.xmi.PackageNotFoundException: Package with uri 'http://www.eclipse.org/e4/demo/simpleide' not found. (file:/E:/Users/Vlad/workspace4/org.eclipse.e4.demo.simpleid e.e4editor/xmi/fragment.e4xmi, 4, 315)
at org.eclipse.emf.ecore.xmi.impl.XMLHandler.getPackageForURI(X MLHandler.java:2591)
at org.eclipse.emf.ecore.xmi.impl.XMLHandler.getFactoryForPrefi x(XMLHandler.java:2422)
at org.eclipse.emf.ecore.xmi.impl.XMLHandler.createObjectFromTy peName(XMLHandler.java:2072)
at org.eclipse.emf.ecore.xmi.impl.XMLHandler.createObject(XMLHa ndler.java:2031)
at org.eclipse.emf.ecore.xmi.impl.XMIHandler.createObject(XMIHa ndler.java:134)
at org.eclipse.emf.ecore.xmi.impl.XMLHandler.handleFeature(XMLH andler.java:1840)
at org.eclipse.emf.ecore.xmi.impl.XMLHandler.processElement(XML Handler.java:1023)
at org.eclipse.emf.ecore.xmi.impl.XMIHandler.processElement(XMI Handler.java:87)
at org.eclipse.emf.ecore.xmi.impl.XMLHandler.startElement(XMLHa ndler.java:1001)
at org.eclipse.emf.ecore.xmi.impl.XMLHandler.startElement(XMLHa ndler.java:712)
at org.eclipse.emf.ecore.xmi.impl.XMIHandler.startElement(XMIHa ndler.java:169)
at com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser .startElement(Unknown Source)
at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentS cannerImpl.scanStartElement(Unknown Source)
at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentS cannerImpl$FragmentContentDriver.next(Unknown Source)
at com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerIm pl.next(Unknown Source)
at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentS cannerImpl.scanDocument(Unknown Source)
at com.sun.org.apache.xerces.internal.parsers.XML11Configuratio n.parse(Unknown Source)
at com.sun.org.apache.xerces.internal.parsers.XML11Configuratio n.parse(Unknown Source)
at com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(U nknown Source)
at com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser .parse(Unknown Source)
at com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl$JAXPSA XParser.parse(Unknown Source)
at javax.xml.parsers.SAXParser.parse(Unknown Source)
at org.eclipse.emf.ecore.xmi.impl.XMLLoadImpl.load(XMLLoadImpl. java:181)
at org.eclipse.emf.ecore.xmi.impl.XMLResourceImpl.doLoad(XMLRes ourceImpl.java:180)
at org.eclipse.emf.ecore.resource.impl.ResourceImpl.load(Resour ceImpl.java:1494)
at org.eclipse.emf.ecore.resource.impl.ResourceImpl.load(Resour ceImpl.java:1282)
at org.eclipse.emf.ecore.resource.impl.ResourceSetImpl.demandLo ad(ResourceSetImpl.java:255)
at org.eclipse.emf.ecore.resource.impl.ResourceSetImpl.demandLo adHelper(ResourceSetImpl.java:270)


regards,
Vlad
Re: Developing plug-ins [message #579828 is a reply to message #550554] Fri, 30 July 2010 19:18 Go to previous messageGo to next message
Vlad Dumitrescu is currently offline Vlad Dumitrescu
Messages: 318
Registered: July 2009
Location: Gothenburg
Senior Member
I also get other exceptions when opening e4xmi files (sometimes)

java.lang.ClassCastException: org.eclipse.e4.ui.model.fragment.impl.ModelFragmentsImpl cannot be cast to org.eclipse.e4.ui.model.application.impl.ApplicationImpl
at org.eclipse.e4.tools.ui.designer.E4UIRenderer.doLoad(E4UIRen derer.java:72)
at org.eclipse.e4.xwt.tools.ui.designer.core.ceditor.ConfigureD esigner$1.runInUIThread(ConfigureDesigner.java:151)
Re: Developing plug-ins [message #579850 is a reply to message #579828] Fri, 30 July 2010 20:32 Go to previous messageGo to next message
Vlad Dumitrescu is currently offline Vlad Dumitrescu
Messages: 318
Registered: July 2009
Location: Gothenburg
Senior Member
Okay, I finally fumbled my way through... The usual way long lists with a "search" filed at the top work is that when the search field is empty, everything is shown. In the case of "find parent elements" the list is initially empty and one has to enter a part of an id that matches something in order to populate the list.

If the key combo for showing the live editor (Alt+Shift+F9) is mentioned somewhere in the docs/tutorials, I missed it too. Very helpful tool!

On to the next problem, I'm sure it's not far away! :)

/Vlad
Re: Developing plug-ins [message #579862 is a reply to message #579828] Fri, 30 July 2010 21:45 Go to previous messageGo to next message
Thomas Schindl is currently offline Thomas Schindl
Messages: 5422
Registered: July 2009
Senior Member
Well - I think the Visual Designer can't deal with ModelFragments. You
need to use the Formbased ModelEditor.

Tom

Am 30.07.10 21:18, schrieb Vlad Dumitrescu:
> I also get other exceptions when opening e4xmi files (sometimes)
>
> java.lang.ClassCastException:
> org.eclipse.e4.ui.model.fragment.impl.ModelFragmentsImpl cannot be cast
> to org.eclipse.e4.ui.model.application.impl.ApplicationImpl
> at
> org.eclipse.e4.tools.ui.designer.E4UIRenderer.doLoad(E4UIRen derer.java:72)
> at
> org.eclipse.e4.xwt.tools.ui.designer.core.ceditor.ConfigureD esigner$1.runInUIThread(ConfigureDesigner.java:151)
>
>
>
Re: Developing plug-ins [message #579881 is a reply to message #550554] Fri, 30 July 2010 21:50 Go to previous messageGo to next message
Thomas Schindl is currently offline Thomas Schindl
Messages: 5422
Registered: July 2009
Senior Member
The SimpleIDE uses an extended EMF-Model, so the problem you are facing
is that org.eclipse.e4.demo.simpleide.model is not in your OSGi-Runtime.

There are 2 possibilities:
a) Export
* org.eclipse.e4.demo.simpleide.model
* org.eclipse.e4.demo.tools.simpleide
and copy them to your dropins-Folder

b) Launch an inner Eclipse
* Checkout org.eclipse.e4.demo.tools.simpleide and
org.eclipse.e4.demo.simpleide.model
* Launch an Inner Eclipse
* Checkout the rest

Tom

Am 30.07.10 21:04, schrieb Vlad Dumitrescu:
> Tom Schindl wrote on Fri, 30 July 2010 14:28
>> Hi,
>> The project is named Simple-IDE and it for example holds a descriptor
>> which is able to replace the editor-extension point. The current
>> PartDescriptor mentioned below is a replacement for the view-extension
>> point because for an editor more meta informations are needed (e.g.
>> which file-extensions it is used for, ...)
>>
>> You can find the sources for the project in CVS:
>> e4/org.eclipse.e4.ui/examples/org.eclipse.e4.demo.simpleide* and
>> org.eclipse.e4.demo.tools.simpleide*.
>
>
> Thanks a lot for the answers, Tom! Maybe it's not a bad idea that you
> will go on vacation, it will force me to do better research before
> asking :)
>
> I'm not sure why the SimpleIDE project went unnoticed... anyway, I just
> imported the sources and I get an exception when opening Application.e4xmi:
> org.eclipse.emf.ecore.xmi.PackageNotFoundException: Package with uri
> 'http://www.eclipse.org/e4/demo/simpleide' not found.
> (file:/E:/Users/Vlad/workspace4/org.eclipse.e4.demo.simpleid e.e4editor/xmi/fragment.e4xmi,
> 4, 315)
> at
> org.eclipse.emf.ecore.xmi.impl.XMLHandler.getPackageForURI(X MLHandler.java:2591)
>
> at
> org.eclipse.emf.ecore.xmi.impl.XMLHandler.getFactoryForPrefi x(XMLHandler.java:2422)
>
> at
> org.eclipse.emf.ecore.xmi.impl.XMLHandler.createObjectFromTy peName(XMLHandler.java:2072)
>
> at
> org.eclipse.emf.ecore.xmi.impl.XMLHandler.createObject(XMLHa ndler.java:2031)
>
> at
> org.eclipse.emf.ecore.xmi.impl.XMIHandler.createObject(XMIHa ndler.java:134)
> at
> org.eclipse.emf.ecore.xmi.impl.XMLHandler.handleFeature(XMLH andler.java:1840)
>
> at
> org.eclipse.emf.ecore.xmi.impl.XMLHandler.processElement(XML Handler.java:1023)
>
> at
> org.eclipse.emf.ecore.xmi.impl.XMIHandler.processElement(XMI Handler.java:87)
>
> at
> org.eclipse.emf.ecore.xmi.impl.XMLHandler.startElement(XMLHa ndler.java:1001)
>
> at
> org.eclipse.emf.ecore.xmi.impl.XMLHandler.startElement(XMLHa ndler.java:712)
> at
> org.eclipse.emf.ecore.xmi.impl.XMIHandler.startElement(XMIHa ndler.java:169)
> at
> com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser .startElement(Unknown
> Source)
> at
> com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentS cannerImpl.scanStartElement(Unknown
> Source)
> at
> com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentS cannerImpl$FragmentContentDriver.next(Unknown
> Source)
> at
> com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerIm pl.next(Unknown
> Source)
> at
> com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentS cannerImpl.scanDocument(Unknown
> Source)
> at
> com.sun.org.apache.xerces.internal.parsers.XML11Configuratio n.parse(Unknown
> Source)
> at
> com.sun.org.apache.xerces.internal.parsers.XML11Configuratio n.parse(Unknown
> Source)
> at
> com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(U nknown Source)
> at
> com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser .parse(Unknown
> Source)
> at
> com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl$JAXPSA XParser.parse(Unknown
> Source)
> at javax.xml.parsers.SAXParser.parse(Unknown Source)
> at
> org.eclipse.emf.ecore.xmi.impl.XMLLoadImpl.load(XMLLoadImpl. java:181)
> at
> org.eclipse.emf.ecore.xmi.impl.XMLResourceImpl.doLoad(XMLRes ourceImpl.java:180)
>
> at
> org.eclipse.emf.ecore.resource.impl.ResourceImpl.load(Resour ceImpl.java:1494)
>
> at
> org.eclipse.emf.ecore.resource.impl.ResourceImpl.load(Resour ceImpl.java:1282)
>
> at
> org.eclipse.emf.ecore.resource.impl.ResourceSetImpl.demandLo ad(ResourceSetImpl.java:255)
>
> at
> org.eclipse.emf.ecore.resource.impl.ResourceSetImpl.demandLo adHelper(ResourceSetImpl.java:270)
>
>
>
> regards,
> Vlad
>
>
Re: Developing plug-ins [message #579954 is a reply to message #550583] Wed, 04 August 2010 08:49 Go to previous messageGo to next message
Simon Chemouil is currently offline Simon Chemouil
Messages: 24
Registered: July 2009
Junior Member
Tom Schindl a écrit :
> The SimpleIDE uses an extended EMF-Model, so the problem you are facing
> is that org.eclipse.e4.demo.simpleide.model is not in your OSGi-Runtime.
>
> There are 2 possibilities:
> a) Export
> * org.eclipse.e4.demo.simpleide.model
> * org.eclipse.e4.demo.tools.simpleide
> and copy them to your dropins-Folder

There's also PDE's super handy "Export into host repository" which can
install them directly into your running instance (in your workspace
PDE's metadata).

This is exactly the same as what you proposed, but with this method, no
need to copy to dropins, it's limited to your workspace and there's no
fear of a mistake (copying to the wrong directory, etc).

The same feature is really useful when patching any Eclipse bundle, just
import the sources, hack and export to host repository... and you're
running a customized Eclipse instance in a matter of minutes.

Simon
Re: Developing plug-ins [message #579970 is a reply to message #550741] Wed, 04 August 2010 09:05 Go to previous message
Vlad Dumitrescu is currently offline Vlad Dumitrescu
Messages: 318
Registered: July 2009
Location: Gothenburg
Senior Member
Cool, thanks, I will try that!

/Vlad
Previous Topic:XWT. How to use Link with anchor?
Next Topic:XWT and CSS: Warning - could not initialize CSS styling : org.eclipse.e4.xwt.css.CSSEngineNotFoundEx
Goto Forum:
  


Current Time: Fri Oct 24 23:11:37 GMT 2014

Powered by FUDForum. Page generated in 0.08053 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software