JavaOne – Maven BOF

“Maven 5 BOF”

Speaker: Brian Fox, Manfred Moser & Robert Scholte

For more blog posts from JavaOne, see the table of contents


[I was late because we talked more about JUnit 5 after the BOF]

Only 26.4% of Maven Central traffic is from Maven. Nothing else is more than 10% though; not even Ivy or Gradle

Some projects don’t have snapshots; instead every commit is a release

Talked about version ranges. Depends on proximity to your project rather than the latest version. Important to clean up pom dependencies before Java 9 so not in module path. Use Maven dependency plugin (analyze) to find unused ones. Make sure to use latest version of depedency plugin.

Maven won’t generate module descriptor. Different purpose. Not all modules are dependencies. More info in module descriptor. What to export is a decision that needs to be decided by developer. jdeps can generate a rough descriptor to get started based on binaries.

Can have .mvn file inside projects with preferences startig in Maven 3.3.5. For example, you can specify to provide more memory.

Shouldn’t be issues going from 3.3.5 to 3.5.9

Maven (dependency) resolver is now a standalone project

JavaOne – Project Jigsaw – Integration with Tools

“Project Jigsaw – Integration with Tools”

Speaker: Alexandru Jecan (author of Java 9 Modularity Revealed)

For more blog posts from JavaOne, see the table of contents


What expect build tools and IDEs to do

  • Code completion (IDEs only)
  • Make things easier
  • Work with class path and module path

Maven

  • Only Maven 3+ supports Java 9.
  • No changes to Maven core to run on Java 9
  • presence of module-info.java decides if Maven uses module path
  • Need Maven compiler plugin 3.6.1 to compile Java 9 code
  • Discourages using automatic module name
  • GAV not related to module name. Continue to use GAV.
  • Use module name in module-info.java – double work
  • Maven does not generate “requires” clauses for module-info.java
  • Can add <compilerArgs> options for -add-modules or -add-exports
  • New tag <release> which takes precedence over source/target tags. Recomended compiling twice or backward compatbility. once for java 9 modules and once for java 8. [why? isn’t that what multi release ars are for?]
  • maven-exec-plugin – can configure module path
  • taked abut updating maven toolchain file [not clear how this differs than prior versions of java]
  • maven-jdeps-plugin – can automatically generate module descriptor [but said earlier couldn’t]
  • maven-jmod-plugin – new plugin; not yet released. Creates and lists content of jmod files. Merge native code into jar
  • maven-jlink-plugin – new plugin; not yet released. Creates runtime images
  • maven-depdendency-plugin – said lists GAV [not clear how changed

Gradle
No first class support for Java 9 yet. Coming soon. [but said using; puzled?]

Ant
Ant 1.9.8+ support JDK 9 modules for java/javac/junit. [yet Ant doesn’t support JUnit 5]

Loom

  • New build tool for Java 9
  • Uses YAML config. Uses Maaven repo.
  • Supports JUnit 5,

loom.builders

Moditect
Maven plugin that generates module-info.java based on dependencies. Says helps a little but doesn’t do all the work. [how?]

SonarJava
SonarJava 4.11+ recognizes module keywords

Graphviz
Open source visualization software
Reads jdeps input to generate graphical representation of Jigsaw. As can IDES

IDEs

  • NetBeans, Eclipse and IntelliJ all understand modules clauses [if you count pre-release versions]
  • Also offer autocompletion, syntax higlighting, etc
  • NetBeans 9 – not yet released; must build yourself. Showed editing module path, visual of module dependencies, jshell, jlink
  • Eclipse Oxygen with Java 9 support – came out 9/27/17. Ten second demo
  • IntelliJ 2017.1+ – Mark directory as source root so directory name matches module name. Errors on common module errors, Showed module editing, module dependencies and other features

Open source readiness

How to modularize your app

  • Introduce modue-info.java by creating manually or running jdeps to generate
  • Problems: using JDK internal APIs (ignore warning or fix), using odule not availalbe such as xml bindings (add-modules at compile and runtime), cyclic dependencies (can have at runtime but not compile time), split packages (Oracle plans to make change in later version of Java to deal with this)
  • [Note: He recommended renaming packags as a solution to spit packages. That sounds like a horrible idea unless you can guarantee only you call that code]

    My take before session: You know how they say that first impressions matter? The speaker is wearing a suit. 90% of the people in the room are wearing jeans. Two people in the room are wearing a suit The speaker and someone he knows. Then he showed the table of contents. There are 29 points in 45 minutes in the outline. Preparing to have my head spin!

    My take after session: He is in fact technical. The suit was misleading! The pace was way too fast though; drinking from a fire hose. Not enough time to understand/process many of the points. He talks fast (as do I), but key is to *pause* if you talk fast so people can catch up. Also the side transitions were distracting. A cube transition is cute. But if you are reading when it moves, it is disorienting. And due to the speed, there was a good chance of being reading when transitions started. This was good information, but should have been two sessions so split up and a decent pace. And omiting how to migrate your libraries; that’s a talk on its own There is a Maven BOF tonight; maybe folks can discuss more then!

    One minute after the official end time, he asked if there were questions. My head was spinning with questions. [I didn’t even have time to process which was most important]. Another attendee asked if having JUnit tests in a parallel directory with the same package name is a split package. The speaker said yes and went on to say to wait for Java 10 or rename. I interjected at that point. Unless you are distributing a test jar, I don’t think this is a problem. In fact, most IDEs compile both the /src/main/java and /test/main/java directories to the same folder. I stated this and asked the speaker if he agreed. He said yes.

JavaOne – Apache Maven and its Impact on Java 9

“Apache Maven and its Impact on Java 9”

Speaker: Robert Scholte

For more blog posts from JavaOne, see the table of contents


Up until Java 8, Maven goes fine on top of Java. In Java 9, there is overlap.

Review of Maven

  • Dependency management
  • All about pom.xml
  • All about classpaths
  • Generate project information

Module path mismatch

  • Classpath accepts – output dirs, jar files and zip files (Maven doesn’t support zip files)
  • Module path accepts output directories, module output directories and directories with jars [and jars; keep reading]
  • Options included pointing to diretory containing the jar (but contains other things to), symlins (windows unhappy), create lib directory and copy files (a lot of IO)
  • Java 9 team added specifying direct jar files per Maven’s request

Module names

  • Like problem with group id/artifact id
  • Need to be unique
  • Learned over 30K artifact ids end with a number. This was a problem for automatic module names because many woul have same name creating collision. ex: commons-lang2 and commons-lang3
  • Also, many artifact ids are naming conflicts if ignore group id. Which is problematic for automatic module names when use two jars that collide
  • Made difference between library builders and app builders. Standard that library builders should never refer to automatic modules. If no exports, can assume it is an application. And apps have control of what gets used.
  • Maven gives warning if library refers to automatic module usage. (use Maven 3.+ so warning shows up in color

Dependencies not yet modular

  • If you are dependent on open source library and it is dependent on one that isn’t modular (or the depenency changed the module name), the direct dependency can’t migrate to modules yet
  • Solution: use Automatic-Module-Name to manifest of libraries so not using algorithm. A good bridge

Tips

  • Point of no return – each time you refer to a dependency that is a module, you can’t go back to a previous version that does not
  • Don’t have split packages if can (Maven itself has a split package issue for old compatibility classes)
  • Don’t have classs in the root package
  • Provide your future module name in the manifest
  • Use a unique module name
  • Don’t change folder structure to add module name
  • plexus-java can help plugins build path
  • Classpath isn’t going away. The older the project, the harder it will likely be to migrate to modules

release tag
In addition to source/target 1.9, you can specify <release> to indicate compatiblity
Can use animal-sniffer to determine if code compiled on a newer version of Java in an older JDK mode will ctually run.

Module file
Maven doesn’t generate. Requires human input. Not all modules are dependencies. jdeps can do it because has access to binary files. But need before compile at build time so not compiling twice

My take: Interesting problems and solutions. I feel like he takeaway is “don’t upgrade to Java 9 yet”. The font was small on the screen. Even when there aren’t a lot of words on the screen