search

ibm-cloud-architecture / refarch-jee

This project provides a Reference Implementation for migrating existing Java EE applications from on-premise to cloud-based deployments, as well as migration to a microservices-based architecture.
Apache License 2.0
18 stars 21 forks source link

Asess: Duplicate or unused classes #4

Open dhvines opened 7 years ago

dhvines commented 7 years ago

The following paragraph is too strong and in some sense misleading and there is a typo higly => highly

As we can see in the report, there are several concerning facts such as duplicate or unused libraries we should pay attention to and which we higly recommend fixing before migrating your application to a newer WebSphere Application Server version and/or different IBM platform

Although it is nice to see these jar's there is really nothing that you can do with this information except to store it away as potential problems. It would not be advisable at all to simply start removing duplicate or unused classes. Remember that application worked with this collection or jars. So its best to keep these jars unless you discover some class loading issues during testing.

AND

After removing the unused libraries and verifying that this does not introduce any other problem/error in the code, we look at the ear structure, its ejb, web and test projects. We realise that there are several libraries being used by multiple projects but yet included in each of them as opposed to packaging them at the ear level as a shared library among all ear project components. After repackaging libraries at the ear level, this is how the inventory report looks like:

I would never recommend changing any jars based on this report ... you can only change the jars during the testing phase. For instance, there are many frameworks that do dynamic class loading. So the report may give incorrect information regarding unused jars .... Also, as mentioned remember that this app did work with the "as is" classes and packaging ... do not change it! the more you move away from the working app the more chances you have of introducing a crit sit ... again, only repackage or change jars based on resolving defects during testing ...

AND

We see now that both web projects and the ejb project look fine library wise. However, the report indicates that there are still several duplicate libraries. Looking in detail at what packages those duplicate libraries come with, we realise that, in effect, several libraries packages are included by others (normally broader and heavier Java libraries. For instance, the jackson-all library includes all packages the other three lighter and more specific jackson libraries come with). We then remove remaining duplicate libraries and run the report again: We see now that both web projects and the ejb project look fine library wise. However, the report indicates that there are still several duplicate libraries. Looking in detail at what packages those duplicate libraries come with, we realise that, in effect, several libraries packages are included by others (normally broader and heavier Java libraries. For instance, the jackson-all library includes all packages the other three lighter and more specific jackson libraries come with). We then remove remaining duplicate libraries and run the report again:

Never ever do that ...

AND

Again, we remove these libraries and run the report. This time, the report comes finally clean except from some warnings regarding missing dependencies on some projects/libraries.

No, no, no, Never do that ...

AND

We have repackaged and refactor our application structure to a situation were we do not have duplicate or unused libraries and the libraries we want/need to include are packaged in the proper location. At this point, we are now ready to start the migration to the newer WebSphere Application Server version or IBM Platform.

Don't repackage and refactor the app base on the unused libraries, etc.

jesusmah commented 7 years ago

@dhvines to me the inventory report is a very good tool in order to understand your projects structure in terms of libraries, technologies and versions. I would agree with you that the safest would be not to touch any of these libraries since the application is working as it is.

However, some of the libraries included in the projects were duplicated, others unused and others provided by WAS or some of its feature packs included. From a migration pov I agree that the least you touch the safest but from a software development best practices pov, the structure we initially had for the project was simply very bad. Having duplicated and unused libraries is not only a bad practice but it might introduce problems long term (specially if you have more than a bunch of problems)...

I do agree that we should not remove libraries and repackage the app only based on the inventory report but also applying intelligence to what the inventory report suggests and, above all, executing an exhaustive test process for these changes on your current WAS version and dev/test platform before moving on to migrate to a newer WAS version or IBM platform...

As I said, the inventory report has brought up an image of the project structure very valuable to me which I did not have just by looking at the code and testing the app before. Would it not make sense to recommend to leave libraries and packages as they are for migration but suggest to use the inventory report to look at potential 'not good software development practices' if you want to call it that way?

Thanks for your feedback beforehand.

dhvines commented 7 years ago

Agreed that the binary scanner is a good tool to introspect the archives and show you some information about their content without you having to unzip those archives to manually inspect it. Definitely create those reports and refer to them while you are doing the source code migration with WAMT.

But do not make any changes during the assessment for "good software development practices". Of course, I'm only talking about the lift and shift pattern or the like for like migration strategy. Some customers may require that you remediate a certain well-defined set of "technical debt" (e.g. wink); however that is not the classic "lift and shift" pattern.

Having said that, we always produce a report after we have completed a migration of the problems and the solutions that we encountered and the changes (to make post migration) to follow "good software development practices"