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.
Review
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
Glossary
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
At the moment there is no automated way to publish a new version of a plugin to the official plugin repo – according to their support page.
Spin-off: Let’s create a Jenkins plugin for this!
Use Idea’s built in diagram drawer
I used an another tool so far: com.github.ferstl:depgraph-maven-plugin. It was easy to integrate into a build process but it is not as handy as a fully integrated solution in an IDE.
Planning
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.
Epilogue
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.
András Tornai 