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
