Re: [cu-dev] Release job

["Nathan Rauh" <nathan.rauh@xxxxxxxxxx>]

Actually I think
it might be a problem with the Jenkins build.

I can get it to
generate the right version (3.0.0) locally if I change,

 
      <non.final>true</non.final>
 
      <last.spec_version>1.1</last.spec_version>
 
      <next.spec_version>2.0</next.spec_version>
 
      <spec.version>${next.spec_version}</spec.version>
 
      <new.spec.version>3.0</new.spec.version>

to:
 
      <non.final>false</non.final>
 
      <last.spec_version>2.0</last.spec_version>
 
      <next.spec_version>3.0</next.spec_version>
 
      <spec.version>${next.spec_version}</spec.version>
 
      <new.spec.version>3.1</new.spec.version>

The above works
an generates correct 3.0.0 versions in the MANIFEST.MF.
However, I know
that we shouldn't be changing the versions because that's the responsibility
of the Jenkins release build.  So I tried changing only the first
property (non.final) but then it fails locally when a normal build is attempted.
 My conclusion is that probably Jenkins is intended to hard code non.final=false
on the release build, but isn't.

What do others
think - should/can that be changed in the release build?




From:
       "Nathan
Rauh" <nathan.rauh@xxxxxxxxxx>
To:
       "cu
developer discussions" <cu-dev@xxxxxxxxxxx>
Date:
       01/19/2022
02:57 PM
Subject:
       [EXTERNAL]
Re: [cu-dev] Release job
Sent
by:        "cu-dev"
<cu-dev-bounces@xxxxxxxxxxx>

---

Steve - Awesome! Thanks for
all of your hard work getting these Jenkins builds working. I looked over
the console output and it's clearly building the TCK jar as well as the
API, so hopefully that all ends up going to staging when we don't select
Steve - Awesome! Thanks for all of your hard work getting these Jenkins
builds working.

I looked over the console output and it's clearly building the TCK jar
as well as the API, so hopefully that all ends up going to staging when
we don't select the dry run option.

One potential minor issue that I did spot probably has nothing to do with
Jenkins and is that I see versions of 2.0.99.bnulland
2.0.99.nullbeing
reported in the log here,

[INFO] -- spec properties --
[INFO] spec.bundle.symbolic-name = jakarta.enterprise.concurrent-api
[INFO] spec.implementation.version = 3.0.0
[INFO] spec.extension.name = jakarta.enterprise.concurrent
[INFO] spec.bundle.spec.version = 2.0.99.bnull
[INFO] spec.specification.version = 2.0.99.null
[INFO] spec.bundle.version = 2.0.99.bnull

From past experience with locally built snapshots, I've seen those versions
show up in the MANIFEST.MF, for example as,

Bundle-Version: 2.0.99.bnull
Export-Package: jakarta.enterprise.concurrent;version="2.0.99.bnull";u
 ses:="jakarta.enterprise.util,jakarta.interceptor",jakarta.enterprise
 .concurrent.spi;version="2.0.99.bnull"
...
Specification-Version: 2.0.99.null

While Open Liberty can easily get around this by replacing the manifest
with one its own, it would be best to get it right for everyone in the
artifact that will end up on Maven.
I'll do some experimenting locally to see if I can correct it within the
pom somewhere.




From:        "Steve
Millidge (Payara)" <steve.millidge@xxxxxxxxxxx>
To:        "cu
developer discussions" <cu-dev@xxxxxxxxxxx>
Date:        01/19/2022
02:36 PM
Subject:        [EXTERNAL]
[cu-dev] Release job
Sent by:        "cu-dev"
<cu-dev-bounces@xxxxxxxxxxx>

---

I think I have got the release job into a stage where it may work. I’ve
only run a dry run but it is building the tck jar. Jakarta Concurrency
- Concurrency API release #61 [Jenkins] (eclipse.org) Steve ‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

I think I have got the release job into a stage where it may work. I’ve only run a dry run but it is building the tck jar.

Jakarta Concurrency - Concurrency API release #61 [Jenkins] (eclipse.org)

 

Steve

 

 _______________________________________________
cu-dev mailing list
cu-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cu-dev

_______________________________________________
cu-dev mailing list
cu-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cu-dev