Skip to Content

One of the major reasons of why Eclipse was chosen as a foundation for the new ABAP development environment is its extensibility. Almost every introduction to ADT I’ve seen so far stresses the additional value that can be gained by combining plug-ins from multiple sources. I’ve used Eclipse for some time now (starting with 3.2 or 3.3, I don’t exactly remember when), developed my own Eclipse-based tools and while I’m certainly not an expert, I know about the basics of implementing and extending Eclipse plug-ins.

Until now, I have more or less ignored ADT – mostly because our ABAP environments were too outdated to use ADT. This is slowly changing, so I took the opportunity and visited the introductory DEV165 session at this year’s SAP TechEd && d-code in Berlin. Back at home, I wanted to put the claim of extensibility to the test. My aim was to create a plug-in that takes an existing interface and generates a pre-fabricated implementation class according to some rules. The details are not of importance here – I’ll probably write about it later when there is something to be seen.

My idea was to extend the Project Explorer view so that you could right-click the interface and start some kind of wizard that creates a class for the interface. Extending the Project Explorer is a frequent task in the Eclipse world, so there are a number of tutorials available. If you want to code along, I’d recommend using this tutorial to get a starting point.

The next step would be to place a restriction on the menu extension so that the context menu entry only appears for interfaces. This is fairly easy, you just need to add a condition to the extension. In this case, I figured that an instanceof condition should do the trick, so I used the Plug-in Spy provided by the PDE to find out more about the interface entries in the Project Explorer (select an interface in the project explorer, then press Alt+Shift+F1).

PDESpy.png

Among other information, you can see that the current selection (which is what matters most here) is a TreeSelection that contains an AbapRepositoryInterfaceNode. Using this information, it is possible to limit the popup menu entry to Interfaces:

Extension.png

In the command handler, you would usually use the central selection service to find out what objects the command should work on. There’s a basic example in the tutorial I mentioned above; it involves examining the selection and then casting the selected object to a suitable class or interface variable. This is where the trouble really starts…

If you try to look up the class AbapRepositoryInterfaceNode in the ADT SDK documentation, you’ll be out of luck – as the fully qualified class name com.sap.adt.oo.ui.internal.interfaces.projectexplorer.AbapRepositoryInterfaceNode suggests, this is an internal implementation class, and most of the object-specific classes aren’t documented anyway. This is not good – while it is still possible to plough on, it makes things a lot harder for wannabe contributors.

Using some dirty tricks, it is possible to put together an inheritance tree of AbapRepositoryInterfaceNode. However, it doesn’t look too promising:

ARIN-Inheritance-Commented.png

Using the documented API, you can find out which project the interface belongs to, and that’s about it. Now for the average Eclipse plug-in that would be annoying, but not too uncommon – there are loads of plug-ins with a similar level of (un)documentation. At this point, you would start to dig into the source code to find out about the structure of AbapRepositoryInterfaceNode and its superclasses and interfaces, other classes that use it, perhaps some service implementations, and usually within a reasonable amount of time, you would have gained an understanding of the inner workings. That’s not possible in this case, simply because the source code is not available publicly. We’ll have to continue guessing, which in this case is easy: A TreeNode has a generic means to attach a value to the node. A quick look with the debugger reveals that this is indeed the way the node keeps track of the object it represents:

ARIN-Debugger.png

So, a RepositoryObjectListItem, let’s look that up in the SDK – whoops, internal stuff again. This class implements IRepositoryObject, which is undocumented as well, but at least gives you basic information about the selected interface:

IRO.png

Fine so far, but now you might want to be interested in the contents of the interface. At this point, you would probably use the References in Workspace (Ctrl+Shift+G) function to try and find out where the interface is used and what you might do with it – but again, this only applies to open source projects where you have the source code at your disposal.

/wp-content/uploads/2014/11/dangersign_586353.jpg

At the moment, this looks like the end of the road – if you want to continue your journey, you have to put on a hard hat, break out the heavy machinery and probably violate a few terms of the licensing agreement in the process.

I would have liked to blog about something else today, something a bit closer to an implementation, but that wasn’t to be. A few key takeaways from my point of view:

  1. Extensibility doesn’t come automatically with the platform, it has to be considered in the architecture and implementation of each and every aspect of the product. An Eclipse plug-in can be as segregated and hard to extend as any other commercial application.
  2. Extensibility of other products largely comprises of the ability to examine the existing stuff. This applies not only to Eclipse, but likewise to the SAP NetWeaver platform and the applications built on top of it. Imagine having to implement a BAdI without access to the application around it…
  3. Documentation is no substitute for access to the source code unless it is really comprehensive and well-maintained.
  4. Likewise, access to the source code is no real substitute for documentation – it tells you how things are built, but not why.
To report this post you need to login first.

3 Comments

You must be Logged on to comment or reply to a post.

  1. Thomas Alexander Ritter

    Hi Volker,

    thanks for taking the time and providing feedback regarding the SDK. I fully agree with you on the points you made. When we worked on the first version of the SDK we had to decide whether we:

    a) spend an huge amount of time documenting and releasing every single development object. Even if it might not be needed

    b) release only the basic APIs and let the community tell us what else they need

    The Eclipse platform API was released using option number b). They did not release/document everything in the beginning. Instead they listened to the community and when it became apparent that an API is necessary based on community feedback they made it public and provided documentation. We liked this approach and picked option b), too. However, I do not think we communicated this strategy well enough over the last years. I did talk about it during SAP CodeJams but it is not documented in this community. This is something we have to improve.

    So what is our current strategy to help customers like you with extending ABAP in Eclipse?

    1) Please tell us when you are using unreleased APIs and whenever possible we will make them public

    2) Ask questions in the forums. This space is not only about the tools. It is about the SDK, too. So in situations like you discussed in the blog feel free to ask a question in the forum and we will try to help you

    3) We want to provide more simple examples on how to use the API

    Regarding your use case. Have a look at the source code for the SAPlink Eclipse plug-in. They also wanted a menu item addition only for certain object types. Their property tester gives you a general idea how to check for interfaces (Type: INTF/OI):

    https://www.assembla.com/code/saplink-for-abap-in-eclipse/subversion/nodes/39/branches/adt-2.0/eclipse-plugin/src/org/saplink/ui/actions/SaplinkPropertyTester.java

    Hope this helps. Looking forward to read more about your plug-in.

    Cheers

    Thomas

    p.s. Christian Drumm blog posts might also be worth a look: http://scn.sap.com/community/abap/eclipse/blog/2014/08/27/creating-a-abap-in-eclipse-plug-in-using-the-adt-sdk

    (0) 
    1. Volker Wegert Post author

      Hi Thomas,

      thank you for your kind words. I fully understand the reasons for the decision you took, and would probably have done the same thing.

      Thomas Alexander Ritter wrote:

      The Eclipse platform API was released using option number b). They did not release/document everything in the beginning.

      That is correct, but they released the source code. While it is tedious going through undocumented software and trying to find out how things fit together, you learn a log in the process – and it really saves time. Communication through Q&A forums is not instantaneous, and if I had to wait for an answer to each question I had while building my first Eclipse 3.3 plug-in, I probably wouldn’t have completed it today.

      I understand that maybe you are not in a position to decide whether the ADT sources can be opened for read-only access, but it takes some time to adjust to this (after all, the entire business suite including the “classic” ABAP Workbench is open source for customers).

      1) Please tell us when you are using unreleased APIs and whenever possible we will make them public

      Will do.

      2) Ask questions in the forums. This space is not only about the tools. It is about the SDK, too. So in situations like you discussed in the blog feel free to ask a question in the forum and we will try to help you

      I have to admit I didn’t think about this – I only went through the first three or four pages of the forums and only found “basic” user questions, so I didn’t think of this as an ADT developer forum.

      Have a look at the source code for the SAPlink Eclipse plug-in. They also wanted a menu item addition only for certain object types. Their property tester gives you a general idea how to check for interfaces (Type: INTF/OI):

      Thanks, I’ll certainly do so.

      Cheers

        Volker

      (0) 
      1. Thomas Fiedler

        Hi Volker,

        The ABAP tools for eclipse tools are in contrast to the eclipse platform not an open source product. Therefore it is not possible for us to provide you the sources due to legal aspects.

        I’m in contact with our open source experts how we can manage this issue. Same request we already got from other contributors.

        Regards,

        Thomas.

        (0) 

Leave a Reply