Le jeu. 27 août 2026 à 14:56, Martin Desruisseaux via dev < [email protected]> a écrit :
> Le 27/08/2026 à 14:15, Romain Manni-Bucau a écrit : > > > Hmm, maybe I misread the diff but AFAIK current PR does only violate > > artifactId value by overriding it silently by the module id > > No. When compiling a multi-module project, javac writes the output of > each module in a directory having the module name (this is standard > javac behavior, not something invented by the work on Maven module > support). The pull request detects this situation and generates a JAR > for each module. Because the result is many JAR files (one per module), > we cannot use a single artifactID anymore. The name of each module is > used as artifactID. The plugin also generates the corresponding pom.xml > for each JAR. > > Just to clarify your "no" means "yes" there until I misread your answer. To try to make it simpler: do your java module have the same name than the artifactId in the pom? if "no" then we have a design issue until we drop the artifactId concept else it is ok and I just miss something. > > > inconsistencies with other plus (sources, javadoc etc - agree we could > > align them but also think we should stick to our model and not > > disrespect it). > > We will need to align them, otherwise we cannot support multi-module in > Java sense. It is already on my roadmap after JAR. > Did you already do the exercise to solve it for deploy plugin? this is the one highlighting this issue and current convention is not very satisfying for me even if we can promite a workaround everywhere - hope we don't. > > > > I'm also a bit worried on the coordinate -> file names vs java modules > > File name is Java module name + version number and eventually other > stuff (type, etc.) if we want. > This is only valid if you never resolve the artifact else you do 1. pom 2. from(pom) -> metadata.xml when remote, direct filename locally 3. you're doomed today (and we can't change metadata and local metadata easily since we must work woth maven 3 and other consumers). > > Martin > >
