2

I'm currently trying to find a suitable workflow to execute refactorings across multiple Maven projects, but I cannot find any satisfying solution.

Suppose there are three projects. One project called common and two dependent projects called app1 and app2. Each on a separate Git repository.

Now suppose that a method in common called StringUtils.trim() shall be renamed to StringUtils.getTrimed(). Because this method is used by app1 and app2, those projects need to be adapted, too.

Now, the question is, what is the correct workflow to provide this modification to the development team. Given this situation: A team of about 10 developers with a central SCM server and a central Maven repository server to host the artifacts.

Possible work-flows:

  1. Just commit the changes to the SCM (for all three projects) --> Problem: Developers working on app1 for example probably don't have project common checked out, but are using a binary from the central artifact server. When they fetch the newest version of app1 from the SCM, their build will break. BAD!

  2. Additionally to 1, change the dependency of app1 to point to the SNAPSHOT version of common. --> Problem: When the developers working on app1 fetch the newest version from the SCM, they probably won't get the latest SNAPSHOT of common, if the update policy is set to DAILY (which is the default). BAD!

  3. Additionally to 2, change the update policy for SNAPSHOTS to ALWAYS. --> Problem: Now, the developers of app1 will get the latest SNAPSHOT of common and everything is fine, but only if the SNAPSHOT is deployed to the artifact server before I commit the changes to app1! Furthermore, there is a time period, between the deployment of the common project to the artifact server and my commit of app1 to the SCM. If the developers fetch the latest SNAPSHOT of common, it will be incompatible with the current version of app1 in the SCM, since I have not committed the changes to app1 yet. BAD!

The only workable solution I can come up with is to skip the SNAPSHOT mechanism and work with versions. Here is the work-flow:

  • After changing the three projects locally on my machine (before any commit), increase the version of common from say 1.0 to 1.1.
  • Commit common to the SCM and deploy it to the artifact server.
  • Only after the deployment is done, change the dependencies in app1 and app2 to point to the new version of common and commit app1 and app2.

Problems with this approach: I have to do version management, so this can only be done in coordination with the whole team and considering all dependent projects. Additionally, I have to wait for the common project to be deployed to the artifact server before I can commit my changes to app1 and app2.

Isn't there any easy and flexible mechanism, how to execute such refactorings? I hope that someone can help me. Maybe there is also some misconception on my side.

user1670954
  • 21
  • 1

4 Answers4

0

I don't think you will find an easy way of doing refactorings if they are of the type that you suggest in your example. What you basically have here is a third-party dependency from app 1 & 2 to common. And, as you might have noticed, third party dependencies do not change the name of their interface methods very often, for a good reason - it would be hell for anyone trying to update to the latest version.

I would suggest that you keep the names of your interface methods to a as high degree as possible, there should be something terribly wrong with the name in order for it to change (the name states that it does something it doesn't or vica versa). Wanting to change "trim()" to "getTrimmed()" is not good enough reason to do so.

So, my suggestion would be this:

Do all the refactoring that you want in the internal parts of common, keep the interface as is. If you really have to rename something, make a duplicate of the method in question with the new name, mark the old one as deprecated, and keep them both alive for a period of time, until it is reasonable to assume that everyone has started using the new one, and stopped using the old.

Tobb
  • 11,850
  • 6
  • 52
  • 77
0

I would recommend you an OpenSource tool like Sonar (sonarsource.org)

Switch
  • 14,783
  • 21
  • 69
  • 110
0

Depreciate the old method names and refer the calls to the new method names. Then you have a time window to work with both. Just then ask the development teams to check for depreciated methods every X and after a fixed time drop the depreciated in a future release.

JoeyBoy
  • 1
0

Yes. Use versioning. For minor version upgrades, keep the old method in place and mark it as deprecated. Document your changes to the interface in the release notes of the common project.

flup
  • 26,937
  • 7
  • 52
  • 74