Le lun. 19 déc. 2022 à 01:13, sebb <seb...@gmail.com> a écrit : > > On Sun, 18 Dec 2022 at 23:53, Gilles Sadowski <gillese...@gmail.com> wrote: > > > > Le lun. 19 déc. 2022 à 00:17, Alex Herbert <alex.d.herb...@gmail.com> a > > écrit : > > > > > > On Sun, 18 Dec 2022, 23:06 Gilles Sadowski, <gillese...@gmail.com> wrote: > > > > > > > Le dim. 18 déc. 2022 à 23:10, Alex Herbert <alex.d.herb...@gmail.com> a > > > > écrit : > > > > > > > > > > I think the name for the distribution archive is collected in: > > > > > > > > > > dist-archive/src/assembly/[bin|src].xml > > > > > > > > > > These use ${project.artifactId}-${project.version} by specifying the > > > > > <baseDirectory> tag. > > > > > > > > > > So renaming the artifactId for the dist-archive in the pom.xml from > > > > > commons-math to commons-math4 fixes this. > > > > Commit e2dd8f1a0d559967a0f9a3cd538b96d66561adc6 (in "master"). > > > > > > > > > > Thus the "mistake" is in the definition of <artifactId> in the > > > > "dist-archive" module: By the current convention, it must be > > > > "commons-math4". [Similarly to the <artifactId> of module > > > > "commons-math-core" being "commons-math4-core".] > > > > > > > > Now I wonder: Is this distinction (with or without the "4") really > > > > necessary in what the elements are used for? > > > > E.g. for the file names referred to in the previous message: > > > > commons-math-4.0-beta1-bin.tar.gz > > > > vs > > > > commons-math4-4.0-beta1-bin.tar.gz > > > > why is the latter better than the former? > > > > IOW, the "4" is redundant since it is present in the "version" > > > > string. So why keep track, in the POM files, of distinct strings > > > > "commons-math" and "commons-math4" if wherever they are > > > > used, the "version" string is also used? > > > > > > > > Hence, could we adopt a new, less error-prone, convention that > > > > will be simpler: <artifactId> is always composed of the string > > > > "commons", a hyphen, and the name of the component, > > > > irrespective of version? > > > > > > > > > > > > > I don't know the history here but looking at commons Lang the download for > > > the 2.x line does not have lang2 in the name but for the 3.x line it does > > > have lang3. > > > > > > https://commons.apache.org/proper/commons-lang/download_lang.cgi > > > > > > I thought the artifact id was used in commons to match the package name. > > > > That is the reason, indeed. > > > > > So > > > you can import math3 and math4 artifacts. So it is important for jar > > > artifacts. > > > > Ah, yes. > > > > > > > > But for the distribution module having the math4 is redundant, but also > > > harmless to keep it included. > > > > Sure. And if the <artefactId> must be different (so that several > > "different" > > libraries can be fetched through maven), then it is better to be consistent > > in the naming; thus arriving at the current convention (even though it is > > redundant in the case of the distribution files). > > Group Id + Artifact Id are the Maven co-ordinates used to distinguish > different release families. > > Java does not allow multiple classes with the same full classname > (i.e. including the package) on the same classpath. > > So Maven does not allow multiple jars on the same classpath with the > same co-ordinates. > > It is vital that there is a one-to-one correspondance between Java > classname and Maven co-ordinate. > Change one, and you must change the other to avoid the possibility jar hell.
Yes; but I think that we were not discussing a potential issue with the contents of an artefact, but how it can be fetched as a dependency. Leaving aside <groupId> (that is the same for all "Commons"), maven will only ever download a single item for a given <artifactId>, even if the contents would not cause JAR hell; and, for that matter, it would also download a item with a different <artifactId>, even if its contents would cause JAR hell (that's why we adopted the rule, external to maven, that a new major version should come with a change of the top-level package name). Gilles --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org