Niceties in my life: participating in an another superb wedding party, settling down in an almost new apartment in the heart of the preferred area – Grüezi von Opfikon! – and assembling furnitures there. I dedicate this post to my favorite piece of equipment: Nespresso Inissia and its invigorating effects.
The cover image was taken of the Kapellbrücke during our recent small trip to Luzerne.
Now I have a small bunch of tests so I have a continuously growing and living specification. The following scenarios are supported:
- moving dependency to a new/existing module (sibling, parent, child)
- moving all java classes depending – even transitively – on the what if the from does not provide the referenced classes by any other dependency
- resolving properties in maven coordinate (groupId, artifactId, version) tags even if there are inherited properties
- dependencyManagement is taken into consideration
- preliminary check: to might contain what but in this case the version must match otherwise the user is asked to resolve the conflict first
- give insight to the user about the completed operations via Intellij’s Event Log panel
what: trivial, the dependency you want to move
from: trivial, the maven module that includes the what
as/to: as is referring to a new, non-existing module while to is marking an existing one
parentTo: the parent of the as/to module
Small lessons learned
Do not use together two dependencies where both contain a class with the same FQCN
com.google.collections:google-collections:1.0 and com.google.guava:guava:18.0 both contain class com.google.common.collect.Iterables with method: void removeIf(Iterable, Predicate). In google-collections it has no modifier so its package-private while the guava provides this as public. This caused a runtime Error sometimes because the classloader found the stricter one:
java.lang.IllegalAccessError: tried to access method com.google.common.collect.Iterables.removeIf(Ljava/lang/Iterable;Lcom/google/common/base/Predicate;)Z
Spin-off: It should be an easy task to implement a validator by reusing the existing code to cover this scenario but at the moment I do not want to lose the focus.
No automated way to publish to JetBrains IntelliJ IDEA Plugin Repository
Spin-off: Let’s create a Jenkins plugin for this!
Use Idea’s built in diagram drawer
Focus on splitting Java classes:
ClassAB depends on DepA and DepB. Let’s move DepB to an another module: split ClassAB into two: ClassA remains in the same place but ClassB must be moved to the new module. Update the dependencies of other modules, fix imports and references in Java classes. The code must compile after the transformation.
Do not think that even the highlighted scenarios are all well-rounded. I track all popping up idea within a Google spreadsheet and it is growing super fast. The more I work on this project the more idea I have and the more I realize how much I do not know about Java and Maven. Most of the time I have nothing but a dim and uncertain assumption.