Closed torsten-liermann closed 6 years ago
We always automatically publish both stable and snapshot releases to Maven central:
Look at version 3.3.1 in maven central, the jar only contains the classes of src/main/java. The ZIP file and the targz are missing. The same applies to version 3.3.0 . It would be better if the jar is FAT jar.
@torsten-liermann I now see what you mean, I'm checking the POM
remove the final name from configuration of the shade-plugin and also remove the maven-jar-plugin.
The issue was due to the move from the maven assembly plugin to the shade plugin.
This has been fixed in the 3.3.3-SNAPSHOT and 3.4.0-SNAPSHOT jar files. Usually it should require a few hours for 3.3.2 stable to propagate to Maven central. I'll try also to manually re-deploy the 3.3.1 to maven central as well.
BTW, I moved the finalName up to the build element, because I need to have a plain "restheart.jar" file for the Docker build process to work. I also need to keep the maven-jar-plugin because that allows to see the version number in logs when starting RESTHeart:
restheart | 20:12:00.392 [main] INFO org.restheart.Bootstrapper - ANSI colored console: true
restheart | 20:12:00.421 [main] INFO org.restheart.Bootstrapper - Starting RESTHeart instance restheart-docker
restheart | 20:12:00.423 [main] INFO org.restheart.Bootstrapper - version 3.4.0-SNAPSHOT
restheart | 20:12:00.430 [main] INFO org.restheart.Bootstrapper - Logging to file /var/log/restheart.log with level DEBUG
Thank you.
After a more careful review of the process, I've decided to go back to the maven assembly plugin and get rid of the shade plugin that was introduced in 3.3. This is necessary to preserve backward compatibility: there are many previous build systems in place that are already using the JAR with no dependencies, and moving to a JAR with dependencies could introduce unpredictable behaviors.
It means the fat jar will be available either directly from Github: https://github.com/SoftInstigate/restheart/releases/download/3.3.2/restheart-3.3.2.tar.gz
And via the maven central, but in the tar.gz or zip bundles, e.g. https://oss.sonatype.org/content/repositories/snapshots/org/restheart/restheart/3.4.0-SNAPSHOT/
This modification will be effective in terms of future versions from 3.3.3 and 3.4.0, as AFAIK Maven Central doesn't allow to republish already released artifacts.
For compatibility: please make a final build with all distribution artifacts and available via maven central.
From the perspective of CI builds, the download via github is no alternative.
If interested, I would like to simplify this maven build including building the docker image.
Hi @torsten-liermann The next 3.3.3 release will deploy on Maven both the nodeps JAR and an archive (zip, tgz) containing restheart with all dependencies. This was the normal behavior before 3.3 and we need to restore it. We include the restheart.jar "nodeps" distributed via maven to build and embed customized versions of restheart in several different projects.
Regarding docker: we played with the docker-maven-plugin but we ended using a bash script, which works pretty fine and it's fast. Is there any reason you think doing that with maven would be better?
We've just released 3.3.3 https://oss.sonatype.org/content/repositories/releases/org/restheart/restheart/3.3.3/
The restheart-3.3.3.jar has no deps, has it's usually just included as a dependency in other POMs, but if you download the zip or tgz archives, they contain the complete "with deps" release.
A compromise: the maven-shade-plugin creates the FAT jar in addition to the normal jar
<shadedClassifierName>fat</shadedClassifierName>
<CreateDependencyReducedPom>false</createDependencyReducedPom>
<ShadedArtifactAttached>true</shadedArtifactAttached>
Despite this would be feasible, we don't really like the idea to use Maven as a distribution device for releases. Instead, we have improved the build process and let Travis-ci automatically upload all the artifacts to Github releases when it finds a tag. From the next versions on, you'll find tar.gz, zip and also the fat jar automatically attached to each new release and those could be easily downloaded. Does this solve your problem?
No, not a good solution.
For maven (also gradle and so on) based CI builds it is necessary that the dependencies can be obtained from a repository in maven structure. Many Java projects on github deploy in maven repositories like maven central. Please also follow this principle for the small restheart project. Imagine the pom of restheart when dependencies like undertow, snake, http client and so on would not be reachable via maven repositories.
We have plenty of projects that builds using restheart as a dependency in CI/CD pipelines (with Travis-CI or bitbucket Pipelines) and we've never used the fat jar. Besides, we don't see this as a common practice. For example, below a complete POM which creates a fully customized restheart for one of our customers:
<?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>it.softinstigate</groupId>
<artifactId>art-restheart</artifactId>
<version>1.0-SNAPSHOT</version>
<packaging>jar</packaging>
<name>art-restheart</name>
<properties>
<project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
<maven.compiler.source>1.8</maven.compiler.source>
<maven.compiler.target>1.8</maven.compiler.target>
</properties>
<dependencies>
<dependency>
<groupId>org.restheart</groupId>
<artifactId>restheart</artifactId>
<version>3.3.3</version>
</dependency>
<dependency>
<groupId>org.json</groupId>
<artifactId>json</artifactId>
<version>20160810</version>
</dependency>
<dependency>
<groupId>com.mashape.unirest</groupId>
<artifactId>unirest-java</artifactId>
<version>1.4.9</version>
</dependency>
<dependency>
<groupId>com.cronutils</groupId>
<artifactId>cron-utils</artifactId>
<version>5.0.5</version>
</dependency>
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<version>4.12</version>
<scope>test</scope>
</dependency>
<dependency>
<groupId>org.hamcrest</groupId>
<artifactId>hamcrest-core</artifactId>
<version>1.3</version>
<scope>test</scope>
</dependency>
</dependencies>
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-shade-plugin</artifactId>
<version>2.4.1</version>
<configuration>
<finalName>${project.artifactId}</finalName>
<createDependencyReducedPom>true</createDependencyReducedPom>
<filters>
<filter>
<artifact>*:*</artifact>
<excludes>
<exclude>META-INF/*.SF</exclude>
<exclude>META-INF/*.DSA</exclude>
<exclude>META-INF/*.RSA</exclude>
</excludes>
</filter>
</filters>
</configuration>
<executions>
<execution>
<phase>package</phase>
<goals>
<goal>shade</goal>
</goals>
<configuration>
<transformers>
<transformer implementation="org.apache.maven.plugins.shade.resource.ManifestResourceTransformer">
<mainClass>org.restheart.Bootstrapper</mainClass>
</transformer>
</transformers>
</configuration>
</execution>
</executions>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-jar-plugin</artifactId>
<version>3.0.2</version>
<configuration>
<archive>
<manifest>
<addClasspath>true</addClasspath>
<mainClass>org.restheart.Bootstrapper</mainClass>
<addDefaultImplementationEntries>true</addDefaultImplementationEntries>
<addDefaultSpecificationEntries>true</addDefaultSpecificationEntries>
</manifest>
</archive>
</configuration>
</plugin>
</plugins>
</build>
</project>
After all, it's your projects and you can handle it the way you think is right.
Close the issue.
Hi,
Please push also the distributions to maven central.
Thanks, Torsten