5.0.0-SNAPSHOT referenced by grizzly-project-5.0.0.pom

[pzygielo]

https://repo.maven.apache.org/maven2/org/glassfish/grizzly/grizzly-project/5.0.0/grizzly-project-5.0.0.pom:

    <parent>
        <groupId>org.glassfish.grizzly</groupId>
        <artifactId>grizzly-bom</artifactId>
        <version>5.0.0-SNAPSHOT</version>
        <relativePath>boms/bom/pom.xml</relativePath>
    </parent>

👀

---

• Added repositories and deployment configuration #2275

[OndroMih]

@dmatej

[pzygielo]

• This makes some tools to fail for missing metadata, like openrewrite in Bump grizzly.version from 4.0.2 to 5.0.0 openmq#2809.

[pzygielo]

And with access to central-portal-snapshots blocked regular maven build does not like it as well:

Could not collect dependencies for project ...
[ERROR] Failed to read artifact descriptor for org.glassfish.grizzly:grizzly-portunif:jar:5.0.0
[ERROR] 	Caused by: The following artifacts could not be resolved: org.glassfish.grizzly:grizzly-bom:pom:5.0.0-SNAPSHOT (absent): Could not find artifact org.glassfish.grizzly:grizzly-bom:pom:5.0.0-SNAPSHOT in central-portal-snapshots (... blocked...)

[pzygielo]

This is perhaps the result of the same release job, that top-level pom.xml in https://github.com/eclipse-ee4j/glassfish-grizzly/tree/5.0.0 has version updated, but not version on parent:

glassfish-grizzly/pom.xml

Lines 24 to 34 in bce1a0d

	<parent>
	<groupId>org.glassfish.grizzly</groupId>
	<artifactId>grizzly-bom</artifactId>
	<version>5.0.0-SNAPSHOT</version>
	<relativePath>boms/bom/pom.xml</relativePath>
	</parent>
	<artifactId>grizzly-project</artifactId>
	<!-- Version must be repeated so versions-maven-plugin:set works correctly -->
	<version>5.0.1-SNAPSHOT</version>
	<packaging>pom</packaging>

while the bom-bom parent is not even touched:

glassfish-grizzly/boms/bom/pom.xml

Line 33 in bce1a0d

<version>5.0.0</version>

😞

[pzygielo]

@arjantijms Is there a plan to re-release something like 5.0.1 soon to address this issue and make Grizzly 5 fully usable?

[carryel]

@arjantijms I'm also curious if the release was made using the Jenkins job below.

https://ci.eclipse.org/glassfish/view/Grizzly/job/1_grizzly-build-and-release/80/

If so, would it be possible to reference other Grizzly derivative projects, such as grizzly-ahc, grizzly-memcached, grizzly-npn, etc., using this release job?

PS) The release above appears to have been made using JDK 17, but it would be better if it were updated to JDK 21.

https://ci.eclipse.org/glassfish/view/Grizzly/job/1_grizzly-build-and-release/80/injectedEnvVars/

[OndroMih]

Hi @carryel , @arjantijms , yes, Grizzly 5.0.0 was released by https://ci.eclipse.org/glassfish/view/Grizzly/job/1_grizzly-build-and-release/80/, but it's an obsolete job. Though it works correclty, and it uses Java 21 because the shell script sets the JAVA_HOME=/opt/tools/java/openjdk/jdk-21/latest, even if the job is started with JAVA_HOME pointing to Java 17.

We now prefer using this general job to release GlassFish components: https://ci.eclipse.org/glassfish/view/All%20Projects/job/all-projects_1_build-and-stage/
This job contains a parameter to select which component to release. The build shell script in the job sets env variables, e.g. JAVA_HOME, according to the selected components. The general job wasn't updated for Grizzly, I updated it now to set Java 21 instead of 17, and remove Maven configuration that used the old deploy plugin.

The general job doesn't contain config for other Grizzly components, it's currently configured only for the main github.com:eclipse-ee4j/grizzly.git repository.

We'll need to add config for the other Grizzly components and test whether it works. In general, every new component needs the following:

• add a component name to the list of choices for the PROJECT parameter
• add a section for the component name into the bash script that specifies its repository, Nexus staging description (STAGING_DESC var) and optionally other variables, like JAVA_HOME
• Very important - the repository needs to support the expected structure - has to be possible to release it by running a Maven deploy command from the top-level directory. Most repositories have that but I remember I had to adjust some older repos to meet the expectation, before I could release from this general job