Mavenize #7
Mavenize #7
Conversation
|
GH CI results here https://github.com/cstamas/dsiutils/actions/runs/4357867583/jobs/7617701838 |
|
Oh wow. That's a lot of information. Let me digest 😂. Thanks! |
|
This is NOT to be committed, just a "demo" you can start from... But again, there is a lot more to be done:
As you want to end up with maven artifact, and want to deploy to Maven Central, unsure why is build still Ant and not Maven... Just ask if anything more needed. |
|
Will continue later... so you can track the changes. But again: DO NOT MERGE |
|
OK, there's no danger at the moment: I hate Maven and the way it forces you to do things his way. 😂 |
|
So, just try One problem remaining: if you'd use Ivy, it would replace the POM added by this PR (the IMHO, next step would be to adhere to standard project layout, drop Ant/Ivy build... See the updated README for some hints. |
|
Also, maven does not force you to do anything, the point of maven is that whoever checks out the project, does not have to look left and right to find things, but there is "standard" layout. And same fol building, no need to sift thru ant XML, but |
Added bnd-process and use it in JAR
Layout reorganized to standard project layout.
|
Layout reorganized, you can check how it looks here: https://github.com/cstamas/dsiutils/tree/mavenize All tests collapsed as you did good job of naming them Test ans SlowTest, so the improvement here is that SlowTest always compile, so is easier to spot mistakes, but they run only if -P slow profile is activated. |
|
Last bits are bash/, prngperf and setcp.sh, as am unsure what are they used to.... I'd like some hint here... the bash would most probably become some submodule, maybe prngperf as well.... Waiting for some input! |
|
|
|
Once you compare output of https://github.com/vigna/dsiutils/tree/master and https://github.com/cstamas/dsiutils/tree/mavenize and those match your expectations, you CAN merge 😄 to have maven build |
|
Also,merge will give you CI as well, run of last commit https://github.com/cstamas/dsiutils/actions/runs/4364687079/jobs/7632309036 |
|
Hint: here https://github.com/cstamas/dsiutils/blob/mavenize/.github/workflows/maven.yml#L17 add to line end |
|
To get Java CP: |
|
Well, really thanks, that was a lot of work. I'll check it—if I do this I'll have to do the same to all my projects, so I have understand exactly what I'm doing. Any way to download automatically last releases like I do with Ivy? |
|
Well, the "download automatically last releases" goes against reproducible builds principle (so even a tagged commit would become "movable target" if there is a new release of some dependency). With Maven it is "best practice" to keep versions locked down, and on next dev iteration "just ask" for new versions: |
|
What did you say about Maven not forcing you to do things his way? 🤔😂 This is a complicated topic. For a library, the fact that versions are nailed down doesn't mean much, because when the library will be used by someone else Maven will resolve conflicts and the library might and up running with a different version. Rust has truly reproducible builds, at the price of building everything from scratch and never relying on dynamic libraries. |
|
Well, there are some misconceptions here, and probably my wrong choice of words.... When I said "lock down" versions, I mean "express versions". What happens in YOUR project (when your project P is being built) is that you build your P project that has D1, D2, ... dependencies (those 1st level specified in POM/dependencies), and Maven "mediates" the dependencies as needed (your case can be called "trivial"). When some other project Q uses your project P as a dependency things are different. In that case again, the built project Q prevails, while the transitive dependencies enlisted by your project P are taken into account as "recommendations", and Maven sorts out any conflicts and mediation. So to say, when dsiutils is used as library, then yes, user of this project as dependency may opt to choose newer SLF4J API for example. To avoid that (and cause many sleepless nights to downstream developers) specify your dependencies as "locked down" -- It is assumed developer of Q (consumer of P) "knows best" what he does, and also assume something like "semantic versioning", so 1.2.1 is binary compatible with 1.2.2 and so on. Just to demonstrate this breakage that you dont want to do:
diff --git a/pom.xml b/pom.xml
index 85f5a79..ace04bd 100644
--- a/pom.xml
+++ b/pom.xml
@@ -62,7 +62,7 @@
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>slf4j-api</artifactId>
- <version>2.0.3</version>
+ <version>[2.0.3]</version>
</dependency>
<dependency>
<groupId>ch.qos.logback</groupId>Locks down slf4j-api strictly to 2.0.3.
<?xml version="1.0" encoding="UTF-8"?>
<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>
<groupId>org.cstamas.example</groupId>
<artifactId>project</artifactId>
<version>1.0-SNAPSHOT</version>
<dependencies>
<dependency>
<groupId>it.unimi.dsi</groupId>
<artifactId>dsiutils</artifactId>
<version>2.7.4-SNAPSHOT</version>
</dependency>
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>slf4j-api</artifactId>
<version>[2.0.4]</version>
</dependency>
</dependencies>
</project>Would use dsiutil with strictly another slf4j-api version.
It figures these two are doomed to fail. |
|
That's what I said. 🤷🏻♂️ |
|
But again, this above is complicated issue, as you mention. But for me, bigger and much much worse issue is this one: if I check out git tag 2.7.2 after 5 years, and let's assume Ceki releases SLF4J 3.0.0, Ivy will pick it up happily. Meaning, that the git tag is not reproducible, it is a "moving target", something that does not happen with approach like this one. Dev cycle is:
Meaning all your tags are reproducible, are not "moving targets". You can rebuild, since as you mention, rebuilding from source is something many (ie. Google) chooses to do even with Java. |
Just to pull the string with some honey on it.... 😄
But it would be better to adopt "standard" project layout (src/main/java, src/test/java) etc...