ABAP Tags Plug-in – Release 1.9
It’s been a while since I last wrote about any notable changes in my ADT Plug-in ABAP Tags. There have actually been a few releases in between this one and that last blog post I published, but only the last 4 minor releases have brought major changes with it, which all were released in the last 2 months.
It’s a common occurence when I get back into plug-in development after certain time. I start to implement one small feature, and say to myself that it will stay at one. But as always, I get triggered by something during development and other ideas pop up. And then it’s just, “hey, you are already in it, why not continue..”.
In the following sections I will describe every new and updated part, so all big changes that were introduced with version 1.6 up to the current version 1.9. So, do not stop reading, maybe now this plug-in provides exactly the features you have been missing since release 1.0 😉.
Go crazy with Tag Hierarchies
Let’s start with the component that received the biggest update of all. The hierarchical tags.
The first release already shipped with the option to create tag hierarchies. So you could create sub tags of arbitrary tree depth. The downside was, that until now you always had to choose a tagged object when assigning a sub tag to an object. The following screenshot shows such a typical scenario.
But sometimes, there just isn’t a valid or logical object dependency. You just want to categorize your tags in a tree structure, and assign your objects at the appropriate sub tag.
Let’s have a look at the following screenshot from the Tag Manager view.
This depicts a typical hierarchy where object to object relations during tagging wouldn’t make much sense. Of course, I possibly could find valid objects in the upper levels of the tag XSLT but essentially I only want to tag transformations that are used in backend ADT development.
So, with this restriction lifted, feel free to create any hierarchy you can think of.
But wait, this was not everything that changed in regards to hierarchical tags.
If you still have object to object tagging requirements and were annoyed in the past that you could assign only to one specific parent object, then you will be happy to hear that this restriction has been lifted as well. The following sample shows this, where we have 2 consumption CDS views that both select from the same interface view.
Last but not least, you can even skip some hierarchy levels. Consider that a given hierarchy is semantically always true, e.g. the typical modelling of an analytical CDS query view. Here we would have from top to bottom the tag hierarchy
Query > Aggregation > Cube > Interface > Private > Database
But there is not always an aggregation view between your cube and query. In the past you had to create 2 sub trees to realize that requirement, now you can just assign your tagged cube view directly to your tagged query view. Cool, right?
On to the next new feature. Some colleagues of mine had the requirement to tag local classes, especially test classes.
This required some special consideration as the information about which local class is stored in which global class is not stored in any database table – apart from the where-used-index which is not that easy to read.
At the end I could solve the problem with a mixture of reading the source code of the includes of the global class and RegEx matching to get the exact row and column of the local class definition or implementation (Row/Column information are needed so the navigation in ADT works correctly).
So, now you can tag local classes/interfaces of global classes as well. The options to tag a component are a bit restricted in comparison to tagging a standard repository object. You can only do this either via the context menu of the Outline view or the Project Explorer view.
As especially test classes may have the same name in many global classes (e.g. ltcl_abap_unit), I added the name of the owning global class at the end if you would run a Tagged Object Search for example.
Note: The color of the global class can be configured in the Eclipse color preferences.
For now, it is only possible to tag local classes/interfaces, but maybe in a future release it will also be possible to tag other components, like e.g. methods, types etc. – but no promises.
Browsing your tagged objects
The next feature came about during development. There is an Eclipse extension point in the Project Explorer view that I wanted to try out for a while and the tags provided me with a pretty good use case, so I thought I would try it out.
This resulted in a feature I conveniently named Tagged Object Tree. It follows the concept of the ABAP repository trees and displays an extra node under each ABAP project called Tagged Objects. The content of this node is loaded on the fly and then only the direct child content, so even if you have tagged thousands of objects it should not result in any kind of performance problems.
This gives you a most flexible way now to create object trees and browse these objects the same way as you would access objects via your favorite packages or other trees you have configured.
I have no concrete plans yet, but it is not inconveivable to make this single tagged object tree configurable similar to the ABAP repository trees.
Removing Tags from Objects
So enough of adding tags and browsing tagged objects. I also wanted to make the removal of tags from an object a smooth experience so I created also a wizard dialog for that. This wizard can either be accessed from the main Eclipse toolbar, the Tag Manager view, Object Tags view or the Tagged Object Tree.
Regardless where you start it from, at the end you should see a list objects from which you want to remove certain tags. If you selected a tagged object that still has tagged child objects than a removal of that tag will not be possible, which will be indicated in an extra Issues column of the table.
This wizard is also a good way to clean up tagged objects that no longer exist in the ABAP repository. So objects that were deleted but still tagged at that time. This is unfortunately not avoidable as there is not a clean way to plug in to the delete event to also remove the tags from that object at the same time.
The final clean up would be of course to delete the tags themeselves. In the previous version of the plug-in you only got a simple warning dialog before you could delete a tag and all underlying child tags.
This wizard gives a bit more safety. First of all, it is now no longer possible to delete any tags if there are still objects assigned to this tag or to any sub tag. So you first have to use the other wizard and remove the tags from those objects. Second of all you also get a warning indicator that existing child tags will be deleted as well.
That should cover all the major improvements of the last few releases. If you want to have a more detailed overview of all features or check out the changes from version to version you’ll have to install the plug-in and check out the included Eclipse Help content of the plug-in.
It is on my todo list to publish the complete feature list for all of my plug-ins on a different medium, but right now Eclipse Help is the only place 😉.
As with all other versions, please follow the installation procedures for the ADT backend of the plug-in on corresponding GitHub project site https://github.com/stockbal/abap-tags-backend. It is still compatible with all ABAP systems starting from 7.40Sp09.
To avoid any problems during installation please consider updating to the newest version of abapGit.
Migration to v2.0
Due the changes to the hierarchical tags I had to make some changes in the data model. Therefore, if you upgrading from an older backend version please execute the report ZABAPTAGS_MIGR_V2_0.
The plug-in frontend can be installed via the usual ways, i.e. Eclipse Marketplace or directly via my update sites (see https://eclipse.devepos.com/)
I hope some of these updates or new features made you curious and you will give this plug-in a try. Or maybe it gave you an incentive to create your own first plug-in. Trust me, it is really cool, and I am sure there are still many features that are not implemented in the ADT and are just waiting for a motivated developer.
And if none of these points adhere to you, then I hope that it was at least interesting to read. If so, please share it also with others who may not be frequent visitors here.