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
