You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@maven.apache.org by Tommy Svensson <to...@natusoft.se> on 2024/04/07 17:21:45 UTC
Will this potentially break in future releases ?
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
tommy@natusoft.se
Re: Will this potentially break in future releases ?
Posted by Tommy Svensson <to...@natusoft.se>.
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
tommy@natusoft.se
Från: Francois Marot <fr...@gmail.com>
Svara: Maven Users List <us...@maven.apache.org>
Datum: 7 april 2024 at 22:45:26
Till: Maven Users List <us...@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 <la...@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 (tommy@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
> > tommy@natusoft.se
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
Re: Will this potentially break in future releases ?
Posted by Tommy Svensson <to...@natusoft.se>.
"you will currently produce an invalid pom.xml which is unusable by others. !"
Hmm, this is interesting! You have a good point there! I didn't think that far!
My goal is to have one set of sources but provide repo deployable versions for both 11, and latest byte code supported by Groovy, and do that in an as uncomplicated way as possible.
I have my own repo at repsy.io which I can test against.
Thanks for the replies!
/Tommy
______________________
Tommy Svensson
tommy@natusoft.se
Från: Francois Marot <fr...@gmail.com>
Svara: Maven Users List <us...@maven.apache.org>
Datum: 7 april 2024 at 22:45:26
Till: Maven Users List <us...@maven.apache.org>
Ämne: Re: Will this potentially break in future releases ?
you will currently produce an invalid pom.xml which is unusable by others.
Re: Will this potentially break in future releases ?
Posted by Francois Marot <fr...@gmail.com>.
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 <la...@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 (tommy@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
> > tommy@natusoft.se
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
Re: Will this potentially break in future releases ?
Posted by Greg Chabala <gr...@gmail.com>.
I like both of these approaches better than the Scala approach to binary
compatibility, which is to munge a version into the artifact ID. That feels
very broken to me, but unfortunately that is their standard now.
I have heard of complaints that using classifiers to specify bytecode level
can cause dependency resolution issues, but that sounds like a problem that
needs to be exposed and solved, not worked around.
The POM reference highlights using classifiers for bytecode versioning
explicitly: https://maven.apache.org/pom.html#dependencies
(I wish this page had an anchor for the classifier section).
Re: Will this potentially break in future releases ?
Posted by Lasse Lindqvist <la...@gmail.com>.
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 (tommy@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
> tommy@natusoft.se
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org