Re: [DISCUSSION] activating Reproducible Builds by default in Maven 4
A follow-up message for those not familiar with the SOURCE_DATE_EPOCH
environment variable ...
On 9/25/24 9:22 AM, John Neffenger wrote:
That makes sense, but in general, I always set the date like this:
SOURCE_DATE_EPOCH=$(git log -1 --pretty=%ct)
export SOURCE_DATE_EPOCH
I pass that to Maven with:
${env.SOURCE_DATE_EPOCH}
The page below describes the variable, including a link to its
specification:
SOURCE_DATE_EPOCH
https://reproducible-builds.org/docs/source-date-epoch/
The following page gives more background information:
ReproducibleBuilds/StandardEnvironmentVariables
https://wiki.debian.org/ReproducibleBuilds/StandardEnvironmentVariables
John
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
Re: [DISCUSSION] activating Reproducible Builds by default in Maven 4
On 9/25/24 7:23 AM, Jorge Solórzano wrote:
* Using the SCM last commit date is a bad choice, not everyone will use SCM
or the source code could be downloaded without scm information (eg.: Source
Code download links from GitHub), so this is a -1 for me.
That makes sense, but in general, I always set the date like this:
SOURCE_DATE_EPOCH=$(git log -1 --pretty=%ct)
export SOURCE_DATE_EPOCH
I pass that to Maven with:
${env.SOURCE_DATE_EPOCH}
* This leaves us with the fixed value by default, the current value (in the
PR) is 2001-01-01T00:00:00Z this is a good approach, but my personal
preference is to set it to 1980-01-01T00:00:02Z, the minimal date allowed.
Right! See my comment below on the pull request that added this feature
to the 'jar' and 'jmod' tools in the JDK:
https://github.com/openjdk/jdk/pull/6481#issuecomment-984220137
Just for reference, at the time of my comment, Debian added 12 hours 1
minute to the first second of 1980 for their default value
(1980-01-01T12:01:00Z), while Gradle skipped to the next month
(1980-02-01T00:00:00Z).
The main thing is to avoid 1980-01-01T00:00:00Z, 1980-01-01T00:00:01Z,
and any earlier instant.
There should be a way to opt out of this and get the previous behavior for
those that don't what this.
How about just using SOURCE_DATE_EPOCH directly when defined? I guess
that's more opt-in than opt-out, but it would at least let me avoid
having to define 'project.build.outputTimestamp' in all my projects.
John
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
Re: Maven 3.9.9 unexpected operator
Thank you, Tamás. Respin #1 is working fine for me now. John On 8/14/24 1:32 AM, Tamás Cservenák wrote: Howdy, Thanks for testing! Fix is on way (3.9.9 and 4) and will respin 3.9.9 release: https://github.com/apache/maven/pull/1652 https://github.com/apache/maven/pull/1653 Thanks T - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Maven 3.9.9 unexpected operator
I think the errors I'm getting in my previous message are from Maven 3.9.9 using a Bash construct in a normal '/bin/sh' shell script, which is dash on my Ubuntu system. Dash prints the "unexpected operator" error message when '==' is used instead of '=' in a test. I think you can also use '-eq' for the test. It's on Line 43 of this file: maven/apache-maven/src/assembly/shared/init https://github.com/apache/maven/blob/master/apache-maven/src/assembly/shared/init#L43 Thanks, John - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Release Apache Maven 3.9.9
-1 I'm getting the following error when I run Maven 3.9.9 in a directory that does not have a ".mvn" sub-directory. Does anyone else get these errors? .../maven/bin/mvn: 136: [: /home/john: unexpected operator .../maven/bin/mvn: 136: [: /home: unexpected operator .../maven/bin/mvn: 136: [: /: unexpected operator .../maven/bin/mvn: 136: [: //: unexpected operator If I change to a directory containing ".mvn", it works fine. Seems to be related to this change: [MNG-8165] Align mvn.sh script with mvn.cmd (#1648) https://github.com/apache/maven/commit/cf2934b Thanks, John - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Maven 3.9.7 fails to activate profile?
On 5/28/24 7:52 AM, Tamás Cservenák wrote: well, after a quite long investigation we came to several conclusions: * 3.9.6 and before worked really "by chance", as * the POM is invalid Thank you very much, Tamás and Romain. I really appreciate your help and expertise. I will report the issue to the OpenJFX project. In fact, am unsure what produced this POM, as Maven cannot even grasp it (refuses to load it even): https://gist.github.com/cstamas/27b948306cddabd00105f747e744e2cd I recreated those errors now, too. Thanks for the evidence. John - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Maven 3.9.7 fails to activate profile?
Thank you for the quick response, Tamás. On 5/27/24 11:51 AM, Tamás Cservenák wrote: Can you create a small reproducer, ideally shared on github or similar service? This "Hello World" JavaFX project illustrates the problem for me: Hello JavaFX! https://github.com/jgneff/hello-javafx Just clone and build with: $ git clone https://github.com/jgneff/hello-javafx.git $ cd hello-javafx $ mvn clean package Thanks, John - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Maven 3.9.7 fails to activate profile?
Maven 3.9.7 fails to set a profile property in the main JavaFX POM:
Maven Central: org.openjfx:javafx:22.0.1
https://central.sonatype.com/artifact/org.openjfx/javafx/22.0.1
Building a simple JavaFX program with Maven 3.9.6 or 3.8.8 works fine,
but I get the following error when I upgrade to Maven 3.9.7:
$ mvn clean package
[ERROR] Failed to execute goal on project hello-javafx:
Could not resolve dependencies for project
org.status6.hello:hello-javafx:jar:1.0.0:
The following artifacts could not be resolved:
org.openjfx:javafx-controls:jar:${javafx.platform}:22.0.1 (absent),
org.openjfx:javafx-graphics:jar:${javafx.platform}:22.0.1 (absent),
org.openjfx:javafx-base:jar:${javafx.platform}:22.0.1 (absent):
Could not find artifact
org.openjfx:javafx-controls:jar:${javafx.platform}:22.0.1
in central (https://repo.maven.apache.org/maven2) -> [Help 1]
It seems that the property 'javafx.platform' is no longer being set, so
Maven 3.9.7 tries to download the following artifacts:
$ mvn -U clean package
Downloading from central:
https://repo.maven.apache.org/maven2/org/openjfx/javafx-controls/22.0.1/javafx-controls-22.0.1-$%7Bjavafx.platform%7D.jar
Downloading from central:
https://repo.maven.apache.org/maven2/org/openjfx/javafx-graphics/22.0.1/javafx-graphics-22.0.1-$%7Bjavafx.platform%7D.jar
Downloading from central:
https://repo.maven.apache.org/maven2/org/openjfx/javafx-base/22.0.1/javafx-base-22.0.1-$%7Bjavafx.platform%7D.jar
I'm running with:
$ ~/opt/apache-maven-3.9.7/bin/mvn --version
Apache Maven 3.9.7 (8b094c9513efc1b9ce2d952b3b9c8eaedaf8cbf0)
Maven home: /home/john/opt/apache-maven-3.9.7
Java version: 21.0.2, vendor: Private Build, runtime:
/usr/lib/jvm/java-21-openjdk-amd64
Default locale: en_US, platform encoding: UTF-8
OS name: "linux", version: "5.15.0-107-generic", arch: "amd64", family:
"unix"
I have a couple questions:
1. Does JavaFX need to update how it's setting this platform classifier?
2. Could this be related to the following change?
MNG-8081 - default profile activation should consider available system
and user properties
https://issues.apache.org/jira/browse/MNG-8081
Thank you,
John
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Require Java 17 for Maven 4
+1 (set JDK17 min version for Maven 4.x) Secretly hoping it ends up being JDK 21 (or an even later LTS), John On 2/27/24 11:30 PM, Benjamin Marwell wrote: Hi Maven Devs/Users/Committers and PMC members! After several discussions on the mailing lists, I would like to start a vote in favour of setting the minimal Java bytecode target of Maven-Core 4 to 17 and hence require Java 17 for Maven 4. This is a procedural majority vote [1*]: You can also vote with fractions and negative votes are not vetoes. Please also notice: * Maven 3 will stay at Java 8 no matter what. * We may raise Maven 4 to JDK 21 later if we feel like it (depending on the release date). This is not part of this vote. * The linked PR is not part of this vote (this is not a code vote). But you may take a look at it to understand the intended change. PR: https://github.com/apache/maven/pull/1430 Maven-Parent will not be raised with this vote, the other PR is not part of this vote. Please refrain from starting discussions in this thread, but do include a reasoning on downvotes and feel free to start a new discussion on the mailing list, or comment on the existing ones. --- Vote open for 72 hours: [ ] +1 (set JDK17 min version for Maven 4.x) [ ] +0 [ ] -1 (please include reasoning) --- - Ben [1*]: https://www.apache.org/foundation/voting.html - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [DISCUSS] Java version for Maven
On 2/26/24 11:42 AM, Basil Crow wrote: We had a similar conversation in the Jenkins community, and I wrote up our conclusions here: We also had a similar conversation in the NetBeans community, with the final vote to drop JDK 8 (vote result: 20 to 1.5). See here: [VOTE][RESULT] Minimum JDK build and run policy (dropping JDK 8) https://lists.apache.org/thread/oq8bof3owctq0ot6xwk03n3w45d09zcc In particular, see the comments from James Gosling: Re: Lets talk about JDK 8 (new year edition) https://lists.apache.org/thread/sspm6fy1xq0jn2k8lfprn47v69g88jvh "So…. In my opinion, JDK8 must die." "Stop the unholy contortions to coexist. Kill it. Nail its coffin closed. Do not look back." I couldn't agree more. :-) John - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
