Announcement Announcement Module
Collapse
No announcement yet.
Spring with Eclipse RCP anyone? Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • Spring with Eclipse RCP anyone?

    Hi,

    I'm interested to integrate Spring into Eclipse RCP so that the actions can be wired up automagically by Spring.

    I would like to know if anyone tried this?
    Or else, at least, is there any pointers for my further exploration?

    TIA,
    Raymond

  • #2
    I have considered to do so too. The problem is, everything in Eclipse is a contribution. So everything should be specified by the plugin.xml. 'Contributing' actions or anything like that, without using plugin.xml would violate the 'Everything is a contribution' rule(?).

    I end up to specify only the domain related parts using Spring (Model and some controllers). I am also using a custom dependency injection solution (simply using marker interfaces) for injecting dependencies of contributed elements. Works well.

    If you make further progress, please drop me a note.


    Cheers,

    Martin (Kersten)

    Comment


    • #3
      Martin,

      I'd be interested in seeing your approach here. Could you by chance send me or post a sample of you using Eclipse RCP with Spring to connect Eclipse Actions and UI objects to middle tier services wired up using Spring?

      Comment


      • #4
        I've talked about the domain related code. You can think about it, as the core you would write if you have to provide both, a Swing and a SWT GUI. You know all the domain-logic (meaning, model, commands, undo/redo, selection etc.) is wired up using Spring. There is no Eclipse related stuff configured using Spring. Eclipse's RCP code is than used to present the model and trigger the domain-logic related actions.

        For example, the logic of an action is Eclipse RCP independent and therefore is part of the Spring stuff. An contributed action (contributed using plugin.xml) simply warps those domain actions, being able to trigger the action and/or provide dialogs/wizards to configure the action.

        So you may think about the Eclipse RCP as a diffrent world triggering domain-behaviour and reacting to the domain-model.

        It worked best to seperate both worlds using two diffrent projects. One is the client.domain (plugin-)project and the other is the client.ui plugin providing ui and connectors like content-provider.

        Testing the client.domain stuff is done using plain jUnit tests (no Plugin-jUnit tests). And it should also do not require any Eclipse plug-ins. It helped alot to speed development. So the client.ui and client.domain are clearly seperated.

        Comment


        • #5
          I understand that; in fact, we implement a very similiar ui+domain layer strategy in Spring Rich Client, which is a rich client framework built on Swing that uses Spring for configuration and for connecting to the domain layer.

          I'm interested in exactly how you did this with Eclipse RCP down to the code level; as I would consider making Eclipse RCP integration part of what we're doing with the Spring Rich effort as well.

          Spring Rich is targeting Swing; no SWT/JFace there, and specifically data-centric enterprise apps. So we offer a good deal of features Eclipse RCP doesn't, but there is some overlap, too, and some opportunities to integrate. Seems like you could help us jumpstart that integration!

          Comment


          • #6
            I understand that; in fact, we implement a very similiar ui+domain layer strategy in Spring Rich Client, which is a rich client framework built on Swing that uses Spring for configuration and for connecting to the domain layer.
            I didn't evaluated it in depth.

            I'm interested in exactly how you did this with Eclipse RCP down to the code level; as I would consider making Eclipse RCP integration part of what we're doing with the Spring Rich effort as well.
            It's quite simple (like any MVC stuff). First you add some logic to the ui layer. Remove the ui-dependencies as much as possible and let it drip down to the model/controller part of the domain-layer. Thats all. There isn't much fuzz about it.

            Spring Rich is targeting Swing; no SWT/JFace there, and specifically data-centric enterprise apps. So we offer a good deal of features Eclipse RCP doesn't, but there is some overlap, too, and some opportunities to integrate. Seems like you could help us jumpstart that integration!
            There really isn't much to do. Mostly content-provider, actions and dialog logic are important. Also some high-level business logic needs to be utilized by the UI stuff. It's quite normal TDD going on.

            If you have a question or anything you are fighting with, just ask me a certain question but in general it's like programming an UI application and think the way:"If I am also writing a Swing application, what logic would I like to reuse." That's it. Nothing more. Well beside having a undo/redo stuff etc. But this is also normal domain-layer stuff - so nothing to be excited about.

            Comment


            • #7
              So do you want to suggest that we can only use the pull approach (getApplicationContext().getBean() thing) on the actions, views, etc... we wrote for Eclipse?

              This method is good, just I want to enable IoC on these "contributions" for Eclipse too.

              I did looked a bit at Eclipse's source code. It seems that only Eclipse's WorkbenchAdvisor can be a customized implementation; others are not, including the factory classes for instantiating Views, Perspectives, Actions, etc.

              If these factory classes are pluggable everything will be much simpler. However, it seems Eclipse is not the case.

              Any ideas on this one?

              Thanks again,
              cptechno

              Comment


              • #8
                So do you want to suggest that we can only use the pull approach (getApplicationContext().getBean() thing) on the actions, views, etc... we wrote for Eclipse?
                It looks like. But providing aid for doing so, is much productive.

                This method is good, just I want to enable IoC on these "contributions" for Eclipse too.
                I use dependency injection using a context. The context is bound to the plugin class (and hidden).

                So it ends up:

                Code:
                MyPlugin.injectDependencies(Object);
                The context used by MyPlugin to inject the dependencies is configured using Spring. That's how everything is connected. If a view is created it injects it dependency on it's own (same for action, providers etc.) or if a contribution to an extension-point definied by MyPlugin is instanciated/initialized it gets its dependencies injected transparently by MyPlugin.

                Thats how I tie all code together.

                If these factory classes are pluggable everything will be much simpler. However, it seems Eclipse is not the case.
                Maybe a factory can be seen like the dependency injection I use. You know creating a two parted solution. For example: you may define a view within Spring, setting the properties and also contribute a view using plugin.xml. Since the view is extended using a Spring RCP abstract view, it will look for a bean-definition and automatically set the properties like specified. For the user of this view, it would be absolutly transparent how the properties got injected.

                Maybe the id's should be in sync meaning contributing the view: 'org.spring.view.MyView' and the corresponding context item being 'org.spring.view.MyView' (ergo the same). This can be also done with labels etc. Just store the values within such a Spring RCP definition object and on creation inject the properties.

                This comes by the cost using additional JFace / SWT components - I think some are not intended to be subclassed anyway, so a property-injection facility must be provided anyway.

                I guess this solution may be an great step forward compared to my dependency injection which also work great, anyway.

                The above idea is very promessing. I guess I would like to join your subproject and provide some contribution and also comments and stuff. So I you like, I would like to join your project as a minior developer. (since the outcome of your affords seams to provide some value for me :-) )

                Comment


                • #9
                  Originally posted by Martin Kersten

                  I use dependency injection using a context. The context is bound to the plugin class (and hidden).

                  So it ends up:
                  Code:
                  MyPlugin.injectDependencies(Object);
                  This should be what I'm looking for. However:

                  - (A bit OT) Does it mean that I can create a plugin that can intervene the instantiation of these contributions by giving them a already wired instances?
                  - If yes, where from Eclipse's source/javadoc should I begin to look into for me to dug deeper? I think actually this should be the ultimate starting point for writing IoC for Actions, Views, etc. with Spring.

                  Thanks again,
                  cptechno

                  Comment


                  • #10
                    - (A bit OT) Does it mean that I can create a plugin that can intervene the instantiation of these contributions by giving them a already wired instances?
                    You can only do this when the plugin defines the extension-point. The plugin defining the extension-point is responsible to create and instanciate every contribution to the point.

                    - If yes, where from Eclipse's source/javadoc should I begin to look into for me to dug deeper? I think actually this should be the ultimate starting point for writing IoC for Actions, Views, etc. with Spring.
                    Check out the plugin loading mechanisms. Like view, action etc. It's quite ugly code (if they havn't changed it yet). But you will learn much.


                    Can you give me an example of what you are planing /wanting to do. You know just a scenario like the RCP should be able to do this and that. I was also thinking about the way the components are created... .

                    Views by the way has some kind of init() methods. Therefore injecting dependencies there is not much of a problem. And ViewPart(s) are intended to be subclassed.

                    Comment


                    • #11
                      Thanks very much for your advice, it seems I can see where I should go now.

                      What I'm going to do is very simple - make the actions' dependencies automagically satisfied when they are called from menu items, buttons, etc.

                      Of course, if menu bars, pull-down/pop-up menus can also be built with wrapper classes that goes to Spring it will be much better.

                      So it returns to the core of the question - integrating Spring's BeanFactory into Eclipse...

                      TIA,
                      cptechno

                      Comment


                      • #12
                        What I'm going to do is very simple - make the actions' dependencies automagically satisfied when they are called from menu items, buttons, etc.
                        I guess it is best to subclass an abstract action subclass providing a transparent way to inject those dependencies. This works well. The problem is that you do not control the contribution initialisation since this is done by eclipse.ui parts (I think).

                        Another side step is not to use the actions in a traditional way. I mostly like to use a Command like pattern:

                        ui.action-> Command -> domain actions

                        You know an ui.action should never find it's way into the domain layer. It produces much trouble and is mostly not logical. I tend to write my domain layer tests using junit only. Whenever I add eclipse related modules/dependencies to it, something is wrong. Mostly this will end up in cycles between your moduls since the UI couples tightly within the domain elements.

                        Of course, if menu bars, pull-down/pop-up menus can also be built with wrapper classes that goes to Spring it will be much better.
                        Go for it, it works well. If you define the extension it is best to use interfaces and handle interjection after creation but before the initialization process (not inbetween the init-phase).

                        So it returns to the core of the question - integrating Spring's BeanFactory into Eclipse...
                        The only way I know: Two parted. Once the element is created by Eclipse, it should look up for any stuff specified using Spring. So a Eclipse element should not be created/instanciated by a Spring context. It would be something like reversed responsibility. Since the UI layer should be responsible for UI elements and Eclipse is not build for being configured using Spring.

                        So draw a border inbetween and inject dependencies using special abstract classes or inject them internaly using Plugin.injectDependency() method.

                        Tip: Inject the dependencies only, if they are not set. So testing becomes easy.

                        Comment


                        • #13
                          Also interested in using spring with the real RCP (eclipse)

                          I also find the subject of using spring with eclipse plugins / RCP applications interesting and potentially very useful (spring should "join" eclipse RCP instead of reventing the wheel as some people may be trying to do with spring RCP). I hope to hear more about using spring with eclipse plugins / RCP in the future!

                          Comment


                          • #14
                            We should work to integrate with eclipse's rich client platform certainly. I would be doing this now myself if I built apps with Eclipse for a living. Currently, however, I and my customers prefer Swing solutions at this point, and Spring Rich adds a lot of value there.

                            I think what we've focused on in spring rich thus far is not reinvention, but innovation, and innovation that builds on standard Swing, not JFace/AWT. Swing needs simplification through appropriate, higher-level OO abstractions, and needs it bad. And many people still view Swing as "the" widget toolkit to build platform independent desktop apps in Java.

                            To date we've done a lot of cool things integrating Spring's IoC container into a Swing-app environment. The result? It's a lot easier to write a clean, concisely coded (and well-layered) swing app, where it was quite easy to write ugly, lengthy coded one before.

                            I should point out a good many of the issues we're addressing in rich client, for example: data validation, UI-to-domain model binding, and command/request workflow aren't really addressed by Eclipse's base RCP platform, anyway. There is a definite "enterprise/j2ee app" focus in spring rich client.

                            With all this said I definitely would LOVE to see Eclipse RCP integration on top of Spring, leveraging existing complimentary libraries of spring rich (such as the data binding stuff). But I wouldn't want to force spring rich users to HAVE to use eclipse's platform: in many cases it's just not necessary (particularly when a team already knows Swing, cares about platform independence, and doesn't want the complexity of the eclipse plugin model - yet another thing to configure...)

                            Keith

                            Comment


                            • #15
                              Eclipse has code editors. Should now all standalone editors die on the vine or be just plug-ins into Eclipse? There may be reasons why they should, but then Eclipse starts becomming another OS in some ways.

                              I'd rather be able to use a plug-in into any container. So, a component that provides me with a value-add should be able to cooperate with other components that I use in certain containers, like IDEA, JEdit, Vslick, Netbeans, and so forth. This, I thought, was a major goal of the OOP hype and COM this or that.

                              Oh well, I guess off topic.

                              Comment

                              Working...
                              X