![]() ![]() The most common case of this has been driven by the JCP. There can be a situation where the equivalent code is released twice for license reasons. This makes sense, because the module name is an aspect of the bytecode, not of the deployment.Īs before, the build tool needs to be setup to pick the correct jar file artifact, this time choosing between the patched one and the original.īuild tool must pick either the original artifact or the patch for the runtime JPMS module graph If it didn't it, it would be no use as a patched version.Įxactly the same rationale applies to the module name - the module name of the patched version needs to stay the same. The patched version still uses the same package name. ![]() If you want to publish a patched version of an open source project, the standard way to do this is to use your groupId, not the original groupId. In extreme cases, we have to publish the bug-fix version to Maven Central. Sometimes, we have to fix it and have a private copy of the library (ie. We've all run into the problem of finding a bug in another library, such as one on Maven Central. With Java SE 9 we can say that Maven is picking one artifact from a set of artifacts to use in the runtime JPMS module graph.īuild tool must pick one of these artifacts for the runtime JPMS module graph Maven already manages versions of course, picking one version from a set of versions, where all with the same groupId:artifactId. Maven.īut while the classpath will tolerate having two versions of the artifact (typically with bad consequences at runtime), the JPMS modulepath will refuse to start if there two modules contain the same package, as would happen if two versions of the same module are found. This will typically be the build tool, eg. Therefore, when assembling a modulepath for Java SE 9, something else is going to have to choose the correct version of the module. Given this, what is the mapping between an artifact and a module?Įach version of a project will consist of a different artifact (jar file), perhaps released on Maven Central.Įach version will have the same module name.īut, we also know that the Java platform (JPMS) does not know about versions or version-selection. This is just like package names - projects don't change package name with every release. Secondly, lets assume that a project is going to have the same module name over time. We are interested primarily in the bytecode for this discussion. For a project on Maven Central, this includes jar files of bytecode, jar files of sources and jar files of Javadoc. An artifact is a file produced when developing software. If you want to grasp what JPMS modules are all about, it turns out that it is critical to understand what they are not.įirstly, lets define an artifact. Other articles in the series are Module basics and Module naming. This is the next article in a series I'm writing to help make sense of the Java Platform Module System (JPMS) in Java SE 9. ![]()
0 Comments
Leave a Reply. |
Details
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |