Technology Blogs by Members
Explore a vibrant mix of technical expertise, industry insights, and tech buzz in member blogs covering SAP products, technology, and events. Get in the mix!
cancel
Showing results for 
Search instead for 
Did you mean: 
SandipAgarwalla
Active Contributor
4,902

With the latest version of SAPUI5 1.38, SAP has punched out a shocker. If you are not aware yet, the entire sap.ui.commons, sap.ui.ux3, and few other libraries are marked as deprecated. Here is the snapshot of the announcement from the release notes of 1.38

That might mean, these libraries will not receive any further improvements and will be removed from the SAPUI5 Runtime sometime soon. It’s been hardly 4 years since it came out and its already deprecated!!! Wow, this is some agility. Now the question – When these libraries will be removed and what will happen to the applications which were built using sap.ui.commons library? The speed at which SAPUI5 versions are updated, my personal feeling is that the commons, ux3 library might be removed by end of this year.


During the later part of 2012 and early 2013 - when SAPUI5 was still evolving and sap.m library was still maturing, many of the clients went for sap.ui.commons based applications. I am sure some of you may be in a similar situation. These applications were mostly meant for Desktop, had multiple screens, lot of information and they did their job perfectly.


Now what’s the future of these applications? Do these applications need to be re-developed using sap.m controls? If yes, then the planning for the re-build has to start sooner than later. I think SAP needs to answer by when these commons, ux3 libraries will be removed from the packages.


One of my client regularly update their SAPUI5 version on the Gateway server, so as to get the latest features. So I do not really want them to see one fine morning that these applications are not working anymore. We need an answer from SAP on the future of these libraries. WHEN??? So that we can inform our clients and can start the mitigation plan.

What happened to the commitment from SAP that they will keep providing 2 separate libraries? I understand maintaining/developing 2 separate libraries may be an overhead but <4 years is too low a shelf life.

Is this cool or what??? | SCN

Will the same thing happen with sap.m libraries :smile:   It does not look like, but especially the announcement of SDK for iOS Fiori has convoluted the things. What’s next – I keep guessing.


Can you really recommend a Front-End road-map for your clients for the next 3-4 years? Go for sap.m based fiori type applications, no wait there is a Fiori iOS SDK coming up. No Wait...

P.S. - I absolutely love the sap.m controls, they are fantastic and are the way to go forward. But I would like to know by when these will be removed.

Your feedback, inputs are always welcome.

Regards

Sandip

12 Comments
former_member184221
Contributor
0 Kudos

As its not the 1st April, then I guess we must believe this article. What a shocker !

Former Member
0 Kudos

Sandeep,

Thanks for bringing this up.

But in my opinion deprecated doesn't mean they will be deleted, but as you stated .. the way SAP is moving we MIGHT see this happen.... not a good news for both developers (us) and clients as well.

So, i've had a same question on slack-chat (few months back) with openSAP team, they CONCLUDED saying the deprecated APIs are not going to be removed. I hope this is a TRUE statement, otherwise SAP can share the roadmap or give us the direction towards the API Lifecycle Management.

Bottom line, there are lots of new features on the recent versions, if you want them... you need to upgrade, and challenge with upgrade is you need to rebuilt your existing apps... customer is :-((((( so do we.

Hopefully they are not deleted just like that, someone from SAP could share the roadmap on the API lifecycle.


Thanks, MS

SandipAgarwalla
Active Contributor
0 Kudos

MS,

That's excatly the point. We need answers from SAP whether they will keep these libraries in deprecated mode or will remove them soon.

Regards

Sandip

mantrishekar
Active Participant
0 Kudos

Hi All,

What happens if we(developers) use deprecated libraries?

How it is going to effect the client as well as Developer.

Earlier we have a library called sap.m.DateTimePicker in which it has both Date and time selection in one field which is deprecated.but SAP did not provided any alternative for that.

Why SAP Deprecates libraries once after releasing it?

Lets assume if sap.ui.commons.layout.MatrixLayout is deprecated.but still i want to use this library but i doubt it might create any problem in further future.

Now what is the alternative for me to get the functionality of Matrix Layout.

Regards,

Shekar.

ChrisSolomon
Active Contributor
0 Kudos

This is not uncommon if you are used to using any other web development frameworks/libraries.

As for you and your apps, being "deprecated" does not mean your apps should stop working. You "should" already have a "local" copy with your production distribution....so it should still work just fine. As long as you are not relying on a public CDN, I don't see the possible problems. The only other concern I would have is any dependencies, but even then, if you dist is packaged already, I don't see the issue. I would just look at moving your next "version" of your app to a newer, supported version....which might take a little time but your software should be evolving anyways. Worse case, you might have to "customize" the library itself to meet your needs/work correctly.

SandipAgarwalla
Active Contributor
0 Kudos

Hi Chris

You "should" already have a "local" copy with your production distribution....so it should still work just fine. As long as you are not relying on a public CDN,

I did not quite get it. We do not reply on public CDN, rather on the Gateway UI. And our production gateways also get updated. So what if in one of the UI5 version, the commons library is removed, how would the application run? How would a local copy help here?

regards
Sandip

Qualiture
Active Contributor
0 Kudos

Since the SAP SRM UI Addon uses sap.ui.commons instead of sap.m, this *might* be an issue with future upgrades... or is it planned the SRM UI Addon will be revamped to sap.m libraries as well?

Anyway, I applaud SAP for taking this bold move, and phase out these unresponsive controls and layouts (I myself can't even remember when I used ux3 / commons libraries for the last time :wink: )

Matt_Fraser
Active Contributor
0 Kudos

Do we know what the future of SRM UI Addon is, in light of the SRM Fiori Addon? Will the UI Addon receive continued development, or will SAP nudge customers toward Fiori as the UI5 SRM interface of choice?

former_member182862
Active Contributor
0 Kudos

IMO, they should not be removed. They are just deprecated.

I will try to get hold of SAPUI5 core team to respond to this.

Thanks

-D

StefanBeck
Product and Topic Expert
Product and Topic Expert
0 Kudos

Hi folks,

to start with the most important statement: the deprecated libraries will not be removed during the next 3 years. The release 1.38 itself has an extended maintenance window of min 2 years and during this period, the libraries must not be removed for legal reasons. SAPUI5 already started internally to build/release 1.40 and the next stable version is most likely 1.44 that still will have the deprecated libraries. That means once shipped roughly in the middle of the first half of 2017, this will give you an additional 2 years maintenance.

Our intention is to indicated that all newly built applications should avoid to use these libraries and that you should start to think of a migration plan to the sap.m-family over the next years for existing apps. The reasons is that these deprecated controls will not be developed further and slightly fall back behind the other controls product standards wise or will potentially not get new themes.

To avoid the size of SAPUI5 growing more and more, the option to create a quarantine package that must be separately installed is under discussion. This would come in combination with a reduced support offering being only very high OSS tickets/showstoppers. Realistically, these are the 2 major consequences that might come and even they allow in theory to preserve the current app status until end of maintenance.

Anyhow, the official recommendation is to start planning and execution of the migration of existing applications to the sap.m-family within the next 3 years to be on the safe side. Otherwise these applications will not profit from future SAPUI5 improvements and start to look odd when running together with other apps in the same FLP. However, seen from the other angle: the status quo of these existing apps will be kept and not actively destroyed.   

I hope this clarifies the situation.

Best regards

Stefan

SimoneMilesi
Active Contributor
0 Kudos
To avoid the size of SAPUI5 growing more and more, the option to create a quarantine package that must be separately installed is under discussion

This would be a really nice solution for who has many apps relying on Commons and with few resources (time, people, founds) to work on a migration

SandipAgarwalla
Active Contributor
0 Kudos

Dear Stefan

Thanks much for your reply.

Its's good to know that the clients will get around 3 years to move the apps to sap.m libraries. We have already started the discussion on moving the existing and old commons apps to sap.m within a year or so but I was worried if the commons library would be removed much before expected.

Thanks again for the clarification.

Best Regards

Sandip

Labels in this area