On Mon, 19 Dec 2022 at 01:15, Gilles Sadowski <gillese...@gmail.com> wrote: > > 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"),
Actually there are still some components that have a different groupId, e.g. commons-net commons-io commons-logging There are several others. [Of course these cannot be changed without breaking binary compatibility; they would require major version updates and a package name change.] > 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). Indeed, that's my point. But one cannot change the artifactId purely to match some convention, as appeared to be suggested else-thread. > Gilles > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org