I just replied to this, or at least I thought I did, but my mail client says differently, so I try again.
> So if youI did not deploy your artifacts somewhere, it may be a problem I did not think about that! You have a point! All I want to do is to provide binaries for JDK level 11 and also latest JDK level supported by Groovy. This preferably without having duplicated sources! I just got a potential idea, that I'm not going to explain until I tried it and it turns upp working ... I have a maven repo at repsy.io that I can test against. I also have a public repo there for all my open source binaries. So if I screw up I only screw up my stuff :-). Thanks for replies! ______________________ Tommy Svensson to...@natusoft.se Från: Francois Marot <francois.ma...@gmail.com> Svara: Maven Users List <users@maven.apache.org> Datum: 7 april 2024 at 22:45:26 Till: Maven Users List <users@maven.apache.org> Ämne: Re: Will this potentially break in future releases ? Hello Tommy, Lasse and all, as Lasse suggests it *may* be a good fit for classifiers. But I want to emphasize that to my knowledge, the miscellaneous artifacts with different classifiers sharing the same 'main' artifact HAVE TO BE INSTALLED OR DEPLOYED AT THE SAME TIME. So if you deploy your artifacts somewhere, it may be a problem. If you keep on relying on the version (or artifactId) to differentiate the artifacts, you may also face problems in case you deploy your artifact on a repository to be consumed by others: you will currently produce an invalid pom.xml which is unusable by others. You have to use the flatten maven plugin and configure your build correctly to produce a "patched" pom where the version is replaced. You may find more info here https://maven.apache.org/maven-ci-friendly.html (Maven 3) or in a recent blog post from Karl Heinz Marbaise here for Maven 4 (which do not require flattening the pom): https://blog.soebes.io/posts/2024/03/2024-03-31-maven-4-part-i/ Hope it helps Francois Le dim. 7 avr. 2024 à 19:28, Lasse Lindqvist <lasse.k.lindqv...@gmail.com> a écrit : > Even if putting the bytecode version in the version works, you should > consider using classifier field instead. See for example > https://www.baeldung.com/maven-artifact-classifiers > > su 7. huhtik. 2024 klo 20.22 Tommy Svensson (to...@natusoft.se) kirjoitti: > > > > These days I'm *only* coding in Groovy since it is such a nice, painless > language and most of my GitHub code is in Groovy. > > > > Groovy does a lot different than Java, one such difference is that you > can now select what bytecode level to produce when building, this > independent from the source. That is, the same source can be built for many > different byte code levels without any changes in source code. You just > select at what bytecode level you want the binary to be. > > > > I want to be able to build binaries for multiple bytecode levels and > thus I'm doing this: > > > > <project xmlns="http://maven.apache.org/POM/4.0.0"; > > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; > > xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 > http://maven.apache.org/xsd/maven-4.0.0.xsd";> > > <modelVersion>4.0.0</modelVersion> > > > > <parent> > > <groupId>se.natusoft.seagull</groupId> > > <artifactId>Seagull-APIs</artifactId> > > <version>1.0.0</version> > > </parent> > > > > <artifactId>Seagull-Internal-APIs</artifactId> > > <version>${parent.version}_${bytecode.version}</version> > > This actually works! I do however get warnings about using variable > expressions in version tag. > > > > Will this feature potentially go away in future versions of maven ? > > > > My goal is to be able to produce same code at different byte-code > levels. By appending byte-code level in version I can produce multiple > artifacts for different byte-code levels, in a relatively easy way. But if > using variables in <version/> tag goes away then it becomes much more > difficult. That it works now I see as a very nice and flexible feature. > > > > BR / Tommy > > ______________________ > > Tommy Svensson > > to...@natusoft.se > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > >
