Re: Multi-module Maven projects and Scala-aware artifact IDs

[Hervé Boutemy]

> Guava has -jre
> and -android flavors on their artifact ID instead of using classifiers.
not exactly, they have the flavor as part of version string

https://central.sonatype.com/artifact/com.google.guava/guava/32.0.1-jre/
versions

which in fact looks like what François describes in another answer to the 
thread

Regards,

Hervé


Le lundi 12 juin 2023, 19:30:12 CEST Greg Chabala a écrit :
> Sure, individual projects have done things as they saw fit. Guava has -jre
> and -android flavors on their artifact ID instead of using classifiers.
> Bouncycastle is using ant for their build process. I wouldn't want to
> emulate either as best practice.
> 
> Scala, as an ecosystem, has decided on "_binaryVersion" appended to
> artifact ID, which feels gross.
> 
> The Maven POM reference ( https://maven.apache.org/pom.html ) is pretty
> clear: "The classifier distinguishes artifacts that were built from the
> same POM but differ in content. It is some optional and arbitrary string
> that - if present - is appended to the artifact name just after the version
> number. As a motivation for this element, consider for example a project
> that offers an artifact targeting Java 11 but at the same time also an
> artifact that still supports Java 1.8."
> 
> Binary compatibility versions are noise that should be in the classifier,
> if you're building from the same source tree, it only needs one artifact ID.





-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Multi-module Maven projects and Scala-aware artifact IDs

[Francois Marot]

Hello Florent,

i'll suggest something while I know this is not exactly what you asked for.
But i'll try nevertheless, it may help :)

If you could change your requirements a bit to change the *version* instead
of the artifactId, then you could use the
ci-friendly concept in Maven (
https://maven.apache.org/maven-ci-friendly.html ). This in conjonction with
the flatten plugin
that ensures pom.xml are correctly alterned before being deployed could
help to have something quite similar to what you asked.

So my idea is to run a command similar to:

mvn deploy -Drevision=1.2.3-2.12
or
mvn deploy -Drevision=1.2.3-2.13

The consumer of your artifacts would have to update the version as well as
the artifactId, but they are usually colocated so it may be acceptable.
This is compatible with multi-module Maven projects where each child just
reference the parent pom with the ${revision} variable.
Hope this helps

François


Le lun. 12 juin 2023 à 15:21, Florent Biville  a
écrit :

> Hello,
>
> I'm working on a multi-module Maven project where part of the artifact ID
> includes the Scala version it is built against (2.12, 2.13, ...), as it is
> common with Scala projects, since Scala minor version bumps often break (or
> so I read).
>
> I'm currently trying to fix the project setup, since it relies on dynamic
> expressions in some of the module artifact IDs to achieve the above effect
> and that does not really work (and litters the build with warnings,
> rightfully so).
>
> My current approach is to script the whole thing, something like
> "./build-for-scala.sh 2.12" or "./build-for-scala-2.13". Sprinkle some sed
> and it kinda works.
>
> However, it is very fragile. Not only must the module artifact IDs change,
> but so must any reference to the parent POM and the artifact ID of each
> dependency sibling.
>
> Reading about this problem led me to
> https://stackoverflow.com/a/35023562/277128 but the solution is not very
> compelling.
>
> And of course, since that's an established project, I cannot afford to
> change the artifact IDs before the next major version.
>
> I would not even mind writing my own plugin or extension if that could
> solve this particular dynamic artifact ID resolution.
>
> Has anyone faced this before? How did you manage to solve this problem "the
> Maven way"?
>
> Best regards,
> Florent
>

Re: Multi-module Maven projects and Scala-aware artifact IDs

[Greg Chabala]

Sure, individual projects have done things as they saw fit. Guava has -jre
and -android flavors on their artifact ID instead of using classifiers.
Bouncycastle is using ant for their build process. I wouldn't want to
emulate either as best practice.

Scala, as an ecosystem, has decided on "_binaryVersion" appended to
artifact ID, which feels gross.

The Maven POM reference ( https://maven.apache.org/pom.html ) is pretty
clear: "The classifier distinguishes artifacts that were built from the
same POM but differ in content. It is some optional and arbitrary string
that - if present - is appended to the artifact name just after the version
number. As a motivation for this element, consider for example a project
that offers an artifact targeting Java 11 but at the same time also an
artifact that still supports Java 1.8."

Binary compatibility versions are noise that should be in the classifier,
if you're building from the same source tree, it only needs one artifact ID.

Re: Multi-module Maven projects and Scala-aware artifact IDs

[Delany]

Bouncycastle does similar, e.g. bcprov-jdk15to18-173.jar

https://www.bouncycastle.org/latest_releases.html

Delany

On Mon, 12 Jun 2023 at 18:51, Greg Chabala  wrote:

> >
> > Has anyone faced this before?
> >
>
> Yes. The fact that Scala's binary incompatibility leaked into artifact IDs
> rather than being a classifier irritates me still.
>
> I have no good solution for you. The mess that would have come from using
> Maven for cross version Scala builds led me to follow the status quo of
> using sbt for Scala projects. The question you linked is a good summary of
> the compromises.
>
> My belief is that if sbt didn't exist the Scala community would have been
> more motivated to improve this, with different artifact naming conventions
> and/or improvements to Maven.
>
> Greg
>

Re: Multi-module Maven projects and Scala-aware artifact IDs

[Greg Chabala]

>
> Has anyone faced this before?
>

Yes. The fact that Scala's binary incompatibility leaked into artifact IDs
rather than being a classifier irritates me still.

I have no good solution for you. The mess that would have come from using
Maven for cross version Scala builds led me to follow the status quo of
using sbt for Scala projects. The question you linked is a good summary of
the compromises.

My belief is that if sbt didn't exist the Scala community would have been
more motivated to improve this, with different artifact naming conventions
and/or improvements to Maven.

Greg